En savoir plus sur le déploiement d'une grappe étendue vSAN VMware dans les régions OCI avec Oracle Cloud VMware Solution

Oracle Cloud Infrastructure (OCI) offre une haute disponibilité et une tolérance aux pannes pour toutes ses multiples régions de domaine de disponibilité. Ces régions assurent de manière inhérente l'isolement des pannes au niveau du centre de données, chaque domaine de disponibilité étant subdivisé en plusieurs domaines d'erreur pour se protéger contre les pannes au niveau du bâti. Cette architecture intégrée répond aux exigences de résilience de la plupart des charges de travail d'entreprise.

Pour les charges de travail VMware, la solution Oracle Cloud VMware Solution prend en charge plusieurs déploiements de domaine de disponibilité dans des régions avec trois domaines de disponibilité. Dans ce cas, vous pouvez déployer des grappes étendues vSAN VMware de manière native dans une seule région, en tirant parti de la haute disponibilité VMware et du vSAN VMware sans avoir besoin de configurations inter-sites complexes.

Cependant, dans les régions publiques OCI ne comptant qu'un seul domaine de disponibilité, ou dans les régions dédiées à Oracle Cloud Infrastructure Dedicated Region (régions dédiées OCI, anciennement appelées Oracle Dedicated Region Cloud@Customer), plusieurs configurations de domaine de disponibilité ne sont pas disponibles. Pour les clients de ces environnements qui ont besoin d'une protection au niveau régional contre les pannes complètes du site, une approche différente est nécessaire. Ce livre de jeu de solution présente une architecture validée et gérée par le client pour déployer des grappes étendues vSAN VMWare dans plusieurs régions OCI, solution activée par le contrôle de pile complet offert par Oracle Cloud VMware Solution.

Note :

Ce modèle de déploiement a été testé avec succès dans les région dédiée OCI. Si les exigences de latence, de forme d'hôte et de connectivité réseau nécessaires sont satisfaites, il peut également être répliqué dans les régions publiques OCI.

Bien qu'OCI n'offre pas de méthode native ou automatisée pour déployer une grappe étendue vSAN VMware inter-région, Oracle Cloud VMware Solution le rend possible grâce à sa flexibilité unique. Les clients conservent le contrôle administratif total sur les hôtes VMware vCenter, VMware NSX et VMware ESXi, ce qui leur permet de concevoir et de mettre en oeuvre des configurations avancées qui, autrement, seraient difficiles ou impossibles dans les offres VMware en nuage géré plus restreint.

Ce livre de jeu fournit des conseils architecturaux et des étapes détaillées pour créer cette puissante configuration à l'aide de la solution Oracle Cloud VMware Solution.

Comprendre les concepts fondamentaux

Qu'est-ce qu'une grappe étendue vSAN VMware?

A vSAN stretched cluster is a VMware configuration that extends a single logical VMware vSAN datastore across two physically separate locations. Les deux emplacements sont considérés comme des sites actifs et la configuration garantit une disponibilité continue en cas d'indisponibilité d'un site. Les machines virtuelles (VM) peuvent basculer automatiquement entre les sites, grâce aux fonctionnalités natives de VMware vSphere HA, et vSAN assurera la disponibilité du stockage tant qu'un site et le noeud témoin resteront opérationnels.

Dans le contexte d'OCI, cette architecture est bien mappée aux région dédiée OCI, qui sont généralement suffisamment proches géographiquement pour répondre aux exigences strictes en matière de faible latence des déploiements étendus vSAN VMware.

Pour plus d'informations, consultez la documentation officielle de Broadcom : Présentation des grappes étendues vSAN.

Extension des grappes étendues vSAN à OCI et à Oracle Cloud VMware Solution

Alors que les grappes étendues vSAN VMware couvrent généralement deux sites physiquement distincts, au sein d'OCI, Oracle Cloud VMware Solution peut déployer un centre de données défini par logiciel (SDDC) VMware dans un seul domaine de disponibilité par défaut ou sur plusieurs domaines de disponibilité dans la même région lorsqu'il est configuré en conséquence. Ce modèle de déploiement s'aligne sur la portée régionale du réseau en nuage virtuel (VCN) sous-jacent, qui fonctionne dans les régions OCI, mais pas entre elles.

Pour assurer la résilience au niveau de la région et se protéger contre les pannes régionales, les clients qui utilisent des régions dédiées à OCI peuvent déployer deux SDDC Oracle Cloud VMware Solution distincts dans des régions dédiées OCI distinctes. Ces SDDC sont interconnectés au moyen du réseau fédérateur privé d'OCI, ce qui permet une communication sécurisée et à faible latence. Le noeud VMware vSAN Witness requis est déployé dans une troisième région géographiquement voisine (comme une région publique OCI) pour terminer la configuration de grappe étendue.

Cette conception permet une disponibilité active-active du site dans l'environnement VMware et assure la continuité des opérations même en cas de défaillance régionale. Il s'aligne sur les meilleures pratiques de VMware et d'Oracle en matière de haute disponibilité et de reprise après sinistre.

Architecture

Cette architecture montre comment déployer des grappes étendues vSAN VMware personnalisées dans plusieurs régions OCI.

La topologie de haut niveau comprend les éléments suivants :

  • Site principal : SDDC Oracle Cloud VMware Solution déployé dans la région dédiée OCI A.
  • Site secondaire : SDDC Oracle Cloud VMware Solution déployé dans la région dédiée OCI B.
  • Site de témoins : Emplacement régional distinct pour le déploiement du boîtier VMware vSAN Witness.

La communication entre ces sites est établie au moyen du réseau fédérateur privé d'OCI et d'OCI FastConnect, qui sont tous deux obligatoires pour répondre aux exigences de faible latence et de bande passante élevée d'une grappe étendue vSAN VMware stable.

Note :

Le RPV IPSec n'est pas pris en charge pour cette configuration.

Le diagramme suivant illustre cette architecture.


Description de ocvs-vsan-stretched-cluster.png :
Description de l'illustration ocvs-vsan-stretched-cluster.png

ocvs-vsan-stretched-cluster-oracle.zip

Les sections suivantes décrivent les principales considérations techniques qui influencent le déploiement réussi d'une grappe étendue vSAN VMware dans Oracle Cloud VMware Solution dans une région dédiée OCI.

Considérations relatives au réseau

Un des principaux moteurs de cette architecture est le réseau dorsal OCI robuste qui interconnecte les région dédiée OCI d'une location de client. Cette dorsale assure la communication à haute vitesse et à faible latence nécessaire pour le trafic de réplication vSAN VMware et la signalisation de pulsation entre les sites.

Facteurs clés pour planifier :

  • Établissez des connexions d'appairage distant entre les réseaux en nuage virtuels de la région dédiée OCI A et de la région dédiée OCI B à l'aide des passerelles de routage dynamique (DRG). Cela permet une connectivité maillée complète sur tous les hôtes VMware ESXi.
  • Utilisez OCI FastConnect (et non un RPV IPSec) pour connecter les deux région dédiée OCI à la région OCI publique hébergeant le témoin. Cela garantit une latence faible constante et un débit fiable pour la prise en charge de la communication des témoins.
  • Documentation de référence : Appairage distant, Gestion des passerelles DRG, OCI FastConnect

Considérations relatives au calcul et au stockage

La planification de l'infrastructure dans les trois régions implique plusieurs décisions :

  1. Sélection de région
    • Sélectionnez deux régions dédiées OCI avec une latence < 5 ms RTT entre elles.
    • Sélectionnez une région OCI publique avec une latence < 200 ms RTT vers les deux région dédiée OCI pour le déploiement de témoin.
  2. Sélection de la forme
    • Utilisez des formes sans système d'exploitation denses (par exemple, BM.DenseIO.E5.128) avec le stockage NVMe local pour VMware vSAN.
    • Évitez les formes standard qui utilisent des volumes par blocs, car elles ne conviennent pas aux déploiements vSAN étendus.
  3. Exigences minimales en matière d'hôte
    • Région principale : Trois hôtes sans système d'exploitation denses au minimum
    • Région secondaire : Trois hôtes sans système d'exploitation denses au minimum
    • Région témoin : Un hôte sans système d'exploitation
  4. Directives relatives aux appareils des témoins

Exigences relatives aux grappes étendues

  • Latence RTT < 5 ms entre les régions principale et secondaire
  • Latence RTT < 200 ms entre l'un des sites et le noeud Witness
  • Tous les hôtes (y compris Witness) doivent appartenir à la même grappe vSAN VMware
  • Le matériel et la configuration de l'hôte doivent être identiques d'une région à l'autre
  • Le témoin doit résider dans un troisième emplacement distinct

Considérations opérationnelles

Les clients sont responsables d'effectuer manuellement les opérations du jour 2. Notes clés :

  • Les environnements Oracle Cloud VMware Solution sont déployés séparément dans chaque région dédiée OCI. Les gestionnaires NSX VMware vCenter et VMware du site secondaire doivent être détachés et intégrés manuellement à la grappe principale.
  • Un basculement manuel et des mises à jour d'itinéraire sont requis en cas de panne du site.
  • VMware La passerelle NSX Tier-0 n'est active que sur un seul site, ce qui implique un modèle actif-passif pour le routage du trafic Nord-Sud.

Aperçu de la conception

S'appuyant sur les sections précédentes qui couvraient l'architecture et les exigences d'une configuration vSAN étendue avec Oracle Cloud VMware Solution, cette section explique comment mettre en oeuvre une conception hautement disponible capable de résister à la défaillance d'une région dédiée OCI.

Cette conception utilise deux réseaux en nuage virtuels par site, soit un total de quatre réseaux en nuage virtuels :

OCI Dedicated Region A

  • VCN Primary avec deux blocs CIDR; par exemple, 10.16.0.0/16 en tant que bloc CIDR principal et 172.45.0.0/16 en tant que bloc CIDR secondaire (ajouté après la création du VCN). Le bloc CIDR secondaire est requis uniquement pour le déploiement du SDDC initial.

    Comme un SDDC Oracle Cloud VMware Solution ne peut pas couvrir plusieurs réseaux en nuage virtuels, un bloc CIDR secondaire (172.45.0.0/16) est attaché au VCN principal dans la région dédiée OCI A. Cela active les définitions de VLAN pour les sous-réseaux de gestion et de services tout en les conservant logiquement regroupées dans un seul VCN.

  • VCN MGMT Active, en utilisant le même bloc CIDR que le bloc CIDR secondaire attaché au VCN principal; c'est-à-dire 172.45.0.0/16.

OCI Dedicated Region B

  • VCN Secondary avec un bloc CIDR distinct de VCN Primary et ne se chevauchant pas; par exemple, 10.17.0.0/16.
  • VCN MGMT Failover, utilisant le même bloc CIDR que VCN MGMT Active; c'est-à-dire 172.45.0.0/16.

Oracle Cloud VMware Solution offre de la flexibilité dans le provisionnement de réseau. Lors de la création du SDDC, les utilisateurs peuvent :

  • Spécifiez un bloc CIDR et autorisez l'automatisation d'Oracle Cloud VMware Solution à créer les composants de réseau requis, ou
  • Créez manuellement des réseaux en nuage virtuels, des sous-réseaux, des réseaux VLAN, des tables de routage et des groupes de sécurité de réseau au préalable, puis sélectionnez ces ressources existantes lors du déploiement.

Pour cette conception vSAN étirée, cette dernière approche est nécessaire. Un contrôle précis de la segmentation du réseau sur plusieurs réseaux en nuage virtuels et régions nécessite la création préalable de tables de routage, de groupes de sécurité de réseau et de réseaux VLAN. Cette séparation prend en charge des responsabilités claires entre les réseaux en nuage virtuels et permet un comportement de basculement transparent.

Un aspect essentiel est que le sous-réseau de gestion (172.45.0.0/16) doit être accessible dans les deux régions dédiées OCI. Pour prendre en charge le basculement, la conception permet à ce réseau de gestion de réseau en nuage virtuel (VCN) de "flotter" entre les deux sites au moyen de mises à jour manuelles du réseau lors d'événements de basculement, tels que la modification des tables de routage et la réannonce du sous-réseau au moyen d'attachements de passerelle DRG.

La résolution de DNS est essentielle pour le basculement et la disponibilité du service. Par conséquent, un sous-réseau de services dédiés sera créé dans chaque VCN pour héberger le DNS et l'infrastructure de soutien.

Pour simplifier le marquage VLAN :

  • Les marqueurs de réseau VLAN dans l'intervalle 100 sont spécifiques à la région, limités à leurs sites respectifs.
  • Les marqueurs de réseau VLAN dans l'intervalle de 200 sont associés au sous-réseau 172.45.0.0/16 et flotteront entre les sites.

Avec la conception de haut niveau définie, nous entrons maintenant dans la configuration pratique de chaque site, en commençant par la région principale.