Considerazioni sulla pianificazione del clustering

 

Ultima modifica dell'argomento: 2006-03-17

Prima di procedere alla pianificazione dei cluster di Exchange 2003 è opportuno fare le seguenti considerazioni relative ai cluster di Exchange 2003 in Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition, Windows 2000 Advanced Server e Windows 2000 Datacenter Server:

• Computer dedicati a Exchange
• Soluzioni di archiviazione cluster
• Considerazioni su prestazioni e scalabilità
• Compatibilità dell'hardware del cluster
• Clustering dislocato geograficamente
• Strategie per il ripristino di emergenza dei cluster

Nelle sezioni seguenti vengono descritte in dettaglio queste considerazioni.

Computer dedicati a Exchange

Oltre a Exchange 2003, sui cluster del server possono essere eseguite altre applicazioni. Tuttavia, l'esecuzione di più applicazioni sullo stesso nodo può influenzare le prestazioni dei server virtuali di Exchange. Se si decide di dedicare alcuni computer solo a Exchange, tenere presente quanto segue:

• Se si utilizza un cluster per più applicazioni, è consigliabile dedicare un nodo a ogni applicazione e assicurarsi che sia disponibile un numero sufficiente di nodi passivi.
• Se si utilizzano i cluster per fornire servizi di Exchange agli utenti, è consigliabile eseguire unicamente Exchange 2003 sui cluster e le altre applicazioni su computer separati.
• Per risultati ottimali, non eseguire il failover di un server virtuale di Exchange su un nodo attivo sul quale viene eseguita un'altra applicazione.
• I nodi del cluster di Exchange 2003 devono essere server membri di un dominio. Nei cluster di Exchange 2003 non sono supportati i nodi impostati come controller di dominio o server di catalogo globale.

Per ulteriori informazioni sulle prestazioni dei cluster di Exchange 2003, vedere "Gestione dei cluster di Exchange" nel Manuale dell'amministratore di Exchange Server 2003.

Soluzioni di archiviazione cluster

In questa guida non viene analizzata in dettaglio la scelta di una soluzione di archiviazione cluster. Tuttavia, in questa sezione vengono forniti consigli e strategie generali per l'implementazione di una soluzione di archiviazione cluster.

La maggior parte delle procedure consigliate relative ai server autonomi (non cluster) si applicano anche ai server cluster (ad esempio, soluzioni RAID e SAN). Per informazioni dettagliate sulle soluzioni di archiviazione di Exchange, vedere Pianificazione di una soluzione di archiviazione back-end affidabile.

Per informazioni dettagliate sulla scelta di un metodo di archiviazione cluster in Windows Server 2003, vedere Choosing a Cluster Storage Method (informazioni in lingua inglese).

Unità disco rigido separate per i file di registro

Se i gruppi di archiviazione di un server virtuale di Exchange vengono configurati in modo che i file di registro si trovino in un insieme di unità disco fisico e i database in un'altro, è necessario configurare tutte le unità come risorse disco all'interno dello stesso server virtuale di Exchange. In particolare, tutti i dati devono trovarsi su un disco condiviso e tutte le risorse disco fisico devono appartenere al gruppo di cluster di Exchange. In questo modo, nel momento in cui il server virtuale di Exchange non è in linea, verrà eseguito il failover dei file di registro e dei database del gruppo di archiviazione a un altro nodo.

Nota

È necessario che il Supervisore sistema venga reso dipendente da tutte le risorse del disco fisico (unità e punti di montaggio del volume) che contengono dati di Exchange. In questo modo la risorsa Supervisore sistema può accedere correttamente ai dati di Exchange nelle risorse del disco fisico del server virtuale di Exchange. Se il Supervisore sistema non dipende da queste risorse, le risorse di Exchange potrebbero essere avviate prima di ottenere l'accesso alla lettura dei dati nelle risorse del disco fisico e potrebbe verificarsi il seguente errore del database di Exchange: -1022 Jet_errDiskIO. Per informazioni sull'errore 1022 del database di Exchange, vedere l'articolo 314917 della Microsoft Knowledge Base "Interpretazione e analisi degli errori -1018, -1019 e -1022 del database di Exchange".

Limitazioni relative ai gruppi di archiviazione

In Exchange 2003 esiste il limite di quattro gruppi di archiviazione per server. Si tratta di una limitazione fisica applicabile anche ai nodi di un cluster che può causare problemi nelle configurazioni di tipo attivo/attivo, ma non nelle configurazioni di tipo attivo/passivo.

Nota

Il clustering di tipo attivo/passivo è vivamente consigliato in Exchange 2003. Per informazioni sul motivo per cui è preferibile questo tipo di configurazione, vedere "Configurazioni cluster" in Concetti relativi al clustering di Exchange Server 2003.

Per spiegare il motivo per cui questa limitazione riguarda solo i cluster di tipo attivo/attivo, si consideri un cluster di tipo attivo/attivo a due nodi, dove un nodo contiene due gruppi di archiviazione e l'altro ne contiene tre.

Configurazione di un cluster di tipo attivo/attivo a due nodi con cinque gruppi di archiviazione

Server virtuale di Exchange	Stato	Nomi dei gruppi di archiviazione
Nodo 1 Server virtuale di Exchange (EVS)1	Attivo	gruppo di archiviazione 1, gruppo di archiviazione 2, gruppo di archiviazione 3
Nodo 2 Server virtuale di Exchange (EVS)2	Attivo	gruppo di archiviazione 1, gruppo di archiviazione 2

In questa tabella, nel cluster di Exchange sono presenti cinque gruppi di archiviazione. Se viene eseguito il failover del server virtuale 2 dal nodo 2 al nodo 1, non è possibile installare entrambi i gruppi di archiviazione nel nodo 1, in quanto viene superato il limite di quattro gruppi di archiviazione. Di conseguenza, il server virtuale 2 non tornerà in linea sul nodo 1. Se il nodo 2 è ancora disponibile, verrà eseguito il failover del server virtuale 2 al nodo 2.

Nota

In Exchange 2003 è supportato un gruppo di archiviazione aggiuntivo per il backup e il ripristino, denominato gruppo di archiviazione di ripristino. Tuttavia, non è possibile utilizzare il gruppo di archiviazione di ripristino per il failover dei nodi del cluster. Per ulteriori informazioni sui gruppi di archiviazione di ripristino, vedere "New Recovery Features for Exchange 2003" in Exchange Server 2003 Disaster Recovery Planning Guide (informazioni in lingua inglese).

Limitazioni relative alle lettere di unità

Prima di distribuire i cluster di Exchange 2003, assicurarsi di avere valutato la limitazione di Windows di 26 lettere di unità per server. Se si intende configurare la maggior parte dei dischi del server come risorse cluster condivise, la limitazione di 26 lettere di unità si applica all'intero cluster, non solo al singolo nodo. Indipendentemente dal numero di nodi del cluster, il numero massimo di dischi condivisi è generalmente 22 e non 26, perché un disco deve essere il disco di sistema per ogni nodo e due dischi aggiuntivi sono generalmente assegnati alle unità floppy e CD (o DVD).

Nota

Se sui nodi del cluster viene eseguito Windows Server 2003 Enterprise Edition o Windows Server 2003 Datacenter Edition, è possibile utilizzare i punti di montaggio del volume per evitare la limitazione di 26 lettere di unità. Per ulteriori informazioni, vedere "Punti di montaggio del volume di Windows Server 2003" più avanti in questo argomento.

È consigliabile utilizzare una lettera di unità per i database e una per i file di registro di ogni gruppo di archiviazione. In un cluster a quattro nodi con tre server virtuali di Exchange, è possibile disporre di un massimo di 12 gruppi di archiviazione. Pertanto, è possibile che siano necessarie più di 22 lettere di unità per un cluster a quattro nodi.

Nelle sezioni che seguono vengono fornite informazioni sulla pianificazione della soluzione di archiviazione cluster, a seconda del sistema operativo in uso, vale a dire Windows 2000 o Windows Server 2003.

Concetti relativi alle limitazioni delle lettere di unità in Windows 2000

Per alcune configurazioni di cluster a quattro nodi su cui è eseguito Windows 2000 Datacenter Server, può essere necessario disabilitare una o più unità per liberare una maggiore quantità di spazio per più dischi condivisi nel cluster. Ad esempio, può essere necessario disabilitare le unità CD-ROM o DVD-ROM sui server. Aumentare al massimo il numero di dischi condivisi può ridurre la possibilità di mappare le unità per l'accesso alla condivisione di rete.

Nota

Poiché in Windows 2000 non è supportato l'utilizzo di punti di montaggio del volume (un tipo di disco logico), non è possibile utilizzare punti di montaggio del volume per i dischi condivisi di Exchange con Windows 2000. È tuttavia possibile utilizzarli per le unità locali, ad esempio unità CD-ROM o DVD.

Questa limitazione relativa alle lettere di unità influisce sul modo in cui si progetta il gruppo di archiviazione e l'architettura del database per un cluster di Exchange. Nelle sezioni seguenti vengono forniti esempi su come ottimizzare l'affidabilità dei dati nel cluster con Windows Server 2003.

Configurazione del disco con tre gruppi di archiviazione

La configurazione illustrata nella tabella seguente è affidabile, poiché ogni gruppo di archiviazione (gruppo di archiviazione 1, gruppo di archiviazione 2 e gruppo di archiviazione 3) dispone di un’unità dedicata per i database e di un’unità dedicata per i file di registro. Un disco aggiuntivo viene utilizzato per la directory della coda SMTP del server virtuale di Exchange. Tuttavia, in questa struttura è presente il limite di tre gruppi di archiviazione per ogni server virtuale di Exchange.

Architettura a 3 nodi attivi e 1 nodo passivo con tre server virtuali di Exchange, ognuno con tre gruppi di archiviazione

Nodo 1 (server virtuale di Exchange 1 attivo)	Nodo 2 (server virtuale di Exchange 2 attivo)	Nodo 3 (server virtuale di Exchange 3 attivo)	Nodo 4 (passivo)
Disco 1: SMTP/MTA	Disco 8: SMTP	Disco 15: SMTP	Disco 22: Quorum
Disco 2: database del gruppo di archiviazione 1	Disco 9: database del gruppo di archiviazione 1	Disco 16: database del gruppo di archiviazione 1
Disco 3: registri del gruppo di archiviazione 1	Disco 10: registri del gruppo di archiviazione 1	Disco 17: registri del gruppo di archiviazione 1
Disco 4: database del gruppo di archiviazione 2	Disco 11: database del gruppo di archiviazione 2	Disco 18: database del gruppo di archiviazione 2
Disco 5: registri del gruppo di archiviazione 2	Disco 12: registri del gruppo di archiviazione 2	Disco 19: registri del gruppo di archiviazione 2
Disco 6: database del gruppo di archiviazione 3	Disco 13: database del gruppo di archiviazione 3	Disco 20: database del gruppo di archiviazione 3
Disco 7: registri del gruppo di archiviazione 3	Disco 14: registri del gruppo di archiviazione 3	Disco 21: registri del gruppo di archiviazione 3

Configurazione del disco con quattro gruppi di archiviazione

Nella configurazione descritta nella tabella seguente viene aggiunto un ulteriore gruppo di archiviazione. Tuttavia, per rispettare la limitazione di 22 dischi, i database di ognuno dei quattro gruppi di archiviazione per server virtuale di Exchange (gruppo di archiviazione 1, gruppo di archiviazione 2, gruppo di archiviazione 3 e gruppo di archiviazione 4) vengono uniti nello spazio di due dischi. I file di database (EDB e STM) dei gruppi di archiviazione 1 e 2 condividono il volume comune di un disco, così come i file di database dei gruppi di archiviazione 3 e 4. Il vantaggio di questa configurazione consiste nella possibilità di utilizzare tutti i quattro gruppi di archiviazione in un cluster a quattro nodi. Lo svantaggio consiste nella possibilità che i volumi contenenti i database dei gruppi di archiviazione condivisi debbano essere di grandi dimensioni. Di conseguenza, se si verifica un errore in un disco del database, vengono interessati due gruppi di archiviazione anziché uno.

Architettura a 3 nodi attivi e 1 nodo passivo con tre server virtuali di Exchange, ognuno con quattro gruppi di archiviazione

Nodo 1 (server virtuale di Exchange 1 attivo)	Nodo 2 (server virtuale di Exchange 2 attivo)	Nodo 3 (server virtuale di Exchange 3 attivo)	Nodo 4 (passivo)
Disco 1: SMTP/MTA	Disco 8: SMTP	Disco 15: SMTP	Disco 22: Quorum
Disco 2: database dei gruppi di archiviazione 1 e 2	Disco 9: database dei gruppi di archiviazione 1 e 2	Disco 16: database dei gruppi di archiviazione 1 e 2
Disco 3: registri del gruppo di archiviazione 1	Disco 10: registri del gruppo di archiviazione 1	Disco 17: registri del gruppo di archiviazione 1
Disco 4: registri del gruppo di archiviazione 1	Disco 11: registri del gruppo di archiviazione 2	Disco 18: registri del gruppo di archiviazione 2
Disco 5: database dei gruppi di archiviazione 3 e 4	Disco 12: database dei gruppi di archiviazione 3 e 4	Disco 19: database dei gruppi di archiviazione 3 e 4
Disco 6: registri del gruppo di archiviazione 3	Disco 13: registri del gruppo di archiviazione 3	Disco 20: registri del gruppo di archiviazione 3
Disco 7: registri del gruppo di archiviazione 4	Disco 14: registri del gruppo di archiviazione 4	Disco 21: registri del gruppo di archiviazione 4

Punti di montaggio del volume di Windows Server 2003

I punti di montaggio del volume sono ora supportati su dischi condivisi se sui nodi del cluster (quattro o più) viene eseguito Windows Server 2003 Enterprise Edition o Windows Server 2003 Datacenter Edition. I punti di montaggio del volume (noti anche come punti di giunzione NTFS o unità montate) sono directory che fanno riferimento in modo permanente a volumi del disco specificati. Ad esempio, è possibile configurare C:\Data per fare riferimento a un volume del disco. Grazie ai punti di montaggio del volume non è necessario associare ogni volume del disco a una lettera di unità, superando così il limite delle 26 lettere di unità.

I punti di montaggio risultano utili per cluster di Exchange di grandi dimensioni (ad esempio, cluster a quattro o otto nodi) che non dispongono di un numero sufficiente di lettere di unità per fornire prestazioni e affidabilità ottimali. Per informazioni su come i punti di montaggio possono essere utilizzati per ridurre il numero delle lettere di unità, vedere Using Clustering with Exchange 2003: An Example (informazioni in lingua inglese).

Prima di installare punti di montaggio del volume nei cluster, tenere presente quanto segue:

• Assicurarsi di creare punti di montaggio del volume univoci in modo che non entrino in conflitto con unità locali esistenti sui nodi del cluster.
• Non creare punti di montaggio del volume tra dischi nella periferica di archiviazione del cluster (dischi cluster) e dischi locali.
• Non creare punti di montaggio del volume dal disco cluster contenente la risorsa disco quorum. È tuttavia possibile creare un punto di montaggio del volume dalla risorsa disco quorum a un disco cluster.
• È necessario che i punti di montaggio del volume da un disco cluster a un altro si trovino nello stesso gruppo di risorse cluster e che dipendano dal disco principale. In particolare, il disco con il punto di montaggio del volume non verrà portato in linea, se non è già in linea il disco principale. L'impostazione di questa dipendenza consente di evitare timeout ed errori all'avvio.

È consigliabile utilizzare punti di montaggio del volume con cluster di Exchange 2003 ad almeno quattro nodi. Utilizzare un disco principale per gruppo di archiviazione. È possibile posizionare i registri sul disco principale e il database sull'unità montata. Se non è disponibile un numero sufficiente di lettere di unità, come in un cluster a otto nodi, è possibile utilizzare un unico disco principale. Tuttavia, in caso di errore del disco, per ridurre al minimo il rischio di perdita dei dati, non archiviare dati nel disco principale. È necessario un disco principale per ogni server virtuale di Exchange.

Per ulteriori informazioni sul supporto dei punti di montaggio, vedere l'articolo 318458 della Microsoft Knowledge Base "Supporto di montaggio di volume per un cluster Server 2003 in un sistema basato su Windows Server 2003 nel punto".

Per ulteriori informazioni sull'aggiunta di un punto di montaggio del volume in un server virtuale di Exchange, vedere le seguenti risorse:

• "Distribuzione di Exchange 2003 in un cluster" in Guida alla distribuzione di Exchange Server 2003
• articolo 280297 della Microsoft Knowledge Base "Come configurare punti di montaggio mount point dei volumi su un server cluster".

Considerazioni su prestazioni e scalabilità

In questa sezione vengono descritti i seguenti aspetti relativi alle prestazioni e alla scalabilità dei cluster di server:

• Dimensioni dei cluster di tipo attivo/passivo
• Dimensioni dei cluster di tipo attivo/attivo
• Scalabilità in verticale o in orizzontale
• Verifica dei componenti dei server cluster

Importante

Come avviene per i server autonomi (non cluster), anche i nodi del cluster di Exchange (in particolare i nodi del cluster di tipo attivo/attivo) vengono influenzati dalla frammentazione della memoria virtuale. Per l'ottimizzazione e il monitoraggio delle informazioni per gestire la frammentazione della memoria virtuale in un cluster, vedere "Gestione dei cluster di Exchange" in Manuale dell'amministratore di Exchange Server 2003.

Per informazioni sulle prestazioni e la scalabilità di Exchange 2003, vedere il Manuale relativo alle prestazioni e alla scalabilità di Exchange Server 2003.

Dimensioni dei cluster di tipo attivo/passivo

Come avviene per i server autonomi, è necessario dimensionare i cluster di tipo attivo/passivo.

Nota

Prima di distribuire i server cluster, è consigliabile verificare la metrica di dimensionamento in un ambiente di prova. Per eseguire i test, è possibile utilizzare strumenti di Exchange quali Exchange Server Load Simulator 2003 (LoadSim) e Jetstress. Per informazioni sull'importanza delle verifiche in laboratorio e delle distribuzioni pilota, vedere "Verifiche di laboratorio e distribuzioni pilota" in Misure per la tolleranza di errore a livello di sistema.

Dimensionamento dei cluster di tipo attivo/attivo

I cluster di tipo attivo/attivo non rappresentano la migliore configurazione dei cluster del server Exchange. Tuttavia, se si decide di implementare i cluster di tipo attivo/attivo, tenere presente che Exchange supporta solo cluster di tipo attivo/attivo a due nodi. Inoltre, con i cluster di tipo attivo/attivo è necessario tenere presente due importanti vincoli:

• Il numero di connessioni utente simultanee per nodo non deve essere superiore a 1.900. Se è presente più di un server virtuale di Exchange per nodo, assicurarsi che la somma di tutte le connessioni utente MAPI simultanee sia inferiore a 1.900.
• Il carico medio della CPU per server non deve superare il 40%.

Se questi requisiti non vengono soddisfatti, gli utenti potrebbero rilevare un significativo calo di prestazioni dopo un failover. Inoltre, un singolo nodo del cluster di tipo attivo/attivo potrebbe non essere in grado di portare in linea il secondo server virtuale di Exchange.

Nota

Prima di distribuire i server cluster, è consigliabile verificare la metrica di dimensionamento in un ambiente di prova. Per eseguire i test, è possibile utilizzare strumenti di Exchange quali Exchange Server Load Simulator 2003 (LoadSim) e Jetstress. Per informazioni sull'importanza delle verifiche in laboratorio e delle distribuzioni pilota, vedere "Verifiche di laboratorio e distribuzioni pilota" in Misure per la tolleranza di errore a livello di sistema.

Considerazioni sul monitoraggio dei cluster di tipo attivo/attivo

Dopo aver distribuito il cluster di tipo attivo/attivo, procedere come segue:

• Monitorare il carico della CPU per ogni nodo del cluster.
• Monitorare il numero di connessioni simultanee (utenti) per nodo.

Nota

Valutare la possibilità di monitorare questi valori durante gli intervalli di massimo utilizzo della posta elettronica. In questo modo, se è necessario un failover nell'intervallo di massimo utilizzo della posta, è possibile sapere se il singolo nodo è in grado di eseguire entrambi i server virtuali di Exchange. Inoltre, è possibile monitorare manualmente un contatore in tempo reale oppure usarlo per compilare un rapporto in un determinato periodo di tempo (ad esempio, nelle due ore di massimo utilizzo della posta).

Monitoraggio dei carichi della CPU per ogni nodo del cluster

Se il carico della CPU supera il 40% (carico generato dagli utenti) per oltre 10 minuti, spostare le cassette postali al di fuori del server. Questo carico non include gli aumenti amministrativi del carico, ad esempio per lo spostamento di utenti.

Per monitorare il carico della CPU per ogni nodo nel cluster di tipo attivo/attivo, utilizzare il seguente contatore di Performance Monitor (Perfmon):

Prestazione/%Tempo processore/_Totale contatore

Nota

Non tenere conto di eventuali picchi nelle prestazioni della CPU. Normalmente, il carico della CPU di un server raggiungerà un picco superiore all'80% o anche al 90%.

Monitoraggio delle connessioni simultanee degli utenti per nodo

Se il numero di utenti simultanei per nodo supera i 1.900 per oltre 10 minuti, spostare le cassette postali al di fuori del server virtuale. Anche se è possibile soddisfare questo requisito posizionando solo 1.900 cassette postali in ogni server virtuale del cluster di tipo attivo/attivo, generalmente è consigliabile monitorare il numero di utenti MAPI simultanei per server, poiché alcuni utenti potrebbero eseguire più connessioni alle loro cassette postali.

Per monitorare il numero degli utenti simultanei per nodo, utilizzare uno o più dei seguenti contatori Perfmon:

• Numero connessioni attive/MSExchangeIS
• Cassetta postale di MSExchangeIS(_Totale)/Accessi client attivi

Nota

Questi contatori forniscono risultati differenti e considerano le connessioni di Outlook Web Access in modo diverso dalle connessioni di Outlook. Per informazioni sull'utilizzo del server, monitorare le modifiche dei contatori durante una normale giornata lavorativa.

Scalabilità in verticale o in orizzontale

Nella valutazione su come contenere più utenti (o più messaggi per utente) nell'ambiente cluster, un'opzione è la scalabilità in verticale. La scalabilità in verticale prevede l'utilizzo di componenti server più potenti nei nodi del cluster per soddisfare le richieste crescenti di prestazioni. Tuttavia, è importante notare che, scalando in verticale l'hardware nei nodi del cluster, ad esempio per ospitare più utenti in ogni nodo, l'importanza della disponibilità di ciascun nodo aumenta in modo significativo.

Un'alternativa alla scalabilità in verticale è la scalabilità in orizzontale. La scalabilità in orizzontale prevede l'aggiunta di nodi a un cluster.

Per descrivere queste due opzioni, si consideri un'organizzazione che ospita 3.000 utenti in un cluster a quattro nodi. Il cluster ha tre nodi attivi (1.000 utenti per nodo) e un nodo passivo. Se è necessario aggiungere altri 1.000 utenti, sono disponibili due opzioni:

• Opzione 1: Scalabilità in verticale   In particolare, aggiornare la memoria RAM e le CPU di ogni nodo del cluster, quindi distribuire i 1.000 utenti aggiuntivi in parti uguali tra i nodi.
• Opzione 2: Scalabilità in orizzontale   In particolare, aggiungere un nodo al cluster. In questo modo viene modificata la configurazione del cluster in un cluster a cinque nodi, quattro dei quali attivi, dove ogni nodo attivo ospita 1.000 cassette postali.

In questo esempio, se un problema grave provoca un errore in uno dei server, l'implementazione della seconda opzione interesserebbe un numero inferiore di utenti. Quindi, quando Exchange viene distribuito in un cluster, valutare la scalabilità in orizzontale come parte del piano di scalabilità.

La scalabilità in orizzontale consente, inoltre, di aumentare la tolleranza di errore del cluster di Exchange. Ad esempio, un cluster a quattro nodi di cui 2 attivi e 2 passivi può gestire più errori simultanei rispetto a un cluster a quattro nodi di cui 3 attivi e 1 passivo. Per ulteriori informazioni sui cluster di tipo attivo/passivo, vedere "Clustering di tipo attivo/passivo" in Concetti relativi al clustering di Exchange Server 2003.

Verifica dei componenti dei server cluster

Prima di distribuire i server cluster nell'ambiente di produzione, è importante eseguire una verifica della loro capacità. Gli strumenti utilizzati per eseguire la verifica della distribuzione dei cluster sono gli stessi strumenti utilizzati per eseguire la verifica dei server non cluster (ad esempio LoadSim e Jetstress). Per informazioni sull'importanza delle verifiche in laboratorio e delle distribuzioni pilota, vedere "Verifiche di laboratorio e distribuzioni pilota" in Misure per la tolleranza di errore a livello di sistema.

Nell'elenco seguente vengono fornite considerazioni sulle verifiche specifiche per il clustering dei server.

Eseguire la verifica dei seguenti componenti hardware:

• Singoli componenti di computer quali dischi rigidi, controller, processori e RAM
• Componenti esterni quali router, bridge, switch, cavi e connettori.

Impostare le seguenti prove di stress:

• Prova delle prestazioni del cluster in situazioni di carichi di rete eccessivi.
• Prova delle prestazioni del cluster in situazioni di eccessivo input/output (I/O) del disco sullo stesso disco.
• Prova delle prestazioni del cluster in situazioni di carico eccessivo dei servizi di Exchange.
• Prova delle prestazioni del cluster in presenza di un numero elevato di tentativi di accesso simultanei.
• Failover di ciascun server virtuale di Exchange almeno una volta a ognuno dei nodi. Eseguire questa operazione in situazioni di carico eccessivo dei servizi di Exchange.

Utilizzare i risultati di queste prove per:

• Calcolare il tempo di risposta del client per la configurazione del server in presenza di un carico di lavoro elevato.
• Calcolare il numero di utenti per server.
• Identificare colli di bottiglia nel server.

Compatibilità dell'hardware del cluster

Windows Server 2003 Enterprise Edition e Windows Server 2003 Datacenter Edition supportano unicamente sistemi di cluster di server completi scelti nel Catalogo di Windows Server.

Il supporto di componenti di terze parti è regolato dai requisiti delle soluzioni di terze parti. Per ulteriori informazioni, vedere l'articolo 814607 della Microsoft Knowledge Base "Microsoft si supporta per i cluster di server con i componenti di sistema di terza parte".

Generalmente, per ogni nodo del cluster è consigliabile utilizzare lo stesso hardware (ad esempio, schede di rete, quantità di RAM e processori identici). Per ulteriori informazioni su questo consiglio e sulla possibilità di utilizzare hardware asimmetrico nei nodi del cluster, vedere "Configurazioni cluster" in Concetti relativi al clustering di Exchange Server 2003.

Nota

Per un cluster geograficamente distribuito, le configurazioni hardware e software devono essere certificate ed elencate nel catalogo di Windows Server. Per informazioni sulla compatibilità hardware per cluster dislocati geograficamente, vedere "Configurazioni qualificate dei cluster dislocati geograficamente" più avanti in questo argomento.

Per ulteriori informazioni sull'hardware dei cluster, vedere l'articolo 309395 della Microsoft Knowledge Base "La politica di supporto Microsoft per cluster di server, Hardware Compatibility List e Windows Server Catalog".

Clustering dislocato geograficamente

L'obiettivo principale di un cluster dislocato geograficamente è assicurare che la perdita di un sito non provochi la perdita dell'applicazione completa. Il clustering dislocato geograficamente aumenta la disponibilità e la recuperabilità dei servizi di posta elettronica di Exchange. Tuttavia, i nodi del cluster nel sito di ripristino alternativo non forniscono i servizi di Exchange, a meno che non si verifichi un errore nel sito. Inoltre, in caso di gravi problemi del sito i cluster dislocati geograficamente forniscono tolleranza di errore e funzionalità di failover per determinate applicazioni. Sono disponibili molte soluzioni hardware e software per cluster di Exchange dislocati geograficamente che consentono continuità nelle operazioni aziendali sia a livello del cluster sia a livello del sito.

Nella pianificazione della soluzione di cluster dislocati geograficamente, assicurarsi di disporre delle seguenti informazioni:

• Problemi principali affrontati dai cluster dislocati geograficamente.
• Configurazioni qualificate dei cluster dislocati geograficamente.
• Requisiti del Servizio cluster che una soluzione di clustering dislocato geograficamente deve soddisfare.
• Nel resto di questa sezione vengono fornite informazioni su ciascuno dei tre argomenti precedenti.

Per informazioni generali sul modo in cui il clustering dislocato geograficamente consente di ottenere la tolleranza di errore per l'organizzazione di Exchange 2003, vedere "Utilizzo di più siti fisici" in Misure per la tolleranza di errore a livello di sistema.

Problemi che un cluster dislocato geograficamente deve affrontare

Un cluster dislocato geograficamente deve affrontare i seguenti problemi:

• Assicurare che più siti abbiano copie indipendenti degli stessi dati. Replica delle modifiche dei dati nei siti. Trasmissione delle modifiche ai siti rimanenti nel caso in cui i dati vengono modificati in un sito nel quale si verifica un errore.
• Fornitura dei servizi di Exchange da parte di applicazioni quali Exchange 2003 in caso di errore in un sito.
• Protezione dalle calamità naturali dei cluster dislocati geograficamente.

Il primo problema viene facilmente risolto replicando i dati di sola lettura tra i siti fisici; è possibile copiare i dati di sola lettura e salvare un'istanza di essi in ciascun sito. Per risolvere il problema della replica dei dati è possibile implementare il mirroring software e hardware o la replica sincrona. Queste tecniche di replica consentono di mantenere i mirror dei dati correnti di ogni sito fisico.

Per risolvere il secondo problema è necessario implementare una soluzione di failover dei cluster. Affinché questa soluzione sia efficace, i nodi del cluster in siti fisici separati devono essere visualizzati dal Servizio cluster come appartenenti alla stessa rete. Per eseguire questa operazione, è possibile utilizzare le reti VLAN (Virtual Local Area Network). Le reti VLAN consentono la connessione da posizioni fisiche separate e a grande distanza.

Per risolvere il terzo problema, assicurarsi che i siti siano sufficientemente lontani tra loro, in modo che una calamità naturale non abbia conseguenze su più di un sito. È necessario che ogni sito disponga di fonti di alimentazione e provider di infrastrutture di comunicazione diversi.

Nella figura seguente viene illustrato un cluster di base dislocato geograficamente con queste soluzioni attive.

Configurazioni qualificate dei cluster dislocati geograficamente

Un cluster dislocato geograficamente è una combinazione di componenti hardware e software forniti dagli OEM (original equipment manufacturers) e dai fornitori di software. Le configurazioni di un cluster dislocato geograficamente di Exchange 2003 possono essere complesse e i cluster devono utilizzare esclusivamente componenti supportati da Microsoft. È necessario che i cluster dislocati geograficamente vengano distribuiti solo da fornitori in grado di offrire configurazioni qualificate.

Generalmente, le restrizioni relative ai cluster dislocati geograficamente di Windows Server 2003 sono applicabili anche a Exchange 2003. Per informazioni dettagliate sui cluster dislocati geograficamente in Windows Server 2003, vedere Geographically Dispersed Clusters in Windows Server 2003 (informazioni in lingua inglese).

L'hardware di un cluster dislocato geograficamente deve essere qualificato e nell'elenco Microsoft Hardware Compatibility List (informazioni in lingua inglese). Per un elenco della compatibilità hardware per i cluster dislocati geograficamente, vedere Catalogo di Windows Server.

Nota

È possibile creare cluster dislocati geograficamente aggiungendo software per la replica dei dati e ulteriore hardware LAN alle configurazioni certificate esistenti. Tuttavia, queste soluzioni modificano radicalmente la natura di una configurazione non ancora certificata, in particolare in relazione all'intervallo e alla latenza. Per essere supportata da Microsoft, la configurazione hardware e software di un cluster dislocato geograficamente deve essere certificata ed essere inclusa nell'elenco di compatibilità hardware per i cluster.

Per ulteriori informazioni sull'hardware dei cluster, vedere l'articolo 309395 della Microsoft Knowledge Base "La politica di supporto Microsoft per cluster di server, Hardware Compatibility List e Windows Server Catalog".

Requisiti tecnologici del Servizio cluster

Il software del Servizio cluster di Windows non dispone di informazioni sulla natura estesa dei cluster dislocati geograficamente. In particolare, il Servizio cluster non include funzionalità specifiche delle configurazioni dei cluster dislocati geograficamente. Quindi, l'architettura della rete e dell'archiviazione dei cluster dislocati geograficamente deve soddisfare i seguenti requisiti:

• Le connessioni alla rete pubblica e privata devono trovarsi nella stessa subnet (rete LAN non instradata). Per l'implementazione, utilizzare reti VLAN per assicurarsi che tutti i nodi del cluster si trovino nelle stesse subnet IP.

• Le connessioni di rete devono essere in grado di fornire una latenza di andata e ritorno massima garantita tra i nodi non superiore a 500 millisecondi. Il cluster utilizza gli heartbeat per determinare se un nodo è attivo o non risponde. Gli heartbeat vengono inviati periodicamente (ogni 1,2 secondi). Se un nodo impiega troppo tempo per rispondere ai pacchetti heartbeat, il Servizio cluster avvia un protocollo pesante per determinare i nodi ancora attivi e quelli non disponibili. Questa operazione è denominata riorganizzazione del cluster.

• Se si sta utilizzando un quorum a nodi standard, definito anche quorum singolo, il cluster deve disporre di un singolo disco condiviso, definito anche disco quorum.

  Nota

  Se viene eseguito Exchange 2003 su Windows Server 2003, è possibile ignorare questo requisito utilizzando il quorum maggioranza dei nodi. Per ulteriori informazioni sui tipi di quorum, vedere "Risorsa disco quorum" in Concetti relativi al clustering di Exchange Server 2003.

  Affinché il Servizio cluster visualizzi un set di dischi in due siti separati come un disco singolo, l'infrastruttura di archiviazione può fornire il mirroring tra i siti. Tuttavia, deve essere conservata la semantica fondamentale richiesta dalla risorsa del disco fisico:

  • Il Servizio cluster utilizza i comandi di riserva SCSI e la reimpostazione del bus per determinare e proteggere i dischi condivisi. La semantica di questi comandi deve essere conservata nei siti, anche in caso di errori nella comunicazione tra i siti. Se viene assegnato un disco a un nodo del sito A, i nodi del sito B non devono essere in grado di accedere ai contenuti del disco. Questa semantica è fondamentale per evitare il danneggiamento dei dati del cluster e dei dati dell'applicazione.
  • È necessario replicare il disco quorum nei siti in tempo reale e in modalità sincrona. I diversi membri di un disco quorum di cui è stato eseguito il mirroring devono contenere gli stessi dati.

Strategie per il ripristino di emergenza dei cluster

Per informazioni sulle strategie per il ripristino di emergenza dei cluster di Exchange 2003, vedere "Backing up Exchange 2003 Clusters" e "Restoring Exchange 2003 Clusters" in Exchange Server 2003 Disaster Recovery Operations Guide (informazioni in lingua inglese).