Soluzioni testate per Exchange 2010: 32400 cassette postali in tre siti con Hyper-V su server blade Cisco Unified Computing System e risorse di archiviazione EMC CLARiiON

Articolo
03/03/2017

Ultima modifica dell'argomento: 2016-12-14

Rob Simpson, Program Manager, Microsoft Exchange; Boris Voronin, Sr. Solutions Engineer, Exchange Solutions Engineering, EMC; Mike Mankovsky, Microsoft Solutions Architect, Cisco

Data

giugno 2011

Soluzioni testate per Exchange 2010

In Soluzioni testate per Exchange 2010, Microsoft e i suoi partner per la fornitura di server, sistemi di archiviazione e reti esaminano una serie di scenari comuni tra i clienti e analizzano le domande che qualsiasi cliente deve porsi nel momento in cui decide di distribuire Microsoft Exchange Server 2010. Con questa serie di documenti, Microsoft desidera fornire un esempio di soluzioni Exchange 2010 personalizzate ed efficienti distribuite su componenti hardware forniti da alcuni nostri partner per la fornitura di server, sistemi di archiviazione e reti.

È possibile scaricare questo documento dall'Area download Microsoft.

Si applica a

Microsoft Exchange Server 2010 con Service Pack 1 (SP1)

Windows Server 2008 R2

Hyper-V di Windows Server 2008 R2

Sommario

Introduzione
Sommario della soluzione
Requisiti del cliente
- Profilo delle cassette postali
- Posizione geografica
- Protezione di dati e server
Presupposti per la progettazione
- Configurazione del server
- Configurazione dell'archiviazione
Progettazione della soluzione
- Individuazione della strategia per una disponibilità elevata
- Requisiti per la capacità di archiviazione stimata delle cassette postali
- Requisiti per le operazioni I/O stimate delle cassette postali
- Scelta del tipo di archiviazione
- Scelta di una soluzione di archiviazione DAS o SAN
- Scelta di una soluzione di archiviazione
- Requisiti per la memoria stimata delle cassette postali
- Calcolo della cache necessaria per il database
- Requisiti per la CPU stimata delle cassette postali
- Riepilogo dei requisiti per le cassette postali
- Scelta del modello del server
- Calcolo della capacità della CPU per il modello del server
- Individuazione del numero di server Cassette postali fisici necessari
- Stabilire il numero di cassette postali attive per server Cassette postali in scenari di normale operatività e di errore
- Distribuzione dei ruoli server Accesso client e Trasporto Hub su diversi server fisici
- Scelta del numero di combinazioni server Accesso client e server Trasporto Hub fisici necessarie
- Individuazione del numero totale di server fisici necessari
- Utilizzo della virtualizzazione server
- Utilizzo della virtualizzazione per ridurre il numero di server fisici
- Calcolo della capacità della CPU del server radice Hyper-V
- Rettifica del numero di megacicli disponibili per sovraccarico di virtualizzazione
- Individuazione della capacità della CPU delle macchine virtuali
- Verifica della capacità della CPU delle macchine virtuali del server Cassette postali principale
- Verifica della capacità della CPU delle macchine virtuali del server Cassette postali secondario
- Individuazione della quantità di memoria necessaria per ogni macchina virtuale del server Cassette postali principale
- Individuazione della quantità di memoria necessaria per ogni macchina virtuale del server Cassette postali secondario
- Individuazione della quantità di memoria necessaria per ogni combinazione server Accesso client e server Trasporto Hub
- Individuazione della quantità di memoria necessaria per ogni server radice Hyper-V
- Progettazione dei gruppi di disponibilità del database
- Progettazione del layout delle copie del database
- Modalità di coordinamento dell'attivazione del datacenter
- Posizionamento del witness di condivisione file
- Pianificazione dello spazi dei nomi
- Array del server Accesso client e strategia per il bilanciamento del carico
- Individuazione del modello per il bilanciamento del carico hardware
- Progettazione dell'archiviazione
Panoramica sulla soluzione
- Diagramma della soluzione logica
- Diagramma della soluzione fisica
- Riepilogo della configurazione del server radice Hyper-V
- Configurazione del server Accesso client e Trasporto Hub
- Configurazione del server Cassette postali
- Layout del database
- Componenti hardware di archiviazione
- Configurazione dell'archiviazione
Metodologia di verifica
- Metodologia di verifica di sistema di archiviazione
- Verifica del server
- Test di verifica funzionale
- Verifica del passaggio di database
- Verifica del passaggio di server
- Verifica del failover di server
- Verifica del passaggio di datacenter
- Verifica del ripristino del servizio per il datacenter principale
- Sede dei test
Risultati della verifica
- Risultati della verifica funzionale
- Risultati della verifica dell'architettura di archiviazione
- Risultati della verifica dell'architettura di archiviazione
Conclusione
Ulteriori informazioni

Introduzione

Questo documento fornisce un esempio di come progettare, verificare e convalidare una soluzione Exchange Server 2010 con tecnologia Hyper-V di Windows Server 2008 R2 per un ambiente con 32.400 cassette postali distribuite su server blade Cisco Unified Computing System e soluzioni di archiviazione EMC CLARiiON. Una delle principali sfide legate alla progettazione di ambienti Exchange 2010 di dimensioni maggiori ha per oggetto l'esame delle opzioni attualmente disponibili a livello di server e archiviazione e la scelta dei componenti hardware più adatti a garantire il miglior ritorno sull'investimento tenuto conto dal durata prevista della soluzione. Seguendo la procedura dettagliata illustrata nel documento, l'utente verrà guidato attraverso le più importanti decisioni da prendere per vincere queste sfide nel rispetto delle specifiche esigenze della sua attività. Una volta individuata la soluzione più adatta per il cliente, questa viene sottoposta a un processo di verifica in un ambiente simulato al fine di controllarne il corretto funzionamento in scenari di normale operatività, manutenzione ed errore.

Soluzioni testate per Exchange 2010

Sommario della soluzione

Nella tabella seguente sono indicati i principali componenti Exchange e hardware per questa soluzione.

Componenti di Exchange

Componente di Exchange	Valore o descrizione
Numero di cassette postali target	32400
Dimensione media delle cassette postali target	2 GB (thin provisioning con dimensione iniziale di 600 MB)
Profilo target per la media dei messaggi	100 messaggi al giorno
Numero di copie database	3
Backup tramite Servizio Copia Shadow del volume (VSS, Volume Shadow Copy Service)	Nessuna
Resilienza del sito	Sì
Numero di siti	3
Modello del gruppo di disponibilità del database (DAG, Database Availability Group)	Distribuzione attivo/attivo con più DAG
Virtualizzazione	Hyper-V
Numero di server Exchange	4 macchine virtuali
Numero di server fisici	2

Componenti hardware

Componente hardware	Valore o descrizione
Partner per il server	Cisco
Modello di server	M200
Tipo di server	Blade
Processore	Intel Xeon X5570
Partner per l'archiviazione	EMC
Modello di archiviazione	CX4-480
Tipo di archiviazione	Rete SAN
Tipo di disco	450 GB 15.000 SAS 3,5"
Partner per il bilanciamento del carico	Cisco
Modello per il bilanciamento del carico hardware	Ace

Soluzioni testate per Exchange 2010

Requisiti del cliente

Nella fase iniziale della progettazione di una soluzione Exchange, una delle operazioni più importanti è rappresentata dall'individuazione dei requisiti tecnici e aziendali critici, in quanto questi elementi sono fondamentali per poter prendere le decisioni di progettazione corrette. Le sezioni seguenti descrivono i requisiti del cliente per questa soluzione.

Soluzioni testate per Exchange 2010

Profilo delle cassette postali

Stabilire i requisiti il profilo delle cassette postali il più accuratamente possibile in quanto questi potrebbero influire su tutti gli altri componenti dell'architettura. Gli utenti che non hanno mai utilizzato Exchange potrebbero dover procedere per tentativi. Se si dispone già di un ambiente di Exchange, è possibile utilizzare lo strumento Microsoft Exchange Server Profile Analyzer per raccogliere il maggior numero di informazioni. Nelle tabelle seguenti sono indicati i requisiti per il profilo delle cassette postali per questa soluzione.

Numero di cassette postali

Requisito	Valore
Numero totale di cassette postali (incluse quelle delle risorse)	30000
Crescita percentuale prevista del numero di cassette postali (aumento previsto nel numero di cassette postali nel periodo di durata della soluzione)	8%
Percentuale di concorrenza delle cassette postali (numero massimo di cassette postali attive contemporaneamente)	100%
Numero di cassette postali target (il numero di cassette postali inclusa la crescita x la concorrenza prevista)	32400

Dimensione delle cassette postali

Requisito	Valore
Dimensione media delle cassette postali (in MB)	600 MB
Dimensione media dell'archivio delle cassette postali (in MB)	Non applicabile
Crescita percentuale prevista della dimensione delle cassette postali (in MB) (aumento previsto nella dimensione delle cassette postali nel periodo di durata della soluzione)	230%
Dimensione media delle cassette postali target (in MB)	2.048 MB

Profilo delle cassette postali

Requisito	Valore
Profilo dei messaggi target (il numero totale medio di messaggi inviati più quelli ricevuti per utente per giorno)	100 messaggi al giorno
Dimensione media dei messaggi target (in KB)	75
% in modalità cache di MAPI	100
% in modalità online di MAPI	0
% in modalità cache di Outlook via Internet	0
% in Microsoft Office Outlook Web App (Outlook Web Access in Exchange 2007 e versioni precedenti)	0
% in Exchange ActiveSync	0

Soluzioni testate per Exchange 2010

Posizione geografica

Conoscere la distribuzione dei datacenter e degli utenti delle cassette postali è molto importante per prendere decisioni che hanno per oggetto i livelli di disponibilità elevata e la resilienza del sito.

Nella tabella seguente è indicata la distribuzione geografica degli utenti che utilizzeranno il sistema Exchange.

Distribuzione geografica degli utenti

Requisito	Valore
Numero di siti principali che contengono utenti delle cassette postali	3
Numero di utenti di cassette postali nel sito 1	10800
Numero di utenti di cassette postali nel sito 2	10800
Numero di utenti di cassette postali nel sito 3	10800

Nella tabella seguente è indicata la distribuzione geografica dei datacenter che potrebbero utilizzare l'infrastruttura della posta elettronica di Exchange.

Distribuzione geografica dei datacenter

Requisito	Valore
Numero totale di datacenter	3
Numero di cassette postali attive in prossimità del datacenter 1	10800
Numero di cassette postali attive in prossimità del datacenter 2	10800
Numero di cassette postali attive in prossimità del datacenter 3	10800
Exchange deve risiedere in più datacenter	Sì

Soluzioni testate per Exchange 2010

Protezione di dati e server

È importante stabilire i requisiti per la protezione di dati e server perché da questi requisiti dipendono decisioni che hanno per oggetto i livelli di disponibilità elevata e la resilienza del sito.

Nella tabella seguente sono indicati i requisiti per la protezione del server.

Protezione del server

Requisito	Valore
Numero di errori simultanei del server o della macchina virtuale all'interno del sito	1
Numero di errori simultanei del server o della macchina virtuale durante un errore del sito	0

Nella tabella seguente sono indicati i requisiti per la protezione dei dati.

Protezione dei dati

Requisito	Valore o descrizione
È necessario conservare una copia di backup dei database di Exchange al di fuori dell'ambiente di Exchange (ad esempio, tramite una soluzione di backup di terzi)	No
È necessario conservare delle copia dei database di Exchange all'interno dell'ambiente di Exchange (ad esempio, per la protezione dei dati nativi di Exchange)	Sì
È necessario conservare più copie dei dati delle cassette postali nel datacenter primario	Sì
È necessario conservare più copie dei dati delle cassette postali nel datacenter secondario	No
È necessario conservare una copia ritardata di tutti i database di Exchange	No
Periodo di conservazione della copia ritardata (in giorni)	Non applicabile
Numero di copie del database target	3
Periodo di conservazione degli elementi nella cartella Posta eliminata (in giorni)	14

Soluzioni testate per Exchange 2010

Presupposti per la progettazione

In questa sezione sono incluse informazioni che generalmente non vengono raccolte tra i requisiti del cliente, ma sono tuttavia critiche nelle fasi di pianificazione e verifica del progetto.

Soluzioni testate per Exchange 2010

Configurazione del server

Nella seguente tabella sono indicati i valori target dell'utilizzo della CPU in scenari di normale operatività, manutenzione del server o errore del server nel sito.

Target di utilizzo del server

Presupposti per la progettazione del target di utilizzo della CPU del server	Valore
Operatività normale per i server Cassette postali	<70%
Operatività normale per i server Accesso client	<70%
Operatività normale per i server Trasporto Hub	<70%
Operatività normale per più ruoli server (Accesso client, Trasporto Hub e Cassette postali)	<70%
Operatività normale per più ruoli server (Accesso client e Trasporto Hub)	<70%
Errore a livello di nodo per i server Cassette postali	<80%
Errore a livello di nodo per i server Accesso client	<80%
Errore a livello di nodo per i server Trasporto Hub	<80%
Errore a livello di nodo per più ruoli server (Accesso client, Trasporto Hub e Cassette postali)	<80%
Errore a livello di nodo per più ruoli server (Accesso client e Trasporto Hub)	<80%
Errore a livello di sito per i server Cassette postali	<80%
Errore a livello di sito per i server Accesso client	<80%
Errore a livello di sito per i server Trasporto Hub	<80%
Errore a livello di sito per più ruoli server (Accesso client, Trasporto Hub e Cassette postali)	<80%
Errore a livello di sito per più ruoli server (Accesso client e Trasporto Hub)	<80%

Soluzioni testate per Exchange 2010

Configurazione dell'archiviazione

Nella tabella seguente sono indicati alcuni presupposti I/O e di configurazione dei dati utilizzati nella fase di progettazione della configurazione del sistema di archiviazione.

Presupposti di configurazione dei dati

Presupposto	Valore o descrizione
Fattore di sovraccarico dati	20%
Spostamenti delle cassette postali a settimana	1%
Manutenzione o ripristino dedicato del numero di unità logica (LUN)	No
Spazio libero LUN	20%
Compressione abilitata per il log shipping	Sì
Crittografia abilitata per il log shipping	Sì

Presupposti di configurazione I/O

Presupposto	Valore o descrizione
Fattore di sovraccarico I/O	20%
Ulteriori requisiti di I/O	Nessuna

Soluzioni testate per Exchange 2010

Progettazione della soluzione

Nella sezione che segue viene illustrata in dettaglio una metodologia utilizzata per progettare questa soluzione. Questa metodologia tiene conto dei requisiti del cliente e dei presupposti per la progettazione e guida l'utente attraverso le più importanti decisioni che deve prendere quando progetta un ambiente Exchange 2010.

Soluzioni testate per Exchange 2010

Individuazione della strategia per una disponibilità elevata

Quando si progetta un ambiente Exchange 2010, molte delle decisioni che hanno per oggetto le strategie per una disponibilità elevata influiscono su altri elementi del progetto. È pertanto consigliabile stabilire quale strategia per una disponibilità elevata adottare all'inizio del processo di progettazione. Prima di procedere, è consigliabile esaminare le informazioni per:

Passaggio 1: Verificare se la resilienza del sito è necessaria

Se si utilizzano più datacenter, è necessario decidere se distribuire l'infrastruttura di Exchange in un unico datacenter o in due o più datacenter. I contratti di servizio (SLA) di ripristino stipulati dall'organizzazione definiscono il livello di servizio necessario a seguito di un errore del datacenter principale. Queste informazioni devono essere alla base di questa decisione.

* Punto decisionale *

In questa soluzione, ci sono tre ubicazioni fisiche per i datacenter. Il contratto di servizio (SLA) stabilisce che la resilienza del datacenter è necessaria per tutti i servizi di importanza strategica, inclusa la posta elettronica. L'architettura di Exchange 2010 si baserà quindi su una distribuzione multisito con resilienza a livello di sito per i dati e i servizi di messaggistica.

Passaggio 2: Stabilire il rapporto tra le ubicazioni degli utenti abilitati per le cassette postali e le ubicazioni dei datacenter

In questo passo si verifica se tutti gli utenti abilitati per le cassette postali si trovano in prevalenza in un sito o se sono distribuiti su più siti e quindi se questi siti sono associati ai datacenter. Se gli utenti sono distribuiti su più siti e a questi ultimi sono associati dei datacenter, è necessario stabilire se esiste un requisito per il mantenimento dell'affinità tra questi utenti e il datacenter associato a quel sito.

* Punto decisionale *

In questo esempio, ciascuno dei tre datacenter si trova presso gli uffici regionali. In condizioni di normale operatività, si desidera mantenere l'affinità tra l'ubicazione dell'utente e quella della copia attiva principale della cassetta postale.

Passaggio 3: Individuare il modello di distribuzione del database

Dal momento che il cliente ha scelto di distribuire l'infrastruttura di Exchange in più ubicazioni fisiche, deve individuare il modello di distribuzione del database che può soddisfare meglio le esigenze dell'organizzazione. Ci sono tre modelli di distribuzione del database:

Distribuzione Attivo/Passivo Le copie attive del database delle cassette postali vengono distribuite nel datacenter principale e solo le copie passive del database vengono distribuite in un datacenter secondario. Il datacenter secondario funge da datacenter standby e nessuna cassetta postale attiva si trova in questo datacenter in condizioni di normale operatività. Nel caso che un'interruzione del servizio coinvolga il datacenter principale, si esegue un passaggio manuale al datacenter secondario in modo che i database attivi possano essere ospitati lì fino a quando il datacenter principale non è di nuovo online.

Distribuzione Attivo/Passivo
Distribuzione Attivo/Attivo (DAG singolo) I database attivi delle cassette postali vengono distribuiti nei datacenter principale e secondario. La corrispondente copia passiva si trova nel datacenter alternativo. Tutti i server Cassette postali sono membri di un singolo gruppo di disponibilità del database. In questo modello, la connessione WAN (Wide Area Network) tra i due datacenter potenzialmente è un singolo punto di errore. La perdita della connessione WAN provoca lo stato di errore dei server Cassette postali in uno dei datacenter a causa della perdita del quorum.

Distribuzione Attivo/Attivo (DAG singolo)
Distribuzione Attivo/Attivo (più DAG) Questo modello utilizza più gruppi di disponibilità del database per eliminare la connettività WAN come singolo punto di errore. Un gruppo di disponibilità del database ha le copie attive dei database nel primo datacenter e le corrispondenti copie passive nel secondo datacenter. Il secondo gruppo di disponibilità del database ha le copie attive dei database nel secondo datacenter e le corrispondenti copie passive nel primo datacenter. A fronte di una perdita della connessione WAN, le copie attive in ciascun sito continuano a garantire la disponibilità dei database agli utenti locali abilitati per le cassette postali.

Distribuzione attivo/attivo con più DAG

* Punto decisionale *

In questo esempio, dal momento che i database delle cassette postali verranno distribuiti in ciascuna delle tre ubicazioni dei datacenter, il modello di distribuzione del database sarà Attivo/Attivo con più gruppi di disponibilità del database. Quando si utilizza un modello di distribuzione del database Attivo/Attivo con più gruppi di disponibilità del database, è necessario tenere conto di alcune ulteriori considerazioni di progettazione che verranno illustrate in un passo successivo.

Passaggio 4: Stabilire la strategia per il backup e la resilienza del database

Exchange 2010 include diverse nuove funzionalità che, se distribuite e configurate correttamente, possono fornire la protezione dei dati nativi, eliminando così la necessità di eseguire le tradizionali operazioni di backup dei dati. Le copie di backup vengono generalmente utilizzate per il ripristino di emergenza, il ripristino degli elementi eliminati per errore, l'archiviazione dei dati a lungo termine e il ripristino temporizzato del database. Exchange 2010 è in grado di gestire tutte queste situazioni senza dover ricorrere alle tradizionali copie di backup:

Ripristino di emergenza Nel caso in cui si verifichi un errore software o hardware, più copie del database in un gruppo di disponibilità del database garantiscono una disponibilità elevata con tempi di failover più brevi e nessuna perdita di dati. I DAG possono essere estesi su più siti e possono offrire la resilienza contro errori del datacenter.
Ripristino degli elementi eliminati per errore Con la nuova cartella Elementi ripristinabili in Exchange 2010 e il criterio di conservazione che è possibile applicarle, è possibile conservare tutti i dati eliminati e modificati per un determinato periodo di tempo e ciò rende molto più facile e veloce il recupero di questi elementi. Per ulteriori informazioni, vedere Criteri di messaggistica e conformità, Informazioni su elementi ripristinabili e Informazioni sui tag di conservazione e sui criteri di conservazione.
Archiviazione dei dati a lungo termine A volte, i backup vengono utilizzati anche per l'archiviazione. Generalmente, si utilizza un nastro per conservare per lunghi periodi di tempo delle istantanee temporizzate dei dati, in conformità a quanto stabilito dai requisiti di conformità. Le nuove funzionalità di archiviazione, ricerca in più cassette postali e conservazione dei messaggi disponibili in Exchange 2010 consentono all'utente finale di conservare e accedere facilmente ai dati anche per lunghi periodi di tempo. Per ulteriori informazioni, vedere Informazioni sugli archivi personali, Informazioni sulla ricerca su più cassette postali e Informazioni sui tag di conservazione e sui criteri di conservazione.
Istantanea temporizzata del database Se per l'organizzazione è necessaria una copia precedente temporizzata dei dati della cassetta postale, Exchange offre la possibilità di creare una copia ritardata in un ambiente DAG. Ciò può essere utile nel caso in cui si verifichi un danneggiamento della partizione logica che si ripete nei database del DAG e quindi sia necessario tornare a uno stato precedente. Potrebbe anche essere utile se un amministratore elimina accidentalmente i dati dell'utente o delle cassette postali.

È comunque necessario tenere conto di varie considerazioni di natura tecnica e generica prima di decidere di utilizzare le funzionalità incorporate in Exchange 2010 per sostituire i backup tradizionali. Prima di prendere questa decisione, vedere Informazioni su backup, ripristino e ripristino di emergenza.

* Punto decisionale *

In questo esempio, con l'implementazione corrente di Exchange, l'utilizzo principale della soluzione di backup tradizione prevede il ripristino di elementi di posta eliminati per errore. L'ottanta percento delle richieste di ripristino di singoli elementi ha per oggetto messaggi eliminati meno di 15 giorni prima. Di conseguenza, il periodo di conservazione per gli elementi eliminati sarà di 14 giorni. Dal momento che le tradizionali soluzioni di backup VSS non sono necessarie per ripristinare un singolo elemento e non soddisfano l'obiettivo temporale per il recupero, come sistema per la resilienza del database verranno utilizzate le funzionalità di Exchange per la protezione dei dati nativi e la conservazione della cartella Posta eliminata.

Passaggio 5: Stabilire il numero di copie del database necessarie

La successiva decisione che è necessario prendere quando si definisce la strategia per la resilienza del sito riguarda il numero di copie del database da distribuire. Si consiglia di distribuire almeno tre copie di un database delle cassette postali prima di eliminare i tradizionali sistemi di protezione del database quali i backup tradizionali basati su VSS o le soluzioni RAID (Redundant Array of Independent Disks).

Prima di prendere questa decisione, vedere Informazioni sulle copie del database delle cassette postali.

* Punto decisionale *

In questo esempio, dal momento che non viene distribuita una soluzione di backup tradizionale basata su VSS, verranno distribuite almeno tre copie del database in modo che vengano soddisfatti i requisiti per il punto e il tempo di ripristino. Due copie verranno posizionate nel datacenter principale e una terza in un datacenter alternativo per garantire la resilienza del sito.

Passaggio 6: Stabilire il tipo di copia del database

Sono disponibili due tipi di copie del database:

Copie a disponibilità elevata Questa copia del database è configurata con un intervallo di riesecuzione pari a zero. Come suggerito dal nome stesso, le copie del database a disponibilità elevata vengono aggiornate dal sistema che può anche attivarle automaticamente e vengono utilizzate per fornire una disponibilità elevata ai dati e al servizio delle cassette postali.
Copie ritardate Questa copia del database è configurata in modo che ritardi la riesecuzione del registro delle transazioni per un periodo di tempo. Le copie ritardate del database sono progettate per fornire una protezione temporizzata, che può essere utilizzata per il ripristino da danneggiamenti della partizione logica dell'archivio, da errori amministrativi (ad esempio, l'eliminazione di una cassetta postale disconnessa) e da errori di automazione (ad esempio, l'eliminazione in blocco delle cassette postali disconnesse).

* Punto decisionale *

In questo esempio, tutte e tre le copie del database delle cassette postali verranno distribuite come copie a disponibilità elevata. Il contratto di servizio (SLA) non richiede una copia ritardata dei dati. Dal momento che in passato non si sono verificati episodi di danneggiamento dei dati logici e per la gestione dei messaggi non vengono utilizzate altre applicazioni, non è necessaria una copia ritardata. L'unico motivo per utilizzare una copia ritardata potrebbe essere rappresentato dalla necessità di ripristinare singoli elementi eliminati, ma per eseguire questa operazione è molto più comodo e conveniente utilizzare la funzionalità di conservazione della cartella Posta eliminata.

Passaggio 7: Stabilire la strategia per la resilienza del server Cassette postali

Exchange 2010 è stato riprogettato per offrire la resilienza delle cassette postali. Ora la protezione automatica da failover è fornita a livello di database delle cassette postali invece che a livello di server. È possibile distribuire in modo strategico le copie attive e passive dei database sui server Cassette postali in un gruppo di disponibilità del database. Stabilire il numero di copie del database che verranno attivate su ogni singolo server è un fattore chiave per pianificare correttamente la capacità di Exchange 2010. I modelli di distribuzione dei database sono molteplici, ma generalmente è preferibile scegliere uno dei seguenti:

Struttura per tutte le copie attivate In questo modello, il server Cassette postali viene dimensionato per supportare l'attivazione di tutte le copie del database sul server. Ad esempio, un server Cassette postali potrebbe ospitare quattro copie del database. In condizioni di normale operatività, il server potrebbe avere due copie del database attive e due copie passive. In caso di errore o durante la manutenzione, tutte e quattro le copie del database diventano attive sul server Cassette postali. Di solito, questa soluzione viene distribuita a coppie. Ad esempio, se si distribuiscono quattro server, la prima coppia è composta dai server MBX1 e MBX2 e la seconda dai server MBX3 e MBX4. Inoltre, quando si progetta questo modello, ciascun server Cassette postali verrà dimensionato in modo che utilizzi al massimo il 40% delle risorse disponibili in condizioni di normale operatività. In una distribuzione con resilienza del sito con tre copie del database e sei server, questo modello può essere distribuito in gruppi di tre server, con il terzo server che risiede nel datacenter secondario. Questo modello fornisce un blocco predefinito a tre server per le soluzioni che utilizzano un sistema di resilienza del sito attivo/passivo.

È possibile utilizzare questo modello nei seguenti casi:
- Configurazione con più siti di tipo Attivo/Passivo in cui gli eventuali domini in errore (ad esempio, rack, sistemi blade e array di archiviazione) richiedono che le copie del database possano essere facilmente isolate nel datacenter principale
- Configurazione con più siti di tipo Attivo/Passivo in cui la crescita prevista potrebbe rendere necessaria l'aggiunta di unità logiche di scala
- Configurazioni che non è necessario superino l'eventuale perdita simultanea di due server Cassette postali nel gruppo di disponibilità del database
Questo modello prevede che i server vengano distribuiti in coppie nel caso di distribuzione in un sito singolo e in gruppi nel caso di distribuzione in più siti. Nella tabella seguente viene illustrato un esempio di layout dei database per questo modello.

Struttura per tutte le copie attivate

Legenda della tabella:
- C1 = copia attiva (valore della preferenza di attivazione pari a 1) in condizioni normali di operatività
- C2 = copia passiva (valore della preferenza di attivazione pari a 2) in condizioni normali di operatività
- C3 = copia passiva (valore della preferenza di attivazione pari a 3) durante un errore a livello di sito
Struttura per gli scenari di errore In questo modello, il server Cassette postali viene progettato per supportare l'attivazione di un sottogruppo di copie del database sul server. Il numero di copie del database all'interno del sottogruppo dipende dallo specifico scenario di errore considerato. L'obiettivo principale di questo modello è ottenere una distribuzione equa del carico dei database attivi tra gli altri server Cassette postali nel gruppo di disponibilità del database.

È consigliabile utilizzare questo modello nei seguenti casi:
- Tutte le configurazioni a sito singolo con tre o più copie del database
- Configurazioni che è necessario superino l'eventuale perdita simultanea di due server Cassette postali nel gruppo di disponibilità del database
L'architettura del gruppo di disponibilità del database per questo modello necessita di un numero di server Cassette postali compreso tra 3 e 16. Nella tabella seguente viene illustrato un esempio di layout dei database per questo modello.

Struttura per gli scenari di errore

Legenda della tabella:
- C1 = copia attiva (valore della preferenza di attivazione pari a 1) in condizioni normali di operatività
- C2 = copia passiva (valore della preferenza di attivazione pari a 2) in condizioni normali di operatività
- C3 = copia passiva (valore della preferenza di attivazione pari a 3) in condizioni normali di operatività

* Punto decisionale *

In un passo precedente si è scelto di implementare un modello di distribuzione del database di tipo Attivo/Attivo con più gruppi di disponibilità del database. Dal momento che ciascun gruppo di disponibilità del database in questo modello ha una configurazione di tipo Attivo/Passivo con due sole copie del database a disponibilità elevata nel datacenter principale, è opportuno applicare una strategia per la resilienza del server Cassette postali che preveda l'attivazione di tutte le copie.

Passaggio 8: Stabilire il numero di gruppi di disponibilità del database

Un gruppo di disponibilità del database rappresenta il componente base nel modello con resilienza del sito e a disponibilità elevata incorporato in Exchange 2010. Un DAG è un gruppo di massimo 16 server Cassette postali che ospita un gruppo di database replicati e fornisce un ripristino automatico a livello di database nel caso si verifichino errori che coinvolgono i singoli server o database.

Un gruppo di disponibilità del database è un confine per la replica del database delle cassette postali, per il passaggio e il failover di database e server e per un componente interno denominato Active Manager. Active Manager è un componente di Exchange 2010 che gestisce passaggi e failover. Active Manager viene eseguito su ogni server in un gruppo di disponibilità del database.

Nell'ottica della pianificazione, può essere consigliabile cercare di minimizzare il numero di gruppi di disponibilità del database distribuiti. Si dovrebbe valutare la possibilità di utilizzare più gruppi di disponibilità del database se:

Si distribuiscono più di 16 server Cassette postali.
Ci sono utenti abilitati per le cassette postali attive in più siti (configurazione del sito di tipo Attivo/Attivo).
Sono necessari confini amministrativi separati a livello di gruppo di disponibilità del database.
Ci sono più server Cassette postali in domini separati. Il gruppo di disponibilità del database rappresenta il limite per il dominio.

* Punto decisionale *

In un passo precedente si è scelto di implementare un modello di distribuzione del database di tipo Attivo/Attivo. Si potrebbe distribuire un singolo gruppo di disponibilità del database con utenti abilitati per le cassette postali attive in ciascun sito. Tuttavia, nel caso che i membri del gruppo in un sito perdano temporaneamente la connessione con i membri del gruppo in un altro sito, il cluster in quel sito perderà il quorum e smetterà di funzionare correttamente. Per questo motivo, verranno distribuiti tre gruppi di disponibilità del database. Ciascun gruppo conterrà i server Cassetta postale dal datacenter principale che ospita le copie principale e secondaria del database. Ciascun gruppo conterrà inoltre i server in uno dei datacenter alternativi che ospiteranno la terza copia del database. Il modello risultante sarà composto da tre gruppi di disponibilità del database di tipo Attivo/Passivo con ciascun datacenter che ospita le copie principale e secondaria di un gruppo e la terza copia di un altro gruppo.

Passaggio 9: Stabilire il numero di server Cassette postali per ogni gruppo di disponibilità del database

In questo passo è necessario stabilire il numero minimo di server Cassette postali per il supporto del gruppo di disponibilità del database. Questo numero potrebbe essere diverso dal numero di server necessari per supportare il carico di lavoro, quindi la decisione finale sul numero di server viene presa successivamente.

* Punto decisionale *

In un passo precedente si è scelto di implementare tre gruppi di disponibilità del database di tipo Attivo/Passivo e una strategia per la resilienza del server con l'attivazione di tutte le copie. Ciascun gruppo deve essere distribuito in incrementi di tre server (due nel sito principale e uno in un sito alternativo). Dal momento che si devono distribuire tre gruppi di disponibilità del database, sono necessari almeno nove server per supportare questo modello. La soluzione disporrà di 9, 18 o 27 server, a seconda del numero di server necessari per supportare il carico di lavoro. Nella tabella seguente vengono illustrate le possibili configurazioni.

Numero di server Cassette postali per gruppo di disponibilità del database

Datacenter principale DAG1	Datacenter secondario DAG1	Datacenter principale DAG2	Datacenter secondario DAG2	Datacenter principale DAG3	Datacenter secondario DAG3	Numero totale di server Cassette postali
2	1	2	1	2	1	9
4	2	4	2	4	2	18
6	3	6	3	6	3	27

Nota

In un modello con tre nodi DAG, se si perdono i due nodi nel datacenter principale, il cluster perde il quorum e l'attivazione automatica. La terza copia nel datacenter secondario garantisce la disponibilità dei dati, ma il ripristino del servizio nel datacenter secondario deve essere eseguito manualmente.

Soluzioni testate per Exchange 2010

Requisiti per la capacità di archiviazione stimata delle cassette postali

Molti fattori influenzano i requisiti di capacità di archiviazione per il server Cassette postali. Per ulteriori informazioni, vedere Informazioni sui fattori capacità registro e database delle cassette postali.

Nei passi successivi viene spiegato come calcolare i requisiti di capacità delle cassette postali. Questi requisiti verranno utilizzati per individuare le opzioni della soluzione di archiviazione più adatte. In una sezione successiva vengono illustrati ulteriori calcoli per pianificare correttamente il layout del sistema di archiviazione per la piattaforma scelta.

A tale scopo, Microsoft ha creato un apposito strumento per il calcolo dei requisiti del ruolo server Cassette postali. Per scaricare questo strumento di calcolo, vedere E2010 Mailbox Server Role Requirements Calculator. Per ulteriori informazioni sull'utilizzo di questo strumento di calcolo, vedere Exchange 2010 Mailbox Server Role Requirements Calculator.

Passaggio 1: Calcolare la dimensione delle cassette postali su disco

Prima di tentare di stabilire i requisiti di spazio totale, è necessario conoscere la dimensione delle cassette postali su disco. Per una cassetta postale completa con una quota pari a 1 GB è necessario più di 1 GB di spazio su disco perché si deve tenere conto dei limiti per la proibizione di invio e ricezione, del numero del messaggi che l'utente invia o riceve ogni giorno, dell'intervallo di conservazione impostato per la cartella Posta eliminata (con o senza registrazione della versione del calendario e ripristino di un singolo elemento) e del numero medio di variazioni giornaliere del database per ogni cassetta postale. Lo strumento per il calcolo dei requisiti del ruolo server Cassette postali può eseguire questo calcolo. È anche possibile utilizzare le seguenti informazioni per eseguire manualmente i calcoli.

Le seguenti operazioni consentono di stabilire la dimensione su disco di una cassetta con limite di 2 GB in questa soluzione:

Spazio vuoto = 100 messaggi al giorno x 75/1024 MB = 7,3 MB
Dumpster = (100 messaggi al giorno × 75 ÷ 1024 MB × 14 giorni) + (2.048 MB × 0,012) + (2.048 MB × 0,058) = 246 MB
Dimensione cassetta postale su disco = limite di cassetta postale + spazio vuoto + dumpster

= 2048 + 7.3 + 246

= 2.301 MB

Passaggio 2: Calcolare i requisiti di capacità di archiviazione per il database

In questo passo viene calcolata la capacità di archiviazione di alto livello necessaria per tutti i database delle cassette postali La capacità calcolata include la dimensione del database, la dimensione dell'indice del catalogo e il 20% di spazio disponibile.

Per stabilire la capacità di archiviazione necessaria per tutti i database, utilizzare le seguenti formule:

Dimensione database = (numero di cassette postali × dimensione cassetta postale su disco × fattore di crescita del sovraccarico database) + (20% sovraccarico dati)

= (32400 × 2301 × 1) + (14910480)

= 89.462.880 MB

= 87.366 GB
Dimensioni indice database = 10% delle dimensioni del database

= 87366 × 0.10

= 8.737 GB
Capacità totale del database = (dimensione del database) + (dimensioni dell'indice) ÷ 0,80 per aggiungere il 20% dello spazio disponibile nel volume

= (87366 + 8737) ÷ 0.8

= 120.128 GB

Passaggio 3: Calcolare i requisiti di capacità di archiviazione del registro delle transazioni

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. Nel caso che il server non sia di nuovo online entro tre giorni, rimuovere temporaneamente la copia per consentire il troncamento.

Per stabilire la capacità di archiviazione necessaria per tutti i registri delle transazioni, utilizzare le seguenti formule:

Dimensione file di registro = (dimensione file di registro × numero di registrazioni per cassetta postale ogni giorno × numero di giorni necessari per sostituire l'infrastruttura danneggiata × numero di utenti abilitati per le cassette postali) + (1% sovraccarico spostamento cassetta postale)

= (1 MB × 20 × 4 × 32.400) + (32.400 × 0,01 × 2048 MB)

= 3.255.552 MB

= 3.179 GB
Capacità totale del registro = dimensione dei file di registro ÷ 0,80 per aggiungere il 20% dello spazio disponibile nel volume

= (3179) ÷ 0.80

= 3974

Passaggio 4: Stabilire i requisiti di capacità di archiviazione totale

Nella tabella seguente sono indicati i requisiti di capacità di archiviazione di alto livello per questa soluzione. In un passo successivo, si utilizzeranno queste informazioni per scegliere la soluzione di archiviazione da distribuire. Successivamente, si analizzeranno più in dettaglio gli specifici requisiti di archiviazione.

Riepilogo dei requisiti di capacità di archiviazione

Requisito	Valore
Dimensione media delle cassette postali su disco (MB)	2301
Capacità database necessaria (GB)	120128
Registro capacità necessaria (GB)	3974
Capacità totale necessaria (GB)	124102
Capacità totale necessaria per tre copie del database (GB)	372306
Capacità totale necessaria per tre copie del database (TB)	364
Capacità totale necessaria per ciascun sito (TB)	122

Soluzioni testate per Exchange 2010

Requisiti per le operazioni I/O stimate delle cassette postali

Quando si progetta un ambiente Exchange, è necessario conoscere i fattori di prestazioni per database e registri. È consigliabile consultare Informazioni sui database e log prestazioni fattori.

Passaggio 1: Calcolare i requisiti per le operazioni I/O totali delle cassette postali

Dal momento che le operazioni I/O transazionali rappresentano un parametro fondamentale ai fini del calcolo dello spazio di archiviazione necessario, è importante conoscere il numero di operazioni I/O al secondo (IOPS) eseguite sul database da ciascun utente abilitato per le cassette postali. Le operazioni I/O sequenziali non vengono prese in considerazione ai fini del calcolo del valore IOPS per i server Cassette postali perché i sottosistemi di archiviazione sono in grado di gestire le operazioni I/O sequenziali in modo molto più efficace delle operazioni I/O casuali. Tra queste operazioni vi sono la manutenzione del database in background e le operazioni I/O transazionali e di replica dei registri. In questo passo si calcola il valore IOPS totale necessario per supportare le attività di tutti gli utenti abilitati per le cassette postali utilizzando i seguenti valori:

Valore IOPS stimato per ogni utente abilitato per le cassette postali = 0,10
Valore IOPS totale necessario = IOPS per ciascun utente abilitato per le cassette postali × numero di cassette postali × fattore di sovraccarico I/O

= 0.10 × 32400 × 1.2

= 3888

Nota

Per stabilire il profilo IOPS per uno specifico profilo messaggi, vedere la tabella "Cache del database e valori IOPS stimati per ogni cassetta postale in base all'attività dei messaggi" in Informazioni sui database e log prestazioni fattori.

Passaggio 2: Calcolare i requisiti per le operazioni I/O totali delle cassette postali per singolo sito

Dal momento che si tratta di una distribuzione multisito, è necessario tenere conto dei requisiti del valore IOPS per ogni singolo sito in modo da poter dimensionare correttamente l'archivio di ciascun sito. In un passo precedente si è stabilito che ciascun sito avrebbe ospitato le copie principale e secondaria del database dal gruppo di disponibilità del database principale e la terza copia del database da un gruppo di disponibilità del database alternativo. In questo modello, la peggiore delle ipotesi si verificherebbe a fronte di un errore di un singolo sito nel caso in cui 10.800 cassette postali del gruppo di disponibilità del database principale e altre 10.800 cassette del gruppo di disponibilità del database alternativo siano attive nell'archivio presso quel sito. Utilizzare la seguente formula:

Valore IOPS totale necessario per ogni sito = IOPS per ciascun utente abilitato per le cassette postali × numero di cassette postali × fattore di sovraccarico I/O

= 0.10 × 21600 × 1.2

= 2592

Soluzioni testate per Exchange 2010

Scelta del tipo di archiviazione

Exchange 2010 include importanti miglioramenti a livello di prestazioni, affidabilità e disponibilità che consentono alle organizzazioni di eseguire Exchange su una vasta gamma di tipologie di archiviazione.

Quando si esaminano le diverse tipologie di archiviazione disponibili, è importante riuscire a bilanciare correttamente i livelli di prestazioni, capacità e gestibilità al fine di ottenere una soluzione di archiviazione adatta ad Exchange.

Per ulteriori informazioni sulla scelta di una soluzione di archiviazione per Exchange 2010, vedere Progettazione dell'archiviazione del server Cassette postali.

Soluzioni testate per Exchange 2010

Scelta di una soluzione di archiviazione DAS o SAN

Per Exchange 2010 sono disponibili numerose tipologie di archiviazione, anche se fondamentalmente tutto si riduce a scegliere se distribuire una soluzione di archiviazione DAS (Direct-Attached Storage) con disco locale o una soluzione SAN (Storage Area Network). Entrambe presentano vantaggi e svantaggi e pertanto è opportuno confrontarsi con il proprio fornitore di fiducia per individuare la soluzione che meglio può soddisfare le esigenze della propria azienda e i requisiti in termini di costo totale di proprietà (TCO).

* Punto decisionale *

In questo esempio viene distribuita un'infrastruttura SAN per l'archiviazione di tutti i dati nell'ambiente. Si continuerà a utilizzare una soluzione di archiviazione SAN e verranno esaminate le opzioni per la distribuzione di Exchange 2010.

Soluzioni testate per Exchange 2010

Scelta di una soluzione di archiviazione

Per scegliere una soluzione di archiviazione, fare quanto segue.

Passaggio 1: Individuare il proprio fornitore di fiducia per i sistemi di archiviazione

In questo esempio, per molti anni è stato utilizzato un archivio EMC e quindi si utilizzerà una soluzione di archiviazione EMC anche per la distribuzione di Exchange 2010. EMC Corporation offre array di archiviazione a prestazioni elevate quali CLARiiON e Symmetric.

Passaggio 2: Esaminare le opzioni disponibili presso il proprio fornitore di fiducia

La famiglia di prodotti EMC CLARiiON fornisce diversi livelli di archiviazione, quali unità flash USB aziendali e sistemi Fibre Channel e SATA (Serial ATA), che consentono di ridurre i costi in quanto permettono di gestire più livelli attraverso un'unica interfaccia.

CLARiiON Virtual Provisioning fornisce vantaggi che vanno oltre il tradizionale thin provisioning, incluse una gestione semplificata del sistema di archiviazione e un migliore utilizzo delle spazio. È possibile assegnare all'host una capacità notevole e quindi utilizzare lo spazio da un pool condiviso in base alle necessità.

CLARiiON serie CX4 offre quattro modelli con livelli di capacità, funzionalità e prestazioni flessibili. Nella tabella seguente sono descritte le funzionalità di ciascun modello.

Funzionalità di CLARiiON serie CX4

Funzionalità	Modello CX4-120	Modello CX4-240	Modello CX4-480	Modello CX4-960
Numero massimo di dischi	120	240	480	960
Processori di archiviazione	2	2	2	2
Memoria fisica per processore di archiviazione	3 GB	4 GB	8 GB	16 GB
Valore massimo cache in scrittura	600 MB	1,264 GB	4,5 GB	10,764 GB
Numero massimi iniziatori per sistema	256	512	512	1024
Numero di host a disponibilità elevata	128	256	256	512
Dimensione minima del form factor	6U	6U	6U	9U
Numero massimo di LUN standard	1024	1024	4096	4096
Istantanee SnapView	Sì	Sì	Sì	Sì
Cloni SnapView	Sì	Sì	Sì	Sì
Copia SAN	Sì	Sì	Sì	Sì
MirrorView/S	Sì	Sì	Sì	Sì
MirrorView/A	Sì	Sì	Sì	Sì
RecoverPoint/S	Sì	Sì	Sì	Sì
RecoverPoint/A	Sì	Sì	Sì	Sì

Passaggio 3: Selezionare un tipo di disco

In questo esempio vengono selezionati i dischi da 450 GB Fibre Channel a 15.000 rpm e ciò garantisce prestazioni e capacità I/O sufficienti per soddisfare i requisiti iniziali di un utente di Exchange.

Nota

Rispetto a quando sono stati eseguiti i primi test, i prezzi dei dischi da 600 GB a 10.000 rpm si sono ridotti notevolmente e quindi anche questi possono rappresentare una buona scelta in una distribuzione di questo tipo.

Passaggio 4: Selezionare un array

In questo esempio, la soluzione deve fornire 122 TB di spazio di archiviazione utilizzabile e 2.592 IOPS. Tutte le opzioni nella tabella precedente sono in grado di soddisfare i requisiti di IOPS, quindi la decisione deve basarsi solo sui requisiti di capacità. Il modello CLARiiON CX4-240 fornisce circa 100 TB di spazio utilizzabile con dischi da 450 GB in una configurazione di tipo RAID-5. Viene scelto il modello EMC CLARiiON CX4-480 perché fornisce lo spazio e le prestazioni I/O necessari per soddisfare tutti i requisiti di Exchange 2010.

Soluzioni testate per Exchange 2010

Requisiti per la memoria stimata delle cassette postali

Una corretta allocazione della memoria è fondamentale per ottenere un ambiente di Exchange che funzioni al meglio. È consigliabile consultare Concetti relativi alle configurazioni della memoria e alle prestazioni di Exchange e Informazioni sulla cache del database delle cassette postali.

Soluzioni testate per Exchange 2010

Calcolo della cache necessaria per il database

Il motore ESE (Extensible Storage Engine) utilizza la cache del database per ridurre le operazioni I/O. In genere, la dimensione della cache del database disponibile è inversamente proporzionale al numero di operazioni I/O generate su un server Cassette postali con Exchange 2010. Tuttavia, si arriva ad un punto in cui l'aggiunta di ulteriore cache del database non garantisce più una significativa riduzione nel valore IOPS. Di conseguenza, aggiungere grandi quantitativi di memoria fisica al server Exchange senza aver preventivamente individuato il valore ottimale per la cache del database potrebbe portare a costi maggiori a fronte di un aumento insignificante delle prestazioni.

Le stime per i valori IOPS completate in un passo precedente presuppongono che a ciascuna cassetta postale sia assegnata una quantità minima della cache del database. Questi valori minimi sono riportati nella tabella "Valori IOPS stimati per cassetta postale in base all'attività dei messaggi e alla cache del database delle cassette postali" in Informazioni sulla cache del database delle cassette postali.

Nella tabella seguente sono riportate le quantità di cache del database per ciascun utente in base a diversi profili messaggio.

Cache del database per utente

Messaggi inviati o ricevuti per cassetta postale al giorno (dimensione media dei messaggi circa 75 KB)	Cache del database per utente (MB)
50	3 MB
100	6 MB
150	9 MB
200	12 MB

In questo passo verranno stabilite i requisiti di memoria di alto livello per l'intero ambiente. In un passo successivo si utilizzerà questo risultato per stabilire la quantità di memoria fisica necessaria per ciascun server Cassette postali. Utilizzare la seguente formula:

Cache del database = cache del database specifica per il profilo × numero di utenti abilitati per le cassette postali

= 6 MB × 32.400

= 194.400 MB

= 190 GB

Soluzioni testate per Exchange 2010

Requisiti per la CPU stimata delle cassette postali

La pianificazione della capacità dei server Cassette postali è notevolmente cambiata rispetto alle precedenti versioni di Exchange a causa della presenza del nuovo modello di resilienza del database delle cassette postali fornito in Exchange 2010. Per ulteriori informazioni, vedere Pianificazione della capacità del processore del server Cassette postali.

Nei passi successivi, si calcoleranno i requisiti per i megacicli di alto livello per le copie attive e passive del database. Questi requisiti verranno utilizzati successivamente per stabilire il numero di server Cassette postali necessari per supportare il carico di lavoro. Notare che il numero di server Cassette postali necessari dipende anche dl modello di resilienza del server Cassette postali e dal layout delle copie del database.

L'utilizzo dei requisiti dei megacicli per stabilire il numero di utenti abilitati per le cassette postali che un server Cassette postali di Exchange può supportare non è una scienza esatta. Infatti, in ambienti di test e produzione sono numerosi i fattori che possono provocare risultati imprevisti per i megacicli. I megacicli devono essere utilizzati solamente per individuare il numero approssimativo di utenti abilitati per le cassette postali che un server Cassette postali di Exchange può supportare. Nel corso del processo di progettazione, quando si affronta la fase di pianificazione dello spazio è sempre preferibile mantenere un "basso livello".

I calcoli seguenti si basano sulle stime dei megacicli pubblicate come riportato nella seguente tabella.

Stime megacicli

Messaggi giornalieri inviati o ricevuti per ogni cassetta postale	Megacicli per ciascuna cassetta postale per il database delle cassette postali attive	Megacicli per ciascuna cassetta postale per il database delle cassette postali passive remote	Megacicli per ciascuna cassetta postale per il database delle cassette postali passive locali
50	1	0.1	0.15
100	2	0.2	0.3
150	3	0.3	0.45
200	4	0.4	0.6

Passaggio 1: Calcolare i requisiti per la CPU delle cassette postali attive

In questo passo si calcoleranno i megacicli necessari per supportare le copie attive del database utilizzando la seguente formula:

Megacicli delle cassette postali attive necessari = megacicli specifici per il profilo × numero di utenti abilitati per le cassette postali

= 2 × 32400

= 64800

Passaggio 2: Calcolare i requisiti per la CPU della copia del database remoto delle cassette postali attive

In un'architettura con tre copie per ciascun database, per conservare le copie del database sui server remoti è necessario un sovraccarico del processore associato alle registrazioni di spedizione. Generalmente, questo sovraccarico corrisponde al 10% dei megacicli delle cassette postali attive per ciascuna copia remota oggetto della manutenzione. Calcolare i requisiti utilizzando la seguente formula:

Megacicli delle copie remote necessari = megacicli specifici per il profilo × numero di utenti abilitati per le cassette postali × numero di copie remote

= 0.1 × 32400 × 2

= 6480

Passaggio 3: Calcolare i requisiti per la CPU delle cassette postali passive locali

In un'architettura con tre copie di ciascun database, al mantenimento delle copie passive locali di ciascun database è associato un sovraccarico del processore. In questo passo verranno calcolati i megacicli di alto livello necessari per supportare le copie passive locali dei database. Questi numeri verranno ritoccati in un passo successivo in modo che possano corrispondere alla strategia per la resilienza del sito e al layout delle copie del database. Calcolare i requisiti utilizzando la seguente formula:

Megacicli delle cassette postali passive remote necessari = megacicli specifici per il profilo × numero di utenti abilitati per le cassette postali × numero di copie passive

= 0.3 × 32400 × 2

= 19440

Passaggio 4: Calcolare i requisiti totali per la CPU

Calcolare i requisiti totali utilizzando la seguente formula:

Totale megacicli necessari = cassette postali attive + passive remote + passive locali

= 64800 + 6480 + 19440

= 90720

Megacicli medi per cassetta postale = 90.720 ÷ 32.400 = 2,8

Soluzioni testate per Exchange 2010

Riepilogo dei requisiti per le cassette postali

Nella tabella seguente viene fornito un prospetto riepilogativo del numero approssimativo di megacicli e della cache del database necessari per questo ambiente. Queste informazioni verranno utilizzate nei passi successivi per stabilire quali server distribuire nella soluzione.

Riepilogo dei requisiti per le cassette postali

Requisiti per la CPU delle cassette postali	Valore
Numero totale di megacicli necessari per l'intero ambiente	97200
Cache del database totale necessaria per l'intero ambiente	190 GB

Soluzioni testate per Exchange 2010

Scelta del modello del server

È possibile utilizzare i seguenti passi per scegliere il modello del server.

Passaggio 1: Individuare il proprio fornitore di fiducia per i server

In questa soluzione, la piattaforma server scelta è Cisco Unified Computing System, una piattaforma datacenter che racchiude funzionalità di elaborazione, gestione delle reti, accesso agli archivi e virtualizzazione in un unico sistema messo a punto per ridurre i costi di proprietà e massimizzare la flessibilità. Il sistema integra un'infrastruttura di rete unificata Ethernet da 10 GB a bassa latenza con server x86 per grandi organizzazioni. Grazie a un approccio sistemistico all'architettura, alla tecnologia, alle partnership e ai servizi, Cisco Unified Computing System ottimizza le risorse del datacenter, scala la fornitura dei servizi e riduce il numero di dispositivi da configurare, gestire, alimentare, raffreddare e cablare.

Passaggio 2: Esaminare le opzioni disponibili presso il proprio fornitore di fiducia

Cisco Unified Computing System è un sistema di server blade composto da quattro componenti principali. Questi componenti sono il Fabric Interconnect, lo chassis, i Fabric Extender (moduli I/O) e i server blade.

Per questa soluzione è possibile scegliere tra i seguenti modelli di server blade.

Opzione 1: Server blade B200

Il modello Cisco Unified Computing System modello B200 è un server blade a metà larghezza e a due socket. Il sistema utilizza due processori Intel Xeon 5500 o 5600, fino a 96 GB di memoria DDR3, due unità disco SAS con form factor ridotto opzionali che supportano lo swapping a caldo e un unico connettore in grado di gestire una velocità di trasferimento I/O fino a 20 GB al secondo (Gbps). Il server bilancia perfettamente semplicità, prestazioni e densità per gestire una virtualizzazione a livello di produzione e altri carichi di lavoro del datacenter mainstream.

Opzione 2: Server blade B250

Il modello Cisco Unified Computing System B250 è un server blade a larghezza completa e a due socket che può contare sulla tecnologia di memoria estesa Cisco. Il sistema supporta due processori Intel Xeon 5500 o 5600, fino a 384 GB di memoria DDR3, due unità disco SAS con form factor ridotto opzionali e due connettori in grado di gestire una velocità di trasferimento I/O fino a 40 GB al secondo (Gbps). Il server aumenta le prestazioni e lo spazio per la virtualizzazione e i carichi di lavoro di grandi dimensioni sui dataset.

Opzione 3: Server blade B440

Il server blade Cisco Unified Computing System B440 è stato messo a punto per potenziare le applicazioni aziendali, quali database con molte transazioni e dataset di grandi dimensioni, programmi ERP (Enterprise Resource Planning) e sistemi DSS (Decision Support System). Grazie alle funzionalità di affidabilità e prestazioni scalabili proprie dei processori Intel Xeon 7500, il server blade Cisco Unified Computing System B440 consente di accrescere l'ambito per la virtualizzazione del carico di lavoro e racchiude in un'unica infrastruttura integrata e semplificata le applicazioni standalone che necessitano di una notevole quantità di risorse. Il modello Cisco Unified Computing System B440 supporta fino a 32 core di elaborazione e 256 GB di memoria principale con una velocità di trasferimento I/O fino a 40 Gbps.

Passaggio 3: Selezionare un modello del server

Viene selezionato il server blade Cisco Unified Computing System B200 con processori Intel Xeon X5570 perché garantisce il bilanciamento ottimale tra potenza di elaborazione, capacità di memoria e form factor per questa distribuzione. Spesso, tenendo conto di tutti i fattori, inclusi costi e scalabilità, la piattaforma server a due socket si dimostra una buona scelta per le distribuzioni di Exchange 2010. Il server blade Cisco Unified Computing System B250 supporta una configurazione di memoria superiore e una maggiore velocità di trasferimento I/O, ma questo non è necessario per la soluzione in esame.

Nota

Soluzioni testate per Exchange 2010

Calcolo della capacità della CPU per il modello del server

Nei passi precedenti si sono calcolati i megacicli necessari per supportare il numero di utenti abilitati per le cassette postali attive. Nei passi successivi si stabilirà il numero di megacicli che il modello del server e il processore possono supportare così da individuare il numero di cassette postali attive che ciascun server può supportare.

Passaggio 1: Stabilire il benchmark per server e processore

Dal momento che i requisiti per i megacicli si basano su un modello di processore e server iniziale, è necessario rettificare il numero di megacicli disponibili per il server in base al modello iniziale. A tale scopo, vengono utilizzati dei benchmark delle prestazioni forniti dalla SPEC (Standard Performance Evaluation Corporation). La SPEC è una società senza fini di lucro fondata per definire, mantenere e sostenere l'utilizzo di un gruppo standardizzato di benchmark che possono essere applicati ai computer ad alte prestazioni di ultimissima generazione.

Per semplificare la procedura necessaria per ottenere il valore di benchmark per il server e il processore utilizzati, è disponibile lo strumento Exchange Processor Query. Questo strumento automatizza le operazioni manuali necessarie per stabilire il valore di benchmark SPECint 2006 del processore pianificato. Per eseguire questo strumento, il computer deve essere collegato a Internet. Lo strumento utilizza il modello del processore pianificato come input e quindi esegue una query sul sito Web Standard Performance Evaluation Corporation che restituisce tutti i dati ottenuti in ambiente di test per quello specifico modello di processore. Inoltre, lo strumento calcola un valore di benchmark SPECint 2006 medio basato sul numero di processori che si prevede di utilizzare in ciascun server Cassette postali. Utilizzare la seguente formula:

Processore = Intel X5570 da 2,93 GHz
Valore SPECint_rate2006 = 256
Valore SPECint_rate2006 per ogni processore core = 256 ÷ 8

= 32

Passaggio 2: Calcolare il numero rettificato di megacicli

Nei passi precedenti si sono calcolati i megacicli necessari per l'intero ambiente sulla base della stima dei megacicli per ogni cassetta postale. Queste stime sono state misura sulla base di un sistema iniziale (HP DL380 G5 x5470 3,33 GHz, 8 core) che ha un valore di benchmark SPECint_rate2006 pari a 150 (per un server a 8 core) o 18,75 per ogni core.

In questo passo è necessario rettificare il numero di megacicli disponibili per il processore e il server scelti rispetto al processore iniziale in modo da poter utilizzare i megacicli necessari per la pianificazione della capacità.

Per stabilire i megacicli della piattaforma Cisco B200-M1 Intel X5570 da 2,93 GHz, utilizzare le seguenti formule:

Numero rettificato di megacicli per core = (nuova piattaforma per valore core) × (hertz per core della piattaforma iniziale) ÷ (piattaforma iniziale per valore core)

= (32 × 3330) ÷ 18.75

= 5683
Numero rettificato di megacicli per ogni server = numero rettificato di megacicli per ogni core × numero di core

= 5683 × 8

= 45466

Passaggio 3: Calcolare il numero di megacicli disponibili per ogni server Cassette postali

Una volta ricavato il numero rettificato di megacicli per server, è necessario rettificare il valore target per l'utilizzo massimo del processore. In una sezione precedente si è stabilito di non superare l'80% dell'utilizzo del processore durante i picchi dei carichi di lavoro o in caso di errore. Utilizzare la seguente formula:

Numero rettificato di megacicli disponibili = megacicli disponibili per ogni server × valore target di utilizzo massimo del processore

= 45466 × 0.80

= 36372

Ogni server ha una capacità utilizzabile di 36.372 megacicli.

Soluzioni testate per Exchange 2010

Individuazione del numero di server Cassette postali fisici necessari

È possibile utilizzare la seguente procedura per stabilire il numero di server Cassette postali fisici necessari.

Passaggio 1: Stabilire il numero massimo di cassette postali attive supportate da un singolo server Cassette postali

Per stabilire il numero di cassette postali attive supportate da un server Cassette postali, utilizzare la seguente formula:

Numero delle cassette postali attive = megacicli disponibili per server ÷ megacicli per cassetta postale

= 36372 ÷ 2.8

= 12990

Passaggio 2: Stabilire il numero minimo di server Cassette postali necessari per sito per supportare il carico di lavoro necessario per ciascun gruppo di disponibilità del database

Ciascun gruppo di disponibilità del database ha 10.800 cassette postali attive. Per stabilire il numero minimo di server Cassette postali necessari per supportare tutte le cassette postali in un gruppo di disponibilità del database, utilizzare la seguente formula:

Numero di server necessari = numero totale di cassette postali per gruppo di disponibilità del database ÷ cassette postali attive per server

= 10800 ÷ 12990

= 0.83

È necessario almeno un server Cassette postali per ciascun gruppo di disponibilità del database per supportare il carico di lavoro di 10.800 cassette postali.

Passaggio 3: Stabilire il numero di server necessari per supportare la strategia per la resilienza delle cassette postali per ciascun gruppo di disponibilità del database

In un passo precedente si è scelto di impostare l'architettura in modo che tutte le copie fossero attivate in un gruppo di disponibilità del database di tipo Attivo/Passivo. Per questo modello è necessario che i ruoli server Cassette postali siano distribuiti in gruppi di tre per ciascun gruppo di disponibilità del database.

Numero di server Cassette postali e gruppi di disponibilità del database

Datacenter principale DAG1	Datacenter secondario DAG1	Datacenter principale DAG2	Datacenter secondario DAG2	Datacenter principale DAG3	Datacenter secondario DAG3	Numero totale di server Cassette postali
2	1	2	1	2	1	9
4	2	4	2	4	2	18
6	3	6	3	6	3	27

In base all'architettura del gruppo di disponibilità del database, sono necessari almeno tre server Cassette postali fisici in ciascun gruppo o nove server Cassette postali fisici per tutti e tre i gruppi.

Soluzioni testate per Exchange 2010

Stabilire il numero di cassette postali attive per server Cassette postali in scenari di normale operatività e di errore

Con la seguente procedura è possibile stabilire il numero di cassette postali attive per server Cassette postali in scenari di normale operatività e di errore.

Passaggio 1: Stabilire il numero di cassette postali attive per ogni server di Cassette postali in situazioni di normale operatività

Per stabilire il numero di cassette postali attive ospitate da ciascun server Cassette postali in scenari di normale operatività, utilizzare la seguente formula:

Numero di cassette postali per server = numero totale di cassette postali nel gruppo di disponibilità del database ÷ numero di server Cassette postali nel datacenter principale

= 10800 ÷ 2

= 5400

Passaggio 2: Stabilire il numero di cassette postali attive per ogni server Cassette postali in situazioni di errore di un server Cassette postali nel datacenter principale

Nel caso di errore di un server Cassette postali nel datacenter principale, le 5.400 cassette postali attive ospitate sul server in errore verranno attivate sull'altro server. In questo scenario, il server Cassette postali rimanente avrà 10.800 cassette postali attive.

Passaggio 3: Stabilire il numero di cassette postali attive per ogni server Cassette postali in situazioni di errore di entrambi i server Cassette postali nel datacenter principale

Se il datacenter principale si scollega, le 10.800 cassette postali attive nel datacenter principale verranno attivate nel datacenter secondario. In questo scenario, il server nel datacenter secondario avrà 10.800 cassette postali attive.

Soluzioni testate per Exchange 2010

Distribuzione dei ruoli server Accesso client e Trasporto Hub su diversi server fisici

Quando si deve stabilire il numero di ruoli server Accesso client e Trasporto Hub da distribuire negli ambienti con un numero ridotto di server, può essere opportuno decidere di distribuire entrambi i ruoli sulla stessa macchina fisica. In questo modo è possibile ridurre il numero di macchine fisiche da gestire, il numero di sistemi operativi server da aggiornare e manutenere e il numero di licenze Windows ed Exchange da acquistare. Inoltre, la scelta di combinare i ruoli server Accesso client e Trasporto Hub consente di semplificare l'architettura. Quando i ruoli vengono distribuiti su diverse macchine, è consigliabile distribuire un processore logico per Trasporto Hub ogni quattro processori logici per Cassette postali e tre processori logici per Accesso client ogni quattro processori logici per Cassette postali. Un modello di questo tipo può diventare confuso, soprattutto se è necessario disporre di un numero di server Accesso client e Trasporto Hub sufficiente per affrontare situazioni di manutenzione o errore di più server fisici. Quando si distribuiscono i server Accesso client, Trasporto Hub e Cassette postali su server fisici o macchine virtuali simili, è possibile distribuire una qualsiasi combinazione server Accesso client e server Trasporto Hub per ogni server Cassette postali nel sito.

* Punto decisionale *

In questa soluzione si è deciso di collocare i ruoli server Accesso cliente e Trasporto Hub sulla stessa macchina fisica. In questo modo si ridurrà il numero di sistemi operativi da gestire e si semplificherà la pianificazione della resilienza del server.

Soluzioni testate per Exchange 2010

Scelta del numero di combinazioni server Accesso client e server Trasporto Hub fisici necessarie

In un passo precedente si è stabilito che in ogni sito sono necessari tre server Cassette postali (due nel gruppo di disponibilità del database che ospita le cassette postali attive per quel sito e uno nel gruppo di disponibilità del database alternativo che supporta la resilienza del sito nel caso che si verifichi un errore nel datacenter principale per quel gruppo).

È consigliabile distribuire una combinazione server Accesso client e server Trasporto Hub per ciascun server Cassette postali, come indicato nella tabella seguente.

Numero di combinazioni server Accesso client e server Trasporto Hub fisici necessarie

Configurazione del ruolo del server	Rapporto dei core del processore consigliato
Cassette postali:ruoli server Accesso client e Trasporto Hub combinati	1:1

Quando nello stesso sito ci sono uno o più gruppi di disponibilità del database, è necessario esaminare la peggiore delle ipotesi per poter stabilire il numero di combinazioni server Accesso client e server Trasporto Hub necessarie. In questa soluzione, la peggiore delle ipotesi si verifica se uno dei server Cassette postali nel gruppo di disponibilità del database principale si scollega e contemporaneamente si verifica un errore nel sito in cui sono ospitate le cassette postali attive di un altro sito. In questo caso ci saranno 21.600 cassette postali attive nel sito su due server Cassette postali e di conseguenza saranno necessarie almeno due combinazioni server Accesso client e server Trasporto Hub in ciascun sito, come mostrato nella figura seguente.

Server Accesso client e Trasporto Hub

Soluzioni testate per Exchange 2010

Individuazione del numero totale di server fisici necessari

Finora si è stabilito che sono necessari 15 server fisici per supportare i ruoli server Accesso client, Trasporto Hub e Cassette postali per 32.400 cassette postali attive in tre datacenter, come mostrato nella figura seguente.

Numero di server fisici necessari

Soluzioni testate per Exchange 2010

Utilizzo della virtualizzazione server

Numerosi fattori sono importanti quando si desidera eseguire la virtualizzazione del server per Exchange. Per ulteriori informazioni sulle configurazioni supportate per la virtualizzazione, vedere Requisiti di sistema di Exchange 2010.

L'utilizzo di virtualizzazione con Exchange può essere opportuno nei seguenti casi:

Se si ritiene che la capacità del server sia sottoutilizzata e possa essere sfruttata meglio, la virtualizzazione potrebbe consentire di acquistare un numero inferiore di server.
Si desidera utilizzare Bilanciamento carico di rete di Microsoft Windows quando si distribuiscono i ruoli server Accesso client, Trasporto Hub e Cassette postali sullo stesso server fisico.
Se l'organizzazione utilizza la virtualizzazione in tutte le infrastrutture server, può essere opportuno utilizzarla anche con Exchange per adeguarsi ai criteri aziendali.

Per stabilire se utilizzare la virtualizzazione in questo ambiente, tenere conto dell'utilizzo previsto del processore e valutare se si ritiene che i server possano essere sottoutilizzati.

Passaggio 1: Stabilire l'utilizzo previsto della CPU del server Cassette postali in condizioni di normale operatività

Per stabilire l'utilizzo della CPU di 5.400 cassette postali attive su un unico server Cassette postali, utilizzare la seguente formula:

Utilizzo percentuale del processore (picco in condizioni di normale operatività) = megacicli necessari ÷ megacicli disponibili

= (5400 × 2.8) ÷ 45466

= 33.2%

Passaggio 2: Stabilire l'utilizzo previsto della CPU del server Cassette postali in condizioni di errore

Per stabilire l'utilizzo della CPU di 10,800 cassette postali attive su un unico server Cassette postali, utilizzare la seguente formula:

Utilizzo percentuale del processore (picco in condizioni di errore) = megacicli necessari ÷ megacicli disponibili

= (10800 × 2.8) ÷ 45466

= 66.5%

* Punto decisionale *

Dal momento che nella peggiore delle ipotesi si è immaginato un utilizzo target del server inferiore all'80% in caso di errore, utilizzando la virtualizzazione potrebbe essere necessario ridurre il numero di server. Questo argomento verrà trattato più dettagliatamente nei passi successivi.

Soluzioni testate per Exchange 2010

Utilizzo della virtualizzazione per ridurre il numero di server fisici

Nei passi successivi si stabilirà se è possibile utilizzare la virtualizzazione per ridurre il numero di server fisici necessari nella soluzione. Come la piattaforma di virtualizzazione si utilizzerà Microsoft Hyper-V.

Passaggio 1: Aggiungere la virtualizzazione al numero di server fisici esistenti

In fase di test, Microsoft Hyper-V supporta al massimo quattro processori virtuali per ogni macchina virtuale. Nell'architettura fisica, il ruolo server Cassette postali per il gruppo di disponibilità del database principale è stato distribuito su due server fisici con un totale di 16 processori logici. Aggiungendo la virtualizzazione, il ruolo server Cassette postali per il gruppo di disponibilità del database principale viene distribuito su quattro macchine virtuali, ciascuna con quattro processori virtuali per un totale di 16 processori virtuali.

Nell'architettura fisica, il ruolo server Cassette postali per il gruppo di disponibilità del database alternativo è stato distribuito su un unico server fisico con otto processori logici. Aggiungendo la virtualizzazione, il ruolo server Cassette postali per il gruppo di disponibilità del database alternativo viene distribuito su due macchine virtuali, ciascuna con quattro processori virtuali per un totale di 8 processori virtuali.

Nell'architettura fisica, la combinazione server Accesso client e server Trasporto Hub è stata distribuita su due server fisici con un totale di 16 processori logici. Aggiungendo la virtualizzazione, le combinazioni server Accesso client e server Trasporto Hub vengono distribuite su quattro macchine virtuali, ciascuna con quattro processori virtuali per un totale di 16 processori virtuali.

Quando si utilizzano i server radice Hyper-V con otto processori, è consigliabile distribuire una macchina virtuale del server Cassette postali e una macchina virtuale della combinazione server Accesso client e server Trasporto Hub su ciascun server radice Hyper-V.

A questo punto la soluzione dispone di 10 macchine virtuali su cinque server fisici in ciascun sito, come mostrato nella figura seguente.

Macchine virtuali

Passaggio 2: Ridurre il numero di server fisici

Sulla base dei calcoli eseguiti nei passi precedenti, si prevede che nella peggiore delle ipotesi i requisiti per i megacicli potranno essere gestiti da quattro server fisici. In questo passo si ridurrà il numero di server fisici da cinque a quattro e si ridistribuiranno i server Cassette postali nel gruppo di disponibilità del database alternativo sui quattro server fisici rimanenti. Per garantire una condizione di simmetria sui quattro server fisici, sarà necessario passare da due macchine virtuali del server Cassette postali (con quattro processi virtuali) a quattro macchine virtuali del server Cassette postali (con due processori virtuali).

A questo punto ci sono 12 macchine virtuali su quattro server fisici in ciascun sito, come mostrato nella figura seguente.

Macchine virtuali

Passaggio 3: Stabilire il numero di processori virtuali assegnati a ciascuna macchina virtuale

In questo passo si stabilirà il numero di processori virtuali necessari per ciascuna macchina virtuale. Nei passi successivi si eseguiranno i calcoli per verificare la correttezza dei valori stimati.

In condizioni di normale operatività, ciascuna delle quattro macchine virtuali del server Cassette postali nel gruppo di disponibilità del database supporterà il 25% delle 10.800 cassette postali attive nel gruppo, cioè ognuna supporterà 2.700 cassette postali. Nel caso che si verifichi un errore a livello di un server, la macchina virtuale del server Cassette postali rimanente dovrà supportare 5.400 attive.

Nel caso che si verifichi un errore a livello di sito, ciascuna delle quattro macchine virtuali del server Cassette postali nel gruppo di disponibilità principale supporterà il 25% delle 10.800 cassette postali attive nel gruppo, cioè ciascuna supporterà 2.700 cassette postali. In questo scenario, le cassette postali verranno eseguite su una terza copia del database. Nel caso che si verifichi un errore a livello di un server o macchina virtuale, la macchina virtuale rimanente dovrà supportare 5.400 attive. Il numero massimo di cassette postali sarà sempre 2.700.

È corretto che le macchine virtuali nel gruppo di disponibilità alternativo abbiano la metà dei processori rispetto alle macchine virtuali nel gruppo di disponibilità del database principale. In questa soluzione, si assegneranno quattro processori virtuali alle macchine virtuali nel gruppo di disponibilità del database principale e due processori virtuali alle macchine virtuali nel gruppo di disponibilità del database alternativo.

Se si mantiene un rapporto di 1:1 tra i processori logici e quelli virtuali, restano due processori virtuali per ciascuna combinazione server Accesso client e server Trasporto Hub. Dal momento che si desidera mantenere un rapporto di 1:1 tra i core del server Cassette postali e i core della combinazione server Accesso cliente e server Trasporto Hub, assegnare quattro processori virtuali a ciascuna combinazione server Accesso cliente e server Trasporto Hub. Ciò crea uno scenario in cui il numero di processori virtuali supera il numero di processori fisici sul server radice. Questa operazione viene definita oversubscription. Nella maggior parte dei casi si sconsiglia di utilizzare l'oversubscription. Tuttavia, in questa soluzione, le macchine virtuali del server Cassette postali nel gruppo di disponibilità del database alternativo verranno utilizzate solo in caso di errore a livello di sito. Poiché si tratta di un evento raro, una leggera oversubscription è accettabile.

Nella tabella seguente vengono indicate le allocazioni consigliate per i processori virtuali.

Allocazione dei processori virtuali

Macchina virtuale	Numero di processori virtuali
Combinazione Accesso client e Trasporto Hub	3
Cassette postali (gruppo di disponibilità del database principale)	4
Cassette postali (gruppo di disponibilità del database alternativo)	2
Totale	9

Soluzioni testate per Exchange 2010

Calcolo della capacità della CPU del server radice Hyper-V

Soluzioni testate per Exchange 2010

Rettifica del numero di megacicli disponibili per sovraccarico di virtualizzazione

Quando si distribuiscono le macchine virtuali sui server radice, è necessario tenere conto dei megacicli necessari per supportare l'hypervisor e lo stack di virtualizzazione. Questo sovraccarico varia da server a server e a fronte di diversi carichi di lavoro. Si utilizzerà un valore stimato pari al 10% dei megacicli disponibili, come mostrato nella seguente formula:

Numero rettificato di megacicli disponibili = megacicli disponibili x 0,90

= 45466 × 0.90

= 40919

Ciascun server ha una capacità utilizzabile per le macchine virtuali di 40.919 megacicli.

La capacità utilizzabile per processore logico è 5.115 megacicli.

Soluzioni testate per Exchange 2010

Individuazione della capacità della CPU delle macchine virtuali

In un passo precedente si è stabilita l'allocazione dei processori virtuali per i tre tipi di macchine virtuali, come mostrato nella tabella seguente.

Allocazione dei processori virtuali

Macchina virtuale	Numero di processori virtuali
Combinazione Accesso client e Trasporto Hub	3
Cassette postali (gruppo di disponibilità del database principale)	4
Cassette postali (gruppo di disponibilità del database alternativo)	2
Totale	9

Passaggio 1: Stabilire il numero di megacicli disponibili per ogni processore virtuale

Dal momento che ci sono nove processori virtuali su un server radice con otto processori logici, il numero di megacicli disponibili per un processore virtuale non è uguale al numero di megacicli disponibili per un processore logico. In questo passo si calcolerà il numero di megacicli disponibili per ogni processore virtuale:

Megacicli per processore virtuale = megacicli per processore logico × (numero di processori logici ÷ numero di processori virtuali)

= 5115 × (8 ÷ 9)

= 4547

Passaggio 2: Stabilire il numero di megacicli disponibili per ogni macchina virtuale

In questo passo, per stabilire il numero di megacicli disponibili per ogni macchina virtuale, fare riferimento alla tabella seguente.

Megacicli disponibili per macchina virtuale

Macchina virtuale	Numero di processori virtuali	Megacicli per processore virtuale	Megacicli disponibili
Combinazione Accesso client e Trasporto Hub	3	4547	13641
Cassette postali (gruppo di disponibilità del database principale)	4	4547	18188
Cassette postali (gruppo di disponibilità del database alternativo)	2	4547	9094

Passaggio 3: Stabilire il target di megacicli disponibili per ogni macchina virtuale

Dal momento che i presupposti del progetto prevedono che l'utilizzo del processore non debba superare l'80%, rettificare il numero di megacicli disponibili in modo che si adatti al target dell'80%, come mostrato nella tabella seguente.

Target di megacicli disponibili per macchina virtuale

Macchina virtuale	Megacicli disponibili	Utilizzo massimo processore	Target megacicli disponibili
Combinazione Accesso client e Trasporto Hub	13641	80%	10913
Cassette postali (gruppo di disponibilità del database principale)	18188	80%	14550
Cassette postali (gruppo di disponibilità del database alternativo)	9094	80%	7275

Soluzioni testate per Exchange 2010

Verifica della capacità della CPU delle macchine virtuali del server Cassette postali principale

Per verificare la capacità della CPU delle macchine virtuali del server Cassette postali principale, fare quanto segue.

Passaggio 1: Stabilire i requisiti per i megacicli nella peggiore delle ipotesi

Nella peggiore delle ipotesi, il carico di lavoro del server Cassette postali principale raggiunge un picco di 5.400 cassette postali attive in condizioni di manutenzione o errore del server e con le altre due copie remote sottoposte a manutenzione (ad esempio, a seguito di un ripristino in cui le copie passive vengono aggiornate, ma le cassette postali attive non sono ancora state ritrasferite sul server di destinazione). In questo passo si stabiliranno i requisiti a livello di megacicli per la macchina virtuale del server Cassette postali principale utilizzando la seguente formula:

Megacicli necessari per Cassette postali = (numero di utenti abilitati per le cassette postali × megacicli specifici per il profilo) + numero di copie del database remote × (numero di utenti abilitati per le cassette postali × megacicli specifici per il profilo × 10%)

= (5400 × 2) + 2 × (5400 × 2 × 0.1)

= 10800 + 2160

= 12960

Passaggio 2: Stabilire se le macchine virtuali del server Cassette postali principale possono supportare il carico di lavoro nella peggiore delle ipotesi

In questo passo si verificherà se il numero di megacicli disponibili supera il numero di megacicli necessari. Sono necessari 12.960 megacicli e se ne hanno disponibili 14.550, quindi la macchina virtuale del server Cassette postali principale ha una capacità sufficiente per supportare 5.400 cassette postali attive.

Soluzioni testate per Exchange 2010

Verifica della capacità della CPU delle macchine virtuali del server Cassette postali secondario

Per verificare la capacità della CPU delle macchine virtuali del server Cassette postali secondario, fare quanto segue.

Passaggio 1: Stabilire i requisiti per i megacicli nella peggiore delle ipotesi

Nella peggiore delle ipotesi, il carico di lavoro del server Cassette postali secondario raggiunge un picco di 2.700 cassette postali attive a fronte di un errore a livello di sito e con le altre due copie remote sottoposte a manutenzione (ad esempio, a seguito della riattivazione del sito originale sul quale è in corso l'aggiornamento delle copie principale e secondaria originali, ma senza che le cassette postali attive siano ancora state ritrasferite sul server originale). In questo passo si stabiliranno i requisiti a livello di megacicli per la macchina virtuale del server Cassette postali secondario utilizzando la seguente formula:

Megacicli necessari per Cassette postali = (numero di utenti abilitati per le cassette postali × megacicli specifici per il profilo) + numero di copie del database remote × (numero di utenti abilitati per le cassette postali × megacicli specifici per il profilo × 10%)

= (2700 × 2) + 2 × (2700 × 2 × 0.1)

= 5400 + 1080

= 6480

Passaggio 2: Stabilire se le macchine virtuali del server Cassette postali principale possono supportare il carico di lavoro nella peggiore delle ipotesi

In questo passo si verificherà se il numero di megacicli disponibili supera il numero di megacicli necessari. Sono necessari 6.480 megacicli e se ne hanno disponibili 7.275, quindi la macchina virtuale del server Cassette postali secondario ha una capacità sufficiente per supportare 2.700 cassette postali attive.

Soluzioni testate per Exchange 2010

Individuazione della quantità di memoria necessaria per ogni macchina virtuale del server Cassette postali principale

È possibile utilizzare la seguente procedura per stabilire la quantità di memoria necessaria per ogni macchina virtuale del server Cassette postali principale.

Passaggio 1: Stabilire i requisiti per la cache del database per ogni server nel caso di errore più grave

In un passo precedente si è stabilito che la dimensione della cache del database per tutte le cassette postali deve essere di 190 GB e la dimensione media della cache per ogni cassetta postale attiva deve essere di 6 MB.

Per prefigurare lo scenario peggiore si calcolerà la dimensione necessaria per la cache del database basandosi su 5.400 cassette postali attive sulle macchine virtuali degli altri server Cassette postali:

Memoria necessaria per la cache del database = numero di cassette postali attive × cache media per cassetta postale

= 5400 × 6 MB

= 32.400 MB

= 31,6 GB

Passaggio 2: Stabilire i requisiti per la memoria totale per ogni macchina virtuale del server Cassette postali nel caso di errore più grave

In questo passo fare riferimento alla seguente tabella per individuare la configurazione di memoria consigliata.

Requisiti di memoria

Memoria fisica del server (RAM)	Dimensione della cache del database (solo ruolo server Cassette postali)
24 GB	17,6 GB
32 GB	24,4 GB
48 GB	39,2 GB

La configurazione di memoria consigliata per supportare 31.6 GB di cache del database per un ruolo server Cassette postali è di 48 GB.

Soluzioni testate per Exchange 2010

Individuazione della quantità di memoria necessaria per ogni macchina virtuale del server Cassette postali secondario

È possibile utilizzare la seguente procedura per stabilire la quantità di memoria necessaria per ogni macchina virtuale del server Cassette postali secondario.

Passaggio 1: Stabilire i requisiti per la cache del database per ogni server nel caso di errore più grave

Per prefigurare lo scenario peggiore si calcolerà la dimensione necessaria per la cache del database basandosi su 2.700 cassette postali attive sulle macchine virtuali del server Cassette postali secondario:

Memoria necessaria per la cache del database = numero di cassette postali attive × cache media per cassetta postale

= 2.700 × 6 MB

= 16.200 MB

= 15,8 GB

Passaggio 2: Stabilire i requisiti per la memoria totale per ogni macchina virtuale del server Cassette postali nel caso di errore più grave

In questo passo fare riferimento alla seguente tabella per individuare la configurazione di memoria consigliata.

Requisiti di memoria

Memoria fisica del server (RAM)	Dimensione della cache del database (solo ruolo server Cassette postali)	Dimensione della cache del database (più ruoli server, ad esempio Cassette postali e Trasporto Hub)
24 GB	17,6 GB	14 GB
32 GB	24,4 GB	20 GB
48 GB	39,2 GB	32 GB

La configurazione di memoria consigliata per supportare 15,8 GB di cache del database per un ruolo server Cassette postali è di 24 GB.

Soluzioni testate per Exchange 2010

Individuazione della quantità di memoria necessaria per ogni combinazione server Accesso client e server Trasporto Hub

Per individuare la configurazione di memoria per ogni macchina virtuale della combinazione server Accesso client e server Trasporto Hub, fare riferimento alla tabella seguente.

Configurazioni di memoria per i server Exchange 2010 in base ai ruoli del server installati

Ruolo del server Exchange 2010	Minima supportata	Massimo consigliato
Combinazione server Accesso client e server Trasporto Hub (con i ruoli server Accesso client e Trasporto Hub in esecuzione sullo stesso server fisico)	4 GB	2 GB per ogni core (almeno 8 GB)

Dal momento che la macchina virtuale della combinazione server Accesso client e server Trasporto Hub ha tre processori virtuali, 6 GB di memoria vengono allocati a ciascuna macchina virtuale della combinazione di server Accesso client e server Trasporto Hub.

Soluzioni testate per Exchange 2010

Individuazione della quantità di memoria necessaria per ogni server radice Hyper-V

Per stabilire la quantità di memoria necessaria per ogni server radice Hyper-V, utilizzare la seguente formula:

Memoria del server radice = memoria del sistema operativo radice + memoria della macchina virtuale della combinazione di server Accesso client e server Trasporto Hub + memoria della macchina virtuale del server Cassette postali principale + memoria della macchina virtuale del server Cassette postali secondario

= 4 GB + 6 GB + 48 GB + 24 GB

= 82 GB

La quantità di memoria fisica necessaria per il server radice è 82 GB. In base alle configurazioni di memoria fisica consigliate, al server verranno assegnati 96 GB.

Soluzioni testate per Exchange 2010

Progettazione dei gruppi di disponibilità del database

In un passo precedente si è stabilito che la soluzione sarebbe stata costituita da tre gruppi di disponibilità del database e che ciascuno di questi si sarebbe esteso su due delle tre ubicazioni fisiche. Una volta stabiliti il numero di server Cassette postali necessari per supportare il carico di lavoro e i requisiti per i gruppi di disponibilità del database, è possibile proseguire con la progettazione dei gruppi.

Progettazione del gruppo di disponibilità del database

Soluzioni testate per Exchange 2010

Progettazione del layout delle copie del database

Per progettare il layout delle copie del database, fare quanto segue.

Passaggio 1: Stabilire il numero di database Exchange univoci nel gruppo di disponibilità del database

Per stabilire il numero ottimale di database Exchange da distribuire, utilizzare lo strumento Exchange 2010 Mailbox Server Role Requirements Calculator. Immettere le informazioni appropriate nella scheda e quindi selezionare Yes per Automatically Calculate Number of Databases / DAG. Nel campo per il limite della dimensione della cassetta postale immettere il valore 2.048 MB che corrisponde alla quota della cassetta postale con provisioning completo.

Database Exchange nel gruppo di disponibilità del database

Nella scheda Role Requirements viene visualizzato il numero consigliato di database. Per questa soluzione, lo strumento consiglia che ciascun gruppo di disponibilità del database abbia almeno 24 database univoci.

* Punto decisionale *

Applicando quanto consigliato dallo strumento, verranno distribuiti 24 database per ogni gruppo di disponibilità del database.

Passaggio 2: Stabilire il layout del database in condizioni di normale operatività

Dal momento che nel gruppo di disponibilità del database sono presenti 24 database univoci e otto server, ciascuno dei quattro server nel sito principale ospiterà sei copie attive del database in condizioni di normale operatività.

Iniziare aggiungendo le copie attive del database ai quattro server, come mostrato nella tabella seguente.

Layout del database in condizioni di normale operatività

Database	MBX1	MBX2	MBX3	MBX4
DB1-6	A1
DB7-12		A1
DB13-18			A1
DB19-24				A1

Legenda della tabella:

A1 = copia attiva del database

In un passo precedente si è stabilito che la strategia per la resilienza del server Cassette postali sarebbe stata messa a punto avendo come obiettivo principale l'efficienza operativa. I server Cassette postali verranno distribuiti in coppie.

Dal momento che nel gruppo di disponibilità del database ci sono quattro server Cassette postali, i server 1 e 2 saranno una coppia e i server 3 e 4 saranno una coppia. In questo passo si aggiungeranno le copie passive del database (P1) al server alternativo in ciascuna coppia, come mostrato nella tabella seguente.

Layout del database in condizioni di normale operatività con copie passive

Database	MBX1	MBX2	MBX3	MBX4
DB1-6	A1	P1
DB7-12	P1	A1
DB13-18			A1	P1
DB19-24			P1	A1

Legenda della tabella:

A1 = copia attiva del database
P1 = copia passiva del database

Passaggio 3: Stabilire il layout del database in caso di manutenzione del server o errore del server nel sito

Durante la manutenzione o in caso di errore di un server, le copie P1 vengono attivate sul server alternativo. Nella tabella seguente viene illustrata questa situazione con i server MBX2 e MBX4 non attivi perché sottoposti a manutenzione.

Layout delle copie del database in caso di manutenzione del server o errore del server nel sito

Legenda della tabella:

A1 = copia attiva del database
P1 = copia passiva del database

Passaggio 4: Aggiungere le copie dei database al datacenter secondario per supportare la resilienza del sito

In questo passo si aggiungerà una terza copia del database ai membri del gruppo di disponibilità del database nel datacenter secondario per garantire la resilienza del sito, come mostrato nella tabella seguente.

Copie database aggiunte al datacenter secondario per supportare la resilienza del sito

Database	MBX1 sitoA	MBX2 sitoA	MBX3 sitoA	MBX4 sitoA	MBX5 sitoB	MBX6 sitoB	MBX7 sitoB	MBX8 sitoB
DB1-6	A1	P1			P2
DB7-12	P1	A1				P2
DB13-18			A1	P1			P2
DB19-24			P1	A1				P2

Legenda della tabella:

A1 = copia attiva del database
P1 = copia passiva del database locale
P2 = copia passiva del database remota

Passaggio 5: Stabilire il layout del database in caso di errore del sito

In caso di errore del datacenter principale, le copie P2 verranno attivate nel sito secondario, come mostrato nella tabella seguente. Notare che fino a quanto il sito principale non ritorna attivo, ci sarà un'unica copia del database.

Layout del database in caso di errore del sito

Legenda della tabella:

A1 = copia attiva del database
P1 = copia passiva del database
P2 = copia passiva del database

Soluzioni testate per Exchange 2010

Modalità di coordinamento dell'attivazione del datacenter

La modalità di coordinamento dell'attivazione del datacenter consente di controllare il comportamento di attivazione di un gruppo di disponibilità del database in presenza di un errore irreparabile che coinvolge il gruppo (ad esempio, un errore completo di uno dei datacenter). Se la modalità DAC non è abilitata e si verifica un errore che coinvolge più server nel gruppo DAG, quando dopo l'errore viene ripristinata la maggior parte dei membri DAG, il gruppo DAG si riavvierà e riproverà a installare i database. In una configurazione con più datacenter, questo comportamento potrebbe provocare la sindrome "split brain", una condizione che si verifica quando tutte le reti smettono di funzionare e i membri del gruppo di disponibilità del database non riescono più scambiarsi i segnali heartbeat. La sindrome split brain si può verificare anche quando la connettività di rete tra i datacenter viene interrotta. È possibile evitare questa sindrome e mantenere il gruppo DAG operativo, facendo in modo che la maggior parte dei membri del gruppo DAG (e, nel caso di gruppi DAG con un numero pari di membri, il server di controllo) sia sempre disponibile e in grado di interagire. Per ulteriori informazioni, vedere Informazioni sulla modalità di coordinamento dell'attivazione del centro dati.

* Punto decisionale *

La modalità di coordinamento dell'attivazione del datacenter sarà abilitata per tutti e tre i gruppi di disponibilità del database nell'ambiente per evitare che si verifichi la sindrome split brain.

Soluzioni testate per Exchange 2010

Posizionamento del witness di condivisione file

In Exchange 2010, il gruppo di disponibilità del database utilizza un insieme minimo di componenti dal clustering di failover di Windows. Uno di questi componenti è la risorsa quorum che rappresenta uno strumento di arbitraggio quando si deve stabilire lo stato di un cluster e si devono prende decisioni relative all'appartenenza al gruppo. È fondamentale che ogni membro del gruppo di disponibilità del database abbia un'idea chiara di come è configurato il cluster alla base del gruppo. Il quorum viene utilizzato come l'archivio in cui sono memorizzate tutte le informazioni di configurazione relative al cluster. Per evitare la sindrome split brain, il quorum viene utilizzato anche per risolvere eventuali conflitti. La sindrome split brain si verifica quando i membri del gruppo di disponibilità del database non riescono a comunicare tra loro pur essendo attivi e in esecuzione. È possibile evitare questa sindrome e mantenere il gruppo di disponibilità del database operativo, facendo in modo che la maggioranza dei membri del gruppo (e, nel caso dei gruppi con un numero dispari di membri, il server di controllo) sia sempre disponibile e in grado di interagire.

Un server di controllo è un server che si trova all'esterno di un gruppo di disponibilità del database e che viene utilizzato per ottenere e mantenere il quorum quando il gruppo di disponibilità del database ha un numero pari di membri. I gruppi di disponibilità del database con un numero dispari di membri non utilizzano un server di controllo. Quando si crea un gruppo di disponibilità del database, per impostazione predefinita il witness di condivisione file viene aggiunto a un server Trasposto Hub (su cui non è installato il ruolo server Cassette postali) nello stesso sito del primo membro del gruppo. Se il server Trasporto Hub è in esecuzione su una macchina virtuale che si trova sullo stesso server radice delle macchine virtuali su cui è in esecuzione il ruolo server Cassette postali, è consigliabile spostare il witness di condivisione file su un altro server a disponibilità elevata. È possibile spostare il witness di condivisione file su un controller di dominio, ma è consigliabile eseguire questa scelta solo in casi estremi per le implicazioni che comporta a livello di sicurezza.

Nelle soluzioni dove il gruppo di disponibilità del database si estende su più siti, è consigliabile definire un witness di condivisione file per il sito secondario. In questo modo, il cluster potrà conservare il quorum anche in caso di errore del sito se è abilitata la modalità di coordinazione dell'attivazione del database.

* Punto decisionale *

Dal momento che si è scelto di distribuire tre gruppi di disponibilità del database e tutti hanno membri in diversi siti, è necessario definire tre directory di controllo principali e tre directory di controllo alternative. Queste directory si troveranno sui file server all'interno di ciascun sito.

Soluzioni testate per Exchange 2010

Pianificazione dello spazi dei nomi

Quando si pianifica l'organizzazione Exchange 2010, una delle decisioni più importanti da prendere è come organizzare lo spazio dei nomi esterno. Lo spazio dei nomi è una struttura logica generalmente rappresentata da un nome di dominio nel DNS (Domain Name System). Quando si definisce lo spazio dei nomi, è necessario considerare le diverse ubicazioni dei client e dei server in cui sono si trovano le cassette postali. Oltre alle ubicazioni fisiche dei client, è necessario valutare la loro modalità di connessione a Exchange 2010. Da queste valutazioni dipende il numero degli spazi dei nomi necessari. Gli spazi dei nomi saranno generalmente allineati alla configurazione DNS. È consigliabile che ogni sito di Active Directory in una regione che dispone di uno o più server Accesso client con connessione a Internet disponga di uno spazio dei nomi univoco. Generalmente, questo è rappresentato nel DNS da un record A, ad esempio mail.contoso.com o mail.europe.contoso.com.

Per ulteriori informazioni, vedere Informazioni sugli spazi dei nomi dei server Accesso client.

Ci sono diversi modi per organizzare gli spazi dei nomi esterni, ma generalmente è sufficiente applicare uno dei seguenti modelli per soddisfare i propri requisiti:

Modello di datacenter consolidato Questo modello è costituito da un unico sito fisico. Tutti i server si trovano in quell'unico sito ed esiste un unico spazio dei nomi, ad esempio mail.contoso.com.
Spazio dei nomi singolo con siti proxy Questo modello è costituito da più siti fisici. Un solo sito contiene un server Accesso client con connessione a Internet. Gli altri siti fisici non interfacciano con Internet. In questo modello esiste un solo spazio dei nomi per i siti, ad esempio, mail.contoso.com.
Spazio dei nomi singolo con siti proxy Questo modello è costituito da più siti fisici. Ciascun sito può avere un server Accesso client con connessione a Internet. In alternativa, potrebbe esserci un solo sito che contiene i server Accesso client con connessione a Internet. In questo modello esiste un solo spazio dei nomi per i siti, ad esempio, mail.contoso.com.
Spazi dei nomi regionali Questo modello è costituito da più siti fisici e più spazi dei nomi. Ad esempio, un sito che si trova a New York avrà lo spazio dei nomi mail.usa.contoso.com, un sito che si trova a Toronto avrà lo spazio dei nomi mail.canada.contoso.com e un sito che si trova a Londra avrà lo spazio dei nomi mail.europe.contoso.com.
Più foreste Questo modello è costituito da più foreste con più spazi dei nomi. Un'organizzazione che utilizza questo modello potrebbe essere composta da due società partner, ad esempio, Contoso e Fabrikam. Gli spazi dei nomi potrebbero includere mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.fabrikam.com e mail.europe.fabrikam.com.

* Punto decisionale *

In questo scenario si applica il modello degli spazi dei nomi regionali perché è quello più adatto per le organizzazioni con cassette postali attive in più siti.

Il vantaggio di questo modello è rappresentato dalla riduzione dagli inoltri tramite proxy resa possibile dal fatto che una percentuale notevole di utenti può connettersi a un server Accesso cliente nello stesso sito di Active Directory in cui si trova il server Cassette postali. In tal modo migliorano le prestazioni per l'utente finale. Per gli utenti con cassette postali in un sito che non dispone di un server Accesso client con connessione a Internet continuerà ad essere utilizzato l'inoltro tramite proxy.

Questa soluzione ha anche i seguenti requisiti di configurazione:

È necessario gestire più record DNS.
È necessario richiedere, configurare e gestire più certificati.
La gestione della protezione è più complessa perché ciascun sito con connessione a Internet necessita di un computer con Microsoft Forefront Threat Management Gateway o un'altra soluzione firewall o proxy inverso.
Gli utenti devono connettersi al proprio spazio dei nomi regionale. Ciò può causare più richieste di supporto al servizio di assistenza e rendere necessaria una maggiore formazione.

Soluzioni testate per Exchange 2010

Array del server Accesso client e strategia per il bilanciamento del carico

In Exchange 2010, i servizi Accesso client RPC e Rubrica di Exchange sono stati inseriti nel ruolo server Accesso client per migliorare l'operatività degli utenti abilitati per le cassette postali quando la copia del database delle cassette postali attive viene spostata su un altro server Cassette postali (ad esempio, in caso di manutenzione o errore del database delle cassette postali). Gli endpoint di connessione per l'accesso alle cassette postali da Microsoft Outlook e altri client MAPI sono stati spostati dal ruolo server Cassette postali al ruolo server Accesso client. Di conseguenza, è necessario bilanciare le connessioni interne ed esterne di Outlook tra tutti i server Accesso client nel sito per ottenere un'adeguata tolleranza degli errori. Per associare l'endpoint MAPI a un gruppo di server Accesso client piuttosto che a uno specifico server Accesso client, è possibile definire un array di server Accesso client. È possibile configurare un solo array per ogni sito di Active Directory e un array non estendersi su più siti di Active Directory. Per ulteriori informazioni, vedere Informazioni su Accesso client RPC e Understanding Load Balancing in Exchange.

* Punto decisionale *

Dal momento che questa è una distribuzione su tre siti con quattro server con ruolo Accesso client in ciascun sito, in totale ci saranno tre array di server Accesso client. Per distribuire il carico tra gli array di server Accesso client in ciascun sito si utilizzerà una soluzione per il bilanciamento del carico hardware.

Soluzioni testate per Exchange 2010

Individuazione del modello per il bilanciamento del carico hardware

Per stabilire un modello per il bilanciamento del carico hardware, fare quanto segue.

Passaggio 1: Individuare il proprio fornitore di fiducia per le soluzioni di bilanciamento del carico hardware

In questo esempio, il fornitore di fiducia è Cisco perché la linea di prodotti Cisco Application Control Engine (ACE) è perfettamente compatibile con i componenti Cisco Unified Computing System scelti per il server, la rete e il sistema di archiviazione.

La linea di prodotti Cisco ACE fornisce una soluzione con un datacenter scalabile e a disponibilità elevata perfetta per l'ambiente di Exchange 2010. I prodotti Cisco ACE offrono un ottimo livello di interoperabilità, con i seguenti vantaggi:

Prestazioni, scalabilità, velocità di trasmissione e disponibilità delle applicazioni
Progettazione basata sugli standard
Architettura virtuale con partizionamento del dispositivo
Amministrazione basata sui ruoli e gestione centralizzata
Servizi di sicurezza tramite una verifica approfondita dei pacchetti, elenchi di controllo degli accessi, Unicast Reverse Path Forwarding e conversione degli indirizzi di rete e di porta

Passaggio 2: Esaminare le opzioni disponibili presso il proprio fornitore di fiducia

La linea di prodotti Cisco ACE include due diversi modelli per il bilanciamento del carico hardware in grado di fornire una soluzione con datacenter scalabile e a disponibilità elevata perfetta per l'ambiente applicativo di Exchange 2010. Questi modelli sono Cisco ACE 4710 e il modulo per il servizio integrato nelle piattaforme Cisco Catalyst 6500/Cisco 7600.

Cisco ACE 4710 offre una velocità di trasmissione fino a 4 Gbps in un form factor di tipo 1RU, aggiornabile tramite licenza software, che garantisce un'ottima scalabilità e una buona protezione degli investimenti a lungo termine. Il 4710 è uno chassis in rack di tipo 1U dotato di scheda acceleratore Cavium Nitrox Octeon e porte Ethernet da 4 Gb che possono essere unificate tramite Cisco EtherChannel e connesse a uno switch. Per impostazione predefinita, Cisco ACE 4710 supporta la virtualizzazione con un dispositivo amministratore e quattro dispositivi utente, una larghezza di banda pari a 1 Gbps, 1.000 transazioni SSL (Secure Sockets Layer) al secondo e una compressione di 100 Mbps. È possibile espandere questa soluzione senza dover aggiungere altri componenti hardware, semplicemente utilizzando i seguenti aggiornamenti per le licenze software:

Velocità di trasmissione Il valore predefinito pari a 1 Gbps può essere portato fino a 2 o 4 Gbps.
Dispositivi virtuali È possibile aumentare il numero di dispositivi virtuali passando da 5 a 20.
Transazioni SSL al secondo Il valore delle transazioni SSL al secondo può essere portato da 1.000 a 5.000 o persino 7.500.
Compressione La compressione per la velocità di trasmissione può essere portata a 500 Mbps o persino a 1 o 2 Gbps.
Controllo di accesso basato sui ruoli La gestione centralizzata basata sui ruoli viene eseguita attraverso l'interfaccia grafica per la gestione delle applicazioni o l'interfaccia della riga di comando.
Disponibilità elevata Le configurazioni ridondanti sono supportate (intraappliance e intercontesto).

Il modulo Cisco ACE per gli switch della serie Cisco Catalyst 6500 o i router della serie Cisco 7600 garantisce una velocità di trasmissione fino a 16 Gbps in un modulo form factor a uno slot che, come nel caso di ACE 4710, può essere aggiornato attraverso le licenze software. In uno switch della serie Cisco Catalyst 6500 o router della serie Cisco 7600 è possibile installare fino a quattro moduli Cisco ACE. Ciascuno può supportare i processi di più unità aziendali indipendenti e ciò consente di sfruttare al meglio la vasta gamma di opzioni di connessione disponibili per lo switch e il router. L'amministratore di sistema stabilisce i requisiti per le applicazioni e assegna i servizi di rete appropriati nell'ambito dei contesti virtuali. Ogni contesto racchiude un suo insieme di criteri, interfacce, risorse e amministratori:

Velocità di trasmissione I servizi per il bilanciamento del carico forniscono una velocità di trasmissione fino a 16 Gbps e 345.000 connessioni a 4 layer al secondo.
Dispositivi virtuali È possibile aumentare il numero di dispositivi virtuali passando da 5 a 250.
Transazioni SSL al secondo Le transazioni SSL al secondo possono essere portate a 15.000 sui moduli ACE20 e a 30.000 sui moduli ACE30.
Compressione La compressione può essere aumentata a 6 Gbps sui moduli ACE30.
Controllo di accesso basato sui ruoli La gestione centralizzata basata sui ruoli viene eseguita attraverso l'interfaccia grafica per la gestione delle applicazioni o l'interfaccia della riga di comando.
Disponibilità elevata Le configurazioni ridondanti sono supportate (intrachassis, interchassis, intercontesto).

Passaggio 3: Selezionare un modello per il bilanciamento del carico hardware

È stato selezionato il prodotto Cisco ACE 4710 perché garantisce la massima disponibilità applicativa, un ottimo livello di sicurezza, un'architettura virtualizzata e un buon grado di protezione dell'investimento:

Massima disponibilità dell'applicazione Cisco ACE 4710 garantisce la continuità aziendale e il supporto ai clienti finali grazie all'ottimizzazione della disponibilità attraverso l'alta scalabiità del bilanciamento del carico su 4 layer e dello switching dei contenuti su 7 layer che consente anche di minimizzare l'effetto di potenziali errori a livello di applicazione o dispositivo.
Ottimo livello di sicurezza Cisco ACE 4710 funge da strumento di difesa del server contro le minacce a livello di applicazioni e gli attacchi di tipo Denial of Service grazie a funzionalità quali la verifica approfondita dei pacchetti, la protezione di reti e protocolli e le funzioni di controllo degli accessi altamente scalabili.
Architettura virtualizzata L'architettura virtualizzata rappresenta un elemento chiave nella progettazione di Cisco ACE e un'offerta unica rispetto ad altre soluzioni presenti sul mercato. I manager IT possono configurare fino a 20 dispositivi virtuali su un unico modulo Cisco ACE 4710. Il vantaggio principale è rappresentato dal ridotto numero di dispositivi da gestire a fronte di un aumento nella distribuzione delle applicazioni, una notevole riduzione nei costi di alimentazione e raffreddamento e una velocizzazione del supporto per le nuove applicazioni.

Soluzioni testate per Exchange 2010

Progettazione dell'archiviazione

Una soluzione di archiviazione progettata correttamente è fondamentale per la distribuzione del ruolo server Cassette postali di Exchange 2010 . Per ulteriori informazioni, vedere Progettazione dell'archiviazione del server Cassette postali.

Passaggio 1: Riepilogare i requisiti per l'archiviazione

Nella tabella seguente sono riepilogati i requisiti per l'archiviazione calcolati o stabiliti in un passo precedente.

Riepilogo dei requisiti per lo spazio su disco

Requisito	Valore
Dimensione delle cassette postali su disco per una cassetta postale da 2 GB (MB)	2301
Capacità totale necessaria per il database (GB)	120128
Capacità totale necessaria per il registro (GB)	3974
Capacità totale necessaria (GB)	124102
Capacità totale necessaria per tre copie del database (GB)	372306
Capacità totale necessaria per tre copie del database (TB)	364
Capacità totale necessaria per ciascun sito (TB)	122

Passaggio 2: Stabilire se utilizzare un provisioning di tipo virtual o thin

Numerosi clienti desiderano aumentare sensibilmente le quote delle cassette postali quando passano a Exchange 2010. Tuttavia, l'aumento delle dimensioni delle cassette postali da diverse centinaia di megabyte a diverse centinaia di gigabyte potrebbe richiedere del tempo. In questo caso, alcune organizzazioni potrebbero scegliere di rimandare l'acquisto di ulteriore memoria fino a quando i prezzi non saranno inferiori.

Numerosi fornitori di sistemi di archiviazione offrono delle soluzioni di thin provisioning che consentono di offrire al server Exchange uno spazio di archiviazione superiore a quello effettivamente disponibile per poi aggiungere spazio fisico per soddisfare l'aumento della richiesta senza che ciò comporti interruzioni o tempo di inattività. Questo sistema riduce i costi totali di proprietà in quanto limita l'allocazione iniziale di memoria e semplifica la gestione riducendo il numero di operazioni necessarie per supportare la crescita.

La soluzione di archiviazione EMC consente di implementare il thin provisioning attraverso una funzionalità di virtual provisioning che supporta la creazione di hot-spare e proactive-spare, un'espansione thin pool che non comporta interruzioni e la possibilità di eseguire la migrazione delle thin LUN alle thick LUN tradizionali senza che ciò comporti tempo di inattività. Questa flessibilità differenzia il virtual provisioning offerto dalla soluzione di archiviazione EMC dalle implementazioni del thin provisioning standard.

* Punto decisionale *

L'implementazione corrente di Exchange dispone di una quota di cassetta postale definita di 200 MB. Dopo il passaggio a Exchange 2010, si prevede che nei primi 12-18 mesi, le dimensioni delle cassette postali aumentino di circa il 300%. Il piano prevede che venga acquistato uno spazio di archiviazione sufficiente per cassette postali con una dimensione media di 600 MB. Nel periodo di utilizzo di Exchange 2010, si prevede che la dimensione media delle cassette postali raggiunga i 2 GB. Dal momento che acquistare 2 GB di quote delle cassette postali è costoso, si implementerà il thin provisioning in modo che sia possibile distribuire la quota iniziale di 600 MB. Lo spazio fisico di archiviazione alla base del sistema verrà successivamente aumentato per soddisfare il crescente fabbisogno.

Passaggio 3: Stabilire se i registri e i database verranno collocati sullo stesso LUN

Quando si utilizza il thin provisioning sulla soluzione di archiviazione EMC per le distribuzioni di Exchange 2010, è consigliabile separare i file del registro dai file del database. Se si prevede una crescita nella dimensione delle cassette postali, ma non nel profilo dei messaggi (messaggi inviati/ricevuti ogni giorno), sarà necessario aumentare in maniera incrementale i LUN del database, ma non quelli del registro. Potrebbe non essere opportuno collocare i registri su LUN con thin provisioning.

La separazione dei LUN di database e registri offre inoltre la possibilità di collocarli su diversi tipi di dischi o di utilizzare diversi livelli di RAID.

* Punto decisionale *

Conformemente a una procedura consigliata di EMC, i database e i log verranno separati su diversi LUN. Dal momento che si prevede che il profilo dei messaggi resterà più o meno costante nei prossimi tre anni, non ci sarebbe alcun vantaggio nel collocare i registri su LUN con thin provisioning.

Passaggio 4: Stabilire il numero di database per ogni LUN

Dal momento che le funzioni di backup e ripristino basate su VSS operano a livello di LUN, il numero di database per ogni LUN generalmente dipende dalla strategia di backup. In un passo precedente si è scelto di non includere i backup basati su VSS nella strategia per la resilienza del database. La scelta del numero di database per LUN si basa su altri fattori. Come procedura consigliata, generalmente sarebbe opportuno distribuire un singolo database per LUN. Infatti, la presenza di più database su ogni LUN potrebbe provocare i seguenti svantaggi:

Un database sovraccarico influisce negativamente su un database integro
Un'operazione di seeding su un database influisce negativamente su un database integro
Le operazioni I/O su un database passivo influiscono negativamente sui database attivi

* Punto decisionale *

Dal momento che non c'è necessità di distribuire più database per LUN, il sistema di archiviazione si baserà su un modello che prevede un singolo database per LUN.

Passaggio 5: Stabilire il numero di LUN per ogni server per il server Cassette postali del datacenter principale

In un passo precedente si è stabilito che ciascun server Cassette postali principale deve supportare sei cassette postali attive e sei cassette postali passive. Di conseguenza, per ciascun server Cassette postali del datacenter principale ci saranno 24 LUN, come mostrato nella tabella seguente.

Numero di LUN necessari per ogni server Cassette postali

Tipi di LUN	LUN per server
LUN database attivi	6
LUN registri attivi	6
LUN database passivi	6
LUN registri passivi	6
LUN totali	24

Passaggio 6: Stabilire il numero di LUN per ogni server per il server Cassette postali del datacenter secondario

In un passo precedente si è stabilito che ciascun server Cassette postali secondario deve supportare sei cassette postali passive. Di conseguenza, per ciascun server Cassette postali del datacenter secondario ci saranno 12 LUN, come mostrato nella tabella seguente.

Numero di LUN necessari per ogni server Cassette postali

Tipi di LUN	LUN per server
LUN database passivi	6
LUN registri passivi	6
LUN totali	12

Passaggio 7: Definire il blocco predefinito di archiviazione

Per semplificare le rimanenti fasi nella progettazione del sistema di archiviazione, utilizzare un approccio basato su "blocchi predefiniti". In questa soluzione, ciascun database supporta 450 cassette postali attive. Ciascun server Cassette postali supporta 6 database o 2.700 cassette postali attive su 6 LUN dei database e 6 LUN dei registri. Si utilizzerà quindi un blocco predefinito con 12 LUN che supporta incrementi di 2.700 cassette postali.

Passaggio 8: Stabilire i requisiti per le operazioni IOPS del blocco predefinito

In questo passo si calcoleranno le operazioni IOPS transazionali necessarie per supportare 2.700 utenti abilitati per le cassette postali attive nel blocco predefinito. In un passo successivo si utilizzeranno i requisiti per le operazioni IOPS per stabilire i numeri minimo e massimo di dischi da utilizzare per il blocco predefinito in base alla quota di cassette postali sottoposta a provisioning iniziale e completo. Utilizzare la seguente formula:

Numero totale di operazioni IOPS transazionali per blocco predefinito = IOPS per ciascun utente abilitato per le cassette postali × numero di cassette postali × fattore di sovraccarico I/O

= 0.10 × 2700 × 20%

= 324 IOPS

Passaggio 9: Stabilire la dimensione iniziale delle cassette postali su disco

In un passo precedente si è calcolato che la dimensione delle cassette postali su disco è pari a 2.301 MB per una quota delle cassette postali pari a 2.048 MB. Dal moment che si utilizzerà il thin provisioning, calcolare la dimensione iniziale delle cassette postali su disco. Questo valore verrà utilizzato successivamente per stabilire i requisiti per la capacità iniziale.

Per stabilire la dimensione iniziale delle cassette postali su disco per questa soluzione partendo da un quota di 600 MB per le cassette postali, utilizzare le formule seguenti:

Spazio vuoto = 100 messaggi al giorno x 75/1024 MB = 7,3 MB
Dumpster = (100 messaggi al giorno × 75 ÷ 1024 MB × 14 giorni) + (600 MB × 0,012) + (600 MB × 0,058) = 144,2 MB
Dimensione cassetta postale su disco = limite di cassetta postale + spazio vuoto + dumpster

= 600 MB + 7,3 MB + 144,2 MB

= 752 MB

Passaggio 10: Stabilire i requisiti per la capacità iniziale del database del blocco predefinito

Per stabilire la capacità di archiviazione iniziale necessaria per 2.700 cassette postali con una quota iniziale di 600 MB per le cassette postali, utilizzare le seguenti formule:

Capacità file database = (numero di cassette postali × dimensione cassetta postale su disco × fattore di crescita del sovraccarico database) + (20% sovraccarico dati)

= (2700 × 752 × 1) + (406080)

= 2.436.480 MB

= 2.379 GB
Capacità catalogo database = 10% della capacità dei file di database

= 238 GB
Capacità totale del database = (dimensione dei file database) + (dimensioni dell'indice) ÷ 0,80 per ottenere il 20% dello spazio disponibile nel volume

= (2379 + 238) ÷ 0.8

= 3.271 GB

I sei database nel blocco predefinito necessitano di una capacità di archiviazione iniziale pari a 3.271 GB.

Passaggio 11: Stabilire i requisiti per la capacità del database con provisioning completo del blocco predefinito

Per stabilire la capacità di archiviazione con provisioning completo necessaria per 2.700 cassette postali con una quota iniziale di 2.048 MB per le cassette postali, utilizzare le seguenti formule:

Capacità file database = (numero di cassette postali × dimensione cassetta postale su disco × fattore di crescita del sovraccarico database) + (20% sovraccarico dati)

= (2700 × 2301 × 1) + (1242540)

= 7.455.240 MB

= 7.281 GB
Capacità catalogo database = 10% della capacità dei file di database

= 728 GB
Capacità totale del database = (dimensione dei file database) + (dimensioni dell'indice) ÷ 0,80 per ottenere il 20% dello spazio disponibile nel volume

= (7281 + 728) ÷ 0.8

= 10.011 GB

I sei database nel blocco predefinito necessitano di una capacità di archiviazione con provisioning completo pari a 10.011 GB.

Passaggio 12: Stabilire i requisiti per la capacità dei registri del blocco predefinito

Per stabilire la capacità di archiviazione dei registri necessaria per le 2.700 cassette postali nel blocco predefinito, utilizzare le seguenti formule:

Capacità necessaria per i registri del blocco predefinito = numero di utenti abilitati per le cassette postali × numero di registri per cassetta postale al giorno × dimensione registri × (numero di giorni necessari per sostituire l'infrastruttura danneggiata) + (percentuale sovraccarico spostamento cassetta postale)

= (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)

= 216.054 MB

= 211 GB
Capacità totale del registro = capacità dei registri ÷ 0,80 per ottenere il 20% dello spazio disponibile nel volume

= 211 ÷ 0.80

= 264

I sei gruppi di registri nel blocco predefinito necessitano di una capacità di archiviazione pari a 264 GB.

Nota

Dal momento che ai volumi dei registri non si applica il thin provisioning, la capacità di archiviazione calcolata rappresenta i requisiti di capacità in un ambiente con provisioning completo.

Passaggio 13: Stabilire il numero dei dischi necessari per supportare i requisiti per le operazioni IOPS del blocco predefinito

In questo passo si stabilirà il numero dei dischi necessari per supportare i requisiti per le operazioni IOPS. Nel prossimo passo si stabilità il numero dei dischi necessari per soddisfare i requisiti di capacità.

In un passo precedente si è stabilito che le operazioni IOPS necessarie per supportare le 2.700 cassette postali del blocco predefinite sono 324. In questo passo si calcolerà il numero di dischi necessari per soddisfare i requisiti per le operazioni IOPS utilizzando seguente la formula:

Numero di dischi = (IOPS utente × rapporto lettura) + penalità scrittura × (IOPS utente × rapporto scrittura) ÷ capacità IOPS del tipo di disco scelto

= (324 × 0.6) + 4 × (324 × 0.4) ÷ 155

= 4.6

I requisiti per le operazioni IOPS possono essere soddisfatti da cinque dischi in una configurazione RAID-5.

Nota

Questi calcoli sono specifici per questa soluzione EMC. Rivolgersi al proprio fornitore di soluzioni per l'archiviazione per verificare i requisiti in termini di dischi per la soluzione scelta.

Passaggio 14: Stabilire il numero dei dischi necessari per supportare i requisiti per la capacità iniziale del database del blocco predefinito

In un passo precedente si è stabilito che per le 2.700 cassette postali del blocco predefinito con una quota iniziale di 600 MB è necessaria una capacità di archiviazione pari a 3,271 GB. Lo spazio utilizzabile su un disco da 450 GB in una configurazione RAID-5 sul modello CX4-480 è di circa 402 GB. Per stabilire il numero dei dischi necessari, utilizzare la seguente formula:

Numero di dischi = (capacità totale necessaria) ÷ (capacità utilizzabile per disco con RAID-5)

= 3,271 GB ÷ 402 GB

= 8.1

I requisiti per la capacità iniziale del database possono essere soddisfatti con nove dischi.

Il sistema migliore per allocare la memoria sulla soluzione di archiviazione EMC utilizzando il thin provisioning si ottiene configurando i thin pool RAID-5 in multipli di cinque dischi. Allocando 10 dischi per un blocco predefinito costituito da 2.700 cassette postali si avranno a disposizione le risorse per la crescita futura.

Passaggio 15: Stabilire il numero dei dischi necessari per supportare i requisiti per la capacità del database con provisioning completo del blocco predefinito

In un passo precedente si è stabilito che per le 2.700 cassette postali del blocco predefinito con una quota iniziale di 2.048 MB è necessaria una capacità di archiviazione pari a 10.011 GB. Lo spazio utilizzabile su un disco da 450 GB in una configurazione RAID-5 sul modello CX4-480 è di circa 402 GB. Per stabilire il numero dei dischi necessari, utilizzare la seguente formula:

Numero di dischi = (capacità totale necessaria) ÷ (capacità utilizzabile per disco con RAID-5)

= 10.011 GB ÷ 402 GB

= 24.9

I requisiti per la capacità del database con provisioning completo possono essere soddisfatti con venticinque dischi.

Passaggio 16: Stabilire il numero dei dischi necessari per supportare i requisiti per la capacità dei registri del blocco predefinito

In un passo precedente si è stabilito che per le 2.700 cassette postali del blocco predefinito è necessaria una capacità di archiviazione dei registri pari a 264 GB. Utilizzando due unità da 450 GB in una configurazione RAID-1/0 su un modello CX4-480 si hanno a disposizione circa 402 GB di spazio di archiviazione utilizzabile. La configurazione a due dischi soddisfa i requisiti per la capacità dei registri per le 2.700 cassette postali del blocco predefinito.

Passaggio 17: Stabilire la strategia di thin pool

Una volta stabilito il numero dei dischi necessari per supportare le operazioni IOPS e i requisiti di capacità del blocco predefinito, è necessario individuare il sistema di provisioning dei LUN sull'array del blocco predefinito quando si utilizza un provisioning di tipo virtual o thin.

Sono disponibili tre modelli tra cui è possibile scegliere quando si progettano i thin pool da utilizzare per Exchange:

Pool di archiviazione singolo Un pool di archiviazione di grandi dimensioni per tutti i registri e database di Exchange è il sistema più semplice e garantisce il miglior utilizzo dello spazio. Tuttavia, non è consigliabile utilizzare un singolo thin pool quando su uno stesso array fisico ci sono più copie di uno stesso database.
Un pool di archiviazione per server Un pool di archiviazione per ciascun server Cassette postali di Exchange offre una maggiore granularità nella disposizione dei LUN sull'array. Se progettato correttamente, questo sistema consente di isolare le copie dei database per separare i gruppi di dischi e ridurre il rischio che eventuali errori a livello di contenuto dei dischi possano palesarsi durante attività quali il seeding/reseeding, il backup e la manutenzione online (manutenzione in background dei database). Tuttavia, a seconda del numero di server Cassette postali, questo modello potrebbe portare alla creazione di un numero esagerato di thin pool e quindi ad una gestione troppo complicata.
Un pool di archiviazione per copia di database Un pool di archiviazione per ciascuna copia di database fa sì che ciascuna copia sia isolata su un diverso gruppo di dischi sull'array. Dal momento che la maggior parte delle organizzazioni distribuisce tra le due e le quattro copie di database, il numero di thin pool risulta gestibile. In un modello di questo tipo, più server Cassette postali mantengono i LUN dei database nello stesso thin pool. Esiste la possibilità che attività quali il seeding/reseeding, il backup e la manutenzione online (manutenzione in background dei database) eseguite su un server Cassette postali influiscano negativamente sulle prestazioni di un altro server Cassette postali.

* Punto decisionale *

Sebbene il modello basato su un pool di archiviazione per ogni server offra vantaggi evidenti, comporterebbe anche otto thin pool in ciascun sito, per un totale di 24 thin pool. Per semplificare il progetto, si utilizzerà il modello basato su un pool di archiviazione per ogni copia del database in quanto questo comporta tre thin pool in ciascun sito e garantisce che ogni copia del database si trovi su un gruppo univoco di dischi. Con questo modello, i dischi con le copie dei database restano isolati durante le operazioni di aggiunta di memoria per rispondere a esigenze di aumento della capacità di archiviazione.

Passaggio 18: Stabilire il numero di dischi iniziali per thin pool

Il primo thin pool conterrà un blocco predefinito composto da 2.700 cassette postali da ciascuno dei quattro server Cassette postali nel datacenter principale all'interno del sito. In un passo precedente si è stabilito che sono necessari 10 dischi per supportare le operazioni IOPS e i requisiti di capacità del blocco predefinito. Per supportare 10.800 cassette postali attive, il primo thin pool avrà bisogno di 40 dischi.

Anche il secondo thin pool conterrà un blocco predefinito composto da 2.700 cassette postali da ciascuno dei quattro server Cassette postali nel datacenter principale all'interno del sito. Per supportare 10.800 cassette postali passive, il secondo thin pool avrà bisogno di 40 dischi.

Anche il terzo thin pool conterrà un blocco predefinito composto da 2.700 cassette postali da ciascuno dei quattro server Cassette postali nel datacenter secondario all'interno del sito (i server in un gruppo di disponibilità del database alternativo che supportano le copie dei database per la resilienza del sito). Per supportare 10.800 cassette postali passive, il terzo thin pool avrà bisogno di 40 dischi.

Per supportare i requisiti per la capacità iniziale del database saranno necessari 120 dischi per sito.

Passaggio 19: Stabilire il numero di dischi con provisioning completo per thin pool

Il primo thin pool conterrà un blocco predefinito composto da 2.700 cassette postali da ciascuno dei quattro server Cassette postali nel datacenter principale all'interno del sito. In un passo precedente si è stabilito che sono necessari 25 dischi per supportare le operazioni IOPS e i requisiti di capacità con provisioning completo del blocco predefinito. Per supportare 10.800 cassette postali attive, il primo thin pool avrà bisogno di 100 dischi.

Per supportare i requisiti per la capacità del database con provisioning completo saranno necessari 300 dischi per sito.

Passaggio 20: Stabilire il numero dei dischi necessari per supportare tutti i LUN dei registri

In un passo precedente si è stabilito che per supportare i requisiti per i LUN dei registri sono necessari due dischi per ciascun blocco predefinito contenente 2.700 cassette postali.

Ci sono quattro blocchi predefiniti che supportano i database delle cassette postali attive sui server Cassette postali nel datacenter principale. Per supportare 10.800 cassette postali attive, il LUN dei registri avrà bisogno di otto dischi.

Ci sono quattro blocchi predefiniti che supportano i database delle cassette postali passive sui server Cassette postali nel datacenter principale. Per supportare 10.800 cassette postali passive, il LUN dei registri avrà bisogno di otto dischi.

Ci sono quattro blocchi predefiniti che supportano i database delle cassette postali passive sui server Cassette postali nel datacenter secondario. Per supportare 10.800 cassette postali passive, il LUN dei registri avrà bisogno di otto dischi.

Per supportare i requisiti per i LUN dei registri in un singolo sito sono necessari 24 dischi.

Passaggio 21: Verificare che l'array di archiviazione sia in grado di supportare il numero di dischi richiesto inizialmente

In questo passo si verificherà che l'array di archiviazione scelto sia in grado di supportare il numero totale di dischi richiesti. Utilizzare la seguente formula:

Dischi totali necessari per sito = dischi necessari per i LUN dei database + dischi necessari per i LUN dei registri

= 120 + 24

= 144

Un modello CX4-480 con 10 enclosure per array di dischi ha 150 dischi e soddisfa i requisiti.

Passaggio 22: Stabilire il numero dei dischi necessari per supportare un ambiente con provisioning completo

In questo passo si calcolerà il numero totale dei dischi necessari per supportare l'ambiente con provisioning completo utilizzando la seguente formula:

Dischi totali necessari per sito = dischi necessari per i LUN dei database + dischi necessari per i LUN dei registri

= 300 + 24

= 324

Un modello CX4-480 con 22 enclosure per array di dischi ha 330 dischi e soddisfa i requisiti.

Soluzioni testate per Exchange 2010

Panoramica sulla soluzione

Nella sezione precedente sono state fornite informazioni sulle decisioni da prendere quando si lavora alla progettazione di una soluzione Exchange 2010. Nella seguente sezione viene fornita una panoramica sulla soluzione.

Soluzioni testate per Exchange 2010

Diagramma della soluzione logica

Questa soluzione è costituita da 36 server Exchange 2010 distribuiti in una topologia multisito. Su dodici dei 36 server vengono eseguiti entrambi i ruoli Accesso client e Trasporto Hub. Sugli altri 24 server viene eseguito il ruolo Cassette postali. In ciascun sito è presente un array di server Accesso client con quattro combinazioni server Accesso client e server Trasporto Hub. Ci sono tre gruppi di disponibilità del database, ciascuno con otto server Cassette postali. I file server in ciascun sito ospitano i server di controllo della condivisione file principale e alternativo per ciascun gruppo di disponibilità del database.

Diagramma della soluzione logica

Soluzioni testate per Exchange 2010

Diagramma della soluzione fisica

Ciascuno dei tre siti contiene quattro server blade Cisco B200 connessi a un array di archiviazione EMC CLARiiON CX4-480 tramite switch Cisco Fabric Interconnect 6120 e Cisco MDS 9134 ridondanti. Gli switch Ethernet Cisco Nexus 5010 ridondanti forniscono l'infrastruttura di rete di base. Il carico del traffico client viene bilanciato nell'array di server Accesso client in ciascun sito tramite i dispositivi di bilanciamento del carico Cisco ACE 4710 ridondanti.

Diagramma della soluzione fisica

Soluzioni testate per Exchange 2010

Riepilogo della configurazione del server radice Hyper-V

Nella tabella seguente sono riportati i componenti hardware del server fisico utilizzati in questa soluzione.

Server Cisco Unified Computing System

Elemento	Descrizione
Server blade	4 × B200 M1
Processori	2 × Intel Zeon x5570 (2,93 GHz)
Memoria	96 GB di RAM (12 × 8 GB DIMM)
Scheda di rete convergente	M71KR-Q (2 × 10 gigabit Ethernet e 2 × 4 Gbps Fibre Channel)
Memoria interna	2 × dischi 146 GB SAS 10.000 RPM (RAID-1)
Chassis	5108 (6RU)
Fabric Extender	2 × 2104XP
Fabric Interconnect	2 × 6120XP
Modulo di espansione Fabric Interconnect	2 × 4 Gbps Fibre Channel a 8 porte

Nella tabella seguente sono riportati i componenti hardware di rete e archiviazione utilizzati in questa soluzione.

Switch LAN e SAN

Elemento	Descrizione
Switch 10 gigabit Ethernet (GbE)	2 × Nexus 5010 (8 porte fisse 1 GbE/10 GbE, 12 porte fisse 10 GbE, bridging datacenter)
Switch Fibre Channel	2 × MDS 9134 (32 porte fisse 4 Gbps)

Nella tabella seguente sono riportati i componenti software utilizzati in questa soluzione.

Software

Elemento	Descrizione
Server host hypervisor	Hyper-V di Windows Server 2008 R2 Enterprise
Macchine virtuali server Exchange	Windows Server 2008 R2 Enterprise
Ruolo server Cassette postali di Exchange Server 2010	Enterprise Edition RU2
Ruolo server Accesso client e Trasporto Hub di Exchange Server 2010	Standard Edition RU2
Percorso multipli e bilanciamento I/O	EMC PowerPath

Soluzioni testate per Exchange 2010

Configurazione del server Accesso client e Trasporto Hub

Nella tabella seguente è riportata la configurazione della combinazione server Accesso client e server Trasporto Hub utilizzata in questa soluzione.

Configurazione del server Accesso client e Trasporto Hub

Componente	Valore o descrizione
Fisico o virtuale	Macchina virtuale Hyper-V
Processori virtuali	3
Memoria	8 GB
Archiviazione	Disco rigido virtuale sul volume del sistema operativo del server radice
Sistema operativo	Windows Server 2008 R2
Versione di Exchange	Exchange Server 2010 Standard Edition
Livello di aggiornamento di Exchange	Aggiornamento cumulativo 2 di Exchange 2010
Software di terzi	Nessuna

Soluzioni testate per Exchange 2010

Configurazione del server Cassette postali

Nella tabella seguente è riportata la configurazione del server Cassette postali principale (che ospita le copie dei database principale e secondario nel sito principale per il DAG) utilizzata in questa soluzione.

Configurazione del server Cassette postali principale

Componente	Valore o descrizione
Fisico o virtuale	Macchina virtuale Hyper-V
Processori virtuali	4
Memoria	53 GB
Archiviazione	Disco rigido virtuale sul volume del sistema operativo del server radice

Sistema operativo	Windows Server 2008 R2
Versione di Exchange	Exchange Server 2010 Enterprise Edition
Livello di aggiornamento di Exchange	Aggiornamento cumulativo 2 di Exchange 2010
Software di terzi	Nessuna

Nella tabella seguente è riportata la configurazione del server Cassette postali secondario (che ospita la copia del terzo database nel sito secondario per il DAG) utilizzata in questa soluzione.

Configurazione del server Cassette postali secondario

Componente	Valore o descrizione
Fisico o virtuale	Macchina virtuale Hyper-V
Processori virtuali	2
Memoria	24 GB
Archiviazione	Disco rigido virtuale sul volume del sistema operativo del server radice

Sistema operativo	Windows Server 2008 R2
Versione di Exchange	Exchange Server 2010 Enterprise Edition
Livello di aggiornamento di Exchange	Aggiornamento cumulativo 2 di Exchange 2010
Software di terzi	Nessuna

Soluzioni testate per Exchange 2010

Layout del database

Nei seguenti diagrammi è illustrato il layout delle copie del database utilizzato in questa soluzione in condizioni di normale operatività.

Layout delle copie del database: 1

Layout delle copie del database: 2

Layout delle copie del database: 3

Soluzioni testate per Exchange 2010

Componenti hardware di archiviazione

Nella tabella seguente sono riportati i componenti hardware di archiviazione utilizzati in questa soluzione.

Soluzione di archiviazione EMC NS-480 (integrata con CLARiiON CX4-480)

Elemento	Descrizione
Archiviazione	3 CLARiiON CX4-480 (1 per ogni sito)
Connettività di archiviazione (Fibre Channel, SAS, SATA, iSCSI)	Fibre Channel
Cache di archiviazione	32 GB (600 MB di cache in lettura e 10.160 MB di cache in scrittura per porta di archiviazione)
Numero di controller di archiviazione	2 per storage frame
Numero di porte di archiviazione disponibile o utilizzate	8 disponibili per storage frame (4 per porta di archiviazione), 4 utilizzate (2 per porta di archiviazione)
Larghezza di banda massima per la connessione all'host	8 × 4 Gbps
Numero totale di dischi verificati nella soluzione	432 (360 per i database e 72 per i registri in 3 siti)
Numero massimo di dischi che il sistema di archiviazione può ospitare	480 in un singolo array di archiviazione

Soluzioni testate per Exchange 2010

Configurazione dell'archiviazione

Ciascuno degli array di archiviazione CX4-480 utilizzati nella soluzione sono stati configurati come mostrato nella tabella seguente.

Configurazione dell'archiviazione

Componente	Valore o descrizione
Numero totale di storage enclosure	3
Numero totale di storage enclosure per sito	1
Numero totale di dischi per enclosure	150
Numero totale di pool di archiviazione per enclosure	3
Numero totale di dischi per pool di archiviazione (iniziale)	40
Numero totale di dischi per LUN database (iniziale)	10
Numero totale di dischi per LUN registro	2
Numero totale di dischi utilizzati per enclosure	144
Dimensione del LUN per il database (iniziale)	4.020 GB
Dimensione del LUN per i registri	402 GB
Livello RAID per i database	5
Livello RAID per i registri	1/0

Nella tabella seguente viene illustrata l'allocazione della memoria disponibile tra i tre sistemi di archiviazione CX4-480.

Configurazione dell'archiviazione tra i sistemi di archiviazione CX4-480

Datacenter	DAG	Database	Array1	Array2	Array3
1	1	DB1-24	C1, C2		C3
2	2	DB25-48	C3	C1, C2
3	3	DB49-72		C3	C1, C2

Soluzioni testate per Exchange 2010

Metodologia di verifica

Prima di distribuire una soluzione Exchange in un ambiente di produzione, verificare che sia stata progettata, dimensionata e configurata correttamente. Questa verifica deve includere dei test funzionali che possano garantire il corretto funzionamento del sistema e dei test delle prestazioni che possano garantire la capacità del sistema di gestire il carico utenti desiderato. In questa sezione viene descritto l'approccio e la metodologia utilizzati per verificare l'architettura del server e del sistema di archiviazione per questa soluzione. Verranno illustrati in dettaglio i seguenti test:

Test delle prestazioni
- Verifica delle prestazioni del sistema di archiviazione (Jetstress)
- Verifica delle prestazioni del server (Loadgen)
Test funzionali
- Verifica del passaggio di database
- Verifica del passaggio di server
- Verifica del failover di server
- Verifica del passaggio di datacenter

Soluzioni testate per Exchange 2010

Metodologia di verifica di sistema di archiviazione

Il livello di prestazioni e affidabilità del sottosistema di archiviazione connesso al ruolo server Cassette postali di Exchange ha un impatto notevole sull'integrità globale della distribuzione di Exchange. Inoltre, prestazioni insoddisfacenti a livello di sistema di archiviazione provocheranno un alto grado di latenza nelle transazioni e ciò avrà ripercussioni negative sull'accesso al sistema Exchange da parte dei client. Per garantire la migliore esperienza client, verificare il dimensionamento e la configurazione del sistema di archiviazione utilizzando il metodo descritto in questa sezione.

Gruppo di strumenti

Per verificare la dimensione e la configurazione del sistema di archiviazione di Exchange, è consigliabile utilizzare Microsoft Exchange Server Jetstress. Lo strumento Jetstress è stato progettato per simulare un carico di lavoro I/O di Exchange a livello di database tramite l'interazione diretta con il modulo ESE, conosciuto anche con il nome di Jet. Il modulo ESE è la tecnologia di database utilizzata da Exchange per archiviare i messaggi sul ruolo server Cassette postali. È possibile configurare Jetstress per verificare la velocità massima di trasferimento per le operazioni I/O disponibile nel sottosistema di archiviazione entro i limiti di prestazioni previsti per Exchange. In alternativa, Jetstress può accettare un profilo target per il numero di utenti e le operazioni IOPS per utente e verificare che il sottosistema di archiviazione sia in grado di mantenere un livello di prestazioni accettabile con il profilo target. La durata del test è variabile ed è possibile scegliere se eseguirlo per un periodo di tempo minimo per controllare solamente che le prestazioni siano adeguate o per un periodo più esteso per controllare l'affidabilità del sottosistema di archiviazione.

Per scaricare lo strumento Jetstress, accedere all'Area download Microsoft e sceglier una delle seguenti versioni:

La documentazione inclusa con il programma di installazione di Jetstress descrive come configurare ed eseguire un test di verifica Jetstress sui componenti hardware del server.

Approccio alla verifica del sistema di archiviazione

Le configurazioni di archiviazione si suddividono in due tipologie:

Sistemi DAS o con dischi interni
Sistemi SAN

In un sistema DAS o con dischi interni, c'è un solo server che accede al sottosistema di dischi e di conseguenza le prestazioni del sottosistema di archiviazione possono essere valutate separatamente.

In un sistema SAN, l'archiviazione utilizzata dalla soluzione può essere condivisa da più server e anche l'infrastruttura che collega i server all'archiviazione può essere una dipendenza condivisa. Ciò richiede un'ulteriore verifica perché è necessario simulare correttamente l'influenza di questi server sull'infrastruttura condivisa per poter valutare prestazioni e funzionalità.

Test case per la verifica del sistema di archiviazione

Sulla soluzione sono stati eseguiti i test case riportati di seguito che possono essere considerati un valido punto di partenza per la verifica del sistema di archiviazione. Le specifiche distribuzioni potrebbero prevedere diversi requisiti da verificare con ulteriori prove e di conseguenza questo elenco non può essere considerato esaustivo:

Verifica del peggiore scenario per il passaggio di database In questo test case, viene preso in considerazione il livello di operazioni I/O che il sottosistema di archiviazione si trova a gestire nel peggiore scenario per il passaggio di database (numero massimo di copie attive su numero minore di server). A seconda che il sottosistema di archiviazione sia di tipo DAS o SAN, potrebbe essere necessario eseguire questo test su più host per verificare che sia possibile gestire il carico della soluzione end-to-end sul sottosistema di archiviazione.
Verifica delle prestazioni del sistema di archiviazione in uno scenario di errore e ripristino del sistema di archiviazione (ad esempio, sostituzione e rebuild di un disco danneggiato) In questo test case, le prestazioni di un sottosistema di archiviazione vengono verificate in uno scenario di errore e ripristino per controllare che si mantengano a un livello tale da non creare problemi nell'utilizzo dei client Exchange. La stessa avvertenza si applica ad entrambe le distribuzioni di tipo DAS e SAN: Se più host dipendono da un sottosistema di archiviazione condiviso, il test deve includere il carico da questi host per simulare l'effetto totale della condizione di errore e rebuild.

Analisi dei risultati

Lo strumento Jetstress produce un file di report dopo il completamento di ciascun test. Per analizzare il report, utilizzare le linee guida fornite in Jetstress 2010 Test Summary Reports.

Nello specifico, utilizzare le linee guida fornite nella tabella che segue quando si esaminano i dati nella tabella Risultati test del report.

Analisi dei risultati di Jetstress

Istanza del contatore delle prestazioni	Linee guida per l'esecuzione del test
Latenza media letture database I/O (msec)	Il valore medio deve essere inferiore a 20 millisecondi (msec) (0,020 secondi) e il valore massimo deve essere inferiore a 50 msec.
Latenza media scritture registro I/O (msec)	Le scritture sul disco del registro sono sequenziali e di conseguenza la latenza media deve essere inferiore a 10 msec e il valore massimo deve essere inferiore a 50 msec.
% tempo processore	Il valore medio deve essere inferiore all'80% e il valore massimo inferiore al 90%.
Pagine di transizione reimpiegate/sec (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2)	Il valore medio deve essere inferiore a 100.

Il file di report riporta diverse categorie di operazioni I/O eseguite dal sistema Exchange:

Prestazioni I/O transazionali Questa tabella elenca le operazioni I/O che rappresentano attività eseguite dall'utente sul database (ad esempio, operazioni I/O generate da Outlook). Questi dati si ottengono sottraendo le operazioni I/O di manutenzione in background e le operazioni I/O di replica del registro dal numero totale di operazioni I/O misurato durante il test. Questi dati forniscono il numero effettivo di operazioni IOPS generate sul database e le misurazioni della latenza I/O, cioè le informazioni necessarie per stabilire se un test delle prestazioni Jetstress è stato superato o meno.
Prestazioni I/O di manutenzione del database in background Questa tabella elenca le operazioni I/O generate a seguito delle attività di manutenzione in background del database ESE.
Prestazioni I/O di replica del registro Questa tabella elenca le operazioni I/O generate dalla replica del registro simulata.
Prestazioni I/O totali Questa tabella elenca il numero totale di operazioni I/O generate durante il test Jetstress.

Soluzioni testate per Exchange 2010

Verifica del server

Dopo aver verificato le prestazioni e l'affidabilità del sottosistema di archiviazione, è necessario controllare la funzionalità, le prestazioni e la scalabilità di tutti i componenti che fanno parte del sistema di messaggistica. Ciò significa verificare l'interazione tra il software client e il prodotto Exchange così come qualsiasi prodotto sul lato server che interagisce con Exchange. Per controllare che i client end-to-end funzionino in modo accettabile e che l'intera soluzione sia in grado di supportare il carico di utenti desiderato, è possibile utilizzare il metodo illustrato in questa sezione per verificare l'architettura del server.

Gruppo di strumenti

Per verificare le prestazioni e la scalabilità della soluzione end-to-end, è consigliabile utilizzare Microsoft Exchange Server Load Generator (Loadgen). Loadgen è stato progettato per produrre un carico di lavoro simulato nell'ambito di una distribuzione di Exchange. Questo carico di lavoro consente di valutare le prestazioni del sistema Exchange e può anche essere utilizzato per analizzare gli effetti delle variazioni di configurazione sulla soluzione quando il sistema è sotto carico. Loadgen è in grado di simulare le attività client di Microsoft Office Outlook 2007 (in modalità online e cache), Office Outlook 2003 (in modalità online e cache), POP3, IMAP4, SMTP, ActiveSync e Outlook Web App (chiamato Outlook Web Access in Exchange 2007 e nelle versioni precedenti). Può essere utilizzato per generare un carico di lavoro con un singolo protocollo o questi protocolli client possono essere combinati tra loro per generare un carico di lavoro con più protocolli.

Per scaricare lo strumento Loadgen, accedere all'Area download Microsoft e sceglier una delle seguenti versioni:

La documentazione inclusa con il programma di installazione di Loadgen descrive come configurare ed eseguire un test di verifica Loadgen su una distribuzione di Exchange.

Approccio alla verifica del server

Quando si verifica l'architettura del server, controllare lo scenario peggiore in base al picco previsto per il carico di lavoro. Sulla base dei dati ottenuti dallo staff IT di Microsoft e da altri clienti, generalmente il picco è uguale a due volte il carico di lavoro medio per la parte restante della giornata lavorativa. In questo caso si parla di "rapporto picco/media", cioè il valore del rapporto tra il picco e la media di carico di lavoro.

Performance Monitor

In questa immagine sono raffigurati diversi contatori che rappresentano il lavoro Exchange svolto nel corso di un determinato periodo di tempo su un server Cassette postali in un ambiente di produzione. Il valore medio delle operazioni RPC al secondo (riga evidenziata) calcolato sulla media dell'intera giornata è pari a circa 2.386. Il valore medio per questo contatore nell'intervallo di picco tra le 10:00 e le 11:00 è pari a circa 4.971 e di conseguenza il rapporto picco/media è di 2,08.

Per verificare che la soluzione Exchange sia in grado di gestire il carico di lavoro generato nell'intervallo di picco medio, modificare le impostazioni di Loadgen per generare un carico di lavoro costante a livello di picco medio piuttosto che distribuire il carico di lavoro sull'intera giornata lavorativa simulata. I moduli di simulazione Loadgen basati sulle attività (come i moduli di simulazione Outlook) utilizzano un profilo di attività che definisce quante volte ciascuna attività coinvolgerà un utente medio nell'arco della giornata simulata.

Il numero totale di attività che devono essere eseguite durante una giornata simulata è dato dal numero di utenti moltiplicato per il numero di attività configurate nel profilo di attività. Loadgen stabilisce la velocità a cui deve eseguire le attività per il gruppo di utenti configurato dividendo il numero totale di attività da eseguire nella giornata simulata per la durata della giornata. Ad esempio, se Loadgen deve eseguire 1.000.000 attività in una giornata simulata e una giornata simulata corrisponde a 8 ore (28.800 secondi), Loadgen dovrà eseguire 1.000.000 ÷ 28.800 = 34,72 attività al secondo per gestire il carico di lavoro assegnatogli. Per aumentare il carico fino al picco medio desiderato, dividere la durata della giornata simulata (8 ore) per il rapporto picco/media (2) e utilizzare il valore ottenuto come nuova durata della giornata simulata.

Eseguendo di nuovo il calcolo dell'esempio precedente con i nuovi valori si otterranno 69,44 attività al secondo (=1.000.000 ÷ 14.400). In questo modo, la durata della giornata simulata risulta dimezzata e quindi il carico di lavoro effettivamente gestito dal server risultata duplicato. Si ottiene così il picco medio di carico di lavoro. Nella configurazione di Loadgen, non viene modificata la durata del test. La durata del test non influenza la velocità di esecuzione delle attività sul server Exchange.

Test case per la verifica dell'architettura server

Sull'architettura server sono stati eseguiti i test case riportati di seguito che possono essere considerati un valido punto di partenza per la verifica del server. Le specifiche distribuzioni potrebbero prevedere diversi requisiti da verificare con ulteriori prove e di conseguenza questo elenco non può essere considerato esaustivo:

Condizioni di normale operatività In questo test case, l'architettura di base della soluzione viene controllata con tutti i componenti in condizioni di normale operatività (non viene simulato alcun errore). Viene creato il carico di lavoro desiderato e le prestazioni della soluzione vengono verificate rispetto sulla base delle metriche di seguito riportate.
Errore server singolo o manutenzione server singolo (in sito) In questo test case, un singolo server viene scollegato per simulare un errore imprevisto del server o un'operazione di manutenzione pianificata sul server. Il carico di lavoro che normalmente verrebbe gestito dal server non disponibile viene ora gestito dagli altri server nella soluzione e vengono verificate le prestazioni globali della soluzione.

Esecuzione del test e raccolta dei dati

I dati sulle prestazioni di Exchange possono presentare delle variazioni all'interno di uno stesso test e tra un test e l'altro. È consigliabile utilizzare i valori medi ottenuti da più test così da ridurre questa variazione. Sulle soluzioni Exchange sono stati eseguiti almeno tre test separati nell'arco di otto ore. I dati sulle prestazioni sono stati raccolti nel corso di tutte le otto ore di durata del test. I dati riepilogativi sulle prestazioni sono stati ricavati da un periodo di stabilità durato tra le tre e le quattro ore (escludendo le prime e le ultime due ore del test). Per ciascun ruolo del server Exchange, i dati riepilogativi sulle prestazioni sono stati calcolati sulla base della media dei valori fatti registrare dai server per ciascun test, così da ottenere un unico valore medio per ciascun punto di verifica. È stato calcolato il valore medio dei risultati registrati così da ottenere un unico punto di verifica per tutti i server con lo stesso ruolo nel corso di tutti i test.

Verifica del carico previsto

Prima di esaminare i contatori delle prestazioni o iniziare l'analisi dei risultati dei test sulle prestazioni, verificare che il carico di lavoro eseguito corrisponda a quello previsto. Sebbene siano disponibili diversi modi per stabilire se il carico di lavoro simulato corrisponde a quello previsto, il sistema più semplice e immediato consiste nell'esaminare la velocità di recapito dei messaggi.

Calcolo della velocità di consegna prevista per i picchi di messaggi

Ciascun profilo di messaggi è costituito dalla somma del numero medio di messaggi inviati e ricevuti quotidianamente. Per calcolare la velocità di recapito dei messaggi, selezionare nella seguente tabella il numero medio di messaggi ricevuti ogni giorno.

Velocità di recapito per i picchi di messaggi

Profilo messaggi	Messaggi inviati ogni giorno	Messaggi ricevuti ogni giorno
50	10	40
100	20	80
150	30	120
200	40	160

Nel seguente esempio si presuppone che su ciascun server Cassette postali ci siano 5.000 cassette postali attive con un profilo che prevede 150 messaggi al giorno (30 messaggi inviati e 120 ricevuti quotidianamente).

Velocità di recapito per i picchi di messaggi per 5.000 cassette postali attive

Descrizione	Calcolo	Valore
Profilo messaggi	Numero di messaggi ricevuti ogni giorno	120
Numero di cassette postali attive per ogni server Cassette postali	Non applicabile	5000
Numero totale di messaggi ricevuti ogni giorno da ogni server Cassette postali	5000 × 120	600000
Numero totale di messaggi ricevuti ogni secondo da ogni server Cassette postali	600000 ÷ 28800	20.83
Numero totale di messaggi in base al picco	20.83 × 2	41.67

Si prevede che su ciascun server Cassette postali con 5.000 cassette postali attive e un profilo di 150 messaggi al giorno durante i picchi vengano consegnati 41,67 messaggi al secondo.

Misurazione delle velocità effettiva di recapito dei messaggi

La velocità effettiva di recapito dei messaggi può essere misurata utilizzando il seguente contatore su ciascun server Cassette postali: MSExchangeIS Cassetta postale(_Total)\Messaggi recapitati/sec. Se la velocità di recapito misurata si discosta di uno o due messaggi al secondo dalla velocità target, si può essere ragionevolmente certi che il profilo di carico desiderato è stato eseguito correttamente.

Verifica del server: prestazioni e i criteri di integrità

In questa sezione vengono descritti i contatori e le soglie di Performance Monitor utilizzati per stabilire se l'ambiente Exchange è stato dimensionato correttamente ed è in grado di restare integro a fronte di picchi di carico per periodi prolungati. Per ulteriori informazioni sui contatori per le prestazioni di Exchange, vedere Contatori e soglie di prestazioni e scalabilità.

Server radice Hyper-V

Per verificare le prestazioni e i criteri di integrità di un server radice Hyper-V e della applicazioni in esecuzione sulle macchine virtuali, è necessario avere una conoscenza di base dell'architettura Hyper-V e del modo in cui essa influenza il monitoraggio delle prestazioni.

Hyper-V ha tre componenti principali: stack di virtualizzazione, hypervisor e dispositivi. Lo stack di virtualizzazione gestisce i dispositivi simulati, le macchine virtuali e le I/O dei servizi. L'hypervisor programma i processori virtuali, gestisce gli interrupt, controlla i timer e altre funzioni a livello di chip. L'hypervisor non gestisce i dispositivi o le I/O (ad esempio, non esistono driver di hypervisor). I dispositivi fanno parte del server radice o sono installati nei server guest come parte dei servizi di integrazione. Poiché il server radice ha una visione completa del sistema e controlla le macchine virtuali, è anche in grado di fornire le informazioni di monitoraggio tramite WMI (Windows Management Instrumentation) e i contatori delle prestazioni.

Processore

Quando si verifica l'utilizzo del processore fisico sul server radice (o nella macchina virtuale guest), il contatore Processore\% Tempo Processore non è molto utile..

È più opportuno esaminare il contatore Processore logico hypervisor Hyper-V\% Tempo di esecuzione totale. Questo contatore riporta la percentuale di tempo di processore utilizzato nel guest e nell'hypervisor ed è questo valore che andrebbe utilizzato per misurare l'utilizzo totale del processore per l'hypervisor e per tutte le macchine virtuali in esecuzione sul server radice. Questo contatore non deve superare l'80 per cento o il target di utilizzo massimo specificato.

Contatore	Destinazione
Processore logico hypervisor Hyper-V\% Tempo di esecuzione totale	<80%

Chi è interessato a sapere quale percentuale di tempo di processore viene impiegata per gestire le macchine virtuali guest, può esaminare il contatore Processore logico hypervisor Hyper-V\\% Tempo di esecuzione guest. Chi è interessato a sapere quale percentuale di tempo di processore viene impiegata nell'hypervisor, può esaminare il contatore Processore logico hypervisor Hyper-V\\% Tempo di esecuzione hypervisor. Questo contatore dovrebbe riportare una percentuale inferiore al 5 per cento. Il contatore The Processore virtuale radice hypervisor Hyper-V\% Tempo di esecuzione guest mostra la percentuale di tempo del processore impiegata nello stack di virtualizzazione. Anche questo contatore dovrebbe riportare una percentuale inferiore al 5 per cento. Questi due contatori possono essere utilizzati per determinare quale percentuale di tempo del processore fisico viene impiegata per supportare la virtualizzazione.

Contatore	Destinazione
Processore logico hypervisor Hyper-V\% Tempo di esecuzione guest	<80%
Processore logico hypervisor Hyper-V\% Tempo di esecuzione hypervisor	<5%
Processore virtuale radice hypervisor Hyper-V\% Tempo di esecuzione guest	<5%

Memoria

Occorre verificare che il server radice Hyper-V disponga di memoria sufficiente per supportare la memoria allocata alle macchine virtuali. Hyper-V riserva automaticamente 512 MB (questa quantità potrebbe variare a seconda della versione di Hyper-V) per il sistema operativo radice. Se la memoria è insufficiente, Hyper-V impedisce l'avvio dell'ultima macchina virtuale. In ottica generale, non occorre preoccuparsi di verificare la memoria su un server radice Hyper-V. È più importante verificare che sia allocata sufficiente memoria alle macchine virtuali per il supporto dei ruoli di Exchange.

Integrità dell'applicazione

Un modo semplice per capire se tutte le macchine virtuali sono integre consiste nell'esaminare i contatori di Riepilogo integrità macchine virtuali Hyper-V.

Contatore	Destinazione
Riepilogo integrità macchine virtuali Hyper-V\Integrità confermata	1
Riepilogo integrità macchine virtuali Hyper-V\Integrità critica	0

Server di cassette postali

Quando si verifica il corretto dimensionamento di un server Cassette postali, è opportuno concentrarsi su processore, memoria, spazio di archiviazione e integrità dell'applicazione Exchange. Questa sezione descrive l'approccio alla verifica di ciascuno di questi componenti.

Processore

Durante la progettazione, è stata calcolata la capacità in megacicli rettificata del server o della piattaforma del processore. Quindi, è stato calcolato il numero massimo di cassette postali attive che potevano essere supportate dal server senza superare l'80 per cento dei megacicli disponibili. Sono state altresì determinate le proiezione delle percentuali di utilizzo della CPU in condizioni di normale operatività e in vari scenari di manutenzione o errore dei server.

Durante la verifica, è necessario controllare che anche nel peggiore dei casi il carico non superi l'80 per cento dei megacicli disponibili. Verificare, inoltre, che l'utilizzo effettivo della CPU sia prossimo all'utilizzo previsto in condizioni di normale operatività e in diversi scenari di manutenzione o errore dei server.

Per la distribuzione fisica di Exchange, utilizzare il contatore Processore(_Total)\% Tempo del processore e verificare che questo contatore riporti in media una percentuale inferiore all'80 per cento.

Contatore	Destinazione
Processore(_Totale)\% tempo processore	<80%

Per la distribuzione virtuale di Exchange, il valore del contatore Processore(_Total)\% Tempo del processore viene calcolato nella macchina virtuale. In questo caso, il contatore non calcola l'utilizzo della CPU fisica, ma quello della CPU virtuale fornita dall'hypervisor. Pertanto, questo contatore non fornisce una lettura accurata del processore fisico e non va utilizzato per le procedure di verifica dell'architettura. Per ulteriori informazioni, vedere Hyper-v: Clocks lie... which performance counters can you trust? (informazioni in lingua inglese)

Per la verifica delle distribuzioni in esecuzione su Microsoft Hyper-V, utilizzare il contatore Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest. Questo contatore riporta un valore più preciso per la percentuale di CPU fisica utilizzata dal sistema operativo guest. Il valore medio del contatore deve essere inferiore all'80 per cento.

Contatore	Destinazione
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<80%

Memoria

Nel corso della progettazione, è stata calcolata la quantità di cache necessaria per supportare il numero massimo di database attivi su ciascun server Cassette postali. È stata poi determinata la configurazione di memoria fisica ottimale per supportare la cache del database e i requisiti di memoria del sistema.

Verificare se un server Cassette postali Exchange dispone di memoria sufficiente per supportare il carico previsto non è cosa semplice. Utilizzare i contatori della memoria disponibile per determinare quanta memoria fisica rimane non serve, in quanto il gestore della memoria in Exchange è progettato per utilizzare quasi tutta la memoria fisica disponibile. L'archivio delle informazioni (store.exe) riserva un'ampia porzione di memoria fisica per la cache del database. La cache del database viene utilizzata per tenere in memoria le pagine del database. Quando si accede a una pagina in memoria, le relative informazioni non vengono recuperate dal disco, con conseguente riduzione delle I/O di lettura. La cache del database viene utilizzata anche per ottimizzare le I/O di scrittura.

Quando una pagina del database viene modificata (è detta pagina dirty), essa viene tenuta nella cache per un determinato periodo di tempo. Quanto più a lungo la pagina rimane nella cache tanto maggiore è la probabilità che la pagina sia modificata più volte prima che le modifiche vengano effettivamente scritte sul disco. Tenere delle pagine dirty nella cache determina anche la scrittura di più pagine sul disco nella stessa operazione (evento noto come write coalescing). Exchange utilizza la massima quantità di memoria possibile ed è per questa ragione che su un server Cassette postali non rimane mai molta memoria disponibile.

Non è facile stabilire se la configurazione della memoria sul server Cassette postali è insufficiente. Nella maggior parte dei casi, il server Cassette postali funziona comunque, ma il relativo profilo di I/O potrebbe essere molto più alto del previsto. Un profilo I/O più alto può determinare maggiori latenze delle scritture e letture sul disco, con conseguente impatto sull'integrità e sulle prestazioni delle applicazioni. Nella sezione dei risultati, non è riportato alcun riferimento ai contatori della memoria. I potenziali problemi di memoria vengono riportati nella sezione dei risultati della verifica dell'archiviazione e in quella dei risultati della verifica dell'integrità delle applicazioni, in quanto con queste verifiche è più probabile rilevare questo tipo di problemi.

Archiviazione

Nel caso di problemi di prestazioni sul server Cassette postali, questi problemi potrebbero proprio essere legati alla memoria. I problemi di archiviazione potrebbero essere causati da un numero di dischi insufficiente rispetto ai requisiti di I/O previsti, da un'infrastruttura di connessione sovraccarica o con un'architettura inadeguata oppure da fattori in grado di alterare il profilo I/O target, come nel caso già visto di memoria insufficiente.

La prima fase della verifica dell'archiviazione consiste nel controllare che le latenze del database siano al di sotto delle soglie target. Nelle versioni precedenti, la latenza di lettura e scrittura su disco veniva riportata dai contatori dei dischi logici. In Exchange 2010, è probabile che il server Cassette postali Exchange che si sta monitorando abbia un mix di copie attive e passive di database Cassette postali. Le caratteristiche di I/O delle copie attive e passive del database sono diverse. Poiché le dimensioni delle I/O sono molto maggiori nelle copie passive, in queste ultime le latenze sono in genere molto più alte. Il target di latenza per le copie di database passive è 200 msec, che è 10 volte maggiore rispetto al target delle copie di database attive. In genere, questo non determina alcuna preoccupazione, in quanto le latenze sui database passivi non hanno alcun impatto sui client. Tuttavia, se si utilizzano i contatori dei dischi logici per calcolare le latenze, è necessario esaminare i singoli volumi e separare i volumi contenenti database attivi da quelli contenenti database passivi. In alternativa, si suggerisce di utilizzare i nuovi contatori Database di MSExchange in Exchange 2010.

Per la verifica delle latenze sui server Cassette postali in Exchange 2010, si consiglia di utilizzare i contatori riportati nella seguente tabella per i database attivi.

Contatore	Destinazione
Database di MSExchange\Latenza media I/O letture database (allegate)	<20 msec
Database di MSExchange\Latenza media I/O scritture database (allegate)	<20 msec
Database di MSExchange\Latenza media scritture registro I/O	<1 msec

Si consiglia di utilizzare i contatori riportati nella seguente tabella per i database passivi

Contatore	Destinazione
Database di MSExchange\Latenza media I/O letture database (ripristino)	<200 msec
Database di MSExchange\Latenza media I/O scritture database (ripristino)	<200 msec
Database di MSExchange\Latenza media letture registro I/O	<200 msec

Nota

Per visualizzare questi contatori in Performance Monitor, è necessario abilitare i contatori di database avanzati. Per ulteriori informazioni, vedere Abilitazione dei contatori di prestazioni ESE estesi.

Quando si effettua la verifica delle latenze dei dischi per le distribuzioni di Exchange in esecuzione su Microsoft Hyper-V, occorre ricordare che i contatori Latenza media database I/O (come molti altri contatori che calcolano il tempo) potrebbero non riportare valori precisi, in quanto il concetto di tempo sulle macchine virtuali è diverso rispetto a quello sul server fisico. L'esempio che segue mostra come il valore Latenza media I/O letture database (allegate) sia 22,8 sulla macchina virtuale e 17,3 su un server fisico per lo stesso carico simulato. Se i contatori basati sul tempo riportano valori superiori alle soglie target, ciò potrebbe indicare un funzionamento non corretto del server. Esaminare tutti i criteri di integrità prima di prendere una decisione concernente l'integrità del server, quando il ruolo di server Cassette postali viene distribuito nell'ambito di una macchina virtuale.

Valori dei contatori delle latenze dei dischi per i server Cassette postali virtuali e fisici

Contatore	Server Cassette postali virtuale	Server Cassette postali fisico
Database di MSExchange /
Letture database I/O (allegate) / Latenza media	22.792	17.250
Letture database I/O (allegate) / sec	17.693	18.131
Letture database I/O (recupero) / Latenza media	34.215	27.758
Scritture database I/O (recupero) / sec	10.829	8.483
Letture database I/O (allegate) / Latenza media	0.944	0.411
Scritture database I/O (allegate) / sec	10.184	10.963
MSExchangeIS
Latenza media RPC	1.966	1.695
Operazioni RPC al secondo	334.371	341.139
Pacchetti RPC / sec	180.656	183.360
MSExchangeIS Mailbox
Messaggi recapitati / sec	2.062	2.065
Messaggi inviati al secondo	0.511	0.514

Oltre alle latenze dei dischi, esaminare il contatore Database\Errori di pagina di database bloccati / sec. Questo contatore indica la percentuale di errori di pagina che possono essere gestiti in quanto non vi sono pagine disponibili per l'allocazione dalla cache del database. Questo contatore deve essere 0 su un server integro.

Contatore	Destinazione
Database\Blocchi errori di pagine di database/sec	<1

Inoltre, esaminare il contatore Database\Record di registro bloccati /sec che indica il numero di record di registro che non possono essere aggiunti ai buffer di registro in quanto i buffer sono pieni. Questo contatore deve avere un valore medio inferiore a 10.

Contatore	Destinazione
Database\Record di registro bloccati/sec	<10

Integrità dell'applicazione Exchange

Anche nel caso in cui non vi siano evidenti problemi di processore, memoria e dischi, si consiglia di tenere sotto controllo i contatori di integrità standard per essere certi che il server Cassette postali Exchange sia integro.

Il contatore MSExchangeIS\Latenza media RPC fornisce la migliore indicazione per valutare se gli altri contatori con latenze elevate stiano effettivamente impattando in modo negativo sull'integrità di Exchange e sulle prestazioni dei client. Spesso, elevate latenze medie RPC sono associate a un elevato numero di richieste RPC, che dovrebbe rimanere sempre al di sotto di 70.

Contatore	Destinazione
MSExchangeIS\Latenza media RPC	<10msec in media
MSExchangeIS\Richieste RPC	<70 sempre

Quindi, assicurarsi che il livello di trasporto sia integro. Tutti i problemi del trasporto o a valle del trasporto che impattano sul livello di trasporto possono essere rilevati tramite il contatore MSExchangeIS Cassetta postale(_Total)\Messaggi accodati per l'invio. Il valore riportato da questo contatore deve essere sempre inferiore a 50. In questo contatore potrebbero verificarsi degli aumenti temporanei, ma il valore non deve aumentare nel tempo e non deve rimanere troppo alto per più di 15 minuti.

Contatore	Destinazione
MSExchangeIS Mailbox(_Total)\Messaggi accodati per l'invio	<50 sempre

Quindi, accertarsi che la manutenzione delle copie del database avvenga in condizioni di integrità. Gli eventuali problemi di spedizione o riproduzione dei registri possono essere identificati utilizzando i contatori Replica di MSExchange(*)\CopyQueueLength e Replica di MSExchange(*)\ReplayQueueLength. La lunghezza della coda delle copie mostra il numero di registri delle transazioni in attesa di essere copiati nella cartella dei registri delle copie passive e deve essere inferiore a 1 sempre. La coda di riproduzione mostra il numero di registri di transazioni in attesa di essere riprodotti nella copia passiva e la sua lunghezza deve essere inferiore a 5. valori più alti non impattano sulle prestazioni dei client, ma prolungano i tempi di montaggio dell'archivio, in caso di passaggio, failover o attivazione.

Contatore	Destinazione
Replica MSExchange(*)\CopyQueueLength	<1
Replica di MSExchange(*)\ReplayQueueLength	<5

Server Accesso client

Per stabilire se un server Accesso client è integro, esaminare i contatori di integrità del processore, della memoria e dell'applicazione. Per un elenco completo dei contatori, vedere Contatori per i server Accesso client.

Processore

Per le distribuzioni fisiche di Exchange, utilizzare il contatore Processore (_ Totale) \% tempo processore. Il valore medio del contatore deve essere inferiore all'80 per cento.

Contatore	Destinazione
Processore(_Totale)\% tempo processore	<80%

Contatore	Destinazione
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<80%

Integrità dell'applicazione

Per stabilire se l'esperienza client MAPI è accettabile, utilizzare il contatore MSExchange RpcClientAccess\Latenza media RPC. Questo contatore dovrebbe riportare un valore inferiore a 250 msec. Elevate latenze possono essere associate a un gran numero di richieste RPC. Il valore medio del contatore MSExchange RpcClientAccess\Richieste RPC deve rimanere al di sotto di 40.

Contatore	Destinazione
MSExchange RpcClientAccess\Latenza media RPC	<250 msec
MSExchange RpcClientAccess\Richieste RPC	<40

Server di trasporto

Per stabilire se un server di trasporto è integro, esaminare i contatori di integrità del processore, dei dischi e dell'applicazione. Per un elenco completo dei contatori, vedere Contatori per server di trasporto.

Processore

Per le distribuzioni fisiche di Exchange, utilizzare il contatore Processore (_ Totale) \% tempo processore. Il valore medio del contatore deve essere inferiore all'80 per cento.

Contatore	Destinazione
Processore(_Totale)\% tempo processore	<80%

Contatore	Destinazione
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<80%

Disco

Per stabilire se le prestazioni dei dischi sono accettabili, utilizzare i contatori Disco logico(*)\Media letture disco/sec e Disco logico(*)\Media scritture disco/sec per i volumi contenenti i registri e i database del trasporto. Entrambi i contatori devono riportare un valore inferiore a 20 msec.

Contatore	Destinazione
Disco logico(*)\Media letture disco/sec	<20 msec
Disco logico(*)\Media scritture disco/sec	<20 msec

Integrità dell'applicazione

Per stabilire se un server Trasporto Hub è adeguatamente dimensionato e integro, esaminare i contatori Code di MSExchangeTransport riportarti nella tabella che segue. Tutte queste code conterranno dei messaggi in tempi diversi. Occorre verificare che la lunghezza delle code non aumenti nel tempo. Se ciò accade, significa che il server Trasporto Hub potrebbe essere sovraccarico. In alternativa, il problema potrebbe riguardare la rete o una server Cassette postali sovraccarico che non è più in grado di ricevere nuovi messaggi. Per avere la certezza, occorre verificare anche altri componenti dell'ambiente Exchange.

Contatore	Destinazione
Code di MSExchangeTransport(_total)\Recapito aggregato	<3000
Code di MSExchangeTransport(_total)\Lunghezza coda di recapito remota attiva	<250
Code di MSExchangeTransport(_total)\Lunghezza coda di recapito attiva delle cassette postali	<250
Code di MSExchangeTransport(_total)\Lunghezza coda dei tentativi di recapito delle cassette postali	<100
Code di MSExchangeTransport(_total)\Lunghezza coda di invio	<100

Soluzioni testate per Exchange 2010

Test di verifica funzionale

Per i test di verifica funzionale è possibile utilizzare le informazioni incluse nelle seguenti sezioni.

Soluzioni testate per Exchange 2010

Verifica del passaggio di database

Un passaggio di database è la procedura mediante la quale un singolo database attivo viene trasferito su un'altra copia del database (copia passiva) che diventa la nuova copia attiva del database. I switchover possono avvenire sia all'interno dei datacenter che tra l'uno e l'altro. È possibile eseguire un passaggio di database utilizzando Exchange Management Console (EMC) o Exchange Management Shell.

Per verificare che una copia passiva del database possa essere correttamente attivata su un altro server, utilizzare il seguente comando:

Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>

Criteri di verifica completata: il database delle cassette postali attive è montato sul server di destinazione specificato. È possibile confermare questo risultato utilizzando il seguente comando:

Get-MailboxDatabaseCopyStatus <DatabaseName>

Soluzioni testate per Exchange 2010

Verifica del passaggio di server

Un switchover del server è la procedura mediante la quale tutti i database attivi su un membro DAG sono attivati su uno o più altri membri DAG. Come i switchover dei database, un switchover di un server può avvenire sia nell'ambito di un datacenter che tra un datacenter e l'altro e può essere avviato utilizzando EMC o Shell.

Per verificare che tutte le copie passive dei database su un server possano essere correttamente attivate su altri server che ospitano una copia passiva, utilizzare il seguente comando:
```
Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>
```
Criteri di verifica completata: i database delle cassette postali attive sono montati sul server di destinazione specificato. È possibile confermare questo risultato utilizzando il seguente comando:
```
Get-MailboxDatabaseCopyStatus <DatabaseName>
```
Per verificare che una copia di ciascuno dei database attivi sarà correttamente attivata su un altro server Cassette postali che ospita copie passive dei database, chiudere il server facendo quanto segue.

Spegnere il server attivo corrente.

Criteri di verifica completata: I database delle cassette postali attive sono montati su un altro server delle cassette postali nel DAG. È possibile confermare questo risultato utilizzando il seguente comando:
```
Get-MailboxDatabaseCopyStatus <DatabaseName>
```

Soluzioni testate per Exchange 2010

Verifica del failover di server

Un failover del server si verifica quando il membro del gruppo di disponibilità del database non è più in grado di operare con la rete MAPI oppure quando il servizio cluster di un membro del gruppo di disponibilità non è più in grado di contattare i rimanenti membri del gruppo di disponibilità del database.

Per verificare che una copia di ciascuno dei database attivi sarà correttamente attivata su un altro server Cassette postali che ospita copie passive dei database, chiudere il server effettuando una delle seguenti azioni:

Tenere premuto il pulsante di alimentazione sul server fino a quando il server non si spegne.
Scollegare i cavi di alimentazione dal server, determinando lo spegnimento del server stesso.

Criteri di verifica completata: I database delle cassette postali attive sono montati su un altro server delle cassette postali nel DAG. È possibile confermare questo risultato utilizzando il seguente comando:

Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus

Soluzioni testate per Exchange 2010

Verifica del passaggio di datacenter

Un errore di un datacenter o di un sito viene gestito differentemente rispetto ai tipi di errore che potrebbero provocare un failover del server o del database. In una configurazione ad elevata disponibilità, il ripristino automatico viene avviato dal sistema e l'errore generalmente lascia il sistema di messaggistica in uno stato completamente funzionante. Contrariamente, un errore del datacenter viene considerato un'operazione di ripristino di emergenza e il ripristino deve essere eseguito e completato manualmente per il servizio client da ripristinare e per l'interruzione da terminare. La procedura eseguita viene denominata switchover del datacenter. Come per molti scenari di ripristino di emergenza, la pianificazione e preparazione anticipata di uno switchover del datacenter può semplificare il processo e ridurre la durata dell'interruzione.

Per ulteriori informazioni sullo switchover di datacenter, incluse le procedure dettagliate di esecuzione, vedere Passaggi centro dati.

Sono disponibili quattro passaggi di base da completare per eseguire lo switchover del centro dati, una volta deciso di attivare il secondo centro dati:

Interruzione di un datacenter parzialmente in esecuzione (in errore).
Verificare e confermare i prerequisiti per il secondo datacenter.
Attivare i server Cassette postali.
Attivare i server Accesso Client.

Le sezioni seguenti descrivono i passaggi utilizzati per verificare un passaggio di datacenter.

Interrompere un datacenter parzialmente in errore (presupponendo che il DAG sia in modalità DAC)

Quando il gruppo di disponibilità del database è in modalità di coordinazione dell'attivazione del database, le specifiche azioni per terminare i membri del gruppo di disponibilità del database ancora attivi nel datacenter principale dipende dallo stato del datacenter in errore. Effettuare una delle operazioni seguenti:

Se i server Cassette postali nel datacenter in errore sono ancora accessibili (in genere non lo sono), eseguire questo comando su ciascun server Cassette postali:
```
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>
```
Se i server Cassette postali nel datacenter in errore sono indisponibili e Active Directory funziona nel datacenter principale, eseguire questo comando su un controller di dominio:
```
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
```

Nota

Un errore durante la disattivazione dei server Cassette postali nel centro dati danneggiato o l'esecuzione del comando Stop-DatabaseAvailabilityGroup sui server può comportare la possibilità che si verifichi la sindrome split brain sui due datacenter. Potrebbe essere necessario disattivare singolarmente i computer tramite i dispositivi di risparmio energia per soddisfare questo requisito.

Criteri di verifica completata: Tutti i server Cassette postali nel sito in errore sono fermi. Questa condizione può essere verificata eseguendo questo comando da un server del datacenter in errore:

Get-DatabaseAvailabilityGroup | Format-List

Verificare e confermare i prerequisiti per il datacenter secondario

È ora necessario aggiornare il secondo datacenter per indicare quali server del datacenter principale sono fermi. Da un server del datacenter secondario, eseguire questo comando:

Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly

Lo scopo di questo passaggio è informare i server del datacenter secondario su quali sono i server Cassette postali disponibili per l'uso durante il servizio di ripristino.

Criteri di verifica completata: tutti i server Cassette postali nel datacenter in errore sono fermi. Per verificare questa condizione, eseguire questo comando da un server del datacenter secondario:

Get-DatabaseAvailabilityGroup | Format-List

Attivare i server Cassette postali (supponendo che il DAG sia in modalità DAC)

Prima di attivare i membri del gruppo di disponibilità del database nel datacenter secondario, è opportuno verificare che i servizi di infrastruttura nel secondo datacenter siano pronti per l'attivazione del servizio di messaggistica.

Di seguito, è riportata la procedura per il completamento dell'attivazione dei server Cassette postali nel datacenter secondario quando il gruppo di disponibilità del database è in modalità di coordinazione dell'attivazione del database:

Arrestare il servizio cluster in ogni membro del DAG nel datacenter secondario. È possibile utilizzare il cmdlet Stop-Service per arrestare il servizio (ad esempio, Stop-Service ClusSvc) oppure utilizzare net stop clussvc da un prompt dei comandi elevato.
Per attivare i server Cassette postali nel datacenter secondario, eseguire questo comando:
```
Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>
```
Se si utilizza tale comando, i criteri del quorum vengono compressi nei server del datacenter secondario. Se il numero di server in quel centro dati è un numero pari, verrà attivato il gruppo di disponibilità del database mediante l'uso del server di controllo alternativo come identificato dall'impostazione dell'oggetto gruppo di disponibilità del database.

Per attivare i database, eseguire uno di questi comandi:

Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>

oppure

Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>

Controllare i registri degli eventi e leggere tutti i messaggi di avviso ed errore per verificare che il sito secondario sia integro. Tutti i problemi riportati vanno seguiti e risolti prima del montaggio dei database.

Per montare i database, utilizzare il seguente comando:

Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database

Criteri di verifica completata: i database Cassette postali attivi sono montati sui server Cassette postali nel sito secondario. Ad esempio, eseguire questo comando:

Get-MailboxDatabaseCopyStatus <DatabaseName>

Attivazione dei server Accesso client

I client si connettono agli endpoint del servizio per accedere ai dati e ai servizi Exchange. Pertanto, l'attivazione dei server Accesso client con accesso a Internet implica la modifica dei record DNS affinché puntino ai nuovi indirizzi IP che verranno configurati per i nuovi endpoint del servizio. I client si connetteranno automaticamente ai nuovi endpoint del servizio in uno dei due modi riportati di seguito:

I client continueranno a tentare la connessione e dovrebbero connettersi automaticamente una volta scaduto il valore TTL (Time to Live) per la voce DNS originale e una volta che la voce risulta scaduta dalla cache DNS del client. Gli utenti possono anche eseguire il comando ipconfig /flushdns da un prompt dei comandi per cancellare manualmente la propria cache DNS. Se si utilizza Outlook Web App, potrebbe essere necessario chiudere e riaprire il browser per cancellare la cache DNS utilizzata dal browser stesso. In Exchange 2010 SP1, è possibile mitigare questo problema della cache del browser configurando il parametro FailbackURL nella directory virtuale owa di Outlook Web App.
L'avvio o riavvio dei client comporterà una ricerca DNS all'avvio e consentirà di ottenere il nuovo indirizzo IP per l'endpoint del servizio che sarà un server Accesso client o una matrice nel secondo centro dati.

Per verificare lo scenario con Loadgen, effettuare le seguenti operazioni:

Modificare la voce DNS dell'array del server Accesso client in modo che punti all'indirizzo IP virtuale del bilanciamento del carico hardware nel sito secondario.
Eseguire il comando ipconfig /flushdns su tutti i server Loadgen.
Riavviare il test Loadgen.
Verificare che i server Accesso client del sito secondario stiano ora sostenendo il carico.

Per verificare lo scenario con un client Outlook 2007, effettuare le seguenti operazioni:

Modificare la voce DNS dell'array del server Accesso client in modo che punti all'indirizzo IP virtuale del bilanciamento del carico hardware nel sito secondario.
Eseguire il comando ipconfig /flushdns sui client o attendere che sia trascorso il tempo TTL (Time to Live).
Attendere che il client Outlook si riconnetta.

Soluzioni testate per Exchange 2010

Verifica del ripristino del servizio per il datacenter principale

Il processo di ripristino del servizio per un centro dati precedentemente danneggiato viene definito failback. La procedura utilizzata per eseguire un failback del centro dati è analoga a quella utilizzata per eseguire uno switchover del centro dati. Una distinzione significativa è che i failback del centro dati sono programmati e la durata dell'interruzione spesso è molto breve.

È importante che il failback non venga eseguito fino a quando le dipendenze dell'infrastruttura per Exchange non saranno state riattivate, rese funzionanti e stabili nonché verificate. Se tali dipendenze non sono disponibili o integre, è probabile che il processo di failback provochi un'interruzione maggiore del necessario ed è possibile che il processo non venga portato a termine correttamente.

Il ruolo del server Cassette postali dovrebbe essere il primo ruolo per il quale viene eseguito il failback al centro dati principale. I passaggi che seguono descrivono in dettaglio il processo di failback del ruolo server Cassette postali (presupponendo che il DAG sia in modalità DAC).

Per reincorporare i membri del gruppo di disponibilità del database nel sito principale, utilizzare il seguente comando:
```
Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>
```
Per verificare lo stato delle copie del database nel datacenter principale, utilizzare il seguente comando:
```
Get-MailboxDatabaseCopyStatus
```

Una volta incorporati i server Cassette postali del centro dati principale nel gruppo di disponibilità del database, sarà necessario sincronizzarne saltuariamente le relative copie del database. A seconda del tipo di errore, della durata dell'interruzione e delle azioni intraprese da un amministratore durante l'interruzione, ciò potrebbe richiedere il reseeding delle copie del database. Ad esempio, se durante l'interruzione, si rimuovono le copie del database dal datacenter principale danneggiato per consentire il troncamento dei file di registro per le restanti copie attive nel datacenter secondario, sarà necessario eseguire il reseeding. In questo momento, ogni database può essere sincronizzato individualmente. Una volta verificata l'integrità di una copia del database replicata nel datacenter principale, è possibile procedere con il passaggio successivo.

Durante il processo di switchover del centro dati, il gruppo di disponibilità del database era configurato per utilizzare un server di controllo alternativo. Per riconfigurare il gruppo di disponibilità del database in modo che utilizzi un server di controllo nel datacenter principale, utilizzare il seguente comando.
```
Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>
```
I database in fase di riattivazione nel datacenter principale devono essere smontati nel datacenter secondario. Eseguire il comando riportato di seguito.
```
Get-MailboxDatabase | Dismount-Database
```
Una volta smontati i database, è necessario spostare gli URL del server Accesso client dal datacenter secondario al datacenter principale. Per farlo, modificare il record DNS degli URL in modo che puntino al server Accesso client o all'array del datacenter principale.

Importante

Non passare al passo successivo fino allo spostamento degli URL del server Accesso client e alla scadenza delle voci della cache e del valore TTL del DNS. L'attivazione dei database nel datacenter principale prima di trasferirvi gli URL del server Accesso client comporta una configurazione errata (ad esempio, viene montato un database privo di server Accesso client nel relativo sito Active Directory).

Per attivare i database, eseguire uno di questi comandi:

Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>

oppure

Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>

Per montare i database, utilizzare il seguente comando:

Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database

Criteri di verifica completata: i database Cassette postali attivi sono correttamente montati sui server Cassette postali del sito principale. Ad esempio, eseguire questo comando:

Get-MailboxDatabaseCopyStatus <DatabaseName>

Soluzioni testate per Exchange 2010

Sede dei test

I test sono stati condotti presso il Microsoft Enterprise Engineering Center, un modernissimo laboratorio per la verifica delle soluzioni enterprise che si trova all'interno del complesso principale Microsoft di Redmond, nello stato di Washington.

Con oltre 125 milioni di dollari di hardware e una forte e duratura partnership con i principali OEM (Original Equipment Manufacturers) del settore, il laboratorio EEC è in grado di replicare pressoché qualunque ambiente di produzione. L'EEC offre un ambiente che consente un'ampia collaborazione tra clienti, partner e tecnici Microsoft. Ciò garantisce che le soluzioni end-to-end di Microsoft soddisfino le elevate aspettative dei clienti.

Soluzioni testate per Exchange 2010

Risultati della verifica

Le seguente sezione fornisce un quadro sintetico dei risultati dei test di verifica funzionale e delle prestazioni.

Soluzioni testate per Exchange 2010

Risultati della verifica funzionale

La seguente tabella riassume i risultati dei test di verifica funzionale.

Risultati della verifica funzionale

Test case	Risultato	Commenti
Passaggio di database	Riuscito	Completato senza errori
Passaggio di server	Riuscito	Completato senza errori
errore del server	Riuscito	Completato senza errori
Errore del sito	Riuscito	Completato senza errori

Soluzioni testate per Exchange 2010

Risultati della verifica dell'architettura di archiviazione

I test di tutti i dischi di ciascun sito su un singolo storage frame mostrano che il modello CX4-480 è in grado di gestire poco più di 8.000 operazioni IOPS transazionali di Exchange 2010 su otto macchine virtuali Exchange configurate con un profilo utente di 150 messaggi a 0,15 IOPS e un 20 per cento di margine aggiuntivo. Le prestazioni hanno superato l'obiettivo base di 5.832 IOPS necessario per questa configurazione e hanno garantito un margine aggiuntivo per affrontare eventuali picchi di carico. Le latenze dei dischi rientravano tutte entro parametri accettabili secondo le migliori procedure Microsoft relative alle prestazioni di Exchange 2010.

Risultati della verifica dell'architettura di archiviazione

I/O database	Valori target	4 server Cassette postali in condizioni operative normali (2.700 utenti per server Cassette postali)	4 server Cassette postali in condizione di passaggio (5.400 utenti per server Cassette postali)	Totale
Numero di IOPS transazionali raggiunto (Letture database I/O/sec + Scritture database I/O/sec)	1944 / 3888	3576 IOPS	4488 IOPS	8064 IOPS
Letture database I/O/sec	Non applicabile	2193	2729	4922
Scritture database I/O/sec	Non applicabile	1439	1703	3142
Latenza media letture database I/O (msec)	<20 msec	14	18	16
Latenza media scritture database I/O (msec)	Non è un buon indicatore per la latenza del client perché le scritture del database sono asincrone	14	18	16

Scritture registro I/O/sec	Non applicabile	1238	1560	2798
Latenza media letture registro I/O (msec)	<10 msec	2	2	2

Soluzioni testate per Exchange 2010

Risultati della verifica dell'architettura di archiviazione

Le sezioni che seguono forniscono un riepilogo dei risultati della verifica dell'architettura server in base ai test case utilizzati.

Verifica LoadGen: scenari di test

Test	Descrizione
Operatività normale	In un sito è stato simulato un carico di concorrenza del 100 per cento per 10.800, con 2.700 utenti gestiti da ciascun server Cassette postali.
Errore server singolo o manutenzione server singolo (in sito)	È stato simulato l'errore di un singolo server Hyper-V in ciascun sito. Un carico di concorrenza del 100 per cento è stato applicato a un singolo host Hyper-V con una macchina virtuale che gestiva 5.400 utenti. Il carico era gestito solo da tre server Accesso client e Trasporto hub combinati.
Errore del sito	È stato simulato un errore del sito e sono state attivate le immagini secondarie su macchine virtuali del server Cassette postali di standby. È stato applicato un carico di concorrenza del 100 per cento per 21.600 utenti in un singolo sito.

Test case: Condizioni di operatività normali

Questo test case rappresenta il picco di carico durante la normale operatività. Per condizioni di normale operatività s'intende lo stato per cui tutti database attivi e passivi risiedono sui server sui quali era già pianificato dovessero risiedere. Poiché questo test case non rappresenta il caso peggiore in termini di carico, il relativo test di verifica non è particolarmente probante per le prestazioni. Tuttavia, fornisce una buona indicazione di come questo ambiente si deve comportare in caso di errore o manutenzione di un server. L'obiettivo di questo test era verificare l'intero ambiente Exchange in normali condizioni di operatività con un picco di carico. Tutte le macchine virtuali Exchange operavano in condizioni normali. LoadGen è stato configurato per simulare il picco di carico. Era previsto che il profilo di 150 messaggi in modalità di picco generasse un numero doppio di messaggi inviati e recapitati al secondo.

Verifica del carico previsto

La velocità di recapito del messaggio consente di verificare che il carico di lavoro testato corrisponda al carico target. La velocità di recapito dei messaggi è leggermente superiore al target, determinando un carico leggermente superiore rispetto al profilo desiderato.

Contatore	Destinazione	Risultato testato
Velocità di recapito dei messaggi per cassetta postale	15.0	15.2

Verifica dei server Cassette postali principali

Le tabelle che seguono riportano i risultati della verifica ottenuti dalle macchine virtuali del server Cassette postali principale.

Processore

L'utilizzo del processore è inferiore all'70 per cento, come previsto.

Contatore	Destinazione	Risultato testato
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<70%	69

Archiviazione

I risultati dell'archiviazione sono buoni. Tutte le latenze sono sotto i valori target.

Contatore	Destinazione	Risultato testato
Database di MSExchange\Latenza media I/O letture database (allegate)	<20 msec	19
Database di MSExchange\Latenza media I/O scritture database (allegate)	<20 msec <Media letture	18
Database\Blocchi errori di pagine di database/sec	0	0
Database di MSExchange\Latenza media scritture registro I/O	<20 msec	5
Database\Record di registro bloccati/sec	0	0

Integrità dell'applicazione

Exchange è un'applicazione integra e tutti i contatori utilizzati per determinare lo stato di integrità dell'applicazione riportano valori inferiori ai valori target.

Contatore	Destinazione	Risultato testato
MSExchangeIS\Richieste RPC	<70	3.0
MSExchangeIS\Latenza media RPC	<10 msec	2.0
MSExchangeIS Mailbox(_Total)\Messaggi accodati per l'invio	0	2.0

Verifica dei server Cassette postali secondari

Le tabelle che seguono riportano i risultati della verifica ottenuti dalle macchine virtuali del server Cassette postali secondario.

Processore

L'utilizzo del processore è inferiore all'70 per cento, come previsto.

Contatore	Destinazione	Risultato testato
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<70%	26

Archiviazione

I risultati dell'archiviazione sono buoni. Tutte le latenze sono sotto i valori target.

Contatore	Destinazione	Risultato testato
Database di MSExchange\Latenza media I/O letture database (ripristino)	<100 msec	0
Database di MSExchange\Latenza media I/O scritture database (ripristino)	<100 msec <Media letture	16
Database\Blocchi errori di pagine di database/sec	0	0
Database di MSExchange\Latenza media scritture registro I/O	<20 msec	3
Database\Record di registro bloccati/sec	0	0

Integrità dell'applicazione

I server Cassette postali secondari mantengono solo le terze copie dei database passivi, pertanto gli indicatori standard dello stato di integrità dell'applicazione Exchange non sono applicabili a questo scenario.

Contatore	Destinazione	Risultato testato
MSExchangeIS\Richieste RPC	<70	Non applicabile
MSExchangeIS\Latenza media RPC	<10 msec	Non applicabile
MSExchangeIS Mailbox(_Total)\Messaggi accodati per l'invio	0	Non applicabile

Verifica dei server Accesso client e Trasporto Hub

Le tabelle che seguono riportano i risultati della verifica ottenuti dalle macchine virtuali dei server Accesso client e Trasporto Hub.

Processore

La percentuale di utilizzo del processore è bassa, come previsto.

Contatore	Destinazione	Risultato testato
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<70%	48

Archiviazione

I risultati dell'archiviazione sembrano buoni. Le latenze molto basse non dovrebbero avere alcun impatto sul trasporto dei messaggi.

Contatore	Destinazione	Risultato testato
Disco logico/fisico(*)\Media letture disco/sec	<20 msec	0.001
Disco logico/fisico(*)\Media scritture disco/sec	<20 msec	0.005

Integrità dell'applicazione

I bassi valori di latenza media RPC confermano lo stato di integrità del server Accesso client senza alcun impatto sulle prestazioni client.

Contatore	Destinazione	Risultato testato
MSExchange RpcClientAccess\Latenza media RPC	<250 msec	8
MSExchange RpcClientAccess\Richieste RPC	<40	3

I contatori delle code di trasporto riportano valori inferiori ai valori target, confermando l'integrità del server Trasporto Hub e la sua capacità di elaborare e recapitare i messaggi.

Contatore	Destinazione	Risultato testato
\Code di MSExchangeTransport(_total)\Lunghezza coda di recapito aggregata (tutte le code)	<3000	2.5
\Code di MSExchangeTransport(_total)\Lunghezza coda di recapito remota attiva	<250	0
\Code di MSExchangeTransport(_total)\Lunghezza coda di recapito attiva delle cassette postali	<250	2.3
\Code di MSExchangeTransport(_total)\Lunghezza coda di invio	<100	0
\Code di MSExchangeTransport(_total)\Lunghezza coda dei tentativi di recapito delle cassette postali	<100	0.3

Verifica dell'integrità del server radice

Le tabelle che seguono riportano i risultati della verifica del server radice Hyper-V.

Processore

Come previsto, la percentuale di utilizzo del processore è molto bassa e ben al di sotto delle soglie target.

Contatore	Destinazione	Risultato testato
Processore logico hypervisor Hyper-V(_total)\% Tempo di esecuzione guest	<75%	66
Processore logico hypervisor Hyper-V(_total)\% Tempo di esecuzione hypervisor	<5%	2
Processore logico hypervisor Hyper-V(_total)\% Tempo di esecuzione totale	<80%	68
Processore virtuale radice hypervisor Hyper-V(_total)\% Tempo di esecuzione guest	<5%	3

Integrità dell'applicazione

I contatori relativi allo stato di integrità delle macchine virtuali indicano che tutte la macchine virtuali sono integre.

Contatore	Destinazione	Risultato testato
Riepilogo integrità macchine virtuali Hyper-V\Integrità critica	0	0

Test case: Errore server singolo o manutenzione server singolo (in sito)

L'obiettivo di questo test era verificare l'intero ambiente Exchange in condizioni di errore o manutenzione di un server radice Hyper-V fisico con un picco di carico. Tutte le macchine virtuali in esecuzione su uno dei server radice Hyper-V nel sito sono state chiuse per simulare una condizione di manutenzione dell'host. Di conseguenza, le immagini dei database (copie) sono state trasferite su altre macchine virtuali dei server Cassette postali, creando una condizione operativa con 5.400 utenti per ogni macchina virtuale del server Cassette postali. Solo la metà dei server Accesso client e Trasporto Hub combinati gestiva l'accesso ai client e il recapito dei messaggi di posta elettronica.

Verifica del carico previsto

La velocità effettiva di recapito dei messaggi era entro il valore target.

Contatore	Destinazione	Risultato testato
Velocità di recapito dei messaggi per server	30	30

Verifica dei server Cassette postali principali

Le tabelle che seguono riportano i risultati della verifica ottenuti dalle macchine virtuali del server Cassette postali principale.

Processore

La percentuale di utilizzo del processore è appena superiore al target. Questo test case rappresenta uno scenario di errore o manutenzione con picco di carico, quindi rappresenta un evento che ha scarse probabilità di verificarsi. Tuttavia, non è auspicabile mantenere una percentuale di utilizzo del processore così alta per un lungo periodo di tempo.

Contatore	Destinazione	Risultato testato
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<80%	83

Archiviazione

I risultati dell'archiviazione sembrano accettabili. La latenza di lettura media è di poco superiore al valore target. La latenza media di scrittura nel database è maggiore del previsto. Questo si verifica nel caso peggiore, vale a dire uno scenario di errore con picco di carico, un evento che non capita molto spesso. Le latenze elevate non fanno innalzare i valori dei contatori di integrità oltre le soglie target, per cui gli utenti dovrebbero continuare ad avere una condizione di operatività accettabile. Tuttavia, non è auspicabile mantenere valori di latenza così alti per un lungo periodo di tempo.

Contatore	Destinazione	Risultato testato
Database di MSExchange\Latenza media I/O letture database (allegate)	<20 msec	20.5
Database di MSExchange\Latenza media I/O scritture database (allegate)	<20 msec	23
Database\Blocchi errori di pagine di database/sec	0	0
Database di MSExchange\Latenza media scritture registro I/O	<20 msec	8
Database\Record di registro bloccati/sec	0	0

Integrità dell'applicazione

I contatori mostrano che Exchange è ancora ragionevolmente integro. Un certo accumulo di messaggi nella coda indica che sta iniziando a formarsi un picco di carico. Non è auspicabile protrarre questa condizione per un lungo periodo di tempo.

Contatore	Destinazione	Risultato testato
MSExchangeIS\Richieste RPC	<70	9.0
MSExchangeIS\Latenza media RPC	<10 msec	2.0
MSExchangeIS Mailbox(_Total)\Messaggi accodati per l'invio	0	77

Verifica dei server Cassette postali secondari

Le tabelle che seguono riportano i risultati della verifica ottenuti dalle macchine virtuali del server Cassette postali secondario.

Processore

L'utilizzo del processore è inferiore all'70 per cento, come previsto.

Contatore	Destinazione	Risultato testato
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<70%	21

Archiviazione

I risultati dell'archiviazione sono buoni. Tutte le latenze sono sotto i valori target.

Contatore	Destinazione	Risultato testato
Database di MSExchange\Latenza media I/O letture database (ripristino)	<100 msec	0
Database di MSExchange\Latenza media I/O scritture database (ripristino)	<100 msec <Media letture	21
Database\Blocchi errori di pagine di database/sec	0	0
Database di MSExchange\Latenza media scritture registro I/O	<20 msec	3
Database\Record di registro bloccati/sec	0	0

Integrità dell'applicazione

Contatore	Destinazione	Risultato testato
MSExchangeIS\Richieste RPC	<70	Non applicabile
MSExchangeIS\Latenza media RPC	<10 msec	Non applicabile
MSExchangeIS Mailbox(_Total)\Messaggi accodati per l'invio	0	Non applicabile

Verifica dei server Accesso client e Trasporto Hub

Le tabelle che seguono riportano i risultati della verifica ottenuti dalle macchine virtuali dei server Accesso client e Trasporto Hub.

Processore

L'utilizzo del processore è inferiore all'80 per cento, come previsto.

Contatore	Destinazione	Risultato testato
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<80%	74

Archiviazione

I risultati dell'archiviazione sembrano buoni. Le latenze molto basse non dovrebbero avere alcun impatto sul trasporto dei messaggi.

Contatore	Destinazione	Risultato testato
Disco logico/fisico(*)\Media letture disco/sec	<20 msec	0.001
Disco logico/fisico(*)\Media scritture disco/sec	<20 msec	0.008

Integrità dell'applicazione

I bassi valori di latenza media RPC confermano lo stato di integrità del server Accesso client senza alcun impatto sulle prestazioni client.

Contatore	Destinazione	Risultato testato
MSExchange RpcClientAccess\Latenza media RPC	<250 msec	18
MSExchange RpcClientAccess\Richieste RPC	<40	14

I contatori delle code di trasporto riportano valori inferiori ai valori target, confermando l'integrità del server Trasporto Hub e la sua capacità di elaborare e recapitare i messaggi.

Contatore	Destinazione	Risultato testato
\Code di MSExchangeTransport(_total)\Lunghezza coda di recapito aggregata (tutte le code)	<3000	49
\Code di MSExchangeTransport(_total)\Lunghezza coda di recapito remota attiva	<250	0
\Code di MSExchangeTransport(_total)\Lunghezza coda di recapito attiva delle cassette postali	<250	43
\Code di MSExchangeTransport(_total)\Lunghezza coda di invio	<100	53
\Code di MSExchangeTransport(_total)\Lunghezza coda dei tentativi di recapito delle cassette postali	<100	4

Verifica dell'integrità del server radice

Le tabelle che seguono riportano i risultati della verifica del server radice Hyper-V.

Processore

La percentuale di utilizzo del processore è prossima alla soglia target, evento previsto in uno scenario di errore o manutenzione con picco di carico.

Contatore	Destinazione	Risultato testato
Processore logico hypervisor Hyper-V(_total)\% Tempo di esecuzione guest	<75%	77
Processore logico hypervisor Hyper-V(_total)\% Tempo di esecuzione hypervisor	<5%	2
Processore logico hypervisor Hyper-V(_total)\% Tempo di esecuzione totale	<80%	79
Processore virtuale radice hypervisor Hyper-V(_total)\% Tempo di esecuzione guest	<5%	3

Integrità dell'applicazione

I contatori relativi allo stato di integrità delle macchine virtuali indicano che tutte la macchine virtuali sono integre.

Contatore	Destinazione	Risultato testato
Riepilogo integrità macchine virtuali Hyper-V\Integrità critica	0	0

Test case: Errore del sito e passaggio dei database

Questo test case simula un errore del sito con il passaggio dei database attivi del sito principale ai database passivi del sito secondario che determina 21.600 cassette postali attive in uno stesso sito. Le quattro macchine virtuali del server Cassette postali principale nel sito superstite gestiscono un normale carico di 2.700 cassette postali attive ciascuna. Le quattro macchine virtuali del server Cassette postali secondario nel sito superstite gestiscono ora 2.700 cassette postali attive ciascuna. Ciascun server radice Hyper-V ospita 5.400 cassette postali attive.

Verifica del carico previsto

La velocità di recapito dei messaggi è leggermente superiore al target, determinando un carico leggermente superiore rispetto al profilo desiderato.

Contatore	Destinazione	Risultato testato
Velocità di recapito dei messaggi per server	15	15.1

Verifica dei server Cassette postali principali

Le tabelle che seguono riportano i risultati della verifica ottenuti dalle macchine virtuali del server Cassette postali principale.

Processore

Le macchine virtuali del server Cassette postali principale gestiscono un carico di lavoro normale e, come previsto, hanno una percentuale di utilizzo del processore inferiore al target.

Contatore	Destinazione	Risultato testato
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<70%	63

Archiviazione

I risultati dell'archiviazione sono buoni. Tutte le latenze sono sotto i valori target.

Contatore	Destinazione	Risultato testato
Database di MSExchange\Latenza media I/O letture database (allegate)	<20 msec	12
Database di MSExchange\Latenza media I/O scritture database (allegate)	<20 msec	13
Database\Blocchi errori di pagine di database/sec	0	0
Database di MSExchange\Latenza media scritture registro I/O	<20 msec	4
Database\Record di registro bloccati/sec	0	0

Integrità dell'applicazione

Exchange è un'applicazione integra e tutti i contatori utilizzati per determinare lo stato di integrità dell'applicazione riportano valori inferiori ai valori target.

Contatore	Destinazione	Risultato testato
MSExchangeIS\Richieste RPC	<70	3.0
MSExchangeIS\Latenza media RPC	<10 msec	2.0
MSExchangeIS Mailbox(_Total)\Messaggi accodati per l'invio	0	3

Verifica dei server Cassette postali secondari

Le tabelle che seguono riportano i risultati della verifica ottenuti dalle macchine virtuali del server Cassette postali secondario.

Processore

L'utilizzo del processore è appena superiore al target dell'80 per cento. È una percentuale più alta di quella ottimale, ma non sembra impattare su altri contatori dello stato di integrità di Exchange. Poiché questo test rappresenta un picco di carico durante una condizione di errore del sito che ha scarse probabilità di verificarsi, va bene così. Tuttavia, non è auspicabile mantenere questa percentuale di utilizzo del processore per un lungo periodo di tempo.

Contatore	Destinazione	Risultato testato
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<80%	84

Archiviazione

I risultati dell'archiviazione sono buoni. Tutte le latenze sono sotto i valori target.

Contatore	Destinazione	Risultato testato
Database di MSExchange\Latenza media I/O letture database (allegate)	<20 msec	17
Database di MSExchange\Latenza media I/O scritture database (allegate)	<20 msec <Media letture	12
Database\Blocchi errori di pagine di database/sec	0	0
Database di MSExchange\Latenza media scritture registro I/O	<20 msec	3
Database\Record di registro bloccati/sec	0	0

Integrità dell'applicazione

I contatori mostrano che Exchange è integro. Ci sono pochissimi messaggi in coda.

Contatore	Destinazione	Risultato testato
MSExchangeIS\Richieste RPC	<70	3
MSExchangeIS\Latenza media RPC	<10 msec	2
MSExchangeIS Mailbox(_Total)\Messaggi accodati per l'invio	0	106

Verifica dei server Accesso client e Trasporto Hub

Le tabelle che seguono riportano i risultati della verifica ottenuti dalle macchine virtuali dei server Accesso client e Trasporto Hub.

Processore

L'utilizzo del processore è inferiore all'80 per cento, come previsto.

Contatore	Destinazione	Risultato testato
Processore virtuale hypervisor Hyper-V\% Tempo di esecuzione guest	<70%	63

Archiviazione

I risultati dell'archiviazione sembrano buoni. Le latenze molto basse non dovrebbero avere alcun impatto sul trasporto dei messaggi.

Contatore	Destinazione	Risultato testato
Disco logico/fisico(*)\Media letture disco/sec	<20 msec	0.002
Disco logico/fisico(*)\Media scritture disco/sec	<20 msec	0.003

Integrità dell'applicazione

I bassi valori di latenza media RPC confermano lo stato di integrità del server Accesso client senza alcun impatto sulle prestazioni client.

Contatore	Destinazione	Risultato testato
MSExchange RpcClientAccess\Latenza media RPC	<250 msec	9
MSExchange RpcClientAccess\Richieste RPC	<40	7

I contatori delle code di trasporto riportano valori inferiori ai valori target, confermando l'integrità del server Trasporto Hub e la sua capacità di elaborare e recapitare i messaggi.

Contatore	Destinazione	Risultato testato
\Code di MSExchangeTransport(_total)\Lunghezza coda di recapito aggregata (tutte le code)	<3000	5
\Code di MSExchangeTransport(_total)\Lunghezza coda di recapito remota attiva	<250	0
\Code di MSExchangeTransport(_total)\Lunghezza coda di recapito attiva delle cassette postali	<250	4
\Code di MSExchangeTransport(_total)\Lunghezza coda di invio	<100	0
\Code di MSExchangeTransport(_total)\Lunghezza coda dei tentativi di recapito delle cassette postali	<100	1

Verifica dell'integrità del server radice

Le tabelle che seguono riportano i risultati della verifica del server radice Hyper-V.

Processore

L'utilizzo del processore è superiore al target dell'80 per cento. Poiché questo test rappresenta un picco di carico durante una condizione di errore del sito che ha scarse probabilità di verificarsi, va bene così. Tuttavia, non è auspicabile mantenere questa percentuale di utilizzo del processore per un lungo periodo di tempo.

Contatore	Destinazione	Risultato testato
Processore logico hypervisor Hyper-V(_total)\% Tempo di esecuzione guest	<75%	85
Processore logico hypervisor Hyper-V(_total)\% Tempo di esecuzione hypervisor	<5%	2
Processore logico hypervisor Hyper-V(_total)\% Tempo di esecuzione totale	<80%	87
Processore virtuale radice hypervisor Hyper-V(_total)\% Tempo di esecuzione guest	<5%	3

Integrità dell'applicazione

I contatori relativi allo stato di integrità delle macchine virtuali indicano che tutte la macchine virtuali sono integre.

Contatore	Destinazione	Risultato testato
Riepilogo integrità macchine virtuali Hyper-V\Integrità critica	0	0

Soluzioni testate per Exchange 2010

Conclusione

Il presente documento fornisce un esempio di come strutturare, testare e verificare una soluzione Exchange 2010 per ambienti con 32.400 cassette postali in più siti distribuita su hardware Cisco ed EMC. La procedura dettagliata riportata nel presente documento guida l'utente attraverso le più importanti decisioni da prendere per vincere le nuove sfide nel rispetto delle specifiche esigenze della propria attività.

Soluzioni testate per Exchange 2010

Ulteriori informazioni

Per la documentazione completa di Exchange 2010, vedere Exchange Server 2010.

Per ulteriori informazioni su Cisco ed EMC, vedere le seguenti risorse:

EMC CLARiiON CX4-480: EMC CLARiiON Virtual Provisioning
EMC CLARiiON CX4-480: Panoramica dei prodotti
Server e sistemi Unified Computing di Cisco: Panoramica dei sistemi UCS
Server e sistemi Unified Computing di Cisco: Server Blade serie B
Server e sistemi Unified Computing di Cisco: UCS Manager

Il presente documento viene fornito “così com'è”. Le informazioni in esso contenute, inclusi gli URL e altri riferimenti a siti Web, sono soggette a modifica senza preavviso. L'utente ne accetta l'utilizzo a proprio rischio.

Il presente documento non prevede la concessione di alcun diritto di proprietà intellettuale per i prodotti Microsoft. È possibile copiarlo e utilizzarlo per scopi interni e di riferimento.

Soluzioni testate per Exchange 2010