Informazioni sui fattori di disponibilità elevata

Ultima modifica dell'argomento: 2010-01-27

In questo argomento vengono trattati diversi fattori di elevata disponibilità che interesseranno l'architettura complessiva del server Cassette postali.

Resilienza delle cassette postali

Con Exchange Server 2010, è possibile stabilire se distribuire l'infrastruttura del server Cassette postali in un'implementazione autonoma o con la resilienza delle cassette postali. Exchange 2010 è stato riprogettato in base al concetto di resilienza delle cassette postali, in cui l'architettura è stata modificata per fornire la protezione di failover automatica a livello del database delle cassette postali invece che a livello del server.

Se si seleziona una soluzione che utilizza la resilienza delle cassette postali, si dispone di diverse opzioni in termini di architettura:

• Distribuendo più copie del database, è possibile:
  • Progettare una soluzione che limiti i motivi più comuni per l'utilizzo di un backup. Le copie del database assicurano la sicurezza contro gli errori hardware, software e datacenter.
  • Aumentare le dimensioni del database fino a 2 terabyte, in quanto il meccanismo di recupero indica un'altra copia del database e non il ripristino da backup.
  • Considerare le alternative di architettura di archiviazione come JBOD (Just a Bunch of Disks), se si distribuiscono tre o più copie del database.
• Distribuendo database attivi in tutti i server che partecipano all'interno di un gruppo di disponibilità del database, è possibile massimizzare l'efficienza dell'hardware. Per ulteriori informazioni, vedere la sezione successiva di questo argomento.

Per ulteriori informazioni, vedere Pianificazione della disponibilità elevata e della resilienza del sito e Informazioni su backup, ripristino e ripristino di emergenza.

Host delle copie del database attive e passive sullo stesso server

Un aspetto chiave per la pianificazione della capacità delle cassette postali di Exchange 2010 è determinare quante copie del database si prevede di attivare su ogni server una volta configurato per la resilienza delle cassette postali. Diverse strutture sono disponibili, ma si consigliano i seguenti modelli.

Struttura per tutte le copie del database attivate

In questo modello di pianificazione delle capacità, si progetta l'architettura del server per gestire il 100% di tutte le copie del database ospitate e attive. Ad esempio, se il server ospita 35 copie del database, si progettano il processore e la memoria per contenere tutti i 35 database diventati attivi durante il periodo di massima attività.

Dei due modelli descritti in questo argomento, quest'ultimo fornisce la migliore disponibilità, oltre alle migliori caratteristiche delle prestazioni client. Tuttavia, questo modello implica un maggiore costo di investimento server.

Struttura per gli scenari di errore di destinazione

In questo modello, si progetta l'architettura del server per gestire il carico delle cassette postali attivo nel caso di errore peggiore che si prevede di gestire. Esistono molti fattori da considerare in questo modello, tra cui la resilienza del sito, l'archiviazione RAID e JBOD, le dimensioni del gruppo di disponibilità del database e il numero delle copie del database.

Una semplice regola consiste nel progettare come segue:

• Errore di nodo unico automatico nelle configurazioni a due nodi
• Errore di nodo doppio nelle configurazioni a tre server (attivazione manuale per il secondo errore)
• Errori di nodo doppi automatici in cui il gruppo di disponibilità del database dispone di quattro o più nodi

Il numero adeguato delle copie del database viene richiesto in tutti gli scenari di cui sopra e le copie devono essere distribuite in modo casuale e uniforme.

Se si sceglie questo modello di pianificazione delle capacità, si consiglia vivamente di limitare il numero dei database attivabili per ogni server, in modo che il server non superi il numero di database attivi che è stato progettato per il servizio (e, di conseguenza, compromettere l'esperienza client).

È possibile limitare il numero di database configurando la massima impostazione di database attivi. È possibile configurare questo limite in Exchange Management Shell eseguendo: Set-MailboxServer -MaximumActiveDatabases. Configurare questo limite per ogni server del gruppo di disponibilità del database per abbinare quanti più database attivi possibili in base alle dimensioni della distribuzione. Per ulteriori informazioni, vedere Set-MailboxServer.

Questo modello di pianificazione delle capacità prevede un equilibrio tra costi di investimento, disponibilità e caratteristiche delle prestazioni client.

Per ulteriori informazioni, vedere Esempi di progettazione di gruppi di disponibilità del database.