Connectivité à la zone d’atterrissage des données sur plusieurs régions
Si vous avez une présence dans plusieurs régions Azure et que vous devez héberger votre plateforme de données et vos applications de données dans plusieurs zones géographiques, la connectivité devient légèrement plus compliquée.
Les déploiements multi-régions ont généralement un abonnement de hub de connectivité dans chaque emplacement Azure individuel. Par exemple, si vous avez des services en cours d’exécution dans les régions USA Est et Europe Ouest, vous allez configurer un abonnement de hub de connectivité avec des ressources réseau partagées dans chaque région. Les ressources réseau partagées sont les suivantes :
- Appliances virtuelles réseau (comme Pare-feu Azure)
- Passerelles ExpressRoute
- Passerelles VPN
- Réseaux virtuels de hub (dans une architecture hub and spoke) ou hubs vWAN (dans une configuration vWan)
Figure 1 : Connectivité inter-régions.
Dans l’architecture hub-spoke-spoke-hub, les réseaux virtuels des hubs de connectivité sont souvent connectés à l’aide du peering de réseaux virtuels mondial. Pour les environnements plus volumineux, une alternative courante consiste à utiliser ExpressRoute Global Reach. Quelle que soit l’option de connectivité que vous choisissez, vous pouvez obtenir un routage global et une connectivité entre des réseaux spoke dans plusieurs zones géographiques. Cela signifie que vous pouvez déplacer des données entre les régions à l’aide d’appliances virtuelles réseau, de groupes de sécurité réseau et de tables de routage, étant donné que votre trafic n’est pas bloqué dans l’un ou l’autre des abonnements de connectivité.
Important
Cet article et d’autres articles de la section Mise en réseau décrivent les unités commerciales qui partagent les données. Toutefois, il ne doit pas s’agir de votre stratégie initiale et vous devez commencer au niveau de base.
Concevez votre réseau de manière que vous puissiez éventuellement implémenter notre configuration recommandée entre les zones d’atterrissage des données. Assurez-vous que les zones d’atterrissage de gestion des données sont directement connectées aux zones d’atterrissage de gouvernance.
Peering de réseaux virtuels mondial (recommandé)
Vous pouvez connecter des zones d’atterrissage de données entre régions à l’aide du peering de réseaux virtuels mondial direct. Dans cette configuration, si nous continuons notre exemple de scénario précédent, la machine virtuelle en Europe Ouest accède directement au point de terminaison privé du compte de stockage USA Est, sans compter sur les architectures réseau hub and spoke ou vWAN. Les données sont directement chargées par la machine virtuelle sur un point de terminaison privé, traitées, puis stockées sur le compte de stockage en Europe Ouest.
Gestion de l’accès utilisateur dans le peering de réseaux virtuels mondial
Il n’existe aucun avantage ou inconvénient particulier pour l’une des options de connectivité de zone d’atterrissage de données inter-régions proposées.
Résumé : 
/
Management des services dans le peering de réseaux virtuels mondial
Le peering de réseaux virtuels mondial n’a pas d’appliance virtuelle réseau qui agit comme un point de défaillance unique ou un facteur de limitation du débit. Les données ne sont pas envoyées via vos hubs de connectivité. Vous n’avez donc pas besoin de mettre à l’échelle les appliances virtuelles et les passerelles au sein des hubs de connectivité. Ce manque de mise à l’échelle réduit la surcharge de gestion pour votre équipe principale de plateforme Azure. Vous n’avez pas non plus besoin d’établir une liste d’autorisation des connexions inter-régions individuelles. Vos équipes de données peuvent accéder aux données à partir de zones d’atterrissage de données dans d’autres régions sans avoir à attendre les modifications apportées à la table de routage.
Dans cette conception réseau, votre équipe de plateforme Azure centrale ne peut plus inspecter et journaliser tout le trafic à l’aide d’un pare-feu de couche 7. Toutefois, le scénario d’analytique à l’échelle du cloud est une plateforme cohérente couvrant plusieurs abonnements, ce qui permet de mettre à l’échelle et de surmonter les limitations au niveau de la plateforme, ce qui n’est pas un inconvénient. Vous pouvez capturer les journaux réseau à l’aide des journaux de flux du groupe de sécurité réseau. Vous pouvez consolider et stocker d’autres journaux de niveau application et service à l’aide des paramètres de diagnostic spécifiques au service.
Vous pouvez capturer tous ces journaux à grande échelle à l’aide des définitions Azure Policy pour les paramètres de diagnostic.
Dans certains scénarios, vous devez limiter en raison des conséquences réglementaires ou légales. Par exemple, vous pouvez avoir une réglementation locale qui exige que certains jeux de données restent dans un centre de données particulaire, de sorte que vous n’êtes pas autorisé à les transférer entre les régions. Vous pouvez compter sur des groupes de sécurité réseau pour vous aider à vous conformer à ce type de règle, ce qui permet uniquement au trafic de se déplacer dans une seule direction d’USA Est vers Europe Ouest et non l’inverse. Au sein de vos groupes de sécurité réseau, vous pouvez vous assurer que le trafic provenant d’USA Est est refusé alors que le trafic provenant d’Europe Ouest est autorisé.
Cette approche de solution n’a pas d’impact sur la bande passante et la latence, et permet aux clients de rester conformes tout en combinant les jeux de données de plusieurs régions. Cette option n’a pas d’impact sur votre architecture DNS et vous permet d’utiliser une solution native Azure basée sur les zones de DNS privé Azure.
Résumé :
Coût du peering de réseaux virtuels mondial
Remarque
Lorsque vous accédez à un point de terminaison privé à partir d’un réseau appairé, vous n’êtes facturé que pour le point de terminaison privé lui-même, et non pour le peering VNet. Vous pouvez lire l’explication officielle dans Forum aux questions : Comment est facturé l’accès à un point de terminaison privé à partir d’un réseau appairé ?.
Avec cette conception de réseau, vous êtes facturé pour vos points de terminaison privés (par heure) et tous les trafics d’entrée et de sortie envoyés par leur intermédiaire. Vous devez également payer un coût de transfert de données pour le trafic entre les régions. Toutefois, aucun coût d’entrée et de sortie de peering de réseaux virtuels mondial ne vous sera facturé. Pour cette raison, l’option de peering de réseaux virtuels mondial présente des avantages notables en termes de coût par rapport à l’option spoke-hub-hub-spoke traditionnelle décrite plus loin dans cet article.
Résumé :
Bande passante et latence dans le peering de réseaux virtuels mondial
L’impact sur la bande passante et la latence est beaucoup plus faible dans le peering de réseaux virtuels mondial que dans l’option spoke-hub-hub-spoke traditionnelle. Le peering de réseaux virtuels mondial contient un nombre inférieur de tronçons pour l’échange de données de zone d’atterrissage de données inter-régions et n’a pas d’appliances virtuelles réseau limitant le débit. Les seules choses qui dictent la bande passante et la latence que vous pouvez atteindre pour le trafic inter-régions sont les limites physiques de nos centres de données (vitesse des câbles de fibre optique, des passerelles et des routeurs).
Résumé :
Résumé du peering de réseaux virtuels mondial
Le peering de réseaux virtuels mondial entre des zones d’atterrissage de données dans différentes régions offre d’énormes avantages, en particulier à mesure que le trafic de données inter-régions augmente au sein de votre plateforme de données. Il simplifie le management des services pour votre équipe principale de plateforme Azure, et bénéficie en particulier des cas d’usage qui nécessitent une faible latence et une bande passante élevée. Il offre également des avantages significatifs en matière de coûts par rapport à l’option de conception spoke-hub-hub-spoke traditionnelle.
Conception spoke-hub-hub-spoke traditionnelle (non recommandée)
Votre autre option pour les transferts de données inter-régions est la conception spoke-hub-hub-spoke traditionnelle. Dans notre exemple de scénario, si une machine virtuelle dans la zone d’atterrissage de données A hébergée en Europe Ouest charge un jeu de données stocké dans un compte de stockage à partir de la zone d’atterrissage des données B hébergée dans USA Est, les données traversent deux peerings de réseaux virtuels locaux (connectivité entre le hub et les spokes), un peering de réseaux virtuels mondial (connectivité entre hubs) et deux passerelles ou appliances virtuelles réseau avant d’être chargées par la machine virtuelle, puis replacées dans le compte de stockage local.
Gestion de l’accès utilisateur dans la conception traditionnelle spoke-hub-hub-spoke
Il n’existe aucun avantage ou inconvénient particulier pour l’une des options de connectivité de zone d’atterrissage de données inter-régions proposées.
Résumé :
/
Management des services dans la conception spoke-hub-hub-spoke traditionnelle
Cette approche de solution est bien connue et cohérente avec d’autres modèles de connectivité inter-régions, ce qui facilite son adoption et son implémentation. Elle n’a pas d’impact sur l’architecture DNS et vous permet d’utiliser une solution native Azure basée sur les zones de DNS privé Azure.
Bien que cette option de connectivité fonctionne en toute transparence si vous la configurez correctement, elle présente des inconvénients. Le trafic inter-régions est souvent refusé par défaut et doit être activé au cas par cas. Cela signifie qu’un ticket doit être envoyé à votre équipe principale de plateforme Azure pour chaque exigence d’accès aux données inter-régions requise afin que votre équipe puisse établir une liste d'autorisation de chaque connexion spécifique entre une machine virtuelle et un compte de stockage inter-régions. Ce processus augmente considérablement la surcharge de gestion. Il ralentit également vos équipes de projet de données, car elles ne peuvent pas accéder aux données dont elles ont besoin.
Notez également que dans cette option, les hubs de connectivité agissent comme des points de défaillance uniques. Dans le temps d’arrêt de l’appliance virtuelle réseau ou de la passerelle, la connectivité et les plateformes de données correspondantes échouent. Vous avez également un risque élevé de configuration incorrecte des itinéraires dans les hubs de connectivité. Cette configuration incorrecte peut entraîner des temps d’arrêt plus graves dans votre plateforme de données et entraîner une série de défaillances de flux de travail et de produits de données dépendants.
Vous devez surveiller la quantité de données que vous devez transférer entre les régions tout en utilisant cette approche de solution. Au fil du temps, ce monitoring peut impliquer des gigaoctets ou des téraoctets de données qui transitent par vos instances centrales. Étant donné que la bande passante des appliances virtuelles réseau est souvent limitée à un débit gigaoctet à un ou deux chiffres, les appliances peuvent agir comme un goulot d’étranglement critique limitant le flux de trafic entre les régions et le partage de vos ressources de données. Pour cette raison, vos ressources réseau partagées peuvent nécessiter des mécanismes de mise à l’échelle, qui sont souvent fastidieux et coûteux, et peuvent avoir un impact sur d’autres charges de travail dans votre locataire.
Résumé :
Coût de conception spoke-hub-hub-spoke traditionnelle
Remarque
Lorsque vous accédez à un point de terminaison privé à partir d’un réseau appairé, vous n’êtes facturé que pour le point de terminaison privé lui-même, et non pour le peering VNet. Vous pouvez lire l’explication officielle dans Forum aux questions : Comment est facturé l’accès à un point de terminaison privé à partir d’un réseau appairé ?.
Dans la conception traditionnelle spoke-hub-hub-spoke, les points de terminaison privés (par heure) de vos deux comptes de stockage vous sont facturés, ainsi que tout le trafic d’entrée et de sortie envoyé par leur intermédiaire. Vous êtes également facturé pour le trafic d’entrée et de sortie d’un peering de réseau virtuel local et du peering de réseau virtuel mondial entre vos hubs de connectivité. Toutefois, vous ne serez pas facturé pour le premier peering de réseaux virtuels, comme nous l’avons expliqué dans la note précédente.
Vos appliances virtuelles de réseau central seront également un coût important si vous choisissez cette conception de réseau. Cela est dû au fait que vous devez acheter des licences supplémentaires pour mettre à l’échelle les appliances en fonction de la demande ou que vous devez payer les frais par gigaoctet traité pour celles-ci, comme avec Pare-feu Azure.
Résumé :
Bande passante et latence dans la conception spoke-hub-hub-spoke traditionnelle
Cette conception de réseau présente des limitations de bande passante importantes. Vos appliances virtuelles de réseau central deviennent des goulots d’étranglement critiques à mesure que votre plateforme se développe, ce qui limite les cas d’utilisation des zones d’atterrissage de données inter-régions et le partage de vos jeux de données. Il est également probable que plusieurs copies de vos jeux de données sont créées au fil du temps. Cette conception affecte également fortement la latence, ce qui est particulièrement critique pour les scénarios d’analytique en temps réel, car vos données traversent de nombreux tronçons.
Résumé :
Résumé de la conception spoke-hub-hub-spoke traditionnelle
La conception spoke-hub-hub-spoke est bien connue et établie dans de nombreuses organisations, ce qui la rend facile à établir dans un environnement existant. Toutefois, elle présente des inconvénients importants pour le management des services, le coût, la bande passante et la latence. Ces problèmes sont particulièrement visibles à mesure que votre nombre de cas d’usage inter-régions augmente.
Conclusion
Le peering de réseaux virtuels mondial présente de nombreux avantages par rapport à la conception spoke-hub-hub-spoke traditionnelle, car il est rentable, facile à manager et offre une connectivité fiable entre les régions. Bien que la conception spoke-hub-hub-spoke traditionnelle puisse être une option viable alors que votre volume de données et vos besoins en matière d’échange de données inter-régions sont faibles, nous vous recommandons d’utiliser l’approche de peering de réseaux virtuels mondial à mesure que la quantité de données que vous devez échanger entre les régions augmente.