Disponibilità gestita

Assicurare che gli utenti abbiano un'esperienza ottimale con la posta elettronica è sempre stato l'obiettivo principale degli amministratori di sistema. Nell'organizzazione Exchange Server, tutti gli aspetti del sistema devono essere monitorati attivamente e gli eventuali problemi rilevati devono essere risolti rapidamente. A tale scopo, una funzionalità denominata Disponibilità gestita fornisce azioni di monitoraggio e ripristino che tutelano l'esperienza dell'utente finale.

Disponibilità gestita

La disponibilità gestita, nota anche come monitoraggio attivo o monitoraggio attivo locale, è l'integrazione di azioni predefinite di monitoraggio e ripristino con la piattaforma a 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?

La disponibilità gestita offre 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. 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 eseguirà l'escalation del problema a un amministratore con registrazione eventi.

Disponibilità gestita viene implementata sotto forma di due servizi:

• Servizio Exchange Health Manager (MSExchangeHMHost.exe): 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): processo di lavoro responsabile dell'esecuzione di attività in fase di esecuzione all'interno del framework di disponibilità gestito.

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.

Componenti della disponibilità gestita

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

Componenti della disponibilità gestita

Probe

Il primo componente è denominato probe. I probe sono responsabili dell'acquisizione di misurazioni nei server e della raccolta di dati.

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. In questo modo, l'infrastruttura di controllo è consapevole del verificarsi di eventuali problemi per gli utenti. Infine, le regole di notifica consentono al sistema di reagire immediatamente dopo un evento critico, senza attendere i risultati dei dati raccolti da un probe. In genere si tratta di eccezioni o condizioni rilevabili senza un ampio set di campioni.

I probe ricorrenti vengono eseguiti a intervalli di pochi minuti e consentono di valutare 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 Il tipo di oggetto codice del probe che contiene la logica del probe.

• ServiceName Il nome del sistema di integrità che contiene tale probe.

• TargetResource L'oggetto che il probe sta convalidando. Viene aggiunto al nome del probe quando viene eseguito per diventare un risultato del probe ResultName

• RecurrenceIntervalSeconds La frequenza di esecuzione del probe.

• TimeoutSeconds Per quanto tempo il probe dovrà restare in attesa prima di un 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.

Nota

Il canale crimson ProbeResult può diventare non disponibile con centinaia di probe in esecuzione a intervalli di qualche minuto e registrando un evento, quindi potrebbe esserci un impatto reale sulle prestazioni del server Exchange se si tenta di effettuare query costose rispetto ai log eventi in un ambiente di produzione.

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

Monitor

I risultati delle misurazioni raccolti dai probe fluiscono nel secondo componente, il monitor. Lo strumento di monitoraggio contiene tutta la logica aziendale utilizzata dal sistema 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.

Con i monitoraggi vengono eseguite query sui dati per determinare se intraprendere o meno un'azione in base al 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 stati aggiuntivi visualizzati in Exchange Management 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 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.

Vale la pena notare che un singolo errore del probe non indica necessariamente che si è verificato un errore nel server. È la progettazione dei monitor per identificare correttamente quando si verifica un problema reale che deve essere risolto. Questo è il motivo per cui molti monitor hanno 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. Ciò include l'errore del probe più recente.

Risponditori

Esistono, infine, i risponditori, che sono responsabili delle azioni di ripristino ed escalation. Come indicato dal nome, i risponditori eseguono un certo tipo di risposta a un avviso generato da un sistema di monitoraggio. Se qualche elemento non è integro, la prima azione da eseguire è tentare di recuperarlo. Tutto ciò potrebbe includere azioni di ripristino in più fasi; ad esempio, il primo tentativo potrebbe essere di riavviare il pool di applicazioni, il secondo di riavviare il servizio, il terzo di riavviare il server e il tentativo successivo potrebbe essere quello di mettere 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.

I risponditori eseguire varie azioni di ripristino, ad esempio la reimpostazione di un pool di ruoli di lavoro dell'applicazione o il riavvio di un server. Esistono diversi tipi di risponditori:

• Risponditore di riavvio Consente di terminare e riavviare un servizio.

• Risponditore di reimpostazione di un pool di applicazioni Consente di interrompere e riavviare un pool di applicazioni in Internet Information Services (IIS).

• Risponditore failover Consente di avviare il failover di un database o server.

• Risponditore del controllo errori Consente di avviare un controllo sugli errori del server, causando un riavvio del server.

• Risponditore offline Consente di accettare un protocollo su un server fuori servizio (rifiuta le richieste dei client).

• Risponditore online Consente di rimettere in servizio un protocollo su un server (accetta richieste dei client).

• Risponditore escalation Consente di passare il problema all'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 in Exchange Server (ad esempio, Outlook sul web, 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 2012 R2.

Esistono quattro gruppi di integrità principali:

• Punti tocco del cliente Componenti che influenzano interazioni dell'utente in tempo reale, quali protocolli o Archivio informazioni.

• Componenti di servizio Componenti senza interazioni dell'utente dirette e in tempo reale, come ad esempio il servizio di replica delle cassette postali di Microsoft Exchange o il processo di generazione della Rubrica fuori rete (OABGen).

• Componenti del server Risorse fisiche del server, ad esempio spazio su disco, memoria e rete.

• Disponibilità delle dipendenze 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 nel registro eventi di Windows gli eventi consumati dallo strumento di monitoraggio all'interno di SCOM. Questi vengono visualizzati come avvisi nella vista Avvisi attivi.

• Integrità dell'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à del server I set di integrità correlati vengono combinati in gruppi di integrità e riepilogati in questa vista.

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 solo server (note come sostituzioni server) o essere applicate a un gruppo di server sostituzioni globali). 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 un override, non avrà effetto immediatamente. 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 in genere eseguono 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 per la disponibilità gestita sono il registro eventi di Windows e Exchange Management 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.

• Informazioni dettagliate sulle azioni di ripristino del risponditore, tra cui quando viene avviata l'azione di ripristino, e vengono considerate complete (con esito positivo o negativo), registrate nel registro eventi RecoveryActionResults.

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

Cmdlet	Descrizione
Get-ServerHealth	Utilizzato per ottenere informazioni non elaborate sull'integrità del server, quali set di integrità e relativo stato corrente (integro o non integro), strumenti di monitoraggio del set di integrità, componenti del server, risorse di destinazione per probe e timestamp relativi ai tempi di avvio o interruzione di probe o strumenti di monitoraggio e ai tempi di transizione dello stato.
Get-HealthReport	Utilizzato per ottenere una vista di riepilogo dell'integrità che include set di integrità e il relativo stato corrente.
Get-MonitoringItemIdentity	Utilizzato per visualizzare probe, strumenti di monitoraggio e risponditori associati a un set di integrità specifico.
Get-MonitoringItemHelp	Utilizzato per visualizzare le descrizioni su alcune delle proprietà di probe, strumenti di monitoraggio e risponditori.
Add-ServerMonitoringOverride	Utilizzato per creare una sostituzione locale e specifica del server di un probe, uno strumento di monitoraggio o risponditore.
Get-ServerMonitoringOverride	Utilizzato per visualizzare un elenco di sostituzioni locali sul server specificato.
Remove-ServerMonitoringOverride	Utilizzato per rimuovere una sostituzione locale da un server specifico.
Add-GlobalMonitoringOverride	Utilizzato per creare una sostituzione globale per un gruppo di server.
Get-GlobalMonitoringOverride	Utilizzato per visualizzare un elenco di sostituzioni globali configurati nell'organizzazione.
Remove-GlobalMonitoringOverride	Utilizzato per rimuovere una sostituzione globale.
Set-ServerComponentState	Utilizzato per configurare lo stato di uno o più componenti del server.
Get-ServerComponentState	Utilizzato per visualizzare lo stato di uno o più componenti del server.