Affidabilità in Azure Site Recovery

Azure Site Recovery è un servizio di replica e failover gestito per le macchine virtuali che mantiene disponibili i carichi di lavoro durante le interruzioni. Replica continuamente i carichi di lavoro dai siti primari alle posizioni secondarie e limita la perdita e il tempo di inattività dei dati. Durante la manutenzione pianificata o interruzioni impreviste, gestisce il failover e il failback. Questo servizio supporta il ripristino di emergenza per gli ambienti locali e le macchine virtuali di Azure, che consentono alle organizzazioni di mantenere la continuità aziendale.

Quando si usa Azure, reliability è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere Site Recovery resiliente a varie potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità e interruzioni dell'area. Vengono inoltre evidenziate le informazioni chiave sul contratto di servizio di Site Recovery.

Annotazioni

Questo articolo descrive come il servizio Site Recovery è resiliente o come renderlo resiliente a vari problemi. Non spiega come usare Site Recovery per proteggere le macchine virtuali o altri asset. Per altre informazioni, vedere Informazioni su Site Recovery.

Raccomandazioni per la distribuzione di produzione per l'affidabilità

Quando si usa Site Recovery con carichi di lavoro di produzione, è consigliabile eseguire queste azioni:

  • Distribuire l'insieme di credenziali di Servizi di ripristino nell'area di destinazione per la replica.

  • Per il ripristino di emergenza da Azure ad Azure, utilizzare la funzionalità di Site Recovery elevato tasso di cambiamento per le macchine virtuali con un'elevata variabilità di dati. Il supporto di varianza elevata migliora l'obiettivo del punto di ripristino (RPO) e abilita la replica per molti carichi di lavoro di database su larga scala.

  • Per il ripristino di emergenza da Azure a Azure, configurare l'account di archiviazione della cache per l'uso dell'archiviazione con ridondanza di zona.

  • Eseguire regolarmente i failover di test come parte delle esercitazioni di disaster recovery. Eseguire esercitazioni sul ripristino di emergenza ogni trimestre o semestralmente per verificare che i processi di replica e failover siano integri.

  • Usare prenotazioni di capacità su richiesta per garantire la disponibilità delle risorse di calcolo nella regione di destinazione per il failover.

  • Abilitare gli aggiornamenti automatici per gli agenti di mobilità.

  • Monitorare l'integrità della replica e configurare gli avvisi in modo da ricevere una notifica in caso di problemi.

Panoramica dell'architettura di affidabilità

Quando si usa Site Recovery, si definisce un'origine e una destinazione che rappresentano le macchine virtuali replicate:

  • L'origine può essere una macchina virtuale di Azure o una macchina virtuale o un server da un'altra origine supportata, inclusi server fisici locali, macchine virtuali VMware e Hyper-V macchine virtuali.

  • Il target è sempre una macchina virtuale Azure. Per la replica di macchine virtuali da Azure a Azure, la destinazione può essere un'area o una zona di disponibilità diversa dalla macchina virtuale di origine.

L'utente è responsabile della distribuzione e della configurazione delle risorse e delle impostazioni correlate, tra cui:

  • Recovery Services vault, che Site Recovery usa per archiviare le impostazioni di configurazione della replica. Il vault non archivia i dati replicati. La configurazione della ridondanza dell'insieme di archiviazione non è importante per Site Recovery, ma è importante se si usa lo stesso insieme di archiviazione per Azure Backup.

    Un archivio può includere una configurazione extra, ad esempio:

    • Criteri di replica che configurano la frequenza di snapshot e la lunghezza di conservazione.

    • Un piano di ripristino, che coordina l'ordine di failover dei computer e può includere script e azioni manuali. I piani di ripristino sono particolarmente utili per i carichi di lavoro con più livelli, ad esempio livelli di applicazione e database, che devono eseguire il failover in un ordine specifico.

  • Per la replica da Azure a Azure, un account di archiviazione cache che archivia una copia dei dati di origine nella propria area prima che venga replicata nella destinazione. La configurazione di ridondanza dell'account di archiviazione della cache può influire sull'affidabilità durante un'interruzione della zona di disponibilità.

Diagramma che mostra la relazione tra la cassetta delle credenziali dei Servizi di Ripristino, l'account di archiviazione della cache, l'origine e la destinazione in Site Recovery.

Annotazioni

Questa guida è incentrata sull'affidabilità dei componenti basati su Azure di Site Recovery e sulla relazione di replica. Se si replicano dati o macchine virtuali da un ambiente locale o da un altro provider di servizi cloud, prendere in considerazione l'affidabilità dei componenti all'esterno di Azure.

Per altre informazioni sui componenti distribuiti, vedere gli articoli seguenti:

Il servizio di base Site Recovery viene eseguito nell'infrastruttura gestita da Microsoft. Questo articolo fa riferimento a questi componenti collettivamente come servizio di Site Recovery di base.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Site Recovery gestisce automaticamente gli errori temporanei che si verificano durante il processo di replica ritentando le operazioni. Non è necessario configurare la gestione degli errori temporanei per Site Recovery.

Resilienza ai guasti delle zone di disponibilità

Zone di disponibilità sono gruppi fisicamente separati di data center all'interno di un'area Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

Per comprendere il comportamento della replica di Site Recovery durante gli errori della zona di disponibilità, è necessario considerare i componenti del servizio seguenti:

  • Servizio Core Site Recovery: Il servizio Core Site Recovery è progettato per essere resiliente agli errori della zona di disponibilità nelle aree supportate. I componenti interni del servizio supportano automaticamente la ridondanza della zona senza alcuna configurazione del cliente necessaria.

  • Vault di Servizi di ripristino: Il vault memorizza i dati di configurazione. Nelle aree in cui Site Recovery supporta la resilienza zonale, anche i dati della configurazione nell'insieme sono a loro volta resilienti.

  • Account di archiviazione della cache: Per la replica da Azure ad Azure, sei responsabile di garantire la ridondanza della zona dell'account di archiviazione della cache mediante il deployment utilizzando il livello ZRS.

    Se si usa il livello di replica di Archiviazione di Azure con ridondanza locale per l'account di archiviazione della cache e una zona ha esito negativo, Site Recovery potrebbe non replicare i dati modificati di recente nella destinazione.

Annotazioni

Site Recovery consente di eseguire il failover tra macchine virtuali in zone di disponibilità diverse. Per ulteriori informazioni, vedere Abilitare il disaster recovery delle macchine virtuali di Azure tra le zone di disponibilità.

Requisiti

Supporto per l'area:

  • Servizio Core Site Recovery e insiemi di credenziali di Servizi di ripristino: Site Recovery è resiliente nella zona nelle aree seguenti.

    Americhe Europa Medio Oriente Asia Pacifico
    Cile centrale Austria orientale Israel Central Indonesia centrale
    Messico centrale Italia settentrionale Japan West
    Stati Uniti occidentali 3 Poland Central Malesia occidentale
    Spain Central Nuova Zelanda settentrionale

    Site Recovery distribuisce il supporto per le zone di disponibilità in tutte le aree abilitate per la zona di disponibilità. Nelle aree non elencate nella tabella precedente come resilienti alla zona, gli errori di zona potrebbero influire sulle operazioni.

  • Account di archiviazione della cache: È possibile distribuire un account di archiviazione ZRS in tutte le zone di disponibilità abilitate.

Costo

Site Recovery viene fatturato in base al numero di istanze di macchina virtuale protette, indipendentemente dalla configurazione della zona di disponibilità. Per altre informazioni, vedere Prezzi di Site Recovery.

Configurare il supporto delle zone di disponibilità

  • Core Site Recovery service: Non è possibile configurare la resilienza della zona nel servizio di base Site Recovery. Microsoft offre resilienza della zona nelle aree supportate.

    Se Microsoft abilita la resilienza della zona in un'area in un secondo momento, le risorse di Site Recovery traggono automaticamente vantaggio dalla resilienza della zona. Non è necessario eseguire alcuna azione.

  • Insieme di credenziali di Servizi di ripristino: Gli insiemi di credenziali di Servizi di ripristino hanno un'impostazione di ridondanza, ma Site Recovery non usa la configurazione di ridondanza dell'insieme di credenziali. Non è necessario configurare il vault per la ridondanza di zona quando si usa Site Recovery.

  • Account di archiviazione cache: Quando si usa la replica da Azure a Azure, si è responsabili della creazione dell'account di archiviazione della cache e per la configurazione con il livello di ridondanza appropriato. Per renderla ridondante per la zona, configurarla per il tipo di replica ZRS. Per altre informazioni, vedere Reliability in Azure Blob Storage.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando si usa Site Recovery in un'area che supporta le Zone di Disponibilità per il servizio principale, l'account di archiviazione della cache è configurato per l'uso con ZRS, e tutte le zone di disponibilità sono operative.

  • Operazione tra zone: Il processo di replica può usare l'infrastruttura in più zone di disponibilità per attivare ed eseguire processi di replica. Il servizio gestisce questa infrastruttura in modo trasparente.

  • Replicazione dei dati tra zone: Site Recovery e Archiviazione gestiscono la replicazione dei dati delle zone.

    • Configurazione di Site Recovery: Site Recovery replica i dati di configurazione tra zone anche se si configura la cassetta di sicurezza per l'uso di LRS.

    • Account di archiviazione della cache: Se si configura l'account di archiviazione della cache per utilizzare ZRS (Zona Redundancy Storage), l'archiviazione replica sincronicamente i dati memorizzati nella cache tra le zone.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando si usa Site Recovery in un'area con supporto della zona di disponibilità per il servizio principale, l'account di archiviazione della cache è configurato per l'uso di ZRS e si verifica un'interruzione della zona di disponibilità.

Annotazioni

Se la zona non riuscita contiene la macchina virtuale di origine, si è responsabili dell'attivazione del failover nella destinazione. Per ulteriori informazioni, vedere gli articoli seguenti:

  • Rilevamento e risposta: La piattaforma Site Recovery rileva automaticamente gli errori in una zona di disponibilità e avvia una risposta. Non è necessario avviare manualmente un failover di zona per il servizio Core Site Recovery. Tuttavia, se l'interruzione della zona influisce sulla macchina virtuale di origine, potrebbe essere necessario avviare il failover della macchina virtuale.
  • Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. Tuttavia, è possibile usare Azure Service Health per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità del servizio Servizi per segnalare eventuali problemi.

  • Richieste attive: L'effetto sui processi di replica attivi dipende dal tipo di replica:

    • Replica da zona a zona e da area a area di macchine virtuali Azure: Se l'istanza di origine o di destinazione si trova nella zona non riuscita, la replica viene sospesa fino a quando entrambe le istanze non sono nuovamente disponibili.

      Se la zona non riuscita non contiene la macchina virtuale di origine o di destinazione e l'account di archiviazione della cache è stato configurato per l'uso dello storage a ridondanza di zona (ZRS), la replica continua a essere eseguita.

    • On-premises per Azure: Se l'istanza di destinazione si trova nella zona non riuscita, la replica viene sospesa fino a quando l'istanza non sarà nuovamente disponibile.

      Se la zona non riuscita non contiene la macchina virtuale di destinazione, la replica continua a essere eseguita.

  • Perdita di dati prevista: Non è prevista alcuna perdita di dati durante un errore di zona.

  • Tempo di inattività previsto: Se la zona non riuscita contiene la macchina virtuale di origine o di destinazione, la replica viene sospesa fino a quando entrambe le istanze non saranno nuovamente disponibili.

  • Ridistribuzione: Site Recovery e Archiviazione si adattano automaticamente agli errori di zona:

    • Servizio Core Site Recovery: Il servizio Di base di Site Recovery usa automaticamente l'infrastruttura nelle zone di disponibilità integre per eseguire la replica. Non è necessario eseguire alcuna azione.

    • Account di archiviazione della cache: L'archiviazione instrada automaticamente le richieste di dati della cache alle zone integre.

Ripristino della zona

Quando la zona di disponibilità interessata viene ripristinata, Site Recovery riprende automaticamente i processi di replica sospesi durante l'interruzione della zona.

L'utente è responsabile di avviare il failback per i server o le macchine virtuali su cui è stato eseguito il failover durante l'interruzione della zona. Per ulteriori informazioni, vedere gli articoli seguenti:

Verifica dei guasti di zona

La piattaforma Site Recovery gestisce la resilienza della zona per i componenti interni. Questa funzionalità è completamente gestita, quindi non è necessario avviare o convalidare i processi di errore della zona di disponibilità.

È importante eseguire normali esercitazioni sul ripristino di emergenza, che devono testare il failover della macchina virtuale e le procedure di risposta complessive. Progettate le vostre esercitazioni sul ripristino di emergenza per evitare effetti sull'ambiente di produzione. Per ulteriori informazioni, vedere gli articoli seguenti:

Resilienza agli errori a livello di area

Per la replica da Azure ad Azure, Site Recovery offre resilienza ai guasti regionali abilitando il failover delle macchine virtuali in un'area di destinazione sana. Per altre informazioni, vedere Replicate Azure VM in un'altra area Azure.

Considerazioni

  • Area del vault: Si crea un vault dei Servizi di ripristino in un'area di Azure specifica selezionata. La regione del vault è importante. La replica continua durante un'interruzione nella regione del vault. Tuttavia, non è possibile eseguire operazioni di gestione di Site Recovery, tra cui failover e failback, fino a quando l'area non viene ripristinata.

    La distribuzione del vault nella regione di destinazione assicura che le operazioni di failover e ripristino siano disponibili in caso di interruzione nella regione di origine. Impedisce inoltre che un'interruzione in una terza area influisca sulle operazioni di failover e ripristino.

    Annotazioni

    Se la cassaforte si trova nella regione che si utilizza abitualmente come regione di destinazione, allora, dopo il failover e la riattivazione della replica, quella regione diventa la nuova regione sorgente. Se l'area successivamente presenta un problema, potrebbe non essere possibile eseguire il failback fino a quando entrambe le aree non sono integre.

  • Prenotazioni di capacità: Si è responsabili della verifica che l'area di destinazione supporti i tipi di macchina virtuale necessari e che abbia capacità disponibile per il carico di lavoro. È consigliabile usare prenotazioni di capacità su richiesta per assicurarsi che le risorse di calcolo siano disponibili per il carico di lavoro in caso di failover.

Configurare il supporto per più aree

  • Insieme di credenziali di Servizi di ripristino: È necessario selezionare l'area dell'insieme di credenziali. Per maggiori informazioni, consultare Considerazioni.

    Le casseforti dei Servizi di ripristino hanno un'impostazione di ridondanza, ma Site Recovery non utilizza la configurazione di ridondanza della cassaforte. Non è necessario configurare l'insieme di credenziali per la ridondanza geografica quando si usa Site Recovery.

  • Account di archiviazione della cache: L'account di archiviazione della cache viene usato solo come percorso temporaneo per i dati prima della replica, quindi non è consigliabile configurarlo per l'uso dell'archiviazione con ridondanza geografica.

Comportamento durante un errore di area

Il comportamento specifico del servizio principale Site Recovery durante un errore dell'area dipende dall'area in cui si verifica l'errore:

  • Errore nell'area di origine: Per la replica da Azure ad Azure, è possibile attivare un failover quando l'area di origine non è disponibile.

    Poiché l'area di origine non è disponibile, la replica si arresta fino a quando la macchina virtuale nell'area di origine non è integra.

    Diagramma che mostra il comportamento quando l'area di origine ha esito negativo. L'origine non è disponibile e la replica si arresta fino al ripristino dell'area di origine.

  • Errore nell'area di destinazione: Poiché l'area di destinazione non è disponibile, la replica si arresta e non è possibile eseguire il failover verso la destinazione fino a quando l'area non è operativa.

    Diagramma che mostra il comportamento quando l'area di destinazione ha esito negativo. La replica si arresta e il failover non è disponibile fino a quando l'area di destinazione non viene ripristinata.

  • Errore nell'area che contiene il vault: Se si distribuisce il vault in un'area terza (non nell'area di origine o di destinazione) e si verifica un errore, Site Recovery continua a replicare i dati. Tuttavia, non è possibile avviare alcuna operazione, incluso il failover o il failback, fino a quando la cassaforte non è integra.

    Diagramma che mostra il comportamento quando la regione del vault ha un guasto. La replica continua, ma le operazioni di failover e failback non sono disponibili fino a quando la regione del vault non viene ripristinata.

Ripristino della regione

L'utente è responsabile di avviare il failback per i server o le macchine virtuali di cui è stato effettuato il failover durante un'interruzione regionale. Per ulteriori informazioni, vedere gli articoli seguenti:

Testare gli errori dell'area

È importante eseguire normali esercitazioni sul ripristino di emergenza per testare il failover della macchina virtuale e le procedure di risposta complessive. Progettare le esercitazioni sul ripristino di emergenza per evitare l'impatto sull'ambiente di produzione. Per ulteriori informazioni, vedere gli articoli seguenti:

Resilienza ai problemi di configurazione e replica

Una soluzione di ripristino di emergenza è affidabile solo quando si sa che funziona prima che si verifichi un'emergenza. Monitorare Site Recovery per rilevare problemi, ad esempio errori di configurazione o problemi di integrità della replica della macchina virtuale. Per altre informazioni, vedere Monitorare Site Recovery.

Si consiglia di configurare gli avvisi di Monitoraggio di Azure per essere informati sui problemi di integrità della replica. Per altre informazioni, vedere Avvisi predefiniti di Monitoraggio di Azure per Site Recovery.

Resilienza alla manutenzione del servizio

Azure gestisce automaticamente gli aggiornamenti e la manutenzione per il servizio di base Site Recovery. Le operazioni di manutenzione non richiedono tempi di inattività e non interrompono la replica delle macchine virtuali e dei server.

Tuttavia, l'utente è responsabile dell'applicazione degli aggiornamenti ai componenti di Site Recovery nelle macchine virtuali e nei server, incluso l'agente di mobilità quando necessario.

Importante

È consigliabile abilitare gli aggiornamenti automatici per gli agenti. Se la versione dell'agente supera di più di quattro versioni, la replica viene disattivata e la recuperabilità del carico di lavoro è a rischio.

Per altre informazioni, vedere aggiornamenti di Service in Site Recovery.

Contratto di servizio

Il contratto di servizio (SLA) per Azure servizi descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per ottenere tale aspettativa di disponibilità. Per ulteriori informazioni, vedere gli accordi sul livello di servizio per i servizi online.

Per Site Recovery, i contratti di servizio separati coprono:

  • Disponibilità del servizio, il che significa che Site Recovery è disponibile per eseguire il failover di istanze protette. Un'istanza protetta è una macchina virtuale o un server fisico che esegue la replica in una posizione secondaria. Per essere idoneo per questo contratto di servizio, è necessario ripetere i tentativi di failover non riusciti ogni 30 minuti.

  • Obiettivo del tempo di ripristino (RTO), ovvero il tempo trascorso dal momento in cui si attiva un failover (o gli script lo attivano) a quando viene eseguita la macchina virtuale di destinazione. Questa volta esclude le azioni manuali o l'esecuzione di script.

Il contratto di servizio fornisce crediti di servizio solo quando l'area secondaria ha una capacità di calcolo sufficiente.

Contenuti correlati

  • Last updated on