Planifier des charges de travail Azure Stack HCI
Après avoir vérifié qu’Azure Stack HCI était adapté à l’hébergement de votre charge de travail, vous devez tenir compte de vos besoins en matière d’infrastructure, y compris les composants de calcul, de stockage et de mise en réseau. Ces considérations étant dépendantes de la charge de travail, pour un scénario tel que Contoso, vous devez tenir compte des exigences de performances distinctes de Microsoft SQL Server et de l’infrastructure VDI.
Planifier Azure Stack HCI
Les considérations générales relatives à la planification d’une implémentation Azure Stack HCI sont les suivantes :
- Nombre de serveurs physiques par cluster. Ce nombre doit être compris entre 1 et 16.
- Nombre de domaines d’erreur par cluster. Par défaut, chaque nœud d’un cluster de Storage Spaces Direct est un domaine d’erreur.
- Nombre et type de processeurs par serveur. La première de ces valeurs détermine le nombre de cœurs, et le second leur vitesse.
- Quantité et type de mémoire par serveur, y compris l’utilisation ou non de la mémoire persistante (PMEM).
- Performances du disque, y compris la configuration correspondante de hiérarchisation et de mise en cache.
- Nombre, types et fonctionnalités de vos cartes réseau.
- L’abonnement Azure dans lequel vous allez inscrire votre déploiement Azure Stack HCI, car des frais sont facturés pour les clusters Azure Stack HCI en fonction du type d’abonnement Azure.
Les considérations relatives à la planification concernant les performances et la capacité de stockage sont les suivantes :
- Nombre et types de disques, notamment les disques durs, disques SSD et NVMe.
- Niveaux de résilience de Storage Spaces Direct.
- Configuration de la hiérarchisation et de la mise en cache.
Voici d’autres facteurs réseau à prendre en compte :
- Utilisation de commutateurs réseau ou pas (des petits clusters peuvent utiliser un réseau de maillage complet pour connecter des serveurs entre eux sans commutateur)
- Câblage physique requis pour les cartes (commutés ou pas)
- Commutateurs réseau par cluster et appartenance à ceux-ci
D’autres considérations s’appliquent aux clusters étendus, notamment le nombre de serveurs requis par chaque site et le mode de configuration du cluster. Les deux modes sont :
- Mode actif/passif, dans lequel un site principal désigné est répliqué de manière unidirectionnelle vers un autre site qui fournit des fonctionnalités de reprise d’activité après sinistre.
- Mode actif/actif, dans lequel deux sites répliquent leurs volumes respectifs de façon unidirectionnelle l’un vers l’autre, ce qui fournit une fonctionnalité de basculement en cas d’échec d’un site ou de l’autre. Le mode actif/actif permet de réduire les coûts de continuité de l’activité, car vous n’aurez pas besoin d’un site de récupération d’urgence dédié.
Vos charges de travail prévues affectent tous ces facteurs. En fait, les cas d’usage précédemment étudiés servent de base pour identifier une configuration matérielle Azure Stack HCI optimale. Le catalogue Azure Stack HCI contient une liste de toutes les solutions Azure Stack HCI que les fournisseurs de matériel tiers proposent et que Microsoft approuve.
Planifier le stockage de l’hôte Azure Stack HCI
Pour expliquer simplement, la planification pour le stockage d’hôte Azure Stack HCI implique l’identification de l’équilibre optimal entre la résilience, la capacité et les performances de Storage Spaces Direct. Toutefois, il y a un problème, à savoir que l’optimisation de l’une de ces caractéristiques a généralement un impact négatif sur au moins l’une des deux autres. Par exemple, l’amélioration de la résilience réduit la capacité utilisable, bien que les performances résultantes peuvent varier en fonction du type de résilience.
Lecteurs
Storage Spaces Direct prend en charge les lecteurs de disque dur (HDD), les disques SSD et les lecteurs NVMe (mémoire non volatile Express), notamment PMEM. Le choix du type de lecteur affecte directement les performances de stockage en raison des différences de caractéristiques de performances entre chaque type et le mécanisme de cache.
Cache de Storage Spaces Direct
En général, les espaces de stockage direct affectent les lecteurs à l’une des deux catégories suivantes en fonction du type de lecteur : capacité ou cache.
- Les lecteurs de capacité fournissent un stockage brut pour le cluster et sont généralement plus lents et plus vastes que les lecteurs de cache.
- Les lecteurs de cache sont utilisés pour accélérer les lectures et les écritures dans des lecteurs de capacité plus lents.
Dans les clusters avec plusieurs types de lecteurs, Storage Spaces Direct attribue automatiquement tous les types de lecteurs les plus rapides au cache et utilise les disques restants pour la capacité. Vous pouvez mettre manuellement en cache dans les scénarios où la configuration par défaut ne produit pas de performances optimales.
Symétrie de lecteur
Storage Spaces Direct fonctionne de façon optimale lorsque chaque serveur possède exactement le même nombre et le même type de lecteurs. En général, vous devez configurer votre cluster Storage Spaces Direct de la façon suivante :
- Tous les serveurs ont le même type de lecteur.
- Tous les serveurs ont le même nombre de lecteurs par type.
- Tous les lecteurs ont le même modèle et la même version de microprogramme.
- Tous les lecteurs du même type ont la même taille.
Il est possible que le nombre de lecteurs diffère temporairement en cas de pannes ou lors de l’ajout ou de la suppression de lecteurs. Il existe également une certaine flexibilité avec les modèles et les tailles de lecteur. Par exemple, vous risquez de ne pas pouvoir remplacer un lecteur défaillant par le même modèle. Toutefois, si les lecteurs sont trop différents, vous pourriez finir avec une capacité bloquée ou des performances inégales.
Quorums de cluster et de pool
Dans un cluster de basculement, le terme quorum est le nombre de composants de clustering qui doivent être disponibles pour que ce cluster reste en ligne. Ces composants peuvent inclure les nœuds de cluster et, éventuellement, un témoin. Le terme témoin spécifie une ressource dédiée exclusivement à l’établissement et à la maintenance d’un quorum.
Avec Storage Spaces Direct, il existe deux mécanismes de quorum distincts :
- Le quorum de cluster, qui opère au niveau du cluster et est basé sur les votes des nœuds et un témoin. Les espaces de stockage direct ne prennent pas en charge le témoin de disque, laissant seulement le témoin cloud et le témoin de partage de fichiers comme options viables.
- Le quorum de pool, qui fonctionne au niveau du pool de stockage et est basé sur les votes des nœuds et la résilience du stockage. Pour optimiser la configuration du quorum du pool lors de l’implémentation de Storage Spaces Direct, assurez-vous qu’il existe une configuration de stockage correspondante dans chaque nœud de cluster.
Volumes
Avec les espaces de stockage direct, les volumes vous permettent de regrouper des lecteurs dans le pool de stockage afin de générer une combinaison optimale d’exigences de tolérance de panne, de scalabilité et de performances. Lorsque vous planifiez des volumes Storage Spaces Direct, vous devez tenir compte des éléments suivants :
Nombre de volumes par cluster : Pour optimiser les performances de stockage, le nombre de volumes par serveur doit être un multiple du nombre de serveurs par cluster.
Système de fichiers : Nous vous recommandons d’utiliser le système ReFS (Resilient File System) pour les volumes d’espaces de stockage direct.
Si votre charge de travail demande une fonctionnalité que ReFS ne prend pas encore en charge, vous pouvez utiliser des volumes NTFS à la place pour cette charge de travail (vous pouvez avoir des volumes ReFS et NTFS dans le même cluster).
Taille du volume : La taille d’un volume sur un cluster Azure Stack HCI ne doit pas dépasser 64 To.
Capacité de réserve : Pour optimiser l’utilisation de l’espace disque, envisagez de réserver l’équivalent d’un lecteur de capacité par serveur, jusqu’à quatre lecteurs par cluster.
Type de résilience : La résilience du volume est le mécanisme principal qui protège les données résidant dans le pool de stockage contre les problèmes matériels, comme les défaillances de lecteur ou de serveur. Le choix du type de résilience dépend de la charge de travail.
- Utilisez la mise en miroir pour les volumes qui ont besoin d’optimiser les performances des charges de travail avec des besoins de latence stricts ou un grand nombre d’IOPS aléatoires mixtes, comme les bases de données Microsoft SQL Server ou les machines virtuelles Hyper-V sensibles aux performances.
- Utilisez la double parité pour les volumes qui ont besoin d’optimiser l’efficacité des capacités et pour les charges de travail qui ont des besoins d’E/S moins grands, comme les serveurs de fichiers ou l’infrastructure VDI (Virtual Desktop Infrastructure).
- Utilisez la parité accélérée par miroir pour équilibrer les performances et la capacité des charges de travail qui effectuent beaucoup d’écritures séquentielles, comme les logiciels de sauvegarde.
- Utilisez la résilience imbriquée sur les clusters à deux serveurs qui exécutent des charges de travail de production pour ajouter la résilience à une défaillance de lecteur qui se produit pendant qu’un serveur est hors connexion. Vous pouvez utiliser la mise en miroir imbriquée ou la parité à mise en miroir accélérée, en fonction de votre charge de travail.
Planifier la mise en réseau de l’hôte Azure Stack HCI
En termes plus simples, la planification des réseaux hôtes dans Azure Stack HCI implique l’identification de la configuration de l’adaptateur et du commutateur physique que vous utiliserez. En outre, les considérations relatives aux clusters étendus incluent les exigences et la latence des ports réseau inter-sites.
Considérations relatives au réseau physique
Au minimum, les clients doivent veiller à :
- Utiliser un commutateur Azure Stack HCI conforme.
- Connaître les sous-réseaux IP et les réseaux locaux virtuels pour la gestion, le stockage et le trafic de calcul.
D’autres besoins réseau, comme le Data Center Bridging, devront probablement s’intégrer à vos besoins réseau pour votre solution (plus d’informations sur ce sujet ultérieurement).
Network ATC
Network ATC est un nouveau service qui permet de déployer et de gérer la configuration réseau de l’hôte et n’est disponible que sur Azure Stack HCI. Network ATC offre les avantages suivants :
- Simplifie le déploiement de réseau hôte sur l’ensemble du cluster
- Implémente les dernières bonnes pratiques validées par Microsoft
- Garde toutes les configurations de réseau hôte synchronisées dans le cluster
- Corrige les erreurs de configuration de l’administrateur pour empêcher une dérive de configuration
- Simplifie l’expansion de cluster, ce qui permet de s’assurer que de nouveaux serveurs sont déployés exactement comme les autres
Avec Network ATC, vous réduisez la configuration d’hôte à une seule commande ou interface utilisateur (via Windows Admin Center).
RDMA
RDMA est une technologie réseau clé qui fournit une communication à haut débit et à faible latence qui décharge le trafic réseau des processeurs, ce qui libère du temps processeur pour les charges de travail en cours d’exécution. Les configurations Azure Stack HCI peuvent utiliser l’une des deux technologies RDMA courantes :
- (Recommandé) Protocole RDMA sur Internet (iWarp) sur TCP/IP, avec TCP fournissant le contrôle du trafic et la gestion de la congestion
- RDMA sur Ethernet convergé (RoCE) sur UDP/IP, avec Data Center Bridging (DCB)
Si vous ne savez pas trop quelle technologie utiliser, nous vous recommandons d’utiliser iWARP parce qu’il est plus simple à configurer.
Planifier SDN (Software Defined Networking)
Azure Stack HCI comprend SDN (Software Defined Networking), qui peut fournir des services réseau sur votre infrastructure de réseau local virtuel (VLAN) existante, ainsi que virtualiser vos réseaux et fournir des services réseau sur les réseaux virtualisés.
Scénarios SDN sur les réseaux VLAN traditionnels :
- Microsegmentation : Les clients peuvent appliquer des stratégies de liste de contrôle d’accès (ACL) de sécurité pour protéger leurs charges de travail contre les attaques externes et internes.
- Qualité de service (QoS) : Les clients peuvent appliquer des stratégies QoS pour empêcher une machine virtuelle d’application ou de charge de travail de monopoliser la bande passante entière de leurs nœuds de cluster HCI.
- Équilibrage de charge logiciel (SLB) : Les clients peuvent déployer SLB pour distribuer uniformément le trafic réseau des clients entre plusieurs ressources. L’équilibrage de charge logicielle (SLB) permet à plusieurs serveurs d’héberger une même charge de travail, ce qui assure une disponibilité et une scalabilité de haut niveau. Il fournit également des services NAT (Network Address Translation).
Scénarios SDN sur des réseaux virtualisés :
- Virtualisation réseau : Les clients peuvent apporter leurs propres réseaux IP et provisionner des charges de travail sur ces réseaux.
- Microsegmentation : Les clients peuvent appliquer des stratégies de liste de contrôle d’accès (ACL) de sécurité pour protéger leurs charges de travail contre les attaques externes et internes.
- Qualité de service (QoS) : Les clients peuvent appliquer des stratégies QoS pour empêcher une machine virtuelle d’application ou de charge de travail de consommer la bande passante entière de leurs clusters.
- Équilibrage de charge logiciel (SLB) : Les clients peuvent déployer l’équilibrage de charge logiciel pour distribuer uniformément le trafic réseau des clients entre plusieurs ressources. L’équilibrage de charge logiciel permet à plusieurs serveurs d’héberger la même charge de travail, offrant ainsi haute disponibilité et scalabilité. Il fournit également des services NAT (Network Address Translation).
- Appliances virtuelles : Les clients peuvent utiliser leurs propres appliances virtuelles tierces, comme entre autres les pare-feu, les appareils de détection d’intrusion, les équilibreurs de charge, et les attacher aux réseaux virtualisés.
- Connectivité aux réseaux externes : Les clients peuvent utiliser des passerelles SDN pour fournir une connectivité entre leurs réseaux virtualisés et les réseaux externes. SDN fournit une connectivité aux réseaux locaux via Internet ou sur des réseaux dédiés. Il fournit également une connectivité entre les réseaux virtualisés et les réseaux physiques au même endroit.
SDN a trois composants d’infrastructure, et vous pouvez choisir de les déployer tous ou une partie en fonction de vos besoins.
- Contrôleur de réseau : Il s’agit du composant principal du SDN. Le contrôleur de réseau est le plan de contrôle centralisé pour SDN. Il reçoit une stratégie du plan de gestion et configure le plan de données avec la stratégie. Avec le contrôleur de réseau, les clients peuvent gérer les services réseau tels que la microsegmentation et la QoS pour les réseaux VLAN traditionnels et les réseaux virtualisés.
- Équilibreur de charge logiciel (SLB) : C’est un composant d’infrastructure chargé de fournir les fonctionnalités d’équilibrage de charge et NAT pour les charges de travail sur les réseaux VLAN traditionnels et les réseaux virtualisés.
- Passerelles : Il s’agit de composants d’infrastructure chargés de fournir une connectivité de réseau virtuel aux réseaux externes.