Formazione Regione Marche 4/5 Aprile 2013
Giovedi’ 4
1 14:00 - 14:30 (Livio)
Introduzione al Monitoring!30' 2 14:30 - 15:30 (Attilio)
Panoramica sui pacchetti Ganglia e Nagios!1h00' 3 15:30 - 16:00 (Livio/Hassen)
Metriche, Architettura e integrazione in OpenStack!30' 4 16:15 - 16:45 (Andrea)
Ciclo di vita delle immagini virtuali: automatismi per alta affidabilità!30' 5 16:45 - 17:45 (Hassen/Andrea)
Descrizione delle funzionalità del pacchetto MMC (Monitor per Marche Cloud)!1h00'
" " 1. Contestualizzazione nell'infrastruttura!20'
" " 2. Integrazione di Ganglia/Nagios nella Dashboard!20'
" " 3. Scripting e Plugin realizzati!20'
Venerdi' 5
6 09:00 - 09:30 (Livio)
Lezioni dal periodo di rodaggio 12/12-2/13!30' 7 09:30 - 11:15 (Andrea/Hassen)
Laboratorio - Training specifico sulla Dashboard, pratica all'uso dei livelli di monitoring in MMC!2h00
" 1. Installazione passo per passo di MMC (1h00)
" " installazione standard di Nagios
" " installazione standard di Ganglia
" " installazione del User-Level Monitoring
" " integrazione nella Dashboard
" " " 2. Configurazione di MMC 1h00
" " " " configurazione e tests di Nagios e Ganglia
" " " " configurazione e tests di user level monitoring
Formazione Regione Marche 4/5 Aprile 2013
Giovedi’ 4
1 14:00 - 14:30 (Livio)
Introduzione al Monitoring!30' 2 14:30 - 15:30 (Attilio)
Panoramica sui pacchetti Ganglia e Nagios!1h00' 3 15:30 - 16:00 (Livio/Hassen)
Metriche, Architettura e integrazione in OpenStack!30' 4 16:15 - 16:45 (Andrea)
Ciclo di vita delle immagini virtuali: automatismi per alta affidabilità!30' 5 16:45 - 17:45 (Hassen/Andrea)
Descrizione delle funzionalità del pacchetto MMC (Monitor per Marche Cloud)!1h00'
" " 1. Contestualizzazione nell'infrastruttura!20'
" " 2. Integrazione di Ganglia/Nagios nella Dashboard!20'
" " 3. Scripting e Plugin realizzati!20'
Venerdi' 5
6 09:00 - 09:30 (Livio)
Lezioni dal periodo di rodaggio 12/12-2/13!30' 7 09:30 - 11:15 (Andrea/Hassen)
Laboratorio - Training specifico sulla Dashboard, pratica all'uso dei livelli di monitoring in MMC!2h00
" 1. Installazione passo per passo di MMC (1h00)
" " installazione standard di Nagios
" " installazione standard di Ganglia
" " installazione del User-Level Monitoring
" " integrazione nella Dashboard
" " " 2. Configurazione di MMC 1h00
" " " " configurazione e tests di Nagios e Ganglia
" " " " configurazione e tests di user level monitoring 8 12:00 - 13:30 (Andrea/Hassen)
Training su simulazioni di condizioni specifiche (istanza che muore, sovraccarica, hanged...)!1h45'
" " " 1. Overview dei plugins esistente in Nagios (30 min)
" " " 2. Abilitare/Disabilitare un plugin esistente
" " " 3. Modificare l’azione associata
9 14:30 - 16:30 (Andrea/Hassen)
Personalizzazione delle soluzioni di monitoring (realizzazione di allarmi su eventi specifici)!2h00'
" " " 1. Event handler che riavvia tomcat se httpd non risponde
" " " 2. Se una delle partizioni e’ occupata > 90%, un event handler:
" " " " 2.1 cancella tutti file in /tmp che matchano un dato pattern
" " " " 2.2 se lo spazio utlizzato e' ancora > 90% notifica le
" " " " cartelle che usano piu' spazio agli admin
" " " 3. Plugin in nagios che controlla i tentativi ssh falliti:
" " " " 3.1 se i tentativi di un dato indirizzo supera una certa soglia
" " " " manda una mail che contiene l’indirizzo agli admin e cambia
" " " " le regole del firewall per bloccare l’indirizzo
Cloud
Monitoring
Livio Fanò
INFN - Perugia
• Background
• Il Cloud Monitoring
– System-‐level – User-‐level
– Network-‐level
Background
• Complessità e pun> cri>ci di una Cloud
– Scala ed eterogeneità dell’infrastru3ura
• Servers, network devices, storages, etc.
• cen9naia, migliaia di macchine
– Alto numero di applicazioni
• Possibili conseguenze catastrofiche per failure / security breach / performance degrada9on
• Il Monitoring e’ Indispensabile
– Availability, failure detec9on – Performance, provisioning – Security, anomaly detec9on – Applica9on-‐level monitoring
Background
• Monitoring-‐as-‐a-‐Service
– Simile ad altri Servizi-‐Cloud
• Database service
• Storage service
• Applica9on service
– Benefici
• Supporto End-‐to-‐end, integrato e facile da usare, mantenere
• Implementazione condivisa
Systems Monitoring
Systems Monitoring
External Monitor
website, fileserver, mail server, VoIP, DB
HTTP/HTTPS GET/POST, PING, TCP, UDP, POP3, IMAP, SMTP,
FTP, VOIP, DNS, MySQL Check Response Time and
Availability
perchè un sito è in crash ?
Server Monitor
CPU, Memory, Processes, Storage;
Linux, Windows, FreeBSD, Solaris Agents
es: agen9 mandano i da9 al sistema di monitoring
nessuna necessità di modificare il firewall
supporto na9vo per infrastru3ure distribuite
problemi di networking ?
Network Monitor
SNMP, ping, h?p, ssh, discovery
“Agentless check” dei disposi>vi di networking e
servers
tuR gli aspeR di un sito sono
soSo controllo ?
Transac>on Monitor
Mul>-‐step applica>ons, scenario-‐based
Applica9on workflow, checks, simulazioni di azioni
da parte dell’end-‐user
16
ho il controllo sulle applicazioni/da>
nella cloud?
Cloud Monitor
instances, automa>on, usage
monitor delle istanze, auto-‐
deploy di monitoring tool per server e applicazioni, controllo
dell’u9lizzo
quale livello di traffico per un sito ?
Web Traffic Monitor
visitors, page views, keywords, referrers
Real-‐>me web traffic
tracking
un po’ piu’ in deSaglio...
Background
• Monitoring di Stato -‐ flusso logico
– Osserva lo stato di un sistema / applicazione / servizio
– Dove per “stato” si intende un valore scalare che descrive un certo parametro di funzionamento, V
• ad esempio l’uso della CPU, tempo medio di risposta ecc...
– Condizione di violazione de V > T
Background
• Monitoring di Stato distribuito
– Il valore di stato V è aggregato tra diversi oggeR – Monitor e ColleSore
– Ad esempio un “web server monitoring” (consumo medio della CPU)
Background
• ArchiteSura
– Monitor Server
– Coordinator Server
Preroga>ve a Livello di Sistema
• Scalabilità
– Possibilità di supportare mol> tasks separa> di monitoring – Costo effeRvo: minimizzare l’uso di risorse
• QoS (priorità differen> ad applicazioni differen>) – Mul>-‐tenancy environment
– Minimizzazione dei confliR di risorse tra i task di monitoring
Scalabilità
• Massive Scale
– Mol9 task di monitoring sono intrinsecamente di larga scala
• Es. ServiceLevelAgreement monitoring
– Numero grande di uten9
• Infrastructure monitoring
• Applica9on monitoring
– Task specifici ad “alto costo”
• Es. “heavy hi3er” detec9on basato su un qualche algoritmo
• Costo effeRvo
– Monitoring e’ un servizio che deve aiutare (semplice) – Deve coinvolgere meno risorse possibile
Scalabilità
• Osservazione
– Non tuR i task hanno bisogno di un monitoring intensivo
– Un task potrebbe non averne bisogno sempre
Scalabilità
• Probabilità di violazione
– Monitoring intensivo quando
• solo per i task con alta probabilità di violazione
• solo quando la probabilità locale di un task è alta
– Un metodo efficiente di s9ma della violazione è basato sul campionamento del differenziale δ
– La frequenza del campionamento è definita dall’a3endibilità della s9ma probabilis9ca (tolleranza)
V2
V1 δ
Time Monitored
Value
Scalabilità
• variabilità dell’osservabile
• Distribuire la tolleranza tra nodi di monitoring mul>pli
Error Allowance
Scalabilità
• Monitoring sta>co VS dinamico
Preroga>ve a Livello di Sistema
• Scalabilità
– Possibilità di supportare mol> tasks separa> di monitoring – Costo effeRvo: minimizzare l’uso di risorse
• QoS
– Mul>-‐tenancy environment
– Minimizzazione dei confliR di risorse tra i task di monitoring
Quality-‐of-‐Service
• Implicazioni del Mul>-‐Tenancy (singola istanza -‐> mol> uten>) – Monitoring tasks (aggiungere, rimuovere...)
– ConfliSo delle risorse tra i task
• Capire l’impaSo del confliSo di risorse
• Implementazione di un monitoring server
Quality-‐of-‐Service
• Threading per Monitor Servers
– ObieRvi di scalabilità e prestazioni – Implementazione Naïve
• Un thread per nodo
• Gran numero di task simultanei
• Costo di threading elevato
– Implementazione basata su un Thread-‐pool
• Scheduling globale per tua i nodi di monitor associa9 ad un server
–Sampling condizionato (trigger) –Scalabilità: sorted triggers
Quality-‐of-‐Service
• ImpaSo del confliSo di risorse
– Sampling job possono finire a tempi diversi (mis-‐deadlines) – I task potrebbero perdere alcuni pun9 di sampling (misfiring)
Quality-‐of-‐Service
• La risoluzione dei confliR:
– Non è sufficiente l’uso medio di una risorsa
• potrebbe portare a decisioni sbagliate
– Il Monitor dello stesso task dovrebbe essere eseguito allo stesso tempo
• minimizzare il 9me shic
60 secs 60 secs 60 secs
60 secs 60 secs 60 secs
Quality-‐of-‐Service
60 secs 60 secs 60 secs
60 secs 60 secs 60 secs
• La risoluzione dei confliR:
– Non è sufficiente l’uso medio di una risorsa
• potrebbe portare a decisioni sbagliate
– Il Monitor dello stesso task dovrebbe essere eseguito allo stesso tempo
• minimizzare il 9me shic
Quality-‐of-‐Service
60 secs 60 secs 60 secs
60 secs 60 secs 60 secs
• La risoluzione dei confliR:
– Non è sufficiente l’uso medio di una risorsa
• potrebbe portare a decisioni sbagliate
– Il Monitor dello stesso task dovrebbe essere eseguito allo stesso tempo
• minimizzare il 9me shic
Quality-‐of-‐Service
60 secs 60 secs 60 secs
60 secs 60 secs 60 secs
• La risoluzione dei confliR:
– Non è sufficiente l’uso medio di una risorsa
• potrebbe portare a decisioni sbagliate
– Il Monitor dello stesso task dovrebbe essere eseguito allo stesso tempo
• minimizzare il 9me shic
Quality-‐of-‐Service
• Approccio intui>vo
– CaSura di paSern per
• Task di consumo delle risorse
• Disponibilità di risorse
– Matching efficiente dei paSern d’uso e di disponibilità
– Riduzione del 50%-‐80% delle mis-‐deadlines e misfiring
Preroga>ve a Livello Utente
• Budget-‐Aware Monitoring
– PermeSe una risoluzione dinamica del monitoring in base al budget disponibile
• Distributed Con>nuous Viola>on Detec>on
– Incontra i bisogni di modelli differen>
– Efficiente
Budget-‐Aware Monitoring
• Cloud e “Pay-‐as-‐You-‐Go”
– Associa dire3amente i cos9 computazionali con quelli monetari – Perme3e un provisioning flessibile basato sul budget disponibile
• Overhead nel Cloud Monitoring
– costo di processamento della violazione
• Es. nuovi server in corrispondenza di un allarme rela>vo al degrado delle prestazioni – consumo di per se del budget dell’utente
• Cosa manca alle tecniche di monitoring a3uali ?
– assenza in generale di una connessione tra u9lity di monitoring e costo del monitoring –Es. il consumo del budget di un task di monitoring è sconosciuto
– un modello di monitoring ideale
Budget-‐Aware Monitoring
• Perchè è necessaria una nuova interfaccia
– auto-‐scaling delle web-‐applica>on
• aggiunge/rimuove server in base alle prestazioni
• dato un budget, come si dovrebbe configurare un task di monitoring ?
Budget-‐Aware Monitoring
• Risoluzione
– Granularità del monitoring – “sliding windows”
• Es. mediare i valori di riferimento in una certa finestra temporale
Budget-‐Aware Monitoring
• Risoluzione
– Granularità del monitoring – “sliding windows”
• Es. mediare i valori di riferimento in una certa finestra temporale
Budget-‐Aware Monitoring
• come funziona ?
– Si determina la risoluzione del monitoring in base al budget disponibile
• budget abbondante
–risoluzione ad alta granularità
–vengono risolte violazioni di ogni 9po
• budget limitato
–risoluzione peggiore
–vengonoo risolte solo le violazioni principali
Budget-‐Aware Monitoring
• esempio architeSura
• Distributed Con>nuous Viola>on Detec>on
– Modello di rilevazione istantanea – Modello a rilevazione con>nua
Short-term burst Persistent violation
L L
Preroga>ve a Livello Utente
Network Level
• Resource-‐Aware Monitoring -‐ struSura
– Monitor del funzionamento sia dei sistemi che delle applicazioni su larga scala
– Raccolta con9nua e de3agliata dei valori di monitoring
• alto numero di nodi
• alto numero di osservabili
– Overhead cresce rapidamente se l’infrastru3ura, le applicazioni ed i task di monitoring crescono
• Goal
– organizzare i nodi in stru3ure di monitoring – non violare il “per-‐node resource constraint”
– minimizzare il numero di osservabili
