Considérations relatives au réseau pour les déploiements cloud d’Azure Local

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

Cet article explique comment concevoir et planifier un réseau de système local Azure pour le déploiement cloud. Avant de continuer, prenez le temps de vous familiariser avec les différents modèles de mise en réseau locaux Azure et les configurations disponibles.

Infrastructure de conception réseau

Le diagramme suivant illustre les différentes décisions et étapes qui définissent l’infrastructure de conception réseau pour votre instance Azure Local : taille du cluster, connectivité de stockage de cluster, intentions de trafic réseau, connectivité de gestion et configuration de la carte réseau. Chaque décision de conception active ou autorise les options de conception disponibles dans les étapes suivantes :

Étape 1 : Déterminer la taille du cluster

Pour déterminer la taille de votre instance Azure Local, utilisez l’outil de dimensionnement Azure Local, qui vous permet de définir votre profil, comme le nombre de machines virtuelles, la taille des machines virtuelles et l’utilisation de la charge de travail des machines virtuelles comme Azure Virtual Desktop, SQL Server ou AKS.

Comme décrit dans l’article sur la configuration requise de l’ordinateur local Azure, le nombre maximal de machines prises en charge sur l’instance locale Azure est de 16. Une fois que vous avez terminé la planification de la capacité de votre charge de travail, vous devez avoir une bonne compréhension du nombre de nœuds d’ordinateur requis pour exécuter des charges de travail sur votre infrastructure.

• Si vos charges de travail nécessitent quatre nœuds ou plus : vous ne pouvez pas déployer ni utiliser une configuration sans commutateur pour le trafic réseau de stockage. Vous devez inclure un commutateur physique compatible avec l’accès à la mémoire directe à distance (RDMA) pour gérer le trafic de stockage. Pour plus d’informations sur l’architecture réseau d’instance locale Azure, consultez Vue d’ensemble des modèles de référence réseau.

• Si vos charges de travail nécessitent trois nœuds ou moins : vous pouvez choisir des configurations avec ou sans commutateur pour la connectivité de stockage.

• Si vous envisagez d’effectuer un scale-out et d'utiliser plus de trois nœuds ultérieurement : vous devez utiliser un commutateur physique pour le trafic réseau de stockage. Toute opération de scale-out pour les déploiements sans commutateur requiert une configuration manuelle de votre câblage réseau entre les nœuds que Microsoft ne valide pas activement dans le cadre de son cycle de développement logiciel pour Azure Local.

Voici un résumé des informations concernant la décision de taille du cluster :

Décision	Considération
Taille du cluster (nombre de nœuds par cluster)	La configuration sans commutateur avec les modèles de portail Azure ou Azure Resource Manager n’est disponible que pour les clusters à un, deux ou trois nœuds. Les clusters comptant quatre nœuds ou plus nécessitent un commutateur physique pour le trafic réseau de stockage.
Exigences en matière de scale-out	Si vous envisagez d’effectuer un scale-out de votre cluster avec l’orchestrateur, vous devez utiliser un commutateur physique pour le trafic réseau de stockage.

Étape 2 : Déterminer la connectivité de stockage du cluster

Comme décrit dans Exigences liées aux réseaux physiques, Azure Local prend en charge deux types de connectivité pour le trafic réseau de stockage :

• Utilisez un commutateur réseau physique pour gérer le trafic.
• Connectez directement les nœuds entre eux avec un réseau croisé ou des câbles fibre pour le trafic de stockage.

Les avantages et inconvénients de chaque option sont documentés dans l’article fourni ci-dessus.

Comme indiqué précédemment, vous n'avez le choix entre les deux options que lorsque votre cluster compte trois nœuds ou moins. Les clusters de quatre nœuds ou plus sont automatiquement déployés à l’aide d’un commutateur réseau pour le stockage.

Si les clusters comptent moins de trois nœuds, la décision de connectivité de stockage influence le nombre et le type d’intentions réseau que vous pouvez définir à l’étape suivante.

Par exemple, pour les configurations sans commutateur, vous devez définir deux intentions de trafic réseau. Le trafic de stockage pour les communications est-ouest utilisant des câbles croisés n’a pas de connectivité nord-sud. Il est complètement isolé du reste de votre infrastructure réseau. Autrement dit, vous devrez définir une deuxième intention de réseau pour la connectivité sortante de gestion et pour vos charges de travail de calcul.

Bien qu'il soit possible de définir chaque intention de réseau avec un seul port physique d'adaptateur de réseau, cela n'offre aucune tolérance de panne. C'est pourquoi nous vous recommandons toujours d’utiliser au moins deux ports réseau physiques pour chaque intention réseau. Si vous décidez d’utiliser un commutateur réseau pour le stockage, vous pouvez regrouper tout le trafic réseau, y compris le stockage, dans une seule intention de réseau, également appelé configuration réseau hyperconvergée ou entièrement convergée.

Voici un résumé des informations concernant la décision de connectivité de stockage de cluster :

Décision	Considération
Aucun commutateur pour le stockage	La configuration sans commutateur via le portail ou le déploiement de modèles Resource Manager est uniquement compatible avec les clusters à un, deux ou trois nœuds. Vous pouvez déployer des clusters sans commutateur de stockage à un ou deux nœuds à l’aide des modèles du portail Azure ou de Resource Manager. Les clusters sans commutateur de stockage à trois nœuds peuvent être déployés uniquement à l’aide de modèles Resource Manager. Les opérations de scale-out ne sont pas prises en charge avec les déploiements sans commutateur. Toute modification apportée au nombre de nœuds après le déploiement nécessite une configuration manuelle. Au moins 2 intentions réseau sont requises lors de l’utilisation de la configuration sans commutateur de stockage.
Commutateur réseau pour le stockage	Si vous envisagez d’effectuer un scale-out de votre cluster avec l’orchestrateur, vous devez utiliser un commutateur physique pour le trafic réseau de stockage. Vous pouvez utiliser cette architecture avec 1 à 16 nœuds. Bien que ce ne soit pas obligatoire, vous pouvez utiliser une seule intention pour tous vos types de trafic réseau (gestion, calcul et stockage)

Le diagramme suivant récapitule les options de connectivité de stockage disponibles pour différents déploiements :

Étape 3 : Déterminer les intentions de trafic réseau

Pour Azure Local, tous les déploiements s’appuient sur Network ATC pour la configuration du réseau hôte. Les intentions réseau sont automatiquement configurées lors du déploiement d’Azure Local via le portail Azure. Pour en savoir plus sur les intentions réseau et la manière de les résoudre, consultez Commandes ATC réseau courantes.

Cette section explique les conséquences de votre décision de conception en ce qui concerne les intentions de trafic réseau et comment elles influencent l’étape suivante du framework. Pour les déploiements cloud, vous pouvez choisir entre quatre options pour regrouper votre trafic réseau dans une ou plusieurs intentions. Les options disponibles dépendent du nombre de nœuds de votre cluster et du type de connectivité de stockage utilisé.

Les options d’intention réseau disponibles sont décrites dans les sections suivantes.

Intention réseau : regrouper tout le trafic

Network ATC configure une intention unique qui inclut la gestion, le calcul et le trafic réseau de stockage. Les adaptateurs réseau affectés à cette intention partagent la bande passante et le débit pour l'ensemble du trafic réseau.

• Cette option nécessite un commutateur physique pour le trafic de stockage. S'il vous faut une architecture sans commutateur, vous ne pouvez pas utiliser ce type d’intention. Le portail Azure filtre automatiquement cette option si vous sélectionnez une configuration sans commutateur pour la connectivité de stockage.

• Nous vous recommandons d'utiliser au moins deux ports de carte réseau pour garantir une haute disponibilité.

• Au moins 10 Go/s sont nécessaires pour prendre en charge le trafic RDMA pour le stockage.

Intention du réseau : gestion de groupe et trafic de calcul

L'ATC réseau configure deux intentions. La première intention inclut la gestion et le trafic réseau de calcul. La deuxième intention inclut uniquement le trafic réseau de stockage. Chaque intention doit avoir un ensemble différent de ports d'adaptateur réseau.

Vous pouvez utiliser cette option pour la connectivité de stockage commutée et sans commutateur, si :

• Deux ports de carte réseau au moins sont disponibles pour chaque intention afin de garantir une haute disponibilité.

• Vous utilisez un commutateur réseau pour RDMA si vous utilisez le commutateur réseau pour le stockage.

• Au moins 10 Go/s sont nécessaires pour prendre en charge le trafic RDMA pour le stockage.

Intention du réseau : calcul de groupe et trafic de stockage

L'ATC réseau configure deux intentions. La première intention inclut le calcul et le trafic réseau de stockage. La deuxième intention inclut uniquement la gestion du réseau de stockage. Chaque intention doit utiliser un ensemble différent de ports d'adaptateur réseau.

• Cette option nécessite un commutateur physique pour le trafic de stockage, car les mêmes ports sont partagés avec le trafic de calcul, ce qui requiert une communication nord-sud. S'il vous faut une configuration sans commutateur, vous ne pouvez pas utiliser ce type d’intention. Le portail Azure filtre automatiquement cette option si vous sélectionnez une configuration sans commutateur pour la connectivité de stockage.

• Cette option nécessite un commutateur physique pour RDMA.

• Nous vous recommandons d'utiliser au moins deux ports de carte réseau pour garantir une haute disponibilité.

• Au moins 10 Go/s sont recommandés pour le calcul et l’intention de stockage de prendre en charge le trafic RDMA.

• Même lorsque l’intention de gestion est déclarée sans intention de calcul, Network ATC crée un commutateur virtuel Switch Embedded Teaming (SET) pour fournir une haute disponibilité au réseau de gestion.

Intention réseau : configuration personnalisée

Définissez jusqu’à trois intentions avec votre propre configuration tant qu’au moins l’une des intentions inclut le trafic de gestion. Nous vous recommandons d’utiliser cette option lorsque vous avez besoin d’une deuxième intention de calcul. Les scénarios de cette deuxième exigence d’intention de calcul incluent le trafic de stockage distant, le trafic de sauvegarde des machines virtuelles ou une intention de calcul distincte pour les différents types de charges de travail.

• Utilisez cette option pour la connectivité de stockage avec ou sans commutateur si l’intention de stockage est différente des autres intentions.

• Utilisez cette option quand une autre intention de calcul est nécessaire ou lorsque vous souhaitez séparer complètement les différents types de trafic sur différentes cartes réseau.

• Utilisez au moins deux ports de carte réseau pour chaque intention afin de garantir une haute disponibilité.

• Au moins 10 Go/s sont recommandés pour le calcul et l’intention de stockage de prendre en charge le trafic RDMA.

Le diagramme suivant récapitule les options d’intention réseau disponibles pour différents déploiements :

Étape 4 : Déterminer la connectivité réseau de gestion et de stockage

Dans cette étape, vous définissez l’espace d’adressage du sous-réseau d’infrastructure, la manière dont ces adresses sont affectées à votre cluster et s’il existe un proxy ou un ID de VLAN requis pour les nœuds pour la connectivité sortante à Internet et d’autres services intranet tels que DNS (Domain Name System) ou Active Directory Services.

Les composants de sous-réseau d’infrastructure suivants doivent être planifiés et définis avant le début du déploiement afin de pouvoir anticiper les exigences de routage, de pare-feu ou de sous-réseau.

Pilotes de la carte réseau

Une fois que vous avez installé le système d’exploitation et avant de configurer la mise en réseau sur vos nœuds, vous devez vérifier que vos cartes réseau disposent du pilote le plus récent fourni par votre fournisseur d’interface réseau ou OEM. Les fonctionnalités importantes des cartes réseau ne s'afficheront peut-être pas lors de l’utilisation des pilotes Microsoft par défaut.

Pool d’adresses IP de gestion

Lors du déploiement initial de votre instance Azure Local, vous devez définir une plage d’adresses IP consécutives pour les services d’infrastructure déployés par défaut.

Afin de vérifier que la plage dispose de suffisamment d’adresses IP pour les services d’infrastructure actuels et futurs, vous devez définir une plage d’au moins six adresses IP disponibles consécutives. Ces adresses sont utilisées pour l’adresse IP du cluster ainsi que la machine virtuelle Azure Resource Bridge et ses composants.

Si vous prévoyez d’exécuter d’autres services dans le réseau d’infrastructure, nous vous recommandons d’affecter une mémoire tampon supplémentaire d’adresses IP d’infrastructure au pool. Il est possible d’ajouter d’autres pools IP à l’aide de PowerShell une fois le réseau d’infrastructure déployé si la taille du pool que vous aviez planifié au départ est épuisée.

Les conditions suivantes doivent être remplies lors de la définition de votre pool IP pour le sous-réseau d’infrastructure pendant le déploiement :

#	Condition
1	La plage d’adresses IP doit utiliser des adresses IP consécutives, et toutes les adresses IP doivent être disponibles dans cette plage. La plage ne peut pas être modifiée après le déploiement.
2	La plage d’adresses IP ne doit pas inclure les adresses IP de gestion des nœuds de cluster. Toutefois, elle doit se trouver sur le même sous-réseau que vos nœuds.
3	La passerelle par défaut définie pour le pool d’adresses IP de gestion doit fournir une connectivité sortante à Internet.
4	Les serveurs DNS doivent garantir la résolution de noms avec Active Directory et Internet.
5	Les adresses IP de gestion nécessitent un accès Internet sortant.

ID du VLAN de gestion

Nous recommandons que le sous-réseau de gestion de votre instance Azure Local utilise le réseau local virtuel par défaut. Dans la plupart des cas, celui-ci est déclaré en tant qu’ID de réseau local virtuel 0. Cependant, si votre réseau exige un VLAN de gestion spécifique pour votre réseau d’infrastructure, il doit être configuré sur vos cartes réseau physiques que vous envisagez d’utiliser pour le trafic de gestion.

Si vous envisagez d’utiliser deux cartes réseau physiques pour la gestion, vous devez configurer le VLAN sur les deux cartes. Cette opération doit être effectuée lors de la configuration de démarrage de vos machines, et avant qu’elles ne soient inscrites auprès d’Azure Arc. Cela vous permet de vérifiez que vous enregistrez correctement les nœuds à l’aide de ce VLAN.

Pour définir l’ID de VLAN sur les cartes réseau physiques, utilisez la commande PowerShell suivante :

Cet exemple configure l'ID VLAN 44 sur la carte réseau physique NIC1.

Set-NetAdapter -Name "NIC1" -VlanID 44

Une fois que l’ID de réseau local virtuel est défini et que les adresses IP de vos nœuds sont configurées sur les cartes réseau physiques, l’orchestrateur lit cette valeur d’ID de VLAN à partir de la carte réseau physique utilisée pour la gestion et la stocke. Elle pourra ainsi être utilisée pour la machine virtuelle Azure Resource Bridge ou toute autre machine virtuelle d’infrastructure requise pendant le déploiement. Il est impossible de définir l’ID de VLAN de gestion pendant le déploiement cloud à partir de Portail Azure. En effet, cela risque de rompre la connectivité entre les nœuds et Azure si les réseaux locaux virtuels de commutateur physique ne sont pas routés correctement.

Management VLAN ID avec un commutateur virtuel

Dans certains cas de figure, vous devez créer un commutateur virtuel avant de démarrer le déploiement.

Note

Avant de créer un commutateur virtuel, veillez à activer le rôle Hype-V. Pour plus d’informations, consultez Installer le rôle Windows requis.

Si vous devez utiliser une configuration de commutateur virtuel et vous un ID de VLAN spécifique, procédez comme suit :

1. Créer un commutateur virtuel avec une convention de nommage recommandée

Les déploiements locaux Azure s’appuient sur Network ATC pour créer et configurer les commutateurs et les cartes réseau virtuels pour la gestion, le calcul et les intentions de stockage. Par défaut, lorsque Network ATC crée le commutateur virtuel pour les intents, il utilise un nom spécifique pour le commutateur virtuel.

Nous vous recommandons de nommer vos commutateurs virtuels selon la même convention de dénomination. Le nom recommandé pour les commutateurs virtuels est le suivant :

« ConvergedSwitch($IntentName) », où $IntentName doit correspondre au nom de l’intention saisie dans le portail lors du déploiement. Cette chaîne doit également correspondre au nom de la carte réseau virtuelle utilisée pour la gestion, comme décrit à l’étape suivante.

L’exemple suivant illustre comment créer le commutateur virtuel avec PowerShell à l’aide de la convention d’affectation de noms recommandée avec $IntentName. La liste des noms de cartes réseau est une liste des cartes réseau physiques que vous envisagez d’utiliser pour la gestion et le trafic réseau de calcul :

$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

Note

Une fois qu’une instance locale Azure est déployée, la modification du nom de l’intention de gestion ou du nom du commutateur virtuel n’est pas prise en charge. Vous devez utiliser le même nom d’intention et le même nom de commutateur virtuel si vous devez mettre à jour ou recréer l’intention après le déploiement.

2. Configurer la carte réseau virtuelle de gestion avec la convention de nommage ATC réseau requise pour tous les nœuds

Une fois que le commutateur virtuel et la carte réseau virtuelle de gestion associée sont créés, vérifiez que le nom de la carte réseau est conforme aux conventions de nommage ATC réseau.

Plus précisément, le nom de la carte réseau virtuelle utilisée pour le trafic de gestion doit utiliser les conventions suivantes :

• Nom de l'adaptateur réseau et l'adaptateur réseau virtuel doit utiliser vManagement($intentname)
• Ce nom est sensible à la casse.
• $Intentname peut être n’importe quelle chaîne, mais doit être le même nom que celui utilisé pour le commutateur virtuel. Veillez à utiliser cette même chaîne dans Portail Azure lorsque vous définissez le nom de l’intention Mgmt.

Pour mettre à jour le nom de l'adaptateur réseau virtuel de gestion, utilisez les commandes suivantes :

$IntentName = "MgmtCompute"

#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

#Rename NetAdapter because during creation, Hyper-V adds the string "vEthernet" to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

3. Configurer l’ID de VLAN pour gérer la carte réseau virtuelle pour tous les nœuds

Une fois le commutateur virtuel et la carte réseau virtuelle de gestion créés, vous pouvez spécifier l’ID de VLAN requis pour cette carte. Bien qu’il existe différentes options pour affecter un ID de réseau local virtuel à une carte réseau virtuelle, la seule option prise en charge consiste à utiliser la commande Set-VMNetworkAdapterIsolation.

Une fois l’ID VLAN requis configuré, vous pouvez affecter l’adresse IP et les passerelles à la carte réseau virtuelle de gestion pour vérifier qu’elle dispose d’une connectivité avec d’autres nœuds, le DNS, Active Directory et Internet.

L’exemple suivant illustre comment configurer la carte réseau virtuelle de gestion pour utiliser l’ID de VLAN 8 au lieu de la valeur par défaut :

Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"

4. Référencement des adaptateurs réseau physiques pour l'intention de gestion pendant le déploiement.

Bien que l'adaptateur réseau virtuel nouvellement créé s'affiche comme étant disponible lors du déploiement via le portail Azure, il est important de se rappeler que la configuration du réseau est basée sur l'ATC réseau. Cela signifie que lors de la configuration de l'intention de gestion, ou de l'intention de gestion et de calcul, nous devons toujours sélectionner les adaptateurs réseau physiques utilisés pour cette intention.

Note

Ne sélectionnez pas l'adaptateur réseau virtuel pour l'intention réseau.

La même logique s’applique aux modèles Azure Resource Manager. Vous devez spécifier les adaptateurs réseau physiques que vous souhaitez utiliser pour les intentions réseau et jamais les adaptateurs réseau virtuels.

Voici un résumé des informations concernant l’ID de VLAN :

#	Considérations
1	L’ID de VLAN doit être spécifié sur la carte réseau physique pour la gestion avant d’inscrire les machines auprès d’Azure Arc.
2	Suivez la procédure spécifique lorsqu’un commutateur virtuel est requis avant d’inscrire les machines dans Azure Arc.
3	L’ID de VLAN de gestion est transféré de la configuration hôte aux machines virtuelles d’infrastructure pendant le déploiement.
4	Il n’existe aucun paramètre d’entrée d’ID de VLAN pour le déploiement de portail Azure ou de modèle Resource Manager.

Adresses IP personnalisées pour le stockage

Par défaut, l’ATC réseau affecte automatiquement les adresses IP et les VLAN pour le stockage à partir du tableau suivant :

Adaptateur de stockage	Adresse IP et sous-réseau	Réseau Local Virtuel (VLAN)
pNIC1	10.71.1.x	7:11
pNIC2	10.71.2.x	712
pNIC3	10.71.3.x	713

Cependant, si vos exigences de déploiement ne correspondent pas à ces adresses IP par défaut ni aux VLAN, vous pouvez utiliser vos propres adresses IP, sous-réseaux et VLAN pour le stockage. Cette fonctionnalité n'est disponible que lors du déploiement de clusters à l’aide de modèles ARM. Vous devez spécifier les paramètres suivants dans votre modèle.

• enableStorageAutoIP  : ce paramètre, lorsqu’il n’est pas spécifié, est défini sur true. Pour activer les adresses IP de stockage personnalisées pendant le déploiement, ce paramètre doit avoir la valeur « false ».
• storageAdapterIPInfo : ce paramètre a une dépendance avec le paramètre « enableStorageAutoIP » et est toujours requis lorsque le paramètre IP automatique de stockage est défini sur « false ». Dans le paramètre « storageAdapterIPInfo » de votre modèle ARM, vous devez également spécifier les paramètres « ipv4Address » et « subnetMask » pour chaque nœud et carte réseau avec vos propres adresses IP et masque de sous-réseau.
• vlanId : comme décrit ci-dessus dans le tableau, ce paramètre utilise les VLAN par défaut des ATC réseau si vous n’avez pas besoin de les modifier. Cependant, si ces VLAN par défaut ne fonctionnent pas dans votre réseau, vous pouvez indiquer vos propres ID de VLAN pour chacun de vos réseaux de stockage.

Le modèle ARM suivant inclut un exemple d’instance Azure Local à deux nœuds avec un commutateur réseau pour le stockage, où les adresses IP de stockage sont personnalisées 2 nœuds de déploiement avec des adresses IP de stockage personnalisées

Affectation d’adresses IP de nœud et de cluster

Pour l’instance Azure Local, vous avez deux options pour attribuer des adresses IP pour les nœuds de machine et pour l’adresse IP du cluster.

• Les protocoles DHCP (Dynamic Host Configuration Protocol) et statique sont tous deux pris en charge.

• Attribuer des adresses IP de nœud de manière appropriée est essentiel pour la gestion du cycle de vie du cluster. Choisissez entre les options statiques et DHCP avant d’enregistrer les nœuds dans Azure Arc.

• Les machines virtuelles et services d’infrastructure, comme Arc Resource Bridge et Network Controller, continuent d’utiliser des adresses IP statiques à partir du pool d’adresses IP de gestion. Autrement dit, même si vous décidez d’utiliser DHCP pour affecter les adresses IP à vos nœuds et à votre adresse IP de cluster, le pool d’adresses IP de gestion est toujours nécessaire.

Les sections suivantes abordent les implications de chaque option.

Attribution d’adresse IP statique

Si vous utilisez des adresses IP statiques pour les nœuds, le pool d’adresses IP de gestion est utilisé pour obtenir une adresse IP disponible et l’affecter automatiquement à l’adresse IP du cluster lors du déploiement.

Il est important d’utiliser des adresses IP de gestion pour les nœuds qui ne font pas partie de la plage d’adresses IP définies pour le pool d’adresses IP de gestion. Les adresses IP de nœud des machines doivent se trouver sur le même sous-réseau de la plage d’adresses IP définie.

Nous vous recommandons de n’attribuer qu'une seule adresse IP de gestion pour la passerelle par défaut et pour les serveurs DNS configurés pour toutes les cartes réseau physiques du nœud. Ainsi, l’adresse IP ne change pas une fois l’intention du réseau de gestion créée. Par ailleurs, les nœuds conservent leur connectivité sortante pendant le processus de déploiement, notamment pendant l’inscription Azure Arc.

Pour éviter les problèmes de routage et identifier l’adresse IP utilisée pour la connectivité sortante et l’inscription Arc, le portail Azure vérifie qu’il existe plusieurs passerelles par défaut configurées.

Si un commutateur virtuel et une carte réseau virtuelle de gestion ont été créés pendant la configuration du système d’exploitation, l’adresse IP de gestion du nœud doit être affectée à cette carte réseau virtuelle.

Attribution d’adresse DHCP IP

Si des adresses IP pour les nœuds sont acquises depuis un serveur DHCP, une adresse IP dynamique est également utilisée pour l’adresse IP du cluster. Les machines virtuelles et services d’infrastructure nécessitent toujours des adresses IP statiques, ce qui signifie que la plage d’adresses du pool d’adresses IP de gestion doit être exclue de l’étendue DHCP utilisée pour les nœuds et l’adresse IP du cluster.

Par exemple, si la plage d’adresses IP de gestion est de 192.168.1.20/24 à 192.168.1.30/24 pour les adresses IP statiques de l’infrastructure, l’étendue DHCP définie pour le sous-réseau 192.168.1.0/24 doit avoir une exclusion équivalente au pool d’adresses IP de gestion pour éviter les conflits d'adresse IP avec les services d’infrastructure. Nous vous recommandons en outre d’utiliser des réservations DHCP pour les adresses IP de nœud.

Le processus de définition de l’adresse IP de gestion après la création de l’intention de gestion implique d'utiliser l’adresse MAC de la première carte réseau physique sélectionnée pour l’intention réseau. L'adresse MAC est ensuite affectée à la carte réseau virtuelle créée à des fins de gestion. Cela signifie que l’adresse IP que la première carte réseau physique obtient auprès du serveur DHCP est la même que celle utilisée par la carte réseau virtuelle comme adresse IP de gestion. Il est donc important de créer une réservation DHCP pour l’adresse IP du nœud.

La logique de validation réseau utilisée pendant le déploiement cloud échoue si elle détecte plusieurs interfaces réseau physiques ayant une passerelle par défaut dans leur configuration. Si vous devez utiliser le protocole DHCP pour l'attribution des adresses IP des hôtes, vous devez précréer le commutateur virtuel SET (switch embedded teaming) et l'adaptateur réseau virtuel de gestion comme décrit ci-dessus, de sorte que seul l'adaptateur réseau virtuel de gestion acquière une adresse IP auprès du serveur DHCP.

Informations concernant l’adresse IP du nœud de cluster

Voici un résumé des informations concernant les adresses IP :

#	Considérations
1	Les adresses IP de nœud doivent se trouver sur le même sous-réseau que la plage de pool d’adresses IP de gestion définie, qu’elles soient statiques ou dynamiques.
2	Le pool d’adresses IP de gestion ne doit pas inclure les adresses IP de nœud. Utilisez des exclusions DHCP si vous utilisez l’attribution d’adresses IP dynamiques.
3	Utilisez autant que possible les réservations DHCP pour les nœuds.
4	Les adresses DHCP sont uniquement prises en charge pour les adresses IP de nœud et l’adresse IP du cluster. Les services d’infrastructure utilisent des adresses IP statiques à partir du pool de gestion.
5	L’adresse MAC de la première carte réseau physique est affectée à la carte réseau virtuelle de gestion une fois l’intention du réseau de gestion créée.

Considérations relatives au serveur DNS

Les déploiements locaux Azure basés sur Active Directory nécessitent un serveur DNS capable de résoudre le domaine local et les points de terminaison publics Internet. Dans le cadre du déploiement, il est nécessaire de définir les mêmes serveurs DNS pour la plage d’adresses IP de l’infrastructure configurée sur les nœuds. La machine virtuelle du plan de contrôle Azure Resource Bridge et le plan de contrôle AKS utilisent ces mêmes serveurs DNS pour la résolution de noms. Une fois le déploiement terminé, il n'est pas possible de modifier les adresses IP des serveurs DNS, et il ne sera pas possible de mettre à jour les adresses dans la pile de la plateforme Azure locale.

Les serveurs DNS utilisés pour Azure Local doivent être externes et opérationnels avant le déploiement. Il n'est pas possible de les exécuter en tant que machines virtuelles Azure locales.

Voici les considérations résumées relatives aux adresses des serveurs DNS :

#	Considérations
1	Les serveurs DNS sur tous les nœuds du cluster doivent être identiques.
2	Les serveurs DNS de la plage d’adresses IP de l’infrastructure doivent être les mêmes que ceux utilisés pour les nœuds.
3	Le plan de contrôle de machine virtuelle Azure Resource Bridge et le plan de contrôle AKS utilisent les serveurs DNS configurés sur la plage d’adresses IP de l’infrastructure.
4	Il n'est pas possible de modifier les serveurs DNS après le déploiement. Veillez à planifier votre stratégie DNS avant d’effectuer le déploiement d’Azure Local.
5	Lorsque vous définissez un tableau de plusieurs serveurs DNS sur un modèle ARM pour le réseau d’infrastructure, vérifiez que chaque valeur se trouve entre guillemets « » et séparées par des virgules, comme dans l’exemple suivant.
6	Il n’est pas pris en charge pour exécuter les serveurs DNS utilisés par l’infrastructure locale Azure dans les machines virtuelles exécutées à l’intérieur de l’instance locale Azure.

"dnsServers": [
                        "10.250.16.124",
                        "10.250.17.232",
                        "10.250.18.107"
                    ]

Configuration requise du proxy

Un proxy sera probablement nécessaire pour accéder à Internet au sein de votre infrastructure locale. Azure Local ne prend en charge que les configurations de proxy non authentifiées. Étant donné qu'un à Internet est requis pour inscrire les nœuds dans Azure Arc, la configuration du proxy doit être définie lors de la configuration du système d’exploitation avant l’inscription des nœuds de machine. Pour plus d’informations, consultez Configurer les paramètres de proxy.

Le système d’exploitation Azure Stack HCI propose trois services différents (WinInet, WinHTTP et variables d’environnement) qui nécessitent la même configuration de proxy pour que tous les composants du système d’exploitation puissent accéder à Internet. La même configuration de proxy utilisée pour les nœuds est automatiquement transmise à la machine virtuelle Arc Resource Bridge et AKS. L'accès à internet sera donc octroyé durant le déploiement.

Voici un résumé des informations concernant la configuration du proxy :

#	Considération
1	La configuration du proxy doit être terminée avant d’inscrire les nœuds dans Azure Arc.
2	La même configuration de proxy doit être appliquée pour WinINET, WinHTTP et les variables d’environnement.
3	Grâce au vérificateur d’environnement, la configuration du proxy est cohérente entre tous les composants proxy.
4	La configuration proxy de la machine virtuelle Arc Resource Bridge et AKS est effectuée automatiquement par l’orchestrateur lors du déploiement.
5	Seuls les proxys non authentifiés sont pris en charge.

Configuration requise du pare-feu

Vous devez actuellement ouvrir plusieurs points de terminaison Internet dans vos pare-feu pour qu’Azure Local et ses composants puissent se connecter avec succès. Pour obtenir une liste détaillée des points de terminaison requis, consultez Configuration requise pour le pare-feu.

La configuration du pare-feu doit être effectuée avant d’inscrire les nœuds dans Azure Arc. Vous pouvez utiliser la version autonome du vérificateur d’environnement pour vous assurer que vos pare-feu ne bloquent pas le trafic envoyé à ces points de terminaison. Pour plus d’informations, consultez Azure Local Environment Checker pour évaluer la préparation du déploiement pour Azure Local.

Voici un résumé des informations concernant le pare-feu :

#	Considération
1	Vous devez configurer le pare-feu avant d’inscrire les nœuds dans Azure Arc.
2	Le vérificateur d’environnement en mode autonome peut être utilisé pour valider la configuration du pare-feu.

Étape 5 : Déterminer la configuration de la carte réseau

Les cartes réseau sont qualifiées par type de trafic réseau (gestion, calcul et stockage) avec lesquelles elles sont utilisées. Lorsque vous passez en revue le catalogue Windows Server, la certification Windows Server 2022 indique pour quel trafic réseau les cartes sont qualifiées.

Avant d’acheter une machine pour Azure Local, vous devez disposer d’au moins un adaptateur qualifié pour la gestion, le calcul et le stockage. Les trois types de trafic sont en effet requis sur Azure Local. Le déploiement cloud utilise Network ATC pour configurer les cartes réseau pour les types de trafic appropriés. Il est donc important d’utiliser les cartes réseau prises en charge.

Les valeurs par défaut qu'utilise Network ATC sont documentées dans Paramètres réseau du cluster. Nous vous recommandons d’utiliser les valeurs par défaut. Cela étant, les options suivantes peuvent être remplacées à l’aide de modèles Portail Azure ou Resource Manager si nécessaire :

• VLAN de stockage : définissez cette valeur sur les VLAN requis pour le stockage.
• Paquets Jumbo : définit la taille des paquets jumbo.
• Réseau direct : définissez cette valeur sur « false » si vous souhaitez désactiver RDMA pour vos cartes réseau.
• Technologie directe réseau : définissez cette valeur sur RoCEv2 ou iWarp.
• Traffic Priorities Datacenter Bridging (DCB) : définissez les priorités qui répondent à vos besoins. Nous vous recommandons vivement d’utiliser les valeurs DCB par défaut, car elles sont validées par Microsoft et les clients.

Voici un résumé des informations concernant la configuration de la carte réseau :

#	Considération
1	Utilisez les configurations par défaut autant que possible.
2	Les commutateurs physiques doivent être configurés en fonction de la configuration de la carte réseau. Consultez Exigences liées aux réseaux physiques pour Azure Local.
3	Vérifiez que vos cartes réseau sont prises en charge pour Azure Local à l’aide du catalogue Windows Server.
4	Lorsque vous acceptez les valeurs par défaut, Network ATC configure automatiquement les adresses IP de carte réseau de stockage et les VLAN. On appelle cette étape « configuration d’adresse IP automatique du stockage ». Dans certains cas, la configuration d’adresse IP automatique du stockage n’est pas prise en charge et vous devez déclarer chaque adresse IP de carte réseau de stockage à l’aide de modèles Resource Manager.

Étapes suivantes

• À propos du déploiement local Azure.