> For the complete documentation index, see [llms.txt](https://cleyrop.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cleyrop.gitbook.io/docs/administration/gerer-les-clusters.md). # Gérer les clusters Les clusters sont les environnements d’exécution utilisés pour les traitements de données sur la plateforme. Ils assurent la bonne exécution des Dataflows et des collectes de données. *** ## Clusters par défaut Chaque environnement Cleyrop dispose de deux clusters actifs par défaut : * un cluster Spark — dédié aux traitements de données distribués (collectes, transformations, Low Code, SQL, etc.), * un cluster Python — dédié aux scripts, automatisations, et traitements unitaires. Ces deux clusters garantissent que les exécutions sont toujours possibles sans temps d’allumage et servent de fallback en cas d’indisponibilité d’un cluster personnalisé. {% hint style="info" %} Les collectes de données s’exécutent toujours sur le cluster Spark par défaut. {% endhint %} ## Capacités de calcul et limites d’environnement Les capacités de calcul disponibles sur votre environnement Cleyrop sont finies et mutualisées. Elles correspondent à une configuration de votre environnement, c’est-à-dire à un nombre fixe de machines et de ressources CPU/RAM globales. Ces ressources sont **partagées** entre : * les **sessions Jupyter** ouvertes dans le **CodeLab**, * les **clusters Spark et Python** utilisés pour exécuter les Dataflows et collectes. {% hint style="warning" %} Chaque session de cluster est **réellement provisionnée en ressources**. {% endhint %} Ainsi : * si plusieurs clusters ont été créés et consomment toutes les ressources disponibles, il ne sera plus possible de créer de nouvelles sessions Jupyter * si trop se sessions Jupyter sont ouvertes, les nouvelles sessions de clusters pourront échouer à la création (erreur de provisionnement). {% hint style="success" %} En cas de **saturation récurrente**, rapprochez-vous de votre Customer Success Manager pour ajuster la **capacité de votre environnement** (changement de taille ou ajout de compute nodes). {% endhint %} ## Créer et configurer un cluster personnalisé Les Platform Managers peuvent créer de nouveaux clusters pour répondre à des besoins spécifiques (gros volumes, tâches parallélisées, environnements isolés, etc.).
Chaque cluster peut être **configuré** selon plusieurs paramètres : | Paramètre | Description | | -------------- | ------------------------------------------------------------------------------------------------------------ | | Nom | Visible par tous les utilisateurs. Choisissez un nom clair et non confidentiel (ex. spark-prod, python-ml…). | | Type | Spark ou Python. | | Ressources | Quantité de CPU / RAM allouée au driver et aux exécuteurs. | | Sessions | Nombre de sessions parallèles actives (permet la parallélisation des Dataflows). | | Version Python | Pour les clusters Python : choix entre 3.11, 3.12 ou 3.13. | | Librairies | Liste des packages préinstallés dans le cluster (pandas, polars, numpy, pyspark, etc.). | L’augmentation du nombre de sessions permet d’exécuter plusieurs Dataflows en parallèle, dans la limite des ressources CPU/RAM disponibles. {% hint style="warning" %} Si la RAM ou le nombre d’exécuteurs est insuffisant, des erreurs de type **OOM (Out Of Memory)** peuvent survenir. {% endhint %} #### Comprendre la logique d’exécution Spark Un cluster Spark repose sur une architecture distribuée : * Driver : coordonne les tâches et collecte les résultats. * Executors : effectuent les calculs en parallèle sur les partitions de données. * Sessions : représentent des connexions isolées au cluster qui peuvent exécuter des Dataflows simultanément. #### **Consulter la fiche Cluster** La fiche de chaque cluster permet de visualiser la **liste des Dataflows** associés, consulter l'**historique des exécutions** de dataflow, collectes ou autres opérations associées (ex. suppression de dataset), connaître ses **librairies** et paramètres de configurations.
## Utiliser des librairies personnalisées (images) Pour utiliser des librairies Python spécifiques dans vos clusters, il est nécessaire de **créer au préalable une image de runtime** incluant ces librairies. Une image correspond à un environnement Python ou PySpark préconfiguré (version de Python + librairies).\ Une fois créée, **la même image peut être réutilisée dans plusieurs clusters**, ce qui permet de partager une configuration identique entre différents projets ou dataflows. **Principe général** 1. Vous créez une **image** en choisissant une base (Python ou PySpark). 2. Vous ajoutez les **librairies nécessaires** à vos traitements. 3. L’image est construite et mise à disposition dans la plateforme. 4. Vous sélectionnez cette image lors de la **création ou modification d’un cluster**.
### Créer une image avec des librairies La création d’une image consiste à partir d’une image de base Cleyrop (Python ou PySpark), qui inclut déjà un socle de librairies standards. Vous pouvez ensuite ajouter des librairies supplémentaires dans celles disponibles sur PyPI : * Choisissez une image de base : Python (3.11 / 3.12 / 3.13) ou PySpark. * Ajoutez les librairies à inclure: * Nom (obligatoire) * Version (optionnelle) * si vide : dernière version disponible sur PyPI * opérateurs supportés : ==, >, < (format type requirements.txt) * Cliquez sur Créer.\ Avant la construction, la plateforme vérifie automatiquement : l’existence de la librairie, sa compatibilité avec le runtime choisi, l’absence de conflits connus entre dépendances. En cas d’erreur, un message explicite est affiché.
Après sa création vous pouvez consulter le **statut** et les **logs** de l'image pour vérifier sa disponibilité à l'utilisation dans un cluster. {% hint style="warning" %} Si au moins une **librairie** ne peut pas être installée, le build échoue entièrement. {% endhint %} ### Consulter une image et visualiser les logs Depuis la fiche d’une image, vous pouvez visualiser la liste des librairies installées, leurs versions, l’état du dernier build et l’historique des modifications. Cela permet de comprendre précisément quel environnement sera utilisé par les clusters qui s’appuient sur cette image. Les logs de build sont accessibles afin de diagnostiquer rapidement une erreur d’installation ou de compatibilité. Tant que le build n’est pas réussi, l’image n’est pas utilisable. Le bouton **Rebuilder**, disponible depuis la liste des images ou la fiche détail, permet de relancer manuellement la construction de l'image, utile par exemple pour récupérer les dernières versions disponibles des librairies sans version fixée. {% hint style="warning" %} Après un rebuild, il est nécessaire de redémarrer les clusters utilisant cette image pour qu'ils prennent en compte la nouvelle version. {% endhint %} {% hint style="info" %} * En cas d’édition, un fallback utilise la dernière version d’image qui a un build réussi. * Un warning apparaît si la dernière configuration éditée ne correspond pas à l’image actuellement disponible (car le dernier build a échoué). {% endhint %}
### Utiliser une image dans un cluster Une fois le build réussi, l’image devient disponible lors de la création ou de l’édition d’un cluster.
Tous les dataflows et sessions exécutés sur ce cluster bénéficient automatiquement des librairies incluses dans l’image, sans configuration supplémentaire. ### Gérer l’évolution des images Les images peuvent être modifiées ou supprimées. Toute modification (ajout, mise à jour ou suppression de librairie) déclenche un build unique de l’image qui est tracé dans l'historique. Les changements s’appliquent aux nouveaux usages de l’image ; les clusters déjà en cours d’exécution ne sont pas interrompus automatiquement. En cas de problème lors d’un build, la plateforme conserve la dernière version valide de l’image afin d’éviter une rupture de service. ## Gérer l’arrêt et le redémarrage d’un cluster Les Plateforme Managers peuvent arrêter et relancer les clusters non-défaut afin de gérer les ressources de calcul de manière plus flexible. #### Arrêter un cluster Seuls les clusters personnalisés peuvent être arrêtés. Vous pouvez réaliser depuis la liste des clusters ou depuis la fiche du cluster en cliquant sur le bouton Arrêter :stop: Arrêter un cluster entraîne automatiquement : * l’**arrêt de toutes les sessions** associées à ce cluster après les dernières exécutions en cours, * la **libération des ressources** de calcul qu’il utilisait Cette opération n’impacte pas les Dataflows déjà exécutés, mais toute tentative d’exécution nécessitera un cluster actif. {% hint style="warning" %} Les futures exécutions des **Dataflow liés** à ce cluster resteront tant qu'il ne sera pas relancé ou exécuté sur un cluster actif {% endhint %} #### Relancer un cluster interrompu Relancer un cluster permet de remettre à disposition les ressources pour l’exécution des Dataflows liés. Lors du redémarrage : * le cluster recrée automatiquement le même nombre de sessions que celui défini dans sa configuration d’origine, * il redevient disponible pour exécuter des dataflows, * si un Dataflow était **en attente** il sera exécuté ## Surveiller les exécutions ### **Visualiser les clusters actifs** Depuis l’onglet Clusters du panneau d’administration, les Platform Managers peuvent : * Type (Python / Spark) * Nombre de sessions allouées * Statut (actif / inactif) * File d'attente ### Consulter les exécutions en temps réél Dans l'onglet Exécutions de la page Cluster, il est possible de visualiser l'ensemble des exécutions en temps réél . Cela permet de voir si un traitement est bloqué ou en attente et agir en conséquence. ### Consulter les exécutions d'un cluster Chaque cluster affiche la liste des Dataflows, collectes et opérations associées (ex. suppression de dataset, exécution planifiée…). Pour chaque exécution : * le statut (succès, en cours, échec), * la durée, * le type de tâche, * et le Dataflow concerné sont affichés.
### Suivre le monitoring global Depuis l’onglet Monitoring, il est possible d’observer : * l’utilisation CPU et RAM global, * et l’évolution de la consommation en temps réel.
## Ajuster les ressources pour résoudre certains incidents En cas de ralentissement ou file d’attente, suivez ces étapes : 1. Vérifier les exécutions en cours → Onglet *Clusters > Exécutions* : identifiez les tâches longues ou bloquées. Vous pouvez contacter le responsable du Dataflow pour investiguer ces lenteurs ou lui demander d'arrêter. En cas d'urgence ou d'indisponibilité, le responsable du projet peut modifier le owner Dataflow afin de l'arrêter. 2. Analyser l’utilisation CPU/RAM → Onglet *Monitoring* : un pic de consommation peut indiquer un manque de ressources. 3. Ajuster les ressources du cluster → Augmentez la RAM, le nombre d’exécuteurs ou les sessions parallèles si nécessaire. 4. Vérifier le statut des sessions → Une session inactive ou bloquée peut nécessiter un redéploiement. {% hint style="warning" %} Les erreurs OOM (Out Of Memory) sont souvent dues à un traitement non distribué ou à un dataset trop volumineux manipulé côté driver. {% endhint %} *** ## Bonnes pratiques * Nommer clairement les clusters pour faciliter leur usage (spark-prod, python-etl, spark-ml…). * Créer des clusters dédiés pour les traitements lourds ou sensibles. * Limiter le nombre de sessions actives à la capacité réelle du cluster. * Surveiller régulièrement le monitoring pour anticiper les saturations.