Apache DolphinScheduler 3.x এর আর্কিটেকচার বা স্থাপত্য কাঠামো সম্পূর্ণ বদলে দিয়েছে। যারা এখনও 1.3 ভার্সন ব্যবহার করছেন, তাদের আপগ্রেড করার আগে ক্লাস্টার লেআউট পুনরায় সাজাতে হবে এবং ডাটাবেস স্কিমা নতুন করে লিখতে হবে। পুরনো সিঙ্গেল-নোড মাস্টার সিস্টেমটি এখন আর নেই; এর পরিবর্তে এসেছে একটি প্লাগ-ইন চালিত, বিকেন্দ্রীকৃত (decentralized) সিস্টেম যা জব শিডিউল করা, স্টোর করা এবং লগ করার ক্ষেত্রে ভিন্ন পদ্ধতি অনুসরণ করে।
কেন এই পরিবর্তনটি গুরুত্বপূর্ণ
ভার্সন 1.3 একটি সেন্ট্রালাইজড মাস্টারের ওপর নির্ভরশীল ছিল যা প্রতিটি শিডিউলিং সিদ্ধান্ত গ্রহণ করত এবং মাত্র বারোটি বিল্ট-ইন টাস্ক টাইপ প্রদান করত। 3.x ভার্সনে এর পরিবর্তে একটি মাইক্রোকার্নেল ব্যবহার করা হয়েছে যা প্লাগ-ইন হিসেবে টাস্ক টাইপ এবং স্টোরেজ অ্যাডাপ্টার লোড করে। এছাড়া, এটি একটি রেজিস্ট্রি সার্ভিসের মাধ্যমে মাস্টার এবং ওয়ার্কারদের মধ্যে যোগাযোগ স্থাপন করে 'সিঙ্গেল পয়েন্ট অফ ফেইলিউর' (single point of failure) সমস্যাটি দূর করেছে। এর ফলে অপারেটররা স্কেলেবিলিটি এবং রেজিলিয়েন্স (resilience) বা স্থিতিস্থাপকতা পাচ্ছেন; আর ডেভেলপাররা কোর কোড পরিবর্তন না করেই কেবল একটি JAR ফাইল যুক্ত করার মাধ্যমে শিডিউলারের কার্যকারিতা বাড়িয়ে নিতে পারছেন।
স্থাপত্যের আমূল পরিবর্তন
- Microkernel plug-in system – টাস্ক ডেফিনিশন, রিসোর্স হ্যান্ডলার এবং কাস্টম হেলথ চেক এখন আলাদা মডিউলে থাকে। এর প্লাগ-ইনটি ক্লাসপাথে (classpath) রেখে এবং সংশ্লিষ্ট নোডগুলো রিস্টার্ট করার মাধ্যমে আপনি সহজেই নতুন টাস্ক টাইপ যোগ করতে পারেন।
- Decentralized coordination – মাস্টার এবং ওয়ার্কাররা একটি রেজিস্ট্রি সার্ভিসের মাধ্যমে একে অপরকে শনাক্ত করতে পারে। এই রেজিস্ট্রি হিসেবে ZooKeeper (যা আগে ডিফল্ট ছিল), একটি JDBC-ভিত্তিক রিলেশনাল ডাটাবেস অথবা একটি Etcd ক্লাস্টার ব্যবহার করা যেতে পারে। আপনার বর্তমান টেক স্ট্যাকের সাথে সামঞ্জস্যপূর্ণ প্রযুক্তিটি বেছে নিন।
- Expanded task catalog – বিল্ট-ইন টাস্কের সংখ্যা ১২ থেকে বেড়ে ৩০-এর বেশি হয়েছে, যা ক্লাউড-নেটিভ ওয়ার্কলোড এবং মেশিন-লার্নিং পাইপলাইনকেও কভার করে।
- MasterServer vs WorkerServer – MasterServer এখন DAG পার্টিশনিং, সাবমিশন এবং হেলথ মনিটরিংয়ের কাজ সামলায়। অন্যদিকে, WorkerServer একটি পিওর এক্সিকিউশন ইঞ্জিন হিসেবে কাজ করে যা লগ স্ট্রিমও করে। এই বিভাজনের ফলে দায়িত্বগুলো সুনির্দিষ্ট হয় এবং আপনি প্রতিটি লেয়ারকে স্বাধীনভাবে স্কেল করতে পারেন।
- Fault tolerance via Watcher – Watcher রেজিস্ট্রি সার্ভিসের মাধ্যমে নোড ফেইলিওর বা ত্রুটি পর্যবেক্ষণ করে। যখন কোনো মাস্টার বা ওয়ার্কার অকেজো হয়ে পড়ে, রেজিস্ট্রি স্বয়ংক্রিয়ভাবে ফেইলওভার (failover) প্রক্রিয়া শুরু করে।
- gRPC log transport – রিমোট লগ সংগ্রহের পদ্ধতি Netty-ভিত্তিক প্রোটোকল থেকে gRPC-তে স্থানান্তরিত হয়েছে, যা অধিকতর উন্নত পারফরম্যান্স প্রদান করে।
ডাটাবেস রিফ্যাক্টরিং যা এড়িয়ে যাওয়া অসম্ভব
স্কিমা পরিবর্তনের বিষয়টি যেকোনো আপগ্রেডের ক্ষেত্রে সবচেয়ে বড় বাধা হতে পারে:
| 1.3 Table | 3.x Table | কী পরিবর্তন হয়েছে |
|---|---|---|
t_ds_process_definition |
t_ds_workflow_definition |
UI এবং API-এর শব্দভাণ্ডারের সাথে সামঞ্জস্য রাখতে “process” শব্দটিকে পরিবর্তন করে “workflow” করা হয়েছে। |
t_ds_process_instance |
t_ds_workflow_instance |
রানটাইম রেকর্ডের ক্ষেত্রেও একই ধরনের পরিবর্তন করা হয়েছে। |
নাম পরিবর্তনের পাশাপাশি, 3.x ভার্সনে টাস্ক মেটাডেটা (যা আগে JSON ব্লবের ভেতরে থাকত) এখন ডেডিকেটেড রিলেশনাল টেবিলে রাখা হয়েছে, যা ডাটা ম্যানেজমেন্টকে আরও সহজ ও পরিচ্ছন্ন করেছে।
মাইগ্রেশন চেকলিস্ট
- সবকিছু ব্যাকআপ নিন – 1.3 ডাটাবেসের সম্পূর্ণ ডাম্প এক্সপোর্ট করুন এবং
confডিরেক্টরি কপি করে রাখুন। - পুরানো টেবিলগুলোকে নতুন নামে ম্যাপ করুন – একটি স্ক্রিপ্ট চালান যা
t_ds_process_definition-কেt_ds_workflow_definition-এ এবংt_ds_process_instance-কেt_ds_workflow_instance-এ পরিবর্তন করবে। এরপর ফরেন-কী (foreign-key) কনস্ট্রেইন্টগুলো যাচাই করে নিন। - JSON টাস্ক ফিল্ড মাইগ্রেট করুন – JSON-এনকোড করা টাস্ক ডেটা নতুন রিলেশনাল টেবিলগুলোতে কপি করুন। শিডিউলার নতুন লেআউটটি সঠিকভাবে পড়তে পারছে কি না তা নিশ্চিত করতে কয়েকটি DAG পরীক্ষা করে দেখুন।
- একটি রেজিস্ট্রি বেছে নিন – আপনি যদি ইতিমধ্যে ZooKeeper ব্যবহার করে থাকেন তবে সেটিই রাখুন; অন্যথায় একটি JDBC-ভিত্তিক রেজিস্ট্রি বা Etcd ক্লাস্টার সেটআপ করুন এবং সমস্ত নোডকে নতুন অ্যাড্রেসটি নির্দেশ করুন।
- প্লাগ-ইন ডেপ্লয় করুন – 1.3 ভার্সনে ব্যবহৃত কাস্টম টাস্ক টাইপগুলোকে 3.x-এর উপযোগী প্লাগ-ইন হিসেবে প্যাকেজ করুন এবং প্রতিটি MasterServer-এ ডেপ্লয় করুন।
- প্রথমে MasterServer চালু করুন – মাইগ্রেট করা ডাটাবেসটি ব্যবহার করে একটি নতুন MasterServer ইনস্ট্যান্স চালু করুন। এটি বিদ্যমান ওয়ার্কফ্লোগুলোর তালিকা দেখাচ্ছে কি না এবং হেলথ ড্যাশবোর্ডে কোনো ত্রুটি দেখাচ্ছে কি না তা যাচাই করুন।
- WorkerServer যোগ করুন – একটি একটি করে WorkerServer চালু করুন। রেজিস্ট্রি সার্ভিসে সফলভাবে রেজিস্ট্রেশন হয়েছে কি না তা দেখুন এবং gRPC-এর মাধ্যমে লগ প্রবাহিত হচ্ছে কি না তা নিশ্চিত করুন।
- স্মোক টেস্ট (smoke tests) চালান – সাধারণ টাস্ক টাইপগুলো কভার করে এমন কিছু কম ঝুঁকির DAG ট্রিগার করুন। UI-তে লগ দেখা যাচ্ছে কি না এবং টাস্ক স্ট্যাটাস আপডেটগুলো সঠিকভাবে কাজ করছে কি না তা পরীক্ষা করুন।
- ফেইলওভার পর্যবেক্ষণ করুন – একটি MasterServer ক্র্যাশ করার পরিস্থিতি তৈরি করুন এবং দেখুন Watcher কীভাবে একটি স্ট্যান্ডবাই সার্ভারকে সক্রিয় করে। নিশ্চিত করুন যে চলমান (in-flight) টাস্কগুলো ম্যানুয়াল রিস্টার্ট ছাড়াই চলতে থাকে।
সম্ভাব্য চ্যালেঞ্জসমূহ
নতুন প্লাগ-ইন মডেলটি অত্যন্ত শক্তিশালী, তবে এটি কাস্টম ডেভেলপমেন্টের ক্ষেত্রে মানদণ্ড বা জটিলতা বাড়িয়ে দিয়েছে।
সারকথা: ১.৩ থেকে ৩.x-এ পরিবর্তন করা কেবল একটি সাধারণ ভার্সন আপডেট নয়; এর জন্য একটি সমন্বিত database rename, JSON-to-relational migration এবং একটি plug-in-enabled, registry-driven মডেলের ভিত্তিতে আপনার ক্লাস্টারের re-architecture প্রয়োজন। চেকলিস্টটি ধাপে ধাপে অনুসরণ করুন, দ্রুত পরীক্ষা করুন, এবং আপনি এমন একটি scheduler পাবেন যা scales out করতে পারে, স্বয়ংক্রিয়ভাবে recover করতে পারে এবং আধুনিক cloud services-এর মতো একই protocol ব্যবহার করে।