Pianificazione della capacità con Azure Site Recovery
Come organizzazione, è imperativo adottare una strategia di continuità aziendale e ripristino di emergenza che mantiene i dati sicuri, le app e i carichi di lavoro online durante le interruzioni pianificate e non pianificate.
Tramite la replica dei carichi di lavoro delle macchine virtuali 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, la disponibilità dell'applicazione e i 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 viene eseguito di nuovo, è possibile eseguirne il failback. Per altre informazioni, vedere Informazioni su Site Recovery.
Per abilitare la replica di macchine virtuali in due stamp dell'hub di Azure Stack, è possibile configurare due ambienti:
-
Ambiente di origine :
- Il timbro dell'hub di Azure Stack in cui vengono eseguite 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 delle modifiche dei dati all'interno della rispettiva macchina virtuale.
- Quanti dati vengono generati o rimossi?
- Come sembra la progettazione dell'applicazione e altro ancora?
Dimensioni della macchina virtuale, numero di dischi e modalità di associare ogni macchina virtuale ad altre macchine virtuali.
- Per le soluzioni che richiedono diverse macchine virtuali, comprendere in quale ordine devono essere avviate le 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 durante la creazione di un piano BCDR.
Le sezioni seguenti elencano i punti principali da considerare da un punto di vista di Azure Site Recovery. Ogni piano BCDR è diverso e si basa 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 di macchine virtuali di Azure Site Recovery. La macchina virtuale è una macchina virtuale di Standard_DS4_v2 (8 vCPUS, memoria da 28 GB, 32 dischi dati) eseguita nella sottoscrizione utente dell'hub di Azure Stack.
Nell'ambiente di origine prendere in considerazione le aree seguenti:
Quota:
- È necessario disporre di una quota sufficiente per la creazione dell'appliance macchina virtuale di Azure Site Recovery. È necessario uno o più, a seconda del piano complessivo.
Archiviazione per l'appliance macchina virtuale di Azure Site Recovery:
L'appliance macchina virtuale di Azure Site Recovery ha i requisiti di dati definiti dalle dimensioni della macchina virtuale.
Quando si pianifica la capacità, assicurarsi che la macchina virtuale dell'appliance disponga di spazio di archiviazione sufficiente per eseguire il failback e ri-proteggere i meccanismi.
Nota
Se sono presenti limitazioni di archiviazione, il failback e la riprotezione possono non riuscire con un errore Un errore interno si è verificato un 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 apportate a ogni macchina virtuale vengono replicate, a seconda dei criteri di replica e di ogni tipo di applicazione.
Considerazioni di destinazione
Nell'ambiente di destinazione sono disponibili due parti da considerare per la pianificazione della capacità:
Requisiti del servizio di Azure Site Recovery: quanto viene usato per eseguire azure Site Recovery, senza necessariamente proteggere i carichi di lavoro.
Requisiti dei carichi di lavoro protetti.
L'ambiente di destinazione richiede la creazione di un insieme di credenziali di Azure Site Recovery per ogni appliance Site Recovery, per proteggere le macchine virtuali dall'origine (un'appliance per insieme di credenziali). Anche se questa non è una limitazione dal punto di vista della capacità, deve essere presa 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 dell'amministratore 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 dispongono di determinate vCPUS allocate:
| Servizio | vCore | Memoria | Dimensione disco |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 GB | 1,4 TB |
Nota
Queste risorse sono servizi 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 creazione di nuovi dati.
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 eseguire 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 effettuato il provisioning di una larghezza di banda inferiore.
Considerazioni sull'archiviazione:
- Quantità di dati necessari per la replica iniziale.
- Quanti punti di ripristino vengono mantenuti e in che modo i dati aumentano, 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 di calcolo:
- Quando si verifica il failover, le macchine virtuali vengono avviate nelle sottoscrizioni utente dell'hub di Azure Stack di destinazione. L'allocazione della quota sufficiente deve essere in grado di avviare queste risorse della macchina virtuale.
- Durante la protezione della macchina virtuale, quando la macchina virtuale protetta è attiva nell'ambiente di origine, nessuna risorsa correlata alla macchina virtuale, ad esempio vCPU, memoria e così via, viene utilizzata nell'ambiente di destinazione. Queste risorse diventano rilevanti solo durante un processo di failover, ad esempio il 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 è presente un failover, durante le normali operazioni, moltiplicare il numero di dischi replicati dal RPO medio. Ad esempio, potrebbe essere disponibile (2 MB * 250s). L'account di archiviazione della cache è in genere un paio di KB a 500 MB per disco.
Se è presente un failover, dato uno scenario peggiore, moltiplicare il numero di dischi replicati dal RPO medio in un giorno intero.
Importante
Se alcune parti di Azure Site Recovery non funzionano, ma altri funzionano, possono esserci al massimo un giorno di difflog nell'account di archiviazione prima che Azure Site Recovery decide di timeout.
Failback nella 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 elaborata | Totale operazioni al secondo | Bottleneck |
|---|---|---|---|
| 68 | 136 MB/s | 68 | storage |
| 60 | 120 MB/s | 2048 | storage |
| 28 | 28 MB/s | 3584 | CPU e memoria di Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Nota
8 Kb è la dimensione minima dei blocchi di dati supportati da Azure Site Recovery. Le modifiche minori di 8 Kb vengono considerate come 8 Kb.
Per testare ulteriormente, è stato generato un tipo coerente di carico di lavoro; Ad esempio, modifiche coerenti di archiviazione in blocchi di 8 KB che totali 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 tra cinque file.
La replica ha avuto esito positivo in tutte e 120 le macchine virtuali con un carico basso-medio nei servizi di Site Recovery di Azure.
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
Le applicazioni e i carichi di lavoro della soluzione 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, poiché 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 modelli di disponibilità attivo-attivo e attivo-passivo.
Supporto per distribuzioni in più aree per il failover, con prossimità dei componenti per le prestazioni. È possibile che si verifichino operazioni dell'applicazione con funzionalità ridotte o prestazioni ridotte durante un'interruzione.
Nota
L'applicazione potrebbe conoscere in modo nativo per l'esecuzione in o avere determinati componenti che possono essere eseguiti in più ambienti dell'hub di Azure Stack. 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 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 ripristino di emergenza.
- 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 fornisca 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 previste e dei criteri di replica con una risorsa di archiviazione da 1,5x a 2x nella destinazione, assicurarsi che i processi di failover non presentino problemi.
- È possibile considerare la presenza dell'ambiente dell'hub di Azure Stack di destinazione come destinazione per più origini dell'hub di Azure Stack. In questo caso, si riduce il costo complessivo, ma è necessario pianificare ciò che accade quando alcuni carichi di lavoro si arrestano; Ad esempio, quale origine deve essere prioritaria.
- 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 spostando gli interi carichi di lavoro per convalidare i flussi end-to-end.