Topologie de réseau hub-and-spoke

Hub-and-spoke est un modèle de réseau pour une gestion efficace des besoins de communication ou de sécurité courants. Il permet également d’éviter les limitations des abonnements Azure. Ce modèle répond aux préoccupations suivantes :

• Économie de coûts et gestion efficace : Centralisez les services qui peuvent être partagés par plusieurs charges de travail, comme les appliances virtuelles réseau et les serveurs DNS. Avec un emplacement unique pour les services, le département informatique peut réduire les ressources redondantes et le travail de gestion.

• Dépassement des limites de l’abonnement : les charges de travail cloud traitant de gros volumes peuvent nécessiter davantage de ressources que celles contenues dans un même abonnement Azure. Vous avez la possibilité de dépasser ces limites en effectuant le peering des réseaux virtuels de charge de travail issus de différents abonnements à un hub central. Pour plus d’informations, consultez Limites des abonnements Azure.

• Instaurer une séparation des préoccupations : Vous pouvez déployer des charges de travail individuelles entre les équipes informatiques centrales et les équipes chargées des charges de travail.

Les patrimoines cloud plus petits pourraient ne pas bénéficier de la structure et des capacités ajoutées offertes par ce modèle. Toutefois, il est préférable d’adopter une architecture de mise en réseau hub-and-spoke en cas d’efforts plus important d’adoption cloud et d’une des préoccupations mentionnées précédemment.

Vue d’ensemble

Figure 1 : Exemple de topologie de réseau hub-and-spoke.

Comme indiqué dans le diagramme, Azure prend en charge deux types de conception hub-and-spoke. Le premier type prend en charge la communication, les ressources partagées et la stratégie de sécurité centralisée. Ce type est libellé Hub VNet dans le diagramme. Le deuxième type est basé sur Azure Virtual WAN, qui est libellé Réseau étendu virtuel dans le diagramme. Ce type est destiné aux communications à grande échelle de succursale à succursale et de succursale à Azure.

Un hub est une zone réseau centrale qui contrôle et inspecte le trafic d’entrée ou de sortie entre les zones : Internet, le réseau local et des spokes. La topologie hub-and-spoke offre à votre service informatique un moyen efficace d’appliquer des stratégies de sécurité à un emplacement central. Elle réduit également les risques de configuration incorrecte et d’exposition.

Le hub contient souvent les composants de service courants que les spokes consomment. Voici des exemples de services centraux courants :

• Un service DNS résout le nommage de la charge de travail dans les spokes pour accéder aux ressources locales et sur Internet si le service Azure DNS n’est pas utilisé.
• Une infrastructure à clé publique implémente l’authentification unique pour les charges de travail.
• Le flux de trafic TCP et UDP est contrôlé entre les zones du réseau spoke et Internet.
• Le flux est contrôlé entre les spokes et localement.
• Si nécessaire, le flux est contrôlé entre un spoke et un autre.

Vous pouvez réduire la redondance, simplifier la gestion et réduire le coût global en utilisant l’infrastructure de hub partagé pour prendre en charge plusieurs spokes.

Le rôle de chaque rayon peut consister à héberger différents types de charges de travail. Les rayons offrent également une approche modulaire pour les déploiements renouvelables des mêmes charges de travail. C’est le cas, par exemple, des phases de développement et de test, de tests d’acceptation par les utilisateurs, de mise en lots et de production.

Les rayons permettent également de séparer et d’activer différents groupes au sein de votre organisation. Les groupes Azure DevOps en sont un exemple. À l’intérieur d’un spoke, il est tout aussi possible de déployer une charge de travail de base que des charges de travail multiniveaux complexes avec un contrôle du trafic entre les différents niveaux.

La passerelle d’application présentée dans le diagramme ci-dessus peut fonctionner en étoile avec l’application qu’elle sert pour une meilleure gestion et une meilleure mise à l’échelle. Cependant, la stratégie d’entreprise peut vous obliger à placer la passerelle d’application dans le hub pour des raisons de gestion centralisée et de séparation des responsabilités.

Limites d’abonnement et concentrateurs multiples

Dans Azure, chaque type de composant est déployé dans un abonnement Azure. L’isolement des composants Azure dans différents abonnements Azure peut satisfaire aux exigences de différents métiers, telles que la configuration de niveaux différenciés d’accès et d’autorisation.

Une implémentation hub-and-spoke unique peut effectuer un scale-up pour atteindre un grand nombre de spokes. Toutefois, comme pour chaque système informatique, il existe des limites liées à la plateforme. Le déploiement du hub est lié à un abonnement Azure spécifique, qui comporte des restrictions et des limites. Le nombre maximal d’appairages de réseaux virtuels est un bon exemple. Pour plus d’informations, consultez Azure subscription and service limits (Limites de service et d’abonnement Azure).

Quand les limites sont un problème, vous pouvez effectuer un scale-up de l’architecture en étendant le modèle à un cluster de hubs et de spokes. Vous pouvez connecter plusieurs hubs dans une ou plusieurs régions Azure en utilisant les éléments suivants :

• Peering de réseau virtuel
• Azure ExpressRoute
• WAN virtuel Azure
• VPN site à site

Figure 2 : Cluster de réseaux hub-and-spoke.

L’introduction de plusieurs hubs augmente les frais généraux liés au coût et à la gestion du système. Cette augmentation est justifiée seulement par les éléments suivants :

• Extensibilité
• Limites du système
• Redondance et réplication régionale pour les performances utilisateur ou la reprise d’activité

Dans les scénarios qui nécessitent plusieurs hubs, ces derniers doivent s’efforcer tous d’offrir le même ensemble de services afin d’en faciliter l’exploitation.

Interconnexion entre les rayons

Il est possible d’implémenter des charges de travail multiniveaux complexes dans un même spoke. Vous pouvez implémenter des configurations multiniveaux à l’aide de sous-réseaux (un pour chaque niveau) dans le même réseau virtuel et en utilisant des groupes de sécurité réseau pour filtrer les flux.

Un architecte peut vouloir déployer une charge de travail multiniveau sur plusieurs réseaux virtuels. Avec le Peering de réseaux virtuels, vous pouvez connecter des spokes à d’autres spokes du même hub ou de hubs distincts.

Ce scénario s’applique généralement aux cas où les serveurs de traitement d’application sont situés dans un même spoke ou réseau virtuel. La base de données est déployée sur un autre spoke ou réseau virtuel. Dans ce cas, il est facile d’interconnecter les spokes grâce au Peering de réseaux virtuels et d’éviter le transit par le hub. Étudiez avec soin l’architecture et la sécurité pour vérifier que le contournement du hub n’élude pas de points de sécurité ou d’audit importants susceptibles qui se trouvent seulement dans le hub.

Figure 3 : Exemple de spokes se connectant entre eux et vers un hub.

Il est également possible d’interconnecter des rayons à un rayon jouant le rôle de concentrateur. Cette approche crée une hiérarchie à deux niveaux : le spoke du niveau supérieur (niveau 0) devient le hub de spokes de niveau inférieur (niveau 1) dans la hiérarchie. Les spokes sont nécessaires pour transférer le trafic vers le hub central. Cette exigence fait que le trafic peut transiter vers sa destination sur le réseau local ou sur l’Internet public. Une architecture à deux niveaux de hubs introduit un routage complexe qui supprime les avantages d’une relation hub-and-spoke simple.

Étapes suivantes

Maintenant que vous avez exploré les bonnes pratiques pour les réseaux, découvrez comment aborder l’identité et les contrôles d’accès.