Passez en revue le modèle de référence réseau de déploiement à trois nœuds sans commutateur, double TOR, de déploiement de liaison unique pour Azure Local
> 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 le modèle de référence réseau à liaison unique de maillage complet 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 réseau incluent les laboratoires, les usines, les magasins de détail, les secteurs publics et le gouvernement.
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 L3 (Software Defined Network) 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 la qualité de service (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 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.
- Deux cartes réseau RDMA sur chaque nœud dans une configuration de liaison unique de maillage complet pour le trafic Est-Ouest pour le stockage.
Remarque
Pour cette configuration, il n’existe aucune connexion réseau redondante entre les nœuds.
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 | Deux 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 trois 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 d’une configuration sans commutateur à trois nœuds, 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. Les considérations suivantes s’appliquent à chaque configuration :
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 les types de trafic Gestion et 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.
Trois 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 1 : 10.0.1.0/24 –
Pour plus d’informations, consultez Déployer la mise en réseau de l’hôte avec Network ATC.
Exemple de configuration réseau de l’intention de stockage du modèle ARM
Vous pouvez utiliser le modèle ARM pour le stockage à 3 nœuds sans commutateur, double TOR et liaison unique.
Voici un extrait de code du modèle :
"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.2.1",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork2",
"networkAdapterName": "SMB2",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.2.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.3.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.3.2",
"subnetMask": "255.255.255.0"
}
]
}
]
},