Apache DolphinScheduler 3.x அதன் கட்டமைப்பை (architecture) முற்றிலும் மாற்றியமைத்துள்ளது. இன்னும் 1.3 பதிப்பைப் பயன்படுத்தும் குழுக்கள், மேம்படுத்துவதற்கு (upgrade) முன்னதாகத் தங்கள் கிளஸ்டர் அமைப்பை (cluster layout) மாற்றியமைக்க வேண்டும் மற்றும் தரவுத்தள ஸ்கீமாவை (database schema) மீண்டும் எழுத வேண்டும். பழைய ஒற்றை-முனைய மாஸ்டர் (single-node master) நீக்கப்பட்டு, அதற்குப் பதிலாக பிளக்-இன் மூலம் இயங்கும், பரவலாக்கப்பட்ட (decentralized) ஒரு அமைப்பு வந்துள்ளது. இது வேலைகளைத் திட்டமிடுதல் (scheduling), சேமித்தல் மற்றும் பதிவுகளைப் பதிவு செய்தல் (logging) ஆகியவற்றில் வேறுபட்ட முறையைப் பின்பற்றுகிறது.

இந்த மாற்றம் ஏன் முக்கியமானது

பதிப்பு 1.3, ஒவ்வொரு திட்டமிடல் முடிவையும் கையாளும் ஒரு மையப்படுத்தப்பட்ட மாஸ்டரைச் சார்ந்திருந்தது மற்றும் பன்னிரண்டு உள்ளமைக்கப்பட்ட பணி வகைகளை (task types) மட்டுமே வழங்கியது. 3.x பதிப்பு, பணி வகைகளையும் சேமிப்பு அடாப்டர்களையும் (storage adapters) பிளக்-இன்களாகப் பதிவேற்றும் ஒரு மைக்ரோகெர்னல் (microkernel) முறையை அறிமுகப்படுத்துகிறது. மேலும், மாஸ்டர்கள் மற்றும் வொர்க்கர்கள் (workers) ஒரு ரெஜிஸ்ட்ரி சேவையின் (registry service) மூலம் தொடர்புகொள்ள அனுமதிப்பதன் மூலம், 'சிங்கிள் பாயிண்ட் ஆஃப் ஃபெயிலியர்' (single point of failure) சிக்கலை இது நீக்குகிறது. இதன் மூலம் ஆபரேட்டர்கள் அளவிடுதல் திறன் (scalability) மற்றும் மீள்தன்மை (resilience) ஆகியவற்றைப் பெறுகிறார்கள்; டெவலப்பர்கள் கோர் குறியீட்டை (core code) மாற்றியமைப்பதற்குப் பதிலாக, ஒரு JAR கோப்பைச் சேர்ப்பதன் மூலம் எளிதாக ஸ்கெட்யூலரை விரிவாக்க முடியும்.

கட்டமைப்பு மறுசீரமைப்பு (Architectural overhaul)

  • மைக்ரோகெர்னல் பிளக்-இன் அமைப்பு – பணி வரையறைகள் (task definitions), வளக் கையாளுபவர்கள் (resource handlers) மற்றும் தனிப்பயன் ஆரோக்கிய சோதனைகள் (custom health checks) இப்போது தனித்தனி தொகுதிகளாக (modules) உள்ளன. அதன் பிளக்-இனை கிளாஸ்பேஸில் (classpath) வைத்து, பாதிக்கப்பட்ட முனைகளை (nodes) மறுதொடக்கம் செய்வதன் மூலம் புதிய பணி வகையைச் சேர்க்கலாம்.
  • பரவலாக்கப்பட்ட ஒருங்கிணைப்பு – மாஸ்டர்கள் மற்றும் வொர்க்கர்கள் ஒரு ரெஜிஸ்ட்ரி மூலம் ஒன்றையொன்று கண்டறிந்து கொள்கின்றன. இந்த ரெஜிஸ்ட்ரி ZooKeeper (பழைய இயல்புநிலை), ஒரு JDBC-அடிப்படையிலான உறவுநிலை தரவுத்தளம் (relational database) அல்லது Etcd கிளஸ்டராக இருக்கலாம். உங்கள் தற்போதைய தொழில்நுட்பத் தொகுப்பிற்கு (stack) ஏற்ற தொழில்நுட்பத்தைத் தேர்ந்தெடுக்கவும்.
  • விரிவுபடுத்தப்பட்ட பணி பட்டியல் – உள்ளமைக்கப்பட்ட பணிகள் 12-லிருந்து 30-க்கும் மேலாக அதிகரித்துள்ளன, இவை கிளவுட்-நேட்டிவ் பணிச்சுமைகள் (cloud-native workloads) மற்றும் மெஷின் லேர்னிங் பைப்லைன்களை (machine-learning pipelines) உள்ளடக்கியுள்ளன.
  • MasterServer vs WorkerServer – MasterServer இப்போது DAG பிரிப்பர்ட்டிஷன் (partitioning), சமர்ப்பித்தல் (submission) மற்றும் ஆரோக்கியக் கண்காணிப்பு (health monitoring) ஆகியவற்றைச் செய்கிறது. WorkerServer ஒரு தூய செயலாக்க இயந்திரமாக (execution engine) செயல்படுகிறது மற்றும் பதிவுகளை (logs) ஸ்ட்ரீம் செய்கிறது. இந்த பிரிவினை பொறுப்புகளைத் தெளிவுபடுத்துகிறது மற்றும் ஒவ்வொரு அடுக்கையும் (layer) தனித்தனியாக அளவிட அனுமதிக்கிறது.
  • Watcher மூலம் பிழைத் தாங்குதிறன் (Fault tolerance) – Watcher, முனைகளின் தோல்விகளைக் கண்டறிய ரெஜிஸ்ட்ரியைக் கண்காணிக்கிறது. ஒரு மாஸ்டர் அல்லது வொர்க்கர் செயலிழக்கும்போது, ரெஜிஸ்ட்ரி தானியங்கி ஃபெயிலோவர் (failover) முறையைத் தூண்டுகிறது.
  • gRPC லாக் போக்குவரத்து – தொலைதூர லாக் மீட்டெடுப்பு (Remote log retrieval) Netty-அடிப்படையிலான புரோட்டோகாலிலிருந்து gRPC-க்கு மாற்றப்பட்டுள்ளது, இது சிறந்த செயல்திறனை வழங்கும் என்று மூலத் தகவல் கூறுகிறது.

நீங்கள் தவிர்க்க முடியாத தரவுத்தள மறுசீரமைப்பு (Database refactoring)

ஸ்கீமா மறுசீரமைப்பு என்பது எந்தவொரு மேம்பாட்டிற்கும் (upgrade) மிக முக்கியமான தடையாக உள்ளது:

1.3 அட்டவணை 3.x அட்டவணை என்ன மாறியது
t_ds_process_definition t_ds_workflow_definition UI மற்றும் API சொற்களஞ்சியத்துடன் ஒத்துப்போக, “process” என்ற சொல் “workflow” என மாற்றியமைக்கப்பட்டது.
t_ds_process_instance t_ds_workflow_instance ரன்டைம் பதிவுகளுக்கும் (runtime records) இதே போன்ற பொருள் மாற்றம் செய்யப்பட்டுள்ளது.

மறுபெயரிடுதலைத் தாண்டி, 3.x பதிப்பு, முன்பு JSON பிளாப்களுக்குள் (JSON blobs) இருந்த பணி மெட்டாடேட்டாவை (task metadata) பிரத்யேக உறவுநிலை அட்டவணைகளுக்கு (relational tables) மாற்றுகிறது, இது தரவு நிர்வாகத்தை எளிதாக்குகிறது.

இடமாற்றப் பட்டியல் (Migration checklist)

  1. அனைத்தையும் பேக்அப் எடுக்கவும் – முழுமையான 1.3 தரவுத்தள டம்பை (database dump) ஏற்றுமதி செய்து conf கோப்பகத்தை (directory) நகலெடுக்கவும்.
  2. பழைய அட்டவணைகளை புதிய பெயர்களுக்கு மாற்றவும் – t_ds_process_definition-ஐ t_ds_workflow_definition ஆகவும், t_ds_process_instance-ஐ t_ds_workflow_instance ஆகவும் மாற்றும் ஸ்கிரிப்டை இயக்கவும். அதன் பிறகு ஃபாரீன்-கீ (foreign-key) கட்டுப்பாடுகளைச் சரிபார்க்கவும்.
  3. JSON பணி புலங்களை இடமாற்றம் செய்யவும் – JSON-குறியாக்கப்பட்ட (JSON-encoded) பணித் தரவை புதிய உறவுநிலை அட்டவணைகளுக்கு நகலெடுக்கவும். ஸ்கெட்யூலர் புதிய அமைப்பைப் படிக்கிறதா என்பதை உறுதிப்படுத்த சில DAG-களைச் சோதிக்கவும்.
  4. ஒரு ரெஜிஸ்ட்ரியைத் தேர்ந்தெடுக்கவும் – நீங்கள் ஏற்கனவே ZooKeeper பயன்படுத்துகிறீர்கள் என்றால் அதையே தொடரலாம்; இல்லையெனில், ஒரு JDBC-அடிப்படையிலான ரெஜிஸ்ட்ரி அல்லது Etcd கிளஸ்டரை அமைத்து, அனைத்து முனைகளையும் (nodes) புதிய முகவரிக்குத் திருப்பவும்.
  5. பிளக்-இன்களைப் பயன்படுத்தவும் – 1.3-இல் நீங்கள் பயன்படுத்திய எந்தவொரு தனிப்பயன் பணி வகைகளையும் 3.x-க்கு இணக்கமான பிளக்-இன்களாகத் தொகுத்து (package), ஒவ்வொரு MasterServer-க்கும் பயன்படுத்தவும்.
  6. முதலில் MasterServer-ஐத் தொடங்கவும் – இடமாற்றம் செய்யப்பட்ட தரவுத்தளத்தைக் குறிக்கும் புதிய MasterServer இன்ஸ்டன்ஸ் (instance)-ஐத் தொடங்கவும். அது ஏற்கனவே உள்ள பணிப்பாய்வுகளைப் (workflows) பட்டியலிடுகிறதா என்பதையும், ஹெல்த் டேஷ்போர்டு (health dashboard) பிழைகளைக் காட்டவில்லை என்பதையும் சரிபார்க்கவும்.
  7. WorkerServers-ஐச் சேர்க்கவும் – WorkerServers-ஐ ஒவ்வொன்றாகத் தொடங்கவும். ரெஜிஸ்ட்ரியில் வெற்றிகரமான பதிவை (registration) கவனிக்கவும் மற்றும் லாக்ஸ் gRPC வழியாகச் செல்கின்றனவா என்பதை உறுதிப்படுத்தவும்.
  8. ஸ்மோக் டெஸ்ட்களை (smoke tests) இயக்கவும் – மிகவும் பொதுவான பணி வகைகளை உள்ளடக்கிய சில குறைந்த அபாயமுள்ள DAG-களைத் தூண்டவும். UI-இல் லாக்ஸ் தோன்றுகிறதா என்பதையும், பணி நிலை மாற்றங்கள் (task status updates) சரியாகப் பரவுகின்றனவா என்பதையும் சரிபார்க்கவும்.
  9. ஃபெயிலோவரை (failover) கண்காணிக்கவும் – ஒரு MasterServer செயலிழப்பSimulate செய்து, Watcher ஒரு ஸ்டாண்ட்பை (standby) சர்வரைத் தூண்டுகிறதா என்று பார்க்கவும். இயங்கிக்கொண்டிருக்கும் பணிகள் (in-flight tasks) கைமுறையாக மறுதொடக்கம் செய்யாமல் தொடர்வதை உறுதிப்படுத்தவும்.

உங்களுக்குச் சிக்கலை ஏற்படுத்தக்கூடியவை

புதிய பிளக்-இன் மாதிரி சக்தி வாய்ந்தது, ஆனால் இது தனிப்பயன் மேம்பாட்டிற்கான (custom development) தேவைகளை அதிகப்படுத்துகிறது.

முக்கியமான விஷயம்: 1.3 இலிருந்து 3.x க்கு மாறுவது என்பது ஒரு சாதாரண பதிப்பு மாற்றம் மட்டுமல்ல; இதற்கு ஒருங்கிணைக்கப்பட்ட தரவுத்தள மறுபெயரிடல், JSON-லிருந்து உறவுநிலை தரவுத்தளத்திற்கு மாற்றுதல் மற்றும் பிளக்-இன் வசதியுடன் கூடிய, பதிவேடு சார்ந்த மாதிரியைச் சுற்றி உங்கள் கிளஸ்டரை மறுவடிவமைப்பு செய்தல் ஆகியவை தேவைப்படுகின்றன. சரிபார்ப்புப் பட்டியலை படிப்படியாகப் பின்பற்றி, முன்கூட்டியே சோதனை செய்யுங்கள்; இதன் மூலம் தானாகவே விரிவடையும், தானாகவே இயல்பு நிலைக்குத் திரும்பும் மற்றும் நவீன கிளவுட் சேவைகளைப் போன்றே செயல்படும் ஒரு ஸ்கெட்யூலரை நீங்கள் பெறுவீர்கள்.