Monitoraggio della disponibilità elevata e della resilienza del sito

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2015-03-09

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, le responsabilità e i ruoli coinvolti nelle operazioni devono essere formalizzati. È importante comprendere la connessione tra procedure operative efficaci e l'integrità di un'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, script e funzionalità predefinite 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 e analizzare 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.

Sommario

Cmdlet Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

Registrazione degli eventi del canale Crimson

Script CollectOverMetrics.ps1

Script CollectReplicationMetrics.ps1

Script CheckDatabaseRedundancy.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

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.

Cmdlet Get-MailboxDatabaseCopyStatus

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

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

Cmdlet Get-MailboxDatabaseCopyStatus

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:

1. Aprire Visualizzatore eventi.

2. Nell'albero della console, accedere a Registri applicazioni e servizi > Microsoft > Exchange.

3. 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.

Cmdlet Get-MailboxDatabaseCopyStatus

Script CollectOverMetrics.ps1

Exchange 2010 include nella cartella Scripts uno script chiamato CollectOverMetrics.ps1. CollectOverMetrics.ps1 legge i registri eventi dei membri del gruppo di disponibilità del database (DAG) per raccogliere informazioni sulle operazioni del database (ad esempio i montaggi, gli spostamenti e i failover del database) in un intervallo di tempo specifico. Per ogni operazione, lo script registra le informazioni seguenti:

• Identità del database

• Ora di inizio e di fine dell'operazione

• Server su cui il database è stato montato all'inizio e alla fine dell'operazione

• Motivo dell'operazione

• Se l'operazione ha avuto esito positivo, inclusi i dettagli sull'errore se l'operazione non è riuscita

Lo script scrive queste informazioni nei file CSV con un'operazione per riga. Lo script scrive in un file CSV separato per ciascun gruppo di disponibilità del database (DAG).

Lo script supporta parametri che consentono di personalizzarne il comportamento e l'output. Ad esempio, è possibile limitare i risultati a un sottoinsieme specificato utilizzando i parametri Database o ReportFilter. Solo le operazioni che corrispondono a tali filtri saranno incluse nel rapporto HTML di riepilogo. I parametri disponibili sono elencati nella tabella seguente.

Parametri dello script CollectOverMetrics.ps1

Esempi di 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

Negli esempi seguenti vengono dimostrate le modalità di filtraggio del rapporto HTML di riepilogo. Nel primo viene utilizzato il parametro Database, che prende un elenco di nomi dal database. Il rapporto di riepilogo contiene quindi solo i dati relativi a questi database. Nei due esempi successivi viene utilizzata l'opzione ReportFilter. Nell'ultimo esempio vengono filtrati tutti i database predefiniti.

CollectOverMetrics -SummariseCsvFiles (dir *.csv) -Database MailboxDatabase123,MailboxDatabase456
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { $_.DatabaseName -notlike "Mailbox Database*" }
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { ($_.ActiveOnStart -like "ServerXYZ*") -and ($_.ActiveOnEnd -notlike "ServerXYZ*") }

Cmdlet Get-MailboxDatabaseCopyStatus

Script CollectReplicationMetrics.ps1

CollectReplicationMetrics.ps1 è un altro script per le metriche di integrità incluso in Exchange 2010. Questo script fornisce una forma attiva di monitoraggio, in quanto raccoglie le metriche in tempo reale durante l'esecuzione dello script. CollectReplicationMetrics.ps1 raccoglie i dati dai contatori di prestazioni relativi alla replica del database. Lo script raccogli i dati relativi ai contatori da più server Cassette postali, scrive tutti i dati del server in un file CSV e può riportare diverse statistiche per tutti i dati (ad esempio, il periodo di tempo in cui una copia non è riuscita o è stata sospesa, la lunghezza media della coda di riesecuzione o di copia o la quantità di tempo in cui le copie non soddisfacevano i criteri di failover).

I server possono essere specificati singolarmente o per interi gruppi di disponibilità del database. Lo script può essere eseguito per raccogliere i dati e creare il rapporto o può essere eseguito solo per raccogliere i dati o solo per creare il rapporto dei dati già raccolti. È possibile specificare la frequenza con cui i dati devono essere campionati e la durata complessiva di raccolta dei dati.

I dati raccolti da ogni server vengono salvati in un file denominato CounterData.<ServerName>.<TimeStamp>.csv. Se lo script non è stato eseguito con il parametro DagName, il rapporto di riepilogo verrà salvato in un file denominato HaReplPerfReport.<DAGName>.<TimeStamp>.csv o HaReplPerfReport.<TimeStamp>.csv.

Lo script avvia i processi PowerShell per raccogliere i dati da ogni server. Questi processi vengono eseguiti per l'intera durata di raccolta dei dati. Se si specifica un gran numero di server, l'operazione può richiedere una notevole quantità di memoria. La fase finale del processo, in cui i dati vengono elaborati in un rapporto di riepilogo, può richiedere anche del tempo per l'elaborazione di grandi quantità di dati. È possibile eseguire la fase di raccolta su un computer, quindi copiare i dati altrove per l'elaborazione.

Lo script CollectReplicationMetrics.ps1 supporta parametri che consentono di personalizzarne il comportamento e l'output. I parametri disponibili sono elencati nella tabella seguente.

Parametri dello script CollectReplicationMetrics.ps1

Esempio di CollectReplicationMetrics.ps1

Nell'esempio seguente vengono raccolti i dati relativi a un'ora da tutti i server nel gruppo di disponibilità del database "DAG1", campionati a intervalli di un minuto, e viene quindi generato un rapporto di riepilogo. Viene inoltre utilizzato il parametro ReportPath, a causa del quale lo script posiziona tutti i file nella directory corrente.

CollectReplicationMetrics.ps1 -DagName DAG1 -Duration "01:00:00" -Frequency "00:01:00" -ReportPath

Nell'esempio seguente vengono letti i dati da tutti i file che corrispondono a "CounterData*" e viene quindi generato il rapporto di riepilogo.

CollectReplicationMetrics.ps1 -SummariseFiles (dir CounterData*) -Mode ProcessOnly -ReportPath

Cmdlet Get-MailboxDatabaseCopyStatus

Script CheckDatabaseRedundancy.ps1

Come indicato dal nome, l'obiettivo dello script CheckDatabaseRedundancy.ps1 è monitorare la ridondanza dei database delle cassette postali replicati con la convalida di almeno due copie configurate, integre e aggiornate e generare un avviso quando è presente solo una copia integra di un database replicato. In questo caso, vengono conteggiate entrambe le copie attiva e passiva per la determinazione della ridondanza.

Quando si installa il ruolo server Cassette postali, lo script CheckDatabaseRedundancy.ps1 viene automaticamente configurato da Exchange per essere eseguito come un'attività pianificata di nome Database One Copy Alert. Per impostazione predefinita, l'attività pianificata di nome Database One Copy Alert è configurata per essere eseguita ogni 60 minuti. Per modificare tale comportamenti e le impostazioni dell'attività pianificata, è possibile utilizzare l'utilità di pianificazione di Windows. Lo script è progettato per verificare innanzitutto l'appartenenza al gruppo di disponibilità del database. Pertanto, se il server Cassette postali non è membro del gruppo di disponibilità del database, lo script termina immediatamente.

Lo script può essere eseguito anche in modo interattivo dalla cartella scripts. Quando si esegue lo script in modo interattivo, è necessario specificare un nome di database o il nome di un membro del gruppo di disponibilità del database. Per specificare un database viene utilizzato il parametro MailboxDatabaseName e per specificare un membro del gruppo di disponibilità del database viene utilizzato il parametro MailboxServerName. Quando viene eseguito in modalità interattiva nella console, lo script esegue il controllo di ridondanza solo una volta e visualizza CurrentState (rosso o verde) sulla schermata.

Analogamente ad altri script e cmdlet, CheckDatabaseRedundancy.ps1 può anche essere eseguito in modalità di monitoragggio e può generare eventi con l'aggiunta del parametro MonitoringContext. L'attività pianificata creata da Exchange esegue lo script in modalità di monitoraggio. In tale modalità lo script può essere richiamato anche da una soluzione di monitoraggio, ad esempio Microsoft System Center Operations Manager (SCOM). In modalità di monitoraggio, lo script genera eventi con avvisi di colore rosso e verde nel registro eventi dell'applicazioni del server locale. Un evento con avviso di colore rosso (ID evento 4113) viene generato solo se il database è stato in modalità "rosso" per più di 20 minuti (non consecutivi, riferito alla durata) nell'esecuzione dello script della durata di un'ora e un evento di colore verde (ID evento 4114) quando il database è stato in modalità "verde" per 10 minuti consecutivi. Per impostazione predefinita, una volta generato un evento di colore rosso, l'evento continuerà a essere segnalato ogni 15 minuti.

Inoltre, lo script dispone di alcune opzioni utili. Ad esempio, è possibile aggiungere il parametro ShowDetailedErrors per ottenere maggiori informazioni sugli errori verificatisi e aggiungere il parametro Verbose per ulteriori informazioni sulla risoluzione dei problemi. Lo script include anche il parametro SendSummaryMailTos utilizzabile per inviare un rapporto di riepilogo via posta elettronica a un elenco di indirizzi di posta elettronica specificati quando l'esecuzione dello script è terminata. Ciò consente all'amministratore di esaminare rapidamente i rapporti su base oraria per controllare se si sono verificati problemi di ridondanza. Se si utilizza la funzionalità di posta elettronica, sarà necessario includere il parametro SummaryMailFrom ogniqualvolta viene utilizzato il parametro SendSummaryMailTos.

Microsoft consiglia di eseguire lo script regolarmente nell'ambito delle normali operazioni di monitoraggio, utilizzando l'attività pianificata automatizzata o un sistema di monitoraggio quale SCOM. Per assicurarsi che la ridondanza del database non venga compromessa per lunghi periodi, eseguire lo script ogni 60 minuti. Lo script include un parametro denominato TerminateAfterDurationSecs che, se impostato su valori come -1 o 0 durante l'esecuzione dello script, può essere utilizzato per eseguire lo script una quantità infinita di volte.

Se non si utilizza una soluzione di monitoraggio come SCOM, è consigliabile consentire all'attività pianificata creata automaticamente di automatizzare e pianificare l'esecuzione dello script.

Nell'utilità di pianificazione di Windows Server 2008 SP2 si verificano dei problemi noti che possono determinarne l'arresto anomalo quando è stata pianificata un'attività di lunga durata. In Windows Server 2008 R2 questi problemi non esistono. Pertanto, se possibile, eseguire lo script da Windows Server 2008 R2. Se lo script non può essere eseguito da Windows Server 2008 R2 e viene eseguito da Windows Server 2008 SP2, è consigliabile apportare due modifiche. In primo luogo, anziché eseguire lo script con l'eliminazione temporanea incorporata di 60 minuti, eseguirlo ogni 5 minuti utilizzando i seguenti parametri:

CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors

In secondo luogo, se possibile utilizzare SCOM per definire il comportamento di eliminazione temporanea (ad esempio, se si registrano 3 eventi con avvisi di colore rosso in un periodo di 20 minuti, viene generato un avviso; se si registra un evento con avviso di colore verde, lo stato CurrentState diventa di colore verde).

Se l'attività pianificata Database One Copy Alert viene modificata o rimossa, è possibile eliminarla e ripianificarla tramite il comando seguente:

schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY

Sostituire i parametri nello script precedente con i parametri che si desidera utilizzare. Nello script sono anche descritti i parametri aggiuntivi utilizzabili.

Quando si utilizza lo strumento della riga di comando schtasks per creare un'attività pianificata, l'opzione /TR può avere una lunghezza massima di 261 caratteri. Nell'esempio precedente questo limite viene superato. Se i parametri e i percorsi utilizzati determinano il superamento di 261 caratteri nell'opzione /TR, è necessario creare manualmente l'attività pianificata utilizzando l'applet utilità di pianificazione nel menu degli strumenti amministrativi. In alternativa, è possibile copiare e incollare il seguente XML in Blocco note, modificarlo in modo adeguato, salvarlo come file XML e importarlo utilizzando l'applet utilità di pianificazione.

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="https://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2010-05-11T15:55:47</Date>
    <Author>administrator</Author>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT1H</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2010-05-11T15:55:00</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>SYSTEM</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <IdleSettings>
      <Duration>PT10M</Duration>
      <WaitTimeout>PT1H</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>Powershell.exe</Command>
      <Arguments>-NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue</Arguments>
    </Exec>
  </Actions>
</Task>

Cmdlet Get-MailboxDatabaseCopyStatus

 ©2010 Microsoft Corporation. Tutti i diritti riservati.