La fonctionnalité de transfert de données de site à site vous permet de connecter vos sites externes à l'aide du réseau Google. Dans ce contexte, un site externe est un réseau que vous gérez en dehors de Google Cloud. Par exemple, un site externe peut être votre réseau sur site ou votre réseau chez un autre fournisseur de services cloud.
Le transfert de données de site à site n'est possible que dans certains emplacements. Cependant, vous devrez peut-être conserver une ressource de connectivité dans une région non compatible avec le transfert de données de site à site. Si vous utilisez ce type de topologie de réseau et que vous souhaitez transférer des données de site à site, utilisez la configuration décrite sur cette page. Sinon, votre connectivité de site à site risque d'échouer.
Le transfert de données de site à site fait partie de Network Connectivity Center, qui vous permet de gérer votre réseau à l'aide d'une architecture en étoile. Pour utiliser le transfert de données de site à site, vous établissez la connectivité à chaque réseau externe à l'aide d'une ressource de connectivité compatible. Ensuite, vous devez associer chaque ressource de connectivité à un spoke de Network Connectivity Center qui est associé à un hub de Network Connectivity Center. Network Connectivity Center établit ensuite une connectivité maillée complète entre tous les sites externes associés à vos spokes.
Exemple de topologie
Dans cet exemple, une organisation utilise le transfert de données de site à site pour connecter deux réseaux sur site :
Réseau A, en Inde
Réseau B, en Australie
Ces réseaux se connectent à Google Cloud à l'aide de rattachements de VLAN d'interconnexion dédiée et de tunnels Cloud VPN haute disponibilité. Ces ressources sont situées dans deux régions compatibles avec le transfert de données de site à site : asia-south1 et australia-southeast1. Ces deux rattachements de VLAN sont associés à des spokes Network Connectivity Center pour lesquels la fonctionnalité de transfert de données de site à site est activée.
Cette topologie place également les machines virtuelles (VM) Compute Engine dans australia-southeast1. Ces VM exécutent des services auxquels les systèmes sur site situés dans le réseau A accèdent régulièrement.
Cependant, cette topologie a été conçue pour que les ressources d'interconnexion dédiée disposent d'une disponibilité de 99,99 %. Pour obtenir une disponibilité de 99,99 %, vous devez utiliser deux paires de connexions Dedicated Interconnect dans deux régions. Chaque connexion doit posséder son propre rattachement de VLAN.
Pour répondre à cette exigence, l'exemple de topologie place une paire redondante de rattachements de VLAN dans une région non compatible hypothétique (region-unsupported1). Le réseau A est équidistant de asia-south1 et region-unsupported1. Cependant, la région non compatible est plus proche de australia-southeast1 que asia-south1.
Cette configuration pose potentiellement problème pour transférer des données de site à site. Comme region-unsupported1 est plus proche de australia-southeast1, l'instance Cloud Router de australia-southeast1 considère la ressource de region-unsupported1 comme le chemin d'accès optimal au réseau A. Toutefois, étant donné que ce chemin d'accès n'est pas associé à Network Connectivity Center, Cloud Router n'annonce pas à nouveau les préfixes du réseau A au réseau B.
Options de configuration
Dans l'exemple de scénario, vous pouvez contrôler la manière dont le trafic est acheminé en configurant le routeur externe pour le réseau A. Utilisez l'une des options décrites dans les sections suivantes.
Ces deux options impliquent d'utiliser MED. Pour comprendre comment Cloud Router utilise MED, consultez la section Conseils pour les priorités de base.
Option 1 : Optimiser le transfert de données de site à site
Si le transfert de données de site à site est essentiel, forcez tout le trafic à donner la préférence aux ressources associées aux spokes Network Connectivity Center. Vous pouvez appliquer ce comportement en utilisant différentes valeurs MED pour asia-south1 et region-unsupported1.
Par exemple, configurez le routeur du réseau sur site A pour annoncer 10.1/16 à l'aide des éléments suivants :
- Une valeur MED de
100àasia-south1 - Une valeur MED de
20000àregion-unsupported1
Dans ce cas, le routeur cloud de australia-southeast1 considère que l'annonce provenant de asia-south1 est le meilleur chemin. Il annonce aussi à nouveau 10.1/16 au réseau sur site B.
L'avantage de cette approche est qu'elle vous permet d'utiliser le transfert de données de site à site de manière cohérente. L'inconvénient est qu'elle augmente la latence pour les systèmes réseau A qui doivent accéder aux VM dans australia-southeast1.
Option 2 : Optimiser le trafic de site à cloud
Si le transfert de données de site à site n'est pas essentiel, forcez tout le trafic à donner la préférence à region-unsupported1. Vous pouvez appliquer ce comportement en utilisant les mêmes valeurs MED pour asia-south1 et region-unsupported1.
Par exemple, configurez le routeur du réseau sur site A pour annoncer 10.1/16 à l'aide des éléments suivants :
- Une valeur MED de
100àasia-south1 - Une valeur MED de
100àregion-unsupported1
Dans ce scénario, le routeur cloud de australia-southeast1 considère que l'annonce provenant de region-unsupported1 est le meilleur chemin, car il est plus proche géographiquement que asia-south1.
Comme ce chemin d'accès n'est pas associé à Network Connectivity Center, Cloud Router n'annonce pas à nouveau 10.1/16 au réseau sur site B.
L'avantage de cette approche est que, pour les systèmes du réseau A qui doivent accéder aux VM de australia-southeast1, la préférence est donnée à la route présentant une latence plus faible. L'inconvénient de cette approche est qu'elle entraîne l'échec du transfert de données de site à site.
Étapes suivantes
- Pour en savoir plus sur la façon dont Network Connectivity Center permet une connectivité maillée complète entre les sites externes, consultez la page Échange de routes avec transfert de données de site à site.
- Pour afficher un exemple de topologie, consultez la page Exemple de topologie pour le transfert de données de site à site.
- Pour en savoir plus sur les exigences de haute disponibilité, consultez la section Exigences de haute disponibilité pour les ressources de spoke.
- Pour apprendre à créer des hubs et des spokes, consultez la section Travailler avec des hubs et des spokes.