Utilisation de clusters à grande échelle dans le Cloud

Cet article propose des recommandations pour exécuter des traitements techniques à grande échelle sur la plateforme Google Cloud Platform (GCP). De nombreuses applications nécessitent un grand nombre de « compute », connectés entre eux pour former un cluster, lequel coordonne le traitement et l’accès aux données sur tous les nœuds.

Les concepts et les technologies sous-jacentes de l’IT en cluster se sont développés au cours des dernières décennies, et sont désormais matures et largement appliqués. La migration de la pile logicielle vers le Cloud peut entraîner des contraintes supplémentaires, mais offre également des possibilités incontestables de réduction des coûts et d’atténuation des goulets d’étranglement existants dans les environnements IT hautes performances d’aujourd’hui.
Ce guide présente un aperçu des technologies, des enjeux et des différentes solutions actuelles d’exécution de clusters de traitement sur GCP.

Le Cluster collecte et coordonne un ensemble de machines pour qu’elles travaillent ensemble à la réalisation d’une tâche. Les Clusters sont généralement dotés d’un nœud principal unique (parfois appelé nœud maître), d’un certain nombre de nœuds de calcul, et d’autres nœuds spécialisés, le cas échéant. Le nœud principal constitue le cerveau du système et est chargé :

  • D’enregistrer les nœuds de calcul au sein du système.
  • De surveiller les nœuds.
  • D’affecter les tâches aux nœuds particuliers.

clusters-technical-compute-nodes.png

Figure 1. Un cluster est composé d’un nœud principal et d’un ensemble de nœuds de calcul. Les utilisateurs communiquent avec le nœud principal, lequel délègue ensuite le travail aux nœuds de calcul.

Les utilisateurs soumettent des travaux, composés de plusieurs tâches, qui constituent une unité élémentaire de travail. Certaines applications nécessitent que toutes les tâches d’un travail soient exécutées simultanément et permettent la communication entre les tâches pour mettre en œuvre un algorithme parallèle.
D’autres travaux sont associés à un ensemble de dépendances de tâches de sorte que certaines tâches soient exécutées avant d’autres, tandis que d’autres tâches nécessitent des configurations de nœuds particulières en termes de mémoire, CPU, ou d’autres matériels sur lesquels elles fonctionnent.
Les tâches sont des fichiers exécutables qui lisent des données d’entrée dans leur espace de stockage, traitent ces données pour produire un résultat, puis enregistrent les résultats finaux à nouveau dans l’espace de stockage.

Les charges de travail du traitement en cluster peuvent être divisées en deux principaux types :

  • Calcul haute performance (HPC, High-performance computing) — Type de traitement qui utilise de nombreux nœuds de travail, étroitement liés et qui s’exécutent simultanément pour accomplir une tâche. Ces machines nécessitent généralement une faible latence réseau pour communiquer efficacement. Des exemples d’applications dans ce domaine sont les modélisations météorologiques, la mécanique de fluides dynamiques, la modélisation de contraintes dans l’ingénierie et la conception électronique.
  • Calcul à haut rendement (HTC, High-throughput computing) — Type de traitement où les applications disposent de multiples tâches qui peuvent être traitées indépendamment les unes des autres, sans que les nœuds individuels aient besoin de communiquer entre eux. Parfois, ces charges de travail sont désignées comme massivement parallèles ou comme charges de travail par lot. Des exemples classiques d’applications sont le rendu multimédia, le transcodage, la génomique, la simulation de phénomènes de physiques de particules et le traitement. Si vous devez traiter un grand nombre de fichiers individuels, il s’agit sans doute d’une charge de travail HTC.

Pile logicielle du cluster

Une pile logicielle de cluster se compose des éléments suivants :

  • Un logiciel de gestion du système qui fournit et construit les clusters.
  • Des planificateurs qui gèrent l’exécution des travaux.
  • Les applications de l’utilisateur final.

Les sections suivantes décrivent le logiciel de gestion du système et les planificateurs.

Logiciel de gestion du système

Vous pouvez exécuter un logiciel de cluster directement au niveau du matériel même, comme c’est le cas des clusters physiques sur site, ou dans des environnements virtualisés, tels que les environnements Cloud. La gestion manuelle de multiples nœuds dans un cluster est à la fois chronophage et source d’erreurs. Vous pouvez utiliser un logiciel de gestion de cluster spécialisé pour fournir et configurer de multiples nœuds et ressources ensemble, d’une manière répétable et déterministe.

Le logiciel open source ElastiCluster créé par l’université de Zurich, fournit une approche Cloud Native de la gestion de cluster. Il assure le provisionnement des nœuds, par l’intermédiaire de Google Compute Engine et les configure via Ansible. ElastiCluster fournit les nœuds et installe une pile logicielle de base, y compris NFS pour les fichiers, la gestion du compte utilisateur NIS et un planificateur de tâches qui exécute les applications de l’utilisateur. Il prend en charge divers planificateurs, est facile d’utilisation ou peut être personnalisé pour s’adapter aux besoins d’équipes de PME ou TPE.

Si vous utilisez d’autres outils de gestion des configurations pour gérer les clusters HPC, tels que Chef, Puppet ou Terraform, vous pouvez tirer parti de ces investissements lors de votre migration vers le Cloud en utilisant les outils et plug-ins disponibles. Pour plus de détails, consultez Compute Engine Management avec Puppet, Chef, Salt et Ansible.

GCP fournit des services natifs pour la fourniture et le déploiement de systèmes logiciels multinœuds. Google Cloud Deployment Manager vous fournit un ensemble de ressources Cloud, y compris Compute Engine, les groupes d’instances managées Compute Engine, et Google Cloud Storage. Le didacticiel HTCondor vous explique comment utiliser Cloud Deployment Manager et les groupes d’instances managées pour fournir et configurer un cluster.

Planificateurs de tâches (job schedulers)

Dès lors que le cluster est opérationnel, le logiciel chargé de l’exécution des tâches et de l’affectation des nœuds est désigné comme planificateur de tâches (ou parfois gestionnaire de charge de travail ou encore gestionnaire de file d’attente).

Souvent, un gestionnaire de cluster intègre également un planificateur de tâches. Les planificateurs de tâches offrent diverses fonctionnalités de gestion de travaux et de tâches, telles que :

  • La prise en charge de la hiérarchie des travaux entre les utilisateurs et les groupes, qui contribue à assurer une planification des travaux en fonction d’une politique spécifique.
  • La prise en charge des tâches échouées en les replaçant en file d’attente et en les replanifiant.
  • La prise en compte des besoins des dépendances et des ressources des tâches pour les affecter.
  • L’évolution de la dimension du cluster en fonction du nombre de travaux dans la file d’attente.

De nombreux gestionnaires de charge de travail open source sont disponibles. Par exemple,
HTCondor de l’université du Wisconsin, Slurm de SchedMD, Univa Grid Engine, et LSF Symphony d’IBM.
Chacun présente ses avantages.

HTCondor repose sur une philosophie shared-nothing et est facile à utiliser sur diverses ressources partagées pour planifier des travaux de manière optimale, sur des ressources inactives. Il est doté de son propre mécanisme de déplacement de fichiers et ne nécessite donc aucun système de fichiers partagé. Par conséquent, il s’adapte à des centaines de milliers de nœuds principaux et peut être utilisé dans diverses zones et régions du monde. HTCondor a été utilisé pour des charges de travail hybrides, lorsque le travail est partagé ou divisé entre des systèmes physiques et dans le Cloud. Cependant, comme son nom l’indique, il est dédié aux travaux à haut rendement, parallèles, mais non étroitement liés.

Slurm et Univa Grid Engine offrent un environnement de cluster HPC plus traditionnel, en prenant tous deux en charge les applications parallèles à la fois à haut rendement et à haute performance. Ils reposent tous deux sur un système de fichiers partagé par tous les nœuds, qui nous affranchit des transferts de données. Les deux offrent un environnement utilisateur pratique et convivial, car il s’agit le plus souvent des mêmes outils que ceux utilisés sur site.
Ces planificateurs de travaux traditionnels conviennent aux clusters de petite taille et de taille moyenne, mais dès lors que la taille du cluster augmente, la charge supportée par le serveur de fichiers entrave la performance.
Les systèmes de fichiers parallèles, tels que Gluster et Ceph, peuvent contribuer à atténuer ce problème à grande échelle. Sinon, lorsque l’accès aux fichiers à faible latence est inutile, vous pouvez tirer parti du stockage dans le Cloud, qui garantit l’accès à un objet parallèle à l’aide de l’API ou à travers gcsfuse, qui nécessite la compatibilité POSIX.

Enfin, GCP inclut un service simple de planification de tâche de type Docker sur Compute Engine pour les charges de travail à haut rendement : l'API Pipelines de Google Genomics. Ce service est simple d’utilisation, mais vous oblige à décomposer les travaux en tâches, à gérer les dépendances entre les tâches et la durée de vie de la tâche.
Le projet open source dsub présente un outil de ligne de commande qui facilite encore plus le lancement de travaux par lots et prend en charge l’API Genomics Pipelines.

Pourquoi un cluster dans le Cloud ?

Il existe de nombreuses bonnes raisons pour exécuter des clusters de calcul dans le Cloud :

  • Délai de mise en œuvre. Le lancement d’un cluster exploitable dans le Cloud ne prend que quelques minutes, qu’il s’agisse d’un cluster de 10 nœuds comportant des centaines de cœurs disponibles jusqu’à des clusters à grande échelle incluant des centaines de milliers ou plus de cœurs. En revanche, la mise en place de nouveaux clusters physiques sur site peut prendre des mois avant que ceux-ci ne soient opérationnels. Même lorsque les clusters sur site sont disponibles, les temps d’attente d’utilisation et de file d’attente sont généralement interminables — il faut parfois attendre des heures ou des jours — avant de voir ses travaux planifiés pour être exécutés. Par contre, vous pouvez construire vos propres clusters dans le Cloud, les utiliser pour gérer vos charges de travail et les arrêter une fois votre analyse terminée.
  • Abaisser le coût total de possession. Non seulement GCP réduit le délai de mise en œuvre, mais il réduit également le coût total de possession par exécution, en tirant parti des machines virtuelles préemptibles , des remises sur l’utilisation à long terme et de l’évolutivité dynamique. Vous pouvez ajouter des nœuds alors que les travaux sont en file d’attente et les éliminer une fois qu’ils sont devenus inutiles.
  • Prise en charge de la collaboration. Dans de nombreux cas, la collaboration pour l’analyse de traitement implique différentes personnes dans de nombreuses entreprises. GCP est doté d’outils de gestion des identités et de gestion des accès,
    permettant l’accès contrôlé aux données et aux outils d’analyse. Ainsi, les utilisateurs peuvent accéder aux mêmes applications, données et clusters et sont assurés de se trouver sur la même page sans devoir copier des données, gérer les versions, ni synchroniser des configurations de clusters.
  • Ressources adaptées aux tâches. Étant donné que le coût d’un travail dépend uniquement du nombre d’heures de cœurs utilisées totales, et non pas du nombre d’instances, l’exécution de clusters dans le Cloud permet à chaque équipe ou groupe de disposer de son propre cluster dédié. Cette approche permet d’éliminer un inconvénient majeur lié au développement de politiques d’utilisation multi groupes. En effet, il est possible de personnaliser et d’adapter chaque cluster dédié à son application cible. Les clusters sur site, quant à eux, sont plus souvent composés de ressources universelles partagées par divers groupes et applications. Dans un tel environnement, les politiques de partage entre les groupes sont souvent complexes à configurer et à maintenir.
  • Intégration. Avant de pouvoir exécuter un grand nombre de travaux de calcul, les chercheurs effectuent un travail significatif de préparation des datasets. Après les avoir placés dans le Cloud, ces chercheurs peuvent tirer parti des outils Big Data disponibles dans le Cloud. Les résultats des systèmes de calcul doivent également être analysés. Pour cela, des outils tels que Google BigQuery et Google Cloud Datalab peuvent conférer des avantages certains, comparés aux outils disponibles sur les systèmes physiques.

clusters-technical-compute-compare.png

Figure 2. Les clusters sur site conventionnels sont partagés par les utilisateurs et les groupes et prennent en charge de nombreux besoins d’applications très différentes. Au contraire, lorsque vous passez à GCP, vous avez la possibilité de personnaliser les propriétés du cluster pour l’adapter aux besoins de l’application et ainsi, réduire le coût tout en augmentant les performances.

Quid de l’architecture ?

Même si les avantages décrits jusqu’ici sont convaincants, certains défis technologiques freinent souvent les projets de migration.

  • Mouvement des données. Les dataset qui sont traités par des nœuds de calcul d’un cluster doivent généralement être transférés vers le Cloud avant d’exécuter les travaux. La gestion de ces mouvements de données peut être complexe, en fonction du volume de ces données et de leur gestion. Des outils tels que Avere peuvent aider en créant une couche de mise en cache sur le Cloud qui déplace automatiquement les données en fonction des besoins. Mais pour de nombreuses applications, les données doivent être transférées manuellement.
  • Accès aux données. De nombreuses applications HPC nécessitent un accès partagé à un ensemble de fichiers et répertoires. La manière dont cet accès est octroyé peut pénaliser de manière significative les performances de l’application. Vous pouvez tirer parti des données partagées dans Cloud Storage, sur les serveurs NFS, ou utiliser des systèmes de fichiers parallèles tels que Gluster et Ceph.
  • Sécurité. Pour les données sensibles, vous devez veiller à ce que l’accès soit toujours sécurisé et les données correctement chiffrées, qu’elles soient inactives ou en transit. Même si Cloud Storage chiffre les données inactives et en transit, vous pouvez appliquer une couche de contrôle supplémentaire et gérer des clés de chiffrement, soit dans Key Management Service de Google soit par vous-même. Les clés doivent être extraites ou installées sur les nœuds de calcul avant l’exécution du travail.
  • Latence inter nœud. Pour les applications HPC étroitement liées, la performance peut dépendre de la latence inter nœud entre les nœuds d’un cluster. Étant donné que GCP fournit des nœuds pouvant comprendre jusqu’à 64 cœurs, vous pouvez donc exécuter des travaux parallèles à 64 voies sans traverser de nœuds. Souvent, des travaux comportant environ 1 000 cœurs ou moins fonctionnent correctement sur des matériels réseau non spécialisés.
  • Gestion de licence logicielle. De nombreuses applications commerciales nécessitent un serveur de licences, également désigné comme serveur de clés. Certaines applications intègrent ou recommandent un serveur de licences spécifique, tandis que d’autres sont compatibles avec des offres de serveurs de licences existants. Certains planificateurs de tâches peuvent aider à la gestion des licences et interrompre l’exécution d’un travail jusqu’à l’obtention d’une licence.

Architectures et meilleures pratiques recommandées

L’IT propose de nombreux outils et approches adaptés à différentes circonstances. Avec une offre aussi pléthorique, vous aurez peut-être du mal à faire votre choix. Quel que soit votre choix de planificateur et de management de cluster, vous pouvez vous approprier un certain nombre de meilleures pratiques lors de l’exécution de GCP.

  • Tirer parti des machines virtuelles préemptibles dès que possible. Les machines virtuelles préemptibles ne sont rien d’autre que des machines virtuelles conventionnelles sur Compute Engine, mais qui coûtent 80 % moins cher que les premières, avec l’inconvénient qu’elles peuvent être récupérées, sans avis préalable. Pour les charges de travail à haut rendement, vos planificateurs de tâches détecteront la perte d’un nœud, le traiteront comme une panne, et replanifieront alors les tâches de ce nœud sur une ressource différente. Le travail effectué sur ces nœuds disparus pourrait être perdu, mais la probabilité de perte d’un nœud est suffisamment faible pour que le prix proposé en vaille la peine. Le taux de perte attendu est compris entre 5 et 15 %. Les machines virtuelles préemptibles présentent une durée d’utilisation de 24 heures maximum avant d’être récupérées.
  • Tirer parti du coût et de la bande passante de Cloud Storage au lieu d’exécuter votre propre système de fichiers parallèles. Cloud Storage assure une forte cohérence et des performances parallèles évolutives pour un coût très faible. Même si la latence du premier octet est à environ 100 ms, les applications qui peuvent tirer parti de Cloud Storage au lieu d’exécuter un serveur de fichiers parallèles sur Compute Engine, sont bien plus économiques. La bande passante disponible entre Cloud Storage et les nœuds de calcul est suffisante pour de nombreuses applications : certains clients ont en effet témoigné d’une largeur de bande globale constante d’une valeur supérieur à 23 Go/s .
  • Construire un cluster d’application unique ou de groupe unique. Les clusters traditionnels sont partagés entre de nombreux utilisateurs, groupes et applications, ce qui peut entraîner des files d’attente très longues pour les travaux et une utilisation inefficace des ressources par les applications. Sur GCP, envisagez de créer plusieurs clusters pour chaque groupe ou projet, et d’utiliser des clusters optimisés pour les applications qui s’exécutent dessus. 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, dans le second cas, les durées d’attente des fils d’attente est réduit et les performances de l’application améliorées.

Même si chaque cas d’usage est unique, les sections suivantes fournissent des recommandations générales sur trois cas courants.

Des chercheurs indépendants qui souhaitent traiter leurs données

Les chercheurs visent généralement à exécuter leur application sur leurs données et à obtenir des résultats aussi vite que possible. Ils peuvent connaitre leur application sur le bout des doigts, mais n’ont pas envie de se familiariser avec l’administration ou la gestion de clusters.
Si vous exécutez des charges de travail à haut rendement, vous pouvez donc envisager d’utiliser l’ API Pipelines de Genomics.

L’API Pipelines ne vous demande que d’insérer votre application dans un conteneur Docker et de placer vos fichiers d’entrée dans un compartiment Cloud Storage. Une fois cette opération effectuée, vous pouvez utiliser l’outil de commande en ligne gcloud pour lancer l’application sur chacun des fichiers présents dans le compartiment Cloud Storage. Les résultats ainsi obtenus peuvent être placés dans un autre compartiment Cloud Storage.

Voici un exemple d’une commande permettant d’exécuter une tâche qui utilise les samtools pour générer un fichier d’index BAM provenant d’un fichier BAM d’entrée :


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

Il est inutile de fournir ou de gérer un cluster. La tâche s’exécute simplement jusqu’à la fin sur une machine virtuelle, fournie et gérée par l’API Pipelines. Cette solution est économique, car Compute Engine facture à la minute d’utilisation.

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

Au sein d’un projet ou d’une équipe, les membres peuvent avoir accès à un cluster exécuté par une équipe centrale d’utilisateurs dans leur entreprise, ou peuvent avoir accès à des ressources à grande échelle depuis un centre HPC hors site.
Dans les deux cas, les clusters sont gérés professionnellement et il est possible d’y accéder via des outils standard.
Par exemple, des utilisateurs peuvent accéder via SSH à un nœud principal et utiliser des scripts de soumission Grid Engine pour soumettre des travaux à exécuter.

L’approche pour une telle équipe consisterait à utiliser ElastiCluster pour définir un environnement de cluster similaire à celui installé dans leurs systèmes physiques. Elle peut ainsi personnaliser le cluster en sélectionnant le type de Compute Engine le mieux adapté à son application, et en personnalisant les scripts de démarrage pour installer les dépendances logicielles pour son application. Il est toujours possible de placer les données dans Cloud Storage, et d’installer gcsfuse sur les nœuds de calcul pour monter les données d’entrée.

Ces détails sont stockés dans le fichier de configuration ElastiCluster et, une fois le calcul nécessaire, un cluster est créé au moyen d’un outil de ligne de commande, par exemple :
% elasticluster start astrocluster1

Le cluster, nommé astrocluster1 dans le fichier de configuration, est fourni et configuré comme spécifié. Les définitions dans un fichier de configuration sont flexibles et prennent en charge différents types de nœuds pour les nœuds principaux et de calcul, l’espace de travail des disques persistances de Compute Engine, les machines virtuelles préemptibles pour diminuer les coûts pour des charges de travail à haut rendement et des GPU pour accélérer le fonctionnement.
Un exemple de configuration de base pour un cluster de type Slurm, avec 10 nœuds de calcul et 1 nœud principal qui utilise des machines virtuelles à 32 cœurs s’exécutant sur CentOS serait comme suit :

[cluster/astrocluster1]
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, dès lors qu’aucun travail n’est plus exécuté sur le système, il est possible d’arrêter le cluster :
% elasticluster stop astrocluster1

Pour les charges de travail plus importantes, vous pouvez :

  • Chercher à personnaliser les types de machines de cluster, afin de réduire encore les coûts.
  • Ajouter un système de fichiers parallèles externe pour augmenter les performances à grande échelle.
  • Ajouter des capacités d’évolutivité automatique pour ajouter et éliminer des nœuds en fonction de la longueur de la file d’attente.

Le centre HPC peut ajouter des capacités en burst aux clusters existants

Les centres HPC disposent d’une grande capacité de calcul, mais étant donné qu’ils sont utilisés par de plusieurs groupes d’une entreprise ou d’une organisation, ils ont tendance à se caractériser par des temps d’utilisation élevés et des files d’attente très longues.
Leur achat est souvent décidé en fonction d’une capacité de production spécifique, et lorsque des charges de travail non prévues sont soumises au système, ils risquent de ralentir la progression de manière significative.

Dans ce cas, vous pouvez traiter en dépassement dans l’environnement GCP en ajoutant temporairement des nœuds aux clusters. Le cluster devient alors une version hybride mélangeant le nœud principal et des nœuds de calcul physiques, côtoyant d’autres nœuds de calcul s’exécutant sur GCP. Une fois les files d’attente des travaux vidées, les nœuds supplémentaires peuvent être libérés.

Le traitement en burst dans le Cloud est pratique pour certaines raisons :

  • Il maintient un environnement cohérent pour l’utilisateur final et lui permet de soumettre et de gérer des travaux. L’utilisateur final ne sait même pas et ne se préoccupe pas de savoir si des nœuds sont ajoutés.
  • Il permet aux cadres IT de définir des politiques de recours au mode « burst », afin de contrôler les coûts.

L’enjeu le plus important est de fournir des données et des noms de fichiers cohérents pour les travaux des utilisateurs sur les nœuds physiques et GCP. Les nœuds GCP peuvent ne pas avoir accès aux systèmes de fichiers internes, contrairement aux nœuds physiques. Dans ce cas, les travaux faisant référence à ces fichiers ne seront pas exécutés.

Si les nœuds GCP sont configurés avec des permissions d’accès aux fichiers internes, les travaux seront alors exécutés, mais ne se dérouleront sans doute pas de la même manière et pourront solliciter plus de bande passante et entraîner des coûts supplémentaires pour obtenir des résultats.
En outre, les travaux parallèles qui sont divisés entre les nœuds physiques et les nœuds dans le Cloud peuvent également réaliser de médiocres performances en raison de l’augmentation de la latence entre les différentes portions de l’application.

Pour les travaux à haut rendement, l’utilisation de HTCondor pour passer en mode « burst » dans les ressources du Cloud peut atténuer nombre de ces enjeux.
HTCondor prend en charge le provisionnement dynamique par l’intermédiaire GlideInWMS. Au fur et à mesure que les travaux sont soumis dans une file d’attente, ils peuvent déclencher des nœuds fournis et ajoutés au cluster. Dès lors qu’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.

Source : Google Cloud Platform

Nos services autour de Google Cloud Platform