Considérations relatives au réseau pour les déploiements cloud d’Azure Stack HCI, version 23H2

S’applique à : Azure Stack HCI, version 23H2

Cet article explique comment concevoir et planifier un réseau système Azure Stack HCI version 23H2 pour le déploiement cloud. Avant de continuer, familiarisez-vous avec les différents modèles de mise en réseau Azure Stack HCI et les configurations disponibles.

Infrastructure de conception réseau

Le diagramme suivant montre les différentes décisions et étapes qui définissent l’infrastructure de conception réseau pour votre système Azure Stack HCI : taille du cluster, connectivité de stockage de cluster, intentions de trafic réseau, connectivité de gestion et configuration de carte réseau. Chaque décision de conception permet 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 système Azure Stack HCI, utilisez l’outil de tailleur Azure Stack HCI, où vous pouvez 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 telles qu’Azure Virtual Desktop, SQL Server ou AKS.

Comme décrit dans l’article sur la configuration requise du serveur système Azure Stack HCI, le nombre maximal de serveurs pris en charge sur le système Azure Stack HCI 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 serveur 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 et utiliser une configuration sans commutateur pour le trafic réseau de stockage. Vous devez inclure un commutateur physique avec prise en charge de 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 du cluster Azure Stack HCI, consultez la 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 sans commutateur ou commutées pour la connectivité de stockage.

• Si vous envisagez d’effectuer un scale-out ultérieur vers plus de trois nœuds : 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 nécessite 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 Stack HCI.

Voici les considérations résumées relatives à la décision de taille du cluster :

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

Comme décrit dans la configuration réseau physique requise, Azure Stack HCI 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 lié ci-dessus.

Comme indiqué précédemment, vous ne pouvez décider entre les deux options que lorsque la taille de votre cluster est de trois nœuds ou moins. Tout cluster avec quatre nœuds ou plus est automatiquement déployé à l’aide d’un commutateur réseau pour le stockage.

Si les clusters ont 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 à l’aide des câbles croisés n’a pas de connectivité nord-sud et il est complètement isolé du reste de votre infrastructure réseau. Cela signifie que vous devez 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 réseau avec un seul port de carte réseau physique chacun, cela ne fournit aucune tolérance de panne. Par conséquent, 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 les considérations résumées relatives à la décision de connectivité de stockage de cluster :

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 Stack HCI, 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 Stack HCI via le Portail Azure. Pour en savoir plus sur les intentions réseau et comment les résoudre, consultez commandes ATC réseau courantes.

Cette section explique les implications de votre décision de conception pour les intentions de trafic réseau et comment elles influencent l’étape suivante du framework. Pour les déploiements cloud, vous pouvez sélectionner 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 cartes réseau affectées à cette intention partagent la bande passante et le débit pour tout le trafic réseau.

• Cette option nécessite un commutateur physique pour le trafic de stockage. Si vous avez besoin d’une architecture sans commutateur, vous ne pouvez pas utiliser ce type d’intention. Portail Azure filtre automatiquement cette option si vous sélectionnez une configuration sans commutateur pour la connectivité de stockage.

• Au moins deux ports de carte réseau sont recommandés pour garantir la haute disponibilité.

• Au moins 10 Gbits/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

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

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

• Au moins deux ports de carte réseau sont disponibles pour chaque intention afin de garantir la haute disponibilité.

• Un commutateur physique est utilisé pour RDMA si vous utilisez le commutateur réseau pour le stockage.

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

Intention du réseau : grouper le trafic de calcul et de stockage

Network ATC configure deux intentions. La première intention inclut le trafic réseau de calcul et de stockage, et la deuxième intention inclut uniquement le trafic réseau de gestion. Chaque intention doit utiliser un ensemble différent de ports de carte 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 nécessite une communication nord-sud. Si vous avez besoin d’une configuration sans commutateur, vous ne pouvez pas utiliser ce type d’intention. 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.

• Au moins deux ports de carte réseau sont recommandés pour garantir la haute disponibilité.

• Au moins 10 Gbits/s sont recommandées 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 à l’aide de 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 types de charges de travail distincts.

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

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

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

• Au moins 10 Gbits/s sont recommandées 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 façon dont ces adresses sont affectées à votre cluster et, s’il existe un proxy ou un ID de réseau local virtuel 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 de commencer le déploiement afin de pouvoir anticiper les exigences de routage, de pare-feu ou de sous-réseau.

Pilotes de 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 vous assurer 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 peuvent ne pas apparaître lors de l’utilisation des pilotes Microsoft par défaut.

Pool d’adresses IP de gestion

Lorsque vous effectuez le déploiement initial de votre système Azure Stack HCI, vous devez définir une plage d’adresses IP consécutives pour les services d’infrastructure déployés par défaut.

Pour vous assurer que la plage dispose de suffisamment d’adresses IP pour les services d’infrastructure actuels et futurs, vous devez utiliser une plage d’au moins six adresses IP disponibles consécutives. Ces adresses sont utilisées pour : l’adresse IP du cluster, 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 après le déploiement du réseau d’infrastructure à l’aide de PowerShell si la taille du pool que vous avez planifié est épuisée à l’origine.

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 :

ID de réseau local virtuel de gestion

Nous recommandons que le sous-réseau de gestion de votre cluster Azure HCI utilise le réseau local virtuel par défaut, qui, dans la plupart des cas, est déclaré comme ID de réseau local virtuel 0. Toutefois, si vos besoins réseau doivent utiliser un réseau local virtuel 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 définir le réseau local virtuel sur les deux cartes. Cette opération doit être effectuée dans le cadre de la configuration de démarrage de vos serveurs, et avant qu’ils ne soient inscrits auprès d’Azure Arc, pour vous assurer que vous inscrivez correctement les nœuds à l’aide de ce réseau local virtuel.

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

Cet exemple configure l’ID de réseau local virtuel 44 sur la carte NIC1réseau physique.

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 réseau local virtuel à partir de la carte réseau physique utilisée pour la gestion et la stocke, afin qu’elle puisse être utilisée pour la machine virtuelle Azure Resource Bridge ou toute autre machine virtuelle d’infrastructure requise pendant le déploiement. Il n’est pas possible de définir l’ID de réseau local virtuel de gestion pendant le déploiement cloud à partir de Portail Azure car 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.

ID de réseau local virtuel de gestion avec un commutateur virtuel

Dans certains scénarios, il est nécessaire de créer un commutateur virtuel avant le démarrage du déploiement.

Si une configuration de commutateur virtuel est requise et que vous devez utiliser un ID de réseau local virtuel spécifique, procédez comme suit :

1. Créer un commutateur virtuel avec une convention d’affectation de noms recommandée

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

Nous vous recommandons de nommer vos noms de commutateur virtuel avec la même convention d’affectation de noms. Le nom recommandé pour les commutateurs virtuels est le suivant :

«ConvergedSwitch($IntentName) », où $IntentName doit correspondre le nom de l’intention tapée dans le portail pendant le 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 montre 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

2. Configurer la carte réseau virtuelle de gestion à l’aide de la convention d’affectation de noms 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 normes d’affectation de noms 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 la carte réseau et de la carte réseau virtuelle doivent utiliser vManagement($intentname).
• Ce nom respecte 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 lors de la définition du nom de l’intentionMgmt.

Pour mettre à jour le nom de la carte réseau virtuelle 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 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 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 Set-VMNetworkAdapterIsolation commande.

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, DNS, Active Directory et Internet.

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

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

4. Référencer les cartes réseau physiques pour l’intention de gestion pendant le déploiement

Bien que la carte réseau virtuelle nouvellement créée s’affiche comme disponible lors du déploiement via Portail Azure, il est important de se rappeler que la configuration réseau est basée sur Network ATC. Cela signifie que lors de la configuration de la gestion ou de l’intention de gestion et de calcul, nous devons toujours sélectionner les cartes réseau physiques utilisées pour cette intention.

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

Voici les considérations résumées relatives à l’ID de réseau local virtuel :

Adresses IP personnalisées pour le stockage

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

Toutefois, si vos exigences de déploiement ne correspondent pas à ces adresses IP par défaut et aux réseaux locaux virtuels, vous pouvez utiliser vos propres adresses IP, sous-réseaux et réseaux locaux virtuels pour le stockage. Cette fonctionnalité est disponible uniquement lors du déploiement de clusters à l’aide de modèles ARM et 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 » dans 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 réseaux locaux virtuels réseau atc par défaut si vous n’avez pas besoin de les modifier. Toutefois, si ces réseaux virtuels par défaut ne fonctionnent pas dans votre réseau, vous pouvez spécifier vos propres ID de réseau local virtuel pour chacun de vos réseaux de stockage.

Le modèle ARM suivant inclut un exemple de cluster HCI à deux nœuds avec 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 le système Azure Stack HCI, vous avez deux options pour attribuer des adresses IP pour les nœuds de serveur et pour l’adresse IP du cluster.

• Les protocoles DHCP (Static and Dynamic Host Configuration Protocol) sont pris en charge.

• L’attribution d’adresses IP de nœud appropriée est essentielle pour la gestion du cycle de vie du cluster. Choisissez entre les options statiques et DHCP avant d’inscrire les nœuds dans Azure Arc.

• Les machines virtuelles et services d’infrastructure, tels que Arc Resource Bridge et le contrôleur de réseau, continuent d’utiliser des adresses IP statiques à partir du pool d’adresses IP de gestion. Cela implique que 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 décrivent les implications de chaque option.

Affectation d’adresses IP statiques

Si des adresses IP statiques sont utilisées 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 pendant le 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 serveur doivent se trouver sur le même sous-réseau de la plage d’adresses IP définies.

Nous vous recommandons d’attribuer 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. Cela garantit que l’adresse IP ne change pas une fois l’intention du réseau de gestion créée. Cela garantit également que 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, Portail Azure valide s’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.

Affectation d’adresses IP DHCP

Si des adresses IP pour les nœuds sont acquises à partir d’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 implique 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 définie comme 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 IP avec les services d’infrastructure. Nous vous recommandons également 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 l’utilisation de l’adresse MAC de la première carte réseau physique sélectionnée pour l’intention réseau. Cette 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 adresse IP que celle utilisée par la carte réseau virtuelle comme adresse IP de gestion. Par conséquent, il est 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 qui ont une passerelle par défaut dans leur configuration. Si vous devez utiliser DHCP pour vos attributions d’adresses IP hôtes, vous devez précréer le commutateur virtuel SET (changer d’association incorporée) et la carte réseau virtuelle de gestion comme décrit ci-dessus, de sorte que seule la carte réseau virtuelle de gestion acquiert une adresse IP à partir du serveur DHCP.

Considérations relatives à l’adresse IP du nœud de cluster

Voici les considérations résumées relatives aux adresses IP :

Configuration requise du proxy

Un proxy est probablement nécessaire pour accéder à Internet au sein de votre infrastructure locale. Azure Stack HCI prend uniquement en charge les configurations de proxy non authentifiées. Étant donné que l’accès à Internet est requis pour inscrire les nœuds dans Azure Arc, la configuration du proxy doit être définie dans le cadre de la configuration du système d’exploitation avant l’inscription des nœuds de serveur. Pour plus d’informations, consultez Configuration des paramètres de proxy.

Le système d’exploitation Azure Stack HCI a trois services différents (WinInet, WinHTTP et variables d’environnement) qui nécessitent la même configuration de proxy pour garantir que tous les composants du système d’exploitation peuvent 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, ce qui garantit qu’ils disposent d’un accès Internet pendant le déploiement.

Voici les considérations résumées relatives à la configuration du proxy :

Configuration requise du pare-feu

Vous devez actuellement ouvrir plusieurs points de terminaison Internet dans vos pare-feu pour vous assurer qu’Azure Stack HCI et ses composants peuvent se connecter avec succès. Pour obtenir une liste détaillée des points de terminaison requis, consultez la 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 vérifier que vos pare-feu ne bloquent pas le trafic envoyé à ces points de terminaison. Pour plus d’informations, consultez Azure Stack HCI Environment Checker pour évaluer la préparation du déploiement pour Azure Stack HCI.

Voici les considérations résumées relatives au 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 un serveur pour Azure Stack HCI, vous devez disposer d’au moins un adaptateur qualifié pour la gestion, le calcul et le stockage, car les trois types de trafic sont requis sur Azure Stack HCI. Le déploiement cloud s’appuie sur 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 utilisées par Network ATC sont documentées dans les paramètres réseau du cluster. Nous vous recommandons d’utiliser les valeurs par défaut. Cela dit, les options suivantes peuvent être remplacées à l’aide de modèles Portail Azure ou Resource Manager si nécessaire :

• Réseaux locaux virtuels de stockage : définissez cette valeur sur les réseaux locaux virtuels 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 Bridgeing (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 par les clients.

Voici les considérations résumées relatives à la configuration de la carte réseau :

Étapes suivantes

• À propos d’Azure Stack HCI, déploiement de la version 23H2.