Progettazione dell'archiviazione dei server Trasporto

 

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2009-01-26

I server Trasporto Edge e Trasporto Hub sono ruoli del server che vengono utilizzati per i seguenti tipi di recapito:

• Posta in arrivo e in uscita dall'organizzazione.

• Posta in arrivo e in uscita dai server Cassette postali.

• Messaggi della segreteria telefonica inviati dai server Messaggistica unificata.

Per garantire un flusso di posta e un recapito efficienti all'interno dell'organizzazione di Exchange, i server Trasporto Edge e Trasporto Hub dovrebbero presentare una soluzione di archiviazione progettata correttamente.

In questo argomento sono riportati informazioni ed esempi per consentire di determinare i requisiti di capacità e di input/output (I/O) per i server Trasporto Edge e Trasporto Hub.

Requisiti di capacità e di I/O dei server Trasporto Edge

I server Trasporto Edge devono essere progettati per soddisfare i requisiti a livello di capacità e di I/O transazionale di ciascuna organizzazione. È importante gestire correttamente la crescita delle code e instradare la posta il più rapidamente possibile, in modo che i contratti di servizio (SLA, service level agreements) non subiscano effetti negativi. Esistono numerosi fattori che incidono sulla capacità generale di un server Trasporto Edge:

• Registri di verifica messaggi

• Registri di protocollo

• Database delle cassette postali

• Registri di connettività

• Registri degli agenti

L'unità contenente il database delle code dei messaggi deve disporre di un minimo di 500 MB di spazio libero sul disco e nel database. In caso contrario il sistema di trasporto attiva il controllo dell'utilizzo delle risorse, una funzione di monitoraggio delle risorse di sistema del servizio di trasporto di Microsoft Exchange Server 2007.

Nota

Nella versione di produzione (RTM) di Exchange Server 2007 il sistema di trasporto attiva una congestione quando lo spazio disponibile scende al di sotto di 4 GB. In Exchange 2007 Service Pack 1 questa soglia è stata abbassata a 500 MB.

Il valore predefinito per il controllo dell'utilizzo delle risorse dipende dal parametro PercentageDatabaseDiskSpaceUsedHighThreshold, che può essere modificato in caso di necessità. Per ulteriori informazioni sul controllo dell'utilizzo delle risorse e sulle opzioni per configurare il controllo dell'utilizzo delle risorse, vedere Concetti relativi alla funzionalità di controllo dell'utilizzo delle risorse.

Se i registri di verifica dei messaggi sono abilitati, è necessaria una capacità aggiuntiva. I requisiti per la capacità di verifica dei messaggi dipendono dal numero dei messaggi ricevuti dal server di trasporto. Se l'organizzazione attualmente utilizza Microsoft Exchange Server 2003, è possibile determinare l'attuale frequenza di generazione del registro e impostare un limite esatto per il numero di giorni per i quali conservare i dati, ad esempio 10 giorni. Microsoft genera 220 megabyte (MB) di registri di verifica dei messaggi per ogni giorno lavorativo (tranne il fine settimana) e garantisce una capacità sufficiente per una settimana di registri (circa 1,3 GB). Le dimensioni dei registri di protocollo, connettività e agenti variano in base all'attività. Per avere un riferimento, i server di trasporto di produzione in Microsoft generano:

• Da 5 a 15 GB di registri di protocollo al giorno sui server Trasporto Edge. La capacità sufficiente per la quota dei registri di protocollo, pari a 15 GB, è garantita.

• 100 MB di registri di connettività al giorno sui server Trasporto Edge. La capacità sufficiente per una settimana di registri, pari a 600 GB, è garantita.

• 250 MB di registri degli agenti al giorno sui server Trasporto Edge. La capacità sufficiente per una settimana di registri, pari a circa 1,5 GB, è garantita.

I registri delle transazioni non necessitano di un'elevata capacità su disco, poiché la creazione di un registro normale è limitata dall'uso della registrazione circolare. Di conseguenza, i registri delle transazioni possono essere posizionati sul numero di unità logica (LUN, logical unit number) contenente il sistema operativo. Microsoft utilizza un mirroring a due dischi per questo LUN.

Il database (mail.que) non archivia gli elementi in modo indefinito e la capacità riservata dovrebbe corrispondere alla dimensione media dei messaggi moltiplicata per il numero massimo di messaggi nella coda, nel caso in cui la coda abbia raggiunto il limite massimo e il server sia stato arrestato. Una coda di 500.000 elementi con una dimensione media dei messaggi di 50 kilobyte (KB) corrisponde a circa 25 GB di dati nel database.

I server Trasporto Edge che eseguono analisi antivirus sulla posta in arrivo, necessitano di spazio sufficiente per la quarantena antivirus. I requisiti di risorse I/O su disco dipendono dalla percentuale di posta in arrivo infetta da virus, che generalmente è ridotta. La quantità di messaggi e allegati infetti e la durata della loro permanenza in quarantena determinano la quantità di spazio necessario per la quarantena. Un GB di spazio su disco rappresenta un buon punto di partenza, sebbene le esigenze effettive di ogni organizzazione siano diverse.

Per la maggior parte delle distribuzioni di server Trasporto Edge, si consiglia di aggiungere un fattore di sovraccarico del 20% alla dimensione del database (dopo che tutti gli altri fattori sono stati considerati). Questo valore inciderà su strutture interne nell'ambito del database e garantirà uno spazio adeguato qualora un picco o una variazione nel flusso di posta dovesse comportare una crescita della dimensione del database.

Esempio di capacità per un server Trasporto Edge

In questo esempio i registri delle transazioni sono archiviati sulla partizione del sistema operativo (C:), che è ospitata da un controller RAID (Redundant Array of Independent Disks) supportato da batteria. I requisiti di capacità sono ridotti (nell'ordine di diversi megabyte).

Il processo per determinare la capacità di un server Trasporto Edge comprende due passaggi: il primo consiste nel calcolare la dimensione del database e il secondo nel determinare la dimensione del registro delle transazioni.

Passaggio 1: Dimensione del database

Considerare un server Trasporto Edge che riceve una media di 5 messaggi al secondo (con una dimensione media di 50 KB) in un periodo di 24 ore, con una coda massima di 500.000 elementi. Dopo che sono stati aggiunti tutti gli altri fattori, viene incluso un sovraccarico aggiuntivo del 20% e la dimensione totale sul disco è di 58 GB, come mostrato nella tabella seguente.

Dimensione del database

Numero massimo di messaggi nella coda	Capacità della coda	Registri di protocollo	Registri di verifica messaggi	Quarantena antivirus	Registri di connettività	Registri degli agenti	Spazio libero	Dimensione totale su disco
500,000	Circa 25 GB (500.000 × 50 KB)	15 GB	1,3 GB	1 GB	600 MB	1,5 GB	4 GB	58 GB (48 GB + 20%)

Passaggio 2: Dimensione del registro delle transazioni

Per determinare la dimensione del registro delle transazioni, è necessario considerare l'I/O transazionale, l'altro I/O del disco e l'I/O del database al secondo (IOPS) per ogni messaggio.

I/O transazionale

Se il server dispone di memoria disponibile sufficiente, la posta in arrivo verrà archiviata nella RAM e nel registro delle transazioni, riducendo al minimo l'impatto sul disco. Se le risorse della memoria sono ridotte, solo i primi 128 KB del messaggio vengono archiviati nella memoria e nel registro delle transazioni. Il resto del messaggio viene archiviato nel database. Durante la conversione del contenuto, i dati vengono inviati a una posizione temporanea per l'elaborazione. Tale posizione è specificata dall'impostazione TemporaryStoragePath del file EdgeTransport.exe.config. Per impostazione predefinita, il valore di TemporaryStoragePath è "C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Temp".

Nota

Per impostazione predefinita, Il file EdgeTransport.exe.config si trova nella directory %ProgramFiles%\Microsoft\Exchange Server\Bin folder.

È importante posizionare la directory temporanea sullo stesso LUN del database. Altrettanto importante è impostare per la cache del controller di archiviazione la lettura al 50% e la scrittura al 50%. Nei casi in cui non vi è una coda in forte crescita, alcuni I/O del disco saranno operazioni di lettura. Se è presente una coda, il messaggio potrebbe non trovarsi nella cache del database e pertanto richiedere più I/O del disco.

Altro I/O del disco

Oltre all'I/O transazionale, sul sistema può essere presente un altro I/O del disco. Ad esempio:

• L'abilitazione dei registri di verifica messaggi richiede un sovraccarico aggiuntivo del 2-5% dell'I/O del disco.

• L'abilitazione dei registri di protocollo e connettività determina un piccolo sovraccarico dell'I/O del disco che dipende dalla quantità di posta in arrivo.

• L'abilitazione dei registri agenti predefiniti comporta un piccolo sovraccarico dell'I/O del disco. Anche se si utilizzano agenti personalizzati, possono essere necessarie più risorse sul disco.

• Nella memoria si verificano operazioni di protezione da posta indesiderata e operazioni antivirus che richiedono maggiori risorse CPU.

Verificare i server Trasporto Edge eseguendo il test con tutti i servizi in esecuzione che si prevede di utilizzare nella produzione.

Operazioni di IOPS database per messaggio

Durante il test interno in Microsoft è stata utilizzata una dimensione media dei messaggi di 60 KB. Per il dimensionamento dei propri server, molte organizzazioni si basano su una determinata frequenza dei messaggi, ad esempio 20 messaggi al secondo. Questa frequenza dei messaggi necessiterebbe di 140 (20 × (4,5 + 2,5)) I/O del database e di 220 (20 × 11) I/O del registro.

Quando si forma una coda occorrono più letture, in particolare nel caso di RAID-1/0, poiché ogni disco fisico risponde alle richieste di lettura, come mostrato nella tabella seguente.

Operazioni di IOPS database per messaggio

I/O database Trasporto Edge (stato di stabilità)	I/O Edge approssimativi
Totale operazioni di IOPS per messaggio (circa 60 KB)	18
I/O scrittura registro per messaggio (sequenziale)	11
I/O scrittura database per messaggio (casuale)	4.5
I/O lettura database per messaggio (casuale)	2.5

Nota

I numeri nella tabella precedente costituiscono le medie di molti server nella produzione, con variazioni fino a più o meno 30%. Funzionalità aggiuntive, ad esempio regole di inserimento nel journal e di trasporto, incidono anch'esse sull'I/O previsto per messaggio e possono influire sui numeri della produzione forniti a scopo esemplificativo in questo argomento.

Applicazione di linee guida per il dimensionamento alla progettazione dell'hardware per un server Trasporto Edge

Una volta che si dispone dei requisiti relativi a capacità e I/O transazionale per un server Trasporto Edge, è possibile applicarli a una progettazione proposta per l'hardware. Per la configurazione del processore e della memoria, vedere Pianificazione delle configurazioni dei processori e Pianificazione delle configurazioni di memoria. Quando si progetta un server Trasporto Edge è importante che il sistema disponga di una RAM sufficiente (ogni messaggio necessita di 8 o 9 KB di memoria) per evitare che i corpi dei messaggi in coda vengano temporaneamente memorizzati nella cache sul disco.

Un server Trasporto Edge utilizza il database ESE (Extensible Storage Engine). Per ottenere resilienza e prestazioni ottimali, in ambienti che ospiteranno un'ampia coda è importante separare i file di registro e di database su dischi fisici distinti. Nelle distribuzioni più piccole, con minori requisiti di I/O del disco, può essere possibile posizionare sia i registri delle transazioni che il database nello stesso LUN. Il server Trasporto Edge, come il server Cassette postali, richiede tempi di risposta I/O inferiori a 20 millisecondi.

È importante utilizzare controller RAID supportati da batteria ed eseguire la manutenzione del database durante la notte. Assicurarsi inoltre che il tipo di disco scelto offra il giusto equilibrio di capacità e prestazioni.

Esempio di dimensionamento del progetto dell'hardware per un server Trasporto Edge

Questo esempio illustra come progettare l'archiviazione in base al numero di messaggi previsti per secondo. In questo esempio viene considerato un server Trasporto Edge che gestisce 20 messaggi al secondo e necessita di 140 IOPS per il LUN del database e di 220 IOPS per il LUN del registro. Aggiungere sempre un fattore di crescita del 20% per la prestazione I/O del disco per la gestione di carichi maggiori rispetto a quelli dei giorni normali. Il layout del disco è RAID10. Per i risultati del dimensionamento dell'hardware, vedere la tabella seguente.

Dimensionamento dell'hardware

Dischi (1) e (2), layout RAID1	Dischi (3), (4), (5) e (6), layout RAID10
Sistema operativo e registri delle transazioni 220 + 20% = 264 IOPS	Registri di database, protocollo e verifica dei messaggi e quarantena antivirus 140 + 20% = 168 IOPS

Questo esempio ha un requisito di capacità LUN del database di circa 70 GB per una settimana di dati. Se si necessita di due settimane di dati, raddoppiare il requisito di capacità, portandolo a 140 GB. Se si utilizzano dischi fisici da 146 GB in una configurazione RAID10 è possibile un LUN da 292 GB.

Requisiti di capacità e I/O dei server Trasporto Hub

Anche i server Trasporto Hub devono essere progettati per soddisfare i requisiti a livello di capacità e I/O transazionale dell'organizzazione. Come per il server Trasporto Edge, l'unità contenente il database delle code dei messaggi deve comprendere come minimo 500 MB di spazio libero sul disco e nel database, poiché in caso contrario il sistema di trasporto attiva il controllo dell'utilizzo delle risorse. È possibile modificare il valore predefinito per il parametro PercentageDatabaseDiskSpaceUsedHighThreshold sui server Trasporto Hub.

Nota

Nella versione di produzione (RTM) di Exchange Server 2007 il sistema di trasporto attiva una congestione quando lo spazio disponibile scende al di sotto di 4 GB. In Microsoft Exchange 2007 Service Pack 1 questa soglia è stata abbassata a 500 MB.

La capacità di verifica dei messaggi dipende dal numero dei messaggi ricevuti dal server di trasporto. Se l'organizzazione attualmente utilizza Microsoft Exchange 2003, è possibile determinare l'attuale frequenza di generazione del registro e impostare un limite esatto per il numero di giorni per i quali conservare i dati, ad esempio 10 giorni. Microsoft genera 700 MB di registri di verifica dei messaggi per ogni giorno lavorativo (tranne il fine settimana) sui server Trasporto Hub e garantisce una capacità sufficiente per una settimana di registri, pari a circa 4,5 GB.

Le dimensioni del registro di protocollo variano a seconda dell'attività. Microsoft genera 2,7 GB di registri di protocollo al giorno sui server Trasporto Hub e garantisce una capacità sufficiente per una settimana di registri, pari circa a 16 GB.

I registri delle transazioni non necessitano di un'elevata capacità su disco, poiché la creazione di un registro normale è limitata dall'uso della registrazione circolare. Di conseguenza, i registri delle transazioni possono essere posizionati nel LUN del sistema operativo. Microsoft utilizza un mirroring a due dischi per questo LUN.

Il database (mail.que) non archivia gli elementi in modo indefinito e la capacità riservata dovrebbe corrispondere alla dimensione media dei messaggi moltiplicata per il numero massimo di messaggi nella coda, nel caso in cui la coda abbia raggiunto il limite massimo e il server sia stato arrestato. Una coda di 500.000 elementi con una dimensione media dei messaggi di 50 KB corrisponde a circa 25 GB di dati nel database.

Per la maggior parte delle distribuzioni di server Trasporto Hub, si consiglia di aggiungere un fattore di sovraccarico aggiuntivo del 20% alla dimensione del database dopo che tutti gli altri fattori sono stati considerati.

Dumpster del trasporto

È necessario operare una considerazione speciale per i server Trasporto Hub in siti che contengono:

• Server di cassette postali in cluster distribuiti in un ambiente di replica continua cluster utilizzando Exchange Server 2007 RTM o Exchange 2007 SP1.

• Server Cassette postali che eseguono Exchange 2007 (SP1) aventi uno o più gruppi di archiviazione abilitati per la replica continua locale (LCR, Local Continuous Replication).

Quando si esegue la distribuzione di uno dei due ambienti di cui sopra, assicurarsi di progettare il server Trasporto Hub con una capacità sufficiente ad archiviare posta per tutti i gruppi di archiviazione nel sito, affinché i messaggi possano essere ripristinati in caso di interruzione non pianificata del nodo attivo. Questa funzionalità viene definita dumpster del trasporto.

Il sovraccarico I/O del dumpster del trasporto è simile alla crescita di una coda. Esistono sono due parametri che si possono utilizzare per controllare la durata della permanenza di un messaggio nel dumpster del trasporto: MaxDumpsterSizePerStorageGroup e MaxDumpsterTime. Il valore predefinito per MaxDumpsterSizePerStorageGroup è 18 MB. Per determinare il dumpster del trasporto adatto per l'ambiente, considerare la più elevata dimensione del messaggio accettabile e aumentarla del 50%. Ad esempio, se la quota del messaggio è pari a 10 MB, impostare MaxDumpsterSizePerStorageGroup su 15 MB. Se sono presenti più server Trasporto Hub nello stesso sito del servizio directory Active Directory come server di cassette postali in cluster nell'ambiente CCR oppure un ambiente LCR esegue Exchange 2007 SP1, l'archiviazione complessiva per i gruppi di archiviazione su questo server di cassette postali in cluster viene distribuita attraverso tutti i server Trasporto Hub. Ad esempio, se si dispone di quattro server Trasporto Hub con un dumpster del trasporto di 15 MB, per il gruppo di archiviazione ci sarebbe un dumpster del trasporto di 60 MB.

Per le organizzazioni in cui non sono posti limiti alla dimensione dei messaggi si consiglia di configurare MaxDumpsterSizePerStorageGroup su un valore pari a 1,5 volte la dimensione media dei messaggi inviati nell'ambito dell'organizzazione. Inoltre, se la dimensione media dei messaggi non è stata impostata, non vi è alcuna garanzia di poter recuperare il messaggio dopo un failover non programmato in un ambiente CCR o dopo l'attivazione di una copia passiva in un ambiente LCR che esegue Exchange 2007 SP1.

Si consiglia di impostare MaxDumpsterTime sul valore 7 giorni, ovvero su quello predefinito.

La capacità consumata dal dumpster del trasporto dovrebbe corrispondere al numero di gruppi di archiviazione moltiplicato per la dimensione massima del dumpster del trasporto. Se la dimensione massima del dumpster del trasporto è 15 MB e il server Trasporto Hub provvede a 100 gruppi di archiviazione in un ambiente LCR (Exchange 2007 SP1) o CCR (Exchange 2007 RTM), allocare 1,5 GB per il dumpster del trasporto.

Esempio di dimensionamento del dumpster del trasporto

In questo esempio i registri delle transazioni si trovano sul disco contenente la partizione del sistema operativo (C:), che è ospitata da un controller RAID supportato da batteria. I requisiti di capacità saranno ridotti (nell'ordine di megabyte). Per i risultati del dimensionamento, vedere le tabelle seguenti.

Il processo per determinare la capacità di una funzionalità dumpster del trasporto comprende due passaggi: il primo consiste nel calcolare la dimensione del database e il secondo nel determinare la dimensione del registro delle transazioni.

Passaggio 1: Dimensione del database

Considerare un server Trasporto Hub che riceve una media di 5 messaggi al secondo in un periodo di 24 ore, con un numero massimo di 500.000 elementi in coda.

Dimensionamento del dumpster del trasporto

Numero massimo di messaggi nella coda	Capacità della coda	Registri di protocollo	Registri di verifica messaggi	Dumpster del trasporto	Dimensione totale su disco
500,000	25 GB (500.000 x 50 KB)	15 GB	4,5 GB	1,5 GB	55 GB (46 GB + 20%)

Passaggio 2: Dimensione del registro delle transazioni

Per determinare la dimensione del registro delle transazioni, è necessario considerare l'I/O transazionale, l'altro I/O del disco e l'I/O del database IOPS per ogni messaggio.

I/O transazionale

Lo stesso principio per l'I/O transazionale elencato per i server Trasporto Edge si applica ai server Trasporto Hub. Come menzionato in precedenza, è particolarmente importante configurare le impostazioni della cache nel controller di archiviazione come segue: lettura 50% e scrittura 50%.

I/O dumpster del trasporto

Se il dumpster del trasporto è abilitato, l'I/O del disco aumenta. Anche se le scritture del database aumentano, ora si verificano anche letture del database, che nei server di produzione Microsoft sono mediamente tre per ogni messaggio.

Altro I/O del disco

Lo stesso principio per l'altro I/O del disco precedentemente elencato per i server Trasporto Edge si applica ai server Trasporto Hub. È particolarmente importante verificare i server Trasporto Edge eseguendo il test con tutti i servizi in esecuzione che si prevede di utilizzare nella produzione.

Operazioni di IOPS database per messaggio

Durante il test interno in Microsoft, se si utilizza una dimensione media dei messaggi di 40 KB, l'abilitazione del dumpster del trasporto richiede più risorse del disco sul server Trasporto Hub. Per il dimensionamento dei propri server, molte aziende si basano su una determinata frequenza dei messaggi, ad esempio 20 messaggi al secondo. Se il dumpster del trasporto è abilitato, sarebbero necessari 200 I/O del database (20 × (7 + 3)) e 140 I/O del registro (20 × 7) per fornire una frequenza di messaggi in arrivo di 20 messaggi al secondo. Se il dumpster del trasporto è disabilitato, sarebbero necessari 40 I/O del database (20 × (2 + 40)) e 40 I/O del registro (20 × 2) per fornire una frequenza di messaggi in arrivo di 20 messaggi al secondo.

Quando si forma una coda occorrono più letture, in particolare nel caso di RAID10, poiché ogni disco fisico risponde alle richieste di lettura. Per ulteriori informazioni, vedere la tabella seguente:

Dimensionamento del registro delle transazioni

I/O database server Trasporto Hub (stato di stabilità)	Dumpster del trasporto abilitato	Dumpster del trasporto disabilitato
Totale operazioni di IOPS per messaggio (circa 40 KB)	17	4
I/O scrittura registro per messaggio (sequenziale)	7	2
I/O scrittura database per messaggio (casuale)	7	2
I/O lettura database per messaggio (casuale)	3	0

Nota

I numeri nella tabella precedente costituiscono le medie di molti server nella produzione, con variazioni fino a più o meno 30%. Funzionalità aggiuntive, ad esempio regole di inserimento nel journal e di trasporto, incidono anch'esse sull'I/O previsto per messaggio e possono influire sui valori forniti in questo esempio.

Applicazione di linee guida per il dimensionamento alla progettazione dell'hardware per un server Trasporto Hub

Una volta che si dispone dei requisiti relativi a capacità e I/O transazionale per un server Trasporto Hub, è possibile applicarli a una progettazione proposta per l'hardware. Per le configurazioni la configurazione del processore e della memoria per i server Trasporto Hub, vedere Pianificazione delle configurazioni dei processori e Pianificazione delle configurazioni di memoria. Quando si progetta un server Trasporto Hub è importante che il sistema disponga di una RAM sufficiente (ogni messaggio necessita di 8 o 9 KB di memoria) per evitare che i corpi dei messaggi in coda vengano temporaneamente memorizzati nella cache sul disco.

Un server Trasporto Hub utilizza un database ESE. Per ottenere prestazioni ottimali, in ambienti che ospiteranno un'ampia coda oppure quando si utilizza il dumpster del trasporto è importante separare i file di registro e di database su dischi fisici distinti. Nelle distribuzioni più piccole, con minori requisiti di I/O del disco, può essere possibile posizionare sia i registri delle transazioni che il database nello stesso LUN. Il server Trasporto Hub, come il server Trasporto Edge, richiede tempi di risposta I/O inferiori a 20 millisecondi.

Esempi di dimensionamento del progetto dell'hardware per un server Trasporto Hub

È importante progettare l'archiviazione in base al numero di messaggi previsti per secondo. In questo esempio, un server Trasporto Hub gestisce 20 messaggi al secondo con dumpster del trasporto disabilitato e necessita di 40 IOPS per il LUN del database e di 40 IOPS per il LUN del registro. Aggiungere sempre un fattore di crescita del 20% per la prestazione I/O del disco per la gestione di carichi maggiori rispetto a quelli dei giorni normali. Il layout del disco sarebbe RAID1. Questo esempio ha un requisito di capacità LUN del database di circa 55 GB per una settimana di dati. Se si necessita di due settimane di dati, raddoppiare il requisito di capacità, portandolo a 110 GB. Utilizzando dischi fisici da 140 GB si otterrebbe un LUN del database da 140 GB in una configurazione RAID1 e un LUN di registro da 140 GB in una configurazione RAID1. Per i risultati, vedere la tabella seguente:

Dimensionamento dell'hardware per un server Trasporto Hub che gestisce 20 messaggi al secondo con il dumpster del trasporto disabilitato

Dischi (1) e (2), layout RAID1	Dischi (3) e (4), layout RAID1
Sistema operativo e registri delle transazioni 40 + 20% = 48 IOPS	Registri di database, protocollo e verifica dei messaggi e quarantena antivirus 40 + 20% = 48 IOPS

Nell'esempio successivo viene considerato un server Trasporto Hub con il dumpster del trasporto abilitato che gestisce 20 messaggi al secondo. Questa configurazione richiede 200 IOPS per il LUN del database e 140 IOPS per il LUN del registro, più il fattore di crescita aggiuntivo del 20%. Il layout del disco è RAID10. Questo esempio ha un requisito di capacità LUN del database di circa 55 GB per una settimana di dati o di 110 GB per due settimane di dati. Utilizzando dischi fisici da 140 GB si otterrebbe un LUN del database da 280 GB in una configurazione RAID10 e un LUN di registro da 140 GB in una configurazione RAID1.

Dimensionamento dell'hardware per un server Trasporto Hub che gestisce 20 messaggi al secondo con il dumpster del trasporto abilitato

Dischi (1) e (2), layout RAID1	Dischi (3), (4), (5) e (6), layout RAID10
Sistema operativo e registri delle transazioni 140 + 20% = 168 IOPS	Registri di database, protocollo e verifica dei messaggi e quarantena antivirus 200 + 20% = 240 IOPS