À propos de la migration vers Google Cloud avec 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 de cloud privé virtuel (VPC) sans avoir à modifier les adresses IP. 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.

Hybrid Subnets permet également de migrer des VM depuis Google Cloudvers un réseau sur site ou entre deux réseaux VPC.

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, un sous-réseau hybride assure la connectivité entre les charges de travail d'un réseau source et un réseau VPC (cliquez pour agrandir).

Spécifications

Les sous-réseaux hybrides présentent les spécifications suivantes.

  • Propriétés :
    • Un sous-réseau hybride est un sous-réseau logique unique qui combine un segment d'un réseau source avec un sous-réseau d'un réseau VPC.
    • La connectivité interne est maintenue entre toutes les VM et charges de travail d'un sous-réseau hybride.
    • Le réseau source peut être un réseau sur site ou un autre réseau VPC. Le segment peut être un sous-réseau entier ou une partie de celui-ci.
    • Les deux parties d'un sous-réseau hybride doivent être connectées par un produit de connectivité réseau tel que Cloud VPN ou Cloud Interconnect.
    • La plage d'adresses IPv4 principale du sous-réseau VPC doit correspondre à la plage du segment du réseau source utilisé par le sous-réseau hybride.
  • Configuration du réseau VPC :
    • Vous devez activer le routage de sous-réseau hybride pour configurer un sous-réseau VPC en tant que sous-réseau hybride. Lorsque le routage de sous-réseau hybride est activé, les routes personnalisées peuvent entrer en conflit (se chevaucher) avec les plages d'adresses IPv4 principales et secondaires des sous-réseaux.
    • 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. Pour prendre en charge le proxy ARP et la correspondance du préfixe le plus long, ces routes doivent être plus spécifiques (avec un masque de sous-réseau plus long) que la plage d'adresses IP du sous-réseau hybride. Vous pouvez utiliser des routes /32 pour des VM individuelles.
  • Configuration réseau source :
    • Vous devez configurer proxy ARP dans le réseau source.
    • Vous devez configurer le réseau source pour qu'il annonce la plage d'adresses IP du sous-réseau hybride.
Un Cloud Router et un routeur sur site gèrent le routage entre les deux parties d'un sous-réseau hybride qui utilise une plage d'adresses IP partagée et chevauchante.
Figure 2. Ce schéma présente les étapes à suivre pour créer un sous-réseau hybride et explique comment Cloud Router et un routeur sur site acheminent les paquets entre les deux parties d'un sous-réseau hybride (cliquez pour agrandir).

Routage de sous-réseau hybride

Un sous-réseau hybride combine un sous-réseau dans un réseau source avec un sous-réseau VPC pour créer un seul sous-réseau logique. Les charges de travail dans les deux parties du sous-réseau hybride conservent la connectivité interne. Une charge de travail peut envoyer du trafic vers une destination dans l'une ou l'autre partie du sous-réseau hybride comme si elle était locale, quelle que soit l'emplacement de la destination.

Routage du 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 :

  • Si le paquet est associé à une instance de VM en cours d'exécution ou à une règle de transfert interne dans le sous-réseau VPC, Google Cloudtransmet le paquet en fonction de la route de sous-réseau hybride local.
  • Si le paquet n'est pas associé à une VM en cours d'exécution ni à une règle de transfert interne dans le sous-réseau VPC, Google Cloud utilise un processus de routage spécial pour les ressources non correspondantes. Ce processus inclut la vérification des routes dynamiques et statiques personnalisées qui chevauchent la plage du sous-réseau hybride. Dans un sous-réseau hybride correctement configuré, les paquets sont acheminés vers le réseau source à l'aide d'une route dynamique locale que Cloud Router apprend pour le sous-réseau source.
Dans un sous-réseau hybride, le paquet A est acheminé localement, et le paquet B est acheminé vers une destination sur site.
Figure 3. Les VM d'un sous-réseau hybride peuvent atteindre des destinations dans un sous-réseau sur site et un sous-réseau de réseau VPC, même si les deux sous-réseaux partagent la même plage d'adresses IP qui se chevauchent (cliquez pour agrandir).

Par exemple, sur la figure 3, le paquet A est acheminé vers une VM dans la partie VPC d'un sous-réseau hybride à l'aide d'une route de sous-réseau hybride local. La destination du paquet B n'est pas associée à une VM en cours d'exécution ni à une règle de transfert interne dans la partie VPC du sous-réseau hybride. Par conséquent, Google Cloud recherche les routes personnalisées en conflit. Une correspondance est trouvée, et Google Cloud utilise la route dynamique personnalisée qui se chevauche pour distribuer le paquet B au réseau source.

Routage du réseau source

Lorsqu'une charge de travail du réseau source envoie un paquet à une destination dans la plage d'adresses IP du sous-réseau hybride, le routeur ou le périphérique de premier saut du réseau source effectue une recherche dans la table de routage.

Si la destination est associée à une charge de travail dans le réseau source, le routeur n'intervient pas dans le proxy ARP. La destination reçoit la requête ARP et répond avec sa propre adresse MAC. Le paquet est ensuite transmis localement.

Si la destination se trouve dans la partie VPC du sous-réseau hybride et que le routeur a appris une route dynamique pour la destination plus spécifique que la route de sous-réseau local, il sélectionne la route dynamique en utilisant la correspondance du préfixe le plus long. Cela déclenche la fonctionnalité proxy ARP du routeur. Le routeur répond avec sa propre adresse MAC et achemine le paquet vers Cloud Router du réseau VPC.

Un routeur sur site utilise un proxy ARP pour acheminer un paquet d'une charge de travail dans un réseau source 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 dans un réseau source vers une VM qui a migré vers Google Cloud(cliquez pour agrandir).

Limites

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

  • Limites de ressources :

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

  • Trafic et itinéraires non pris en charge :

    • Les paquets sont supprimés si le prochain saut d'une route en conflit se trouve dans une région différente de celle du sous-réseau hybride.
    • Les types de routes suivants ne sont pas acceptés comme routes conflictuelles :
      • Routes par défaut générées par le système
      • Routes basées sur des règles
      • des routes statiques associées à des tags réseau.
      • Routes avec des destinations qui contiennent la route de sous-réseau hybride ou sont plus larges
    • Network Connectivity Center n'est pas entièrement compatible avec les sous-réseaux hybrides. Vous pouvez configurer un réseau VPC contenant un sous-réseau hybride pour qu'il devienne un spoke d'un hub Network Connectivity Center. Toutefois, le comportement de routage du trafic provenant des spokes connectés vers la plage d'adresses IP du sous-réseau hybride est imprévisible.
    • Hybrid NAT n'est pas compatible avec les sous-réseaux hybrides. Bien que vous puissiez configurer un sous-réseau hybride pour utiliser Hybrid NAT, la fonctionnalité n'est pas appliquée au trafic affecté par le routage de sous-réseau hybride.
    • Le routage de sous-réseau hybride ne s'applique pas au trafic IPv6.
    • 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.
    • Cloud Router d'un sous-réseau hybride ne peut pas dépasser le nombre maximal de routes annoncées personnalisées par session BGP.
    • 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.

  • Scénarios de migration non compatibles :

    • 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 la migration de VM depuis une source Azure ou AWS.
    • Hybrid Subnets n'est pas compatible avec le transfert de données de site à site.
    • 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.

  • Autres limites :

    • Hybrid Subnets ne détecte pas les conflits d'adresses IP entre les parties réseau source et 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 ne peut pas héberger de charges de travail sur les adresses IP réservées dans les sous-réseaux IPv4.
    • 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.
    • Le transfert entrant Cloud DNS ne répond pas aux requêtes DNS des charges de travail du réseau source.

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.

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 source (le point où un hôte envoie pour la première fois du trafic dont la destination est 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 source :

  • Consultez le fournisseur de votre structure réseau source pour connaître les bonnes pratiques concernant l'activation du 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é

Pour qu'un sous-réseau hybride fonctionne correctement, les routes conflictuelles (routes personnalisées qui chevauchent la plage d'adresses du sous-réseau hybride) doivent avoir tous leurs prochains sauts dans la même région que le sous-réseau hybride.

Si une route en conflit comporte des prochains sauts dans une autre région :

  • Si la route comporte un mélange de sauts suivants locaux et distants, le trafic est abandonné chaque fois qu'ECMP sélectionne un saut suivant dans une région distante. 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 même région.
  • Si la route ne comporte aucun saut suivant dans la même région que le 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 VPC configuré en tant que sous-réseau hybride
  • Routeur cloud qui apprend les routes vers votre réseau source
  • Tunnels VPN haute disponibilité ou rattachements de VLAN qui fournissent une connectivité hybride

Par exemple, supposons qu'il existe un sous-réseau hybride avec la plage d'adresses IP 192.0.2.0/24. Le sous-réseau VPC se trouve dans la région us-central1. Cloud Router a appris deux routes conflictuelles :

  • Une route personnalisée avec une plage de destination 192.0.2.0/25 et un saut suivant dans la région us-central1
  • Une route personnalisée avec une plage de destination 192.0.2.0/30 et un 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 VPC. 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 ne comporte pas de saut suivant dans la région du sous-réseau hybride. 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 sous-réseau hybride à un réseau VPC pair à l'aide de l'l'appairage de réseaux VPC. Le réseau VPC du sous-réseau hybride doit être configuré pour exporter les routes de sous-réseau et personnalisées, et le réseau VPC appairé doit être configuré pour les importer.

Une fois que le réseau VPC appairé a programmé les routes, il peut atteindre les destinations dans la plage d'adresses IP du sous-réseau hybride, qu'elles existent dans Google Cloud ou dans le réseau source.

Les routes ne seront pas programmées pour le réseau appairé dans les cas suivants :

  • Une route de sous-réseau locale dans le réseau appairé a une plage de destination identique à celle de la route importée.
  • Le quota Routes dynamiques par région et par groupe d'appairage est dépassé.
  • Les deux réseaux VPC ne sont pas directement appairés. L'appairage de réseaux VPC n'est pas transitif.

Si l'une de ces conditions est remplie, le sous-réseau hybride ne fonctionnera pas correctement du point de vue du réseau VPC appairé.

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 tunneling de couche 2 permet d'empêcher 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 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 dans la partie VPC d'un sous-réseau hybride vous sont facturés.

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

Étapes suivantes