Esempio di struttura del ruolo del server Cassette postali di Exchange 2010

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2016-11-28

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.

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)

• Il server Cassette postali di Exchange ospita anche i ruoli server Trasporto Hub e Accesso client

• 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

Nell'esempio seguente viene illustrato il calcolo della dimensione appropriata per un ambiente che include 24.000 cassette postali da 2 GB, con un profilo di 100 messaggi al giorno, distribuite fra sei server Cassette postali appartenenti a un gruppo di disponibilità del database, con tre copie per ogni database. Queste cassette postali ricevono in media 37 MB di posta per 5 giorni la settimana, con una dimensione media dei messaggi pari a 75 KB. È abilitato il ripristino a livello di singolo elemento, con un periodo di conservazione di 14 giorni per gli elementi eliminati. 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 al giorno x 75/1024 MB = 7,32 MB

Dumpster = (100 messaggi al giorno x 75/1024 MB * 14 giorni) + (2048 MB x 0,012) + (2048 MB x 0,03) = 188,6 MB

Valori di esempio per la determinazione della dimensione effettiva della cassetta postale su disco

Poiché in questo ambiente viene utilizzata l'archiviazione JBOD, la dimensione massima del database che è possibile implementare dipende dalla dimensione del disco. Per determinare la dimensione massima del database per lo scenario JBOD, utilizzare la formula seguente, in cui la capacità formattata di un disco da 1 TB è di 931 GB, la percentuale di spazio libero richiesto è del 20% e la percentuale dell'indice dei contenuti è del 10%:

Dimensione massima database = [Capacità disco formattato x (1 – Percentuale spazio libero richiesto)] / (1 + Percentuale indice contenuto)

= [931 GB x (1 - 0,2)] / (1+ 0,10)

= 744,8 GB / 1,1

= 677 GB

In questo ambiente, la cassetta postale di ciascun utente occupa 2,25 GB di spazio su disco. Per supportare 24.000 cassette postali, con ciascun database di 677 GB, è necessario disporre di 102 database. Questo requisito 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.

Supponendo che per la base di utenti venga utilizzato un profilo di 100 messaggi al giorno, si prevede un utilizzo di 0,1 IOPS per ogni cassetta postale. Con questo profilo IOPS il disco è in grado di supportare un massimo di 440 cassette postali. 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 619 GB, come illustrato nella tabella seguente.

Requisiti di capacità dei database

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 al giorno genera in media 20 registri transazioni al giorno. In un ambiente con 24.000 cassette postali vengono pertanto prodotti 576.000 registri di transazioni al giorno, pari a 5.647 registri al giorno per ogni database. 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

Considerando la resilienza delle cassette postali e una configurazione JBOD con tre copie, ciascun database e i relativi registri transazioni verranno inseriti nello stesso LUN. La dimensione richiesta per il LUN è:

Capacità LUN = Dimensione database ÷ (1 - Percentuale di spazio libero richiesto)

= (Dimensione database + Dimensione registri transazioni + Dimensione indice contenuto) ÷ (1 - 0,2)

= (619 GB + 23 GB + 61,9 GB) /0,8

= 879 GB

Determinazione della dimensione del LUN

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.

Per ulteriori informazioni su come distribuire le copie del database tra i server Cassette postali, vedere Struttura di layout della copia del database.

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

Quando si implementa un'architettura con più ruoli, in base alla tabella riportata in Informazioni sulla cache del database delle cassette postali la memoria fisica totale necessaria per supportare questa configurazione è di 64 GB.

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

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

 ©2010 Microsoft Corporation. Tutti i diritti riservati.