À propos de Hybrid Subnets

Hybrid Subnets vous permet de combiner un sous-réseau sur site avec un sous-réseau cloud privé virtuel (VPC) pour créer un seul sous-réseau logique. Vous pouvez migrer des charges de travail individuelles et des instances de machine virtuelle (VM) du sous-réseau sur site vers le sous-réseau VPC au fil du temps sans avoir à modifier les adresses IP. Une fois toutes les charges de travail et toutes les VM migrées, vous pouvez mettre hors service le sous-réseau sur site.

Figure 1 : Dans un sous-réseau hybride, les routeurs sur site et les routeurs cloud annoncent des routes à l'aide du protocole BGP (Border Gateway Protocol).

Hybrid Subnets et Migrate to Virtual Machines

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. Migrate to Virtual Machines est compatible avec Google.

.

Pour en savoir plus sur les options de migration, consultez la page Ressources de migration.

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 obtenir de l'aide concernant la planification d'une migration vers Google Cloud à l'aide de Hybrid Subnets, envoyez une demande d'assistance.

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

Spécifications

  • Hybrid Subnets nécessite un produit de connectivité réseau tel que Cloud VPN ou Cloud Interconnect.
  • Un routeur sur site utilise un proxy ARP pour acheminer le trafic des machines sur site vers des VM Google Cloud en utilisant les routes apprises des routes annoncées personnalisées de Cloud Router.
  • La plage d'adresses IPv4 principale du sous-réseau Google Cloud doit correspondre à la plage d'adresses IP du sous-réseau sur site.
  • 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'option allow-cidr-routes-overlap s'applique aux plages de sous-réseaux IPv4 principales, aux plages de sous-réseaux IPv4 secondaires et aux plages de sous-réseaux IPv6.
  • La connectivité interne est maintenue entre toutes les VM et 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 depuis un réseau sur site vers Google Cloud, vous mettez à jour les routes annoncées personnalisées Cloud Router pour inclure les adresses IP des VM migrées.
  • Vous pouvez connecter un sous-réseau hybride à un réseau VPC appairé à 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 les routes personnalisées. La configuration d'appairage pour l'autre réseau VPC doit être configurée pour importer des routes personnalisées.

Limites

  • Le nombre maximal de VM dans un réseau VPC utilisant Hybrid Subnets est de 130. Le dépassement de cette limite peut entraîner des problèmes de connectivité et de stabilité.
  • Le routeur 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.
  • 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 n'est pas compatible avec Google Cloud VMware Engine. Nous vous recommandons de migrer des VM VMware à l'aide de VMware HCX.
  • Si une charge de travail sur site possède la même adresse IP que le routeur Cloud Router, les charges de travail de la partie VPC d'un sous-réseau hybride ne peuvent pas envoyer de paquets à cette adresse IP. Par exemple, si la plage d'adresses IP du sous-réseau hybride est 192.168.1.0/24, les charges de travail du sous-réseau VPC ne peuvent pas atteindre 192.168.1.1.
  • 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 de la partie sur site d'un sous-réseau hybride.
  • Les charges de travail de la partie sur site d'un sous-réseau hybride ne peuvent pas atteindre les API et services Google en utilisant l'accès privé à Google.
  • Les charges de travail de la partie sur site d'un sous-réseau hybride ne peuvent pas atteindre les points de terminaison Private Service Connect pour les API Google.
  • Hybrid Subnets n'est pas compatible avec le transfert de données de site à site.
  • Hybrid Subnets n'est pas compatible avec la migration de charges de travail depuis d'autres fournisseurs de services cloud, ni avec la migration de charges de travail dans Google Cloud, car ces environnements ne sont pas compatibles avec le proxy ARP.
  • Un sous-réseau hybride ne peut pas se connecter aux réseaux pairs à l'aide de 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.

Performances du réseau

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

En particulier, éviter la tunnelisation 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.

Proxy ARP et Hybrid Subnets

Le proxy ARP est requis pour Hybrid Subnets. Nous vous recommandons de suivre les conseils suivants pour utiliser un proxy ARP dans la partie sur site d'un sous-réseau hybride :

  • Consultez le fournisseur de votre structure réseau sur site pour connaître les bonnes pratiques d'activation du proxy ARP et de sécurisation de votre environnement réseau.
  • Désactivez le proxy ARP une fois la migration vers Google Cloud terminée.

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 qu'un déchiffrement transparent ou une inspection approfondie du trafic superposé.

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 sur site.

Tarifs

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

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

Étapes suivantes