Utiliser des clusters pour les calculs techniques à grande échelle dans le cloud

Cette solution propose des conseils pour réaliser des calculs techniques à grande échelle sur Google Cloud. De nombreuses applications de calcul technique requièrent un grand nombre de nœuds de calcul individuels, interconnectés au sein d'un cluster, ainsi qu'un système coordonnant les calculs et l'accès aux données pour l'ensemble des nœuds.

Les concepts et les technologies sous-jacents aux clusters de calcul se sont développés au cours des dernières décennies et sont désormais des outils courants arrivés à maturité. Migrer une pile logicielle vers Google Cloud peut occasionner quelques difficultés, mais c'est également une opportunité de réduire les coûts et de résoudre certains goulots d'étranglement dans les environnements de calcul hautes performances existants. Ce guide fournit une vue d'ensemble des technologies, des défis et de la panoplie actuelle de solutions permettant d'exécuter des clusters de calcul sur Google Cloud.

Les clusters de calcul consistent à regrouper et coordonner un ensemble de machines pour les faire travailler conjointement à résoudre une tâche. Les clusters comportent 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 nœuds supplémentaires spécialisés. Le nœud principal est le cerveau du système. Il est responsable de :

  • l'enregistrement des nœuds de calcul au sein du système ;
  • la surveillance des nœuds ;
  • l'allocation des tâches à des nœuds donnés.
Un cluster se compose d'un nœud principal et d'un ensemble de nœuds de calcul.
Figure 1. Un cluster est composé d'un nœud principal et d'un ensemble de nœuds de calcul. Les utilisateurs interagissent avec le nœud principal qui coordonne ensuite le travail des nœuds de calcul.

Les utilisateurs soumettent des travaux constitués d'un certain nombre de tâches, une tâche représentant l'unité de travail de base. Certaines applications nécessitent l'exécution simultanée de toutes les tâches d'un travail et permettent aux tâches de communiquer pour mettre en œuvre un algorithme parallèle. Certaines tâches présentent un ensemble complexe de dépendances entre elles, ce qui requiert l'exécution de certaines tâches avant les autres. Enfin, certaines tâches peuvent nécessiter des configurations de nœud particulières en termes de mémoire, de processeurs ou de tout autre matériel particulier dont elles ont besoin pour s'exécuter. Les tâches sont des exécutables qui lisent les données d'entrée à partir du stockage, les traitent pour produire un résultat, puis écrivent le résultat final dans l'espace de stockage.

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

  • Calcul hautes performances (HPC, high performance computing) : type de calcul qui utilise de nombreux nœuds de calcul étroitement couplés et s'exécutant simultanément pour accomplir une tâche. Ces machines ont généralement besoin d'une latence réseau faible pour pouvoir communiquer efficacement. Les exemples d'applications de ce type incluent la modélisation météorologique, la dynamique des fluides numérique (CFD, Computational Fluid Dynamics), la modélisation des contraintes en ingénierie et la conception électronique.

  • Calcul à haut débit (HTC, high throughput computing) : type de calcul dans lequel les applications ont plusieurs tâches pouvant être traitées indépendamment les unes des autres sans que les nœuds de calcul individuels aient besoin de communiquer. Parfois, on utilise l'expression de parallélisme embarrassant ou de tâches par lot pour qualifier ces charges de travail. Le rendu multimédia, le transcodage, la génomique, ainsi que la simulation et le traitement en physique des particules, en sont des exemples typiques. Si vous devez traiter de nombreux fichiers individuels, il s'agit probablement d'une charge de travail HTC.

Pile logicielle pour les clusters de calcul

La pile logicielle d'un cluster de calcul est composée :

  • d'un logiciel de gestion de système qui provisionne et crée les clusters ;
  • de planificateurs qui orchestrent l'exécution des travaux ;
  • d'applications pour utilisateurs finaux.

Les sections suivantes abordent le logiciel de gestion du système et les planificateurs.

Logiciel de gestion de système

Vous pouvez exécuter les logiciels d'un cluster directement sur du matériel dédié, comme c'est le cas avec un cluster sur site, ou dans des environnements virtualisés tels que les environnements cloud. Coordonner les nœuds d'un cluster manuellement prend beaucoup de temps en plus d'être source d'erreurs. Vous pouvez utiliser un logiciel de gestion de cluster spécialisé pour provisionner et configurer ensemble des nœuds et ressources multiples, de manière répétable et déterministe.

Le logiciel Open Source ElastiCluster, développé par l'Université de Zurich, propose une approche cloud native de la gestion des clusters, avec prise en charge du provisionnement des nœuds à l'aide de Compute Engine, et la possibilité de configurer les nœuds à l'aide d'un ensemble de playbooks Ansible. ElastiCluster provisionne les nœuds et installe une pile logicielle de base incluant NFS pour la gestion des fichiers, la gestion des comptes utilisateur NIS et un planificateur de tâches pour l'exécution d'applications utilisateur. ElastiCluster est compatible avec différents planificateurs. Vous pouvez l'utiliser sans configuration préalable ou le personnaliser pour répondre aux besoins des équipes de petite et moyenne taille.

Si vous utilisez d'autres systèmes de gestion de configurations pour exploiter vos clusters HPC, par exemple Chef, Puppet ou Terraform, vous pouvez profiter de ces investissements lorsque vous migrez vers Google Cloud en faisant appel aux outils et plug-ins disponibles.

Google Cloud fournit des services natifs pour le provisionnement et le déploiement de systèmes logiciels multi-nœuds. Cloud Deployment Manager vous permet de provisionner un ensemble de ressources cloud, y compris Compute Engine, les groupes d'instances gérés Compute Engine et Cloud Storage. Le tutoriel HTCondor vous montre comment utiliser Cloud Deployment Manager et des groupes d'instances gérés pour provisionner 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é un planificateur de tâches (parfois également appelé gestionnaire de charge de travail ou gestionnaire de files d'attente). Les gestionnaires de cluster sont souvent livrés avec un planificateur de tâches intégré. Les planificateurs de tâches proposent un éventail de fonctionnalités vous assistant dans la gestion des travaux et des tâches, par exemple :

  • Gestion de la priorité des tâches suivant les utilisateurs et groupes, ce qui facilite la programmation des tâches à partir d'un ensemble de stratégies
  • Gestion des tâches ayant échoué par remise en file d'attente et reprogrammation
  • Prise en compte des dépendances entre 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 un éventail de gestionnaires de charge de travail populaires, aussi bien commerciaux qu'Open Source. Citons par exemple HTCondor de l'Université du Wisconsin, Slurm de SchedMD, Univa Grid Engine et LSF Symphony d'IBM. Chacun possède des atouts spécifiques.

HTCondor a été conçu selon une philosophie sans partage et est utilisé sur des ressources partagées pour programmer des tâches de manière opportuniste sur des ressources inutilisées. Il gère lui-même le transfert des données et ne nécessite par conséquent aucun système de fichiers partagé. En conséquence, HTCondor peut être utilisé avec des centaines de milliers de cœurs et également sur plusieurs zones et régions. HTCondor a été utilisé pour des charges de travail hybrides, dans lesquelles le travail est partagé ou divisé entre des systèmes sur site et des systèmes basés dans le cloud. Cependant, comme son nom l'indique, il est axé sur les tâches à haut débit plutôt que sur des tâches parallèles à faible couplage.

Slurm et Univa Grid Engine fournissent un environnement de cluster HPC plus traditionnel, prenant en charge les applications parallèles aussi bien à haut débit qu'à hautes performances. Ils nécessitent tous deux un système de fichiers partagé entre les nœuds, ce qui évite de déplacer les données. Tous deux proposent un environnement utilisateur pratique et familier pour le développement d'applications, car ce sont souvent les mêmes outils que ceux utilisés sur site. Ces planificateurs de tâches traditionnels sont suffisants pour les clusters de taille petite à moyenne. Toutefois, si la taille du cluster augmente, la charge sur le serveur de fichiers devient un goulot d'étranglement des performances. Les systèmes de fichiers distribués et parallèles (voir section suivante) peuvent aider à résoudre ce problème lorsqu'il est à grande échelle. Sinon, si l'accès à faible latence aux fichiers n'est pas une nécessité, vous pouvez recourir à Cloud Storage, qui fournit un accès parallèle aux objets, en passant soit par l'API, soit par gcsfuse, lorsque la compatibilité POSIX est exigée.

Enfin, Google Cloud inclut un service simple permettant de programmer une tâche Docker sur Compute Engine pour des charges de travail à haut débit : l'API Pipelines Cloud Life Sciences. Ce service est simple à utiliser, mais vous devez décomposer le travail en tâches et gérer les dépendances entre les tâches ainsi que leur cycle de vie. Le projet Open Source dsub fournit un outil de ligne de commande permettant de lancer des tâches par lots et est compatible avec l'API Pipelines Cloud Life Sciences.

Stockage

La plupart des applications HPC nécessitent une solution de stockage de fichiers compatible avec l'API POSIX. FileStore fournit un service de stockage de fichiers géré par Google pour les clusters plus petits. En revanche, pour les clusters plus importants, les E/S d'applications sont susceptibles de brider les performances. Les systèmes de fichiers parallèles et à scaling horizontal, tels que Elastifile (racheté par Google), Lustre ou Quobyte, facilitent le scaling en clusters de grande taille (ou même en clusters plus petits, dotés d'un grand nombre d'entrées/sorties).

Sinon, si l'accès à faible latence aux fichiers n'est pas une nécessité, vous pouvez recourir à Cloud Storage, qui fournit un accès parallèle aux objets, en passant soit par l'API, soit par gcsfuse, lorsque la compatibilité POSIX est exigée.

Opportunités d'utilisation des clusters de calcul dans le cloud

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

  • Temps nécessaire à la mise en place de la solution. Le lancement d'un cluster de qualité production dans le cloud ne prend que quelques minutes, qu'il s'agisse d'un petit cluster à 10 nœuds avec quelques centaines de cœurs ou de clusters à grande échelle comprenant au moins cent mille cœurs. Par opposition, la mise en place d'un nouveau cluster sur site peut prendre des mois avant d'atteindre un stade opérationnel. Même lorsqu'un cluster sur site est disponible, l'utilisation est généralement intensive et les files d'attente parfois très longues, jusqu'à plusieurs heures voire plusieurs jours, avant que l'exécution des tâches ne soit effectivement programmée. Au lieu de cela, vous pouvez créer vos propres clusters dans le cloud, les exploiter pour vos charges de travail, et les supprimer dès que votre analyse est terminée.

  • Coût total de possession réduit. Google Cloud réduit non seulement le temps nécessaire à la mise en place de la solution, mais peut également réduire le coût total par exécution en tirant parti des VM préemptives, des remises pour utilisation à long terme et du scaling dynamique. Vous pouvez ajouter des nœuds lorsqu'il y a des tâches en file d'attente et les supprimer dès qu'ils ne sont plus nécessaires.

  • Aide à la collaboration. Dans de nombreuses situations, l'analyse de calcul est développée grâce à la collaboration de différentes personnes réparties dans plusieurs organisations. Google Cloud fournit des outils de gestion de l'authentification et des accès au niveau des projets, ce qui permet de contrôler l'accès 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 est cohérent pour l'ensemble des utilisateurs sans avoir à copier des données, gérer des versions ou synchroniser des configurations de cluster.

  • Ressources adaptées aux tâches. Étant donné que le coût d'une tâche dépend uniquement du nombre total d'heures d'utilisation d'un cœur, et non du nombre d'instances, exécuter des clusters dans le cloud permet à chaque équipe ou groupe de disposer de son propre cluster dédié. Cette approche peut également réduire une autre charge majeure, à savoir l'élaboration de stratégies dans le contexte de groupes multiples. Vous pouvez ensuite personnaliser chaque cluster cloud dédié pour l'adapter à l'application cible. Les clusters sur site ont tendance à être constitués d'une ressource unique partagée entre plusieurs groupes et applications. Dans un tel environnement, les stratégies de partage entre groupes ont tendance à être complexes à mettre en place et à maintenir.

  • Intégration. Pour pouvoir exécuter des tâches de calcul volumineuses, les chercheurs effectuent d'abord un travail de préparation conséquent sur les ensembles de données. La migration vers le cloud permet à ces chercheurs d'utiliser des outils big data, qui y sont disponibles. Les résultats des systèmes de calcul doivent également être analysés. Des outils tels que BigQuery et Datalab peuvent offrir des avantages significatifs par rapport aux outils proposés par les systèmes sur site.

Un cluster sur site est généralement partagé entre les utilisateurs et groupes, et doit répondre à de nombreux besoins différents en matière d'applications.
Figure 2. Un cluster sur site est généralement partagé entre les utilisateurs et groupes, et doit répondre à de nombreux besoins différents en matière d'applications. En revanche, Google Cloud permet aux utilisateurs de personnaliser les propriétés du cluster en fonction des besoins en termes d'applications, afin de réduire les coûts et d'améliorer les performances.

Considérations relatives à l'architecture

Bien que les avantages décrits jusqu'à présent soient convaincants, certains défis techniques entravent souvent les projets de migration.

  • Transfert des données. Les ensembles de données traités par les nœuds de calcul d'un cluster doivent généralement être déplacés vers le cloud avant que les tâches soient exécutées. Gérer le déplacement des données peut être difficile, suivant le volume des données et la méthode choisie. Des outils tels que Avere peuvent fournir une aide précieuse grâce à une couche de mise en cache dans le cloud, qui déplace automatiquement les données en cas de besoin. Toutefois, pour de nombreuses applications, les ensembles de données doivent être déplacés 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 manière dont cet accès est fourni peut affecter les performances de l'application de manière significative. Vous pouvez exploiter des données partagées stockées dans Cloud Storage, sur des serveurs NFS tels que Filestore ou à l'aide de systèmes de fichiers parallèles, comme décrit dans la section Stockage.

  • Sécurité. Dans le cadre de données sensibles, vous devez vous assurer que les accès sont toujours soumis à autorisation et que les données sont correctement chiffrées aussi bien au repos qu'en transit. Même si Cloud Storage chiffre les données au repos et en transit, vous pouvez appliquer une couche de contrôle supplémentaire et gérer des clés, soit par vous-même, soit en passant par Cloud Key Management Service. Les clés doivent être récupérées ou installées sur les nœuds de calcul avant l'exécution des tâches.

  • Latence entre nœuds. Pour les applications HPC à couplage fort, les performances peuvent être sensibles à la latence entre les nœuds du cluster. Étant donné que Google Cloud fournit des nœuds pouvant comporter jusqu'à 64 cœurs, vous pouvez exécuter jusqu'à 64 tâches parallèles sans changer de nœud. Dans la plupart des cas, les tâches d'environ 1 000 cœurs ou moins présentent des performances raisonnablement bonnes sur du matériel réseau non spécialisé.

  • Gestion des licences logicielles. De nombreuses applications commerciales nécessitent un serveur de licences, parfois appelé serveur de clés. Certaines applications sont livrées avec un serveur de licences intégré ou recommandé, tandis que d'autres peuvent être compatibles avec les offres de serveurs de licences existantes. Certains planificateurs de tâches peuvent intégrer des fonctionnalités de gestion des licences et arrêter l'exécution des tâches jusqu'à ce qu'une licence soit disponible.

Le calcul technique fournit de nombreux outils et approches pour différentes situations. Avec autant d'options à votre disposition, vous aurez peut-être du mal à vous lancer. Indépendamment du choix du logiciel de gestion de cluster et du planificateur, il existe un certain nombre de bonnes pratiques que nous vous recommandons de suivre pour l'exécution sur Google Cloud.

  • Utilisez des VM préemptives autant que possible. Les VM préemptives sont identiques aux VM classiques de Compute Engine, mais leur prix peut être jusqu'à 80 % inférieur, dans la mesure où elles peuvent être récupérées avec un processus de notification minime. Pour les charges de travail à débit élevé, vos planificateurs de tâches détectent la perte du nœud, la traitent comme une défaillance et planifient à nouveau sur une autre ressource toutes les tâches en cours d'exécution sur ce nœud. Bien que tout le travail déjà effectué sur ces nœuds perdus soit lui-même perdu, la probabilité de perdre un nœud est suffisamment faible pour que le gain tarifaire en vaille la peine. Le taux de perte prévisionnel est de 5 % à 15 %. Les VM préemptives sont limitées à une utilisation maximale de 24 heures avant récupération.
  • Tirez parti du coût et de la bande passante de Cloud Storage au lieu de gérer votre propre système de fichiers parallèle. Cloud Storage offre une cohérence forte et des performances parallèles évolutives, le tout à un coût global faible. Si la latence du premier octet est élevée, à environ 100 ms, les applications qui peuvent exploiter Cloud Storage au lieu de faire appel à un serveur de fichiers parallèle sur Compute Engine se révèlent plus rentables. La bande passante disponible entre Cloud Storage et les nœuds de calcul est suffisante pour de nombreuses applications. Certains clients ont indiqué bénéficier d'une bande passante globale soutenue supérieure à 23 Go/s.
  • Créez un cluster dédié à une application ou à un groupe. Les clusters traditionnels sont partagés entre plusieurs utilisateurs, groupes et applications, ce qui peut entraîner de longues files d'attente pour les tâches et une utilisation inefficace des ressources par les applications. Sur Google Cloud, vous pouvez envisager de créer plusieurs clusters pour chaque groupe ou projet et d'utiliser des clusters optimisés pour les applications particulières qu'ils exécutent. Que vous utilisiez un seul cluster pendant deux heures ou deux clusters pendant une heure, le coût global est identique. En revanche, ce second cas de figure peut réduire les temps d'attente et améliorer les performances applicatives.

Bien que chaque mise en œuvre soit unique, les sections suivantes fournissent des recommandations générales pour trois cas de figure courants.

Chercheur indépendant souhaitant traiter ses données

Pour les chercheurs individuels, l'objectif est le plus souvent d'exécuter leur application avec leurs propres données et d'obtenir le résultat le plus rapidement possible. Ce sont généralement des experts sur leur application, mais ils ne veulent pas devenir des experts en administration ou en gestion de cluster.

Si vous exécutez des charges de travail à haut débit, vous pouvez envisager d'utiliser l'API Pipelines Cloud Life Sciences. L'API Pipelines nécessite d'intégrer votre application à un conteneur Docker et d'héberger vos fichiers d'entrée dans un bucket Cloud Storage. Une fois que c'est fait, vous pouvez utiliser l'outil de ligne de commande gcloud pour lancer l'application sur chacun des fichiers du bucket Cloud Storage. Vous pouvez enregistrer les résultats dans un autre bucket Cloud Storage.

Voici un exemple de commande qui exécute une tâche utilisant 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 [PIPELINE_ID] \
--logging gs://[YOUR_BUCKET/YOUR_DIRECTORY]/logs \
--inputs inputFile=gs://genomics-public-data/gatk-examples/example1/NA12878_chr22.bam \
--outputs outputFile=gs://[YOUR_BUCKET]/[YOUR_DIRECTORY]/output/NA12878_chr22.bam.bai

Où :

  • [PIPELINE_ID] représente l'ID de votre application dans l'API Pipelines.
  • [YOUR_BUCKET] représente le nom de votre bucket Cloud Storage.
  • [YOUR_DIRECTORY] 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'à ce que chacun des fichiers soit traité, dans une VM provisionnée et gérée par l'API Pipelines. L'opération globale est rentable, car Compute Engine facture par seconde d'utilisation.

Cluster de petite à moyenne taille dédié à un projet ou à une équipe

Dans un projet ou une équipe, les membres peuvent avoir accès à un cluster géré par une équipe centrale pour l'ensemble des utilisateurs de leur entreprise. Ils peuvent également avoir accès à des ressources à grande échelle hébergées dans un centre HPC hors site. Dans ces deux cas, les clusters sont gérés de manière professionnelle et l'accès se fait à l'aide d'outils standards. Par exemple, les utilisateurs peuvent utiliser ssh pour se connecter à un nœud principal, puis utiliser des scripts Grid Engine submit pour envoyer des tâches à exécuter.

Une approche pour de tels utilisateurs consiste à employer ElastiCluster pour définir un environnement de cluster semblable à leurs systèmes sur site. Ils peuvent personnaliser le cluster en sélectionnant le type de machine Compute Engine le mieux adapté à leur application et personnaliser les scripts de démarrage pour installer les dépendances logicielles de leur application. Les données d'entrée peuvent toujours être stockées dans Cloud Storage et vous pouvez installer gcsfuse sur les nœuds de calcul pour installer les données d'entrée.

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

% elasticluster start astrocluster1

Le cluster, dont le nom astrocluster1 est défini dans le fichier de configuration, est provisionné et configuré comme spécifié. Les définitions dans un fichier de configuration sont flexibles et permettent de mettre en place des types différents pour les nœuds principaux et les nœuds de calcul, des disques persistants Compute Engine pour l'espace de travail, des machines virtuelles préemptives pour réduire le coût des charges de travail à haut débit, ou encore des GPU pour un fonctionnement accéléré. Voici un exemple de configuration de base pour un cluster basé sur Slurm comportant 10 nœuds de calcul et 1 nœud principal, utilisant chacun des machines virtuelles à 32 cœurs basées sur CentOS :

[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
 

Une fois qu'il n'y a plus de tâche en cours d'exécution sur le système, vous pouvez arrêter le cluster :

% elasticluster stop astrocluster1

Pour des charges de travail plus importantes, vous pouvez :

  • essayer de personnaliser les types de machines du cluster pour réduire davantage les coûts ;
  • ajouter un serveur de stockage parallèle externe pour améliorer les performances à grande échelle ;
  • mettre en place des fonctionnalités d'autoscaling pour ajouter des nœuds supplémentaires ou bien en supprimer, en fonction de la profondeur de la file d'attente.

Ajouter une capacité d'utilisation intensive à des clusters existants grâce aux services HPC centraux

Les services HPC centraux ont une capacité de calcul considérable, mais comme ils sont utilisés par de nombreux groupes au sein de l'entreprise ou de l'organisation, ils ont tendance à être caractérisés par une utilisation soutenue et de longues files d'attente. Généralement, leur achat est réalisé sur la base d'une estimation donnée de la capacité requise en production et, lorsqu'ils doivent faire face à des charges de travail imprévues, les progrès peuvent s'en trouver considérablement ralentis.

Dans ces situations, vous pouvez passer en utilisation intensive dans l'environnement Google Cloud en ajoutant temporairement des nœuds de calcul au cluster. Le cluster devient alors un cluster hybride, le nœud principal et certains nœuds de calcul s'exécutant sur site tandis que d'autres nœuds de calcul s'exécutent sur Google Cloud. Une fois les files d'attente de tâches épuisées, les nœuds supplémentaires peuvent être libérés.

Basculer en utilisation intensive sur le cloud se révèle pratique pour deux raisons :

  • Cela préserve la cohérence de l'environnement utilisateur pour l'envoi et la gestion des tâches. Les utilisateurs ne savent pas ou ne se soucient pas de savoir si des nœuds supplémentaires sont ajoutés.
  • Cela permet aux responsables informatiques d'élaborer des règles définissant quand basculer en utilisation intensive sur le cloud, afin de maîtriser les coûts.

Le principal défi consiste à fournir un espace de noms, pour les fichiers et les données des tâches utilisateur, qui reste cohérent entre les nœuds sur site et les nœuds Google Cloud. Les nœuds Google Cloud n'ont pas forcément accès aux mêmes systèmes de fichiers internes que les nœuds sur site. Dans de tels cas, l'exécution des tâches faisant référence à ces fichiers échouera.

Si les nœuds Google Cloud sont configurés avec des autorisations internes d'accès aux fichiers, les tâches seront exécutées, mais risquent de ne pas fonctionner de la même manière. Cela peut conduire à des frais supplémentaires de bande passante et de trafic sortant. En outre, les tâches parallèles réparties entre des nœuds locaux et des nœuds dans le cloud peuvent également présenter des performances dégradées, du fait de la latence supplémentaire entre les différentes parties de l'application.

Pour les tâches à haut débit, l'utilisation de HTCondor pour basculer en utilisation intensive vers le cloud évite bon nombre de ces problèmes. HTCondor accepte le provisionnement dynamique à l'aide de GlideInWMS. Lorsque des tâches sont envoyées à la file d'attente, elles peuvent déclencher le provisionnement de nœuds et leur ajout au cluster. Une fois les nœuds ajoutés, le planificateur condor transfère les fichiers d'entrée vers le nœud désigné et utilise ces nœuds supplémentaires pour exécuter les tâches et vider la file d'attente.

Étapes suivantes

Découvrez-en davantage sur les cas d'utilisation des clusters de calcul avec Google Cloud :

Renseignez-vous sur les thèmes suivants :

Premiers pas avec votre cluster :

Exemples de projets sur GitHub :