Esempio di struttura del ruolo del server Cassette postali di Exchange 2010
Ultima modifica dell'argomento: 2009-12-09
Questo argomento fornisce un esempio di come determinare memoria adeguata, capacità, I/O e requisiti relativi alle prestazioni CPU per il ruolo del server Cassette postali e la sua architettura.
È possibile utilizzare lo strumento di calcolo dei requisiti del ruolo del server Cassette postali di Exchange Server 2010 per determinare i requisiti appropriati per il ruolo del server Cassette postali specificando un gruppo di fattori di input. Lo strumento di calcolo è in grado di determinare i requisiti descritti in questo esempio. Per ulteriori informazioni sullo strumento di calcolo e su come scaricarlo, vedere l'articolo nel blog del team di Exchange Server Strumento di calcolo dei requisiti del ruolo del server Cassette postali di Exchange 2010.
Nota
Il contenuto di ogni blog e il relativo URL sono soggetti a modifica senza preavviso. Il contenuto di ogni blog viene fornito "COSÌ COM'È" senza garanzie, e non conferisce alcun diritto. L'utilizzo di codice o di esempi di script è soggetto ai termini specificati nella pagina Web Microsoft - Informazioni sulle condizioni per l'utilizzo.
Per ulteriori informazioni sulla progettazione dell'archiviazione per il ruolo del server Cassette postali, vedere Progettazione dell'archiviazione del server Cassette postali.
Lo scenario utilizzato in questo esempio prevede una soluzione con tre copie del database che utilizza un archivio (un semplice gruppo di dischi) JBOD. Ai fini di questo esempio, considerare i seguenti requisiti dell'architettura:
- Sei server Cassette postali che fanno parte di un singolo gruppo di disponibilità del database (DAG)
- Ciascun server dispone di processori Intel Xeon x5470 3,33GHZ (architettura 2 x 4 core)
- Tre copie del database delle cassette postali ad elevata disponibilità, nessun copia ritardata del database
- Vengono utilizzati spindle SATA da 1 TB 7,2 K (7.200 g/min)
- Configurazione di archiviazione JBOD (1 numero unità logica (LUN) / architettura LUN database)
- Per l'architettura di backup, utilizzando le funzionalità di protezione dei dati nativi fornite tramite il recupero di un singolo elemento e la resilienza delle cassette postali.
- Un LUN di ripristino viene distribuito per le operazioni di manutenzione e ripristino
- Ogni LUN ha un minimo di spazio libero del 20 %
- La soluzione deve resistere agli eventi di errore del server doppio
- L'unico ruolo del server installato è il ruolo del server Cassette postali
Sommario
Requisiti di capacità della cassetta postale
Requisiti delle copie del database
Requisiti di memoria per le cassette postali
Requisiti di I/O delle cassette postali
Requisiti della CPU per le cassette postali
Requisiti di capacità della cassetta postale
Il seguente esempio illustra il ridimensionamento appropriato per un ambiente in cui ci sono 24.000 cassette postali da 2 GB con un profilo di 100 messaggi al giorno dislocate su sei server Cassette postali che compartecipano all'interno di un DAG con tre copie per ogni database. Queste cassette postali ricevono una media di 37 MB di posta per 5 giorni a settimana, con una dimensione media dei messaggi pari a 75 KB. Il ripristino di un singolo elemento è possibile grazie a una finestra che conserva gli elementi eliminati per i successivi 14 giorni. La dimensione della cassetta postale viene determinata in base ai seguenti calcoli:
Dimensione cassetta postale = Limiti delle cassette postali + Spazio vuoto + Dumpster
Spazio vuoto = 100 messaggi/giorno x 75/1024 MB = 7,3 MB
Dumpster = (100 messaggi/giorno x 75/1024 MB * 14 giorni) + (2048 MB x 0,012) + (2048 MB x 0,058) = 246 MB
Valori di esempio per la determinazione della dimensione effettiva della cassetta postale su disco
| Quota della cassetta postale | Dimensione dumpster (due settimane) | Spazio vuoto | Dimensione totale su disco |
|---|---|---|---|
2 GB |
246 MB |
7,3 MB |
2,25 GB (+12%) |
In questo ambiente, ciascun utente utilizza 2,25 GB di spazio su disco. Questa soluzione inoltre sfrutterà i dischi da 1TB in una configurazione JBOD, quindi la dimensione massima del database è 667 GB. Per supportare 24.000 cassette postali, con ciascun database di 667 GB, è necessario disporre di 102 database. Ciò determina un numero finale di 235 cassette postali per database.
Tuttavia, poiché questa soluzione sfrutta un'architettura di archiviazione JBOD, è di vitale importanza garantire che il numero di cassette postali per ogni database non superi la quantità di richieste di I/O casuali che può essere raggiunta su un singolo disco. Poiché questa soluzione si avvale di spindle SATA da 7,2K, ogni spindle può raggiungere un massimo di 55 richieste di I/O casuali al secondo (IOPS) nel momento di massimo utilizzo. Considerando il factoring in un buffer con capacità di incremento dell'overhead di I/O pari al 20 per cento, ne consegue che ogni spindle può gestire un totale di 44 IOPS casuali.
A condizione che il profilo dell'utente medio preveda 100 messaggi/giorno, per ogni cassetta postale si prevede un utilizzo di 0,1 IOPS e di conseguenza il disco è in grado di supportare un massimo di 440 cassette postali con questo tipo di profilo IOPS. Poiché il calcolo della capacità ha stabilito che il numero massimo di cassette postali supportato è 235 e questo numero è minore delle 440 cassette postali calcolate sulla base del profilo IOPS, questa soluzione può essere implementata su un singolo disco.
Per determinare le dimensioni effettive del database, utilizzare la seguente formula:
Dimensione database = Numero di cassette postali x Occupazione di ciascuna cassetta postale sul disco x Fattore di incremento dell'overhead del database
In base al numero di cassette postali, alla dimensione effettiva di ciascuna di esse e a un fattore di incremento dell'overhead del database pari al 20 per cento, la dimensione del database risulta essere di 635 GB, come illustrato nella tabella seguente.
Requisiti di capacità dei database
| Cassette postali per database | Numero totale di database | Requisiti di dimensione dei database |
|---|---|---|
235 |
102 |
635 GB |
Al fine di garantire che il server Cassette postali non incorra in interruzioni dovute a problemi di allocazione dello spazio, è necessario dimensionare adeguatamente anche i registri delle transazioni generati durante la creazione del set di backup. Considerando che questa architettura sfrutta la resilienza delle cassette postali e le funzionalità di ripristino di un singolo elemento come architettura di backup, è opportuno che la capacità dei registri sia calcolata sulla base di un'allocazione pari a tre volte la frequenza giornaliera di generazione dei registri per fare fronte all'eventualità che una copia in errore non venga corretta per tre giorni consecutivi. La presenza di una copia in errore impedisce che si verifichi il troncamento dei registri.
Un cassetta postale con un profilo di 100 messaggi/giorno genera mediamente 20 registri di transazioni al giorno, per cui un ambiente di 24.000 cassette postali produrrà 576.000 registri di transazioni al giorno. Ciò significa che ogni database genererà 5.647 registri al giorno. Ogni settimana, in genere il sabato, viene spostato l'1% delle cassette postali. La soluzione si avvale delle funzionalità di protezione dei dati nativi integrate in Exchange, pertanto non esegue i backup ed è dimensionata per tollerare 3 giorni senza il troncamento dei registri.
Come illustrato nella tabella seguente, questo server richiede 23 GB di spazio per ciascuna copia del database.
Requisiti di capacità dei registri
| Registri per ogni database | Dimensione del file di registro | Dimensione dei registri giornalieri | Dimensione delle cassette postali spostate/database | Tolleranza di troncamento | Requisiti di dimensione dei registri |
|---|---|---|---|---|---|
5647 |
1 MB |
5,65 GB |
6 GB (240 × 2,25 GB/102) |
16,5 GB (3 × 5,65 GB) |
23 GB 16,5 GB (+ 6 GB) |
Considerando una resilienza delle cassette postali/configurazione JBOD con tre copie, ciascun database e i relativi registri delle transazioni saranno messi sullo stesso LUN. La dimensione richiesta per il LUN è:
Capacità LUN = Dimensione dati/ (1 - Percentuale di spazio libero richiesto)
= (Dimensione database + Dimensione registri transazioni + Dimensione indice contenuto) / (1 - 2)
= (635 GB + 23 GB + 63,5 GB) /.8
= 902 GB
Determinazione della dimensione del LUN
| Dimensione del database | Dimensione dei registri | Dimensione indice contenuto | Dimensione del LUN del database |
|---|---|---|---|
635 GB |
23 GB |
63,5 GB |
902 GB |
Inizio pagina
Requisiti delle copie del database
Considerando un totale di 102 database necessari per supportare 24.000 cassette postali e considerando tre copie di ogni database, il DAG dovrà supportare un totale di 306 database. Avere 306 database distribuiti su sei server Cassette postali significa che ogni server Cassette postali dovrà ospitare 51 copie di database. Le copie del database dovrebbero essere distribuite tra tutti i server del DAG, in modo tale che gli errori a livello di server determinino l'attivazione del maggior numero di database possibile sui server rimanenti (le copie dei database non vengono distribuite in maniera simmetrica).
Per ottimizzare l'efficienza dei server Cassette postali inclusi nel DAG, i database attivi saranno equamente distribuiti tra tutti i server Cassette postali. Come risultato, quando tutti e sei i server Cassette postali sono funzionanti, ogni server dovrebbe ospitare 17 copie di database attive.
In caso di errore di un singolo server Cassette postali, i 17 database saranno ridistribuiti tra i restanti server Cassette postali, aumentando quindi a 21 il numero di copie di database attive su ciascun server.
In caso di errore di due server Cassette postali, i 34 database saranno ridistribuiti tra i restanti server Cassette postali, aumentando quindi a 26 il numero di copie di database attive su ciascun server. Questo numero di copie attive verrà utilizzato per determinare i requisiti di memoria e CPU del server Cassette postali.
Inizio pagina
Requisiti di memoria per le cassette postali
Con un profilo di 100 messaggi/giorno, il supporto della cache del database richiede una memoria minima di 6 MB per ciascuna cassetta postale. Dal momento che nel caso peggiore il numero di database di cassette postali attivi su ciascun server è 26, ogni server può ospitare un totale di 6.110 cassette postali attive. In aggiunta, si deve calcolare un totale di 51 database per ciascun server. Il server Cassette postali richiede una cache dei database di almeno 12 GB. Di conseguenza, la quantità di memoria necessaria per supportare la cache dei database è:
Requisiti minimi della cache dei database = MAX((Numero di Cassette postali attive x Memoria richiesta/Cassetta postale), Memoria minima per i database)
= MAX(6110 x 6/1024 GB, 12 GB)
= MAX (36 GB, 12 GB)
= 36 GB
La memoria fisica totale necessaria per supportare questa configurazione è di 48 GB, in base alla tabella riportata in Informazioni sulla cache del database delle cassette postali.
Inizio pagina
Requisiti di I/O delle cassette postali
Ciascuna cassetta postale invia o riceve 100 messaggi/giorno. Pertanto, ciascuna cassetta postale ha un profilo IOPS di 0,1. Ogni database ospita 235 cassette postali. Di conseguenza, la quantità totale di I/O del volume del database è:
I/O volume database = Numero di cassette postali x Profilo IOPS x (1 + Fattore di incremento overhead di I/O)
= 235 x 0,1 x 1,2
= 28,2 IOPS
Con questa architettura, la percentuale di I/O di lettura sul database è del 60%. Pertanto, ogni volume di database genera 16,92 IOPS di I/O di lettura e 11,28 IOPS di I/O di scrittura.
In questa architettura, ogni flusso di registro genera il 50 per cento delle I/O di scrittura sul database. Pertanto, le I/O di scrittura nel registro per il volume sono pari a 5,64 IOPS.
Le 26 copie di database attive generano anche il 10 per cento delle I/O di scrittura sul registro, quindi le I/O di lettura del registro per questi database è pari a 0,56 IOPS.
Considerando che ogni disco SATA da 7,2K con form factor di grandi dimensioni genera 55 IOPS casuali, il disco potrà sicuramente gestire i requisiti di I/O del database.
Inizio pagina
Requisiti della CPU per le cassette postali
In caso di errore su due server, ciascuno dei server rimanenti ospiterà 26 database per un totale di 6.110 cassette postali attive per server. Sulla base dei calcoli effettuati in Pianificazione della capacità del processore del server Cassette postali, ogni server ha i seguenti requisiti di megacicli della CPU.
Determinazione dei requisiti di megacicli della CPU
| Requisiti di megacicli della CPU per le cassette postali attive | Requisiti di megacicli della CPU per le cassette postali passive | Requisiti totali di megacicli della CPU |
|---|---|---|
14,682 |
1,765 |
16,447 |
Considerando che la piattaforma server scelta è in grado di supportare un totale di 26.400 megacicli, la CPU del server è in grado di supportare l'ambiente in caso di errore su due server.
Inizio pagina