En savoir plus sur le déploiement d'un cluster étendu 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 dans toutes ses différentes régions de domaine de disponibilité. Ces régions assurent intrinsèquement l'isolement des pannes au niveau du centre de données, chaque domaine de disponibilité étant subdivisé en plusieurs domaines de pannes pour vous protéger contre les pannes au niveau du rack. 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, Oracle Cloud VMware Solution prend en charge plusieurs déploiements de domaine de disponibilité dans des régions comportant trois domaines de disponibilité. Dans ce cas, vous pouvez déployer de manière native des clusters étendus vSAN VMware au sein d'une seule région, en tirant parti de HA VMware et de vSAN VMware sans avoir besoin de configurations intersites complexes.

Toutefois, dans les régions publiques OCI avec un seul domaine de disponibilité ou dans les régions Oracle Cloud Infrastructure Dedicated Region (régions OCI Dedicated, 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 de la région contre les pannes de site complètes, une approche différente est nécessaire. Ce guide stratégique présente une architecture validée et gérée par le client pour le déploiement de clusters étendus VMWare vSAN dans plusieurs régions OCI, une solution activée par le contrôle complet de la pile offert par Oracle Cloud VMware Solution.

Remarques :

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

Bien qu'OCI ne propose pas de méthode native ou automatisée pour le déploiement d'un cluster étendu VMware vSAN inter-région, Oracle Cloud VMware Solution le rend possible grâce à sa flexibilité unique. Les clients conservent un contrôle administratif total sur les hôtes VMware vCenter, VMware NSX et VMware ESXi, ce qui leur permet de concevoir et d'implémenter des configurations avancées qui seraient autrement difficiles ou impossibles dans les offres cloud VMware gérées plus restreintes.

Ce guide stratégique fournit des conseils architecturaux et des étapes détaillées pour créer cette configuration puissante à l'aide d'Oracle Cloud VMware Solution.

Comprendre les concepts de base

A quoi sert un cluster étendu vSAN VMware ?

Un cluster étendu vSAN est une configuration VMware qui étend une seule banque de données VMware vSAN logique sur deux emplacements physiquement distincts. Les deux emplacements sont considérés comme des sites actifs-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 garantit la disponibilité du stockage tant qu'un site et le noeud témoin restent opérationnels.

Dans le contexte d'OCI, cette architecture correspond bien aux régions dédiées OCI, qui sont généralement suffisamment proches géographiquement pour répondre aux exigences strictes de faible latence des déploiements étendus VMware vSAN.

Pour plus d'informations, reportez-vous à la documentation officielle de Broadcom : Introduction aux clusters étendus vSAN.

Extension de clusters étendus vSAN à OCI et à Oracle Cloud VMware Solution

Alors que les clusters étendus VMware vSAN s'étendent généralement sur deux sites physiquement distincts, dans 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 dans plusieurs domaines de disponibilité de 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 cloud virtuel (VCN) sous-jacent, qui fonctionne au sein des régions OCI, mais pas entre elles.

Pour atteindre la résilience au niveau de la région et se protéger contre les pannes régionales, les clients utilisant 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 via le réseau dorsal privé d'OCI, permettant 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 proche (comme une région publique OCI) pour terminer la configuration de cluster étendue.

Cette conception permet une disponibilité de site active-active dans l'environnement VMware et garantit des opérations continues même en cas de panne 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 clusters étendus vSAN VMware personnalisés dans plusieurs régions OCI.

La topologie de haut niveau se compose des é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 témoin : emplacement régional distinct pour le déploiement de l'appliance témoin vSAN VMware.

La communication entre ces sites est établie via le réseau dorsal privé d'OCI et OCI FastConnect, qui sont tous deux obligatoires pour répondre aux exigences de faible latence et de bande passante élevée d'un cluster étendu VMware vSAN stable.

Remarques :

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

Le schéma suivant illustre cette architecture.


Description de l'image 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'un cluster étendu VMware vSAN dans Oracle Cloud VMware Solution dans les régions dédiées OCI.

Remarques concernant la mise en réseau

L'un des principaux moteurs de cette architecture est le réseau dorsal OCI robuste qui interconnecte les régions dédiées OCI au sein d'une location client. Cette colonne vertébrale assure la communication à haute vitesse et à faible latence nécessaire pour le trafic de réplication vSAN VMware et la signalisation de signal d'activité entre les sites.

Facteurs clés de la planification :

  • Etablissez des connexions d'appairage à distance (RPC) entre les réseaux cloud virtuels de la région dédiée OCI A et de la région dédiée OCI B à l'aide de passerelles de routage dynamique. Cela permet une connectivité maillée complète sur tous les hôtes VMware ESXi.
  • Utilisez OCI FastConnect (et non le VPN IPSec) pour connecter les deux régions dédiées OCI à la région OCI publique hébergeant le témoin. Cela garantit une faible latence cohérente et un débit fiable pour prendre en charge la communication des témoins.
  • Documentation de référence : Appairage à distance, Gestion des passerelles de routage dynamique, 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
    • Choisissez 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 inférieure à 200 ms RTT vers les deux régions dédiées OCI pour le déploiement Witness.
  2. Sélection de forme
    • Utilisez des formes Bare Metal denses (par exemple BM.DenseIO.E5.128) avec un stockage NVMe local pour VMware vSAN.
    • Evitez les formes standard qui utilisent des volumes de blocs, car elles ne conviennent pas aux déploiements vSAN étendus.
  3. Configuration minimale de l'hôte
    • Région principale : trois hôtes Bare Metal denses au minimum
    • Région secondaire : trois hôtes Bare Metal denses au minimum
    • Région témoin : un hôte Bare Metal
  4. Instructions relatives à l'appareil témoin

Exigences relatives aux clusters étendus

  • Latence RTT < 5 ms entre les régions principale et secondaire
  • Latence RTT < 200 ms entre les deux sites et le nœud Witness
  • Tous les hôtes (y compris Witness) doivent appartenir au même cluster vSAN VMware
  • Le matériel et la configuration de l'hôte doivent être identiques entre les régions
  • Le témoin doit résider dans un troisième emplacement distinct.

Considérations opérationnelles

Les clients sont responsables de l'exécution manuelle des 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 OCI dédiée. Les gestionnaires NSX VMware vCenter et VMware du site secondaire doivent être détachés manuellement et intégrés au cluster principal.
  • Le basculement manuel et les mises à jour de routage 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 implémenter une conception hautement disponible capable de résister à l'échec d'une région OCI Dedicated.

Cette conception utilise deux réseaux cloud virtuels par site, ce qui donne un total de quatre réseaux cloud virtuels :

Région dédiée OCI A

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

    Etant donné qu'un SDDC Oracle Cloud VMware Solution ne peut pas s'étendre sur plusieurs réseaux cloud 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 permet de définir des VLAN pour les sous-réseaux de gestion et de services tout en les regroupant logiquement au sein d'un seul VCN.

  • VCN MGMT Active, en utilisant le même bloc CIDR que le CIDR secondaire attaché au VCN principal, à savoir 172.45.0.0/16.

Région dédiée OCI B

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

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

  • Indiquez un bloc CIDR et autorisez l'automatisation d'Oracle Cloud VMware Solution à créer les composants réseau requis, ou
  • Créez manuellement des réseaux cloud virtuels, des sous-réseaux, des VLAN, des tables de routage et des groupes de sécurité 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 cloud virtuels et régions nécessite la précréation de tables de routage, de groupes de sécurité réseau et de VLAN. Cette séparation prend en charge des responsabilités claires entre les réseaux cloud 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 VCN MGMT de "flotter" entre les deux sites via des mises à jour réseau manuelles lors des événements de basculement, tels que la modification des tables de routage et la réannonce du sous-réseau via des pièces jointes DRG.

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

Pour simplifier le balisage VLAN :

  • Les balises VLAN dans la plage 100 sont spécifiques à la région, limitées à leurs sites respectifs.
  • Les balises VLAN dans la plage 200 sont associées au sous-réseau 172.45.0.0/16 et flottent d'un site à l'autre.

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.