Condividi tramite

Proteggere le macchine virtuali distribuite nell'hub di Azure Stack

  • Articolo

Usare questo articolo come guida per sviluppare una strategia di protezione dei dati e ripristino di emergenza per le macchine virtuali IaaS distribuite dall'utente distribuite nell'hub di Azure Stack.

Per proteggersi da perdite di dati e tempi di inattività prolungati, implementare un piano di ripristino di backup o di ripristino di emergenza per le applicazioni utente e i relativi dati. Ogni applicazione deve essere valutata come parte della strategia completa di continuità aziendale e ripristino di emergenza (BC/DR) dell'organizzazione.

Considerazioni sulla protezione delle macchine virtuali IaaS

Ruoli e responsabilità

Prima di tutto, 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 di mantenere online e integro l'hub di Azure Stack. L'hub di Azure Stack include un servizio che esegue il backup dei dati del servizio interno dai servizi di infrastruttura e non include dati utente, incluse macchine virtuali create dall'utente, account di archiviazione con dati utente o applicazione o database utente.

Proprietario/architetto dell'applicazione Operatore dell'hub di Azure Stack
- Allineare l'architettura dell'applicazione ai principi di progettazione del cloud.
- Modernizzare le applicazioni tradizionali in base alle esigenze per prepararle per l'ambiente cloud.
- Definire RTO e RPO accettabili per l'applicazione.
- Identificare le risorse dell'applicazione e i repository di dati che devono essere protetti.
- Implementare un metodo di recupero dei dati e dell'applicazione che meglio si allinea all'architettura dell'applicazione e ai requisiti dei clienti.		 - Identificare gli obiettivi di continuità aziendale e ripristino di emergenza dell'organizzazione.
- Distribuire istanze sufficienti dell'hub di Azure Stack per soddisfare gli obiettivi bc/dr dell'organizzazione.
- Progettare e gestire l'infrastruttura di protezione dei dati/applicazione.
- Fornire soluzioni gestite o accesso self-service ai servizi di protezione.
- Collaborare con proprietari/architetti di applicazioni per comprendere la progettazione delle applicazioni e consigliare strategie di protezione.
- Abilitare il backup dell'infrastruttura per la correzione del servizio e il ripristino cloud.

Combinazioni di origine/destinazione

Gli utenti che devono proteggersi da un data center o da un'interruzione del sito possono usare un altro hub di Azure Stack o Azure per offrire disponibilità elevata o ripristino rapido. Con la posizione primaria e secondaria, gli utenti possono distribuire applicazioni in una configurazione attiva/attiva o attiva/passiva in due ambienti. Per carichi di lavoro meno critici, gli utenti possono usare la capacità nella posizione secondaria per eseguire il ripristino su richiesta delle applicazioni dal backup.

Uno o più cloud dell'hub di Azure Stack possono essere distribuiti in un data center. Per sopravvivere a un'emergenza irreversibile, la distribuzione di almeno un cloud dell'hub di Azure Stack in un data center diverso garantisce che sia possibile eseguire il failover dei carichi di lavoro e ridurre al minimo i tempi di inattività non pianificati. Se si ha un solo hub di Azure Stack, è consigliabile usare il cloud pubblico di Azure come cloud di ripristino. La determinazione della posizione in cui l'applicazione può essere eseguita sarà determinata dalle normative governative, dai criteri aziendali e dai rigorosi requisiti di latenza. È possibile determinare la posizione di ripristino appropriata per ogni applicazione. Ad esempio, è possibile avere applicazioni in una sottoscrizione che esegue il backup dei dati in un altro data center e in un'altra sottoscrizione, replicando i dati nel cloud pubblico di Azure.

Obiettivi di ripristino delle applicazioni

I proprietari delle applicazioni sono principalmente responsabili della determinazione della quantità di tempo di inattività e perdita di dati che l'applicazione e l'organizzazione possono tollerare. Quantificando tempi di inattività accettabili e perdita di dati accettabili, è possibile creare un piano di ripristino che riduce al minimo l'impatto di un'emergenza nell'organizzazione. Per ogni applicazione, tenere presente quanto segue:

  • Obiettivo del tempo di ripristino (RTO)
    RTO è il tempo massimo accettabile per cui un'app non può essere disponibile dopo un evento imprevisto. Ad esempio, un RTO di 90 minuti significa che è necessario essere in grado di ripristinare l'app in uno stato di esecuzione entro 90 minuti dall'inizio di un'emergenza. Se si dispone di un RTO basso, è possibile mantenere una seconda distribuzione continuamente in esecuzione in standby per proteggersi da un'interruzione a livello di area.
  • Obiettivo del punto di ripristino (RPO)
    Per obiettivo del punto di ripristino (RPO) si intende la durata massima di perdita dei dati accettabile durante un'emergenza. Ad esempio, se si archiviano dati in un singolo database, di cui viene eseguito il backup orario e non dispone di alcuna replica in altri database, è possibile perdere fino a un'ora di dati.

Un'altra metrica è il tempo medio di ripristino (MTTR), ovvero il tempo medio necessario per ripristinare l'applicazione dopo un errore. MTTR è un valore empirico per un sistema. Se mttr supera l'obiettivo RTO, un errore nel sistema causa un'interruzione aziendale inaccettabile perché non sarà possibile ripristinare il sistema all'interno dell'RTO definito.

Opzioni di protezione

Backup-restore

Il backup delle applicazioni e dei set di dati consente di eseguire rapidamente il ripristino da tempi di inattività dovuti a danneggiamento dei dati, eliminazioni accidentali o emergenze. Per le applicazioni basate su macchine virtuali IaaS è possibile usare un agente guest per proteggere i dati dell'applicazione, la configurazione del sistema operativo e i dati archiviati nei volumi.

Eseguire il backup con l'agente guest

Il backup di una macchina virtuale tramite un agente del sistema operativo guest include in genere l'acquisizione di configurazione del sistema operativo, file/cartelle, dischi, file binari dell'applicazione o dati dell'applicazione.

Il ripristino di un'applicazione da un agente richiede la ricreazione manuale della macchina virtuale, l'installazione del sistema operativo e l'installazione dell'agente guest. A questo punto, i dati possono essere ripristinati nel sistema operativo guest o direttamente nell'applicazione.

Eseguire il backup usando lo snapshot del disco per le macchine virtuali arrestate

I prodotti di backup possono proteggere la configurazione e i dischi delle macchine virtuali IaaS collegati a una macchina virtuale arrestata. Usare i 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. Se è possibile un tempo di inattività pianificato per l'applicazione, assicurarsi che la macchina virtuale sia in stato arrestato prima di avviare il flusso di lavoro di backup.

Backup con snapshot del disco per l'esecuzione di macchine virtuali

Importante

L'uso degli snapshot del disco dal portale non è attualmente supportato per la macchina virtuale in uno stato di esecuzione. La creazione di uno snapshot di un disco collegato a una macchina virtuale in esecuzione può compromettere le prestazioni o influire sulla disponibilità del sistema operativo o dell'applicazione nella macchina virtuale. È consigliabile usare una soluzione fornitore di backup che si integra con la funzionalità snapshot incrementale rp di archiviazione o un agente guest per proteggere l'applicazione se il tempo di inattività pianificato non è un'opzione.

Macchine virtuali in un set di scalabilità o in un set di disponibilità

Le macchine virtuali in un set di scalabilità o in un gruppo di disponibilità considerate risorse temporanee non devono essere sottoposte a backup a livello di macchina virtuale, soprattutto se l'applicazione è senza stato. Per le applicazioni con stato distribuite in un set di scalabilità o in un set di disponibilità, è consigliabile proteggere i dati dell'applicazione, ad esempio un database o un volume in un pool di archiviazione.

Replica/failover manuale

Per le applicazioni che richiedono una perdita minima di dati o tempi di inattività minimi, la replica dei dati può essere abilitata a livello di sistema operativo guest o applicazione per replicare i dati in un'altra posizione. Alcune applicazioni, ad esempio Microsoft SQL Server, supportano in modo nativo la replica. Se l'applicazione non supporta la replica, è possibile usare il software nel sistema operativo guest per replicare i dischi o una soluzione partner che viene installata come agente nel sistema operativo guest.

Con questo approccio, l'applicazione viene distribuita in un cloud e i dati vengono replicati nell'altro cloud locale o in Azure. Quando viene attivato un failover, l'applicazione nella destinazione deve essere avviata e collegata ai dati replicati prima di poter avviare le richieste di manutenzione.

Disponibilità elevata/failover automatico

Per le applicazioni senza stato che possono tollerare solo pochi secondi o minuti di inattività, considerare una configurazione a disponibilità elevata. Le applicazioni a disponibilità elevata sono progettate per essere distribuite in più posizioni in una topologia attiva/attiva in cui tutte le istanze possono gestire le richieste. Per gli errori hardware locali, l'infrastruttura dell'hub di Azure Stack implementa la disponibilità elevata nella rete fisica usando due commutatori top di rack. Per gli errori a livello di calcolo, l'hub di Azure Stack usa più nodi in un'unità di scala e eseguirà automaticamente il failover di una macchina virtuale. A livello di macchina virtuale, è possibile usare set di scalabilità o macchine virtuali nel set di disponibilità per assicurarsi che gli errori del nodo non arrestino l'applicazione. La stessa applicazione deve essere distribuita in un percorso secondario nella stessa configurazione. Per attivare/attivare l'applicazione, è possibile usare un servizio di bilanciamento del carico o un DNS per indirizzare le richieste a tutte le istanze disponibili.

Nessun ripristino

Alcune app nell'ambiente potrebbero non avere bisogno di protezione da tempi di inattività non pianificati o perdite di dati. Ad esempio, le macchine virtuali usate per lo sviluppo e il test in genere non devono essere ripristinate. È la decisione di eseguire senza protezione per un'applicazione o un set di dati.

Considerazioni importanti per la distribuzione dell'hub di Azure Stack:

Recommendation Commenti
Eseguire il backup o il ripristino di macchine virtuali in una destinazione di backup esterna già distribuita nel data center Consigliato Sfruttare le competenze operative e dell'infrastruttura di backup esistenti. Assicurarsi di ridimensionare l'infrastruttura di backup in modo che sia pronta per proteggere le istanze di vm aggiuntive. Assicurarsi che l'infrastruttura di backup non si trova in prossimità dell'origine. È possibile ripristinare le macchine virtuali nell'hub di Azure Stack di origine, in un'istanza secondaria dell'hub di Azure Stack o in Azure.
Backup/ripristino di macchine virtuali in una destinazione di backup esterna dedicata all'hub di Azure Stack Consigliato È possibile acquistare una nuova infrastruttura di backup o effettuare il provisioning di un'infrastruttura di backup dedicata per l'hub di Azure Stack. Assicurarsi che l'infrastruttura di backup non si trova in prossimità dell'origine. È possibile ripristinare le macchine virtuali nell'hub di Azure Stack di origine, in un'istanza secondaria dell'hub di Azure Stack o in Azure.
Eseguire il backup e il ripristino di macchine virtuali direttamente in Azure globale o in un provider di servizi attendibili Consigliato Purché sia possibile soddisfare i requisiti normativi e sulla privacy dei dati, è possibile archiviare i backup in Azure globale o in un provider di servizi attendibili. Idealmente, il provider di servizi esegue anche l'hub di Azure Stack in modo da ottenere coerenza nell'esperienza operativa durante il ripristino.
Replicare/eseguire il failover di macchine virtuali in un'istanza separata dell'hub di Azure Stack Consigliato Nel caso di failover, è necessario avere un secondo cloud dell'hub di Azure Stack completamente operativo, in modo da evitare tempi di inattività estesi delle app.
Replicare/eseguire il failover di macchine virtuali direttamente in Azure o in un provider di servizi attendibili Consigliato Purché sia possibile soddisfare i requisiti normativi e sulla privacy dei dati, è possibile replicare i dati in Azure globale o in un provider di servizi attendibili. Idealmente, il provider di servizi esegue anche l'hub di Azure Stack in modo da ottenere coerenza nell'esperienza operativa dopo il failover.
Distribuire una destinazione di backup nello stesso hub di Azure Stack che ospita anche tutte le applicazioni protette dalla stessa destinazione di backup. Destinazione autonoma: destinazione non consigliata
che replica i dati di backup esternamente: scelta consigliata		 Se si sceglie di distribuire un'appliance di backup nell'hub di Azure Stack (ai fini dell'ottimizzazione del ripristino operativo), è necessario assicurarsi che tutti i dati vengano copiati continuamente in un percorso di backup esterno.
Distribuire l'appliance di backup fisico nello stesso rack in cui è installata la soluzione hub di Azure Stack Non supportato Attualmente, non è possibile connettere altri dispositivi ai commutatori top of rack che non fanno parte della soluzione originale.

Considerazioni per una macchina virtuale IaaS ripristinata

È necessario apportare alcune modifiche alla macchina virtuale dopo il ripristino del computer dal backup. Queste includono:

  • Indirizzo MAC
    La scheda di rete virtuale otterrà un nuovo indirizzo MAC. Non esiste un metodo per mantenere l'indirizzo MAC originale.
  • Indirizzo IP
    Se la macchina virtuale ha un indirizzo IP statico impostato internamente, l'indirizzo IP interno nella scheda di rete virtuale può essere impostato in modo che corrisponda all'originale. Potrebbe essere necessario considerare se la rete virtuale ha una VPN da sito a un ambiente esterno in cui potrebbe essere in uso l'indirizzo IP.
  • Artefatti non richiesto
    Se è stato eseguito il backup della macchina virtuale in una piattaforma diversa, ad esempio VMware vSphere, è necessario seguire alcuni passaggi aggiuntivi per pulire eventuali elementi non necessari dall'origine.

Passaggi successivi

Questo articolo ha fornito linee guida generali per la protezione delle macchine virtuali utente distribuite nell'hub di Azure Stack. Per informazioni sull'uso dei servizi di Azure per proteggere le macchine virtuali utente, vedere: