Utilisation de clusters pour le calcul technique à grande échelle dans le cloud

Cette solution fournit des conseils pour effectuer des calculs techniques à grande échelle sur Google Cloud. De nombreuses applications informatiques techniques requièrent un grand nombre de nœuds de calcul individuels, connectés ensemble dans un cluster, et coordonnant le calcul et l’accès aux données entre les nœuds.

Les concepts et technologies sous-jacents à l’informatique en grappes se sont développés au cours des dernières décennies et sont maintenant matures et courants. La migration du logiciel vers Google Cloud peut ajouter quelques rides, mais offre également un certain nombre d’opportunités pour réduire les coûts et atténuer les goulots d’étranglement existants dans les environnements informatiques hautes performances actuels. Ce guide donne un aperçu des technologies, des défis et de la récolte actuelle de solutions pour l’exécution de clusters informatiques sur Google Cloud.

Cluster computing agrège et coordonne une collection de machines à travailler ensemble pour résoudre une tâche. Les clusters ont généralement un seul nœud principal (parfois appelé nœud maître), un certain nombre de nœuds de calcul et éventuellement quelques autres nœuds spécialisés. Le nœud principal est le cerveau du système et est responsable de:

• Enregistrement des nœuds de calcul dans le système.
• Surveillance des nœuds.
• Attribution de tâches à des nœuds particuliers.

Les utilisateurs soumettent des tâches, qui sont composées de nombreuses tâches, où une tâche est l’unité de travail de base. Certaines applications nécessitent que toutes les tâches d’un travail s’exécutent actuellement et permettent aux tâches de communiquer pour implémenter un algorithme parallèle ; certains travaux ont un ensemble complexe de dépendances de tâches telles que des tâches particulières doivent être exécutées avant d’autres ; et certaines tâches peuvent nécessiter des configurations de nœuds particulières en termes de mémoire, de PROCESSEURS ou d’autres matériels particuliers sur lesquels s’exécuter. Les tâches sont des exécutables qui lisent les données d’entrée du stockage, traitent les données pour produire un résultat, puis écrivent les résultats finaux dans le stockage.

Il existe deux principaux types de charges de travail de calcul en cluster:

• Calcul haute performance (HPC) – Un type de calcul qui utilise de nombreux nœuds de travail, étroitement couplés et s’exécutant simultanément pour accomplir atask. Ces machines ont généralement besoin d’une faible latence réseau pour communiquer efficacement. Les exemples d’applications dans cet espace incluent la modélisation météorologique, la dynamique des fluides computationnelle (CFD), la modélisation des contraintes en ingénierie et la conception électronique.

• Calcul à haut débit (HTC) – Un type de calcul où les applications ont plusieurs tâches qui sont traitées indépendamment les unes des autres sans qu’il soit nécessaire que les nœuds de calcul individuels communiquent. Parfois, ces charges de travail sont appelées charges de travail parallèles ou par lots embarrassantes. Les exemples typiques incluent le rendu des médias, le transcodage, la génomique et la simulation et le traitement d’événements de physique des particules. Si vous avez besoin de traiter beaucoup de fichiers individuels, c’est probablement une charge de travail HTC.

Pile logicielle de calcul de grappes

Une pile logicielle de calcul de grappes est composée de:

• Logiciel de gestion de système qui fournit et construit des clusters.
• Ordonnanceurs qui orchestrent l’exécution des tâches.
• Applications utilisateur final.

Les sections suivantes traitent des logiciels de gestion du système et des planificateurs.

Logiciel de gestion de système

Vous pouvez exécuter un logiciel de clustering directement sur le matériel bare-metal, avec des clusters sur site, ou dans des environnements virtualisés, comme avec cloudenvironments. L’orchestration manuelle de plusieurs nœuds dans un cluster prend du temps et est sujette aux erreurs. Vous pouvez utiliser un logiciel de gestion de cluster spécialisé pour provisionner et configurer plusieurs nœuds et ressources, ensemble, de manière déterministe et personnalisable.

Le logiciel open sourceElastiCluster de l’Université de Zurich fournit une approche cloud native de la gestion des clusters, avec prise en charge des nœuds de provisionnement, en utilisant Compute Engine, et la configuration des nœuds à l’aide d’un ensemble de livres Ansibleplaybooks. ElastiCluster provisionne les nœuds et installe un logiciel de base, y compris NFS pour le service de fichiers, la gestion des comptes d’utilisateurs NIS et le planificateur ajob pour l’exécution des applications utilisateur. ElastiCluster prend en charge une variété de programmeurs, et vous pouvez l’utiliser prêt à l’emploi ou le personnaliser pour répondre aux besoins des équipes de petite à moyenne taille.

Si vous utilisez d’autres systèmes de gestion de configuration pour gérer vos clusters HPC, tels que Chef, Puppet ou Terraform, vous pouvez tirer parti de cesinvestissements lors de votre migration vers Google Cloud en utilisant les outils et plugins disponibles.

Google Cloud fournit des services natifs pour le provisionnement et le déploiementdes systèmes logiciels multi-nœuds. Cloud Deployment Manager vous permet de provisionner un ensemble de ressources cloud, y compris le moteur de calcul, les groupes d’instances gérés par le moteur de calcul et le stockage dans le Cloud. Le didacticiel Htcondor vous montre comment utiliser Cloud Deployment Manager et les groupes d’instances gérés pour configurer et configurer un cluster.

Planificateurs de tâches

Une fois le cluster opérationnel, le logiciel qui gère l’exécution des tâches et l’allocation des nœuds est appelé planificateur de tâches (parfois appelé gestionnaire de charge de travail ou gestionnaire de files d’attente). Souvent, un gestionnaire de cluster est livré avec un planificateur de tâches intégré. Les planificateurs de tâches offrent une variété de fonctionnalités pour aider à gérer des tâches et des tâches, telles que:

• Prise en charge des priorités des tâches pour les utilisateurs et les groupes, ce qui aide à fournir une planification des tâches basée sur la politique.
• Prise en charge des tâches ayant échoué par mise en file d’attente et rééchelonnement des tâches.
• Prise en compte des dépendances des tâches et des besoins en ressources pour l’allocation des tâches.
• Mise à l’échelle de la taille du cluster en fonction du nombre de tâches dans la file d’attente.

Il existe une variété de gestionnaires de charge de travail commerciaux et open source populaires.Les exemples incluent HTCONDOR de l’Université du Wisconsin, Slurm de SchedMD, Univa Grid Engine et LSF Symphony d’IBM. Chacun a ses atouts.

HTCondor est construit avec une philosophie de rien partagé et est utilisé à travers des ressources partagées pour planifier de manière opportuniste des tâches sur des ressources autrement inactives. Il fournit son propre mouvement de données et ne nécessite donc aucun système sharedfile. En conséquence, HTCondor évolue vers des centaines de milliers de cœurs et vous pouvez l’utiliser sur plusieurs zones et régions. HTCondor a été utilisé pour les charges de travail hybrides, où le travail est partagé ou divisé entre des systèmes sur site et basés sur le cloud. Cependant, comme son nom l’indique, il se concentre surtravaux à haut débit, pas des emplois parallèles étroitement couplés.

Slurm et Univa Grid Engine fournissent un environnement de cluster HPC plus traditionnel, prenant en charge les applications parallèles à haut débit et hautes performances. Ils supposent un système de fichiers partagé entre les nœuds, ce qui élimine le besoin de déplacer les données. Les deux fournissent un environnement utilisateur pratique et familier pour le développement d’applications, car ce sont souvent les mêmes outils utilisés sur site.Ces planificateurs de tâches traditionnels sont suffisants pour les clusters de petite à moyenne taille, mais à mesure que la taille du cluster augmente, la charge sur le serveur de fichiers devient le col de noeud des performances. Les systèmes de fichiers parallèles et distribués (voir la section suivante) peuventaider à ce problème lorsqu’il est à grande échelle. Alternativement, lorsque l’accès aux fichiers à faible latence n’est pas requis, vous pouvez tirer parti du stockage dans le Cloud, qui fournit un accès aux objets parallèle à l’aide de l’API ou via gcsfuse, où la compatibilité de la solution est requise.

Enfin, Google Cloud inclut un service simple permettant de planifier des tâches basées sur aDocker sur Compute Engine pour des charges de travail à haut débit : l’API Cloud Life SciencesPipelines.Ce service vous oblige à décomposer la tâche en tâches, à gérer les dépendances entre les tâches et à gérer le cycle de vie des tâches. Thedsub open source project fournit un outil en ligne de commande pour lancer des tâches par lots et prend en charge l’API Cloud Life Sciences Pipelines.

Stockage

La plupart des applications HPC nécessitent une solution de stockage de fichiers prenant en charge l’API POSIX. Pour les clusters plus petits, FileStore fournit un service de stockage de fichiers NFS géré par Google. Pour les clusters plus grands, cependant, les E / S d’application peuvent devenir un goulot d’étranglement des performances.Les systèmes de fichiers Scale-out et parallèles, tels qu’Elastifichier (acquis par Google), Lustre ouQuobyte, aident à la mise à l’échelle vers de grands clusters (ou même des clusters plus petits et lourds en E / S).

Alternativement, lorsque l’accès aux fichiers à faible latence n’est pas requis, vous pouvez tirer parti du stockage en nuage, qui fournit un accès aux objets parallèle en utilisant l’API ou via gcsfuse, où la compatibilité POSIX est requise.

Opportunités pour le calcul de clusters dans le cloud

Il existe de nombreuses raisons d’exécuter des clusters de calcul dans le cloud:

• Temps de solution. Le lancement d’un cluster de qualité de production dans le cloud ne prend que quelques minutes, d’un petit cluster à 10 nœuds avec des centaines de cœurs disponibles à des clusters à grande échelle avec cent mille cœurs ou plus. En revanche, la construction de nouveaux clusters sur site peut prendre des mois avant d’être opérationnelle. Même lorsque les clusters sur site sont disponibles, ils ont généralement une utilisation élevée et de longs temps d’attente — parfois des heures ou des jours — avant l’exécution programmée des tâches. Au lieu de cela, vous pouvez créer vos propres clusters dans le cloud, les utiliser pour vos charges de travail et les supprimer lorsque votre analyse est terminée.

• Coût total de possession réduit. Google Cloud réduit non seulement le temps consacré à la solution, mais peut également réduire le coût total par exécution en tirant parti des machines virtuelles prévisibles, des remises sur l’utilisation à long terme et de la mise à l’échelle dynamique. Vous pouvez ajouter des nœuds lorsque les tâches sont en file d’attente et les supprimer lorsqu’elles ne sont pas nécessaires.

• Soutien à la collaboration. Dans de nombreuses situations, l’analyse de calcul est développée en collaboration avec différentes personnes dans plusieurs organisations. Google Cloud fournit des outils de gestion de l’identité et des accès au niveau du projet pour permettre un accès contrôlé aux données et aux outils d’analyse. Les utilisateurs autorisés peuvent accéder aux mêmes applications, données et clusters pour s’assurer que tout le monde est sur la même page sans avoir à copier des données, gérer des versions ou des configurations de synccluster.

• Ressources adaptées aux tâches. Étant donné que le coût d’une tâche dépend uniquement du nombre total d’heures de base, plutôt que du nombre d’instances, l’exécution de clusters dans le cloud permet à chaque équipe ou groupe d’avoir son propre cluster dédié. Cette approche peut atténuer un autre point douloureux majeur de l’élaboration de politiques autour de l’utilisation multi-groupes. Vous pouvez ensuite personnaliser chaque cluster cloud dédié pour l’adapter à l’application cible. Les clusters locaux ont tendance à comprendre une ressource unique partagée entre les différents groupes et applications. Dans un tel environnement, les politiques de partage entre les groupes ont tendance à être complexes à mettre en place et à maintenir.

• Intégration. Avant de pouvoir exécuter de gros travaux de calcul, les chercheurs doivent travailler de manière significative pour préparer les ensembles de données. Après le passage au cloud, ces chercheurs peuvent tirer parti des outils Big Data disponibles dans le cloud. Les sorties des systèmes de calcul doivent également être analysées. Des outils tels que Gigquery et Datalab peuvent offrir des avantages significatifs par rapport à ceux disponibles dans les systèmes sur site.

Considérations architecturales

Si les avantages décrits jusqu’à présent sont convaincants, il existe néanmoins de nombreux défis techniques qui entravent souvent les projets de migration.

• Mouvement des données. Les ensembles de données traités par les codes de calcul d’un cluster doivent généralement être mis en scène dans le cloud avant l’exécution des tâches.La gestion du mouvement des données peut être complexe, en fonction du volume desdonnées et de la façon dont elles sont gérées. Des outils tels Queavere peuvent vous aider en fournissant une couche de mise en cache dans le cloud qui déplace automatiquement les données lorsque cela est nécessaire, mais pour de nombreuses applications, les ensembles de données doivent être mis en scène manuellement.

• Accès aux données. De nombreuses applications HPC nécessitent un accès partagé à un ensemble de fichiers et de répertoires. La façon dont cet accès est fourni peut affecter de manière significative les performances de l’application. Vous pouvez tirer parti des données partagées stockées dansle stockage en nuage, dans des serveurs NFS tels Quefilestore, ou en utilisant des systèmes de fichiers parallèles, comme indiqué dans la section Stockage.

• Sécurité. Pour les données sensibles, vous devez veiller à ce que l’accès soit toujours autorisé et que les données soient correctement cryptées au repos et en transit. Alors que le stockage en nuage crypte les données au repos et en transit, vous pouvez appliquer une couche supplémentaire de contrôle et gérer les clés, soit avec le service de gestion des clés Cloud, soit par vous-même. Les clés doivent être récupérées ou installées sur les codes de calcul avant d’exécuter la tâche.

• Latence inter-nœuds. Pour les applications HPC étroitement couplées, les performances peuvent être sensibles à la latence inter-nœuds entre les nœuds du cluster.Étant donné que Google Cloud fournit des nœuds avec des tailles allant jusqu’à 64 cœurs, vous pouvez exécuter des tâches parallèles à 64 voies sans traverser les nœuds. Dans la plupart des cas, les travaux d’environ 1000 cœurs ou moins fonctionnent raisonnablement bien sur du matériel de réseau non spécialisé.

• Gestion des licences logicielles. De nombreuses applications commerciales nécessitent un serveur alicense, parfois appelé serveur de clés. Certaines applications viennent avec un serveur de licences intégré ou recommandé et d’autres peuvent être compatibles avec les offres de serveurs de licences existantes. Certains planificateurs de tâches peuvent aider à la gestion des licences et à empêcher l’exécution des tâches jusqu’à ce qu’une licence soit disponible.

Architectures recommandées et bonnes pratiques

Le calcul technique fournit de nombreux outils et approches pour différentes circonstances. Avec autant d’options, vous pourriez avoir du mal à démarrer.Quel que soit le choix du logiciel de gestion de cluster et du planificateur, il existe un certain nombre de bonnes pratiques que vous pouvez suivre lors de l’exécution sur Google Cloud.

• Tirez parti des machines virtuelles préemptables autant que possible. Les machines virtuelles préemptables sont tout comme les machines virtuelles régulières sur Compute Engine, mais coûtent jusqu’à 80% moins cher que les machines virtuelles régulières, avec la mise en garde qu’elles peuvent être récupérées avec peu de préavis.Pour les charges de travail à haut débit, vos planificateurs de tâches détectent la perte du nœud et la traitent comme une défaillance du nœud et replanifient toutes les tâches exécutées sur ce nœud sur une ressource différente. Alors que tout travail effectué sur ces nœuds perdus peut être perdu, la probabilité de perte de nœud est suffisamment faible pour que le prix le plus bas en vaille la peine. Le taux de perte attendu est de 5% à 15%. Les mesures préventives sont limitées à un maximum de 24 heures d’utilisation avant d’être récupérées.
• Tirez parti du coût et de la bande passante du stockage en nuage au lieu de faire fonctionner votre propre système de fichiers parallèle. Le stockage dans le cloud offre une cohérence élevée et des performances parallèles évolutives à faible coût global.Alors que la latence du premier octet est élevée à environ 100 ms, les applications qui peuvent gérer le stockage dans le Cloud au lieu d’exécuter un serveur de fichiers parallèle sur un moteur de calcul sont plus rentables. La largeur de bande disponible entre le stockage en nuage et les nœuds de calcul est suffisante pour de nombreuses applications, certains clients ont signalé une bande passante globale soutenue de plus de 23 Go/ s.
• Créez un cluster à une seule application ou à un seul groupe. Les clusters traditionnels sont partagés entre plusieurs utilisateurs, groupes et applications, ce qui peut entraîner de longs temps d’attente pour les tâches et une utilisation inefficace des ressources par les applications. Sur le cloud OnGoogle, envisagez de créer plusieurs clusters pour chaque groupe ou projet et d’utiliser des clusters optimisés pour des applications particulières qui s’exécutent sur eux. Que vous exécutiez un cluster pendant deux heures ou deux clusters pendant une heure chacun, le coût global est le même, mais ce dernier modèle peut réduire les temps d’attente et améliorer les performances de l’application.

Bien que chaque implémentation soit unique, les sections suivantes fournissent des recommandations générales pour trois cas courants.

Chercheur indépendant cherchant à traiter ses données

Les chercheurs individuels cherchent généralement à exécuter leur application sur leurs données et à les compléter le plus rapidement possible. Ils pourraient être des experts dans leurapp, mais ils ne veulent pas être des experts dans l’administration ou la gestion de clusters.

Si vous exécutez des charges de travail à haut débit, vous pouvez envisager d’utiliser l’API Cloud Life SciencesPipelines.L’API Pipelines vous oblige à placer votre application dans un conteneur Docker et à placer vos fichiers d’entrée dans un compartiment de stockage en nuage. Après cela, vous pouvez utiliser l’outil de ligne de commande gcloud pour lancer l’application contre chacun des fichiers du compartiment de stockage en nuage. Vous pouvez placer les résultats dans un autre compartiment de stockage en nuage.

Voici un exemple de commande pour exécuter une tâche qui utilise Samtools pour générer un fichier d’index BAM à partir d’un fichier BAM d’entrée:

gcloud alpha genomics pipelines run --pipeline_id \--logging gs:///logs \--inputs inputFile=gs://genomics-public-data/gatk-examples/example1/NA12878_chr22.bam \--outputs outputFile=gs:////output/NA12878_chr22.bam.bai

Où

• représente l’ID de votre application dans l’API Pipelines.
• représente le nom de votre compartiment de stockage Cloud.
• représente le nom de votre répertoire.

Il n’y a pas de cluster à provisionner ou à gérer. Les tâches s’exécutent simplement jusqu’à l’achèvement dans une machine virtuelle provisionnée et gérée par l’API Pipelines. C’est un coût efficace car Calculez les factures du moteur par seconde d’utilisation.

Cluster de petite à moyenne taille pour un projet ou une équipe unique

Dans un projet ou une équipe, les membres peuvent avoir accès à un cluster géré par une équipe centrale pour les utilisateurs de l’ensemble de leur entreprise, ou peuvent avoir accès à des ressources à grande échelle dans un centre HPC hors site. Dans les deux cas, les clusters sont gérés et accessibles par des professionnels à l’aide d’outils standard. Par exemple, les utilisateurs peuvent utiliser ssh pour se connecter à un nœud principal et utiliser des scripts Grid Engine submit pour soumettre des tâches à exécuter.

Une approche pour une telle équipe consiste à utiliser ElastiCluster pour définir un environnement de clusters similaire à leurs systèmes sur site. Ils peuvent personnaliser thecluster en sélectionnant un type de machine de moteur de calcul qui convient le mieux à leur application, et personnaliser les scripts de démarrage pour installer les dépendances logicielles pour leur application. Les données d’entrée peuvent toujours être mises en scène dansle stockage à haute résolution, et vous pouvez installer gcsfuse sur les nœuds de calcul pour monter les données d’entrée.

Ces détails sont enregistrés dans le fichier de configuration ElastiCluster, et lorsqu’un calcul est nécessaire, un cluster est créé à l’aide de l’outil de ligne de commande, par exemple:

% elasticluster start astrocluster1

Le cluster, nommé dans le fichier de configuration comme astrocluster1, est provisionedand configuré comme spécifié. Les définitions d’un fichier de configuration sont flexibles et prennent en charge différents types de nœuds pour les nœuds de tête et de calcul, les disques Compute Enginepersistent pour l’espace de travail, les machines virtuelles préemptibles pour réduire le coût des charges de travail à entrée élevée et les GPU pour un fonctionnement accéléré. Un exemple de configuration de base pour un cluster basé sur Slurm avec 10 nœuds de calcul et 1 nœud de tête utilisant des machines virtuelles à 32 cœurs basées sur CentOS se présenterait comme suit:

 cloud=google login=google setup=ansible-slurm security_group=default image_id=centos-7-v20170327 flavor=n1-standard-32 frontend_nodes=1 compute_nodes=10 ssh_to=frontend boot_disk_size=50 

Enfin, lorsque plus aucune tâche n’est en cours d’exécution dans le système, vous pouvez arrêter le cluster:

% elasticluster stop astrocluster1

Pour des charges de travail plus importantes, vous pouvez:

• Regardez pour personnaliser les types de machines de cluster afin de réduire davantage les coûts.
• Ajoutez un filtre parallèle externe pour augmenter les performances à grande échelle.
• Ajoutez des capacités de mise à l’échelle automatique pour ajouter et supprimer des nœuds supplémentaires en fonction de la profondeur de file d’attente.

Centre HPC ajoutant une capacité de rafale aux clusters existants

Les centres HPC centraux ont une capacité de calcul énorme, mais parce qu’ils sont utilisés par de nombreux groupes de l’entreprise ou de l’organisation, les centres HPC ont tendance à avoir une utilisation constamment élevée et de longs temps d’attente. Ils sont généralement achetés avec une capacité de production particulière à l’esprit, et lorsque des charges de travail imprévues sont introduites dans le mélange, elles peuvent ralentir considérablement les progrès.

Dans ces situations, vous pouvez accéder à l’environnement Google Cloud en ajoutant temporairement des nœuds de calcul au cluster. Le cluster devient un hybride, le nœud principal et certains nœuds de calcul s’exécutant sur site, et d’autres codes de calcul s’exécutant sur Google Cloud. Lorsque les files d’attente de tâches ont été vidées, les nœuds supplémentaires peuvent être libérés.

L’éclatement du nuage est pratique pour plusieurs raisons:

• Il maintient un environnement utilisateur cohérent pour la soumission et la gestion des tâches. Les utilisateurs ne savent pas ou ne se soucient pas si des nœuds supplémentaires sont ajoutés.
• Il permet aux responsables informatiques de définir des stratégies pour savoir quand éclater, afin de contrôler les coûts.

Le plus grand défi consiste à fournir un espace de noms de données et de fichiers cohérent pour les tâches de l’utilisateur sur les nœuds locaux et Google Cloud. Les nœuds Cloud Google peuvent ne pas avoir accès aux mêmes systèmes de fichiers internes que les nœuds sur site. Dans cette situation, les tâches qui référencentces fichiers ne s’exécuteront pas.

Si les nœuds Google Cloud sont configurés avec des permissions d’accès aux fichiers internes, les tâches s’exécuteront, mais pourraient ne pas fonctionner de la même manière et pourraient créer une bande passante réseau et des frais de sortie supplémentaires. En outre, les tâches parallèles réparties entre les nœuds locaux et cloud peuvent également ne pas fonctionner correctement avec la latence supplémentaire entre les différentes parties de l’application.

Pour les tâches à haut débit, l’utilisation de HTCondor pour accéder aux ressources cloud évite de nombreux défis. HTCondor prend en charge le provisionnement dynamique à l’aide de Glideinwms.Lorsque des tâches sont soumises dans la file d’attente d’une tâche, elles peuvent déclencher la création de nœuds et leur ajout au cluster. Lorsqu’ils sont ajoutés, le planificateur condor transfère les fichiers d’entrée au nœud désigné et utilise ces nœuds supplémentaires pour exécuter les tâches et vider la file d’attente.

En savoir plus sur les cas d’utilisation du cluster computing sur Google Cloud:

• Google Cloud, HEPCloud et sonder la nature de la nature
• 220 000 cœurs et comptage: un professeur de mathématiques du MIT bat le record du plus grand travail de moteur de calcul

En savoir plus sur:

• Serveurs de fichiers sur Compute Engine
• Documentation du gestionnaire de déploiement Cloud

Commencez avec votre cluster:

• Traitement par lots avec Compute Engine Autoscaler
• Création d’un cluster HTCondor à l’aide de modèles Cloud Deployment Manager

Exemples de projets sur GitHub:

• dsub exemple : Travaux par lots simples avec Docker
• Exemple ElastiCluster

• Exemples d’API de pipelines

• Essayez d’autres fonctionnalités de Google Cloud par vous-même. Jetez un coup d’œil à nos articles.