Génération d’un cluster HPC Pack haute disponibilité dans Azure
Dans cet article, nous allons fournir les étapes et la prise en compte de la création d’un cluster HPC Pack haute disponibilité dans Azure.
Considérations relatives au cluster à haut niveau disponible
Un cluster HPC Pack classique se compose d’un SQL Server avec nos bases de données qui stockent des travaux HPC ; Un nœud principal serveur qui exécute des services critiques tels que le service SDM du service planificateur ; Un ensemble de nœuds de calcul qui se connectent aux services sur le nœud principal exécutent les charges de travail HPC de l’utilisateur. En outre, nous avons également besoin d’un contrôleur de domaine qui sert l’authentification pour les clients. Tous ces composants sont connectés via réseau.
Dans un environnement cloud Azure, l’un des composants ci-dessus peut échouer, par exemple, le nœud principal redémarré pour windows update, certains nœuds de calcul peuvent redémarrer, car vous utilisez une machine virtuelle de faible priorité. Ainsi, comment pouvons-nous configurer un cluster HPC Pack à haute disponibilité qui satisfait :
Tout composant mentionné ci-dessus a échoué, la charge de travail de l’utilisateur peut toujours s’exécuter sans être annulée ou ayant échoué
Les tâches exécutées sur des nœuds de calcul ayant échoué doivent être réécrites vers d’autres nœuds de calcul
Le cluster doit toujours être en mesure de servir les fonctionnalités, notamment la gestion des clusters, la gestion des travaux
Par conséquent, examinons chaque situation de défaillance des composants et leur solution de haute disponibilité.
Gestion de l’échec de la base de données
Vous avez deux choix pour obtenir une base de données SQL haute disponible sur le cloud :
À l’aide du modèle ARM pour déployer un cluster SQL AlwaysOn, vous pouvez consulter ce blog
Traitement de l’échec du nœud principal
Configurez au moins 3 nœuds principaux de cluster. Avec cette configuration, toute défaillance de nœud principal entraîne le déplacement du service HPC actif de ce nœud principal vers d’autres.
Traitement de l’échec AD
Lorsque HPC n’a pas pu se connecter au contrôleur de domaine, l’administrateur et l’utilisateur ne pourront pas se connecter au service HPC, ce qui n’est pas en mesure de gérer et d’envoyer des travaux au cluster. Et les nouveaux travaux ne pourront pas démarrer sur les nœuds d’ordinateur joints au domaine, car le service NodeManager
Avoir un contrôleur de domaine à haut niveau de disponibilité déployé avec votre cluster HPC Pack dans Azure
Utilisation du service de domaine Azure AD. Pendant le déploiement du cluster, vous pouvez simplement joindre tous vos nœuds de cluster à ce domaine et obtenir le service de domaine à haut niveau de disponibilité à partir d’Azure.
À l’aide de solution d’intégration HPC Pack Azure AD sans que les nœuds de cluster rejoignent un domaine. Ainsi, tant que le service HPC a une connectivité au service Azure AD.
Gestion de l’échec réseau
Le réseau lui-même dans le centre de données Azure est élevé, nous n’avons donc pas besoin d’avoir un réseau de sauvegarde.
Génération d’un cluster HPC Pack haute disponibilité
Nous avons un modèle ARM ici, sélectionnez qui est en mesure de déployer un cluster HPC à haute disponibilité avec les options suivantes :
Créer une base de données Azure SQL
Se connecter à un domaine Active Directory existant
Créer un cluster HPC Pack à 3 nœuds principaux
modèle : cluster haute disponibilité avec des bases de données Azure SQL pour les charges de travail Windows avec un de domaine Active Directory existant
Ce modèle déploie un cluster HPC Pack avec une haute disponibilité pour les charges de travail HPC Windows dans une forêt de domaine Active Directory existante. Le cluster comprend trois nœuds principaux, des bases de données SQL Azure et un nombre configurable de nœuds de calcul Windows.
Partages de cluster HPC Pack
Actuellement, dans tous les modèles ARM HPC Pack, nous créons le partage de cluster sur l’un des nœuds principaux qui n’est pas élevé, comme si ce nœud principal est arrêté, le partage ne sera pas accessible au service HPC s’exécutant sur un autre nœud principal. En fait, il n’aura pas d’impact sur les travaux en cours d’exécution et la gestion des nœuds.
Avec Azure Files, ces partages de fichiers peuvent être déplacés vers des partages Azure Files avec des autorisations SMB pour les rendre disponibles. Reportez-vous à ce document.
| Nom du partage | Usage | Emplacement par défaut | Impact en cas de panne | Comment rendre la disponibilité élevée |
|---|---|---|---|---|
| Partage d’installation à distance | Après l’installation du cluster, nous mettons des fichiers binaires d’installation HPC Pack dans ce dossier de partage afin que les ordinateurs clients et les machines de calcul puissent effectuer le répertoire d’installation à partir de ce partage. | \\<HN3>\REMINST |
Lorsque ce partage est en panne ou n’est pas accessible, il n’a aucun impact sur les fonctionnalités existantes du cluster HPC. | L’administrateur de cluster peut également créer les mêmes partages sur les deux autres nœuds principaux et copier les fichiers binaires configurés là-bas afin que n’importe quel nœud principal vers le bas, le partage est toujours disponible |
| Partage d’inscription HPC SOA | Ce partage stocke le fichier d’inscription du service SOA | \\<HN3>\HpcServiceRegistration |
Le travail de service SOA qui s’appuie sur les fichiers d’inscription dans ce partage ne peut pas s’exécuter | Lors de l’inscription du nouveau fichier de configuration du service SOA, ne placez pas le fichier d’inscription dans le partage, mais utilisez Importer un fichier de configuration à haut niveau de disponibilité... à partir du Gestionnaire de cluster pour importer le fichier d’inscription du service SOA dans le magasin fiable du cluster HPC afin que le fichier d’inscription soit disponible même lorsque le partage est arrêté. |
| Partage d’exécution HPC SOA | Ce partage stocke les données courantes du travail SOA | \\<HN3>\Runtime$ |
Le travail SOA avec des données courantes échouera | Le client SOA doit placer les données communes dans le stockage Azure afin que les données communes soient toujours disponibles même le partage d’exécution est arrêté. |
| HPC SOA TraceRepository | Référentiel de traces de diagnostics Soa. | \\<HN3>\TraceRepository |
Si le suivi des diagnostics SOA est activé, la trace échoue à collecter. | Utilisez le partage Azure Files. |
| Partage de diagnostics HPC | Ce partage stocke le résultat du test de diagnostic | \\<HN3>\Diagnostics |
Lorsque ce partage est arrêté, le travail Diagnostics HPC échoue, car il n’a aucun emplacement pour écrire le résultat du test. | L’administrateur de cluster peut basculer vers un nouveau partage de diagnostic lorsqu’il souhaite exécuter des tests de diagnostic. Pour passer à un nouveau partage de diagnostic, exécutez HPC powershell cmd set-HpcClusterRegistry -PropertyName DiagnosticsShare -PropertyValue "\\<HN2>\diagnostics" |
| CcpSpoolDir | Partage de spoulage de sortie pour les nœuds de calcul. | \\<HN3>\CcpSpoolDir |
Si elle est utilisée pour la sortie de tâche, la tâche ne parvient pas à écrire des données de sortie. | Utilisez le partage Azure Files. |