Migrer une infrastructure vers un nouveau vDC

Etape 1.2 Sélectionner vos hosts (compute)

Vous avez maintenant choisi votre gamme commerciale.

Attention, ce choix n'est pas définitif, vous pouvez commencer par 2 hôtes de 96GB de RAM et passer à 3 hôtes de 192GB de RAM.

Etape 1.3 Sélectionner vos datastores (storage)

Vous avez maintenant choisi votre gamme commerciale et vos hosts. Veuillez noter que certains de vos datastores actuels peuvent être compatibles avec les nouvelles gammes, c'est-à-dire que ces datastores peuvent être définis comme globaux. Un datastore global est un datastore partagé sur tous les clusters/vDC au sein d'une infrastructure VMware, c'est-à-dire partagé entre le vDC d'origine et le vDC de destination. Vous pouvez utiliser l'API OVHcloud pour vérifier la compatibilité des datastores :

Résultat attendu : boolean

Si le retour API est TRUE, ce datastore est compatible avec les nouvelles gammes et vous pourrez le conserver. Vous pourrez le définir comme global par la suite dans le processus de mise à jour. Si le retour API est FALSE, ce datastore n'est pas compatible, vous devrez commander de nouveaux datastores, VMware On OVHcloud datastores.
En fonction de vos besoins en capacité de stockage, vous pouvez choisir le type et le nombre de datastores à commander.

Il vous suffit de remplacer les datastores qui ne sont pas compatibles. Il vous sera possible de libérer les datastores qui ne sont pas compatibles à la fin du processus.

Veuillez noter que ce choix n'est pas définitif, vous pouvez commencer par 4x3Tb et passer à 2x6Tb par la suite.

Etape 2.2 Ajouter des nouveaux hosts et datastores

Au sein de l'espace client OVHcloud, vous devriez voir votre nouveau vDC dans votre infrastructure. vous pouvez procéder à la commande des nouvelles ressources (sélectionnées à l'étape 1) dans le nouveau vDC de destination en suivant ce guide d'informations sur la facturation Private Cloud.

Etape 2.3 Convertir une datastore comme global

Vous avez maintenant de nouveaux datastores dans le nouveau vDC de destination ainsi que des datastores compatibles dans votre vDC existant (étape 1.3). Vous pouvez procéder à la conversion en datastore global.

Exécutez l'API OVHcloud pour convertir les datastores en global:

Résultat attendu : Informations de tâche

Etape 3.2 Gérer les droits des utilisateurs

Dans le cycle de vie du vDC d'origine, une liste d'utilisateurs peut avoir été créée pour des besoins métiers, ou des besoins organisationnels. Ces utilisateurs seront également présents sur le nouveau vDC mais n'auront aucun droit sur ce nouveau vDC. Vous devrez donc attribuer les droits appropriés aux utilisateurs, en fonction de la configuration du vDC de destination.

Consultez à cet effet nos guides pour changer les droits d'un utilisateur, modifier le mot de passe d'un utilisateur et associer un e-mail à un utilisateur.

Etape 3.3 Activer les options Veeam Managed Backup & Zerto Disaster Recovery

Ces options sont à activer et à configurer par vDC. Vous devez activer la/les option(s) concernée(s) sur le nouveau vDC.

Etape 3.4 Vérifier votre réseau (vRack, IP publique)

Etape 3.4.1 vRack

Par défaut, dans le cadre d'une migration, le nouveau vDC sera lié au même vRack que le vDC d'origine. Consultez notre guide sur l'utilisation de Hosted Private Cloud au sein d'un vRack.

Etape 3.4.2 Réseau publique

Les adresses IP publiques attachées au vDC d'origine seront automatiquement disponibles pour une utilisation dans le vDC de destination.

Etape 4.2 Reconfigurer VMware Distributed Resource Scheduler (DRS)

L'installation d'un nouveau vDC de destination implique la reconfiguration de la fonction VMware DRS (Distributed Resource Scheduler), en particulier des règles d'affinité ou d'anti-affinité pour les groupes d'hôtes et de VMs. Consultez notre guide sur la configuration de VMware DRS.

Voici une liste des éléments à prendre en compte :

• Niveau d'automatisation
• Groupes de VMs / d'hôtes
• Règles d'affinité / d'anti-affinité des VMs / hôtes
• Remplacements des machines virtuelles

Conseils d'automatisation : Ce fil de discussion de la communauté VMware détaille les options d'exportation et d'importation des règles d'affinité via powercli.

Etape 4.3 Reconstruire vos resource pools

L'installation d'un nouveau vDC de destination nécessite la reconstruction des pools de ressources, notamment les réservations, les partages et les applications virtuelles. Cela s'applique également aux vApps et à toute configuration de commande de démarrage définie dans les vApps.

Pour plus d'informations, consultez la documentation de VMware pour la gestion des pools de ressources.

Voici une liste d'éléments à prendre en compte:

• Paramètres des partages CPU/mémoire
• Réservations CPU/mémoire
• Option évolutive CPU/Memory
• Limites CPU/mémoire

Conseils d'automatisation : L'applet de commande Powercli « Get-ResourcePool » rassemble les informations de la liste de ressources partagées et l'applet de commande « New-ResourcePool » recrée la liste de ressources partagées sur le vDC de destination.

Etape 4.4 Recréer vos Datastores Clusters (si pertinent)

Si des clusters de datastores sont présents dans le vDC d'origine, l'installation d'un nouveau vDC de destination peut nécessiter la recréation de ces clusters de datastores sur le vDC de destination, si le même niveau de structure et le SDRS sont nécessaires.

Voici une liste des éléments à prendre en compte:

• Niveau d'automatisation SDRS
• Espace SDRS, I/O, règle, stratégie, paramètres d'évacuation des VMs
• Règles d'affinité/anti-affinité SDRS
• Modifications des VMs SDRS

Etape 4.5 Activer vSAN (si pertinent)

Si vSAN était activé sur votre vDC d'origine, il sera nécessaire de l'activer à nouveau sur le vDC de destination. Consultez notre guide pour mettre en œuvre l'hyperconvergence VMware avec vSAN.

Etape 4.6 Recréer votre configuration réseau vSphere

L'installation d'un nouveau vDC de destination implique la recréation des groupes de ports virtuels de vRack sur le vDC de destination pour garantir la cohérence du réseau de VMs. Si des VLAN vRack sont en cours d'utilisation sur le vRack du vDC d'origine, ils peuvent être utilisés pour étendre le domaine L2 au vDC de destination afin de permettre un plan de migration plus échelonné. Pour plus d'informations, consultez notre guide sur l'Utilisation du cloud privé dans un vRack.

Voici une liste des éléments à prendre en compte:

• Type de VLAN de groupe de ports
• Paramètres de sécurité (Important dans le cas où le mode promiscuité (promiscuous mode) est nécessaire)
• Paramètres de Teaming et de Failover
• Allocation des ressources réseau du client

Pour plus d'informations, consultez le guide OVHcloud sur comment créer un V(x)LAN dans un vRack et la documentation de VMware sur comment modifier les paramètres des groupes de ports distribués.

Conseils d'automatisation : L'applet de commande Powercli « Export-VDPortGroup » peut récupérer des informations de Portgroups virtuels distribués qui peuvent ensuite être importées dans le Distributed Switch de destination à l'aide de l'applet de commande « New-VDPortgroup -BackupPath ».

Etape 4.7 Vérifier l'organisation de votre inventaire (si pertinent)

Pour des raisons organisationelles, les VMs, les hosts ou les datastores peuvent avoir été placés dans des répertoires.

Si cette organisation est toujours nécessaire, il vous faudra la créer à nouveau dans le vDC de destination.

Etape 4.8 Migrer NSX-V vers NSX (si pertinent)

Dans le cadre d'une migration NSX-V vers NSX, si vous utilisez un des services ci-dessous, voici comment effectuer cette migration en détails.

Dans un premier temps, nous vous invitions à consulter notre documentation sur les premiers pas avec NSX.

Etape 4.8.1 NSX Distributed Firewall

Il est extrêmement important de comprendre que les objets placés dans le pare-feu distribué correspondront à l'ID d'objet significatif en local. Par exemple, si un groupe de ports VLAN vRack est utilisé dans une règle dans le pare-feu distribué, il référencera le groupe de ports à partir du vDC d'origine uniquement et non à partir d'un groupe de ports vRack recréé dans le vDC de destination.

Il sera nécessaire de vérifier si le pare-feu distribué contient des objets significatifs en local et de modifier le pare-feu distribué afin qu'il puisse également voir les objets dans le nouveau vDC. Par exemple, une règle qui utilise un groupe de ports VLAN vRack à partir du vDC d'origine peut être modifiée pour utiliser à la fois le groupe de ports VLAN vRack d'origine et le nouveau groupe de ports VLAN vRack dans le vDC de destination.

Les objets devant être considérés :

• Clusters
• Datacenters
• Groupes de ports distribués
• Groupe de ports Legacy
• Resource Pool
• vApp

Pour plus d'informations, consultez notre documentation sur la gestion du pare-feu distribué dans NSX.

Etape 4.8.2 NSX Distributed Logical Router

L'objet Distributed Logical Router de NSX V n'a pas de réel équivalent dans NSX. Pour migrer les Distributed Logical Routers, il faut directement faire le routage dans les Gateways T1 directement.

Etape 4.8.3 NSX Edges

De manière générale, en fonction du nombre de Edges déployées via NSX-V dans le vDC source, il conviendra de créer des T1 gateway dans NSX sur le vDC de destination. Cependant, il peut être aussi intéressant de prendre du recul afin de revoir l'architecture réseau mise en place pour faire correspondre au mieux les besoins dans le nouveau produit NSX.

De plus, si votre production nécessite de n'avoir aucune interruption de service, des solutions peuvent être mises en place pour éviter ces coupures.

Dans ces deux cas et comme indiqué plus haut, notre équipe Professional Services peut vous accompagner dans cette démarche.

Etape 4.8.3.1 Créer les T1 et les segments

Pour créer les T1, suivez cette documentation. Ce guide vous aiguillera aussi sur la façon de créer les segments. Avant de créer les segments, il est nécessaire de faire l'inventaire des VXLANs utilisés dans le vDC source et de créer un segment pour chaque VXLAN utilisé sur votre infrastructure.

Il suffit ensuite de les relier à la T0 fournie dans NSX.

Pour plus d'informations, consultez notre documentation sur la gestion des segments dans NSX.

Il est aussi possible de créer des segments de type VLAN et les relier au vRack via la Transport Zone ovh-tz-vrack.

Par la suite, pour pouvoir contacter le vRack via NSX, il faut positionner les segments VLAN soit au niveau des T1, soit au niveau des T0 avec des interfaces de type Service.

Etape 4.8.3.2 DHCP

Pour recréer les DHCP et les associer à vos segments puis à vos T1, consultez notre guide sur la configuration du DHCP dans NSX.

Etape 4.8.3.3 DNS

Pour recréer les DNS et les associer à vos T1, consultez notre guide sur la configuration du redirecteur DNS dans NSX.

Etape 4.8.3.4 Règles NAT

Pour recréer vos règles NAT et les associer aux T1, consultez notre guide sur la mise en place du NAT pour des redirections de ports avec NSX.

Etape 4.8.3.5 Load Balancing NSX

Pour recréer vos Load Balancer, suivez les indications de notre guide sur la configuration du Load Balancing dans NSX.

Etape 4.8.3.6 Pare-feu des passerelles T0 T1

Pour recréer les règles de pare-feu associées à vos anciennes edges, consultez notre guide sur la gestion du pare-feu des passerelles dans NSX.

Etape 4.8.3.7 VPN

Etape 4.8.3.7.1 IPSec

Pour recréer vos sessions IPsec, consultez notre guide sur la mise en place d'un tunnel IPsec avec NSX.

Etape 4.8.3.7.2 SSL VPN

Si vous utilisez la fonctionnalité SSL VPN, cette fonctionnalité n'existe malheureusement plus sur NSX. Des alternatives opensource sont néanmoins disponibles, telles que OpenVPN, OpenConnect VPN, WireGuard, etc.

Ces applications réseau sont à monter sur des VMs dédiées hébergées sur votre Hosted Private Cloud. Chaque client est ensuite à installer sur les postes des collaborateurs afin qu'ils puissent de nouveau accéder à leur VPN.

Etape 4.8.3.8 Reconfiguration du bloc IP initial

Pour cette étape vous aurez besoin de deux éléments :

• le bloc IP initialement associé au vDC NSX-V.
• l'IP publique de la VIP associée à la T0 de NSX (visible dans Networking > Tier-0 Gateways > ovh-T0-XXXX > dépliez > HA VIP Configuration > cliquez sur 1 > section IP Address / Mask)

Par la suite, depuis votre espace client OVHcloud, suivez les indications de notre guide « Déplacer une Additional IP » pour déplacer le bloc initial NSX-V sur le service PCC que vous migrez, tout en précisant comme next hop l'IP de la VIP de la T0 récupérée précédemment, comme sur l'exemple ci-dessous :

Etape 4.9 Etendre la protection Zerto Disaster Recovery Protection (si pertinent)

Zerto Replication est configuré au niveau du vDC. Afin de protéger la charge de travail sur le nouveau vDC, certaines actions sont nécessaires.

Prérequis :

• Avoir un nouveau vDC
• Disposer sous le nouveau vDC d'un cluster host avec le nombre de hosts requis (identique au cluster source et au minimum deux hosts)
• Avoir sous le nouveau vDC un datastore accessible depuis les 2 hosts
• Avoir activé Zerto Replication sur le nouveau vDC

Exécutez l'API OVHcloud pour préparer la migration :

{datacenterId} est le nouvel id vDC, vous pouvez l'obtenir avec l'appel API suivant :

Une tâche est lancée sur l'infrastructure pour déployer vRA sur chacun des hosts du nouveau vDC.

Ensuite, Zerto Replication fonctionnera sur les deux datacentres :

• l'ancien est toujours en cours d'exécution et protège votre charge de travail
• le nouveau est prêt à accueillir votre charge de travail

L'étape suivante dépend de la configuration actuelle par groupe de protection virtuelle :

• source de la réplication
• destination de la réplication

Etape 4.9.1 VPG Source

Avec la migration sur le nouveau vDC, Zerto continuera de protéger la charge de travail avec vRA déployé sur le cluster et les hôtes cibles.

Etape 4.9.2 VPG Destination

Malheureusement, il n'y a aucun moyen de mettre à jour la configuration de VPG, la seule option est de supprimer le VPG et d'en créer un nouveau.

Etape 5.2 vMotion

Comme le vDC d'origine et le vDC de destination se trouvent dans le même vCenter, VMware vMotion peut être utilisé à chaud ou à froid pour migrer des VMs.

Hot vMotion peut être utilisé lorsque le chipset du CPU est le même entre la source et la destination (par exemple Intel à Intel).

Cold vMotion peut être utilisé lorsque le chipset du CPU est différent entre la source et la destination (par exemple, AMD à Intel).

Voici une liste des aspects à prendre en compte:

• Chipsets de CPU hôte ESXi sur les vDC d'origine et de destination
• Modes EVC sur les clusters d'origine et de destination
• Les versions vDS sont les mêmes entre le vDC d'origine et le vDC de destination. Il est possible de mettre à jour le vDS vRACK du vDC d'origine. Pour le vDS avec le VM Network (VXLAN vDS), veuillez contacter le support afin que le vDS soit mis à jour.

Etape 6.2 Reconfigurer Zerto Disaster Recovery (si pertinent)

Exécutez l'API OVHcloud pour finaliser la migration :

{datacenterId} est le nouvel id vDC, vous pouvez l'obtenir avec l'appel API suivant :

Une tâche est lancée pour :

• Vérifier si aucun VPG de destination n'existe encore sur le datacentre : ils DOIVENT être retirés.
• Basculer l'option Zerto Replication (souscription) de l'ancien vers le nouveau vDC.
• Retirer tous les vRA des hôtes sur l'ancien vDC.

Etape 6.3 Recréer les règles d'affinité

Les règles d'affinité sont basées sur des objets de VM de sorte que les règles ne peuvent être créées qu'après la migration des VMs vers le vDC de destination. Une fois la migration terminée, les règles d'affinité peuvent être réappliquées sur le vDC de destination.

Conseils d'automatisation : Ce fil de discussion de communauté VMware détaille les options d'exportation et d'importation des règles d'affinité via powercli.

Etape 6.4 Reconfigurer la Private Gateway (si pertinent)

Pour changer la Private Gateway de virtual datacenter (vDC), pour devez d'abord la désactiver en suivant les étapes du guide pour désactiver la private gateway.

Puis activez de nouvelle celle-ci en en suivant les étapes du guide pour activer la private gateway et en choisissant le datacenterId du nouveau vDC.

Etape 6.5 Passer les hosts en mode maintenance

Vous devez mettre les hôtes en mode maintenance en procédant comme suit :

1. Dans le client vSphere, accédez à Hosts and Clusters.
2. Accédez à un Host.
3. Faites un clic droit sur le Host.
4. Accédez à Maintenance Mode.
5. Cliquez sur Enter Maintenance Mode.

Répétez l'action pour chaque hôte.

Etape 6.6 Supprimer les anciens datastores

À cette étape, on peut considérer qu'il n'y a plus de données et/ou de VM sur l'ancien vDC, donc on peut supprimer des ressources.

Dans les instructions suivantes, {datacenterId} est l'ancien id vDC, vous pouvez l'obtenir avec l'appel API suivant :

Avec l'API, obtenez la liste des ID du filer (datastore) :

Puis pour chaque ID :

Dans le cas d'un datastore global, vous pouvez utiliser l'appel API suivant :

Une tâche est créée pour chaque appel, vous pouvez suivre l'avancement avec :

Etape 6.7 Supprimer les anciens hosts

Dans les instructions suivantes, {datacenterId} est l'ancien id vDC, vous pouvez l'obtenir avec l'appel API suivant :

Avec l'API, obtenez la liste des ID d'hôte :

Puis pour chaque ID :

Une tâche est créée pour chaque appel, vous pouvez suivre l'avancement avec :

Etape 6.8 Supprimer le vDC source

Dans les instructions suivantes, {datacenterId} est l'ancien id vDC, vous pouvez l'obtenir avec l'appel API suivant :

Avec l'API, demandez la suppression du vDC :