Apache DolphinScheduler 3.x معماری خود را به کلی دگرگون کرده است. تیمهایی که هنوز از نسخه 1.3 استفاده میکنند، باید پیش از ارتقا، چیدمان کلاستر خود را بازسازی کرده و طرحواره (schema) پایگاه داده را بازنویسی کنند. مدل قدیمی single-node master حذف شده و جای خود را به یک سیستم غیرمتمرکز مبتنی بر پلاگین داده است که وظایف (jobs) را به شکلی متفاوت زمانبندی، ذخیره و لاگ میکند.
چرا این تغییر مهم است
نسخه 1.3 به یک master متمرکز وابسته بود که تمام تصمیمات زمانبندی را مدیریت میکرد و تنها دوازده نوع تسک داخلی داشت. نسخه 3.x این مدل را با یک میکروکرنل جایگزین کرده است که انواع تسکها و آداپتورهای ذخیرهسازی را به عنوان پلاگین بارگذاری میکند؛ همچنین با اجازه دادن به masterها و workerها برای برقراری ارتباط از طریق یک سرویس registry، نقطه شکست واحد (single point of failure) را از بین میبرد. اپراتورها از مقیاسپذیری و تابآوری بیشتری بهرهمند میشوند و توسعهدهندگان میتوانند به جای دستکاری در کدهای اصلی، تنها با قرار دادن یک فایل JAR، زمانبند (scheduler) را گسترش دهند.
بازنگری معماری
- سیستم پلاگین میکروکرنل – تعاریف تسک، مدیریتکنندههای منابع و بررسیهای سلامت سفارشی اکنون در ماژولهای مجزا قرار دارند. با قرار دادن پلاگین مربوطه در classpath و راهاندازی مجدد گرههای (nodes) تحت تأثیر، میتوانید یک نوع تسک جدید اضافه کنید.
- هماهنگی غیرمتمرکز – masterها و workerها از طریق یک registry یکدیگر را شناسایی میکنند. این registry میتواند ZooKeeper (پیشفرض قدیمی)، یک پایگاه داده رابطهای مبتنی بر JDBC یا یک کلاستر Etcd باشد. تکنولوژیای را انتخاب کنید که با پشته (stack) فعلی شما همخوانی دارد.
- کاتالوگ گستردهتر تسکها – تسکهای داخلی از ۱۲ مورد به بیش از ۳۰ مورد افزایش یافتهاند که طیف وسیعی از بارهای کاری cloud-native و خط لولههای یادگیری ماشین (machine-learning pipelines) را پوشش میدهند.
- MasterServer در مقابل WorkerServer – اکنون MasterServer وظایف تقسیمبندی DAG، ارسال و نظارت بر سلامت را بر عهده دارد. WorkerServer به عنوان یک موتور اجرای خالص عمل میکند که وظیفه استریم کردن لاگها را نیز بر عهده دارد. این تفکیک باعث شفافیت در مسئولیتها شده و به شما اجازه میدهد هر لایه را به طور مستقل مقیاسبندی کنید.
- تحمل خطا از طریق Watcher – ابزار Watcher وضعیت registry را برای شناسایی خرابی گرهها زیر نظر میگیرد. هنگامی که یک Master یا Worker از دسترس خارج شود، registry یک failover خودکار را فعال میکند.
- انتقال لاگ با gRPC – بازیابی لاگهای از راه دور از پروتکل مبتنی بر Netty به gRPC منتقل شده است که طبق منابع، عملکرد بهتری ارائه میدهد.
بازسازی پایگاه داده که نمیتوان از آن چشمپوشی کرد
بازنگری در schema، ملموسترین مانع برای هرگونه ارتقا است:
| جدول 1.3 | جدول 3.x | چه چیزی تغییر کرد |
|---|---|---|
t_ds_process_definition |
t_ds_workflow_definition |
اصطلاح “process” برای مطابقت با واژگان UI و API به “workflow” تغییر یافت. |
t_ds_process_instance |
t_ds_workflow_instance |
همین تغییر معنایی برای سوابق زمان اجرا (runtime records) اعمال شده است. |
علاوه بر تغییر نام، نسخه 3.x متادیتای تسکها را که قبلاً درون blobهای JSON ذخیره میشد، به جداول رابطهای اختصاصی منتقل کرده است که باعث مدیریت تمیزتر دادهها میشود.
چکلیست مهاجرت
- از همه چیز نسخه پشتیبان تهیه کنید – یک 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 کدگذاری شدهاند را به جداول رابطهای جدید منتقل کنید. تعدادی از DAGها را تست کنید تا مطمئن شوید scheduler ساختار جدید را به درستی میخواند.
- یک registry انتخاب کنید – اگر در حال حاضر از ZooKeeper استفاده میکنید، آن را حفظ کنید؛ در غیر این صورت، یک registry مبتنی بر JDBC یا یک کلاستر Etcd را راهاندازی کرده و تمام گرهها را به آدرس جدید هدایت کنید.
- پلاگینها را مستقر کنید – هر نوع تسک سفارشی که در نسخه 1.3 استفاده میکردید را به صورت پلاگینهای سازگار با 3.x بستهبندی کرده و در هر MasterServer مستقر کنید.
- ابتدا MasterServer را مستقر کنید – یک نمونه جدید از MasterServer را که به پایگاه داده مهاجرتیافته متصل است، راهاندازی کنید. بررسی کنید که آیا workflowهای موجود را لیست میکند و آیا داشبورد سلامت (health dashboard) خطایی نشان نمیدهد یا خیر.
- WorkerServerها را اضافه کنید – WorkerServerها را یکی پس از دیگری بالا بیاورید. وضعیت registry را برای ثبت موفقیتآمیز بررسی کنید و مطمئن شوید که لاگها از طریق gRPC جریان دارند.
- تستهای اولیه (smoke tests) را اجرا کنید – چند DAG کمخطر را که رایجترین انواع تسکها را پوشش میدهند، اجرا کنید. بررسی کنید که لاگها در UI ظاهر شوند و وضعیت تسکها به درستی بهروزرسانی شوند.
- وضعیت failover را مانیتور کنید – خرابی یک MasterServer را شبیهسازی کنید و مشاهده کنید که آیا Watcher یک گره standby را جایگزین میکند یا خیر. تأیید کنید که تسکهای در حال اجرا بدون نیاز به راهاندازی مجدد دستی، ادامه مییابند.
مواردی که ممکن است چالشبرانگیز باشند
مدل جدید پلاگین بسیار قدرتمند است، اما سطح دشواری توسعه سفارشی را نیز افزایش میدهد.
خلاصه کلام: انتقال از نسخه ۱.۳ به ۳.x صرفاً یک ارتقای ساده نسخه نیست؛ این کار مستلزم تغییر نام هماهنگشده پایگاه داده، مهاجرت از JSON به مدل رابطهای (relational) و بازطراحی معماری کلاستر شما بر پایه مدلی مبتنی بر رجیستری و مجهز به پلاگین است. چکلیست را گامبهگام دنبال کنید، زودتر تست کنید و به زمانبندی (scheduler) دست خواهید یافت که قابلیت مقیاسپذیری افقی دارد، بهطور خودکار بازیابی میشود و از همان پروتکل سرویسهای ابری مدرن استفاده میکند.