Partager via

Configuration réseau physique requise pour Azure Local

  • Article

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

Cet article traite des considérations et exigences relatives au réseau physique (fabric) pour Azure Local, en particulier pour les commutateurs réseau.

Remarque

Les conditions requises pour les futures versions locales d’Azure peuvent changer.

Commutateurs réseau pour Azure Local

Microsoft teste Azure Local sur les normes et protocoles identifiés dans la section configuration requise pour le commutateur réseau ci-dessous. Bien que Microsoft ne certifiera pas les commutateurs réseau, nous travaillons avec les fournisseurs pour identifier les appareils qui prennent en charge les exigences locales d’Azure.

Important

Bien que d’autres commutateurs réseau utilisant des technologies et des protocoles non répertoriés ici fonctionnent, Microsoft ne peut pas garantir qu’ils fonctionnent avec Azure Local et peuvent être incapables d’aider à résoudre les problèmes qui se produisent.

Lors de l’achat de commutateurs réseau, contactez votre fournisseur de commutateurs et vérifiez que les appareils répondent aux exigences locales d’Azure pour vos types de rôles spécifiés. Les fournisseurs suivants (par ordre alphabétique) ont confirmé que leurs commutateurs prennent en charge les exigences locales Azure :

Cliquez sur un onglet Fournisseur pour afficher les commutateurs validés pour chacun des types de trafic local Azure. Ces classifications réseau sont disponibles ici.

Important

Nous mettons à jour ces listes, car nous sommes informés des modifications apportées par les fournisseurs de commutateurs réseau.

Si votre commutateur n’est pas indiqué, contactez le fournisseur pour vérifier que votre modèle et la version du système d’exploitation respectent les exigences formulées dans la section suivante.

Exigences concernant les commutateurs réseau

Cette section répertorie les normes du secteur qui sont obligatoires pour les rôles spécifiques des commutateurs réseau utilisés dans les déploiements locaux Azure. Ces normes permettent de garantir des communications fiables entre les nœuds dans les déploiements locaux Azure.

Remarque

Ethernet est requis par les cartes réseau utilisées pour le trafic de calcul, de stockage et de gestion. Pour plus d’informations, consultez Exigences liées aux réseaux d’hôtes.

Voici les standards et spécifications IEEE obligatoires :

Configuration requise pour les rôles 23H2

Exigence Gestion Stockage Calcul (Standard) Calcul (SDN)
RÉSEAUX LOCAUX virtuels ✓ ✓ ✓ ✓
Contrôle de flux de priorité ✓
Sélection améliorée de la transmission ✓
ID de réseau local virtuel du port LLDP ✓
Nom du VLAN LLDP ✓ ✓ ✓
Agrégation de liens LLDP ✓ ✓ ✓ ✓
LLDP ETS Configuration ✓
Recommandation ETS LLDP ✓
LLDP PFC Configuration ✓
Taille maximale du frame LLDP ✓ ✓ ✓ ✓
Unité de transmission maximale ✓
Protocole BGP ✓
Agent de relais DHCP ✓

Remarque

RdMA invité nécessite à la fois le calcul (standard) et le stockage.

Standard : IEEE 802.1Q

Les commutateurs Ethernet doivent respecter la spécification IEEE 802.1Q qui définit les réseaux locaux virtuels. Les réseaux locaux virtuels sont requis pour plusieurs aspects d’Azure Local et sont requis dans tous les scénarios.

Standard : IEEE 802.1Qbb

Les commutateurs Ethernet utilisés pour le trafic de stockage local Azure doivent se conformer à la spécification IEEE 802.1Qbb qui définit le contrôle de flux prioritaire (PFC). PFC est exigé en cas d’utilisation de Data Center Bridging (DCB). Comme DCB peut être utilisé dans les scénarios RDMA RoCE et iWARP, 802.1Qbb est exigé dans tous les scénarios. Un minimum de trois priorités de classe de service (CoS) sont nécessaires sans rétrograder les capacités du commutateur ni la vitesse des ports. Au moins l’une de ces classes de trafic doit assurer une communication sans perte.

Standard : IEEE 802.1Qaz

Les commutateurs Ethernet utilisés pour le trafic de stockage local Azure doivent se conformer à la spécification IEEE 802.1Qaz qui définit la sélection de transmission améliorée (ETS). ETS est obligatoire en cas d’utilisation de DCB. Comme DCB peut être utilisé dans les scénarios RDMA RoCE et iWARP, 802.1Qaz est exigé dans tous les scénarios.

Un minimum de trois priorités CoS sont nécessaires sans rétrograder les capacités du commutateur ou la vitesse du port. En outre, si votre appareil autorise la définition des taux de QoS entrants, nous vous recommandons de ne pas configurer les taux d’entrée ou de les configurer exactement sur la même valeur que les taux de sortie (ETS).

Remarque

L’infrastructure hyperconvergée présente une dépendance élevée vis-à-vis de la communication Est-Ouest de couche 2. La configuration ETS est donc nécessaire. Microsoft ne teste pas Azure Local avec le point de code de services différenciés (DSCP).

Standard : IEEE 802.1AB

Les commutateurs Ethernet doivent respecter la spécification IEEE 802.1AB qui définit le protocole LLDP (Link Layer Discovery Protocol). LLDP est requis pour Azure Local et permet de résoudre les problèmes liés aux configurations de mise en réseau physique.

La configuration des valeurs TLV (Type-Length-Values) LLDP doit être activée de manière dynamique. Les commutateurs ne doivent pas demander de configuration supplémentaire au-delà de l’activation d’une valeur TLV spécifique. Par exemple, l’activation du sous-type 3 de la spécification 802.1 doit être automatiquement annoncée à tous les réseaux locaux virtuels disponibles sur les ports de commutateur.

Exigences TLV personnalisées

LLDP permet aux organisations de définir et d’encoder leurs propres valeurs TLV personnalisés. Celles-ci sont appelées TLV spécifiques à l’organisation. Toutes les valeurs TLV spécifiques à l’organisation commencent par la valeur TLV LLDP de Type 127. Le tableau ci-dessous montre quels sous-types de sous-types TLV (TLV Type 127) spécifiques de l’organisation sont requis.

Organisation Sous-type TLV
IEEE 802.1 ID de port de réseau local virtuel (Sous-type = 1)
IEEE 802.1 Nom VLAN (Sous-type = 3)
Minimum de 10 réseaux locaux virtuels
IEEE 802.1 Agrégation de liens (Sous-type = 7)
IEEE 802.1 Configuration ETS (Sous-type = 9)
IEEE 802.1 Recommandation ETS (Sous-type = A)
IEEE 802.1 Configuration PFC (Sous-type = B)
IEEE 802.3 Taille de trame maximale (Sous-type = 4)

Unité de transmission maximale

L’unité de transmission maximale (MTU) est la plus grande taille de frame ou de paquet pouvant être transmise sur une liaison de données. Une plage de 1514-9174 est requise pour l’encapsulation SDN.

Protocole BGP

Les commutateurs Ethernet utilisés pour le trafic de calcul SDN local Azure doivent prendre en charge le protocole BGP (Border Gateway Protocol). BGP est un protocole de routage standard utilisé pour échanger des informations de routage et d’accessibilité entre deux réseaux ou plus. Les routes sont ajoutées automatiquement à la table de routage pour tous les sous-réseaux pour lesquels la propagation BGP est activée. Cela est nécessaire pour activer les charges de travail de locataire avec SDN et le peering dynamique. RFC 4271 : Border Gateway Protocol 4

Agent de relais DHCP

Les commutateurs Ethernet utilisés pour le trafic de gestion locale Azure doivent prendre en charge l’agent de relais DHCP. L’agent de relais DHCP est n’importe quel hôte TCP/IP utilisé pour transférer des demandes et des réponses entre le serveur DHCP et le client quand le serveur est présent sur un autre réseau. Il est requis pour les services de démarrage PXE. RFC 3046 : DHCPv4 ou RFC 6148 : DHCPv4

Trafic réseau et architecture

Cette section est principalement destinée aux administrateurs réseau.

Azure Local peut fonctionner dans différentes architectures de centre de données, notamment 2 niveaux (Colonne vertébrale) et 3 niveaux (Core-Aggregation-Access). Cette section fait référence à des concepts de la topologie Spin-Leaf couramment utilisée avec des charges de travail dans une infrastructure hyperconvergée, telle qu’Azure Local.

Modèles de réseaux

Le trafic réseau peut être classé selon sa direction. Les environnements de réseau de zone de stockage (SAN) traditionnels sont majoritairement de type Nord-Sud : le trafic circule d’un niveau de calcul vers un niveau de stockage en franchissant une limite de couche 3 (IP). L’infrastructure hyperconvergée est plus massivement de type Est-Ouest. Dans ce cas, une part importante du trafic reste au sein d’une limite de couche 2 (VLAN).

Important

Nous recommandons vivement que toutes les machines locales Azure d’un site se trouvent physiquement dans le même rack et connectées aux mêmes commutateurs toR (Top-of-Rack).

Remarque

La fonctionnalité de cluster étendu est disponible uniquement dans Azure Local version 22H2.

Trafic nord-sud pour Azure Local

Le trafic Nord-Sud présente les caractéristiques suivantes :

  • Le trafic va d’un commutateur ToR vers la branche centrale ou inversement.
  • Le trafic quitte le rack physique ou franchit une limite de la couche 3 (IP).
  • Inclut la gestion (PowerShell, Windows Admin Center), le calcul (machine virtuelle) et le trafic de cluster étendu entre sites.
  • Il utilise un commutateur Ethernet pour la connectivité au réseau physique.

Trafic Est-Ouest pour Azure Local

Le trafic Est-Ouest présente les caractéristiques suivantes :

  • Le trafic reste dans les commutateurs ToR et la limite de couche 2 (VLAN).
  • Inclut le trafic de stockage ou le trafic de migration dynamique entre les nœuds du même système et (si vous utilisez un cluster étendu) au sein du même site.
  • Il peut utiliser un commutateur Ethernet (commuté) ou une connexion directe (sans commutateur) (cf. les deux sections suivantes).

Avec commutateurs

Le trafic Nord-Sud impose d’utiliser des commutateurs. Outre l’utilisation d’un commutateur Ethernet qui prend en charge les protocoles requis pour Azure Local, l’aspect le plus important est le dimensionnement approprié de l’infrastructure réseau.

Il est impératif de comprendre la bande passante « non bloquante » de la structure que les commutateurs Ethernet peuvent prendre en charge et de réduire (ou de préférence supprimer) le surabonnement du réseau.

Le surabonnement et les points de congestion courants (par exemple le groupe d’agrégation de liens à plusieurs châssis utilisé pour la redondance de chemin) peuvent être éliminés par une utilisation appropriée des sous-réseaux et des réseaux VLAN. Consultez également Exigences liées aux réseaux d’hôtes.

Contactez votre fournisseur de réseau ou l’équipe de support réseau pour vérifier que vos commutateurs réseau sont bien dimensionnés pour la charge de travail que vous prévoyez d’exécuter.

Sans commutateurs

Azure Local prend en charge les connexions sans commutateur (directes) pour le trafic Est-Ouest pour toutes les tailles du système tant que chaque nœud du système dispose d’une connexion redondante à chaque nœud du système. C’est ce que l’on appelle une connexion à « maillage complet ».

Diagramme illustrant une connectivité sans commutateur à maillage complet

Paire d’interfaces Sous-réseau VLAN
Carte réseau virtuelle de l’hôte de gestion Spécifique au client Spécifique au client
SMB01 192.168.71.x/24 711
SMB02 192.168.72.x/24 712
SMB03 192.168.73.x/24 713

Remarque

Les avantages des déploiements sans commutateur diminuent avec les systèmes supérieurs à trois nœuds en raison du nombre de cartes réseau requises.

Avantages des connexions sans commutateur

  • Aucun achat de commutateur n’est nécessaire pour le trafic Est-Ouest. Il faut à l’inverse un commutateur pour le trafic Nord-Sud. Cela peut entraîner des dépenses d’investissement inférieures (CAPEX), mais dépend du nombre de nœuds dans le système.
  • Étant donné qu’il n’y a pas de commutateur, la configuration est limitée à l’hôte, ce qui peut réduire le nombre potentiel d’étapes de configuration nécessaires. Cette valeur diminue à mesure que la taille du système augmente.

Inconvénients des connexions sans commutateur

  • Une planification supplémentaire est nécessaire pour les schémas d’adressage IP et de sous-réseau.
  • Ces connexions n’offrent qu’un accès au stockage local. Ni le trafic de gestion, ni le trafic des machines virtuelles, ni le reste du trafic nécessitant un accès Nord-Sud ne peuvent utiliser ces adaptateurs.
  • À mesure que le nombre de nœuds du système augmente, le coût des cartes réseau peut dépasser le coût d’utilisation des commutateurs réseau.
  • Ne s’adapte pas bien au-delà des systèmes à trois nœuds. Un plus grand nombre de nœuds requiert un câblage et une configuration supplémentaires dont la complexité peut être supérieure à l'utilisation d'un commutateur.
  • L’expansion du système est complexe, nécessitant des modifications de configuration matérielle et logicielle.

Étapes suivantes