Meilleures pratiques pour les grands déploiements de nœuds Azure avec Microsoft HPC Pack

À compter de HPC Pack 2008 R2 avec Service Pack 1, les administrateurs de cluster WINDOWS HPC et les développeurs peuvent augmenter la puissance du cluster local en ajoutant des ressources de calcul à la demande dans Azure. Ce scénario de cluster HPC « burst » avec des instances de rôle de travail Azure active des charges de travail HPC plus volumineuses, nécessitant parfois des milliers de cœurs en plus ou à la place de ressources de cluster locales. Cette rubrique fournit des conseils et des recommandations de bonnes pratiques pour faciliter la planification et l’implémentation d’un déploiement important de nœuds Azure à partir d’un cluster HPC Pack local. Ces bonnes pratiques recommandées doivent aider à réduire l’occurrence des délais d’attente de déploiement Azure, des échecs de déploiement et la perte d’instances actives.

Remarque

• Ces bonnes pratiques incluent des recommandations pour l’environnement Azure et la configuration du nœud principal local. La plupart des recommandations améliorent également le comportement des déploiements plus petits de nœuds Azure. Les exceptions à ces instructions sont des déploiements de test sur lesquels les performances et la fiabilité des services de nœud principal peuvent ne pas être critiques et très petits déploiements, où les services de nœud principal ne seront pas fortement stressés.
• La plupart des considérations relatives à la configuration d’un nœud principal local pour un déploiement Azure volumineux s’appliquent également aux clusters qui contiennent un grand nombre de nœuds de calcul locaux.
• Ces recommandations complètent le cluster, la mise en réseau et d’autres exigences pour ajouter des nœuds Azure à un cluster HPC Windows. Pour plus d’informations, consultez Configuration requise pour les nœuds Azure.
• Ces recommandations générales peuvent changer au fil du temps et doivent être ajustées pour vos charges de travail HPC.

Versions applicables de HPC Pack et du Kit de développement logiciel (SDK) Azure pour .NET

Ces recommandations sont généralement basées sur HPC Pack 2012 R2 et HPC Pack 2012, mais elles sont également utiles pour les grands déploiements effectués avec HPC Pack 2008 R2.

Le tableau suivant répertorie les versions de HPC Pack et les versions associées du Kit de développement logiciel (SDK) Azure pour .NET auxquelles ces instructions s’appliquent.

HPC Pack	Kit de développement logiciel (SDK) Azure
HPC Pack 2012 R2	Kit de développement logiciel (SDK) Azure pour .NET 2.2
HPC Pack 2012 avec Service Pack 1 (SP1)	Kit de développement logiciel (SDK) Azure pour .NET 2.0
HPC Pack 2012	Kit de développement logiciel (SDK) Azure pour .NET 1.8
HPC Pack 2008 R2 avec Service Pack 4 (SP4)	Kit de développement logiciel (SDK) Azure pour .NET 1.7
HPC Pack 2008 R2 avec Service Pack 3 (SP3)	Kit de développement logiciel (SDK) Azure pour .NET 1.6

Seuils pour les déploiements volumineux de nœuds Azure

Un déploiement de nœuds Azure pour un cluster HPC est considéré comme « volumineux » lorsqu’il devient nécessaire de prendre en compte la configuration du nœud principal et lorsque le déploiement demande un pourcentage significatif du cluster Azure de ressources pouvant être utilisé par un seul service cloud. Un déploiement plus volumineux risquerait des délais d’attente de déploiement et perdait des instances actives.

Important

Chaque abonnement Azure est alloué à un quota de cœurs et d’autres ressources, ce qui affecte également votre capacité à déployer un grand nombre de nœuds Azure. Pour pouvoir déployer un grand nombre de nœuds Azure, vous devrez peut-être d’abord contacter le support Microsoft pour demander une augmentation de quota principale pour votre abonnement. Notez qu’un quota est une limite de crédit, et non une garantie de disponibilité des ressources.

Le tableau suivant répertorie les nombres de seuils pratiques d’instances de rôle couramment utilisées pour un déploiement important de nœuds Azure dans un seul service cloud. Le seuil dépend de la taille de machine virtuelle (prédéfinie dans Azure) choisie pour les instances de rôle Azure.

Taille de l’instance de rôle	Nombre d’instances de rôle
A9 (pris en charge à partir de HPC Pack 2012 R2)	125
A8 (pris en charge à partir de HPC Pack 2012 R2)	250
A7 (pris en charge à partir de HPC Pack 2012 avec SP1)	250
A6 (pris en charge à partir de HPC Pack 2012 avec SP1)	250
Extra Large	250
grand	500
Moyenne	800
Petit	1 000

Pour plus d’informations sur chaque taille de machine virtuelle, y compris le nombre de cœurs d’UC et de mémoire pour chaque taille, consultez Tailles pour les services cloud.

Pour déployer plus de ces nombres de seuils d’instances de rôle dans un service avec une fiabilité élevée, il est généralement nécessaire d’impliquer manuellement l’équipe des opérations Azure. Pour lancer cette opération, contactez votre représentant commercial Microsoft, votre responsable de compte de support Microsoft Premier ou le support Microsoft. Pour plus d’informations sur les plans de support, consultez Support Azure.

Bien qu’il n’existe aucune limite difficile et applicable à tous les déploiements de nœuds Azure, 1 000 instances par service cloud constituent une limite de production pratique.

Meilleures pratiques pour l’utilisation d’Azure pour les déploiements volumineux

Voici des instructions générales pour créer et utiliser des déploiements Azure volumineux avec votre cluster HPC.

Fournir des signaux précoces à l’équipe des opérations Azure

Sauf si vous avez pris des dispositions pour déployer sur un cluster Azure dédié dans un centre de données, la recommandation la plus importante consiste à communiquer la nécessité à l’équipe des opérations Azure (via un canal de support Microsoft) d’une grande quantité de capacité à l’avance et de planifier les déploiements en conséquence afin d’éliminer la capacité en tant que goulot d’étranglement. Il s’agit également d’une occasion d’obtenir des conseils supplémentaires sur les stratégies de déploiement au-delà des stratégies décrites dans cette rubrique.

Déployer des déploiements sur plusieurs services cloud

Nous vous recommandons de fractionner des déploiements volumineux en plusieurs déploiements de petite taille, à l’aide de plusieurs services cloud, pour les raisons suivantes :

• Pour permettre une flexibilité dans le démarrage et l’arrêt des groupes de nœuds.

• Pour rendre possible l’arrêt des instances inactives une fois les travaux terminés.

• Pour faciliter la recherche de nœuds disponibles dans les clusters Azure, en particulier lorsque des instances extra-volumineuses sont utilisées.

• Pour activer l’utilisation de plusieurs centres de données Azure pour la reprise d’activité ou les scénarios de continuité d’activité.

Il n’existe aucune limite fixe sur la taille d’un service cloud, mais les conseils généraux sont inférieurs à 500 à 700 instances de machine virtuelle ou moins de 1 000 cœurs. Les déploiements plus volumineux risquent d’expirer, de perdre des instances actives et des problèmes liés à l’échange d’adresses IP virtuelles.

Le nombre maximal de services cloud testés pour un cluster HPC unique est de 32.

Remarque

Vous pouvez rencontrer des limitations dans le nombre de services cloud et d’instances de rôle que vous pouvez gérer via HPC Pack ou le portail de gestion Azure.

Être flexible avec l’emplacement

La présence de dépendances sur d’autres services et d’autres exigences géographiques peut être inévitable, mais elle peut vous aider si votre déploiement Azure n’est pas lié à une région ou une zone géographique spécifique. Toutefois, il n’est pas recommandé de placer plusieurs déploiements dans différentes régions géographiques, sauf s’ils ont des dépendances externes dans ces régions géographiques ou si vous avez des exigences de haute disponibilité et de récupération d’urgence.

Être flexible avec la taille de machine virtuelle

Avoir des dépendances strictes sur une certaine taille de machine virtuelle (par exemple, Extra Large) peut avoir un impact sur la réussite des déploiements à grande échelle. Une flexibilité pour ajuster ou même combiner des tailles de machine virtuelle pour équilibrer le nombre d’instances et les cœurs peut vous aider.

Utiliser plusieurs comptes de stockage Azure pour les déploiements de nœuds

Il est recommandé d’utiliser différents comptes de stockage Azure pour les déploiements simultanés de grands nœuds Azure et pour les applications personnalisées. Pour certaines applications limitées par les E/S, utilisez plusieurs comptes de stockage. En outre, comme bonne pratique, un compte de stockage utilisé pour un déploiement de nœuds Azure ne doit pas être utilisé à des fins autres que l’approvisionnement de nœuds. Par exemple, si vous envisagez d’utiliser le stockage Azure pour déplacer des données de travail et de tâches vers et depuis le nœud principal ou vers et depuis les nœuds Azure, configurez un compte de stockage distinct à cet effet.

Remarque

Vous entraînez des frais pour la quantité totale de données stockées et pour les transactions de stockage sur les comptes de stockage Azure, indépendamment du nombre de comptes de stockage Azure. Toutefois, chaque abonnement limite le nombre total de comptes de stockage. Si vous avez besoin de comptes de stockage supplémentaires dans votre abonnement, contactez le support Azure.

Ajuster le nombre d’instances de nœud proxy pour prendre en charge le déploiement

Les nœuds proxy sont des instances de rôle de travail Azure qui sont automatiquement ajoutées à chaque déploiement de nœuds Azure à partir d’un cluster HPC pour faciliter la communication entre les nœuds principaux locaux et les nœuds Azure. La demande de ressources sur les nœuds proxy dépend du nombre de nœuds déployés dans Azure et des travaux exécutés sur ces nœuds. Vous devez généralement augmenter le nombre de nœuds proxy dans un déploiement Azure volumineux.

Remarque

• Les instances de rôle proxy entraînent des frais dans Azure, ainsi que les instances de nœud Azure.
• Les instances de rôle proxy consomment des cœurs alloués à l’abonnement et réduisent le nombre de cœurs disponibles pour déployer des nœuds Azure.

HPC Pack 2012 a introduit des outils de gestion HPC pour vous permettre de configurer le nombre de nœuds proxy dans chaque déploiement de nœuds Azure (service cloud). (Dans HPC Pack 2008 R2, le nombre est automatiquement défini sur 2 nœuds proxy par déploiement.) Le nombre d’instances de rôle pour les nœuds proxy peut également être mis à l’échelle à l’aide des outils du portail de gestion Azure, sans redéployer des nœuds. Le nombre maximal recommandé de nœuds proxy pour un déploiement unique est de 10.

Les déploiements plus volumineux ou fortement utilisés peuvent nécessiter plus que le nombre de nœuds proxy répertoriés dans le tableau suivant, qui est basé sur une utilisation du processeur inférieure à 50 % et à la bande passante inférieure au quota.

Nœuds Azure par service cloud	Nombre de nœuds proxy
<100	2
100 - 400	3
400 - 800	4
800 - 1000	5

Pour plus d’informations sur les options de configuration des nœuds proxy, consultez Définir le nombre de nœuds proxy Azure.

Meilleures pratiques pour configurer le nœud principal pour les déploiements volumineux

Les grands déploiements de nœuds Azure peuvent faire passer des demandes importantes sur le nœud principal (ou les nœuds principaux) d’un cluster. Le nœud principal effectue plusieurs tâches pour prendre en charge le déploiement :

• Accède aux instances de nœud proxy créées dans un déploiement Azure pour faciliter la communication avec les nœuds Azure (consultez Ajuster le nombre d’instances de nœud proxy pour prendre en charge le déploiement, dans cette rubrique).

• Accède aux comptes de stockage Azure pour les objets blob (tels que les packages d’exécution), la file d’attente et les données de table.

• Gère l’intervalle de pulsation et les réponses, le nombre de proxys (à partir de HPC Pack 2012), le nombre de déploiements et le nombre de nœuds.

À mesure que les déploiements Azure augmentent en taille et en débit, le stress sur le nœud principal du cluster HPC augmente. En général, les éléments clés nécessaires pour vous assurer que votre nœud principal peut prendre en charge le déploiement sont les suivants :

• Ram suffisante

• Espace disque suffisant

• Une base de données SQL Server de taille appropriée et bien gérée pour les bases de données de cluster HPC

Spécifications matérielles pour le nœud principal

Voici quelques spécifications minimales suggérées pour un nœud principal pour prendre en charge un déploiement Azure volumineux :

• 8 cœurs de processeur

• 2 disques

• 16 Go de RAM

Configurer des bases de données SQL Server distantes

Pour les déploiements volumineux, nous vous recommandons d’installer les bases de données de cluster sur un serveur distant exécutant Microsoft SQL Server, au lieu d’installer les bases de données de cluster sur le nœud principal. Pour obtenir des instructions générales sur la sélection et la configuration d’une édition de SQL Server pour le cluster, consultez La planification et le réglage de la capacité de base de données pour Microsoft HPC Pack.

Ne configurez pas le nœud principal pour des rôles de cluster supplémentaires

Comme bonne pratique générale pour la plupart des déploiements de production, nous vous recommandons de ne pas configurer les nœuds principaux avec un rôle de cluster supplémentaire (rôle de nœud de calcul ou rôle de nœud broker WCF). Le fait que le nœud principal ait plusieurs objectifs peut empêcher l’exécution de son rôle de gestion principal. Pour modifier les rôles effectués par votre nœud principal, commencez par mettre le nœud hors connexion à l’aide de l’action dans Gestion des ressources (appelée Gestion des nœuds dans certaines versions de HPC Pack) dans HPC Cluster Manager. Ensuite, cliquez avec le bouton droit sur le nœud principal, puis cliquez sur Modifier le rôle.

En outre, le déplacement du stockage de cluster hors du nœud principal garantit que le nœud principal n’est pas insuffisant et fonctionne efficacement.

Utiliser les utilitaires clients HPC pour se connecter à distance au nœud principal

Lorsque le nœud principal fonctionne sous une charge importante, ses performances peuvent être négativement affectées par l’utilisation de nombreux utilisateurs connectés avec des connexions Bureau à distance. Au lieu que les utilisateurs se connectent au nœud principal à l’aide des services Bureau à distance (RDS), les utilisateurs et les administrateurs doivent installer les utilitaires client HPC Pack sur leurs stations de travail et accéder au cluster à l’aide de ces outils distants.

Désactiver la collecte des compteurs de performances et le transfert d’événements

Pour les déploiements volumineux, la collecte des compteurs de performances et le transfert d’événements peuvent entraîner une charge importante sur le service de gestion HPC et SQL Server. Pour ces déploiements, il peut être souhaitable de désactiver ces fonctionnalités à l’aide des outils de gestion de cluster HPC. Par exemple, définissez la propriété de cluster CollectCounters sur false à l’aide de l’applet de commande PowerShell Set-HpcClusterProperty . Il peut y avoir un compromis entre les performances améliorées et la collecte des métriques qui peuvent vous aider à résoudre les problèmes qui surviennent.

Désactiver les services de nœud principal inutiles

Pour garantir un encombrement matériel minimal du système d’exploitation et, en tant que bonne pratique générale du cluster HPC, désactivez tous les services de système d’exploitation qui ne sont pas requis pour l’opération du cluster HPC. Nous encourageons en particulier la désactivation de toutes les fonctionnalités orientées bureau qui ont pu être activées.

N’exécutez pas NAT sur le nœud principal

Bien que HPC Pack autorise la configuration rapide du service de routage et d’accès à distance (RRAS) exécuté sur le nœud principal pour fournir une traduction d’adresses réseau (NAT) et pour permettre aux nœuds de calcul d’atteindre le réseau d’entreprise, cela peut rendre le nœud principal un goulot d’étranglement important pour la bande passante réseau et peut également affecter ses performances. Comme bonne pratique générale pour les déploiements ou déploiements plus volumineux avec un trafic important entre les nœuds de calcul et le réseau public, nous vous recommandons l’une des alternatives suivantes :

• Fournissez une connexion réseau publique directe à chaque nœud de calcul.

• Fournissez un routeur NAT dédié, tel qu’un serveur distinct exécutant un système d’exploitation Windows Server et qui est double-hébergé sur les deux réseaux et exécutant RRAS.

Garantir une période de stockage raisonnable pour les travaux terminés

La propriété TtlCompletedJobs de la commande cluscfg et l’applet de commande Set-HpcClusterProperty HPC contrôlent la durée pendant laquelle les travaux terminés restent dans la base de données SQL Server du cluster HPC. La définition d’une valeur importante pour cette propriété garantit que les informations de travail sont conservées dans le système pendant longtemps, ce qui peut être souhaitable à des fins de création de rapports. Toutefois, un grand nombre de travaux dans le système augmenteront les besoins en stockage et en mémoire du système, car la base de données (et les requêtes sur celle-ci) sera généralement plus grande.

Configurer un nombre raisonnable de pulsations manquées avant de marquer les nœuds inaccessibles

HPC Pack utilise un signal de pulsation pour vérifier la disponibilité des nœuds. Le manque de réponse d’un nœud de calcul à cette sonde d’intégrité périodique par le service hpC Job Scheduler détermine si le nœud est marqué comme inaccessible. En configurant les options de pulsation dans la configuration du planificateur de travaux dans HPC Cluster Manager, ou en utilisant la commande cluscfg ou l’applet de commande Set-HpcClusterProperty HPC, l’administrateur du cluster peut définir la fréquence des pulsations (HeartbeatInterval) et le nombre de pulsations qu’un nœud peut manquer (InactivityCount) avant qu’il soit marqué comme inaccessible. Par exemple, l’objet HeartbeatInterval par défaut de 30 secondes peut être augmenté à 2 minutes lorsque le cluster inclut un déploiement Azure volumineux. L’inactivityCount par défaut est défini sur 3, qui convient à certains déploiements locaux, mais il doit être augmenté à 10 ou plus lorsque les nœuds Azure sont déployés.

Remarque

À compter de HPC Pack 2012 avec SP1, le nombre de pulsations manquées est configuré séparément pour les nœuds locaux et les nœuds Azure. La propriété de cluster InactivityCountAzure configure le nombre de pulsations manquées après lesquelles les nœuds Worker déployés dans Azure sont considérés comme inaccessibles par le cluster. La valeur par défaut de InactivityCountAzure est définie sur 10. À compter de HPC Pack 2012 avec SP1, la propriété InactivityCount s’applique exclusivement aux nœuds locaux.

Si le nœud principal ou les nœuds broker WCF sont configurés pour la haute disponibilité dans un cluster de basculement, vous devez également prendre en compte le signal de pulsation utilisé par chaque ordinateur de cluster de basculement pour surveiller la disponibilité de l’autre ordinateur (ou ordinateurs) dans le cluster de basculement. Par défaut, si un ordinateur manque cinq pulsations, une fois par seconde, la communication avec cet ordinateur est considérée comme ayant échoué. Vous pouvez utiliser le Gestionnaire du cluster de basculement pour réduire la fréquence des pulsations ou augmenter le nombre de pulsations manquées dans un cluster avec un déploiement Azure volumineux.

Si vous exécutez des travaux d’architecture orientée service (SOA) sur les nœuds Azure, vous devrez peut-être ajuster les paramètres de délai d’attente de surveillance dans le fichier d’inscription de service pour gérer les sessions volumineuses. Pour plus d’informations sur le fichier de configuration du service SOA, consultez les fichiers de configuration du service SOA dans Windows HPC Server 2008 R2.

Configurer une clé de Registre pour améliorer les performances des opérations de préproduction de fichiers

À compter de HPC Pack 2008 R2 avec SP2, vous pouvez définir une clé de Registre sur l’ordinateur du nœud principal pour améliorer les performances des tests de diagnostic, les opérations clusrun et l’utilitaire hpcfile sur de grands déploiements de nœuds Azure. Pour ce faire, ajoutez une nouvelle valeur DWORD appelée FileStagingMaxConcurrentCalls dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HPC. Nous vous recommandons de configurer une valeur comprise entre 50% et 100% du nombre de nœuds Azure que vous envisagez de déployer. Pour terminer la configuration, après avoir défini la valeur FileStagingMaxConcurrentCalls , vous devez arrêter, puis redémarrer le service du planificateur de travaux HPC.

Avertissement

Une modification incorrecte du Registre peut endommager gravement votre système. Avant toute modification du registre, il est conseillé de sauvegarder toutes les données importantes de votre ordinateur.

Voir aussi

Burst to Azure Worker Instances with Microsoft HPC Pack
Meilleures pratiques pour la conception de services Large-Scale sur Azure Cloud Services
Conseils techniques de continuité d’activité Windows Azure