È necessario virtualizzare Exchange 2007 SP1?

 

Ultima modifica dell'argomento: 2009-03-02

Con il rilascio di Windows Server 2008 con tecnologia Hyper-V e di Microsoft Hyper-V Server 2008, un server Microsoft Exchange Server 2007 Service Pack 1 (SP1) virtualizzato non è più destinato unicamente ai laboratori, bensì può essere distribuito in un ambiente di produzione e ricevere il supporto completo di Microsoft. Nell'agosto 2008 Microsoft ha pubblicato criteri di supporto e consigli per virtualizzare Exchange. In questo articolo sono riportate le risposte alle domande principali: La virtualizzazione è una buona soluzione per Exchange?

A causa dei requisiti aziendali e delle prestazioni di Exchange Server, la maggior parte delle distribuzioni trae vantaggio dalla distribuzione dei ruoli del server di Exchange su server fisici. Tuttavia, vi sono alcuni scenari in cui l'esecuzione di Exchange in un ambiente di virtualizzazione dell'hardware può consentire di ottenere vantaggi reali in termini di spazio, energia e flessibilità di distribuzione. In questo articolo vengono presentati:

  • Scenari   In questa sezione vengono descritti quattro scenari in cui è consigliabile eseguire la virtualizzazione di Exchange 2007 SP1.

  • Elenchi di controllo tecnici   In questa sezione vengono forniti elenchi di controllo che consentono di valutare se il carico corrente dell'infrastruttura in uso è idoneo per la virtualizzazione.

Scenari

In questa sezione vengono descritti quattro scenari:

  • Piccolo ufficio con disponibilità elevata

  • Ufficio remoto o filiale con elevata disponibilità

  • Ripristino d'emergenza

  • LAN mobile

Piccolo ufficio con disponibilità elevata

Alcune organizzazioni sono piccole, tuttavia necessitano di una disponibilità di tipo aziendale. Ad esempio, si prenda in considerazione Contoso, Ltd., un'azienda fittizia per la quale il servizio di posta elettronica è di fondamentale importanza. Contoso dispone di molte piccole filiali in cui lavorano 250 utenti. Contoso desidera conservare l'ambiente di posta elettronica presso le sedi per ragioni legali e avere un sistema di posta elettronica completamente ridondante. Gli utenti di Contoso presentano profili di messaggistica utente medi con cassette postali da 2 GB.

Per ottenere la ridondanza completa per tutti i ruoli del server di Exchange che utilizzano un hardware fisico, Contoso dovrebbe distribuire sette server: due server per Active Directory e DNS, un server per i servizi file e stampa, due server che eseguano ruoli del server Accesso client e Trasporto Hub e due server che eseguano il ruolo del server Cassette postali in un ambiente di replica continua cluster (CCR, Cluster Continuous Replication). Si presume che tali server dispongano di due processori quad core e che la quantità di RAM corrisponda alle specifiche consigliate da Microsoft per ciascun ruolo installato. Ogni nodo di replica continua cluster (CCR) ha 4 GB di RAM e ciascuno degli altri server dispone di un minimo di 2 GB di RAM per supportare gli utenti e i modelli del traffico. Con profili di messaggistica utente medi, il carico tipico per un server a otto core dovrebbe corrispondere al 35-45% della CPU.

Attraverso la virtualizzazione Contoso può raggiungere lo stesso livello di ridondanza e disponibilità utilizzando solo tre server. Ciascun server fisico eseguirebbe più server virtualizzati come macchine guest. In questo scenario, tre server fisici con due processori quad core e 16 GB di RAM dovrebbero disporre della capacità sufficiente per gli utenti di Contoso. Ciascuno dei server virtuali verrebbe configurato con due CPU virtuali. Inoltre, per l'archiviazione, insieme alla RAM e ai processori, i server dovrebbero disporre di più schede di rete e di percorsi ridondanti. Poiché ha ancora lo stesso numero di server Exchange da gestire, Contoso non trarrebbe beneficio dal punto di vista delle operazioni e della manutenzione, ma godrebbe di vantaggi in termini di spazio, energia e raffreddamento.

Questo scenario è illustrato dal seguente diagramma.

Possibile progettazione di piccola filiale

Nota

Il server Trasporto Hub che ospita il witness di condivisione file per l'ambiente della replica continua cluster non è un guest della stessa macchina radice dell'hypervisor come uno dei nodi del cluster. Ciò consente di eliminare ogni singolo punto di errore nella soluzione di clustering e di fornire una capacità di clustering reale.

In tale scenario, il passaggio da sette server fisici a tre server fisici e sette server virtuali consente un risparmio potenziale di 25.754 kWh e di $22.516 l'anno. Per effettuare questo calcolo è stato utilizzato lo strumento Microsoft Virtualization (informazioni in lingua inglese).

Rapporto Microsoft HyperGreen 7 a 3

La determinazione delle dimensioni di Exchange per un ambiente di virtualizzazione dell'hardware non differisce dalla determinazione delle dimensioni di Exchange per server fisici. Se si utilizzano server fisici o virtualizzati, ciascun nodo di replica continua cluster necessita di 4 GB di RAM e di una capacità di archiviazione tale da supportare 48 IOPS per i database e 19 IOPS per i registri delle transazioni. In questo scenario, i requisiti per le operazioni IOPS sono molto ridotti e dovrebbero essere gestiti in un ambiente virtualizzato. Dato il numero esiguo di utenti ospitati sui server Exchange virtualizzati, per questa soluzione dovrebbe essere sufficiente utilizzare dei dischi rigidi virtuali a dimensione fissa. Per un numero di utenti maggiore, è consigliabile utilizzare una memoria esterna.

Inizio pagina

Ufficio remoto o filiale con elevata disponibilità

In passato, alcune organizzazioni necessitavano di server Exchange locali presso uffici remoti o filiali che fornissero prestazioni sufficienti a soddisfare gli utenti di tali uffici. Con miglioramenti quali la modalità cache e Outlook via Internet, il consolidamento dei server in un centro dati principale è divenuto il metodo consigliato.

Tuttavia, in determinate situazioni, la scarsa connettività di rete agli uffici remoti impone ancora ad alcune organizzazioni di ricorrere, per questi uffici, a un server di Exchange locale. Spesso, il numero degli utenti che lavorano presso tali sedi è talmente esiguo che non avrebbe senso dedicare un server fisico all'ambiente di Exchange. Le considerazioni tecniche relative a questo scenario sono analoghe a quelle descritte nello scenario precedente: "Piccolo ufficio con disponibilità elevata". Per un esempio di questo scenario, in cui un'azienda ha utilizzato Exchange 2007 SP1 in un ambiente Hyper-V, scaricare questo caso di studio per soluzioni clienti di Windows Server 2008 relativo a Caspian Pipeline Consortium (informazioni in lingua inglese).

Ripristino d'emergenza

Per fornire ridondanza e resilienza per un sito di produzione, è possibile che alcune organizzazioni necessitino di un sito "warm" contenente un duplicato dell'infrastruttura di Exchange della produzione principale. Lo scopo di questo sito "warm" è fornire un livello di funzionalità più simile possibile a quello del sito principale, nel caso dell'eventuale perdita di quest'ultimo. Tuttavia, disporre di un'infrastruttura duplicata a scopo precauzionale, sebbene sia utile al raggiungimento di requisiti elevati per il contratto di servizio (SLA, service level agreement), potrebbe risultare eccessivamente costoso per alcune organizzazioni.

Al fine di ridurre i costi, è possibile creare un duplicato dell'intero sito principale mediante macchine guest in un ambiente Hyper-V. Una configurazione tipica del sito "warm" con server Exchange 2007 fisici includerebbe uno o più server configurati insieme come un cluster di standby e uno o più server configurati come ruoli dei server Accesso client e Trasporto Hub. Per ottenere la ridondanza dei soli servizi di messaggistica interni al sito "warm", sarebbero necessari quattro server fisici. Al contrario, una soluzione virtualizzata con soli tre server fisici può fornire a un'organizzazione un sito "warm" che, in un ambiente di replica continua cluster, include due server Cassette postali, nonché server Accesso client e Trasporto Hub ridondanti. Inoltre, mediante la virtualizzazione di Exchange in questo scenario, è possibile fornire agli utenti una maggiore qualità dei servizi, risparmiando in termini di requisiti di spazio e di costi destinati all'hardware, all'energia e al raffreddamento rispetto a una soluzione configurata in modo analogo, distribuita su server fisici.

Questa configurazione è illustrata nel seguente diagramma.

Possibile configurazione del ripristino di emergenza del sito "warm"

Il sito principale utilizza un hardware fisico a causa delle dimensioni e del profilo di messaggistica richiesti dal gruppo di utenti. In questo scenario, il sito "warm" è progettato per supportare l'intero gruppo di utenti dal sito principale. Sebbene l'utilizzo di un sito "warm" rappresenti una soluzione temporanea a prestazioni ridotte, è necessario considerare attentamente la configurazione dell'ambiente che supporterà il gruppo di utenti.

Nel diagramma viene illustrato come il sito "warm" includa un cluster di standby, che a sua volta include un nodo configurato come destinazione della replica continua di standby (SCR) per l'ambiente di produzione di replica continua cluster. Viene distribuita anche una coppia di controller di dominio. La destinazione SCR è un cluster di standby a due nodi. Nel caso di un errore del sito, il cluster di standby verrebbe attivato mediante l'operazione Restore-StorageGroupCopy, quindi il server di cassette postali in cluster verrebbe recuperato utilizzando il comando Setup /RecoverCMS. Vengono applicate le stesse procedure di ripristino di emergenza mediante un cluster di standby, ad eccezione del fatto che il cluster di standby è una macchina guest in un ambiente di virtualizzazione dell'hardware. Dopo aver portato il cluster di standby in linea e aver ospitato il server di cassette postali in cluster del sito in cui si è verificato l'errore, l'accesso client ai servizi di messaggistica e ai dati viene ripristinato dopo la replica DNS e Active Directory.

Il sito "warm" virtuale deve essere in grado di fornire un livello di servizio adeguato agli utenti in caso di perdita del sito principale, con la consapevolezza che è probabile che il livello del servizio sia ridotto a causa dei collegamenti WAN/Internet al sito "warm". Tuttavia, poiché il sito è progettato per fornire funzionalità di emergenza, e solo per un breve periodo di tempo, tale livello "ridotto" del servizio deve risultare accettabile. In ogni caso, è necessario tenere presente che durante il periodo di inattività del sito principale, non vi è alcuna resilienza per il sito "warm".

In tale scenario, il passaggio da otto server fisici a tre server fisici e otto server virtuali consente un risparmio potenziale di 33.005 kWh e di $28.225 l'anno. Per effettuare questo calcolo è stato utilizzato lo strumento Microsoft Virtualization (informazioni in lingua inglese).

Rapporto Microsoft HyperGreen 8 a 3

Inizio pagina

LAN mobile

Talvolta è possibile che una azienda, un'agenzia o un dipartimento governativo abbiano bisogno di un'infrastruttura di rete completa che venga distribuita in posizioni specifiche non appena richiesto. Tale infrastruttura è quindi connessa alla rete dell'organizzazione via satellite o mediante altra tecnologia WAN remota. Ad esempio, un'organizzazione non governativa (ONG) deve poter reagire a una situazione di emergenza e impostare dei server locali in modo da poter essere utilizzati dalla comunità interessata. Tale sottoinsieme di server deve essere completo e capace di fornire tutti i servizi necessari al personale che si trova nel luogo di destinazione.

In una situazione simile, la rete LAN mobile deve essere facile da trasportare. Deve disporre di un form factor ridotto e di elevata efficacia, in grado di fornire tutti i servizi necessari agli utenti locali occupando meno spazio possibile. Data la probabile distanza delle varie posizioni in cui la LAN mobile deve essere distribuita, è necessario inoltre che fornisca capacità a tolleranza di errore in modo tale che non si verifichino singoli punti di errore in luoghi in cui recuperare pezzi di ricambio risulterebbe difficile.

In questo scenario, un server Hyper-V può essere utilizzato per ospitare servizi di Exchange, servizi di file server e servizi di infrastruttura del dominio in un form factor compatto.

Nota

Per virtualizzare Exchange 2007 SP1 è necessario che nel server radice non sia installata alcuna applicazione caratterizzata da utilizzo elevato di I/O.

Nel seguente diagramma viene illustrata la possibile configurazione di un server Hyper-V che ospita Exchange 2007 e sistemi di infrastruttura del dominio. A causa della natura dello scenario, nessuno dei ruoli del server Exchange è stato combinato nella stessa macchina guest.

Possibile configurazione LAN mobile

Nel diagramma viene mostrata una soluzione di rete completa per un'organizzazione che necessita della fornitura locale di tutti i servizi server necessari indipendentemente dall'ubicazione. Tale soluzione deve consentire un livello elevato di tolleranza di errore e disponibilità di sistema, pur essendo di dimensioni ridottissime.

Nel rack potrebbe essere necessario disporre di apparecchiature per l'infrastruttura di rete sufficienti a supportare i server radice dell'hypervisor e le workstation. I sistemi radice dell'hypervisor devono utilizzare un iSCSI o il canale a fibra ottica della rete SAN. SAN deve fornire gli assi necessari per ottenere le prestazioni richieste per i sistemi guest. In questo scenario, tutta l'apparecchiatura necessaria deve rientrare in un unico rack da 42U.

In tale scenario, il passaggio da 14 server fisici a tre server fisici e 14 server virtuali consente un risparmio potenziale di 91.012 kWh e di $73.891 l'anno. Per effettuare questo calcolo è stato utilizzato lo strumento Microsoft Virtualization (informazioni in lingua inglese).

Rapporto Microsoft HyperGreen 14 a 3

Inizio pagina

Elenchi di controllo tecnici

Se Exchange fosse stato distribuito su hardware fisico, in tutti gli scenari precedentemente descritti le risorse sarebbero state sottoutilizzate. Per determinare se l'ambiente di Exchange è idoneo al consolidamento, è possibile utilizzare i seguenti elenchi di controllo. Se da tali elenchi di controllo risulta che l'hardware è sottoutilizzato, è possibile procedere come segue:

  • Se l'organizzazione è piccola, mediante la virtualizzazione è possibile ridurre la superficie del server fisico a tre server fisici con la ridondanza completa dei ruoli di Exchange.

  • Se l'hardware sottoutilizzato si trova presso un ufficio remoto o una filiale in cui non è possibile eseguire il consolidamento in un centro dati principale, è possibile limitare la superficie di un server fisico a quella determinata posizione mediante la virtualizzazione.

  • In altri scenari, è possibile snellire l'ambiente Exchange verificando quanto la capacità del server sia corrispondente al carico degli utenti. È possibile ridurre il numero di server fisici per aumentare l'utilizzo ai livelli desiderati. In tale scenario, non è necessario eseguire la virtualizzazione.

Tenere presente che il termine hardware sottoutilizzato indica semplicemente che l'ambiente Exchange dispone di capacità in eccesso. Tale situazione può essere preimpostata (per adattare i picchi di utilizzo o la crescita prevista) oppure accidentale. È consigliabile disporre di capacità in eccesso, un fattore che viene preso in considerazione nei seguenti elenchi di controllo.

Nota

L'utilizzo dell'hardware non è l'unico fattore da valutare quando si decide se virtualizzare o meno Exchange. Aggiungere la virtualizzazione a un ambiente Exchange comporta un'ulteriore complessità in diverse aree, incluse le configurazioni di backup, monitoraggio e archiviazione. Per ulteriori informazioni, vedere Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments (informazioni in lingua inglese).

Elenco di controllo n. 1 - Contatori delle prestazioni

Nel seguente elenco di controllo sono descritti i contatori delle prestazioni da monitorare, che indicano se l'ambiente Exchange è sottoutilizzato o meno. Questi contatori devono essere raccolti nei sever fisici di Exchange, non in quelli virtualizzati. Poiché la pianificazione dell'infrastruttura di Exchange è basata sul ruolo del server Cassette postali, negli elenchi di controllo sottostanti viene utilizzata prevalentemente la metrica del server Cassette postali.

Si consiglia di raccogliere le informazioni da ciascuno di questi contatori a intervalli regolari per almeno una settimana. Dopo aver raccolto i dati, è possibile confrontare i risultati con i valori previsti. Se i valori rilevati sono inferiori ai valori previsti seguenti, l'hardware del server è stato sottoutilizzato.

I contatori presenti nell'elenco di controllo provengono da Monitoring without System Center Operations Manager (informazioni in lingua inglese). Dopo averli inseriti in produzione, sarà necessario garantire il monitoraggio dei server utilizzati.

Nota

Si consiglia di monitorare le prestazioni del processore in Windows Server 2008 per verificare che il sistema operativo non rallenti la frequenza dei processori. Questa situazione potrebbe indurre a credere che vi sia un elevato utilizzo della CPU, mentre in realtà l'utilizzo della CPU è ridotto poiché i processori hanno subito un rallentamento per risparmiare energia.

Elenco di controllo del contatore delle prestazioni

Categoria Indicatore Valore previsto Presente

Contatori delle prestazioni comuni (tutti i server Exchange)

Totale % processore

Mediamente, il valore deve essere inferiore al 40%.

[ ]

Sistema\Lunghezza coda processore (tutte le istanze)

Il valore non deve essere superiore a 5 per processore.

[ ]

Interfaccia di rete(*)Totale byte/sec

Per una scheda di rete da 1000 Mbps, il contatore deve indicare un valore inferiore a 30-35 Mbps.

[ ]

Contatore delle prestazioni specifiche dei server Cassette postali

MSExchangeIS Client (*)\Latenza media RPC

Mediamente, il valore deve essere inferiore a 30 ms.

[ ]

Processo(Microsoft.Exchange.Search.ExSearch)\% tempo processore

In genere il valore deve essere inferiore a 1% del tempo CPU complessivo e non restare sopra il 3% per intervalli di tempo prolungati.

[ ]

Interfaccia archivio di MSExchange(_Total)\Latenza media RPC (msec)

Il valore deve essere sempre inferiore a 100 ms.

[ ]

Interfaccia archivio di MSExchange(_Total)\Richieste RPC in sospeso

Il valore deve essere sempre inferiore a 0.

[ ]

Server Cassette postali CCR, LCR e SCR - Contatori delle prestazioni specifiche

Replica di Microsoft Exchange(*)\CopyQueueLength

Per la replica continua cluster (CCR) e replica continua di standby (SCR), il valore deve essere sempre inferiore a 10.

Per la replica continua locale (LCR), il valore deve essere sempre inferiore a 1.

[ ]

Inizio pagina

Elenco di controllo n. 2 - Fattori profilo utente

Un metodo più rapido (e meno preciso) per determinare se il server è sottoutilizzato consiste nel confrontare i core di processore con i profili utente mediante le linee guida generali per il dimensionamento, disponibili alla pagina Planning Processor Configurations (informazioni in lingua inglese). Per determinare il profilo utente dell'organizzazione, fare riferimento alla tabella dei profili utente presente nel relativo articolo (riprodotta di seguito per praticità).

Tipo utente (profilo di utilizzo) Invio/ricezione di messaggi con una dimensione di circa 50 KB al giorno

Basso

5 invii/20 ricezioni

Medio

10 invii/40 ricezioni

Alto

20 invii/80 ricezioni

Molto alto

30 invii/120 ricezioni

Come indicato alla pagina Planning Processor Configurations (informazioni in lingua inglese), una regola generale per il dimensionamento è quella per cui 1.000 cassette postali con profilo medio attivo richiedono un core di processore. Ad esempio, per un server di 4000 cassette postali con un profilo di utilizzo medio sono necessari 4 core di processore. Un profilo di utilizzo elevato richiede più cicli del processore rispetto a un profilo medio. Pertanto, per la pianificazione è consigliabile utilizzare 750 cassette postali con profilo a utilizzo elevato per core di processore. Con questa logica, è possibile riepilogare nel seguente elenco di controllo il numero di utenti necessari per utilizzare a pieno un core di processore:

Elenco di controllo dei fattori del profilo utente

Categoria Indicatore Valore previsto Presente

Utenti con profilo basso

Numero consigliato \ Core di processore = 2000

≤1,000

[ ]

Profilo utente medio

Numero consigliato \ Core di processore = 1000

≤500

[ ]

Profilo utente alto

Numero consigliato \ Core di processore = 750

≤375

[ ]

Profilo utente molto alto

Numero consigliato \ Core di processore = 500

≤250

[ ]

Poiché il numero consigliato di utenti medi è pari a 1000 per core di processore, disporre di un gruppo di utenti pari a 500 o di cassette postali con profilo medio inferiore indicherebbe che non ci sono utenti sufficienti per utilizzare completamente un core di processore del server Cassette postali. È necessario tenere presente che, per i sever fisici di Exchange, il numero massimo di core di processore utilizzato in modo efficace dal ruolo del server Cassette postali è otto (vedere Planning Processor Configurations). L'implementazione delle cassette postali in server con più di otto core non offre miglioramenti di scalabilità significativi.

L'utilizzo di questo elenco di controllo per il recupero del numero di core di processore del server Cassette postali è un buon punto di partenza per esaminare gli altri ruoli del server di Exchange, poiché la metodologia di pianificazione dell'infrastruttura di Exchange per i server Accesso client e Trasporto Hub è in parte basata sul rapporto del core di processore con il server Cassette postali (Cassette postali:Hub e Cassette postali:Server Accesso client). Ad esempio, il rapporto fra server Cassette postali:Hub è 5:1 nel caso in cui i server Trasporto Hub eseguano software antivirus di trasporto e 7:1 nel caso in cui i server Trasporto Hub non eseguano software antivirus di trasporto. Pertanto, se un gruppo di utenti non utilizza completamente un core di processore del server Cassette postali, il medesimo gruppo non utilizzerà completamente neanche un core di processore di Trasporto Hub. Tale risultato indica che l'utilizzo della virtualizzazione per i server Trasporto Hub e/o Accesso client è consigliabile.

Conclusione

Con il rilascio di Windows Server 2008 con Hyper-V e, più di recente, di Microsoft Hyper-V Server 2008, vengono offerte nuove possibilità per la distribuzione di Exchange Server 2007 SP1. In molti casi, mantenere Exchange su un hardware fisico fornisce maggiore gestibilità e un costo totale di proprietà inferiore rispetto alla virtualizzazione. Tuttavia, vi sono alcuni scenari in cui un'infrastruttura di Exchange virtualizzata può consentire di ottenere vantaggi reali in termini di spazio, energia e flessibilità di distribuzione.

Il livello attuale di sottoutilizzo dell'hardware rappresenta un fattore chiave nel determinare se i vantaggi della virtualizzazione siano maggiori rispetto alle difficoltà derivate dall'introduzione di uno strato virtuale sotto Exchange. I vantaggi della virtualizzazione sono generalmente riservati ad ambienti in cui la distribuzione di Exchange è troppo ridotta per gravare sui server sottostanti. Distribuzioni ridotte di Exchange, siti remoti con scarsa connettività, casi di ripristino di emergenza e distribuzioni delle rete LAN mobile sono tutti esempi di scenari per cui la virtualizzazione è largamente consigliata.

Per la maggior parte delle organizzazioni, Exchange risulta essere un'applicazione di importanza strategica. Se, al momento della progettazione dell'ambiente virtualizzato, non si trascura questo fattore e vengono seguiti i criteri di supporto Microsoft e i consigli per i server Exchange virtualizzati, sarà possibile risultati ottimali.

Ulteriori informazioni