Migrer des charges de travail depuis le matériel ve1 en fin de vie

Ce document explique comment migrer vos charges de travail Google Cloud VMware Engine du matériel ve1 en fin de vie vers le matériel ve1 ou ve2 compatible. Vous pouvez migrer des charges de travail de deux manières : 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 d'emplacements 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 un calendrier détaillé, 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 atteint sa date de retrait prévue, vous pouvez migrer vos charges de travail vers du matériel plus récent.

Ce document décrit les détails de l'avis d'arrêt 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 toute interruption de service.

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

  • Délai de migration strict de 60 jours : Google vous aide à effectuer votre migration pendant 60 jours maximum après l'approbation de votre demande de quota de capacité cible :
    • Vous devez migrer les charges de travail et mettre hors service le matériel obsolète pendant cette période.
    • Si la durée de migration de votre charge de travail dépasse 60 jours après le provisionnement du cluster cible, vous devez apporter votre propre licence Broadcom (BYOL) pour couvrir toute consommation dépassant les droits d'accès standards.

Voici les facteurs qui pourraient potentiellement bloquer votre migration :

  • Bloqueur d'espace d'adressage IP (bloqueur de l'option 1) : l'option 1 (cloud privé à nœuds mixtes) nécessite que votre cloud privé existant dispose d'un espace d'adressage IP de gestion libre suffisant. Vous avez besoin de suffisamment d'espace pour prendre en charge le cluster cible supplémentaire, 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 Planifier la capacité de l'espace d'adressage IP pour déterminer votre éligibilité.
  • Compatibilité de la migration à chaud avec les bases de données : 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 la migration à chaud 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'adressage 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é doit comporter au moins trois nœuds.

  1. Affichez la plage d'adresses IP de gestion et la version du plan d'adresses IP de votre cloud privé. Pour référence, consultez Versions de la 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/vSAN.
  4. Calculer : Existing node count + 3 ≤ maximum nodes supported by CIDR size

Si votre bloc CIDR ne peut pas accepter au moins trois nœuds supplémentaires, vous ne pouvez pas utiliser de 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 offre de capacité future spécifie des nœuds ve2, contactez votre équipe chargée du compte Google Cloud pour dimensionner et déterminer les types de nœuds ve2 (mega, large, standard ou small) et les nombres appropriés pour vos charges de travail. Pour connaître les caractéristiques techniques, consultez Types de nœuds HCI VMware Engine.

Exigences concernant les licences et les logiciels

Tenez compte des exigences suivantes en termes de licence et de logiciel pour votre migration :

  • Licences Broadcom : si la durée de la migration de votre charge de travail dépasse 60 jours après le provisionnement du cluster cible, vous devez apporter votre propre licence Broadcom pour couvrir toute consommation dépassant vos droits d'accès standards.
  • Mailles de service 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 d'emplacements de gestion : Google provisionne la capacité dans les groupes d'emplacements appropriés. Pour les configurations à nœuds mixtes, le Cloud Customer Care configure le nouveau cluster dans le groupe de placement cible. Pour les nouveaux clouds privés, envoyez le nom prévu du cloud privé à votre équipe chargée du compte avant de créer le cloud privé. Vous vous assurerez ainsi que Google le configure dans le bon groupe d'emplacements.

Engagements et facturation du forfait

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

  • ve1 Limites des remises sur engagement d'utilisation : seules les remises sur engagement d'utilisation ve1 d'un an avec 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.
  • ve2 Compatibilité avec les CUD : les engagements de trois ans avec remise pour utilisation soutenue 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 contacter votre Google Cloud équipe chargée du compte pour vérifier votre éligibilité.

Comprendre l'avis de fin de vie de votre 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 d'un avis de fin de vie

L'avis comprend 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 cluster ve1 de la région :
    • Si l'offre de capacité cible est ve1 : le même nombre de nœuds que dans le cluster ve1 actuel, avec une configuration de durée de vie utile 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, la future offre comprendra au minimum trois nœuds. Cela garantit une valeur FTT par défaut de 1.

Étapes clés de la migration

Votre migration comprend les étapes suivantes :

  1. Examinez l'offre de capacité cible pour chaque cluster concerné par l'arrêt. Si vous avez besoin d'une configuration différente (types ou nombre de nœuds), contactez l'équipe chargée de votre compteGoogle Cloud pour ajuster l'offre de capacité.
  2. Gérez les remises sur engagement d'utilisation (CUD) : si vous avez des engagements de remise sur engagement d'utilisation ve1 actifs qui dépassent les dates de fin de vie du matériel, contactez votre équipe chargée du compte pour les ajuster ou les résilier.
  3. Sélectionnez votre chemin de migration : choisissez entre créer un cloud privé avec une famille de nœuds mixtes ou un nouveau déploiement de cloud privé. Pour vous aider à choisir, comparez les méthodes de migration dans la section suivante.
  4. Exécutez la migration : migrez vos charges de travail en suivant le chemin choisi. Vous disposez d'un délai maximal de 60 jours pour effectuer la migration une fois que Google a approuvé votre demande de quota.
  5. Mettez hors service l'ancien matériel : supprimez les clusters ve1 en cours d'arrêt 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 toute interruption 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é hybride (nœuds mixtes) Option 2 : Nouveau déploiement de cloud privé
Description Ajoutez des clusters de familles de matériel cibles directement au cloud privé existant. Déployez un tout nouveau cloud privé sur le matériel cible.
Exigences concernant la plage d'adresses IP de gestion Nécessite suffisamment d'espace CIDR libre dans le cloud privé existant pour prendre en charge le cluster ajouté (au moins trois nœuds). L'espace insuffisant est un facteur bloquant pour l'option 1. Flexible. Utilise une toute nouvelle plage d'adresses IP de gestion.
Impact Mise en réseau et le DNS Minimal. Conserve les réseaux, les sous-réseaux et les interfaces de gestion actuels. Élevée. Nécessite la configuration de nouvelles topologies de réseau, d'un DNS et de coordonnées d'accès.
Workflow de migration Migration à chaud standard VMware vMotion et Storage vMotion. Migrations à grande échelle à l'aide de VMware HCX.
Méthode de création Demande effectuée à l'aide d'un ticket Cloud Customer Care (vous ne pouvez pas ajouter vous-même de clusters aux 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 des clusters de familles de matériel cibles directement à 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 console Google Cloud , 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, indiquez 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 la demande approuvée par Google, vous pouvez consulter 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 de 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é
    • Nouveau nom du cluster cible
    • Nouvelle famille de machines (ve1 ou ve2) et nouveau type de nœud
    • Nombre de nœuds HCI
    • Nombre de nœuds de stockage uniquement (le cas échéant)
  3. L'assistance Cloud Customer Care vous avertit 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 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 Gérer les ressources de cloud privé.
  2. N'effectuez pas d'autres activités de cluster (comme 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

  • Mailles de service VMware HCX : les appliances de parc 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'applications Aria de la même manière que les VM de charges 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 peuvent pas tolérer vMotion.

Mettre hors service le cluster retiré

  1. Une fois que vous avez terminé et vérifié la migration des charges de travail et des VM de gestion, supprimez le cluster à mettre hors service à l'aide de la console Google Cloud , 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 : Nouvelle migration vers un cloud privé

Cette méthode vous permet de déployer un tout nouveau cloud privé sur le matériel cible et de migrer les charges de travail du cloud privé en cours d'arrêt à 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, indiquez 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 console Google Cloud , 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 ancien réseau VMware Engine (créé avant novembre 2022), créez le nouveau cloud privé dans le même projet pour continuer à utiliser les fonctionnalités réseau standards. Pour en savoir plus, consultez Réseaux Google Cloud VMware Engine standards et anciens.

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 des mailles de migration pour déplacer les charges de travail et les données des clusters de cloud privé en cours d'arrêt. Si votre cloud privé en cours d'arrêt comporte plusieurs clusters, assurez-vous que vos profils de calcul et 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 intervalles de maintenance appropriés.

Ajuster les services et les applications

  • VMware HCX : déployez des mailles de service 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. Après avoir 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 obsolète. 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 votre équipe chargée du compte pour organiser les structures de facturation et aligner les remises sur engagement d'utilisation (CUD) lors de la migration.

Incitations à la double utilisation

Pour vous aider à compenser les frais d'utilisation simultanée (double utilisation) associés à l'exécution de vos empreintes retirées et cibles pendant la période de migration, Google propose des incitations pour atténuer ces frais pendant une période fixe. Planifiez soigneusement votre période de migration pour profiter de ces incitations.

Ajustements des remises sur engagement d'utilisation

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

  • Chevauchement de la période : si vos engagements CUD expirent avant la date de fin de vie du groupe de placement de nœuds actuel, votre facturation ne change pas.
  • Migration sur les nœuds ve1 : si votre offre de capacité cible utilise du nouveau matériel ve1, vos engagements de remise sur engagement d'utilisation restent valides pendant toute leur durée.
  • Migrer vers des nœuds ve2 : les types de remises sur engagement d'utilisation étant liés à des catégories de matériel spécifiques, vous devez contacter votre équipe chargée du compte pour résilier ou convertir les contrats ve1 actifs :
    • Remises sur engagement d'utilisation non convertibles : vous devez résilier 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 avec licence portable.
Utilisation actuelle Chronologie Offre future Impact du CUD
ve1 Toutes les remises sur engagement d'utilisation ve1 expirent avant la fin de vie ve1 ou ve2 Les CUD existants ne seront pas affectés.
ve1 Certaines remises sur engagement d'utilisation ve1 expirent après la fin de vie ve1 La migration n'aura aucune incidence sur les remises pour utilisation soutenue existantes. Le groupe d'emplacements ve1 cible a une durée de vie utile 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 en souscrire de nouvelles ve2. Contactez 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 avec licence portable appropriées. Contactez l'équipe chargée de votre compte.

Étapes suivantes