Monitoraggio della disponibilità elevata e della resilienza del sito
Si applica a: Exchange Server 2010
Ultima modifica dell'argomento: 2010-01-11
Per le operazioni quotidiane legate alle messaggistica è fondamentale assicurarsi che i server operino in modo affidabile e che le copie dei database siano integre. Per garantire la disponibilità e l'affidabilità dell'organizzazione di Microsoft Exchange Server 2010, è necessario controllare attivamente l'hardware, il sistema operativo Windows e i servizi di Exchange 2010. Il monitoraggio proattivo, unito alla manutenzione preventiva, consente di identificare potenziali errori prima che un problema grave interferisca con il funzionamento dell'organizzazione di Exchange.
Il monitoraggio dell'organizzazione di Exchange implica il controllo regolare dei problemi relativi ai dati e ai servizi. In genere, il monitoraggio include un sistema di notifiche che invia avvisi al verificarsi dei problemi. Windows Server 2008 ed Exchange 2010 includono diversi strumenti e servizi che permettono di garantire il funzionamento corretto e ininterrotto dell'organizzazione di Exchange. Di seguito sono riportati i principali vantaggi derivanti dal monitoraggio giornaliero:
- Conformità ai requisiti dei contratti di servizio
- Garanzia del completamento corretto di specifiche attività di amministrazione, ad esempio le operazioni di backup giornaliere
- Rilevamento e soluzione dei problemi, riguardanti ad esempio il servizio di messaggistica o la disponibilità dei dati
In un'organizzazione di Exchange 2010, le procedure, i ruoli e le responsabilità relativi alle operazioni devono essere formalizzati. È importante comprendere il collegamento tra procedure operative ottimali e integrità dell'infrastruttura. Procedure e processi operativi accurati e ben documentati consentono di assicurare che tutti i componenti dell'ambiente organizzativo su cui si basa Exchange siano gestiti in modo efficace ed efficiente.
Exchange 2010 include diversi strumenti e funzionalità predefiniti utilizzabili come parte del normale monitoraggio proattivo quando Exchange è configurato per la disponibilità elevata o per la resilienza del sito. I principali cmdlet di monitoraggio per la disponibilità elevata e la resilienza del sito sono Get-MailboxDatabaseCopyStatus e Test-ReplicationHealth. Oltre a fornire cmdlet in grado di eseguire funzioni di monitoraggio e segnalare lo stato, Exchange 2010 dispone anche di un nuovo flusso del registro eventi che utilizza le capacità del canale Crimson in Windows Server e gli script predefiniti in grado di raccogliere dati da questi canali di eventi.
È possibile utilizzare i dettagli in questo argomento per monitorare l'integrità e lo stato delle copie del database delle cassette postali per i gruppi di disponibilità del database. Per informazioni generali sul monitoraggio di Exchange 2010, vedere Monitoraggio di Exchange 2010.
Sommario
Cmdlet Get-MailboxDatabaseCopyStatus
Cmdlet Test-ReplicationHealth
Registrazione degli eventi del canale Crimson
Script CollectOverMetrics.ps1
Script CollectReplicationMetrics.ps1
Cmdlet Get-MailboxDatabaseCopyStatus
È possibile utilizzare il cmdlet Get-MailboxDatabaseCopyStatus per visualizzare le informazioni sullo stato delle copie del database delle cassette postali. Questo cmdlet consente di visualizzare informazioni su tutte le copie di un particolare database, informazioni su una specifica copia di un database su un server specifico, oppure informazioni su tutte le copie del database su un server. Nella seguente tabella sono descritti i possibili valori per lo stato di una copia del database delle cassette postali.
Stato della copia del database
| Stato della copia del database | Descrizione |
|---|---|
Failed |
La copia del database delle cassette postali è nello stato Failed quando non è stata sospesa e non è in grado di copiare o rieseguire i file di registro. Se lo stato è Failed e la copia non è sospesa, il sistema controlla periodicamente se il problema che ha causato l'impostazione dello stato Failed per la copia è stato risolto. Una volta rilevata la risoluzione del problema, a condizione che non vi siano altri problemi, lo stato della copia diventa automaticamente Healthy. |
Seeding |
La copia del database delle cassette postali, l'indice del contenuto per la copia del database delle cassette postali o entrambi gli elementi sono sottoposti a seeding. Al completamento del seeding, lo stato della copia cambia in Initializing. |
SeedingSource |
La copia del database delle cassette postali è utilizzata come origine per l'operazione di seeding della copia del database. |
Suspended |
La copia del database delle cassette postali è nello stato Suspended a seguito della sospensione manuale della copia del database da parte di un amministratore che ha eseguito il cmdlet Suspend-MailboxDatabaseCopy. |
Healthy |
La copia del database delle cassette postali esegue correttamente la copia e la riesecuzione dei file di registro, oppure ha completato correttamente la copia e la riesecuzione di tutti i file di registro disponibili. |
ServiceDown |
Il servizio Replica di Microsoft Exchange non è disponibile o è in esecuzione sul server che ospita la copia del database delle cassette postali. |
Initializing |
La copia del database delle cassette postali è nello stato Initializing quando è stata creata una copia del database, quando il servizio Replica di Microsoft Exchange è in fase di avvio o è stato appena avviato, e durante le transizioni dallo stato Suspended, ServiceDown, Failed, Seeding, SinglePageRestore, LostWrite o Disconnected a un altro stato. Quando la copia è in questo stato, il sistema verifica che il database e il flusso di registro abbiano uno stato coerente. Nella maggior parte dei casi, lo stato della copia rimane Initializing per circa 15 secondi, ma in ogni caso non deve rimanere tale per più di 30 secondi. |
Resynchronizing |
La copia del database delle cassette postali e i suoi file di registro vengono confrontati con la copia attiva del database per verificare eventuali divergenze tra le due copie. La copia rimane in questo stato fino a quando non sono state rilevate e risolte tutte le divergenze. |
Mounted |
La copia attiva è online e sta accettando le connessioni dei client. Solo la copia attiva della copia del database delle cassette postali può assumere lo stato Mounted. |
Dismounted |
La copia attiva è offline e non sta accettando le connessioni dei client. Solo la copia attiva della copia del database delle cassette postali può assumere lo stato Dismounted. |
Mounting |
La copia attiva sta per diventare online e non sta ancora accettando le connessioni dei client. Solo la copia attiva della copia del database delle cassette postali può assumere lo stato Mounting. |
Dismounting |
La copia attiva sta per diventare offline e sta terminando le connessioni dei client. Solo la copia attiva della copia del database delle cassette postali può assumere lo stato Dismounting. |
DisconnectedAndHealthy |
La copia del database delle cassette postali non è più connessa alla copia del database attiva ed era nello stato Healthy quando si è verificata la perdita della connessione. Questo stato rappresenta la copia del database rispetto alla connettività alla copia del database di origine. Può essere segnalato durante gli errori di rete del gruppo di disponibilità del database tra la copia di origine e la copia del database di destinazione. |
DisconnectedAndResynchronizing |
La copia del database delle cassette postali non è più connessa alla copia del database attiva ed era nello stato Resynchronizing quando si è verificata la perdita della connessione. Questo stato rappresenta la copia del database rispetto alla connettività alla copia del database di origine. Può essere segnalato durante gli errori di rete del gruppo di disponibilità del database tra la copia di origine e la copia del database di destinazione. |
FailedAndSuspended |
Gli stati Failed e Suspended sono stati impostati contemporaneamente dal sistema in quanto è stato rilevato un errore la cui risoluzione richiede esplicitamente l'intervento dell'amministratore. Un esempio è il caso in cui il sistema rileva una divergenza irreversibile tra il database delle cassette postali attivo e una copia del database. A differenza dello stato Failed, il sistema non controlla periodicamente se il problema è stato risolto e non esegue il ripristino automatico. Deve intervenire un amministratore per risolvere la causa dell'errore prima che la copia del database possa passare a uno stato di integrità. |
ActivationSuspended |
L'attivazione della copia del database delle cassette postali è stata bloccata manualmente da un amministratore. |
SinglePageRestore |
Questo stato indica che sulla copia del database delle cassette postali si è verificata un'operazione di ripristino della singola pagina. |
Il cmdlet Get-MailboxDatabaseCopyStatus include anche un parametro ConnectionStatus, che restituisce i dettagli sulle reti di replica in uso. Se si utilizza questo parametro, nell'output dell'attività vengono compilati due campi di output aggiuntivi, IncomingLogCopyingNetwork e SeedingNetwork.
Esempi di Get-MailboxDatabaseCopyStatus
Negli esempi riportati di seguito viene utilizzato il cmdlet Get-MailboxDatabaseCopyStatus. In ciascun esempio i risultati vengono inviati al cmdlet Format-List affinché siano visualizzati in formato elenco.
Con questo esempio vengono restituite le informazioni di stato per tutte le copie del database DB2.
Get-MailboxDatabaseCopyStatus -Identity DB2 | Format-List
Con questo esempio viene restituito lo stato per tutte le copie del database sul server di cassette postali MBX2.
Get-MailboxDatabaseCopyStatus -Server MBX2 | Format-List
Con questo esempio viene restituito lo stato per tutte le copie del database sul server di cassette postali locale.
Get-MailboxDatabaseCopyStatus -Local | Format-List
Con questo esempio vengono restituiti lo stato, il log shipping e le informazioni di rete di seeding per il database DB3 sul server di cassette postali MBX1.
Get-MailboxDatabaseCopyStatus -Identity DB3\MBX1 -ConnectionStatus | Format-List
Per ulteriori informazioni sull'uso del cmdlet Get-MailboxDatabaseCopyStatus, vedere Get-MailboxDatabaseCopyStatus.
Inizio pagina
Cmdlet Test-ReplicationHealth
È possibile utilizzare il cmdlet Test-ReplicationHealth per visualizzare le informazioni sullo stato di replica continua delle copie del database delle cassette postali. Il cmdlet può essere utilizzato per controllare tutti gli aspetti dello stato di replica e riesecuzione per fornire una panoramica completa di uno specifico server di cassette postali in un gruppo di disponibilità del database.
Il cmdlet Test-ReplicationHealth è progettato per il monitoraggio preventivo della replica continua e della pipeline di replica continua, della disponibilità di Active Manager e dell'integrità e dello stato del Servizio cluster, del quorum e dei componenti di rete sottostanti. Può essere eseguito in locale o in modalità remota su qualsiasi server di cassette postali in un DAG. Il cmdlet Test-ReplicationHealth esegue i test elencati nella seguente tabella.
Test del cmdlet Test-ReplicationHealth
| Nome del test | Descrizione |
|---|---|
ClusterService |
Verifica che il Servizio cluster sia in esecuzione e raggiungibile sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database. |
ReplayService |
Verifica che il servizio Replica di Microsoft Exchange sia in esecuzione e raggiungibile sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database. |
ActiveManager |
Verifica che l'istanza di Active Manager in esecuzione sul membro del gruppo di disponibilità del database specificato (o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database) sia in un ruolo valido (primario, secondario o autonomo). |
TasksRpcListener |
Verifica che la chiamata di procedura remota (RPC) delle attività sia in esecuzione e raggiungibile sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database. |
TcpListener |
Verifica che il listener della copia del registro TCP sia in esecuzione e raggiungibile sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database. |
DagMembersUp |
Verifica che tutti i membri del gruppo di disponibilità del database siano disponibili, in esecuzione e raggiungibili. |
ClusterNetwork |
Verifica che tutte le reti gestite dal cluster sul membro del gruppo di disponibilità del database specificato (o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database) siano disponibili. |
QuorumGroup |
Verifica che il gruppo di cluster predefinito (gruppo di quorum) sia in uno stato integro e online. |
FileShareQuorum |
Verifica che il server di controllo, la directory di controllo e la condivisione configurata per il gruppo di disponibilità del database siano raggiungibili. |
DBCopySuspended |
Controlla se le copie del database delle cassette postali sono nello stato Suspended sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database. |
DBCopyFailed |
Controlla se le copie del database delle cassette postali sono nello stato Failed sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database. |
DBInitializing |
Controlla se le copie del database delle cassette postali sono nello stato Initializing sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database. |
DBDisconnected |
Controlla se le copie del database delle cassette postali sono nello stato Disconnected sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database. |
DBLogCopyKeepingUp |
Verifica che la copia del registro e l'ispezione da parte delle copie passive dei database sul membro del gruppo di disponibilità del database specificato (o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database) siano in grado di tenere il passo dell'attività di generazione del registro sulla copia attiva. |
DBLogReplayKeepingUp |
Verifica che l'attività di riesecuzione per le copie passive dei database sul membro del gruppo di disponibilità del database specificato (o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database) sia in grado di tenere il passo dell'attività di ispezione e copia del registro. |
Esempio di Test-ReplicationHealth
Con questo esempio viene utilizzato il cmdlet Test-ReplicationHealth per verificare lo stato della replica per il server di cassette postali MBX1.
Test-ReplicationHealth -Identity MBX1
Inizio pagina
Registrazione degli eventi del canale Crimson
Windows Server 2008 include due categorie di registri eventi: i registri Windows e i registri applicazioni e servizi. La categoria dei registri di Windows include i registri eventi disponibili nelle versioni precedenti di Windows: applicazioni, protezione e sistema. Include inoltre due nuovi registri: il registro dell'installazione e il registro ForwardedEvents. I registri di Windows sono progettati per archiviare gli eventi delle applicazioni legacy e gli eventi relativi all'intero sistema.
I registri applicazioni e servizi sono una nuova categoria di registri eventi. Questi registri archiviano gli eventi di una singola applicazione o di un singolo componente, anziché gli eventi che possono avere un impatto sull'intero sistema. Questa nuova categoria di registri eventi è definita canale Crimson di un'applicazione.
La categoria dei registri applicazioni e servizi include quattro sottotipi: amministrazione, operativo, analitico e debug. Gli eventi nei registri di amministrazione sono di particolare interesse se si utilizzano i record del registro eventi per la risoluzione dei problemi. Gli eventi nel registro di amministrazione forniscono una guida sulla modalità di risposta agli eventi. Gli eventi nel registro operativo sono altrettanto utili, ma richiedono una maggiore interpretazione. I registri di amministrazione e di debug non sono di facile comprensione per gli utenti. I registri analitici (che per impostazione predefinita sono nascosti e disabilitati) archiviano gli eventi che analizzano un problema; al loro interno viene spesso registrato un elevato volume di eventi. I registri di debug sono utilizzati dagli sviluppatori durante il debug delle applicazioni.
Exchange 2010 registra gli eventi relativi ai canali Crimson nell'area dei registri applicazioni e servizi. È possibile visualizzare questi canali eseguendo la procedura descritta di seguito:
- Aprire Visualizzatore eventi.
- Nell'albero della console, accedere a Registri applicazioni e servizi > Microsoft > Exchange.
- Sotto Exchange, selezionare un canale Crimson: HighAvailability o MailboxDatabaseFailureItems.
Il canale HighAvailability contiene gli eventi relativi all'avvio e all'arresto del servizio Replica di Microsoft Exchange e ai diversi componenti eseguiti all'interno del servizio Replica di Microsoft Exchange, ad esempio Active Manager, l'API di replica sincrona di terze parti, il server RPC delle attività, il listener TCP e il writer del servizio Copia Shadow del volume (VSS). Il canale HighAvailability è utilizzato anche da Active Manager per registrare gli eventi relativi al monitoraggio del ruolo Active Manager e agli eventi di azione del database, ad esempio un'operazione di installazione del database e di troncamento del registro, e per la registrazione di eventi relativi al cluster sottostante a un gruppo di disponibilità del database.
Il canale MailboxDatabaseFailureItems è utilizzato per registrare eventi associati a qualsiasi errore che influisce su un database delle cassette postali replicato.
Inizio pagina
Script CollectOverMetrics.ps1
Exchange 2010 include nella cartella Scripts uno script chiamato CollectOverMetrics.ps1. Questo script del flusso di lavoro raccoglie informazioni sulle diverse statistiche di passaggi e failover. L'uso dello script CollectOverMetrics.ps1 rappresenta una forma passiva di monitoraggio. Lo script raccoglie e analizza eventi già registrati e supporta parametri che consentono di personalizzare il comportamento e l'output dello script. I parametri disponibili sono elencati nella tabella seguente.
Parametri dello script CollectOverMetrics.ps1
| Parametro | Descrizione |
|---|---|
DatabaseAvailabilityGroup |
Specifica il nome del gruppo di disponibilità del database da cui si desidera raccogliere le metriche. Se questo parametro viene omesso, viene utilizzato il gruppo di disponibilità del database di cui è membro il server locale. |
Database |
Fornisce un elenco dei database per cui è necessario generare il report. Sono supportati i caratteri jolly, ad esempio |
TemporaryDataPath |
Specifica il percorso per l'archiviazione dei file temporanei. Se il parametro viene omesso, il nome della directory corrisponde al seguente: %SystemDrive%\Temp\CollectOverMetrics\<OraAvvioScript> |
StartTime |
Specifica l'ora di inizio della raccolta dei dati sugli eventi. Se il parametro viene omesso, l'ora di inizio corrisponde alle 00.00 (mezzanotte) di ieri. |
EndTime |
Specifica l'ora di fine della raccolta dei dati sugli eventi. Se il parametro viene omesso, l'ora di fine corrisponde alle 23.59 di ieri. |
ReportPath |
Specifica la cartella utilizzata per archiviare i risultati dell'elaborazione degli eventi. Se il parametro viene omesso, viene utilizzata la cartella Scripts. |
ReportAlias |
Specifica l'alias di posta elettronica a cui inviare il report. |
IncludeAppLogs |
Specifica se devono essere raccolti, gestiti ed elaborati anche gli eventi nel registro eventi applicazioni. Per impostazione predefinita, sono inclusi i seguenti provider: MSExchangeIS, MSExchangeIS Archivio cassetta postale e MSExchangeRepl. |
AppLogProviders |
Specifica se devono essere raccolti gli eventi del registro eventi applicazioni specifico. Se il parametro viene specificato, i provider elencati per IncludeAppLogs non vengono inclusi; è necessario specificarli in modo esplicito utilizzando il parametro AppLogProviders. |
AnalyzeOnly |
Specifica che i dati sono già stati raccolti e che è necessaria solamente l'elaborazione. |
MergedXmlFile |
Specifica il nome del file XML in cui saranno uniti tutti i record del registro eventi raccolti. |
GenerateHtmlReport |
Specifica che il report dovrà essere generato sotto forma di una tabella HTML semplice per facilitarne la visualizzazione. |
ShowHtmlReport |
Specifica che il report HTML generato deve essere visualizzato in un Web browser subito dopo la generazione. |
DotSourceMode |
Specifica che non è necessaria l'esecuzione immediata, ma che il file è soggetto a dot sourcing mediante i metodi di Windows PowerShell definiti al suo interno. |
Esempi di CollectOverMetrics.ps1
Negli esempi riportati di seguito viene utilizzato lo script CollectOverMetrics.ps1.
Con questo esempio vengono raccolte le metriche per tutti i database corrispondenti a DB* (che include un carattere jolly) nel gruppo di disponibilità del database DAG1. Dopo la raccolta delle metriche, viene generato e visualizzato un report in formato HTML.
CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport
Con questo esempio vengono raccolte le metriche per tutti i database del gruppo di disponibilità del database DAG2. Dopo la raccolta delle metriche, viene generato e visualizzato un report in formato HTML.
CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG2 -GenerateHTMLReport -ShowHTMLReport
Inizio pagina
Script CollectReplicationMetrics.ps1
Un altro script per le metriche di integrità incluso in Exchange 2010 è CollectReplicationMetrics.ps1. Questo script rappresenta una forma attiva di monitoraggio, in quanto raccoglie le metriche in tempo reale durante l'esecuzione dello script. Lo script supporta parametri che consentono di personalizzarne il comportamento e l'output. I parametri disponibili sono elencati nella tabella seguente.
Parametri dello script CollectReplicationMetrics.ps1
| Parametro | Descrizione |
|---|---|
DagName |
Specifica il nome del gruppo di disponibilità del database da cui si desidera raccogliere le metriche. Se questo parametro viene omesso, viene utilizzato il gruppo di disponibilità del database di cui è membro il server locale. |
DatabaseNames |
Fornisce un elenco dei database per cui è necessario generare il report. Sono supportati i caratteri jolly, ad esempio |
ReportAlias |
Specifica l'alias di posta elettronica a cui inviare il report. |
TemporaryDataPath |
Specifica il percorso per l'archiviazione dei file temporanei. Se il parametro viene omesso, il nome della directory corrisponde al seguente: %SystemDrive%\Temp\CollectReplicationMetrics\<OraAvvioScript> |
ReportPath |
Specifica la cartella utilizzata per archiviare i risultati dell'elaborazione degli eventi. Se il parametro viene omesso, viene utilizzata la cartella Scripts. |
Duration |
Specifica il tempo di esecuzione del processo di raccolta. |
Frequency |
Specifica la frequenza di raccolta delle metriche dei dati. |
Verbose |
Visualizza l'output delle attività sullo schermo una volta completata l'attività. |
ProcessOnly |
Specifica che i dati sono già stati raccolti e che è necessaria solamente l'elaborazione. |
Esempio di CollectReplicationMetrics.ps1
Nell'esempio riportato di seguito viene utilizzato lo script CollectReplicationMetrics.ps1.
Con questo esempio vengono raccolte le metriche per tutti i database nel gruppo di disponibilità del database DAG1 e i dati raccolti vengono visualizzati in un report sullo schermo.
CollectReplicationMetrics.ps1 -DagName DAG1 -Verbose
Inizio pagina