NetApp Disaster Recovery è un servizio di disaster recovery basato sul cloud, accessibile tramite la NetApp Console, che automatizza i flussi di lavoro di disaster recovery per ambienti VMware e Kubernetes. Replica i carichi di lavoro VMware on-premises che utilizzano storage ONTAP, o i carichi di lavoro Kubernetes che utilizzano storage ONTAP gestito da Trident, verso un altro sito come destinazione per il disaster recovery. Il servizio utilizza la tecnologia ONTAP SnapMirror, con orchestrazione nativa VMware o orchestrazione Trident Protect, per proteggere i carichi di lavoro preservando le efficienze dello storage ONTAP come compressione e deduplicazione.

Il Disaster Recovery non richiede alcuna attivazione separata. Appare automaticamente nella barra di navigazione a sinistra della NetApp Console, sotto Protection > Disaster recovery. Per accedere alla NetApp Console, in un browser, inserisci: "https://console.netapp.com/".

Per l'accesso completo e continuativo è necessaria una licenza Disaster Recovery. Puoi provare il servizio con una prova gratuita di 30 giorni prima di acquistare una licenza o un abbonamento. Per dettagli, consulta "Configura la licenza per il Disaster Recovery".

Disaster Recovery supporta i seguenti obiettivi di protezione:

Per i carichi di lavoro VMware, Disaster Recovery supporta i seguenti tipi di datastore:

Per i carichi di lavoro Kubernetes, Disaster Recovery protegge i volumi persistenti forniti tramite NetApp Trident su storage ONTAP.

Disaster Recovery offre le seguenti opzioni di licenza:

I costi per il disaster recovery si basano sulla capacità utilizzata dei datastore nel sito di origine quando è presente almeno una VM o una risorsa Kubernetes con un piano di replica.

Per un BYOL, se i dati superano la capacità consentita, le operazioni nel servizio sono limitate finché non ottieni una licenza di capacità aggiuntiva o non aggiorni la licenza nella NetApp Console.

Al termine del periodo di prova gratuito, puoi comunque visualizzare ed eliminare risorse come carichi di lavoro e piani di replica, e eseguire tutte le operazioni pianificate create durante il periodo di prova. Per continuare a usare il servizio con tutte le funzionalità, devi ottenere un abbonamento PAYGO dal tuo cloud provider oppure acquistare una licenza BYOL da NetApp.

Puoi acquistare una licenza o abbonarti in qualsiasi momento e non ti verrà addebitato nulla fino al termine del periodo di prova di 30 giorni.

Disaster Recovery supporta le seguenti topologie:

Per l'elenco completo, vedi "Prerequisiti per il disaster recovery".

Un agente Console è un componente software che permette alla NetApp Console di comunicare con i tuoi storage ONTAP e i cluster VMware vCenter. È necessario perché NetApp Disaster Recovery funzioni correttamente. L'agente risiede nella tua rete privata (in un data center on-premises o in una VPC cloud) e comunica con le tue istanze di storage ONTAP e i cluster vCenter.

Per il disaster recovery da on-premises a on-premises, installa l'agente Console on-premises nel sito di disaster recovery. Per il disaster recovery da on-premises ad AWS, installa l'agente Console per AWS nella tua AWS VPC. Sia il cluster vCenter di origine che quello di destinazione devono usare lo stesso agente Console. Il disaster recovery funziona solo con la distribuzione dell'agente in modalità standard.

Ogni cluster Kubernetes deve avere NetApp Trident installato, un backend ONTAP e una classe di storage configurati, e i CRD e il controller per gli snapshot di volume installati. Le applicazioni devono usare volumi persistenti forniti tramite la classe di storage Trident. Quando aggiungi un cluster Kubernetes come sito, Disaster Recovery ti guida nell’installazione e nella registrazione di Trident Protect su quel cluster. Vedi "Requisiti del cluster Kubernetes per il Disaster Recovery" per i comandi passo-passo e i controlli di verifica.

Un sito è un container logico, in genere associato a un data center fisico o a una posizione cloud, che ospita uno o più cluster vCenter o cluster Kubernetes. Devi aggiungere sia un sito di origine (produzione) sia un sito di destinazione (disaster recovery) prima di creare un piano di replica.

Un gruppo di risorse è un container logico che ti permette di gestire più macchine virtuali, datastore o namespace e risorse Kubernetes come un'unica unità, così puoi proteggerli con uno snapshot comune. Una macchina virtuale può appartenere a un solo gruppo di risorse alla volta. Puoi creare un gruppo di risorse per ogni applicazione o carico di lavoro che vuoi proteggere, e le macchine virtuali si accendono in base all'ordine di avvio che configuri all'interno del gruppo.

Un piano di replica è un insieme di regole su quanto spesso vengono eseguiti i backup e su come gestire gli eventi di failover. Seleziona i siti di origine e di destinazione, assegna i gruppi di risorse, definisce le mappature di recovery e configura il comportamento all'accensione. I piani definiscono il recovery point objective (RPO) tramite la frequenza della replica dei dati.

L'obiettivo del punto di ripristino (RPO) è la quantità massima di perdita di dati accettabile in caso di disastro; è definito dalla frequenza o dalla pianificazione di replica del piano di replica. L'obiettivo del tempo di ripristino (RTO) è il tempo massimo accettabile per il ripristino da un disastro; è determinato da quanto tempo ci vuole per eseguire il failover al sito di DR e riavviare tutte le VM o applicazioni.

Per i passaggi, vedi "Aggiungi siti in Disaster Recovery".

Il rilevamento viene eseguito ogni 24 ore per impostazione predefinita; puoi personalizzare la pianificazione in base al tuo ambiente. L'intervallo minimo è di 30 minuti e il massimo è di 24 ore. NetApp consiglia di eseguire prima alcuni rilevamenti manuali per ottenere informazioni aggiornate, poi di impostare la pianificazione per l'esecuzione automatica. Le risorse appena aggiunte o eliminate vengono riconosciute al successivo rilevamento pianificato o manuale.

No. Ospitare macchine virtuali protette e non protette sullo stesso datastore può causare problemi. In particolare, se il datastore viene sottoposto a failover, le macchine virtuali non protette presenti su di esso non esisteranno più nell'origine dopo il failover e Disaster Recovery non le avvierà nel sito di failover.

Dovresti organizzare le risorse prima di implementare il Disaster Recovery, così che i carichi di lavoro protetti e non protetti utilizzino sottoinsiemi separati di datastore, e assicurarti che un singolo datastore non sia protetto da più di un piano di replica.

Se prevedi di utilizzare backup gestiti dalla piattaforma (gestiti da ONTAP), usa la policy MirrorAll. MirrorVault e Asynchronous sono alternative accettabili, ma devi assicurarti che lo snapshot selezionato durante il failover o il failback esista sia sul volume di origine che su quello di destinazione, altrimenti l'operazione fallisce con un errore "no common snapshot found". MirrorLatest non è consigliato perché lascia solo uno snapshot comune per il failover. Per le relazioni di SnapMirror gestite da Disaster Recovery, non pianificare aggiornamenti al di fuori del servizio, perché Disaster Recovery gestisce la tempistica della replica.

Sì. Se una relazione di SnapMirror esiste già tra i volumi di origine e di destinazione per un datastore protetto, Disaster Recovery utilizza quella relazione per tutte le operazioni di replica invece di crearne una nuova.

Sì. Puoi migrare le applicazioni VMware da un sito di origine a un altro sito utilizzando un piano di replica configurato per la migrazione. Dopo che avvii la migrazione, il servizio verifica ogni 30 minuti che la migrazione proceda secondo il piano; puoi monitorare l'avanzamento in Monitoraggio processi. La migrazione non è attualmente supportata per i carichi di lavoro basati su Kubernetes. Vedi "Migra le applicazioni su un altro sito".

Sì. Durante un test di failover, Disaster Recovery crea VM temporanee da un nuovo volume FlexClone dello snapshot selezionato e mappa un datastore temporaneo basato su FlexClone agli host ESXi. Questo non consuma capacità fisica aggiuntiva, non modifica il volume di origine originale e non interrompe la relazione di SnapMirror o i carichi di lavoro di produzione, che continuano a replicarsi normalmente. Dopo il test, pulisci l'ambiente di test usando l'azione Clean up failover test. Vedi "Eseguire il failover delle applicazioni su un sito remoto".

Sì. Per impostazione predefinita, tutte le macchine virtuali si avviano insieme in parallelo, ma puoi assegnare a ciascuna VM un numero sequenziale (ad esempio, 1, 2, 3) per controllare l'ordine di avvio, oppure assegnare lo stesso numero a più VM per avviarle simultaneamente. Puoi anche impostare un ritardo di avvio (0–10 minuti) per ogni VM per scaglionare l'avvio, utile per assicurarti che le VM prioritarie siano in esecuzione prima che partano quelle con priorità inferiore.

Il failback riporta le operazioni al sito di origine originale dopo che il disastro è stato risolto. Partendo da una relazione che ha effettuato il failover verso la destinazione, NetApp Disaster Recovery risincronizza tutte le modifiche con la VM di origine o il cluster Kubernetes originale prima di invertire la direzione della replica. Il processo:

Vedi "Esegui il failback delle applicazioni alla sorgente originale".

Usa la Dashboard di Disaster Recovery per vedere se i siti e i piani sono integri, disconnessi o degradati; controlla gli avvisi recenti e i job non riusciti; identifica i workload protetti e non protetti; e visualizza la capacità a colpo d'occhio. Vedi "Visualizza lo stato di salute del piano di recovery".

Usa Monitoraggio processi per controllare i timestamp, lo stato e l'initiator (o "system" se è stato avviato da Disaster Recovery). Puoi annullare un processo "In corso" o "In coda" dal menu Azioni, utile se un processo è bloccato o se devi dare priorità a un'altra operazione. Vedi "Monitora i job di Disaster Recovery".

Puoi generare report specifici per VMware, Kubernetes o tutti i workload, che includono dettagli sui piani di replica, stato di compliance e riepiloghi dei job. I report possono essere scaricati come file PDF, HTML o JSON. Coprono un periodo da uno a sette giorni. Per ulteriori informazioni, vedi "Crea report in Disaster Recovery".

Un AppVault è il cloud storage di destinazione in cui Trident Protect salva i dati di protezione di Kubernetes. Crei un AppVault durante la configurazione di un piano di replica di Kubernetes.