Partager via

Exigences liées aux réseaux d’hôtes pour Azure Stack HCI

  • Article

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

Cette rubrique traite des exigences et considérations relatives à la mise en réseau hôte pour Azure Stack HCI. Pour plus d’informations sur les architectures de centre de données et les connexions physiques entre les serveurs, consultez Configurations requises des réseaux virtuels.

Pour plus d'informations sur la façon de simplifier la mise en réseau des hôtes à l'aide de Network ATC, consultez Simplifier la mise en réseau des hôtes avec Network ATC.

Types de trafic réseau

Le trafic réseau Azure Stack HCI peut être classé selon son rôle prévu :

  • Trafic de gestion : trafic à destination ou en provenance de l’extérieur du cluster local. Il s’agit par exemple du trafic du réplica de stockage ou du trafic utilisé par l’administrateur pour la gestion du cluster comme Bureau à distance, Windows Admin Center, Active Directory, etc.
  • Trafic de calcul : trafic en provenance ou à destination d’une machine virtuelle (VM).
  • Trafic de stockage : Trafic utilisant le protocole SMB, par exemple pour les espaces de stockage direct ou la migration dynamique basée sur SMB. Ce trafic est de couche 2 et n’est pas routable.

Important

Le réplica de stockage utilise un trafic SMB non basé sur RDMA. Ceci et la nature directionnelle du trafic (Nord-Sud) entraînent un alignement étroit sur le trafic de « gestion » listé ci-dessus, similaire à celui d’un partage de fichiers traditionnel.

Sélectionner une carte réseau

Les cartes réseau sont qualifiées par les types de trafic réseau (voir ci-dessus) qu’ils sont pris en charge pour une utilisation. Lorsque vous passez en revue le catalogue Windows Server, la certification Windows Server 2022 indique maintenant un ou plusieurs des rôles suivants. Avant d’acheter un serveur pour Azure Stack HCI, vous devez disposer au minimum d’un adaptateur qualifié pour la gestion, le calcul et le stockage, car les trois types de trafic sont requis sur Azure Stack HCI. Vous pouvez ensuite utiliser Network ATC pour configurer vos adaptateurs pour les types de trafic appropriés.

Pour plus d’informations sur cette qualification de carte réseau basée sur les rôles, consultez ce lien.

Important

L’utilisation d’un adaptateur en dehors de son type de trafic qualifié n’est pas prise en charge.

Niveau Rôle de gestion Rôle de calcul Rôle de stockage
Distinction basée sur les rôles Gestion Standard de calcul Standard de stockage
Prix maximal Non applicable Calcul Premium Stockage Premium

Remarque

La qualification la plus élevée pour n’importe quel adaptateur de notre écosystème contiendra les qualifications Gestion, Calcul Premium et Stockage Premium.

Capture d’écran montrant les qualifications « Certifiées pour Windows », notamment les fonctionnalités Gestion, Compute Premium et Stockage Premium.

Configuration requise des pilotes

Les pilotes de boîte de réception ne sont pas pris en charge pour une utilisation avec Azure Stack HCI. Pour identifier si votre adaptateur utilise un pilote de boîte de réception, exécutez l’applet de commande suivante. Un adaptateur utilise un pilote de boîte de réception si la propriété DriverProvider est Microsoft.

Get-NetAdapter -Name <AdapterName> | Select *Driver*

Vue d’ensemble des principales fonctionnalités des cartes réseau

Les principales fonctionnalités des cartes réseau utilisées par Azure Stack HCI comprennent :

  • File d’attente multiple de machines virtuelles dynamique (Dynamic VMMQ, ou d.VMMQ)
  • Accès direct à la mémoire à distance (RDMA, Remote Direct Memory Access)
  • RDMA invité
  • SET (Switch Embedded Teaming)

Dynamic VMMQ

Toutes les cartes réseau avec la qualification Compute (Premium) prennent en charge Dynamic VMMQ. Cette technologie impose d’utiliser la fonctionnalité Switch Embedded Teaming.

Types de trafic applicables : calcul

Certifications requises : Calcul (Premium)

Dynamic VMMQ est une technologie intelligente côté réception. Il s’appuie sur ses prédécesseurs, File d’attente d’ordinateurs virtuels (VMQ), Mise à l’échelle côté réception virtuelle (vRSS) et VMMQ, pour offrir trois améliorations principales :

  • optimisation de l’efficacité des hôtes en utilisant moins de cœurs de processeur ;
  • réglage automatique du traitement du trafic réseau sur les cœurs de processeur, permettant ainsi aux machines virtuelles de respecter et de maintenir le débit attendu ;
  • Permet aux charges de travail « bursty » de recevoir la quantité attendue de trafic.

Pour plus d’informations sur la fonctionnalité Dynamic VMMQ, consultez le billet de blog Accélérations synthétiques.

RDMA

RDMA est un déchargement de la pile réseau vers la carte réseau. Cela permet au trafic de stockage SMB de contourner le système d’exploitation pour traitement.

La fonctionnalité RDMA permet une mise en réseau à débit élevé et faible latence avec une utilisation minimale des ressources de processeur hôte. Ces ressources peuvent alors servir à exécuter des machines virtuelles ou des conteneurs supplémentaires.

Types de trafic applicables : stockage hôte

Certifications requises : Stockage (Standard)

Tous les adaptateurs avec la qualification stockage (Standard) ou Stockage (Premium) prennent en charge RDMA côté hôte. Pour plus d’informations sur l’utilisation de RDMA avec des charges de travail invitées, consultez la section « RdMA invité » plus loin dans cet article.

Azure Stack HCI prend en charge RDMA avec les implémentations de protocole RDMA (iWARP) ou RDMA sur des implémentations de protocole Ethernet convergé (RoCE).

Important

Les adaptateurs RDMA fonctionnent uniquement avec d’autres adaptateurs RDMA qui implémentent le même protocole RDMA (iWARP ou RoCE).

Toutes les cartes réseau des fournisseurs ne prennent pas en charge la fonctionnalité RDMA. Le tableau suivant répertorie les fournisseurs (par ordre alphabétique) qui offrent des adaptateurs RDMA certifiés. Toutefois, il existe des fabricants de matériel qui ne figurent pas dans cette liste et prennent également en charge la fonctionnalité RDMA. Consultez le catalogue Windows Server pour rechercher des adaptateurs avec la qualification Stockage (Standard) ou Stockage (Premium) qui nécessitent une prise en charge RDMA.

Remarque

InfiniBand (IB) n’est pas pris en charge avec Azure Stack HCI.

Fournisseur de cartes réseau iWARP RoCE
Broadcom Non Oui
Intel Oui Oui (certains modèles)
Marvell (Qlogic) Oui Oui
Nvidia Non Oui

Pour plus d’informations sur le déploiement de RDMA pour l’hôte, nous vous recommandons vivement d’utiliser Network ATC. Pour plus d’informations sur le déploiement manuel, consultez le référentiel GitHub SDN.

iWARP

iWARP utilise le protocole TCP (Transmission Control Protocol) et peut éventuellement être amélioré avec les standards PFC (Priority-based Flow Control) et ETS (Enhanced Transmission Service).

Utilisez iWARP si :

  • Vous n’avez pas d’expérience de gestion des réseaux RDMA.
  • Vous ne gérez pas ou n’êtes pas à l’aise avec la gestion de vos commutateurs toR (top-of-rack).
  • Vous n’êtes pas la personne qui gère la solution après le déploiement.
  • Vous avez déjà effectué des déploiements utilisant iWARP.
  • Vous ne savez pas quelle option choisir.

RoCE

RoCE utilise le protocole UDP (User Datagram Protocol) et demande à PFC et ETS d’assurer sa fiabilité.

Utilisez RoCE si :

  • Votre centre de données comporte déjà des déploiements avec RoCE.
  • Vous êtes à l’aise avec la gestion de la configuration réseau DCB requise.

RDMA invité

La fonctionnalité RDMA invité permet aux charges de travail SMB pour machines virtuelles de bénéficier des avantages offerts par la technologie RDMA sur les hôtes.

Types de trafic applicables : stockage basé sur l’invité

Certifications requises : Calcul (Premium)

Voici les principaux avantages de la fonctionnalité RDMA invité :

  • Déchargement du processeur sur la carte d’interface réseau pour le traitement du trafic réseau.
  • Latence extrêmement faible.
  • Débit élevé.

Pour plus d’informations, téléchargez le document depuis le Référentiel SDN GitHub.

SET (Switch Embedded Teaming)

SET (Switch Embedded Teaming ) est une technologie d’association basée sur des logiciels qui a été intégrée dans le système d’exploitation Windows Server depuis la version Windows Server 2016. La fonctionnalité SET est la seule technologie d’association prise en charge par Azure Stack HCI. SET fonctionne bien avec le trafic de calcul, de stockage et de gestion et est pris en charge avec jusqu’à huit adaptateurs dans la même équipe.

Types de trafic applicables : calcul, stockage et gestion

Certifications requises : Calcul (Standard) ou Calcul (Premium)

La fonctionnalité SET est la seule technologie d’association prise en charge par Azure Stack HCI. La fonctionnalité SET fonctionne avec le trafic de calcul, de stockage et de gestion.

Important

Azure Stack HCI ne prend pas en charge l’association de cartes réseau avec l’ancien équilibrage de charge/basculement (LBFO). Pour plus d’informations sur la technologie LBFO dans Azure Stack HCI, consultez le billet de blog Association dans Azure Stack HCI.

La technologie SET est importante pour Azure Stack HCI, car il s’agit de la seule technologie d’association qui donne accès aux fonctionnalités suivantes :

  • Association d’adaptateurs RDMA (si nécessaire).
  • RDMA invité.
  • Dynamic VMMQ.
  • Autres fonctionnalités clés d’Azure Stack HCI (voir Association dans Azure Stack HCI).

SET nécessite l’utilisation d’adaptateurs symétriques (identiques). Les cartes réseau symétriques sont celles qui présentent les mêmes caractéristiques :

  • Marque (fournisseur)
  • Modèle (version)
  • Vitesse (débit)
  • configuration

Dans 22H2, Network ATC détecte et vous informe automatiquement si les adaptateurs que vous avez choisis sont asymétriques. Le moyen le plus simple d’identifier manuellement si les adaptateurs sont symétriques est que les vitesses et les descriptions d’interface correspondent exactement . Ils ne peuvent différer que par le chiffre indiqué dans la description. Utilisez la cmdlet Get-NetAdapterAdvancedProperty pour vérifier que la configuration signalée présente les mêmes valeurs de propriété.

Dans le tableau suivant figure un exemple de descriptions d’interface qui ne diffèrent que par le chiffre :

Nom Description de l’interface Vitesse de liaison
NIC1 Carte réseau 1 25 Gbits/s
NIC2 Carte réseau 2 25 Gbits/s
NIC3 Carte réseau 3 25 Gbits/s
NIC4 Carte réseau 4 25 Gbits/s

Remarque

SET prend uniquement en charge la configuration indépendante du commutateur à l’aide des algorithmes d’équilibrage de charge Port Hyper-V ou Dynamic. Pour bénéficier de performances optimales, nous vous recommandons d’utiliser Port Hyper-V sur toutes les cartes réseau qui opèrent à 10 Gbits/s ou plus. Network ATC effectue toutes les configurations requises pour SET.

Considérations relatives au trafic RDMA

Si vous implémentez DCB, vous devez vous assurer que la configuration PFC et ETS est correctement implémentée sur chacun des ports réseau, notamment les commutateurs réseau. Les standards DCB sont obligatoires pour le protocole RoCE et facultatifs pour le protocole iWARP.

Pour plus d’informations sur le déploiement de la fonctionnalité RDMA, téléchargez le document depuis le Référentiel GitHub SDN.

Les implémentations d’Azure Stack HCI basées sur le protocole RoCE nécessitent la configuration de trois classes de trafic PFC, notamment la classe de trafic par défaut, sur l’ensemble de la structure et des hôtes.

Classe de trafic de cluster

Cette classe de trafic garantit une bande passante réservée suffisante pour les pulsations de cluster :

  • Obligatoire : Oui
  • Compatible avec PFC : non
  • Priorité de trafic recommandée : priorité 7
  • Réservation de bande passante recommandée :
    • Réseaux RDMA de 10 GbE ou moins = 2 pour cent
    • Réseaux RDMA de 25 GbE ou moins = 1 pour cent

Classe de trafic RDMA

Cette classe de trafic garantit une bande passante réservée suffisante pour les communications RDMA sans perte en utilisant SMB Direct :

  • Obligatoire : Oui
  • Compatible avec PFC : oui
  • Priorité de trafic recommandée : priorité 3 ou 4
  • Réservation de bande passante recommandée : 50 pour cent

Classe de trafic par défaut

Cette classe de trafic couvre tous les autres types de trafic non définis dans le cluster ni dans les classes de trafic RDMA, notamment le trafic des machines virtuelles et le trafic de gestion :

  • Obligatoire : par défaut (aucune configuration nécessaire sur l’hôte)
  • Compatible avec PFC (contrôle de flux prioritaire) : non
  • Classe de trafic recommandée : par défaut (Priorité 0)
  • Réservation de bande passante recommandée : par défaut (aucune configuration hôte requise)

Modèles de trafic de stockage

En tant que protocole de stockage pour Azure Stack HCI, le protocole SMB offre de nombreux avantages, notamment SMB Multichannel. SMB Multichannel n’est pas discuté dans cette rubrique. Cependant, il est important de comprendre que le trafic est multiplexé sur chacune des liaisons possibles utilisées par SMB Multichannel.

Remarque

Nous vous recommandons d’utiliser plusieurs sous-réseaux et réseaux VLAN pour séparer le trafic de stockage dans Azure Stack HCI.

Prenons l’exemple d’un cluster à quatre nœuds. Chaque serveur possède deux ports de stockage (à gauche et à droite). Étant donné que chaque adaptateur se trouve sur le même sous-réseau et le même réseau VLAN, SMB Multichannel répartit les connexions entre toutes les liaisons disponibles. Par conséquent, le port situé à gauche sur le premier serveur (192.168.1.1) établit une connexion avec le port de gauche du deuxième serveur (192.168.1.2). Le port qui se trouve à droite sur le premier serveur (192.168.1.12) établit une connexion avec le port de droite du deuxième serveur. Des connexions similaires sont établies pour le troisième et le quatrième serveurs.

Cela crée toutefois des connexions inutiles et provoque une congestion au niveau de l’interlien (groupe d’agrégation de liens à plusieurs châssis ou MC-LAG) qui connecte les commutateurs ToR (marqués par des X). Consultez le diagramme suivant :

Diagramme montrant un cluster à quatre nœuds sur le même sous-réseau.

L’approche recommandée consiste à utiliser des sous-réseaux et des réseaux VLAN distincts pour chaque ensemble d’adaptateurs. Dans le diagramme suivant, les ports de droite utilisent désormais le sous-réseau 192.168.2.x /24 et VLAN2. Cela permet au trafic des ports de gauche de rester sur TOR1 et à celui des ports de droite de rester sur TOR2.

Diagramme montrant un cluster à quatre nœuds sur différents sous-réseaux.

Allocation de bande passante au trafic

Le tableau suivant donne des exemples d’allocations de bande passante de différents types de trafic, avec des vitesses d’adaptateur courantes, dans Azure Stack HCI. Notez qu’il s’agit d’un exemple d’une solution convergée dans laquelle tous les types de trafic (calcul, stockage et gestion) s’exécutent sur les mêmes adaptateurs physiques et sont associés à l’aide de la fonctionnalité SET.

Puisque ce cas d’usage est celui qui impose le plus de contraintes, il constitue une bonne ligne de base. Toutefois, en prenant en compte les permutations du nombre d’adaptateurs et des vitesses, il doit être considéré comme un exemple et non comme une configuration requise pour la prise en charge.

Cet exemple repose sur les hypothèses suivantes :

  • Il existe deux adaptateurs par équipe.

  • Le trafic SBL (Storage Bus Layer), le trafic de Volume partagé de cluster (CSV) et le trafic Hyper-V (Migration dynamique) :

    • utilisent les mêmes adaptateurs physiques ;
    • utilisent le protocole SMB.

  • SMB reçoit une allocation de bande passante de 50 % en utilisant DCB.

    • SBL/CSV est la trafic à la priorité la plus élevée et reçoit 70 % de la réservation de bande passante SMB.
    • La Migration dynamique (LM) est limitée en utilisant la cmdlet Set-SMBBandwidthLimit et reçoit 29 % de la bande passante restante.

      • Si la bande passante disponible pour la Migration dynamique est >= 5 Gbits/s et que les cartes réseau sont compatibles, optez pour la fonctionnalité RDMA. Utilisez pour cela la cmdlet suivante :

        Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

      • Si la bande passante disponible pour la Migration dynamique est < 5 Gbits/s, appliquez une compression pour réduire les durées d’indisponibilité. Utilisez pour cela la cmdlet suivante :

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

  • Si vous utilisez la fonctionnalité RDMA avec la trafic de Migration dynamique, assurez-vous que le trafic de Migration dynamique ne peut pas utiliser toute la bande passante allouée à la classe de trafic RDMA grâce à une limite de bande passante SMB. Soyez prudent, car cette cmdlet prend une entrée en octets par seconde (octets/s), tandis que les cartes réseau sont répertoriées en bits par seconde (bits/s). Utilisez la cmdlet suivante pour définir une limite de bande passante de 6 Gbit/s, par exemple :

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB

    Remarque

    750 Mbits/s dans cet exemple équivaut à 6 Gbit/s.

Voici le tableau d’allocation des exemples de bande passante :

Vitesse de la carte réseau Bande passante associée Réservation de bande passante SMB** % SBL/CSV Bande passante SBL/CSV % Migration dynamique Bande passante Migration dynamique maximale % pulsations Bande passante des pulsations
10 Gbits/s 20 Gbits/s 10 Gbits/s 70 % 7 Gbits/s * 200 Mbits/s
25 Gbits/s 50 Gbit/s 25 Gbits/s 70 % 17,5 Gbit/s 29 % 7,25 Gbit/s 1% 250 Mbit/s
40 Gbits/s 80 Gbit/s 40 Gbits/s 70 % 28 Gbit/s 29 % 11,6 Gbit/s 1% 400 Mbit/s
50 Gbit/s 100 Gbits/s 50 Gbit/s 70 % 35 Gbit/s 29 % 14,5 Gbit/s 1% 500 Mbits/s
100 Gbits/s 200 Gbits/s 100 Gbits/s 70 % 70 Gbit/s 29 % 29 Gbit/s 1% 1 Gbit/s
200 Gbits/s 400 Gbit/s 200 Gbits/s 70 % 140 Gbit/s 29 % 58 Gbit/s 1% 2 Gbit/s

Utilisez la compression plutôt que la fonctionnalité RDMA, car l’allocation de bande passante pour le trafic de Migration dynamique est < 5 Gbits/s.

** 50 % est un exemple de réservation de bande passante.

Clusters étendus

Les clusters étendus offrent une récupération d’urgence couvrant plusieurs centres de données. Dans sa forme la plus simple, un réseau en cluster Azure Stack HCI étendu se présente ainsi :

Diagramme montrant un cluster étendu.

Exigences des clusters étendus

Important

La fonctionnalité de cluster étendu est disponible uniquement dans Azure Stack HCI, version 22H2.

Les clusters étendus présentent les exigences et caractéristiques suivantes :

  • La fonctionnalité RDMA est limitée à un seul site et n’est pas prise en charge sur différents sites ou sous-réseaux.

  • Les serveurs du même site doivent se trouver dans le même rack et la même limite de couche 2.

  • La communication d’hôte entre les sites doit franchir une limite de couche 3 ; les topologies de couche 2 étendues ne sont pas prises en charge.

  • Disposez d’une bande passante suffisante pour exécuter les charges de travail sur l’autre site. En cas de basculement, l’autre site doit exécuter tout le trafic. Nous vous recommandons d’approvisionner les sites à 50 % de leur capacité réseau disponible. Ce n’est toutefois pas une exigence si vous pouvez tolérer un niveau de performance inférieur au cours d’un basculement.

  • Les adaptateurs utilisés pour la communication entre sites présentent les caractéristiques suivantes :

    • Ils peuvent être physiques ou virtuels (carte réseau virtuelle hôte). Si les adaptateurs sont virtuels, vous devez approvisionner une carte d’interface réseau virtuelle dans son propre sous-réseau et son propre réseau VLAN par carte d’interface réseau physique.

    • Ils doivent se trouver sur leur propre sous-réseau et leur propre réseau VLAN qui peuvent être acheminés entre les sites.

    • La fonctionnalité RDMA doit être désactivée en utilisant la cmdlet Disable-NetAdapterRDMA. Nous vous recommandons de demander explicitement au réplica de stockage d’utiliser des interfaces spécifiques en utilisant la cmdlet Set-SRNetworkConstraint.

    • Ils doivent satisfaire à toutes les exigences supplémentaires liées au réplica de stockage.

Étapes suivantes