Disponibilità elevata

 

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2009-04-01

Nella sezione Elevata disponibilità sono inclusi argomenti utili per progettare, creare e utilizzare un sistema di messaggistica a elevata disponibilità basato sulla versione di produzione (RTM) di Microsoft Exchange Server 2007 ed Exchange 2007 Service Pack 1 (SP1). La documentazione fornita in questa sezione contiene i seguenti argomenti:

Prima di progettare o distribuire una soluzione di messaggistica a elevata disponibilità basata su Exchange 2007 SP1, si consiglia di leggere la documentazione applicabile.

La documentazione disponibile in questa sezione è stata aggiornata per includere i suggerimenti e le procedure consigliate più recenti per la distribuzione di Exchange 2007 SP1 in Windows Server 2008 e Windows Server 2003 Service Pack 2 (SP2).

Elevata disponibilità per Exchange Server 2007

Mentre le esigenze minime in termini di tempo di attività variano tra le organizzazioni, ogni organizzazione vorrebbe conseguire un'alta percentuale di tempo di attività. Le organizzazioni per cui la messaggistica svolga un ruolo essenziale per l'esecuzione delle attività spesso scelgono di progettare un sistema di messaggistica con un'elevata disponibilità in grado di fornire il tempo di attività auspicato.

Exchange 2007 RTM ed Exchange 2007 SP1 includono le seguenti funzionalità incorporate che garantiscono un ripristino rapido, un'elevata disponibilità e la resilienza del sito per i server Cassette postali di Exchange 2007:

  • Replica continua locale   La replica continua locale (LCR, Local Continuous Replication) è una soluzione per i server che utilizzano la tecnologia di log shipping asincrono incorporata per creare e mantenere una copia di un gruppo di archiviazione su un secondo gruppo di dischi connessi allo stesso server del gruppo di archiviazione di produzione. La replica continua locale consente il log shipping, la riproduzione dei registri e un rapido passaggio manuale a una copia secondaria dei dati.

  • Replica continua cluster   La replica continua cluster (CCR, Cluster Continuous Replication), una soluzione di cluster di failover per l'archiviazione non condivisa, è uno dei due tipi di distribuzione di server di cassette postali in cluster disponibili in Exchange 2007. La replica continua cluster è una soluzione cluster (detta anche ambiente CCR) che utilizza la tecnologia di log shipping asincrono incorporata per creare e mantenere una copia di un gruppo di archiviazione su un secondo server in un cluster di failover. La replica continua cluster è progettata come soluzione a uno o due centri dati, in grado di assicurare un'elevata disponibilità e la resilienza del sito. La replica continua cluster è molto diversa dal tipo di cluster utilizzato nelle versioni precedenti di Exchange Server. Per ulteriori informazioni su alcune delle differenze, vedere Risorse cluster di Exchange per server Mailbox cluster e Procedura di ripristino della replica continua cluster.

  • Replica continua di standby   La replica continua di standby (SCR, Standby Continuous Replication) è una nuova funzionalità che è stata introdotta in Exchange 2007 SP1. Come indicato dal nome, la replica continua di standby è stata progettata per scenari in cui vengono utilizzati o in cui è consentito l'utilizzo di server di ripristino di standby. La replica continua di standby estende le funzioni di replica continua esistenti e consente nuovi scenari di disponibilità di dati per i server Cassette postali di Exchange 2007. La replica continua di standby utilizza la stessa tecnologia di log shipping e di riproduzione utilizzata dalla replica continua locale e dalla replica continua cluster per fornire ulteriori opzioni e configurazioni di distribuzione, consentendo all'amministratore di creare copie aggiuntive dei gruppi di archiviazione. La replica continua di standby può essere utilizzata per replicare i dati da server Cassette postali autonomi e server di cassette postali in cluster.

  • Cluster a copia singola   Il cluster a copia singola, una soluzione di cluster di failover per l'archiviazione condivisa, è l'altro dei due tipi di distribuzione di server di cassette postali in cluster disponibili in Exchange 2007. Il cluster a copia singola è una soluzione cluster che utilizza una singola copia di un gruppo di archiviazione in un archivio condiviso tra i nodi del cluster. Per certi aspetti, il cluster a copia singola è simile al tipo di cluster utilizzato nelle versioni precedenti di Exchange Server, tuttavia, oltre a numerosi miglioramenti, sono state apportate alcune modifiche significative. Per ulteriori informazioni su alcune delle modifiche apportate, vedere Modello di risorse cluster a copia singola e Comportamento del ripristino del cluster a copia singola.

Per ulteriori informazioni su altre funzioni e funzionalità di elevata disponibilità introdotte in SP1, vedere Nuove funzionalità per l'elevata disponibilità in Exchange 2007 SP1.

Elevata disponibilità per i server Cassette postali

Esistono due forme di elevata disponibilità per i server Cassette postali: disponibilità del servizio e disponibilità dei dati. La disponibilità del servizio viene fornita mediante l'utilizzo di un cluster di failover Windows Server. La disponibilità dei dati viene fornita mediante una funzionalità incorporata denominata replica continua.

Server di cassette postali in cluster

Sia la replica continua cluster (CCR) che il cluster a copia singola (SCC) sono soluzioni distribuite in un cluster di failover Windows Server. In un failover dei cluster è possibile installare solo il ruolo del server Cassette postali. In un failover dei cluster non è possibile installare altri ruoli. Un server Cassette postali distribuito in un cluster di failover è denominato server di cassette postali in cluster. I server di cassette postali in cluster in esecuzione in un ambiente di replica continua cluster (CCR) sono molto diversi dai server di cassette postali in cluster in esecuzione in un ambiente cluster a copia singola (SCC). Inoltre, i server di cassette postali in cluster in Exchange 2007 RTM e in Exchange 2007 SP1 sono molto diversi rispetto ai server di cassette postali in cluster nelle versioni precedenti di Microsoft Exchange.

È possibile utilizzare Get-MailboxServer <CMSName> | fl Name, ClusteredStorageType in Exchange Management Shell per determinare se un server di cassette postali in cluster si trova in un ambiente di replica continua cluster o in un cluster a copia singola. Il valore NonShared indica che il server di cassette postali in cluster si trova in un ambiente di replica continua cluster, mentre il valore Shared indica che il server di cassette postali in cluster si trova in un cluster a copia singola. Il valore Disabled indica che il server Cassette postali è un server autonomo.

È inoltre possibile controllare Active Directory per determinare se un server di cassette postali in cluster si trova in un ambiente di replica continua cluster o in un cluster a copia singola esaminando il valore dell'attributo msExchClusterStorageType per l'oggetto server Cassette postali. Il valore 1 per l'attributo msExchClusterStorageType indica che il server di cassette postali in cluster si trova in un ambiente di replica continua cluster, mentre il valore 2 indica che si trova in un cluster a copia singola. Il valore <Non impostato> indica che il server Cassette postali è un server autonomo.

Ambienti di replica continua cluster

Exchange 2007 RTM ed Exchange 2007 SP1 supportano un massimo di due nodi con installato il ruolo del server Cassette postali (uno attivo e uno passivo) in un ambiente di replica continua cluster. È supportato anche un cluster a tre nodi che utilizza un nodo voter e un normale quorum maggioranza dei nodi, ma quest'ultimo non è un modello di cluster preferito. Alla maggioranza dei clienti si consiglia di distribuire ambienti di replica continua cluster che utilizzano soltanto due nodi e un quorum maggioranza dei nodi e delle condivisioni file (Windows Server 2008) o un quorum maggioranza dei nodi con witness di condivisione file (Windows Server 2003). Pertanto, la documentazione sulla replica continua cluster (CCR) è orientata al tipo di cluster di failover a due nodi che utilizza uno di questi modelli di quorum.

Nota

È supportato anche il cluster di failover a nodo singolo distribuito in un ambiente CCR, ma non è considerato come una soluzione a elevata disponibilità per il fatto che nel cluster non esiste alcuna ridondanza. Quando si utilizza un cluster di failover a nodo singolo in un ambiente CCR, è necessario utilizzare un quorum maggioranza dei nodi (normale, senza witness di condivisione file).

Cluster a copia singola

Exchange 2007 RTM ed Exchange 2007 SP1 supportano un massimo di otto nodi in un ambiente SCC. Le combinazioni valide di SCC con Exchange 2007 SP1 su cluster di failover di Windows Server includono:

  • 7 attivi / 1 passivo

  • 6 attivi / 1 o 2 passivi

  • 5 attivi / 1, 2 o 3 passivi

  • 4 attivi / 1, 2, 3 o 4 passivi

  • 3 attivi / 1, 2, 3, 4 o 5 passivi

  • 2 attivi / 1, 2, 3, 4, 5 o 6 passivi

  • 1 attivo / 0, 1, 2, 3, 4, 5, 6 o 7 passivi

    Nota

    La versione a 64 bit di Windows Server 2008 supporta fino a 16 nodi in un singolo cluster di failover, tuttavia Exchange 2007 supporta un massimo di 8 nodi nel cluster. Il cluster di failover può comunque contenere fino a 16 nodi, tuttavia Exchange 2007 deve essere installato in non più di 8 nodi del cluster di failover.

Solitamente, non è necessario che vi sia più di un nodo passivo nel cluster per ogni nodo attivo nel cluster. Di conseguenza, una configurazione di un nodo attivo e un nodo passivo è preferibile rispetto alle configurazioni con un nodo attivo e più nodi passivi. Quando si utilizza un ambiente SCC a nodo singolo, è necessario utilizzare un quorum di archiviazione condivisa o un quorum maggioranza dei nodi (normale, senza witness di condivisione file). Benché siano supportati, gli ambienti SCC a nodo singolo non sono considerati come soluzione a elevata disponibilità perché nel cluster non esiste alcuna ridondanza.

Cluster esteso

Un cluster esteso, noto anche come cluster dislocato geograficamente, è un cluster di failover che viene esteso (ovvero, distribuito) su più centri dati fisici. È possibile utilizzare i cluster estesi come parte di un progetto di resilienza del sito per l'organizzazione di Exchange. Poiché la replica continua cluster non utilizza l'archiviazione condivisa, è possibile distribuirla facilmente in un cluster di failover dislocato geograficamente, includendo un cluster esteso per più subnet in Windows Server 2008. Anche la funzionalità di cluster a copia singola è supportata in un cluster esteso. Tuttavia, l'estensione di cluster a copia singola richiede una tecnologia di replica sincrona di terze parti. Per ulteriori informazioni sui cluster estesi, vedere Site Resilience Configurations.

Cluster di standby

Un altro tipo di cluster supportato da Exchange 2007 e da Exchange 2007 SP1 è il cosiddetto cluster di standby. Un cluster di standby è un cluster di failover Windows Server che non contiene un server di cassette postali in cluster, ma che può essere rapidamente predisposto con un server di cassette postali in cluster sostitutivo nel caso di un'emergenza, di un altro errore nel cluster di failover di produzione o di altri scenari di recupero.

Replica continua

La replica continua, nota anche con il termine log shipping, è il processo di automatizzazione della replica di file di registro delle transazioni chiuse da un gruppo di archiviazione di produzione a una copia dello stesso gruppo di archiviazione che si trova su un secondo insieme di dischi presente nel computer locale o in un altro server. Una volta copiati nella seconda posizione, i file di registro vengono quindi riprodotti nella copia del database, mantenendo così i gruppi di archiviazione sincronizzati con un leggero ritardo.

In Exchange 2007 RTM la replica continua è disponibile in due forme (LCR e CCR), mentre in Exchange 2007 SP1 sono disponibili tre forme (LCR, CCR e SCR).

Elevata disponibilità per altri ruoli del server

L'elevata disponibilità per i ruoli del server Trasporto Hub, Trasporto Edge, Accesso client e Messaggistica unificata viene ottenuta attraverso una combinazione di ridondanza dei server, bilanciamento del carico di rete (NLB Network Load Balancing), bilanciamento del carico hardware, round robin DNS e gestione proattiva dei server, dei servizi e dell'infrastruttura. In genere è possibile ottenere un'elevata disponibilità per i ruoli del server Accesso client, Trasporto Hub, Trasporto Edge e Messaggistica unificata utilizzando le seguenti strategie e tecnologie:

  • Trasporto Edge   È possibile distribuire più server Trasporto Edge e utilizzare più record Mail Exchanger (MX) DNS per il bilanciamento del carico tra i server in questione. È inoltre possibile utilizzare NLB per il bilanciamento del carico e la disponibilità elevata dei server Trasporto Edge.

  • Accesso client   È possibile utilizzare NLB o un dispositivo di bilanciamento del carico di rete basato su hardware di terze parti per assicurare l'elevata disponibilità del server Accesso client. Per ulteriori informazioni su NLB, vedere Windows Server TechCenter (informazioni in lingua inglese).

  • Trasporto Hub   È possibile distribuire più server Trasporto Hub per garantire l'elevata disponibilità del trasporto interno. Nel ruolo del server Trasporto Hub la resilienza è stata progettata nei modi seguenti:

    • Da server Trasporto Hub a server Trasporto Hub (all'interno dell'organizzazione) Per la comunicazione tra server Trasporto Hub e server Trasporto Hub all'interno di un'organizzazione, il carico viene automaticamente bilanciato tra i server Trasporto Hub disponibili nel sito del servizio directory di Active Directory di destinazione.

    • Da server Cassette postali a server Trasporto Hub (all'interno del sito Active Directory)   Il Servizio di invio posta di Microsoft Exchange nei server Cassette postali bilancia automaticamente il carico tra tutti i server Trasporto Hub disponibili all'interno dello stesso sito Active Directory.

    • Da server Messaggistica unificata a server Trasporto Hub   Il server Messaggistica unificata bilancia automaticamente il carico delle connessioni tra tutti i server Trasporto Hub disponibili all'interno dello stesso sito Active Directory.

    • Da server Trasporto Edge a server Trasporto Hub   Il server Trasporto Edge bilancia automaticamente il carico del traffico Simple Mail Transfer Protocol (SMTP) in ingresso tra tutti i server Trasporto Hub disponibili nel sito Active Directory al quale è sottoscritto il server Trasporto Edge.

    Per ottenere una maggiore ridondanza (ad esempio applicazioni che richiedono l'inoltro SMTP), è possibile creare un nuovo record DNS (ad esempio inoltro.azienda.com), assegnare un indirizzo IP e utilizzare un dispositivo hardware di bilanciamento del carico per reindirizzare tale indirizzo IP a più server Trasporto Hub. In Exchange 2007 SP1, è possibile utilizzare il bilanciamento del carico di rete per i connettori client sui server Trasporto Hub. Quando si utilizza un dispositivo di bilanciamento del carico hardware, è necessario confermare che nessun traffico all'interno dell'organizzazione Exchange 2007 passerà attraverso tale dispositivo di bilanciamento del carico hardware perché, come descritto in precedenza, il traffico all'interno dell'organizzazione utilizza algoritmi di bilanciamento del carico incorporati. Per ulteriori informazioni sul bilanciamento del carico per i server di trasporto, vedere Opzioni di distribuzione dei server Trasporto Hub e Bilanciamento del carico e tolleranza di errore per i server di trasporto.

  • Messaggistica unificata   Le distribuzioni di messaggistica unificata possono avere una resilienza maggiore se si distribuiscono più server Messaggistica unificata e almeno due si trovano in un singolo dial plan. I gateway Voice over IP (VoIP) supportati dalla messaggistica unificata possono essere configurati in modo che indirizzino le chiamate a server Messaggistica unificata in modo round robin. Inoltre questi gateway possono recuperare l'elenco di server per un dial plan da DNS. In entrambi i casi i gateway VoIP presenteranno una chiamata a un server Messaggistica unificata e tale chiamata, se non viene accettata, verrà presentata a un altro server. Nel momento in cui la chiamata viene stabilita, si ottiene ridondanza.

Raggiungimento dell'elevata disponibilità con ridondanza dei dati e dei servizi

La premessa di base dell'architettura a elevata disponibilità di Exchange 2007 è quella di introdurre ridondanza nella distribuzione. Per eseguire il recupero da un errore, vengono utilizzate le risorse informative restanti per supportare i servizi di Exchange. Una volta corretti gli errori, le risorse informatiche saranno nuovamente disponibili per Exchange e i relativi client. In questo contesto le risorse informatiche possono essere computer o sistemi di archiviazione per cassette postali o altri dati di Exchange.

La ridondanza può essere introdotta all'interno di un singolo centro dati. Questa operazione viene eseguita per offrire protezione dagli errori di singoli server. Ad esempio, se si introduce un secondo server Trasporto Hub nel centro dati principale della propria organizzazione, il flusso di posta non viene interrotto anche se uno dei due server si blocca.

In alternativa o in aggiunta, la ridondanza può essere introdotta anche in un centro dati secondario. È possibile mantenere la continuità del servizio dopo un errore del centro dati grazie a due configurazioni del centro dati. Se un server Trasporto Hub aggiuntivo viene introdotto in un centro dati secondario, questo secondo server può gestire il flusso di posta quando si verifica un errore nel server Trasporto Hub principale oppure quando il centro dati di produzione non è disponibile. Se vengono distribuiti tre server Trasporto Hub, due possono essere assegnati al centro dati di produzione e uno al centro dati secondario.

È importante sottolineare che, nella distribuzione, la ridondanza può impedire interruzioni che altrimenti provocherebbero numerosi errori. Il modo in cui vengono distribuiti i servizi e i computer ridondanti determina quali errori si possono verificare senza compromettere i dati o la disponibilità dei servizi. Le organizzazioni devono avere un'immagine chiara dei propri requisiti e solo successivamente esaminare i problemi operativi per individuare la soluzione ideale. Ad esempio, un'organizzazione potrebbe attivare un centro dati di backup solo se un errore del centro dati di produzione si prolunga per oltre 20 minuti. In questo caso l'organizzazione deve disporre dei processi necessari per poter convalidare regolarmente l'attivazione e il funzionamento del centro dati di backup. Un'altra organizzazione potrebbe decidere che la una convalida continua del centro dati di backup sia di importanza critica per il successo. Di conseguenza, per questa organizzazione, sarebbe necessaria una configurazione di distribuzione diversa.