Nuove funzionalità per l'elevata disponibilità in Exchange 2007 SP1

Si applica a: Exchange Server 2007 SP1

Ultima modifica dell'argomento: 2009-03-18

In Microsoft Exchange Server 2007 Service Pack 1 (SP1) sono state introdotte diverse nuove funzionalità per l'elevata disponibilità e sono stati inclusi miglioramenti alle funzionalità per l'elevata disponibilità già esistenti. Le funzionalità nuove e migliorate estendono gli scenari in cui è possibile ottenere la disponibilità di dati e servizi per i ruoli server di Exchange 2007. I nuovi scenari consentono alle organizzazioni di separare gli scenari di elevata disponibilità dagli scenari di resilienza del sito e di distribuire configurazioni personalizzate in base alle specifiche esigenze dell'organizzazione in ciascuna area.

Di seguito vengono illustrati le nuove funzionalità per l'elevata disponibilità e i miglioramenti apportati alle funzionalità di elevata disponibilità esistenti di Exchange 2007 SP1:

• Replica continua di standby (SCR)

• Supporto per le seguenti funzionalità di Windows Server 2008:

  • Cluster di failover di più subnet

  • DHCP (Dynamic Host Configuration Protocol) IPv4 (Internet Protocol version 4)

  • IPv6

  • Configurazione di rete del cluster di failover e di Exchange

  • Nuovi modelli di quorum (witness di condivisione file e disco)

• Replica continua (distribuzione dei registri e seeding) su una rete cluster ridondante in un ambiente di replica continua cluster (CCR, Cluster Continuous Replication)

• Miglioramenti alle funzionalità di monitoraggio e creazione di rapporti

• Miglioramenti delle prestazioni

• Miglioramenti al dumpster di trasporto

• Miglioramenti di Exchange Management Console

Ciascuna di queste funzionalità verrà descritta più avanti in questo argomento e verranno forniti i collegamenti alla documentazione relativa alle modalità di pianificazione, distribuzione e gestione delle suddette funzionalità. Nella tabella riportata di seguito viene illustrato il supporto di Exchange 2007 per le funzionalità dei cluster di failover di Windows Server 2003 e diWindows Server 2008.

Funzionalità dei cluster di failover supportate da Exchange 2007 SP1

Replica continua di standby

Replica continua di standby (SCR, Standby Continuous Replication) è una nuova funzionalità introdotta in Exchange 2007 SP1. SCR estende le funzionalità di replica continua già disponibili in Exchange 2007 RTM e introduce il supporto per nuovi scenari di disponibilità dei dati per i server Cassette postali di Exchange 2007. SCR prevede l'utilizzo della stessa tecnologia di distribuzione e riproduzione dei registri utilizzata dalla replica continua locale (LCR, Local Continuous Replication) e dalla replica continua cluster per fornire configurazioni e opzioni di distribuzione aggiuntive. SCR è simile a LCR e CCR, ma presenta caratteristiche univoche:

• SCR supporta più destinazioni per ogni gruppo di archiviazione. LCR e CCR supportano una sola destinazione di replica per ogni gruppo di archiviazione (copia passiva).

• SCR consente a un amministratore di specificare un intervallo di tempo di attesa per la replica. Questa opzione risulta utile in un'ampia gamma di scenari. Quando si verifica, ad esempio, un failover con perdita di dati dal NodoA al NodoB, se i file di registro persi venissero riprodotti sul NodoM remoto, sarebbe necessario eseguire nuovamente il seeding di NodoM. Se tuttavia i registri venissero copiati ma non riprodotti, potrebbero essere eliminati, consentendo la copia e la riproduzione in un momento successivo dei nuovi file di registro. In questo caso, non sarebbe necessario eseguire nuovamente il seeding della copia su NodoM.

• A differenza di CCR e LCR, non è possibile eseguire il backup di una copia SCR. In un ambiente SCR, quando i backup vengono eseguiti sul gruppo di archiviazione di origine, le intestazioni dei database per le copie SCR vengono aggiornate e i file di registro vengono troncati.

SCR consente di utilizzare la replica continua per replicare i dati dei server di cassette postali da un server di cassette postali autonomo o da un server di cassette postali in cluster in un ambiente SCC o CCR.

Il processo per l'attivazione di copie di dati di server Cassette postali creati e gestiti da SCR è manuale e deve essere utilizzato quando si verifica un errore di importanza critica (e non per semplici interruzioni dei server che possono essere risolte con il riavvio del sistema o utilizzando altri metodi rapidi). È possibile attivare una destinazione SCR tramite la portabilità del database, l'opzione di ripristino del server (Setup /m:RecoverServer) o, se il server di cassette postali è incluso in un cluster, l'opzione di ripristino del server di cassette postali in cluster (Setup /RecoverCMS). L'opzione selezionata varia a seconda della configurazione e del tipo di errore verificatosi.

Per ulteriori informazioni su SCR, vedere Replica continua di standby.

Supporto per Windows Server 2008

In Windows Server 2008 sono state introdotte nuove funzionalità per l'elevata disponibilità che sono supportate da Exchange 2007 SP1. In Windows Server 2008, i miglioramenti apportati ai cluster di failover (noti come cluster di server in Windows Server 2003 e versioni precedenti) hanno lo scopo di semplificare i cluster e di garantirne una maggiore protezione e stabilità. Inoltre, l'installazione e la gestione del cluster è stata semplificata e i componenti di protezione, rete e archiviazione del cluster sottostanti sono stati migliorati. Per un elenco completo dei miglioramenti introdotti nei cluster di failover, vedere la sezione relativa al clustering di failover di Windows Server 2008 (informazioni in lingua inglese).

Oltre al supporto di Windows Server 2008 come piattaforma del sistema operativo, in Exchange 2007 SP1 viene fornito anche il supporto per le funzionalità dei cluster di failover di Windows Server 2008 riportate di seguito. Il supporto per queste funzionalità è stato inoltre integrato nel programma di installazione di Exchange 2007 sia per la versione da riga di comando (Setup.com) che per l'interfaccia utente grafica (GUI) (Setup.exe, nota anche come Installazione guidata di Exchange Server 2007).

Supporto per i cluster di failover di più subnet

Il clustering di failover di Windows Server 2008 introduce nuove funzionalità di rete che rappresentano un cambiamento significativo nell'ambito della gestione delle operazioni rispetto ai cluster legacy. I cluster di failover di Windows Server 2008 forniscono, ad esempio, il supporto per più subnet. Durante l'esecuzione in un cluster di failover di Windows Server 2008, Exchange 2007 SP1 fornisce il supporto per il failover di cluster geograficamente lontani su due subnet. Questo supporto include i cluster a copia singola e i server Cassette postali in un ambiente CCR.

Con l'introduzione del clustering di failover di Windows Server 2008 i singoli nodi cluster possono ora essere situati in reti con routing separate. Questo richiede che le risorse che dipendono dalle risorse indirizzo IP, ad esempio le risorse nome di rete, implementino una logica OR in quanto è improbabile che ogni nodo cluster abbia una connessione locale diretta a ogni rete nota al cluster. In tal modo, le risorse indirizzo IP e nome di rete possono essere messe in linea con maggiore facilità quando i servizi o le applicazioni eseguono il failover sui nodi remoti.

Quando si utilizzano i cluster di failover di più subnet, gli indirizzi IP associati a una risorsa nome di rete vengono registrati dinamicamente nel sistema DNS (Domain Name System), se configurato per gli aggiornamenti dinamici, ogniqualvolta vengono portati in linea. Pertanto, solo le risorse indirizzo IP in linea vengono restituite ai client. Poiché i nodi cluster possono essere posizionati in reti con routing differenti e i meccanismi di comunicazione sono stati modificati e configurati per l'utilizzo di protocolli di sessione affidabili implementati su User Datagram Protocol (UDP) (unicast), i requisiti di rete per i cluster geograficamente lontani di Windows Server 2003 non sono più applicabili in Windows Server 2008. Di conseguenza, le organizzazioni possono distribuire un ambiente SCC o CCR su due centri dati fisici senza dover utilizzare la tecnologia VLAN (LAN virtuale) per espandere le subnet.

In caso di spostamento o di failover di un server di cassette postali in cluster distribuito in un cluster di failover di più subnet geograficamente lontano, il nome del server di cassette postali in cluster viene mantenuto, mentre l'indirizzo IP assegnato a tale nome non viene mantenuto. La disponibilità di questo server ai client e ad altri server dipende dalla propagazione del nuovo indirizzo IP nel sistema DNS. La propagazione in DNS potrebbe richiedere molto tempo. Per questo motivo, è consigliabile configurare un valore TTL (Time to Live) per il record host DNS del server di cassette postali in cluster su 10 minuti.

Sebbene i client Microsoft Outlook interni non necessitino di profili nuovi o riconfigurati per connettersi tramite il nuovo indirizzo IP, dovranno attendere tuttavia lo svuotamento della relativa cache DNS locale in modo che la risoluzione del nome del server di cassette postali in cluster venga spostata dall'indirizzo IP precedente al nuovo indirizzo IP. Dopo che l'indirizzo IP è stato propagato ai server DNS appropriati, la cache DNS nei client Outlook potrà essere svuotata eseguendo il comando riportato di seguito dalla riga di comando del client.

ipconfig /flushdns

Supporto per DHCP-IPv4

Nel clustering di failover di Windows Server 2008 questo supporto viene fornito in un contesto in cui le risorse indirizzo IP sono in grado di ottenere il relativo indirizzamento dai server DHCP oltre che tramite voci statiche. Se gli stessi nodi cluster vengono configurati per il recupero dei relativi indirizzi IP da un server DHCP, il comportamento predefinito prevede il recupero automatico di un indirizzo IP per tutte le risorse indirizzo IP del cluster. Se il nodo cluster include indirizzi IP assegnati in modo statico, anche le risorse indirizzo IP del cluster dovranno essere configurate con indirizzi IP statici. Pertanto, l'assegnazione degli indirizzi IP alle risorse indirizzo IP del cluster si basa sulla configurazione del nodo fisico e di ciascuna interfaccia specifica del nodo.

Supporto per IPv6

Windows Server 2008 e il servizio cluster supportano il formato IPv6. Questa capacità prevede a sua volta il supporto delle risorse indirizzo IP IPv6 e IPv4 da sole o in combinazione in un cluster. Inoltre, i cluster di failover supportano il protocollo ISATAP (Intra-site Automatic Tunneling Addressing Protocol) e solo gli indirizzi IPv6 che consentono la registrazione dinamica in DNS (record host AAAA e zona di ricerca inversa IP6.ARPA). Attualmente, sono disponibili tre tipi di indirizzi IPv6: globale, locale di sito e locale di collegamento. Le registrazioni DNS dinamiche non vengono eseguite per gli indirizzi locali di collegamento e pertanto gli indirizzi di questo tipo non possono essere utilizzati in un cluster.

Configurazione di rete del cluster di failover e di Exchange

Durante la configurazione di un SCC o un CCR per Exchange 2007 SP1, prendere in considerazione i seguenti requisiti:

• I formati IPv6 e DHCP IPv4 sono supportati solo in Windows Server 2008. Non è possibile utilizzare nessuno dei due formati quando Exchange 2007 viene eseguito su Windows Server 2003.

• La tecnologia DHCP IPv6 non è supportata da Windows Server 2008 o dal servizio cluster. Di conseguenza non è neppure supportata in Exchange 2007. Sono supportati solo indirizzi IPv6 dinamici assegnati dal sistema.

• Gli indirizzi IPv6 statici sono supportati da Windows Server 2008 e dal servizio cluster. Tuttavia, è consigliabile non utilizzare indirizzi IPv6 statici. Di conseguenza, Exchange 2007 non supporta la configurazione di indirizzi IPv6 statici durante l'installazione.

• Il tunneling IPv6 su IPv4 è supportato dal clustering di Windows Server 2008, ma l'installazione di Exchange non prevede la creazione di questo tipo di risorsa indirizzo IP.

Il programma di installazione è stato modificato in Exchange 2007 SP1 in modo da fornire il supporto per le modifiche descritte in precedenza. Quando si utilizza l'Installazione guidata di Exchange Server 2007, notare che sono disponibili pagine e campi aggiuntivi per la configurazione delle risorse nome di rete e indirizzo IP del cluster. Inoltre, le opzioni /NewCMS e /RecoverCMS per Setup.com sono state aggiornate per garantire il supporto di diversi nuovi parametri facoltativi, illustrati nella tabella riportata di seguito.

Parametri facoltativi per /NewCMS e /RecoverCMS aggiunti in Exchange 2007 SP1

Il parametro CMSIPAddress, che era un parametro obbligatorio per /NewCMS e /RecoverCMS nella versione di produzione (RTM, Release to Manufacturing) di Microsoft Exchange Server 2007, viene ancora utilizzato per specificare un singolo indirizzo IPv4 statico per il server di cassette postali in cluster. Tuttavia, in Exchange 2007 SP1, CMSIPAddress è ora un parametro facoltativo in quanto per l'installazione è sufficiente specificare uno dei quattro parametri disponibili.

I parametri nella tabella precedente possono essere utilizzati solo in Windows Server 2008.

Nuovi modelli di quorum di Windows Server 2008

Quando si verificano problemi di rete, è possibile che questi interferiscano con la comunicazione tra i nodi cluster. Un piccolo gruppo di nodi potrebbe essere in grado di comunicare su una parte funzionante di una rete, ma potrebbe non essere in grado di comunicare con un gruppo differente di nodi in un'altra parte della rete. Questa situazione può causare problemi molto gravi. In questa situazione di split brain, è necessario che almeno uno dei gruppi di nodi interrompa l'esecuzione come cluster, anche se i gruppi di nodi non dispongono di informazioni definite sullo stato degli altri nodi.

Per impedire problemi causati da uno split brain nel cluster, il software del cluster richiede che un gruppo qualsiasi di nodi eseguito come cluster utilizzi un algoritmo di voto per determinare se, in un periodo di tempo specifico, tale gruppo raggiunge il quorum. Poiché uno specifico cluster prevede una specifica configurazione di gruppi di nodi e di quorum, il cluster sarà in grado di determinare i voti che costituiscono una maggioranza (un quorum). Se il numero scende al di sotto della maggioranza, il cluster interromperà l'esecuzione. I nodi continueranno ad ascoltare gli altri nodi, attendendo che un altro nodo sia di nuovo visibile sulla rete, ma i nodi non inizieranno a funzionare come cluster fino a quando non viene raggiunto di nuovo il quorum.

La configurazione quorum in un cluster di failover determina il punto in cui un numero eccessivo di errori impedirà l'esecuzione del cluster. Gli errori rilevanti in questo contesto sono rappresentati da errori di nodi o, in alcuni casi, un disco witness o una condivisione file witness (che contiene una copia della configurazione cluster). Windows Server 2008 consente di scegliere tra quattro possibili configurazioni quorum:

• Maggioranza dei nodi   Questo modello è consigliato per i cluster con un numero dispari di nodi ed è in grado di supportare un numero di errori pari alla metà del numero di nodi meno 1. Ad esempio, un cluster a 7 nodi è in grado di gestire 3 errori di nodi.

• Maggioranza dei nodi e dei dischi   Questo modello è consigliato per i cluster con un numero pari di nodi ed è in grado di supportare un numero di errori pari alla metà del numero di nodi se il disco witness rimane in linea. Un cluster a 6 nodi ad esempio con un disco witness è in grado di supportare 3 errori di nodi e un numero di errori pari alla metà del numero di nodi meno 1 se il disco witness è in modalità non in linea o riporta un errore. Ad esempio, un cluster a 6 nodi in cui il disco witness riporta un errore è in grado di supportare 2 errori di nodi (3-1 = 2).

• Maggioranza dei nodi e delle condivisioni di file   Questo modello è progettato per i cluster con configurazioni speciali e si consiglia di utilizzarlo per i server di cassette postali in cluster in un ambiente CCR. Questo modello funziona allo stesso modo di un modello di tipo Maggioranza dei nodi e dei dischi, ma anziché utilizzare un disco witness, utilizza una condivisione file witness.

• Non di maggioranza - solo disco   Questo modello, anche se supportato, non è consigliato. È in grado di supportare gli errori di tutti i nodi eccetto 1. Tuttavia, questa configurazione non è consigliata in quanto il disco rappresenta un singolo punto di errore.

Replica continua su reti cluster ridondanti

In Exchange 2007 RTM, tutte le operazioni di copia e seeding dei file di registro delle transazioni in un ambiente CCR vengono eseguite sulla rete pubblica. Questa configurazione presenta i seguenti limiti:

• Quando il nodo passivo non è disponibile per diverse ore, è possibile che si accumuli un numero significativo di registri che devono essere trasferiti. Quando il nodo passivo diventa disponibile, è necessario che lo spostamento di questi registri avvenga nei tempi più rapidi possibile. Poiché la copia dei registri avviene sulla rete pubblica, lo spostamento dei registri entra in contesa con il traffico client, il che influisce sul traffico client e determina un rallentamento della risincronizzazione.

• In caso di errore sulla rete pubblica, si verifica un failover con perdita di dati anche se i dati dei registri sono disponibili.

• L'utilizzo di una rete isolata per la comunicazione dei registri consente di garantire la protezione dei dati di messaggistica senza fare uso della crittografia, evitando pertanto la riduzione delle prestazioni associata generalmente all'impiego di questa tecnologia.

• In alcune circostanze è possibile che si si accumuli un numero eccessivo di registri. Una situazione di questo tipo può avere come conseguenza un carico di replica insolitamente elevato sul sistema e causare un utilizzo eccessivo delle risorse del client se i dati dei registri devono essere comunicati sulla stessa rete utilizzata per comunicare con i client.

Questi problemi non si verificano tutti con la stessa frequenza. Tuttavia, il primo problema si verifica a intervalli regolari di pochi mesi in quanto i nodi passivi vengono messi in modalità non in linea per consentire l'esecuzione di attività di manutenzione periodiche.

In Exchange 2007 SP1 gli effetti dei problemi sopra descritti vengono ridotti al minimo, consentendo all'amministratore di creare una o più reti miste nel cluster, ad esempio una rete cluster che supporta il traffico heartbeat del cluster e il traffico client, per la distribuzione dei registri. Exchange 2007 SP1 consente inoltre a un amministratore di specificare una determinata rete da utilizzare per il seeding.

Il supporto della copia dei file di registro su una rete mista viene configurato mediante un nuovo cmdlet di Exchange Management Shell denominato Enable-ContinuousReplicationHostName. In modo simile, la disattivazione della funzionalità si ottiene utilizzando il cmdlet Disable-ContinuousReplicationHostName. Quando un server di cassette postali in cluster viene reso disponibile in un ambiente CCR, un amministratore può eseguire Enable-ContinuousReplicationHostName su entrambi i nodi del cluster e specificare nomi host e indirizzi IP aggiuntivi, che verranno quindi creati in gruppi cluster dedicati associati a ciascun nodo. Una volta completata questa attività, il servizio di replica di Microsoft Exchange inizierà a utilizzare la rete appena creata per la copia dei registri immediatamente dopo averla configurata e aver verificato il corretto funzionamento della nuova rete. Se vengono create numerose reti nuove, il servizio di replica di Microsoft Exchange ne selezionerà una in modo casuale. Se la rete specificata diventa non disponibile, il servizio di replica di Microsoft Exchange inizierà a utilizzare automaticamente altre reti di replica o, se nessuna di queste reti è disponibile, inizierà a utilizzare la rete pubblica per la distribuzione dei registri nel giro di 5 minuti (l'individuazione della rete del servizio di replica di Microsoft Exchange viene eseguita ogni 5 minuti). Quando la rete di replica desiderata diventa nuovamente disponibile, il servizio di replica di Microsoft Exchange la utilizzerà di nuovo per la distribuzione dei registri. Per ulteriori informazioni su questi cmdlet, vedere Enable-ContinuousReplicationHostName e Disable-ContinuousReplicationHostName.

Il supporto per il seeding su una rete cluster ridondante viene configurato mediante il cmdlet Update-StorageGroupCopy che è stato aggiornato in Exchange 2007 SP1 in modo da includere un nuovo parametro denominato DataHostNames. Questo parametro viene utilizzato per specificare la rete cluster da utilizzare per il seeding. Per ulteriori informazioni sulle modifiche al cmdlet Update-StorageGroupCopy in Exchange 2007 SP1, vedere Update-StorageGroupCopy.

Dopo aver creato una rete cluster per la replica continua, è possibile utilizzare il cmdlet Get-ClusteredMailboxServerStatus per visualizzare informazioni aggiornate sulle reti cluster abilitate per l'attività di replica continua. Le informazioni aggiornate restituite includono:

• OperationalReplicationHostNames:{Host1,Host2,Host3}

• FailedReplicationHostNames:{Host4}

• InUseReplicationHostNames:{Host1,Host2}

Per ulteriori informazioni sulle modifiche apportate al cmdlet Get-ClusteredMailboxServerStatus in Exchange 2007 SP1, vedere Get-ClusteredMailboxServerStatus.

Per ulteriori informazioni sull'abilitazione delle reti cluster per la replica continua in Windows Server 2003, vedere Come abilitare le reti cluster ridondanti per il log shipping e il seeding in Windows Server 2003.

Per ulteriori informazioni sull'abilitazione delle reti cluster per la replica continua in Windows Server 2008, vedere Come abilitare le reti di cluster ridondanti per il log shipping e il seeding in Windows Server 2008.

Per ulteriori informazioni sulla disabilitazione delle reti cluster per la replica continua, vedere Come disabilitare la replica continua per una rete cluster.

Miglioramenti alle funzionalità di monitoraggio e creazione di rapporti

In Exchange 2007 SP1 sono state introdotte diverse modifiche che migliorano la gestibilità di Exchange 2007. Tali modifiche determinano un miglioramento delle funzionalità di creazione di rapporti cluster in Exchange 2007 RTM e includono funzionalità aggiuntive progettate per il monitoraggio proattivo degli ambienti di replica continua. Nello specifico, le modifiche e i miglioramenti correggono le vulnerabilità con il cmdlet Get-StorageGroupCopyStatus, introducono un nuovo cmdlet denominato Test-ReplicationHealth e forniscono maggiore visibilità nella finestra delle perdite del dumpster del trasporto. Per ulteriori informazioni sui miglioramenti alle funzionalità di monitoraggio e creazione di rapporti, vedere Monitoraggio della Replica continua.

Miglioramenti delle prestazioni

I miglioramenti delle prestazioni introdotti in Exchange 2007 SP1 si rivelano particolarmente utili per le distribuzioni a disponibilità elevata. Tra i miglioramenti sono inclusi:

• Riduzione delle operazioni di I/O sui dischi contenenti copie passive dei gruppi di archiviazione in ambienti di replica continua   In Exchange 2007 SP1, la progettazione dell'architettura della replica continua è stata modificata in modo da consentire la persistenza della cache del database sul nodo passivo tra i diversi batch dell'attività di riproduzione dei registri. La persistenza della cache del database tra i batch dell'attività di riproduzione dei registri consente al servizio di replica di Microsoft Exchange di sfruttare le funzionalità di memorizzazione nella cache del database di Extensible Storage Engine (ESE), che, a sua volta, riduce il numero di operazioni di input/output (I/O) del disco eseguite sui numeri di unità logica (LUN) della copia passiva. In Exchange 2007 RTM, invece, è stata creata una nuova cache del database per ciascun batch dell'attività di riproduzione dei registri che, in alcuni casi, ha determinato un aumento delle operazioni di I/O del disco sul nodo passivo di due o tre volte superiore rispetto alle operazioni di I/O del disco sul nodo attivo.

  Maggiore rapidità nello spostamento dei server di cassette postali in cluster tra i nodi in un ambiente CCR   Questi miglioramenti consentono di spostare i server di cassette postali in cluster tra i nodi in meno di due minuti e includono spostamenti eseguiti da un amministratore (mediante il cmdlet Move-ClusteredMailboxServer) e failover gestiti dal servizio cluster. Per eseguire spostamenti rapidi in un ambiente CCR, i database vengono messi in modalità non in linea senza svuotare la cache del database. In un SCC, lo spostamneto del server Cassette postali richiede circa cinque minuti. Lo svuotamento della cache del database viene eseguito prima dello spostamento del server di cassette postali in cluster. Si tratta di uno svuotamento "opportunistico" che consente ai client di rimanere connessi al database. Questo comportamento riduce i tempi di inattività che si verificano quando il server di cassette postali in cluster viene spostato in un altro nodo.

  Durante il processo di failover, l'ID evento 9868 viene registrato due volte per indicare lo stato dell'operazione di svuotamento, l'ID evento 113 viene registrato per indicare lo stato della replica. Tali eventi sono riportati di seguito:

  ID evento: 9868 Origine: MSExchangeIS Categoria: Generale Tipo: Informazioni Descrizione: Il tentativo di svuotare la cache del server "<Nome server Cassette postali>" si è concluso con 0 gruppi di archiviazione che non hanno raggiunto profondità del punto di arresto desiderata.

  ID evento: 9868 Origine: MSExchangeIS Categoria: Generale Tipo: Informazioni Descrizione: Il tentativo di svuotare la cache del server "<Nome server Cassette postali>" si è concluso con 2 gruppi di archiviazione che non hanno raggiunto la profondità del punto di arresto desiderata.

  ID evento: 113 Origine: MSExchangeRepl Categoria: Sposta Tipo: Informazioni Descrizione: Lo svuotamento della cache di Archivio informazioni prima dello spostamento del server di cassette postali "<Nome server Casette postali>" in cluster non è stato completato. Dati: Gruppo di archiviazione "<Nome server Cassette postali>\<Nome gruppo di archiviazione>": inizio profondità del punto di arresto è 19,fine profondità del punto di arresto è 17. Gruppo di archiviazione "<Nome server Cassette postali>\<Nome secondo gruppo di archiviazione>": inizio profondità del punto di arresto è 19,fine profondità del punto di arresto è 13.

Miglioramenti al dumpster di trasporto

Il dumpster del trasporto è una funzione del ruolo del server Trasporto Hub. Il dumpster di trasporto gestisce una coda dei messaggi che sono stati di recente recapitati a destinatati la cui cassetta postale si trova in un server di cassette postali in cluster in un ambiente CCR. Questa coda è associata al periodo di tempo in cui la posta viene conservata e al totale dello spazio utilizzato. Quando si verifica un failover con perdita di dati, il server di cassette postali in cluster richiede automaticamente a ogni server Trasporto Hub del sito di Active Directory di inviare nuovamente la posta a partire dalla coda del dumpster di trasporto.

In Exchange 2007 SP1, sono stati apportati i seguenti miglioramenti alla funzionalità dumpster di trasporto:

• Supporto per LCR   Il dumpster di trasporto ora include il supporto per le distribuzioni LCR. A differenza di CCR, in cui la richiesta di nuovo recapito della posta del dumpster di trasporto è una fase automatica del processo di ripristino, in un ambiente LCR il processo è manuale. Il cmdlet Restore-StorageGroupCopy è stato aggiornato in Exchange 2007 SP1 in modo da includere la richiesta di reinvio del dumpster di trasporto. Pertanto, quando un amministratore attiva una copia passiva di un gruppo di archiviazione in un ambiente LCR mediante il cmdlet Restore-StorageGroupCopy, la richiesta di invio del dumpster del trasporto viene effettuata nel corso del processo di attivazione.

• Statistiche del dumpster di trasporto   Per informare un amministratore prima di ripristinare un server in cui i file di registro risultano mancanti, il dumpster di trasporto è stato migliorato in modo da includere informazioni statistiche che forniscono lo stato corrente di tutti i server Trasporto Hub contenenti i messaggi per il gruppo di archiviazione interessato. Queste statistiche includono il numero di messaggi e la scadenza del messaggio meno recente, disponibile su ciascun server Trasporto Hub nel sito di Active Directory. Queste statistiche sono visibili quando si utilizza un nuovo parametro per il cmdlet Get-StorageGroupCopyStatus denominato DumpsterStatistics. Quando si utilizza questo nuovo valore, l'output per il cmdlet Get-StorageGroupCopyStatus include le statistiche del dumpster di trasporto relative a tutti i server Trasporto Hub accessibili e un elenco dei server Trasporto Hub non accessibili. I server accessibili vengono elencati in una struttura multivalore denominata DumpsterStatistics, mentre i server non accessibili vengono elencati come stringa multivalore denominata DumpsterStatisticsNotAvailable, come illustrato di seguito:

  DumpsterStatistics: {HUB1 (timestamp meno recente; numero di elementi contenuti nel dumpster; dimensioni del dumpster), HUB2 (timestamp meno recente; numero di elementi contenuti nel dumpster; dimensioni del dumpster), HUB3 (timestamp meno recente; numero di elementi contenuti nel dumpster; dimensioni del dumpster)}

  DumpsterStatisticsNotAvailable: {HUB4,HUB5}

  Nell'esempio precedente, l'indicatore di orario meno recente è rappresentato dal momento in cui il messaggio viene ricevuto dal server Trasporto Hub, non dal momento in cui il messaggio è stato originariamente recapitato al server Cassette postali.

  Il cmdlet Get-StorageGroupCopyStatus supporta anche una nuova struttura multivalore denominata OutstandingDumpsterRequests, che include i server Trasporto Hub con richieste in sospeso e l'intervallo di tempo (low–high) per le richieste in sospeso, come illustrato di seguito:

  OutstandingDumpsterRequests: {HUB1 (time-low;time_high), HUB5 (time_low;time_high)}

Miglioramenti di Exchange Management Console

Exchange 2007 SP1 include nuovi elementi dell'interfaccia utente grafica in Exchange Management Console progettati per migliorare le attività di gestione e configurazione dei server di cassette postali in cluster. Tra i miglioramenti sono inclusi:

• Gestione guidata server di cassette postali in cluster   Questa procedura guidata viene utilizzata per spostare, arrestare o avviare un server di cassette postali in cluster in un ambiente CCR e in un cluster a copia singola. Le funzionalità di spostamento e arresto includono inoltre i campi facoltativi dei commenti dell'amministratore, consentendo a un amministratore di immettere il motivo per cui un server di cassette postali in cluster viene spostato o arrestato. Questa procedura guidata equivale all'utilizzo dei seguenti cmdlet di Exchange Management Shell:

  • Move-ClusteredMailboxServer

  • Stop-ClusteredMailboxServer

  • Start-ClusteredMailboxServer

• Gestisci replica continua   In Exchange Management Console sono stati introdotti controlli dell'interfaccia utente aggiuntivi che consentono a un amministratore di sospendere, riprendere, aggiornare e ripristinare la replica continua. L'utilizzo di questi controlli equivale all'utilizzo dei seguenti cmdlet di Exchange Management Shell:

  • Suspend-StorageGroupCopy

  • Resume-StorageGroupCopy

  • Update-StorageGroupCopy

  • Restore-StoreGroupCopy

  È possibile utilizzare questi cmdlet e le attività di Exchange Management Console corrispondenti per gestire la replica continua in un ambiente CLR e CCR.

  Nota

  In un ambiente CCR l'Aggiornamento guidato copia gruppo archiviazione è disponibile solo dal nodo passivo e il Ripristino guidato copia gruppo archiviazione è disponibile solo dal nodo attivo.

• Scheda Server cassette postali cluster   Alla finestra di dialogo Proprietà server per i server Cassette postali che risiedono in un cluster è stata aggiunta una nuova scheda. Le informazioni della nuova scheda sono disponibili per gli ambienti CCR e i cluster a copia singola. La nuova scheda fornisce informazioni dettagliate sul server di cassette postali in cluster e consente a un amministratore di configurare il valore per la proprietà AutoDatabaseMountDial per i server di cassette postali in cluster in un ambiente CCR. La maggior parte delle informazioni visualizzate nella nuova scheda diventa disponibile mediante il cmdlet Get-ClusteredMailboxServerStatus. Per ulteriori informazioni sulla scheda Server cassette postali cluster, vedere Proprietà server > Scheda Server di cassette postali in cluster.

• Pagina Replica continua cluster   Alla finestra di dialogo Proprietà gruppo di archiviazione per i server Cassette postali distribuiti in un ambiente CCR è stata aggiunta una nuova pagina. La nuova pagina delle proprietà fornisce informazioni dettagliate sullo stato della replica continua nel cluster. Per ulteriori informazioni sulla pagina Replica continua cluster, vedere Proprietà gruppo di archiviazione > Pagina Replica continua cluster.

Ulteriori informazioni

Windows Server 2008 include diverse funzionalità che sono state migliorate o rinominate. Per informazioni sulle modifiche alle funzionalità tra Windows Server 2003 e Windows Server 2008, vedere Modifiche alla terminologia.