Architecture de référence pour AKS Azure Stack HCI

Cette architecture de référence de référence fournit des conseils et des recommandations indépendantes de la charge de travail pour la configuration d’une infrastructure Azure Stack HCI 23H2 et ultérieures pour garantir une plateforme fiable qui peut déployer et gérer des charges de travail virtualisées et conteneurisées hautement disponibles. Cette architecture décrit les composants de ressources et les choix de conception de cluster pour les nœuds physiques qui fournissent des fonctionnalités de calcul, de stockage et de mise en réseau locales. Elle explique également comment utiliser les services Azure pour simplifier et rationaliser la gestion au quotidien d’Azure Stack HCI.

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 utiliser la conception réseau commutée de stockage pour le déploiement d’un cluster Azure Stack HCI à plusieurs nœuds. Les applications de charge de travail déployées sur un cluster Azure Stack HCI doivent être bien conçues. Les applications de charge de travail bien conçues doivent être déployées à l’aide de plusieurs instances ou d’une haute disponibilité de tous les services de charge de travail critiques et en mettant en place des contrôles appropriés de continuité des activités et de reprise après sinistre (BCDR). Ces contrôles BCDR incluent des sauvegardes régulières et des 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 plus d’informations, consultez Ressources associées.

Cas d’usage potentiels

Les cas d’usage classiques pour Azure Stack HCI incluent la possibilité d’exécuter des charges de travail haute disponibilité (HA) dans des emplacements locaux ou en périphérie, ce qui fournit une solution pour répondre aux exigences de la charge de travail. Vous pouvez :

• Fournir une solution de cloud hybride déployée sur site pour répondre aux exigences de souveraineté des données, de réglementation et de conformité, ou de latence.

• Déployer et gérer des charges de travail en périphérie hautement disponibles virtualisées ou basées sur des conteneurs déployées dans un emplacement unique ou dans plusieurs emplacements. Cette stratégie permet aux applications et aux services critiques pour l’entreprise de fonctionner de manière résiliente, rentable et évolutive.

• Réduire le coût total de possession (TCO) en utilisant des solutions certifiées par Microsoft, un déploiement basé sur le cloud, une gestion centralisée, ainsi que des fonctions de surveillance et d’alerte.

• Fournir une fonctionnalité d’approvisionnement centralisée à l’aide d’Azure et d’Azure Arc pour déployer des charges de travail sur plusieurs emplacements de manière cohérente et sécurisée. Des outils comme le portail Azure, Azure CLI ou les modèles d’infrastructure en tant que code (IaC) utilisent Kubernetes pour la conteneurisation ou la virtualisation traditionnelle de la charge de travail pour favoriser l’automatisation et la répétabilité.

• Respecter les exigences strictes de sécurité, de conformité et d’audit. Azure Stack HCI est déployé avec une posture de sécurité renforcée configurée par défaut ou sécurisée par défaut. Azure Stack HCI intègre du matériel certifié, un démarrage sécurisé, un module de plateforme sécurisée (TPM), une sécurité basée sur la virtualisation (VBS), la protection des informations d’identification et des stratégies Windows Defender Application Control appliquées. Il s’intègre également aux services modernes de sécurité et de gestion des menaces basés sur le cloud, tels que Microsoft Defender pour le cloud et Microsoft Sentinel.

Détails du scénario

Les sections suivantes fournissent plus d’informations sur les scénarios et les cas d’usage potentiels pour cette architecture de référence. Ces sections incluent une liste des avantages métier et des exemples de types de ressources de charge de travail que vous pouvez déployer sur Azure Stack HCI.

Utiliser Arc avec Azure Stack HCI

Azure Stack HCI s’intègre directement à Azure à l’aide d’Azure Arc pour réduire la surcharge opérationnelle et le coût total de possession. Azure Stack HCI est déployé et géré via Azure, qui fournit une intégration intégrée d’Azure Arc à travers le déploiement du composant pont de ressources Azure Arc. Ce composant est installé pendant le processus de déploiement du cluster HCI. Les nœuds de cluster Azure Stack HCI sont inscrits auprès d’Azure Arc pour les serveurs comme prérequis pour lancer le déploiement basé sur le cloud du cluster. Pendant le déploiement, les extensions obligatoires sont installées sur chaque nœud de cluster, comme Lifecycle Manager, Gestionnaire des appareils Microsoft Edge et les données de télémétrie et de diagnostic. Vous pouvez utiliser Azure Monitor et l’analytique des journaux d’activité pour surveiller le cluster HCI après le déploiement en activant Azure Stack HCI Insights. Les mises à jour des fonctionnalités pour Azure Stack HCI sont publiées régulièrement afin d’améliorer l’expérience utilisateur. Les mises à jour sont contrôlées et gérées via le Gestionnaire de mise à jour Azure.

Vous pouvez déployer des ressources de charge de travail telles que des machines virtuelles Azure Arc, Azure Kubernetes Service (AKS) avec Azure Arc et des hôtes de session Azure Virtual Desktop qui utilisent le Portail Azure en sélectionnant un emplacement personnalisé de cluster Azure Stack HCI comme cible pour le déploiement de la charge de travail. Ces composants fournissent une administration, une gestion et un support centralisés. Si vous disposez d’une Software Assurance active sur vos licences de base Windows Server Datacenter existantes, vous pouvez réduire les coûts en appliquant Azure Hybrid Benefit à Azure Stack HCI, aux machines virtuelles Windows Server et aux clusters AKS. Cette optimisation permet de gérer efficacement les coûts de ces services.

L’intégration d’Azure et d’Azure Arc étend les fonctionnalités des charges de travail virtualisées et conteneurisées Azure Stack HCI à inclure :

• Machines virtuelles Azure Arc pour les applications ou services traditionnels qui s’exécutent dans des machines virtuelles sur Azure Stack HCI.

• AKS sur Azure Stack HCI pour les applications ou services conteneurisés qui tirent parti de l’utilisation de Kubernetes comme plateforme d’orchestration.

• Azure Virtual Desktop pour déployer vos hôtes de session pour les charges de travail Azure Virtual Desktop sur Azure Stack HCI (sur site). Vous pouvez utiliser le plan de contrôle et de gestion dans Azure pour lancer la création et la configuration du pool d’hôtes.

• Services de données avec Azure Arc pour Azure SQL Managed Instance conteneurisé ou un serveur Azure Database pour PostgreSQL qui utilise Azure Arc-enabled AKS hébergé sur Azure Stack HCI.

• L’extension Azure Event Grid avec Azure Arc pour Kubernetes afin de déployer les composants de l’agent Event Grid et de l’opérateur Event Grid. Ce déploiement permet d’utiliser des fonctionnalités telles que les rubriques et les abonnements Event Grid pour le traitement des événements.

• Machine learning avec Azure Arc avec un cluster AKS déployé sur Azure Stack HCI en tant que cible de calcul pour exécuter Azure Machine Learning. Vous pouvez utiliser cette approche pour entraîner ou déployer des modèles de machine learning en périphérie.

Les charges de travail connectées à Azure Arc offrent une cohérence et une automatisation Azure améliorées pour les déploiements Azure Stack HCI, notamment l’automatisation de la configuration du SE invité avec les extensions de machine virtuelle Azure Arc ou l’évaluation de la conformité aux réglementations du secteur ou aux normes d’entreprise par le biais d’Azure Policy. Vous pouvez activer Azure Policy via le portail Azure ou l’automatisation IaC.

Tirez parti de la configuration de sécurité par défaut d’Azure Stack HCI

La configuration de sécurité par défaut d’Azure Stack HCI fournit une stratégie de défense en profondeur pour simplifier les coûts de sécurité et de conformité. Le déploiement et la gestion des services informatiques pour les scénarios de vente au détail, de fabrication et de bureau distant présentent des défis uniques en matière de sécurité et de conformité. La sécurisation des charges de travail contre les menaces internes et externes est cruciale dans les environnements qui disposent d’un support informatique limité ou qui manquent de centres de données dédiés. Azure Stack HCI dispose d’un renforcement de la sécurité par défaut et d’une intégration approfondie avec les services Azure pour vous aider à relever ces défis.

Le matériel certifié Azure Stack HCI intègre la prise en charge du démarrage sécurisé, d’UEFI (Unified Extensible Firmware Interface) et du TPM. Utilisez ces technologies en combinaison avec VBS pour protéger vos charges de travail vulnérables sur le plan de la sécurité. Vous pouvez utiliser le chiffrement de lecteur BitLocker pour chiffrer les volumes de disque de démarrage et les volumes directs des espaces de stockage au repos. Le chiffrement SMB (Server Message Block) fournit le chiffrement automatique du trafic entre les serveurs du cluster (sur le réseau de stockage) et la signature du trafic SMB entre les nœuds du cluster et d’autres systèmes. Le chiffrement SMB permet également d’éviter les attaques de relais et facilite la conformité aux normes réglementaires.

Vous pouvez intégrer les machines virtuelles Azure Stack HCI dans Defender pour le cloud pour activer l’analytique comportementale basée sur le cloud, la détection des menaces, la correction, les alertes et les rapports. Gérez les machines virtuelles Azure Stack HCI dans Azure Arc afin de pouvoir utiliser Azure Policy pour évaluer la conformité avec les réglementations du secteur et les normes de l’entreprise.

Composants

Cette architecture se compose de serveurs physiques que vous pouvez utiliser pour déployer des clusters Azure Stack HCI dans des emplacements locaux ou en périphérie. Pour améliorer les fonctionnalités de plateforme, Azure Stack HCI s’intègre à Azure Arc et à d’autres services Azure qui fournissent des ressources de prise en charge. Azure Stack HCI fournit une plateforme résiliente pour déployer, gérer et exploiter des applications utilisateur ou des systèmes métier. Les ressources et les services de plateforme sont décrits dans les sections suivantes.

Ressources de la plate-forme

L’architecture nécessite les ressources et composants obligatoires suivants :

• Azure Stack HCI est une solution d’infrastructure hyperconvergée (HCI) qui est déployée sur site ou en périphérie au moyen d’un serveur physique et d’une infrastructure réseau. Azure Stack HCI offre une plateforme pour déployer et gérer des charges de travail virtualisées telles que des machines virtuelles, des clusters Kubernetes et d’autres services activés par Azure Arc. Les clusters Azure Stack HCI peuvent évoluer d’un déploiement à un seul nœud jusqu’à un maximum de seize nœuds en utilisant des catégories de matériel validées, intégrées ou premium qui sont fournies par des partenaires fabricants d’ordinateurs (OEM).

• Azure Arc est un service basé sur le cloud qui étend le modèle de gestion basé sur Azure Resource Manager à Azure Stack HCI et à d’autres sites non-Azure. Azure Arc utilise Azure comme plan de contrôle et de gestion pour faciliter la gestion de diverses ressources telles que les machines virtuelles, les clusters Kubernetes, les données conteneurisées et les services de machine learning.

• Azure Key Vault est un service cloud que vous pouvez utiliser pour stocker et accéder en toute sécurité aux secrets. Un secret est un élément auquel on souhaite restreindre étroitement l’accès, comme les clés API, les mots de passe, les certificats, les clés de chiffrement, les informations d’identification de l’administrateur local et les clés de récupération BitLocker.

• Témoin cloud est une fonctionnalité d’Azure Storage qui agit comme quorum de cluster de basculement. Les nœuds de cluster Azure Stack HCI utilisent ce quorum pour voter, ce qui garantit la haute disponibilité du cluster. Le compte de stockage et la configuration du témoin sont créés pendant le processus de déploiement cloud Azure Stack HCI.

• Le Gestionnaire de mises à jour est un service unifié conçu pour gérer et régir les mises à jour pour Azure Stack HCI. Vous pouvez utiliser le Gestionnaire de mises à jour pour gérer les charges de travail déployées sur Azure Stack HCI, y compris la conformité des mises à jour du SE invité pour les machines virtuelles Windows et Linux. Cette approche unifiée simplifie la gestion des patchs dans les environnements Azure, sur site, et d’autres plateformes cloud via un tableau de bord unique.

Ressources de prise en charge de la plateforme

L’architecture inclut les services de prise en charge facultatifs suivants pour améliorer les fonctionnalités de la plateforme :

• Monitor est un service basé sur le cloud qui permet de collecter, d’analyser et d’agir sur les journaux de diagnostic et les données de télémétrie de vos charges de travail dans le cloud et sur site. Monitor vous permet d’optimiser la disponibilité et les performances de vos applications et services grâce à une solution de surveillance complète. Déployez Azure Stack HCI Insights pour simplifier la création de la règle de collecte de données (DCR) Monitor et activer rapidement la surveillance des clusters Azure Stack HCI.

• Azure Policy est un service qui évalue les ressources Azure et sur site. Azure Policy évalue les ressources grâce à l’intégration avec Azure Arc en utilisant les propriétés de ces dernières pour les règles métier, appelées définitions de stratégie, afin de déterminer la conformité ou les capacités que vous pouvez utiliser pour appliquer la configuration de la machine virtuelle invitée à l’aide des paramètres de la stratégie.

• Defender pour le cloud est une système de gestion de sécurité de l’infrastructure complète. Il améliore la posture de sécurité de vos centres de données et offre une protection avancée contre les menaces pour les charges de travail hybrides, qu’elles résident dans Azure ou ailleurs, et entre les environnements sur site.

• Azure Backup est un service basé sur le cloud qui fournit une solution simple, sécurisée et rentable pour sauvegarder vos données et les récupérer dans le cloud Microsoft. Le serveur de sauvegarde Azure est utilisé pour effectuer la sauvegarde de machines virtuelles déployées sur Azure Stack HCI et les stocker dans le service de sauvegarde.

• Site Recovery est un service de récupération d’urgence qui fournit des fonctionnalités BCDR en permettant aux applis métier et aux charges de travail de basculer en cas de sinistre ou de panne. Site Recovery gère la réplication et le basculement des charges de travail exécutées sur des serveur physiques et des machines virtuelles entre leur site principal (sur site) et un emplacement secondaire (Azure).

Choix de conception de cluster

Lors de la conception d’un cluster HCI Azure Stack, il est important de comprendre les exigences en matière de performances et de résilience de la charge de travail. Ces exigences incluent l’objectif de délai de récupération (RTO) et l’objectif de point de récupération (RPO), les exigences en matière de calcul (PROCESSEUR), de mémoire et de stockage pour toutes les charges de travail déployées sur le cluster Azure Stack HCI. Plusieurs caractéristiques de la charge de travail affectent le processus décisionnel et incluent :

• Les capacités de l’architecture de l’unité centrale de traitement (UC), y compris les caractéristiques de la technologie de sécurité matérielle, le nombre d’UC, la fréquence (vitesse) du GHz et le nombre de cœurs par socket d’UC.

• Les exigences liées à l’unité de traitement graphique (GPU) de la charge de travail, telles que pour l’IA ou le machine learning, l’inférence ou le rendu graphique.

• La mémoire par nœud ou la quantité de mémoire physique requise pour exécuter la charge de travail.

• Le nombre de nœuds physiques dans le cluster qui va de 1 à 16 nœuds à l’échelle. Le nombre maximal de nœuds est de trois lorsque vous utilisez l’architecture réseau sans commutateur de stockage.

  • Pour maintenir la résilience de calcul, vous devez réserver au moins N+1 nœuds de capacité dans le cluster. Cette stratégie permet le drainage des nœuds pour les mises à jour ou la récupération après des pannes soudaines telles que les coupures de courant ou les défaillances matérielles.

  • Pour les charges de travail critiques, envisagez de réserver une capacité de N+2 nœuds pour augmenter la résilience. Ainsi, si deux nœuds du cluster sont hors connexion, la charge de travail peut rester en ligne. Cette approche permet de faire face aux scénarios dans lesquels un nœud exécutant une charge de travail est mis hors ligne au cours d’une procédure de mise à jour planifiée, ce qui entraîne la mise hors ligne simultanée de deux nœuds.

• Exigences en matière de résilience, de capacité et de performance du stockage :

  • Résilience : nous vous recommandons de déployer trois nœuds ou plus pour activer la mise en miroir tridirectionnelle, qui fournit trois copies des données, pour les volumes d’infrastructure et d’utilisateur. La mise en miroir tridirectionnelle améliore les performances et la fiabilité maximale pour le stockage.

  • Capacité : le stockage utilisable total requis après la prise en compte de la tolérance aux panne, ou des copies. Ce chiffre correspond à environ 33 % de l’espace de stockage brut de vos disques de niveau de capacité lorsque vous utilisez la mise en miroir tridirectionnelle.

  • Performances : opérations d’entrée/sortie par seconde (IOPS) de la plateforme qui détermine les capacités de débit de stockage de la charge de travail lorsqu’elles sont multipliées par la taille de bloc de l’application.

Pour concevoir et planifier un déploiement Azure Stack HCI, nous vous recommandons d’utiliser l’outil de dimensionnement Azure Stack HCI et de créer un Nouveau projet pour le dimensionnement de vos clusters HCI. Pour utiliser l’outil de dimensionnement, vous devez connaître vos exigences en matière de charge de travail. Lors de l’évaluation du nombre et de la taille des machines virtuelles qui s’exécutent sur votre cluster, veillez à prendre en compte des facteurs tels que le nombre de processeurs virtuels, les besoins en mémoire et la capacité de stockage nécessaire pour les machines virtuelles.

La section Préférences de l’outil de dimensionnement répond aux questions relatives au type de système (Premier, système intégré ou nœud validé) et aux options de famille de CPU. Il vous aide également à sélectionner vos exigences en matière de résilience pour le cluster. Veillez à respecter les points suivants :

• Réservez au minimum une capacité de N+1 nœuds, ou un nœud, dans le cluster.

• Réservez une capacité de N+2 nœuds dans le cluster pour une résilience supplémentaire. Cette option permet au système de résister à une défaillance de nœud lors d’une mise à jour ou d’un autre événement inattendu qui affecte simultanément deux nœuds. Elle garantit également que la capacité du cluster est suffisante pour que la charge de travail s’exécute sur les nœuds restants en ligne.

Ce scénario nécessite l’utilisation de la mise en miroir tridirectionnelle pour les volumes utilisateur, qui est celle par défaut pour les clusters qui ont trois nœuds physiques ou plus.

Le résultat de l’outil de dimensionnement d’Azure Stack HCI est une liste de solutions matérielles recommandées qui peuvent fournir la capacité de charge de travail requise et les exigences en matière de résilience de la plateforme en fonction des valeurs d’entrée dans le dimensionneur de projets. Pour en savoir plus sur les solutions de partenaires fabricants de matériel OEM disponibles, consultez le Catalogue de solutions Azure Stack HCI. Pour vous aider à dimensionner correctement les références de la solution en fonction de vos besoins, contactez votre fournisseur de solutions matérielles ou votre partenaire d’intégration de systèmes (SI) préféré.

Lecteurs de disques physiques

Les espaces de stockage directs prennent en charge plusieurs types de disques physiques qui varient en termes de performances et de capacité. Lorsque vous concevez un cluster HCI Azure Stack, travaillez avec le fabricant de matériel que vous avez choisi pour déterminer les types de disques physiques les plus appropriés pour répondre aux exigences en matière de capacité et de performances de votre charge de travail. Les disques durs rotatifs (HDD), ou les lecteurs SSD (Solid State Drives) et NVMe en sont des exemples. Ces lecteurs sont souvent appelés lecteurs flash, ou stockage de mémoire persistante (PMem), connu sous le nom de mémoire de classe de stockage (SCM).

La fiabilité de la plateforme dépend de la performance de ses dépendances critiques, telles que les types de disques physiques. Veillez à choisir les types de disques appropriés pour vos besoins. Utilisez des solutions de stockage flash comme des lecteurs NVMe ou SSD pour les charges de travail qui ont des exigences élevées en matière de performances ou de faible latence. Ces charges de travail incluent, sans s’y limiter, les technologies de bases de données hautement transactionnelles, les clusters AKS de production, ou toute charge de travail stratégique ou critique pour l’entreprise qui ont des besoins de stockage à faible latence ou à débit élevé. Utilisez des déploiements 100 % flash pour optimiser les performances de stockage. Les configurations entièrement composées de lecteurs NVMe ou SSD, en particulier à petite échelle, améliorent l’efficacité du stockage et maximisent les performances car aucun lecteur n’est utilisé en tant que niveau de cache. Pour en savoir plus, consultez Stockage entièrement flash.

Pour les charges de travail à usage général, une configuration de stockage hybride, comme des lecteurs NVMe ou SSD pour le cache et des disques durs pour la capacité, peut fournir davantage d’espace de stockage. La contrepartie est que les performances des disques rotatifs sont inférieures si la charge de travail dépasse l’ensemble de travail du cache, et que le temps moyen entre deux pannes des disques durs est inférieur à celui des lecteurs NVMe et SSD.

Les performances de votre stockage en cluster sont influencées par le type de disque physique, qui varie en fonction des caractéristiques de performance de chaque type de disque et du mécanisme de mise en cache que vous avez choisi. Le type de disque physique fait partie intégrante de la conception et de la configuration des espaces de stockage directs. En fonction des exigences en matière de charges de travail et des contraintes budgétaires d’Azure Stack HCI, vous pouvez choisir d’optimiser les performances, d’optimiser la capacité ou d’implémenter une configuration mixte de types de lecteurs qui assure l’équilibre entre les performances et la capacité.

Les espaces de stockage directs fournissent une mise en cache intégrée, permanente, en temps réel, en lecture et en écriture côté serveur qui optimise les performances de stockage. Le cache doit être dimensionné et configuré pour prendre en charge le jeu de travail de vos applications et charges de travail. Les disques ou les volumes virtuels des espaces de stockage directs sont utilisés en combinaison avec le cache de lecture en mémoire partagé de cluster (CSV) afin d’améliorer les performances Hyper-V, en particulier pour l’accès en entrée sans mise en mémoire tampon aux fichiers de disque dur virtuel (VHD) ou de disque dur virtuel v2 (VHDX) de la charge de travail.

Conception du réseau

La conception du réseau correspond à l’agencement général des composants au sein de l’infrastructure physique et des configurations logiques du réseau. Vous pouvez utiliser les mêmes ports de carte d’interface réseau (NIC) physique pour toutes les combinaisons d’intentions de gestion, de calcul et de réseau de stockage. L’utilisation des mêmes ports de NIC à toutes fins liées à l’intention est appelée configuration de mise en réseau entièrement convergée.

Bien qu’une configuration de réseau entièrement convergée soit prise en charge, la configuration optimale en termes de performances et de fiabilité consiste à utiliser des ports de carte d’interface réseau dédiés à l’intention de stockage. Ainsi, cette architecture de référence fournit des indications sur la manière de déployer un cluster Azure Stack HCI à plusieurs nœuds en utilisant l’architecture de réseau commutée de stockage avec deux ports de carte réseau convergés pour les intentions de gestion et de calcul, et deux ports de carte réseau dédiés à l’intention de stockage. Pour en savoir plus, consultez Considérations relatives au réseau pour les déploiements cloud d’Azure Stack HCI.

Cette architecture nécessite au moins deux nœuds physiques et jusqu’à un maximum de 16 nœuds à l’échelle. Chaque nœud nécessite quatre ports de carte réseau connectés à deux commutateurs ToR (Top-of-Rack). Les deux commutateurs ToR doivent être interconnectés via des liaisons avec groupe d’agrégation de liens multi-châssis (MLAG). Les deux ports de carte réseau utilisés pour le trafic d’intention de stockage doivent prendre en charge l’accès direct à la mémoire directe à distance (RDMA). Ces ports nécessitent une vitesse minimale de liaison de 10 Gbits/s, mais nous vous recommandons une vitesse de 25 Gbits/s ou plus. Les deux ports de carte réseau utilisés pour les intentions de gestion et de calcul sont convergés à l’aide de la technologie d’association incorporée au commutateur (SET). La technologie SET fournit des fonctionnalités de redondance de liaison et d’équilibrage de charge. Ces ports nécessitent une vitesse minimale de liaison de 1 Gbits/s, mais nous vous recommandons une vitesse de 10 Gbits/s ou plus.

Topologie de réseau physique

La topologie de réseau physique suivante montre les connexions physiques réelles entre les nœuds et les composants réseau.

Lors de la conception d’un déploiement Azure Stack HCI commutée de stockage multinœud utilisant cette architecture de base, vous avez besoin des composants suivants :

• Commutateurs doubles ToR :

  • Les commutateurs de réseau ToR doubles sont nécessaires pour assurer la résilience du réseau et pour permettre la maintenance ou l’application de mises à jour du micrologiciel aux commutateurs sans temps d’arrêt. Cette stratégie évite d’avoir un point de défaillance unique (SPoF).

  • Les commutateurs ToR doubles sont utilisés pour le stockage, ou le trafic est-ouest. Ces commutateurs utilisent deux ports Ethernet dédiés qui ont des réseaux locaux virtuels (VLAN) de stockage spécifiques et des classes de trafic de contrôle de flux prioritaire (PFC) qui sont définies pour fournir une communication RDMA sans perte.

  • Ces commutateurs se connectent aux nœuds via des câbles Ethernet.

• Au moins deux nœuds physiques et jusqu’à un maximum de 16 nœuds :

  • 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 quatre ports de carte réseau au total : deux ports compatibles RDMA pour le stockage et deux ports de carte réseau pour la gestion et le trafic de calcul.

  • Le stockage utilise les deux ports de carte réseau compatibles RDMA dédiés qui se connectent avec un chemin d’accès à chacun des deux commutateurs ToR. Cette approche offre une redondance des chemins de liaison et une bande passante dédiée et prioritaire pour le trafic de stockage SMB Direct.

  • La gestion et le calcul utilisent deux ports de carte réseau qui fournissent un chemin d’accès à chacun des deux commutateurs ToR pour la redondance de chemin de liaison.

• Connectivité externe :

  • Les commutateurs ToR doubles se connectent au réseau externe, par exemple, votre réseau local d’entreprise interne, pour fournir l’accès aux URL sortantes requises à l’aide de votre appareil réseau en périphérie. Cet appareil peut être un pare-feu ou un routeur. Ces commutateurs acheminent le trafic entrant et sortant du cluster Azure Stack HCI ou trafic nord-sud.

  • La connectivité du trafic nord-sud externe prend en charge l’intention de gestion du cluster et les intentions de calcul. Pour ce faire, on utilise deux ports de commutation et deux ports de carte réseau par nœud, qui sont convergés au moyen de la technologie d’association incorporée au commutateur (SET) et d’un commutateur virtuel dans Hyper-V pour garantir la résilience. Ces composants fournissent une connectivité externe aux machines virtuelles Azure Arc et aux autres ressources de charge de travail déployées dans les réseaux logiques créés dans le Gestionnaire de ressources à travers le portail Azure, l’interface de ligne de commande ou des modèles IaC.

Topologie de réseau logique

La topologie logique du réseau fournit une vue d’ensemble de la manière dont les données du réseau circulent entre les appareils, indépendamment de leurs connexions physiques.

La configuration logique de cette architecture de base de commutation de stockage à plusieurs nœuds pour Azure Stack HCI est résumée ci-dessous :

• Commutateurs doubles ToR :

  • Avant de déployer le cluster, les deux commutateurs réseau ToR doivent être configurés avec les ID de réseau local virtuel requis, les paramètres d’unité de transmission maximale et la configuration de pontage du centre de données pour les ports de gestion, de calcul et de stockage. Pour en savoir plus, consultez Exigences liées aux réseaux physiques pour Azure Stack HCI, ou demandez de l’aide à votre fournisseur de matériel de commutation ou à votre partenaire SI.

• Azure Stack HCI utilise l’approche Network ATC pour appliquer l’automatisation du réseau et la configuration réseau basée sur l’intention.

  • 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 sur la 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 d’association SET convergée, 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 d’une association SET pour les intentions de calcul et de gestion.

• Trafic du stockage :

  • Les nœuds physiques communiquent entre eux à l’aide de deux ports de carte réseau dédiés connectés aux commutateurs ToR pour fournir une bande passante et une résilience élevées pour le trafic de stockage.

  • Les ports de stockage SMB1 et SMB2 se connectent à deux réseaux distincts non routables (ou couche 2). Chaque réseau possède un ID de réseau local virtuel (VLAN) spécifique qui doit correspondre à la configuration des ports de commutation sur les ID de réseau local virtuel (VLAN) de stockage par défaut : 711 et 712 des commutateurs ToR.

  • Il n’existe aucune passerelle par défaut configurée sur les deux 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 des espaces de stockage directs 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 fournit 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.

Exigences concernant les commutateurs réseau

Vos commutateurs Ethernet doivent respecter les différentes spécifications requises par Azure Stack HCI et définies par l’Institute of Electrical and Electronics Engineers Standards Association (IEEE SA). Par exemple, pour les déploiements commutés de stockage à plusieurs nœuds, le réseau de stockage est utilisé pour RDMA via RoCE v2 ou iWARP. Ce processus nécessite le PFC, norme IEEE 802.1Qbb, pour garantir une communication sans perte pour la classe de trafic de stockage. Vos commutateurs ToR doivent prendre en charge la norme IEEE 802.1Q pour les réseaux locaux virtuels et la norme IEEE 802.1AB pour le protocole LLDP (Link Layer Discovery Protocol).

Si vous envisagez d’utiliser des commutateurs réseau existants pour un déploiement Azure Stack HCI, revoyez la liste des normes et spécifications IEEE obligatoires que les commutateurs réseau et la configuration doivent fournir. Lors de l’achat de nouveaux commutateurs réseau, contactez votre fournisseur pour vous assurer que les appareils répondent aux exigences de la spécification IEEE pour Azure Stack HCI, ou consultez la liste des modèles de commutateurs certifiés par les fournisseurs de matériel qui prennent en charge les exigences du réseau Azure Stack HCI.

Exigences relatives aux adresses IP

Dans un déploiement commuté de stockage à plusieurs nœuds, le nombre d’adresses IP nécessaires augmente avec l’ajout de chaque nœud physique, jusqu’à un maximum de 16 nœuds au sein d’un seul cluster. Par exemple, pour déployer une configuration commutée de stockage à deux nœuds d’Azure Stack HCI, l’infrastructure de cluster nécessite un minimum de 11 adresses IP à allouer. D’autres adresses IP sont requises si vous utilisez la microsegmentation ou la mise en réseau définie par logiciel. Pour en savoir plus, consultez Examiner les exigences en matière d’adresse IP du modèle de référence de stockage à deux 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 de déployer AKS sur Azure Stack HCI, consultez AKS activé par les exigences du réseau Azure Arc.

Surveillance

Pour améliorer la surveillance et les alertes, activez Monitor Insights sur Azure Stack HCI. Insights peut être mis à l’échelle pour surveiller et gérer plusieurs clusters sur site à l’aide d’une expérience cohérente Azure. Insights utilise des compteurs de performances de cluster et des canaux de journaux d’événements pour surveiller les fonctionnalités clés d’Azure Stack HCI. Les journaux d’activité sont collectés par le DCR configuré via Monitor et Log Analytics.

Azure Stack HCI Insights est conçu à l’aide de Monitor et log Analytics, ce qui garantit une solution évolutive toujours à jour et hautement personnalisable. Insights donne accès à des classeurs par défaut avec des métriques de base, ainsi qu’à des classeurs spécialisés créés pour surveiller les fonctionnalités clés d’Azure Stack HCI. Ces composants fournissent une solution de surveillance en temps quasi réel et permettent la création de graphiques, la personnalisation des visualisations par l’agrégation et le filtrage, et la configuration de règles d’alerte personnalisées sur l’état des ressources.

Gestion des mises à jour

Les clusters Azure Stack HCI et les ressources de charge de travail déployées, telles que les machines virtuelles Azure Arc, doivent être mis à jour et patchées régulièrement. En effectuant des mises à jour régulières, vous vous assurez que votre organisation maintient un niveau de sécurité élevé et vous améliorez la fiabilité globale et la facilité d’utilisation de votre patrimoine. Nous vous recommandons d’utiliser des évaluations manuelles automatiques et périodiques pour la découverte et l’application précoces des correctifs de sécurité et des mises à jour du système d’exploitation.

Les mises à jour de l’infrastructure.

Azure Stack HCI est mis à jour en continu pour améliorer l’expérience client et ajouter de nouvelles fonctionnalités. Ce processus est géré par des trains de mise à jour, qui fournissent de nouvelles builds de base tous les trimestres. Les builds de référence sont appliquées aux clusters Azure Stack HCI pour les maintenir à jour. Outre les mises à jour régulières des builds de référence, Azure Stack HCI bénéficie de mises à jour mensuelles concernant la sécurité et la fiabilité du système d’exploitation.

Update Manager est un service Azure que vous pouvez utiliser pour appliquer, afficher et gérer les mises à jour pour Azure Stack HCI. Ce service fournit un mécanisme permettant d’afficher tous les clusters Azure Stack HCI sur l’ensemble de votre infrastructure et des emplacements en périphérie à l’aide du portail Azure pour offrir une expérience de gestion centralisée. Pour plus d’informations, consultez les ressources suivantes :

• À propos des informations de version d’Azure Stack HCI

• Rythme du cycle de vie d’Azure Stack HCI

• Consulter les phases de mise à jour d’Azure Stack HCI

• Utiliser le gestionnaire de mise à jour Azure pour mettre à jour Azure Stack HCI

Il est important de vérifier régulièrement, par exemple tous les trois à six mois, si de nouvelles mises à jour des pilotes et des microprogrammes sont disponibles. Si vous utilisez une version de catégorie de solution Premier pour votre matériel Azure Stack HCI, les mises à jour du package d’extension du générateur de solutions sont intégrées au gestionnaire de mise à jour pour offrir une expérience simplifiée en la matière. Si vous utilisez des nœuds validés ou une catégorie de système intégrée, il peut s’avérer nécessaire de télécharger et d’exécuter un package de mise à jour spécifique à l’OEM qui contient les mises à jour du microprogramme et du pilote pour votre matériel. Pour déterminer la façon dont les mises à jour sont fournies pour votre matériel, contactez votre partenaire OEM ou SI pour le matériel.

Mise à jour corrective du SE invité de la charge de travail

Vous pouvez inscrire des machines virtuelles Azure Arc déployées sur Azure Stack HCI à l’aide du gestionnaire de mise à jour Azure (AUM) pour fournir une expérience de gestion unifiée des correctifs au moyen du même mécanisme utilisé pour mettre à jour les nœuds physiques du cluster Azure Stack HCI. Vous pouvez utiliser le gestionnaire de mise à jour Azure pour créer des configurations de maintenance invitée. Ces configurations contrôlent des paramètres tels que le paramètre de redémarrage redémarrage si nécessaire, la planification (dates, heures et options de répétition) et une liste dynamique (abonnement) ou statique des machines virtuelles Azure Arc pour l’étendue. Ces paramètres contrôlent la configuration pour laquelle les correctifs de sécurité du système d’exploitation sont installés à l’intérieur du système d’exploitation invité de votre machine virtuelle de la charge de travail.

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.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Identifiez les points de défaillance potentiels

Chaque architecture est susceptible de connaître des pannes. L’analyse des modes de défaillance permet d’anticiper les défaillances et de se préparer à les atténuer. Le tableau suivant décrit quatre exemples de points de défaillance potentiels dans cette architecture :

Pour plus d’informations, consultez Recommandations pour effectuer une analyse du mode d’échec.

Objectifs de fiabilité

Cette section présente un exemple de scénario. Un client fictif appelé Contoso Manufacturing utilise cette architecture de référence pour déployer Azure Stack HCI. Ils souhaitent satisfaire leurs besoins et déployer et gérer des charges de travail sur site. Contoso Manufacturing s’est fixé un objectif interne de niveau de service (SLO) de 99,8 % sur lequel les parties prenantes de l’entreprise et des applications s’accordent pour leurs services.

• Un SLO de 99,8 % de temps de fonctionnement, ou de disponibilité, se traduit par les périodes suivantes de temps d’arrêt autorisé, ou d’indisponibilité, pour les applications déployées à l’aide des machines virtuelles Azure Arc qui s’exécutent sur Azure Stack HCI :

  • Hebdomadaire : 20 minutes et 10 secondes

  • Mensuelle : 1 heure, 26 minutes, et 56 secondes.

  • Trimestrielle : 4 heures, 20 minutes et 49 secondes

  • Annuelle : 17 heures, 23 minutes et 16 secondes

• Pour répondre aux objectifs de SLO, Contoso Manufacturing met en œuvre le principe de privilège minimum (PoLP) pour limiter le nombre d’administrateurs de cluster Azure Stack HCI à un petit groupe de personnes approuvées et qualifiées. Cette approche permet d’éviter les temps d’arrêt dus à des actions involontaires ou accidentelles effectuées sur les ressources de production. En outre, les journaux d’événements de sécurité pour les contrôleurs de domaine Active Directory Domain Services (AD DS) sur site sont surveillés pour détecter et signaler les modifications d’appartenance aux groupes de comptes d’utilisateur, appelées actions d’ajout et de suppression, pour le groupe d’administrateurs de clusters Azure Stack HCI à l’aide d’une solution de gestion des événements relatifs aux informations de sécurité (SIEM). La surveillance augmente la fiabilité et améliore la sécurité de la solution.

  Pour plus d'informations, veuillez consulter la section Recommandations pour la gestion des identités et des accès.

• Les procédures strictes de contrôle des modifications sont en place pour les systèmes de production de Contoso Manufacturing. Ce processus requiert le test et la validation de toutes les modifications dans un environnement de test représentatif avant leur mise en œuvre dans la production. Toutes les modifications soumises au processus hebdomadaire du comité consultatif des modifications doivent inclure un plan de mise en œuvre détaillé (ou un lien vers le code source), un score de niveau de risque, un plan de restauration complet, des tests et vérifications postérieurs à la publication et des critères de réussite clairs pour qu’une modification puisse être examinée ou approuvée.

  Pour en savoir plus, consultez Recommandations pour des pratiques de déploiement sécurisé.

• Les correctifs de sécurité mensuels et les mises à jour de base trimestrielles sont appliqués aux clusters Azure Stack HCI de production uniquement après leur validation par l’environnement de préproduction. Le gestionnaire de mise à jour et la fonction de mise à jour tenant compte des clusters automatisent le processus de migration en direct des machines virtuelles afin de minimiser les temps d’arrêt des charges de travail critiques pendant les opérations de maintenance mensuelles. Les procédures opérationnelles standard de Contoso Manufacturing exigent que les mises à jour de sécurité, de fiabilité ou de référence soient appliquées à tous les systèmes de production dans un délai de quatre semaines à compter de leur date de publication. Sans cette stratégie, les systèmes de production ne peuvent pas rester à jour avec les mises à jour mensuelles du système d’exploitation et de sécurité. Les systèmes obsolètes affectent négativement la fiabilité et la sécurité de la plateforme.

  Pour en savoir plus, consultez Recommandations pour l’établissement d’une base de référence de sécurité.

• Contoso Manufacturing implémente des sauvegardes quotidiennes, hebdomadaires et mensuelles pour conserver les 6 derniers jours de sauvegardes quotidiennes (du lundi au samedi), les 3 dernières sauvegardes hebdomadaires (chaque dimanche) et 3 sauvegardes mensuelles, le dimanche de la semaine 4 étant conservé pour devenir les sauvegardes du mois 1, du mois 2 et du mois 3 à l’aide d’une planification basée sur un calendrier dynamique documenté et auditable. Cette approche répond aux exigences de Contoso Manufacturing en matière d’équilibre entre le nombre de points de récupération des données disponibles et la réduction des coûts du service de stockage de sauvegarde hors site ou dans le cloud.

  Pour en savoir plus, consultez Recommandations pour la conception d’une stratégie de récupération d’urgence.

• Les processus de sauvegarde et de récupération des données sont testés pour chaque système d’entreprise tous les six mois. Cette stratégie permet de s’assurer que les processus de BCDR sont valides et que l’entreprise est protégée en cas de catastrophe dans le centre de données ou de cyberincident.

  Pour en savoir plus, consultez Recommandations pour la conception d’une stratégie de test de fiabilité.

• Les processus et procédures opérationnels décrits précédemment dans l’article, ainsi que les recommandations du guide du service Well-Architected Framework pour Azure Stack HCI, permettent à Contoso Manufacturing d’atteindre son objectif de SLO de 99,8 % et de dimensionner et gérer efficacement Azure Stack HCI et les déploiements de charges de travail sur plusieurs sites de fabrication répartis dans le monde entier.

  Pour plus d’informations, consultez Recommandations pour définir des objectifs de fiabilité.

Redondance

Considérons une charge de travail que vous déployez sur un seul cluster Azure Stack HCI en tant que déploiement localement redondant. Le cluster fournit une haute disponibilité au niveau de la plateforme, mais vous devez le déployer dans un seul rack. Pour les cas d’usage stratégiques pour critiques pour l’entreprise, nous vous recommandons de déployer plusieurs instances d’une charge de travail ou d’un service sur deux clusters Azure Stack HCI distincts, idéalement dans des emplacements physiques séparés.

Utilisez des modèles standard à haute disponibilité pour les charges de travail qui fournissent une réplication active/passive, une réplication synchrone ou asynchrone, comme SQL Server Always On. Vous pouvez également utiliser une technologie d’équilibrage de charge réseau (NLB) externe qui achemine les requêtes utilisateur sur plusieurs instances de charge de travail qui s’exécutent sur des clusters Azure Stack HCI que vous déployez dans des emplacements physiques séparés. Envisagez l’utilisation d’un appareil NLB externe partenaire. Vous pouvez également évaluer les options d’équilibrage de charge qui prennent en charge le routage du trafic pour les services hybrides et sur site, telles qu’une instance Azure Application Gateway qui utilise Azure ExpressRoute ou un tunnel VPN pour se connecter à un service sur site.

Pour en savoir plus, consultez Recommandations pour la conception de la redondance.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Éléments de sécurité à prendre en compte :

• Une base sécurisée pour la plateforme Azure Stack HCI : Azure Stack HCI est un produit sécurisé par défaut qui utilise des composants matériels validés avec un module de plateforme sécurisé TPM, un microprogramme UEFI et un démarrage sécurisé pour créer une base sécurisée pour la plateforme Azure Stack HCI et la sécurité de la charge de travail. Lorsqu’il est déployé avec les paramètres de sécurité par défaut, Azure Stack HCI comprend Windows Defender Application Control, Credential Guard et BitLocker activés. Pour simplifier la délégation des autorisations à l’aide du principe du moindre privilège, utilisez des rôles de contrôle d’accès en fonction du rôle (RBAC) intégrés Azure Stack HCI, tels qu’administrateur Azure Stack HCI pour les administrateurs de plateforme et Contributeur de machine virtuelle Azure Stack HCI ou Lecteur de machine virtuelle Azure Stack HCI pour les opérateurs de charge de travail.

• Paramètres de sécurité par défaut : la sécurité par défaut d’Azure Stack HCI applique les paramètres de sécurité par défaut pour votre cluster Azure Stack HCI pendant le déploiement et permet au contrôle de dérive de conserver les nœuds dans un état correct connu. Vous pouvez utiliser les paramètres de sécurité par défaut pour gérer la sécurité du cluster, le contrôle de dérive et les paramètres de serveur principal sécurisés sur votre cluster.

• Journaux d’événements de sécurité : le transfert du Syslog Azure Stack HCI s’intègre aux solutions de surveillance de la sécurité en récupérant les journaux d’événements de sécurité pertinents pour agréger et stocker des événements pour la conservation dans votre propre plateforme SIEM.

• Protection contre les menaces et les vulnérabilités : Defender pour le cloud protège vos clusters Azure Stack HCI contre diverses menaces et vulnérabilités. Ce service permet d’améliorer la posture de sécurité de votre environnement Azure Stack HCI et de vous protéger contre les menaces existantes et en constante évolution.

• Détection et correction des menaces : Microsoft Advanced Threat Analytics détecte et corrige les menaces, notamment celles visant AD DS, qui fournissent des services d’authentification aux nœuds de cluster Azure Stack HCI et à leurs charges de travail de machine virtuelle Windows Server.

• Isolation du réseau : isoler les réseaux si nécessaire. Ainsi, vous pouvez provisionner plusieurs réseaux logiques qui utilisent des réseaux locaux virtuels distincts et des plages d’adresses réseau. Si vous adoptez cette approche, assurez-vous que le réseau de gestion peut atteindre chaque réseau logique et réseau local virtuel afin que les nœuds de cluster Azure Stack HCI puissent communiquer avec les réseaux VLAN via les commutateurs ToR ou les passerelles. Cette configuration est nécessaire pour la gestion de la charge de travail, par exemple pour permettre aux agents de gestion de l’infrastructure de communiquer avec le SE invité de la charge de travail.

  Pour en savoir plus, consultez Recommandations pour la création d’une stratégie de segmentation.

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 :

• Modèle de facturation de type cloud pour les licences : la tarification Azure Stack HCI suit le modèle de facturation à abonnement mensuel, avec un taux forfaitaire par cœur de processeur physique dans un cluster Azure Stack HCI. Des frais d’utilisation supplémentaires s’appliquent si vous utilisez d’autres services Azure. Si vous possédez des licences de base sur site pour l’édition Windows Server Datacenter avec Software Assurance active, vous pouvez choisir de les échanger pour activer les frais d’abonnement aux clusters HCI Azure Stack et aux machines virtuelles Windows Server.

• Mise à jour corrective automatique d’un invité de machine virtuelle pour les machines virtuelles Azure Arc : cette fonctionnalité permet de réduire la surcharge liée aux correctifs manuels et les coûts de maintenance associés. Cette action permet non seulement de rendre le système plus sûr, mais aussi d’optimiser l’allocation des ressources et de contribuer à la rentabilité globale.

• Consolidation de la supervision des coûts : pour consolider les coûts de supervision, utilisez Azure Stack HCI Insights et appliquer un correctif à l’aide du gestionnaire de mise à jour pour Azure Stack HCI. Insights utilise Monitor pour fournir des métriques et des fonctionnalités d’alerte enrichies. Le composant de gestion du cycle de vie d’Azure Stack HCI s’intègre au gestionnaire de mise à jour pour simplifier la tâche de mise à jour de vos clusters en consolidant les flux de travail de mise à jour pour les différents composants en une seule expérience. Utilisez Monitor et le gestionnaire de mise à jour pour optimiser l’allocation des ressources et contribuer à la rentabilité globale.

  Pour en savoir plus, consultez Recommandations pour optimiser le temps du personnel.

• Capacité de charge de travail initiale et croissance : lorsque vous planifiez votre déploiement Azure Stack HCI, tenez compte de votre capacité de charge de travail initiale, des exigences en matière de résilience et des considérations de croissance future. Tentez de déterminer si une architecture sans commutateur de stockage à deux ou trois nœuds pourrait réduire les coût, par exemple en supprimant la nécessité d’acheter des commutateurs réseau de classe de stockage. L’achat de commutateurs réseau de classe de stockage supplémentaires peut se révéler un élément coûteux des nouveaux déploiements de clusters Azure Stack HCI. En revanche, vous pouvez utiliser les commutateurs existants pour les réseaux de gestion et de calcul, ce qui simplifie l’infrastructure. Si la capacité de votre charge de travail et vos besoins en matière de résilience ne dépassent pas une configuration à trois nœuds, envisagez d’utiliser les commutateurs existants pour les réseaux de gestion et de calcul, et l’architecture sans commutateur de stockage à trois nœuds pour déployer Azure Stack HCI.

  Pour en savoir plus, consultez Recommandations pour optimiser les coûts des composants.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

Les considérations relatives à l’excellence opérationnelle sont les suivantes :

• Provisionnement simplifié et expérience de gestion intégrée à Azure : le déploiement basé sur le cloud dans Azure fournit une interface pilotée par un assistant qui vous montre comment créer un cluster Azure Stack HCI. De même, Azure simplifie le processus de gestion des clusters Azure Stack HCI et des machines virtuelles Azure Arc. Vous pouvez automatiser le déploiement basé sur le portail du cluster Azure Stack HCI à l’aide du modèle ARM. Ce modèle assure la cohérence et l’automatisation du déploiement d’Azure Stack HCI à l’échelle, en particulier dans les scénarios en périphérie tels que les magasins de vente au détail ou les sites de fabrication qui nécessitent un cluster Azure Stack HCI pour exécuter des charges de travail critiques pour l’entreprise.

• Fonctionnalités d’automatisation pour des machines virtuelles : Azure Stack HCI fournit un large éventail de fonctionnalités d’automatisation pour la gestion des charges de travail, telles que les machines virtuelles Azure Arc, avec le déploiement automatisé de machines virtuelles Azure Arc à l’aide de l’interface de ligne de commande Azure, ARM ou le modèleBicep, avec les mises à jour du système d’exploitation des machines virtuelles en utilisant l’extension Azure Arc pour les mises à jour et le gestionnaire de mise à jour Azure pour mettre à jour chaque cluster Azure Stack HCI. Azure Stack HCI prend également en charge la gestion des machines virtuelles Azure Arc à l’aide de l’interface de ligne de commande Azure et des machines virtuelles non-Azure Arc à l’aide de Windows PowerShell. Vous pouvez exécuter les commandes d’interface de ligne de commande Azure localement à partir de l’un des serveurs Azure Stack HCI ou à distance à partir d’un ordinateur de gestion. L’intégration avec Azure Automation et Azure Arc facilite un large éventail de scénarios d’automatisation supplémentaires pour les charges de travail de machines virtuelles via les extensions Azure Arc.

  Pour en savoir plus, consultez Recommandations pour l’utilisation de technologies IaC.

• Fonctionnalités d’automatisation pour les conteneurs sur AKS : Azure Stack HCI fournit un large éventail de fonctionnalités d’automatisation pour la gestion des charges de travail, telles que les conteneurs, sur AKS. Vous pouvez automatiser le déploiement de clusters AKS à l’aide de l’interface de ligne de commande Azure. Mettez à jour les clusters de charge de travail AKS à l’aide de l’extension Azure Arc pour les mises à jour Kubernetes. Vous pouvez également gérer AKS avec Azure Arc à l’aide de l’interface de ligne de commande Azure. Vous pouvez exécuter les commandes d’interface de ligne de commande Azure localement à partir de l’un des serveurs Azure Stack HCI ou à distance à partir d’un ordinateur de gestion. Intégrez Azure Arc pour un large éventail de scénarios d’automatisation supplémentaires pour les charges de travail conteneurisées via des extensions Azure Arc.

  Pour en savoir plus, consultez Recommandations pour activer l’automatisation.

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 :

• Performances de stockage d’une charge de travail : envisagez d’utiliser l’outil DiskSpd pour tester les fonctionnalités de performances de stockage d’une charge de travail d’un cluster Azure Stack HCI. Vous pouvez utiliser l’outil VMFleet pour générer la charge et mesurer les performances d’un sous-système de stockage. Déterminez si vous devez utiliser VMFleet pour mesurer les performances du sous-système de stockage.

  • Avant de déployer des charges de travail de production, nous vous recommandons d’établir une base de référence pour les performances de vos clusters Azure Stack HCI. DiskSpd utilise différents paramètres de ligne de commande qui permettent aux administrateurs de tester les performances de stockage du cluster. La fonction principale de DiskSpd est d’effectuer des opérations de lecture et d’écriture et de fournir des mesures de performance, telles que la latence, le débit et les IOP.

    Pour en savoir plus, consultez Recommandations pour les tests des performances.

• Résilience du stockage d’une charge de travail : tenez compte des avantages de la résilience du stockage, de l’efficacité de l’utilisation (ou de la capacité) et des performances. La planification des volumes Azure Stack HCI inclut l’identification de l’équilibre optimal entre la résilience, l’efficacité de l’utilisation et les performances. Il peut s’avérer difficile de parvenir à un équilibre optimal, car l’optimisation de l’une de ces caractéristiques a généralement un effet négatif sur une ou plusieurs autres. L’augmentation de la résilience réduit la capacité utile. Par conséquent, les performances peuvent varier en fonction du type de résilience sélectionné. Lorsque la résilience et les performances sont prioritaires et que vous utilisez trois nœuds ou plus, la configuration de stockage par défaut utilise la mise en miroir tridirectionnelle pour les volumes d’infrastructure et les volumes utilisateur.

  Pour en savoir plus, consultez Recommandations relatives à la planification de la capacité.

• Optimisation des performances réseau : envisagez l’optimisation des performances réseau. Dans le cadre de votre conception, veillez à inclure l’allocation de bande passante du trafic réseau projetée lors de la détermination de la configuration de votre matériel réseau optimal.

  • Pour optimiser les performances de calcul dans Azure Stack HCI, vous pouvez utiliser l’accélération GPU. L’accélération GPU est avantageuse pour les charges de travail d’IA ou de machine learning à haute performance qui impliquent des insights de données ou des inférences. Ces charges de travail nécessitent un déploiement à des emplacements en périphérie en raison de considérations telles que la gravité des données ou les exigences de sécurité. Dans un déploiement hybride ou un déploiement sur site, il est important de prendre en compte les exigences de performances de votre charge de travail, y compris les GPU. Cette approche vous aide à sélectionner les services appropriés lorsque vous concevez et procurez vos clusters Azure Stack HCI.

    Pour en savoir plus, consultez Recommandations pour sélectionner les services appropriés.

Déployer ce scénario

La section suivante fournit une liste d’exemples de tâches de haut niveau ou de flux de travail typiques utilisés pour déployer Azure Stack HCI, y compris les tâches requises et les considérations. Cette liste de flux de travail n’est donnée qu’à titre d’exemple. Il ne s’agit pas d’une liste exhaustive de toutes les actions requises, qui peuvent varier en fonction des exigences organisationnelles, géographiques ou propres à un projet.

Scénario : un projet ou un cas d’utilisation exige le déploiement d’une solution de cloud hybride sur site ou en périphérie afin de fournir des capacités locales de calcul pour le traitement des données et la volonté d’utiliser des expériences de gestion et de facturation cohérentes avec Azure. Des détails supplémentaires sont fournis dans la section cas d’usage potentiels de cet article. Les étapes suivantes présument qu’Azure Stack HCI est la solution de plateforme d’infrastructure choisie pour le projet.

1. Collectez les exigences relatives à la charge de travail et aux cas d’utilisation auprès des parties prenantes concernées. Cette stratégie permet de confirmer que les caractéristiques et les fonctionnalités d’Azure Stack HCI répondent aux exigences en matière de mise à l’échelle de la charge de travail, de performances et de fonctionnalités. Ce processus de vérification doit inclure la compréhension de l’échelle ou de la taille de la charge de travail, et des fonctionnalités requises telles que les machines virtuelles Azure Arc, AKS, Azure Virtual Desktop, ou encore les services de données avec Azure Arc ou Machine Learning service avec Azure Arc. Les valeurs RTO et RPO (fiabilité) de la charge de travail et d’autres exigences non fonctionnelles (extensibilité des performances/de la charge) doivent être documentées dans le cadre de cette étape de collecte des exigences.

2. Examinez la sortie du dimensionneur d’Azure Stack HCI pour la solution de partenaire matériel recommandée. Cette sortie inclut des détails sur la marque et le modèle du serveur physique recommandé, le nombre de nœuds physiques et les spécifications de l’unité centrale, de la mémoire et de la configuration de stockage de chaque nœud physique requis pour déployer et exécuter vos charges de travail.

3. Utilisez l’outil de dimensionnement Azure Stack HCI pour créer un nouveau projet qui modélise le type et l’échelle de la charge de travail. Ce projet inclut la taille et le nombre de machines virtuelles et leurs besoins en termes de stockage. Ces informations sont saisies en même temps que les choix relatifs au type de système, à la famille de CPU préférée et à vos exigences en matière de résilience pour la haute disponibilité et la tolérance aux pannes de stockage, comme expliqué dans la section précédente Choix de conception de cluster.

4. Examinez la sortie du dimensionneur d’Azure Stack HCI pour la solution de partenaire matériel recommandée. Cette solution inclut des détails sur le matériel du serveur physique recommandé (marque et modèle), le nombre de nœuds physiques et les spécifications de l’unité centrale, de la mémoire et de la configuration de stockage de chaque nœud physique requis pour déployer et exécuter vos charges de travail.

5. Contactez l’OEM ou le partenaire SI pour vérifier l’adéquation de la version recommandée du matériel avec vos exigences en matière de charge de travail. S’ils sont disponibles, utilisez des outils de dimensionnement propres à l’OEM pour déterminer les exigences de dimensionnement matérielle spécifiques à l’OEM pour les charges de travail prévues. Cette étape inclut généralement des discussions avec le partenaire OEM ou SI sur les aspects commerciaux de la solution. Ces aspects incluent les devis, la disponibilité du matériel, les délais et tous les services professionnels ou à valeur ajoutée fournis par le partenaire pour accélérer votre projet ou vos résultats métier.

6. Déployez deux commutateurs ToR pour l’intégration réseau. Pour les solutions à haute disponibilité, les clusters HCI nécessitent le déploiement de deux commutateurs ToR. Chaque nœud physique nécessite quatre cartes réseau, dont deux compatibles RDMA, qui fournissent deux liaisons entre chaque nœud et les deux commutateurs ToR. Deux cartes réseau, chacune connectée à un commutateur, sont convergées pour la connectivité nord-sud sortante pour les réseaux de calcul et de gestion. Les deux autres cartes réseau compatibles RDMA sont dédiées au trafic de stockage est-ouest. Si vous envisagez d’utiliser des commutateurs réseau existants, veillez à ce que la marque et le modèle de ces derniers figurent dans la liste approuvée des commutateurs réseau pris en charge par Azure Stack HCI.

7. Collaborez avec le partenaire OEM ou SI pour le matériel pour organiser la livraison de ce dernier. Le partenaire SI ou vos employés sont alors tenus d’intégrer le matériel dans votre centre de données sur site ou dans votre site en périphérie, notamment par la mise en rack et l’empilage du matériel, le réseau physique et le câblage de l’unité d’alimentation pour les nœuds physiques.

8. Effectuez le déploiement du cluster Azure Stack HCI. Selon la version de la solution choisie (solution Premier, système intégré ou nœuds validés), le partenaire matériel, le partenaire SI ou vos employés peuvent déployer le logiciel Azure Stack HCI. Cette étape commence par l’intégration des nœuds physiques du système d’exploitation Azure Stack HCI dans les serveurs compatibles avec Azure Arc, puis par le lancement du processus de déploiement cloud d’Azure Stack HCI. Les clients et les partenaires peuvent formuler une demande d’assistance directement auprès de Microsoft dans le portail Azure en sélectionnant l’icône Assistance + Dépannage ou en contactant leur OEM matériel ou leur partenaire SI, en fonction de la nature de la demande et de la catégorie de la solution matérielle.

   Conseil

   L’implémentation de référence du cluster Azure Stack HCI 23H2 montre comment déployer un déploiement à plusieurs serveurs commuté d’Azure Stack HCI à l’aide d’un modèle ARM et d’un fichier de paramètres. L’exemple Bicep montre également comment utiliser un modèle Bicep pour déployer un cluster Azure Stack HCI et ses ressources requises au préalable.

9. Déployer des charges de travail hautement disponibles sur Azure Stack HCI à l’aide du portail Azure, de l’interface de ligne de commande ou de modèles ARM + Azure Arc pour l’automatisation. Utilisez la ressource d’emplacement personnalisé du nouveau cluster HCI comme région cible lorsque vous déployez des ressources de charge de travail telles que des machines virtuelles Azure Arc, AKS, des hôtes de session Azure Virtual Desktop ou d’autres services avec Azure Arc que vous pouvez activer via les extensions AKS et la conteneurisation sur Azure Stack HCI.

10. Installez des mises à jour mensuelles pour améliorer la sécurité et la fiabilité de la plateforme. Pour maintenir vos clusters Azure Stack HCI à jour, il est important d’installer les mises à jour des logiciels Microsoft et celles des pilotes et micrologiciels de l’OEM. Ces mises à jour améliorent la sécurité et la fiabilité de la plateforme. Update Manager applique les mises à jour et fournit une solution centralisée et évolutive pour installer des mises à jour sur un seul cluster ou plusieurs clusters. Vérifiez auprès de votre partenaire OEM le processus d’installation des mises à jour des pilotes et des microprogrammes, car il peut varier en fonction du type de catégorie de solution matérielle que vous avez choisi (solution Premier, système intégré ou nœuds validés). Pour en savoir plus, consultez Mises à jour de l’infrastructure.

Ressources associées

• Conception d’une architecture hybride
• Options hybrides Azure
• Automatisation 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 de Monitor
• Vue d’ensemble de Change Tracking and Inventory
• Présentation d’Update Manager
• Présentation des services de données avec Azure Arc
• Que sont les serveurs avec Azure Arc ?
• Qu’est-ce que le service Sauvegarde ?

Documentation produit pour plus d’informations sur des services Azure spécifiques :

• Azure Stack HCI
• Azure Arc
• Key Vault
• Stockage Blob Azure
• Surveiller
• Azure Policy
• Azure Container Registry
• Defender pour le cloud
• 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 le machine learning en tout lieu- Blog de la communauté technique
• Exploiter le machine learning partout avec AKS et le machine learning avec Azure 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
• Présentation de la cible de calcul Kubernetes dans le machine learning
• Conserver vos machines virtuelles mises à jour
• Protégez les paramètres de votre machine virtuelle avec la Automation state configuration
• Protéger vos machines virtuelles grâce à la sauvegarde