Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
À compter de HPC Pack 2008 R2 avec Service Pack 1 (SP1), HPC Pack inclut des utilitaires et mécanismes intégrés qui aident les administrateurs de cluster à déployer des applications (tels que des fichiers exécutables, des services SOA, des fichiers XLL et des classeurs Microsoft Excel compatibles avec le cluster) sur des nœuds Azure joints à un cluster local dans un scénario Azure « burst ». Par défaut, les nœuds Azure ne peuvent pas accéder directement aux ressources locales et aux dossiers partagés. Par conséquent, les méthodes que vous utilisez pour déployer des applications sur des nœuds Azure diffèrent des méthodes que vous utilisez pour déployer des applications locales. En outre, les nœuds Azure ajoutés à un cluster HPC Windows sont déployés et reprovisionnés dynamiquement. Par conséquent, les méthodes recommandées pour le déploiement d’applications permettent de s’assurer que les applications sont automatiquement disponibles sur les nouvelles instances de nœud Azure.
Considérations relatives aux charges de travail d’application HPC pour Azure burst
Avant de déployer des applications sur des nœuds Azure, évaluez si vos charges de travail HPC existantes ou planifiées s’exécutent ou sont mises à l’échelle efficacement dans Azure. Les considérations détaillées relatives à la migration, au développement et à la conception pour les applications HPC qui s’exécutent dans un scénario de rafale Azure dépassent l’étendue de cette rubrique. En outre, les fonctionnalités de la plateforme Azure évoluent en permanence. Toutefois, voici les caractéristiques actuelles des charges de travail Azure réussies avec HPC Pack, en particulier pour les déploiements à grande échelle de nœuds Azure :
Calculs à nœud unique hautement distribués Il s’agit notamment de nombreux travaux d’architecture paramétrique et d’architecture orientée service (SOA). D’autres types de travaux, notamment les travaux MPI (Message Passing Interface), peuvent s’exécuter dans une configuration de rafale Azure, mais peuvent nécessiter la sélection d’une taille d’instance nécessitant beaucoup de ressources de calcul qui prend en charge le réseau Azure RDMA. Pour obtenir des informations générales sur les types de travaux HPC, consultez Présentation des travaux de calcul parallèle.
Le temps de calcul dépasse le temps de déplacement des données Certaines charges de travail HPC nécessitent le chargement de grandes quantités de données dans Azure pour le calcul ou retournent de grandes quantités de données qui ont été traitées. Vérifiez que le déplacement des données n’est pas un goulot d’étranglement dans votre workflow HPC.
Accès aux données basées sur des fichiers Les applications HPC existantes qui accèdent aux fichiers de données locaux peuvent être facilement migrées pour s’exécuter dans Azure en accédant aux fichiers de données chargés dans le stockage Blob Azure. De nouvelles applications HPC peuvent être développées pour accéder à la variété de types de stockage dans Azure. Toutefois, en fonction de la sensibilité des données, des exigences légales, des considérations relatives aux coûts et d’autres facteurs, il peut ne pas être possible de stocker les données d’application dans Azure.
Modèle de charge de travail « Bursty » Le scénario de rafale Azure est idéal pour les charges de travail gourmandes en ressources qui ne sont pas facilement terminées à l’aide des ressources fixes d’un cluster local. Les charges de travail peuvent inclure des pics de calcul irréguliers, des travaux planifiés régulièrement ou des travaux ponctuels.
Pour plus d’informations sur l’exécution d’applications sur des nœuds Azure, consultez Instructions pour l’exécution d’applications HPC sur des nœuds Azure.
Sélection d’une méthode pour déployer des applications et des données sur des nœuds Azure
La méthode que vous utilisez pour déployer des applications et des données (dans certains cas) sur des nœuds Azure dépend de ce qui est nécessaire pour installer votre application, comme indiqué dans le tableau suivant.
| Configuration requise | Méthode | Disponibilité |
|---|---|---|
| L’installation peut être effectuée en copiant des fichiers et toutes les dépendances telles que les DLL ou les fichiers de configuration sur le nœud. | - Packages d’administrateur et étapes de fichiers dans le stockage Azure à l’aide des commandes hpcpack . Consultez Utilisation de hpcpack et hpcsync. - L’administrateur déploie des nœuds Azure. Les packages sont automatiquement déployés (copiés et extraits) sur de nouvelles instances de nœud Azure, ou l’administrateur peut déployer manuellement si les nœuds sont déjà en cours d’exécution. Consultez Burst to Azure Worker Instances avec Microsoft HPC Pack. |
HPC Pack 2008 R2 avec SP1 |
| L’installation nécessite l’exécution silencieuse d’un programme d’installation ou nécessite des étapes de configuration supplémentaires, telles que la définition de variables d’environnement ou la création d’exceptions de pare-feu. | - Packages d’administrateur et étapes des fichiers ou programmes d’installation vers le stockage Azure à l’aide des commandes hpcpack . Consultez Utilisation de hpcpack et hpcsync. - L’administrateur spécifie un script de démarrage dans le modèle de nœud Azure pour configurer l’environnement ou exécuter des commandes d’installation. Consultez Utiliser un script de démarrage pour les nœuds Azure. - L’administrateur déploie des nœuds Azure. Les packages sont automatiquement déployés sur de nouvelles instances de nœud Azure, puis le script de démarrage s’exécute dans le cadre du processus d’approvisionnement. Consultez Burst to Azure Worker Instances avec Microsoft HPC Pack. |
HPC Pack 2008 R2 avec SP2 |
| L’installation et la distribution des données sur les nœuds Azure peuvent se produire pendant une tâche de préparation au moment de l’exécution du travail. | - L’administrateur utilise un outil de stockage Azure tel qu’AzCopy pour charger des programmes d’installation et des fichiers de données dans un conteneur dans le stockage d’objets blob Azure. - Les packages d’administrateur et étapent des fichiers ou programmes d’installation supplémentaires dans le stockage Azure à l’aide des commandes hpcpack . Consultez Utilisation de hpcpack et hpcsync. - L’administrateur spécifie un script de démarrage dans le modèle de nœud Azure pour configurer l’environnement ou exécuter des commandes d’installation. Consultez Utiliser un script de démarrage pour les nœuds Azure. - L’administrateur déploie des nœuds Azure. Les packages sont automatiquement déployés sur de nouvelles instances de nœud Azure, puis le script de démarrage s’exécute dans le cadre du processus d’approvisionnement. Consultez Burst to Azure Worker Instances avec Microsoft HPC Pack. - L’administrateur crée un travail avec une tâche de préparation de nœud pour effectuer des étapes d’installation supplémentaires ou pour télécharger des données à partir d’un conteneur de stockage d’objets blob Azure. Consultez Définir une tâche de préparation de nœud - Gestionnaire de travaux. |
HPC Pack 2008 R2 avec SP1 |
| L’installation nécessite des étapes qui ne sont pas facilement scriptées, et les données d’application et d’application sont accessibles à partir d’un lecteur durable dans Azure. - |
- L’administrateur utilise les outils Windows pour créer un disque dur virtuel (VHD) et installer l’application et toutes les données d’application nécessaires sur le disque dur virtuel. - L’administrateur détache le disque dur virtuel et utilise la commande hpcpack upload pour charger le disque dur virtuel en tant qu’objet blob de pages dans le stockage Azure. Consultez Utilisation de hpcpack et hpcsync. - L’administrateur spécifie le disque dur virtuel d’application qui se trouve dans le stockage Azure lors de la configuration du modèle de nœud Azure. Consultez Monter un disque dur virtuel d’application sur des nœuds Worker Azure. - Si vous le souhaitez, l’administrateur spécifie un script de démarrage pour des configurations supplémentaires ou pour configurer des dossiers partagés sur un ou plusieurs nœuds du déploiement. Consultez Utiliser un script de démarrage pour les nœuds Azure. - L’administrateur déploie des nœuds Azure. Les instances de nœud Azure sont créées qui montent le disque dur virtuel de l’application, tous les packages sur le stockage sont automatiquement déployés sur les nœuds, puis le script de démarrage s’exécute dans le cadre du processus d’approvisionnement. Consultez Burst to Azure Worker Instances avec Microsoft HPC Pack. |
HPC Pack 2012 |
Utilisation de hpcpack et hpcsync
Chaque déploiement de nœud Azure est associé à un compte de stockage Azure spécifié dans le modèle de nœud. Un administrateur de cluster peut mettre en scène des fichiers (comme des applications, des services SOA, des XLLs, des classeurs Excel activés pour le cluster et des utilitaires) sur le compte de stockage à l’aide des commandes hpcpack . Vous pouvez utiliser hpcpack create pour empaqueter des fichiers ou des dossiers dans un format compressé (.zip) qui peut être chargé dans le stockage Azure. Chaque application, service SOA ou XLL doit être empaqueté séparément, et le package doit inclure toutes les dépendances requises telles que les DLL ou les fichiers de configuration. Vous pouvez ensuite utiliser le chargement hpcpack pour charger le package dans le compte de stockage. Vous pouvez exécuter les commandes hpcpack à partir du nœud principal ou sur un ordinateur sur lequel les utilitaires clients HPC sont installés.
Tous les packages du compte de stockage sont automatiquement déployés sur de nouvelles instances de nœud Azure pendant le processus d’approvisionnement. Cela se produit lorsque vous déployez un ensemble de nœuds Azure à l’aide des utilitaires de gestion HPC, et si vos instances de nœud sont reprovisionnée automatiquement par le système Azure De fenêtre. La commande hpcsync s’exécute sur chaque nœud Azure et copie tous les packages du stockage vers le nœud, puis extrait les fichiers. Si vous chargez des packages vers le stockage une fois les nœuds Azure démarrés, vous pouvez déployer les packages en exécutant manuellement la commande hpcsync sur chaque nœud Azure.
Remarque
Si vous créez plusieurs modèles de nœuds Azure qui référencent le même compte de stockage, les mêmes fichiers intermédiaires seront déployés sur tous les ensembles de nœuds Azure. Pour déployer différents fichiers sur différents ensembles de nœuds, créez un compte de stockage Azure distinct pour chaque modèle de nœud Azure.
Le diagramme suivant illustre le flux de travail et les mécanismes de base pour copier des applications vers des nœuds Azure :
Par défaut, hpcsync extrait les fichiers à un emplacement spécifié par la variable d’environnement CCP_PACKAGE_ROOT. Cette variable est définie sur les nœuds Azure pendant le processus d’approvisionnement. Les fichiers extraits sont placés dans un dossier déterminé comme suit : %CCP_PACKAGE_ROOT%\<packageName>\<uploadTimeStamp>. Il s’agit de l’emplacement attendu pour les classeurs SOA services, XLL et Excel. Toutefois, cela n’est pas pratique pour les applications que les utilisateurs du cluster appelleront dans leurs lignes de commande. Pour simplifier la structure de dossiers pour les fichiers exécutables, vous pouvez définir la propriété de chemin d’accès relatif du package lorsque vous le chargez dans le stockage.
hpcsync applique le chemin relatif lors de l’extraction des fichiers, afin que le chemin d’accès soit déterminé comme suit : %CCP_PACKAGE_ROOT%\<relativePath>. Les utilisateurs peuvent ensuite spécifier le chemin d’accès à leur application comme dans l’exemple suivant d’une commande d’envoi de travail : job submit %CCP_PACKAGE_ROOT%\myRelativePath\myapp.exe
Voici des considérations importantes sur hpcsync et CCP_PACKAGE_ROOT :
Sur les nœuds Worker Azure, le dossier %CCP_PACKAGE_ROOT% est créé sur une partition de disque de 10 Go. Cela signifie que tous les fichiers d’application sur une instance de nœud ne peuvent pas dépasser 10 Go. Si une application a des fichiers d’entrée et de sortie considérables, vous pouvez utiliser un script de démarrage pour accorder des autorisations utilisateur sur les lecteurs C :\ afin que les utilisateurs puissent écrire dans tous les espaces de travail disponibles sur le nœud.
Lorsque vous exécutez hpcsync manuellement, vous pouvez remplacer l’emplacement par défaut (%CCP_PACKAGE_ROOT%). Par exemple, vous pouvez créer un dossier sur chaque nœud Azure, puis spécifier cet emplacement lorsque vous exécutez hpcsync. Tous les packages seront extraits dans ce dossier. Toutefois, toutes les nouvelles instances de nœud déployées (ou reprovisionnés automatiquement) n’incluent pas ce dossier, et les packages sont automatiquement déployés à l’emplacement par défaut. En outre, les utilisateurs du cluster disposent uniquement d’autorisations d’écriture dans des dossiers dans %CCP_PACKAGE_ROOT%. Sauf si vous modifiez des autorisations de dossier sur les nœuds Azure, seuls les administrateurs peuvent exécuter des applications en dehors de %CCP_PACKAGE_ROOT%.
Lorsque hpcsync déploie un package, aucun des fichiers extraits ne peut avoir une longueur de chemin d’accès complète supérieure à 256 caractères. Les répertoires racines où les fichiers extraits sont temporairement placés et finalement placés peuvent prendre jusqu’à 136 caractères, en laissant 120 caractères pour le nom de fichier, les sous-répertoires (le cas échéant) et le relativePath (le cas échéant). Si le chemin des fichiers extraits dépasse 256 caractères, le déploiement du package échoue.
Le mécanisme hpcsync est suffisant pour déployer des services SOA, des fichiers XLL et des applications qui peuvent être installés en copiant simplement des fichiers sur un nœud. Si vous devez exécuter un programme d’installation pour installer une application ou si l’application nécessite des étapes de configuration supplémentaires telles que la définition de variables d’environnement, l’ajout d’exceptions de pare-feu, la modification des autorisations de dossier ou la création de dossiers, vous pouvez inclure un script de démarrage dans le modèle de nœud. Ce script s’exécute pendant le processus d’approvisionnement après les exécutions hpcsync et peut être utilisé pour configurer les nœuds et effectuer les étapes d’installation de l’application requises.
Guide pratique pour mettre en scène des fichiers d’application vers le stockage Azure
Cette section fournit des informations sur la façon de empaqueter des applications et de les mettre en scène dans le stockage Azure à l’aide de hpcpack. Les packages intermédiaires sont automatiquement déployés sur de nouvelles instances de nœud Azure que vous approvisionnez (ou qui sont automatiquement reprovisionnés par le système Azure).
Remarque
Vous devez être administrateur de cluster ou au moins disposer de l’ID d’abonnement Azure et de la clé du compte de stockage pour mettre en scène des fichiers vers le stockage Azure.
Spécifications
Si vous empaqueter un service SOA :
Le nom du package doit être le nom du service SOA (autrement dit, le nom du service spécifié par le client SOA dans le constructeur SessionStartInfo). Par exemple, serviceName.zip ou serviceName_serviceVersion.zip.
Vous devez inclure la DLL de service, les DLL dépendantes et les fichiers de configuration de service dans le package.
Le fichier de configuration du service doit également être déployé sur le nœud principal. Tous les paramètres sont déterminés par la copie locale du fichier de configuration.
Ne spécifiez pas de chemin relatif lorsque vous chargez le package. Les services SOA doivent être décompressés à l’emplacement par défaut.
Si vous empaqueter un fichier XLL :
Le nom du package doit être le nom du fichier XLL. Par exemple, XLLName.zip.
Si xlL a des dépendances, placez le fichier XLL et les fichiers de prise en charge dans un dossier et empaquetez le dossier. Le fichier XLL doit se trouver dans le niveau supérieur du dossier (et non dans un sous-dossier).
Ne spécifiez pas de chemin relatif lorsque vous chargez le package. Les XLL doivent être décompressés à l’emplacement par défaut.
Si vous empaqueter un classeur Excel :
Le nom du package doit être le nom du classeur. Par exemple, workbookName.zip.
Si le classeur a des dépendances, placez le classeur et les fichiers de prise en charge dans un dossier et empaquetez le dossier. Le classeur doit se trouver dans le niveau supérieur du dossier (et non dans un sous-dossier).
Ne spécifiez pas de chemin relatif lorsque vous chargez le package. Les classeurs doivent être décompressés à l’emplacement par défaut.
Si vous empaquetez un fichier exécutable (par exemple, une application MPI), un programme d’installation d’application ou un utilitaire que vous allez appeler à partir d’un script de démarrage :
Vous devez inclure des DLL ou fichiers dépendants dans le package.
Lorsque vous chargez le package, spécifiez la propriété de chemin d’accès relatif.
Si vous empaqueter un script de démarrage :
Le nom du package doit être le nom du script de démarrage. Par exemple, startup.bat.zip.
Ne spécifiez pas de chemin relatif lorsque vous chargez le package. Le script de démarrage doit être décompressé à l’emplacement par défaut.
Si votre script de démarrage appelle des programmes d’installation ou des utilitaires, veillez à empaqueter et à mettre en scène les fichiers requis séparément.
Étapes
Par exemple, les procédures suivantes illustrent comment mettre en scène différents types de fichiers d’application vers le stockage Azure.
Remarque
Vous n’avez pas besoin d’une invite de commandes avec élévation de privilèges (exécuter en tant qu’administrateur) pour exécuter hpcpack create. Toutefois, le chargement hpcpack nécessite une élévation. Pour effectuer les procédures suivantes, exécutez les commandes dans une fenêtre d’invite de commandes avec élévation de privilèges.
Pour empaqueter et mettre en scène un service SOA vers le stockage Azure
Si le service SOA n’est pas déjà inscrit et déployé sur le cluster local, inscrivez le service SOA en plaçant une copie du fichier de configuration du service dans le dossier d’inscription du service sur le nœud principal (en général, il s’agit %CCP_HOME%\ServiceRegistration). Pour plus d’informations, consultez Déployer et modifier le fichier de configuration du service.
Copiez le fichier de configuration du service, l’assembly de service et toutes les DLL dépendantes dans un dossier vide. Par exemple, copiez les fichiers dans un dossier nommé C :\myFiles\myServiceFiles.
À l’invite de commandes avec élévation de privilèges, exécutez hpcpack create et spécifiez un nom pour votre package et le dossier qui contient vos fichiers de service.
Important
Le nom du package doit être le nom du service SOA (autrement dit, le nom du service spécifié par le client SOA dans le
SessionStartInfoconstructeur).Par exemple, pour empaqueter le contenu de C :\myFiles\myServiceFiles en tant que myServiceName.zip (et enregistrer le package dans un dossier appelé AzurePackages) :
hpcpack create C:AzurePackagesmyServiceName.zip C:myFilesmyServiceFilesExécutez le chargement hpcpack pour charger le package dans le stockage Azure à l’aide de la commande suivante, où myHeadNode est le nom de votre nœud principal, et myAzureTemplate est le nom du modèle que vous avez utilisé pour déployer les nœuds Azure. Par exemple:
hpcpack upload C:\AzurePackages\myServiceName.zip /nodetemplate:myAzureNodeTemplate /scheduler:myHeadNode
Pour empaqueter et mettre en scène un fichier XLL ou un classeur Excel dans le stockage Azure
Si le fichier XLL ou le classeur a des dépendances sur des DLL ou d’autres fichiers, copiez le fichier XLL ou le classeur et ses dépendances dans un dossier, tel que c :\myFiles\myExcelFiles.
À une invite de commandes avec élévation de privilèges, exécutez hpcpack create pour empaqueter votre xll ou votre classeur. Spécifiez un nom pour le package et spécifiez le xll ou le classeur. Le nom du package doit être le nom du fichier XLL ou du classeur Excel.
Par exemple, si votre XLL ou classeur a des dépendances, empaquetez l’intégralité du dossier (et enregistrez le package dans un dossier appelé AzurePackages) :
hpcpack create C:\AzurePackages\myXLL.zip C:\myFiles\myExcelFilesSi votre XLL ou classeur n’a pas de dépendances, vous pouvez le empaqueter directement. Par exemple, pour empaqueter C :\myFiles\myXLL.xll en tant que myXLL.zip:
hpcpack create C:\AzurePackages\myXLL.zip C:\myFiles\myXLL.xllExécutez le chargement hpcpack pour charger le package dans le stockage Azure à l’aide de la commande suivante, où myHeadNode est le nom de votre nœud principal, et myAzureTemplate est le nom du modèle que vous avez utilisé pour déployer les nœuds Azure. Par exemple:
hpcpack upload C:\AzurePackages\myXLL.zip /nodetemplate:myAzureNodeTemplate /scheduler:myHeadNode
Pour empaqueter et mettre en scène un fichier exécutable dans le stockage Azure
Copiez l’exécutable et toutes les dépendances ou DLL dans un dossier, tel que C :\myFiles\myAppFiles.
À une invite de commandes avec élévation de privilèges, exécutez hpcpack create pour empaqueter vos fichiers d’application. Spécifiez un nom pour votre package et spécifiez le dossier qui contient vos fichiers d’application.
Par exemple, pour empaqueter le contenu de c :\myFiles\myAppFiles en tant quemyApp.zip (et enregistrer le package dans un dossier appelé AzurePackages) :
hpcpack create c:\AzurePackages\myApp.zip c:\myFiles\myAppFilesChargez le package dans le stockage Azure à l’aide de la commande suivante, où myHeadNode est le nom de votre nœud principal, et myAzureTemplate est le nom du modèle que vous avez utilisé pour déployer les nœuds Azure. Spécifiez un chemin relatif pour les fichiers d’application. Par exemple:
hpcpack upload c:\AzurePackages\myApp.zip /scheduler:myHeadNode /nodetemplate:myAzureTemplate /relativepath:myApp
Comment déployer des packages intermédiaires sur des nœuds Azure
Les packages intermédiaires vers le stockage Azure sont automatiquement déployés sur de nouvelles instances de nœud. Vous pouvez déployer manuellement des packages , par exemple, pour vérifier que vous disposez de toutes les dépendances nécessaires dans un package avant d’automatiser le déploiement sur tous les nouveaux nœuds, ou de déployer des packages sur des nœuds déjà en cours d’exécution. Vous pouvez utiliser clusrun et hpcsync pour déployer les fichiers à partir du compte de stockage Azure sur les nœuds Azure.
Par exemple:
clusrun /nodegroup:AzureWorkerNodes hpcsync
Pour afficher la liste des dossiers ou fichiers déployés sur les nœuds Azure, vous pouvez exécuter la commande suivante :
clusrun /nodegroup:AzureWorkerNodes dir %CCP_PACKAGE_ROOT% /s
Accès aux fichiers à partir de nœuds Azure
Si votre application HPC nécessite un accès aux fichiers, les options suivantes permettent d’accéder aux fichiers à partir des applications déployées sur des nœuds Azure.
| Choix | Conditions préalables | Remarques |
|---|---|---|
| Lecteur Azure | L’administrateur configure et monte un disque dur virtuel d’application sur des nœuds Azure. Consultez Monter un disque dur virtuel d’application sur des nœuds Worker Azure. |
- Le lecteur est copié et mis en cache localement sur chaque nœud - Le lecteur ne peut être écrit que par un seul nœud à la fois |
| Serveur de fichiers sur une machine virtuelle Azure | L’administrateur configure une instance de machine virtuelle Azure, attache un disque de données à la machine virtuelle, active le rôle Serveur de fichiers et crée un dossier de partage de fichiers. Découvrez comment configurer un serveur de fichiers de machine virtuelle Azure et l’utiliser à partir de travaux de calcul Windows HPC Server. |
- L’accès par les travaux aux ressources du serveur de fichiers nécessite un accès utilisateur authentifié. - Fournit la compatibilité SMB pour les applications existantes - Fournit un maximum de 16 To de données par serveur - Limite la bande passante à 800 Mo/s |
| Mettre en miroir des fichiers locaux vers le stockage d’objets blob Azure | L’administrateur utilise un outil de stockage Azure tel qu’AzCopy pour mettre en miroir des fichiers locaux vers un conteneur dans le stockage d’objets blob Azure. |
- La mise en miroir de données à partir d’un environnement local vers Azure ajoute une surcharge. |
| Accéder directement au stockage d’objets blob Azure | L’application est conçue pour effectuer des opérations d’accès aux données directement sur des objets blob Azure | - Fournit une scalabilité maximale des options disponibles |