Partager via

Exigences liées aux réseaux physiques pour Azure Stack HCI

  • Article

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

Cet article décrit les considérations et exigences relatives aux réseaux physiques (structure) pour Azure Stack HCI, en particulier pour les commutateurs réseau.

Remarque

Les exigences sont susceptibles de changer dans les versions à venir d’Azure Stack HCI.

Commutateurs réseau pour Azure Stack HCI

Microsoft teste Azure Stack HCI par rapport aux normes et aux protocoles identifiés dans la section Exigences liées aux commutateurs réseau ci-dessous. Bien que Microsoft ne certifie pas les commutateurs réseau, nous travaillons avec les fournisseurs pour identifier les appareils qui prennent en charge les exigences Azure Stack HCI.

Important

Il est possible que d’autres commutateurs réseau utilisant des technologies et des protocoles non répertoriés ici fonctionnent. Microsoft ne peut néanmoins pas garantir qu’ils seront compatibles avec Azure Stack HCI et ne pourra peut-être pas 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 d’Azure Stack HCI pour vos types de rôles spécifiés. Les fournisseurs suivants (classés par ordre alphabétique) ont confirmé que leurs commutateurs respectent ces exigences :

Cliquez sur l’onglet Fournisseur pour afficher les commutateurs validés pour chacun des types de trafic Azure Stack HCI. 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 Azure Stack HCI. Ces standards permettent de garantir la fiabilité des communications entre les nœuds dans les déploiements de clusters Azure Stack HCI.

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. Ces deniers sont nécessaires pour plusieurs aspects d’Azure Stack HCI et sont exigés dans tous les scénarios.

Standard : IEEE 802.1Qbb

Les commutateurs Ethernet utilisés pour le trafic de stockage Azure Stack HCI doivent être conformes à 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 Azure Stack HCI doivent être conformes à 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 Stack HCI avec la valeur DSCP (Differentiated Services Code Point).

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 nécessaire à Azure Stack HCI et permet de résoudre les problèmes liés aux configurations des réseaux physiques.

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 Azure Stack HCI 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 Azure Stack HCI 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 Stack HCI peut fonctionner dans différentes architectures de centres de données, notamment à deux niveaux (Spine-Leaf) et à trois niveaux (Core-Aggregation-Access). Cette section fait davantage référence aux concepts de la topologie Spine-Leaf, couramment utilisée avec les charges de travail dans une infrastructure hyperconvergée comme Azure Stack HCI.

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

Il est vivement recommandé que tous les nœuds de cluster d’un site se trouvent physiquement dans le même rack et soit connectés aux mêmes commutateurs ToR.

Remarque

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

Trafic Nord-Sud pour Azure Stack HCI

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

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 cluster 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 le recours à un commutateur Ethernet compatible avec les protocoles requis pour Azure Stack HCI, l’aspect le plus important est le bon dimensionnement 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 Stack HCI prend en charge les connexions sans commutateur (directes) pour le trafic Est-Ouest avec toutes les tailles de cluster, à condition que chacun des nœuds du cluster dispose d’une connexion redondante à tous les nœuds. 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 clusters de plus de 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 une réduction des dépenses d’investissement, en fonction toutefois du nombre de nœuds du cluster.
  • É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 cluster 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.
  • Plus le nombre de nœuds du cluster augmente, plus le coût des cartes réseau risque de dépasser le coût lié au recours à des commutateurs réseau.
  • Ceux-ci ne présentent pas une scalabilité satisfaisante au-delà de clusters à 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 cluster est complexe, nécessitant des modifications de configuration matérielle et logicielle.

Étapes suivantes