Lezioni dal data center: Disponibilità gestita (Managed Availability)

Articolo originale pubblicato sabato 22 settembre 2012

Il monitoraggio è un elemento chiave per una distribuzione corretta di Exchange. Nelle versioni precedenti ci siamo fortemente impegnati per lo sviluppo di un motore di correlazione e abbiamo lavorato in stretta collaborazione con il gruppo del prodotto System Center Operations Manager (SCOM) per offrire una soluzione di invio di avvisi globale per gli ambienti Exchange.

Il monitoraggio ha sempre comportato la raccolta di dati ed eventualmente l'esecuzione di un'azione in base ai dati raccolti. Nel contesto di SCOM ad esempio vengono utilizzati diversi meccanismi per raccogliere dati tramite Exchange Management Pack:

Obiettivi di monitoraggio di Exchange Server 2013

Quando abbiamo iniziato a sviluppare Exchange 2013, una delle aree chiave su cui ci siamo concentrati è stato il miglioramento del monitoraggio end-to-end per tutte le distribuzioni di Exchange, dalla più piccola in locale alla più grande in assoluto, ovvero Office 365. Avevamo tre obiettivi principali:

1. Offrire la nostra conoscenza ed esperienza del servizio Office 365 ai clienti delle versioni in locale. Per quasi sei anni il gruppo del prodotto Exchange ha utilizzato Exchange Online. Il modello di operazioni utilizzato è conosciuto come modello di operazioni per sviluppatori (DevOps). In questo modello i problemi vengono riassegnati direttamente allo sviluppatore di una funzionalità che presenta problemi di prestazioni nel servizio o per cui viene segnalato da un cliente un problema sconosciuto. Indipendentemente dall'origine del problema, la riassegnazione diretta allo sviluppatore fa sì che se ne faccia carico con la correzione degli eventuali difetti.

   Utilizzando questo modello abbiamo appreso molto. Ad esempio, in Exchange 2010 Management Pack esistono almeno 1100 avvisi, ma negli anni abbiamo scoperto che solo circa 150 di questi avvisi sono utili in Office 365 (e abbiamo disabilitato il resto). Abbiamo scoperto inoltre che quando uno sviluppatore riceve una riassegnazione, è più probabile che si faccia carico del problema e si impegni a risolverlo (mediante una correzione del codice, nuovi flussi di lavoro di ripristino, la modifica dell'avviso e così via), poiché non desidera essere continuamente interrotto per risolvere sempre la stessa questione. Nel modello DevOps è previsto un processo in cui ogni settimana il personale reperibile tiene una riunione di assegnazione per esaminare gli eventi della settimana precedente. In questo modo vengono sviluppati flussi di lavoro di ripristino interni, ad esempio la reimpostazione dei pool di applicazioni IIS e così via. Prima di Exchange 2013, disponevamo del nostro motore interno per la gestione di questi flussi di lavoro di ripristino. Questo processo non è stato mai applicato nei prodotti in locale. Con Exchange 2013, abbiamo creato componenti del motore dei flussi di lavoro di ripristino in modo da poter condividere queste esperienze con i clienti dei prodotti in locale.

2. Eseguire il monitoraggio in base all'esperienza dell'utente finale. Siamo inoltre giunti alla conclusione che molte delle metodologie utilizzate per il monitoraggio non sono utili in realtà per l'utilizzo dell'ambiente. Stiamo passando quindi a una visione incentrata sul cliente per il metodo di monitoraggio utilizzato.

   Nelle versioni precedenti il team di ogni componente avrebbe sviluppato un modello di integrità articolando i diversi componenti del sistema. Ad esempio, il trasporto è costituito da SMTP-IN, SMTP-OUT, agenti di trasporto, classificatore, motore di routing, driver di archivio e così via. Il team preposto a questi componenti avrebbe quindi creato avvisi per ognuno di questi componenti. Nel Management Pack sarebbero stati inclusi quindi avvisi in cui viene indicato che si è verificato un errore del driver di archivio. Sarebbero mancate però informazioni sull'esperienza utente end-to-end o sul problema riscontrato nell'esperienza utente. In Exchange 2013 stiamo tentando quindi di ribaltare il modello. Non ci stiamo liberando del monitoraggio a livello di sistema, perché è comunque importante. Quello però che è veramente importante se si desidera gestire un servizio è il problema percepito dal punto di vista degli utenti. Abbiamo quindi ribaltato il modello per tentare di monitorare l'esperienza utente.

3. Proteggere l'esperienza utente mediante l'elaborazione orientata al ripristino. Con le versioni precedenti di Exchange, il monitoraggio è sempre stato basato sul sistema e sui componenti e non su come recuperare e ripristinare automaticamente le funzionalità dell'utente finale.

Monitoraggio di Exchange Server 2013 - Disponibilità gestita (Managed Availability)

Disponibilità gestita (Managed Availability) è un'infrastruttura di monitoraggio e ripristino integrata con la soluzione di disponibilità elevata di Exchange. Consente di individuare i problemi e di eseguire contestualmente il ripristino.

Si tratta di un'infrastruttura incentrata sull'utente. Desideriamo misurare tre aspetti chiave: la disponibilità, l'esperienza (che per la maggior parte dei protocolli client viene misurata come latenza) e se si verificano errori. Per illustrare questi tre aspetti, prendiamo in esame un esempio di un utente che utilizza Outlook Web App (OWA).

La disponibilità indica semplicemente se l'utente può o meno accedere alla pagina Web di autenticazione basata su moduli di OWA. Se non è possibile accedere, l'esperienza è bloccata e viene generata una riassegnazione all'helpdesk. Per quanto riguarda l'esperienza, in caso di accesso a OWA, viene indicato ad esempio come è l'esperienza, se l'interfaccia si carica correttamente e se è possibile accedere alla posta. L'ultimo aspetto è la latenza, ovvero la velocità di rendering della posta nel browser, partendo dal presupposto che l'utente sia in grado di connettersi e accedere all'interfaccia. Queste sono le aree che costituiscono l'esperienza dell'utente finale.

Una delle differenze principali tra le versioni precedenti ed Exchange 2013 consiste nel fatto che in Exchange 2013 la soluzione di monitoraggio non tenta di fornire la causa radice. Questo non significa che i dati non vengano registrati nei log, che non vengano generati dump o che non sia possibile individuare la causa radice. È importante capire che con le versioni precedenti non eravamo sempre efficienti nel comunicare la causa radice: a volte avevamo ragione, ma spesso avevamo torto.

Componenti di Disponibilità gestita (Managed Availability)

La funzionalità Disponibilità gestita (Managed Availability) è incorporata in entrambi i ruoli del server in Exchange 2013. Include tre componenti asincroni principali. Il primo componente è il motore probe. Il compito di questo motore è quello di effettuare misurazioni nel server. Si passa così al secondo componente, ovvero il monitor, in cui è contenuta la regola business che codifica cosa deve essere ritenuto integro. Può essere considerato come un motore di riconoscimento dei modelli. Cerca diversi modelli nelle diverse misurazioni a disposizione e quindi prende una decisione per determinare se un elemento deve essere considerato integro o meno. L'ultimo componente è il motore risponditore, indicato come Recover nella figura seguente. Quando viene rilevato un componente non integro, la prima azione è tentare di ripristinarlo. In Disponibilità gestita (Managed Availability) sono disponibili numerose azioni di ripristino in più fasi: il primo tentativo potrebbe essere quello di riavviare il pool di applicazioni, il secondo quello di riavviare il servizio, il terzo quello di riavviare il server e l'ultimo quello di disconnettere il server in modo che non accetti più traffico. Se questi tentativi hanno esito negativo, la disponibilità gestita riassegna il problema a un responsabile mediante una notifica del log eventi.

È inoltre possibile osservare che abbiamo decentralizzato alcune attività. Nelle versioni precedenti è presente un agente SCOM in ogni server e tutte le misurazioni vengono passate a un server SCOM centrale, che deve valutarle per determinare se i componenti sono integri o meno. In un ambiente su larga scala le correlazioni sono complesse e abbiamo osservato ad esempio che gli avvisi richiedono più tempo per attivarsi. Lo spostamento di tutte le attività in una posizione centralizzata non avrebbe garantito la scalabilità. Abbiamo scelto pertanto di fare in modo che ogni singolo server agisca in modo isolato: ogni server esegue i propri probe, monitorizza il proprio sistema e agisce per ripristinarsi, naturalmente riassegnando il problema, se necessario.

Figura 1: componenti di Disponibilità gestita (Managed Availability)

Probe

L'infrastruttura dei probe è costituita da tre framework distinti:

1. I probe sono transazioni sintetichecreate dai team preposti ai singoli componenti. Sono simili ai cmdlet di prova delle versioni precedenti. Misurano la percezione del servizio eseguendo transazioni utente end-to-end sintetiche.
2. Le verifiche sono un meccanismo di monitoraggio passivo. Misurano il traffico effettivo di clienti.
3. Il framework di notifica consente di agire immediatamente senza attendere l'esecuzione di un probe. In questo modo, se viene rilevato un errore, è possibile intraprendere immediatamente l'azione richiesta. Questo framework si basa sulle notifiche. Quando ad esempio scade un certificato, viene attivato un evento di notifica in cui si avvisa che il certificato deve essere rinnovato.

Monitor

I dati raccolti dai probe vengono inviati ai monitor. Non esiste necessariamente una correlazione uno-a-uno tra probe e monitor. Più probe possono inviare dati a un singolo monitor. I monitor esaminano i risultati dei probe e giungono a una conclusione di tipo binario, ovvero di integrità o di non integrità.

Come affermato precedentemente, il monitoraggio in Exchange 2013 si basa sull'esperienza degli utenti finali. A tale scopo, è necessario eseguire il monitoraggio a livelli diversi nell'ambiente:

Figura 2: monitoraggio a livelli diversi per la verifica dell'esperienza utente

Come è possibile osservare nella figura precedente, vengono eseguite quattro verifiche diverse. La prima è la verifica automatica delle cassette postali (Mailbox Self Test). Questo probe controlla che l'interfaccia o il protocollo locale possa accedere al database. La seconda è la verifica automatica del protocollo (Protocol Self Test), che controlla il funzionamento del protocollo locale nel server delle cassette postali. La terza è la verifica automatica proxy (Proxy Self Test) eseguita nel server Accesso client per controllare il funzionamento del proxy per il protocollo. La quarta e ultima è la verifica tutto compreso, che controlla l'esperienza end-to-end (dal proxy del protocollo alle funzioni di archiviazione). Ogni verifica esegue rilevamenti a intervalli diversi.

Il monitoraggio viene eseguito a livelli diversi per gestire le dipendenze. Poiché non sono presenti motori di correlazione in Exchange 2013, abbiamo tentato di distinguere le dipendenze con codici di errore univoci corrispondenti ai diversi probe e con probe che non includono dipendenze contigue. Se ad esempio una verifica automatica delle cassette postali e un probe di verifica automatica del protocollo hanno entrambi esito negativo contemporaneamente, non viene necessariamente indicato che l'archivio è inattivo, bensì che l'istanza del protocollo locale nel server delle cassette postali non funziona. Se invece la verifica automatica del protocollo ha esito positivo e quella delle cassette postali ha esito negativo, viene indicata l'esistenza di un problema nel livello di "archiviazione", ad esempio che l'archivio o il database è offline.

Dal punto di vista del monitoraggio questo significa che ora possiamo esercitare un maggiore controllo sugli avvisi che vengono generati. Se ad esempio stiamo valutando l'integrità di OWA, è più probabile che ritarderemo la generazione di un avviso nel caso di una verifica automatica delle cassette postali non riuscita e di una verifica automatica del protocollo riuscita. Verrebbe invece generato un avviso se entrambe le verifiche automatiche rilevassero una situazione di non integrità.

Risponditori

I risponditori eseguono risposte in base agli avvisi generati da un monitor. Vengono eseguiti solo se un monitor rileva una situazione di non integrità.

Sono disponibili diversi tipi di risponditori:

• Risponditore di riavvio: termina e riavvia il servizio.
• Risponditore di reimpostazione del pool di applicazioni: esegue il ciclo del pool di applicazioni IIS.
• Risponditore di failover: disconnette un server delle cassette postali di Exchange 2013.
• Risponditore di controllo errori: avvia un controllo errori del server.
• Risponditore offline: utilizza un protocollo in un computer fuori servizio.
• Risponditore di riassegnazione: riassegna un problema.
• Risponditori di componenti specializzati. 

Il risponditore offline viene utilizzato per rimuovere un protocollo dall'utilizzo nei server Accesso client. È stato progettato per non tenere conto delle soluzioni di bilanciamento del carico. Quando viene richiamato questo risponditore, il protocollo non riconosce la verifica dell'integrità delle soluzioni di bilanciamento del carico, consentendo così alla soluzione di bilanciamento del carico di rimuovere il server o il protocollo dal pool di bilanciamento del carico. Analogamente, esiste un risponditore online corrispondente che viene avviato automaticamente nel momento in cui il relativo monitor risulta di nuovo integro (presupponendo che non siano associati altri monitor con stato di non integrità). Il risponditore online consente semplicemente al protocollo di rispondere alla verifica di integrità della soluzione di bilanciamento del carico, in modo che la soluzione di bilanciamento del carico possa aggiungere di nuovo il server o il protocollo nel pool di bilanciamento del carico. Il risponditore offline può essere richiamato anche manualmente mediante il cmdlet Set-ServerComponentState. In questo modo gli amministratori possono attivare manualmente nei server Accesso client la modalità manutenzione.

Quando viene richiamato il risponditore di riassegnazione, viene generato un evento di Windows riconosciuto da Exchange 2013 Management Pack. Non si tratta di un normale evento di Exchange né di un evento in cui viene indicato che si è verificato un problema con OWA oppure un errore di I/O. Si tratta piuttosto di un evento di Exchange che indica una situazione di integrità o di non integrità di un set di integrità. Utilizziamo eventi di istanza singola come questi per modificare i monitor in SCOM. A tale scopo, utilizziamo un evento generato nel risponditore di riassegnazione invece di eventi sparsi nell'ambito del prodotto. È possibile considerarlo anche come livello di riferimento indiretto. Disponibilità gestita (Managed Availability) decide quando utilizzare un monitor in SCOM basandosi sull'opportunità di eseguire una riassegnazione, ovvero di coinvolgere un responsabile.

È anche possibile applicare limitazioni ai risponditori per evitare di mettere a rischio l'intero servizio. Il tipo di limitazione varia a seconda del risponditore:

• Alcuni risponditori prendono in considerazione il numero minimo di server nel gruppo di disponibilità dei database o nel pool di server Accesso client con bilanciamento del carico.
• Alcuni risponditori prendono in considerazione il tempo che intercorre tra le esecuzioni.
• Alcuni risponditori prendono in considerazione per quante volte è stato avviato il risponditore.
• Alcuni risponditori possono utilizzare una combinazione delle soluzioni precedenti.

A seconda del risponditore, quando viene applicata una limitazione è possibile che l'azione del risponditore venga ritardata o semplicemente saltata.

Sequenze di ripristino

È importante sottolineare che i monitor definiscono i tipi di risponditori eseguiti e la tempistica dell'esecuzione. È questo che intendiamo per sequenza di ripristino di un monitor. Supponiamo ad esempio che i dati del probe per il protocollo OWA (verifica automatica del protocollo) determinino un monitor non integro. A questo punto viene salvato l'intervallo di tempo corrente (che indicheremo con "T"). Il monitor avvia una pipeline di ripristino basata sull'intervallo di tempo corrente. Il monitor può definire azioni di ripristino in corrispondenza di intervalli di tempo denominati nella pipeline di ripristino. Nel caso del monitor del protocollo di OWA nel server delle cassette postali, la sequenza di ripristino sarà la seguente:

1. In corrispondenza di T=0, viene eseguito il risponditore di reimpostazione del pool di applicazioni IIS.
2. Se in corrispondenza di T=5 minuti non è stato ripristinato lo stato di integrità del monitor, viene avviato il risponditore di failover e i database vengono spostati dal server.
3. Se in corrispondenza di T=8 minuti non è stato ripristinato lo stato di integrità del monitor, viene avviato il risponditore di controllo errori e viene forzato il riavvio del server.
4. Se in corrispondenza di T=15 minuti non è stato ripristinato lo stato di integrità del monitor, viene avviato il risponditore di riassegnazione.

La pipeline di ripristino viene arrestata nel momento in cui il monitor risulta integro. Non è necessario che l'azione dell'ultimo intervallo di tempo denominato sia stata completata perché venga avviata quella successiva. Un monitor inoltre può disporre di un numero illimitato di intervalli di tempo denominati.

Systems Center Operations Manager (SCOM)

Systems Center Operations Manager (SCOM) viene utilizzato come portale per visualizzare le informazioni sull'integrità relative all'ambiente Exchange. Gli stati di non integrità nel portale SCOM vengono avviati da eventi scritti nel log applicazioni tramite il risponditore di riassegnazione. Il dashboard di SCOM è stato perfezionato e ora include tre aree principali:

• Area relativa agli avvisi attivi
• Area relativa all'integrità dell'organizzazione
• Area relativa all'integrità dei server

Exchange Server 2013 SCOM Management Pack sarà supportato con SCOM 2007 R2 e SCOM 2012.

Sostituzioni

Indipendentemente dall'ambiente, le impostazioni predefinite non corrispondono sempre a condizioni ottimali oppure possono verificarsi situazioni in cui è richiesta un'azione di emergenza. Disponibilità gestita (Managed Availability) offre la possibilità di abilitare sostituzioni per l'intero ambiente o per una specifica versione del server. Ogni sostituzione può essere impostata per una durata specifica o per una versione specifica del server. I cmdlet *-ServerMonitoringOverride e *-GlobalMonitoringOverride consentono agli amministratori di impostare, rimuovere o visualizzare le sostituzioni.

Determinazione dell'integrità

I monitor simili o associati all'architettura di un componente specifico sono raggruppati per formare set di integrità. L'integrità di un set di integrità è sempre determinata dalla valutazione "peggiore" dei monitor nel set di integrità. Se pertanto disponete di nove monitor in un set di integrità e un monitor non è integro, l'intero set di integrità verrà considerato non integro. È possibile determinare la raccolta di monitor (con probe e risponditori associati) di un set di integrità specifico utilizzando il cmdlet Get-MonitoringItemIdentity.

Per visualizzare l'integrità vengono utilizzati i cmdlet Get-ServerHealth e Get-HealthReport. Il cmdlet Get-ServerHealth viene utilizzato per richiamare i dati di integrità non elaborati, mentre il cmdlet Get-HealthReport agisce su questi dati e fornisce uno snapshot corrente dell'integrità. Questi cmdlet possono agire a livelli diversi:

• Possono mostrare l'integrità di un server specifico, scomponendola per set di integrità.
• Possono essere utilizzati per esaminare in dettaglio un set di integrità specifico e visualizzare lo stato di ogni monitor.
• Possono essere utilizzati per riepilogare l'integrità di un insieme specifico di server (membri di gruppi di disponibilità dei database o array di server Accesso client con bilanciamento del carico).

I set di integrità vengono ulteriormente raggruppati in unità funzionali denominate gruppi di integrità. Esistono quattro gruppi di integrità utilizzati per la segnalazione nel portale di gestione di SCOM:

1. Touchpoint clienti: componenti con interazioni dirette in tempo reale tra i clienti, ad esempio OWA.
2. Componenti di servizi: componenti senza interazioni dirette in tempo reale tra i clienti, ad esempio la generazione della rubrica offline.
3. Componenti di server: risorse fisiche di un server, ad esempio disco o memoria.
4. Disponibilità dipendenza: capacità del server di utilizzare le dipendenze, ad esempio Active Directory.

Conclusione

Disponibilità gestita (Managed Availability) esegue una vasta gamma di valutazioni di integrità in ogni server. Queste verifiche periodiche determinano la funzionalità di diversi componenti del server per stabilire lo stato di integrità del server o di un insieme di server prima e durante il caricamento degli utenti. Se vengono individuati problemi, vengono intraprese azioni correttive in più fasi per ripristinare lo stato funzionante del server. Qualora nel server non venga ripristinato lo stato di integrità, Disponibilità gestita (Managed Availability) può inviare avvisi ai responsabili per indicare che è necessario intervenire.

In conclusione, è possibile affermare che Disponibilità gestita (Managed Availability) si basa sull'esperienza utente e garantisce che in caso di problemi l'impatto sull'esperienza utente sia nullo o comunque di entità minima.

Questo è un post di blog localizzato. L'articolo originale è disponibile in Lessons from the Datacenter: Managed Availability.