Disponibilità gestita

Si applica a: Exchange Server 2013 SP1

Assicurare che gli utenti abbiano un'esperienza ottimale con la posta elettronica è sempre stato l'obiettivo principale degli amministratori di sistema. Per garantire la disponibilità e l'affidabilità dell'organizzazione Microsoft Exchange Server 2013, è necessario monitorare attivamente tutti gli aspetti del sistema e risolvere rapidamente eventuali problemi rilevati. Nelle versioni precedenti di Exchange, il monitoraggio dei componenti di sistema critici comportava in genere l'uso di un'applicazione esterna, ad esempio Microsoft System Center 2012 Operations Manager, per raccogliere dati e per fornire un'azione di ripristino per i problemi rilevati in seguito all'analisi dei dati raccolti. Exchange 2010 e versioni precedenti includevano manifesti di integrità e motori di correlazione sotto forma di Management Pack. Questi componenti hanno consentito a Operations Manager di stabilire se un componente specifico era integro o non integro. Operations Manager ha inoltre usato l'infrastruttura dei cmdlet di diagnostica incorporata in Exchange 2010 per eseguire transazioni sintetiche su vari aspetti del sistema.

Exchange 2013 adotta un nuovo approccio al monitoraggio e al mantenimento dell'esperienza utente finale in modo nativo usando una funzionalità denominata Disponibilità gestita che fornisce azioni di monitoraggio e ripristino predefinite.

La disponibilità gestita, nota anche come monitoraggio attivo o monitoraggio attivo locale, è l'integrazione di azioni predefinite di monitoraggio e ripristino con la piattaforma di disponibilità elevata di Exchange. Tale piattaforma è stata progettata per rilevare e risolvere i problemi non appena si verificano e vengono rilevati dal sistema. Diversamente dalle precedenti soluzioni e tecniche di monitoraggio esterno di Exchange, la disponibilità gestita non cerca di identificare o comunicare la causa principale di un problema. È incentrata piuttosto sugli aspetti del ripristino legati alle tre aree principali dell'esperienza utente:

• Disponibilità: gli utenti possono accedere al servizio?
• Latenza: qual è l'esperienza per gli utenti?
• Errori: gli utenti sono in grado di eseguire le operazioni desiderate?

Il consolidamento del ruolo del server e altre modifiche dell'architettura in Exchange 2013 richiedono un nuovo approccio alle metodologie di monitoraggio e al modello di integrità usati nelle versioni precedenti di Exchange. La disponibilità gestita è progettata per risolvere queste modifiche fornendo una soluzione di monitoraggio e ripristino dell'integrità nativa. Si discosta dal monitoraggio di singole sezioni di sistema separate per adottare il monitoraggio dell'esperienza utente end-to-end, proteggendola mediante azioni orientate al ripristino.

La disponibilità gestita è un processo interno eseguito in ogni server Exchange 2013. Effettua il polling e analizza centinaia di metriche di integrità ogni secondo. Se viene trovato qualcosa di sbagliato, la maggior parte delle volte viene risolto in modo automatico. Esistono comunque dei problemi che non possono essere risolti automaticamente. In questi casi, la disponibilità gestita passa il problema a un amministratore attraverso la registrazione eventi.

Disponibilità gestita implementata sotto forma di due servizi:

• Servizio Exchange Health Manager (MSExchangeHMHost.exe): questo servizio è un processo di controller usato per gestire i processi di lavoro. Viene utilizzato per realizzare, eseguire, avviare e interrompere il processo di lavoro, in base alle esigenze. Viene inoltre utilizzato per recuperare il processo di lavoro in caso di arresti anomali per impedire che questo diventi un singolo punto di errore.

• Processo di lavoro di Exchange Health Manager (MSExchangeHMWorker.exe): questo servizio è il processo di lavoro responsabile dell'esecuzione di attività in fase di esecuzione all'interno del framework di disponibilità gestita.

Gestione disponibilità utilizza un'archiviazione persistente per svolgere le sue funzioni:

• I file XML nella cartella \bin\Monitoring\config vengono utilizzati per archiviare le impostazioni di configurazione di alcuni degli elementi di lavoro di probe e monitor.
• Active Directory viene utilizzato per archiviare le sostituzioni globali.
• Il Registro di sistema di Windows è utilizzato per memorizzare dati di runtime, ad esempio i segnalibri e le sostituzioni locali (specifiche del server).
• L'infrastruttura del registro eventi del canale Crimson di Windows viene utilizzata per archiviare i risultati degli elementi di lavoro.
• Le cassette postali di integrità vengono utilizzate per attività di tipo "probe". Verranno create più cassette postali di integrità in ogni database delle cassette postali esistente sul server.

Come mostrato nel disegno seguente, la disponibilità gestita include tre componenti asincroni principali costantemente attivi.

Il primo componente è denominato probe. I probe sono responsabili dell'acquisizione di misurazioni nei server e della raccolta di dati. I risultati di tali misurazioni vengono inseriti nel secondo componente, il monitoraggio. Lo strumento di monitoraggio contiene tutta la logica aziendale utilizzata dal sistema sulla base di ciò che è considerato integro nei dati raccolti. Simile al motore di riconoscimento dello schema, lo strumento di monitoraggio cerca vari schemi diversi in tutte le misurazioni raccolte, quindi stabilisce se un elemento debba considerarsi o meno integro. Esistono, infine, i risponditori, che sono responsabili delle azioni di ripristino ed escalation. Se qualche elemento non è integro, la prima azione da eseguire è tentare di recuperarlo. Questo sforzo di ripristino potrebbe includere azioni di ripristino in più fasi; Ad esempio, il primo tentativo può essere il riavvio del pool di applicazioni, il secondo potrebbe essere il riavvio del servizio, il terzo tentativo potrebbe essere il riavvio del server e il tentativo successivo potrebbe essere quello di portare offline il server in modo che non accetti più il traffico. Se le azioni di recupero hanno esito negativo, il sistema inoltra il problema a una persona tramite notifiche del registro eventi.

Esistono tre categorie principali di probe: probe ricorrenti, notifiche e controlli. I probe ricorrenti sono transazioni sintetiche eseguite dal sistema per testare l'esperienza utente end-to-end. I controlli sono l'infrastruttura che esegue la raccolta di dati sulle prestazioni, incluso il traffico utente, e misurano i dati raccolti rispetto alle soglie impostate per determinare i picchi di errori degli utenti. Questa funzionalità di misurazione consente all'infrastruttura di controllo di prendere coscienza quando gli utenti riscontrano problemi. Infine, la logica di notifica consente al sistema di intervenire immediatamente in base a un evento critico, senza dover attendere i risultati dei dati raccolti da un probe. Queste eccezioni o condizioni possono essere rilevate e riconosciute senza un set di campioni di grandi dimensioni.

I probe ricorrenti vengono eseguiti ogni pochi minuti e verificano alcuni aspetti dell'integrità del servizio. Tali probe potrebbero trasmettere un'e-mail tramite Exchange ActiveSync a una cassetta postale di monitoraggio, potrebbero connettersi a un endpoint RPC o potrebbero verificare la connettività Accesso client-Cassetta postale.

Tutti i probe vengono definiti all'avvio del servizio Health Manager nel canale Crimson Microsoft.Exchange.ActiveMonitoring\ProbeDefinition. Ogni definizione di probe ha molte proprietà, ma le proprietà più rilevanti sono:

• Nome: nome del probe, che inizia con un samplemask del monitoraggio del probe.
• TypeName: tipo di oggetto codice del probe che contiene la logica del probe.
• ServiceName: nome del set di integrità che contiene questo probe.
• TargetResource: oggetto convalidato dal probe. Questo nome di proprietà viene aggiunto al nome del probe quando viene eseguito per diventare un risultato del probe ResultName
• RecurrenceIntervalSeconds: frequenza di esecuzione del probe.
• TimeoutSeconds: tempo di attesa del probe prima dell'esito negativo.

Sono disponibili centinaia di probe ricorrenti. Molti di questi probe sono specifici per database, quindi se aumenta il numero di database aumenta anche il numero di probe. La maggior parte dei probe è definita nel codice e pertanto non è individuabile direttamente.

I concetti di base di un probe ricorrente sono i seguenti: inizia ogni RecurrenceIntervalSeconds e controlla (o testa) alcuni aspetti legati all'integrità. Se il componente è integro, il controllo del probe viene superato e viene inserito un evento informativo nel canale Microsoft.Exchange.ActiveMonitoring\ProbeResult con un ResultType pari a 3. Se la verifica ha esito negativo o scade, il controllo del probe ha esito negativo e viene inserito un evento di errore nello stesso canale. ResultType 4 indica che il controllo non è riuscito e ResultType pari a 1 indica il timeout. Molti probe verranno rieseguiti in caso di timeout, fino al valore della proprietà MaxRetryAttempts.

Le notifiche sono probe che non vengono eseguiti dal framework di gestione dell'integrità, ma da altri servizi nel server. Tali servizi eseguono un proprio monitoraggio, per poi inserire i dati raccolti nel framework di Disponibilità gestita scrivendo direttamente i risultati del probe. Tali probe non vengono visualizzati nel canale ProbeDefinition, poiché tale canale descrive solo i probe che vengono eseguiti dal framework di Disponibilità gestita. Ad esempio, il monitor ServerOneCopyMonitor viene attivato dai risultati del probe scritti dal servizio MSExchangeDAGMgmt. Questo servizio esegue il proprio monitoraggio, determina se esiste un problema e registra un risultato del probe. La maggior parte dei probe di notifica è in grado di registrare sia un evento rosso che rende il monitor non integro e un evento verde che ripristina il monitor.

I controlli sono probe che registrano eventi solo quando un contatore delle prestazioni supera o meno una soglia predefinita. Si tratta di casi particolari di probe di notifica, poiché è presente un servizio che monitora i contatori delle prestazioni nel server e che registra eventi nel canale ProbeResult quando si soddisfa la soglia configurata.

Per trovare il contatore e la soglia considerati non integri, è possibile osservare il monitor per questo controllo. I monitoraggi di tipo Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor o Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor indicano che il probe che osservano è un probe di controllo

Monitora le query sui dati raccolti dai probe per determinare se è necessario eseguire un'azione in base a un set di regole predefinito. In base alla regola o alla natura del problema, il monitoraggio può anche avviare un risponditore o inoltrare il problema a un utente mediante una voce del registro eventi. Inoltre, i monitoraggi definiscono quanto tempo dopo un errore viene eseguito un risponditore e il flusso di lavoro dell'azione di ripristino. I monitoraggi dispongono di diversi stati. Dal punto di vista dello stato del sistema, gli stati del monitoraggio sono due:

• Integro: il monitoraggio funziona correttamente e tutte le metriche raccolte si trovano all'interno dei normali parametri operativi
• Non integro: il monitoraggio non è integro e ha avviato il ripristino tramite un risponditore o ha avvisato un amministratore tramite escalation.

Dal punto di vista amministrativo, i monitoraggi hanno molti altri stati visualizzati nella shell:

• Degradato: quando uno stato di monitoraggio non è integro da 0 a 60 secondi, viene considerato degradato. Se un monitoraggio risulta danneggiato per più di 60 secondi, viene considerato non integro.
• Disabilitato: il monitoraggio è stato disabilitato in modo esplicito da un amministratore.
• Non disponibile: il servizio Integrità di Microsoft Exchange esegue periodicamente query su ogni monitoraggio per verificarne lo stato. Se non si riceve alcuna risposta alla query, lo stato del monitoraggio sarà Non disponibile.
• Ripristino: un amministratore imposta lo stato di ripristino per indicare al sistema che un utente sta eseguendo un'azione correttiva, che consente al sistema e agli esseri umani di distinguere tra altri errori che possono verificarsi nello stesso momento in cui viene eseguita un'azione correttiva,ad esempio un'operazione di reinvio della copia del database.

Ogni monitoraggio ha una proprietà SampleMask nella relativa definizione. Durante l'esecuzione del monitoraggio, cerca gli eventi nel canale ProbeResult che hanno un ResultName che corrisponde a SampleMask del monitoraggio. Questi eventi possono provenire da probe ricorrenti, notifiche o controlli. Se si raggiungono le soglie del monitor, questo diventa non integro. Dal punto di vista del monitor, i tre tipi di probe sono gli stessi per ogni log nel canale ProbeResult.

È importante notare che l'errore di un singolo probe non indica necessariamente che sono presenti problemi con il server. È la struttura dei monitor che identifica correttamente quando si verifica un problema reale che deve essere risolto. Pertanto, molti monitoraggi presentano soglie di più errori di probe prima di diventare non integri. Anche in questo caso, molti di tali problemi possono essere risolti automaticamente dai risponditori, quindi il posto migliore in cui cercare problemi che richiedono un intervento manuale è nel canale Crimson Microsoft.Exchange.ManagedAvailability\Monitoring. Questo canale include l'errore probe più recente.

Come indicato dal nome, i risponditori eseguono un certo tipo di risposta a un avviso generato da un sistema di monitoraggio. I risponditori eseguire varie azioni di ripristino, ad esempio reimpostando un pool di ruoli di lavoro dell'applicazione per riavviare un server. Esistono diversi tipi di risponditori:

• Riavvia risponditore: termina e riavvia un servizio
• Reimpostare il risponditore AppPool: arresta e riavvia un pool di applicazioni in Internet Information Services (IIS)
• Risponditore di failover: avvia un failover di database o server
• Risponditore di controllo errori: avvia un controllo dei bug del server, causando un riavvio del server
• Risponditore offline: accetta un protocollo in un server fuori servizio (rifiuta le richieste client)
• Risponditore online: reinsere un protocollo in un server nell'ambiente di produzione (accetta richieste client)
• Escalation del risponditore: inoltra il problema a un amministratore tramite la registrazione eventi

Oltre ai risponditori elencati sopra, alcuni componenti presentano anche risponditori specializzati esclusivi.

Tutti i risponditori includono il comportamento di limitazione, che fornisce un meccanismo di sequenziazione predefinito per il controllo delle azioni del risponditore. Il comportamento di limitazione è progettato per garantire che il sistema non venga compromesso o peggiorato dalle azioni di ripristino del risponditore. Tutti i risponditori sono limitati in qualche modo. Quando si verifica la limitazione, l'azione di ripristino del risponditore potrebbe essere ignorata o ritardata, a seconda del tipo di azione. Ad esempio, quando il risponditore del controllo errori è limitato, l'azione viene ignorata e non ritardata.

Set di integrità

Da una prospettiva relativa alla creazione dei report, la disponibilità gestita presenta due viste dell'integrità, una interna e una esterna. La vista interna utilizza i set di integrità. Ogni componente di Exchange 2013 (ad esempio, Outlook Web App, Exchange ActiveSync, il servizio Archivio informazioni, l'indicizzazione del contenuto, i servizi di trasporto e così via) viene monitorato dalla disponibilità gestita tramite probe, monitoraggi e risponditori. Un gruppo di probe, monitoraggi e risponditori per un determinato componente è denominato set di integrità. Un set di integrità consiste in un gruppo di probe, strumenti di monitoraggio e risponditori che determinano se il componente è integro. Lo stato corrente di un set di integrità, ad esempio se è integro o non integro, è determinato usando lo stato dei monitoraggi del set di integrità. Se tutti gli strumenti di monitoraggio del set di integrità sono integri, allora il set di integrità è integro. Se anche uno degli strumenti di monitoraggio non è integro, lo stato del set di integrità verrà determinato dallo strumento di monitoraggio meno integro.

Per ulteriori informazioni sulla visualizzazione dello stato di integrità del server o dei set di integrità, vedere Manage health sets and server health.

Gruppi di integrità

La vista esterna sulla disponibilità gestita è formata da gruppi di integrità. I gruppi di integrità sono esposti a System Center Operations Manager 2007 R2 e System Center Operations Manager 2012.

Esistono quattro gruppi di integrità principali:

• Punti di contatto del cliente: componenti che influiscono sulle interazioni utente in tempo reale, ad esempio i protocolli o l'Archivio informazioni
• Componenti del servizio: componenti senza interazioni utente dirette e in tempo reale, ad esempio il servizio Replica cassette postali di Microsoft Exchange o il processo di generazione della rubrica offline (OABGen)
• Componenti server: risorse fisiche del server, ad esempio spazio su disco, memoria e rete
• Disponibilità delle dipendenze: la possibilità del server di accedere alle dipendenze necessarie, ad esempio Active Directory, DNS e così via.

Quando il Management Pack di Exchange è installato, System Center Operations Manager (SCOM) funge da portale di integrità per la visualizzazione delle informazioni relative all'ambiente di Exchange. Il dashboard SCOM include tre visualizzazioni dell'integrità del server di Exchange:

• Avvisi attivi: i risponditori di escalation scrivono eventi nel registro eventi di Windows utilizzati dal monitoraggio all'interno di SCOM. Questi eventi vengono visualizzati come avvisi nella visualizzazione Avvisi attivi.
• Integrità organizzazione: in questa visualizzazione viene visualizzato un riepilogo cumulativo dell'integrità complessiva dell'integrità dell'organizzazione di Exchange. Tali riepiloghi includono la visualizzazione dell'integrità dei singoli gruppi di disponibilità del database e dell'integrità all'interno di siti Active Directory specifici.
• Integrità server: i set di integrità correlati vengono combinati in gruppi di integrità e riepilogati in questa visualizzazione.

Sostituzioni

Le sostituzioni consentono a un amministratore di configurare alcuni aspetti dei probe, degli strumenti di monitoraggio e dei risponditori della disponibilità gestita. Le sostituzioni consentono di ottimizzare alcuni dei limiti utilizzati dalla disponibilità gestita. Possono inoltre essere utilizzate per abilitare azioni di emergenza per eventi inattesi che richiedono impostazioni di configurazione diverse da quelle predefinite.

Le sostituzioni possono essere create e applicate a un singolo server (questo processo è noto come override del server) o possono essere applicate a un gruppo di server (questo processo è noto come override globale). I dati di configurazione della sostituzione del server vengono conservati nel Registro di sistema di Windows nel server al quale viene applicata la sostituzione. I dati di configurazione della sostituzione globale vengono archiviati in Active Directory.

Le sostituzioni possono avere durata illimitata o specifica. Inoltre, le sostituzioni globali possono essere applicate a tutti i server o solo a quelli che eseguono una versione specifica di Exchange.

Quando si configura una sostituzione, essa non avrà effetto immediato. Microsoft Exchange Health Manager Service verifica l'aggiornamenti dei dati di configurazione ogni 10 minuti. Inoltre, le sostituzioni globali dipendono dalla latenza di replica di Active Directory.

Per i passaggi dettagliati per visualizzare o configurare le sostituzioni del server o globali, vedere Configurare le sostituzioni della disponibilità gestita.

I cmdlet e attività di gestione

Esistono tre attività operative principali che gli amministratori eseguono generalmente in relazione alla disponibilità gestita:

• Estrazione o visualizzazione dell'integrità di sistema
• Visualizzazione dei set di integrità e dei dettagli su probe, strumenti di monitoraggio e risponditori
• Gestione delle sostituzioni

I due strumenti di gestione principali della disponibilità gestita sono il Registro eventi di Windows Event e Shell. La disponibilità gestita registra una grande quantità di informazioni nel registro eventi del canale Crimson ActiveMonitoring e ManagedAvailability di Exchange, come ad esempio:

• Definizioni di probe, strumenti di monitoraggio e risponditori, registrati nei rispettivi registri di eventi *Definition.
• Risultati di probe, strumenti di monitoraggio e risponditori, registrati nei rispettivi registri di eventi *Results.
• I dettagli sulle azioni di ripristino del risponditore, compresi dati sul quando l'azione di ripristino ha inizio e quando è considerata conclusa (con esito positivo o meno), registrati nel registro eventi RecoveryActionResults.

Sono disponibili 12 cmdlet utilizzati per la disponibilità gestita, descritti nella tabella seguente.