Partager via

Configuration réseau requise pour Azure Local

S’applique à : Azure Local 2311.2 et versions ultérieures

Cette rubrique décrit les considérations et exigences relatives à la mise en réseau de l’hôte pour Azure Local. Pour plus d’informations sur les architectures de centre de données et les connexions physiques entre les machines, consultez configuration réseau physique requise.

Pour plus d’informations sur la simplification de la mise en réseau hôte à l’aide de Network ATC, consultez Simplifier la mise en réseau de l’hôte avec Network ATC.

Types de trafic réseau

Le trafic réseau local Azure peut être classifié par son objectif prévu :

  • Trafic de gestion : Trafic vers ou depuis l’extérieur du système local. Par exemple, le trafic des répliques de stockage ou le trafic utilisé par l'administrateur pour la gestion du système, comme Remote Desktop, Windows Admin Center, Active Directory, etc.
  • Trafic de calcul : Trafic provenant ou destiné à une machine virtuelle.
  • Trafic de stockage : Trafic à l’aide de SMB (Server Message Block), par exemple des espaces de stockage direct ou une migration dynamique basée sur SMB. Ce trafic est de couche 2 et n’est pas routable.

Importante

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) avec lesquels elles sont compatibles. Lorsque vous passez en revue le catalogue Windows Server, la certification Windows Server 2022 indique désormais un ou plusieurs des rôles suivants. Avant d’acheter une machine pour Azure Local, vous devez disposer minimalement d’au moins un adaptateur qualifié pour la gestion, le calcul et le stockage, car les trois types de trafic sont requis sur Azure Local. Vous pouvez ensuite utiliser Network ATC pour configurer vos adaptateurs pour les types de trafic appropriés.

Pour découvrir plus d’informations sur cette qualification de carte réseau axée sur les rôles, consultez ce billet de blog Windows Server.

Importante

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 Norme 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 Management, Compute Premium et Storage Premium .

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

Exigences des pilotes

Les pilotes de boîte de réception ne sont pas pris en charge pour une utilisation avec Azure Local. 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 adaptateurs réseau

Les principales fonctionnalités de l'adaptateur réseau utilisées par Azure Local sont les suivantes :

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

VMMQ dynamique

Toutes les cartes réseau dotées de la qualification Compute (Premium) prennent en charge Dynamic VMMQ. Dynamic VMMQ nécessite l'utilisation de la fonctionnalité Switch Embedded Teaming.

Types de trafic applicables : calcul

Certifications requises : Informatique (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 « en rafale » de recevoir la quantité de trafic attendue.

Pour plus d’informations sur 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 Storage (Standard) ou Storage (Premium) prennent en charge le 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 Local prend en charge RDMA avec les implémentations des protocoles Internet Wide Area RDMA Protocol (iWARP) ou RDMA over Converged Ethernet (RoCE).

Importante

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 le support RDMA.

Remarque

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

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 vos commutateurs ToR (top-of-rack) ou n’êtes pas à l’aise avec leur gestion.
  • 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 des exigences du réseau DCB.

RDMA invité

Guest RDMA n'est pas pris en charge sur Azure Local.

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. SET est la seule technologie d’association prise en charge par Azure Local. 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)

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

Importante

Azure Local ne prend pas en charge le NIC teaming avec l'ancien Load Balancing/Failover (LBFO). Consultez le billet de blog Teaming dans Azure Local pour plus d’informations sur LBFO dans Azure Local.

SET est important pour Azure Local, car il s’agit de la seule technologie d’association qui permet :

  • Association d’adaptateurs RDMA (si nécessaire).
  • RDMA invité.
  • VMMQ dynamique.
  • Autres fonctionnalités clés d’Azure Local (consultez Teaming dans Azure Local).

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)
  • paramétrage

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
Carte réseau 1 Carte réseau 1 25 Gbits/s
Carte réseau 2 Carte réseau 2 25 Gbits/s
Carte réseau 3 Carte réseau 3 25 Gbits/s
Carte réseau 4 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 RDMA, téléchargez le document à partir du dépôt GitHub SDN.

Les implémentations locales Azure basées sur RoCE nécessitent la configuration de trois classes de trafic PFC, y compris la classe de trafic par défaut, dans l’infrastructure et tous les hôtes.

Classe de trafic système

Cette classe de trafic garantit que la bande passante réservée aux pulsations système est suffisante :

  • 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
  • PFC activé : 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 transporte tout autre trafic non défini dans les classes de trafic système ou RDMA, notamment le trafic de machine virtuelle et le trafic de gestion :

  • Obligatoire : par défaut (aucune configuration nécessaire sur l’hôte)
  • Contrôle de flux (PFC) activé : 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

SMB offre de nombreux avantages en tant que protocole de stockage pour Azure Local, 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 locaux virtuels pour séparer le trafic de stockage dans Azure Local.

Prenons l’exemple suivant d’un système à quatre nœuds. Chaque machine a 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 gauche sur la première machine (192.168.1.1)) établira une connexion au port de gauche sur la deuxième machine (192.168.1.2). Le port de droite sur la première machine (192.168.1.12) se connecte au port de droite sur la deuxième machine. Des connexions similaires sont établies pour les troisième et quatrième machines.

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 système à 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 système à quatre nœuds sur différents sous-réseaux.

Allocation de bande passante au trafic

Le tableau suivant montre des exemples d’allocations de bande passante de différents types de trafic, à l’aide de vitesses d’adaptateur courantes, dans Azure Local. Notez qu’il s’agit d’un exemple de solution convergée, où tous les types de trafic (calcul, stockage et gestion) s’exécutent sur les mêmes adaptateurs physiques et sont en équipe à l’aide de 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 le trafic avec la priorité la plus élevée et reçoit 70 % d'une 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 agrégée Réservation de bande passante SMB** % SBL/CSV Bande passante SBL/CSV Migration en direct % Bande passante maximale de migration en direct % pulsations Bande passante de fréquence cardiaque
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 cluster étendu d’Azure Local ressemble à ceci :

Diagramme montrant un cluster étendu.

Exigences des clusters étendus

Importante

La fonctionnalité de cluster étendu est disponible uniquement dans Azure Local 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 machines du même site doivent résider dans le même rack et appartenir à 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 :

    • Peut être physique ou virtuel (vNIC 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 d'exiger explicitement que Storage Replica utilise 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