À propos de Hybrid Subnets

Hybrid Subnets vous aide à migrer des charges de travail d'un autre réseau (le réseau source) vers un sous-réseau cloud privé virtuel (VPC) sans avoir à modifier les adresses IP. Ce processus de migration est appelé "Migrate Motion". En combinant un sous-réseau du réseau source avec un sous-réseau VPC, vous créez un seul sous-réseau logique qui vous permet de migrer des charges de travail et des instances de machine virtuelle (VM) individuelles au fil du temps. Une fois toutes les charges de travail et toutes les VM migrées, vous pouvez mettre hors service le sous-réseau source.

Dans un sous-réseau hybride, un routeur dans un réseau source et un routeur cloud dans un réseau VPC annoncent des routes à l'aide du protocole BGP (Border Gateway Protocol) (cliquez pour agrandir).

Options de migration

Nous vous recommandons d'utiliser Migrate to Virtual Machines avec Hybrid Subnets pour automatiser le processus de migration des VM à partir d'une source VMware ou à partir d'une source Google Cloud VMware Engine.

Hybrid Subnets n'est pas compatible avec Google Cloud VMware Engine comme cible de migration. Si VMware Engine est votre cible de migration, nous vous recommandons de migrer des VM VMware à l'aide de VMware HCX. Vous n'avez pas besoin de configurer des sous-réseaux hybrides lorsque vous utilisez VMware HCX pour migrer vers Google Cloud VMware Engine.

Vous pouvez également utiliser des outils de migration tiers avec Hybrid Subnets, à condition que les exigences de Hybrid Subnets décrites dans ce document soient remplies.

Pour en savoir plus sur les options de migration, consultez les ressources de migration.

Pour en savoir plus sur la planification d'une migration avec Migrate to VMs, consultez la page Parcours de migration avec Migrate to VMs.

Pour obtenir de l'aide concernant la planification d'une migration vers Google Cloud à l'aide de sous-réseaux hybrides, envoyez une demande d'assistance.

Spécifications

  • Hybrid Subnets nécessite un produit de connectivité réseau tel que Cloud VPN ou Cloud Interconnect.
  • Le proxy ARP doit être configuré dans le réseau source.
  • Le réseau source doit être configuré pour annoncer la plage d'adresses IP du sous-réseau hybride.
  • La plage d'adresses IPv4 principale du sous-réseau VPC doit correspondre à la plage d'adresses IP du sous-réseau source.
  • Vous devez activer le champ allow-cidr-routes-overlap d'un sous-réseau VPC pour configurer le sous-réseau en tant que sous-réseau hybride. Lorsque allow-cidr-routes-overlap est activé, Google Cloud autorise les routes personnalisées à chevaucher les plages d'adresses IP de sous-réseau.
  • L'indicateur allow-cidr-routes-overlap s'applique aux plages de sous-réseaux IPv4 principales et secondaires.
  • La connectivité interne est maintenue entre toutes les VM et les charges de travail d'un sous-réseau hybride.
  • Vous utilisez des routes annoncées personnalisées Cloud Router pour annoncer de manière sélective les adresses IP des VM lorsque vous les migrez vers le sous-réseau VPC.
  • Lorsque vous migrez des charges de travail d'un réseau source vers Google Cloud, vous mettez à jour les routes annoncées personnalisées de Cloud Router pour inclure les adresses IP des VM migrées.
  • Vous pouvez connecter un sous-réseau hybride à un réseau VPC homologue à l'aide de l'appairage de réseaux VPC. La configuration d'appairage du réseau VPC contenant le sous-réseau hybride doit être configurée pour exporter des routes personnalisées. La configuration d'appairage de l'autre réseau VPC doit être configurée pour importer des routes personnalisées.

Limites

  • Les réseaux VPC qui utilisent des sous-réseaux hybrides sont soumis aux limites de ressources suivantes:

    Ces limites de ressources ne sont pas appliquées par des limites ou des quotas Google Cloud . Le dépassement de ces limites peut entraîner des problèmes de connectivité et de stabilité.

  • Le routeur cloud d'un sous-réseau hybride ne peut pas dépasser le nombre maximal de routes annoncées personnalisées par session BGP.

  • Le trafic de diffusion et de multidiffusion dans un sous-réseau hybride n'est pas compatible.

  • Vous ne pouvez pas utiliser les connexions par interconnexion partenaire de couche 3 qui ne sont pas compatibles avec l'annonce de routes /32 avec Hybrid Subnets.

  • Hybrid Subnets n'est pas compatible avec IPv6.

  • Hybrid Subnets ne peut pas héberger des charges de travail sur les adresses IP réservées dans les sous-réseaux IPv4.

  • Le transfert entrant Cloud DNS ne répond pas aux requêtes DNS des charges de travail du réseau source.

  • Les charges de travail du réseau source ne peuvent pas accéder aux API et services Google à l'aide de l'accès privé à Google.

  • Les charges de travail du réseau source ne peuvent pas atteindre les points de terminaison Private Service Connect pour les API Google.

  • Les charges de travail du réseau source ne peuvent pas être des points de terminaison pour les groupes de points de terminaison du réseau de connectivité hybride qui utilisent des vérifications d'état centralisées.

  • Hybrid Subnets n'est pas compatible avec le transfert de données de site à site.

  • Vous ne pouvez pas connecter un sous-réseau hybride à un autre sous-réseau hybride.

  • Les sous-réseaux hybrides ne détectent pas les conflits d'adresses IP entre le réseau source et les parties VPC d'un sous-réseau hybride. Assurez-vous que chaque adresse IP (à l'exception de la passerelle par défaut) n'est utilisée qu'une seule fois.

  • Hybrid Subnets n'est pas compatible avec Google Cloud VMware Engine comme cible de migration.

  • Hybrid Subnets n'est pas compatible avec la migration de VM depuis une source Azure ou AWS.

  • Hybrid Subnets n'est pas compatible avec la migration de charges de travail depuis d'autres fournisseurs de services cloud.

  • Hybrid Subnets n'est pas compatible avec Network Connectivity Center.

Éléments à prendre en compte pour l'utilisation de Hybrid Subnets

Les sections suivantes décrivent les considérations liées à l'utilisation de Hybrid Subnets.

Proxy ARP et Hybrid Subnets

Hybrid Subnets nécessite que le proxy ARP soit configuré sur l'appareil de premier saut du réseau source. Un dispositif de premier saut est le point où un hôte envoie pour la première fois du trafic dont la destination se trouve en dehors de son réseau local. Le proxy ARP permet à l'appareil de répondre avec sa propre adresse MAC lorsqu'il reçoit des requêtes ARP pour les VM situées dans la partie VPC d'un sous-réseau hybride. L'appareil peut ensuite transférer des paquets vers des VM dans le sous-réseau VPC à l'aide des blocs CIDR appris à partir des routes annoncées personnalisées de la session BGP (Border Gateway Protocol) sur le routeur cloud.

L'appareil de premier saut peut être un routeur, un dispositif virtuel, un pare-feu ou une VM exécutant une solution logicielle telle que choparp.

Nous vous recommandons de suivre les conseils suivants pour utiliser un proxy ARP dans votre réseau source:

  • Consultez le fournisseur de votre fabric réseau source pour connaître les bonnes pratiques à suivre pour activer le proxy ARP et sécuriser votre environnement réseau.
  • Désactivez le proxy ARP une fois la migration versGoogle Cloudterminée.

Performances du réseau

Hybrid Subnets utilise la couche 3 du modèle OSI pour acheminer les paquets entre le réseau source et les parties VPC d'un sous-réseau hybride. Cette approche permet à Hybrid Subnets d'éviter les problèmes de latence, de gigue et de débit qui peuvent survenir lors des migrations lorsque certaines charges de travail existent sur un réseau source, mais que d'autres charges de travail ont migré vers le cloud.

En particulier, éviter le tunnellisation de couche 2 permet d'éviter la dégradation des performances associée à l'encapsulation et au chiffrement d'une superposition de couche 2 supplémentaire. De plus, le routage de couche 3 permet à Hybrid Subnets d'éviter un problème courant avec la tunnelisation de couche 2, où le trafic est envoyé à un nœud central avant d'atteindre des destinations proches du point d'origine du trafic. Ce problème est parfois appelé tromboning du réseau.

L'approche de routage de Hybrid Subnets signifie que vous pouvez vous attendre à des performances d'un sous-réseau hybride semblable ou identique à un réseau qui n'utilise pas Hybrid Subnets.

Pare-feu et Hybrid Subnets

Hybrid Subnets évite les problèmes liés à l'utilisation des pare-feu avec un trafic encapsulé dans des superpositions de couche 2. Pour le trafic de couche 2, les pare-feu ne peuvent inspecter les paquets qu'au niveau des points de terminaison de la superposition ou au-delà, sauf si vous prenez des mesures spécifiques telles que le déchiffrement transparent ou les inspections approfondies du trafic de superposition.

L'utilisation de pare-feu et de règles de pare-feu existantes avec Hybrid Subnets ne nécessite aucune mesure particulière. Toutefois, vous devrez peut-être configurer des règles de pare-feu pour vous assurer que les VM Google Cloud peuvent communiquer avec les charges de travail du réseau source.

Tarifs

L'utilisation de Hybrid Subnets est gratuite. Toutefois, les ressources et le trafic réseau de la partie VPC d'un sous-réseau hybride sont facturés.

Pour en savoir plus, consultez la page Tarifs du cloud privé virtuel.

Étapes suivantes