Informazioni sui fattori di disponibilità elevata

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2015-03-09

Quando si pianifica un'architettura di database e di server Cassette postali ad alta disponibilità, è necessario considerare le scelte di progettazione, quali:

• Verranno distribuite più copie del database?

• Quante copie del database verranno distribuite?

• Si disporrà di un'architettura che fornisce resilienza del sito?

• Che tipo di modello di resilienza verrà distribuito per il server Cassette postali?

• Quanti server Cassette postali verranno distribuiti?

• Come verranno distribuite le copie del database?

• Quale modello di backup verrà utilizzato?

• Quale architettura di archiviazione verrà utilizzata?

Microsoft Exchange Server 2010 consente di distribuire l'infrastruttura dei server Cassette postali utilizzando i server Cassette postali standalone o i server Cassette postali configurati per la resilienza delle cassette postali. I server Cassette postali configurati per la resilienza utilizzano un gruppo di disponibilità del database (DAG) con più copie del database efficientemente distribuite in tutto il gruppo DAG. Distribuendo più copie del database, è possibile:

• Progettare una soluzione che limiti il motivo più comune per l'utilizzo di un backup. Le copie del database forniscono protezione rispetto agli errori hardware, software e di datacenter.

• Aumentare le dimensioni del database fino a 2 terabyte, in quanto il meccanismo di recupero costituisce un'altra copia del database e non il ripristino da backup.

• Considerare le alternative di architettura di archiviazione a una configurazione RAID tradizionale come un JBOD (Just a Bunch of Disks), se si distribuiscono tre o più copie del database. La combinazione di JBOD e dischi meno costosi può portare a un risparmio dei costi per l'organizzazione.

Distribuendo database attivi in tutti i server che partecipano all'interno di un gruppo DAG, è possibile massimizzare l'efficienza dell'hardware.

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

Sommario

Pianificazione del numero di copie del database da distribuire

Tipi di copia del database

Resilienza del sito

Pianificazione del modello di resilienza per il server Cassette postali

Pianificazione del numero di server Cassette postali da distribuire

Pianificazione del layout di copia del database

Pianificazione dell'architettura del modello di backup

Pianificazione dell'architettura del modello di archiviazione

Per informazioni sulle attività di gestione relative all'alta disponibilità, vedere Gestione della disponibilità elevata e della resilienza del sito.

Pianificazione del numero di copie del database da distribuire

Come descritto in Informazioni sulle copie del database delle cassette postali, un membro del gruppo DAG può ospitare una copia di ogni database delle cassette postali, con un massimo di 100 database per server nell'Enterprise Edition del prodotto (nel calcolo di questo limite vanno considerate sia le copie attive che quelle passive). Ciò significa che esiste un limite di 1.600 database supportati da un gruppo DAG di 16 membri (100 copie del database per server × 16 server per gruppo DAG ÷ 1 copia per database = 1.600 database per gruppo DAG).

In una configurazione ad alta disponibilità, non esiste alcun valore per la distribuzione di una singola copia di un database, in quanto non fornisce la ridondanza dei dati. Utilizzare una formula per determinare il numero di database supportabili da uno specifico gruppo DAG. Ad esempio, se si sceglie D come numero di database distribuiti, C come numero di copie di ogni database e S come numero di server, vale quanto segue:

• D × C = numero totale di copie del database nel gruppo DAG

• (D × C) ÷ S = copie del database per server

Ad esempio, si supponga di disporre di un gruppo DAG con 6 server e 84 database delle cassette postali, con 3 copie di ogni database (notare che 6 server è un numero intero multiplo di 3 copie). Vale quanto segue:

• 84 database × 3 copie = 252 database totali

• 252 database ÷ 6 server = 42 copie del database per server

In un altro esempio, si dispone di un gruppo DAG con 4 server e 136 database delle cassette postali, con 3 copie di ogni database. Vale quanto segue:

• 136 database × 3 copie = 408 database totali

• 408 database ÷ 4 server = 102 copie del database per server

Siccome 102 è maggiore di 100, lo scenario proposto non costituisce una progettazione DAG valida.

Inizio pagina

Tipi di copia del database

Sono disponibili due tipi di copie del database:

• Copie ad alta disponibilità del database

• Copie ritardate del database

Le copie ad alta disponibilità del database indicano copie configurate con un intervallo di riesecuzione pari a zero. Come suggerito dal nome stesso, le copie ad alta disponibilità del database vengono aggiornate dal sistema, possono essere attivate automaticamente dal sistema e vengono utilizzate per fornire un'alta disponibilità al servizio e ai dati delle cassette postali.

Le copie ritardate del database indicano copie configurate per ritardare la riesecuzione del registro delle transazioni per un periodo di tempo. Le copie ritardate del database sono progettate per fornire una protezione temporizzata, che può essere utilizzata per il ripristino da danneggiamenti della partizione logica dell'archivio, da errori amministrativi (ad esempio, l'eliminazione di una cassetta postale disconnessa) e da errori di automazione (ad esempio, l'eliminazione in blocco delle cassette postali disconnesse).

In genere, le copie ritardate del database non vengono attivate a causa dell'algoritmo di selezione delle copie migliori in Active Manager. Siccome vengono distribuite per ridurre i rischi operativi, le copie ritardate del database non dovrebbero essere attivate. Se attivate e se viene inviata una richiesta di installazione, la riesecuzione del registro viene avviata, eseguendo di nuovo tutti i file di registro necessari per aggiornare il database e impostarlo su uno stato di chiusura normale, perdendo così la capacità temporizzata.

Per ulteriori informazioni sul blocco dell'attivazione a livello dei server Cassette postali o di sospensione dell'attivazione per una o più copie del database per evitare l'attivazione automatica di una copia del database (ad esempio, una copia ritardata del database), vedere Set-MailboxServer e Suspend-MailboxDatabaseCopy.

Inizio pagina

Resilienza del sito

L'ambiente può essere costituito da più datacenter. In quanto parte della progettazione di Exchange 2010, determinare se l'infrastruttura di Exchange verrà distribuita in un unico datacenter o tra due o più datacenter. I contratti di servizio (SLA) di ripristino dell'organizzazione devono definire il livello di servizio necessario a seguito di un errore del datacenter principale.

Se la distribuzione di Exchange verrà implementata tra più datacenter per supportare gli obiettivi di resilienza del sito, considerare il modello di distribuzione degli utenti da applicare. Esistono due tipi di modelli di distribuzione degli utenti, in base alla posizione della cassetta postale rispetto al datacenter:

• Modello di distribuzione attivo/passivo degli utenti

• Modello di distribuzione attivo/attivo degli utenti

Se le cassette postali degli utenti si trovano soprattutto in un unico datacenter (o se gli utenti accedono ai dati tramite un unico datacenter) ed esiste un requisito SLA per il quale gli utenti continuano ad accedere ai dati tramite il datacenter principale durante le operazioni normali, l'architettura è costituita da un modello di distribuzione attivo/passivo degli utenti.

Se le cassette postali degli utenti sono distribuite tra più datacenter ed esiste un requisito SLA per il quale gli utenti continuano ad accedere ai dati tramite il datacenter principale durante le operazioni normali, l'architettura è costituita da un modello di distribuzione attivo/attivo degli utenti.

In un modello di distribuzione attivo/passivo degli utenti, è possibile distribuire l'architettura come mostrato nella figura seguente, in cui le cassette postali attive vengono ospitate dal datacenter principale, mentre le copie del database vengono distribuite nel datacenter secondario.

Modello di distribuzione attivo/passivo degli utenti con due datacenter

L'architettura mostrata nella figura seguente potrebbe potenzialmente essere utilizzata per un modello di distribuzione attivo/attivo degli utenti.

Modello di distribuzione attivo/attivo degli utenti con due datacenter

Tuttavia, esiste un rischio con l'architettura visualizzata nella figura precedente. La rete WAN (Wide Area Network) indica un unico punto di errore per il gruppo DAG. La perdita della rete WAN comporterà la perdita del quorum per i membri DAG nel secondo datacenter. In questo esempio, il cluster di failover di Windows dispone di un totale di cinque voti (quattro membri DAG più il server di controllo) e richiede tre voti per essere disponibile in qualsiasi momento. Tre voti si trovano nel datacenter di Redmond, mentre due si trovano nel datacenter di Portland. La perdita della connessione WAN comporta l'hosting di solo due voti nel datacenter di Portland, quantità insufficiente a mantenere il quorum. Il datacenter di Redmond dispone di tre voti, quindi può mantenere il quorum e continuare a gestire le cassette postali attive (a condizione che questi tre voti siano operativi).

Per ridurre questo rischio per i modelli di distribuzione attivi/attivi degli utenti, si consiglia di distribuire due gruppi DAG, come mostrato nella figura seguente.

Due gruppi DAG per il modello di distribuzione attivo/attivo degli utenti

DAG1 ospita le cassette postali attive per il datacenter di Redmond e viene implementato come modello di distribuzione attivo/passivo degli utenti, con le copie passive del database distribuite nel datacenter di Portland. DAG2 ospita le cassette postali attive per il datacenter di Portland e viene implementato come modello di distribuzione attivo/passivo degli utenti, con le copie passive del database distribuite nel datacenter di Redmond.

Questa architettura può sopravvivere alla perdita della rete WAN:

• Nel datacenter di Redmond, i membri del server Cassette postali per DAG2 entrano in stato di errore a causa della perdita del quorum, ma i membri attivi del server Cassette postali per DAG1 rimangono operativi, consentendo la gestione degli utenti.

• Nel datacenter di Portland, i membri del server Cassette postali per DAG1 entrano in stato di errore a causa della perdita del quorum, ma i membri attivi del server Cassette postali per DAG2 rimangono operativi, consentendo la gestione degli utenti.

Per ulteriori informazioni, vedere Pianificazione della disponibilità elevata e della resilienza del sito.

Inizio pagina

Pianificazione del modello di resilienza per il server Cassette postali

Un aspetto fondamentale per la pianificazione delle capacità del server Cassette postali di Exchange 2010 è determinare il numero di copie del database che si prevede di attivare per ogni server una volta configurato per la resilienza delle cassette postali. Sono possibili diverse strutture, ma due costituiscono i modelli consigliati, come descritto nelle sezioni seguenti.

Struttura per tutte le copie del database attivate

È possibile progettare 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à dell'utente. Di solito, questa soluzione viene distribuita a coppie. Ad esempio, se si distribuiscono quattro server, una coppia è costituita dai server 1 e 2, mentre la seconda è costituita dai server 3 e 4. Inoltre, quando si progetta questo scenario, ogni server viene ridimensionato per non più del 40% delle risorse disponibili per le operazioni normali di runtime.

Dei due descritti in questo argomento, l'ultimo modello dispone di un numero maggiore di server.

Struttura per gli scenari di errore di destinazione

È possibile progettare l'architettura del server per gestire il carico attivo delle cassette postali nel caso di errore peggiore che si prevede di risolvere. Esistono molti fattori da considerare in questo modello, tra cui la resilienza del sito, l'archiviazione RAID e JBOD, le dimensioni del gruppo DAG e il numero di copie del database. Questo modello di pianificazione delle capacità prevede un equilibrio tra costi di investimento, disponibilità e caratteristiche delle prestazioni client.

Supponendo che le copie del database vengono distribuite in modo casuale e uniforme:

• Progettare un errore automatico del server con membro unico nelle configurazioni DAG di due o tre membri con due copie altamente disponibili del database per database delle cassette postali.

• Progettare un errore del server con doppio membro (attivazione manuale dopo il secondo errore) nelle configurazioni DAG di tre membri con tre copie altamente disponibili del database per database delle cassette postali.

• Progettare gli errori automatici del server con doppio membro in cui il gruppo DAG dispone di quattro o più membri e di tre o più copie altamente disponibili del database per database delle cassette postali.

Se si sceglie questo modello di pianificazione delle capacità, si consiglia vivamente di limitare il numero dei database attivabili per server, in modo da non sovraccaricare un singolo server, compromettendo 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 DAG in modo che corrisponda al numero massimo di database attivi supportati dalla distribuzione.

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

Inizio pagina

Pianificazione del numero di server Cassette postali da distribuire

Quando si determina il numero di server Cassette postali da distribuire, utilizzare un multiplo del numero di copie distribuite del database. Ad esempio, se si prevede di distribuire tre copie del database, avviare la progettazione con 3, 6, 9, 12 o 15 server.

Una volta determinato il punto di partenza per il numero di server all'interno del gruppo DAG, ridimensionare i membri DAG in modo appropriato in base al numero di cassette postali, al modello di progettazione degli errori e ad altri vincoli di progettazione che possono aumentare o ridurre il numero necessario di server Cassette postali.

Un vincolo di progettazione di cui dispongono molte organizzazioni è costituito da un numero massimo di cassette postali collocabili su un server. Ad esempio, se un'organizzazione dispone di 20.000 cassette postali e solo il 25% può essere influenzato da un evento di errore, il numero massimo di cassette postali distribuibili su un unico server è 5.000. Ciò richiede la distribuzione di un minimo di quattro server Cassette postali.

L'hardware del server e il modello di archiviazione selezionati possono anche causare un adattamento al numero di cassette postali o al numero di copie del database distribuite per server, influenzando il numero totale di server Cassette postali.

Server con più ruoli e server con ruoli standalone

In Exchange Server 2007, i ruoli dei server Accesso client e Trasporto Hub devono trovarsi su server diversi rispetto ai server Cassette postali in cluster. In Exchange 2010, i server Cassette postali in cluster non esistono più, quindi questa limitazione non viene più applicata. I ruoli dei server Accesso client e Trasporto Hub possono essere ospitati nei membri DAG, fornendo migliori opzioni di distribuzione.

Quando si distribuiscono server con più ruoli (ruoli del server Cassette postali, Accesso client e Trasporto Hub sullo stesso server), la maggior parte delle architetture viene semplificata. A differenza dei server Trasporto Edge e Messaggistica unificata, tutti i server Exchange 2010 possono essere identici. Questi server possono disporre dello stesso hardware, dello stesso processo di installazione software e delle stesse opzioni di configurazione. La coerenza tra i server può semplificare l'amministrazione dell'implementazione di Exchange.

Il server con più ruoli (in ambienti ad alta scala) fornisce un utilizzo più efficace dei server con un elevato numero di core, fornendo elevate capacità di megacicli. Ogni ruolo, se distribuito singolarmente, dispone del numero massimo consigliato di due socket compilati del processore. Quando si combinano i ruoli, il numero massimo di socket del processore consigliato è quattro. I server possono disporre di carichi di lavoro maggiori, che possono ridurre il numero complessivo di server in un'organizzazione. La distribuzione di un numero inferiore di server riduce il costo di gestione di questi server, in quanto il server con più ruoli trasforma il costo da spesa operativa ricorrente a unica spesa di capitale. Un numero di server ridotto può comportare notevoli riduzioni di energia, raffreddamento e spazio del datacenter, consentendo di ridurre ulteriormente le spese operative ricorrenti.

Anche se il concetto di più ruoli è efficace, i ruoli standalone del server possono essere ancora appropriati. Ad esempio, le distribuzioni di ruoli standalone possono essere appropriate in determinati ambienti virtualizzati o quando vengono utilizzate determinate architetture hardware (ad esempio, un'infrastruttura di Blade Server in cui non è possibile isolare l'hardware in modo appropriato).

Quando si distribuiscono i server con più ruoli, è necessario progettare in modo appropriato l'architettura dei processori e della memoria. Per quanto riguarda i processori, è necessario assicurarsi che il ruolo del server Cassette postali non consumi più del 40% dei megacicli disponibili durante la modalità di errore, lasciando il 40% per i ruoli del server Trasporto Hub e Accesso client. Per garantire la disponibilità della memoria adeguata per tutti i ruoli del server, seguire le indicazioni relative alla memoria definite in Informazioni sulla cache del database delle cassette postali.

Per ulteriori informazioni, vedere Informazioni sulle configurazioni con più ruoli del server nella pianificazione della capacità.

Inizio pagina

Pianificazione del layout di copia del database

In quanto parte della progettazione ad alta disponibilità, è necessario progettare un layout di copia bilanciato del database. Quando si pianifica il layout di copia del database, è necessario utilizzare i seguenti principi di progettazione:

• Assicurarsi di ridurre al minimo più errori di copia di uno specifico database delle cassette postali isolando ogni copia. Ad esempio, non collocare più di una copia di uno specifico database delle cassette postali all'interno dello stesso rack di server o nello stesso array di archiviazione. In caso contrario, un errore di rack o di array comporterà l'errore di più copie dello stesso database, influenzando la disponibilità del database.

• Disporre le copie del database in modo coerente e distribuito per garantire la distribuzione uniforme dei database attivi delle cassette postali dopo un errore. La somma delle preferenze di attivazione di ogni copia del database su un server specifico deve essere uguale o quasi uguale, in quanto ciò si traduce in una distribuzione approssimativamente uguale in seguito all'errore, presumendo l'integrità e l'aggiornamento della replica.

Per ulteriori informazioni, vedere Struttura di layout della copia del database.

Inizio pagina

Pianificazione dell'architettura del modello di backup

Exchange 2010 comprende diverse funzionalità e modifiche all'architettura che, se distribuite e configurate correttamente, possono fornire la protezione dei dati nativi. Perciò, non è più necessario eseguire i backup tradizionali dei dati. Utilizzare la tabella seguente per decidere se è necessario continuare a utilizzare un modello di backup tradizionale o se è possibile implementare le funzionalità di protezione dei dati nativi in Exchange 2010.

In genere, il danneggiamento logico indica uno scenario che richiede un backup temporizzato. Tuttavia, con Exchange 2010, esistono diverse opzioni disponibili che possono ridurre la necessità di un backup temporizzato:

• Con il ripristino di un unico elemento, se l'utente modifica determinate proprietà di un elemento in qualsiasi cartella delle cassette postali, una copia dell'elemento viene salvata nella cartella Elementi ripristinabili prima della scrittura della modifica nel database. Se la modifica del messaggio si traduce in una copia danneggiata, l'elemento originale può essere ripristinato.

• L'Assistente di ripristino calendario rileva e corregge le incongruenze che si verificano per gli elementi di riunione unici e ricorrenti per le cassette postali che si trovano sul server Cassette postali. In questo modo, i destinatari non perderanno gli avvisi di riunione o disporranno di informazioni affidabili sulle riunioni.

• Durante gli spostamenti delle cassette postali, il servizio di replica delle cassette postali di Microsoft Exchange rileva gli elementi danneggiati e non li sposterà nel database delle cassette postali di destinazione.

• Exchange 2010 Service Pack 1 (SP1) introduce il cmdlet New-MailboxRepairRequest, che consente di correggere i danneggiamenti relativi a cartelle di ricerca, conteggi di elementi, viste di cartelle e problemi con le cartelle principali/secondarie.

Un backup temporizzato può essere costituito da un backup tradizionale o da una copia ritardata del database: forniscono entrambi le stesse capacità. La scelta tra i due dipende dal contratto di servizio per il ripristino. Il contratto di servizio per il ripristino definisce l'obiettivo del punto di ripristino (in caso di emergenza, i dati devono essere ripristinati entro un certo periodo di tempo), oltre al periodo di conservazione dei backup. Se il contratto di servizio per il ripristino è inferiore o pari a 14 giorni, può essere utilizzata una copia ritardata del database. Se il contratto di servizio per il ripristino è superiore a 14 giorni, deve essere utilizzato un backup tradizionale. Per l'amministratore non autorizzato e per gli scenari di conformità aziendali o normativi, il backup temporizzato in genere viene conservato separatamente rispetto all'infrastruttura e al personale IT di messaggistica, determinando una soluzione di backup tradizionale.

Se si decide di mantenere un backup temporizzato, possono cambiare diversi aspetti della progettazione:

• La distribuzione delle copie ritardate del database ha ripercussioni sull'archiviazione. Deve essere assegnato ulteriore spazio ai registri delle transazioni per la copia ritardata del database a causa delle impostazioni ReplayLagTime. Inoltre, il posizionamento della copia ritardata del database può influenzare l'architettura di archiviazione. Per i dettagli, vedere "Pianificazione dell'architettura del modello di archiviazione" più avanti in questo argomento.

• La distribuzione di una soluzione di backup tradizionale ha ripercussioni sul layout del numero di unità logica (LUN), in base al tipo di soluzione del servizio Copia Shadow del volume (VSS), in quanto le soluzioni di clonazione VSS basate su hardware richiedono due numeri LUN per architettura di database.

In base all'architettura di archiviazione, l'utilizzo di una soluzione di backup tradizionale può richiedere una riduzione significativa delle dimensioni desiderate per le cassette postali degli utenti per soddisfare i contratti di servizio per il periodo di tempo relativo al backup e al ripristino.

Quando si distribuisce la protezione dei dati nativi di Exchange, nei database delle cassette postali viene abilitata la registrazione circolare. Quando si abilita la registrazione circolare, assicurarsi che nel sistema siano incorporate le capacità sufficienti, in modo da consentire la sopravvivenza della soluzione nei casi di emergenza che impediscono il troncamento del registro. Come minimo, è necessario assicurarsi che esistano almeno tre giorni di capacità per il registro delle transazioni (esclusi i requisiti della copia ritardata). Per ulteriori informazioni sul funzionamento della registrazione circolare con la replica continua, vedere Informazioni su backup, ripristino e ripristino di emergenza.

Per ulteriori informazioni sulla pianificazione dei backup, vedere:

• Informazioni sull'architettura di Exchange 2010 LUN

• Informazioni sui fattori capacità registro e database delle cassette postali

• Informazioni su Ripristino calendario

• Informazioni su elementi ripristinabili

Inizio pagina

Pianificazione dell'architettura del modello di archiviazione

Exchange 2010 fornisce flessibilità alla progettazione di archiviazione. Exchange 2010 comprende i miglioramenti alle prestazioni, all'affidabilità e all'alta disponibilità che consentono alle organizzazioni di eseguire Exchange su una serie di dispositivi di archiviazione. In base ai miglioramenti delle operazioni input/output (I/O) del disco introdotti in Exchange 2007, la versione più recente di Exchange richiede meno prestazioni di archiviazione e presenta una maggiore tolleranza degli errori di archiviazione.

Selezionare una piattaforma di archiviazione che assicuri il bilanciamento dei requisiti di capacità con quelli delle operazioni I/O, garantendo, allo stesso tempo, che la soluzione fornisca una latenza accettabile del disco e un'esperienza utente soddisfacente.

RAID o JBOD

Decidere se implementare la piattaforma di archiviazione tramite la tecnologia RAID o un approccio JBOD (presumendo che la piattaforma di archiviazione consenta le configurazioni JBOD). Dalla prospettiva di Exchange, JBOD implica la disposizione del database e dei registri associati archiviati in un unico disco. Per la distribuzione su JBOD, è necessario distribuire un minimo di tre copie altamente disponibili del database. L'utilizzo di un unico disco costituisce un unico punto di errore, perché, quando si verifica un errore del disco, si perde la copia del database che risiede nel disco. La disposizione di un minimo di tre copie del database garantisce la tolleranza di errore disponendo di altre due copie nel caso in cui si verifichi un errore di copia (o del disco). Tuttavia, il posizionamento delle tre copie altamente disponibili del database, così come l'utilizzo di copie ritardate del database, può influenzare la progettazione di archiviazione. Nella tabella seguente vengono visualizzate le linee guida per le considerazioni su RAID o JBOD.

Considerazioni su RAID o JBOD

Per la distribuzione su JBOD con i server principali del datacenter, sono necessarie tre o più copie ad alta disponibilità del database all'interno del gruppo DAG. Se si mischiano le copie ritardate sullo stesso server che ospita le copie altamente disponibili del database (ad esempio, non utilizzando i server dedicati alle copie ritardate del database), sono necessarie almeno due copie ritardate del database.

Affinché i server del datacenter secondario utilizzino JBOD, è necessario disporre di almeno due copie altamente disponibili del database nel datacenter secondario. La perdita di una copia nel datacenter secondario non comporterà la richiesta di un reseeding attraverso la rete WAN o la disposizione di un unico punto di errore nel caso in cui il datacenter secondario venga attivato. Se si mischiano le copie ritardate del database sullo stesso server che ospita le copie altamente disponibili del database (ad esempio, non utilizzando i server dedicati alle copie ritardate del database), sono necessarie almeno due copie ritardate del database.

Per i server dedicati alle copie ritardate del database, è necessario disporre di almeno due copie ritardate del database all'interno di un datacenter per utilizzare JBOD. In caso contrario, la perdita del disco comporta la perdita della copia ritardata del database, così come la perdita del meccanismo di protezione.

Per ulteriori informazioni, vedere Informazioni sulla configurazione di archiviazione.

Inizio pagina

 ©2010 Microsoft Corporation. Tutti i diritti riservati.