Partager via

Configuration réseau requise pour Azure Local

  • Article

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

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 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 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 de réplica de stockage ou le trafic utilisé par l’administrateur pour la gestion du système, comme le 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 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 plus d’informations sur cette qualification de carte réseau basée sur les rôles, consultez ce billet de blog Windows Server.

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 Storage Standard
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 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 cartes réseau

Les principales fonctionnalités de carte 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)

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 Local 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 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 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. 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 avec le trafic de calcul, de stockage et de gestion.

Important

Azure Local ne prend pas en charge l’association de cartes réseau avec l’ancien équilibrage de charge/basculement (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é.
  • Dynamic VMMQ.
  • 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)
  • 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 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 qu’il existe suffisamment de bande passante réservée pour les pulsations système :

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

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 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 cluster étendu d’Azure Local ressemble à ceci :

Diagramme montrant un cluster étendu.

Exigences des clusters étendus

Important

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