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

  • Article
  • 15 minutes de lecture

S’applique à : Azure Stack HCI, versions 21H2 et 20H2

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 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.
  • Trafic de gestion : Trafic utilisé par l’administrateur pour la gestion du cluster, y compris Bureau à distance, Windows Admin Center, Active Directory, etc.

Sélectionner une carte réseau

Azure Stack HCI nécessite le choix d’une carte réseau qui a obtenu la certification de Windows Server Software-Defined Data Center (SDDC) avec la qualification supplémentaire (AQ) Standard ou Premium. Ce sont les adaptateurs qui prennent en charge les fonctionnalités les plus avancées de la plateforme et ont subi le plus de tests de la part de nos partenaires matériels. En général, ce niveau de contrôle entraîne une réduction des problèmes de qualité liés au matériel et au pilote. Ces adaptateurs répondent également aux exigences en matière de mise en réseau établies pour les espaces de stockage direct.

Pour identifier un adaptateur disposant d’une qualification Standard ou Premium, examinez l’entrée Windows Server Catalog correspondante et la version du système d’exploitation applicable. Voici un exemple de notation de Premium AQ :

Capture d’écran des options de Windows certifiées, avec une option Premium AQ mise en surbrillance.

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 disposant de la qualification Premium prennent en charge la technologie Dynamic VMMQ. Cette technologie impose d’utiliser la fonctionnalité Switch Embedded Teaming.

Types de trafic applicables : calcul

Certifications requises : 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 ;
  • possibilité pour les charges de travail « en rafale » de recevoir le volume de trafic attendu.

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 : Standard

Tous les adaptateurs avec une QA Standard ou Premium prennent en charge RDMA. RDMA est le choix de déploiement recommandé pour les charges de travail de stockage dans Azure Stack HCI et peut éventuellement être activé pour les charges de travail de stockage (via le protocole SMB) des machines virtuelles. Pour plus d’informations, consultez la section « RDMA invité » plus loin dans cet article.

Azure Stack HCI prend en charge RDMA à l’aide des implémentations de protocole iWARP (Internet Wide Area RDMA Protocol) ou RoCE (RDMA over Converged Ethernet).

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 présente les fournisseurs qui proposent des adaptateurs RDMA certifiés Premium (par ordre alphabétique). Toutefois, il existe des fabricants de matériel qui ne figurent pas dans cette liste et prennent également en charge la fonctionnalité RDMA. Pour vérifier la prise en charge RDMA, consultez Windows Server Catalog.

Remarque

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

Fournisseur de cartes réseau iWARP RoCE
Broadcom Non Oui
Chelsio Oui Non
Intel Oui Oui (certains modèles)
Marvell (QLogic/Cavium) Oui Oui
NVIDIA (Mellanox) Non Oui

Pour plus d’informations sur le déploiement de RDMA, téléchargez le document depuis 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 avez peu d’expérience réseau, voire aucune, ou n’êtes pas à l’aise avec la gestion des commutateurs réseau.
  • Vous ne contrôlez pas 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 : 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

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. Elle n’est pas dépendante du type de carte réseau utilisé.

Types de trafic applicables : calcul, stockage et gestion

Certifications requises : aucune (la fonctionnalité SET est intégrée au système d’exploitation)

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 les technologies d’association d’équilibrage de charge/basculement (LBFO) plus anciennes et le protocole de contrôle d’agrégation de liaison (LACP) couramment utilisées avec Windows Server. 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).

Notez que SET nécessite l’utilisation d’adaptateurs symétriques (identiques). L’association d’adaptateurs asymétriques n’est pas prise en charge. 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

Le moyen le plus simple d’identifier si les adaptateurs sont symétriques est de regarder si la vitesse est identique et si la description de l’interface correspond. 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
NIC2 Carte réseau 2 25 Gbits
NIC3 Carte réseau 3 25 Gbits
NIC4 Carte réseau 4 25 Gbits

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.

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 :

  • Requis : 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 nécessaire sur l’hôte)

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 50 Gbit/s 25 Gbits 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

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.

  • La réplication entre les sites (trafic nord/sud) peut utiliser les mêmes cartes réseau physiques que le stockage local (trafic est/ouest). Si vous utilisez les mêmes adaptateurs physiques, ils doivent être associés à SET. Les adaptateurs doivent aussi disposer de cartes réseau virtuelles supplémentaires provisionnées pour le trafic routable entre les sites.

  • 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.

Exemple de cluster étendu

L’exemple suivant montre une configuration de cluster étendu. Pour vous assurer qu’une carte réseau virtuelle spécifique est mappée à un adaptateur physique spécifique, utilisez la cmdlet Set-VMNetworkAdapterTeammapping.

Diagramme montrant un exemple de stockage de cluster étendu.

L’exemple suivant montre les détails de l’exemple de configuration du cluster étendu.

Remarque

Votre configuration exacte, notamment les noms de cartes d’interface réseau, les adresses IP et les réseaux VLAN, peut être différente de ce qui est indiqué. Il s’agit uniquement d’une configuration de référence pouvant être adaptée à votre environnement.

SiteA – Réplication locale, fonctionnalité RDMA activée, non routable entre sites

Nom du nœud Nom de la carte d’interface réseau virtuelle Carte d’interface réseau physique (mappée) VLAN IP et sous-réseau Étendue du trafic
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Site local uniquement
NodeA2 vSMB01 pNIC01 711 192.168.1.2/24 Site local uniquement
NodeA1 vSMB02 pNIC02 712 192.168.2.1/24 Site local uniquement
NodeA2 vSMB02 pNIC02 712 192.168.2.2/24 Site local uniquement

SiteB – Réplication locale, fonctionnalité RDMA activée, non routable entre sites

Nom du nœud Nom de la carte d’interface réseau virtuelle Carte d’interface réseau physique (mappée) VLAN IP et sous-réseau Étendue du trafic
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Site local uniquement
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 Site local uniquement
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 Site local uniquement
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 Site local uniquement

SiteA – Réplication étendue, fonctionnalité RDMA désactivée, routable entre sites

Nom du nœud Nom de la carte d’interface réseau virtuelle Carte d’interface réseau physique (mappée) IP et sous-réseau Étendue du trafic
NodeA1 Stretch1 pNIC01 173.0.0.1/8 Routable entre sites
NodeA2 Stretch1 pNIC01 173.0.0.2/8 Routable entre sites
NodeA1 Stretch2 pNIC02 174.0.0.1/8 Routable entre sites
NodeA2 Stretch2 pNIC02 174.0.0.2/8 Routable entre sites

SiteB : réplication étendue, RDMA désactivé, routable entre les sites

Nom du nœud Nom de la carte d’interface réseau virtuelle Carte d’interface réseau physique (mappée) IP et sous-réseau Étendue du trafic
NodeB1 Stretch1 pNIC01 175.0.0.1/8 Routable entre sites
NodeB2 Stretch1 pNIC01 175.0.0.2/8 Routable entre sites
NodeB1 Stretch2 pNIC02 176.0.0.1/8 Routable entre sites
NodeB2 Stretch2 pNIC02 176.0.0.2/8 Routable entre sites

Étapes suivantes