Passez en revue le modèle de référence réseau de déploiement à trois nœuds sans commutateur, double TOR et double liaison pour Azure Local

Article
11/23/2024

> S’applique à : Azure Local, version 23H2 et ultérieure

Dans cet article, découvrez le commutateur de stockage à trois nœuds avec deux commutateurs TOR L3 et deux modèles de référence réseau de liens de maillage complets que vous pouvez utiliser pour déployer votre solution Locale Azure.

Remarque

Les modèles de référence réseau sans commutateur à 3 nœuds décrits dans cet article ont été testés et validés par Microsoft. Pour plus d’informations sur les modèles réseau sans commutateur à deux nœuds, consultez les modèles de déploiement de réseau local Azure.

Scénarios

Les scénarios de ce modèle réseau incluent les laboratoires, les usines, les succursales et les centres de données.

Envisagez d’implémenter ce modèle lorsque vous recherchez une solution économique qui a une tolérance de panne sur tous les composants réseau. Les services SDN L3 sont entièrement pris en charge sur ce modèle. Les services de routage tels que le protocole BGP (Border Gateway Protocol) peuvent être configurés directement sur les commutateurs TOR s’ils prennent en charge les services L3. Les fonctionnalités de sécurité réseau telles que la micro segmentation ou qoS ne nécessitent pas de configuration supplémentaire de l’appareil de pare-feu, car elles sont implémentées au niveau de la couche de carte réseau virtuelle.

Composants de connectivité physique

Comme illustré dans le diagramme ci-dessus, ce modèle comporte les composants réseau physiques suivants :

Pour la communication northbound et southbound, l’instance Azure Local nécessite deux commutateurs TOR dans la configuration du groupe d’agrégation de liaison multi-châssis (MLAG).
Deux cartes réseau utilisant un commutateur virtuel SET pour gérer la gestion et le trafic de calcul, connectées aux commutateurs TOR. Chaque carte réseau est connectée à un autre TOR.
Quatre cartes réseau RDMA sur chaque nœud dans une configuration de double liaison de maillage complet pour le trafic Est-Ouest pour le stockage. Chaque nœud du système dispose d’une connexion redondante avec deux chemins d’accès à l’autre nœud du système.

Réseaux	Gestion et calcul	Stockage
Vitesse de liaison	Au moins 1 Gbit/s. 10 GBits/s recommandés	Au moins 10 Gbits/s
Type d'interface	RJ45, SFP+ ou SFP28	SFP+ ou SFP28
Ports et agrégation	Deux ports en équipe	Quatre ports autonomes

Logical networks

Comme illustré dans le diagramme ci-dessous, ce modèle comporte les composants réseau logiques suivants :

Réseau local virtuel d’interconnexion de nœuds pour le trafic SMB (Stockage et migration dynamique)

Le trafic basé sur l’intention de stockage se compose de six sous-réseaux individuels prenant en charge le trafic RDMA. Chaque interface est dédiée à un réseau d’interconnexion de nœud distinct. Ce trafic est destiné uniquement à se déplacer entre les trois nœuds. Le trafic de stockage sur ces sous-réseaux est isolé sans connectivité à d’autres ressources.

Chaque paire d’adaptateurs de stockage entre les nœuds fonctionne dans différents sous-réseaux IP. Pour activer une configuration sans commutateur, chaque nœud connecté prend en charge le même sous-réseau correspondant de son voisin.

Lors du déploiement de trois nœuds dans une configuration sans commutateur, Network ATC a les exigences suivantes :

Prend uniquement en charge un seul réseau local virtuel pour tous les sous-réseaux IP utilisés pour la connectivité de stockage.
StorageAutoIP le paramètre doit être défini sur false, Switchless le paramètre doit être défini sur true et vous êtes responsable de spécifier les adresses IP sur le modèle ARM utilisé pour déployer l’instance locale Azure à partir d’Azure.
Pour les déploiements cloud Azure Local, version 23H2 :
- Le scale-out des systèmes sans commutateur de stockage n’est pas pris en charge.
- Il est uniquement possible de déployer ce scénario à trois nœuds à l’aide de modèles ARM.

Pour plus d’informations, consultez Déployer via un modèle de déploiement Azure Resource Manager.

Réseau local virtuel de gestion

Tous les hôtes de calcul physiques doivent accéder au réseau logique de gestion. À des fins de planification d’adresses IP, chaque hôte doit avoir au moins une adresse IP affectée à partir du réseau logique de gestion.

Un serveur DHCP peut attribuer automatiquement des adresses IP pour le réseau de gestion, ou vous pouvez attribuer manuellement des adresses IP statiques. Lorsque DHCP est la méthode d’attribution IP préférée, les réservations DHCP sans expiration sont recommandées.

Pour plus d’informations, consultez considérations relatives au réseau DHCP pour le déploiement cloud.

Le réseau de gestion prend en charge deux configurations de réseau local virtuel différentes pour le trafic : native et étiquetée :

Le réseau local virtuel natif pour le réseau de gestion ne vous oblige pas à fournir un ID de réseau local virtuel.
Le réseau local virtuel étiqueté pour le réseau de gestion nécessite une configuration d’ID de réseau local virtuel sur les cartes réseau physiques ou la carte réseau virtuelle de gestion avant d’inscrire les nœuds dans Azure Arc.
Les ports de commutateur physique doivent être configurés correctement pour accepter l’ID de réseau local virtuel sur les adaptateurs de gestion.
Si l’intention inclut des types de trafic de gestion et de calcul, les ports de commutateur physique doivent être configurés en mode jonction pour accepter tous les réseaux locaux virtuels requis pour la gestion et les charges de travail de calcul.

Le réseau de gestion prend en charge le trafic utilisé par l’administrateur pour la gestion du système, notamment le Bureau à distance, Windows Admin Center et Active Directory.

Pour plus d’informations, consultez Considérations relatives au réseau local virtuel de gestion.

Réseaux locaux virtuels de calcul

Dans certains scénarios, vous n’avez pas besoin d’utiliser des Réseau virtuel SDN avec l’encapsulation VXLAN. Au lieu de cela, vous pouvez utiliser des réseaux locaux virtuels traditionnels pour isoler leurs charges de travail de locataire. Ces réseaux locaux virtuels doivent être configurés sur le port des commutateurs TOR en mode jonction. Lors de la connexion de nouvelles machines virtuelles à ces réseaux locaux virtuels, la balise VLAN correspondante est définie sur la carte réseau virtuelle.

Réseau d’adresse du fournisseur HNV (PA)

Le réseau HNV (Network Virtualization Provider Address) Hyper-V sert de réseau physique sous-jacent pour le trafic client Est-Ouest (interne), nord-sud (interne interne) et échange d’informations de peering BGP avec le réseau physique. Ce réseau n’est nécessaire que lorsqu’il est nécessaire de déployer des réseaux virtuels à l’aide de l’encapsulation VXLAN pour une couche supplémentaire d’isolation et de multilocataire réseau.

Pour plus d’informations, consultez Planifier une infrastructure réseau définie par logiciel.

Intentions d’ATC réseau

Pour les modèles sans commutateur de stockage à trois nœuds, deux intentions ATC réseau sont créées. La première intention est de gérer et de calculer le trafic réseau, et la deuxième intention concerne le trafic de stockage.

Intention de gestion et de calcul

Type d’intention : Gestion et calcul
In mode tente : Mode cluster
Teaming : Oui. Équipe pNIC01 et pNIC02.
Réseau local virtuel de gestion par défaut : le réseau local virtuel configuré pour les adaptateurs de gestion n’est pas modifié.
PA et calcul des réseaux locaux virtuels et des réseaux virtuels : le réseau ATC est transparent pour les cartes réseau virtuelles pa et les réseaux locaux virtuels de machines virtuelles de calcul ou de machines virtuelles virtuelles.

Intention de stockage

Type d’intention : Stockage
In mode tente : Mode cluster
Teaming : Non. Les cartes réseau RDMA utilisent SMB Multichannel pour fournir une résilience et une agrégation de bande passante.
Réseaux locaux virtuels par défaut : réseau local virtuel unique pour tous les sous-réseaux.
Adresse IP automatique du stockage : False. Ce modèle nécessite une configuration IP manuelle ou une définition d’adresse IP de modèle ARM.
Six sous-réseaux requis (définis par l’utilisateur) :
- Réseau de stockage 1 : 10.0.1.0/24 – Node1 -> Node2
- Réseau de stockage 2 : 10.0.2.0/24 – Node1 -> Node2
- Réseau de stockage 3 : 10.0.3.0/24 – Node2 -> Node3
- Réseau de stockage 4 : 10.0.4.0/24 – Node1 -> Node3
- Réseau de stockage 5 : 10.0.5.0/24 – Node1 -> Node3
- Réseau de stockage 6 : 10.0.6.0/24 – Node2 -> Node3

Pour plus d’informations, consultez Déployer la mise en réseau de l’hôte avec Network ATC.

Exemple de configuration des réseaux d’intentions de stockage ARM

Vous pouvez utiliser le modèle ARM pour le stockage à 3 nœuds sans commutateur, double TOR et double liaison.

"storageNetworkList": {
        "value": [
            {
                "name": "StorageNetwork1",
                "networkAdapterName": "SMB1",
                "vlanId": "711",
                "storageAdapterIPInfo": [
                    {
                        "physicalNode": "Node1",
                        "ipv4Address": "10.0.1.1",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node2",
                        "ipv4Address": "10.0.1.2",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node3",
                        "ipv4Address": "10.0.5.3",
                        "subnetMask": "255.255.255.0"
                  }
                ]
            },
            {
                "name": "StorageNetwork2",
                "networkAdapterName": "SMB2",
                "vlanId": "711",
                "storageAdapterIPInfo": [
                    {
                        "physicalNode": "Node1",
                        "ipv4Address": "10.0.2.1",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node2",
                        "ipv4Address": "10.0.2.2",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node3",
                        "ipv4Address": "10.0.4.3",
                        "subnetMask": "255.255.255.0"
                  }
                ]
            },
            {
              "name": "StorageNetwork3",
              "networkAdapterName": "SMB3",
              "vlanId": "711",
              "storageAdapterIPInfo": [
                  {
                      "physicalNode": "Node1",
                      "ipv4Address": "10.0.5.1",
                      "subnetMask": "255.255.255.0"
                  },
                  {
                      "physicalNode": "Node2",
                      "ipv4Address": "10.0.3.2",
                      "subnetMask": "255.255.255.0"
                  },
                  {
                      "physicalNode": "Node3",
                      "ipv4Address": "10.0.3.3",
                      "subnetMask": "255.255.255.0"
                }
              ]
          },
          {
            "name": "StorageNetwork4",
            "networkAdapterName": "SMB4",
            "vlanId": "711",
            "storageAdapterIPInfo": [
                {
                    "physicalNode": "Node1",
                    "ipv4Address": "10.0.4.2",
                    "subnetMask": "255.255.255.0"
                },
                {
                    "physicalNode": "Node2",
                    "ipv4Address": "10.0.6.1",
                    "subnetMask": "255.255.255.0"
                },
                {
                    "physicalNode": "Node3",
                    "ipv4Address": "10.0.6.3",
                    "subnetMask": "255.255.255.0"
              }
            ]
        }
        ]
      },

Partager via