Architecture de référence de référence locale Azure

Azure Local

Azure Arc

Azure Key Vault

Azure Monitor

Microsoft Defender for Cloud

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 de l’infrastructure Azure Local 2311 et ultérieure, afin de fournir une plateforme fiable pour les 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 machines physiques qui fournissent des fonctionnalités de calcul, de stockage et de mise en réseau locales. Il explique également comment utiliser des services Azure pour simplifier la gestion quotidienne d’Azure Local pour les opérations à grande échelle.

Pour plus d’informations sur les modèles d’architecture de charge de travail optimisés pour s’exécuter sur Azure Local, consultez le contenu situé dans la charges de travail locales Azure menu de navigation.

Cette architecture est un point de départ pour utiliser la conception réseau commutée de stockage pour déployer une instance locale Azure à plusieurs nœuds. Les applications de charge de travail déployées sur une instance locale Azure 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 haute disponibilité de tous les services de charge de travail critiques et disposer de contrôles de continuité d’activité et de récupération d’urgence appropriés en place. Ces contrôles BCDR incluent des sauvegardes régulières et des fonctionnalités de basculement pour la reprise après sinistre. Pour vous concentrer sur la plateforme d’infrastructure hyperconvergée (HCI), ces aspects de conception de charge de travail sont intentionnellement exclus de cet article.

Pour plus d’informations sur les instructions et les recommandations relatives aux cinq piliers d’Azure Well-Architected Framework, consultez le guide de service Azure Local Well-Architected Framework.

Disposition de l’article

Architecture	Décisions de conception	Approche de Well-Architected Framework
▪ architecture ▪ composants ▪ Ressources de plateforme ▪ Ressources de prise en charge de la plateforme ▪ Détails du scénario ▪ Utiliser Azure Arc avec Azure Local ▪ Tirer parti de la configuration de sécurité par défaut d’Azure Local ▪ cas d’usage potentiels ▪ Déployer ce scénario	▪ choix de conception de cluster ▪ disques physiques ▪ Conception du réseau ▪ Surveillance ▪ Gestion des mises à jour	▪ Fiabilité ▪ Sécurité ▪ Optimisation des coûts ▪ Excellence opérationnelle ▪ Efficacité du niveau de performance

Tip

Ce modèle local Azure montre comment utiliser un modèle Azure Resource Manager (modèle ARM) et un fichier de paramètres pour déployer un déploiement multiserveur commuté d’Azure Local. L’exemple Bicep montre également comment utiliser un modèle Bicep pour déployer une instance locale Azure et ses ressources requises.

Architecture

Le diagramme d’architecture montre un environnement local Azure local connecté à Azure. L’environnement local contient un cluster local Azure à plusieurs nœuds. Le cluster est connecté à des commutateurs ToR doubles pour la connectivité réseau. L’environnement Azure affiche plusieurs services Azure qui s’intègrent à Azure Local. Ces services incluent Azure Arc, Azure Monitor, Azure Key Vault, Azure Policy, Microsoft Defender pour cloud, Azure Update Manager, Sauvegarde Azure et Azure Site Recovery.

Pour plus d’informations, consultez Ressources associées.

Components

Cette architecture se compose de matériel de serveur physique que vous pouvez utiliser pour déployer des instances locales Azure dans des emplacements locaux ou edge. Pour améliorer les fonctionnalités de plateforme, Azure Local s’intègre à Azure Arc et à d’autres services Azure qui fournissent des ressources de prise en charge. Azure Local fournit une plateforme résiliente pour déployer, gérer et exploiter des applications utilisateur ou des systèmes métier. Les ressources et services de plateforme sont décrits dans les sections suivantes.

Ressources de plateforme

• Azure Local est une solution HCI déployée localement ou dans des emplacements de périphérie et qui utilise une infrastructure matérielle et réseau de serveur physique. Azure Local fournit 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 instances locales Azure peuvent passer d’un déploiement à un seul ordinateur à un maximum de 16 machines physiques à l’aide de catégories de matériel validées, intégrées ou premium que fournissent les partenaires OEM (Fabricant d’équipement d’origine). Dans cette architecture, Azure Local fournit la plateforme principale permettant d’héberger et de gérer des charges de travail virtualisées et conteneurisées localement ou en périphérie.

• Azure Arc est un service cloud qui étend le modèle de gestion basé sur Resource Manager à Azure Local et à d’autres emplacements non-Azure. Azure Arc utilise Azure comme plan de contrôle et de gestion pour permettre la gestion de différentes ressources telles que des machines virtuelles, des clusters Kubernetes et des données conteneurisées et des services Machine Learning. Dans cette architecture, Azure Arc permet la gestion centralisée et la gouvernance des ressources déployées sur Azure Local via le plan de contrôle Azure.

• 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 tout ce que vous souhaitez 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. Dans cette architecture, Key Vault sécurise les informations sensibles et les informations d’identification utilisées par les charges de travail et les composants d’infrastructure sur Azure Local.

• Le témoin cloud est une fonctionnalité qui utilise le stockage Azure pour servir de quorum de basculement de cluster. Azure Local (deux instances de machine uniquement) utilise un témoin cloud comme quorum pour le vote, ce qui garantit la haute disponibilité pour le cluster. Le compte de stockage et la configuration du témoin sont créés pendant le processus de déploiement du cloud local Azure. Dans cette architecture, le témoin cloud fournit un quorum pour les clusters à deux nœuds afin de maintenir la haute disponibilité.

• Azure Update Manager est un service unifié conçu pour gérer et régir les mises à jour pour Azure Local. Vous pouvez utiliser Update Manager pour gérer les charges de travail déployées sur Azure Local, y compris la conformité des mises à jour du système d’exploitation invité pour les machines virtuelles Windows et Linux qui peuvent être activées à l’aide d’Azure Policy. Cette approche unifiée centralise la gestion des correctifs dans les environnements Azure, locaux et d’autres plateformes cloud via un tableau de bord unique. Dans cette architecture, Update Manager fournit une gestion centralisée des mises à jour et des correctifs pour l’infrastructure et les charges de travail.

Ressources de prise en charge de la plateforme

• Azure Monitor est un service cloud permettant de collecter, d’analyser et d’agir sur les journaux de diagnostic et les données de télémétrie à partir de charges de travail cloud et locales. Vous pouvez utiliser Azure Monitor pour optimiser la disponibilité et les performances de vos applications et services via une solution de supervision. Déployez Insights pour Azure Local pour simplifier la création de la règle de collecte de données Azure Monitor (DCR) et activer la supervision des instances locales Azure. Dans cette architecture, Azure Monitor fournit des analyses et des données de télémétrie pour les clusters et charges de travail locaux Azure.

• Azure Policy est un service qui évalue les ressources Azure et locales. Azure Policy évalue les ressources via l’intégration à Azure Arc à l’aide des propriétés de ces ressources aux règles métier, appelées définitions de stratégie, pour déterminer la conformité ou les fonctionnalités que vous pouvez utiliser pour appliquer la configuration d’invité de machine virtuelle via les paramètres de stratégie. Dans cette architecture, Azure Policy fournit une fonctionnalité d’audit et de conformité pour la configuration de sécurité du système d’exploitation des machines locales Azure. Les paramètres sont continuellement appliqués à l’aide du contrôle de dérive.

• Defender pour cloud est un système de gestion de la sécurité de l’infrastructure. Il améliore la posture de sécurité des 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 dans des environnements locaux. Dans cette architecture, Defender pour Cloud fournit une surveillance de la sécurité et une protection contre les menaces pour les charges de travail s’exécutant sur Azure Local.

• Sauvegarde Azure est un service cloud qui fournit une solution sécurisée et économique pour sauvegarder des données et les récupérer à partir du cloud Microsoft. Le serveur de sauvegarde Azure est utilisé pour effectuer la sauvegarde de machines virtuelles déployées sur Azure Local et les stocker dans le service de sauvegarde. Dans cette architecture, Sauvegarde Azure protège les données et active la récupération pour les machines virtuelles hébergées sur Azure Local.

• Azure Site Recovery est un service de reprise après sinistre qui fournit des capacités de continuité d’activité et de reprise après sinistre (BCDR) en permettant aux applications 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 qui s’exécutent sur des serveurs physiques et des machines virtuelles entre leur site principal (local) et un emplacement secondaire (Azure). Dans cette architecture, Site Recovery permet la reprise après sinistre et le basculement pour les charges de travail exécutées sur Azure Local.

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 Local.

Utiliser Azure Arc avec Azure Local

Azure Local s’intègre directement à Azure à l’aide d’Azure Arc pour réduire le coût total de possession (TCO) et la surcharge opérationnelle. Azure Local est déployé et géré via Azure, qui fournit une intégration intégrée d’Azure Arc via le déploiement du composant de pont de ressources Azure Arc. Ce composant est déployé dans le cadre du processus de déploiement cloud d’instance locale Azure. Les machines locales Azure sont inscrites auprès d’Azure Arc pour les serveurs comme prérequis pour démarrer le déploiement cloud de votre instance locale Azure. Pendant le déploiement, les extensions obligatoires sont installées sur chaque ordinateur, comme Lifecycle Manager, Microsoft Edge Device Management et les extensions de télémétrie et de diagnostic. Vous pouvez utiliser Azure Monitor et Log Analytics après le déploiement pour surveiller la solution en activant Insights pour Azure Local. Les mises à jour des fonctionnalités pour Azure Local sont publiées tous les six mois pour améliorer l’expérience client. Les mises à jour pour Azure Local sont contrôlées et gérées à l’aide de Update Manager.

Vous pouvez déployer des ressources de charge de travail telles que des machines virtuelles Azure Arc, AKS avec Azure Arc et des hôtes de session Azure Virtual Desktop qui utilisent le portail Azure en sélectionnant un emplacement personnalisé d’instance locale Azure 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 assurance logicielle active sur vos licences principales Windows Server Datacenter existantes, vous pouvez réduire les coûts en appliquant Azure Hybrid Benefit aux clusters Azure Local, Windows Server VMs et AKS. Cette optimisation permet de gérer efficacement les coûts de ces services.

L’intégration d’Azure et d’Azure Arc étendent les fonctionnalités des charges de travail virtualisées et conteneurisées Azure pour inclure les solutions suivantes :

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

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

• Virtual Desktop pour déployer vos hôtes de session pour les charges de travail Virtual Desktop sur Azure Local (local). 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 en conteneur.

• Azure Container Apps avec Azure Arc activé pour exécuter des applications et des microservices basés sur des conteneurs. Vous pouvez le déployer à l’aide de l’extension Container Apps pour Kubernetes, qui permet l’approvisionnement d’environnements Container Apps connectés. Une fois qu’il est activé sur un cluster AKS, vous pouvez exécuter des services tels qu’Azure Functions. Pour prendre en charge la mise à l’échelle pilotée par les événements, vous pouvez éventuellement installer l’extension Kubernetes Event-Driven Autoscaling (KEDA).

• L'extension Azure Event Grid compatible avec Azure Arc pour Kubernetes pour déployer le répartiteur Event Grid et l’opérateur Event Grid . Ce déploiement permet 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 Local 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 Machine Learning à la 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 locaux Azure, telles que l’automatisation de la configuration du système d’exploitation invité avec les extensions de machine virtuelle locale Azure 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 d’infrastructure en tant que code (IaC).

Tirer parti de la configuration de sécurité par défaut d’Azure Local

La configuration de sécurité par défaut d’Azure Local 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 à distance 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 essentielle dans les environnements qui ont un support informatique limité ou un manque ou des centres de données dédiés. Azure Local 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é local Azure garantit la prise en charge intégrée du démarrage sécurisé, de l’interface UEFI (Unified Extensible Firmware Interface) et du module de plateforme sécurisée (TPM). Utilisez ces technologies en combinaison avec la sécurité basée sur la virtualisation (VBS) pour protéger vos charges de travail sensibles à la sécurité. Vous pouvez utiliser le chiffrement de lecteur BitLocker pour chiffrer les volumes de disque de démarrage et les espaces de stockage direct au repos. Le chiffrement SMB (Server Message Block) fournit un chiffrement automatique du trafic entre les machines physiques du cluster (sur le réseau de stockage) et la signature du trafic SMB entre les machines physiques 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 des machines virtuelles locales Azure dans Defender pour Cloud pour activer l’analytique comportementale basée sur le cloud, la détection et la correction des menaces, les alertes et les rapports. Gérez les machines virtuelles locales Azure dans Azure Arc afin de pouvoir utiliser Azure Policy pour évaluer leur conformité aux réglementations du secteur et aux normes d’entreprise.

Cas d’usage potentiels

Les cas d’usage classiques pour Azure Local incluent l’exécution de charges de travail haute disponibilité dans des emplacements locaux ou edge. Azure Local fournit une plateforme pour répondre aux exigences telles que les fonctionnalités suivantes :

• Fournissez une solution connectée au cloud déployée localement pour répondre aux exigences de souveraineté, de réglementation et de conformité des données ou de latence.

• Déployez et gérez des charges de travail ha-virtualisées ou basées sur des conteneurs déployées dans un emplacement unique ou multiple. Cette fonctionnalité permet aux applications et services critiques pour l’entreprise de fonctionner de manière résiliente, rentable et évolutive.

• Réduisez le TCO en déployant une solution certifiée par Microsoft et ses partenaires OEM matériels. Cette solution utilise un processus de déploiement basé sur le cloud moderne et fournit une expérience de gestion et de supervision centralisée cohérentes avec Azure.

• Fournir une fonctionnalité d’approvisionnement centralisée à l’aide d’Azure et d’Azure Arc. Cette fonctionnalité permet le déploiement de charges de travail à plusieurs emplacements de manière cohérente et sécurisée. Les outils tels que le portail Azure, Azure CLI ou les modèles IaC (modèles ARM, Bicep et Terraform) améliorent l’automatisation et la répétabilité. Cette approche permet un déploiement et une gestion rapides des clusters Azure Kubernetes Service (AKS) pour les charges de travail en conteneur et les machines virtuelles locales Azure pour les charges de travail virtualisées traditionnelles.

• Respectez les exigences strictes en matière de sécurité, de conformité et d’audit. Azure Local est déployé avec une posture de sécurité renforcée configurée par défaut, appelée secure-by-default. Azure Local intègre du matériel certifié, un démarrage sécurisé, un module TPM, VBS, Credential Guard et des stratégies de contrôle d’application appliquées. Azure Local a la possibilité d’intégrer des services de sécurité et de gestion des menaces modernes basés sur le cloud, tels que Microsoft Defender pour Cloud et Microsoft Sentinel. Cette intégration fournit des fonctionnalités de détection et de réponse étendues (XDR) et de gestion des événements d’information de sécurité (SIEM).

Choix de conception de cluster

Comprendre les exigences en matière de performances et de fiabilité des charges de travail. Pour la résilience, il est important de comprendre les attentes de la plateforme et des charges de travail afin de maintenir leur fonctionnement pendant les défaillances de matériel ou de nœuds. Définissez également l’objectif de délai de récupération (RTO) et l’objectif de point de récupération (RPO) pour votre stratégie de récupération. Facteur des exigences de calcul, de mémoire et de stockage pour toutes les charges de travail déployées sur l’instance locale Azure. Plusieurs caractéristiques de la charge de travail affectent le processus décisionnel :

• Fonctionnalités d’architecture de l’unité de traitement centrale (UC), notamment les fonctionnalités de technologie de sécurité matérielle, le nombre de processeurs, la fréquence de gigahertz (GHz) (vitesse) et le nombre de cœurs pour chaque socket processeur.

• Exigences de 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.

• Mémoire de chaque ordinateur, ou quantité de mémoire physique requise pour exécuter la charge de travail.

• Nombre de machines physiques dans l’instance qui sont de 1 à 16 machines à l’échelle. Le nombre maximal de machines physiques est de quatre 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 machines physiques de capacité dans l’instance. Cette stratégie permet de vider les nœuds pour les mises à jour ou la récupération à partir de pannes soudaines telles que les pannes de courant ou les défaillances matérielles.

  • Pour les charges de travail critiques ou stratégiques pour l’entreprise, envisagez de réserver des machines physiques N+2 d’une capacité pour augmenter la résilience. Par exemple, si deux machines physiques de l’instance sont hors connexion, la charge de travail peut rester en ligne. Cette approche offre une résilience pour les scénarios dans lesquels une machine exécutant une charge de travail est hors connexion pendant une procédure de mise à jour planifiée et entraîne la connexion simultanée de deux machines physiques d’instance.

• Résilience, capacité et performances du stockage requises :

  • Résilience: Nous vous recommandons de déployer trois machines physiques ou plus pour activer la mise en miroir tridirectionnel, qui fournit trois copies des données, pour les volumes d’infrastructure et d’utilisateur. La mise en miroir tridirectionnel augmente les performances et la fiabilité maximale pour le stockage.

  • Capacité : La capacité de stockage utilisable totale requise après la tolérance de panne, ou les copies, est prise en compte. Ce nombre est d’environ 33% de l’espace de stockage brut de vos disques de niveau capacité lorsque vous utilisez la mise en miroir tridirectionnel.

  • Performance: Opérations d’entrée/sortie par seconde (IOPS) de la plateforme qui détermine les fonctionnalité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 local Azure, nous vous recommandons d’utiliser l’outil de dimensionnement local Azure et de créer un projet pour dimensionnement de vos instances locales Azure. L’utilisation de l’outil de dimensionnement vous oblige à comprendre vos besoins en charge de travail. Lorsque vous tenez compte du nombre et de la taille des machines virtuelles de charge de travail qui s’exécutent sur votre instance, 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 vous guide à travers des questions relatives au type de système, tel que Solution Premier, Système Intégré, ou Nœud Validé, et aux options de famille de processeurs. Il vous aide également à sélectionner vos exigences de résilience pour l’instance. Pour définir des niveaux de résilience, suivez ces recommandations :

• Réservez un minimum de N+1 machines physiques d’une capacité, ou d’un nœud, sur l’instance. Cette approche garantit que vous pouvez appliquer des mises à jour de solution en drainant et en redémarrant chaque nœud un par un, sans provoquer de temps d’arrêt de la charge de travail.

• Réservez N+2 machines physiques en termes de capacité sur l’instance pour une résilience supplémentaire. Cette option permet au système de résister simultanément à une défaillance de machine lors d’une mise à jour ou d’un autre événement inattendu qui affecte simultanément deux ordinateurs. Il garantit également qu’il existe suffisamment de capacité dans l’instance pour que la charge de travail s’exécute sur les machines en ligne restantes.

Ce scénario nécessite l’utilisation de la mise en miroir tridirectionnel pour les volumes utilisateur, qui est la valeur par défaut pour les instances qui ont trois machines physiques ou plus.

La sortie de l’outil de dimensionnement local Azure est une liste des références SKU de solution matérielle recommandées qui peuvent fournir les exigences de résilience de la charge de travail et de la plateforme requises en fonction des valeurs d’entrée dans le projet sizer. Pour plus d’informations sur les solutions de partenaire matériel OEM disponibles, consultez le catalogue de solutions locales Azure. Pour vous aider à dimensionner correctement les références SKU de solution pour répondre à vos besoins, contactez votre fournisseur de solutions matérielle ou partenaire d’intégration de système (SI) préféré.

Lecteurs de disque physique

espaces de stockage direct prend en charge plusieurs types de disques physiques qui varient en performances et en capacité. Lorsque vous concevez une instance locale Azure, collaborez avec votre partenaire OEM matériel choisi pour déterminer les types de lecteurs de disque physique les plus appropriés pour répondre aux exigences de capacité et de performances de votre charge de travail. Par exemple, il s’agit d’épingler des lecteurs de disque dur (HDD) ou des disques SSD (SSD) et des lecteurs NVMe (Non Volatile Memory Express). Ces lecteurs sont souvent appelés lecteurs flash, ou stockage de mémoire persistante (PMem), qui est appelé mémoire de classe de stockage (SCM).

La fiabilité de la plateforme dépend des performances des dépendances de plateforme 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 telles que des lecteurs NVMe ou des DISQUES 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, mais ne sont pas limitées aux technologies de base de données transactionnelles hautement transactionnelles, aux clusters AKS de production ou à toute charge de travail stratégique ou critique pour l’entreprise qui ont des exigences de stockage à faible latence ou à débit élevé. Utilisez des déploiements flash pour optimiser les performances de stockage. Des configurations entièrement NVMe ou entièrement SSD, en particulier à petite échelle, améliorent l’efficacité du stockage et optimisent les performances, car aucun lecteur n'est utilisé en tant que niveau de cache. Pour plus d’informations, consultez de stockage flash .

Le diagramme montre un cluster à plusieurs nœuds. Chaque nœud a deux cartes réseau pour le stockage et deux pour la gestion et le calcul. Les cartes de stockage se connectent à un réseau de stockage. Les cartes de gestion et de calcul se connectent à un réseau de gestion et de calcul. Sous la couche réseau, le diagramme montre la pile de stockage. Il commence par les disques physiques en bas, qui incluent les disques NVMe dans les niveaux de cache et les disques SSD dans les niveaux de capacité. Au-dessus des disques se trouve le pool de stockage Storage Spaces Direct. La couche suivante de cette section est le système de fichiers ReFS sur un fichier CSV. La couche suivante inclut des disques virtuels pour les machines virtuelles. La couche supérieure affiche deux machines virtuelles, avec une flèche qui indique qu’elles peuvent être migrées en direct entre les nœuds.

Le type de lecteur de disque physique influence les performances de votre stockage de cluster. Le type de lecteur varie en fonction des caractéristiques de performances de chaque type de lecteur et du mécanisme de mise en cache que vous choisissez. Le type de lecteur de disque physique fait partie intégrante de toute conception et configuration d’espaces de stockage direct. Selon les exigences de charge de travail locales Azure et les contraintes budgétaires, vous pouvez choisir d’optimiser les performances, d’optimiserla capacité ou d’implémenter une configuration de type de lecteur mixte qui équilibre les performances et la capacité.

Pour les charges de travail à usage général qui nécessitent un stockage persistant à grande capacité, une configuration de stockage hybride peut fournir le stockage le plus utilisable, comme l’utilisation de disques NVMe ou de disques SSD pour le niveau de cache et les disques DURS pour la capacité. Le compromis est que les lecteurs de rotation ont des performances et des capacités de débit inférieures par rapport aux lecteurs flash. Ces limitations peuvent affecter les performances du stockage si votre charge de travail dépasse le jeu de travail du cache. En outre, les disques durs ont un temps moyen entre pannes plus faible comparé aux disques NVMe et aux disques SSD.

Les espaces de stockage direct fournissent un cache intégré côté serveur persistant qui prend en charge les opérations de lecture et d’écriture. Ce cache optimise les performances de stockage. Dimensionner et configurer le cache pour prendre en charge l’ensemble de travail de vos applications et charges de travail. Les disques virtuels de Storage Spaces Direct, ou volumes, sont utilisés en combinaison avec le cache de lecture en mémoire du volume partagé de cluster pour améliorer les performances d'Hyper-V. Cette combinaison est particulièrement efficace pour l’accès d’entrée non chiffré aux fichiers de disque dur virtuel de charge de travail (VHD) ou v2 (VHDX).

Tip

Pour les charges de travail à haute performance ou sensibles à la latence, nous vous recommandons d’utiliser une configuration de stockage tout flash (tous NVMe ou ssd) et une taille de cluster de trois machines physiques ou plus. Le déploiement de cette conception avec les paramètres de de configuration de stockage par défaut utilise de mise en miroir tridirectionnel pour les volumes d’infrastructure et d’utilisateur. Cette stratégie de déploiement offre les performances et la résilience les plus élevées. Lorsque vous utilisez une configuration all-NVMe ou all-SSD, vous bénéficiez de la capacité de stockage utilisable complète de chaque lecteur flash. Contrairement aux configurations NVMe et SSD hybrides ou mixtes, aucune capacité n’est réservée à la mise en cache lorsque vous utilisez un seul type de lecteur. Cette configuration garantit une utilisation optimale de vos ressources de stockage. Pour plus d’informations sur la façon d’équilibrer les performances et la capacité pour répondre aux exigences de votre charge de travail, consultez Planifier les volumes - Quand les performances importent le plus.

Conception du réseau

La conception du réseau est la disposition globale 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 physique pour toutes les combinaisons d’intentions de gestion, de calcul et de réseau de stockage. L’utilisation des mêmes ports de carte réseau à toutes fins liées à l’intention est appelée configuration réseau entièrement convergée.

Une configuration réseau entièrement convergée est prise en charge, mais la configuration optimale pour garantir des performances et une fiabilité maximales consiste à utiliser des ports de carte réseau dédiés pour le stockage. Par conséquent, cette architecture de base fournit des exemples d’instructions pour déployer une instance locale Azure à plusieurs nœuds à l’aide de l’architecture réseau commutée de stockage avec deux ports de carte réseau convergés pour la gestion et les intentions de calcul et deux ports de carte réseau dédiés pour l’intention de stockage. Pour plus d’informations, consultez Considérations relatives au réseau pour les déploiements cloud d’Azure Local.

Cette architecture nécessite deux machines physiques ou plus et jusqu’à un maximum de 16 machines à l’échelle. Chaque machine 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 multi-châssis (MLAG). Les deux ports de carte réseau utilisés pour le trafic d’intention de stockage doivent prendre en charge accès à la mémoire directe à distance (RDMA). Ces ports nécessitent une vitesse minimale de liaison de 10 gigaoctets par seconde (Gbit/s), mais nous vous recommandons une vitesse de 25 Gbits/s ou plus. Les deux ports de carte réseau utilisés pour la gestion et les intentions de calcul sont convergés à l’aide de la technologie SET (Switch Embedded Teaming). 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 Gbit/s, mais nous recommandons une vitesse de 10 Gbits/s ou plus.

Topologie de réseau physique

La topologie de réseau physique suivante montre les connexions réseau physiques entre les machines locales Azure et les composants réseau.

Vous avez besoin des composants suivants lorsque vous concevez un déploiement Azure Local à plusieurs nœuds qui utilise cette architecture de référence.

L’image montre la topologie de réseau physique pour une instance locale Azure à plusieurs nœuds qui utilise une architecture de stockage commutée avec des commutateurs ToR doubles. Le diagramme met en évidence les connexions entre les machines physiques, les commutateurs ToR et les réseaux externes. Il met l’accent sur la redondance et les ports compatibles RDMA dédiés pour le trafic de stockage.

• Commutateurs Double ToR :

  • Les commutateurs réseau Double ToR sont requis pour la résilience réseau et pour le service ou pour appliquer des mises à jour de microprogramme aux commutateurs sans temps d’arrêt. Cette stratégie empêche un point de défaillance unique (SPoF).

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

  • Ces commutateurs se connectent aux machines physiques via des câbles Ethernet.

• Deux machines physiques ou plus et jusqu’à un maximum de 16 machines physiques :

  • Chaque machine est un serveur physique qui exécute le système d’exploitation Azure Stack HCI.

  • Chaque ordinateur 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 fournit une redondance de chemin de liaison et une bande passante hiérarchisée dédiée pour le trafic de stockage direct SMB.

  • 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, tel que le réseau local interne de l'entreprise, pour permettre l'accès aux URL sortantes nécessaires à l'aide de votre dispositif de périmètre réseau. Cet appareil peut être un pare-feu ou un routeur. Ces commutateurs routent le trafic entrant et sortant de l’instance locale Azure ou du trafic nord-sud.

  • La connectivité du trafic nord-sud externe prend en charge l’intention de gestion du cluster et les intentions de calcul. Cette configuration réseau est obtenue à l’aide de deux ports de commutateur et de deux ports de carte réseau pour chaque machine convergée via SET et un commutateur virtuel dans Hyper-V pour garantir la résilience. Ces composants fournissent une connectivité externe pour les machines virtuelles locales Azure et d’autres ressources de charge de travail déployées dans les réseaux logiques créés dans Resource Manager à l’aide du portail Azure, d’Azure CLI ou de modèles IaC.

Topologie de réseau logique

La topologie de réseau logique montre une vue d’ensemble de la façon dont les données réseau circulent entre les appareils, quelles que soient leurs connexions physiques.

L’exemple suivant montre une synthèse de la configuration logique pour cette architecture de base de référence commutée de stockage à plusieurs nœuds pour Azure Local.

Le diagramme montre la topologie de réseau logique pour une instance locale Azure à plusieurs nœuds qui utilise une architecture commutée de stockage. Il illustre le flux de trafic réseau entre les composants. Le diagramme montre deux nœuds physiques, chacun avec plusieurs cartes réseau. Network ATC est utilisé pour définir des intentions concernant le trafic de gestion, de calcul et de stockage. Les intentions de gestion et de calcul sont convergées vers un commutateur virtuel qui utilise un SET. L’intention de stockage utilise des adaptateurs compatibles RDMA dédiés. Le diagramme illustre également les réseaux logiques pour les machines virtuelles et la connexion au réseau externe via les commutateurs ToR.

• Commutateurs Double ToR :

  • Avant de déployer le cluster, les deux commutateurs réseau ToR doivent être configurés avec les ID VLAN 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 plus d’informations, consultez configuration réseau physique requise pour Azure Local, ou demandez à votre fournisseur de matériel de commutateur ou partenaire SI d’obtenir de l’aide.

• ATC réseau :

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

  • Azure Local 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 et un flux de trafic réseau optimaux en utilisant des intentions de trafic réseau. Network ATC définit les ports de carte réseau physiques utilisés pour les différentes intentions de trafic réseau (ou types), comme pour la gestion du cluster, le calcul de charge de travail et les intentions de stockage de cluster.

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

• Communication externe :

  • Lorsque les machines physiques ou la charge de travail doivent communiquer en externe en accédant au réseau local d’entreprise, à Internet ou à un autre service, ils routent via les commutateurs ToR doubles.

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

  • L’intention du réseau de gestion utilise l’interface virtuelle de l’équipe SET convergée, qui permet aux ressources de plan de contrôle et d’adresse IP de gestion du cluster de communiquer en externe.

  • 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’un SET team pour les besoins de calcul et de gestion.

• Trafic de stockage :

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

  • Les ports de stockage SMB1 et SMB2 se connectent à deux réseaux distincts (ou couche 2). Chaque réseau dispose d’un ID de réseau local virtuel spécifique configuré qui doit correspondre à la configuration des ports de commutateur sur le ID de réseau local virtuel de stockage par défaut : 711 et 712.

  • Il n'est configurée aucune passerelle par défaut sur les deux ports des adaptateurs réseau pour l'intention de stockage dans le système d’exploitation Azure Stack HCI.

  • Chaque nœud de cluster peut accéder aux fonctionnalités directes des espaces de stockage du cluster, telles que les lecteurs 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 biais du protocole RDMA SMB-Direct sur les deux ports de carte réseau de stockage dédiés disponibles sur chaque ordinateur. SMB Multichannel est utilisé pour la résilience.

  • Cette configuration fournit une vitesse de transfert de 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.

Configuration requise pour le commutateur réseau

Vos commutateurs Ethernet doivent respecter les différentes spécifications requises par Azure Local 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 la spécification PFC IEEE 802.1Qbb pour garantir une communication sans perte pour la classe de trafic de stockage . Vos commutateurs ToR doivent prendre en charge IEEE 802.1Q pour les réseaux locaux virtuels et IEEE 802.1AB pour le protocole de découverte de couche de liaison.

Si vous envisagez d’utiliser des commutateurs réseau existants pour un déploiement local Azure, passez en revue la liste des normes et spécifications IEEE obligatoires que les commutateurs réseau et la configuration doivent fournir. Lorsque vous achetez de nouveaux commutateurs réseau, passez en revue la liste des modèles de commutateur certifiés par le fournisseur de matériel qui prennent en charge les exigences du réseau local Azure.

Exigences relatives à l’adresse IP

Dans un déploiement commuté de stockage à plusieurs nœuds, le nombre d’adresses IP nécessaires augmente avec l’ajout de chaque machine physique, jusqu’à un maximum de 16 machines physiques au sein d’un seul cluster. Par exemple, pour déployer une configuration commutée de stockage à deux nœuds d’Azure Local, l’infrastructure de cluster nécessite un minimum de 11 adresses IP x à allouer. D’autres adresses IP sont requises si vous utilisez la micro-segmentation ou la mise en réseau définie par logiciel. Pour plus d’informations, consultez Passer en revue les exigences d’adresse IP du modèle de référence de stockage à deux nœuds pour azure Local.

Lorsque vous concevez et planifiez les exigences d’adresse IP pour Azure Local, n’oubliez pas de tenir compte des adresses IP supplémentaires ou des plages réseau nécessaires à votre charge de travail au-delà des exigences de l’instance locale Azure et des composants d’infrastructure. Si vous envisagez de déployer AKS sur Azure Local, consultez AKS activé par la configuration réseau requise pour Azure Arc.

Connectivité réseau sortante

Il est important de comprendre les exigences de connectivité réseau sortante d’Azure Local et de prendre en compte ces exigences dans votre plan de conception et d’implémentation avant de déployer la solution. La connectivité réseau sortante est nécessaire pour permettre à Azure Local de communiquer avec Azure et Azure Arc pour les opérations de plan de gestion et de contrôle. Par exemple, la connectivité sortante est nécessaire pour approvisionner des ressources compatibles Avec Azure Arc, telles que des machines virtuelles locales Azure ou des clusters AKS, et pour utiliser des services de gestion Azure tels que Update Manager et Azure Monitor.

La planification initiale et la diligence raisonnable pour permettre la communication réseau avec les points de terminaison publics requis est extrêmement importante lorsque vous intégrez Azure Local à un réseau de centre de données local existant. Cette exigence est particulièrement importante si vous avez des règles de sortie strictes configurées sur des appareils proxy ou pare-feu. En outre, si vos contrôles de sécurité réseau incluent des technologies d’inspection SSL (Secure Sockets Layer), sachez que l’inspection SSL n’est pas prise en charge pour la communication de réseau local Azure.

Pourquoi la connectivité réseau sortante est importante

La connectivité réseau sortante est requise à partir de votre instance Locale Azure. Cette exigence inclut les machines physiques, l’appliance de pont de ressources Azure Arc , les clusters AKS et les machines virtuelles locales Azure si vous utilisez Azure Arc pour la gestion du système d’exploitation invité de la machine virtuelle. Ces appareils disposent d'agents locaux ou de services qui se connectent aux points de terminaison publics en utilisant l'accès réseau sortant pour une communication en temps réel, permettant ainsi la connectivité aux fournisseurs de ressources du plan de gestion et de contrôle qui s'exécutent dans Azure. Par exemple, la connectivité sortante est nécessaire pour que les opérateurs utilisent le portail Azure, l’interface de ligne de commande Azure ou les outils IaC tels que ARM, Bicep ou Terraform pour approvisionner des ressources, les gérer ou effectuer les deux actions. Azure et le pont des ressources Azure Arc fonctionnent en combinaison avec la ressource d’emplacement personnalisée de votre instance Azure Local. Cette combinaison vous permet de cibler l’instance locale Azure spécifique pour toutes les opérations CRUD de ressources (créer, lire, mettre à jour ou supprimer) pour vos ressources de charge de travail avec Azure Arc.

Pour activer la connectivité, configurez votre pare-feu, votre proxy ou votre technologie de sortie Internet, ou une combinaison de ces composants, pour autoriser l’accès sortant aux points de terminaison publics requis. Tenez compte des considérations clés suivantes pour les exigences du réseau sortant local Azure :

• Azure Local ne prend pas en charge l’inspection des paquets SSL/TLS le long des chemins de mise en réseau de vos instances locales Azure vers les points de terminaison publics. En outre, Private Link et Azure ExpressRoute ne sont pas pris en charge pour la connectivité aux points de terminaison publics requis. Pour plus d’informations, consultez exigences du pare-feu pour Azure Local.

• Envisagez d’utiliser la passerelle Azure Arc pour simplifier les exigences de connectivité. Cette approche réduit considérablement le nombre de points de terminaison requis qui doivent être ajoutés à vos règles de pare-feu ou de proxy pour le déploiement et la gestion d’Azure Local.

• Lorsque vous déployez Azure Local à l’aide d’un serveur proxy pour contrôler et gérer l’accès à la sortie Internet, passez en revue les exigences du proxy.

Monitoring

Insights pour Azure Local repose sur Azure Monitor et Log Analytics, ce qui garantit une solution toujours up-to-date et évolutive hautement personnalisable. Insights fournit l’accès aux classeurs par défaut avec des métriques de base, ainsi que des classeurs spécialisés créés pour la surveillance des fonctionnalités clés d’Azure Local. Ces composants fournissent une solution de supervision en temps quasi réel et permettent la création de graphiques, la personnalisation des visualisations via l’agrégation et le filtrage, ainsi que la configuration des règles d’alerte d’intégrité des ressources personnalisées.

Pour améliorer la surveillance et les alertes, activez Azure Monitor Insights sur Azure Local. Insights peut être mis à l’échelle pour surveiller et gérer plusieurs instances locales via une expérience cohérente avec Azure. Insights utilise des compteurs de performances de cluster et des canaux de journal des événements pour surveiller les principales fonctionnalités locales d’Azure. La DCR, qui est configurée via Azure Monitor et Log Analytics, collecte les journaux.

Gestion des mises à jour

Les instances locales Azure et les ressources de charge de travail déployées, telles que les machines virtuelles locales Azure, doivent être mises à jour et corrigées régulièrement. En appliquant régulièrement des mises à jour, vous assurez que votre organisation maintient une posture de sécurité forte. Vous améliorez également la fiabilité globale et la prise en charge de votre patrimoine. Nous vous recommandons d’utiliser des évaluations manuelles automatiques et périodiques pour la détection anticipée et l’application des correctifs de sécurité et des mises à jour du système d’exploitation.

Mises à jour de l’infrastructure

Azure Local est mis à jour en continu pour améliorer l’expérience client et introduire de nouvelles fonctionnalités et fonctionnalités. Les mises à jour des fonctionnalités sont fournies tous les six mois via les trains de mise en production, avec de nouvelles versions publiées en avril (YY04) et octobre (YY10). Outre les mises à jour régulières des fonctionnalités, Azure Local reçoit des mises à jour cumulatives mensuelles qui incluent des améliorations de sécurité et de fiabilité du système d’exploitation, ainsi que des mises à jour des extensions et des agents.

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

• Informations sur la publication locale d’Azure
• Cadence du cycle de vie local Azure
• Passer en revue les phases de mise à jour d’Azure Local
• Utiliser Update Manager pour mettre à jour Azure Local

Il est important de vérifier régulièrement les nouvelles mises à jour du pilote et du microprogramme, comme toutes les trois à six mois. Si vous utilisez une version de catégorie Premier Solution pour votre matériel Local Azure, les mises à jour du package SBE (Solution Builder Extension) sont intégrées à Update Manager pour offrir une expérience de mise à jour simplifiée. Si vous utilisez des nœuds validés ou une catégorie de système intégrée, il peut être 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 matériel.

Mise à jour corrective du système d’exploitation invité de charge de travail

Vous pouvez inscrire des machines virtuelles locales Azure déployées sur Azure Local dans Update Manager pour fournir une expérience unifiée de gestion des correctifs à l’aide du même mécanisme utilisé pour mettre à jour les machines physiques de l’instance locale Azure. Vous pouvez utiliser Update Manager pour créer des configurations de maintenance invité. Ces configurations contrôlent les paramètres tels que le redémarrage du paramètre de 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 locales Azure 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 dans le système d’exploitation invité de votre machine virtuelle de charge de travail.

Considerations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

Identifier les points d’échec potentiels

Chaque architecture est susceptible d’être défaillante. Vous pouvez anticiper les défaillances et être préparé avec des atténuations à l’aide de l’analyse du mode d’échec (FMA). Le tableau suivant décrit quatre exemples de points de défaillance potentiels dans cette architecture.

Component	Risk	Likelihood	Impact et atténuation	Outage
Panne d’instance locale Azure	Panne de l’alimentation, du réseau, du matériel ou du logiciel	Medium	Pour éviter une panne prolongée d’application causée par l’échec d’une instance locale Azure pour les cas d’usage critiques ou critiques pour l’entreprise, votre charge de travail doit être conçue à l’aide des principes de haute disponibilité et de récupération d’urgence. Par exemple, vous pouvez utiliser des technologies de réplication de données de charge de travail standard pour gérer plusieurs copies des données d’état persistant déployées à l’aide de plusieurs machines virtuelles locales Azure ou d’instances AKS déployées sur des instances azure locales distinctes et dans des emplacements physiques distincts.	Panne potentielle
Panne d’ordinateur physique unique Azure Local	Panne de l’alimentation, du matériel ou du logiciel	Medium	Pour éviter une panne prolongée de l’application causée par l’échec d’une seule machine locale Azure, votre instance Azure Local doit avoir plusieurs machines physiques. Vos besoins en capacité de charge de travail pendant la phase de conception du cluster déterminent le nombre de machines physiques. Nous vous recommandons d’avoir trois machines physiques ou plus. Nous vous recommandons également d’utiliser la mise en miroir tridirectionnel, qui est le mode de résilience de stockage par défaut pour les clusters avec trois machines physiques ou plus. Pour empêcher un SPoF et augmenter la résilience des charges de travail, déployez plusieurs instances de votre charge de travail à l’aide de deux machines virtuelles locales Azure ou de pods de conteneur qui s’exécutent sur plusieurs nœuds worker AKS. En cas d’échec d’une seule machine, les machines virtuelles locales Azure et les services d’application ou de charge de travail sont redémarrés sur les machines physiques en ligne restantes dans le cluster.	Panne potentielle
Machine virtuelle locale Azure ou nœud Worker AKS (charge de travail)	Misconfiguration	Medium	Les utilisateurs de l’application ne peuvent pas se connecter ou accéder à l’application. Identifiez les configurations incorrectes pendant le déploiement. Si ces erreurs se produisent pendant une mise à jour de configuration, l’équipe DevOps doit restaurer les modifications. Vous pouvez redéployer la machine virtuelle si nécessaire. Le redéploiement prend moins de 10 minutes pour le déploiement, mais peut prendre plus de temps en fonction du type de déploiement.	Panne potentielle
Connectivité à Azure	Panne du réseau	Medium	Azure Local nécessite une connectivité réseau à Azure pour que les opérations de plan de contrôle soient disponibles. Par exemple, pour approvisionner de nouvelles machines virtuelles locales Azure ou clusters AKS, installez des mises à jour de solution à l’aide de Update Manager ou surveillez l’état d’intégrité de l’instance à l’aide d’Azure Monitor. Si la connectivité à Azure n’est pas disponible, l’instance fonctionne dans un état détérioré, où ces fonctionnalités ne sont pas disponibles. Toutefois, les charges de travail existantes qui s’exécutent déjà sur Azure Local continuent à s’exécuter. Si la connectivité réseau à Azure n’est pas restaurée dans les 30 jours, l’instance entre un état « Hors stratégie », ce qui peut limiter les fonctionnalités. L’appliance de pont de ressources Azure ne peut pas être hors connexion pendant plus de 45 jours, car cette inactivité peut affecter la validité de la clé de sécurité utilisée pour l’authentification.	Opérations de gestion indisponibles

Pour plus d’informations, consultez Recommandations relatives à l’exécution de FMA.

Cibles de fiabilité

Cette section décrit un exemple de scénario. Un client fictif appelé Contoso Manufacturing utilise cette architecture de référence pour déployer Azure Local. Ils souhaitent répondre à leurs besoins et déployer et gérer des charges de travail locales. Contoso Manufacturing a un objectif de niveau de service interne (SLO) de 99,8% que les parties prenantes de l’entreprise et de l’application conviennent de leurs services.

• Un SLO de 99,8% temps d’activité ou de disponibilité entraîne les périodes suivantes de temps d’arrêt autorisé, ou d’indisponibilité, pour les applications déployées à l’aide de machines virtuelles locales Azure qui s’exécutent sur Azure Local :

  • Hebdomadaire : 20 minutes et 10 secondes

  • Mensuel : 1 heure, 26 minutes et 56 secondes

  • Trimestre : 4 heures, 20 minutes et 49 secondes

  • Annuel : 17 heures, 23 minutes et 16 secondes

• Pour aider à atteindre les cibles SLO, Contoso Manufacturing implémente le principe de privilège minimum (PoLP) pour limiter le nombre d’administrateurs d’instances locales Azure à un petit groupe de personnes approuvées et qualifiées. Cette approche permet d’éviter les temps d’arrêt en raison d’actions accidentelles ou accidentelles effectuées sur les ressources de production. En outre, les journaux des événements de sécurité pour les contrôleurs de domaine Ad DS (Active Directory Domain Services) locaux 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 administrateurs d’instances locales Azure qui utilise une solution SIEM. La surveillance augmente la fiabilité et améliore la sécurité de la solution.

  Pour plus d’informations, consultez Recommandations pour la gestion des identités et des accès.

• procédures strictes de contrôle des modifications sont en place pour les systèmes de production de Contoso Manufacturing. Ce processus nécessite que toutes les modifications soient testées et validées dans un environnement de test représentatif avant l’implémentation en production. Toutes les modifications soumises au processus hebdomadaire du conseil consultatif des modifications doivent inclure un plan d’implémentation détaillé (ou un lien vers le code source), un score de niveau de risque, un plan de restauration complet, des tests et des vérifications post-mise en production, et des critères de réussite clairs pour une modification à examiner ou approuver.

  Pour plus d’informations, consultez Recommandations relatives aux pratiques de déploiement sécurisé.

• Les correctifs de sécurité mensuels et les mises à jour de base trimestrielles sont appliqués aux instances locales Azure de production uniquement après leur validation par l’environnement de préproduction. Update Manager et la fonctionnalité de mise à jour prenant en charge le cluster automatisent le processus d’utilisation de migration dynamique de machine virtuelle pour réduire les temps d’arrêt des charges de travail critiques pour l’entreprise pendant les opérations de maintenance mensuelles. Les procédures d’exploitation standard de Contoso Manufacturing nécessitent que les mises à jour de build de sécurité, de fiabilité ou de base de référence soient appliquées à tous les systèmes de production dans les quatre semaines suivant 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 la sécurité. Les systèmes obsolètes affectent négativement la fiabilité et la sécurité de la plateforme.

  Pour plus d’informations, consultez Recommandations pour établir 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 (lundis à samedis), les 3 x dernières sauvegardes hebdomadaires (chaque dimanche) et 3 x sauvegardes mensuelles, chaque semaine du dimanche 4 étant conservée pour devenir les sauvegardes mensuelles 1, mois 2 et mois 3 à l’aide d’une planification basée sur un calendrier propagé documenté et auditable. Cette approche répond aux exigences de fabrication de Contoso pour un équilibre adéquat entre le nombre de points de récupération de données disponibles et la réduction des coûts pour le service de stockage de sauvegarde hors site ou cloud.

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

• processus de sauvegarde et de récupération des données sont testés pour chaque système métier tous les six mois. Cette stratégie garantit que les processus BCDR sont valides et que l’entreprise est protégée en cas de sinistre ou de cyber-incident de centre de données.

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

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

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

Redundancy

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

Utilisez des modèles de haute disponibilité standard pour les charges de travail qui fournissent une réplication active/passive, une réplication synchrone ou une réplication asynchrone telle que SQL Server Always On. Vous pouvez également utiliser une technologie d’équilibrage de charge réseau externe qui achemine les requêtes utilisateur sur plusieurs instances de charge de travail qui s’exécutent sur des instances locales Azure que vous déployez dans des emplacements physiques distincts. Envisagez d’utiliser 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 locaux, telles qu’une instance Azure Application Gateway qui utilise ExpressRoute ou un tunnel VPN pour se connecter à un service local.

Pour plus d’informations, consultez Recommandations de conception pour la redondance.

Security

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

• Une base sécurisée pour la plateforme locale Azure :Azure Local est un produit sécurisé par défaut qui utilise des composants matériels validés avec un module TPM, UEFI et un démarrage sécurisé pour créer une base sécurisée pour la plateforme locale Azure 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 Local a le contrôle d’application, Credential Guard et BitLocker activé. Pour simplifier la délégation des autorisations à l’aide de PoLP, utilisez des rôles de contrôle d’accès en fonction du rôle intégré Azure Local (RBAC), tels qu’Administrateur local Azure pour les administrateurs de plateforme et Contributeur de machine virtuelle locale Azure ou Lecteur de machine virtuelle locale Azure pour les opérateurs de charge de travail.

• Paramètres de sécurité par défaut : Azure Local applique les paramètres de sécurité par défaut pour votre instance Locale Azure pendant le déploiement et permet au contrôle de dérive de conserver les machines physiques 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 des événements de sécurité :le transfert syslog local Azure 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 rétention dans votre propre plateforme SIEM.

• Protection contre les menaces et les vulnérabilités :Defender pour Cloud protège votre instance locale Azure contre diverses menaces et vulnérabilités. Ce service permet d’améliorer la posture de sécurité de votre environnement local Azure 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, telles que les menaces ciblant AD DS, qui fournissent des services d’authentification aux machines d’instance locale Azure et à leurs charges de travail de machine virtuelle Windows Server.

• isolation réseau : isoler les réseaux si nécessaire. Par exemple, vous pouvez approvisionner plusieurs réseaux logiques qui utilisent des réseaux locaux virtuels distincts et des plages d’adresses réseau. Lorsque vous utilisez cette approche, assurez-vous que le réseau de gestion peut atteindre chaque réseau logique et réseau local virtuel afin que les machines physiques d’instance locale Azure puissent communiquer avec les réseaux VLAN via les commutateurs toR ou les passerelles. Cette configuration est requise pour la gestion de la charge de travail, par exemple pour permettre aux agents de gestion de l’infrastructure de communiquer avec le système d’exploitation invité de la charge de travail.

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

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

• Modèle de facturation de style cloud pour les licences : La tarification Locale Azure suit le modèle de facturation d’abonnement mensuel avec un tarif forfaitaire pour chaque cœur de processeur physique dans une instance locale Azure. Des frais d’utilisation supplémentaires s’appliquent si vous utilisez d’autres services Azure. Si vous possédez des licences principales locales pour l’édition Windows Server Datacenter avec Software Assurance active, vous pouvez choisir d’échanger ces licences pour activer les frais d’abonnement à l’instance locale Azure et à la machine virtuelle Windows Server.

• Mise à jour corrective automatique des invités de machine virtuelle pour les machines virtuelles locales Azure : Cette fonctionnalité permet de réduire la surcharge liée à la mise à jour corrective manuelle et aux coûts de maintenance associés. Non seulement cette action contribue-t-elle à rendre le système plus sécurisé, mais il optimise également l’allocation des ressources et contribue à l’efficacité globale des coûts.

• Consolidation de la surveillance des coûts : Pour consolider les coûts de supervision, utilisez Azure Local Insights et patch à l’aide de Update Manager pour Azure Local. Azure Local Insights utilise Azure Monitor pour fournir des métriques et des fonctionnalités d’alerte enrichies. Le composant Gestionnaire de cycle de vie d’Azure Local s’intègre à Update Manager pour simplifier la tâche de maintenir vos clusters up-to-date en consolidant les flux de travail de mise à jour pour différents composants en une seule expérience. Utilisez Azure Monitor et Update Manager pour optimiser l’allocation des ressources et contribuer à l’efficacité globale des coûts.

  Pour plus d’informations, consultez Recommandations pour optimiser le temps du personnel.

• Capacité et croissance de la charge de travail initiales : Lorsque vous planifiez votre déploiement local Azure, tenez compte de la capacité de votre charge de travail initiale, des exigences de résilience et des considérations de croissance futures. Envisagez d’utiliser une architecture sans commutateur de stockage à deux, trois ou quatre nœuds pour potentiellement réduire les coûts, comme par exemple en éliminant la nécessité d'acquérir des commutateurs réseau de classe stockage. L’achat de commutateurs réseau de classes de stockage supplémentaires peut être un composant coûteux des nouveaux déploiements d’instances locales Azure. Au lieu de cela, vous pouvez utiliser des commutateurs existants pour la gestion et les réseaux de calcul, ce qui simplifie l’infrastructure. Si la capacité et la résilience de votre charge de travail ne sont pas mises à l’échelle au-delà d’une configuration à quatre nœuds, envisagez d’utiliser des commutateurs existants pour les réseaux de gestion et de calcul, et utilisez l’architecture sans commutateur de stockage pour déployer Azure Local.

  Pour plus d’informations, consultez Recommandations pour optimiser les coûts des composants.

Tip

Vous pouvez réduire les coûts par le biais d’Azure Hybrid Benefit si vous conservez des licences Windows Server Datacenter qui incluent l’assurance logicielle active. Pour plus d’informations, consultez Azure Hybrid Benefit pour Azure Local.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

• Expérience de gestion et d’approvisionnement simplifiée intégrée à Azure : Le déploiement basé sur le cloud dans Azure fournit une interface pilotée par l’Assistant qui vous montre comment créer une instance locale Azure. De même, Azure simplifie le processus de gestion des instances locales Azure et des machines virtuelles locales Azure. Vous pouvez automatiser le déploiement basé sur le portail de l’instance locale Azure à l’aide de ce modèle ARM. L’utilisation de modèles fournit une cohérence et une automatisation pour déployer Azure Local à grande échelle, en particulier dans des scénarios de périphérie tels que des magasins de vente au détail ou des sites de fabrication qui nécessitent une instance locale Azure pour exécuter des charges de travail critiques pour l’entreprise.

• Fonctionnalités d’automatisation pour les machines virtuelles Azure : Azure Local fournit un large éventail de fonctionnalités d’automatisation pour la gestion des charges de travail, telles que les machines virtuelles locales Azure. Ces fonctionnalités incluent le déploiement automatisé de machines virtuelles locales Azure à l’aide d’Azure CLI, de modèles ARM ou de modèles Bicep. Les mises à jour du système d’exploitation de machine virtuelle sont fournies via l’extension Azure Arc pour les mises à jour et Update Manager, qui applique les mises à jour à chaque instance locale Azure. Azure Local assure également la prise en charge de la gestion des machines virtuelles locales Azure à l’aide d’Azure CLI et de machines virtuelles non-Azure locales à l’aide de Windows PowerShell. Vous pouvez exécuter les commandes Azure CLI localement à partir de l’une des machines locales Azure 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 machine virtuelle via les extensions Azure Arc.

  Pour plus d’informations, consultez Recommandations pour l’utilisation de l'IaC.

• Fonctionnalités d’automatisation pour les conteneurs sur AKS : Azure Local fournit un large éventail de fonctionnalités d’automatisation pour la gestion des charges de travail, telles que des conteneurs, sur AKS. Vous pouvez automatiser le déploiement de clusters AKS à l’aide d’Azure CLI. Utilisez l’extension Azure Arc pour les mises à jour Kubernetes pour mettre à jour les clusters de charge de travail AKS. Vous pouvez également gérer AKS activé par Azure Arc l’aide d’Azure CLI. Vous pouvez exécuter les commandes Azure CLI localement à partir de l’une des machines locales Azure 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 plus d’informations, consultez les ressources suivantes :

  • Recommandations pour l’activation de l’automatisation
  • Comparer les fonctionnalités de gestion des machines virtuelles sur Azure Local

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

• Performances du stockage de charge de travail : Envisagez d’utiliser l’outil DiskSpd pour tester les fonctionnalités de performances de stockage de charge de travail d’une instance locale Azure. 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.

  Nous vous recommandons d’établir une base de référence pour les performances de vos instances locales Azure avant de déployer des charges de travail de production. 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 consiste à émettre des opérations de lecture et d’écriture et des métriques de performances de sortie, telles que la latence, le débit et les E/S par seconde.

  Pour plus d’informations, consultez Recommandations pour les tests de performances.

• Résilience du stockage de 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 locaux Azure inclut l’identification de l’équilibre optimal entre la résilience, l’efficacité de l’utilisation et les performances. Il peut être difficile d’optimiser cet équilibre, car l’optimisation de l’une de ces caractéristiques a généralement un effet négatif sur une ou plusieurs des autres caractéristiques. L’augmentation de la résilience réduit la capacité utilisable. Par conséquent, les performances peuvent varier en fonction du type de résilience choisi. Lorsque la résilience et les performances sont la priorité et que vous utilisez trois machines physiques ou plus, la configuration de stockage par défaut utilise la mise en miroir tridirectionnel pour les volumes d’infrastructure et d’utilisateur.

  Pour plus d’informations, consultez Recommandations pour 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é lorsque vous déterminez votre configuration matérielle réseau optimale.

  Pour optimiser les performances de calcul dans Azure Local, vous pouvez utiliser l’accélération GPU. L’accélération GPU est bénéfique pour charges de travail d’IA ou de Machine Learning hautes performances qui impliquent des insights de données ou une inférence. Ces charges de travail nécessitent un déploiement à des emplacements de 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 local, 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 instances locales Azure.

  Pour plus d’informations, 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 générales ou de flux de travail standard utilisés pour déployer Azure Local, y compris les tâches requises et les considérations. Cette liste de flux de travail est conçue comme un exemple de guide uniquement. 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 au projet.

Dans ce scénario, un projet ou un cas d’usage vous oblige à déployer une solution cloud hybride dans un emplacement local ou edge pour fournir un calcul local pour le traitement des données. Il est également nécessaire de maintenir des expériences de gestion et de facturation cohérentes avec Azure. Pour plus d’informations, consultez la section Cas d’usage potentiels de cet article. Les étapes restantes supposent qu’Azure Local est la solution de plateforme d’infrastructure choisie pour le projet.

1. Rassemblez les exigences en matière de charge de travail et de cas d’usage auprès des parties prenantes pertinentes. Cette stratégie permet au projet de confirmer que les fonctionnalités et les fonctionnalités d’Azure Local répondent aux exigences relatives à l’échelle, aux performances et aux fonctionnalités de la charge de travail. Ce processus de révision 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 locales Azure, AKS, Virtual Desktop ou les services de données avec Azure Arc ou le service Machine Learning avec Azure Arc. Les valeurs RTO et RPO de charge de travail (fiabilité) et d’autres exigences non fonctionnelles (performances et scalabilité de charge) doivent être documentées dans le cadre de cette étape.

2. Examinez le résultat de l'outil de dimensionnement local Azure pour la solution de matériel recommandée par le partenaire. Cette sortie inclut des détails sur la marque et le modèle du matériel du serveur physique recommandés, le nombre de machines physiques, ainsi que les spécifications de la configuration du processeur, de la mémoire et du stockage pour chaque nœud physique afin de déployer et pour exécuter vos charges de travail.

3. Utilisez l’outil de dimensionnement local Azure pour créer un projet qui modélise le type et la mise à l’échelle de la charge de travail. Ce projet inclut la taille et le nombre de machines virtuelles et leurs besoins de stockage. Ces détails sont saisis en même temps que les choix concernant le type de système, la famille de processeurs préférée et les exigences de résilience en matière de haute-disponibilité et de tolérance de panne de stockage, comme expliqué dans la section Choix de conception du cluster.

4. Passez en revue le résultat d’Azure Local Sizer pour la solution de partenaire matériel recommandée. Cette solution inclut des détails sur le matériel du serveur physique recommandé (fabrique et modèle), le nombre de machines physiques et les spécifications de l’UC, de la mémoire et de la configuration de stockage pour chaque nœud physique à déployer et exécuter vos charges de travail.

5. Contactez le partenaire OEM ou SI matériel pour qualifier davantage la pertinence de la version matérielle recommandée par rapport à vos besoins en charge de travail. Si elle est disponible, 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 matériel pour les aspects commerciaux de la solution. Ces aspects incluent les guillemets, la disponibilité du matériel, les délais d’exécution 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 instances locales Azure nécessitent le déploiement de deux commutateurs ToR. Chaque machine physique nécessite quatre cartes réseau, dont deux doivent être compatibles RDMA, qui fournissent deux liens entre chaque machine et les deux commutateurs ToR. Deux cartes réseau, une connectée à chaque 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 est-ouest de stockage. Si vous envisagez d’utiliser des commutateurs réseau existants, vérifiez que la création et le modèle de vos commutateurs figurent dans la liste approuvée des commutateurs réseau pris en charge par azure Local.

7. Collaborez avec le partenaire OEM ou SI matériel pour organiser la livraison du matériel. Le partenaire SI ou vos employés sont ensuite tenus d’intégrer le matériel à votre centre de données local ou à votre emplacement de périphérie, comme le racking et l’empilement du matériel, du réseau physique et du câblage d’unité d’alimentation pour les machines physiques.

8. Effectuez le déploiement d’instance locale Azure. Selon la version de votre solution choisie (Solution Premier, Système intégré ou Nœud validé), le partenaire matériel, le partenaire SI ou vos employés peuvent déployer le logiciel local Azure. Cette étape commence par intégrer le système d'exploitation Azure Stack HCI des machines physiques dans des serveurs activés pour Azure Arc, puis démarrer le processus de déploiement pour le cloud local Azure. Les clients et les partenaires peuvent déclencher une demande de support directement avec Microsoft dans le portail Azure en sélectionnant l’icône Support + Résolution des problèmes ou en contactant leur partenaire OEM ou SI matériel, en fonction de la nature de la demande et de la catégorie de solution matérielle.

   Tip

   L’implémentation de référence du système d’exploitation Azure Stack HCI version 23H2 montre comment déployer un déploiement à plusieurs nœuds commutés d’Azure Local à l’aide d’un modèle ARM et d’un fichier de paramètres. Vous pouvez également l’exemple Bicep montre comment utiliser un modèle Bicep pour déployer une instance locale Azure, y compris ses ressources requises.

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

10. Installez des mises à jour mensuelles pour améliorer la sécurité et la fiabilité de la plateforme. Pour maintenir vos instances locales Azure à jour, il est important d’installer les mises à jour logicielles Microsoft et les mises à jour du pilote OEM oem matériel et du microprogramme. 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 matériel pour déterminer le processus d’installation des mises à jour du pilote matériel et du microprogramme, car ce processus peut varier en fonction du type de catégorie de solution matérielle choisi (Premier Solution, Système intégré ou Nœud validé). Pour plus d’informations, consultez Mises à jour de l’infrastructure.

Ressources associées

• conception d’architecture hybride
• options hybrides Azure
• Optimiser l’administration des instances SQL dans les environnements locaux et multiclouds avec Azure Arc

Étapes suivantes

Documentation du produit Microsoft Learn :

• Informations sur la publication locale d’Azure
• AKS sur Azure Local
• Virtual Desktop sur Azure Local
• Qu’est-ce qu’Azure Local Monitoring ?
• Protéger les charges de travail de machine virtuelle à l’aide de Site Recovery sur Azure Local
• Vue d’ensemble d’Azure Monitor
• vue d’ensemble du suivi des modifications et de l’inventaire
• vue d’ensemble Update Manager
• Qu’est-ce que les services de données avec Azure Arc ?
• Qu’est-ce que les serveurs avec Azure Arc ?
• Qu’est-ce que le service de sauvegarde ?
• Vue d’ensemble d’Azure Automation
• Configuration de l’état Azure Automation
• Présentation de cible de calcul Kubernetes dans Machine Learning

Documentation du produit Azure :

• Azure Local
• Azure Arc
• Coffre-fort de clés
• Stockage Blob Azure
• Azure Monitor.
• Azure Policy
• Azure Container Registry
• Defender pour cloud
• Site Recovery
• Backup

Formation Microsoft Learn :

• Configurer Azure Monitor
• Concevoir une solution pour la sauvegarde et la récupération d’urgence
• Présentation d’Azure Arc
• Présentation de akS
• Maintenir vos machines virtuelles mises à jour
• protéger vos machines virtuelles à l’aide du de sauvegarde

Autres ressources :

• déploiement de modèle de mise à l’échelle avec Machine Learning n’importe où - Blog Tech Community
• La réalisation de Machine Learning n’importe où avec AKS et Le Machine Learning avec Azure Arc - Blog Tech Community
• Machine Learning sur AKS hybride et Azure Local à l’aide du Machine Learning avec Azure Arc - Blog de la communauté tech

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 de l’infrastructure Azure Local 2311 et ultérieure, afin de fournir une plateforme fiable pour les 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 machines physiques qui fournissent des fonctionnalités de calcul, de stockage et de mise en réseau locales. Il explique également comment utiliser des services Azure pour simplifier la gestion quotidienne d’Azure Local pour les opérations à grande échelle.

Pour plus d’informations sur les modèles d’architecture de charge de travail optimisés pour s’exécuter sur Azure Local, consultez le contenu situé dans la charges de travail locales Azure menu de navigation.

Cette architecture est un point de départ pour utiliser la conception réseau commutée de stockage pour déployer une instance locale Azure à plusieurs nœuds. Les applications de charge de travail déployées sur une instance locale Azure 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 haute disponibilité de tous les services de charge de travail critiques et disposer de contrôles de continuité d’activité et de récupération d’urgence appropriés en place. Ces contrôles BCDR incluent des sauvegardes régulières et des fonctionnalités de basculement pour la reprise après sinistre. Pour vous concentrer sur la plateforme d’infrastructure hyperconvergée (HCI), ces aspects de conception de charge de travail sont intentionnellement exclus de cet article.

Pour plus d’informations sur les instructions et les recommandations relatives aux cinq piliers d’Azure Well-Architected Framework, consultez le guide de service Azure Local Well-Architected Framework.

Disposition de l’article

Architecture	Décisions de conception	Approche de Well-Architected Framework
▪ architecture ▪ composants ▪ Ressources de plateforme ▪ Ressources de prise en charge de la plateforme ▪ Détails du scénario ▪ Utiliser Azure Arc avec Azure Local ▪ Tirer parti de la configuration de sécurité par défaut d’Azure Local ▪ cas d’usage potentiels ▪ Déployer ce scénario	▪ choix de conception de cluster ▪ disques physiques ▪ Conception du réseau ▪ Surveillance ▪ Gestion des mises à jour	▪ Fiabilité ▪ Sécurité ▪ Optimisation des coûts ▪ Excellence opérationnelle ▪ Efficacité du niveau de performance

Tip

Ce modèle local Azure montre comment utiliser un modèle Azure Resource Manager (modèle ARM) et un fichier de paramètres pour déployer un déploiement multiserveur commuté d’Azure Local. L’exemple Bicep montre également comment utiliser un modèle Bicep pour déployer une instance locale Azure et ses ressources requises.

Architecture

Le diagramme d’architecture montre un environnement local Azure local connecté à Azure. L’environnement local contient un cluster local Azure à plusieurs nœuds. Le cluster est connecté à des commutateurs ToR doubles pour la connectivité réseau. L’environnement Azure affiche plusieurs services Azure qui s’intègrent à Azure Local. Ces services incluent Azure Arc, Azure Monitor, Azure Key Vault, Azure Policy, Microsoft Defender pour cloud, Azure Update Manager, Sauvegarde Azure et Azure Site Recovery.

Pour plus d’informations, consultez Ressources associées.

Components

Cette architecture se compose de matériel de serveur physique que vous pouvez utiliser pour déployer des instances locales Azure dans des emplacements locaux ou edge. Pour améliorer les fonctionnalités de plateforme, Azure Local s’intègre à Azure Arc et à d’autres services Azure qui fournissent des ressources de prise en charge. Azure Local fournit une plateforme résiliente pour déployer, gérer et exploiter des applications utilisateur ou des systèmes métier. Les ressources et services de plateforme sont décrits dans les sections suivantes.

Ressources de plateforme

• Azure Local est une solution HCI déployée localement ou dans des emplacements de périphérie et qui utilise une infrastructure matérielle et réseau de serveur physique. Azure Local fournit 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 instances locales Azure peuvent passer d’un déploiement à un seul ordinateur à un maximum de 16 machines physiques à l’aide de catégories de matériel validées, intégrées ou premium que fournissent les partenaires OEM (Fabricant d’équipement d’origine). Dans cette architecture, Azure Local fournit la plateforme principale permettant d’héberger et de gérer des charges de travail virtualisées et conteneurisées localement ou en périphérie.

• Azure Arc est un service cloud qui étend le modèle de gestion basé sur Resource Manager à Azure Local et à d’autres emplacements non-Azure. Azure Arc utilise Azure comme plan de contrôle et de gestion pour permettre la gestion de différentes ressources telles que des machines virtuelles, des clusters Kubernetes et des données conteneurisées et des services Machine Learning. Dans cette architecture, Azure Arc permet la gestion centralisée et la gouvernance des ressources déployées sur Azure Local via le plan de contrôle Azure.

• 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 tout ce que vous souhaitez 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. Dans cette architecture, Key Vault sécurise les informations sensibles et les informations d’identification utilisées par les charges de travail et les composants d’infrastructure sur Azure Local.

• Le témoin cloud est une fonctionnalité qui utilise le stockage Azure pour servir de quorum de basculement de cluster. Azure Local (deux instances de machine uniquement) utilise un témoin cloud comme quorum pour le vote, ce qui garantit la haute disponibilité pour le cluster. Le compte de stockage et la configuration du témoin sont créés pendant le processus de déploiement du cloud local Azure. Dans cette architecture, le témoin cloud fournit un quorum pour les clusters à deux nœuds afin de maintenir la haute disponibilité.

• Azure Update Manager est un service unifié conçu pour gérer et régir les mises à jour pour Azure Local. Vous pouvez utiliser Update Manager pour gérer les charges de travail déployées sur Azure Local, y compris la conformité des mises à jour du système d’exploitation invité pour les machines virtuelles Windows et Linux qui peuvent être activées à l’aide d’Azure Policy. Cette approche unifiée centralise la gestion des correctifs dans les environnements Azure, locaux et d’autres plateformes cloud via un tableau de bord unique. Dans cette architecture, Update Manager fournit une gestion centralisée des mises à jour et des correctifs pour l’infrastructure et les charges de travail.

Ressources de prise en charge de la plateforme

• Azure Monitor est un service cloud permettant de collecter, d’analyser et d’agir sur les journaux de diagnostic et les données de télémétrie à partir de charges de travail cloud et locales. Vous pouvez utiliser Azure Monitor pour optimiser la disponibilité et les performances de vos applications et services via une solution de supervision. Déployez Insights pour Azure Local pour simplifier la création de la règle de collecte de données Azure Monitor (DCR) et activer la supervision des instances locales Azure. Dans cette architecture, Azure Monitor fournit des analyses et des données de télémétrie pour les clusters et charges de travail locaux Azure.

• Azure Policy est un service qui évalue les ressources Azure et locales. Azure Policy évalue les ressources via l’intégration à Azure Arc à l’aide des propriétés de ces ressources aux règles métier, appelées définitions de stratégie, pour déterminer la conformité ou les fonctionnalités que vous pouvez utiliser pour appliquer la configuration d’invité de machine virtuelle via les paramètres de stratégie. Dans cette architecture, Azure Policy fournit une fonctionnalité d’audit et de conformité pour la configuration de sécurité du système d’exploitation des machines locales Azure. Les paramètres sont continuellement appliqués à l’aide du contrôle de dérive.

• Defender pour cloud est un système de gestion de la sécurité de l’infrastructure. Il améliore la posture de sécurité des 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 dans des environnements locaux. Dans cette architecture, Defender pour Cloud fournit une surveillance de la sécurité et une protection contre les menaces pour les charges de travail s’exécutant sur Azure Local.

• Sauvegarde Azure est un service cloud qui fournit une solution sécurisée et économique pour sauvegarder des données et les récupérer à partir du cloud Microsoft. Le serveur de sauvegarde Azure est utilisé pour effectuer la sauvegarde de machines virtuelles déployées sur Azure Local et les stocker dans le service de sauvegarde. Dans cette architecture, Sauvegarde Azure protège les données et active la récupération pour les machines virtuelles hébergées sur Azure Local.

• Azure Site Recovery est un service de reprise après sinistre qui fournit des capacités de continuité d’activité et de reprise après sinistre (BCDR) en permettant aux applications 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 qui s’exécutent sur des serveurs physiques et des machines virtuelles entre leur site principal (local) et un emplacement secondaire (Azure). Dans cette architecture, Site Recovery permet la reprise après sinistre et le basculement pour les charges de travail exécutées sur Azure Local.

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 Local.

Utiliser Azure Arc avec Azure Local

Azure Local s’intègre directement à Azure à l’aide d’Azure Arc pour réduire le coût total de possession (TCO) et la surcharge opérationnelle. Azure Local est déployé et géré via Azure, qui fournit une intégration intégrée d’Azure Arc via le déploiement du composant de pont de ressources Azure Arc. Ce composant est déployé dans le cadre du processus de déploiement cloud d’instance locale Azure. Les machines locales Azure sont inscrites auprès d’Azure Arc pour les serveurs comme prérequis pour démarrer le déploiement cloud de votre instance locale Azure. Pendant le déploiement, les extensions obligatoires sont installées sur chaque ordinateur, comme Lifecycle Manager, Microsoft Edge Device Management et les extensions de télémétrie et de diagnostic. Vous pouvez utiliser Azure Monitor et Log Analytics après le déploiement pour surveiller la solution en activant Insights pour Azure Local. Les mises à jour des fonctionnalités pour Azure Local sont publiées tous les six mois pour améliorer l’expérience client. Les mises à jour pour Azure Local sont contrôlées et gérées à l’aide de Update Manager.

Vous pouvez déployer des ressources de charge de travail telles que des machines virtuelles Azure Arc, AKS avec Azure Arc et des hôtes de session Azure Virtual Desktop qui utilisent le portail Azure en sélectionnant un emplacement personnalisé d’instance locale Azure 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 assurance logicielle active sur vos licences principales Windows Server Datacenter existantes, vous pouvez réduire les coûts en appliquant Azure Hybrid Benefit aux clusters Azure Local, Windows Server VMs et AKS. Cette optimisation permet de gérer efficacement les coûts de ces services.

L’intégration d’Azure et d’Azure Arc étendent les fonctionnalités des charges de travail virtualisées et conteneurisées Azure pour inclure les solutions suivantes :

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

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

• Virtual Desktop pour déployer vos hôtes de session pour les charges de travail Virtual Desktop sur Azure Local (local). 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 en conteneur.

• Azure Container Apps avec Azure Arc activé pour exécuter des applications et des microservices basés sur des conteneurs. Vous pouvez le déployer à l’aide de l’extension Container Apps pour Kubernetes, qui permet l’approvisionnement d’environnements Container Apps connectés. Une fois qu’il est activé sur un cluster AKS, vous pouvez exécuter des services tels qu’Azure Functions. Pour prendre en charge la mise à l’échelle pilotée par les événements, vous pouvez éventuellement installer l’extension Kubernetes Event-Driven Autoscaling (KEDA).

• L'extension Azure Event Grid compatible avec Azure Arc pour Kubernetes pour déployer le répartiteur Event Grid et l’opérateur Event Grid . Ce déploiement permet 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 Local 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 Machine Learning à la 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 locaux Azure, telles que l’automatisation de la configuration du système d’exploitation invité avec les extensions de machine virtuelle locale Azure 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 d’infrastructure en tant que code (IaC).

Tirer parti de la configuration de sécurité par défaut d’Azure Local

La configuration de sécurité par défaut d’Azure Local 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 à distance 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 essentielle dans les environnements qui ont un support informatique limité ou un manque ou des centres de données dédiés. Azure Local 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é local Azure garantit la prise en charge intégrée du démarrage sécurisé, de l’interface UEFI (Unified Extensible Firmware Interface) et du module de plateforme sécurisée (TPM). Utilisez ces technologies en combinaison avec la sécurité basée sur la virtualisation (VBS) pour protéger vos charges de travail sensibles à la sécurité. Vous pouvez utiliser le chiffrement de lecteur BitLocker pour chiffrer les volumes de disque de démarrage et les espaces de stockage direct au repos. Le chiffrement SMB (Server Message Block) fournit un chiffrement automatique du trafic entre les machines physiques du cluster (sur le réseau de stockage) et la signature du trafic SMB entre les machines physiques 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 des machines virtuelles locales Azure dans Defender pour Cloud pour activer l’analytique comportementale basée sur le cloud, la détection et la correction des menaces, les alertes et les rapports. Gérez les machines virtuelles locales Azure dans Azure Arc afin de pouvoir utiliser Azure Policy pour évaluer leur conformité aux réglementations du secteur et aux normes d’entreprise.

Cas d’usage potentiels

Les cas d’usage classiques pour Azure Local incluent l’exécution de charges de travail haute disponibilité dans des emplacements locaux ou edge. Azure Local fournit une plateforme pour répondre aux exigences telles que les fonctionnalités suivantes :

• Fournissez une solution connectée au cloud déployée localement pour répondre aux exigences de souveraineté, de réglementation et de conformité des données ou de latence.

• Déployez et gérez des charges de travail ha-virtualisées ou basées sur des conteneurs déployées dans un emplacement unique ou multiple. Cette fonctionnalité permet aux applications et services critiques pour l’entreprise de fonctionner de manière résiliente, rentable et évolutive.

• Réduisez le TCO en déployant une solution certifiée par Microsoft et ses partenaires OEM matériels. Cette solution utilise un processus de déploiement basé sur le cloud moderne et fournit une expérience de gestion et de supervision centralisée cohérentes avec Azure.

• Fournir une fonctionnalité d’approvisionnement centralisée à l’aide d’Azure et d’Azure Arc. Cette fonctionnalité permet le déploiement de charges de travail à plusieurs emplacements de manière cohérente et sécurisée. Les outils tels que le portail Azure, Azure CLI ou les modèles IaC (modèles ARM, Bicep et Terraform) améliorent l’automatisation et la répétabilité. Cette approche permet un déploiement et une gestion rapides des clusters Azure Kubernetes Service (AKS) pour les charges de travail en conteneur et les machines virtuelles locales Azure pour les charges de travail virtualisées traditionnelles.

• Respectez les exigences strictes en matière de sécurité, de conformité et d’audit. Azure Local est déployé avec une posture de sécurité renforcée configurée par défaut, appelée secure-by-default. Azure Local intègre du matériel certifié, un démarrage sécurisé, un module TPM, VBS, Credential Guard et des stratégies de contrôle d’application appliquées. Azure Local a la possibilité d’intégrer des services de sécurité et de gestion des menaces modernes basés sur le cloud, tels que Microsoft Defender pour Cloud et Microsoft Sentinel. Cette intégration fournit des fonctionnalités de détection et de réponse étendues (XDR) et de gestion des événements d’information de sécurité (SIEM).

Choix de conception de cluster

Comprendre les exigences en matière de performances et de fiabilité des charges de travail. Pour la résilience, il est important de comprendre les attentes de la plateforme et des charges de travail afin de maintenir leur fonctionnement pendant les défaillances de matériel ou de nœuds. Définissez également l’objectif de délai de récupération (RTO) et l’objectif de point de récupération (RPO) pour votre stratégie de récupération. Facteur des exigences de calcul, de mémoire et de stockage pour toutes les charges de travail déployées sur l’instance locale Azure. Plusieurs caractéristiques de la charge de travail affectent le processus décisionnel :

• Fonctionnalités d’architecture de l’unité de traitement centrale (UC), notamment les fonctionnalités de technologie de sécurité matérielle, le nombre de processeurs, la fréquence de gigahertz (GHz) (vitesse) et le nombre de cœurs pour chaque socket processeur.

• Exigences de 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.

• Mémoire de chaque ordinateur, ou quantité de mémoire physique requise pour exécuter la charge de travail.

• Nombre de machines physiques dans l’instance qui sont de 1 à 16 machines à l’échelle. Le nombre maximal de machines physiques est de quatre 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 machines physiques de capacité dans l’instance. Cette stratégie permet de vider les nœuds pour les mises à jour ou la récupération à partir de pannes soudaines telles que les pannes de courant ou les défaillances matérielles.

  • Pour les charges de travail critiques ou stratégiques pour l’entreprise, envisagez de réserver des machines physiques N+2 d’une capacité pour augmenter la résilience. Par exemple, si deux machines physiques de l’instance sont hors connexion, la charge de travail peut rester en ligne. Cette approche offre une résilience pour les scénarios dans lesquels une machine exécutant une charge de travail est hors connexion pendant une procédure de mise à jour planifiée et entraîne la connexion simultanée de deux machines physiques d’instance.

• Résilience, capacité et performances du stockage requises :

  • Résilience: Nous vous recommandons de déployer trois machines physiques ou plus pour activer la mise en miroir tridirectionnel, qui fournit trois copies des données, pour les volumes d’infrastructure et d’utilisateur. La mise en miroir tridirectionnel augmente les performances et la fiabilité maximale pour le stockage.

  • Capacité : La capacité de stockage utilisable totale requise après la tolérance de panne, ou les copies, est prise en compte. Ce nombre est d’environ 33% de l’espace de stockage brut de vos disques de niveau capacité lorsque vous utilisez la mise en miroir tridirectionnel.

  • Performance: Opérations d’entrée/sortie par seconde (IOPS) de la plateforme qui détermine les fonctionnalité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 local Azure, nous vous recommandons d’utiliser l’outil de dimensionnement local Azure et de créer un projet pour dimensionnement de vos instances locales Azure. L’utilisation de l’outil de dimensionnement vous oblige à comprendre vos besoins en charge de travail. Lorsque vous tenez compte du nombre et de la taille des machines virtuelles de charge de travail qui s’exécutent sur votre instance, 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 vous guide à travers des questions relatives au type de système, tel que Solution Premier, Système Intégré, ou Nœud Validé, et aux options de famille de processeurs. Il vous aide également à sélectionner vos exigences de résilience pour l’instance. Pour définir des niveaux de résilience, suivez ces recommandations :

• Réservez un minimum de N+1 machines physiques d’une capacité, ou d’un nœud, sur l’instance. Cette approche garantit que vous pouvez appliquer des mises à jour de solution en drainant et en redémarrant chaque nœud un par un, sans provoquer de temps d’arrêt de la charge de travail.

• Réservez N+2 machines physiques en termes de capacité sur l’instance pour une résilience supplémentaire. Cette option permet au système de résister simultanément à une défaillance de machine lors d’une mise à jour ou d’un autre événement inattendu qui affecte simultanément deux ordinateurs. Il garantit également qu’il existe suffisamment de capacité dans l’instance pour que la charge de travail s’exécute sur les machines en ligne restantes.

Ce scénario nécessite l’utilisation de la mise en miroir tridirectionnel pour les volumes utilisateur, qui est la valeur par défaut pour les instances qui ont trois machines physiques ou plus.

La sortie de l’outil de dimensionnement local Azure est une liste des références SKU de solution matérielle recommandées qui peuvent fournir les exigences de résilience de la charge de travail et de la plateforme requises en fonction des valeurs d’entrée dans le projet sizer. Pour plus d’informations sur les solutions de partenaire matériel OEM disponibles, consultez le catalogue de solutions locales Azure. Pour vous aider à dimensionner correctement les références SKU de solution pour répondre à vos besoins, contactez votre fournisseur de solutions matérielle ou partenaire d’intégration de système (SI) préféré.

Lecteurs de disque physique

espaces de stockage direct prend en charge plusieurs types de disques physiques qui varient en performances et en capacité. Lorsque vous concevez une instance locale Azure, collaborez avec votre partenaire OEM matériel choisi pour déterminer les types de lecteurs de disque physique les plus appropriés pour répondre aux exigences de capacité et de performances de votre charge de travail. Par exemple, il s’agit d’épingler des lecteurs de disque dur (HDD) ou des disques SSD (SSD) et des lecteurs NVMe (Non Volatile Memory Express). Ces lecteurs sont souvent appelés lecteurs flash, ou stockage de mémoire persistante (PMem), qui est appelé mémoire de classe de stockage (SCM).

La fiabilité de la plateforme dépend des performances des dépendances de plateforme 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 telles que des lecteurs NVMe ou des DISQUES 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, mais ne sont pas limitées aux technologies de base de données transactionnelles hautement transactionnelles, aux clusters AKS de production ou à toute charge de travail stratégique ou critique pour l’entreprise qui ont des exigences de stockage à faible latence ou à débit élevé. Utilisez des déploiements flash pour optimiser les performances de stockage. Des configurations entièrement NVMe ou entièrement SSD, en particulier à petite échelle, améliorent l’efficacité du stockage et optimisent les performances, car aucun lecteur n'est utilisé en tant que niveau de cache. Pour plus d’informations, consultez de stockage flash .

Le diagramme montre un cluster à plusieurs nœuds. Chaque nœud a deux cartes réseau pour le stockage et deux pour la gestion et le calcul. Les cartes de stockage se connectent à un réseau de stockage. Les cartes de gestion et de calcul se connectent à un réseau de gestion et de calcul. Sous la couche réseau, le diagramme montre la pile de stockage. Il commence par les disques physiques en bas, qui incluent les disques NVMe dans les niveaux de cache et les disques SSD dans les niveaux de capacité. Au-dessus des disques se trouve le pool de stockage Storage Spaces Direct. La couche suivante de cette section est le système de fichiers ReFS sur un fichier CSV. La couche suivante inclut des disques virtuels pour les machines virtuelles. La couche supérieure affiche deux machines virtuelles, avec une flèche qui indique qu’elles peuvent être migrées en direct entre les nœuds.

Le type de lecteur de disque physique influence les performances de votre stockage de cluster. Le type de lecteur varie en fonction des caractéristiques de performances de chaque type de lecteur et du mécanisme de mise en cache que vous choisissez. Le type de lecteur de disque physique fait partie intégrante de toute conception et configuration d’espaces de stockage direct. Selon les exigences de charge de travail locales Azure et les contraintes budgétaires, vous pouvez choisir d’optimiser les performances, d’optimiserla capacité ou d’implémenter une configuration de type de lecteur mixte qui équilibre les performances et la capacité.

Pour les charges de travail à usage général qui nécessitent un stockage persistant à grande capacité, une configuration de stockage hybride peut fournir le stockage le plus utilisable, comme l’utilisation de disques NVMe ou de disques SSD pour le niveau de cache et les disques DURS pour la capacité. Le compromis est que les lecteurs de rotation ont des performances et des capacités de débit inférieures par rapport aux lecteurs flash. Ces limitations peuvent affecter les performances du stockage si votre charge de travail dépasse le jeu de travail du cache. En outre, les disques durs ont un temps moyen entre pannes plus faible comparé aux disques NVMe et aux disques SSD.

Les espaces de stockage direct fournissent un cache intégré côté serveur persistant qui prend en charge les opérations de lecture et d’écriture. Ce cache optimise les performances de stockage. Dimensionner et configurer le cache pour prendre en charge l’ensemble de travail de vos applications et charges de travail. Les disques virtuels de Storage Spaces Direct, ou volumes, sont utilisés en combinaison avec le cache de lecture en mémoire du volume partagé de cluster pour améliorer les performances d'Hyper-V. Cette combinaison est particulièrement efficace pour l’accès d’entrée non chiffré aux fichiers de disque dur virtuel de charge de travail (VHD) ou v2 (VHDX).

Tip

Pour les charges de travail à haute performance ou sensibles à la latence, nous vous recommandons d’utiliser une configuration de stockage tout flash (tous NVMe ou ssd) et une taille de cluster de trois machines physiques ou plus. Le déploiement de cette conception avec les paramètres de de configuration de stockage par défaut utilise de mise en miroir tridirectionnel pour les volumes d’infrastructure et d’utilisateur. Cette stratégie de déploiement offre les performances et la résilience les plus élevées. Lorsque vous utilisez une configuration all-NVMe ou all-SSD, vous bénéficiez de la capacité de stockage utilisable complète de chaque lecteur flash. Contrairement aux configurations NVMe et SSD hybrides ou mixtes, aucune capacité n’est réservée à la mise en cache lorsque vous utilisez un seul type de lecteur. Cette configuration garantit une utilisation optimale de vos ressources de stockage. Pour plus d’informations sur la façon d’équilibrer les performances et la capacité pour répondre aux exigences de votre charge de travail, consultez Planifier les volumes - Quand les performances importent le plus.

Conception du réseau

La conception du réseau est la disposition globale 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 physique pour toutes les combinaisons d’intentions de gestion, de calcul et de réseau de stockage. L’utilisation des mêmes ports de carte réseau à toutes fins liées à l’intention est appelée configuration réseau entièrement convergée.

Une configuration réseau entièrement convergée est prise en charge, mais la configuration optimale pour garantir des performances et une fiabilité maximales consiste à utiliser des ports de carte réseau dédiés pour le stockage. Par conséquent, cette architecture de base fournit des exemples d’instructions pour déployer une instance locale Azure à plusieurs nœuds à l’aide de l’architecture réseau commutée de stockage avec deux ports de carte réseau convergés pour la gestion et les intentions de calcul et deux ports de carte réseau dédiés pour l’intention de stockage. Pour plus d’informations, consultez Considérations relatives au réseau pour les déploiements cloud d’Azure Local.

Cette architecture nécessite deux machines physiques ou plus et jusqu’à un maximum de 16 machines à l’échelle. Chaque machine 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 multi-châssis (MLAG). Les deux ports de carte réseau utilisés pour le trafic d’intention de stockage doivent prendre en charge accès à la mémoire directe à distance (RDMA). Ces ports nécessitent une vitesse minimale de liaison de 10 gigaoctets par seconde (Gbit/s), mais nous vous recommandons une vitesse de 25 Gbits/s ou plus. Les deux ports de carte réseau utilisés pour la gestion et les intentions de calcul sont convergés à l’aide de la technologie SET (Switch Embedded Teaming). 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 Gbit/s, mais nous recommandons une vitesse de 10 Gbits/s ou plus.

Topologie de réseau physique

La topologie de réseau physique suivante montre les connexions réseau physiques entre les machines locales Azure et les composants réseau.

Vous avez besoin des composants suivants lorsque vous concevez un déploiement Azure Local à plusieurs nœuds qui utilise cette architecture de référence.

L’image montre la topologie de réseau physique pour une instance locale Azure à plusieurs nœuds qui utilise une architecture de stockage commutée avec des commutateurs ToR doubles. Le diagramme met en évidence les connexions entre les machines physiques, les commutateurs ToR et les réseaux externes. Il met l’accent sur la redondance et les ports compatibles RDMA dédiés pour le trafic de stockage.

• Commutateurs Double ToR :

  • Les commutateurs réseau Double ToR sont requis pour la résilience réseau et pour le service ou pour appliquer des mises à jour de microprogramme aux commutateurs sans temps d’arrêt. Cette stratégie empêche un point de défaillance unique (SPoF).

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

  • Ces commutateurs se connectent aux machines physiques via des câbles Ethernet.

• Deux machines physiques ou plus et jusqu’à un maximum de 16 machines physiques :

  • Chaque machine est un serveur physique qui exécute le système d’exploitation Azure Stack HCI.

  • Chaque ordinateur 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 fournit une redondance de chemin de liaison et une bande passante hiérarchisée dédiée pour le trafic de stockage direct SMB.

  • 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, tel que le réseau local interne de l'entreprise, pour permettre l'accès aux URL sortantes nécessaires à l'aide de votre dispositif de périmètre réseau. Cet appareil peut être un pare-feu ou un routeur. Ces commutateurs routent le trafic entrant et sortant de l’instance locale Azure ou du trafic nord-sud.

  • La connectivité du trafic nord-sud externe prend en charge l’intention de gestion du cluster et les intentions de calcul. Cette configuration réseau est obtenue à l’aide de deux ports de commutateur et de deux ports de carte réseau pour chaque machine convergée via SET et un commutateur virtuel dans Hyper-V pour garantir la résilience. Ces composants fournissent une connectivité externe pour les machines virtuelles locales Azure et d’autres ressources de charge de travail déployées dans les réseaux logiques créés dans Resource Manager à l’aide du portail Azure, d’Azure CLI ou de modèles IaC.

Topologie de réseau logique

La topologie de réseau logique montre une vue d’ensemble de la façon dont les données réseau circulent entre les appareils, quelles que soient leurs connexions physiques.

L’exemple suivant montre une synthèse de la configuration logique pour cette architecture de base de référence commutée de stockage à plusieurs nœuds pour Azure Local.

Le diagramme montre la topologie de réseau logique pour une instance locale Azure à plusieurs nœuds qui utilise une architecture commutée de stockage. Il illustre le flux de trafic réseau entre les composants. Le diagramme montre deux nœuds physiques, chacun avec plusieurs cartes réseau. Network ATC est utilisé pour définir des intentions concernant le trafic de gestion, de calcul et de stockage. Les intentions de gestion et de calcul sont convergées vers un commutateur virtuel qui utilise un SET. L’intention de stockage utilise des adaptateurs compatibles RDMA dédiés. Le diagramme illustre également les réseaux logiques pour les machines virtuelles et la connexion au réseau externe via les commutateurs ToR.

• Commutateurs Double ToR :

  • Avant de déployer le cluster, les deux commutateurs réseau ToR doivent être configurés avec les ID VLAN 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 plus d’informations, consultez configuration réseau physique requise pour Azure Local, ou demandez à votre fournisseur de matériel de commutateur ou partenaire SI d’obtenir de l’aide.

• ATC réseau :

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

  • Azure Local 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 et un flux de trafic réseau optimaux en utilisant des intentions de trafic réseau. Network ATC définit les ports de carte réseau physiques utilisés pour les différentes intentions de trafic réseau (ou types), comme pour la gestion du cluster, le calcul de charge de travail et les intentions de stockage de cluster.

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

• Communication externe :

  • Lorsque les machines physiques ou la charge de travail doivent communiquer en externe en accédant au réseau local d’entreprise, à Internet ou à un autre service, ils routent via les commutateurs ToR doubles.

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

  • L’intention du réseau de gestion utilise l’interface virtuelle de l’équipe SET convergée, qui permet aux ressources de plan de contrôle et d’adresse IP de gestion du cluster de communiquer en externe.

  • 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’un SET team pour les besoins de calcul et de gestion.

• Trafic de stockage :

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

  • Les ports de stockage SMB1 et SMB2 se connectent à deux réseaux distincts (ou couche 2). Chaque réseau dispose d’un ID de réseau local virtuel spécifique configuré qui doit correspondre à la configuration des ports de commutateur sur le ID de réseau local virtuel de stockage par défaut : 711 et 712.

  • Il n'est configurée aucune passerelle par défaut sur les deux ports des adaptateurs réseau pour l'intention de stockage dans le système d’exploitation Azure Stack HCI.

  • Chaque nœud de cluster peut accéder aux fonctionnalités directes des espaces de stockage du cluster, telles que les lecteurs 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 biais du protocole RDMA SMB-Direct sur les deux ports de carte réseau de stockage dédiés disponibles sur chaque ordinateur. SMB Multichannel est utilisé pour la résilience.

  • Cette configuration fournit une vitesse de transfert de 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.

Configuration requise pour le commutateur réseau

Vos commutateurs Ethernet doivent respecter les différentes spécifications requises par Azure Local 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 la spécification PFC IEEE 802.1Qbb pour garantir une communication sans perte pour la classe de trafic de stockage . Vos commutateurs ToR doivent prendre en charge IEEE 802.1Q pour les réseaux locaux virtuels et IEEE 802.1AB pour le protocole de découverte de couche de liaison.

Si vous envisagez d’utiliser des commutateurs réseau existants pour un déploiement local Azure, passez en revue la liste des normes et spécifications IEEE obligatoires que les commutateurs réseau et la configuration doivent fournir. Lorsque vous achetez de nouveaux commutateurs réseau, passez en revue la liste des modèles de commutateur certifiés par le fournisseur de matériel qui prennent en charge les exigences du réseau local Azure.

Exigences relatives à l’adresse IP

Dans un déploiement commuté de stockage à plusieurs nœuds, le nombre d’adresses IP nécessaires augmente avec l’ajout de chaque machine physique, jusqu’à un maximum de 16 machines physiques au sein d’un seul cluster. Par exemple, pour déployer une configuration commutée de stockage à deux nœuds d’Azure Local, l’infrastructure de cluster nécessite un minimum de 11 adresses IP x à allouer. D’autres adresses IP sont requises si vous utilisez la micro-segmentation ou la mise en réseau définie par logiciel. Pour plus d’informations, consultez Passer en revue les exigences d’adresse IP du modèle de référence de stockage à deux nœuds pour azure Local.

Lorsque vous concevez et planifiez les exigences d’adresse IP pour Azure Local, n’oubliez pas de tenir compte des adresses IP supplémentaires ou des plages réseau nécessaires à votre charge de travail au-delà des exigences de l’instance locale Azure et des composants d’infrastructure. Si vous envisagez de déployer AKS sur Azure Local, consultez AKS activé par la configuration réseau requise pour Azure Arc.

Connectivité réseau sortante

Il est important de comprendre les exigences de connectivité réseau sortante d’Azure Local et de prendre en compte ces exigences dans votre plan de conception et d’implémentation avant de déployer la solution. La connectivité réseau sortante est nécessaire pour permettre à Azure Local de communiquer avec Azure et Azure Arc pour les opérations de plan de gestion et de contrôle. Par exemple, la connectivité sortante est nécessaire pour approvisionner des ressources compatibles Avec Azure Arc, telles que des machines virtuelles locales Azure ou des clusters AKS, et pour utiliser des services de gestion Azure tels que Update Manager et Azure Monitor.

La planification initiale et la diligence raisonnable pour permettre la communication réseau avec les points de terminaison publics requis est extrêmement importante lorsque vous intégrez Azure Local à un réseau de centre de données local existant. Cette exigence est particulièrement importante si vous avez des règles de sortie strictes configurées sur des appareils proxy ou pare-feu. En outre, si vos contrôles de sécurité réseau incluent des technologies d’inspection SSL (Secure Sockets Layer), sachez que l’inspection SSL n’est pas prise en charge pour la communication de réseau local Azure.

Pourquoi la connectivité réseau sortante est importante

La connectivité réseau sortante est requise à partir de votre instance Locale Azure. Cette exigence inclut les machines physiques, l’appliance de pont de ressources Azure Arc , les clusters AKS et les machines virtuelles locales Azure si vous utilisez Azure Arc pour la gestion du système d’exploitation invité de la machine virtuelle. Ces appareils disposent d'agents locaux ou de services qui se connectent aux points de terminaison publics en utilisant l'accès réseau sortant pour une communication en temps réel, permettant ainsi la connectivité aux fournisseurs de ressources du plan de gestion et de contrôle qui s'exécutent dans Azure. Par exemple, la connectivité sortante est nécessaire pour que les opérateurs utilisent le portail Azure, l’interface de ligne de commande Azure ou les outils IaC tels que ARM, Bicep ou Terraform pour approvisionner des ressources, les gérer ou effectuer les deux actions. Azure et le pont des ressources Azure Arc fonctionnent en combinaison avec la ressource d’emplacement personnalisée de votre instance Azure Local. Cette combinaison vous permet de cibler l’instance locale Azure spécifique pour toutes les opérations CRUD de ressources (créer, lire, mettre à jour ou supprimer) pour vos ressources de charge de travail avec Azure Arc.

Pour activer la connectivité, configurez votre pare-feu, votre proxy ou votre technologie de sortie Internet, ou une combinaison de ces composants, pour autoriser l’accès sortant aux points de terminaison publics requis. Tenez compte des considérations clés suivantes pour les exigences du réseau sortant local Azure :

• Azure Local ne prend pas en charge l’inspection des paquets SSL/TLS le long des chemins de mise en réseau de vos instances locales Azure vers les points de terminaison publics. En outre, Private Link et Azure ExpressRoute ne sont pas pris en charge pour la connectivité aux points de terminaison publics requis. Pour plus d’informations, consultez exigences du pare-feu pour Azure Local.

• Envisagez d’utiliser la passerelle Azure Arc pour simplifier les exigences de connectivité. Cette approche réduit considérablement le nombre de points de terminaison requis qui doivent être ajoutés à vos règles de pare-feu ou de proxy pour le déploiement et la gestion d’Azure Local.

• Lorsque vous déployez Azure Local à l’aide d’un serveur proxy pour contrôler et gérer l’accès à la sortie Internet, passez en revue les exigences du proxy.

Monitoring

Insights pour Azure Local repose sur Azure Monitor et Log Analytics, ce qui garantit une solution toujours up-to-date et évolutive hautement personnalisable. Insights fournit l’accès aux classeurs par défaut avec des métriques de base, ainsi que des classeurs spécialisés créés pour la surveillance des fonctionnalités clés d’Azure Local. Ces composants fournissent une solution de supervision en temps quasi réel et permettent la création de graphiques, la personnalisation des visualisations via l’agrégation et le filtrage, ainsi que la configuration des règles d’alerte d’intégrité des ressources personnalisées.

Pour améliorer la surveillance et les alertes, activez Azure Monitor Insights sur Azure Local. Insights peut être mis à l’échelle pour surveiller et gérer plusieurs instances locales via une expérience cohérente avec Azure. Insights utilise des compteurs de performances de cluster et des canaux de journal des événements pour surveiller les principales fonctionnalités locales d’Azure. La DCR, qui est configurée via Azure Monitor et Log Analytics, collecte les journaux.

Gestion des mises à jour

Les instances locales Azure et les ressources de charge de travail déployées, telles que les machines virtuelles locales Azure, doivent être mises à jour et corrigées régulièrement. En appliquant régulièrement des mises à jour, vous assurez que votre organisation maintient une posture de sécurité forte. Vous améliorez également la fiabilité globale et la prise en charge de votre patrimoine. Nous vous recommandons d’utiliser des évaluations manuelles automatiques et périodiques pour la détection anticipée et l’application des correctifs de sécurité et des mises à jour du système d’exploitation.

Mises à jour de l’infrastructure

Azure Local est mis à jour en continu pour améliorer l’expérience client et introduire de nouvelles fonctionnalités et fonctionnalités. Les mises à jour des fonctionnalités sont fournies tous les six mois via les trains de mise en production, avec de nouvelles versions publiées en avril (YY04) et octobre (YY10). Outre les mises à jour régulières des fonctionnalités, Azure Local reçoit des mises à jour cumulatives mensuelles qui incluent des améliorations de sécurité et de fiabilité du système d’exploitation, ainsi que des mises à jour des extensions et des agents.

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

• Informations sur la publication locale d’Azure
• Cadence du cycle de vie local Azure
• Passer en revue les phases de mise à jour d’Azure Local
• Utiliser Update Manager pour mettre à jour Azure Local

Il est important de vérifier régulièrement les nouvelles mises à jour du pilote et du microprogramme, comme toutes les trois à six mois. Si vous utilisez une version de catégorie Premier Solution pour votre matériel Local Azure, les mises à jour du package SBE (Solution Builder Extension) sont intégrées à Update Manager pour offrir une expérience de mise à jour simplifiée. Si vous utilisez des nœuds validés ou une catégorie de système intégrée, il peut être 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 matériel.

Mise à jour corrective du système d’exploitation invité de charge de travail

Vous pouvez inscrire des machines virtuelles locales Azure déployées sur Azure Local dans Update Manager pour fournir une expérience unifiée de gestion des correctifs à l’aide du même mécanisme utilisé pour mettre à jour les machines physiques de l’instance locale Azure. Vous pouvez utiliser Update Manager pour créer des configurations de maintenance invité. Ces configurations contrôlent les paramètres tels que le redémarrage du paramètre de 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 locales Azure 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 dans le système d’exploitation invité de votre machine virtuelle de charge de travail.

Considerations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

Identifier les points d’échec potentiels

Chaque architecture est susceptible d’être défaillante. Vous pouvez anticiper les défaillances et être préparé avec des atténuations à l’aide de l’analyse du mode d’échec (FMA). Le tableau suivant décrit quatre exemples de points de défaillance potentiels dans cette architecture.

Component	Risk	Likelihood	Impact et atténuation	Outage
Panne d’instance locale Azure	Panne de l’alimentation, du réseau, du matériel ou du logiciel	Medium	Pour éviter une panne prolongée d’application causée par l’échec d’une instance locale Azure pour les cas d’usage critiques ou critiques pour l’entreprise, votre charge de travail doit être conçue à l’aide des principes de haute disponibilité et de récupération d’urgence. Par exemple, vous pouvez utiliser des technologies de réplication de données de charge de travail standard pour gérer plusieurs copies des données d’état persistant déployées à l’aide de plusieurs machines virtuelles locales Azure ou d’instances AKS déployées sur des instances azure locales distinctes et dans des emplacements physiques distincts.	Panne potentielle
Panne d’ordinateur physique unique Azure Local	Panne de l’alimentation, du matériel ou du logiciel	Medium	Pour éviter une panne prolongée de l’application causée par l’échec d’une seule machine locale Azure, votre instance Azure Local doit avoir plusieurs machines physiques. Vos besoins en capacité de charge de travail pendant la phase de conception du cluster déterminent le nombre de machines physiques. Nous vous recommandons d’avoir trois machines physiques ou plus. Nous vous recommandons également d’utiliser la mise en miroir tridirectionnel, qui est le mode de résilience de stockage par défaut pour les clusters avec trois machines physiques ou plus. Pour empêcher un SPoF et augmenter la résilience des charges de travail, déployez plusieurs instances de votre charge de travail à l’aide de deux machines virtuelles locales Azure ou de pods de conteneur qui s’exécutent sur plusieurs nœuds worker AKS. En cas d’échec d’une seule machine, les machines virtuelles locales Azure et les services d’application ou de charge de travail sont redémarrés sur les machines physiques en ligne restantes dans le cluster.	Panne potentielle
Machine virtuelle locale Azure ou nœud Worker AKS (charge de travail)	Misconfiguration	Medium	Les utilisateurs de l’application ne peuvent pas se connecter ou accéder à l’application. Identifiez les configurations incorrectes pendant le déploiement. Si ces erreurs se produisent pendant une mise à jour de configuration, l’équipe DevOps doit restaurer les modifications. Vous pouvez redéployer la machine virtuelle si nécessaire. Le redéploiement prend moins de 10 minutes pour le déploiement, mais peut prendre plus de temps en fonction du type de déploiement.	Panne potentielle
Connectivité à Azure	Panne du réseau	Medium	Azure Local nécessite une connectivité réseau à Azure pour que les opérations de plan de contrôle soient disponibles. Par exemple, pour approvisionner de nouvelles machines virtuelles locales Azure ou clusters AKS, installez des mises à jour de solution à l’aide de Update Manager ou surveillez l’état d’intégrité de l’instance à l’aide d’Azure Monitor. Si la connectivité à Azure n’est pas disponible, l’instance fonctionne dans un état détérioré, où ces fonctionnalités ne sont pas disponibles. Toutefois, les charges de travail existantes qui s’exécutent déjà sur Azure Local continuent à s’exécuter. Si la connectivité réseau à Azure n’est pas restaurée dans les 30 jours, l’instance entre un état « Hors stratégie », ce qui peut limiter les fonctionnalités. L’appliance de pont de ressources Azure ne peut pas être hors connexion pendant plus de 45 jours, car cette inactivité peut affecter la validité de la clé de sécurité utilisée pour l’authentification.	Opérations de gestion indisponibles

Pour plus d’informations, consultez Recommandations relatives à l’exécution de FMA.

Cibles de fiabilité

Cette section décrit un exemple de scénario. Un client fictif appelé Contoso Manufacturing utilise cette architecture de référence pour déployer Azure Local. Ils souhaitent répondre à leurs besoins et déployer et gérer des charges de travail locales. Contoso Manufacturing a un objectif de niveau de service interne (SLO) de 99,8% que les parties prenantes de l’entreprise et de l’application conviennent de leurs services.

• Un SLO de 99,8% temps d’activité ou de disponibilité entraîne les périodes suivantes de temps d’arrêt autorisé, ou d’indisponibilité, pour les applications déployées à l’aide de machines virtuelles locales Azure qui s’exécutent sur Azure Local :

  • Hebdomadaire : 20 minutes et 10 secondes

  • Mensuel : 1 heure, 26 minutes et 56 secondes

  • Trimestre : 4 heures, 20 minutes et 49 secondes

  • Annuel : 17 heures, 23 minutes et 16 secondes

• Pour aider à atteindre les cibles SLO, Contoso Manufacturing implémente le principe de privilège minimum (PoLP) pour limiter le nombre d’administrateurs d’instances locales Azure à un petit groupe de personnes approuvées et qualifiées. Cette approche permet d’éviter les temps d’arrêt en raison d’actions accidentelles ou accidentelles effectuées sur les ressources de production. En outre, les journaux des événements de sécurité pour les contrôleurs de domaine Ad DS (Active Directory Domain Services) locaux 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 administrateurs d’instances locales Azure qui utilise une solution SIEM. La surveillance augmente la fiabilité et améliore la sécurité de la solution.

  Pour plus d’informations, consultez Recommandations pour la gestion des identités et des accès.

• procédures strictes de contrôle des modifications sont en place pour les systèmes de production de Contoso Manufacturing. Ce processus nécessite que toutes les modifications soient testées et validées dans un environnement de test représentatif avant l’implémentation en production. Toutes les modifications soumises au processus hebdomadaire du conseil consultatif des modifications doivent inclure un plan d’implémentation détaillé (ou un lien vers le code source), un score de niveau de risque, un plan de restauration complet, des tests et des vérifications post-mise en production, et des critères de réussite clairs pour une modification à examiner ou approuver.

  Pour plus d’informations, consultez Recommandations relatives aux pratiques de déploiement sécurisé.

• Les correctifs de sécurité mensuels et les mises à jour de base trimestrielles sont appliqués aux instances locales Azure de production uniquement après leur validation par l’environnement de préproduction. Update Manager et la fonctionnalité de mise à jour prenant en charge le cluster automatisent le processus d’utilisation de migration dynamique de machine virtuelle pour réduire les temps d’arrêt des charges de travail critiques pour l’entreprise pendant les opérations de maintenance mensuelles. Les procédures d’exploitation standard de Contoso Manufacturing nécessitent que les mises à jour de build de sécurité, de fiabilité ou de base de référence soient appliquées à tous les systèmes de production dans les quatre semaines suivant 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 la sécurité. Les systèmes obsolètes affectent négativement la fiabilité et la sécurité de la plateforme.

  Pour plus d’informations, consultez Recommandations pour établir 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 (lundis à samedis), les 3 x dernières sauvegardes hebdomadaires (chaque dimanche) et 3 x sauvegardes mensuelles, chaque semaine du dimanche 4 étant conservée pour devenir les sauvegardes mensuelles 1, mois 2 et mois 3 à l’aide d’une planification basée sur un calendrier propagé documenté et auditable. Cette approche répond aux exigences de fabrication de Contoso pour un équilibre adéquat entre le nombre de points de récupération de données disponibles et la réduction des coûts pour le service de stockage de sauvegarde hors site ou cloud.

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

• processus de sauvegarde et de récupération des données sont testés pour chaque système métier tous les six mois. Cette stratégie garantit que les processus BCDR sont valides et que l’entreprise est protégée en cas de sinistre ou de cyber-incident de centre de données.

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

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

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

Redundancy

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

Utilisez des modèles de haute disponibilité standard pour les charges de travail qui fournissent une réplication active/passive, une réplication synchrone ou une réplication asynchrone telle que SQL Server Always On. Vous pouvez également utiliser une technologie d’équilibrage de charge réseau externe qui achemine les requêtes utilisateur sur plusieurs instances de charge de travail qui s’exécutent sur des instances locales Azure que vous déployez dans des emplacements physiques distincts. Envisagez d’utiliser 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 locaux, telles qu’une instance Azure Application Gateway qui utilise ExpressRoute ou un tunnel VPN pour se connecter à un service local.

Pour plus d’informations, consultez Recommandations de conception pour la redondance.

Security

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

• Une base sécurisée pour la plateforme locale Azure :Azure Local est un produit sécurisé par défaut qui utilise des composants matériels validés avec un module TPM, UEFI et un démarrage sécurisé pour créer une base sécurisée pour la plateforme locale Azure 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 Local a le contrôle d’application, Credential Guard et BitLocker activé. Pour simplifier la délégation des autorisations à l’aide de PoLP, utilisez des rôles de contrôle d’accès en fonction du rôle intégré Azure Local (RBAC), tels qu’Administrateur local Azure pour les administrateurs de plateforme et Contributeur de machine virtuelle locale Azure ou Lecteur de machine virtuelle locale Azure pour les opérateurs de charge de travail.

• Paramètres de sécurité par défaut : Azure Local applique les paramètres de sécurité par défaut pour votre instance Locale Azure pendant le déploiement et permet au contrôle de dérive de conserver les machines physiques 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 des événements de sécurité :le transfert syslog local Azure 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 rétention dans votre propre plateforme SIEM.

• Protection contre les menaces et les vulnérabilités :Defender pour Cloud protège votre instance locale Azure contre diverses menaces et vulnérabilités. Ce service permet d’améliorer la posture de sécurité de votre environnement local Azure 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, telles que les menaces ciblant AD DS, qui fournissent des services d’authentification aux machines d’instance locale Azure et à leurs charges de travail de machine virtuelle Windows Server.

• isolation réseau : isoler les réseaux si nécessaire. Par exemple, vous pouvez approvisionner plusieurs réseaux logiques qui utilisent des réseaux locaux virtuels distincts et des plages d’adresses réseau. Lorsque vous utilisez cette approche, assurez-vous que le réseau de gestion peut atteindre chaque réseau logique et réseau local virtuel afin que les machines physiques d’instance locale Azure puissent communiquer avec les réseaux VLAN via les commutateurs toR ou les passerelles. Cette configuration est requise pour la gestion de la charge de travail, par exemple pour permettre aux agents de gestion de l’infrastructure de communiquer avec le système d’exploitation invité de la charge de travail.

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

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

• Modèle de facturation de style cloud pour les licences : La tarification Locale Azure suit le modèle de facturation d’abonnement mensuel avec un tarif forfaitaire pour chaque cœur de processeur physique dans une instance locale Azure. Des frais d’utilisation supplémentaires s’appliquent si vous utilisez d’autres services Azure. Si vous possédez des licences principales locales pour l’édition Windows Server Datacenter avec Software Assurance active, vous pouvez choisir d’échanger ces licences pour activer les frais d’abonnement à l’instance locale Azure et à la machine virtuelle Windows Server.

• Mise à jour corrective automatique des invités de machine virtuelle pour les machines virtuelles locales Azure : Cette fonctionnalité permet de réduire la surcharge liée à la mise à jour corrective manuelle et aux coûts de maintenance associés. Non seulement cette action contribue-t-elle à rendre le système plus sécurisé, mais il optimise également l’allocation des ressources et contribue à l’efficacité globale des coûts.

• Consolidation de la surveillance des coûts : Pour consolider les coûts de supervision, utilisez Azure Local Insights et patch à l’aide de Update Manager pour Azure Local. Azure Local Insights utilise Azure Monitor pour fournir des métriques et des fonctionnalités d’alerte enrichies. Le composant Gestionnaire de cycle de vie d’Azure Local s’intègre à Update Manager pour simplifier la tâche de maintenir vos clusters up-to-date en consolidant les flux de travail de mise à jour pour différents composants en une seule expérience. Utilisez Azure Monitor et Update Manager pour optimiser l’allocation des ressources et contribuer à l’efficacité globale des coûts.

  Pour plus d’informations, consultez Recommandations pour optimiser le temps du personnel.

• Capacité et croissance de la charge de travail initiales : Lorsque vous planifiez votre déploiement local Azure, tenez compte de la capacité de votre charge de travail initiale, des exigences de résilience et des considérations de croissance futures. Envisagez d’utiliser une architecture sans commutateur de stockage à deux, trois ou quatre nœuds pour potentiellement réduire les coûts, comme par exemple en éliminant la nécessité d'acquérir des commutateurs réseau de classe stockage. L’achat de commutateurs réseau de classes de stockage supplémentaires peut être un composant coûteux des nouveaux déploiements d’instances locales Azure. Au lieu de cela, vous pouvez utiliser des commutateurs existants pour la gestion et les réseaux de calcul, ce qui simplifie l’infrastructure. Si la capacité et la résilience de votre charge de travail ne sont pas mises à l’échelle au-delà d’une configuration à quatre nœuds, envisagez d’utiliser des commutateurs existants pour les réseaux de gestion et de calcul, et utilisez l’architecture sans commutateur de stockage pour déployer Azure Local.

  Pour plus d’informations, consultez Recommandations pour optimiser les coûts des composants.

Tip

Vous pouvez réduire les coûts par le biais d’Azure Hybrid Benefit si vous conservez des licences Windows Server Datacenter qui incluent l’assurance logicielle active. Pour plus d’informations, consultez Azure Hybrid Benefit pour Azure Local.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

• Expérience de gestion et d’approvisionnement simplifiée intégrée à Azure : Le déploiement basé sur le cloud dans Azure fournit une interface pilotée par l’Assistant qui vous montre comment créer une instance locale Azure. De même, Azure simplifie le processus de gestion des instances locales Azure et des machines virtuelles locales Azure. Vous pouvez automatiser le déploiement basé sur le portail de l’instance locale Azure à l’aide de ce modèle ARM. L’utilisation de modèles fournit une cohérence et une automatisation pour déployer Azure Local à grande échelle, en particulier dans des scénarios de périphérie tels que des magasins de vente au détail ou des sites de fabrication qui nécessitent une instance locale Azure pour exécuter des charges de travail critiques pour l’entreprise.

• Fonctionnalités d’automatisation pour les machines virtuelles Azure : Azure Local fournit un large éventail de fonctionnalités d’automatisation pour la gestion des charges de travail, telles que les machines virtuelles locales Azure. Ces fonctionnalités incluent le déploiement automatisé de machines virtuelles locales Azure à l’aide d’Azure CLI, de modèles ARM ou de modèles Bicep. Les mises à jour du système d’exploitation de machine virtuelle sont fournies via l’extension Azure Arc pour les mises à jour et Update Manager, qui applique les mises à jour à chaque instance locale Azure. Azure Local assure également la prise en charge de la gestion des machines virtuelles locales Azure à l’aide d’Azure CLI et de machines virtuelles non-Azure locales à l’aide de Windows PowerShell. Vous pouvez exécuter les commandes Azure CLI localement à partir de l’une des machines locales Azure 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 machine virtuelle via les extensions Azure Arc.

  Pour plus d’informations, consultez Recommandations pour l’utilisation de l'IaC.

• Fonctionnalités d’automatisation pour les conteneurs sur AKS : Azure Local fournit un large éventail de fonctionnalités d’automatisation pour la gestion des charges de travail, telles que des conteneurs, sur AKS. Vous pouvez automatiser le déploiement de clusters AKS à l’aide d’Azure CLI. Utilisez l’extension Azure Arc pour les mises à jour Kubernetes pour mettre à jour les clusters de charge de travail AKS. Vous pouvez également gérer AKS activé par Azure Arc l’aide d’Azure CLI. Vous pouvez exécuter les commandes Azure CLI localement à partir de l’une des machines locales Azure 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 plus d’informations, consultez les ressources suivantes :

  • Recommandations pour l’activation de l’automatisation
  • Comparer les fonctionnalités de gestion des machines virtuelles sur Azure Local

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

• Performances du stockage de charge de travail : Envisagez d’utiliser l’outil DiskSpd pour tester les fonctionnalités de performances de stockage de charge de travail d’une instance locale Azure. 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.

  Nous vous recommandons d’établir une base de référence pour les performances de vos instances locales Azure avant de déployer des charges de travail de production. 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 consiste à émettre des opérations de lecture et d’écriture et des métriques de performances de sortie, telles que la latence, le débit et les E/S par seconde.

  Pour plus d’informations, consultez Recommandations pour les tests de performances.

• Résilience du stockage de 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 locaux Azure inclut l’identification de l’équilibre optimal entre la résilience, l’efficacité de l’utilisation et les performances. Il peut être difficile d’optimiser cet équilibre, car l’optimisation de l’une de ces caractéristiques a généralement un effet négatif sur une ou plusieurs des autres caractéristiques. L’augmentation de la résilience réduit la capacité utilisable. Par conséquent, les performances peuvent varier en fonction du type de résilience choisi. Lorsque la résilience et les performances sont la priorité et que vous utilisez trois machines physiques ou plus, la configuration de stockage par défaut utilise la mise en miroir tridirectionnel pour les volumes d’infrastructure et d’utilisateur.

  Pour plus d’informations, consultez Recommandations pour 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é lorsque vous déterminez votre configuration matérielle réseau optimale.

  Pour optimiser les performances de calcul dans Azure Local, vous pouvez utiliser l’accélération GPU. L’accélération GPU est bénéfique pour charges de travail d’IA ou de Machine Learning hautes performances qui impliquent des insights de données ou une inférence. Ces charges de travail nécessitent un déploiement à des emplacements de 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 local, 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 instances locales Azure.

  Pour plus d’informations, 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 générales ou de flux de travail standard utilisés pour déployer Azure Local, y compris les tâches requises et les considérations. Cette liste de flux de travail est conçue comme un exemple de guide uniquement. 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 au projet.

Dans ce scénario, un projet ou un cas d’usage vous oblige à déployer une solution cloud hybride dans un emplacement local ou edge pour fournir un calcul local pour le traitement des données. Il est également nécessaire de maintenir des expériences de gestion et de facturation cohérentes avec Azure. Pour plus d’informations, consultez la section Cas d’usage potentiels de cet article. Les étapes restantes supposent qu’Azure Local est la solution de plateforme d’infrastructure choisie pour le projet.

1. Rassemblez les exigences en matière de charge de travail et de cas d’usage auprès des parties prenantes pertinentes. Cette stratégie permet au projet de confirmer que les fonctionnalités et les fonctionnalités d’Azure Local répondent aux exigences relatives à l’échelle, aux performances et aux fonctionnalités de la charge de travail. Ce processus de révision 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 locales Azure, AKS, Virtual Desktop ou les services de données avec Azure Arc ou le service Machine Learning avec Azure Arc. Les valeurs RTO et RPO de charge de travail (fiabilité) et d’autres exigences non fonctionnelles (performances et scalabilité de charge) doivent être documentées dans le cadre de cette étape.

2. Examinez le résultat de l'outil de dimensionnement local Azure pour la solution de matériel recommandée par le partenaire. Cette sortie inclut des détails sur la marque et le modèle du matériel du serveur physique recommandés, le nombre de machines physiques, ainsi que les spécifications de la configuration du processeur, de la mémoire et du stockage pour chaque nœud physique afin de déployer et pour exécuter vos charges de travail.

3. Utilisez l’outil de dimensionnement local Azure pour créer un projet qui modélise le type et la mise à l’échelle de la charge de travail. Ce projet inclut la taille et le nombre de machines virtuelles et leurs besoins de stockage. Ces détails sont saisis en même temps que les choix concernant le type de système, la famille de processeurs préférée et les exigences de résilience en matière de haute-disponibilité et de tolérance de panne de stockage, comme expliqué dans la section Choix de conception du cluster.

4. Passez en revue le résultat d’Azure Local Sizer pour la solution de partenaire matériel recommandée. Cette solution inclut des détails sur le matériel du serveur physique recommandé (fabrique et modèle), le nombre de machines physiques et les spécifications de l’UC, de la mémoire et de la configuration de stockage pour chaque nœud physique à déployer et exécuter vos charges de travail.

5. Contactez le partenaire OEM ou SI matériel pour qualifier davantage la pertinence de la version matérielle recommandée par rapport à vos besoins en charge de travail. Si elle est disponible, 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 matériel pour les aspects commerciaux de la solution. Ces aspects incluent les guillemets, la disponibilité du matériel, les délais d’exécution 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 instances locales Azure nécessitent le déploiement de deux commutateurs ToR. Chaque machine physique nécessite quatre cartes réseau, dont deux doivent être compatibles RDMA, qui fournissent deux liens entre chaque machine et les deux commutateurs ToR. Deux cartes réseau, une connectée à chaque 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 est-ouest de stockage. Si vous envisagez d’utiliser des commutateurs réseau existants, vérifiez que la création et le modèle de vos commutateurs figurent dans la liste approuvée des commutateurs réseau pris en charge par azure Local.

7. Collaborez avec le partenaire OEM ou SI matériel pour organiser la livraison du matériel. Le partenaire SI ou vos employés sont ensuite tenus d’intégrer le matériel à votre centre de données local ou à votre emplacement de périphérie, comme le racking et l’empilement du matériel, du réseau physique et du câblage d’unité d’alimentation pour les machines physiques.

8. Effectuez le déploiement d’instance locale Azure. Selon la version de votre solution choisie (Solution Premier, Système intégré ou Nœud validé), le partenaire matériel, le partenaire SI ou vos employés peuvent déployer le logiciel local Azure. Cette étape commence par intégrer le système d'exploitation Azure Stack HCI des machines physiques dans des serveurs activés pour Azure Arc, puis démarrer le processus de déploiement pour le cloud local Azure. Les clients et les partenaires peuvent déclencher une demande de support directement avec Microsoft dans le portail Azure en sélectionnant l’icône Support + Résolution des problèmes ou en contactant leur partenaire OEM ou SI matériel, en fonction de la nature de la demande et de la catégorie de solution matérielle.

   Tip

   L’implémentation de référence du système d’exploitation Azure Stack HCI version 23H2 montre comment déployer un déploiement à plusieurs nœuds commutés d’Azure Local à l’aide d’un modèle ARM et d’un fichier de paramètres. Vous pouvez également l’exemple Bicep montre comment utiliser un modèle Bicep pour déployer une instance locale Azure, y compris ses ressources requises.

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

10. Installez des mises à jour mensuelles pour améliorer la sécurité et la fiabilité de la plateforme. Pour maintenir vos instances locales Azure à jour, il est important d’installer les mises à jour logicielles Microsoft et les mises à jour du pilote OEM oem matériel et du microprogramme. 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 matériel pour déterminer le processus d’installation des mises à jour du pilote matériel et du microprogramme, car ce processus peut varier en fonction du type de catégorie de solution matérielle choisi (Premier Solution, Système intégré ou Nœud validé). Pour plus d’informations, consultez Mises à jour de l’infrastructure.

Ressources associées

• conception d’architecture hybride
• options hybrides Azure
• Optimiser l’administration des instances SQL dans les environnements locaux et multiclouds avec Azure Arc

Étapes suivantes

Documentation du produit Microsoft Learn :

• Informations sur la publication locale d’Azure
• AKS sur Azure Local
• Virtual Desktop sur Azure Local
• Qu’est-ce qu’Azure Local Monitoring ?
• Protéger les charges de travail de machine virtuelle à l’aide de Site Recovery sur Azure Local
• Vue d’ensemble d’Azure Monitor
• vue d’ensemble du suivi des modifications et de l’inventaire
• vue d’ensemble Update Manager
• Qu’est-ce que les services de données avec Azure Arc ?
• Qu’est-ce que les serveurs avec Azure Arc ?
• Qu’est-ce que le service de sauvegarde ?
• Vue d’ensemble d’Azure Automation
• Configuration de l’état Azure Automation
• Présentation de cible de calcul Kubernetes dans Machine Learning

Documentation du produit Azure :

• Azure Local
• Azure Arc
• Coffre-fort de clés
• Stockage Blob Azure
• Azure Monitor.
• Azure Policy
• Azure Container Registry
• Defender pour cloud
• Site Recovery
• Backup

Formation Microsoft Learn :

• Configurer Azure Monitor
• Concevoir une solution pour la sauvegarde et la récupération d’urgence
• Présentation d’Azure Arc
• Présentation de akS
• Maintenir vos machines virtuelles mises à jour
• protéger vos machines virtuelles à l’aide du de sauvegarde

Autres ressources :

• déploiement de modèle de mise à l’échelle avec Machine Learning n’importe où - Blog Tech Community
• La réalisation de Machine Learning n’importe où avec AKS et Le Machine Learning avec Azure Arc - Blog Tech Community
• Machine Learning sur AKS hybride et Azure Local à l’aide du Machine Learning avec Azure Arc - Blog de la communauté tech