Planification de l’intégration réseau pour Azure Stack Hub

Cet article fournit des informations sur l’infrastructure réseau Azure Stack Hub pour vous aider à déterminer comment intégrer Azure Stack Hub au sein de votre environnement réseau existant.

Conception du réseau physique

La solution Azure Stack Hub nécessite une infrastructure physique résiliente et hautement disponible pour prendre en charge son fonctionnement et ses services. Pour intégrer Azure Stack Hub au réseau, il nécessite des liaisons montantes entre les commutateurs Top-of-Rack (ToR) et le commutateur ou le routeur le plus proche, qui, dans cet article, est appelé Bordure. Les commutateurs TDR peuvent avoir une liaison montante à une seule bordure ou à deux bordures. Le ToR est préconfiguré par notre outil d’automatisation. Il attend un minimum d’une connexion entre ToR et Border lors de l’utilisation du routage BGP et d’un minimum de deux connexions (une par ToR) entre ToR et Border lors de l’utilisation du routage statique, avec un maximum de quatre connexions sur l’une ou l’autre option de routage. Ces connexions sont limitées au média SFP+ ou SFP28 et à une vitesse minimale d’un Go. Vérifiez auprès de votre fabricant de matériel OEM (Original Equipment Manufacturer) la disponibilité. Le diagramme suivant présente la conception recommandée :

Allocation de bande passante

Azure Stack Hub est créé à l’aide des technologies de cluster de basculement Windows Server 2022 et Spaces Direct. Pour vous assurer que les communications de stockage Direct Spaces peuvent répondre aux performances et à l’échelle requises de la solution, une partie de la configuration du réseau physique Azure Stack Hub est configurée pour utiliser les garanties de séparation du trafic et de bande passante. La configuration réseau utilise des classes de trafic pour séparer les communications basées sur Spaces Direct, RDMA de celles de l’utilisation du réseau par l’infrastructure Azure Stack Hub et/ou le locataire. Pour s’aligner sur les meilleures pratiques actuelles définies pour Windows Server 2022, Azure Stack Hub modifie son utilisation d'une classe de trafic ou d'une priorité supplémentaire pour mieux séparer la communication entre serveurs, en appui de la communication de contrôle du clustering de basculement. Cette nouvelle définition de classe de trafic est configurée pour réserver 2% de la bande passante physique disponible. Cette configuration de réservation de bande passante et de classe de trafic est opérée par une modification des commutateurs ToR (top-of-rack) de la solution Azure Stack Hub, ainsi que sur l’ordinateur hôte ou les serveurs d’Azure Stack Hub. Notez que les modifications ne sont pas requises sur les appareils réseau frontaliers du client. Ces modifications offrent une meilleure résilience pour la communication du cluster de basculement et sont destinées à éviter les situations où la bande passante réseau est entièrement consommée et, par conséquent, les messages de contrôle du cluster de basculement sont interrompus. Notez que la communication du cluster de basculement est un composant essentiel de l’infrastructure Azure Stack Hub et qu’en cas d’interruption pendant des périodes prolongées, elle peut entraîner une instabilité dans les espaces de stockage Spaces Direct ou d’autres services, susceptible d’affecter la stabilité de la charge de travail du locataire ou de l’utilisateur final.

Réseaux logiques

Les réseaux logiques représentent une abstraction de l’infrastructure réseau physique sous-jacente. Ils sont utilisés pour organiser et simplifier les affectations réseau pour les hôtes, les machines virtuelles et les services. Dans le cadre de la création de réseaux logiques, les sites réseau sont créés pour définir les réseaux locaux virtuels (VLAN), les sous-réseaux IP et les paires sous-réseau IP/réseau local virtuel associées au réseau logique dans chaque emplacement physique.

Le tableau suivant présente les réseaux logiques et les plages de sous-réseaux IPv4 associées que vous devez planifier :

Infrastructure réseau

L’infrastructure réseau pour Azure Stack Hub se compose de plusieurs réseaux logiques configurés sur les commutateurs. Le diagramme suivant montre ces réseaux logiques et comment ils s’intègrent aux commutateurs tor (top-of-rack), BMC (Baseboard Management Controller) et border (réseau client).

Réseau BMC

Ce réseau est dédié à connecter tous les contrôleurs de gestion de carte de base (également appelés processeurs BMC ou de service) au réseau de gestion. Voici quelques exemples : iDRAC, iLO, iBMC, et ainsi de suite. Un seul compte BMC est utilisé pour communiquer avec n’importe quel nœud BMC. S’il est présent, l’hôte de cycle de vie du matériel (HLH) se trouve sur ce réseau et peut fournir des logiciels spécifiques à l’OEM pour la maintenance ou la surveillance matérielles.

HlH héberge également la machine virtuelle de déploiement (DVM). La machine virtuelle DVM est utilisée pendant le déploiement d’Azure Stack Hub et est supprimée une fois le déploiement terminé. La machine virtuelle DVM nécessite un accès Internet dans des scénarios de déploiement connectés pour tester, valider et accéder à plusieurs composants. Ces composants peuvent être à l’intérieur et à l’extérieur de votre réseau d’entreprise (par exemple : NTP, DNS et Azure). Pour plus d’informations sur les exigences de connectivité, consultez la section NAT dans l’intégration du pare-feu Azure Stack Hub.

Réseau privé

Ce réseau /20 (4096 adresses IP) est privé dans la région Azure Stack Hub (n’est pas acheminé au-delà des appareils de commutateur de bordure du système Azure Stack Hub) et est divisé en plusieurs sous-réseaux, voici quelques exemples :

• Réseau de stockage : réseau /25 (128 adresses IP) utilisé pour prendre en charge l’utilisation du trafic de stockage SMB (Spaces Direct and Server Message Block) et de la migration dynamique de machine virtuelle.
• Réseau adresses IP virtuelles internes: un réseau /25 exclusivement dédié aux adresses IP virtuelles internes pour l’équilibreur de charge logiciel.
• Réseau de conteneurs : réseau /23 (512 adresses IP) dédié au trafic interne uniquement entre les conteneurs exécutant des services d’infrastructure.

Le système Azure Stack Hub nécessite un espace IP interne privé /20 supplémentaire. Ce réseau est privé du système Azure Stack Hub (n’est pas acheminé au-delà des appareils de basculement de frontière du système Azure Stack Hub) et peut être réutilisé sur plusieurs systèmes Azure Stack Hub au sein de votre centre de données. Bien que le réseau soit privé dans Azure Stack, il ne doit pas chevaucher d’autres réseaux dans le centre de données. L’espace IP privé /20 est divisé en plusieurs réseaux qui permettent d’exécuter l’infrastructure Azure Stack Hub sur des conteneurs. En outre, ce nouvel espace IP privé permet de réduire l’espace IP routable requis avant le déploiement. L’objectif de l’exécution de l’infrastructure Azure Stack Hub dans les conteneurs est d’optimiser l’utilisation et d’améliorer les performances. En outre, l’espace IP privé /20 est également utilisé pour permettre des efforts continus qui réduisent l’espace IP routable requis avant le déploiement. Pour obtenir des conseils sur l’espace IP privé, consultez RFC 1918.

Réseau d’infrastructure Azure Stack Hub

Ce réseau /24 est dédié aux composants Azure Stack Hub internes afin qu’ils puissent communiquer et échanger des données entre eux. Ce sous-réseau peut être routable en externe à partir de la solution Azure Stack Hub vers votre centre de données. Nous vous déconseillons d’utiliser des adresses IP routables publiques ou Internet sur ce sous-réseau. Ce réseau est diffusé jusqu'à la bordure, mais la plupart de ses adresses IP sont protégées par des Listes de Contrôle d'Accès (ACL). Les adresses IP autorisées pour l’accès se trouvent dans une petite plage, d’une taille équivalente à un réseau /27 et à des services hôtes tels que le point de terminaison privilégié (PEP) et la sauvegarde Azure Stack Hub.

Réseau VIP public

Le réseau VIP public est assigné au contrôleur de réseau dans Azure Stack. Ce n’est pas un réseau logique sur le commutateur. Le SLB utilise le pool d’adresses et assigne des réseaux /32 pour les charges de travail clientes. Dans la table de routage du commutateur, ces adresses IP /32 sont publiées en tant qu’itinéraire disponible via BGP. Ce réseau contient les adresses IP publiques ou externes. L’infrastructure Azure Stack Hub réserve les 31 premières adresses de ce réseau d’adresses IP virtuelles publiques, tandis que les adresses restantes sont utilisées par des machines virtuelles de locataire. La taille du réseau sur ce sous-réseau peut passer d’un minimum de /26 (64 hôtes) à un maximum de /22 (1022 hôtes). Nous vous recommandons de planifier un réseau /24.

Connexion à des réseaux locaux

Azure Stack Hub utilise des réseaux virtuels pour les ressources client telles que les machines virtuelles, les équilibreurs de charge et d’autres.

Il existe plusieurs options différentes pour se connecter à partir de ressources à l’intérieur du réseau virtuel à des ressources locales/d’entreprise :

• Utilisez des adresses IP publiques du réseau VIP public.
• Utilisez la passerelle de réseau virtuel ou l’appliance virtuelle réseau (NVA).

Lorsqu’un tunnel VPN S2S est utilisé pour connecter des ressources à des réseaux locaux ou à partir de réseaux locaux, vous pouvez rencontrer un scénario dans lequel une ressource a également une adresse IP publique affectée, et elle n’est plus accessible via cette adresse IP publique. Si la tentative de la source d’accéder à l’adresse IP publique tombe dans la même plage de sous-réseau définie par les routes de passerelle de réseau local (passerelle de réseau virtuel) ou par une route utilisateur pour les solutions NVA, Azure Stack Hub tente de router le trafic sortant vers la source via le tunnel S2S selon les règles de routage configurées. Le trafic de retour utilise l’adresse IP privée de la machine virtuelle, plutôt que d’être traduit par la source en tant qu’adresse IP publique :

Il existe deux solutions à ce problème :

• Acheminer le trafic dirigé vers le réseau VIP public vers Internet.
• Ajoutez un périphérique NAT pour traduire les adresses IP de sous-réseau définies dans la passerelle de réseau local dirigée vers le réseau d’adresse IP virtuelle publique.

Réseau d’infrastructure du commutateur

Ce réseau /26 est le sous-réseau contenant des sous-réseaux IP point à point routables /30 (2 adresses IP d’hôte) et les bouclages dédiés aux sous-réseaux /32 pour la gestion du commutateur intrabande et l’ID de routeur BGP. Cette plage d’adresses IP doit être routable en dehors de la solution Azure Stack Hub vers votre centre de données. Ils peuvent être des adresses IP privées ou publiques.

Réseau de gestion des commutateurs

Ce réseau /29 (six adresses IP hôtes) est dédié à la connexion des ports de gestion des commutateurs. Il autorise l’accès hors bande pour le déploiement, la gestion et la résolution des problèmes. Elle est calculée à partir du réseau d’infrastructure de commutateur mentionné précédemment.

Réseaux autorisés

La feuille de calcul de déploiement a un champ permettant à l’opérateur de modifier certaines listes de contrôle d’accès afin d’autoriser l’accès aux interfaces de gestion des périphériques réseau et à l’hôte de cycle de vie du matériel (HLH) à partir d’une plage réseau de centres de données approuvée. Avec la modification de la liste de contrôle d’accès, l’opérateur peut autoriser ses machines virtuelles de jumpbox de gestion au sein d’une plage réseau spécifique à accéder à l’interface de gestion des commutateurs et au système d’exploitation HLH. L’opérateur peut fournir un ou plusieurs sous-réseaux à cette liste ; si elle est vide, elle refuse par défaut l’accès. Cette nouvelle fonctionnalité supprime la nécessité d'une intervention manuelle après le déploiement, comme c'était auparavant requis dans la section Modification des paramètres spécifiques de configuration de votre commutateur Azure Stack Hub.

Étapes suivantes

• Routage du trafic de réseau virtuel
• En savoir plus sur la planification du réseau : Connectivité frontalière