Le système de stockage constitue un point de défaillance partagé. Proxmox VE HA protège les VM des locataires contre une panne de l’hôte, mais pas contre une panne du système de stockage qui héberge leurs disques. Une panne de stockage affecte tous les locataires de ce système.

Impossible de vendre une disponibilité supérieure. Sans réplication synchrone et basculement automatique du stockage, un fournisseur ne peut pas proposer un niveau de disponibilité premium avec zéro perte de données et des engagements de disponibilité renforcés.

Isolation des locataires pendant la reprise. Les tests de reprise, de maintenance et de reprise après sinistre ne doivent affecter que les locataires concernés, et non l'ensemble de la plateforme.

Le QDevice nécessite toujours un troisième emplacement. ONTAP Cloud Mediator supprime l'hôte médiateur, et non l'hôte QDevice corosync. Le QDevice requiert un petit hôte Linux accessible par tous les nœuds Proxmox VE sur le port TCP 5403, et n'est pas soumis aux exigences de faible latence de corosync.

Les deux clusters doivent avoir accès à la NetApp Console. Si les clusters utilisent un proxy, installez le certificat d'autorité de certification racine du proxy sur les deux clusters. NetApp recommande d'utiliser un serveur proxy différent pour chaque cluster.

Prévoyez le même comportement en cas de défaillance avec l’une ou l’autre option. Lorsque le médiateur est indisponible, la réplication se poursuit sans perte de données, mais les basculements automatiques et planifiés ne sont pas possibles tant que le médiateur n’est pas de nouveau disponible. Avec ONTAP Cloud Mediator, cela inclut une perte de connectivité entre les clusters et la NetApp Console.

Disponibilité des VM au-delà de la haute disponibilité de l’hôte. Les VM locataires continuent de fonctionner en cas de défaillance du système de stockage qui héberge leurs disques. ONTAP bascule vers le second cluster AFF, et les VM reprennent leurs E/S sur le même stockage partagé sans redémarrage.

Niveau de disponibilité premium. Vous pouvez proposer un service de VM à RPO zéro et à stockage résilient en option, en plus des niveaux standard sur un stockage non protégé dans les mêmes clusters.

Protection et basculement par locataire. Grâce à un stockage protégé distinct pour chaque locataire ou niveau de service, vous protégez, basculez et testez la reprise après sinistre pour chaque locataire indépendamment, sans affecter les autres locataires.

Meilleure utilisation des deux sites. Vous pouvez définir certaines charges de travail comme principales sur le site A et d'autres comme principales sur le site B, afin que les deux centres de données prennent en charge des charges de travail actives.

Aucune perte de données pour les VM stratégiques en cas de panne de stockage ou de site.

Récupération automatisée sans scripts, remontages du stockage ni modifications apportées à /etc/pve/storage.cfg.

Intégré à ONTAP, sans couche logicielle supplémentaire sur les nœuds Proxmox VE.

Opérations quotidiennes à partir d'une seule interface. Storage Manager pour Proxmox provisionne le stockage partagé protégé, et sauvegarde, restaure et clone les machines virtuelles grâce aux snapshots ONTAP et à la technologie FlexClone®.

Choisissez MetroCluster lorsque la totalité, ou presque, des charges de travail sur le stockage nécessitent un RPO nul, par exemple lorsqu'une entreprise exécute uniquement des machines virtuelles critiques sur le cluster, ou lorsqu'un fournisseur de services propose le même niveau de disponibilité à tous ses clients. Vous bénéficiez d'un domaine de protection unique, sans configuration par charge de travail.

Choisissez SnapMirror active sync lorsqu'une partie seulement des charges de travail nécessite un RPO nul, par exemple un niveau premium pour certains locataires, ou lorsque vous devez effectuer un basculement ou tester la reprise après sinistre pour un locataire ou une application à la fois.

SnapMirror active sync pour NAS n'est pas pris en charge sur une configuration MetroCluster. Utilisez une solution pour chaque paire de clusters.

Les recommandations relatives à corosync, QDevice et HA dans cette solution s'appliquent aux deux. Avec MetroCluster, alignez le départage QDevice sur le site qui continue à servir les données lorsque la liaison inter-sites tombe en panne, et utilisez les règles d'affinité des nœuds HA pour maintenir les machines virtuelles sur le même site que leur SVM actif.

MetroCluster IP prend également en charge les LIF VIP avec BGP pour les réseaux de couche 3 entre les sites.

SnapMirror active sync nécessite un temps d'aller-retour inter-cluster (RTT) inférieur à 10 ms. Proxmox recommande une latence corosync inférieure à 5 ms entre tous les nœuds, de sorte que l'exigence corosync fixe la limite de distance pour la solution.

Corosync nécessite une latence faible et constante plutôt qu'une bande passante élevée. Utilisez un réseau dédié à corosync, distinct du trafic de stockage et de migration en direct, afin que les pics d'activité du stockage n'entraînent pas de délais d'attente pour corosync.

Configurez au moins deux liaisons corosync (par exemple, liaison 0 et liaison 1) sur des chemins physiques distincts entre les sites. Corosync utilise Kronosnet pour basculer automatiquement entre les liaisons en cas de défaillance d'un chemin.

Proxmox VE HA détecte généralement une défaillance de nœud et récupère ses machines virtuelles en environ deux minutes, y compris un délai d'expiration de fencing du watchdog de 60 secondes. Lors d'une défaillance de site, le basculement de SnapMirror active sync et la récupération de Proxmox VE HA s'exécutent en parallèle.

Utilisez les règles d'affinité de nœud HA avec des priorités de nœud pour placer les machines virtuelles sur les nœuds du même site que leur stockage principal, et pour leur permettre de basculer vers l'autre site.

Après un basculement de site, définissez la propriété HA failback sur 0 pour les VM concernées jusqu'à ce que vous rétablissiez le stockage. Sinon, HA remigre les VM vers les nœuds du site A dès qu'ils reviennent, alors que le stockage actif se trouve toujours sur le site B.

Assurez-vous que les délais d'expiration des disques du système d'exploitation invité sont plus longs que le temps de basculement prévu, afin que les systèmes invités ne signalent pas d'erreurs d'E/S lors d'un basculement du stockage.

Utilisez les groupes de ressources et les stratégies de sauvegarde pour appliquer la même planification et la même durée de conservation aux machines virtuelles d'un locataire ou d'une application.

Utilisez des sauvegardes cohérentes au niveau des fichiers pour les machines virtuelles qui exécutent l'agent invité QEMU, afin que les systèmes de fichiers invités soient figés avant qu'ONTAP ne crée l'instantané.

SMP gère le stockage actif. Après un basculement de la synchronisation active SnapMirror, effectuez une découverte dans SMP afin qu'il mappe le stockage sur le cluster B avant d'exécuter des opérations de sauvegarde ou de restauration.

Pour une troisième copie en dehors des deux sites, ou pour une conservation plus longue, ajoutez une relation de diffusion asynchrone SnapMirror à partir des volumes protégés, ou utilisez Proxmox Backup Server.

Les snapshots inviolables ne sont pas pris en charge avec SnapMirror active sync, alors n’activez pas le verrouillage des snapshots dans SMP pour les volumes protégés.

Exécutez la VM SMP en tant que ressource HA sur un stockage partagé protégé par SnapMirror active sync, afin que SMP reste disponible après une panne du stockage ou du site.

Enregistrez le cluster Proxmox VE et les deux clusters ONTAP dans SMP, afin que SMP puisse accéder au stockage actif sur l'un ou l'autre site.

SnapMirror active sync pour NAS protège l’intégralité d’une machine virtuelle de stockage (SVM). Vous pouvez protéger tous les volumes de la SVM ou exclure certains volumes. Seuls les volumes FlexVol® sont pris en charge, et la SVM ne peut pas contenir de LUN.

Le SVM secondaire reste inactif, ses LIF étant hors service, jusqu'à un basculement. ONTAP réplique la configuration du SVM, y compris les adresses IP des LIF, les règles d'export et les paramètres NFS, afin que le SVM secondaire présente le même point de terminaison NFS après un basculement.

Le basculement s’effectue sans interruption pour NFSv3 et les versions ultérieures.

SnapMirror active sync pour NAS est actif/passif, de sorte que les machines virtuelles sur les nœuds du site B lisent et écrivent via le réseau intersite vers la SVM principale. Pour les charges de travail actives sur les deux sites, utilisez deux SVM avec des directions de réplication opposées, une principale sur chaque site, et alignez la règle d'affinité de nœud de chaque machine virtuelle sur le site de sa SVM principale.

SnapMirror la synchronisation active pour NAS est prise en charge sur les clusters AFF A-Series et C-Series à deux nœuds.

nConnect. Ouvre plusieurs connexions TCP vers une seule adresse de LIF NFS, par exemple nconnect=4. nConnect fonctionne avec NFSv3 et NFSv4.1 ainsi qu'avec une seule adresse de LIF VIP, ce qui en fait l'option recommandée pour SnapMirror active sync pour NAS, y compris les réseaux de couche 3.

Agrégation de sessions. Regroupe plusieurs LIF de données dans une seule session NFSv4.1, par exemple vers=4.1,trunkdiscovery,max_connect=16. L'agrégation de sessions requiert NFSv4.1 ou une version ultérieure. Utilisez-la uniquement lorsque la SVM protégée possède plusieurs LIF de données auxquelles les clients peuvent accéder sur les deux sites, comme dans un réseau de couche 2 étendu. Pour plus de détails, consultez "Trunking NFS".

Provisionnez le volume dans la SVM principale et sélectionnez la LIF NFS, ou la LIF VIP dans un réseau de couche 3, comme LIF préférée. La SVM secondaire utilise la même adresse après un basculement, de sorte que la définition du stockage reste valide.

Montez le stockage sur tous les nœuds Proxmox VE des deux sites afin que HA puisse redémarrer les VMs sur n'importe quel nœud.

Vérifiez que les règles d'export autorisent les nœuds Proxmox VE sur les deux sites. ONTAP réplique les règles d'export sur la SVM secondaire.

Après la mise en service, vérifiez que le volume est inclus dans la protection de synchronisation active SnapMirror.

Les interfaces logiques BGP (LIF) ne prennent pas en charge le basculement automatique. La redondance est assurée par deux LIF BGP par nœud, chacune établissant une session avec un routeur différent. Si un nœud perd toutes ses sessions BGP pour une SVM, ONTAP déplace la LIF VIP vers un autre nœud disposant d'une session BGP active pour cette SVM.

Utilisez le protocole BGP externe (eBGP) avec un numéro de système autonome privé unique (ASN) pour chaque nœud ONTAP et chaque routeur.

Utilisez un sous-réseau /31 (masque de sous-réseau 255.255.255.254) pour chaque LIF BGP et son routeur. Attribuez l'adresse impaire à la LIF BGP et l'adresse paire au routeur.

ONTAP ne traite pas les routes provenant des routeurs. Configurez les routeurs pour qu'ils acceptent les routes hôtes /32 d'ONTAP et qu'ils n'envoient pas de mises à jour de routage au cluster.

Les nœuds Proxmox VE ne doivent pas partager le même sous-réseau que l'adresse VIP. Un routeur de couche 3 redondant, par exemple avec VRRP ou HSRP, doit être présent sur le chemin entre les nœuds et le stockage.

Configurez les groupes de pairs BGP avec -use-peer-as-next-hop true afin que chaque cluster apprenne sa route par défaut à partir de ses routeurs locaux. Les routes pointant vers une passerelle du site A ne sont pas valides sur le site B après un basculement.

Activez le routage multipath afin que le trafic VIP sortant utilise tous les ports LIF BGP disponibles.

Réduisez le délai de maintien BGP par défaut de 180 secondes. TR-4949 recommande un délai de maintien de 3 secondes. Un routeur retire la route d'un cluster défaillant uniquement lorsque le temporisateur de maintien expire, et pendant une panne du système de stockage, le routeur du site A reste en ligne.