Pianificazione della capacità del processore del server Cassette postali
Ultima modifica dell'argomento: 2010-02-04
La pianificazione della capacità del server cassette postali è notevolmente cambiata rispetto alle versioni precedenti di Microsoft Exchange a causa della resilienza delle cassette postali in Microsoft Exchange Server 2010. Exchange 2010 è stato riprogettato in base al concetto di resilienza delle cassette postali, in cui l'architettura è stata modificata per fornire la protezione di failover automatica a livello del database delle cassette postali invece che a livello del server. Ci sono due modifiche principali che influenzano il processo di pianificazione della capacità del ruolo del server Cassette postali:
- Hosting delle copie dei database attivi e passivi sullo stesso server
- Calcolo del numero di copie dei database
È possibile utilizzare le informazioni in questo argomento per comprendere meglio questi cambiamenti e come guida di progettazione per il dimensionamento dei server Cassette postali quando è configurato per la resilienza delle cassette postali.
Sommario
Hosting delle copie dei database attivi e passivi sullo stesso server
Numero di copie dei database
Fasi di progettazione
Hosting delle copie dei database attivi e passivi sullo stesso server
In Exchange 2010, è possibile ospitare copie passive e attive dei database sullo stesso server quando il server è configurato per la resilienza delle cassette postali. I processori su ogni server gestiscono il carico di lavoro dalla cassetta postale attiva (ospitata su un database installato attivo) così come da quella passiva (ospitata sui database passivi). I requisiti del processore per le cassette postali passive e i database devono essere considerati quando si esegue la pianificazione della capacità del server Cassette postali di Exchange 2010. Una copia passiva del database utilizza le risorse della CPU per controllare o convalidare i registri replicati, per rieseguire i registri replicati nel database e per gestire l'indice di contenuto associato alla copia del database. In genere, ogni cassetta postale passiva (ospitata su una copia passiva del database) equivale al 15 per cento della CPU necessaria per ospitare la cassetta postale attiva (ospitata su un copia attiva del database).
Un aspetto chiave per la pianificazione della capacità delle cassette postali di Exchange 2010 è determinare quante copie del database si prevede di attivare su ogni server una volta configurato per la resilienza delle cassette postali. Sono disponibili numerosi modelli e tra questi sono consigliati quelli illustrati in Informazioni sui fattori di disponibilità elevata.
Per ulteriori informazioni, vedere gli argomenti seguenti:
- Understanding Processor Configurations and Exchange Performance
- Concetti relativi alle configurazioni della memoria e alle prestazioni di Exchange
Inizio pagina
Numero di copie dei database
Utilizzando la resilienza delle cassette postali di Exchange 2010, è possibile configurare più copie del database (fino a 16 copie per database) Ogni copia aggiuntiva del database aumenta il lavoro della CPU del server che ospita la copia attiva. Questo lavoro supplementare sul server con la copia attiva riguarda principalmente operazioni di replica e di indicizzazione dei contenuti, perché ogni copia passiva recupera il contenuto da indicizzare dalla copia attiva.
Per i requisiti di CPU della cassetta postale del server che ospita la copia attiva del database deve essere aumentata del 10 per cento per ogni copia aggiuntiva del database (ad esempio, una copia = 10 per cento, due copie = 20 per cento e così via). Questo fattore viene applicato solo ai requisiti della CPU per il server che ospita la copia attiva del database. La CPU utilizzata per ospitare le copie passive del database non è inserita in questo calcolo. Per ulteriori informazioni, vedere Understanding Processor Configurations and Exchange Performance.
Inizio pagina
Fasi di progettazione
A causa di nuovi fattori di dimensionamento, sono necessari ulteriori passi per ridimensionare i server Cassette postali quando sono configurati per la resilienza delle cassette postali. In generale, i passi sono i seguenti:
- Considerare i requisiti di disponibilità elevata per l'intera architettura della soluzione. Prendere in considerazione la resilienza cassetta postale o una soluzione standalone, la resilienza del sito, il numero di copie dei database richiesto e il numero di server o DAG per gestire i casi di errore più frequenti.
- Se si utilizza la resilienza della cassetta postale, scegliere quale modello di attivazione del database desiderato (scenario di errore nella destinazione o per l'attivazione di tutte le copie del database).
- Utilizzare la tabella seguente per valutare la CPU e i requisiti di memoria basati sul progetto. Si consideri la CPU e i requisiti di memoria per le cassette postali attive, i requisiti della CPU per le cassette postali passive e i requisiti della CPU sulla cassetta postale attiva per le copie aggiuntive del database. Utilizzare la scelta del modello di attivazione per definire il numero massimo di cassette postali che il modello è in grado di ospitare.
Nella tabella seguente viene fornita una stima dei valori per ogni profilo utente. I valori stimati sono basati su un periodo di picco di due ore durante la giornata lavorativa (ad esempio, dalle 10:00 fino a mezzogiorno). Questi periodi di maggiore traffico corrispondo generalmente al doppio del carico medio giornaliero tra le 8 e le 10 ore. La descrizione del profilo utente è stata omessa dal momento che l'intervallo dei profili è cresciuto all'aumentare dell'utilizzo della posta elettronica.
Per la cache del database delle cassette postali, le operazioni IOPS e le stime della CPU sono basate sul profilo utente e sull'attività di messaggistica
Messaggi giornalieri inviati o ricevuti per ogni cassetta postale | Cache del database per ogni cassetta postale in megabyte (MB) | Singola copia del database (autonoma) con operazioni IOPS stimate per ogni cassetta postale | Più copie di database (resilienza della cassetta postale) con operazioni IOPS stimate per ogni cassetta postale | Megacicli per cassetta postale attiva o per cassetta postale autonoma | Megacicli per cassetta postale passiva |
---|---|---|---|---|---|
50 |
3 |
0.06 |
0.05 |
1 |
0.15 |
100 |
6 |
0.12 |
0.1 |
2 |
0.3 |
150 |
9 |
0.18 |
0.15 |
3 |
0.45 |
200 |
12 |
0.24 |
0.2 |
4 |
0.6 |
250 |
15 |
0.3 |
0.25 |
5 |
0.75 |
300 |
18 |
0.36 |
0.3 |
6 |
0.9 |
350 |
21 |
0.42 |
0.35 |
7 |
1.05 |
400 |
24 |
0.48 |
0.4 |
8 |
1.2 |
450 |
27 |
0.54 |
0.45 |
9 |
1.35 |
500 |
30 |
0.6 |
0.5 |
10 |
1.5 |
Nota
È necessario aumentare i megacicli per cassetta postale attiva del 10 per cento per ogni copia aggiuntiva del database dopo la prima.
Nota
I megacicli sono stimati sulla base di una misura dei processori Intel i processori Xeon x5470 3.33 GHz (architettura 2 x 4 core). Un processore core 3,33-GHz = velocità effettiva delle prestazioni di 3.300 megacicli. Altre configurazioni del processore possono essere valutate confrontando questa piattaforma esaminata con le piattaforme server testate da Standard Performance Evaluation Corporation (SPEC). Per maggiori dettagli, vedere i risultati SPEC CPU2006 al sito Web Standard Performance Evaluation Corporation.
Esempio di pianificazione della capacità per un server Cassette postali
Nell'esempio seguente viene illustrato il ridimensionamento del processore. L'esempio presenta i seguenti presupposti di progettazione:
- Numero di cassette postali 12.000.
- Profilo della cassetta postale 150 messaggi inviati o ricevuti ogni giorno.
- Requisiti di disponibilità La resilienza della cassetta postale all'interno di un singolo sito e tolleranza errori su due server.
- Architettura di archiviazione Archivio JBOD (non RAID) con tre copie del database, 300 cassette postali per database, 40 database con 30 copie per server (o 120 copie del database per DAG). Le tre copie del database sono distribuite in modo casuale tra i quattro nodi in modo che nessun dei due server si assomigli.
- Modello di attivazione Scenario di errore, in cui gli errori su due server sono tollerati con un'interruzione minima. Ciò significa l'attivazione di 20 database su 30 copie per server dopo errori su due server.
- Piattaforma server Processori Intel Xeon 2 x 4 core x5470 3,33 GHz.
Il seguente processo viene applicato come segue:
- Calcolo del numero dei server Per la tolleranza degli errori su due server, è necessario un gruppo di disponibilità del database (DAG) con quattro nodi, per cui la progettazione deve iniziare con quattro server Cassette postali all'interno del DAG.
- Calcolo del numero massimo di cassette postali attive per ogni server in base al modello di attivazione Presupponendo che i database attivi vengano equamente distribuiti tra i nodi, ogni server ospita idealmente 3.000 cassette postali attive (12.000 ÷ 4). Per calcolare il numero di cassette postali attive dopo un errore su due nodi (in base a questo esempio), il numero di cassette postali verrà diviso tra i due nodi rimanenti, il che equivale a 6.000 cassette postali attive per ogni nodo (12.000 ÷ 2).
In questo esempio, il parametro MaximumActiveDatabases sul cmdlet Set-MailboxServer è configurato per 20. - **Calcolo dei requisiti della CPU per le cassette postali attive **Moltiplicare il numero massimo di cassette postali attive (20 × 300 = 6.000 cassette postali attive) per le cassette postali attive (6.000 × 3 megacicli = 18.000 megacicli), in base alla tabella precedente. Moltiplicare questo valore per 10 per cento per ogni copia di database aggiuntiva.
In questo esempio, esistono una copia attiva e due copie passive per ogni database, quindi i 18.000 megacicli sono aumentati del 20% (18.000 × 1,2 = 21.600 megacicli). - **Calcolo dei requisiti della CPU per le cassette postali passive **Moltiplicare il numero di cassette postali passive (quando un server ospita il numero massimo di cassette postali attive) per i megacicli di ogni cassetta postale passiva (3.000 × 0,45 megacicli = 1.350 megacicli), in base alla tabella precedente.
- Aggiunta dei requisiti di CPU per le cassette postali attive e passive per ottenere il requisito di CPU totali In questo esempio, 21.600 megacicli delle cassette postali attive + 1.350 megacicli delle cassette postali passive = 22.950 megacicli per il requisito di CPU totale.
- Applicazione del requisito di CPU totale alla piattaforma hardware In questo esempio, viene utilizzato un server basato su un processore Intel Xeon 2 x 4 core x5470 3,33 GHz. Ciò si traduce in 26.640 megacicli (8 × 3,330 MHz). Dividere i megacicli necessari per i megacicli disponibili in base alla piattaforma del server per stimare l'utilizzo di CPU nel periodo di massima attività dopo un errore su due nodi (22.950 ÷ 26.640 = 86% di utilizzo previsto della CPU). Un tasso di utilizzo della CPU pari all'86 per cento rappresenta un server pienamente utilizzato in cui lo spazio disponibile è praticamente uguale a zero, ma poiché questo calcolo si basa su una condizione di doppio errore che si verifica durante il periodo di massima attività, questo tasso può essere accettabile.
È opportuno che i server standalone siano progettati per non superare il 70 per cento dell'utilizzo durante il periodo di picco e che le configurazioni a due e tre nodi che non possono tollerare errori su più nodi siano progettate per non superare l'80 per cento dell'utilizzo nel periodo di picco (durante una condizione di errore sul nodo).
Inizio pagina