Ottimizzazione delle prestazioni di Exchange Server 2003

Ultima modifica dell'argomento: 2006-08-16

In questo capitolo vengono fornite informazioni sulle procedure di ottimizzazione e miglioramento delle prestazioni di Microsoft® Exchange Server 2003, nonché numerosi suggerimenti e consigli di ottimizzazione che potrebbero non essere sempre validi per l'installazione corrente. Leggere attentamente questo capitolo per determinare le impostazioni valide per la situazione specifica.

Per gli utenti di Exchange 2000 Server alcuni dei consigli riportati in questo capitolo sono uguali a quelli presenti nella precedente edizione di questo manuale. Inoltre, alcune modifiche trattate in precedenza non sono più necessarie. Per ulteriori informazioni sulle impostazioni che può essere opportuno rimuovere, vedere Impostazioni obsolete.

Miglioramenti delle prestazioni

In Exchange Server 2003 sono stati implementati numerosi miglioramenti a livello di prestazioni quali, ad esempio, quelli relativi al traffico delle informazioni sullo stato dei collegamenti e alla gestione dello spazio di indirizzi virtuali. Per una descrizione dettagliata di tali miglioramenti delle prestazioni, vedere Novità di Exchange 2003.

Sottosistema di dischi

Nelle seguenti sezioni viene presentata una configurazione di archiviazione consigliata per i diversi tipi di server di Exchange 2003. Per gli utenti di Exchange 2000, in questa sezione sono contenuti alcuni consigli già riportati nella precedente documentazione di Exchange 2000 Server.

Server testa di ponte SMTP

Se il server è un server testa di ponte SMTP (Simple Mail Transfer Protocol), in genere per il layout del disco si consiglia di creare una partizione. I messaggi arrivano mediante l'interfaccia SMTP, vengono scritti nella directory Mailroot, che dovrebbe trovarsi in un sistema basato su un file system NTFS, quindi vengono passati al computer successivo. Per ottimizzare le prestazioni, distribuire la directory Mailroot sul maggior numero di dischi possibile. Se su un server testa di ponte SMTP è presente più di una partizione, riposizionare la directory Mailroot SMTP su una partizione più veloce. Per istruzioni dettagliate sullo spostamento della directory Mailroot, vedere How to Move the Mailroot Directory in Exchange Server 2003.

Un unico asse dovrebbe garantire una velocità di trasferimento pari a circa 30 messaggi di piccole dimensioni al secondo. Pertanto, l'aumento del numero di assis comporta anche un miglioramento delle prestazioni.

La configurazione RAID (Redundant Array of Inexpensive Disks) viene determinata in larga misura dal numero di assi disponibili, come illustrato nella seguente tabella.

Consigli sul RAID

Se il controller RAID dell'hardware dispone di una cache write-back con mirroring e batteria e consente di ottimizzare il rapporto della cache di lettura/scrittura, impostare tale rapporto su 100% scrittura in quanto il server è in grado solo di confermare la ricezione di un messaggio dopo che quest'ultimo è stato scritto sul disco. Pertanto, maggiore è la velocità con cui il server è in grado di scrivere sul disco, maggiore sarà la velocità di risposta del server stesso nei confronti degli altri computer. Anche se il contenuto del messaggio deve essere letto nuovamente prima di essere inoltrato al computer successivo, il servizio SMTP è dotato di un handle di file aperto per i dati ed è in grado di recuperare il contenuto dalla cache NTFS.

Server testa di ponte X.400 Bridgehead o altri server di connessione

Se nel server di Exchange 2003 sono presenti più connettori X.400 oppure se il server è connesso ad altri sistemi di messaggistica quali, ad esempio, Lotus cc:Mail, Lotus Notes, Novell GroupWise o Microsoft Mail, creare una partizione del disco distinta per i registri delle transazioni se è presente un numero sufficiente di assi. I messaggi che utilizzano questi connettori di Exchange trasferiscono i dati mediante il processo Store.exe e, se il server è sottoposto a un carico elevato, le prestazioni vengono ottimizzate mediante lo scollegamento dei registri delle transazioni dal database.

Quando un messaggio viene ricevuto dall'Agente di trasferimento messaggi (MTA, Message Transfer Agent), i dati vengono scritti sulla directory Mtadata di una partizione NTFS e quindi passati al processo Store.exe mediante una coda virtuale MTS-IN. Poiché il messaggio viene trasferito a Store.exe, i dati vengono scritti nei file dei registri delle transazioni. Il messaggio passa quindi al processo di categorizzazione e routing. Se il processo di routing determina che il messaggio deve essere inoltrato mediante un connettore X.400, i dati verranno spostati nella coda virtuale MTS-OUT. Gli altri connettori di messaggistica utilizzano un processo simile.

Il numero di assi disponibili influisce sulla configurazione RAID dell'hardware (vedere la tabella seguente).

Consigli sul RAID

Anche se la configurazione con 6 dischi non utilizza una partizione RAID per il file di paging, se l'elevata disponibilità rappresenta un fattore critico, posizionare il file di paging su una partizione protetta.

Se il controller RAID hardware dispone di una cache write-back con mirroring e batteria e consente di ottimizzare il rapporto della cache di lettura/scrittura, impostare tale rapporto su 100% scrittura per le configurazioni che utilizzano un'unica partizione e su 100% scrittura sulla partizione dei registri delle transazioni nelle configurazioni con cinque o più dischi. Si otterranno prestazioni significativamente migliori grazie all'utilizzo della cache di scrittura sui registri delle transazioni anziché della cache di lettura sull'unità del database.

Server delle cassette postali e di cartelle pubbliche

In una configurazione con un unico server di database, la progettazione dei dischi è simile a quella di Exchange Server 5.5 e Exchange 2000 Server. La priorità principale è costituita dalla suddivisione dei registri delle transazioni e del database su assi distinti. Non solo i registri devono trovarsi su un gruppo di assi distinto, ma tale gruppo di assi dovrà anche essere dedicato esclusivamente ai registri. Ad esempio, questa configurazione non offrirà alcun vantaggio a livello di prestazioni se si posiziona il file di paging oppure il sistema operativo Windows® 2000 Server o Windows Server™ 2003 sullo stesso gruppo di assi in cui si trovano i registri.

Se sul server si prevede di creare più gruppi di archiviazione, la principale priorità dovrà essere, ancora una volta, la suddivisione dei registri su assi dedicati. Tuttavia, per garantire un miglioramento delle prestazioni, è necessario disporre di un gruppo di assi dedicati per ogni gruppo di archiviazione. Dopo avere definito un gruppo di assi dedicati, determinare il numero di assi rimasti. Nella maggior parte dei server non saranno disponibili molti slot. Pertanto, la soluzione migliore potrebbe essere costituita dal posizionamento di tutti i database sulla stessa partizione.

Se i database vengono distribuiti su più gruppi di archiviazione nello stesso array e tale array non è più disponibile, tutti i database di tali gruppi di archiviazione, anche quelli che si trovano su altri array, non saranno temporaneamente disponibili. Il database non disponibile verrà contrassegnato come inattivo, mentre i database disponibili effettueranno nuovamente la connessione. L'interruzione del servizio dovrebbe durare solo alcuni minuti, quindi i client MAPI quali Microsoft Outlook® ristabiliscono la connessione.

Se si dispone di un numero sufficiente di dischi, è possibile dividere i file di database delle proprietà (edb) da quelli di flusso (stm). I tipi di client supportati dal server determina i vantaggi a livello di prestazioni della suddivisione di questi file. Se, ad esempio, si prevede di servire solo utenti IMAP4 (Internet Message Access Protocol versione 4rev1) e POP3 (Post Office Protocol versione 3) che utilizzano allegati di grandi dimensioni, le dimensioni di lettura/scrittura dovrebbero essere maggiori di 4 KB, ovvero la configurazione tipica per gli utenti MAPI su un database edb. In questo caso, la suddivisione dei file è una procedura consigliata. È possibile ottimizzare i dischi per i file STM in modo da supportare allegati di grandi dimensioni.

Le operazioni di lettura e scrittura dei client MAPI e Microsoft Outlook Web Access avvengono a livello del file EDB. Dal punto di vista tecnico, i client comunicano con il processo Store.exe. Pertanto, non sono in grado di distinguere tra i file EDB e i file STM. Tutti gli altri client utilizzano invece il file STM. Nella seguente tabella sono riportate le posizioni preferite utilizzate dai diversi client.

Posizioni preferite di archiviazione del client

Anche se in questa tabella è indicato il tipo di file preferito, è possibile che si verifichino conversioni incrociate. Ad esempio, se un client POP3 invia un messaggio, i dati del messaggio vengono memorizzati fisicamente nel file STM. Si tratta di una sorta di trasferimento automatico delle proprietà dell'intestazione del messaggio e di altri dati al file EDB. Si supponga, ora, che un client MAPI tenti di leggere il messaggio. In questo scenario i dati del messaggio contenuti nel file STM vengono completamente spostati nel file EDB file, mentre gli allegati rimangono nel file STM e convertiti nella memoria. Il passaggio avviene solo dal file STM al file EDB. In nessuna situazione i dati vengono spostati nel file STM. In questo scenario tutte le conversioni client vengono eseguite nella memoria con l'aiuto dei file temporanei.

Nella maggior parte dei casi non si ottiene alcun vantaggio effettivo dalla suddivisione dei file EDB e STM su assi diversi. Se, ad esempio, si dispone di sei dischi, è necessario decidere se la creazione di due partizioni RAID5 su tre dischi potrebbe dare prestazioni migliori rispetto alla creazione di un'unica partizione RAID0+1 (con striping e mirroring). In questo caso specifico, una partizione RAID0+1 offre prestazioni di scrittura migliori.

Con l'aumento della dimensione dei dischi, si potrebbe valutare l'ipotesi di acquistare un numero minore di dischi di dimensioni maggiori per la gestione dei dati utente. Purtroppo, tuttavia, la velocità dei dischi non è direttamente proporzionale alle dimensioni. Pertanto potrebbe essere disponibile spazio su disco sufficiente, ma le prestazioni potrebbero risultare insufficienti per il carico di utenti. Allocare pertanto un numero sufficiente di assi del disco fisico per i server delle cassette postali. È opportuno sottolineare che i sottosistemi di archiviazione specializzati che utilizzano gigabyte di cache e numerosi rack di dischi rigidi in genere sono dotati di sistemi di gestione delle partizioni e sistemi operativi con tolleranza di errore propri. In ambienti con questo tipo di dispositivi, si consiglia di rivolgersi al servizio di assistenza clienti del fornitore dell'hardware.

In sintesi, linee guida per la corretta configurazione dei server delle cassette postali sono le seguenti:

• Creare una partizione RAID1 per i file binari di Windows ed Exchange.
• Posizionare il file di paging su un asse di RAID1 distinto. Per i server delle cassette postali, si consiglia di non posizionare mai il file di paging in una partizione non di tipo RAID in quanto la perdita del volume comporta l'arresto del server.
• Creare una partizione dedicata con tolleranza di errore per ogni gruppo di archiviazione per i registri delle transazioni, ad esempio RAID1 o RAID 0+1. Una partizione RAID1 a due dischi dovrebbe fornire circa 300 operazioni di I/O di scrittura sequenziali al secondo. Questa capacità dovrebbe essere più che sufficiente per un gruppo di archiviazione con cinque database ed elevati livelli di traffico.
• Creare almeno una partizione con tolleranza di errore per i database. Se si dispone di un solo array, posizionare tutti i database su tale array. Se si dispone di più array, utilizzare un array per ogni gruppo di archiviazione (solo database).

I database, le code SMTP e i file di registro delle transazioni possono essere spostati in partizioni diverse mediante il Gestore di sistema di Exchange.

Per ulteriori informazioni sullo spostamento di database e registri, vedere l'articolo 257184 della Microsoft Knowledge Base "XADM: Spostamento dei database e dei registri di Exchange in Exchange 2000 Server".

Allineamento delle operazioni di I/O di Exchange ai limiti delle tracce di archiviazione

Con un disco fisico contenente 64 settori per traccia, in Windows la partizione viene sempre creata a partire dal 64° settore. Si viene a creare pertanto un disallineamento tra le partizioni e il disco fisico sottostante. Per garantire l'allineamento del disco, utilizzare lo strumento di partizione del disco Diskpart.exe, un'utilità fornita da Microsoft tra gli strumenti di supporto di Windows Server 2003 Service Pack 1. Diskpart.exe è un'utilità della riga di comando in grado di impostare in modo esplicito l'offset iniziale nel record di avvio principale (MRB, Master Boot Record). Mediante l'impostazione dell'offset iniziale, è possibile gestire l'allineamento e migliorare le prestazioni del disco. In Exchange Server 2003 i dati vengono scritti in operazioni di I/O multiple di 4 KB, ovvero 4 KB per i database e fino a 32 KB per i file di flusso. Assicurarsi pertanto che l'offset iniziale sia un multiplo di 4 KB. In caso contrario, è possibile che una singola operazione di I/O si estenda su due tracce generando in questo modo un deterioramento delle prestazioni.

Per istruzioni dettagliate, vedere la sezione "Allineamento delle operazioni di I/O di Exchange ai limiti delle tracce di archiviazione" in Ottimizzazione del sistema di archiviazione per Exchange Server 2003.