Migrer des charges de travail depuis le matériel ve1 mis hors service

Ce document explique comment migrer vos charges de travail Google Cloud VMware Engine depuis le matériel ve1 mis hors service vers le matériel ve1 ou ve2 compatible. Vous pouvez migrer des charges de travail à l'aide de l'une des deux méthodes suivantes : l'option 1 consiste à ajouter de nouveaux clusters matériels à un cloud privé existant pour créer un cloud privé à nœuds mixtes, tandis que l'option 2 consiste à déployer un nouveau cloud privé à l'aide d'un nouveau matériel.

Google Cloud met hors service le matériel ve1 de première génération de manière progressive à mesure que l'infrastructure physique arrive en fin de vie. Les mises hors service ont lieu par lots en fonction des groupes de placement dans différentes régions de service.

Lorsque Google Cloud planifie la mise hors service de votre matériel, vous recevez une notification ciblée de fin de vie contenant une chronologie détaillée, des limites de ressources et des instructions de migration. Ces notifications ciblées commenceront à être déployées au premier trimestre 2026, et les premiers lots de matériel ve1 arriveront en fin de vie d'ici le premier trimestre 2027. Lorsque votre groupe d'emplacements atteindra la date de mise hors service prévue, vous pourrez migrer vos charges de travail vers un matériel plus récent.

Ce document décrit les détails de l'avis de fin de vie et les étapes à suivre pour migrer vos charges de travail. Pour assurer la continuité du service et la couverture du contrat de niveau de service (SLA), effectuez la migration avant que vos clusters n'atteignent leur date de fin de vie.

Avant de commencer

Avant de configurer de nouvelles ressources, consultez les exigences, les limites et les facteurs qui pourraient bloquer votre migration dans cette section. Ces informations vous aideront à planifier une migration réussie et à éviter les interruptions de service.

Voici les exigences essentielles à prendre en compte avant de commencer une migration :

  • Fenêtre de migration stricte de 60 jours : Google prend en charge votre migration pendant 60 jours maximum après avoir approuvé votre demande de quota de capacité cible :
    • Vous devez effectuer la migration de la charge de travail et mettre hors service le matériel mis hors service au cours de cette période.
    • Si la durée de migration de votre charge de travail dépasse 60 jours après que vous avez provisionné le cluster cible, vous devez apporter votre propre licence Broadcom (BYOL) pour couvrir toute consommation dépassant les droits standards.

Voici les facteurs qui pourraient potentiellement bloquer votre migration :

  • Bloqueur d'espace d'adresses IP (bloqueur d'option 1) : l'option 1 (cloud privé à nœuds mixtes) nécessite que votre cloud privé existant dispose d'un espace d'adresses IP de gestion libre suffisant. Vous avez besoin d'un espace suffisant pour prendre en charge le cluster cible ajouté, qui nécessite au moins trois nœuds. Si votre bloc CIDR existant ne peut pas prendre en charge au moins trois nœuds supplémentaires, vous ne pouvez pas utiliser l'option 1. Dans ce cas, vous devez déployer un nouveau cloud privé (option 2). Consultez la section Planifier la capacité de l'espace d'adresses IP pour déterminer votre éligibilité.
  • Compatibilité avec la base de données de migration à chaud : certaines plates-formes de base de données ne tolèrent pas les migrations vMotion à chaud. Identifiez ces instances de base de données de VM et prévoyez de les recréer directement sur le cluster cible.
  • Connectivité VMware HCX : les appliances VMware HCX Fleet ne sont pas compatibles avec vMotion standard. Vous devez prévoir de redéployer vos maillages de services HCX sur le cluster cible. Pour en savoir plus, consultez l'article Broadcom Migrating HCX appliances to a different SSO, PSC, or vCenter (Migrer des appliances HCX vers un autre SSO, PSC ou vCenter).

Planifier la capacité de l'espace d'adresses IP

Si vous effectuez la migration à l'aide d'un cloud privé à nœuds mixtes (option 1), vérifiez que votre cloud privé existant dispose de suffisamment d'espace disponible dans la plage d'adresses IP de gestion. Le cluster cible ajouté nécessite au moins trois nœuds.

  1. Affichez la plage d'adresses IP de gestion et la version du plan IP de votre cloud privé. Pour référence, consultez la section Versions de division de la plage CIDR des sous-réseaux.
  2. Comptez le nombre actuel de nœuds dans votre cloud privé.
  3. Vérifiez le nombre maximal de nœuds compatibles avec la taille de votre CIDR. Consultez le tableau Taille de la plage CIDR des sous-réseaux vSphere et vSAN.
  4. Calculez : Existing node count + 3 ≤ maximum nodes supported by CIDR size

Si votre bloc CIDR ne peut pas prendre en charge au moins trois nœuds supplémentaires, vous ne pouvez pas utiliser un cloud privé à nœuds mixtes. Dans ce cas, vous devez déployer un nouveau cloud privé (option 2).

Planifier la capacité des nœuds

Si votre future offre de capacité spécifie ve2 nœuds, collaborez avec votre Google Cloud équipe chargée du compte pour dimensionner et déterminer les types de nœuds ve2 appropriés (mega, large, standard, ou small) et les nombres pour vos charges de travail. Pour connaître les spécifications techniques, consultez la section Types de nœuds HCI VMware Engine.

Exigences concernant les licences et les logiciels

Tenez compte des exigences suivantes concernant les licences et les logiciels pour votre migration :

  • Licences Broadcom : si la durée de migration de votre charge de travail dépasse 60 jours après que vous avez provisionné le cluster cible, vous devez apporter votre propre licence Broadcom pour couvrir toute consommation dépassant vos droits standards.
  • Maillages de services VMware HCX : les appliances VMware HCX Fleet ne sont pas compatibles avec vMotion. Vous devez redéployer vos maillages de services HCX sur le cluster cible. Pour en savoir plus, consultez l'article Broadcom Migrating HCX appliances to a different SSO, PSC, or vCenter (Migrer des appliances HCX vers un autre SSO, PSC ou vCenter).
  • Groupes de placement de gestion : Google provisionne la capacité dans les groupes de placement appropriés. Pour les configurations à nœuds mixtes, l'Cloud Customer Care configure le nouveau cluster dans le groupe de placement cible. Pour les nouveaux clouds privés, envoyez le nom du cloud privé prévu à l'équipe chargée de votre compte avant de créer le cloud privé afin de vous assurer que Google le configure dans le groupe de placement approprié.

Planifier les engagements et la facturation

Avant de sélectionner un chemin de migration, consultez les contraintes suivantes pour les remises sur engagement d'utilisation :

  • Limites des remises sur engagement d'utilisation ve1 : seules les remises sur engagement d'utilisation ve1 d'un an avec des options de tarification de licence portable sont disponibles. Pour appliquer un nouvel engagement d'un an, vous devez migrer vers un nouveau groupe de placement ve1 dans la même région.
  • Compatibilité avec les remises sur engagement d'utilisation ve2 : les engagements de remise sur engagement d'utilisation de trois ans ne sont compatibles qu'avec les familles de nœuds ve2.
  • Vérification de l'éligibilité : étant donné que les nouveaux engagements dépendent de la durée de vie restante des groupes de placement de nœuds dans votre région, vous devez collaborer avec votre Google Cloud équipe chargée du compte pour vérifier votre éligibilité.

Comprendre votre avis de fin de vie ve1

L'avis de fin de vie ve1 est un e-mail officiel qui vous informe que vos nœuds bare metal ve1 arrivent en fin de vie.

Composants clés de l'avis de fin de vie

L'avis inclut les informations suivantes :

  • Région et zone auxquelles s'applique l'avis de fin de vie.
  • Votre utilisation actuelle : liste de tous vos projets actifs et de vos clouds privés ve1 dans la région, avec les détails suivants :
    • Nom du cloud privé
    • Numéro du projet
    • Nom du cluster
    • Type de nœud ve1 (HCI ou SON)
    • Nombre de nœuds ve1 de chaque type
    • Date de fin de vie après laquelle le cluster n'est plus compatible
  • Offre de capacité future : l'avis de fin de vie fournit une offre de capacité future pour chaque ve1 cluster de la région :
    • Si l'offre de capacité cible est ve1 : même nombre de nœuds que dans le cluster ve1 actuel, avec une configuration de durée de vie suffisamment longue.
    • Si l'offre de capacité cible est ve2 : type de nœud ve2-mega-128, offrant des ressources de calcul, de mémoire et de capacité de stockage équivalentes ou supérieures.
    • SLA et tolérance aux pannes (FTT) : pour tout cluster comportant au moins trois nœuds, l'offre future comprend au moins trois nœuds. Cela garantit une valeur FTT par défaut de 1.

Étapes principales de la migration

Votre migration comprend la séquence d'étapes suivante :

  1. Examinez l'offre de capacité cible pour chaque cluster soumis à la fin de vie. Si vous avez besoin d'une configuration différente (types ou quantité de nœuds), collaborez avec l'équipe chargée de votre Google Cloud compte pour ajuster l'offre de capacité.
  2. Gérez les remises sur engagement d'utilisation (CUD) : si vous disposez d'engagements de remise sur engagement d'utilisation ve1 actifs qui dépassent les dates de fin de vie du matériel, collaborez avec votre équipe chargée du compte pour les ajuster ou les résilier.
  3. Sélectionnez votre chemin de migration : choisissez entre la création d'un cloud privé de famille à nœuds mixtes ou le déploiement d'un nouveau cloud privé. Pour vous aider à prendre votre décision, comparez les méthodes de migration dans la section suivante.
  4. Exécutez la migration : migrez vos charges de travail à l'aide du chemin choisi. Vous disposez d'une fenêtre d'assistance maximale de 60 jours pour effectuer la migration après que Google a approuvé votre demande de quota.
  5. Mettez hors service l'ancien matériel : supprimez les clusters ve1 mis hors service et les quotas associés pour terminer la migration.

Comparer les options de migration

Choisir le bon chemin de migration vous aide à configurer correctement votre réseau. Cela vous permet également d'éviter les interruptions de service pendant la migration. Le tableau suivant compare les critères techniques, réseau et opérationnels pour chaque option.

Fonctionnalité Option 1 : Cloud privé à nœuds mixtes (hybride) Option 2 : Déploiement d'un nouveau cloud privé
Description Ajoutez directement des clusters de famille de matériel cible au cloud privé existant. Déployez un cloud privé entièrement nouveau sur le matériel cible.
Exigence concernant la plage d'adresses IP de gestion Nécessite un espace CIDR libre suffisant dans le cloud privé existant pour prendre en charge le cluster ajouté (au moins trois nœuds). Un espace insuffisant est un facteur bloquant pour l'option 1. Flexibilité. Utilise une plage d'adresses IP de gestion entièrement nouvelle.
Impact Mise en réseau et le DNS Minimal. Conserve les réseaux, les sous-réseaux et les interfaces de gestion actuels. Élevé. Nécessite la configuration de nouvelles topologies de réseau, d'un nouveau DNS et de nouvelles coordonnées d'accès.
Workflow de migration VMware vMotion et Storage vMotion standards à chaud. Migrations à grande échelle à l'aide de VMware HCX.
Méthode de création Demandée à l'aide d'un ticket Cloud Customer Care (vous ne pouvez pas ajouter vous-même des clusters à des clouds privés hybrides). Entièrement en libre-service (console, API REST, Google Cloud CLI ou Terraform).

Option 1 : Migration d'un cloud privé à nœuds mixtes

Cette méthode vous permet d'ajouter directement des clusters de famille de matériel cible à votre cloud privé existant et de migrer les charges de travail cluster par cluster. Notez que la limite de migration de 60 jours s'applique à chaque migration de cluster.

Envoyer une demande de quota pour le matériel cible

  1. Dans la Google Cloud console, envoyez une demande de quota pour la nouvelle famille de matériel cible (ve1 ou ve2) et le nombre de nœuds.
  2. Dans la description de la demande de quota, écrivez explicitement les propriétés suivantes :
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
  3. Une fois que Google a approuvé la demande, vous pouvez afficher le nouveau quota dans la console.

Créer le cluster cible dans votre cloud privé

  1. Vous ne pouvez pas créer vous-même des clusters dans des clouds privés à nœuds mixtes. Envoyez une demande d'assistance pour demander la configuration du cluster.
  2. Indiquez les informations suivantes dans la demande d'assistance :
    • Numéro du projet
    • Nom du cloud privé
    • Nom du nouveau cluster cible
    • Nouvelle famille de machines (ve1 ou ve2) et type de nœud
    • Nombre de nœuds HCI
    • Nombre de nœuds de stockage uniquement (le cas échéant)
  3. Cloud Customer Care vous informe lorsque le cluster cible est en ligne.

Migrer des charges de travail

Une fois le cluster cible prêt, utilisez la combinaison de VMware vMotion et de Storage vMotion pour migrer les VM de charge de travail et les disques de VM :

  1. Dans le client vSphere, effectuez un clic droit sur la VM, puis sélectionnez Migrate (Migrer).
  2. Sélectionnez Change both compute resource and storage (Modifier à la fois la ressource de calcul et le stockage).
  3. Choisissez le nouveau cluster et les datastores de destination.

Migrer les VM de gestion du cloud privé

Si le cluster que vous mettez hors service est le cluster principal (premier) du cloud privé, vous devez migrer les VM de gestion :

  1. Utilisez la console Google Cloud VMware Engine ou l'API REST pour migrer les VM de gestion vers le nouveau cluster. Pour obtenir des instructions détaillées, consultez la section Gérer les ressources du cloud privé.
  2. N'effectuez pas d'autres activités de cluster (telles que l'ajout de nœuds) pendant la migration. L'état du cloud privé passe à "Mise à jour en cours" pendant le processus.
  3. Démontez tous les datastores NFS connectés aux anciens clusters ve1.

Ajuster d'autres configurations et applications

  • Maillages de services VMware HCX : les appliances Fleet ne sont pas compatibles avec vMotion. Redéployez les composants du maillage de services HCX sur le cluster cible. Pour en savoir plus, consultez l'article Broadcom Migrating HCX appliances to a different SSO, PSC, or vCenter (Migrer des appliances HCX vers un autre SSO, PSC ou vCenter). Envoyez une demande d'assistance si vous avez besoin d'aide.
  • Applications Aria : migrez les VM d'application Aria de la même manière que les VM de charge de travail standards.
  • Plates-formes de base de données : recréez les instances de base de données sur le cluster cible si elles ne tolèrent pas vMotion.

Mettre hors service le cluster mis hors service

  1. Une fois la migration des charges de travail et des VM de gestion terminée et vérifiée, supprimez le cluster mis hors service à l'aide de la Google Cloud console, de l'API REST ou de la ligne de commande Google Cloud CLI.
  2. Envoyez une demande de quota pour réduire le quota du matériel du cluster source. Dans la description de la demande, spécifiez :
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Option 2 : Migration d'un nouveau cloud privé

Cette méthode vous permet de déployer un cloud privé entièrement nouveau sur le matériel cible et de migrer les charges de travail depuis le cloud privé mis hors service à l'aide de VMware HCX.

Quota de requêtes

  1. Envoyez une demande de quota pour le matériel cible.
  2. Dans la description de la demande, écrivez explicitement :
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
    • "New PC Name: [YOUR_NEW_PC_NAME]"

Créer le nouveau cloud privé

  1. Utilisez la Google Cloud console, l'API REST, la Google Cloud CLI ou Terraform pour déployer votre nouveau cloud privé sur le matériel cible.
  2. Si votre déploiement actuel utilise un réseau VMware Engine hérité (un réseau VMware Engine créé avant novembre 2022), créez le nouveau cloud privé dans le même projet pour continuer à utiliser un réseau VMware Engine hérité. Pour en savoir plus, consultez la section Réseaux Google Cloud VMware Engine standards et hérités.

Migrer des charges de travail à l'aide de HCX

  1. Configurez VMware HCX dans le nouveau cloud privé.
  2. Associez les configurations HCX et configurez les maillages de migration pour déplacer les charges de travail et les données depuis les clusters de cloud privé mis hors service. Si votre cloud privé mis hors service comporte plusieurs clusters, assurez-vous que vos profils de calcul et vos maillages de services HCX sont configurés pour inclure tous les clusters à partir desquels vous devez migrer des charges de travail.
  3. Planifiez les lots de migration pendant les fenêtres de maintenance appropriées.

Ajuster les services et les applications

  • VMware HCX : déployez des maillages de services HCX sur le nouveau cloud privé.
  • Produits Aria : si vous utilisez des suites Aria sous licence Google, demandez de l'aide pour installer Aria Suite Lifecycle Manager (LCM) sur le nouveau cloud privé.

Mettre hors service l'ancien cloud privé

  1. Une fois que vous avez vérifié que toutes les charges de travail fonctionnent dans le nouveau cloud privé, supprimez les anciens clusters et le cloud privé lui-même.
  2. Envoyez une demande de quota pour libérer le quota mis hors service. Dans la description de la demande, spécifiez :
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Gérer les engagements et la facturation

Collaborez avec l'équipe chargée de votre compte pour organiser les structures de facturation et aligner les remises sur engagement d'utilisation pendant la migration.

Ajustements des remises sur engagement d'utilisation

L'impact de vos migrations de matériel ve1 sur vos remises sur engagement d'utilisation ve1 actives dépend des offres de chronologie et de capacité :

  • Chevauchement de la chronologie : si vos engagements de remise sur engagement d'utilisation expirent avant la date de fin de vie du groupe de placement de nœuds actuel, votre facturation ne change pas.
  • Migration sur des nœuds ve1 : si votre offre de capacité cible utilise un nouveau ve1 matériel, vos engagements de remise sur engagement d'utilisation restent valides pendant leur durée.
  • Migration vers des nœuds ve2 : étant donné que les types de remise sur engagement d'utilisation sont liés à des catégories de matériel spécifiques, vous devez collaborer avec l'équipe chargée de votre compte pour résilier ou convertir les contrats actifs ve1 :
    • Remises sur engagement d'utilisation non convertibles : vous devez annuler les remises sur engagement d'utilisation standards existantes et acheter de nouvelles remises sur engagement d'utilisation standards ve2.
    • Remises sur engagement d'utilisation convertibles : vous pouvez convertir les remises sur engagement d'utilisation ve1 standards actives en remises sur engagement d'utilisation ve2 à licence portable.
Utilisation actuelle Chronologie Offre future Impact sur les remises sur engagement d'utilisation
ve1 Toutes les remises sur engagement d'utilisation ve1 expirent avant la fin de vie ve1 ou ve2 Les remises sur engagement d'utilisation existantes ne seront pas affectées.
ve1 Certaines remises sur engagement d'utilisation ve1 expirent après la fin de vie ve1 La migration n'affectera pas les remises sur engagement d'utilisation existantes. Le groupe d'emplacements ve1 cible a une durée de vie suffisante.
ve1 Certaines remises sur engagement d'utilisation ve1 non convertibles expirent après la fin de vie ve2 Vous devez résilier les remises sur engagement d'utilisation ve1 existantes et acheter de nouvelles remises sur engagement d'utilisation ve2. Collaborez avec l'équipe chargée de votre compte.
ve1 Certaines remises sur engagement d'utilisation ve1 convertibles expirent après la fin de vie ve2 Convertissez les remises sur engagement d'utilisation ve1 en remises sur engagement d'utilisation ve2 à licence portable appropriées. Collaborez avec l'équipe chargée de votre compte.

Étape suivante