Apache DolphinScheduler 3.x bouleverse totalement son architecture. Les équipes utilisant encore la version 1.3 doivent repenser la configuration de leur cluster et réécrire le schéma de la base de données avant de pouvoir effectuer la mise à niveau. L'ancien master à nœud unique disparaît, remplacé par un système décentralisé piloté par des plug-ins qui planifie, stocke et journalise les tâches différemment.
Pourquoi ce saut est important
La version 1.3 s'appuyait sur un master centralisé qui gérait chaque décision de planification et ne proposait que douze types de tâches intégrés. La version 3.x remplace cela par un micro-noyau qui charge les types de tâches et les adaptateurs de stockage sous forme de plug-ins, et élimine le point de défaillance unique en permettant aux masters et aux workers de communiquer via un service de registre. Les opérateurs gagnent en évolutivité et en résilience ; les développeurs peuvent étendre l'ordonnanceur simplement en ajoutant un fichier JAR au lieu de modifier le code source.
La refonte architecturale
- Système de plug-ins à micro-noyau – Les définitions de tâches, les gestionnaires de ressources et les contrôles de santé personnalisés résident désormais dans des modules distincts. Ajoutez un nouveau type de tâche en plaçant son plug-in sur le classpath et en redémarrant les nœuds concernés.
- Coordination décentralisée – Les masters et les workers se découvrent via un registre. Le registre peut être ZooKeeper (l'option par défaut historique), une base de données relationnelle basée sur JDBC ou un cluster Etcd. Choisissez la technologie qui correspond à votre pile technologique actuelle.
- Catalogue de tâches étendu – Le nombre de tâches intégrées est passé de 12 à plus de 30, couvrant les charges de travail cloud-native et les pipelines d'apprentissage automatique (machine learning).
- MasterServer vs WorkerServer – Le MasterServer gère désormais le partitionnement des DAG, la soumission et la surveillance de l'état de santé. Le WorkerServer agit comme un pur moteur d'exécution qui assure également le streaming des logs. Cette séparation clarifie les responsabilités et vous permet de dimensionner chaque couche indépendamment.
- Tolérance aux pannes via Watcher – Le Watcher surveille le registre pour détecter les défaillances de nœuds. Lorsqu'un Master ou un Worker tombe, le registre déclenche un basculement (failover) automatique.
- Transport de logs via gRPC – La récupération des logs à distance est passée d'un protocole basé sur Netty à gRPC, ce qui, selon la source, offre de meilleures performances.
Un refactoring de la base de données que vous ne pouvez pas ignorer
La refonte du schéma est le principal obstacle concret à toute mise à niveau :
| Table 1.3 | Table 3.x | Ce qui a changé |
|---|---|---|
t_ds_process_definition |
t_ds_workflow_definition |
Le terme « process » a été renommé « workflow » pour correspondre au vocabulaire de l'interface utilisateur et de l'API. |
t_ds_process_instance |
t_ds_workflow_instance |
Même changement sémantique pour les enregistrements d'exécution. |
Au-delà du renommage, la version 3.x extrait les métadonnées des tâches, qui résidaient auparavant dans des blocs JSON, vers des tables relationnelles dédiées, rendant la gestion des données plus propre.
Liste de contrôle pour la migration
- Sauvegardez tout – Exportez l'intégralité du dump de la base de données 1.3 et copiez le répertoire
conf. - Mappez les anciennes tables vers les nouveaux noms – Exécutez un script qui renomme
t_ds_process_definitionent_ds_workflow_definitionett_ds_process_instanceent_ds_workflow_instance. Vérifiez ensuite les contraintes de clé étrangère. - Migrez les champs de tâches JSON – Copiez les données de tâches encodées en JSON dans les nouvelles tables relationnelles. Testez quelques DAG pour confirmer que l'ordonnanceur lit la nouvelle structure.
- Choisissez un registre – Conservez ZooKeeper si vous l'utilisez déjà ; sinon, configurez un registre basé sur JDBC ou un cluster Etcd et pointez tous les nœuds vers la nouvelle adresse.
- Déployez les plug-ins – Packagez tous les types de tâches personnalisés que vous utilisiez en 1.3 sous forme de plug-ins compatibles 3.x et déployez-les sur chaque MasterServer.
- Déployez d'abord le MasterServer – Démarrez une nouvelle instance de MasterServer pointant vers la base de données migrée. Vérifiez qu'elle liste les workflows existants et que le tableau de bord de santé n'affiche aucune erreur.
- Ajoutez les WorkerServers – Démarrez les WorkerServers un par un. Surveillez le registre pour confirmer l'enregistrement réussi et vérifiez que les logs circulent via gRPC.
- Effectuez des tests de fumée (smoke tests) – Déclenchez quelques DAG à faible risque couvrant les types de tâches les plus courants. Vérifiez que les logs apparaissent dans l'interface utilisateur et que les mises à jour du statut des tâches se propagent correctement.
- Surveillez le basculement – Simulez un crash du MasterServer et observez le Watcher promouvoir un serveur de secours (standby). Confirmez que les tâches en cours se poursuivent sans redémarrage manuel.
Ce qui pourrait vous poser problème
Le nouveau modèle de plug-ins est puissant, mais il élève le niveau d'exigence pour le développement personnalisé.
L'essentiel : Passer de la version 1.3 à la 3.x n'est pas une simple montée de version ; cela nécessite un renommage coordonné de la base de données, une migration du format JSON vers un modèle relationnel et une réarchitecture de votre cluster autour d'un modèle piloté par un registre et prenant en charge les plug-ins. Suivez la checklist étape par étape, testez rapidement, et vous obtiendrez un ordonnanceur capable de monter en charge, de se rétablir automatiquement et d'utiliser le même protocole que les services cloud modernes.