Configuration réseau physique requise pour Azure Local
Article
S’applique à : Azure Local, versions 23H2 et 22H2
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.
Broadcom Advanced Enterprise SONiC OS 4.2.1 ou version ultérieure
✓
✓
✓
✓
Remarque
RdMA invité nécessite à la fois le calcul (standard) et le stockage.
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 :
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
Configuration requise pour les rôles 22H2
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
Nouvelle condition requise dans 22H2
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
Nouvelle condition requise dans 22H2
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
Nouvelle condition requise dans 22H2
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.
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 ».
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.