À propos de la migration vers Google Cloud avec Hybrid Subnets

Cette page explique comment utiliser le routage de sous-réseau hybride pour migrer des charges de travail vers Google Cloud.

Le routage de sous-réseaux hybrides permet à un réseau VPC de partager un bloc CIDR avec un réseau sur site connecté. Si un paquet correspond à une route de sous-réseau hybride, mais que l'adresse IP de destination n'est pas associée à une ressource de ce sous-réseau,Google Cloud peut acheminer le paquet vers le réseau sur site à l'aide de routes dynamiques ou statiques.

Cette configuration vous aide à migrer progressivement les charges de travail vers Google Cloudsans avoir à modifier leurs adresses IP. Pendant la migration, les charges de travail migrées vers votre réseau VPC peuvent communiquer avec celles qui restent dans le réseau sur site à l'aide d'adresses IP internes. Une fois toutes les charges de travail migrées, vous pouvez désactiver le routage de sous-réseau hybride pour rétablir le comportement de routage normal.

La migration vers Google Cloud avec les sous-réseaux hybrides nécessite trois composants distincts qui fonctionnent ensemble :

  • Connectivité : vos réseaux sur site et VPC doivent être connectés par un produit de connectivité réseau tel que Cloud VPN ou Cloud Interconnect. Hybrid Subnets ne fournit pas cette connectivité en soi.
  • Routage de sous-réseau hybride : vous devez activer le routage de sous-réseau hybride en appliquant l'indicateur allow-cidr-routes-overlap à une ressource de sous-réseau.
  • Outil de migration : vous avez besoin d'un outil de migration tel que Migrate to Virtual Machines pour migrer les charges de travail vers Google Cloud.
Un diagramme en trois étapes illustre la migration des charges de travail depuis un environnement sur site vers Google Cloud à l'aide de sous-réseaux hybrides.
Figure 1. Lors de la migration, le routage de sous-réseau hybride permet aux charges de travail d'un réseau sur site de communiquer avec les charges de travail d'un réseau VPC connecté à l'aide d'adresses IP internes, même si les sous-réseaux des deux réseaux utilisent le même bloc CIDR (cliquez pour agrandir).

Spécifications

Pour configurer Hybrid Subnets afin de prendre en charge la migration des charges de travail versGoogle Cloud à partir d'un réseau sur site, votre environnement doit répondre aux exigences suivantes.

  • Exigences de connectivité :
    • Vos réseaux sur site et VPC doivent être connectés par un produit de connectivité réseau tel que Cloud VPN ou Cloud Interconnect.
    • Les tunnels VPN haute disponibilité ou les rattachements de VLAN, les routeurs Cloud Router et les sous-réseaux avec routage de sous-réseau hybride activé doivent tous se trouver dans la même région.
  • Configuration du réseau VPC :
    • Une plage d'adresses IPv4 du sous-réseau avec le routage de sous-réseau hybride activé doit correspondre à un bloc CIDR du réseau sur site qui héberge les charges de travail que vous souhaitez migrer. Dans la plupart des cas d'utilisation, la plage d'adresses IPv4 principale du sous-réseau correspond à un bloc CIDR du réseau sur site.
    • Vous devez activer le routage de sous-réseau hybride. Lorsque le routage de sous-réseau hybride est activé, les règles concernant les interactions entre les routes de sous-réseau et les routes statiques et les règles concernant les interactions entre les routes de sous-réseau et les routes dynamiques ne sont pas appliquées. Les routes statiques ou dynamiques locales et d'appairage peuvent exister même si leurs destinations correspondent à la plage d'adresses IPv4 principale du sous-réseau ou à l'une de ses plages d'adresses IPv4 secondaires, ou s'y inscrivent.
    • Vous devez configurer 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 votre réseau VPC. Pour prendre en charge le proxy ARP et la correspondance du préfixe le plus long, ces routes annoncées personnalisées doivent être plus spécifiques (masque de sous-réseau plus long) que la plage d'adresses IPv4 du sous-réseau pour lequel le routage de sous-réseau est activé. Vous pouvez utiliser une route annoncée personnalisée /32 pour chaque adresse IP d'une VM migrée.
  • Configuration du réseau sur site :
    • Vous devez configurer le proxy ARP pour le routeur sur site.
    • Vous devez configurer le routeur sur site pour qu'il annonce la plage d'adresses IP du bloc CIDR partagé.
Un routeur Cloud Router et un routeur sur site gèrent le routage sur un bloc CIDR partagé entre les réseaux sur site et VPC.
Figure 2. Ce schéma récapitule la configuration d'un réseau VPC et d'un réseau sur site pour maintenir la connectivité interne sur un bloc CIDR partagé (cliquez pour agrandir).

Routage de sous-réseau hybride

Une fois la configuration décrite dans les spécifications des sous-réseaux hybrides terminée, les VM des deux réseaux peuvent communiquer à l'aide d'adresses IP internes.

Les sections suivantes décrivent le comportement de routage dans le réseau VPC qui contient un sous-réseau avec le routage de sous-réseau hybride activé, ainsi que dans un réseau sur site une fois cette configuration en place.

Routage dans le réseau VPC

Lors de l'étape de correspondance des routes de sous-réseau du modèle de routage VPC, si la destination d'un paquet correspond à une route de sous-réseau locale ou d'appairage, Google Cloud tente de distribuer le paquet à l'aide de la route de sous-réseau correspondante. Dans un sous-réseau standard, si la destination n'est pas associée à une VM en cours d'exécution ni à une règle de transfert interne, le paquet est supprimé et toutes les autres routes sont ignorées.

Toutefois, si le routage de sous-réseau hybride est activé pour le sous-réseau, la route de sous-réseau devient une route de sous-réseau hybride, et le comportement de routage est différent :

  • Ressources correspondantes : si la destination du paquet correspond à l'interface réseau d'une instance de VM en cours d'exécution ou à une règle de transfert interne dans le sous-réseau, Google Cloud envoie le paquet à l'interface ou à la règle de transfert. Ce comportement est identique à celui d'un sous-réseau standard.
  • Ressources non correspondantes : si la destination du paquet ne correspond pas à une ressource du sous-réseau, Google Cloud suit le processus Ressources non correspondantes dans les sous-réseaux hybrides. Ce processus achemine les paquets vers les sauts suivants des routes statiques ou dynamiques locales ou d'appairage, à condition qu'ils aient des sauts suivants dans la même région que le sous-réseau hybride. Les routes dynamiques ou statiques locales ou d'appairage fournissent un chemin pour transmettre le paquet au réseau sur site.
Dans un sous-réseau où le routage de sous-réseau hybride est activé, le paquet A est routé localement, et le paquet B est routé vers une destination sur site.
Figure 3. Dans un sous-réseau qui utilise le routage de sous-réseau hybride, si la destination d'un paquet correspond à une ressource du sous-réseau, Google Cloud route le trafic vers cette ressource. Pour les ressources non correspondantes, Google Cloud utilise le processus des ressources non correspondantes dans les sous-réseaux hybrides (cliquez pour agrandir).

Par exemple, sur la figure 3, le paquet A est acheminé vers une VM du sous-réseau local à l'aide d'une route de sous-réseau hybride local. La destination du paquet B n'étant pas associée à une VM en cours d'exécution ni à une règle de transfert interne dans le sous-réseau qui utilise le routage de sous-réseau hybride, Google Cloud recherche les routes dynamiques ou statiques qui correspondent à la plage de destination de la route de sous-réseau hybride. Une correspondance est trouvée, et Google Cloud utilise la route dynamique pour envoyer le paquet B au réseau sur site.

Routage dans le réseau sur site

Cette section décrit le comportement de routage dans un réseau sur site. Dans cet exemple, le réseau sur site est connecté à un réseau VPC à l'aide de tunnels Cloud VPN.

Lorsqu'une VM cliente du réseau sur site envoie un paquet à une VM serveur qui se trouve dans le bloc CIDR partagé par les deux réseaux, le routeur ou le périphérique de premier saut du réseau sur site effectue une recherche dans la table de routage :

  • Si la VM du serveur est associée à une adresse IP dans le réseau sur site, le routeur sur site n'intervient pas dans le proxy ARP. La VM de serveur répond aux paquets ARP who-has de la VM cliente avec des réponses contenant l'adresse MAC du serveur. La VM cliente envoie un frame Ethernet à la VM serveur.

  • Si la VM de serveur n'est pas associée à une adresse IP dans le réseau sur site et que le routeur sur site a reçu une annonce de route personnalisée spécifique des sessions BGP du routeur cloud des tunnels Cloud VPN dans le réseau VPC, le routeur sur site intervient avec le proxy ARP. Le routeur sur site répond aux paquets ARP who-has de la VM cliente avec des réponses contenant l'adresse MAC du routeur. La VM cliente envoie un frame Ethernet au routeur sur site, qui extrait le paquet IP et le transfère vers l'un des tunnels Cloud VPN. Le paquet est ainsi transmis à la VM du sous-réseau pour lequel le routage de sous-réseau hybride est activé.

Un routeur sur site utilise un proxy ARP pour acheminer un paquet d'une charge de travail dans un réseau sur site vers une VM migrée vers Google Cloud.
Figure 4. Un routeur sur site utilise un proxy ARP pour acheminer un paquet d'une charge de travail du réseau sur site vers une VM migrée vers Google Cloud (cliquez pour agrandir).

Limites

Les sous-réseaux hybrides sont soumis aux limites suivantes.

  • Gestion des adresses IP et trafic accepté :

    • IPv6 : Hybrid Subnets n'est pas compatible avec le trafic IPv6.

    • Diffusion et multidiffusion : Hybrid Subnets n'est pas compatible avec le trafic de diffusion et de multidiffusion.

    • Conflits d'adresses IP : les sous-réseaux hybrides ne détectent pas les conflits d'adresses IP entre les ressources du réseau sur site et le réseau VPC contenant le sous-réseau pour lequel le routage de sous-réseau hybride est activé. Assurez-vous que chaque adresse IP, à l'exception de la passerelle par défaut, n'est utilisée qu'une seule fois.

    • Adresses inutilisables : les deux premières et les deux dernières adresses IPv4 de la plage d'adresses IPv4 principale d'un sous-réseau ne peuvent pas être utilisées par une ressource Google Cloud . Cette règle reste en vigueur même si vous activez le routage de sous-réseau hybride. Pour en savoir plus, consultez Adresses inutilisables dans les plages de sous-réseaux IPv4.

  • Régions non concordantes : les paquets sont supprimés si le prochain saut d'une route statique ou dynamique correspondante dans la plage de destination de la route de sous-réseau hybride correspondante se trouve dans une région différente de celle du sous-réseau. Pour en savoir plus, consultez Limitation de la régionalité.

  • Routes statiques avec tags réseau : assurez-vous qu'aucune route statique correspondante dans la plage de destination de la route de sous-réseau hybride correspondante n'utilise de tags réseau. Les routes statiques correspondantes qui utilisent des tags réseau entraînent une perte de paquets lorsque les débits de paquets sont élevés.

  • Interactions avec des produits non compatibles : n'utilisez pas Hybrid Subnets avec les éléments suivants.

    • Network Connectivity Center (NCC) : NCC n'est pas compatible avec les sous-réseaux hybrides. Google Cloudne vous empêche pas d'exporter des sous-réseaux pour lesquels le routage de sous-réseau hybride est activé vers un hub NCC, mais cela peut entraîner un comportement de routage imprévisible.

    • NEG de connectivité hybride : les systèmes de vérification d'état de Google pour les vérifications d'état centralisées ne peuvent pas communiquer avec les points de terminaison d'un NEG hybride si les points de terminaison s'inscrivent dans un itinéraire de sous-réseau hybride.

    • Hybrid NAT : Hybrid NAT n'est pas compatible avec Hybrid Subnets. Hybrid NAT n'effectue pas de traduction NAT source (SNAT) sur les paquets envoyés par les VM vers des destinations dans une route statique ou dynamique si une route de sous-réseau hybride est d'abord trouvée.

Tenez également compte des limites pratiques suivantes.

  • Le réseau sur site doit être compatible avec le proxy ARP : Hybrid Subnets n'est pas compatible avec la migration de charges de travail depuis des réseaux distants d'autres fournisseurs de services cloud tels qu'Azure ou AWS, car ces réseaux distants ne sont pas compatibles avec le proxy ARP.

  • Le réseau sur site doit accepter les annonces de route /32 : si vous utilisez une interconnexion partenaire de couche 3, vérifiez auprès du partenaire s'il accepte de recevoir les préfixes /32.

Options de migration

Google recommande 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.

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 savoir comment planifier une migration avec Migrate to Virtual Machines, consultez Parcours de migration avec Migrate to VMs.

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

Pour obtenir de l'aide concernant la planification d'une migration vers Google Cloud à l'aide de Hybrid Subnets, envoyez une demande d'assistance.

É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 pour migrer des charges de travail vers Google Cloud.

Proxy ARP et Hybrid Subnets

Hybrid Subnets nécessite la configuration du proxy ARP sur le routeur ou le périphérique de premier saut du réseau sur site (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 périphérique 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 sur site :

  • Consultez votre fournisseur de structure réseau pour connaître les bonnes pratiques concernant l'activation de proxy ARP et la sécurisation de votre environnement réseau.
  • Désactivez le proxy ARP une fois la migration versGoogle Cloudterminée.

Limitation de la régionalité

Cette limite s'applique lorsque le trafic correspond à une route de sous-réseau hybride, mais que l'adresse IP de destination n'est pas associée à une VM en cours d'exécution ni à une règle de transfert interne. Lors de l'étape Ressources non correspondantes dans les sous-réseaux hybrides du modèle de sélection de route de Google Cloud, les routes sont évaluées comme si la source d'un paquet se trouvait dans le même réseau VPC que la route de sous-réseau hybride.

Si une route statique ou dynamique avec une plage de destination qui s'inscrit dans une route de sous-réseau hybride comporte des sauts suivants dans une autre région :

  • Si la route comporte un mélange de sauts suivants, dont certains se trouvent dans la même région que la route de sous-réseau hybride et d'autres dans d'autres régions, le trafic est abandonné chaque fois qu'ECMP sélectionne un saut suivant dans une région autre que le sous-réseau. Cette suppression de paquets se produit même si le paquet correspond également à une route moins spécifique qui comporte des sauts suivants dans la région du sous-réseau.
  • Si la route ne comporte aucun saut suivant dans la même région que le sous-réseau qui utilise le routage de sous-réseau hybride, le paquet est supprimé.

Assurez-vous que les ressources suivantes se trouvent dans la même région :

  • Sous-réseau pour lequel le routage de sous-réseau hybride est activé
  • Routeur cloud qui apprend les routes vers votre réseau sur site
  • Tunnels VPN haute disponibilité ou rattachements de VLAN qui fournissent une connectivité hybride

Par exemple, supposons qu'il existe un sous-réseau avec la plage d'adresses IP 192.0.2.0/24 pour lequel le routage de sous-réseau hybride est activé. Le sous-réseau se trouve dans la région us-central1. Le routeur cloud a appris deux routes avec des plages de destination qui correspondent à la route de sous-réseau hybride :

  • Route dynamique avec plage de destination 192.0.2.0/25 et saut suivant dans la région us-central1
  • Route dynamique avec plage de destination 192.0.2.0/30 et saut suivant dans la région us-west1.

Un paquet est envoyé à la destination 192.0.2.2. Cette adresse IP n'est associée à aucune VM en cours d'exécution ni à aucune règle de transfert interne dans le sous-réseau local. Le modèle de sélection de route sélectionne donc la route personnalisée dont la destination est la plus spécifique, à savoir 192.0.2.0/30. Cette route n'a pas de saut suivant dans la région du sous-réseau. Le paquet est donc supprimé.

Pour en savoir plus, consultez Ressources non correspondantes dans les sous-réseaux hybrides.

Appairage de réseaux VPC

Vous pouvez connecter un réseau VPC contenant un sous-réseau qui utilise le routage de sous-réseau hybride à un réseau VPC pair à l'aide de l'appairage de réseaux VPC.

Le trafic provenant de clients d'un réseau appairé peut atteindre des destinations dans le bloc CIDR partagé, que les destinations soient des ressourcesGoogle Cloud ou dans le réseau sur site. Si un paquet provenant d'un client du réseau appairé a une destination qui correspond à une route de sous-réseau hybride d'appairage, et que la destination ne correspond pas à une VM en cours d'exécution ni à une règle de transfert interne, le paquet peut être acheminé à l'aide d'une route statique ou dynamique dans le réseau VPC appairé.

Le routage à l'aide d'une route statique ou dynamique dans le réseau VPC appairé ne dépend pas de l'échange de routes personnalisées avec le réseau VPC contenant le client. Toutefois, les éléments suivants restent pertinents :

  • Assurez-vous que l'utilisation du quota routes dynamiques par région et par groupe d'appairage dans le réseau VPC contenant le client est inférieure à la limite du quota.

  • Assurez-vous qu'aucune autre route n'existe dans le réseau VPC du client pour les plages de destination qui correspondent aux routes statiques ou dynamiques du réseau appairé et qui s'inscrivent dans la route de sous-réseau hybride d'appairage.

Performances du réseau

Hybrid Subnets utilise la couche 3 du modèle OSI pour acheminer les paquets entre les réseaux sur site et VPC. 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 sur site, mais que d'autres charges de travail ont migré vers le cloud.

En particulier, éviter le tunneling 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.

Comme Hybrid Subnets utilise cette approche de routage, vous pouvez vous attendre à des performances semblables ou identiques à celles d'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 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 devez 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 sur site.

Tarifs

Pour en savoir plus sur la tarification des sous-réseaux hybrides, consultez la page Tarifs du cloud privé virtuel.

Étapes suivantes