Apache DolphinScheduler 3.x ने आर्किटेक्चरमध्ये आमूलाग्र बदल केले आहेत. जे संघ अजूनही 1.3 वर आहेत, त्यांना अपग्रेड करण्यापूर्वी त्यांच्या क्लस्टर लेआउटमध्ये बदल करावा लागेल आणि डेटाबेस स्कीमा पुन्हा लिहावा लागेल. जुना सिंगल-नोड मास्टर आता नाहीसा झाला असून, त्याऐवजी प्लग-इन-चालित (plug-in-driven), विकेंद्रित (decentralized) प्रणाली आली आहे जी जॉब्सचे शेड्युलिंग, स्टोरेज आणि लॉगिंग वेगळ्या पद्धतीने करते.
हा बदल का महत्त्वाचा आहे
व्हर्जन 1.3 मध्ये एक सेंट्रलाइज्ड मास्टर होता जो प्रत्येक शेड्युलिंग निर्णय हाताळत असे आणि त्यात केवळ बारा इन-बिल्ट टास्क प्रकार उपलब्ध होते. 3.x मध्ये त्याऐवजी मायक्रोकर्नेल (microkernel) वापरले आहे, जे टास्क प्रकार आणि स्टोरेज अडॅप्टर्स प्लगइन्स म्हणून लोड करते. तसेच, मास्टर्स आणि वर्कर्सना रजिस्ट्री सर्व्हिसद्वारे संवाद साधू दिल्याने 'सिंगल पॉइंट ऑफ फेल्युअर'ची समस्या दूर झाली आहे. यामुळे ऑपरेटर्सना स्केलेबिलिटी आणि लवचिकता (resilience) मिळते; तर डेव्हलपर्सना कोअर कोडमध्ये बदल करण्याऐवजी केवळ एक JAR फाईल टाकून शेड्युलरचा विस्तार करता येतो.
आर्किटेक्चरल सुधारणा (Architectural overhaul)
- मायक्रोकर्नेल प्लग-इन सिस्टम – टास्क डेफिनिशन्स, रिसोर्स हँडलर्स आणि कस्टम हेल्थ चेक आता स्वतंत्र मॉड्यूल्समध्ये असतात. नवीन टास्क प्रकार जोडण्यासाठी त्याचा प्लग-इन क्लासपाथवर (classpath) ठेवा आणि संबंधित नोड्स रीस्टार्ट करा.
- विकेंद्रित समन्वय (Decentralized coordination) – मास्टर्स आणि वर्कर्स रजिस्ट्रीद्वारे एकमेकांना शोधतात. रजिस्ट्रीसाठी ZooKeeper (जुना डिफॉल्ट), JDBC-आधारित रिलेशनल डेटाबेस किंवा Etcd क्लस्टर वापरता येतो. तुमच्या सध्याच्या स्टॅकशी जुळणारी तंत्रज्ञान प्रणाली निवडा.
- विस्तारित टास्क कॅटलॉग – इन-बिल्ट टास्कची संख्या १२ वरून ३० पेक्षा जास्त झाली आहे, ज्यामध्ये क्लाउड-नेटिव्ह वर्कलोड्स आणि मशीन-लर्निंग पाइपलाईन्सचा समावेश आहे.
- MasterServer विरुद्ध WorkerServer – MasterServer आता DAG पार्टिशनिंग, सबमिशन आणि हेल्थ मॉनिटरिंग हाताळते. WorkerServer हे केवळ एक्झिक्युशन इंजिन म्हणून काम करते आणि लॉग्स स्ट्रीम करते. या विभाजनामुळे जबाबदाऱ्या स्पष्ट होतात आणि तुम्हाला प्रत्येक लेयर स्वतंत्रपणे सेट करता येतो.
- Watcher द्वारे फॉल्ट टॉलरन्स – Watcher नोड फेल्युअरसाठी रजिस्ट्रीवर लक्ष ठेवते. जेव्हा एखादा मास्टर किंवा वर्कर बंद पडतो, तेव्हा रजिस्ट्री आपोआप 'फेलओव्हर' (failover) प्रक्रिया सुरू करते.
- gRPC लॉग ट्रान्सपोर्ट – रिमोट लॉग रिट्रिव्हल आता Netty-आधारित प्रोटोकॉलवरून gRPC वर हलवण्यात आले आहे, ज्यामुळे अधिक चांगली कामगिरी मिळते असे स्त्रोतानुसार सांगण्यात आले आहे.
डेटाबेस रिफॅक्टरिंग (Database refactoring) ज्याकडे दुर्लक्ष करता येणार नाही
स्कीमामधील बदल हे कोणत्याही अपग्रेडसाठी सर्वात मोठे अडथळे आहेत:
| 1.3 टेबल | 3.x टेबल | काय बदलले |
|---|---|---|
t_ds_process_definition |
t_ds_workflow_definition |
UI आणि API शब्दावलीशी सुसंगत राहण्यासाठी "process" या शब्दाचे नाव बदलून "workflow" करण्यात आले आहे. |
t_ds_process_instance |
t_ds_workflow_instance |
रनटाइम रेकॉर्ड्ससाठी देखील असाच अर्थात्मक बदल करण्यात आला आहे. |
केवळ नाव बदलण्यापलीकडे, 3.x मध्ये टास्क मेटाडेटा (जो पूर्वी JSON ब्लॉब्समध्ये असायचा) आता समर्पित रिलेशनल टेबल्समध्ये काढला आहे, ज्यामुळे डेटा मॅनेजमेंट अधिक सुटसुटीत होते.
मायग्रेशन चेकलिस्ट (Migration checklist)
- सर्व गोष्टींचा बॅकअप घ्या – पूर्ण 1.3 डेटाबेस डंप एक्सपोर्ट करा आणि
confडिरेक्टरी कॉपी करा. - जुन्या टेबल्सना नवीन नावाशी मॅप करा –
t_ds_process_definitionचे नावt_ds_workflow_definitionमध्ये आणिt_ds_process_instanceचे नावt_ds_workflow_instanceमध्ये बदलणारा स्क्रिप्ट चालवा. त्यानंतर फॉरेन-की (foreign-key) कन्स्ट्रेंट्स तपासा. - JSON टास्क फील्ड्स मायग्रेट करा – JSON-एन्कोडेड टास्क डेटा नवीन रिलेशनल टेबल्समध्ये कॉपी करा. शेड्युलर नवीन लेआउट वाचत आहे की नाही हे तपासण्यासाठी काही DAGs टेस्ट करा.
- रजिस्ट्री निवडा – जर तुम्ही आधीपासूनच ZooKeeper वापरत असाल तर तेच ठेवा; अन्यथा JDBC-आधारित रजिस्ट्री किंवा Etcd क्लस्टर सेट करा आणि सर्व नोड्सना नवीन पत्त्यावर पॉइंट करा.
- प्लगइन्स तैनात (Deploy) करा – तुम्ही 1.3 मध्ये वापरलेले कोणतेही कस्टम टास्क प्रकार 3.x-सुसंगत प्लगइन्स म्हणून पॅकेज करा आणि ते प्रत्येक MasterServer वर तैनात करा.
- प्रथम MasterServer तैनात करा – मायग्रेट केलेल्या डेटाबेसशी जोडलेला नवीन MasterServer इन्स्टन्स सुरू करा. तो अस्तित्वात असलेले वर्कफ्लो सूचीबद्ध करतो आणि हेल्थ डॅशबोर्डमध्ये कोणतीही त्रुटी दिसत नाही याची खात्री करा.
- WorkerServers जोडा – एक-एक करून WorkerServers सुरू करा. यशस्वी नोंदणीसाठी रजिस्ट्रीवर लक्ष ठेवा आणि लॉग्स gRPC द्वारे प्रवाहित होत आहेत याची खात्री करा.
- स्मोक टेस्ट्स (Smoke tests) चालवा – सर्वात सामान्य टास्क प्रकारांचा समावेश असलेले काही कमी जोखमीचे DAGs ट्रिगर करा. लॉग्स UI मध्ये दिसत आहेत आणि टास्क स्टेटस अपडेट्स योग्यरित्या अपडेट होत आहेत की नाही ते तपासा.
- फेलओव्हरसाठी मॉनिटर करा – MasterServer क्रॅश झाल्याचे सिम्युलेट करा आणि Watcher कडून स्टँडबाय (standby) सर्व्हर प्रमोट केला जातोय का ते पहा. चालू असलेले (in-flight) टास्क मॅन्युअल रीस्टार्टशिवाय सुरू राहतात याची खात्री करा.
आव्हाने (What could bite you)
नवीन प्लग-इन मॉडेल शक्तिशाली आहे, परंतु यामुळे कस्टम डेव्हलपमेंटसाठी आवश्यक मानके (bar) वाढली आहेत.
थोडक्यात सांगायचे तर: १.३ वरून ३.x वर जाणे ही केवळ एक साधी व्हर्जन अपडेट नाही; त्यासाठी समन्वित डेटाबेस रीनेम, JSON-to-relational मायग्रेशन आणि प्लग-इन-सक्षम, रजिस्ट्री-चालित मॉडेलभोवती तुमच्या क्लस्टरची पुनर्रचना करणे आवश्यक आहे. चेकलिस्टचे टप्प्याटप्प्याने पालन करा, लवकर चाचणी करा, आणि तुम्हाला असा शेड्युलर मिळेल जो स्केल आऊट होतो, आपोआप रिकव्हर होतो आणि आधुनिक क्लाउड सेवांप्रमाणेच एकाच प्रोटोकॉलवर काम करतो.