Nuove funzionalità di base dell'archivio di Exchange

Si applica a: Exchange Server 2010 SP2

Ultima modifica dell'argomento: 2016-11-28

In Microsoft Exchange Server 2010 sono stati apportati numerosi miglioramenti all'architettura dei database di Exchange:

• Il servizio di segnalazione delle cartelle pubbliche è stata migliorato.

• I database non sono più associati ai gruppi di archiviazione. I gruppi di archiviazione sono stati rimossi.

• Gli investimenti effettuati per l'ottimizzazione dello schema dell'archivio e di Extensible Storage Engine (ESE) ha ridotto gli IOPS del 70%.

Tali miglioramenti vengono descritti in dettaglio nelle sezioni seguenti.

Sommario

Servizio di segnalazione avanzato per le cartelle pubbliche

Gestione del database

Modifiche agli archivi

Nuove funzionalità di ESE

Servizio di segnalazione avanzato per le cartelle pubbliche

Il servizio di segnalazione delle cartelle pubbliche è stata migliorato al fine di visualizzare le modifiche apportate dall'utente a qualsiasi elemento di una cartella pubblica. È possibile visualizzare tali informazioni utilizzando il cmdlet Get-PublicFolderStatistics in Exchange Management Shell. Per ulteriori informazioni, vedere Utilizzo di PowerShell con Exchange 2010 (Exchange Management Shell).

Gestione del database

I database non sono più associati ai gruppi di archiviazione. In Exchange 2010 la funzionalità Gruppo di archiviazione è stata spostata nel database.

In Exchange 2010 è possibile gestire i database delle cassette postali e delle cartelle pubbliche nel nodo Configurazione dell'organizzazione di EMC. (In Exchange Server 2007 la gestione dei database viene eseguita nel nodo Configurazione server.)

Anche se in Exchange 2010 la gestione del database delle cartelle pubbliche è stata spostata dal nodo Configurazione server al nodo Configurazione dell'organizzazione, con il database delle cassette postali, la funzionalità per i database delle cartelle pubbliche non è stata modificata. Come in Exchange 2007, non è possibile creare copie dei database delle cartelle pubbliche e non è possibile aggiungere un database delle cartelle pubbliche al gruppo di disponibilità del database (DAG). I database delle cartelle pubbliche possono essere tuttavia ospitati nel server Cassette postali di un DAG, ma tali database non sono soggetti a log shipping o a qualsiasi altra funzionalità DAG.

Modifiche ai cmdlet per i database

Poiché i gruppi di archiviazione sono stati rimossi in Exchange 2010, i cmdlet relativi utilizzati in Exchange 2007 sono stati eliminati e la funzionalità corrispondente ora viene fornita dai cmdlet per i database di Exchange 2010, come illustrato nelle tabelle seguenti.

Cmdlet di Exchange 2010 per i database che sostituiscono i cmdlet di Exchange 2007 per i gruppi di archiviazione

Cmdlet di Exchange 2010 per i database che presentano funzionalità più estese rispetto ai cmdlet di Exchange 2007

Oltre alla precedenti modifiche ai cmdlet, i cmdlet StorageGroupCopy sono stati eliminati. Per ulteriori informazioni, vedere Gestione delle copie del database delle cassette postali.

Modifiche agli archivi

In Exchange 2010 lo schema dell'archivio è stato modificato in modo da rimuovere le dipendenze del database delle cassette postali dall'oggetto server. Il nuovo schema è stato inoltre migliorato in modo da limitare le operazioni di I/O del database al secondo (IOPS) tramite il refactoring delle tabelle utilizzate per archiviare le informazioni. Il refactoring delle tabelle consente di ottenere una contiguità logica superiore e una maggiore località dei riferimenti. Tali modifiche riducono la dipendenza dell'archivio dagli indici secondari gestiti da ESE. Di conseguenza, l'archivio non risente più dei problemi di prestazioni correlati agli indici secondari.

Anche la resilienza e l'integrità dell'archivio sono state migliorate tramite l'aggiunta di numerose funzionalità correlate al rilevamento e alla correzione degli errori, oltre alla visualizzazione di avvisi per i problemi seguenti:

• Quarantena delle cassette postali non autorizzate

• Limitazione del trasporto ai database con meno di 1 GB di spazio

• Rilevamento e segnalazione del timeout dei thread

Per ulteriori informazioni sulla resilienza e l'integrità dell'archivio, vedere Informazioni sull'archivio di Exchange 2010.

Alle funzionalità di base dell'archivio sono state apportate numerose modifiche per migliorare le caratteristiche per la disponibilità elevata. La disponibilità elevata è stata integrata nell'architettura di base di Exchange 2010 per consentire a organizzazioni di tutte le dimensioni e di tutti i segmenti del settore di distribuire in modo economicamente conveniente un servizio di continuità della messaggistica. Per ulteriori informazioni sulle modifiche apportate alle caratteristiche per la disponibilità elevata in Exchange 2010, vedere Informazioni sulla disponibilità elevata e sulla resilienza del sito.

Nuove funzionalità di ESE

In Exchange 2010 Extensible Storage Engine (ESE) è stato migliorato al fine di raggiungere gli obiettivi seguenti:

• I/O con dimensioni superiori e I/O sequenziale per ridurre la frequenza degli IOPS

• Ottimizzazione per l'archiviazione di commodity

• Riduzione delle attività di gestione dei database

• Deframmentazione online

• Analisi dei database online

I/O sequenziale e con dimensioni superiori

ESE consente di migliorare le prestazioni aumentando le dimensioni degli I/O e riducendo la frequenza delle operazioni di lettura e scrittura in Exchange 2010. Consente inoltre di aumentare le prestazioni rendendo più sequenziali i dati nel database, poiché ciò aumenta la probabilità che i dati correlati si trovino vicini nell'albero B.

In Exchange tutti i dati contenuti nei database vengono archiviati in alberi B, che sono suddivisi in pagine. In Exchange 2007 e versioni precedenti i dati archiviati negli alberi B non sono contigui. Infatti, le versioni precedenti di Exchange eseguono letture e scritture casuali nei database. Ciò significa che i dati correlati potrebbero non trovarsi in posizioni vicine sul disco rigido. Se i dati non sono contigui, le operazioni di lettura e scrittura su disco richiedono un maggior numero di passaggi.

Deframmentazione degli alberi B

Il processo di deframmentazione degli alberi B è stato migliorato al fine di ridurre il numero delle operazioni di I/O attraverso la registrazione dei dati in posizioni contigue degli alberi B.

La deframmentazione degli alberi B viene eseguita sul posto (anziché creare un nuovo albero B e rinominare gli indici e le tabelle) tramite tre nuove operazioni:

• Spostamento delle pagine   Lo spostamento delle pagine consiste nello spostamento di tutti i dati da una pagina a una nuova pagina allocata.

• Unione parziale da sinistra   Un'unione parziale da sinistra è analoga all'unione da destra eseguita in Exchange 2007 e versioni precedenti, con la differenza che i dati vengono spostati dalla pagina di sinistra alla pagina di destra.

• Unione completa da sinistra   L'unione completa da sinistra è analoga all'unione completa da destra eseguita in Exchange 2007 e versioni precedenti.

Per la deframmentazione viene ora utilizzata l'unione da sinistra anziché l'unione da destra, al fine di ottimizzare le prestazioni. I dati vengono letti e scritti nel disco rigido da destra a sinistra. Se il database viene deframmentato nella stessa direzione delle operazioni di lettura e scrittura, si verificherà un conflitto con tali operazioni. Inoltre, durante l'allocazione dello spazio è possibile allocare la pagina successiva in un extent ma non quella precedente. Poiché per spostare una pagina è necessario allocare una nuova pagina, la deframmentazione del database da sinistra a destra garantisce una maggiore efficienza.

Defragmentation Manager è un nuovo evento di ESE che consente di monitorare gli alberi B per cui è necessaria la deframmentazione e quelli che sono già stati deframmentati. Defragmentation Manager compila un elenco di alberi B in tutti i database montati e che devono essere deframmentati. Gli eventuali alberi B frammentati individuati vengono registrati tramite Defragmentation Manager, che provvederà a elaborarli.

Aumento della dimensione delle pagine a 32 KB

Tutti i dati contenuti nei database vengono archiviati in alberi B, che sono suddivisi in pagine. La dimensione di pagina è la dimensione minima per le operazioni di lettura e scrittura nei database ed è anche la dimensione dell'unità utilizzata per la memorizzazione del database nella cache. Le operazioni di lettura dal disco sono più lente delle operazioni in memoria, pertanto aumentando a 32 KB la dimensione delle pagine ESE è in grado di ridurre la frequenza degli IOPS, e ciò consente di aumentare le prestazioni memorizzando nella cache di memoria pagine di larghezza superiore.

Ottimizzazione per l'archiviazione commodity

Un altro degli obiettivi di ESE in Exchange 2010 è costituito dalla riduzione dei costi operativi e di capitale correlati alla distribuzione di Exchange. A tale scopo, è possibile ridurre i costi di archiviazione ed eseguire l'ottimizzazione per l'archiviazione commodity utilizzano dischi rigidi di classe JBOD e SATA.

Dovendo gestire un minor numero di operazioni di I/O con dimensioni superiori, i sottosistemi del disco risultano più efficienti. In Exchange 2010 e versioni precedenti la dimensione della pagina è la dimensione minima per le operazioni di lettura e scrittura e per la memorizzazione del database nella cache. L'unione degli I/O è un processo in cui le operazioni sulle pagine del database vengono combinate in una singola operazione di I/O, al fine di ottenere un minor numero di operazioni di I/O con dimensioni inferiori.

L'aumento della dimensione media degli I/O del database attraverso l'unione degli I/O offre i vantaggi seguenti:

• Utilizzo più efficiente del disco   Se le operazioni di I/O da elaborare hanno dimensioni superiori, i dischi risultano più efficienti. Maggiore è l'efficienza di utilizzo del disco, maggiore sarà anche il numero delle cassette postali che è possibile ospitare su tale disco.

• Aumento della velocità di precaricamento della cache   Il precaricamento della cache è un processo che consente di ridurre i tempi di esecuzione precaricando le query iniziali eseguite su un determinato database l'ultima volta che è stato avviato. Dopo il riavvio, il failover o il passaggio del server, la maggiore dimensione delle operazioni di I/O consente a ESE di aumentare la velocità con cui viene eseguito il precaricamento della cache.

Manutenzione dei database

Uno degli obiettivi di ESE in Exchange 2010 è costituito dalla riduzione dei costi di manutenzione e gestione dei database. Per la manutenzione dei database sono necessarie numerose attività con lo scopo di gestire e garantire l'integrità dei database delle cassette postali.

La manutenzione dei database si articola nelle fasi seguenti:

• Manutenzione dell'archivio delle cassette postali

• Manutenzione del database ESE

In Exchange 2007 la manutenzione del database ESE comporta un utilizzo intensivo del disco. In Exchange 2010 sono stati apportati alcuni miglioramenti con lo scopo di aumentare le prestazioni. In Exchange 2010, nei server molto grandi o con profilo molto pesante l'attività di manutenzione dell'archivio delle cassette postali richiede solo 45 minuti circa, mentre le attività di manutenzione del database ESE richiedono da sei a otto ore a notte nei database Exchange 2007 molto grandi (con quote di 2 GB).

In Exchange 2010 sono stati introdotti miglioramenti per supportare sia cassette postali molto grandi, sia l'archiviazione JBOD che l'archiviazione senza l'uso di RAID.

Deframmentazione del database

La deframmentazione rende contigue le pagine interne di un database di Exchange. La deframmentazione può essere eseguita automaticamente dal sistema mentre il database è online (deframmentazione online) o manualmente da un amministratore mentre il database è offline (deframmentazione offline).

Deframmentazione online

In Exchange 2010, l'architettura per la deframmentazione online è stata modificata. La deframmentazione online è stata spostata all'esterno del processo di manutenzione del database delle cassette postali. La deframmentazione online viene ora eseguita in background 24 ore al giorno per 7 giorni la settimana. Poiché la deframmentazione online viene ora eseguita continuamente, Exchange non inserisce più gli eventi nel registro eventi per indicare la quantità di spazio libero nel database. Durante la manutenzione in background del database, gli elementi contrassegnati per la rimozione dal database vengono rimossi, liberando in tal modo pagine di database. La percentuale di spazio vuoto cambia costantemente a causa del processo di deframmentazione online continuo.

È possibile stimare la quantità di spazio vuoto nel database calcolando la quantità di posta inviata e ricevuta dagli utenti con cassette postali nel database. Ad esempio, se si dispone di 100 cassette postali da 2 GB (per un totale di 200 GB) in un database in cui gli utenti inviano e ricevono una media di 10 MB di posta al giorno, lo spazio vuoto è pari a circa 1 GB (100 cassette postali × 10 MB a cassetta postale). La quantità di spazio vuoto può superare questa stima se la manutenzione del database in background non è in grado di completare un passaggio completo.

Non è necessario configurare alcuna impostazione per questa opzione. In Exchange viene eseguito il monitoraggio del database per verificare quando viene utilizzato, e nel tempo vengono apportate piccole modifiche per mantenerlo deframmentato e garantire la contiguità. Se il database analizza un intervallo di pagine e determina che il livello di sequenzialità è inferiore al previsto, avvia un thread asincrono per deframmentare la sezione interessata dell'albero B o della tabella. La deframmentazione online viene inoltre limitata per evitare effetti negativi sulle prestazioni del client.

Per visualizzare le attività eseguite, utilizzare l'insieme di contatori delle prestazioni ESE Database di MSExchange ==> Attività di deframmentazione. Per ulteriori informazioni, vedere Abilitazione dei contatori aggiuntivi ESE estesi.

Deframmentazione non in linea

La deframmentazione offline è un processo manuale che viene eseguito da un amministratore mentre il database è smontato (offline). In tale processo viene utilizzato lo strumento ESEUTIL per leggere il file del database e scrivere un nuovo file di database disponendo i contenuti in aree contigue. Poiché il processo di deframmentazione offline non copia lo spazio vuoto dal database originale, la dimensione del nuovo file di database creato è inferiore a quella del database originale sul disco (potrebbe essere anche molto più piccola, a seconda delle quantità di spazio vuoto presente nel database). I motivi per eseguire una deframmentazione offline includono da sempre i seguenti:

• Ridurre la dimensione del file di database sul disco

• Recuperare lo spazio vuoto presente in un database

• Evitare l'esaurimento dello spazio disponibile su disco

• Ripristinare un database danneggiato (secondo passaggio del processo di ripristino dopo ESEUTIL /p)

La deframmentazione offline non ha mai fatto parte della manutenzione ordinaria dei database di Exchange e per qualche tempo Microsoft ha sconsigliato di eseguire in modo regolare e proattivo la deframmentazione offline dei database. Tale raccomandazione è dovuta a vari motivi, tra cui:

• L'operazione comporta tempi di inattività perché è necessario disconnettere il database.

• In un ambiente con database delle cassette postali replicati, è necessario eseguire il reseeding di tutte le copie passive di una copia attiva deframmentata offline, oltre che di tutte le copie passive deframmentate offline. Evitare pertanto di eseguire la deframmentazione offline di una copia passiva del database,

• poiché determina la creazione di un nuovo database, con una nuova firma di database, impedendo di ripristinare i file di registro da un backup del database creato prima della deframmentazione offline.

Come alternativa alla deframmentazione offline, è consigliabile creare un nuovo database in cui spostare le cassette postali. In un ambiente Exchange 2010 le cassette postali vengono spostate online senza alcuna interruzione del servizio per gli utenti finali. Inoltre, se si spostano tutte le cassette postali da un database esistente a un nuovo database, si ottiene lo stesso risultato finale, ovvero un database deframmentato con pagine contigue e senza quantità significative di spazio vuoto all'interno del file. Al termine del processo è sufficiente eliminare il vecchio database, ormai vuoto. Questa indicazione si riferisce solo alla deframmentazione offline proattiva per il recupero dello spazio vuoto. Può essere comunque necessario eseguire la deframmentazione su indicazione del Servizio Supporto Tecnico Clienti Microsoft.

Analisi online dei database

Anche l'analisi online dei database (nota anche come controllo del checksum dei database) è stata modificata. In Exchange 2007 Service Pack 1 (SP1) è possibile scegliere di utilizzare metà del tempo di deframmentazione online per questo processo di analisi dei database (per assicurare che Exchange legga tutte le pagine del database in un periodo di tempo specifico per rilevare eventuali danni).

In Exchange 2010, durante l'analisi online dei database vengono eseguiti i checksum del database e le operazioni successive all'arresto anomalo dell'archivio di Exchange 2010. Gli arresti anomali possono determinare perdite di spazio e l'analisi online dei database consente di rilevare e recuperare lo spazio perso. In Exchange 2010 il sistema è progettato presupponendo che venga eseguita un'analisi completa di tutti i database ogni sette giorni. Se non viene eseguita l'analisi completa del database in questo periodo viene generato un evento di avviso. In Exchange 2010 sono disponibili due modalità di esecuzione dell'analisi online dei database sulle copie dei database attivi:

• Come ultima attività del processo di manutenzione pianificato del database delle cassette postali. È possibile configurare la durata dell'esecuzione modificando la pianificazione di manutenzione del database delle cassette postali. Questa opzione garantisce prestazioni ottimali per i database con dimensioni inferiori a 1 TB, che richiedono meno tempo per un'analisi completa.

• In background 24 ore al giorno, 7 giorni su 7, con il comportamento predefinito. L'opzione è adatta a database di ogni dimensione, ma è consigliabile per i database di grandi dimensioni (1-2 TB). Exchange effettua l'analisi del database una sola volta al giorno. Questa operazione di I/O di lettura è sequenziale al 100%, ovvero facile sul disco, e nella maggior parte dei sistemi corrisponde a una velocità di controllo del checksum di circa 5 MB/sec.

Per ulteriori informazioni sulla configurazione della manutenzione dei database, vedere Gestione dei database delle cassette postali.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.