Misure per la tolleranza di errore a livello di sistema

 

Ultima modifica dell'argomento: 2006-08-16

In questo argomento vengono descritte considerazioni e strategie a livello di sistema per aumentare la tolleranza d'errore dell'organizzazione di Exchange 2003. Più precisamente, a livello di sistema fa riferimento all'infrastruttura di Exchange 2003 e alle procedure consigliate per implementare la tolleranza di errore all'interno dell'infrastruttura.

Nella seguente figura viene illustrata un'infrastruttura di Exchange 2003 affidabile e vengono elencate le procedure consigliate per mantenere un elevato livello di tolleranza di errore.

Misure per infrastrutture con tolleranza di errore

In questa sezione vengono descritti i metodi per progettare la tolleranza di errore a ciascun livello dell'infrastruttura di Exchange 2003. Più precisamente vengono fornite informazioni su quanto segue:

• Implementazione di firewall e reti perimetrali
• Affidabilità dell'accesso ad Active Directory e DNS (Domain Name System)
• Affidabilità dell'accesso a server front-end di Exchange
• Configurazione di server virtuali di protocollo di Exchange
• Implementazione di una soluzione affidabile di archiviazione back-end
• Implementazione di una soluzione di clustering dei server
• Implementazione di una strategia di monitoraggio
• Implementazione di una strategia di ripristino di emergenza

Implementazione di firewall e reti perimetrali

È consigliabile includere una rete perimetrale e un'architettura server front-end e back-end nella topologia di Exchange 2003. Nella figura seguente viene illustrata la topologia con la protezione aggiuntiva fornita da un server proxy inverso avanzato, in questo caso, ISA (Internet Security and Acceleration) Server 2000 Feature Pack 1.

Nota

Per migliorare le prestazioni e la scalabilità del server proxy inverso avanzato, è possibile implementare la funzione Bilanciamento carico di rete (NLB, Network Load Balancing) di Windows Server 2003 nei server della rete perimetrale. Per ulteriori informazioni sul bilanciamento del carico di rete vedere "Utilizzo di Bilanciamento carico di rete sui server front-end " più avanti in questo argomento.

La distribuzione di ISA Server 2000 Feature Pack 1 in una rete perimetrale è solo uno dei modi di proteggere il sistema di messaggistica. Altri metodi comprendono l'utilizzo della protezione a livello di trasporto come, ad esempio, IPSec (Internet Protocol security) e SSL (Secure Sockets Layer).

Importante

Anche se si decide di non implementare una topologia che includa i server front-end di Exchange 2003, è consigliabile impedire agli utenti di Internet di accedere ai server back-end in modo diretto.

Per informazioni complete sulla progettazione di una topologia di Exchange protetta, vedere "Planning Your Infrastructure" in Planning an Exchange Server 2003 Messaging System (informazioni in lingua inglese).

Per informazioni sull'utilizzo di ISA Server 2000 con Exchange 2003, vedere Using ISA Server 2000 with Exchange Server 2003 (informazioni in lingua inglese).

Affidabilità dell'accesso ad Active Directory e DNS (Domain Name System)

Exchange si avvale soprattutto di Active Directory e di DNS (Domain Name System). Per offrire un accesso affidabile ed efficiente ad Active Directory e DNS, verificare che i controller di dominio, i server di catalogo globale e i server DNS siano opportunamente protetti da possibili errori.

Controller di dominio

Un controller di dominio è un server che ospita un database di domini ed esegue i servizi di autenticazione richiesti affinché i client possano connettersi e accedere a Exchange. Gli utenti devono poter essere autenticati da Exchange o Windows. Exchange 2003 si basa sui controller di dominio per le informazioni relative alla configurazione del server e del sistema. In Windows Server 2003 il database di dominio è parte del database di Active Directory. In un insieme di strutture di dominio di Windows Server 2003, le informazioni di Active Directory vengono replicate tra i controller di dominio che ospitano anche una copia della configurazione dell'insieme di strutture e dei contenitori di schema.

Un controller di dominio può assumere ruoli diversi all'interno dell'infrastruttura di Active Directory: server di catalogo globale, master operazioni o semplice controller di dominio.

Server di catalogo globale

Un server di catalogo globale è un controller di dominio che ospita il catalogo globale. Un server di catalogo globale è necessario per l'accesso, poiché contiene informazioni sull'appartenenza ai gruppi universali, che concede o nega l'accesso utente alle risorse. Se non è possibile contattare un server di catalogo globale, non è possibile determinare l'appartenenza universale di un utente e l'accesso viene negato.

Nota

Sebbene in Windows Server 2003 siano disponibili funzionalità che non richiedono un server di catalogo globale locale, per utilizzare Exchange e Outlook è necessario tale server, che è essenziale per i servizi di Exchange, inclusi l'accesso, l'appartenenza ai gruppi e il servizio Archivio informazioni di Microsoft Exchange, nonché per l'accesso all'elenco indirizzi globale. La distribuzione locale dei server di catalogo globale per i server e gli utenti rende più efficienti le ricerche di indirizzi. Se si contatta un server di catalogo globale attraverso una connessione lenta, il traffico di rete aumenta e le prestazioni peggiorano.

È necessario installare almeno un server di catalogo globale in ogni dominio contenente server di Exchange.

Procedure consigliate per server di catalogo globale e controller di dominio

Poiché nei controller di dominio vengono archiviate informazioni essenziali su Active Directory, accertarsi che siano ben protetti da possibili errori.

Di seguito sono riportate le procedure consigliate per la distribuzione e la configurazione dei controller di dominio e dei server di catalogo globale di Active Directory.

• Non eseguire Exchange 2003 sui controller di dominio, salvo diverse esigenze dell'organizzazione. Per ulteriori informazioni sulle implicazioni dell'esecuzione di Exchange su un controller di dominio, vedere "Esecuzione di Exchange 2003 su un controller di dominio" più avanti in questo argomento.

• Posizionare almeno due controller di dominio in ciascun sito di Active Directory. Se un controller di dominio non è disponibile all'interno di un sito, viene eseguita la ricerca di un altro controller di dominio. Questo si rivela particolarmente importante se all'interno dell'organizzazione è possibile accedere agli altri controller di dominio solo attraverso una rete WAN. Questa circostanza potrebbe causare problemi di prestazioni e, eventualmente, di singoli punti di errore.

• Posizionare almeno due server di catalogo globale in ciascun sito di Active Directory. Se un server di catalogo globale non è disponibile all'interno di un sito, viene eseguita la ricerca di un altro server di catalogo. Questo si rivela particolarmente importante se all'interno dell'organizzazione è possibile accedere agli altri server di catalogo globale solo attraverso una rete WAN. Questa circostanza potrebbe causare problemi di prestazioni e, eventualmente, di singoli punti di errore.

  Nota

  Se i requisiti relativi alle prestazioni non richiedono la larghezza di banda di due controller di dominio e di due server di catalogo globali per ciascun dominio, valutare la possibilità di configurare tutti i controller di dominio come server di catalogo globale. In questo scenario ogni controller di dominio sarà in grado di fornire i servizi del catalogo globale all'organizzazione di Exchange 2003.

• In genere il rapporto tra processori di Exchange e processori di server di catalogo globale dovrebbe essere di 4:1, presumendo che i processori siano simili in quanto a modello e velocità. Tuttavia, un utilizzo maggiore dei server di catalogo globale, un database di Active Directory o liste di distribuzione di grandi dimensioni possono richiedere più server di catalogo globale.

• Nelle filiali con più di 10 utenti, è necessario installare un server di catalogo globale in ogni sito con server di Exchange. Tuttavia, per motivi di ridondanza, la soluzione ideale è la distribuzione di due server di catalogo globale. Se in un sito fisico non sono disponibili due server di catalogo globale, è possibile configurare i controller di dominio esistenti come server di catalogo globale.

• Se l'architettura a disposizione comprende più subnet per sito, è possibile aggiungere ulteriore disponibilità garantendo la presenza di almeno un controller di dominio e di un server di catalogo globale per subnet. Di conseguenza, anche se un router non funziona correttamente, sarà sempre possibile accedere al controller di dominio.

• Assicurarsi che il server a cui è stato assegnato il ruolo di master dell'infrastruttura non sia un server di catalogo globale. Per ulteriori informazioni sul ruolo master dell'infrastruttura, vedere l'argomento relativo al catalogo globale e al master dell'infrastruttura nella Guida di Windows 2000 Server.

• Valutare la possibilità di monitorare la latenza LDAP su tutti i controller di dominio di Exchange 2003. Per informazioni sul monitoraggio di Exchange, vedere Implementazione di strumenti software per il monitoraggio e il rilevamento di errori.

• Valutare la possibilità di aumentare i thread LDAP da 20 a 40, in base alle proprie esigenze. Per informazioni sull'ottimizzazione di Exchange, vedere il Manuale sulle prestazioni e la scalabilità di Exchange Server 2003.

• Assicurarsi inoltre che la pianificazione del backup dei controller di dominio sia affidabile.

Esecuzione di Exchange 2003 su un controller di dominio

Non è consigliabile eseguire Exchange 2003 sui server che fungono anche da controller di dominio di Windows. Piuttosto, è preferibile configurare separatamente i server di Exchange e i controller di dominio di Windows.

Tuttavia, se l'organizzazione richiede l'esecuzione di Exchange 2003 su un controller di dominio, tenere presente le limitazioni riportate di seguito:

• Se Exchange 2003 viene eseguito su un controller di dominio, utilizzerà solo quel controller. Di conseguenza, se si verifica un errore del controller di dominio, Exchange non è in grado di eseguire il failover su un altro controller di dominio.
• Se i server di Exchange eseguono anche le attività dei controller di dominio, oltre a servire i computer client di Exchange, possono verificarsi delle riduzioni delle prestazioni durante carichi utente elevati.
• Se il server di Exchange viene eseguito su un controller di dominio, si può verificare una sovrapposizione delle responsabilità degli amministratori di Active Directory e di Exchange per il ripristino di emergenza e la protezione.
• I server di Exchange 2003 che sono anche controller di dominio non possono essere parte di un cluster di Windows. Più precisamente, in Exchange 2003 non sono supportati i server cluster di Exchange 2003 che coesistono con i server di Active Directory. Ad esempio, poiché gli amministratori di Exchange che possono accedere al server locale dispongono dell'accesso fisico alla console del controller di dominio, possono potenzialmente incrementare le loro autorizzazioni in Active Directory.
• Se il server in questione è l'unico controller di dominio del sistema di messaggistica, è necessario che sia anche un server di catalogo globale.
• Se Exchange 2003 viene eseguito su un controller di dominio, evitare di utilizzare l'opzione /3GB. In caso contrario, è possibile che la cache di Exchange monopolizzi la memoria del sistema. Inoltre, poiché il numero di connessioni utente deve essere basso, l'opzione /3GB non deve essere richiesta.
• Poiché tutti i servizi vengono eseguiti in LocalSystem, in presenza di un bug di protezione aumenta il rischio di esposizione. Ad esempio, se Exchange 2003 è in esecuzione su un controller di dominio, un bug di Active Directory che consente a un potenziale intruso di accedere ad Active Directory consentirebbe anche l'accesso a Exchange.
• Un controller di dominio che esegue Exchange 2003 richiede una considerevole quantità di tempo per il riavvio o l'arresto: almeno 10 minuti. Questo si verifica perché i servizi relativi ad Active Directory (ad esempio, Lsass.exe) vengono arrestati prima dei servizi di Exchange, causando quindi un ripetuto malfunzionamento dei servizi di Exchange durante la ricerca dei servizi di Active Directory. Per risolvere questo problema, è possibile modificare il timeout per un servizio non eseguito correttamente. Una seconda soluzione possibile consiste nell'interrompere manualmente i servizi di Exchange prima di arrestare il server.

Disponibilità dei servizi DNS (Domain Name System) e WINS (Windows Internet Name Service)

I servizi DNS, simili ai servizi del server di catalogo globale e del controller di dominio, sono di fondamentale importanza per la disponibilità dell'organizzazione di Exchange 2003. In una rete di Windows Server 2003 gli utenti individuano le risorse utilizzando i servizi DNS e WINS. L'errore di un server DNS può impedire agli utenti di individuare il sistema di messaggistica.

Per assicurare che nella topologia di Exchange 2003 sia incluso un accesso affidabile a DNS, tenere presente quanto segue:

• Assicurare la presenza di un server DNS secondario in rete. In caso di errore del server DNS primario, il server secondario sarà in grado di reindirizzare gli utenti verso i server appropriati.
• Integrare zone DNS di Windows Server 2003 in Active Directory. In questo scenario ogni controller di dominio diventa un potenziale server DNS.
• Configurare ogni computer client con almeno due indirizzi DNS.
• Nella condizione ideale, entrambi i server DNS dovrebbero trovarsi nello stesso sito del client. In caso contrario, il server DNS primario deve essere quello che si trova nello stesso sito del client.
• Assicurarsi che le funzionalità DNS e di risoluzione dei nomi funzionino correttamente. Per ulteriori informazioni, vedere l'articolo 322856 della Microsoft Knowledge Base "HOW TO: Configurazione del DNS per l'utilizzo con Exchange Server".
• Prima di distribuire Exchange, accertarsi che il DNS sia configurato correttamente nel sito hub e in tutte le filiali.
• Exchange richiede WINS. Sebbene sia possibile eseguire Exchange 2003 senza abilitare WINS, non è una scelta consigliata. L'utilizzo di WINS per risolvere i nomi NetBIOS offre notevoli vantaggi in termini di disponibilità. Ad esempio, l'utilizzo di WINS in alcune configurazioni consente di eliminare il rischio potenziale di duplicazione dei nomi NetBIOS, che provoca un errore nella risoluzione dei nomi. Per ulteriori informazioni, vedere l'articolo 837391 della Microsoft Knowledge Base "Necessità della risoluzione dei nomi NetBIOS per il funzionamento completo di Exchange Server 2003 ed Exchange 2000 Server".

Per informazioni sulla distribuzione di DNS e WINS, vedere "Deploying DNS" e "Deploying WINS" in Microsoft Windows Server 2003 Deployment Kit (informazioni in lingua inglese).

Affidabilità dell'accesso a server front-end di Exchange

Se nell'organizzazione sono presenti più server di Exchange, è consigliabile l'utilizzo di un'architettura server front-end e back-end, che offre diversi vantaggi in termini di disponibilità e prestazioni di accesso client.

I client di Internet accedono alle proprie cassette postali attraverso i server front-end. Tuttavia, nelle configurazioni predefinite di Exchange 2003 i client MAPI non possono utilizzare i server front-end e accedono alle proprie cassette postali direttamente attraverso i server back-end.

Nota

È possibile configurare Exchange 2003 RPC su HTTP per consentire ai client MAPI di accedere alle cassette postali attraverso i server front-end. Per informazioni sull'utilizzo di RPC su HTTP, vedere Exchange Server 2003 RPC over HTTP Deployment Scenarios (informazioni in lingua inglese).

Quando i server front-end utilizzano HTTP, POP3 e IMAP4, le prestazioni risultano migliori perché i server front-end ripartiscono una parte del carico di elaborazione dai server back-end.

Se si prevede di supportare MAPI, HTTP, POP3 o IMAP4, l'utilizzo dell'architettura di server front-end e back-end di Exchange offre i vantaggi riportati di seguito:

• I server front-end ripartiscono equamente tra i server le attività di elaborazione. Ad esempio, i server front-end eseguono l'autenticazione, la crittografia e la decrittografia. In tal modo migliorano le prestazioni dei server back-end di Exchange.
• La protezione del sistema di messaggistica risulta migliorata. Per ulteriori informazioni, vedere "Misure di protezione" più avanti in questo argomento.
• Per incorporare la ridondanza e il bilanciamento del carico nel sistema di messaggistica, è possibile utilizzare la funzione Bilanciamento carico di rete (NLB, Network Load Balancing) sui server front-end di Exchange.

Per informazioni sulla pianificazione di un'architettura front-end e back-end di Exchange 2003, vedere "Planning Your Infrastructure" in Planning an Exchange Server 2003 Messaging System (informazioni in lingua inglese).

Per informazioni sulla distribuzione dei server front-end e back-end, vedere Using Microsoft Exchange 2000 Front-End Servers (informazioni in lingua inglese). Sebbene il documento indicato si concentri su Exchange 2000, il suo contenuto si applica anche a Exchange 2003.

Per implementare la tolleranza di errore nel sistema di messaggistica, valutare la possibilità di implementare server front-end di Exchange che utilizzano la funzione Bilanciamento carico di rete. È anche consigliabile configurare server virtuali ridondanti sui server front-end.

Utilizzo di Bilanciamento carico di rete (NLB) sui server front-end

Il bilanciamento del carico di rete è un servizio di Windows Server 2003 che offre un supporto di bilanciamento del carico per applicazioni basate su IP e servizi che richiedono alta scalabilità ed elevate prestazioni. Quando è implementato sui server front-end di Exchange 2003, il servizio può risolvere i colli di bottiglia causati dai servizi di front-end.

Nella figura seguente viene illustrata un'architettura front-end e back-end di base che include il bilanciamento del carico di rete.

Un cluster NLB distribuisce in modo dinamico il traffico IP su due o più server front-end di Exchange, ripartisce in modo trasparente le richieste dei client tra i server front-end e consente ai client di accedere alle proprie cassette postali utilizzando un solo spazio dei nomi server.

I cluster NLB sono computer che, grazie alla loro quantità, consentono di aumentare la scalabilità e le prestazioni degli elementi indicati di seguito:

• Server Web
• Computer che eseguono ISA Server (per server proxy e firewall)
• Altre applicazioni che ricevono traffico TCP/IP e UDP (User Datagram Protocol)

Di solito i nodi di cluster NLB dispongono di configurazioni hardware e software identiche. In tal modo si assicurano agli utenti prestazioni coerenti del servizio front-end, indipendentemente dal nodo del cluster NLB che fornisce il servizio. I nodi in un cluster NLB sono tutti attivi.

Importante

   Il clustering NLB non fornisce supporto per il failover come il Servizio cluster di Windows. Per ulteriori informazioni, vedere la sezione seguente, "Bilanciamento del carico di rete e scalabilità".

Per ulteriori informazioni sul bilanciamento del carico di rete, vedere "Designing Network Load Balancing" e "Deploying Network Load Balancing" in Microsoft Windows Server 2003 Deployment Kit (informazioni in lingua inglese).

Bilanciamento del carico di rete e scalabilità

Con la funzione Bilanciamento carico di rete è possibile applicare la scalabilità in verticale o in orizzontale non appena aumentano le richieste sui server front-end di Exchange 2003. In generale, se l'obiettivo primario è fornire un servizio più veloce agli utenti di Exchange, la scalabilità in verticale (ad esempio, l'aggiunta di processori e ulteriore memoria) è una buona soluzione. Tuttavia, se si desidera implementare misure per la tolleranza di errore nei servizi front-end, l'aggiunta di server (scalabilità in orizzontale) rappresenta la soluzione più adatta. Mediante il bilanciamento del carico di rete è possibile aggiungere fino a 32 server, se necessario. La scalabilità in orizzontale consente di incrementare la tolleranza di errore perché, se sono disponibili più server nel cluster NLB, un errore del server riguarda un numero limitato di utenti.

Importante

È necessario monitorare attentamente i server presenti nel cluster NLB. Quando si verifica un errore del server in un cluster NLB, le richieste dei client configurate per essere inviate al server con errore non vengono automaticamente distribuite agli altri server del cluster. Di conseguenza, quando un server del cluster NLB non funziona correttamente, deve essere immediatamente rimosso dal cluster per assicurare la fornitura agli utenti dei servizi richiesti.

Configurazione di server virtuali di protocollo di Exchange

Durante la configurazione del sistema di messaggistica di Exchange 2003, utilizzare il Gestore di sistema di Exchange per creare un server virtuale di protocollo per ogni protocollo che si desidera supportare su un server front-end specifico.

Per ottimizzare la disponibilità e le prestazioni dei server front-end, al momento di configurare i server virtuali di protocollo, tenere presente quanto segue.

• Durante la configurazione del bilanciamento del carico di rete per i server front-end di Exchange 2003, è necessario che tutti i server virtuali di protocollo sui server front-end NLB siano configurati con le medesime impostazioni.

  Importante

  Se i server virtuali di protocollo nel cluster NLB non sono identici, i client di posta elettronica possono comportarsi in modo diverso a seconda del server a cui vengono instradati.

• Se non si utilizza la funzione Bilanciamento carico di rete sui server front-end, non creare ulteriori server virtuali di protocollo su ciascuno dei server front-end. Ad esempio, non creare due server virtuali di protocollo HTTP identici sullo stesso server front-end. L'aggiunta di server virtuali può ridurre considerevolmente le prestazioni e tali server andrebbero creati solo quando non è possibile configurare adeguatamente i server virtuali predefiniti.

Per ulteriori informazioni sulla configurazione dei server virtuali dei protocolli di Exchange, vedere il Exchange Server 2003 Administration Guide.

Per informazioni sull'ottimizzazione dei server front-end di Exchange 2003, vedere il Manuale sulle prestazioni e la scalabilità di Exchange Server 2003.

Implementazione di una soluzione di archiviazione back-end affidabile

Una strategia di archiviazione affidabile è di fondamentale importanza per la tolleranza di errore del sistema di messaggistica. Per implementare e configurare una soluzione di archiviazione affidabile, è necessario acquisire familiarità con quanto segue:

• La tecnologia dei database di Exchange 2003
• Le procedure consigliate per la configurazione e la gestione dei dati di Exchange
• Le tecnologie di archiviazione avanzate come, ad esempio, i RAID e le reti SAN (Storage Area Networks)
• Per informazioni dettagliate su come pianificare e implementare una soluzione di archiviazione back-end affidabile, vedere Pianificazione di una soluzione di archiviazione back-end affidabile.

Implementazione di una soluzione di clustering dei server

Poiché consente il failover delle risorse, il clustering dei server fornisce la tolleranza di errore all'organizzazione di Exchange 2003. Più precisamente, i cluster di server che utilizzano il Servizio cluster consentono di mantenere l'integrità dei dati e forniscono il supporto di failover nonché un'elevata disponibilità per servizi e applicazioni di primaria importanza sui server back-end, inclusi i database, i sistemi di messaggistica, i servizi file e i servizi di stampa.

Nella figura seguente viene mostrato l'esempio di un cluster a quattro nodi con tre nodi attivi e uno passivo.

Nei cluster di server i nodi condividono l'accesso ai dati. I nodi possono essere sia attivi che passivi e la configurazione di ognuno dipende dalla modalità operativa (attiva o passiva) e dalla configurazione del failover. Un server designato per la gestione del failover deve essere progettato per gestire il carico di lavoro del nodo con errore.

Nota

In Windows Server 2003 Enterprise Edition e Windows Server 2003 Datacenter Edition i cluster di server possono contenere fino a otto nodi. Ogni nodo è collegato a una o più periferiche di archiviazione cluster e ciò consente ai vari server di condividere gli stessi dati. Poiché i nodi di un cluster di server condividono l'accesso ai dati, il tipo e il metodo di archiviazione nel cluster di server sono molto importanti.

Per informazioni sulla pianificazione dei cluster di server di Exchange, vedere Pianificazione del clustering di Exchange.

Vantaggi derivanti dall'utilizzo del clustering

Il clustering dei server fornisce due vantaggi principali all'organizzazione: failover e scalabilità.

Failover

Il failover è uno dei vantaggi più significativi del clustering dei server. Se un server in un cluster smette di funzionare, il carico di lavoro di quel server viene trasferito su un altro server del cluster. Il failover garantisce la disponibilità continua delle applicazioni e dei dati. Le tecnologie di clustering di Windows consentono di difendersi da tre tipi di errore specifici:

• Errori dei servizi e delle applicazioni. Questi errori riguardano il software applicativo e i servizi essenziali.
• Errori hardware e di sistema. Questi errori riguardano i componenti hardware come le CPU, le unità, la memoria, le schede di rete e gli alimentatori.
• Errori dei siti in organizzazioni a più siti Questi errori possono essere provocati da calamità naturali, interruzioni dell'alimentazione o della connettività. Per proteggere il sistema da questo tipo di errori è necessario implementare una soluzione di geoclustering avanzata. Per ulteriori informazioni, vedere "Utilizzo di più siti fisici" più avanti in questo argomento.

Contribuendo alla prevenzione di questi errori, il clustering dei server fornisce all'ambiente di messaggistica i due vantaggi riportati di seguito:

• Elevata disponibilità   La capacità di offrire agli utenti finali servizi di accesso affidabili e di ridurre le interruzioni involontarie.
• Elevata affidabilità   La capacità di ridurre la frequenza di errori del sistema.

Scalabilità

La scalabilità è un ulteriore vantaggio del clustering dei server. Poiché è possibile aggiungere nodi ai cluster, i cluster di server Windows sono estremamente scalabili.

Limitazioni del clustering

Piuttosto che fornire la tolleranza di errore a livello dei dati, il clustering dei server la fornisce a livello dell'applicazione. Durante l'implementazione di una soluzione di clustering dei server è necessario implementare anche soluzioni valide per il ripristino e la protezione dei dati da virus, danneggiamenti e altre potenziali minacce. Le tecnologie di clustering non offrono protezione da errori provocati da virus, danneggiamento del software o errori umani.

Confronto tra clustering e hardware con tolleranza di errore

Sia il clustering che l'hardware dotato di tolleranza di errore consentono di proteggere il sistema da errori o guasti dei componenti (CPU, memoria, ventola o bus PCI). Sebbene l'hardware con tolleranza di errore e il clustering possano essere utilizzati insieme come soluzione end-to-end è necessario sapere che i due metodi forniscono elevata disponibilità in modi diversi:

• Il clustering fornisce la protezione da un errore dell'applicazione o del sistema operativo. Tuttavia, un server autonomo (non-cluster) che utilizza hardware con tolleranza di errore (oppure un server che utilizza hardware collegabile a caldo, consentendo così l'aggiunta di una periferica mentre il server è in esecuzione) non può fornire protezione da questo tipo di errori.
• Il clustering consente di eseguire aggiornamenti o installazioni su uno dei nodi del cluster mentre viene mantenuta la piena disponibilità del servizio di Exchange per gli utenti. Con server autonomi (non-cluster) è spesso necessario interrompere i servizi offerti da Exchange per eseguire aggiornamenti e installazioni. Per informazioni specifiche su come mantenere la disponibilità dei servizi di Exchange durante l'esecuzione di aggiornamenti e installazioni, vedere "Disattivazione di server virtuali o di risorse di Exchange" nel Manuale dell'amministratore di Exchange Server 2003.

Implementazione di una strategia di monitoraggio

Per un'elevata disponibilità è fondamentale il monitoraggio continuo della rete, delle applicazioni, dei dati e dell'hardware. Strumenti e tecniche di monitoraggio del software consentono di determinare lo stato del sistema e di identificare potenziali problemi prima che si verifichi un errore.

Per ottimizzare la disponibilità, è necessario gestire, monitorare e risolvere i problemi che si verificano nei server e nelle applicazioni in modo coerente. Se si verifica un problema, è necessario essere in grado di reagire rapidamente, in modo da ripristinare i dati e renderli disponibili al più presto. Per offrire un supporto al monitoraggio dell'organizzazione di Exchange 2003, è possibile utilizzare Exchange 2003 Management Pack per Microsoft Operations Manager.

Per ulteriori informazioni su Exchange 2003 Management Pack, Microsoft Operations Manager e altri strumenti di monitoraggio, vedere Implementazione di strumenti software per il monitoraggio e il rilevamento di errori.

Implementazione di una soluzione di ripristino di emergenza

Per incrementare la tolleranza di errore dell'organizzazione, è necessario sviluppare e implementare una strategia di backup e di ripristino opportunamente pianificata. Se opportunamente preparata, l'organizzazione dovrebbe essere in grado di eseguire il ripristino dopo la maggior parte dei problemi.

Ulteriori procedure consigliate a livello di sistema

Dopo avere considerato le misure necessarie per incrementare la tolleranza di errore dell'infrastruttura di Exchange 2003, tenere presenti le ulteriori procedure consigliate a livello di sistema riportate di seguito.

• Salvaguardia dell'ambiente fisico dei server   Adottare le necessarie precauzioni per garantire la sicurezza e la protezione dell'ambiente fisico.
• Misure di protezione   Implementare procedure di autorizzazione, patch di protezione, protezione fisica dei computer, protezione antivirus e soluzioni per la posta indesiderata.
• Routing dei messaggi   Utilizzare hardware di rete con tolleranza di errore e configurare correttamente i gruppi e i connettori di routing.
• Utilizzare più siti fisici   Proteggere i dati da errori dei siti eseguendone il mirroring in uno o più siti remoti oppure implementando soluzioni di geoclustering per consentire il failover in caso di errore o danneggiamento di un sito.
• Procedure operative   Gestire e monitorare i server, utilizzare procedure standard e verificare le procedure di ripristino di emergenza.
• Verifiche di laboratorio e distribuzioni pilota   Prima di distribuire il sistema di messaggistica nell'ambiente di produzione verificarne le prestazioni e la scalabilità in laboratorio e in ambienti pilota.

Salvaguardia dell'ambiente fisico dei server

Per garantire la disponibilità dei server, è necessario mantenere standard elevati dell'ambiente in cui vengono eseguiti. Per aumentare la durata e l'affidabilità dell'hardware dei server, tenere presente quanto segue.

• Temperatura e umidità   Installare i server con dati essenziali in un apposito ambiente di cui sia possibile controllare attentamente la temperatura e l'umidità. I computer funzionano meglio in ambienti la cui temperatura si aggira intorno ai 21°C. Normalmente in un ufficio la temperatura non costituisce mai un problema. Tuttavia, è necessario prendere in considerazione gli effetti di un lungo fine settimana estivo durante il quale l'aria condizionata rimane spenta.
• Polvere o agenti contaminanti   Laddove possibile, proteggere i server e le altre apparechiature da polvere e altri agenti contaminanti e controllare periodicamente la presenza di polvere. Polvere o agenti contaminanti possono provocare cortocircuiti o surriscaldamenti e causare interruzioni intermittenti. Ogni volta che l'alloggiamento di un server è aperto, verificare rapidamente se l'unità necessita di pulizia. In caso, controllare anche le unità circostanti.
• Alimentatori   Come per ogni pianificazione di ripristino d'emergenza, è consigliabile prevedere le interruzioni di alimentazione prima che queste si verifichino effettivamente e quindi identificare in anticipo le risorse più importanti per il corretto funzionamento dell'infrastruttura aziendale. Quando possibile, fornire l'alimentazione da almeno due circuiti all'ambiente in cui sono collocati i computer e suddividere gli alimentatori ridondanti tra le varie fonti di alimentazione. Sarebbe preferibile, inoltre, che i circuiti avessero origine da fonti esterne all'edificio. Informarsi sulla quantità massima di alimentazione che un luogo può fornire. Una sala potrebbe ospitare un numero tale di server per cui l'alimentazione disponibile non sarebbe è sufficiente in caso di aggiunta di altri server. Prendere in considerazione la possibilità di utilizzare un'alimentazione di backup in caso di interruzione dell'alimentazione al centro dati. Può essere necessario continuare a fornire il servizio informatico ad altri edifici della zona o a zone geograficamente più lontane dal centro dati. É possibile utilizzare unità UPS (uninterruptible power supply, alimentazione ininterrotta) per gestire brevi interruzioni di alimentazione e generatori di standby per interruzioni di maggiore durata. Al momento di rivedere i componenti che richiedono un'alimentazione di backup durante un'interruzione di alimentazione, includere componenti di rete come, ad esempio, i router.
• Manutenzione dei cavi   Per impedire danni fisici ai cavi, verificarne le condizioni di pulizia e integrità che dovrano essere garantite mediante un sistema di gestione o di protezione dei cavi stessi. I cavi non devono mai essere esposti in un ambiente dove potrebbero essere disconnessi per errore. Se possibile, verificare che siano saldamente connessi a entrambe le estremità e che Assicurarsi che le apparecchiature che possono essere estratte o montate su supporti abbiano cavi sufficiente lunghi. Verificare inoltre che i cavi non siano attorcigliati o danneggiati in alcun modo. Impostare buoni percorsi per i gruppi di cavi in eccesso. Se vengono utilizzate più fonti di alimentazione o comunicazioni di rete, cercare di indirizzare i cavi negli ambienti da punti diversi. In tal modo, se un cavo è compromesso, l'altro può continuare a funzionare. Non inserire alimentatori doppi nella stessa presa di alimentazione. Se possibile, utilizzare prese di alimentazione separate o unità UPS (possibilmente, connesse a circuiti separati) per evitare un unico punto di errore.

Misure di protezione

La protezione è un componente di fondamentale importanza per ottenere un sistema di messaggistica a elevata disponibilità. Sebbene esistano diverse misure di protezione da prendere in considerazione, di seguito sono riportate quelle principali:

• Procedure di autorizzazione
• Patch di protezione
• Protezione fisica
• Protezione antivirus
• Soluzioni per la posta indesiderata

Per informazioni dettagliate su queste e altre misure di protezione, vedere il Guida alla protezione avanzata di Exchange Server 2003.

Considerazioni sul routing dei messaggi

La topologia di routing è alla base del sistema di messaggistica. Al momento della pianificazione della topologia di routing è pertanto necessario prendere in considerazione problematiche relative alla rete, alla larghezza di banda e alle aree geografiche.

Il routing descrive le modalità di trasferimento dei messaggi tra i server in Exchange. Quando si pianifica la topologia di routing, è necessario conoscere la modalità di trasferimento dei messaggi all'interno di Exchange e pianificare una topologia che consenta il recapito più efficiente dei messaggi. È inoltre necessario pianificare le posizioni dei connettori per i sistemi di messaggistica esterni all'organizzazione di Exchange. Un'attenta pianificazione consente di ridurre il volume del traffico di rete e ottimizzare i servizi di Windows ed Exchange.

Per assicurare la massima affidabilità e disponibilità del sistema di routing, tenere presenti le seguenti raccomandazioni avanzate.

• Assicurarsi che nella rete fisica sia predefinita la ridondanza. Per ulteriori informazioni, vedere "Hardware di rete" in questo argomento.
• Verificare la corretta configurazione dei connettori e dei gruppi di routing. Ad esempio, in alcuni scenari l'utilizzo del Gestore di sistema di Exchange per configurare i percorsi ridondanti dei connettori può rappresentare un limite per un singolo punto di errore.
• Configurare i connettori per garantire la presenza di più percorsi verso tutti i server testa di ponte.
• Se possibile, verificare che i server gateway SMTP (Simple Mail Transfer Protocol) siano ridondanti. Nei centri dati di grandi dimensioni si consiglia di utilizzare specifici server di Exchange 2003 dedicati per la gestione esclusiva del traffico SMTP in ingresso e in uscita. Questo tipo di server viene in genere definito gateway SMTP o hub SMTP ed è responsabile del trasferimento della posta elettronica SMTP tra i client e i server delle cassette postali di Exchange 2003 (server back-end).

Per ulteriori informazioni sulla pianificazione e la configurazione del routing (incluse le raccomandazioni per la creazione dei gruppi di routing e i connettori), vedere Pianificazione di un sistema di messaggistica Exchange Server 2003.

Per informazioni sulla configurazione del routing dei messaggi, vedere la Guida al trasporto e al routing di Exchange Server 2003.

Utilizzo di più siti fisici

Per migliorare il ripristino di emergenza e aumentare la disponibilità, alcune organizzazioni utilizzano siti fisici multipli. Molte strutture di questo tipo comprendono un sito primario e uno o più siti remoti che eseguono il mirroring del sito primario. Il livello di mirroring dei componenti e dei dati tra siti dipende dai contratti di servizio (SLA, Service Level Agreement) e da altri requisiti aziendali. Un'altra opzione consiste nell'implementare cluster dislocati geograficamente, che, se si verifica un problema, consentono il failover delle applicazioni di un sito in un altro sito.

Nelle sezioni seguenti vengono descritti il mirroring dei siti e il geoclustering.

Mirroring dei siti

Il mirroring dei siti prevede l'utilizzo della replica sincrona o asincrona dei dati, come ad esempio i database di Exchange 2003 e i dati del registro delle transazioni, dal sito primario a uno o più siti remoti.

Se si verifica un errore del sito primario, il tempo necessario a portare in linea i servizi di Exchange presso il sito con il mirroring dipende dalla complessità dell'organizzazione di Exchange, dalla quantità di hardware di standby preconfigurato a disposizione e dal livello del supporto amministrativo. Ad esempio, un'organizzazione può essere in grado di seguire una procedura per il ripristino di emergenza precedentemente pianificata e riportare il proprio sistema di messaggistica di Exchange in linea entro 24 ore. Sebbene possa sembrare un tempo molto lungo in termini di tewmpo di inattività, in questo modo sarà possibile ripristinare i dati fino al momento in cui si è verificato l'errore. Per ulteriori informazioni sulla replica sincrona e asincrona dei dati di Exchange, vedere "Tecnologie di replica dei dati di Exchange" in Cenni preliminari sulle tecnologie di archiviazione.

Cluster dislocati geograficamente

Un sistema più avanzato per implementare la tolleranza di errore a livello dei siti consiste nell'implementazione di cluster dislocati geograficamente. Per distribuire cluster dislocati geograficamente con Windows Server 2003, è necessario utilizzare le VLAN (LAN virtuali) per la connessione a lunga distanza delle reti SAN.

Le configurazioni dei cluster dislocati geograficamente possono risultare complesse ed è necessario utilizzare esclusivamente componenti supportati da Microsoft. È consigliabile eseguire la distribuzione di cluster dislocati geograficamente solo con fornitori che offrono configurazioni qualificate.

Per ulteriori informazioni sulle soluzioni di cluster dislocati geograficamente con Exchange 2003, vedere Pianificazione del clustering di Exchange.

Per ulteriori informazioni su Windows Server 2003 e sui cluster dislocati geograficamente, vedere Geographically Dispersed Clusters in Windows Server 2003 (informazioni in lingua inglese).

Procedure operative consigliate

Durante l'esecuzione e l'amministrazione del sistema di messaggistica di Exchange 2003, è importante che il personale IT utilizzi procedure consigliate IP standard. In questa sezione vengono descritte le procedure consigliate per ottimizzare la disponibilità delle applicazioni e dei computer. Le informazioni fornite possono essere applicate ad ambienti cluster e non cluster.

• Ridurre al minimo o eliminare completamente il supporto per versioni multiple di sistemi operativi, service pack e applicazioni non aggiornabili.
  È difficile fornire un supporto tecnico affidabile quando combinazioni multiple di versioni diverse di hardware e software vengono utilizzate assieme in un unico sistema o in sistemi che interagiscono in rete. Software, protocolli e driver (con relativo hardware) non aggiornabili sono inutili se non supportano nuove tecnologie. Pianificare le risorse e il tempo necessari per progettare, verificare e installare nuovi sistemi operativi, componenti software e hardware. Quando si pianificano gli aggiornamenti del software, coinvolgere gli utenti per comprenderne le esigenze. Offrire agli utenti una formazione appropriata per facilitare le transizioni da un software all'altro. Nel bilancio previsto per il software e l'assistenza tecnica, includere fondi per il futuro aggiornamento delle applicazioni e dei sistemi operativi.

• Isolare le applicazioni inaffidabili
  Un'applicazione inaffidabile è un'applicazione indispensabile per l'azienda ma che non soddisfa gli standard di affidabilità richiesti. Se è necessario lavorare con un'applicazione di questo tipo, si possono applicare due soluzioni di base:

  • Rimuovere le applicazioni inaffidabili dai server che contengono dati essenziali per l'organizzazione. Se è noto che un'applicazione è inaffidabile, cercare di isolarla e non eseguirla su un server che contiene dati essenziali.
  • Eseguire un adeguato monitoraggio e utilizzare opzioni di riavvio automatico, se opportuno. Per un monitoraggio adeguato è necessario ottenere a intervalli regolari istantanee delle misurazioni più importanti delle prestazioni del sistema. È possibile impostare il riavvio automatico di un'applicazione o di un servizio utilizzando lo snap-in Servizi. Per ulteriori informazioni sui servizi di Windows, vedere l'argomento relativo alla panoramica dei servizi nella Guida in linea di Windows Server 2003.

• Utilizzare componenti hardware aggiornati e standard
  Se l'hardware è incompatibile, possono verificarsi problemi di prestazioni e perdita dei dati. Mantenere e rispettare uno standard hardware per i nuovi sistemi e le parti di ricambio.

• Pianificare i futuri requisiti di capacità
  La pianificazione delle capacità è di importanza fondamentale per potere disporre di sistemi a elevata disponibilità. Per capire la capacità in eccesso correntemente a disposizione del sistema, studiare e monitorare le prestazioni durante il periodo di carico massimo.

• Mantenere un elenco aggiornato delle procedure operative
  Quando un problema relativo al sistema principale viene risolto, verificare di rimuovere tutte le procedure obsolete dalle pianificazioni operative e di supporto. Ad esempio, quando il software viene sostituito o aggiornato, alcune procedure possono non essere più necessarie o valide. Prestare particolare attenzione alle procedure che possono essere diventate abituali. Verificare che tutte le procedure siano necessarie e non siano soluzioni temporanee per problemi la cui causa principale non è stata rilevata.

• Eseguire adeguate procedure di monitoraggio
  Se il sistema di messaggistica non viene monitorato in modo adeguato, potrebbe non essere possibile identificare un problema prima che diventi grave e provochi errori del sistema. Senza monitoraggio, un errore dell'applicazione o del server potrebbe essere l'unico avviso dell'esistenza di un problema.

• Determinare la natura del problema prima di tentarne la soluzione
  Se il personale operativo non è adeguatamente preparato e istruito per analizzare attentamente i problemi prima di reagire, possono verificarsi considerevoli perdite di tempo nel tentativo di rispondere in modo inappropriato a un problema. Può anche darsi che il personale non utilizzi correttamente gli strumenti di monitoraggio nel periodo di tempo che intercorre tra i primi segnali di un problema e l'errore vero e proprio.

• Affrontare la causa principale del problema invece degli effetti
  Quando si verifica un errore imprevisto o si esegue un'operazione di manutenzione a scopo di prevenzione a breve termine, la correzione dell'effetto dell'errore rappresenta una strategia efficace per il ripristino dei servizi. Tuttavia, queste procedure, aggiunte alle procedure operative standard, possono diventare ingestibili. Il personale di supporto tecnico potrebbe essere troppo impegnato a risolvere gli effetti dei problemi e, quindi, non in grado di reagire all'insorgere di nuovi errori.

• Evitare di interrompere e riavviare i servizi e i server per terminare condizioni di errore
  A volte può essere necessario arrestare e riavviare un server. Tuttavia, se è vero che questa procedura consente di risolvere temporaneamente un problema, non consente di risolverne la causa principale e può creare ulteriori problemi.

Verifiche di laboratorio e distribuzioni pilota

Prima di distribuire qualsiasi nuova soluzione, indipendentemente che sia per la tolleranza di errore o l'hardware di rete, uno strumento di monitoraggio del server o una soluzione cluster di Windows, è necessario verificarla a fondo prima di distribuirla in un ambiente di produzione. Dopo la verifica in un laboratorio isolato, verificare la soluzione in una distribuzione pilota nella quale sono coinvolti solo pochi utenti ed applicare tutte le necessarie modifiche o correzioni alla struttura. Quando si è soddisfatti della distribuzione pilota, eseguire una distribuzione completa scala nell'ambiente di produzione.

A seconda del numero di utenti nell'organizzazione di Exchange, è possibile eseguire la distribuzione completa in più fasi. Dopo ogni fase, verificare che il sistema possa sostenere il maggiore carico di elaborazione proveniente dagli utenti aggiuntivi prima di procedere con il gruppo di utenti successivo. Per informazioni complete sull'impostazione di ambienti di prova e ambienti pilota, vedere "Designing a Test Environment" e "Designing a Pilot Project" in Microsoft Windows Server 2003 Deployment Kit (informazioni in lingua inglese).

Strumenti di pianificazione della capacità di Exchange

Per determinare il numero di server necessari per la gestione del carico di utenti, utilizzare gli strumenti di pianificazione delle capacità riportati di seguito.

• Exchange Server Load Simulator 2003 (LoadSim)
• Exchange Server Stress and Performance (ESP)
• Jetstress

Importante

Poiché alcuni di questi strumenti creano account con password non protette, tali strumenti devono essere utilizzati in ambienti di prova, non in ambienti di produzione.

Exchange Server Load Simulator 2003

Con Exchange Server Load Simulator 2003 (LoadSim) è possibile simulare il carico del client MAPI in Exchange. Il carico viene simulato eseguendo le prove previste dallo strumento LoadSim sui computer client. Tali prove inviano richieste di messaggi al server di Exchange, generando un carico sul server.

Utilizzare i risultati di queste prove per effettuare le seguenti operazioni:

• Calcolo del tempo di risposta del computer client per la configurazione server in presenza di un carico di lavoro client
• Calcolo del numero di utenti per server
• Identificazione di colli di bottiglia sul server

È possibile scaricare LoadSim 2003 dal sito Web Downloads for Exchange Server 2003 (informazioni in lingua inglese).

Exchange Server Stress and Performance

Exchange Server Stress and Performance (ESP) 2003 è uno strumento altamente scalabile per la valutazione delle prestazioni e del sovraccarico di Exchange. Consente la simulazione di un numero elevato di sessioni client mediante l'accesso simultaneo a uno o più servizi protocollo. Alcuni script controllano le operazioni effettuate da ciascun utente simulato. Tali script contengono la logica per la comunicazione con il server. Quindi i moduli di prova (DLL) eseguono gli script. I moduli di prova si connettono a un server attraverso protocolli Internet, chiamate alle API (Application Programming Interfaces) o interfacce quali OLE DB.

ESP è uno strumento modulare ed estensibile e fornisce attualmente i moduli per la maggior parte dei protocolli Internet, inclusi i seguenti:

• WebDAV
• Internet Message Access Protocol versione 4rev1 (IMAP4)
• Lightweight Directory Access Protocol (LDAP)
• OLE DB
• Post Office Protocol versione 3 (POP3)
• Protocollo SMTP (Simple Mail Transfer Protocol)

È possibile scaricare ESP 2003 all'indirizzo Web https://go.microsoft.com/fwlink/?linkid=27881 (informazioni in lingua inglese).

Jetstress

Exchange 2003 è un'applicazione che richiede un uso intensivo del disco. Per funzionare correttamente, è necessario un sottosistema di dischi veloce e affidabile. Jetstress (Jetstress.exe) è uno strumento di Exchange che consente agli amministratori di verificare le prestazioni e la stabilità del sottosistema di dischi prima di distribuire i server di Exchange in un ambiente di produzione. Per ulteriori informazioni su Jetstress e sull'archiviazione back-end di Exchange, vedere Pianificazione di una soluzione di archiviazione back-end affidabile.

È possibile scaricare Jetstress all'indirizzo Web https://go.microsoft.com/fwlink/?linkid=27883 (informazioni in lingua inglese).