Ottimizzazione del sistema di archiviazione per Exchange Server 2003

c5541abf-15ce-464f-b5d2-758395fcdf3e
Ottimizzazione del sistema di archiviazione
per Microsoft Exchange Server 2003
Microsoft Corporation
Data di pubblicazione: 12 dicembre 2006
Autore: team della documentazione di Exchange Server
Riassunto
Questa guida consente di ottimizzare l'architettura di archiviazione per Exchange Server
2003.
Inviare eventuali commenti a [email protected].
Contents
Ottimizzazione del sistema di archiviazione per Exchange Server 2003 ................................. 5
Destinatari della guida ........................................................................................................... 6
Informazioni preliminari.......................................................................................................... 7
Exchange Solution Reviewed Program-Storage ...................................................................... 7
Ulteriori informazioni .............................................................................................................. 8
Cause delle operazioni di I/O del disco di Exchange ................................................................ 8
Componenti dei dati di Exchange .......................................................................................... 9
Altre attività che influiscono sulle operazioni di I/O ............................................................. 11
Procedure consigliate per l'ottimizzazione delle operazioni di I/O del disco di Exchange .. 16
Come calcolare i requisiti di I/O del disco ............................................................................... 19
Calcolo delle operazioni di I/O tramite dati teorici ............................................................... 19
Calcolo delle operazioni di I/O tramite dati dell'ambiente reale ........................................... 22
Modalità di calcolo dei requisiti delle operazioni I/O utilizzando i dati ambientali ................... 23
Informazioni preliminari........................................................................................................ 23
Procedura ............................................................................................................................ 24
Per ulteriori informazioni ...................................................................................................... 26
Ottimizzazione dell'architettura di archiviazione ..................................................................... 27
Ottimizzazione di DAS ......................................................................................................... 27
Ottimizzazione di reti SAN ................................................................................................... 27
Ottimizzazione di NAS (Network-Attached Storage) ........................................................... 28
Ottimizzazione di iSCSI ....................................................................................................... 30
Allineamento delle operazioni di I/O di Exchange ai limiti delle tracce di archiviazione ......... 31
Informazioni preliminari........................................................................................................ 31
Procedura ............................................................................................................................ 32
Abilitazione dei contatori aggiuntivi ESE estesi ...................................................................... 32
Informazioni preliminari........................................................................................................ 33
Procedura ............................................................................................................................ 33
Per ulteriori informazioni ...................................................................................................... 33
Procedure consigliate comuni a più architetture ..................................................................... 33
Procedure consigliate per architetture specifiche ................................................................... 39
Utilizzo di driver Storport invece di driver SCSIPort ............................................................ 43
Ulteriori considerazioni sulla progettazione ............................................................................ 44
Utilizzo di Jetstress per verificare le prestazioni del sistema di archiviazione ........................ 50
Conclusione e ulteriori informazioni ........................................................................................ 51
Copyright ................................................................................................................................. 52
5
Ottimizzazione del sistema di archiviazione
per Exchange Server 2003
Se si sta pianificando l'implementazione di Microsoft® Exchange Server 2003 e si desidera
dedicare particolare attenzione ai fattori di disponibilità, tolleranza d'errore e prestazioni, è
fondamentale comprendere come ottimizzare il sistema di archiviazione per Exchange
Server 2003, indipendentemente dalle dimensioni dell'organizzazione.
I colli di bottiglia del sottosistema di dischi sono fonte di problemi di prestazioni ancor più
delle carenze a livello di CPU o RAM sul lato server, e un sottosistema di dischi strutturato in
modo inadeguato espone un'azienda a numerosi rischi di malfunzionamenti hardware. In
particolare, i problemi di prestazioni del sottosistema di dischi si manifestano nei seguenti
modi:

Latenza media di lettura e scrittura superiore a 20 ms.

Picchi di latenza superiori a 50 ms che durano oltre qualche secondo.
Una elevata latenza del disco è sinonimo di prestazioni insufficienti. Per ridurre al minimo
i problemi di latenza del disco, è opportuno adottare le seguenti misure:

Investire in dischi e assi a elevate prestazioni L'utilizzo di dischi a capacità ridotta
che sfruttano le prestazioni di ogni asse è preferibile all'uso di un numero minore di assi
con capacità elevata. Un sistema di archiviazione veloce con una quantità sufficiente di
assi è uno degli investimenti più importanti per l'infrastruttura di messaggistica di
un'azienda.

Anteporre le prestazioni alla capacità La scelta della dimensione dell'archivio basata
principalmente sulla capacità si traduce spesso in una diminuzione delle prestazioni del
sottosistema di dischi. Ad esempio, sono numerosi gli amministratori che scelgono una
soluzione RAID-5 per ottimizzare l'utilizzo dell'archivio. Tuttavia, in molti casi, una
corretta valutazione delle prestazioni richieste agli assi porta a utilizzare per i sistemi
RAID-5 un numero di dischi superiore rispetto ai sistemi RAID-1+0.

Allineare i dischi Utilizzare DiskPar per verificare che le tracce dei dischi siano
allineate ai settori. Rispetto alle partizioni non allineate create con Gestione dischi, la
creazione di partizioni allineate tramite DiskPart consente di incrementare le prestazioni
del 20%. Per la procedura dettagliata, vedere Allineamento delle operazioni di I/O di
Exchange ai limiti delle tracce di archiviazione. Notare che Diskpart può essere utilizzato
solo con dischi in modalità di base. Non può essere utilizzato con dischi dinamici.
Diskpart fa parte degli strumenti di supporto di Windows Server 2003 Service Pack 1.
Diskpart sostituisce la funzionalità disponibile in Diskpar, uno strumento di Windows 2000
Server Resource Kit.
6
Tutti gli argomenti sopra menzionati sono illustrati in dettaglio più avanti in questo
documento. In generale, per ottimizzare il sistema di archiviazione ed evitare problemi di
latenza elevata del disco, è necessario comprendere:

Le cause di I/O del disco di Exchange.

Come calcolare i requisiti di I/O del disco.

Come ottimizzare l'architettura di archiviazione.

Come verificare le prestazioni del sistema di archiviazione.
Nota:
Scaricare il documento Optimizing Storage for Microsoft Exchange Server 2003 per
stamparlo o leggerlo dopo l'interruzione del collegamento.
Destinatari della guida
Questa guida è destinata a professionisti del settore IT responsabili della pianificazione e
della progettazione di sistemi di messaggistica Exchange. Nella seguente tabella sono
elencati i ruoli e le responsabilità specifici di tali figure professionali:
Ruoli e responsabilità professionali
Ruolo
Responsabilità
Architetti di sistemi di archiviazione

Progettazione dell'infrastruttura di
archiviazione

Sviluppo di strategie e criteri di
distribuzione del sistema di archiviazione

Partecipazione alla progettazione del
sistema di archiviazione per la
connettività di rete

Progettazione dell'infrastruttura server
globale

Sviluppo di strategie e criteri di
distribuzione dei server

Partecipazione allo sviluppo della
connettività di rete
Architetti di sistema
7
Ruolo
Responsabilità
Amministratori di sistema

Pianificazione e distribuzione di
tecnologie per server che eseguono
Microsoft Windows Server™ 2003 o
Windows® 2000 Server

Valutazione e indicazione di nuove
soluzioni a livello di tecnologia

Implementazione e gestione del sistema
di messaggistica dell'azienda
Amministratori del sistema di messaggistica
Informazioni preliminari
Le informazioni sull'archiviazione contenute in questa guida possono essere applicate in
modo appropriato soltanto se si dispone di una conoscenza approfondita dei componenti del
sottosistema di dischi. Si consiglia pertanto ai non esperti di familiarizzare con i concetti
relativi all'archiviazione di Windows prima di affrontare la lettura del presente documento. Per
informazioni su tali concetti, vedere Analisi delle prestazioni dei sottosistemi di dischi per
Windows all'indirizzo.
In tale documento sono inclusi riferimenti ad elementi dell'architettura di base di Exchange
quali gli archivi, i gruppi di archiviazione e i registri delle transazioni. Se non si ha ancora
familiarità con tali elementi e con la relativa implementazione in Exchange, vedere "Gestione
degli archivi di cassette postali e cartelle pubbliche" nel Manuale dell'amministratore di
Exchange Server 2003.
Exchange Solution Reviewed ProgramStorage
Exchange Solution Reviewed Program (ESPR) –Storage è un programma di Microsoft®
Exchange Server progettato per facilitare la verifica dell'archiviazione di terze parti e la
pubblicazione di soluzioni per Exchange Server. ESRP combina un test harness di
archiviazione (Jetstress) con linee guida per la pubblicazione delle soluzioni. Microsoft Gold
Certified Partners e Certified Storage Partners possono utilizzare il framework ESRP fornito
per verificare le proprie soluzioni di archiviazione per la distribuzione di Microsoft Exchange.
Nota:
ESRP–Storage non è un programma di certificazione, qualifica o logo Microsoft.
8
I dati delle prestazioni per la soluzione di archiviazione testata e la white paper sulle
procedure consigliate vengono inoltrate al gruppo dei prodotti Microsoft Exchange per
l'analisi. Le white paper per la soluzione analizzate vengono successivamente elencate e
visualizzate come collegamento nel sito Web di Microsoft Exchange Solution Reviewed
Program (ESRP)-Storage.
Gli ambiti di utilizzo di ESRP-Storage sono i seguenti:

Una soluzione di archiviazione efficace è fondamentale per una corretta
distribuzione di Exchange. Exchange dipende dall'archiviazione per garantire la
disponibilità dei dati. Un'archiviazione progettata in modo non efficace non determinerà
soltanto in un'esperienza negativa da parte dell'utente ma potrà limitare la disponibilità
del server sul quale è in esecuzione Exchange.

I problemi di archiviazione di Exchange sono costosi e difficili da analizzare e
risolvere. Correggere un'architettura di archiviazione progettata in modo non efficace
dopo averla attivata è un'operazione molto rischiosa e costosa perché spesso richiede la
creazione di un nuovo sistema di archiviazione.

Esiste una grande differenza nella qualità e nelle procedure consigliate per la
configurazione tra le singole soluzioni di archiviazione per Exchange. Poiché
l'archiviazione è fondamentale per Exchange, è necessario fornire le linee guida per la
verifica della consistenza dell'archiviazione e per le procedure consigliate.
Per risolvere questi problemi, il team del prodotto di Exchange ha creato ESRP-Storage per
consentire ai fornitori di produrre soluzioni di archiviazione testate e corredate da una valida
documentazione per velocizzare le distribuzioni di Exchange, fornire sicurezza per una
determinata soluzione di archiviazione e infine migliorare l'efficienza della soluzione di
Exchange.
Ulteriori informazioni
Per ulteriori informazioni su ESRP-Storage, vedere le seguenti risorse:

Exchange Solution Reviewed Program (ESPR) -Storage

Sito Web di Microsoft Exchange Storage Partners

Extranet di Microsoft Storage Partner
Cause delle operazioni di I/O del disco di
Exchange
Ogni volta che si verifica una lettura o una scrittura di dati in Exchange, viene generata
un'operazione di I/O del disco. La comprensione delle cause di tali operazioni aiuta a
9
pianificare e configurare il sottosistema di dischi in modo da ottimizzare le prestazioni. A tale
scopo, è consigliabile prestare la massima attenzione alle operazioni di I/O generate durante
l'accesso ai file di registro e ai file di database.
Componenti dei dati di Exchange
Tutti i dati di Exchange sono memorizzati nell'archivio di Exchange, costituito da tre
componenti principali. Nella seguente tabella sono illustrati tali componenti e l'impatto che
ciascuno di essi ha sulle operazioni di I/O del disco.
Componenti dell'archivio di Exchange e corrispondente impatto sulle operazioni di I/O
del disco
Componente
Impatto sulle operazioni di I/O del disco
Database Jet (file EDB)
Il database Jet viene utilizzato per archiviare
tutti i dati inviati dai client MAPI. Tutte le
attività generate da un client MAPI causano
l'aggiornamento del database Jet.
Consente di archiviare la posta SMTP in
arrivo che contiene informazioni MAPI.
Database di flusso (file STM)
Consente di archiviare gli allegati e i dati
inviati da IMAP4, NNTP, Microsoft Outlook®
Web Access o SMTP. I puntatori vengono
salvati nel database Jet in modo che i dati
possano essere recapitati ai client MAPI su
richiesta.
Consente di archiviare la posta SMTP in
arrivo che non contiene informazioni MAPI.
Tutte le attività lato client dei protocolli
Internet causano l'aggiornamento del
database di flusso.
10
Componente
Impatto sulle operazioni di I/O del disco
File di registro delle transazioni (file LOG)
Tutte le modifiche apportate al database
vengono prima salvate nei file di registro
delle transazioni. Di conseguenza, ogni volta
che un utente invia o legge un messaggio o
modifica i dati archiviati nella propria cassetta
postale, tali modifiche vengono scritte nel file
di registro delle transazioni. Le modifiche
vengono immediatamente salvate nella
cache del database in-RAM e quindi copiate
nuovamente su disco quando il carico del
sistema lo consente. Le transazioni vengono
inoltre nuovamente lette quando un database
viene installato.
Poiché ogni componente dell'archivio di Exchange viene scritto in modo diverso, si otterranno
prestazioni migliori memorizzando in un volume i file EDB e i corrispondenti file STM e in un
altro volume i file di registro delle transazioni. Nella seguente tabella viene illustrato il modo in
cui le operazioni di lettura e scrittura su disco vengono eseguite per ogni componente
dell'archivio di Exchange.
Operazioni di lettura e scrittura su disco per ogni componente dell'archivio di
Exchange
Componente
Modello di I/O
Database Jet (file EDB)

Operazioni di lettura e scrittura casuali

Dimensioni di pagina pari a 4 KB

Normali operazioni di lettura e scrittura in
sequenza

Dimensioni di pagina variabili la cui
media è 8 KB in produzione
Database di flusso (file STM)
Nota:
A causa del numero elevato di
operazioni di ricerca, il modello di I/O
non è né interamente casuale né
interamente sequenziale.
11
Componente
Modello di I/O
File di registro delle transazioni (file LOG)

100% di operazioni di scrittura
sequenziali durante le normali operazioni

100% di operazioni di lettura sequenziali
durante le operazioni di ripristino

Le dimensioni delle operazioni di scrittura
variano da 512 byte fino alle dimensioni
del buffer del file di registro
Nota:
Se le cartelle pubbliche si trovano sul server, si verificheranno ulteriori carichi di I/O.
Se tuttavia sul server non esistono repliche del contenuto delle cartelle, il carico di
I/O generato dall'esistenza di un database di cartelle pubbliche è irrilevante rispetto
all'I/O generato dall'accesso degli utenti alle cassette postali.
Altre attività che influiscono sulle operazioni di
I/O
Oltre all'accesso ai file di database, altre attività sono in grado di causare operazioni di I/O
del disco. Nella seguente tabella sono illustrate tali attività e il relativo impatto sulle
operazioni di I/O.
Altre attività che influiscono sulle operazioni di I/O del disco
Attività
Impatto sulle operazioni di I/O del disco
Azzera pagine database eliminate
Se si configura il server per l'azzeramento
delle pagine del database eliminate, ogni
volta che si elimina un elemento dal database
verranno eliminate più pagine. Le pagine
eliminate verranno quindi sovrascritte con
valori pari a zero. Questa funzione viene
eseguita solo durante un backup di flusso in
linea e causa maggiori attività I/O del disco
fisico durante il backup.
12
Attività
Impatto sulle operazioni di I/O del disco
Indicizzazione del contenuto
Durante l'analisi dei database per
l'aggiornamento degli indici, si riscontra
un'eccessiva attività di paging, nonché un
numero eccessivo di operazioni di scrittura
nel file di indicizzazione del contenuto, che
genera un picco nelle operazioni di I/O sul
disco in cui è presente tale file di
indicizzazione.
Trasmissione della posta SMTP
Il traffico SMTP in entrata e in uscita viene
scritto su disco durante il transito nel sistema.
Se il disco è condiviso con file di registro o di
database utente, i messaggi SMTP che
vengono letti o scritti dal disco dovranno
contendersi con tali file il carico di I/O.
Durante lo spooling dalla coda al primo
database di Exchange, i messaggi SMTP
vengono convertiti da MIME in Imail,
generando un ulteriore carico di I/O sui
volumi di database e di file di registro
utilizzati dal database.
Paging
Quando Exchange richiede una quantità di
memoria superiore a quella fisicamente
disponibile, Windows effettua il paging delle
informazioni nel file di paging memorizzato
sul disco rigido. Un'eccessiva attività di
paging causa un numero eccessivo di
operazioni di I/O del disco, che riducono le
prestazioni del server di Exchange. Per
ulteriori informazioni sulla risoluzione dei
problemi di paging e della distribuzione della
memoria kernel, vedere Ruling out MemoryBound Problems
(http://go.microsoft.com/fwlink/?LinkId=62575
informazioni in lingua inglese).
13
Attività
Impatto sulle operazioni di I/O del disco
Gestione dei messaggi MTA
In Exchange 2000 e Exchange 2003, i
messaggi ricevuti durante operazioni di
spostamento delle cassette postali oppure da
server di Exchange 5.5, server X.400 o
tramite connettori EDK vengono scritti nei file
di registro delle transazioni, causando un
carico di I/O del disco nel sistema di
archiviazione.
Numero di elementi in una cartella
Quando il numero di elementi nelle cartelle
principali di Exchange 2003 aumenta, anche
il costo del disco fisico per eseguire alcune
attività aumenta per gli utenti di Outlook in
modalità in linea. Gli indici e le ricerche
vengono eseguiti sul client quando si utilizza
Outlook in modalità cache. Quando si ordina
la Posta in arrivo per dimensione per la prima
volta, è necessario creare un nuovo indice,
che richiede molte attività di I/O. Gli
ordinamenti futuri della Posta in arrivo per
dimensioni possono essere molto costosi.
Esiste un numero fisso di indici che è
possibile avere, quindi ordinando le proprie
cartelle in molti modi diversi si può superare
questo limite e causare attività I/O aggiuntive
del disco.
Numero di cassette postali
In Exchange, le letture del database possono
essere ridotte in qualche misura dalla cache
del database che ha dimensioni fisse.
Quando si aggiungono altre cassette postali
a un server di Exchange, più cassette postali
utilizzano la stessa cache. Per ogni 1000
utenti aggiunti a un server di Exchange su
una base di 1000, si aumentano gli IOPS del
database del 25%.
14
Attività
Impatto sulle operazioni di I/O del disco
Versione di Exchange
Quando si migra da Exchange 5.5 a
Exchange 2000 SP3, è possibile prevedere il
5% di aumento di IOPS del database, se tutti
gli altri fattori sono costanti.
Quando si migra da Exchange 5.5 a
Exchange 2003 SP1, è possibile prevedere il
20% di riduzione di IOPS del database, se
tutti gli altri fattori sono costanti.
Archiviazione di istanza singola
In Exchange 5.5, è presente un solo
database sul server. La posta inviata a più
cassette postali su quel server viene
archiviata una sola volta e dei richiami
vengono recapitati a ciascun destinatario. In
Exchange 2000 e Exchange 2003, è
possibile avere fino a 20 database e ciascun
database può avere una copia del messaggio
se i destinatari risiedono su ciascun
database. Ciascun database aggiuntivo
aggiunge il 2% di IOPS del database.
L'efficienza con la quale Exchange utilizza
l'archiviazione di istanza singola dipende
dalla percentuale dei messaggi inviati ai
destinatari nello stesso database e alla
dimensioni media del messaggio. I messaggi
più grandi hanno più vantaggi con
l'archiviazione di istanza singola.
15
Attività
Impatto sulle operazioni di I/O del disco
BlackBerry
In Exchange 2000 e Exchange 2003, gli
utenti che dispongono di dispositivi
BlackBerry aggiungono ulteriori richieste al
server. In questo campo, molti clienti vedono
un aumento da due a quattro volte maggiore
nelle attività di I/O del disco di database. Per
ulteriori informazioni, vedere la white paper
RIM.
Gli utenti BlackBerry causano un carico
aggiuntivo che influisce sugli IOPS del
database di un server. Quando in RIM sono
stati testati 1000 utenti MMB2 abilitati per
BlackBerry con BlackBerry Enterprise Server
4, è stato rilevato che gli IOPS del database
aumentavano di un fattore di 3,64 rispetto
agli utenti MMB2 standard senza BlackBerry.
Questo fattore potrebbe essere
significativamente inferiore o maggiore in
base al modo in cui i dispositivi BlackBerry
vengono utilizzati nell'ambiente. Il test
BlackBerry includeva: 10 comandi di
sincronizzazione, due aggiunte memo, una
modifica, un'eliminazione e quattro aggiunte
di attività. L'effettivo utilizzo dei dispositivi
BlackBerry non sarà così costante,
determinando un impatto inferiore o minore
sugli IOPS effettivi.
Per un sistema di posta costituito da 2.000
cassette postali con profilo alto, di cui 500
sono abilitati per BlackBerry, viene generato
un totale di 3820 IOPS sul volume del
database. La formula per calcolare tale
valore è la seguente:
IOPS BlackBerry per utente stimato per tipo
di utente × Numero di utenti
In questo esempio, 1.0 IOPS × 2.000
cassette postali=2.000 IOPS. Se 500 utenti
dispongono di dispositivi BlackBerry,
aggiungono 500 cassette postali x 3.64
IOPS=1820 IOPS, o 3820 IOPS totali.
Utilizzando un rapporto moderato di due
operazioni di lettura per ogni operazione di
scrittura, ovvero un rapporto 66% / 33%, è
possibile pianificare 2.546 richieste di
operazioni di I/O di lettura e 1.273 richieste di
16
Procedure consigliate per l'ottimizzazione delle
operazioni di I/O del disco di Exchange
Dopo avere appreso le cause della generazione di operazioni di I/O del disco in Exchange, si
dovrà procedere all'organizzazione del sistema di archiviazione in modo da ottimizzare le
prestazioni. Nella seguente tabella sono indicate le procedure consigliate per il
posizionamento di ogni file di dati.
Procedure consigliate per l'ottimizzazione delle operazioni di I/O del disco
Origine I/O Exchange
Procedure consigliate per l'ottimizzazione delle
prestazioni
File di database
Posizionare tutti i file di database (EDB e
STM) in un gruppo di archiviazione su un
unico volume dedicato a tali file. I dischi su
cui sono presenti i file di database dovranno
avere velocità di accesso casuale elevata.
File di indicizzazione del contenuto
Evitare di posizionare i file di indicizzazione
del contenuto sullo stesso disco che contiene
il file di paging, benché si tratti della
posizione predefinita. Essendo un file ad
accesso casuale, il file di indicizzazione del
contenuto può essere memorizzato nello
stesso volume in cui si trovano i database,
purché il sottosistema di dischi sia in grado di
gestire il carico.
Archiviazione di istanza singola
Per ottimizzare l'utilizzo dell'archiviazione di
istanza singola, le cassette postali che
appartengono agli stessi gruppi di lavoro e
liste di distribuzione devono essere collocate
nello stesso database.
17
Origine I/O Exchange
Procedure consigliate per l'ottimizzazione delle
prestazioni
File di registro delle transazioni
Poiché tutte le transazioni vengono scritte nei
file di registro delle transazioni, è opportuno
posizionare tali file in una periferica di
archiviazione caratterizzata da una latenza di
scrittura minima. In genere è possibile
ottenere la latenza di scrittura minima
dedicando un set RAID-1/RAID-1+0 ai registri
di un singolo gruppo di archiviazione. In tal
modo si evita di unire flussi di dati con altro
I/O e si garantisce il 100% di operazioni di I/O
di scrittura sequenziale, assicurando la
massima velocità di trasmissione dei dati su
disco e latenza minima. Array di
archiviazione con mirroring effettivo, cache
write-back e batteria non possono apportare
alcun miglioramento delle prestazioni in
questo modo, in quanto tutte le operazioni di
I/O di scrittura vengono scritte prima nella
cache, assegnate e infine scritte su disco
(fornendo latenza di scrittura minima in
quanto la scrittura viene restituita al sistema
operativo in modo corretto, una volta
memorizzata nella cache). Jetstress può
essere utilizzato per calcolare se questo tipo
di isolamento I/O offre prestazioni migliori per
una determinata configurazione o piattaforma
di archiviazione.
Per ottimizzare le funzioni di ripristino, si
consiglia di collocare i registri delle
transazioni e i database di un determinato
gruppo di archiviazione in un LUN diverso
(Logical Unit Numbers, Numeri di unità
logica), configurato come RAID-1/RAID-1+0.
Inoltre, è consigliabile che i numeri di unità
logica separati che ospitano i file di registro e
di database dello stesso gruppo di
archiviazione non condividano i dischi fisici
nell'array. In questo modo, si ottiene un
miglior livello di recuperabilità che consente
di eseguire il ripristino da più scenari di errore
del disco con minima perdita di dati (vengono
persi i dischi con la copia dei registri o i dischi
con la copia dei database, ma non entrambi).
Se viene perso il numero di unità logica del
registro, si disporrà ancora di un database
18
Origine I/O Exchange
Procedure consigliate per l'ottimizzazione delle
prestazioni
Coda SMTP
Per il volume delle code SMTP si consiglia di
utilizzare un array di dischi RAID-1+0 con più
assi. Il numero di assi dei dischi e la
dimensione della cache di scrittura dovranno
essere basati sulla velocità di trasmissione
prevista dei messaggi SMTP del server.
La coda SMTP non dovrà mai essere
posizionata su un asse che contiene altri
elementi che hanno impatto sul carico di I/O,
come i file di registro delle transazioni, i file di
database, i file di paging o i file di sistema.
Il fatto che un messaggio sia destinato a una
cassetta postale sullo stesso server o su un
server remoto ha un impatto irrilevante sulle
operazioni di I/O del disco relative alle code
SMTP.
File di paging
Per ottimizzare le prestazioni, si consiglia di
memorizzare il file di paging su assi separati
e su una periferica RAID-1 o superiore. In
caso di perdita del disco che contiene il file di
paging, sul server si verificherà un errore di
interruzione.
Coda MTA
Evitare di memorizzare la coda dell'Agente di
trasferimento messaggi (MTA) su un volume
di database o di registri. Se il server gestisce
una quantità significativa di traffico SMTP e/o
MTA, predisporre un insieme distinto di assi
per le code SMTP e MTA.
Se ad esempio si dispone di un computer con Exchange 2003 che contiene un gruppo di
archiviazione con cinque database, sarà necessario configurare i seguenti array RAID fisici
separati:

C:\ - Volume di sistema, sistema operativo, file di sistema di Exchange - RAID-1 (DAS,
non SAN)

D:\ - File di paging - RAID-1 (DAS, non SAN)

E:\ - Code SMTP e MTA - RAID-1+0 (SAN)
19

F:\ - File di registro del gruppo di archiviazione 1 - RAID-1 (SAN)

G:\ - Database del gruppo di archiviazione 1 - RAID-1+0 (SAN)
Come calcolare i requisiti di I/O del disco
Il passo successivo all'identificazione delle attività e dei componenti di Exchange che
generano operazioni di I/O del disco e delle modalità di configurazione dell'archivio per il
supporto di tali operazioni consiste nel calcolare i requisiti di I/O del disco per gli utenti, allo
scopo di ottimizzare il sottosistema di dischi per meglio supportare le attività degli utenti.
L'obiettivo è quello di fornire prestazioni di I/O del disco adeguate, misurate in base al
numero di operazioni di I/O eseguibili al secondo (IOPS), con una latenza che consenta un
funzionamento efficiente di Exchange.
Il calcolo del valore di IOPS per cassetta postale è un modo utile di misurare il profilo di un
determinato server in base a operazioni di I/O casuali di lettura/scrittura nel database (il
carico di I/O dei registri delle transazioni non è incluso in questa equazione). Maggiore è il
valore di IOPS per cassetta postale, maggiore sarà l'utilizzo del disco da parte del profilo
della cassetta postale.
È possibile calcolare i requisiti di I/O del disco in due modi:

Determinando le necessità degli utenti sulla base di dati teorici

Calcolando l'attività degli utenti tramite la console Prestazioni (Perfmon)
Indipendentemente dall'approccio scelto, è necessario basare i calcoli sui periodi di maggiore
utilizzo, che in numerose aziende corrisponde all'inizio dell'attività lavorativa, quando i
dipendenti raggiungono le postazioni di lavoro e controllano la propria posta elettronica.
Calcolo delle operazioni di I/O tramite dati
teorici
Se si sta pianificando la distribuzione di Exchange nella propria azienda e si desidera
calcolare i requisiti di archiviazione che ne risulteranno, è possibile utilizzare i dati che sono
già stati raccolti, ovvero i profili delle cassette postali, che descrivono i modelli generali di
utilizzo delle cassette postali di Exchange.
Nella seguente tabella sono illustrati i profili delle cassette postali che è possibile utilizzare
come riferimento per la pianificazione della capacità dei server di cassette postali di
Exchange. Tali profili rappresentano l'accesso alle cassette postali calcolato per la media dei
client Outlook o MAPI dell'organizzazione.
20
Profili utenti e schemi di utilizzo corrispondenti
Tipo utente
IOPS su volume
Operazioni giornaliere
Dimensione cassetta
database
di invio e ricezione
postale
Basso
.5
20 invii/50 ricezioni
50 MB
Medio
.75
30 invii/75 ricezioni
100 MB
Alto
1.0
40 invii/100 ricezioni
200 MB
Grande
1.5
60 invii/150 ricezioni
500 MB
Ogni profilo rappresenta il carico di I/O totale sul database Jet e non include l'I/O relativo
all'attività dei file di registro delle transazioni. Per calcolare correttamente il carico del
sottosistema di dischi, è necessario suddividere l'I/O del database in operazioni di I/O di
lettura e di scrittura, poiché le operazioni di scrittura generano un carico di I/O superiore
rispetto alle operazioni di lettura.
Per calcolare il rapporto lettura/scrittura, si consiglia di basarsi sui modelli di utilizzo di
un'azienda con un profilo di cassetta postale alto. In un ambiente di produzione, i rapporti
lettura/scrittura possono essere stimati attorno al 75%/25% e al 66%/33%, in base al gruppo
di utenti considerati.
Per un sistema di posta costituito da 2.000 cassette postali con profilo alto, viene generato un
totale di 1.500 IOPS sul volume del database. La formula per calcolare tale valore è la
seguente:
IOPS per utente stimato per tipo di utente × Numero di utenti
In questo esempio, 0,75 IOPS × 2.000 cassette postali=1.500 IOPS.
Utilizzando un rapporto moderato di due operazioni di lettura per ogni operazione di scrittura,
ovvero un rapporto 66% letture / 33% scritture, è possibile pianificare 1.000 richieste di
operazioni di I/O di lettura e 500 richieste di operazioni di I/O di scrittura al secondo per il
volume del database. Ogni richiesta di scrittura viene prima scritta nel file di registro delle
transazioni e quindi nel database. Circa il 10% dei 1.500 IOPS totali, ovvero 150 IOPS,
inclusi nel volume del database verranno inclusi nel volume dei file di registro delle
transazioni, mentre 500 richieste di I/O di scrittura verranno scritte nel database.
I profili calcolati in questo modo sono validi per un server di Exchange in cui non sono
installati altri componenti oltre al sistema operativo di base. Se durante i periodi di maggiore
utilizzo sono in esecuzione altri programmi, ad esempio un software PIM (Personal
Information Management) di terze parti, un software antivirus MAPI (lato server e client), un
software di gestione e monitoraggio o un programma di backup, tali profili non saranno in
grado di descrivere adeguatamente il profilo di I/O dell'azienda. In questi casi sarà necessario
includere nei calcoli le operazioni di lettura e scrittura richieste da queste applicazioni.
21
IOPS database basato sul conteggio di cassette postali
IOPS database ogni 1000 cassette postali
Cassette postali
IOPS su volume
IOPS
IOPS effettivi
database
1000
1.0
1000
1000
2000
1.0
2000
2500
3000
1.0
3000
3750
4000
1.0
4000
5000
Quando si aumenta il numero di utenti con profili simili in Exchange Server, un numero
maggiore di utenti deve utilizzare la cache del database determinando un aumento dei
trasferimenti del disco del database.
Ad esempio:
1000 cassette postali a 1.0 IOPS producono 1000 IOPS nel numero LUN del database. Se si
raddoppia il numero di utenti con lo stesso profilo a 2000, la formula è: 1.0 IOPS x 2000
cassette postali x 1.25 = 2500 IOPS.
IOPS database basato sul conteggio di database
Database
Fattore IOPS
IOPS effettivi
1
0%
1000
2
2%
1020
4
6%
1060
8
14%
1140
10
18%
1180
20
38%
1380
I vantaggi dell'archiviazione dell'istanza singola si riducono se si aggiungono database a un
server di Exchange. Il grado dell'impatto dipende dal profilo utente e dalla media delle
dimensioni del messaggio. Ad esempio, se si dispone di 1000 utenti in 1 database, che
consumano 1000 IOPS database, dividendo gli utenti in 10 database si consuma il 18% in
più di IOPS database, o 1180 IOPS. Quando un utente invia un file PowerPoint di 10 MB in
allegato a 20 cassette postali che risiedono tutte nello stesso database, vengono scritti nel
database solo 10 MB. Se quegli stessi 20 destinatari si trovano su database diversi, sul
22
disco vengono scritti 200 MB; un aumento 20 volte maggiore nell'attività di scrittura. Questi
dati si basano sul test MMB3 che utilizza un numero significato di liste di distribuzione ed è
un profilo aziendale notevole.
Tipo utente
Modalità cache di
Modalità in linea
Dimensioni Posta in
Outlook
Outlook
arrivo
Azienda
1.0 IOPS
1.0 IOPS
10.000 voci – 500MB
Grande
1.0 IOPS
1.25 IOPS
20.000 voci – 1GB
Enorme
1.0 IOPS
1.75 IOPS
40.000 voci -2GB
Con la modalità cache di Outlook molte attività frequenti che richiedono un uso intensivo del
disco vengono eseguite sul client. La sincronizzazione completa iniziale in modalità cache di
Outlook è un'attività che richiede l'uso intensivo del disco, anche se viene raramente
eseguita. Con la modalità in linea di Outlook, le ricerche e gli ordinamenti vengono eseguiti
sul server. Dopo la creazione iniziale, l'indice viene automaticamente aggiornato quando
viene ricevuta la posta. Gli utenti che dispongono di un numero elevatissimo di indici possono
superare il limite, causando la nuova creazione di alcuni indici. Alcuni plug-in di Outlook e
applicazioni esterne creano indici e causano pressioni aggiuntive sul disco fisico. Quando si
passa da 500 MB a 1 GB, il costo del disco fisico del database aumenta di circa il 25%
mentre passando da 1 GB a 2 GB il costo del disco fisico del database aumenta di circa il
40%.
Calcolo delle operazioni di I/O tramite dati
dell'ambiente reale
Se la distribuzione di Exchange nell'azienda è già stata eseguita, si utilizzeranno i dati
dell'ambiente di produzione esistente per identificare i requisiti di I/O. Il monitoraggio
dell'ambiente di produzione offre il vantaggio di produrre dati che includono tutte le operazioni
di I/O che si verificano per tutte le applicazioni, comprese le applicazioni di terze parti.
Per calcolare il valore di IOPS per cassetta postale, è necessario utilizzare il numero di
cassette postali attualmente presenti sul server. Se sul server sono presenti numerose
cassette postali non utilizzate oppure vengono eseguite altre applicazioni che non generano
carico aggiuntivo durante il periodo di picco di due ore, i risultati ottenuti non
rappresenteranno un tipico carico di utenti. È quindi opportuno scegliere un server che
contenga cassette postali utente tipiche per le misurazioni da eseguire o che non contenga le
cassette postali inutilizzate nel calcolo.
Tenere in considerazione il fatto che in giorni diversi della settimana si possono riscontrare
carichi di utilizzo leggermente diversi. Poiché le differenze possono essere notevoli, si
23
consiglia di monitorare l'ambiente per un periodo di tempo prolungato, possibilmente per un
intero mese, in modo da determinare i periodi di picco più probabili.
Per la procedura dettagliata di calcolo dei requisiti di I/O per l'archiviazione utilizzando i dati
raccolti dall'ambiente di produzione di Exchange, vedere Modalità di calcolo dei requisiti delle
operazioni I/O utilizzando i dati ambientali.
Il valore di IOPS per cassetta postale si applica al livello del sistema operativo. Se è in
esecuzione una soluzione RAID hardware, si otterrà un numero di IOPS diverso a livello del
disco che non è possibile misurare con Perfmon. La penalità ottenuta con RAID-5, ad
esempio, è diversa da quella risultante da RAID-0+1. Per ulteriori informazioni sul calcolo del
valore di IOPS per ogni tipo di soluzione RAID, vedere Analisi delle prestazioni dei
sottosistemi di dischi per Windows all'indirizzo.
Dopo avere calcolato gli IOPS per valore di cassetta postale, è possibile ottimizzare
l'architettura di archiviazione esistente.
Modalità di calcolo dei requisiti delle
operazioni I/O utilizzando i dati ambientali
Se la distribuzione di Exchange nell'azienda è già stata eseguita, si utilizzeranno i dati
dell'ambiente di produzione esistente per identificare i requisiti di I/O. Il monitoraggio
dell'ambiente di produzione offre il vantaggio di produrre dati che includono tutte le operazioni
di I/O che si verificano per tutte le applicazioni, comprese le applicazioni di terze parti.
Per calcolare il valore di IOPS per cassetta postale, è necessario utilizzare il numero di
cassette postali attualmente presenti sul server. Se sul server sono presenti numerose
cassette postali non utilizzate oppure vengono eseguite altre applicazioni che non generano
carico aggiuntivo durante il periodo di picco di due ore, i risultati ottenuti non
rappresenteranno un tipico carico di utenti. È quindi opportuno scegliere un server che
contenga cassette postali utente tipiche per le misurazioni da eseguire o che non contenga le
cassette postali inutilizzate nel calcolo.
Informazioni preliminari
Tenere in considerazione il fatto che in giorni diversi della settimana si possono riscontrare
carichi di utilizzo leggermente diversi. Poiché le differenze possono essere notevoli, si
consiglia di monitorare l'ambiente per un periodo di tempo prolungato, possibilmente per un
intero mese, in modo da determinare i periodi di picco più probabili.
24
Procedura
Per calcolare i requisiti delle operazioni I/O utilizzando i dati ambientali
1. Identificare tre server di cassette postali di Exchange da utilizzare per raccogliere i
dati di riferimento relativi alle prestazioni. Scegliere server di fascia alta che
contengano le cassette postali degli utenti con i profili più alti. In questa procedura si
farà riferimento a tali server con il nome di ex2003base. Spesso a diversi siti
corrispondono diversi tipi di utenti. Talvolta risulta quindi utile raccogliere i dati di
profilo delle cassette postali per ogni sito e disporre di un profilo standard specifico
per ogni sito.
2. Monitorare i server ex2003base per un periodo di 24 ore il giorno in cui normalmente
si verifica un carico di picco, in genere il lunedì per numerose aziende. Nel giorno di
picco, avviare Perfmon su ogni server alle ore 4.00 del mattino e lasciarlo in
esecuzione per 24 ore.
3. Registrare i seguenti oggetti Perfmon (tutti i contatori, tutte le istanze) a intervalli di
15 secondi:

Disco logico

MSExchangeIS

Disco fisico

Processore
4. Compilare i seguenti dati dei server ex2003base:

Determinare la dimensione media delle cassette postali dei tre server
ex2003base. Per determinare le esigenze future relativamente alle prestazioni
del sistema di archiviazione, si utilizzerà la dimensione media della cassetta
postale.
Nota:
È necessario impostare un limite per le dimensioni delle cassette postali al
fine di calcolare adeguatamente il rapporto tra dimensioni dell'archivio e
prestazioni per una determinata base di utenti.

Determinare il numero di cassette postali presenti su ogni server ex2003base, in
modo da stabilire, durante il processo, il corretto carico di I/O medio per cassetta
postale su ciascun server.

Individuare i volumi del server ex2003base utilizzati per ogni funzione di
Exchange, come i file di registro delle transazioni, i database e le code MTA.
5. Analizzare individualmente ciascuno dei tre registri Perfmon raccolti al passaggio 3,
effettuando le seguenti operazioni per ogni registro:
25
a. In Perfmon aprire il registro Perfmon.
b. Aggiungere i seguenti contatori:

MSExchangeIS->Operazioni RPC al secondo

Disco logico->Trasferimenti disco/sec->Istanza=Lettera dell'unità che contiene il
database dell'archivio di Exchange. Aggiungere tutte le lettere di unità contenenti
file di database di Exchange.

Processore->% Tempo processore->Istanza=Totale
a. Impostare la scala in modo che tutti i contatori siano contenuti nell'asse X 0-100,
al fine di visualizzare le variazioni di un minuto di tutti i contatori. Passare alla
visualizzazione Grafico.
b. Analizzare i dati di Perfmon e identificare un periodo di un anno in cui i valori di
tutti e tre i contatori (Operazioni RPC al secondo, Trasferimenti disco/sec e
Processore) sono più alti. Dovrebbe essere visualizzata una finestra che mostra
un utilizzo elevato per periodi prolungati.
c.
Dopo aver visualizzato la finestra contenente i valori descritti al passaggio
precedente, ridurre la cronologia del registro Perfmon in base a tale finestra.
6. Dalla stessa finestra registrare i seguenti dati metrici (media) per ognuno dei server
ex2003base:

Operazioni RPC al secondo:

Trasferimenti disco/sec:

% Tempo processore:
7. Utilizzare questi dati per compilare il foglio di calcolo Server_Sizing.xls incluso nel
download della guida Ottimizzazione dell'archiviazione per Exchange Server 2003.
8. Identificare il server ex2003base in cui si è verificato il carico maggiore e utilizzare i
dati raccolti da tale server come riferimento per stabilire il rapporto
server/processore/archiviazione. Attenersi alle seguenti procedure consigliate:

Impostare sempre il sistema in modo che supporti il 20% in più dell'utilizzo
previsto per i picchi, al fine di consentire al sistema di archiviazione e ai
processori di gestirli durante i periodi di maggiore traffico.

I megacicli e i valori di IOPS per cassetta postale variano ogni volta che la
configurazione del server viene modificata. Nell'elenco seguente sono riportati i
potenziali fattori in grado di modificare i megacicli e i valori IOPS per cassetta
postale.

Variazione significativa delle dimensioni delle cassette postali

Variazione significativa della dimensione massima dei messaggi
26

Aggiunta o rimozione di applicazioni di terze parti

Aggiunta o rimozione di funzionalità di Exchange

Variazione della concorrenza media degli utenti (un numero maggiore o minore
di utenti in linea che utilizzano il sistema in un determinato intervallo di tempo)
9. Dopo avere compilato il foglio di calcolo (compreso nel download della guida
Ottimizzazione dell'archiviazione per Exchange Server 2003) e avere determinato i
profili delle cassette postali, è possibile progettare la soluzione di archiviazione. Se
ad esempio i risultati dell'analisi indicano che il profilo di cassette postali standard
corrisponde a 0,75 IOPS per cassetta postale e a 1,25 megacicli per cassetta
postale, sarà possibile determinare i seguenti requisiti per un server con 4.000
cassette postali:

Numero di cassette postali: 4,000

IOPS database picco: (4,000 × .75) = 3,000

IOPS registri picco: (IOPS database/10) = 300

Megacicli picco: (4.000 × 1,25) = 5.000 megacicli
Per gestire i picchi, è inoltre necessario aggiungere un buffer del 20% ai valori
calcolati per il processore e l'archivio. Con l'aggiunta di tale buffer, i requisiti
hardware minimi per l'esempio corrente sono:

Numero di cassette postali: 4,000

IOPS database picco: (3,000 + 20%) = 3,600

IOPS registri picco: (300 + 20%) = 360

Megacicli picco: (5.000 + 20%) = 6.000 megacicli
10. Per supportare tali requisiti, ogni server di cassette postali dovrebbe essere
configurato con almeno due processori da 3.000 mhz, 4 GB di RAM e un archivio in
grado di gestire 3.600 IOPS database casuali e 360 IOPS di operazioni di scrittura in
sequenza nei file di registro delle transazioni.
Nota:
I requisiti di memoria e di rete non sono inclusi nel calcolo. Per le applicazioni
Enterprise si consiglia di configurare i server di cassette postali di Exchange con
4 GB di memoria e con reti a 100 mbt Full Duplex o superiori.
Per ulteriori informazioni
Per ulteriori informazioni su come calcolare gli IOPS per ciascun tipo di soluzione RAID,
vedere Analisi delle prestazioni dei sottosistemi di dischi per Windows (informazioni in lingua
inglese).
27
Ottimizzazione dell'architettura di
archiviazione
Dopo aver calcolato il valore di IOPS per cassetta postale e aver determinato i requisiti di I/O,
si utilizzeranno le informazioni raccolte per ottimizzare l'architettura del sistema di
archiviazione. Indipendentemente dall'utilizzo di una soluzione di archiviazione DAS (DirectAttached Storage), SAN (Storage Area Network), NAS (Network-Attached Storage) o iSCSI
(Internet SCSI), sono disponibili numerose procedure ottimali da implementare. Inoltre,
poiché ogni soluzione di architettura di archiviazione è unica, sarà necessario eseguire
procedure specifiche per ottimizzare le prestazioni e l'affidabilità sulla base della soluzione
implementata nell'azienda.
Il concetto fondamentale presentato in questa sezione è l'importanza di separare i diversi
carichi di lavoro in assi fisici distinti. Di conseguenza i file di registro delle transazioni, che
generano operazioni di lettura e scrittura in sequenza, non dovranno trovarsi sugli stessi assi
fisici in cui sono memorizzati i file di database, che generano invece operazioni di lettura e
scrittura casuali. Allo stesso modo, i database di Exchange, che generano operazioni di
lettura e scrittura casuali, non dovranno mai trovarsi sugli stessi assi fisici in cui risiedono
altre applicazioni, come SQL Server.
Ottimizzazione di DAS
Il tipo di architettura DAS (Direct Attached Storage) rappresenta uno scenario comune nelle
distribuzioni di Exchange in aziende di piccole dimensioni. La maggior parte delle procedure
consigliate che si applica al DAS è comune ad altri scenari e quindi viene trattata
inProcedure consigliate comuni a più architetture. L'unica ulteriore procedura consigliata per
DAS consiste nell'implementazione della ridondanza per tutti i componenti del sistema di
archiviazione e per l'alimentatore, per prevenire possibili singoli punti di errore.
Ottimizzazione di reti SAN
Benché le reti SAN (Storage Area Network) costituiscano un'eccellente architettura di
archiviazione per Exchange, per ottimizzare affidabilità e prestazioni è necessario
implementare numerose procedure consigliate.
Per ottimizzare le reti SAN al fine di migliorare l'affidabilità, è necessario:

Configurare controller, switch SAN e assi.
Per ottimizzare le reti SAN al fine di migliorare le prestazioni, è necessario:

Dedicare assi fisici dell'architettura SAN ai database di Exchange. È consigliabile
dedicare un'intera rete SAN alle distribuzioni di Exchange di grandi dimensioni.
28

Nella pianificazione ignorare eventuali componenti ridondanti. È necessario considerare
le prestazioni anche in una situazione di failover.

Eseguire la pianificazione in modo tale che l'utilizzo massimo previsto non superi l'80% di
saturazione del sistema.

Configurare il sistema di archiviazione in modo che il canale sull'unità di archiviazione
supporti il valore di IOPS previsto calcolato in precedenza. Il carico di IOPS supportato
sul canale dipende dalle dimensioni della larghezza di banda. Se si dispone di più canali
e si prevede di configurarne uno come ridondante, escludere il canale ridondante dal
calcolo.

Verificare che il commutatore SAN supporti il carico di IOPS previsto, anche in una
situazione di failover. Tale commutatore infatti, poiché deve elaborare le richieste di I/O in
entrata ed inoltrarle attraverso la porta appropriata, limita la quantità di I/O che può
essere gestita.

Verificare che la scheda bus host (HBA) installato nel server supporti il carico di IOPS
previsto, anche in una situazione di failover. Per evitare limitazioni, assicurarsi che la
profondità della coda sia impostata in modo conforme ai suggerimenti del fornitore del
sistema di archiviazione.
Ottimizzazione di NAS (Network-Attached
Storage)
L'architettura NAS si è aggiunta di recente alle architetture supportate da Exchange 2003.
Tuttavia, per le organizzazioni Exchange 2003, si consiglia di implementare una soluzione
SAN (Storage Area Network) sopra una soluzione NAS. Se si decide di implementare
l'archiviazione NAS, assicurarsi di conoscere le procedure consigliate presentate in
Procedure consigliate comuni a più architetture. In seguito, per ottimizzare le prestazioni
della soluzione NAS, si potranno implementare le procedure specifiche illustrate in questa
sezione.
Nota:
Un utilizzo non corretto di Exchange 2003 con un prodotto NAS potrebbe provocare
la perdita di dati, inclusa una perdita totale dei file di database di Exchange. È
fondamentale che la soluzione NAS implementata con Exchange si trovi sul catalogo
di Windows Server. Inoltre, prima di distribuire qualsiasi soluzione per i database di
Exchange 2003, è essenziale ottenere dal fornitore del sistema di archiviazione la
conferma che la soluzione end-to-end sia progettata per l'utilizzo di Exchange 2003.
Poiché numerosi fornitori hanno sviluppato le proprie guide di "procedure consigliate"
per Exchange 2003, è consigliabile attenersi alla guida messa a disposizione dal
proprio fornitore. Per ulteriori informazioni sui criteri di supporto di Microsoft
sull'utilizzo delle soluzioni di archiviazione NAS specifiche per Exchange
Server 2003, vedere l'articolo 839687 della Microsoft Knowledge Base "Microsoft
29
support policy on the use of network-attached storage devices with Exchange
Server 2003".
Per ottimizzare NAS al fine di migliorare le prestazioni, è necessario:

Utilizzare una connessione di rete Gigabit per il collegamento al sistema NAS.

Verificare che la larghezza di banda di I/O, la latenza di I/O e l'utilizzo della CPU
necessari per eseguire una singola operazione di I/O siano in grado di supportare il
carico di IOPS calcolato in precedenza.

Verificare che la larghezza di banda della rete disponibile supporti il carico di IOPS
prodotto dagli utenti. È importante tenere presente che sulla CPU si possono verificare
valori di latenza e tempi di elaborazione superiori rispetto a quelli rilevati in un sistema di
archiviazione collegato in locale.
I contatori di prestazioni dei dischi fisici e logici non servono a misurare le prestazioni dei
dischi sui server di Exchange 2003 configurati per supportare soluzioni NAS (Network
Attached Storage). Le lettere di unità utilizzate per l'archiviazione dei file di registro e dei
database di Exchange 2003 non compaiono come dischi fisici o logici, bensì come lettere di
unità associate a una condivisione file di rete. Ulteriori contatori di prestazioni sono stati
aggiunti a Exchange 2003 Service Pack 1 per facilitare la misurazione di letture e scritture dei
registri e dei database. Questi contatori misurano solo le operazioni di I/O dei database ESE
(file EDB e LOG). Le prestazioni di ExIFS I/O (file STM) non vengono misurate. I contatori
sono esposti solo abilitando i contatori aggiuntivi ESE (Extensible Storage Engine).
Impostando "Mostra contatori avanzati" nel Registro di sistema, è possibile abilitare i seguenti
contatori di prestazioni estesi per Exchange 2003 Service Pack 1.

Database(Archivio informazioni)\Latenza anomala I/O letture database/sec

Database(Archivio informazioni)\I/O letture asincrone in sospeso database

Database(Archivio informazioni)\Media byte I/O letture database

Database(Archivio informazioni)\Latenza media I/O letture database

Database(Archivio informazioni)\I/O letture database in heap

Database(Archivio informazioni)\I/O letture database/sec

Database(Archivio informazioni)\Latenza anomala I/O scritture database/sec

Database(Archivio informazioni)\I/O scritture asincrone in sospeso database

Database(Archivio informazioni)\Media byte I/O scritture database

Database(Archivio informazioni)\Latenza media I/O scritture database

Database(Archivio informazioni)\I/O scritture database in heap

Database(Archivio informazioni)\I/O scritture database/sec

Database(Archivio informazioni)\Latenza anomala I/O letture registro/sec
30

Database(Archivio informazioni)\I/O letture asincrone in sospeso registro

Database(Archivio informazioni)\Media byte I/O letture registro

Database(Archivio informazioni)\Latenza media I/O letture registro

Database(Archivio informazioni)\I/O letture registro in heap

Database(Archivio informazioni)\I/O letture registro/sec

Database(Archivio informazioni)\Latenza anomala I/O scritture registro/sec

Database(Archivio informazioni)\I/O scritture asincrone in sospeso registro

Database(Archivio informazioni)\Media byte I/O scritture registro

Database(Archivio informazioni)\Latenza media I/O scritture registro

Database(Archivio informazioni)\I/O scritture registro in heap

Database(Archivio informazioni)\I/O scritture registro/sec
Per garantire le prestazioni del sistema di archiviazione NAS, è necessario abilitare i
contatori aggiuntivi riportati sopra. Per la procedura dettagliata di abilitazione di questi
contatori aggiuntivi, vedere Abilitazione dei contatori aggiuntivi ESE estesi. Le istruzioni
relative a ciascuno di questi contatori possono essere trovate utilizzando la funzionalità
Descrizione in System Monitor (Performance Monitor).
Ottimizzazione di iSCSI
iSCSI (Internet SCSI) è una tecnologia relativamente nuova che consente di memorizzare i
dati in remoto senza alcun impatto sulle prestazioni del sistema operativo. Di seguito sono
illustrate le procedure consigliate per l'ottimizzazione dell'affidabilità e delle prestazioni in una
soluzione di archiviazione iSCSI.
Per ottimizzare iSCSI al fine di migliorare l'affidabilità, è necessario:

Configurare controller, commutatori SAN, unità di archiviazione e assi ridondanti.

Utilizzare una rete Gigabit dedicata per il traffico iSCSI.
Per ottimizzare iSCSI al fine di migliorare le prestazioni, è necessario:

Contattare il fornitore della soluzione di archiviazione SAN per ottenere eventuali
indicazioni speciali sulle prestazioni e la configurazione.

Eseguire un test per verificare che la latenza del traffico iSCSI osservata sotto pieno
carico del server (per requisiti IOPS) soddisfi le proprie esigenze.

Utilizzare una rete Gigabit Ethernet. È infatti possibile migliorare le prestazioni di iSCSI
utilizzando commutatori e cavi Gigabit Ethernet, oltre a chip iSCSI o HBA su cui
distribuire il carico di elaborazione del protocollo TCP/IP.
31

Utilizzare l'interfaccia della riga di comando di iSCSI (ISCSICLI) per configurare una
destinazione di accesso permanente oppure lo strumento del Pannello di controllo iSCSI
Initiator per rendere i volumi permanenti.

Utilizzare il comando ISCSICLI per eseguire il binding dei volumi persistenti oppure lo
strumento del Pannello di controllo iSCSI Initiator per consentire al servizio iSCSI di
configurare l'elenco di volumi permanenti.
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 negli strumenti di supporto di
Windows Server 2003 Service Pack 1 che può esplicitamente impostare l'offset iniziale nel
record di avvio principale (MBR, 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.
Informazioni preliminari
Diskpart è un utilità che provoca la distruzione di dati. Se utilizzata per un disco, tutti i dati
presenti su di esso vengono eliminati durante il processo di allineamento dei limiti delle
tracce di archiviazione. Pertanto, se il disco su cui viene eseguito Diskpart contiene dei dati,
eseguire il backup dei dati prima di avviare la seguente procedura.
Nota:
Diskpart può essere utilizzato solo con dischi in modalità di base. Non può essere
utilizzato con dischi dinamici. Diskpart sostituisce la funzionalità precedentemente
disponibile in Diskpar.exe. Diskpar e Diskpart devono essere utilizzati solo se l'unità
è convertita in 64 settori per traccia.
Diskpart.exe per impostazione predefinita è situato nella directory seguente sui sistemi che
eseguono Windows Server 2003 : C:\WINDOWS\system32
32
Procedura
Per allineare I/O di Exchange con limiti delle tracce di archiviazione utilizzando
Diskpart.exe
1. Se il disco di cui si sta eseguendo l'allineamento è già vuoto, procedere al Passaggio
3. Se sono presenti dati, eseguire il backup prima di procedere.
2. Eliminare tutte le partizioni del disco.
3. Aprire un prompt dei comandi ed eseguire Diskpart.exe.
4. Nel prompt dei comandi di Diskpart digitare Dischi elenco e premere Invio. Se il
disco da allineare non è visualizzato nell'elenco, assicurarsi che sia presente e
accessibile utilizzando lo snap-in Gestione disco.
5. Al prompt dei comandi Diskpart digitare Select Disk X, dove X corrisponde al
numero del disco come visualizzato nel risultato del comando Disco elenco.
Diskpart restituisce un messaggio in cui viene indicato che il disco X è quello
selezionato.
6. Al prompt dei comandi Diskpart digitare Create Partition Primary Align=X, dove X
corrisponde a 32 o 64, a seconda dei suggerimenti offerti dal fornitore dei sistemi di
archiviazione. In mancanza di particolari suggerimenti, si consiglia di utilizzare 64.
7. Al prompt dei comandi di Diskpart digitare Assign Letter=<Letteraunità>. Ad
esempio, per assegnare la lettera Z al disco, digitare Assign Letter=Z.
8. Una volta assegnata la lettera all'unità, digitare exit per uscire dall'utilità Diskpart.
9. Utilizzare lo snap-in Gestione disco o il comando Formatta di Windows per formattare
la partizione come NTFS.
Abilitazione dei contatori aggiuntivi ESE
estesi
Le lettere di unità utilizzate per l'archiviazione dei file di registro e dei database di
Exchange 2003 non compaiono come dischi fisici o logici, bensì come lettere di unità
associate a una condivisione file di rete. Per misurare le prestazioni del sistema di
archiviazione NAS, è necessario attivare i contatori di prestazioni ESE disponibili in
Exchange 2003 Service Pack 1 (SP1) e versioni successive.
33
Informazioni preliminari
Questo argomento contiene informazioni sulla modifica del Registro di sistema.
Attenzione
La modifica non corretta del Registro di sistema può causare gravi problemi che
potrebbero richiedere la reinstallazione del sistema operativo. È possibile che tali
problemi non possano essere risolti. Prima di apportare modifiche al Registro di
sistema, eseguire il backup di tutti i dati importanti.
Procedura
Per abilitare i contatori di prestazioni ESE estesi
1. Aprire l'editor del Registro di sistema.
2. Passare a HKLM\SYSTEM\CurrentControlSet\Services\ESE\Performance.
3. Fare clic con il pulsante destro del mouse su Prestazioni e selezionare Nuovo |
Valore DWORD.
4. Assegnare il nome al nuovo valore DWORD Show Advanced Counters.
5. Fare doppio clic su Show Advanced Counters.
6. Nel campo Dati valore immettere 1.
7. Chiudere l'editor del Registro di sistema
Per ulteriori informazioni
Per informazioni sulla modifica del Registro di sistema, vedere l'articolo 256986 della
Microsoft Knowledge Base "Description of the Microsoft Windows Registry.
Procedure consigliate comuni a più
architetture
Prima di concentrarsi sulle procedure specifiche dell'architettura di archiviazione
implementata nella propria azienda, è utile apprendere le procedure ottimali valide per
diverse architetture. Indipendentemente dall'architettura implementata, è necessario
considerare i seguenti componenti:

Dischi rigidi

Cache di memoria
34

Controller dispositivi di archiviazione

Motori di rotazione

RAID

Bus

Scheda SCSI

Alimentatore
Essendo l'argomento che suscita maggiore interesse, l'ottimizzazione dei dischi rigidi verrà
illustrata per prima. In generale, sono valide le seguenti procedure consigliate:

La pianificazione della capacità è un aspetto importante della pianificazione del sistema
di archiviazione. Per ottimizzare le prestazioni dei server di Exchange, è necessario
acquistare numerosi dischi a velocità di accesso elevata. Per ulteriori informazioni sulla
pianificazione della capacità di archiviazione, vedere "Planning Storage for Each Server
Configuration" nella Guida alla distribuzione di Exchange Server 2003.

Per i volumi dei registri delle transazioni, con accesso al disco sequenziale, utilizzare
dischi con velocità di rotazione superiori. Per i volumi di database, con accesso al disco
casuale, utilizzare dischi con tempi di ricerca più rapidi.

Utilizzare sistemi di dischi in grado di rilevare errori imminenti e di recuperare o riallocare
i dati danneggiati. La maggior parte delle unità disco supporta questa funzionalità.

Pianificare le penalità di I/O in base alla configurazione RAID hardware in uso. In
generale, per ogni richiesta di scrittura, il RAID hardware genera il seguente carico di I/O:

RAID-0 = 1 operazione di scrittura

RAID-1 o RAID-10 = 2 operazioni di scrittura

RAID-5 = 4 operazioni di scrittura
Utilizzare la seguente formula per calcolare la penalità di I/O:
(IOPS/cassetta postale × RAPPORTO LETTURA)+ ((IOPS/cassetta postale ×
RAPPORTO SCRITTURA) ×penalità RAID)
Se ad esempio si dispone di 1.500 IOPS per cassetta postale, calcolati seguendo le
procedure descritte in precedenza, di un rapporto di lettura pari a 66%/33% (due richieste
su tre sono richieste di lettura mentre la richiesta rimanente è una richiesta di scrittura) e
di un array RAID-1 o RAID-10, il valore di IOPS hardware effettivo sarà:
(1.500 × 2/3) + ((1.500 × 1/3) × 2) = 2.000
Applicando lo stesso scenario a un array RAID-5, il valore di IOPS hardware effettivo
sarà:
(1.500 × 2/3) + ((1.500 × 1/3) × 4) = 3.000
35
Se tutte le unità hanno una velocità di rotazione pari a 10.000 RPM, saranno necessarie
almeno 30 unità per ottenere il valore di IOPS richiesto in una configurazione RAID-5.
Una configurazione RAID-1 o RAID-10 richiederà invece almeno 20 unità (le soluzioni
RAID-1 o RAID-10 non supportano un numero dispari di dischi).

Nella maggior parte dei casi, sarà necessario utilizzare DiskPar per allineare le tracce del
disco rigido con la partizione del disco fisico. Poiché in Windows 2000 e Windows
Server 2003 il numero massimo di settori nascosti è limitato a 63, il settore iniziale
predefinito per i dischi con oltre 63 settori è il sessantaquattresimo settore. Tutte le
partizioni create da Windows 2000 e Windows Server 2003 iniziano quindi dal
sessantaquattresimo settore e causano la scrittura sul disco di un blocco di dati ogni otto
blocchi in modo da occupare due tracce del disco. Per la procedura dettagliata, vedere
"Allineamento delle operazioni di I/O di Exchange ai limiti delle tracce di archiviazione" in
Exchange Server 2003 Performance and Scalability Guide. Diskpart può essere utilizzato
solo con i dischi di base. Non può essere utilizzato con dischi dinamici.
Nella seguente tabella sono descritte le procedure consigliate per ciascuno dei restanti
componenti del sistema di archiviazione.
36
Procedure consigliate per l'ottimizzazione dei componenti comuni del sistema di
archiviazione
Componente
Procedura consigliata

Poiché la cache di memoria su disco
aumenta man mano che la memoria fisica
diminuisce, assicurarsi che sia disponibile
una quantità di memoria sufficiente. Quando
infatti la memoria è insufficiente, sul disco
viene scritto un numero maggiore di pagine,
con un conseguente incremento dell'attività
del disco. Per ulteriori informazioni
sull'ottimizzazione della memoria virtuale,
vedere l’articolo 815372 della Microsoft
Knowledge Base "How to optimize memory
usage in Exchange Server 2003".
Cache di memoria
Assicurarsi inoltre che le dimensioni del file di
paging siano appropriate. Per ulteriori
informazioni sull'impostazione del file di
paging, vedere "Evaluating Memory and
Cache Usage" in the Microsoft Windows
2000 Resource Kit.
Una maggiore quantità di cache può essere
utile per gestire i picchi nelle richieste di I/O
del disco. È tuttavia importante sottolineare
che l'incremento della cache raramente
risolve il problema derivante dal numero
insufficiente di assi, mentre disporre di un
numero adeguato di assi può rendere
superflua l'implementazione di una cache di
grandi dimensioni.
37
Componente
Procedura consigliata

Se si dispone di una cache con supporto
batteria, attivare la cache in scrittura per
migliorare le prestazioni delle operazioni di
scrittura su disco sui volumi dei registri delle
transazioni e dei database. La cache in
scrittura offre un tempo di risposta di 2 ms
per una richiesta di I/O di scrittura, rispetto ai
10-20 ms altrimenti necessari. L'attivazione di
questa funzionalità migliora quindi
notevolmente la velocità di risposta per ogni
invio eseguito da un client.
Controller dispositivi di archiviazione
La cache in lettura non offre invece
miglioramenti alle prestazioni poiché è utile
solo nelle operazioni di lettura sequenziali su
disco, che si verificano esclusivamente nei
file di registro delle transazioni. i quali
vengono letti soltanto durante la riproduzione,
ad esempio dopo il ripristino di un database o
quando un server non viene arrestato
correttamente.
Le cache di dimensioni maggiori consentono
un buffer di un maggior numero di dati e
supportano pertanto periodi di saturazione
più estesi.
Se il controller in uso consente di configurare
la dimensione delle pagine nella cache, si
consiglia di impostarla su 4 KB. Una
dimensione maggiore, ad esempio 8 KB,
dimezzerebbe la quantità di cache
disponibile, poiché una richiesta di I/O di
4 KB occupa l'intera pagina in cache di 8 KB.
38
Componente
Procedura consigliata

I assi hanno un'importanza maggiore rispetto
alla capacità. Sono infatti in grado di
migliorare le prestazioni di Exchange se
supportano un numero elevato di richieste di
I/O casuali.
Motori di rotazione
Se si utilizza Raid-1+0, è possibile calcolare il
numero di assi applicando la seguente
formula e arrotondando il risultato al
successivo numero pari:
1,25 × [(Cassette postali × IOPS per
cassetta postale / IOPS per asse) + % I/O
lettura] / [% I/O lettura + (% I/O scrittura/
2)] = assi
Questa formula si basa sulla pianificazione di
non oltre l'80% dell'utilizzo globale e sulla
disponibilità di un carico di I/O sufficiente,
anche in caso di malfunzionamenti di un
asse.

RAID
La soluzione RAID in uso deve essere basata
sul compromesso tra costi e prestazioni
appropriato per l'azienda. Di conseguenza, in
molti casi può essere opportuno disporre di
più di un tipo di soluzione RAID per
soddisfare determinate esigenze di
archiviazione dei dati. Di seguito sono
riportati alcuni suggerimenti generali:

Utilizzare Raid-1+0 per i volumi dei
registri delle transazioni, i volumi dei
database e le code SMTP.

Utilizzare Raid-1 per i volumi dei registri
delle transazioni, le code SMTP e le code
MTA.

In generale, Raid-5 non offre il migliore
compromesso tra affidabilità/disponibilità
e prestazioni.

Raid-0 non è mai consigliato.
39
Componente
Procedura consigliata

Come già accennato, una velocità di
trasmissione dei dati più elevata si traduce in
un miglioramento delle prestazioni. . In
generale, i bus SCSI offrono migliore velocità
di trasmissione e migliore scalabilità rispetto
ai bus IDE o ATA.
Bus
Per determinare il limite teorico di velocità di
trasmissione del bus, è possibile utilizzare la
seguente equazione:
(Velocità bus (in bit) / 8 bit per byte) ×
Velocità sistema operativo (in MHz) =
Velocità di trasmissione (in MB/s)
È inoltre possibile migliorare le prestazioni
posizionando più unità su bus di I/O distinti.

Schede SCSI

Come già accennato, una velocità di
trasmissione dei dati più elevata si
traduce in un miglioramento delle
prestazioni. Utilizzare le specifiche del
produttore per determinare il carico di I/O
supportato dalla scheda in uso, tenendo
presente che una parte delle operazioni
di elaborazione svolte dalla scheda è
dedicata all'indirizzamento delle richieste
di I/O alla periferica appropriata.
Procedure consigliate per architetture
specifiche
Oltre a implementare le procedure consigliate valide per tutte le architetture di archiviazione,
è opportuno conoscere anche i vantaggi, gli svantaggi e le procedure consigliate specifici di
ogni tipo di architettura. Nella seguente tabella sono illustrati questi tipi di architetture, con i
relativi vantaggi e svantaggi.
40
Architetture di archiviazione e relativi vantaggi e svantaggi
Architettura di archiviazione
Vantaggi
Svantaggi
DAS (Direct-Attached
Storage)

Costi contenuti


Adatta per configurazioni
di piccole e medie
dimensioni
Costi di gestione più
elevati

Scarsa scalabilità

Prestazioni elevate in
caso di utilizzo di un
controller RAID su un bus
PCI o una scheda Ultra-3
SCSI
41
Architettura di archiviazione
Vantaggi
Svantaggi
SAN (Storage Area Network)


Costi elevati, benché in
miglioramento

Soluzione complessa,
poiché richiede un
esperto in archiviazione
con specifiche
conoscenze delle reti
SAN

Deve essere configurata
correttamente per evitare
problemi di affidabilità
Possibilità di aggiungere
dinamicamente spazio di
archiviazione

Buona compatibilità con i
cluster

Prestazioni elevate
adatte ai datacenter e
alle infrastrutture di
grandi dimensioni

Supporto di istantanee,
cloni e snapclone, che
consentono la gestione di
database anche di
dimensioni molto elevate

Possibilità di mirroring dei
dati su un array JBOD
(Just a Bunch of Disks)
dai costi contenuti

Possibilità di raggruppare
in un'unica unità prodotti
di archiviazione di
fornitori diversi

Possibilità di condividere
lo spazio di archiviazione
su una rete dove può
essere condiviso e
facilmente distribuito

Possibilità di spostare le
risorse da un server a un
altro in base alle
necessità
42
Architettura di archiviazione
Vantaggi
Svantaggi
NAS (Network Attached
Storage)
Costi contenuti

Richiede un driver in
modalità blocco per
Exchange 2000, difficile
da recuperare

Potrebbe non essere
supportata sul catalogo di
Windows Server

Richiede l'intervento del
provider del sistema di
archiviazione, che in uno
scenario di ripristino può
risultare dispendioso in
termini di tempo

Scarsa scalabilità

Supporta solo 1.500
utenti per periferica

Supporta solo due server
di Exchange per
periferica collegata in
rete, consentendo quindi
solo l'implementazione di
cluster non superiori a
due nodi

Richiede Exchange 2003
su Windows Server 2003

Non supporta
l'infrastruttura del servizio
Copia Shadow del
volume per le istantanee
43
Architettura di archiviazione
Vantaggi
Svantaggi
iSCSI (Internet SCSI)

Costi più contenuti
rispetto alle reti SAN

Possibilità di
trasmissione dei dati
tramite LAN, WAN e
Internet a posizioni di
archiviazione remote
È consigliabile disporre di
una scheda di rete Gigabit
iSCSI dedicata che separi il
traffico di rete dal traffico del
sistema di archiviazione

I dischi rigidi iSCSI
appaiono collegati
direttamente al server
Per ogni tipo di architettura di archiviazione, è necessario utilizzare il valore di IOPS per
cassetta postale calcolato in precedenza allo scopo di:

Ottimizzare le prestazioni.

Ottimizzare l'affidabilità.
Utilizzo di driver Storport invece di driver
SCSIPort

Il driver Storport, una nuova funzionalità disponibile in Microsoft® Windows Server™
2003, offre prestazioni eccellenti in ambienti hardware RAID e SAN rispetto al driver
SCSIport preesistente.
Nel sistema operativo Microsoft® Windows® il driver SCSIport, in combinazione con driver
miniport specifici per adattatore e creati dal fornitore, è stato per molto tempo il solo driver in
condizioni di fornire comandi SCSI per i gruppi di archiviazione di destinazione. Tuttavia, il
driver SCSIport è stato progettato per funzionare perfettamente con le interconnessioni SCSI
parallele utilizzate con le soluzioni DAS (Direct Attached Storage). Non è stato progettato
per soddisfare gli elevati standard delle prestazioni delle configurazioni SAN Fibre Channel
né con l'hardware RAID.
Pertanto, le organizzazioni che eseguono applicazioni Windows importanti sui server non
ottengono i vantaggi e la gestibilità delle reti SAN Fibre Channel o delle schede hardware
RAID (sull'host e sugli array di archiviazione) quando le operazioni di I/O vengono eseguite
tra l'host e la soluzione di archiviazione di destinazione.
Queste limitazioni sono state superate grazie allo sviluppo di Storport, il nuovo driver per
periferica progettato per il supporto di SCSIport per Windows Server 2003 e versioni
successive. Storport è un nuovo driver per porte che consente prestazioni di I/O superiori,
possibilità di gestione avanzata e un'interfaccia miniport migliorata. La combinazione di
44
queste modifiche consente ai fornitori di hardware di raggiungere gli obiettivi di
interconnessione ad alte prestazioni.
Per ulteriori informazioni sul driver Storport, vedere
http://www.microsoft.com/WindowsServer2003/technologies/storage/storport/default.mspx.
Ulteriori considerazioni sulla progettazione
Oltre al carico previsto di I/O relativo a Exchange, nell'ambiente di produzione possono
esistere diverse circostanze in grado di influire sui requisiti di archiviazione, come quelle
elencate di seguito:

Replica dei dati

Clustering

Cluster dislocati geograficamente

Backup e ripristino
Nella seguente tabella sono riportate le considerazioni relative a ognuna di queste
circostanze.
45
Circostanze che influiscono sui requisiti di archiviazione
Circostanza
Considerazioni
46
Circostanza
Considerazioni
Replica dei dati
Poiché i dati vengono replicati in una
posizione remota, nella progettazione del
sistema di archiviazione è necessario
includere i collegamenti di comunicazione e i
requisiti di archiviazione per la postazione
remota. Per utilizzare i dati replicati per
eseguire un ripristino di emergenza, è
necessario replicare i file di registro delle
transazioni, il file del punto di arresto e i
volumi dei database, nonché mantenere
sincronizzati tutti i set di unità.
Per la replica sincrona, il commit dei dati
deve essere eseguito nella posizione remota
prima di essere eseguito sui dischi rigidi. Di
conseguenza, le prestazioni del collegamento
di comunicazione e del sistema di
archiviazione della postazione remota
rivestono un'importanza fondamentale. Se la
sincronizzazione attraverso il collegamento è
lenta, il server considererà prioritarie le
esigenze di sincronizzazione a discapito delle
richieste degli utenti, rallentando pertanto i
tempi di risposta degli utenti.
Per la replica asincrona, ogni replica è in
genere non sincronizzata. Come accade con
la replica sincrona, quando la replica
asincrona è troppo lenta, si rende necessario
dare priorità all'operazione di replica piuttosto
che alle prestazioni dell'applicazione, con un
conseguente rallentamento dei tempi di
risposta degli utenti.
Importante:
È necessario utilizzare solo servizi e
driver di software qualificato o fornito
da Microsoft, nonché sistemi
hardware che siano stati approvati
dai laboratori Microsoft per il controllo
della qualità dell'hardware per
Windows (WHWL, Windows
Hardware Quality Labs) e abbiano
ricevuto il logo "Designed for
Windows". Inoltre, per Exchange,
una piattaforma completamente
supportata da Microsoft utilizza solo
servizi e componenti nativi di
47
Circostanza
Considerazioni
Clustering
Solamente le soluzioni cluster complete
presenti nel Microsoft Windows Server
Cluster Catalog (noto in precedenza come
elenco HCL) saranno supportate da
Microsoft. I cluster non possono infatti essere
costruiti arbitrariamente da componenti a
livello di periferica (inclusi componenti quali i
controller RAID e i dispositivi a più cluster
qualificati come componenti cluster) e
collegati in una configurazione supportata.
Poiché i cluster di tipo attivo/attivo sono
soggetti a limitazioni relativamente alla
memoria virtuale e al numero di utenti per
nodo, è opportuno non implementare il
clustering di tipo attivo/attivo.
I nodi attivi e passivi accedono ai dati di
Exchange memorizzati in array SCSI, Fibre
Channel o iSCSI condivisi. Di conseguenza,
in un cluster di tipo attivo/passivo a due nodi,
l'implementazione dei nodi passivi non
richiede ulteriori considerazioni
sull'archiviazione. Se si dispone di più nodi
attivi, è necessario configurare il sistema di
archiviazione in modo che ogni server
virtuale di Exchange possa accedere solo ai
propri dati.
48
Circostanza
Considerazioni
Cluster dislocati geograficamente
Analogamente alle soluzioni di clustering,
l'hardware e il software in uso devono essere
certificarti ed elencati nel catalogo di
Windows Server. È tuttavia necessario tenere
presente che, per il corretto funzionamento
dei cluster dislocati geograficamente,
potrebbe essere necessario installare driver e
software di terze parti.
Poiché i dati dei cluster di questo tipo
vengono replicati attraverso un collegamento
WAN, sono valide le stesse considerazioni
relative alla replica dei dati, riportate in
precedenza in questa tabella.
Inoltre, per fornire un adeguato failover, è
necessario configurare almeno un array di
archiviazione in ogni sito. I nodi di cluster
dovranno essere connessi al sottosistema di
archiviazione in modo tale che, in caso di
malfunzionamento di un sito o di problemi di
comunicazione tra siti, i nodi funzionanti
possano continuare a connettersi al sistema
di archiviazione sul proprio sito.
49
Circostanza
Considerazioni
Backup
Il processo di backup dei dati richiede la
lettura dei dati dai volumi dei database e dei
file di registro delle transazioni. Questo
ulteriore carico di I/O potrebbe rallentare i
tempi di risposta degli utenti e dovrebbe
pertanto essere evitato durante gli orari
lavorativi.
Il processo di ripristino software richiede che
Jet riproduca tutti i file di registro delle
transazioni. Di conseguenza, poiché il profilo
di I/O risultante è un flusso di lettura in
sequenza, le prestazioni del processo di
ripristino miglioreranno se i file di registro
delle transazioni vengono posizionati su un
disco con elevata velocità di accesso
sequenziale.
Exchange supporta inoltre il servizio Copia
shadow del volume per Windows
Server 2003. Per ottimizzare il sistema di
archiviazione per le prestazioni di tale
servizio, è necessario:

Installare il pacchetto di aggiornamento
del servizio Copia shadow del volume.
Per ulteriori informazioni
sull'aggiornamento, vedere l'articolo
833167 della Microsoft Knowledge Base
"A Volume Shadow Copy Service update
package is available for Windows
Server 2003".

Verificare che il controller in uso supporti
la velocità di trasmissione del servizio
Copia Shadow del volume dal volume di
origine alla copia shadow del volume.

Spostare la copia shadow sul dispositivo
dei backup utilizzando una rete SAN, una
LAN dedicata o un server di backup
separato che possa essere utilizzato per
il backup su nastro. In altre parole,
eseguire il backup da un disco all'altro,
quindi trasferire il backup su nastro in un
momento opportuno.
50
Utilizzo di Jetstress per verificare le
prestazioni del sistema di archiviazione
Dopo aver valutato i requisiti di I/O e avere ottimizzato il sottosistema di dischi in base alle
procedure consigliate specifiche dell'architettura di archiviazione implementata, occorrerà
verificare che le prestazioni del disco siano in linea con le proprie aspettative prima di
procedere alla configurazione in un ambiente di produzione. A tale scopo, è possibile
eseguire lo strumento Jetstress sul sistema di archiviazione in un ambiente di test.
Per scaricare Jetstress e la relativa documentazione sull'installazione e l'utilizzo, vedere il
sito Web Downloads for Exchange 2003 (informazioni in lingua inglese).
Con Jetstress è possibile verificare le prestazioni dei dischi simulando il carico di I/O dei
dischi di Exchange. Vengono infatti simulati i carichi dei file di database e di registro di
Exchange generati da un determinato numero di utenti. System Monitor, Visualizzatore eventi
e le utilità database di Exchange Server vengono utilizzati con Jetstress per verificare che il
sottosistema di dischi in uso soddisfi o superi i criteri stabiliti per le prestazioni (latenza
minima accettabile sotto il carico di IOPS per cassetta postale).
Con Jetstress è possibile eseguire due tipi di test:

Con Jetstress Disk Performance Test, la cui durata di esecuzione è pari a 2 ore, è
possibile verificare le prestazioni e le dimensioni della soluzione di archiviazione e
calcolare il limite di saturazione dell'unità. Queste informazioni potranno poi essere
utilizzate per verificare che il sistema di archiviazione sia in grado di offrire prestazioni
accettabili anche sotto pieno carico.

Con Jetstress Disk Subsystem Stress Test, la cui durata di esecuzione è pari a 24 ore, è
possibile verificare il carico del server utilizzando carichi maggiori in un intervallo di
tempo più significativo, in modo da stabilire se, sotto un carico eccessivo, si
verificheranno errori nel funzionamento del sistema di archiviazione.
L'esecuzione di entrambi i test è il modo migliore per verificare le prestazioni del sottosistema
di dischi.
Dopo aver completato i test in un ambiente di prova, sarà possibile implementare la
soluzione di archiviazione nell'ambiente di produzione. Jetstress non deve mai essere
eseguito su un server di produzione.
Nota:
Oltre a Jetstress, un altro strumento comunemente utilizzato per valutare le
prestazioni del sistema di archiviazione è Load Simulator 2003 (LoadSim). Tuttavia,
LoadSim non è in grado di verificare tutti i fattori che interessano la valutazione delle
dimensioni dei server e non offre quindi una rappresentazione esaustiva
51
dell'ambiente utente reale. Per valutare le prestazioni del sistema di archiviazione, si
consiglia pertanto di utilizzare Jetstress.
Conclusione e ulteriori informazioni
Un sistema di archiviazione ottimizzato rappresenta un fattore fondamentale per le
prestazioni di Exchange 2003. Dopo aver compreso le cause delle operazioni di I/O del disco
di Exchange, le modalità di calcolo dei requisiti di I/O del disco e le procedure disponibili per
ottimizzare l'architettura di archiviazione implementata e per verificare le prestazioni del
sistema di archiviazione, sarà possibile implementare tali procedure nell'ambiente di
produzione.

Per informazioni sui concetti di archiviazione di Windows e su come calcolare gli IOPS
per ciascun tipo di soluzione RAID, vedere Disk Subsystem Performance Analysis for
Windows.

Per ulteriori informazioni sull'architettura di Exchange, inclusi i gruppi di archiviazione, i
database (archivi) e i file di registro delle transazioni, vedere "Gestione degli archivi di
cassette postali e cartelle pubbliche" in Exchange Server 2003 Administration Guide.

Per informazioni dettagliate sulle prestazioni e la scalabilità di Windows Server 2003 ed
Exchange 2003, vedere il Manuale sulle prestazioni e la scalabilità di Exchange
Server 2003 in http://go.microsoft.com/fwlink/?LinkId=28660.

Per ulteriori informazioni sulla pianificazione della capacità di archiviazione, vedere
"Planning Storage for Each Server Configuration" nella Guida alla distribuzione di
Exchange Server 2003.

Per ulteriori informazioni su Diskpar.exe, vedere la Guida in linea di Microsoft
Windows 2000 Resource Kit Tools.

Per ulteriori informazioni sull'ottimizzazione del file di paging, vedere "Evaluating Memory
and Cache Usage" in Microsoft Windows 2000 Resource Kit.

Per scaricare Jetstress e la relativa documentazione sull'installazione e l'utilizzo, vedere il
sito Web Downloads for Exchange 2003 (informazioni in lingua inglese).

Per verificare che l'hardware Windows Cluster in uso sia presente nel catalogo di
Windows Server, vedere "Cluster Solutions" nel catalogo di Windows Server.

Per ulteriori informazioni sulla struttura dell'agente di trasferimento messaggi MTA,
vedere l’articolo 282780 della Microsoft Knowledge Base "MTA Database Format and
Structure".

Per ulteriori informazioni sull'ottimizzazione della memoria virtuale, vedere l’articolo
815372 della Microsoft Knowledge Base "How to optimize memory usage in Exchange
Server 2003".
52

Per ulteriori informazioni sui criteri di supporto di Microsoft per l'utilizzo delle soluzioni di
archiviazione NAS specifiche per Exchange Server 2003, vedere l'articolo 839687 della
Microsoft Knowledge Base "Microsoft support policy on the use of network-attached
storage devices with Exchange Server 2003".

Per ulteriori informazioni sull'installazione del pacchetto di aggiornamento del servizio
Copia Shadow del volume, vedere l'articolo 833167 della Microsoft Knowledge Base "A
Volume Shadow Copy Service update package is available for Windows Server 2003".

Per ulteriori informazioni sull'utilizzo di Eseutil.exe, vedere l'articolo 825088 della
Microsoft Knowledge Base "How To: Use the Eseutil Utility to Detect File Header
Damage in Exchange 2003".

Per ulteriori informazioni sul criterio di supporto delle soluzioni software di archiviazione
di terze parti per Microsoft, vedere l'articolo 841696 della Microsoft Knowledge Base
"Overview of the Microsoft third-party storage software solutions support policy".
Copyright
Le informazioni contenute nel presente documento rappresentano l'attuale visione di
Microsoft Corporation relativa alle questioni discusse fino al giorno di pubblicazione. Poiché
Microsoft deve reagire a condizioni di mercato mutevoli, queste informazioni non devono
essere interpretate come un impegno da parte di Microsoft, inoltre Microsoft non può
garantire l'accuratezza di alcuna delle informazioni presentate dopo la data di pubblicazione.
Questo White Paper è di natura esclusivamente informativa. MICROSOFT NON
GARANTISCE IN ALCUN MODO, ESPRESSO, IMPLICITO O A TERMINI DI LEGGE, LE
INFORMAZIONI CONTENUTE NEL PRESENTE DOCUMENTO.
Il rispetto di tutte le applicabili leggi in materia di copyright è esclusivamente a carico
dell'utente. Fermi restando tutti i diritti coperti da copyright, nessuna parte di questo
documento potrà comunque essere riprodotta o inserita in un sistema di riproduzione o
trasmessa in qualsiasi forma e con qualsiasi mezzo (in formato elettronico, meccanico, su
fotocopia, come registrazione o altro) per qualsiasi scopo, senza il permesso scritto di
Microsoft Corporation.
Microsoft può essere titolare di brevetti, domande di brevetto, marchi, copyright o altri diritti di
proprietà intellettuale relativi all'oggetto del presente documento. Salvo quanto
espressamente previsto in un contratto scritto di licenza Microsoft, la consegna del presente
documento non implica la concessione di alcuna licenza su tali brevetti, marchi, copyright o
altra proprietà intellettuale.
Se non specificato diversamente, le società, i prodotti, i nomi di dominio, gli indirizzi e-mail, i
logo, i nomi, i luoghi e gli eventi utilizzati nelle riproduzioni delle schermate e negli esempi
sono fittizi. Ogni riferimento a società, prodotti, nomi di dominio, indirizzi e-mail, logo, nomi,
luoghi ed eventi è puramente casuale.
53
© 2006 Microsoft Corporation. Tutti i diritti riservati.
Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory,
ActiveSync, ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN,
MSN, Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile,
Windows NT e Windows Server System sono marchi o marchi registrati di Microsoft
Corporation negli Stati Uniti e/o negli altri paesi.
Tutti gli altri marchi appartengono ai rispettivi proprietari.