Apache DolphinScheduler 3.x משנה לחלוטין את הארכיטקטורה. צוותים שעדיין נמצאים בגרסה 1.3 חייבים לעצב מחדש את פריסת האשכול (cluster layout) ולכתוב מחדש את סכימת מסד הנתונים לפני שיוכלו לשדרג. ה-master הישן בעל הצומת הבודדת נעלם, ובמקומו מגיעה מערכת מבוזרת מבוססת תוספים (plug-in-driven) המתזמנת, מאחסנת ומתעדת (logs) משימות בצורה שונה.
למה המעבר הזה חשוב
גרסה 1.3 נאחזה ב-master מרכזי שניהל כל החלטת תזמון והציעה רק שנים-עשר סוגי משימות מובנים. גרסה 3.x מחליפה זאת ב-microkernel שטוען סוגי משימות ואדפטרים לאחסון כתוספים (plugins), ומבטלת את נקודת הכשל היחידה (single point of failure) על ידי מתן אפשרות ל-masters ול-workers לתקשר דרך שירות רישום (registry service). מפעילים (Operators) מרוויחים יכולת גדילה (scalability) ועמידות (resilience); מפתחים יכולים להרחיב את המתזמן פשוט על ידי הוספת קובץ JAR במקום לשנות את קוד הליבה.
השינוי הארכיטקטוני המקיף
- מערכת תוספים מבוססת Microkernel – הגדרות משימה, מטפלי משאבים (resource handlers) ובדיקות תקינות (health checks) מותאמות אישית חיים כעת במודולים נפרדים. ניתן להוסיף סוג משימה חדש על ידי הצבת התוסף שלו ב-classpath והפעלה מחדש של הצמתים הרלוונטיים.
- תיאום מבוזר – ה-masters וה-workers מגלים זה את זה באמצעות registry. ה-registry יכול להיות ZooKeeper (ברירת המחדל ההיסטורית), מסד נתונים יחסי מבוסס JDBC, או אשכול Etcd. בחרו את הטכנולוגיה שמתאימה ל-stack הקיים שלכם.
- קטלוג משימות מורחב – המשימות המובנות גדלו מ-12 ליותר מ-30, ומכסות עומסי עבודה cloud-native וצינורות (pipelines) של למידת מכונה.
- MasterServer לעומת WorkerServer – ה-MasterServer מטפל כעת בחלוקת DAG, הגשה וניטור תקינות. ה-WorkerServer משמש כמנוע ביצוע טהור שגם מעביר (streams) לוגים. פיצול זה מבהיר את תחומי האחריות ומאפשר לכם לקבוע את הגודל של כל שכבה באופן עצמאי.
- עמידות בתקלות באמצעות Watcher – ה-Watcher עוקב אחר ה-registry לאיתור כשלים בצמתים. כאשר Master או Worker נופל, ה-registry מפעיל failover אוטומטי.
- העברת לוגים באמצעות gRPC – שליפת לוגים מרחוק עברה מפרוטוקול מבוסס Netty ל-gRPC, אשר לפי המקור מספק ביצועים טובים יותר.
ארגון מחדש (refactoring) של מסד הנתונים שאי אפשר להתעלם ממנו
השינוי בסכימה הוא החסם המוחשי ביותר לכל שדרוג:
| טבלת 1.3 | טבלת 3.x | מה השתנה |
|---|---|---|
t_ds_process_definition |
t_ds_workflow_definition |
המונח "process" שונה ל-"workflow" כדי להתאים לאוצר המילים של ה-UI וה-API. |
t_ds_process_instance |
t_ds_workflow_instance |
אותו שינוי סמנטי עבור רשומות זמן ריצה (runtime). |
מעבר לשינוי השמות, גרסה 3.x מחלצת מטא-נתונים של משימות שבעבר היו שמורים בתוך JSON blobs לתוך טבלאות יחסיות ייעודיות, מה שהופך את ניהול הנתונים לנקי יותר.
צ'ק ליסט להגירה
- בצע גיבוי לכל המערכת – ייצא dump מלא של מסד הנתונים בגרסה 1.3 והעתק את ספריית ה-
conf. - מפה טבלאות ישנות לשמות חדשים – הרץ סקריפט שמשנה את
t_ds_process_definitionל-t_ds_workflow_definitionואתt_ds_process_instanceל-t_ds_workflow_instance. לאחר מכן, וודא את אילוצי המפתחות הזרים (foreign-key constraints). - הגר את שדות המשימה בפורמט JSON – העתק נתוני משימה מקודדים ב-JSON לתוך הטבלאות היחסיות החדשות. בדוק מספר קטן של DAGs כדי לוודא שהמתזמן קורא את המבנה החדש.
- בחר registry – השאר את ZooKeeper אם אתם כבר מריצים אותו; אחרת, הגדר registry מבוסס JDBC או אשכול Etcd וכוונו את כל הצמתים לכתובת החדשה.
- פתח תוספים (plug-ins) – ארז כל סוג משימה מותאם אישית שהשתמשת בו בגרסה 1.3 כתוסף תואם לגרסה 3.x ופרסם אותו בכל MasterServer.
- התחל בפריסת ה-MasterServer – התחל מופע (instance) חדש של MasterServer המצביע על מסד הנתונים שהוגר. וודא שהוא מציג את ה-workflows הקיימים ושהלוח (dashboard) של תקינות אינו מציג שגיאות.
- הוסף WorkerServers – הפעל WorkerServers אחד אחד. עקוב אחר ה-registry כדי לוודא רישום מוצלח וודא שהלוגים זורמים דרך gRPC.
- הרץ בדיקות עשן (smoke tests) – הפעל מספר DAGs בסיכון נמוך המכסים את סוגי המשימות הנפוצים ביותר. בדוק שהלוגים מופיעים ב-UI ושהעדכונים של סטטוס המשימה מופצים בצורה נכונה.
- נטר failover – סמל קריסה של MasterServer ועקוב אחר ה-Watcher שמקדם שרת standby. וודא שמשימות בתהליך (in-flight) ממשיכות ללא צורך בהפעלה מחדש ידנית.
מה עלול להכשיל אתכם
מודל התוספים החדש הוא עוצמתי, אך הוא מעלה את רף הפיתוח המותאם אישית.
בשורה התחתונה: המעבר מ-1.3 ל-3.x אינו רק שדרוג גרסה פשוט; הוא דורש שינוי שם מתואם של מסד הנתונים, מיגרציה מ-JSON למודל יחסי (relational), וארכיטקטורה מחדש של ה-cluster שלכם סביב מודל מבוסס רישום (registry-driven) ותומך תוספים (plug-in-enabled). עקבו אחר רשימת הבדיקה צעד אחר צעד, בצעו בדיקות מוקדמות, ותקבלו scheduler שמתרחב (scales out), מתאושש באופן אוטומטי, ומשתמש באותו פרוטוקול של שירותי ענן מודרניים.