Ripristino di emergenza per macchine virtuali nell'hub di Azure Stack

Questo articolo descrive l'architettura e le considerazioni di progettazione di una soluzione che offre un approccio ottimizzato al ripristino di emergenza dei carichi di lavoro eseguiti in macchine virtuali ospitate nell'hub di Azure Stack.

Architettura

Scaricare un file di Visio di questa architettura.

Workflow

I componenti cloud della soluzione proposta includono i servizi seguenti:

• Una sottoscrizione di Azure che ospita tutte le risorse cloud che fanno parte di questa soluzione.

• Tenant di Microsoft Entra ID associato alla sottoscrizione di Azure che fornisce l'autenticazione delle entità di sicurezza di Microsoft Entra per autorizzare l'accesso alle risorse di Azure.

• Un insieme di credenziali di Servizi di ripristino di Azure nell'area di Azure più vicina a un data center locale che ospita la distribuzione dell'hub di Azure Stack.

  Nota

  La scelta dell'area di Azure più vicina al data center locale è specifica dello scenario di esempio incluso in questo articolo. Dal punto di vista del ripristino di emergenza, è preferibile selezionare un'area di Azure più lontana dalla posizione che ospita l'ambiente di produzione. La decisione, tuttavia, può dipendere da altri fattori, ad esempio la necessità di ridurre al minimo la latenza dei feed di dati a livello di area o di soddisfare i requisiti di residenza dei dati.

• Un circuito Azure ExpressRoute che connette i data center locali all'area di Azure che ospita l'insieme di credenziali di Servizi di ripristino di Azure, configurato con peering privato e peering Microsoft. Il primo garantisce che i requisiti di latenza vengano soddisfatti dopo un failover. Lo scopo di quest'ultimo è ridurre al minimo il tempo necessario per replicare le modifiche tra i carichi di lavoro locali e il sito di failover in Azure.

• Un account Archiviazione di Azure che contiene BLOB che contengono i file VHD creati dalla replica del sistema operativo e dei volumi di dati delle macchine virtuali dell'hub di Azure Stack protette. Questi file VHD fungono da origine per i dischi gestiti delle macchine virtuali di Azure di cui viene eseguito automaticamente il provisioning dopo un failover.

• Una rete virtuale di Azure che ospita l'ambiente di ripristino di emergenza. Viene configurato in modo che rispecchi l'ambiente di rete virtuale nell'hub di Azure Stack che ospita i carichi di lavoro di produzione, inclusi componenti come servizi di bilanciamento del carico e gruppi di sicurezza di rete. Questa rete virtuale è in genere connessa alla rete virtuale dell'hub di Azure Stack tramite una connessione ExpressRoute per facilitare il ripristino a livello di carico di lavoro.

  Nota

  A volte una connessione VPN da sito a sito è sufficiente negli scenari in cui i requisiti dell'obiettivo del punto di ripristino (RPO) sono meno rigorosi.

• Una rete virtuale di Azure isolata destinata ai failover di test, configurata in modo che rispecchia l'ambiente di rete virtuale nell'hub di Azure Stack che ospita i carichi di lavoro di produzione, inclusi componenti come servizi di bilanciamento del carico e gruppi di sicurezza di rete.

I componenti locali della soluzione proposta includono i servizi seguenti:

• Un sistema integrato dell'hub di Azure Stack nel modello di distribuzione connesso. Il sistema esegue l'aggiornamento corrente (2002 a partire dal 9/20) e si trova nel data center locale del cliente.

• Una sottoscrizione dell'hub di Azure Stack e una rete virtuale, o più reti virtuali con peering, che ospita tutte le macchine virtuali locali per questa soluzione.

• Configurazione e server di elaborazione di Azure Site Recovery eseguiti in macchine virtuali di Azure Hub Stack di Windows Server 2016 o 2012 R2. I server gestiscono le comunicazioni con l'insieme di credenziali di Servizi di ripristino di Azure e il routing, l'ottimizzazione e la crittografia del traffico di replica.

  Nota

  Per impostazione predefinita, un server di configurazione ospita un singolo server di elaborazione. È possibile distribuire server di elaborazione dedicati per supportare un volume maggiore di traffico di replica.

• Macchine virtuali dell'hub di Azure Stack che devono essere protette. Eseguono versioni supportate dei sistemi operativi Windows Server, CentOS e Ubuntu.

• Site Recovery servizio di mobilità (detto anche agente di mobilità) in esecuzione in macchine virtuali protette. Tiene traccia delle modifiche apportate ai dischi locali, registra le modifiche nei log di replica e replica i log nel server di elaborazione. Il server di elaborazione li instrada all'account di archiviazione di Azure di destinazione. I log vengono usati per creare punti di ripristino per i dischi gestiti implementati usando i BLOB archiviati nell'account di archiviazione di Azure designato.

Componenti

• Microsoft Entra ID
• Rete virtuale di Azure
• Servizi di ripristino di Azure
• Azure ExpressRoute
• Archiviazione BLOB di Azure
• Hub di Azure Stack

Alternative

La soluzione consigliata descritta in questo articolo non è l'unico modo per fornire funzionalità di ripristino di emergenza per i carichi di lavoro basati su macchine virtuali dell'hub di Azure Stack. I clienti hanno altre opzioni, tra cui:

• Failover in un altro stamp dell'hub di Azure Stack. Gli utenti che devono proteggersi da un data center o da interruzioni del sito potrebbero essere in grado di usare un'altra distribuzione dell'hub di Azure Stack per implementare il provisioning del ripristino di emergenza. Con le posizioni primarie e secondarie, gli utenti possono distribuire applicazioni in una configurazione attiva/passiva in due ambienti. Per carichi di lavoro meno critici, potrebbe essere accettabile usare la capacità inutilizzata nella posizione secondaria per eseguire il ripristino su richiesta delle applicazioni dal backup. È anche possibile implementare un sito di ripristino in un altro data center, che a sua volta usa Site Recovery per effettuare il provisioning di una replica del sito di ripristino in Azure. Diversi fattori determinano se l'uso di Site Recovery con Azure funge da sito di failover è una soluzione praticabile. Questi fattori includono normative governative, criteri aziendali e requisiti di latenza.

  Nota

  A partire da luglio 2020, Site Recovery non supporta questo scenario, il che significa che l'implementazione deve usare un partner o una soluzione interna.

• Backup e ripristino. Il backup delle applicazioni e dei set di dati consente di eseguire rapidamente il ripristino da tempi di inattività dovuti al danneggiamento dei dati, alle eliminazioni accidentali o alle interruzioni localizzate. Per le applicazioni basate su macchine virtuali dell'hub di Azure Stack, è possibile usare un agente guest per proteggere i dati dell'applicazione, le configurazioni del sistema operativo e i dati archiviati nei volumi. Il backup di una macchina virtuale tramite un agente del sistema operativo guest include in genere l'acquisizione di configurazioni del sistema operativo, file, cartelle, volumi, file binari dell'applicazione e dati dell'applicazione. Il ripristino di un'applicazione da un agente richiede la ricreazione della macchina virtuale, seguita dall'installazione del sistema operativo e dell'agente guest. A questo punto, è possibile ripristinare i dati nel sistema operativo guest.

• Backup degli snapshot del disco. È possibile usare gli snapshot per acquisire una configurazione della macchina virtuale dell'hub di Azure Stack e i dischi collegati a una macchina virtuale arrestata. Questo processo richiede prodotti di backup che si integrano con le API dell'hub di Azure Stack per acquisire la configurazione della macchina virtuale e creare snapshot del disco.

  Nota

  A partire da luglio 2020, l'uso di snapshot del disco per una macchina virtuale in esecuzione non è supportato. La creazione di uno snapshot di un disco collegato a una macchina virtuale in esecuzione potrebbe compromettere le prestazioni o influire sulla disponibilità del sistema operativo o dell'applicazione nella macchina virtuale.

• Eseguire il backup e il ripristino di macchine virtuali usando una soluzione di backup esterna nello stesso data center e quindi replicare i backup in un'altra posizione. In questo modo, è possibile ripristinare le macchine virtuali dell'hub di Azure Stack nella stessa istanza dell'hub di Azure Stack o in uno diverso o in Azure.

Dettagli dello scenario

L'hub di Azure Stack include funzionalità di riparazione automatica, fornendo correzione automatica in una serie di scenari che comportano errori localizzati dei relativi componenti. Tuttavia, gli errori su larga scala, incluse le interruzioni che interessano i rack del server o le emergenze a livello di sito, richiedono considerazioni aggiuntive. Queste considerazioni devono far parte della strategia di continuità aziendale e ripristino di emergenza per i carichi di lavoro utente basati su macchine virtuali. Questa strategia deve anche tenere conto del ripristino dell'infrastruttura di Azure Stack, che è separata dal ripristino del carico di lavoro.

Le soluzioni di ripristino dei carichi di lavoro locali tradizionali sono complesse da configurare, costose e complesse da gestire e difficili da automatizzare, soprattutto quando si usa un'altra posizione locale come sito di failover. Microsoft consiglia una soluzione alternativa che si basa su una combinazione di componenti cloud e locali per offrire soluzioni resilienti, basate sulle prestazioni, altamente automatizzate e semplici per implementare, proteggere e gestire una strategia di ripristino di emergenza conveniente. L'elemento principale di questa soluzione è Site Recovery, con il sito di failover che risiede in Azure.

Potenziali casi d'uso

Site Recovery con Azure come sito di failover elimina tutti gli svantaggi indicati in precedenza. È possibile usare le relative funzionalità per proteggere server fisici e virtuali, inclusi quelli in esecuzione nelle piattaforme di virtualizzazione Microsoft Hyper-V o VMware ESXi. È anche possibile usare le stesse funzionalità per facilitare il ripristino dei carichi di lavoro eseguiti nelle macchine virtuali dell'hub di Azure Stack.

Funzionalità di base

Site Recovery è una soluzione di ripristino di emergenza che facilita la protezione dei computer fisici e virtuali fornendo due set di funzionalità:

• Replica delle modifiche apportate ai dischi del computer tra le posizioni di produzione e ripristino di emergenza
• Orchestrazione del failover e failback tra queste due posizioni

Site Recovery offre tre tipi di failover:

• Testare il failover. Questo failover consente di convalidare la configurazione di Site Recovery in un ambiente isolato, senza perdita di dati o impatto sull'ambiente di produzione.
• Failover pianificato. Questo failover offre la possibilità di avviare il ripristino di emergenza senza perdita di dati, in genere come parte del tempo di inattività pianificato.
• Failover non pianificato. Questo failover funge da ultima risorsa in caso di interruzione non pianificata che influisce sulla disponibilità del sito primario e potenzialmente comporta la perdita di dati.

Site Recovery supporta diversi scenari, ad esempio failover e failback tra due siti locali, failover e failback tra due aree di Azure e migrazione da cloud di provider di terze parti. Tuttavia, nel contesto di questo articolo, l'attenzione riguarda la replica dei dischi locali delle macchine virtuali dell'hub di Azure Stack in Archiviazione di Azure e sul failover e il failback delle macchine virtuali tra uno stack dell'hub di Azure Stack e un'area di Azure.

I dettagli dell'architettura di Site Recovery e dei relativi componenti dipendono da diversi criteri, tra cui:

• Tipi di computer da proteggere (fisici e virtuali).
• Per gli ambienti virtualizzati, il tipo di hypervisor che ospita le macchine virtuali da proteggere (Hyper-V e VMware ESXi).
• Per gli ambienti Hyper-V, l'uso di System Center Virtual Machine Manager (SCVMM) per la gestione degli host Hyper-V.

Con l'hub di Azure Stack, l'architettura corrisponde a quella applicabile ai computer fisici. Questo non è particolarmente sorprendente, perché in entrambi i casi Site Recovery non può trarre vantaggio dall'accesso diretto a un hypervisor. Al contrario, il meccanismo che tiene traccia e replica le modifiche ai dischi locali viene implementato all'interno del sistema operativo protetto.

A tale scopo, Site Recovery si basa sul servizio di mobilità di Site Recovery (detto anche agente di mobilità), che viene distribuito automaticamente in singole macchine virtuali durante la registrazione nell'ambito della protezione basata su Site Recovery. In ogni macchina virtuale protetta, l'istanza installata localmente dell'agente di mobilità monitora e inoltra continuamente le modifiche al sistema operativo e ai dischi dati al server di elaborazione. Tuttavia, per ottimizzare e gestire il flusso del traffico di replica proveniente da macchine virtuali protette, Site Recovery implementa un set aggiuntivo di componenti in esecuzione in una macchina virtuale separata, denominata server di configurazione.

Il server di configurazione coordina le comunicazioni con l'insieme di credenziali di Site Recovery e gestisce la replica dei dati. Inoltre, il server di configurazione ospita un componente denominato server di elaborazione, che funge da gateway, riceve i dati di replica, li ottimizza tramite memorizzazione nella cache e compressione, crittografandolo e infine inoltrandolo a Archiviazione di Azure. In effetti, il server di configurazione funziona come punto di integrazione tra Site Recovery e macchine virtuali protette in esecuzione nell'hub di Azure Stack. L'integrazione viene implementata distribuendo il server di configurazione e registrandolo con l'insieme di credenziali di Servizi di ripristino di Azure.

Come parte della configurazione di Site Recovery, si definisce l'ambiente di ripristino di emergenza previsto, inclusi componenti dell'infrastruttura come reti virtuali, servizi di bilanciamento del carico o gruppi di sicurezza di rete nel modo in cui rispecchia l'ambiente di produzione. La configurazione include anche criteri di replica, che determinano le funzionalità di ripristino e sono costituiti dai parametri seguenti:

• Soglia RPO. Questa impostazione rappresenta l'obiettivo del punto di ripristino desiderato che si vuole implementare e determina la frequenza in cui Site Recovery genera snapshot dei punti di ripristino coerenti con l'arresto anomalo del sistema. Il valore non influisce sulla frequenza di replica perché la replica è continua. Site Recovery genererà un avviso e, facoltativamente, una notifica tramite posta elettronica, se l'RPO effettivo corrente fornito da Site Recovery supera la soglia specificata. Site Recovery genera snapshot dei punti di ripristino coerenti con l'arresto anomalo del sistema ogni cinque minuti.

  Nota

  Uno snapshot coerente con l'arresto anomalo del sistema acquisisce i dati contenuti nel disco al momento dell'acquisizione dello snapshot. Non include il contenuto della memoria. In effetti, uno snapshot coerente con l'arresto anomalo del sistema non garantisce la coerenza dei dati per il sistema operativo o le app installate in locale.

• Conservazione del punto di ripristino. Questa impostazione rappresenta la durata (in ore) della finestra di conservazione per ogni snapshot del punto di ripristino. Le macchine virtuali protette possono essere ripristinate in qualsiasi punto di ripristino all'interno di una finestra di conservazione. Site Recovery supporta fino a 24 ore di conservazione per le macchine virtuali replicate in account Archiviazione di Azure con il livello di prestazioni Premium. È previsto un limite di conservazione di 72 ore quando si usano account Archiviazione di Azure con il livello di prestazioni standard.

• Frequenza snapshot coerenti con l'app. Questa impostazione determina la frequenza in ore in cui Site Recovery genera snapshot coerenti con l'applicazione. Uno snapshot coerente con l'app rappresenta uno snapshot temporizzato delle applicazioni in esecuzione in una macchina virtuale protetta. È previsto un limite di 12 snapshot coerenti con l'app. Per le macchine virtuali che eseguono Windows Server, Site Recovery usa il servizio Copia Shadow del volume (VSS). Site Recovery supporta anche snapshot coerenti con l'app per Linux, ma richiede l'implementazione di script personalizzati. Gli script vengono usati dall'agente di mobilità quando si applica uno snapshot coerente con l'app.

  Nota

  Per informazioni dettagliate sull'implementazione di snapshot coerenti con l'app nelle macchine virtuali dell'hub di Azure Stack che eseguono Linux, vedere Domande generali su Site Recovery.

Per ogni disco di una macchina virtuale dell'hub di Azure Stack protetta designata, i dati vengono replicati in un disco gestito corrispondente in Archiviazione di Azure. Il disco archivia la copia del disco di origine e tutti gli snapshot coerenti con l'arresto anomalo del sistema e coerenti con l'app. Come parte di un failover, si sceglie uno snapshot coerente con l'arresto anomalo del sistema o coerente con l'app che deve essere usato quando si collega il disco gestito alla macchina virtuale di Azure, che funge da replica della macchina virtuale dell'hub di Azure Stack protetta.

Durante le normali operazioni aziendali, i carichi di lavoro protetti vengono eseguiti nelle macchine virtuali dell'hub di Azure Stack, con modifiche ai dischi replicati continuamente tramite interazioni tra l'agente di mobilità, il server di elaborazione e il server di configurazione nell'account Archiviazione di Azure designato. Quando si avvia un failover di test, pianificato o non pianificato, Site Recovery effettua automaticamente il provisioning delle macchine virtuali di Azure usando le repliche di dischi delle macchine virtuali dell'hub di Azure Stack corrispondenti.

È possibile orchestrare un failover creando piani di ripristino contenenti passaggi manuali e automatizzati. Per implementare quest'ultimo, è possibile usare Automazione di Azure runbook, costituiti da script di PowerShell personalizzati, flussi di lavoro di PowerShell o script Python 2.

Dopo che il sito primario diventa nuovamente disponibile, Site Recovery supporta l'inversione della direzione della replica, consentendo di eseguire un failback con tempi di inattività ridotti al minimo e senza perdita di dati. Tuttavia, con l'hub di Azure Stack, questo approccio non è disponibile. Al contrario, per eseguire il failback, è necessario scaricare i file del disco della macchina virtuale di Azure, caricarli nell'hub di Azure Stack e collegarli a macchine virtuali nuove o esistenti.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

L'hub di Azure Stack consente di aumentare la disponibilità del carico di lavoro grazie alla resilienza intrinseca all'infrastruttura. Questa resilienza offre disponibilità elevata per le macchine virtuali dell'hub di Azure Stack protette da Site Recovery e per i componenti essenziali dell'infrastruttura di Site Recovery locale, inclusi i server di configurazione e di elaborazione.

Analogamente, è possibile usare la resilienza dei componenti basati sul cloud dell'infrastruttura di Site Recovery. Per impostazione predefinita, Servizi di ripristino di Azure è con ridondanza geografica, il che significa che la configurazione viene replicata automaticamente in un'area di Azure che fa parte di una coppia di aree predefinite. È possibile modificare le impostazioni di replica in modo che siano ridondanti in locale, se sufficienti per le esigenze di resilienza. Si noti che non è possibile modificare questa opzione se l'insieme di credenziali contiene elementi protetti. La stessa opzione di resilienza è disponibile per tutti gli account Archiviazione di Azure con il livello di prestazioni standard, anche se è possibile modificarla in qualsiasi momento.

È possibile migliorare ulteriormente il grado di resilienza progettando e implementando soluzioni che estendono l'ambito della protezione del carico di lavoro. Questo è il valore aggiunto fornito da Site Recovery. Nel contesto di Site Recovery in esecuzione nell'hub di Azure Stack, esistono due aspetti principali della disponibilità del carico di lavoro da esaminare in modo più dettagliato:

• Failover in Azure
• Failback nell'hub di Azure Stack

È necessario considerare entrambi quando si sviluppa una strategia di ripristino di emergenza guidata dagli obiettivi del punto di ripristino (RPO) e dagli obiettivi del tempo di ripristino (RTO). RTO e RPO rappresentano i requisiti di continuità stabiliti dalle singole funzioni aziendali all'interno di un'organizzazione. RPO definisce un periodo di tempo che rappresenta la perdita massima di dati accettabile in seguito a un evento imprevisto che ha interessato la disponibilità di tali dati. RTO definisce la durata massima accettabile del tempo necessario per ripristinare le funzioni aziendali in seguito a un evento imprevisto che ha interessato la disponibilità di queste funzioni.

Failover in Azure

Il failover in Azure è alla base delle considerazioni sulla disponibilità nel contesto della protezione basata su Site Recovery delle macchine virtuali dell'hub di Azure Stack. Per ottimizzare la disponibilità del carico di lavoro, la strategia di failover deve soddisfare sia la necessità di ridurre al minimo la potenziale perdita di dati (RPO) e ridurre al minimo il tempo di failover (RTO).

Per ridurre al minimo la potenziale perdita di dati, è possibile prendere in considerazione:

• Ottimizzare la velocità effettiva e ridurre al minimo la latenza del traffico di replica seguendo considerazioni sulla scalabilità e sulle prestazioni. Per altre informazioni, vedere la sezione successiva di questo articolo.
• Aumento della frequenza dei punti di ripristino coerenti con l'app per i carichi di lavoro del database (fino al massimo di un punto di ripristino all'ora). I punti di ripristino coerenti con l'app vengono creati dagli snapshot coerenti con l'app. Gli snapshot coerenti con l'app acquisisce i dati dell'app su disco e in memoria. Anche se questo approccio riduce al minimo la potenziale perdita di dati, presenta uno svantaggio principale. Gli snapshot coerenti con l'app richiedono l'uso del servizio Copia Shadow del volume in Windows o script personalizzati in Linux per uscire dalle app installate localmente. Il processo di acquisizione può compromettere le prestazioni, soprattutto se l'utilizzo delle risorse è elevato. Non è consigliabile usare bassa frequenza per gli snapshot coerenti con l'app per i carichi di lavoro non di database.

Il metodo principale per ridurre al minimo il tempo di failover prevede l'uso dei piani di ripristino di Site Recovery. Un piano di ripristino orchestra un failover tra i siti primari e secondari, definendo la sequenza in cui i server protetti eseguono il failover. È possibile personalizzare un piano aggiungendo istruzioni manuali e attività automatizzate. Il suo scopo è quello di rendere il processo coerente, accurato, ripetibile e automatizzato.

Quando si crea un piano di ripristino, si assegnano server protetti ai gruppi di ripristino ai fini del failover. Eseguire il failover dei server in ogni gruppo. In questo modo è possibile dividere il processo di failover in unità più piccole e più facili da gestire, che rappresentano set di server che possono eseguire il failover senza basarsi su dipendenze esterne.

Per ridurre al minimo il tempo di failover, come parte della creazione di un piano di ripristino, è necessario:

• Definire gruppi di macchine virtuali dell'hub di Azure Stack che devono eseguire il failover insieme.
• Definire le dipendenze tra gruppi di macchine virtuali dell'hub di Azure Stack per determinare la sequenza ottimale di un failover.
• Automatizzare le attività di failover, se possibile.
• Includere azioni manuali personalizzate, se necessario.

Si definisce un piano di ripristino e si creano gruppi di ripristino per acquisire proprietà specifiche dell'app. Si consideri ad esempio un'app tradizionale a tre livelli con un back-end basato su SQL Server, un componente middleware e un front-end Web. Quando si crea un piano di ripristino, è possibile controllare l'ordine di avvio dei server in ogni livello, con i server che eseguono istanze di SQL Server in arrivo online, seguiti da quelli nel livello middleware e aggiunti successivamente dai server che ospitano il front-end Web. Questa sequenza garantisce che l'app funzioni al momento dell'avvio dell'ultimo server. Per implementarla, è sufficiente creare un piano di ripristino con tre gruppi di ripristino, contenenti server nei rispettivi livelli.

Oltre a controllare il failover e l'ordine di avvio, è anche possibile aggiungere azioni a un piano di ripristino. In generale, esistono due tipi di azioni:

• Automatizzazione. Questa azione si basa su Automazione di Azure runbook, che implica uno dei due tipi di attività:
  • Provisioning e configurazione delle risorse di Azure, tra cui, ad esempio, la creazione di un indirizzo IP pubblico e l'associazione all'interfaccia di rete collegata a una macchina virtuale di Azure.
  • Modifica della configurazione del sistema operativo e delle applicazioni in esecuzione in una macchina virtuale di Azure di cui è stato effettuato il provisioning in seguito a un failover.
• Manuale. Questa azione non supporta l'automazione ed è inclusa in un piano di ripristino principalmente a scopo di documentazione.

Failback nell'hub di Azure Stack

Negli scenari basati su Site Recovery, il failback, se implementato correttamente, non comporta la perdita di dati. Ciò significa che l'obiettivo della strategia di failover è ridurre al minimo il tempo di failback (RTO). Tuttavia, come accennato in precedenza, quando si esegue il failback all'hub di Azure Stack, non è possibile fare affidamento sui piani di ripristino. Il failback prevede invece la sequenza di passaggi seguente:

1. Arrestare e deallocare macchine virtuali di Azure nell'ambiente di ripristino di emergenza.
2. Identificare il parametro URI di ogni disco gestito collegato alle macchine virtuali da scaricare.
3. Scaricare i file VHD (Virtual Hard Disk) identificati dai parametri URI identificati nel passaggio precedente nell'ambiente locale.
4. Caricare i file VHD nell'hub di Azure Stack.
5. Collegare i dischi rigidi virtuali caricati alle macchine virtuali dell'hub di Azure Stack nuove o esistenti.
6. Avviare le macchine virtuali dell'hub di Azure Stack.

L'approccio ottimale per ridurre al minimo il tempo di failback consiste nell'automatizzarlo.

Considerazioni specifiche del carico di lavoro

Site Recovery si integra con app e ruoli basati su Windows Server, tra cui SharePoint, Exchange, SQL Server e Dominio di Active Directory Services (AD DS). In questo modo è possibile usare le funzionalità seguenti per implementare la protezione e il ripristino a livello di app:

• Integrazione con tecnologie di replica a livello di app, ad esempio gruppi di disponibilità AlwaysOn di SQL Server, gruppi di disponibilità del database di Exchange e replica di Active Directory Domain Services
• Snapshot coerenti con l'app, per applicazioni a livello singolo o multiplo
• Libreria di automazione avanzata che fornisce script specifici dell'applicazione pronti per la produzione che possono essere scaricati e integrati con i piani di ripristino

In alternativa, è possibile usare meccanismi di replica specifici del carico di lavoro per offrire resilienza a livello di sito. Si tratta di un'opzione comunemente usata quando si implementa il ripristino di emergenza per controller di dominio di Active Directory Domain Services, SQL Server o Exchange, che supportano in modo nativo la replica. Anche se questo richiede il provisioning di macchine virtuali di Azure che ospitano questi carichi di lavoro nell'ambiente di ripristino di emergenza, aumentando il costo, offre i vantaggi seguenti:

• Riduce il tempo necessario per il failover e il failback
• Semplifica il failover a livello di carico di lavoro, in cui non è necessario il failover a livello di sito

Sicurezza

La gestione del ripristino di emergenza dei carichi di lavoro basati su macchine virtuali utente in scenari ibridi garantisce considerazioni aggiuntive sulla sicurezza. Queste considerazioni possono essere raggruppate nelle categorie seguenti:

• Crittografia dei dati in transito. Sono incluse le comunicazioni tra macchine virtuali dell'hub di Azure Stack protette, componenti locali di Site Recovery e componenti di Site Recovery basati sul cloud:

  • L'agente mobility installato nelle macchine virtuali protette comunica sempre con il server di elaborazione tramite Transport Layer Security (TLS) 1.2.
  • È possibile comunicare dal server di configurazione ad Azure e dal server di elaborazione ad Azure per usare TLS 1.1 o 1.0. Per aumentare il livello di sicurezza per la connettività ibrida, è consigliabile applicare l'uso di TLS 1.2.

  Nota

  Per informazioni dettagliate sulla configurazione della crittografia basata su TLS 1.2, vedere Impostazioni del Registro di sistema tls (Transport Layer Security) e Aggiornamento per abilitare TLS 1.1 e TLS 1.2 come protocolli sicuri predefiniti in WinHTTP in Windows

• Crittografia dei dati inattivi. Sono inclusi Archiviazione di Azure e macchine virtuali di Azure nel sito di ripristino di emergenza.

  • Archiviazione di Azure è crittografato inattivo per tutti gli account di archiviazione che usano la crittografia Advanced Encryption Standard a 256 bit ed è conforme allo standard Federal Information Processing Standard 140-2. La crittografia è abilitata automaticamente e non può essere disabilitata. Per impostazione predefinita, la crittografia usa chiavi gestite da Microsoft, ma i clienti hanno la possibilità di usare le proprie chiavi archiviate in un insieme di credenziali delle chiavi di Azure.
  • I dischi gestiti delle macchine virtuali di Azure vengono crittografati automaticamente usando la crittografia lato server dei dischi gestiti di Azure, che si applica anche ai relativi snapshot, usando chiavi di crittografia gestite dalla piattaforma.

È anche possibile applicare l'accesso limitato agli account Archiviazione di Azure che ospitano il contenuto dei dischi replicati da Site Recovery. A tale scopo, abilitare l'identità gestita per l'insieme di credenziali di Servizi di ripristino e assegnare a tale identità gestita i ruoli di controllo degli accessi in base al ruolo di Azure seguenti a livello di account Archiviazione di Azure:

• Account di archiviazione basati su Resource Manager (livello di prestazioni standard):
  • Collaboratore
  • Collaboratore dati BLOB di archiviazione
• Account di archiviazione basati su Resource Manager (livello di prestazioni Premium):
  • Collaboratore
  • Proprietario dei dati del BLOB di archiviazione

L'insieme di credenziali di Servizi di ripristino di Azure offre meccanismi che proteggono ulteriormente il contenuto, incluse le protezioni seguenti:

• Controllo degli accessi in base al ruolo di Azure. Ciò consente la delega e la separazione delle responsabilità in base al principio dei privilegi minimi. Esistono tre ruoli predefiniti correlati a Site Recovery che limitano l'accesso alle operazioni di Site Recovery:
  • Collaboratore di Site Recovery. Questo ruolo dispone di tutte le autorizzazioni necessarie per gestire le operazioni di Site Recovery in un insieme di credenziali di Servizi di ripristino di Azure. Un utente con questo ruolo, tuttavia, non può creare o eliminare l'insieme di credenziali o assegnare diritti di accesso ad altri utenti. Questo ruolo è più adatto per gli amministratori del ripristino di emergenza che possono abilitare e gestire il ripristino di emergenza per un tenant dell'hub di Azure Stack.
  • Operatore site recovery. Questo ruolo dispone delle autorizzazioni per eseguire e gestire operazioni di failover e failback. Un utente con questo ruolo non può abilitare o disabilitare la replica, creare o eliminare insiemi di credenziali, registrare una nuova infrastruttura oppure assegnare diritti di accesso ad altri utenti. Questo ruolo è più adatto per un operatore di ripristino di emergenza che può eseguire il failover delle macchine virtuali dell'hub di Azure Stack quando richiesto dai proprietari delle applicazioni e dagli amministratori IT in uno scenario di emergenza effettivo o simulato.
  • Lettore di Site Recovery. Questo ruolo dispone delle autorizzazioni per tenere traccia di tutte le operazioni di gestione di Site Recovery. Questo ruolo è più adatto per il personale IT responsabile del monitoraggio dello stato delle macchine virtuali dell'hub di Azure Stack protetto e della generazione di ticket di supporto, se necessario.
• Blocchi delle risorse di Azure. È possibile creare ed assegnare blocchi di sola lettura ed eliminazione a un insieme di credenziali di Site Recovery per ridurre il rischio di modificare o eliminare accidentalmente l'insieme di credenziali.
• Eliminazione temporanea. Lo scopo dell'eliminazione temporanea è proteggere l'insieme di credenziali e i relativi dati da eliminazioni accidentali o dannose. Con l'eliminazione temporanea, tutti i contenuti eliminati vengono conservati per 14 giorni aggiuntivi, consentendone il recupero durante tale periodo. La conservazione aggiuntiva di 14 giorni del contenuto dell'insieme di credenziali non comporta alcun costo. L'eliminazione temporanea è abilitata per impostazione predefinita.
• Protezione delle operazioni sensibili alla sicurezza. L'insieme di credenziali di Servizi di ripristino di Azure consente di abilitare un ulteriore livello di autenticazione ogni volta che viene tentata un'operazione sensibile alla sicurezza, ad esempio la disabilitazione della protezione. Questa convalida aggiuntiva consente di garantire che gli utenti autorizzati eseguano tali operazioni.
• Monitoraggio e avvisi di attività sospette. Servizi di ripristino di Azure offre monitoraggio e avvisi predefiniti degli eventi sensibili alla sicurezza correlati alle operazioni dell'insieme di credenziali.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Quando si considera il costo della soluzione di ripristino di emergenza basata su Site Recovery descritta in questo articolo, è necessario tenere conto sia dei componenti locali che basati sul cloud. Il modello di prezzi dell'hub di Azure Stack determina i prezzi dei componenti locali. Come per Azure, l'hub di Azure Stack offre una disposizione con pagamento in base al consumo, disponibile tramite contratti enterprise e il programma Cloud Solution Provider. Questa disposizione include un prezzo mensile per ogni macchina virtuale Windows Server. Se si ha la possibilità di usare licenze di Windows Server esistenti, è possibile ridurre significativamente il costo ai prezzi della macchina virtuale di base. Tuttavia, con Site Recovery, in genere sarà necessaria solo una singola macchina virtuale dell'hub di Azure Stack per tenant, necessaria per implementare il server di configurazione specifico del tenant.

Gli addebiti correlati ad Azure sono associati all'uso delle risorse seguenti:

• Servizi di ripristino di Azure. Il prezzo è determinato dal numero di istanze protette. Vale la pena notare che ogni istanza protetta non comporta addebiti per Site Recovery per i primi 31 giorni.

• Archiviazione di Azure. I prezzi riflettono una combinazione dei fattori seguenti:

  • Livello di prestazioni
  • Volume di dati archiviati
  • Volume di trasferimento dei dati in uscita
  • Quantità e tipi di operazioni eseguite (solo per il livello di prestazioni standard)
  • Ridondanza dei dati (solo per il livello di prestazioni standard)

• Azure ExpressRoute. I prezzi si basano su uno dei due modelli seguenti:

  • Dati illimitati. Questo modello include una tariffa mensile con tutti i trasferimenti di dati in ingresso e in uscita inclusi.
  • Dati a consumo. Questo modello include una tariffa mensile con tutti i trasferimenti di dati in ingresso gratuiti e i trasferimenti di dati in uscita addebitati per GB.

  Nota

  Questa valutazione non include i costi delle connessioni fisiche distribuite dai provider di connettività di terze parti.

• VM di Azure. I prezzi delle macchine virtuali di Azure riflettono una combinazione di due componenti:

  • Costo di calcolo. Le dimensioni della macchina virtuale, il tempo di attività e il modello di licenza del sistema operativo determinano il costo.
  • Costo del disco gestito. Le dimensioni del disco e il livello di prestazioni determinano il costo.

  Nota

  Vale la pena notare che l'idratazione elimina la necessità di eseguire macchine virtuali di Azure durante le normali operazioni aziendali, con carichi di lavoro in esecuzione nell'hub di Azure Stack, riducendo notevolmente i costi di calcolo delle implementazioni basate su Site Recovery, in particolare rispetto alle soluzioni di ripristino di emergenza tradizionali.

  Nota

  I prezzi delle risorse variano tra le aree di Azure.

  Nota

  Per informazioni dettagliate sui prezzi, vedere Prezzi di Azure.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

Le considerazioni principali relative alla gestibilità del ripristino di emergenza basato su Site Recovery delle macchine virtuali dell'hub di Azure Stack includono:

• Implementazione di Site Recovery nell'hub di Azure Stack
• Failover e procedure di failback
• Delega di ruoli e responsabilità
• DevOps

Implementazione di Site Recovery nell'hub di Azure Stack

Per implementare Site Recovery nell'hub di Azure Stack in un ambiente a tenant singolo di piccole e medie dimensioni, è possibile seguire il processo di provisioning manuale basato sull'interfaccia grafica dell'insieme di credenziali di Servizi di ripristino nel portale di Azure. Per le implementazioni multi-tenant, è consigliabile prendere in considerazione l'automazione di parti del processo di implementazione, perché in genere è necessario configurare una macchina virtuale del server di configurazione separata e un insieme di credenziali di Servizi di ripristino separato per ogni tenant. È anche possibile automatizzare la distribuzione dell'agente di mobilità seguendo la procedura descritta in Preparare il computer di origine per l'installazione push dell'agente di mobilità.

Failover e procedure di failback

Per semplificare la gestione del failover, è consigliabile implementare piani di ripristino per tutti i carichi di lavoro protetti. Per altre informazioni, vedere la sezione Affidabilità più indietro in questo articolo. Sono inoltre disponibili raccomandazioni per ottimizzare la gestione della procedura di failback.

Delega di ruoli e responsabilità

La pianificazione e l'implementazione del ripristino di emergenza dei carichi di lavoro basati su macchine virtuali dell'hub di Azure Stack tramite Site Recovery comportano in genere l'interazione degli stakeholder:

• Gli operatori dell'hub di Azure Stack gestiscono l'infrastruttura dell'hub di Azure Stack, assicurandosi che siano disponibili risorse di calcolo, archiviazione e rete sufficienti per implementare una soluzione di ripristino di emergenza completa e rendere queste risorse disponibili per i tenant. Collaborano anche con i proprietari di applicazioni e dati per determinare l'approccio ottimale alla distribuzione dei carichi di lavoro nell'hub di Azure Stack.
• Gli amministratori di Azure gestiscono le risorse di Azure necessarie per implementare soluzioni di ripristino di emergenza ibrido.
• Gli amministratori di Microsoft Entra gestiscono le risorse di Microsoft Entra, inclusi gli oggetti utente e gruppo usati per effettuare il provisioning, configurare e gestire le risorse di Azure.
• Il personale IT del tenant dell'hub di Azure Stack progetta, implementa e gestisce Site Recovery, incluso il failover e il failback.
• Gli utenti dell'hub di Azure Stack devono fornire requisiti RPO e RTO e inviare richieste per implementare il ripristino di emergenza per i carichi di lavoro.

Assicurarsi di avere una chiara comprensione dei ruoli e delle responsabilità attribuiti ai proprietari e agli operatori delle applicazioni nel contesto della protezione e del ripristino. Gli utenti sono responsabili della protezione delle macchine virtuali. Gli operatori sono responsabili dello stato operativo dell'infrastruttura dell'hub di Azure Stack.

DevOps

Durante la configurazione del ripristino a livello di macchina virtuale tramite Site Recovery è principalmente responsabilità delle operazioni IT, esistono alcune considerazioni specifiche di DevOps che devono essere incorporate in una strategia completa di ripristino di emergenza. L'hub di Azure Stack facilita l'implementazione dell'infrastruttura come codice (IaC), che incorpora la distribuzione automatizzata di un'ampia gamma di carichi di lavoro, tra cui applicazioni e servizi basati su macchine virtuali. È possibile usare questa funzionalità per semplificare il provisioning di scenari di ripristino di emergenza basati su Site Recovery, semplificando la configurazione iniziale in più scenari di tenant.

Ad esempio, è possibile usare gli stessi modelli di Azure Resource Manager per effettuare il provisioning di tutte le risorse di rete necessarie per gestire i carichi di lavoro basati su macchine virtuali in un timbro dell'hub di Azure Stack per l'applicazione in un'unica operazione coordinata. È possibile usare lo stesso modello per effettuare il provisioning di un set di risorse corrispondente in Azure per effettuare il provisioning di un sito di ripristino di emergenza. Per tenere conto di eventuali differenze tra i due ambienti, è sufficiente specificare valori diversi dei parametri del modello in ogni caso.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.

Quando si pianifica la distribuzione di Site Recovery nell'hub di Azure Stack, è necessario prendere in considerazione la quantità di elaborazione, archiviazione e risorse di rete allocate ai server di configurazione e di elaborazione. Potrebbe essere necessario modificare il dimensionamento stimato della macchina virtuale dell'hub di Azure Stack che ospita i componenti di Site Recovery dopo la distribuzione per soddisfare le modifiche apportate ai requisiti di elaborazione o archiviazione. Sono disponibili tre opzioni di base per regolare il ridimensionamento:

• Implementare il ridimensionamento verticale. Ciò comporta la modifica della quantità e del tipo di risorse del processore, della memoria e del disco della macchina virtuale dell'hub di Azure Stack che ospita il server di configurazione, incluso il server di elaborazione. Per stimare i requisiti delle risorse, è possibile usare le informazioni nella tabella seguente:

  Tabella 1: Requisiti di ridimensionamento del server di configurazione e elaborazione

  CPU	Memoria	Disco cache	Frequenza di modifica dei dati	Computer protetti
  8 vCPU 2 socket * 4 core a 2,5 GHz	16 GB	300 GB	500 GB o inferiore	< 100 computer
  12 vCPU 2 socket * 6 core a 2,5 GHz	18 GB	600 GB	500 GB-1 TB	Da 100 a 150 computer
  16 vCPU 2 socket * 8 core a 2,5 GHz	32 GB	1 TB	1-2 TB	150-200 computer

• Implementare il ridimensionamento orizzontale. Ciò comporta il provisioning o il deprovisioning delle macchine virtuali dell'hub di Azure Stack con il server di elaborazione installato per soddisfare le esigenze di elaborazione delle macchine virtuali dell'hub di Azure Stack protette. In generale, se è necessario ridimensionare la distribuzione a più di 200 computer di origine o si dispone di una varianza giornaliera totale di più di due terabyte (TB), sono necessari server di elaborazione aggiuntivi per gestire il traffico di replica. Per stimare il numero e la configurazione di server di elaborazione aggiuntivi, vedere Consigli sulle dimensioni per il server di elaborazione.

• Modificare i criteri di replica. Ciò comporta la modifica dei parametri dei criteri di replica, con particolare attenzione agli snapshot coerenti con l'app.

Dal punto di vista della rete, esistono diversi metodi per regolare la larghezza di banda disponibile per il traffico di replica:

• Modificare le dimensioni della macchina virtuale. Le dimensioni delle macchine virtuali dell'hub di Azure Stack determinano la larghezza di banda di rete massima. Tuttavia, è importante notare che non esistono garanzie di larghezza di banda. Le macchine virtuali possono invece usare la quantità di larghezza di banda disponibile fino al limite determinato dalle dimensioni.

• Sostituire le opzioni uplink. I sistemi hub di Azure Stack supportano una gamma di commutatori hardware, offrendo diverse opzioni di velocità di uplink. Ogni nodo del cluster dell'hub di Azure Stack ha due uplink all'inizio dei commutatori rack per la tolleranza di errore. Il sistema alloca la metà della capacità uplink per l'infrastruttura critica. Il resto è la capacità condivisa per i servizi dell'hub di Azure Stack e tutto il traffico utente. I sistemi distribuiti con velocità più veloci hanno più larghezza di banda disponibile per il traffico di replica.

  Nota

  Sebbene sia possibile separare il traffico di rete collegando una seconda scheda di rete a un server, con le macchine virtuali dell'hub di Azure Stack, tutto il traffico delle macchine virtuali verso Internet condivide lo stesso collegamento. Una seconda scheda di rete virtuale non segregerà il traffico a livello di trasporto fisico.

• Modificare la velocità effettiva della connessione di rete ad Azure. Per supportare volumi maggiori di traffico di replica, è consigliabile usare Azure ExpressRoute con il peering Microsoft per le connessioni tra reti virtuali dell'hub di Azure Stack e Archiviazione di Azure. Azure ExpressRoute estende le reti locali nel cloud Microsoft tramite una connessione privata fornita da un provider di connettività. È possibile acquistare circuiti ExpressRoute per un'ampia gamma di larghezze di banda, da 50 megabit al secondo (Mbps) a 100 gigabit al secondo.

  Nota

  Per informazioni dettagliate sull'implementazione di Azure ExpressRoute negli scenari dell'hub di Azure Stack, vedere Connettere l'hub di Azure Stack ad Azure usando Azure ExpressRoute.

• Modificare la limitazione del traffico di replica nel server di elaborazione. È possibile controllare la larghezza di banda usata dal traffico di replica nelle macchine virtuali che ospitano server di elaborazione dall'interfaccia grafica dell'agente di Servizi di ripristino di Microsoft Azure. Le funzionalità supportate includono l'impostazione dei limiti per le ore lavorative e non lavorative, con valori di larghezza di banda compresi tra 512 kilobit al secondo e 1.023 Mbps. In alternativa, è possibile applicare la stessa configurazione usando il cmdlet Di PowerShell Set-OBMachineSetting .

• Modificare la larghezza di banda di rete allocata per ogni macchina virtuale protetta nel server di elaborazione. A tale scopo, modificare il valore della voce UploadThreadsPerVM all'interno della chiave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Backup di Azure\Replication. Per impostazione predefinita, il valore è impostato su 4, ma è possibile aumentarlo a 32 se è disponibile una larghezza di banda di rete sufficiente.

Distribuire lo scenario

Prerequisiti

L'implementazione della soluzione consigliata dipende dal soddisfare i prerequisiti seguenti:

• Accesso a una sottoscrizione di Azure, con autorizzazioni sufficienti per effettuare il provisioning e gestire tutti i componenti cloud dei componenti di Site Recovery, tra cui:

  • Insieme di credenziali di Servizi di ripristino di Azure nell'area di Azure designata come sito di ripristino di emergenza per l'ambiente di produzione dell'hub di Azure Stack.
  • Un account Archiviazione di Azure che ospita il contenuto dei dischi replicati delle macchine virtuali dell'hub di Azure Stack.
  • Una rete virtuale di Azure che rappresenta l'ambiente di ripristino di emergenza a cui le macchine virtuali di Azure idratate verranno connesse dopo un failover pianificato o non pianificato.
  • Una rete virtuale isolata di Azure che rappresenta l'ambiente di test a cui le macchine virtuali di Azure idratate verranno connesse dopo un failover di test.
  • Connettività basata su Azure ExpressRoute tra l'ambiente locale, le reti virtuali di Azure e l'account di archiviazione di Azure usato per ospitare copie di file VHD con contenuto replicato da dischi di macchine virtuali dell'hub di Azure Stack protette.

• Una sottoscrizione utente dell'hub di Azure Stack. Tutte le macchine virtuali dell'hub di Azure Stack protette da un singolo server di configurazione di Site Recovery devono appartenere alla stessa sottoscrizione utente dell'hub di Azure Stack.

• Una rete virtuale dell'hub di Azure Stack. Tutte le macchine virtuali protette devono avere connettività diretta alle macchine virtuali che ospitano il componente server di elaborazione (per impostazione predefinita si tratta della macchina virtuale del server di configurazione).

• Una macchina virtuale Windows Server dell'hub di Azure Stack che ospiterà il server di configurazione e un server di elaborazione. La macchina virtuale deve appartenere alla stessa sottoscrizione e essere collegata alla stessa rete virtuale delle macchine virtuali dell'hub di Azure Stack che devono essere protette. Inoltre, la macchina virtuale deve:

  • Conformità ai requisiti hardware e software del server di configurazione di Site Recovery
  • Soddisfare la documentazione relativa ai requisiti di rete per la connettività esterna.

  Nota

  Altre considerazioni sull'archiviazione e sulle prestazioni per i server di configurazione e di elaborazione sono descritte in modo più dettagliato più avanti in questa architettura.

  • Soddisfare i requisiti di connettività interni. In particolare, le macchine virtuali dell'hub di Azure Stack da proteggere devono essere in grado di comunicare con:

    • Il server di configurazione tramite la porta TCP 443 (HTTPS) in ingresso per la gestione della replica
    • Il server di elaborazione tramite la porta TCP 9443 per recapitare i dati di replica.

    Nota

    È possibile modificare la porta usata dal server di elaborazione per la connettività esterna e interna durante l'esecuzione dell'installazione unificata di Site Recovery.

• Macchine virtuali dell'hub di Azure Stack da proteggere, eseguendo uno dei sistemi operativi supportati Per proteggere le macchine virtuali dell'hub di Azure Stack che eseguono sistemi operativi Windows Server, è necessario:

  • Creare un account di Windows con diritti amministrativi. È possibile specificare questo account quando si abilita Site Recovery in queste macchine virtuali. Il server di elaborazione usa questo account per installare il servizio di mobilità di Site Recovery. In un ambiente del gruppo di lavoro assicurarsi di disabilitare il controllo accesso utente remoto nei sistemi operativi Windows Server di destinazione impostando il valore della voce del Registro di sistema DWORD LocalAccountTokenFilterPolicy nella HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System key su 1.
  • Abilitare le regole condivisione file e stampanti e strumentazione gestione Windows nel firewall di Microsoft Defender.

• Per proteggere le macchine virtuali dell'hub di Azure Stack che eseguono sistemi operativi Linux, è necessario:

  • Creare un account utente radice. È possibile specificare questo account quando si abilita Site Recovery in queste macchine virtuali. Il server di elaborazione usa questo account per installare il servizio di mobilità di Site Recovery.
  • Installare la versione più recente di openssh, openssh-server e i pacchetti openssl.
  • Abilitare ed eseguire la porta SSH (Secure Shell) 22.
  • Abilitare il sottosistema FTP sicuro e l'autenticazione della password.

Passaggi generali per l'implementazione

A livello generale, l'implementazione del ripristino di emergenza basato su Site Recovery nell'hub di Azure Stack è costituita dalle fasi seguenti:

1. Preparare le macchine virtuali dell'hub di Azure Stack per essere protette da Site Recovery. Assicurarsi che le macchine virtuali soddisfino i prerequisiti di Site Recovery elencati nella sezione precedente.

2. Creare e configurare un insieme di credenziali di Servizi di ripristino di Azure. Configurare un insieme di credenziali di Servizi di ripristino di Azure e specificare gli elementi da replicare. I componenti e le attività di Site Recovery vengono configurati e gestiti tramite l'insieme di credenziali.

3. Configurare l'ambiente di origine della replica. Effettuare il provisioning di un server di configurazione e di elaborazione di Site Recovery installando i file binari di installazione unificata di Site Recovery e registrarlo con l'insieme di credenziali.

   Nota

   È possibile rieseguire l'installazione unificata di Site Recovery per implementare server di elaborazione aggiuntivi nelle macchine virtuali dell'hub di Azure Stack.

4. Configurare l'ambiente di destinazione della replica. Creare o selezionare un account di archiviazione di Azure esistente e una rete virtuale di Azure nell'area di Azure che ospiterà il sito di ripristino di emergenza. Durante la replica, il contenuto dei dischi per le macchine virtuali dell'hub di Azure Stack protetto viene copiato nell'account Archiviazione di Azure. Durante il failover, Site Recovery effettua automaticamente il provisioning delle macchine virtuali di Azure che fungono da repliche di macchine virtuali dell'hub di Azure Stack protette e le connette alla rete virtuale di Azure.

5. Abilitare la replica. Configurare l'impostazione di replica e abilitare la replica per le macchine virtuali dell'hub di Azure Stack. Il servizio Mobility viene installato automaticamente in ogni macchina virtuale dell'hub di Azure Stack per cui è abilitata la replica. Site Recovery avvia la replica di ogni macchina virtuale dell'hub di Azure Stack, in base alle impostazioni dei criteri definite.

6. Eseguire un failover di test. Dopo aver stabilito la replica, verificare che il failover funzioni come previsto eseguendo un failover di test.

7. Eseguire un failover pianificato o non pianificato. Dopo un failover di test riuscito, è possibile eseguire un failover pianificato o non pianificato in Azure. È possibile designare le macchine virtuali dell'hub di Azure Stack da includere nel failover.

8. Eseguire un failback. Quando si è pronti per eseguire il failback, arrestare le macchine virtuali di Azure corrispondenti alle macchine virtuali dell'hub di Azure Stack non riuscite, scaricare i file del disco nell'archiviazione locale, caricarli nell'hub di Azure Stack e collegarli a una macchina virtuale esistente o nuova.

Riepilogo

In conclusione, l'hub di Azure Stack è un'offerta unica, che differisce in molti aspetti da altre piattaforme di virtualizzazione. Di conseguenza, giustifica considerazioni speciali in relazione alla strategia di continuità aziendale per i carichi di lavoro. Usando i servizi di Azure, è possibile semplificare la progettazione e l'implementazione di questa strategia. In questo articolo di riferimento sull'architettura è stato esaminato l'uso di Microsoft Site Recovery per la protezione dei carichi di lavoro basati su vm dell'hub di Azure Stack nel modello di distribuzione connessa. Questo approccio consente ai clienti di trarre vantaggio dalla resilienza e dalla gestibilità dell'hub di Azure Stack e dalla iperscalabilità e dalla presenza globale del cloud di Azure.

È importante notare che la soluzione di ripristino di emergenza descritta qui è incentrata esclusivamente sui carichi di lavoro basati su macchine virtuali dell'hub di Azure Stack. Questa è solo parte di una strategia di continuità aziendale complessiva che deve tenere conto di altri tipi di carico di lavoro e scenari dell'hub di Azure Stack che influiscono sulla disponibilità.

Passaggi successivi

Documentazione sui prodotti:

• Informazioni su Site Recovery
• Panoramica dell'hub di Azure Stack
• Cos'è Microsoft Entra ID?
• Che cos'è l'archiviazione BLOB di Azure?
• Che cos'è Azure ExpressRoute?
• Che cos'è Rete virtuale di Azure?

Moduli di Microsoft Learn:

• Hub di Azure Stack
• Configura l'ID Microsoft Entra
• Configurare gli account di archiviazione
• Configurare le reti virtuali
• Progettare e implementare Azure ExpressRoute
• Progettare la soluzione di site recovery in Azure

Risorse correlate

• Design dell'architettura ibrida
• Eseguire il backup di file e applicazioni nell'hub di Azure Stack
• Connessioni ibride
• Condivisione file ibrida con ripristino di emergenza per i lavoratori presso filiali locali e remote