Ce document fait partie d'une série qui décrit les architectures de mise en réseau et de sécurité pour les entreprises qui migrent les charges de travail de centres de données vers Google Cloud.
La série comprend les documents suivants :
- Concevoir des réseaux pour migrer des charges de travail d'entreprise : Approches architecturales
- Mise en réseau pour un accès sécurisé dans le cloud : Architectures de référence
- Mise en réseau pour la diffusion d'applications Web : Architectures de référence
- Mise en réseau pour les charges de travail hybrides et multicloud : Architectures de référence (ce document)
Ce document traite de la mise en réseau pour un scénario dans lequel les charges de travail s'exécutent à plusieurs emplacements, tels que sur site et dans le cloud, ou dans plusieurs environnements cloud.
Architecture de migration Lift and Shift
Le premier scénario d'accès à une charge de travail hybride est une architecture de migration Lift and Shift.
Établir une connectivité privée
Vous pouvez établir la connectivité à des réseaux sur site à l'aide d'une interconnexion dédiée ou d'une interconnexion partenaire. La topologie illustrée à la figure 1 montre comment utiliser quatre connexions d'interconnexion dans deux zones métropolitaines différentes et des domaines de disponibilité de périphérie différents afin d'atteindre une disponibilité de 99,99 % à l'aide d'une interconnexion dédiée. Pour en savoir plus et obtenir des recommandations détaillées, consultez la section Connectivité hybride entre un environnement sur site et Google Cloud du plan de base de l'entreprise.
Figure 1 : Configuration de connexions Cloud Interconnect redondantes pour une disponibilité de 99,99 %.
Network Connectivity Center vous permet d'utiliser le réseau de Google pour transférer des données entre plusieurs sites sur site ou hébergés dans le cloud. Cette approche vous permet de bénéficier de la portée et de la fiabilité du réseau de Google lorsque vous devez déplacer des données. Vous pouvez utiliser vos dispositifs de routeur Cloud VPN, Cloud Interconnect et SD-WAN en tant que spokes de Network Connectivity Center pour prendre en charge le transfert de données entre les réseaux sur site et les filiales, comme illustré à la figure 2.
Figure 2 : Configuration de Network Connectivity Center connectant différents réseaux sur site et d'autres réseaux cloud externes à Google Cloud à l'aide du réseau backbone de Google.
Pour en savoir plus sur la configuration de Network Connectivity Center, consultez la section Remarques dans la documentation de Network Connectivity Center.
Dispositifs SD-WAN
Network Connectivity Center vous permet d'utiliser un dispositif virtuel de réseau tiers en tant que spoke de Network Connectivity Center pour établir une connectivité entre un site externe et vos ressources de réseau VPC. Un dispositif de routeur peut être un routeur SD-WAN tiers compatible avec l'un de nos partenaires ou un autre dispositif virtuel qui vous permet d'échanger des routes avec l'instance Cloud Router. Ces solutions basées sur des dispositifs s'ajoutent aux options actuelles de connectivité de site à cloud qui sont disponibles avec Cloud VPN et Cloud Interconnect en tant que spokes. La figure 3 montre une topologie qui utilise des dispositifs SD-WAN.
Figure 3. Configuration de Network Connectivity Center avec un dispositif de routeur pour intégrer votre mise en œuvre SD-WAN au réseau de Google.
Vous pouvez utiliser des dispositifs tiers pour effectuer des fonctions de sécurité. Les fonctionnalités de sécurité du dispositif peuvent être intégrées au dispositif de routeur, comme illustré dans la figure 3. Il s'agit également d'un modèle courant d'utilisation d'un dispositif virtuel de mise en réseau, où le trafic provenant d'un environnement sur site est acheminé dans un réseau VPC de transit et où le dispositif établit la connectivité avec le réseau VPC de charge de travail, comme illustré dans la figure 4.
Pour en savoir plus sur la configuration de Network Connectivity Center, consultez la section Remarques dans la documentation de Network Connectivity Center.
Architecture des services hybrides
Comme dans le cas d'utilisation intra-cloud décrit dans la page Mise en réseau pour un accès sécurisé dans le cloud : architectures de référence, Network Connectivity Center permet la connectivité de vos filiales et réseaux sur site vers Google Cloud. Private Service Connect fournit un accès privé aux services gérés par Google ou vous permet d'utiliser d'autres services créés et déployés dans le cloud.
Vous pouvez également mettre en œuvre la sécurité du réseau en utilisant une combinaison de VPC Service Controls, de pare-feu Google Cloud et de dispositifs virtuels, comme illustré à la figure 4.
Figure 4. Réseaux dont l'architecture utilise un modèle de migration Lift and Shift et un modèle de conception de services hybrides qui est conçu pour fournir un plan de données sécurisé.
Architecture distribuée zéro confiance
Dans un environnement hybride, les microservices s'exécutent dans des maillages de services qui sont déployés sur différents fournisseurs de services cloud et environnements sur site. Vous pouvez contribuer à sécuriser la communication entre les microservices en utilisant des règles d'autorisation et mTLS. Il est courant que les entreprises créent des maillages de services dans le cloud et étendent les maillages à l'environnement sur site. La figure 5 montre un exemple dans lequel les services qui sont déployés sur site accèdent aux services dans le cloud. L'authentification mTLS de bout en bout entre les services est activée à l'aide de la passerelle est-ouest et d'un routage basé sur SNI. Anthos Service Mesh vous aide à sécuriser les communications de service à service, ce qui vous permet de configurer des règles d'autorisation pour les services et de déployer des certificats et des clés qui sont fournis par une autorité de certification gérée.
Les environnements hybrides comportent généralement plusieurs déploiements de maillage, tels que plusieurs clusters GKE. Le routage SNI est un composant important de ce flux. Il est utilisé sur la passerelle est-ouest de GKE pour chaque cluster. Cette configuration permet le routage mTLS directement à la charge de travail par la passerelle tout en préservant la connectivité mTLS de bout en bout.
Figure 5. Maillage de services zéro confiance déployé dans un environnement sur site et Google Cloud.
Les entreprises peuvent utiliser Anthos Service Mesh pour déployer sur différents clouds. Pour résoudre les problèmes de gestion des identités et des certificats entre les différents fournisseurs cloud, Anthos Service Mesh fournit une identité de charge de travail et une autorité de certification intermédiaire dans le cluster, à l'aide du service d'autorité de certification. L'autorité de certification intermédiaire peut être associée à une autorité de certification externe ou hébergée sur Google. Vous pouvez personnaliser les attributs de l'autorité de certification tels que la région et l'algorithme de signature, à l'aide des HSM et de Cloud HSM d'entreprise.
Workload Identity vous permet d'attribuer des identités et une autorisation distinctes et précises pour chaque microservice de votre cluster. Anthos Service Mesh gère le processus d'émission des certificats, ainsi que la rotation automatique des clés et des certificats, sans perturber les communications. Il fournit également une racine de confiance unique sur l'ensemble des clusters GKE.
La figure 6 montre une architecture qui utilise Anthos Service Mesh pour gérer l'identité et l'autorisation.
Les services du maillage peuvent accéder aux services Google Cloud à l'aide de la fédération d'identité de charge de travail. Cette fonctionnalité permet aux services d'agir avec l'autorité d'un compte de service Google lorsqu'ils appellent les API Google Cloud. La fédération d'identité de charge de travail permet également au maillage de services qui est installé sur d'autres fournisseurs cloud d'accéder aux API Google Cloud.
Figure 6. Déploiement de maillage de services zéro confiance sur plusieurs clouds.
Vous pouvez utiliser Traffic Director pour acheminer le trafic du maillage vers un environnement sur site ou vers un autre cloud.
Par exemple, vous pouvez créer des services dans Traffic Director appelés on-prem-service et other-cloud-service et ajouter des groupes de points de terminaison du réseau de connectivité hybride ayant des points de terminaison 10.1.0.1:80 et 10.2.0.1:80.
Traffic Director envoie ensuite le trafic à ses clients, qui sont des proxys side-car de maillage qui s'exécutent avec vos applications. Ainsi, lorsque votre application envoie une requête au service on-prem-service, le client Traffic Director inspecte la requête et la dirige vers le point de terminaison 10.0.0.1:80. La figure 7 illustre cette configuration.
Figure 7 : Trafic dirigé à partir d'un maillage de services à l'aide de Traffic Director.
Vous pouvez également intégrer des fonctionnalités avancées telles que l'orientation du trafic en fonction d'une pondération, comme illustré à la figure 8. Cette fonctionnalité vous permet d'activer les besoins critiques de l'entreprise tels que la migration vers le cloud. Traffic Director sert de plan de contrôle polyvalent et géré globalement pour vos maillages de services.
Figure 8. Orientation du trafic pondéré à l'aide de Traffic Director.
Étapes suivantes
- Mise en réseau pour un accès sécurisé dans le cloud : architectures de référence
- Mise en réseau pour la diffusion d'applications Web : Architectures de référence
- La page Migration vers Google Cloud peut vous aider à planifier, à concevoir et à mettre en œuvre le processus de migration de vos charges de travail vers Google Cloud.
- La section Conception des zones de destination dans Google Cloud fournit des conseils pour créer un réseau de zones de destination.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.