Google Cloud VMware Engine… L’hybridation du cloud par Google avec VMware

Partie 1 – Introduction à GCP et GCVE

Vous reprendrez bien un peu de Cloud ? Oui mais hybride s’il vous plait !

On connaissait depuis quelques temps VMware Cloud on Amazon Web Service (VMC on AWS), maintenant l’offre est disponible chez les principaux Cloud Provider : Microsoft (on vous en parle ici), Alibaba, IBM, Dell EMC, Oracle et bien sûr Google.

Google Cloud VMware Engine (disons GCVE, c’est plus court) est donc une offre de Google qui propose de mettre à disposition ses serveurs avec la couche VMware par-dessus : du VMware-As-A-Service en quelque sorte.

Qu’est-ce que c’est ?

Remettons les choses un peu dans leur contexte. Google lance fin 2013 son offre Infrastructure-As-A-Service qui permet à ses clients exécuter des VMs sur des serveurs physiques de Google. Le problème c’est que passer d’une infrastructure à l’autre n’est pas si simple (question de format). Alors fin 2019 Google annonce le rachat de CloudSimple, une startup spécialisée dans le développement de Framework permettant d’exécuter des VMs au format VMware sur le Cloud Public (Azure et GCP en l’occurrence). La promesse de Google : permettre à ses clients d’accélérer les projets de migration vers le Cloud Google et de disposer d’une assistance améliorée. Résultat, juin 2020 GCVE est née.

Avec GCVE c’est donc Google qui vend et prend en charge la mise à disposition de l’infrastructure (serveur physique ET socle VMware). Le contrat est passé avec Google uniquement et le client est certain de pouvoir interfacer facilement son nouvel environnement Cloud avec l’ancien On-Premise. Avec l’assistance 24/24, des SLA élevés (99,99 % pour un Cluster sur une zone avec un FTT=2 et 99,9% pour les interfaces d’administration), Google vise clairement la tranquillité d’esprits de ses clients.

Le client peut se concentrer sur ce qui est le plus important pour lui sans être responsable de l’infrastructure nécessaire.

Spécifications techniques

Concernant les spécifications matériel, Google propose un serveur « ve1-standard-72 » dont les caractéristiques sont les suivantes :

• CPU : Intel Xeon Gold 6240 (Cascade Lake) 2,6 GHz (x2), 36 cores (72 hyper-threads)
• Mémoire : 768 GB
• Disques donnés : 19.2 TB (6 x 3.2 TB NVMe)
• Disques de Cache : 3.2 TB (2 x 1.6 TB NVMe)
• Réseau : 4 x Mellanox ConnectX-4 Lx Dual Port 25 GbE sur un réseau redondé avec une bande passante de 100 Gbps

Autrement dit, on est plutôt dans la cour des grands.

Là-dessus, Google gère le déploiement de la stack VMware à savoir :

• ESXi 7.0.1 U1a Entreprise Plus
• vCenter 7.0 U1a Standard
• vSAN 7.0 U1 Entreprise
• NSX-T 3.0.2 Advanced
• HCX 3.5.3 Advanced

Pour vous donner un ordre d’idée sur le cycle de mise à jour, GCVE était en GA (Generally available : mise à disposition générale) fin juin 2020 avec du vSphere/vSAN 6.7 et NSX 2.5. Il y a eu qu’une seule mise à jour importante des composants VMware en décembre 2020 pour basculer en vSphere/vSAN 7 U1 et NSX-T 3. Vous pouvez retrouver l’historique ici.

Evidemment, il n’y a pas que les versions des produits qui sont mis à jour régulièrement, l’ouverture de nouvelles zones géographiques se fait progressivement. Actuellement il y a dix zones disponibles, dont trois en Europe (mais pas encore en France malheureusement).  La carte présentée ci-dessous n’est pas tout à fait à jours mais donne une bonne visibilité. Les sites prévus en Q4 2020 et Q1 2021 sont déjà disponibles.

Pourquoi vous en avez besoin ?

Extension et migration vers le cloud

La migration vers le cloud est une réalité palpable pour la plupart des organisations. C’est complexe, ça prend du temps et demande bien souvent des compétences spécifiques pas toujours présente au sein des organisations qui se lance dans ce genre de projet. Disposer d’un socle d’infrastructure commun entre l’environnement On-premise et celui dans le Cloud est un facilitateur indéniable. Une fois en place, il devient facile d’étendre un Datacenter vers le Cloud et de le faire grossir à la demande.

Infrastructure de virtualisation des postes de travail

Le VDI (Virtual Desktop Infrastructure) est probablement le cas d’usage le plus d’actualité avec la crise sanitaire. GCVE n’est pas du Desktop-As-A-Service puis que le client doit encore déployer et administrer lui-même son environnement VDI. Mais pour avoir déployé bon nombre de VDI, si l’infrastructure de serveur est disponible à la demande, performante et qu’en plus elle est gérée par un fournisseur qui automatise le tout… ça ne peut qu’accélérer le déploiement et l’adoption compte tenu des performances des machines !

Reprise après un sinistre

On l’a dit, GCVE est aujourd’hui disponible dans huit régions réparties en Asie, Amérique du Nord et Europe. N’est-ce pas une bonne base pour préparer un PRA/PCA ? En combinant VMware Site Recovery Manager (SRM) et vSphere Replication vous pouvez tester vos PRA vers le Cloud sans impact sur la production, automatiser vos workflows de Disaster Recovery et établir des RTO sur la base de métrique fiable.

Modernisation des applications

L’une des principales problématiques avec le Fonction-As-A-Service c’est le temps de réponse. GCVE permet de le réduire à 2 millisecondes entre GCVE et un Google Cloud Services (on reste sur la même infrastructure). On ouvre ainsi la voie à des applications hybride où certains services sont hébergés de manière « traditionnel » dans le GCVE et accède à des fonctions Google Services via un VPC dédié.

Partie 2 – Let’s start ?

Quelques prérequis

Avant d’accéder à votre vCenter, il y a tout de même quelques prérequis :

1. Un compte de facturation ; il faut bien payer à un moment…dès le début même !
2. Activer les API pour VMware Engine.
3. Demander l’augmentation de votre quota (sous 48h).

Le compte de facturation

Pour pouvoir utiliser GCVE, il faut déjà avoir un compte google pour pouvoir se connecter à la Google Cloud Console.  Un premier projet sera créé par défaut. Tous les services que vous activez sont liés à un projet spécifique. Je vous suggère donc de le renommer via le menu IAM & Admin \ Settings.

Si aucun compte de facturation n’est associé à votre compte, il faut en ajouter un puis l’associer à votre projet via le menu de navigation de la console dans la section Biling. C’est plutôt intuitif mais si besoin la documentation de Google (https://cloud.google.com/billing/docs/how-to/modify-project) est limpide (et la traduction parfaitement clair). Néanmoins, ce qui est moins bien documenté c’est le fait que vous ne pouvez pas déployer de GCVE si votre compte est un compte d’évaluation de GCP (Free Program). Si vous ne basculer pas votre compte, vous ne pourrez pas demander l’augmentation de votre quota de nombre de Node VMware Engine (on en reparle plus loin, soyez patient). Il faut donc tout de suite cliquer sur le bouton « Upgrade » dans la section Biling pour que votre compte soit effectivement facturable. Mais ne vous inquiétez pas, vous gardez votre crédit d’évaluation.

Les API VMware Engine

Ensuite il faut activer les API VMware Engine. Typiquement cette action est à réaliser pour chaque projet associé à votre compte. Vous pouvez le faire manuellement via la section API& & Service du menu déroulant ou bien cliquer directement sur VMware Engine toujours depuis le menu déroulant. Cela vous emmènera dans un nouvel onglet pour activer les API nécessaires.

Les quotas

Revenons à notre histoire de quota. Cela permet de limiter la surconsommation. Dans le cas de VMware Engine, il s’agit d’un quota au nombre de Node à configurer par région. Par défaut la valeur est à 0. Et comme on le disait plus haut, un compte dans le Free Program n’a pas l’autorisation de modifier le quota. La modification du quota n’est pas instantanée. Cela passe par un processus de validation manuel des équipes Google. Il vous faudra donc attendre un peu avec de pouvoir continuer. Le délai est de 48h maximum, mais dans les faits, vous pouvez contacter directement le support Google pour faire accélérer les choses si le besoin est véritablement urgent.

Là encore, n’oubliez pas que le quota dépend du projet (et de la région).

La console Google Cloud VMware Engine

Création du Private Cloud

À ce stade, vous avez réalisé les trois principaux prérequis (le compte de facturation opérationnel, les API activées, le quota relevé). Depuis la console Google Cloud Plateform, lorsque vous cliquez sur VMware Engine, vous êtes désormais redirigé vers la console GCVE où vous pourrez créer votre premier « Private Cloud » de 3 nœuds minimum, 16 nœuds maximum dans un Cluster (et 64 maximum dans un Private Cloud – https://cloud.google.com/vmware-engine/docs/concepts-private-cloud). Les maximums sont à moduler en fonction de votre quota.

Vous aurez donc besoin de renseigner un nom pour votre Private Cloud, une zone géographique, un nombre de nœuds, un CIDR pour vSphere/vSAN (/21 à /24) et un autre pour HCX (/26 ou /27). Le déploiement se fait en 30 minutes pour la création du Private Cloud. Google fait même encore mieux pour l’ajout d’un nœud à un Cluster : 15 minutes seulement sont nécessaire grâce un mécanisme de Prepovisionning des ressources non utilisées.

RBAC et élévation de privilège

Avant d’accès à la console vCenter, il y deux notions à aborder. La première ce sont les RBAC (Role-Based Access Control) dans la console Google Cloud Plateform. Les RBAC permettent de données des privilège (Admins ou Viewer) à des utilisateurs sur la console Google Cloud VMware Engine. On les configure dans la section IAM pour rendre accessible VMware Engine à un membre de l’organisation.

Ensuite, depuis la console VMware Engine, il est possible de réaliser une élévation de privilège temporaire pour une durée déterminée. C’est nécessaire pour certaines opérations comme la gestion des utilisateurs sur le vCenter (notamment l’ajout de sources identité), la suppression d’un Distributed Port Group, l’ajout d’un compte de service ou d’une solution de sauvegarde. Cette élévation de privilège ne peut être donné qu’à un seul utilisateur à la fois et peut se désactiver automatique si vous essayez de réaliser certaines opérations (supprimer votre Cluster par exemple…). Google donne la liste complète (https://cloud.google.com/vmware-engine/docs/private-clouds/howto-elevate-privilege) des opérations supervisées dans ce cas.

Les consoles VMware
C’est à partir de la console Google Cloud VMware Engine (directement sur la page d’accueil) que vous pouvez lancer votre client vSphere. Dès votre première connexion, il faudra modifier le mot de passe.

Pour accéder à la console NSX-T, toujours depuis la console Google Cloud VMware Engine vous devez :

1. Cliquez sur Ressources dans le menu de navigation
2. Cliquez sur le nom du Private Cloud
3. Dans la section Details, cliquez sur l’onglet vSphere Management Network
4. Cliquez sur le FQDN correspondant à NSX Manager

Les identifiants par défaut sont les suivants :

• vCenter Server et HCX Manager
  • Utilisateur : CloudOwner@gve.local
  • Mot de passe : VMwareEngine123!
• NSX Manager
  • Utilisateur : admin
  • Mot de passe : VMwareEngine123!

Partie 3 – On n’avait pas dit « hybride » ?

Si, on avait dit hybride. Donc il nous faut une connectivité réseau entre les VMs On-Prem, et celles dans GCVE. Pour ça on va devoir disposer d’un VPC associé au projet GCVE, connecter un réseau de ce VPC à GCVE (perring) interconnecter le DC On-Prem avec le Private Cloud.
Chaque élément dépend des autres dans GCP même s’il est possible de partager certaines briques. Un VPC peut par exemple être partagé entre plusieurs projet. Ici faisons simple, voici une représentation schématique des différentes imbrications.

VPC et connexion réseau

VPC sur GCP

Lorsque vous avez créé votre projet GCP, un Subnet associé à votre VPC a été créé pour chaque régions. Si le plan IP prédéfini par Google chevauche votre propre IP plan On-Prem, il faudra recréer un nouveau VPC (https://cloud.google.com/vmware-engine/docs/networking/howto-setup-private-service-access) et définir un Subnet en mode Custom pour définir vous-même le plan IP :

1. Dans la console Google Cloud Plateform, cliquez sur VPC Networks.
2. Cliquez sur Create VPC Network.
3. Renseignez un nom à votre VPC.
4. Sélectionnez Custom pour le champ Subnet Creation Mode.
5. Dans la section New Subnet, spécifiez les paramètres nécessaires :
   1. Renseignez un nom de Subnet.
   2. Sélectionnez une région dans le champ Region (celle où vous avez créez votre Private Cloud GCVE).
   3. Renseignez un Range d’IP dans le champ correspondant.
   4. Cliquez sur Done.
6. Cliquez sur Create.

Segment sur NSX-T

Maintenant qu’on a posé la base du réseau sur GCP, revenons à l’intérieur de GCVE. Les réseaux de vos VMs sont des segments logiques administré par NSX-T. On a vu comment se connecter à NSX-T, maintenant voyons comment créer un réseau pour une VM :

1. Dans le menu de navigation, cliquez sur Segments dans la section Connectivity.
2. Renseignez un nom et sélectionnez Tier 1 dans le champ Connected Gateway & Type.
3. Cliquez sur Subnets.
4. Cliquez sur Add Subnets.
5. Renseignez l’IP de la Gateway du sous réseau associé à votre segment dans le champ Gateway IP/Prefix Length. Par exemple, si vous créez le segment X pour le sous-réseau 10.12.2.0/24, renseignez 10.12.2.1/24.
6. Spécifiez un DHCP Range si nécessaire et cliquez sur ADD.
7. Dans Segment, sélectionnez TZ-OVERLAY | OVERLAY.
8. Cliquez sur Save.

Maintenant les VMs connectées sur ce segment peuvent communiquer entre elles. Si vous créez plusieurs segments connectés à un même Tier 1, elles pourront communiquer d’un segment à l’autre.

Le lien entre le réseau GCVE et VPC GCP

Bon, un réseau logique NSX-T c’est bien, pouvoir en sortir c’est mieux !
C’est là qu’intervient le backbone de Google de 100 Gbps pour prendre en charge l’interconnexion entre le Private Cloud GCVE et votre VPC GCP (à l’intérieur des régions géographique tout comme entre les régions). Ce lien ne se fait pas tout seul, il faut le réaliser manuellement. Il faut d’une par créer une connexion sur la console GCP : une Private Service Connection (https://cloud.google.com/vpc/docs/configure-private-services-access#creating-connection) :

1. Cliquez sur VPC Networks.
2. Sélectionnez le VPC à connecter.
3. Cliquez sur l’onglet Private Service Connection.
4. Créez une allocation IP :
   1. Cliquez sur l’onglet Allocated IP ranges for services.
   2. Cliquez sur IP range.
   3. Renseignez un nom et une description.
   4. Renseignez un IP Range à allouer pour la connexion :
      1. Choisissez le mode Custom pour renseigner vous-même le bloc d’IP au format CIDR.
      2. Choisissez Automatic pour laisser Google choisir les IP sur la base de la taille du sous réseau que vous aurez indiqué.
   5. Cliquez sur Allocate.
5. Créez une connexion de service :
   1. Cliquez sur l’onglet Private connections to services.
   2. Cliquez sur Create Connection.
   3. Dans le champ Assigned allocation, sélectionnez le range d’IP que vous avez alloué.
   4. Cliquez sur Connect pour créer la connexion.
6. Activez import/export de Custom Routes
   1. Cliquez sur l’onglet Private connections to services
   2.  Si la connexion privée a été créée, vous devez voir une connexion avec le nom servicenetworking-googleapis-com.
   3. Dans la colonne Export custom routes, cliquez sur Enbale.
7. Récupérez le Peered VPC ID
   1. Dans le volet de navigation de gauche, cliquez sur VPC network Peering.
   2. Cliquez sur servicenetworking-googleapis-com.
   3. Copiez la valeur du champ Peered project ID dans un bloc note.

Il faut ensuite confirmer cette connexion sur la console GCVE (https://cloud.google.com/vmware-engine/docs/networking/howto-setup-private-service-access) :

1. Cliquez sur Network dans le volet de navigation.
2. Cliquez sur PRIVATE CONNECTION.
3. Cliquez sur Add Private Connection.
4. Dans le champ Tenant project ID, coller le Peered Project ID que vous venez de récupérez depuis la console GCP.
5. Sélectionnez la région sur laquelle se connecter.
6. Cliquez sur Submit.

Lorsque l’état de la région est à Connected, vous pouvez sélectionner la connexion privée à partir du Tenant project ID. L’onglet Private Connection details vous affichera toutes les routes acquises via le Peering VPC. Les Exported Routes indique les réseaux du Private Cloud connu dans la région et exportés lors du Peering VPC.

Désormais vos VMs, sortent du GCVE et ont accès à votre VPC !

La connectivité au site On-Prem

Pour ça il nous faut maintenant connecter le VPC GCP à l’environnement On-Premises. On a donc trois principales options :

• Cloud VPN (https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn) : du Site-to-Site VPN via internet. C’est facile, ça prend peu de temps mais si vous avez besoin d’une faible latence et une d’une grosse bande passante pour construire votre architecture Cloud Hybride hautement disponible, passez votre chemin.
• Dedicated Interconnect : une fibre entre votre réseau On-Prem et les Datacenter Google (sans passer par internet donc) directe / dédiée.

Partner Interconnect : une fibre entre votre réseau On-Prem et les Datacenter Google (toujours sans passer par internet donc). Via un fournisseur (https://cloud.google.com/network-connectivity/docs/interconnect/concepts/service-providers#europe).

Je ne parle pas du Point to Site VPN, qui est un VPN SSL qui permet de connecter un ordinateur via un client VPN au GCVE-.

Dedicated Interconnect

Voici à quoi ça ressemble :

Comme l’indique ce schéma, cela permet de connecter votre environnement On-Prem avec celui de GCP via une liaison dédiée de 10 Gbps. Vous configurez une interconnexion entre votre propre routeur, le réseau de Google via un « Colocation Facility » d’un fournisseur commun à votre DC et ceux de Google. Si vous ne pouvez pas le faire car votre DC n’est pas en mesure d’atteindre physiquement Google, c’est le fournisseur qui s’en charger via son réseau mais dans ce cas on est sur du Partner Interconnect.

Dans le cas du Dedicated Interconnect, une fois la liaison physique établie, une session BGP est configurée à travers l’interconnexion entre votre router On-Prem et le Cloud Router GCP. Le trafic entre les VMs On-Premises et celle dans GCVE peut passer et les VMs peuvent communiquer.

Migration de VM avec HCX

Pour pouvoir utiliser HCX, il faut le préparer sur votre site local. Côté GCVE, Google s’est chargé du déploiement dans votre Private Cloud. Il vous reste à :

1. Téléchargez le connecteur HCX au format OVA.
   1. Accéder à la console GCVE.
   2. Sur la page Ressources, cliquez sur votre cloud privé.
   3. Sur la page vSphere Management Network, cliquez sur l’URL de HCX, puis connectez-vous à HCX Manager Cloud.
   4. Cliquez sur Download OVA.
2. Mettez à jour HCX Manager Cloud vers la version la plus récente disponible à partir de l’interface utilisateur Cloud de HCX Manager.
3. Téléchargez un code d’activation de licence pour le connecteur HCX.
   1. Revenez à la console GCVE, sur la page Ressources, cliquez sur votre Private Cloud.
   2. Sur la page Summary, téléchargez le code d’activation de la licence.
4. Déployer HCX Connector sur votre DC On-Prem.
5. Utilisez le code d’activation.
6. Configurer HCX Connector pour migrer vos VMs (https://docs.vmware.com/en/VMware-HCX/services/user-guide/GUID-BFD7E194-CFE5-4259-B74B-991B26A51758.html).
7. Pensez à étendre votre réseau avec HCX (https://docs.vmware.com/en/VMware-HCX/services/user-guide/GUID-DD9C3316-D01C-4088-B3EA-84ADB9FED573.html) pour éviter le re-ip.

A partir de là, c’est purement du HCX sans spécificité par rapport à GCVE. Il est donc possible de réaliser des opérations de migration tel que :

• vMotion : migration à chaud d’une VMs sans interruption de service
• Cold Migration : migration à froid
• Bulk Migration : Lot de migration de VMs en parallèle (redémarrage de la VM sur le Private Cloud).

Par Stéphane HEBERLE, Consultant Virtualisation & Cloud