Apache DolphinScheduler 3.x તેના આર્કિટેક્ચરમાં મોટો ફેરફાર લાવે છે. જે ટીમો હજુ પણ 1.3 પર છે, તેમણે અપગ્રેડ કરતા પહેલા તેમના ક્લસ્ટર લેઆઉટને ફરીથી ગોઠવવું પડશે અને ડેટાબેઝ સ્કીમાને ફરીથી લખવું પડશે. જૂનો સિંગલ-નોડ માસ્ટર હવે અદૃશ્ય થઈ ગયો છે, અને તેની જગ્યાએ પ્લગ-ઇન-ડ્રિવન, વિકેન્દ્રિત (decentralized) સિસ્ટમ આવી છે જે જોબ્સને અલગ રીતે શેડ્યૂલ, સ્ટોર અને લોગ કરે છે.
આ ફેરફાર કેમ મહત્વનો છે
વર્ઝન 1.3 એક સેન્ટ્રલાઇઝ્ડ માસ્ટર પર આધારિત હતું જે દરેક શેડ્યૂલિંગ નિર્ણય સંભાળતું હતું અને માત્ર બાર (12) બિલ્ટ-ઇન ટાસ્ક પ્રકારો આપતું હતું. 3.x તેને માઇક્રોકર્નલ (microkernel) સાથે બદલે છે જે ટાસ્ક પ્રકારો અને સ્ટોરેજ એડેપ્ટર્સને પ્લગઇન તરીકે લોડ કરે છે, અને તે માસ્ટર્સ અને વર્કર્સને રજિસ્ટ્રી સર્વિસ દ્વારા વાત કરવા દેવાથી 'સિંગલ પોઈન્ટ ઓફ ફેઈલિયર' (single point of failure) ને દૂર કરે છે. ઓપરેટર્સને સ્કેલેબિલિટી અને રેઝિલિયન્સ (resilience) મળે છે; ડેવલપર્સ કોર કોડમાં ફેરફાર કરવાને બદલે ફક્ત એક JAR ફાઇલ ઉમેરીને શેડ્યૂલરને વિસ્તૃત કરી શકે છે.
આર્કિટેક્ચરલ ઓવરહોલ (Architectural overhaul)
- Microkernel plug-in system – ટાસ્ક ડેફિનેશન, રિસોર્સ હેન્ડલર્સ અને કસ્ટમ હેલ્થ ચેક્સ હવે અલગ મોડ્યુલ્સમાં રહે છે. તેના પ્લગઇનને
classpathપર મૂકીને અને અસરગ્રસ્ત નોડ્સને રીસ્ટાર્ટ કરીને નવો ટાસ્ક પ્રકાર ઉમેરો. - Decentralized coordination – માસ્ટર્સ અને વર્કર્સ રજિસ્ટ્રી દ્વારા એકબીજાને શોધી શકે છે. રજિસ્ટ્રી ZooKeeper (ઐતિહાસિક ડિફોલ્ટ), JDBC-બેક્ડ રિલેશનલ ડેટાબેઝ અથવા Etcd ક્લસ્ટર હોઈ શકે છે. તમારી હાલની ટેકનોલોજી સ્ટેક સાથે મેળ ખાતી ટેકનોલોજી પસંદ કરો.
- Expanded task catalog – બિલ્ટ-ઇન ટાસ્ક 12 થી વધીને 30 થી વધુ થયા છે, જે ક્લાઉડ-નેટિવ વર્કલોડ્સ અને મશીન-લર્નિંગ પાઇપલાઇન્સને આવરી લે છે.
- MasterServer vs WorkerServer – MasterServer હવે DAG પાર્ટિશનિંગ, સબમિશન અને હેલ્થ મોનિટરિંગ સંભાળે છે. WorkerServer એક શુદ્ધ એક્ઝિક્યુશન એન્જિન તરીકે કામ કરે છે જે લોગ્સ પણ સ્ટ્રીમ કરે છે. આ વિભાજન જવાબદારીઓને સ્પષ્ટ કરે છે અને તમને દરેક લેયરને સ્વતંત્ર રીતે સેટ કરવાની સુવિધા આપે છે.
- Fault tolerance via Watcher – Watcher નોડ ફેલ્યોર માટે રજિસ્ટ્રી પર નજર રાખે છે. જ્યારે કોઈ Master અથવા Worker ડ્રોપ થાય છે, ત્યારે રજિસ્ટ્રી આપમેળે ફેલઓવર (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-એન્કોડેડ ટાસ્ક ડેટાને નવા રિલેશનલ ટેબલ્સમાં કોપી કરો. શેડ્યૂલર નવા લેઆઉટને વાંચે છે તેની ખાતરી કરવા માટે થોડા DAGs ટેસ્ટ કરો.
- રજિસ્ટ્રી પસંદ કરો – જો તમે પહેલેથી જ ZooKeeper ચલાવતા હોવ તો તેને જ રાખો; અન્યથા JDBC-બેક્ડ રજિસ્ટ્રી અથવા Etcd ક્લસ્ટર સેટઅપ કરો અને તમામ નોડ્સને નવા એડ્રેસ પર પોઇન્ટ કરો.
- પ્લગઇન્સ ડિપ્લોય કરો – તમે 1.3 માં ઉપયોગમાં લીધેલા કોઈપણ કસ્ટમ ટાસ્ક પ્રકારોને 3.x-સુસંગત પ્લગઇન તરીકે પેકેજ કરો અને તેમને દરેક MasterServer પર ડિપ્લોય કરો.
- પહેલા MasterServer રોલ આઉટ કરો – માઇગ્રેટ કરેલા ડેટાબેઝ તરફ પોઇન્ટ કરતા નવા MasterServer ઇન્સ્ટન્સને શરૂ કરો. તે હાલના વર્કફ્લોની યાદી બતાવે છે અને હેલ્થ ડેશબોર્ડમાં કોઈ ભૂલ નથી તે ચકાસો.
- WorkerServers ઉમેરો – એક પછી એક WorkerServers શરૂ કરો. સફળ રજિસ્ટ્રેશન માટે રજિસ્ટ્રી પર નજર રાખો અને ખાતરી કરો કે લોગ્સ gRPC દ્વારા વહે છે.
- સ્મોક ટેસ્ટ ચલાવો – સૌથી સામાન્ય ટાસ્ક પ્રકારોને આવરી લેતા થોડા ઓછા જોખમી DAGs ટ્રિગર કરો. UI માં લોગ્સ દેખાય છે અને ટાસ્ક સ્ટેટસ અપડેટ્સ યોગ્ય રીતે ફેલાય છે કે નહીં તે તપાસો.
- ફેલઓવર માટે મોનિટર કરો – MasterServer ક્રેશનું સિમ્યુલેશન કરો અને Watcher કેવી રીતે સ્ટેન્ડબાયને પ્રોમોટ કરે છે તે જુઓ. ખાતરી કરો કે ચાલુ (in-flight) ટાસ્ક મેન્યુઅલ રીસ્ટાર્ટ વગર ચાલુ રહે છે.
તમને ક્યાં મુશ્કેલી પડી શકે છે
નવું પ્લગઇન મોડેલ શક્તિશાળી છે, પરંતુ તે કસ્ટમ ડેવલપમેન્ટ માટેના ધોરણો વધારી દે છે.
મુખ્ય વાત: 1.3 થી 3.x પર જવું એ માત્ર એક સાધારણ વર્ઝન અપડેટ નથી; તેમાં સંકલિત ડેટાબેઝ રીનેમ, JSON-to-relational માઈગ્રેશન અને પ્લગ-ઇન-સક્ષમ, રજિસ્ટ્રી-સંચાલિત મોડેલ પર આધારિત તમારા ક્લસ્ટરનું પુનઃ-આર્કિટેક્ચરિંગ જરૂરી છે. ચેકલિસ્ટનું સ્ટેપ-બાય-સ્ટેપ પાલન કરો, વહેલું પરીક્ષણ કરો, અને તમને એવો શેડ્યુલર મળશે જે સ્કેલ આઉટ કરી શકે છે, આપમેળે રિકવર થાય છે, અને આધુનિક ક્લાઉડ સેવાઓ જેવો જ પ્રોટોકોલ વાપરે છે.