Pianificazione della capacità con Azure Site Recovery
In qualità di organizzazione, è fondamentale adottare una strategia di continuità aziendale e ripristino di emergenza (BCDR) che mantiene i dati sicuri, le app disponibili e i carichi di lavoro online durante interruzioni pianificate e non pianificate.
Tramite la replica di carichi di lavoro di macchine virtuali (VM) da un sito primario a una posizione secondaria, Azure Site Recovery nell'hub di Azure Stack offre servizi che possono supportare la sicurezza dei dati dell'organizzazione, della disponibilità delle applicazioni e dei carichi di lavoro durante le interruzioni. Ad esempio, quando si verifica un'interruzione nel sito primario, si esegue il failover in una posizione secondaria per accedere alle app. Non appena il sito primario torna operativo, è possibile effettuare il failback. Per altre informazioni, vedere Informazioni su Site Recovery.
Per abilitare la replica di VM tra due istanze di Azure Stack Hub, configurare due ambienti:
- ambiente di origine:
- Stamp dell'hub di Azure Stack in cui sono in esecuzione le macchine virtuali tenant.
-
ambiente di destinazione:
- Posizione in cui viene eseguito il provider di risorse di Azure Site Recovery.
Un componente essenziale per il successo di un piano di continuità aziendale e ripristino di emergenza è la pianificazione della capacità. Durante la pianificazione della capacità, esistono alcuni fattori da considerare:
Obiettivi del tempo di ripristino (RTO) e obiettivi del punto di ripristino (RPO) per i carichi di lavoro specifici da proteggere.
Carichi di lavoro e caratteristiche dell'applicazione:
- Frequenza con cui i dati vengono modificati all'interno della rispettiva macchina virtuale.
- Quanti dati vengono generati o rimossi?
- Come appare la progettazione dell'applicazione e altro ancora?
Dimensioni delle macchine virtuali, il numero di dischi e il modo in cui ogni macchina virtuale è associata ad altre macchine virtuali.
- Per le soluzioni che richiedono diverse macchine virtuali, comprendere l'ordine in cui devono essere avviate tali macchine virtuali.
Larghezza di banda di rete tra gli ambienti di origine e di destinazione. Questo componente può influire sugli RPO.
Ognuno di questi punti è importante e ha implicazioni generali per la creazione di un piano BCDR.
Le sezioni seguenti elencano i punti principali da considerare dal punto di vista di Azure Site Recovery. Ogni piano BCDR è diverso ed è basato sulle specifiche dei carichi di lavoro che si prevede di proteggere. Pertanto, questo elenco non è completo.
Considerazioni sull'origine
Nell'ambiente di origine l'hub di Azure Stack esegue l'appliance vm di Azure Site Recovery. La macchina virtuale è una macchina virtuale Standard_DS4_v2 (8 vCPU, 28 GB di memoria, 32 dischi dati) eseguita nella sottoscrizione utente dell'hub di Azure Stack.
Nell'ambiente di origine considerare le aree seguenti:
Quota:
- È necessario disporre di una quota sufficiente per la creazione dell'appliance vm di Azure Site Recovery. È necessario uno o più, a seconda del piano complessivo.
Archiviazione per l'appliance vm di Azure Site Recovery:
L'appliance VM di Azure Site Recovery ha i requisiti di dati definiti dalla dimensione della VM.
Quando si pianifica la capacità, assicurarsi che la macchina virtuale dell'appliance disponga di spazio di archiviazione sufficiente per esercitare i meccanismi di failback e riprotezione.
Nota
Se sono presenti limitazioni di archiviazione, il failback e la riprotezione possono non riuscire con un errore Si è verificato un errore interno messaggio. Gli utenti devono controllare i log eventi nell'appliance per confermare l'errore effettivo di Azure Resource Manager. Per altre informazioni, vedere Problemi noti per Azure Site Recovery.
Larghezza di banda:
- La replica iniziale genera un utilizzo elevato della larghezza di banda.
- Le modifiche in ogni macchina virtuale vengono replicate, a seconda dei criteri di replica e di ogni tipo di applicazione.
Considerazioni sulla destinazione
Nell'ambiente di destinazione sono disponibili due elementi da considerare per la pianificazione della capacità:
Requisiti del servizio Azure Site Recovery: quanto viene usato per eseguire Azure Site Recovery, senza necessariamente proteggere alcun carico di lavoro.
Requisiti dei carichi di lavoro protetti.
L'ambiente di destinazione richiede che venga creata una cassetta di sicurezza di Azure Site Recovery per ciascun appliance di Site Recovery, per proteggere le VM dall'ambiente di origine (un appliance per ogni cassetta di sicurezza). Anche se questo non è un limite dal punto di vista della capacità, deve essere preso in considerazione durante la pianificazione della progettazione dell'ambiente complessivo.
Risorse rp di Azure Site Recovery
L'installazione di Azure Site Recovery nell'hub di Azure Stack richiede l'installazione del provider di risorse di Site Recovery (RP).
Nota
Con Microsoft.SiteRecovery-1.2301.2216.2287, Azure Site Recovery nell'hub di Azure Stack non richiede Hub eventi come dipendenza.
Questo servizio viene creato nella sottoscrizione di amministrazione dell'hub di Azure Stack e gestito dall'hub di Azure Stack stesso, pertanto non è necessaria alcuna configurazione. Tuttavia, come per qualsiasi servizio, queste risorse usano memoria, archiviazione e hanno determinate vCPU allocate:
| Servizio | vCore | Memoria | Dimensioni disco |
|---|---|---|---|
| Azure Site Recovery | 18 | 64 GB | 384 GB |
Nota
Queste risorse sono servizi dell'hub di Azure Stack sul lato amministrazione dell'hub di Azure Stack. Dopo l'installazione, la piattaforma gestisce queste risorse.
Carichi di lavoro protetti
Quando si crea il piano BCDR, prendere in considerazione tutti gli aspetti dei carichi di lavoro protetti. L'elenco seguente non è completo e deve essere considerato come punto di partenza:
Dimensioni della macchina virtuale, numero di dischi, dimensioni del disco, operazioni di I/O al secondo, varianza dei dati e nuovi dati creati.
Considerazioni sulla larghezza di banda di rete:
- Larghezza di banda di rete necessaria per la replica differenziale.
- Quantità di velocità effettiva, nell'ambiente di destinazione, che Azure Site Recovery può ottenere dall'ambiente di origine.
- Numero di macchine virtuali da raggruppare in batch alla volta. Questo numero si basa sulla larghezza di banda stimata per completare la replica iniziale in un determinato periodo di tempo.
- RPO che può essere ottenuto per una determinata larghezza di banda.
- Effetto sull'RPO desiderato se viene provisionata una larghezza di banda ridotta.
Considerazioni sull'archiviazione:
- Quantità di dati necessari per la replica iniziale.
- Quanti punti di ripristino sono mantenuti e come aumentano i dati per ogni macchina virtuale protetta durante questi intervalli.
- Quante quote devono essere assegnate alle sottoscrizioni utente dell'hub di Azure Stack di destinazione, in modo che gli utenti abbiano un'allocazione sufficiente.
- Account di archiviazione della cache per la replica.
Considerazioni sul calcolo:
- Quando si verifica il failover, le macchine virtuali vengono avviate nelle sottoscrizioni utente dell'hub di Azure Stack di destinazione. Per poter avviare queste risorse di macchina virtuale, è necessario disporre di un numero sufficiente di allocazioni di quote.
- Durante la protezione della macchina virtuale, quando la macchina virtuale protetta è attiva nell'ambiente di origine, non vengono utilizzate risorse correlate a macchine virtuali come vCPU, memoria e così via nell'ambiente di destinazione. Queste risorse diventano rilevanti solo durante un processo di failover, ad esempio un processo di failover di test.
Per l'ambito di Azure Site Recovery nell'hub di Azure Stack, ecco un punto di partenza per i calcoli, in particolare per l'account di archiviazione della cache usato:
Se c'è un failover, durante le normali operazioni, moltiplicare il numero di dischi replicati per il RPO medio. Ad esempio, si potrebbe avere (2 MB * 250 s). L'account di archiviazione della cache è in genere di pochi KB a 500 MB per disco.
Se si verifica un failover, dato uno scenario peggiore, moltiplicare il numero di dischi replicati per l'RPO medio giornaliero.
Importante
Se alcune parti di Azure Site Recovery non funzionano, mentre altre funzionano, ci può essere al massimo un giorno di difflog nell'account di archiviazione prima che Azure Site Recovery decida di andare in timeout.
Failback alla nuova macchina virtuale. Calcolare la somma delle dimensioni dei dischi di ogni batch.
- L'intero disco deve essere copiato nell'account di archiviazione della cache per applicare la macchina virtuale di destinazione, perché la destinazione è un disco vuoto.
- I dati associati vengono eliminati una volta copiati, ma è probabile che venga visualizzato un picco di utilizzo con la somma di tutte le dimensioni del disco.
Creare il piano BDCR in base alle specifiche della soluzione che si sta tentando di proteggere.
La tabella seguente è un esempio di test eseguiti negli ambienti. È possibile usare queste informazioni dettagliate per ottenere una baseline per la propria applicazione, ma ogni carico di lavoro è diverso:
Configurazione
| Dimensioni blocco | Velocità effettiva/disco |
|---|---|
| 2 MB | 2 MB/s |
| 64 KB | 2 MB/s |
| 8 KB | 1 MB/s |
| 8 KB | 2 MB/s |
Risultato
| Numero di dischi supportati | Velocità effettiva totale | Totale OPS | Collo di bottiglia |
|---|---|---|---|
| 68 | 136 MB/s | 68 | immagazzinamento |
| 60 | 120 MB/s | 2048 | immagazzinamento |
| 28 | 28 MB/s | 3584 | CPU e memoria di Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Nota
8 Kb è la dimensione minima del blocco di dati supportata da Azure Site Recovery. Le modifiche minori di 8 Kb vengono considerate come 8 Kb.
Per testare ulteriormente, abbiamo generato un tipo coerente di carico di lavoro; ad esempio, modifiche coerenti nello storage in blocchi di 8 KB che totalizzano fino a 1 MB/s per disco. Questo scenario non è probabilmente in un carico di lavoro reale, dato che le modifiche possono verificarsi in vari momenti del giorno o in picchi di varie dimensioni.
Per replicare questi modelli casuali, sono stati testati anche gli scenari con:
- 120 macchine virtuali (80 Windows, 40 Linux) protette tramite la stessa appliance vm di Azure Site Recovery.
Ogni macchina virtuale che genera a intervalli casuali, almeno due volte all'ora, blocchi casuali per un totale di 5 GB di dati in cinque file.
La replica ha avuto esito positivo in tutte le 120 macchine virtuali con un carico da basso a medio nei servizi di Azure Site Recovery.
Nota
Questi numeri devono essere usati solo come baseline. Non sono necessariamente scalabili in modo lineare. L'aggiunta di un altro batch dello stesso numero di macchine virtuali potrebbe avere un impatto minore rispetto a quello iniziale. I risultati dipendono in modo elevato dal tipo di carichi di lavoro usati.
Come pianificare e testare
I carichi di lavoro delle applicazioni e delle soluzioni hanno determinati requisiti di obiettivo del tempo di ripristino (RTO) e obiettivo del punto di ripristino (RPO). Una progettazione efficace di continuità aziendale e ripristino di emergenza (BCDR) sfrutta entrambe le funzionalità a livello di piattaforma che soddisfano questi requisiti, in quanto vengono usati i meccanismi specifici della soluzione. Per progettare funzionalità BCDR, acquisire i requisiti di ripristino di emergenza della piattaforma e prendere in considerazione tutti questi fattori nella progettazione:
Requisiti di disponibilità delle applicazioni e dei dati:
- Requisiti RTO e RPO per ogni carico di lavoro.
- Supporto per i modelli di disponibilità active-active e active-passive.
Supporto per distribuzioni multi-regionali per il failover, con prossimità dei componenti per ottimizzare le prestazioni. È possibile che si verifichino operazioni dell'applicazione con funzionalità ridotte o prestazioni ridotte durante un'interruzione.
Nota
L'applicazione potrebbe essere in grado di funzionare in modo nativo o potrebbe avere determinati componenti che sono in grado di funzionare in più ambienti Azure Stack Hub. In tal caso, è possibile usare Azure Site Recovery per replicare solo le macchine virtuali con i componenti che non dispongono di questa funzionalità; Ad esempio, una soluzione di tipo front-end o back-end, in cui è possibile distribuire i front-end negli ambienti dell'hub di Azure Stack.
Evitare di usare intervalli di indirizzi IP sovrapposti nelle reti di produzione e disaster recovery.
- Le reti di produzione e ripristino di emergenza con indirizzi IP sovrapposti richiedono un processo di failover che può complicare e ritardare il failover dell'applicazione. Quando possibile, pianificare un'architettura di rete BCDR che fornisce connettività simultanea a tutti i siti.
Ridimensionamento degli ambienti di destinazione:
- Se si usa l'origine e la destinazione in modo 1:1, allocare leggermente più spazio di archiviazione nell'ambiente di destinazione. Ciò è dovuto al modo in cui si verifica la cronologia dei segnalibri del disco. Questa allocazione non è un aumento di 2 volte, perché include solo le modifiche ai dati. A seconda del tipo di dati e delle modifiche attese, i criteri di replica prevedono di avere uno spazio di archiviazione fino a 1,5x o 2x in più nella destinazione per garantire che i processi di failover non presentino problemi.
- È possibile valutare di avere l'ambiente di destinazione di Azure Stack Hub come destinazione per più origini di Azure Stack Hub. In questo caso, si riduce il costo complessivo, ma è necessario pianificare ciò che accade quando alcuni carichi di lavoro si arrestano; ad esempio, quale fonte deve avere la priorità.
- Se l'ambiente di destinazione viene usato per l'esecuzione di altri carichi di lavoro, il piano BCDR deve includere il comportamento di questi carichi di lavoro. Ad esempio, è possibile eseguire le macchine virtuali di sviluppo/test nell'ambiente di destinazione e, se si verifica un problema con l'ambiente di origine, è possibile disattivare tutte le macchine virtuali nella destinazione per assicurarsi che siano disponibili risorse sufficienti per avviare le macchine virtuali protette.
È consigliabile testare il bcdr e convalidare regolarmente. A tale scopo, è possibile usare i processi di failover di test o spostare gli interi carichi di lavoro per convalidare i flussi end-to-end.