Passer en revue le modèle de référence réseau de déploiement de stockage à serveur unique pour Azure Stack HCI

Article
04/24/2024

S’applique à : Azure Stack HCI, versions 23H2 et 22H2

Cet article décrit le modèle de référence réseau de stockage à serveur unique que vous pouvez utiliser pour déployer votre solution Azure Stack HCI. Les informations de cet article vous aident également à déterminer si cette configuration est viable pour vos besoins de planification de déploiement. Cet article s’adresse aux administrateurs informatiques qui déploient et gèrent Azure Stack HCI dans leurs centres de données.

Pour plus d’informations sur les autres modèles de réseau, consultez Modèles de déploiement réseau Azure Stack HCI.

Introduction

Les déploiements à serveur unique offrent des avantages en matière de coûts et d’espace tout en vous aidant à moderniser votre infrastructure et à intégrer l’informatique hybride Azure à des emplacements qui peuvent tolérer la résilience d’un seul serveur. Azure Stack HCI exécuté sur un serveur unique se comporte de la même façon qu’Azure Stack HCI sur un cluster à plusieurs nœuds : il offre l’intégration Native d’Azure Arc, la possibilité d’ajouter des serveurs pour effectuer un scale-out du cluster et inclut les mêmes avantages Azure.

Il prend également en charge les mêmes charges de travail, telles qu’Azure Virtual Desktop (AVD) et AKS sur Azure Stack HCI, et est pris en charge et facturé de la même façon.

Scénarios

Utilisez le modèle de stockage à serveur unique dans les scénarios suivants :

Installations qui peuvent tolérer un niveau de résilience inférieur. Envisagez d’implémenter ce modèle chaque fois que votre emplacement ou service fourni par ce modèle peut tolérer un niveau de résilience inférieur sans affecter votre entreprise.
Alimentation, santé, finance, vente au détail, installations gouvernementales. Certains scénarios alimentaires, de santé, de finances et de vente au détail peuvent appliquer cette option pour réduire leurs coûts sans affecter les opérations de base et les transactions commerciales.

Bien que les services SDN (Software Defined Networking) couche 3 (L3) soient entièrement pris en charge sur ce modèle, les services de routage tels que le protocole BGP (Border Gateway Protocol) peuvent avoir besoin d’être configurés pour le périphérique de pare-feu sur le commutateur TOR (Top-of-Rack).

Les fonctionnalités de sécurité réseau telles que la microsegmentation et la qualité de service (QoS) ne nécessitent pas de configuration supplémentaire pour l’appareil de pare-feu, car elles sont implémentées au niveau de la couche de carte réseau virtuelle. Pour plus d’informations, consultez Microsegmentation avec Azure Stack HCI.

Notes

Les serveurs uniques ne doivent utiliser qu’un seul type de lecteur : disques NVMe (Memory Express) non volatiles ou Solid-State (SSD).

Composants de connectivité physique

Comme illustré dans le diagramme ci-dessous, ce modèle comporte les composants réseau physiques suivants :

Pour le trafic en direction nord/sud, le cluster Azure Stack HCI est implémenté à l’aide d’un seul commutateur TOR L2 ou L3.
Deux ports réseau en équipe pour gérer le trafic de gestion et de calcul connecté au commutateur.
Deux cartes réseau RDMA déconnectées qui sont utilisées uniquement si vous ajoutez un deuxième serveur à votre cluster pour un scale-out. Cela signifie qu’il n’y a pas d’augmentation des coûts de câblage ou de ports de commutateur physique.
(Facultatif) Un carte BMC peut être utilisé pour activer la gestion à distance de votre environnement. Pour des raisons de sécurité, certaines solutions peuvent utiliser une configuration sans tête sans le carte BMC.

Le tableau suivant répertorie quelques recommandations pour un déploiement à serveur unique :

Réseau	Gestion & calcul	Stockage	BMC
Vitesse de liaison	Au moins 1 Gbits/s si RDMA est désactivé, 10 Gbits/s recommandés.	Au moins 10 Gbits/s.	Vérifiez auprès du fabricant du matériel.
Type d'interface	RJ45, SFP+ ou SFP28	SFP+ ou SFP28	RJ45
Ports et agrégation	Deux ports en association	Facultatif pour autoriser l’ajout d’un deuxième serveur ; ports déconnectés.	Un port
RDMA	facultatif. Dépend de la configuration requise pour la prise en charge du RDMA invité et de la carte réseau.	N/A	N/A

Intentions de Network ATC

Le modèle à serveur unique utilise une seule intention Network ATC pour la gestion et le calcul du trafic. Les interfaces réseau RDMA sont facultatives et déconnectées.

Intention de gestion et de calcul

L’intention de gestion et de calcul présente les caractéristiques suivantes :

Type d’intention : Gestion et calcul
Mode intention : mode cluster
Association : Oui - pNIC01 et pNIC02 sont associées
VLAN de gestion par défaut : le réseau local virtuel configuré pour les adaptateurs de gestion est modifié
Réseau local virtuel pa et vNICC : Network ATC est transparent pour les cartes réseau virtuelles pa et les réseaux locaux virtuels
Calcul de réseaux locaux virtuels et de réseaux virtuels : Network ATC est transparent pour calculer les réseaux réseau virtuels et les réseaux locaux virtuels

Intention de stockage

L’intention de stockage présente les caractéristiques suivantes :

Type d’intention : Aucun
Mode Intention : Aucun
Association : pNIC03 et pNIC04 sont déconnectés
Réseaux locaux virtuels par défaut : Aucun
Sous-réseaux par défaut : Aucun

Procédez comme suit pour créer une intention réseau pour ce modèle de référence :

Exécutez PowerShell en tant qu’administrateur.

Exécutez la commande suivante :

Add-NetIntent -Name <management_compute> -Management -Compute -ClusterName <HCI01> -AdapterName <pNIC01, pNIC02>

Pour plus d’informations, consultez Déployer la mise en réseau hôte : intention de calcul et de gestion.

Composants de réseau logique

Comme illustré dans le diagramme ci-dessous, ce modèle comporte les composants de réseau logique suivants :

Réseaux locaux virtuels du réseau de stockage

Facultatif : ce modèle ne nécessite pas de réseau de stockage.

Réseau OOB

Le réseau OOB (Out of Band) est dédié à la prise en charge de l’interface de gestion de serveur « lights-out », également appelée contrôleur de gestion de la carte de base (BMC). Chaque interface BMC se connecte à un commutateur fourni par le client. Le contrôleur BMC est utilisé pour automatiser les scénarios de démarrage PXE.

Le réseau de gestion nécessite l’accès à l’interface BMC à l’aide du port UDP (Intelligent Platform Management Interface) IPMI (Intelligent Platform Management Interface) 623.

Le réseau OOB est isolé des charges de travail de calcul et est facultatif pour les déploiements non basés sur une solution.

VLAN de gestion

Tous les hôtes de calcul physiques ont besoin d’un accès au réseau logique de gestion. Pour la planification des adresses IP, chaque hôte de calcul physique doit avoir au moins une adresse IP affectée à partir du réseau logique de gestion.

Un serveur DHCP peut attribuer automatiquement des adresses IP pour le réseau de gestion, ou vous pouvez attribuer manuellement des adresses IP statiques. Lorsque DHCP est la méthode d’affectation IP préférée, nous vous recommandons d’utiliser des réservations DHCP sans expiration.

Le réseau de gestion prend en charge les configurations de réseau local virtuel suivantes :

VLAN natif : vous n’êtes pas obligé de fournir des ID de VLAN. Cela est requis pour les installations basées sur la solution.
VLAN balisé : vous fournissez des ID de VLAN au moment du déploiement. les connexions de locataire sur chaque passerelle et bascule les flux de trafic réseau vers une passerelle de secours en cas de défaillance d’une passerelle.

Les passerelles utilisent Border Gateway Protocol pour publier des points de terminaison GRE et établir des connexions point à point. Le déploiement SDN crée un pool de passerelles par défaut qui prend en charge tous les types de connexion. Dans ce pool, vous pouvez spécifier le nombre de passerelles réservées en mode veille en cas d’échec d’une passerelle active.

Pour plus d’informations, consultez Qu’est-ce que la passerelle RAS pour le SDN ?

Le réseau de gestion prend en charge tout le trafic utilisé pour la gestion du cluster, y compris le Bureau à distance, Windows Admin Center et Active Directory.

Pour plus d’informations, consultez Planifier une infrastructure SDN : Gestion et fournisseur HNV.

Réseaux locaux virtuels de calcul

Dans certains scénarios, vous n’avez pas besoin d’utiliser des réseaux virtuels SDN avec l’encapsulation VXLAN (Virtual Extensible LAN). Au lieu de cela, vous pouvez utiliser des réseaux locaux virtuels traditionnels pour isoler vos charges de travail de locataire. Ces réseaux locaux virtuels sont configurés sur le port du commutateur TOR en mode jonction. Lors de la connexion de nouvelles machines virtuelles à ces réseaux locaux virtuels, la balise VLAN correspondante est définie sur la carte réseau virtuelle.

Réseau d’adresse du fournisseur HNV (PA)

Le réseau hNV (Hyper-V Network Virtualization) Provider Address (PA) sert de réseau physique sous-jacent pour le trafic client Est/Ouest (interne), le trafic client Nord/Sud (externe-interne) et pour échanger des informations de peering BGP avec le réseau physique. Ce réseau n’est requis que lorsqu’il est nécessaire de déployer des réseaux virtuels à l’aide de l’encapsulation VXLAN pour une autre couche d’isolation et pour la mutualisation du réseau.

Pour plus d’informations, consultez Planifier une infrastructure SDN : Gestion et fournisseur HNV.

Options d’isolement réseau

Les options d’isolation réseau suivantes sont prises en charge :

Réseaux locaux virtuels (IEEE 802.1Q)

Les réseaux locaux virtuels permettent aux appareils qui doivent être séparés de partager le câblage d’un réseau physique tout en étant empêchés d’interagir directement les uns avec les autres. Ce partage managé génère des gains en matière de simplicité, de sécurité, de gestion du trafic et d’économie. Par exemple, un VLAN peut être utilisé pour séparer le trafic au sein d’une entreprise en fonction d’utilisateurs individuels ou de groupes d’utilisateurs ou de leurs rôles, ou en fonction des caractéristiques du trafic. De nombreux services d’hébergement Internet utilisent des réseaux locaux virtuels pour séparer les zones privées les unes des autres, ce qui permet aux serveurs de chaque client d’être regroupés dans un segment réseau unique, quel que soit l’emplacement des serveurs individuels dans le centre de données. Certaines précautions sont nécessaires pour empêcher le trafic de s’échapper d’un VLAN donné, un exploit connu sous le nom de saut VLAN.

Pour plus d’informations, consultez Comprendre l’utilisation des réseaux virtuels et des réseaux locaux virtuels.

Stratégies d’accès réseau et microsegmentation par défaut

Les stratégies d’accès réseau par défaut garantissent que toutes les machines virtuelles de votre cluster Azure Stack HCI sont sécurisées par défaut contre les menaces externes. Avec ces stratégies, nous allons bloquer l’accès entrant à une machine virtuelle par défaut, tout en donnant la possibilité d’activer des ports entrants sélectifs et de sécuriser ainsi les machines virtuelles contre les attaques externes. Cette application est disponible via des outils de gestion tels que Windows Admin Center.

La microsegmentation implique la création de stratégies réseau granulaires entre les applications et les services. Cela réduit essentiellement le périmètre de sécurité à une clôture autour de chaque application ou machine virtuelle. Cette clôture permet uniquement la communication nécessaire entre les niveaux d’application ou d’autres limites logiques, ce qui rend extrêmement difficile la propagation latérale des cybermenaces d’un système à un autre. La microsegmentation isole de manière sécurisée les réseaux les uns des autres et réduit la surface d’attaque totale d’un incident de sécurité réseau.

Les stratégies d’accès réseau et la microsegmentation par défaut sont réalisées sous forme de règles de pare-feu avec état à cinq tuples (préfixe d’adresse source, port source, préfixe d’adresse de destination, port de destination et protocole) sur les clusters Azure Stack HCI. Les règles de pare-feu sont également appelées Groupes de sécurité réseau (NSG). Ces stratégies sont appliquées au port vSwitch de chaque machine virtuelle. Les stratégies sont envoyées via la couche de gestion et le contrôleur de réseau SDN les distribue à tous les hôtes applicables. Ces stratégies sont disponibles pour les machines virtuelles sur les réseaux VLAN traditionnels et sur les réseaux de superposition SDN.

Pour plus d’informations, consultez Qu’est-ce que le pare-feu du centre de données ?.

QoS pour les cartes réseau de machine virtuelle

Vous pouvez configurer la qualité de service (QoS) pour une carte réseau de machine virtuelle afin de limiter la bande passante sur une interface virtuelle afin d’empêcher une machine virtuelle à trafic élevé de se heurter à d’autres trafics réseau de machines virtuelles. Vous pouvez également configurer QoS pour réserver une quantité spécifique de bande passante pour une machine virtuelle afin de garantir que la machine virtuelle peut envoyer du trafic, quel que soit le trafic sur le réseau. Cela peut être appliqué aux machines virtuelles attachées à des réseaux locaux virtuels traditionnels, ainsi qu’aux machines virtuelles attachées à des réseaux de superposition SDN.

Pour plus d’informations, consultez Configurer qoS pour une carte réseau de machine virtuelle.

Réseaux virtuels

La virtualisation réseau fournit des réseaux virtuels aux machines virtuelles comme la virtualisation de serveur (hyperviseur) fournit des machines virtuelles au système d’exploitation. La virtualisation de réseau dissocie les réseaux virtuels de l’infrastructure réseau physique et supprime les contraintes liées à l’attribution d’adresses IP hiérarchiques et au réseau local virtuel du provisionnement de machines virtuelles. Cette flexibilité facilite le déplacement vers les clouds IaaS (Infrastructure-as-a-Service) et permet aux hôtes et aux administrateurs de centre de données de gérer leur infrastructure et de maintenir l’isolation multilocataire nécessaire, les exigences de sécurité et les adresses IP des machines virtuelles qui se chevauchent.

Pour plus d’informations, consultez Virtualisation de réseau Hyper-V.

Options des services réseau L3

Les options de service réseau L3 suivantes sont disponibles :

Peering de réseau virtuel

Le peering de réseaux virtuels vous permet de connecter deux réseaux virtuels de manière transparente. Une fois le peering établi, à des fins de connectivité, les réseaux virtuels apparaissent sous la forme d’un seul réseau. Voici quelques-uns des avantages du peering de réseaux virtuels :

Le trafic entre les machines virtuelles des réseaux virtuels appairés est acheminé via l’infrastructure principale via des adresses IP privées uniquement. La communication entre les réseaux virtuels ne nécessite pas d’Internet public ou de passerelles.
Connexion à latence faible et haut débit entre les ressources de différents réseaux virtuels.
Possibilité pour les ressources d’un réseau virtuel de communiquer avec celles d’un autre réseau virtuel.
Aucun temps d’arrêt pour les ressources des réseaux virtuels au moment de la création du peering.

Pour en savoir plus, consultez Peering de réseaux virtuels.

Équilibreur de charge logiciel SDN

Les fournisseurs de services cloud (CSP) et les entreprises qui déploient la mise en réseau définie par logiciel (SDN) peuvent utiliser software Load Balancer (SLB) pour répartir uniformément le trafic réseau client entre les ressources de réseau virtuel. L’équilibrage de charge logicielle (SLB) permet à plusieurs serveurs d’héberger une même charge de travail, ce qui assure une disponibilité et une scalabilité de haut niveau. Il est également utilisé pour fournir des services NAT (Network Address Translation) entrants pour l’accès entrant aux machines virtuelles et des services NAT sortants pour la connectivité sortante.

À l’aide de SLB, vous pouvez effectuer un scale-out de vos fonctionnalités d’équilibrage de charge à l’aide de machines virtuelles SLB sur les mêmes serveurs de calcul Hyper-V que pour vos autres charges de travail de machine virtuelle. SLB prend en charge la création et la suppression rapides de points de terminaison d’équilibrage de charge en fonction des besoins pour les opérations CSP. En outre, SLB prend en charge des dizaines de gigaoctets par cluster, fournit un modèle d’approvisionnement simple et est facile à effectuer un scale-out et un scale-in facile. SLB utilise le Border Gateway Protocol pour publier des adresses IP virtuelles sur le réseau physique.

Pour plus d’informations, consultez Qu’est-ce que la SLB pour SDN ?

Passerelles VPN SDN

La passerelle SDN est un routeur compatible BGP (Border Gateway Protocol) logiciel conçu pour les fournisseurs de services partagés et les entreprises qui hébergent des réseaux virtuels multilocataires à l’aide de la virtualisation de réseau Hyper-V (HNV). Vous pouvez utiliser la passerelle RAS pour router le trafic réseau entre un réseau virtuel et un autre réseau, qu’il soit local ou distant.

La passerelle SDN peut être utilisée pour :

créer des connexions IPsec de site à site sécurisées entre des réseaux virtuels SDN et des réseaux clients externes sur Internet.
créer des connexions de l’encapsulation de routage générique (GRE) entre les réseaux virtuels SDN et les réseaux externes. La différence entre les connexions de site à site et les connexions GRE est que cette dernière n’est pas une connexion chiffrée.

Pour plus d’informations sur les scénarios de connectivité GRE, consultez Tunneling GRE dans Windows Server.
Create connexions de couche 3 (L3) entre les réseaux virtuels SDN et les réseaux externes. Dans ce cas, la passerelle SDN agit simplement comme un routeur entre votre réseau virtuel et le réseau externe.

La passerelle SDN nécessite un contrôleur de réseau SDN. Le contrôleur de réseau effectue le déploiement de pools de passerelles, configure

Étapes suivantes

Découvrez les modèles à deux nœuds : modèles de déploiement réseau Azure Stack HCI.

Partager via