Il sistema storage rappresenta un punto di guasto condiviso. Proxmox VE HA protegge le VM dei tenant da un guasto dell'host, ma non da un guasto del sistema storage che ospita i loro dischi. Un'interruzione del sistema storage influisce su tutti i tenant presenti su tale sistema.

Impossibile vendere una maggiore disponibilità. Senza replica sincrona e il failover automatico dello storage, un provider non può offrire un livello di disponibilità premium con zero perdita di dati e maggiori garanzie di uptime.

Isolamento dei tenant durante il ripristino. I test di ripristino, manutenzione e disaster recovery devono interessare solo i tenant coinvolti, non l'intera piattaforma.

Il QDevice necessita comunque di una terza posizione. ONTAP Cloud Mediator rimuove l'host del mediatore, non l'host del QDevice di corosync. Il QDevice necessita di un piccolo host Linux raggiungibile da tutti i nodi Proxmox VE sulla porta TCP 5403 e non richiede la bassa latenza di corosync.

Entrambi i cluster devono avere accesso a NetApp Console. Se i cluster utilizzano un proxy, installa il certificato della CA radice del proxy su entrambi i cluster. NetApp consiglia un proxy server diverso per ciascun cluster.

Con entrambe le opzioni, pianifica lo stesso comportamento in caso di errore. Quando il mediatore non è disponibile, la replica continua senza perdita di dati, ma i failover automatici e pianificati non sono possibili finché il mediatore non torna di nuovo disponibile. Con ONTAP Cloud Mediator, questo include una perdita di connettività dai cluster alla NetApp Console.

Disponibilità delle VM oltre l'HA dell'host. Le VM del tenant continuano a funzionare quando il sistema storage che ospita i loro dischi si guasta. ONTAP esegue il failover al secondo AFF cluster e le VM riprendono le operazioni di I/O sullo stesso storage condiviso senza bisogno di riavvio.

Un livello di disponibilità premium. Puoi offrire un servizio VM a RPO zero e resiliente allo storage come componente aggiuntivo, insieme ai livelli standard su storage non protetto negli stessi cluster.

Protezione e failover per singolo tenant. Con uno storage protetto separato per ogni tenant o livello di servizio, puoi proteggere, eseguire il failover e testare il disaster recovery per ogni tenant in modo indipendente, senza influire sugli altri tenant.

Uso ottimale di entrambi i siti. Puoi impostare alcuni carichi di lavoro come primari nel sito A e altri come primari nel sito B, in modo che entrambi i data center gestiscano carichi di lavoro attivi.

Zero perdita di dati per le VM business-critical durante un guasto del sistema storage o del sito.

Ripristino automatico senza script, rimontaggi di storage o modifiche a /etc/pve/storage.cfg.

Integrato in ONTAP, senza alcun livello software aggiuntivo sui nodi Proxmox VE.

Operazioni quotidiane da un'unica interfaccia. Storage Manager per Proxmox esegue il provisioning dello storage condiviso protetto ed effettua il backup, il ripristino e la clonazione delle VM con snapshot ONTAP e la tecnologia FlexClone.

Scegli MetroCluster quando tutti, o quasi tutti, i carichi di lavoro sullo storage necessitano di un RPO pari a zero, ad esempio quando un'azienda esegue solo macchine virtuali mission-critical sul cluster o quando un service provider offre lo stesso livello di disponibilità a ogni tenant. Ottieni un dominio di protezione unico senza configurazione per singolo carico di lavoro.

Scegli la sincronizzazione attiva di SnapMirror quando solo un sottoinsieme di carichi di lavoro richiede RPO zero, ad esempio un livello premium per alcuni tenant, oppure quando devi eseguire il failover o testare il disaster recovery per un tenant o un'applicazione alla volta.

SnapMirror active sync per NAS non è supportato in una configurazione MetroCluster. Usa una soluzione per ogni coppia di cluster.

Le linee guida relative a corosync, QDevice e HA in questa soluzione si applicano a entrambi. Con MetroCluster, allinea il tie breaker di QDevice con il sito che continua a servire i dati quando il collegamento tra i siti si interrompe e utilizza le regole di affinità dei nodi HA per mantenere le VM nello stesso sito della loro SVM attiva.

MetroCluster IP supporta anche VIP LIF con BGP per le reti di livello 3 tra i siti.

SnapMirror active sync richiede un tempo di andata e ritorno (RTT) tra cluster inferiore a 10 ms. Proxmox raccomanda una latenza di corosync inferiore a 5 ms tra tutti i nodi, quindi il requisito di corosync definisce il limite di distanza per la soluzione.

Corosync richiede una latenza bassa e costante piuttosto che un'elevata larghezza di banda. Utilizza una rete dedicata per corosync, separata dal traffico di storage e di migrazione live, in modo che i picchi di traffico dello storage non causino timeout di corosync.

Configura almeno due collegamenti corosync (ad esempio, collegamento 0 e collegamento 1) su percorsi fisici separati tra i siti. Corosync utilizza Kronosnet per commutare automaticamente i collegamenti in caso di guasto di uno di essi.

In genere, Proxmox VE HA rileva un nodo guasto e ripristina le sue VM in circa due minuti, incluso un timeout di 60 secondi per il watchdog fencing. In caso di guasto del sito, il failover di SnapMirror active sync e il ripristino di Proxmox VE HA vengono eseguiti in parallelo.

Utilizza le regole di affinità dei nodi HA con priorità dei nodi per posizionare le VM sui nodi nello stesso sito del loro storage primario e per consentire il failover sull'altro sito.

Dopo un failover del sito, imposta la proprietà HA failback su 0 per le VM interessate finché non ripristini lo storage. In caso contrario, HA migra di nuovo le VM ai nodi del sito A non appena tornano disponibili, mentre lo storage attivo è ancora nel sito B.

Assicurati che i timeout del disco del sistema operativo guest siano più lunghi del tempo di failover previsto, in modo che i guest non segnalino errori di I/O durante un failover dello storage.

Utilizza i gruppi di risorse e le policy di backup per applicare la stessa pianificazione e gli stessi criteri di conservazione alle macchine virtuali di un tenant o di un'applicazione.

Usa backup coerenti a livello di file per le VM che eseguono il guest agent QEMU, in modo che i file system guest vengano messi in quiescenza prima che ONTAP crei lo snapshot.

SMP gestisce lo storage attivo. Dopo un failover di SnapMirror active sync, esegui un rilevamento in SMP in modo che associ lo storage al cluster B prima di eseguire operazioni di backup o ripristino.

Per una terza copia al di fuori dei due siti, o per una conservazione più lunga, aggiungi una relazione fan-out asincrona SnapMirror dai volumi protetti oppure utilizza Proxmox Backup Server.

Gli snapshot a prova di manomissione non sono supportati con SnapMirror active sync, quindi non abilitare il blocco degli snapshot in SMP per i volumi protetti.

Esegui la VM SMP come risorsa HA su uno storage condiviso protetto da SnapMirror active sync, in modo che SMP rimanga disponibile dopo un guasto dello storage o del sito.

Registra il cluster Proxmox VE e entrambi i cluster ONTAP in SMP, in modo che SMP possa raggiungere lo storage attivo in entrambi i siti.

SnapMirror active sync per NAS protegge un'intera macchina virtuale di storage (SVM). Puoi proteggere tutti i volumi nella SVM o escludere i volumi selezionati. Sono supportati solo i volumi FlexVol e la SVM non può contenere LUN.

La SVM secondaria rimane inattiva, con i relativi LIF disattivati, fino a un failover. ONTAP replica la configurazione della SVM, inclusi gli indirizzi IP dei LIF, le policy di esportazione e le impostazioni NFS, in modo che la SVM secondaria presenti lo stesso endpoint NFS dopo un failover.

Il failover non interrompe il funzionamento per NFSv3 e versioni successive.

SnapMirror active sync per NAS è di tipo attivo/passivo, quindi le VM sui nodi del sito B leggono e scrivono attraverso la rete intersito verso l'SVM primario. Per i carichi di lavoro attivi in entrambi i siti, usa due SVM con direzioni di replica opposte, una primaria in ciascun sito, e allinea la regola di affinità del nodo di ogni VM al sito del relativo SVM primario.

SnapMirror active sync per NAS è supportato sui cluster AFF A-Series e C-Series a due nodi.

nConnect. Apre più connessioni TCP a un singolo indirizzo LIF NFS, ad esempio nconnect=4. nConnect funziona con NFSv3 e NFSv4.1 e con un singolo indirizzo LIF VIP, quindi è l'opzione consigliata per SnapMirror active sync per NAS, incluse le reti layer 3.

Session trunking. Raggruppa più LIF di dati in una sessione NFSv4.1, ad esempio vers=4.1,trunkdiscovery,max_connect=16. Il session trunking richiede NFSv4.1 o versione successiva. Utilizzalo solo quando la SVM protetta dispone di più LIF di dati raggiungibili dai client in entrambi i siti, come in una rete layer 2 estesa. Per i dettagli, consulta "Trunking NFS".

Esegui il provisioning del volume nella SVM primaria e seleziona la LIF NFS, oppure la LIF VIP in una rete di livello 3, come LIF preferita. La SVM secondaria utilizza lo stesso indirizzo dopo un failover, quindi la definizione dello storage rimane valida.

Monta lo storage su tutti i nodi Proxmox VE in entrambi i siti in modo che l'HA possa riavviare le VM su qualsiasi nodo.

Assicurati che la policy di esportazione consenta i nodi Proxmox VE in entrambi i siti. ONTAP replica la policy di esportazione sull'SVM secondario.

Dopo il provisioning, verifica che il volume sia incluso nella protezione di sincronizzazione attiva di SnapMirror.

Le BGP LIF non sono soggette a failover. La ridondanza deriva da due BGP LIF per nodo, ognuna in peering con un router diverso. Se un nodo perde tutte le sessioni BGP per una SVM, ONTAP sposta la VIP LIF su un altro nodo che ha una sessione BGP attiva per quella SVM.

Usa il protocollo BGP esterno (eBGP) con un numero di sistema autonomo privato (ASN) univoco per ogni nodo ONTAP e per ogni router.

Usa una sottorete /31 (maschera di sottorete 255.255.255.254) per ogni BGP LIF e il relativo router. Assegna l'indirizzo dispari al BGP LIF e l'indirizzo pari al router.

ONTAP non elabora le rotte provenienti dai router. Configura i router in modo che accettino le rotte host /32 da ONTAP e non inviino aggiornamenti di rotta al cluster.

I nodi Proxmox VE non devono condividere una subnet con l'indirizzo VIP. Un router di livello 3 ridondante, ad esempio con VRRP o HSRP, deve trovarsi nel percorso tra i nodi e lo storage.

Configura i gruppi peer BGP con -use-peer-as-next-hop true in modo che ogni cluster apprenda la propria rotta predefinita dai router locali. Le rotte che puntano al gateway del sito A non sono valide nel sito B dopo un failover.

Abilita il routing multipath in modo che il traffico VIP in uscita utilizzi tutte le porte LIF BGP disponibili.

Riduci il tempo di hold BGP dal valore predefinito di 180 secondi. TR-4949 raccomanda un tempo di hold di 3 secondi. Un router ritira la route da un cluster guasto solo quando scade il timer di hold e, durante un guasto del sistema storage, il router nel sito A rimane online.