Architecture sans commutateur de stockage à trois nœuds Azure Stack HCI

Cet article s’inscrit dans une série consacrée à l’architecture de référence Azure Stack HCI. Pour déployer Azure Stack HCI de façon efficace à l’aide d’une conception de sans commutateur de stockage à trois nœuds, il est important de comprendre l’architecture de référence. Il s’agit notamment de se familiariser avec les choix de conception du cluster pour les nœuds physiques qui fournissent des capacités locales de calcul, de stockage et de mise en réseau. Ces connaissances vous aident à identifier les modifications nécessaires pour un déploiement réussi. Les conseils de cet article s’appliquent également à un déploiement de sans commutateur de stockage à deux nœuds et apportent les ajustements nécessaires pour les cas où le nombre de nœuds physiques passe de trois à deux.

La conception réseau sans commutateur de stockage supprime la nécessité pour les commutateurs réseau de classe de stockage de connecter les ports de carte réseau utilisés pour le trafic de stockage. Au lieu de cela, les nœuds sont directement connectés à l’aide de câbles Ethernet interlink. Cette configuration est couramment utilisée dans les scénarios de vente au détail, de fabrication ou de bureau distant. Elle convient également aux cas d’usage de périphériques de petite taille qui ne disposent pas ou ne nécessitent pas de commutateurs de réseau de centre de données étendus pour le trafic de réplication du stockage.

Cette architecture de référence fournit des conseils et des recommandations indépendantes de la charge de travail pour la configuration d’Azure Stack HCI en tant que plateforme d’infrastructure résiliente pour déployer et gérer des charges de travail virtualisées. Pour en savoir plus sur les modèles d’architecture de charge de travail optimisés pour s’exécuter sur Azure Stack HCI, consultez le contenu situé sous le menu de navigation des charges de travail Azure Stack HCI.

Cette architecture constitue un point de départ pour un cluster Azure Stack HCI à trois nœuds qui utilise une conception réseau sans commutateur de stockage. Les applications de charge de travail déployées sur un cluster Azure Stack HCI doivent être bien conçues. Cette approche inclut le déploiement de plusieurs instances pour la haute disponibilité de tous les services de charge de travail critiques et l’implémentation de contrôles de continuité d’activité et de récupération d’urgence appropriés, notamment les sauvegardes régulières et les fonctionnalités de basculement de récupération d’urgence. Pour se concentrer sur la plateforme d’infrastructure HCI, ces aspects de la conception de la charge de travail sont intentionnellement exclus de cet article. Pour en savoir plus sur les instructions et les recommandations relatives aux cinq piliers d’Azure Well-Architected Framework, consultez le guide du service Azure Stack HCI Well-Architected Framework.

Disposition de l’article

Architecture

Pour en savoir plus sur ces ressources, consultez Ressources associées.

Cas d’usage potentiels

Utilisez cette conception et celles décrites dans l’architecture de référence Azure Stack HCI pour répondre aux exigences de cas d’usage suivants :

• Déployez et gérez des charges de travail de périphérie hautement disponibles virtualisées ou basées sur des conteneurs qui sont déployées dans un emplacement unique pour permettre aux applications et aux services critiques pour l’entreprise de fonctionner de manière résiliente, économique et évolutive.

• La conception réseau sans commutateur de stockage supprime la nécessité de déployer des commutateurs réseau de classe de stockage pour connecter les ports de carte réseau utilisés pour le trafic de stockage.

• Vous pouvez utiliser la conception réseau sans commutateur de stockage pour réduire les coûts associés à l’approvisionnement et à la configuration des commutateurs réseau de classe de stockage pour le trafic de stockage, mais cela augmente le nombre de ports de carte réseau requis dans les nœuds physiques.

Composants de l’architecture

Les ressources d’architecture suivantes ne changent pratiquement pas par rapport à l’architecture de référence. Pour en savoir plus, consultez les ressources de plateforme et les ressources de prise en charge de plateforme utilisées pour les déploiements Azure Stack HCI.

Choix de conception de cluster

Lorsque vous déterminez les options de conception de votre cluster, reportez-vous à l’architecture de référence. Utilisez ces informations et l’outil Azure Stack HCI Sizer pour mettre à l’échelle correctement un cluster Azure Stack HCI en fonction des exigences de la charge de travail.

Si on utilise la conception sans commutateur de stockage, il ne jamais oublier que la taille maximale prise en charge est un cluster à trois nœuds. Cette limitation est un facteur clé dans vos choix de conception de clusters, car vous devez vous assurer que les exigences de capacité de votre charge de travail ne dépassent pas les capacités physiques des spécifications des clusters à trois nœuds. Étant donné qu’il n’est pas possible d’effectuer une opération d’ajout de nœud pour étendre un cluster sans commutateur de stockage au-delà de trois nœuds, il est extrêmement important de comprendre à l’avance les exigences de capacité de votre charge de travail et de formuler des plans en vue d’une croissance future. Vous pouvez ainsi vous assurer que votre charge de travail ne dépasse pas la capacité de stockage et de calcul pendant la durée de vie prévue du matériel du cluster Azure Stack HCI.

Conception du réseau

La conception du réseau fait référence à la disposition globale des composants physiques et logiques au sein du réseau. Dans une configuration sans commutateur de stockage à trois nœuds pour Azure Stack HCI, trois nœuds physiques sont directement connectés sans utiliser de commutateur externe pour le trafic de stockage. Ces connexions Ethernet directement liées entre elles simplifient la conception du réseau en réduisant la complexité, car il n’est pas nécessaire de définir ou d’appliquer des configurations de qualité de service et de priorisation du stockage sur les commutateurs. Les technologies qui sous-tendent la communication RDMA sans perte, telles que la notification explicite de congestion (ECN), le contrôle de flux prioritaire (PFC) ou la qualité de service (QoS) requises pour RoCE v2 et iWARP, ne sont pas nécessaires. Toutefois, cette configuration prend en charge trois nœuds maximum, ce qui signifie qu’on ne peut pas mettre à l’échelle le cluster en ajoutant d’autres nœuds après le déploiement.

Topologie de réseau physique

La topologie de réseau physique montre les connexions physiques réelles entre les nœuds et les composants réseau. Les connexions entre les nœuds et les composants réseau d’un déploiement Azure Stack HCI sans commutateur de stockage à trois nœuds sont les suivantes :

• Trois nœuds (ou serveurs) :

  • Chaque nœud est un serveur physique qui s’exécute sur le système d’exploitation Azure Stack HCI.

  • Chaque nœud nécessite six ports de carte réseau : quatre ports compatibles RDMA pour le stockage et deux pour la gestion et le calcul.

• Trafic du stockage :

  • Chacun des trois nœuds est interconnecté à travers deux ports de carte réseau physique dédiés au stockage. Le diagramme suivant illustre ce processus.

  • Les ports de la carte réseau de stockage se connectent directement à chaque nœud par des câbles Ethernet pour former une architecture réseau maillée complète pour le trafic de stockage.

  • Cette conception assure la redondance des liaisons, une faible latence dédiée, une large bande passante et un débit élevé.

  • Les nœuds du cluster HCI communiquent directement via ces liens pour gérer le trafic de réplication du stockage, également appelé trafic est-ouest.

  • Cette communication directe élimine la nécessité de ports de commutateurs réseau supplémentaires pour le stockage et l’exigence d’appliquer la configuration QoS ou PFC pour le trafic SMB Direct ou RDMA sur les commutateurs réseau.

  • Vérifiez auprès de votre fabricant de matériel ou de votre fournisseur de carte d’interface réseau (NIC) les pilotes de système d’exploitation, les versions de microprogramme ou les paramètres de microprogramme recommandés pour la configuration réseau d’interconnexion sans commutateur.

• Commutateurs ToR (Top-of-Rack) doubles :

  • Cette configuration est sans commutateur pour le trafic de stockage, mais nécessite tout de même des commutateurs ToR pour la connectivité externe. Cette connectivité est appelée trafic nord-sud et inclut l’intention de gestion du cluster et les intentions de calcul de la charge de travail.

  • Les liaisons montantes vers les commutateurs à partir de chaque nœud utilisent deux ports de carte réseau. Les câbles Ethernet connectent ces derniers, un sur chaque commutateur ToR, pour fournir une redondance de liaison.

  • Nous vous recommandons d’utiliser des commutateurs ToR doubles pour assurer la redondance des opérations de service et l’équilibrage de la charge pour la communication externe.

• Connectivité externe :

  • Les commutateurs ToR doubles se connectent au réseau externe, comme le réseau LAN interne de l’entreprise, et utilisent votre appareil frontalier en périphérie du réseau, comme un pare-feu ou un routeur, pour fournir l’accès aux URL sortants requis.

  • Les deux commutateurs ToR gèrent le trafic nord-sud du cluster Azure Stack HCI, y compris celui lié à la gestion et aux intentions de calcul.

    

Topologie de réseau logique

La topologie de réseau logique fournit une vue d’ensemble de la façon dont les données réseau circulent entre les appareils, quelles que soient leurs connexions physiques. La liste suivante récapitule la configuration logique d’un cluster Azure Stack HCI sans commutateur de stockage à trois nœuds :

• Commutateurs doubles ToR :

  • Avant le déploiement du cluster, il faut configurer les deux commutateurs réseau ToR avec les ID du réseau local virtuel requis et les paramètres d’unité de transmission maximale (MTU) pour les ports de gestion et de calcul. Pour en savoir plus, consultez la configuration réseau physique requise ou demandez de l’aide à votre fournisseur de matériel de commutation ou à votre partenaire intégrateur de systèmes (SI).

• Azure Stack HCI applique l’automatisation du réseau et la configuration réseau basée sur l’intention à l’aide du service Network ATC.

  • Network ATC est conçu pour garantir une configuration réseau optimale et un flux de trafic à l’aide d’intentions de trafic réseau. Network ATC définit les ports de carte réseau physiques utilisés pour les différentes intentions (ou types) de trafic réseau, comme pour la gestion du cluster, le calcul de charge de travail et les intentions de stockage du cluster.

  • Les stratégies basées sur les intentions simplifient les exigences de configuration du réseau en automatisant la configuration du réseau de nœuds en fonction des entrées de paramètres qui sont spécifiées dans le cadre du processus de déploiement du cloud Azure Stack HCI.

• Communications externes :

  • Lorsque les nœuds ou la charge de travail doivent communiquer avec l’extérieur en accédant au réseau LAN de l’entreprise, à Internet ou à un autre service, ils utilisent les commutateurs ToR doubles. Ce processus est décrit dans la section précédente Topologie de réseau physique.

  • Lorsque les deux commutateurs ToR agissent en tant qu’appareils de couche 3, ils gèrent le routage et fournissent une connectivité au-delà du cluster à l’appareil frontalier en périphérie, tel que votre pare-feu ou votre routeur.

  • L’intention du réseau de gestion utilise l’interface virtuelle SET (Converged Switch Embedded Teaming), qui permet à l’adresse IP de gestion du cluster et aux ressources du plan de contrôle de communiquer avec l’extérieur.

  • Pour l’intention du réseau de calcul, vous pouvez créer un ou plusieurs réseaux logiques dans Azure avec les ID de réseau local virtuel spécifiques pour votre environnement. Les ressources de charge de travail, telles que les machines virtuelles, utilisent ces ID pour donner accès au réseau physique. Les réseaux logiques utilisent les deux ports de carte réseau physique qui sont convergés à l’aide de SET pour les intentions de calcul et de gestion.

• Trafic du stockage :

  • Les nœuds communiquent entre eux directement pour le trafic de stockage en utilisant les quatre ports Ethernet d’interconnexion directe par nœud, qui utilisent six réseaux distincts non routables (ou couche 2) pour le trafic de stockage.

  • Il n’existe aucune passerelle par défaut configurée sur les quatre ports de carte réseau d’intention de stockage au sein du système d’exploitation du nœud Azure Stack HCI.

  • Chaque nœud peut accéder aux fonctionnalités S2D du cluster, notamment les disques physiques distants utilisés dans le pool de stockage, les disques virtuels et les volumes. L’accès à ces fonctionnalités est facilité par le protocole SMB Direct RDMA sur les deux ports de carte réseau de stockage dédiés disponibles dans chaque nœud. Le SMB multicanal est utilisé uniquement pour la résilience.

  • Cette configuration garantit une vitesse de transfert des données suffisante pour les opérations liées au stockage, telles que la maintenance de copies cohérentes de données pour les volumes mis en miroir.

    

    Schéma montrant la topologie de mise en réseau logique pour un cluster Azure Stack HCI à trois nœuds. Il utilise une architecture de stockage sans commutateur avec des commutateurs ToR doubles pour la connectivité externe (ou nord-sud).

Exigences relatives aux adresses IP

Pour déployer une configuration sans commutateur de stockage à trois nœuds Azure Stack HCI avec deux liens pour les interconnexions de stockage, la plateforme d’infrastructure de cluster exige l’allocation d’un minimum de 20 adresses IP. D’autres adresses IP sont requises si vous utilisez une appliance de machine virtuelle fournie par votre fabricant de matériel, ou si vous utilisez la microsegmentation ou la mise en réseau définie par logiciel (SDN). Pour en savoir plus, consultez Examiner les exigences en matière d’IP du modèle de référence de stockage à trois nœuds pour Azure Stack HCI.

Lorsque vous concevez et planifiez des exigences en matière d’adresses IP pour Azure Stack HCI, n’oubliez pas de tenir compte des adresses IP ou des plages de réseaux supplémentaires nécessaires pour votre charge de travail, en plus de celles qui sont requises pour le cluster Azure Stack HCI et les composants de l’infrastructure. Si vous envisagez d’utiliser Azure Kubernetes Services (AKS) sur Azure Stack HCI, consultez AKS activé par les exigences du réseau Azure Arc.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Éléments à prendre en compte lors de l’optimisation des coûts :

• Interconnexions de clusters sans commutateur et interconnexions de clusters basées sur des commutateurs. La topologie d’interconnexion sans commutateur se compose de connexions entre un port double ou redondant, des ports de carte réseau compatibles RDMA dans chaque nœud pour former un maillage complet. Chaque nœud possède deux connexions directes à chaque autre nœud. Bien que cette implémentation soit simple, elle n’est prise en charge que dans les clusters à deux ou à trois nœuds. Un cluster Azure Stack HCI avec quatre nœuds ou plus nécessite l’architecture réseau commutée de stockage. Vous pouvez utiliser cette architecture pour ajouter d’autres nœuds après le déploiement, contrairement à la conception sans commutateur de stockage qui ne prend pas en charge les opérations d’ajout de nœud.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Les considérations relatives aux performances sont les suivantes :

• On ne peut pas augmenter l’échelle (ou effectuer une opération d’ajout de nœud) d’un cluster HCI existant à trois nœuds sans commutateur de stockage sans le redéployer et sans ajouter des capacités de réseau supplémentaires telles que des commutateurs de réseau, des ports et des câbles pour le trafic de stockage, ainsi que les autres nœuds nécessaires. La taille maximale de cluster pour la conception de réseau sans commutateur de stockage est de trois nœuds. Tenez compte de cette limitation lors de la phase de conception du cluster afin de vous assurer que le matériel peut prendre en charge la croissance future de la capacité de la charge de travail.

Déployer ce scénario

Pour en savoir plus sur la conception, l’acquisition et le déploiement d’une solution Azure Stack HCI, consultez la section Déployer ce scénario de l’architecture de référence Azure Stack HCI.

Utilisez le modèle d’automatisation du déploiement suivant comme exemple de déploiement d’Azure Stack HCI à l’aide de l’architecture sans commutateur de stockage à trois nœuds.

Ressources associées

• Conception d’une architecture hybride
• Options hybrides Azure
• Azure Automation dans un environnement hybride
• Azure Automation – State Configuration
• Optimiser l’administration des instances SQL dans les environnements locaux et multiclouds avec Azure Arc

Étapes suivantes

Documentation du produit :

• Information sur la version 23H2 d’Azure Stack HCI
• AKS sur Azure Stack HCI
• Azure Virtual Desktop pour Azure Stack HCI
• Qu’est-ce que la surveillance Azure Stack HCI ?
• Protéger les charges de travail de machine virtuelle avec Site Recovery sur Azure Stack HCI
• Vue d’ensemble d’Azure Monitor
• Vue d’ensemble de Change Tracking and Inventory
• Aperçu du gestionnaire de mise à jour Azure
• Présentation des services de données avec Azure Arc
• Que sont les serveurs avec Azure Arc ?
• Qu’est-ce que Sauvegarde Azure ?
• Présentation de la cible de calcul Kubernetes dans Azure Machine Learning

Documentation produit sur des services Azure spécifiques :

• Azure Stack HCI
• Azure Arc
• Azure Key Vault
• Stockage Blob Azure
• Surveillance
• Azure Policy
• Azure Container Registry
• Microsoft Defender pour le cloud
• Azure Site Recovery
• Sauvegarde

Modules Microsoft Learn :

• Configurer le moniteur
• Concevoir votre solution de récupération de site dans Azure
• Présentation des serveurs avec Azure Arc
• Introduction aux services de données avec Azure Arc
• Introduction à AKS
• Adapter le modèle de déploiement avec Azure Machine Learning en tout lieu- Blog de la communauté technique
• Exploiter le machine learning partout avec AKS et le machine learning avec Arc - Blog de la communauté technique
• Machine Learning sur AKS hybride et Stack HCI à l’aide du machine learning avec Azure Arc - Blog de la communauté technique
• Garder à jour vos machines virtuelles
• Protéger les paramètres de vos machines virtuelles avec Azure Automation State Configuration
• Protéger vos machines virtuelles grâce à la sauvegarde