VMware dans le cloud public

Dans cet article nous partageons avec vous nos récents travaux sur les offres VMware de certains Cloud Publics (Microsoft , Google , Amazon et Oracle ) et apportons quelques éléments comparatifs tant sur les opportunités économiques (vs du IaaS classique) que sur les modalités de déploiement et de gestion de telles solutions.

Introduction

VMware est une solution que l’on ne présente plus. La société a une place de leader sur le marché de la virtualisation depuis plus de 20 ans.

20 ans plus tard, le catalogue de produits VMware ne cesse de s’étendre pour virtualiser de plus en plus d’assets du datacenter et faciliter la vie de la DSI avec le Software Defined Datacenter (SDDC) : virtualisation du réseau, stockage, sécurité, centre de données, poste de travail, multiclouds, etc.

Les promesses de consolidation, d’économie, de standardisation, d’agilité et d’évolutivité sont nombreuses pour les entreprises.

Quasiment devenu un standard pour une large majorité des DSI, nous comparerons les avantages et inconvénients des offres actuellement sur le marché du Cloud Public concernant les briques principales permettant à VMware de fonctionner : ESXi et vSphere.

Là encore, les promesses des cloud providers sont nombreuses :

• Provisionnement automatique du cluster VMware en quelques heures,
• Disponibilité dans toutes les régions du monde,
• Maintien en condition opérationnel des nœuds physiques,
• Gestion du cycle de vie des logiciels VMware,
• Souscription facilitée : licence VMware incluses, modèle à la demande ou avec un engagement sur 1 ou 3 ans,
• Interfaces avec des services natifs du cloud provider,
• Intégration de VMware dans la console du cloud provider,
• Migration des workloads facilitée avec VMware HCX, à chaud et sans changer d’adresse IP.

Et pour les DSI ? quels avantages ?

• Un modèle 100% OPEX et l’absence d’investissement lourd,
• Un move to cloud en douceur, sans remettre en cause tout l’écosystème technique,
• Un gain de temps considérable sur le déploiement de l’infrastructure,
• La capitalisation sur des compétences déjà acquises sur VMware,
• Une infrastructure dédiée avec un haut niveau de performance (full flash),
• Une réduction des dépenses par rapport à une infrastructure on-prem ou des services en cloud native,
• Une agilité dans le dimensionnement de cette infrastructure (ajout/retrait de nœud),
• Reprendre la maîtrise sur ses machines VMware via vSphere (en comparaison des offres IaaS natives des Cloud Providers et l’absence de mode console),
• Un allégement de la charge de travail et des compétences pour le maintien en condition opérationnel de VMware,
• L’assurance d’avoir une infrastructure à jour pour se prémunir des dernières failles de sécurité,
• Une mise en œuvre rapide/facilitée d’un plan de reprise d’activité informatique,
• Le déploiement rapide et facilité d’une nouvelle infrastructure VMware pour remplacer un datacenter,
• Le déploiement d’environnements de travail temporaire.

Même si toutes les offres se basent sur les technologies VMware fondamentales, l’intégration des services VMware est différente d’une cloud provider à l’autre et il n’est pas simple de s’y retrouver lorsque qu’on souhaite comparer les solutions.

Cet article a été rédigé sur la base de mon expérience chez des opérateurs de cloud privé et public (CSP), de mission pour des clients finaux, d’échange avec des administrateurs infrastructure, d’échange avec des partenaires ainsi qu’avec VMware. Les informations utilisées sont disponibles auprès des opérateurs en question.

Nous espérons que cette synthèse comparative pourra vous guider dans votre réflexion.

Les solutions VMware dans le cloud public

Les premières offres et solutions VMware sur le cloud public existent pour certaines depuis 2018. Je me rappelle de la première présentation de VMware sur Amazon Web Service à laquelle j’ai pu assister à l’occasion de Re:Invent. A l’époque, je n’avais pas compris l’intérêt de cette offre pour AWS, je pensais qu’ils se tiraient une balle dans le pied en sortant VMC on AWS. Migrer des machines au format VMware sur AWS ? cela revient à ne pas consommer de service managé ?

6 ans plus tard, tous les providers de cloud proposent une implémentation de VMware dans leur catalogue :

• Amazon : VMware Cloud on AWS (VMC)
• Microsoft : Azure VMware Solution (AVS)
• Google : Google Cloud VMware Engine (GCVE)
• Oracle : Oracle Cloud VMware Solution (OCVS)
• IBM : IBM Cloud for VMware Solution
• Alibaba : Alibaba Cloud VMware Service

Dans cet article, nous comparerons les 4 offres leaders sur le marché : Amazon, Google, Azure et Oracle.

Toutes ces solutions permettent aux DSI d’accélérer un mouvement de move to cloud, pour ceux qui suivent un plan de transformation digitale dont la stratégie serait d’externaliser ses applications métiers vers le cloud public.

Il peut s’agir d’une première étape, un premier mouvement, permettant de déplacer facilement ces workloads VMware sans faire de big bang technique et organisationnel, pour ensuite de prendre le temps de moderniser ses applications, au fil de l’eau et en douceur. Ou encore de consolider dans le Cloud Public des workloads « Legacy » au côté d’autres dans formats plus natifs des Cloud Providers (IaaS, PaaS …).

Un modèle de responsabilité partagé avec des engagements de service (SLA)

Les cloud providers proposent un modèle de responsabilité partagée, avec des opérations dont ils ont la charge et la responsabilité, et des opérations qui sont à la main du client. Ils peuvent ainsi proposer des engagements de service fonctions de leur niveau de responsabilité ainsi que de la topologie du cluster VMware.

Administration technique : qui fait quoi ?

Cas général et exception OCVS

Sur AWS, AVS, et GCVE, ne vous attendez pas à disposer du compte root super administrateur vSphere, celui-ci est réservé au cloud provider.

Que le compte s’appelle cloudadmin (AVS et AWS) ou cloudowner (Google), le compte principal à disposition du client dispose de privilèges limités. Impossible de se connecter aux ESXi en ligne de commande, de modifier les politiques de stockage vSAN, d’ajouter des utilisateurs locaux, ou de mettre en maintenance un ESXi ou le cluster vSphere. Inutile car ces opérations sont de la responsabilité du fournisseur, qui gère le déploiement, l’administration, les mises à jour, la sauvegarde des configurations (et non celle des VMs), sur l’ensemble des outils VMware.

Seul Oracle offre tous les accès VMware à son client final, et pour cause, Oracle n’aura plus accès à la couche VMware suite au déploiement de l’environnement. L’intégralité des opérations sont à mener par le client, ce qui offre le contrôle total du déclenchement de toutes les opérations, mises à jour, maintenance du cluster, configuration du stockage et propagation de règles de sécurité dans le cas d’interconnexion entre un vCenter On-Prem et un vCenter sur OCVE.

Donc pour toutes les solutions sauf Oracle, si vos outils de CI/CD, monitoring ou sauvegarde nécessitent des accès privilégiés à vSphere, il faudra soit faire une demande au support, dans le cadre de Microsoft, soit utiliser des comptes de service locaux pré-provisionnés dans le cas de Google et AWS.

Sur l’administration côté cloud provider, l’offre AWS se détache de ses concurrents par le fait que c’est VMware qui opère le maintien en condition opérationnel de l’environnement.

Versions des composants VMware

Comme nous venons de le voir, VMware opère l’infrastructure de l’offre VMware Cloud on AWS. Quel est l’avantage ?

Le gain principal, au-delà de la maîtrise parfaite de sa propre solution, réside dans l’alignement de la roadmap produit, et donc une disponibilité des nouvelles versions VMware plus rapide sur AWS que sur les autres solutions.

Pour donner un exemple concret : vCenter 8.0 a été publiée en octobre 2022 par VMware. A ce jour, la version 8.0 de vSphere est disponible uniquement VMC AWS, là où la dernière version proposée par Azure et Oracle est la version 7.0 U3c, et 7.0 U2d chez Google. Ce critère peut être différenciant important, notamment avec les failles de sécurité impactant VMware ESXi remontées au premier trimestre 2023.

Versions actuellement disponibles :

VMC 8.0.0 / GCVE 7.0 U2d / AVS 7.0 U3c / OCVS 7.0 U3c

Modèle de responsabilité partagée

Voici un tableau illustrant le modèle de responsabilité partagé pour ces 4 solutions :

Bleu : responsabilité du fournisseur
Vert : responsabilité du client

Intégration dans les consoles des fournisseurs

L’intégration dans les consoles GCVE et Azure permettent toutes les deux de déployer l’environnement et de réaliser des opérations de base, comme l’ajout d’un nœud, le déploiement d’un segment NSX, configurer l’authentification vSphere en SSO, etc. Ces opérations sont également possibles via les CLI des fournisseurs.

Oracle et AWS : contrairement aux autres solutions, il n’y a pas d’intégration de VMware dans la console du Cloud Provider. Le seul moyen d’administrer VMware Cloud on AWS est d’utiliser la Cloud Console ou bien vCenter.

Topologie de cluster VMware et engagement de service

Rappel : Infrastructure hyperconvergée et principes de tolérance de panne

Les principes de tolérance de panne évoqués ci-dessous ne sont pas propres au Cloud Public ni à VMware mais concerne globalement toute infrastructure hyperconvergée utilisant du stockage partagé et distribué : VMware vSAN, HPE Simplivity, Nutanix, VXrail, etc.

Rappelons que les solutions proposées sont des architectures de type hyperconvergée (HCI) ou les Hosts (ESXi) embarquent des disques durs, présentés aux nœuds sous forme de volume de stockage virtualisé (vSAN). Dans cette topologie, la tolérance de panne se base sur des mécanismes de réplication des données entre plusieurs nœuds.

Comme le niveau RAID sur disque dur dépend du nombre de disques durs disponibles dans le groupement de disques, le niveau de tolérance de panne dans une infrastructure hyperconvergée dépend du nombre de nœuds disponibles dans le cluster, ainsi que du nombre de copies de la donnée souhaitée.

A minima, le cluster doit pouvoir tolérer la perte ou le retrait d’un nœud sans perte des données et de disponibilité des workloads, à l’occasion d’un incident, d’une maintenance sur un nœud, ou d’une mise à jour de VMware ESXi.

Voici les recommandations VMware pour un environnement on-prem :

• 4 nodes for RAID1 ftt1 (3+1)
• 7 nodes for RAID6 ftt1 (6+1)

Pour un environnement on-prem, le +1 est intéressant car en cas de perte de nœud, le RPO/RTO est garanti avec un nœud de secours, prêt à intégrer le cluster ou déjà présent dans celui-ci. Sur les offres de cloud public, en cas de défaillance d’un nœud, des processus automatiques sont censés exécuter le remplacement automatique d’un nœud en défaut avec tout ce que cela implique comme opération (et des possibles baisses de performance associées) :

• mise en maintenance du nœud ou suppression forcée,
• retrait du nœud du cluster,
• ajout d’un nouveau nœud dans le cluster,
• nouvelle répartition des données entre les nœuds,
• sortie du mode maintenance.

Aussi, les capacités techniques (vCPU, RAM, Disque) du cluster pour exécuter vos workloads dépendra de plusieurs critères :

• Votre politique de tolérance de panne et la configuration vSAN associée (configuration par défaut puis par VM),
• La topologie du cluster (nb de nœuds dans le cluster, espace de stockage brut par nœud, vCPU, vRAM)
• Le respect des seuils des engagements de service (ex : ne pas dépasser 80% de charge CPU ou RAM),
• Les ratio de compression et déduplication vSAN, dépendant de vos données.

Les solutions Oracle, Google et Amazon permettent un démarrage sur 1 nœud, pour un usage hors production, et sans support. Les SLA s’appliquent ensuite à partir de 2 nœuds chez AWS et 3 nœuds chez AVS et GCVE.

Un point de vigilance important : les SLA sont applicables à condition de respecter des seuils de consommation sur les CPU, la RAM, et de stockage. Dit autrement : pour rester dans le cadre des engagements de service, il faut prévoir de la capacité technique libre, non allouée dans son capacity planning et ne pas considérer que tout l’espace libre est utilisable pour mettre des VM. Cela concerne aussi bien le CPU, que la RAM et le stockage.

Pour estimer vos besoins en stockage, vSAN Capacity est un outil intéressant permettant d’estimer l’espace disponible pour vos workloads en fonction de la topologie du cluster vSAN.

Ci-dessous par exemple la comparaison de la répartition du stockage entre un scénario RAID1 / 3 noeuds et un scénario RAID5 / 4 noeuds :

Exemple 1 : Pour un cluster de 3 noeuds, avec une tolérance de panne de 1 noeud (FTT-1), et des VM repliquée sur au moins 2 noeuds (RAID1), compter environ 35% de l’espace brut total disponible pour vos workloads.

Exemple 2 : Pour un cluster de 4 noeuds, avec une tolérance de panne de 1 noeud (FTT-1), et 1 noeud (équivalent 1 noeud) de parité dans le cluster (RAID5), compter environ 50% de l’espace brut total disponible pour vos workloads.

Source : https://kauteetech.github.io/vsancapacity/.

Exemple de SLA

Un exemple d’engagement de service en fonction de la typologie du cluster, sur l’offre GCVE :

Source : https://cloud.google.com/vmware-engine/sla

Les offres techniques

Dans ce chapitre, nous comparerons les configurations techniques possibles pour déployer un cluster, les bases communes à chaque offre, les limites connues, les spécifications techniques.

Chaque solution se base sur des fondations VMware commune, et intègre un serveur vCenter, vSphere, NSX pour la gestion du réseau virtualisé, HCX en version standard ou Enterprise pour gérer la migration de vos workloads. Une fois le setup réalisé, vous disposerez des interfaces VMware traditionnelles, que ce soit via vSphere ou via les API VMware.

Type de nœuds disponibles et coûts

Le tableau ci-dessous donne des informations sur les capacités techniques des nœuds et le coût par mois, pour la région France ou Europe.

A la lecture et en complément de ce tableau :

• Toutes les offres proposent du stockage full flash,
• OCVS dispose du meilleur ratio de capacité technique / coût (mais propose aussi moins de services managés),
• OCVS propose d’un plus grand choix de nœud que ses concurrents, de nœuds ayant le plus de capacité technique, et le plus de région (41),
• A coût équivalent, les nœuds proposés par GCVE sont plus performants que les nœuds proposés par Microsoft,
• GCVE est la seule offre limitée à un type de nœud,
• L’offre GCVE n’est pas disponible en France.

Le choix du type de nœud dépend essentiellement de la typologie de workloads que vous prévoyez de migrer sur l’environnement. Il peut être utile de travailler sur la base d’un gabarit type pour estimer vos besoins. Cette approche vous permettra de comparer des coûts unitaires par VM en fonction des scénarios, et d’avoir une base comparable avec des coûts d’hébergement on-prem ou chez d’autres fournisseurs, ou des coûts de machines virtuelles au format proposé directement par les hyperscalers.

Quelques questions à se poser dans sa réflexion :

• Mon activité nécessite-t-elle un hébergement des données en France ?
• Les besoins entre vCPU, vRAM et stockage sont-ils équilibrés ? Ai-je davantage besoin de vCPU, de vRAM, ou de stockage ?
• Comment va évoluer mon besoin pour ces prochaines années ?
• Quels sont les coûts indirects de mes licences ? (License Windows Datacenter par core?)

D’autres critères peuvent être intéressants à comparer, comme la proportion d’énergie renouvelable utilisée pour alimenter le datacenter du fournisseur de cloud. Certaines régions en Europe ont une proportion très importante d’énergie renouvelable comparées aux énergies fossiles.

Overheads système VMware

A noter que les machines de management VMware pour porter vCenter, NSX et HCX consomment des ressources directement sur le cluster VMware, ressources qui seront par conséquent indisponibles pour vos workloads. Autant HCX peut être utilisé temporairement pour des migrations, autant ce n’est pas le cas pour vCenter et NSX. Plusieurs machines virtuelles sont nécessaires sur chaque nœud pour faire fonctionner le réseau NSX (machines Edge et Manager), machines virtuelles dont la taille est dimensionnée en fonction de la taille des nœuds : plus les nœuds sont gros, plus les besoins réseaux seront importants, plus les machines virtuelles NSX auront des capacités techniques importantes.

Pour un cluster de 3 nœuds, il faut estimer un overheads pour le système VMware d’environ 60 vCPU, 200 Gb de RAM, 2 Tb d’espace disque.

Disponibilité en Région et en France

Sur l’offre AVS, GCVE et VMC, le déploiement de l’offre a été progressif, et ne couvre pas l’ensemble des régions. Chez Oracle, tous les nœuds sont disponibles dans toutes les régions.

Si votre activité nécessite un hébergement sur le territoire François, alors l’offre de Google sera exclue. La disponibilité de GCVE en France ne semble pas prévue dans la roadmap.

Stretched cluster

Contrairement à ses concurrents, Azure ne propose pas d’architecture VMware en Stretched cluster, permettant de la haute disponibilité régionale, ni d’autoscaling du cluster VMware (ajout/retrait de nœud dans le cluster suivant la charge globale du cluster). L’ajout d’un nœud passe par un ticket au support, il faut donc anticiper !

Accessibilité et Landing Zone

Pour accéder à votre environnement VMware chez le cloud provider, il convient de disposer en amont d’une landing zone. En effet, l’environnement VMware seul doit être intégré dans l’architecture réseau pour être accessible, que ce soit pour son management, ou pour que les workloads vSphere puissent communiquer à l’extérieur de VMware.

Les environnements peuvent être créés soit dans les souscriptions existantes (Oracle), soit dans des souscriptions dédiées (AVS, VMC, GCVE).

Les meilleures pratiques pour l’exécution de workloads VMware sur le cloud public

Dans ce chapitre, nous évoquerons les principaux sujets permettant l’exécution et l’exploitation technique de workloads VMware dans les solutions des clouds providers.

Nous aborderons :

• la connectivité réseau,
• la planification de la migration des workloads avec VMware HCX,
• l’évolutivité,
• la sauvegarde,
• la réplication et le DR,
• la supervision.

La connectivité réseau

Que vous choisissiez une offre ou une autre, une des premières étapes de votre déploiement sera d’interconnecter votre datacenter on-premise avec votre nouvelle infrastructure VMware.

Deux options s’offrent à vous :

1. déployer un tunnel VPN IPsec et utiliser Internet,
2. déployer une interconnexion dédiée (Expressroute Global Reach, Direct Connect, Cloud Interconnect, etc.).

Suivant le provider et votre besoin, l’architecture réseau à déployer pour l’interconnexion et pour la migration de vos workloads peut vite s’avérer complexe et nécessiter le déploiement de routeur intermédiaire, à la main du fournisseur).

Dans ce type de projet et bien que ne concernant pas directement VMware, le réseau un élément fondamental à ne pas sous-estimer. Les différents retours d’expérience que j’ai fait avec des clients finaux sont unanimes sur le sujet.

Au sein de VMware, vous serez obligé de configurer et d’utiliser NSX-T. Vous pouvez également compléter en exécutant sur VMware vos machines virtuelles de routage / firewalling (NVA), en prenant là aussi le risque de rendre complexe l’architecture réseau. Il est possible de forwarder vos logs NSX vers un collecteur ou siem de votre choix.

Planifier la migration

Solution HCX, le standard VMware

Pour la migration de vos machines virtuelles, toutes les solutions permettent l’utilisation de VMware HCX, en version Standard ou Enterprise. HCX vous permet de planifier des migrations par lot, avec différentes approches techniques possibles, de la migration à froid avec un changement d’IP, à la migration à chaud sans changer d’IP.

La migration à chaud nécessite de faire une extension de niveau 2 entre le site on-prem et le cluster VMware dans le cloud. Le site on-prem doit respecter un certain nombre de prérequis (Version de vCenter et ESXi, licence VMware Enterprise, réseau NSX, déploiement appliance HCX sur chaque ESXi, etc.). Une architecture réseau spécifique doit être maintenue durant toute la phase de migration.

D’après plusieurs retours d’expérience client, la préparation du site on-prem ne doit pas être sous-estimée pour assurer l’extension du réseau avec HCX. La liste des prérequis est importante : https://docs.vmware.com/en/VMware-HCX/4.5/hcx-user-guide/GUID-741F47D5-A3C9-4D74-9672-E54D8791D8F0.htm

Solutions alternatives pour la migration de vos workloards

Fonction de votre écosystème existant, l’utilisation d’autres solutions compatibles est possible : Veeam, Commvault, Cohesity, Zerto, etc.

Que vous utilisiez ou non la solution HCX, le coût des licences est inclus dans la solution globale.

Les points de vigilances à rappeler :

• la préparation du site on-prem et les prérequis à respecter,
• la configuration du réseau étendu niveau 2 entre le site on-prem et le site de destination NSX,
• la consommation de ressource sur chaque ESXi pour déployer les appliances HCX (minimum 3),
• l’absence de conversion possible vers des formats autre que VMware dans HCX (ec2 ou autre).

 L‘évolutivité

Les solutions techniques permettent un scaling horizontal simple, par l’ajout de nœud ESXi dans le cluster existant. L’ajout d’un nœud permet d’augmenter la capacité technique du cluster sur la partie compute et stockage vSAN, ainsi que le réseau.

S’il le besoin est uniquement d’augmenter le stockage, alors il est possible de présenter au cluster vSphere des volumes de stockage via des services intégrés des cloud provider. Il est par exemple possible de déposer des ISO et des templates VMware sur un volume Blob Azure ou un Bucket S3, qui sera monté comme un datastore et partagé à plusieurs clusters VMware.

Il est aussi possible de présenter un volume Netapp (Cloud Volume ONTAP) sur toutes les solutions : GCVE, AVS, VMC et OCVS.

Les bases de données volumineuses peuvent être hébergées en dehors du cluster, sur des services managés par le cloud provider (Azure SQL Database, AWS RDS, Aurora, etc.).

Il est aussi possible de déployer plusieurs clusters VMware pour permettre d’avoir davantage de capacité technique ou une répartition de son infrastructure dans plusieurs régions.

La sauvegarde

Concernant la sauvegarde de VM, le client en a l’entière responsabilité.

Par défaut, rien n’est configuré dans les offres et les coûts de la sauvegarde n’est pas directement inclus dans les calculateurs en ligne.

Toutes les solutions sont compatibles sur le papier avec les solutions de sauvegarde « native » du cloud provider, bien que celle-ci ne soit pas conçue initialement pour sauvegarder des machines VMware.

Par exemple, vous pouvez utilisez Azure Backup pour sauvegarde vos VM VMware sur AVS. Cela nécessitera le déploiement d’un serveur Azure Backup Server dédié, ainsi que d’un volume de stockage dédié qui sera utilisé comme un repository pour vos backups. Il faut prévoir un coût associé à ce serveur de sauvegarde, son compute et son stockage.

Sur AWS, l’utilisation d’AWS backup est également possible.

Les différents retours d’expérience des fournisseurs, partenaires et clients finaux sont unanimes sur le sujet : en général, l’outil de sauvegarde utilisé n’est pas l’outil natif du cloud provider, mais la solution en place sur l’environnement existant du client. Ces solutions sont nativement prévues pour la sauvegarde de VM au format VMware, elles sont connues et maîtrisées par les équipes en place, et sont certifiées par les cloud providers : Commvault, Cohesity, Veeam, Rubrik, etc.

Configurer ces solutions pour sauvegarder un nouveau cluster VMware dans le cloud public n’est pas compliquée et permet de conserver un écosystème technique cohérent. Cela peut nécessiter le déploiement de proxy, appliance, repository dans le cloud, ou l’utilisation de solution de sauvegarde directement dans le Saas.

Attention aux déploiements de solution de sauvegarde sur la même région que la production, ainsi que coût des flux sortants pratiqués par certains fournisseurs.

La réplication et le DR

Plusieurs options s’offrent à vous.

Sur certaines solutions, vous pouvez déployer des stretched cluster VMware, permettant une recopie de données entre plusieurs régions. Vous pouvez aussi déployer plusieurs clusters dans plusieurs régions et mettre en œuvre la solution historique de VMware : VMware Site Recovery Management, qui a fait ses preuves depuis plus de 15 ans ! VSRM est compatible avec toutes les solutions mais le coût de la licence n’est généralement pas inclus dans le prix des nœuds.

Les autres solutions du marché comme Zerto ou Rubrik sont compatibles et peuvent vous permettre de mettre en œuvre facilement vos plans de reprise d’activité en répliquant vos machines VMware d’un cluster à l’autre. Un avantage pour ces solutions, notamment Zerto réside dans leur capacité :

• à faire de conversion de format pendant la réplication,
• à ordonnancer la configuration et le redémarrage des services (changement d’adresse IP, changement de vlan, démarrage, contrôle, etc.),
• à planifier des tests réguliers,
• à faire des rapports de conformité du plan de reprise d’activité (preuves pour des auditeurs lors d’audit ISO ou PCI, etc.),

Par exemple, il est possible de répliquer une machine dont le format source sera VMware, vers un format de VM Azure ou AWS EC2. Dans le cas, la machine qui sera démarrer dans le cadre du PRA s’exécutera directement au format du cloud provider, et non VMware.

Une solution plus récente sur le marché est VMware Cloud Disaster Recovery (VCDR), qui est une solution plus récente que VSRM et adaptée au cloud public, et qui permet de répliquer et d’orchestrer le redémarrage d’un SDDC complet sur AWS ou sur GCVE.

La supervision

Utiliser la solution de votre choix, ce n’est pas un sujet. Une fois le compte de service provisionné, les outils de supervision standard du marché sauront superviser vos ESXi.

Critères de sélection d’une solution VMware dans le cloud public

Nous comparerons dans ce chapitre les offres sur des critères clés que les entreprises peuvent prendre en compte lors du choix d’une solution, tels que la sécurité, l’évolutivité, la compatibilité, le coût et le support. Sans que cette liste soit exhaustive, voici quelques critères :

La souveraineté : Toutes les offres sont disponibles en France, à l’exception de GCVE.

L’évolutivité : Toutes les offres permettent d’ajouter des nœuds dans le cluster. Parfois c’est automatisé (VMC, GCVE), parfois non (AVS). Oracle propose des clusters jusqu’à 64 nœuds ! Avant d’atteindre ces limites, qui sont les limites VMware, vous préférerez répartir vos workloads sur plusieurs clusters afin de cloisonner des périmètres et limiter des risques.

La disponibilité (stretched cluster) : Toutes les offres permettent de déployer des Stretched Cluster avec des nœuds sur plusieurs sites, à l’exception d’AVS.

Le coût : Meilleur rapport capacité technique / prix pour Oracle, mais des tailles de nœuds qui peuvent dépasser le besoin de plus petite infrastructure. Attention, même si le coût facial d’un noeud Oracle est très bien placé, ne pas oublier qu’il y pas le service managé offert par les autres fournisseurs, coût qui sera porté par votre équipe technique ou un infogérant.

le support : qui de mieux que VMware pour opérer votre plateforme VMware ? un bon point pour l’offre VMware Cloud on AWS, où les équipes VMware travaillent de pair avec Amazon sur la gestion de l’infrastructure. Votre point de contact est directement VMware.

Le contrôle : vous souhaitez être le seul maître à bord ? choisir vos versions ? la planification de vos montées de version ? avoir la main sur les règles de sécurité réseau ? souhaitez-vous opérer vous-même votre infrastructure VMware dans le cloud public ? L’offre OVCS laissera le contrôle complet à votre équipe, quand les autres offres de services sont managées par le fournisseur.

Votre legacy : Vous disposez peut-être déjà d’un contrat et exécuter des services sur AWS, Azure, OCI ou GCE ? Votre stratégie impose de diversifier ou au contraire de consolider vos infrastructures ?

La réversibilité : Toutes les offres se basant sur un format de machines virtuelles VMware classique, le retour arrière on-premise de vos workloads n’est pas un sujet si vous disposez d’une autre infrastructure VMware.

La sécurité : Les mises à jour logiciels du SDDC sont en avance sur VMware Cloud on AWS par rapport aux autres offres. Toutefois, comme vous avez la main sur OCVS, vous être libre de faire des upgrades à votre rythme. A noter que la sécurité logique est de l’entière responsabilité du client dans l’ensemble des offres.

Conclusion

Comme nous l’avons vu dans les chapitres précédents, bien que les offres se basent toutes sur des fondamentaux VMware, les implémentions ont quelques différences.

En prenant en compte uniquement les offres techniques et financière, 2 offres nous semblent se distinguer.

1. VMware Cloud on AWS semble leader, avec l’appui exclusif de VMware pour la gestion de l’infrastructure,
2. OCVS d’Oracle, différenciant des autres par son modèle de responsabilité à la main du client, sa forte disponibilité en région, et la capacité importante des nœuds.

Dans les offres managées, celles de Microsoft et Google semblent être des suiveurs, et n’ont pas l’exclusivité d’avoir VMware à la manœuvre pour opérer la plateforme.

Le point commun à l’ensemble des offres est la rapidité de la migration de vos workloads VMware dans le cloud, et le fait que vos administrateurs systèmes ne seront pas perdus face à une console vSphere. En maximum 2 ou 3 semaines, l’ensemble de l’architecture peut être prête pour recevoir et exécuter vos workloads VMware.

Les points de vigilances importantes à retenir avant de se lancer dans un déploiement VMware dans le cloud public :

• Ne pas sous-estimer la complexité de l’architecture réseau,
• Ne pas sous-estimer la préparation du site on-prem si vous souhaitez utiliser HCX,
• Bien réfléchir au niveau de responsabilité souhaité (contrôle ou délégation ?),
• Bien réfléchir à son écosystème global (supervision, sauvegarde, DR, multi-région, etc.),
• Définir en amont sa feuille de route pour la migration des workloads.

Des nombreux assessment sont disponibles auprès des fournisseurs pour vous aider à qualifier vos projets.

Ci-dessous un tableau de synthèse classant les fournisseurs sur certains critères :

Nous espérons que vous avez apprécié la lecture de cet article. N’hésitez pas à commenter ou nos poser vos questions.