Dans le paysage en constante évolution du calcul à haut débit (HTC), gérer les ressources informatiques de manière efficace reste un défi permanent. Les pics de demande inattendus peuvent saturer les grilles locales, entraînant retards et inefficacités. Une stratégie efficace pour y remédier est le cloud bursting, qui permet aux organisations d’étendre temporairement leur capacité de calcul en intégrant des ressources cloud.
Cet article explore comment IBM Spectrum Symphony facilite le cloud bursting et partage notre expérience dans le développement d’un plugin pour Google Cloud Platform (GCP) exploitant les Managed Instance Groups (MIGs).
Cloud bursting
Le cloud bursting est une stratégie cloud où une application locale (on-premise) utilise temporairement le cloud public lorsque la demande en capacité de calcul augmente. Dans le contexte du calcul à haut débit (HTC), où les tâches sont souvent faiblement couplées, peu dépendantes de la localisation des données et peuvent être exécutées de manière indépendante, le cloud bursting offre une solution scalable pour gérer les charges de travail fluctuantes sans sur-provisionner les ressources locales.
IBM Spectrum Symphony
IBM Spectrum Symphony est un puissant outil de gestion de grille conçu pour les environnements de calcul à haut débit (HTC). Il distribue efficacement les charges de travail sur les ressources disponibles, optimisant la performance et le débit. Symphony est l’équivalent HTC d’IBM Spectrum LSF, qui est conçu pour les charges de travail HPC.
Symphony abstrait les ressources informatiques en « slots », représentant une combinaison de cœurs CPU et de mémoire. Par exemple, un slot pourrait correspondre à (1 cœur, 512 Mo). Le Service-Oriented Application Manager (SOAM) peut ensuite allouer ces slots à différentes applications selon la demande.
Le SOAM est l’un des nombreux démons constituant Symphony, parmi lesquels se trouve le Host Factory. Le Host Factory est un composant de Symphony qui facilite le cloud bursting en provisionnant et en déprovisionnant des instances cloud selon les besoins. Il agit comme un intermédiaire entre Symphony et les fournisseurs cloud, en gérant le cycle de vie des ressources cloud.
Host Factory
Présentation
Le Host Factory fonctionne en interrogeant le cluster Symphony afin d’évaluer l’utilisation des ressources et la demande de slots supplémentaires. Cela est réalisé par des requestors. Lorsqu’il y a un déficit de ressources, le Host Factory provisionne des ressources auprès des fournisseurs cloud pour répondre à la demande. Il libère également les ressources cloud inutiles lorsque la demande diminue. Le provisionnement et le déprovisionnement sont délégués à des plugins Host Factory spécifiques à chaque fournisseur cloud. La seule information dont le Host Factory dispose concerne les modèles de machines, car il les utilise pour mapper les slots fournis par le requestor vers des machines concrètes.
Le fonctionnement du Host Factory limite considérablement notre manière d’interagir avec lui. Premièrement, le mécanisme de sondage implique que la communication est unidirectionnelle et périodique, ce qui peut entraîner des retards ou des incohérences dans l’allocation des ressources. De plus, le Host Factory ne peut pas être immédiatement informé des changements initiés en dehors de son contrôle, comme des instances créées ou supprimées par d’autres systèmes. Nous aborderons comment ces deux limitations ont influencé nos choix de conception et certaines solutions pour les contourner.
Templates
Pour traduire les slots abstraits de Symphony en ressources cloud concrètes, le Host Factory utilise des modèles (templates). Ces modèles définissent les spécifications des instances cloud, notamment :
-
Types d’instances : configurations CPU, mémoire, stockage.
-
Modèles de tarification : instances à la demande, Spot, réservées, tarification des machines, etc.
-
Niveaux de priorité : déterminent quels modèles utiliser selon différentes conditions.
Les modèles sont généralement définis dans des fichiers JSON et permettent au Host Factory de sélectionner les instances cloud appropriées correspondant aux slots requis.
Stratégie pour le développement du plugin
Le développement de ce plugin de cloud bursting a présenté plusieurs stratégies potentielles. Les plugins Symphony traditionnels pour d’autres fournisseurs cloud utilisaient souvent des méthodes analogues à la création massive de machines virtuelles. Cependant, pour Google Cloud Platform (GCP), notre objectif était de créer une solution plus profondément intégrée et efficace, en tirant parti des services natifs GCP pour atteindre une scalabilité potentiellement de millions de cœurs.
Une approche initialement envisagée consistait à utiliser Google Kubernetes Engine (GKE). Cette solution aurait déployé Symphony, ainsi que les hôtes de calcul provisionnés dynamiquement, au sein d’un cluster GKE. Un avantage potentiel aurait été de bénéficier de l’autoscaling géré par Kubernetes. Cependant, cela présentait un compromis important : l’autoscaling Kubernetes repose généralement sur des métriques de consommation des ressources (comme l’utilisation CPU ou mémoire), tandis que le Host Factory de Symphony ajuste idéalement le scaling en fonction de la demande de tâches en attente. Ce décalage dans les déclencheurs de mise à l’échelle pouvait entraîner une allocation de ressources sous-optimale. Bien que l’intégration avec GKE reste une possibilité pour certains cas d’usage, cette différence fondamentale a conduit à explorer davantage d’alternatives parmi les services GCP.
Exploitation des Managed Instance Groups de Google Cloud Platform
Les Managed Instance Groups (MIGs) de GCP sont une abstraction puissante pour gérer des collections d’instances de machines virtuelles. Elles offrent des fonctionnalités telles que l’autoscaling, l’auto-healing et une gestion simplifiée des instances.
Avantages de l’utilisation des MIGs :
-
Auto-Healing : remplace automatiquement les instances défaillantes sans intervention manuelle.
-
Cohérence : garantit que toutes les instances sont uniformes, simplifiant la gestion de la configuration.
-
Provisionnement plus rapide des instances GPU.
Nous avons choisi les MIGs pour tirer parti de ces avantages, dans le but de créer une solution de cloud bursting plus robuste et scalable. De plus, l’introduction récente des MIGs flexibles ([voir notre article sur les Managed Instance Groups]) permet un provisionnement tenant compte du taux de préemption pour les Spot VMs, tout en réduisant considérablement la complexité de gestion de multiples MIGs pour différents types d’instances.
Ce qui n’a pas fonctionné
Alors que nous avons mis en place un proof of concept fonctionnant pour de petits tests consistant à étendre notre infrastructure à environ 100-150 machines dans nos workflows GitHub, nous avons rencontré d’importants défis, dont les principaux étaient doubles :
-
Gestion conflictuelle : Les MIGs peuvent créer ou supprimer des instances de manière indépendante pour maintenir la taille souhaitée du groupe, ce qui peut entrer en conflit avec les actions du Host Factory.
-
Discordances de ressources : Les instances créées par les MIGs en dehors du contrôle du Host Factory ne sont pas reconnues, entraînant un désalignement dans le suivi des ressources. Le Host Factory n’ayant pas demandé la création de ces ressources, il ne peut pas demander leur destruction.
Un scénario récurrent est le suivant : nous utilisons des Spot VMs pour nos machines de cloud bursting. Lorsque ces machines sont détruites, la fonctionnalité auto-healing du MIG se déclenche et tente de recréer l’instance. Le problème est que, bien que cette nouvelle instance soit « valide » et « utilisable », le Host Factory ne revendique pas sa propriété. Il n’est pas conscient qu’elle est là pour remplacer l’une des instances précédentes. La seule information que nous pouvons communiquer au Host Factory via son interface de sondage limitée est que l’ancienne instance a été détruite. Nous nous retrouvons alors avec une instance zombie. La seule action possible dans le cadre du contrôle du Host Factory est de demander sa suppression, ce qui est extrêmement inefficace.
Une approche alternative : contourner le Host Factory
Compte tenu des limitations, nous avons exploré une approche alternative consistant à contourner le Host Factory et à utiliser des requestors personnalisés.
Les requestors sont des composants qui surveillent la demande du cluster et demandent des ressources en conséquence. En personnalisant le requestor, nous pouvons obtenir un meilleur contrôle de la gestion des ressources. Nous pouvons créer un plugin requestor qui surveille notre cluster Symphony et, au lieu de transmettre ces informations au Host Factory pour qu’il demande individuellement les machines, nous pouvons utiliser ces données pour définir directement la taille cible des MIGs en fonction des besoins en ressources.
Nous pouvons toujours utiliser les informations de tarification, les priorités et d’autres critères pour déterminer quel MIG mettre à l’échelle. Dans le cas des MIGs flexibles, nous pouvons déléguer une grande partie de la complexité à GCP et tirer parti du provisionnement conscient des préemptions.
En définissant directement la taille cible sans passer par le Host Factory, nous pouvons exploiter pleinement les capacités des MIGs et créer une expérience de cloud bursting plus fluide et efficace. Après tout, la propriété des ressources cloud revient directement au MIG. Toutes les instances créées par le MIG se connecteront automatiquement à notre cluster Symphony principal grâce à nos scripts de démarrage.
