Leader Election
- ●একাধিক নোডের মধ্যে একজনকে leader বানালে coordination সহজ হয় — সিদ্ধান্ত এক জায়গায় হয়, বিভ্রান্তি কমে।
- ●Bully ও Raft-style election নোডদের মধ্যে ভোট/অগ্রাধিকার দিয়ে একজন leader বেছে নেয়।
- ●Split-brain (দুই leader) ভয়ংকর; lease ও fencing token দিয়ে পুরোনো leader-কে ঠেকানো হয়।
সমস্যাটা কী?
ধরো তোমার একটা cluster আছে যেখানে ৫টা নোড একই ডেটা manage করছে। এখন কে ঠিক করবে কোন write কোন ক্রমে হবে? সব নোড যদি স্বাধীনভাবে সিদ্ধান্ত নেয়, তাহলে একজন বলবে "অর্ডার A আগে", আরেকজন বলবে "অর্ডার B আগে" — হযবরল।
সবচেয়ে সহজ সমাধান: একজনকে leader বানিয়ে দাও। সব গুরুত্বপূর্ণ সিদ্ধান্ত সে নেবে, বাকিরা (follower) তাকে অনুসরণ করবে। এতে coordination অনেক সহজ হয়।
কিন্তু সমস্যা — leader তো একটা মেশিন, সেও মরতে পারে। leader মরলে কে নতুন leader হবে? কীভাবে সবাই একমত হবে নতুন leader নিয়ে? আর সবচেয়ে বিপজ্জনক — পুরোনো leader যদি আসলে মরেনি, শুধু network-এ আলাদা হয়ে গিয়েছিল, আর ফিরে এসে আবার নিজেকে leader ভাবে? দুটো leader একসাথে কাজ করলে সর্বনাশ। এই পুরো সমস্যাটাই leader election।
মূল ধারণা
Leader election: একটি distributed protocol যার মাধ্যমে কতগুলো নোড নিজেদের মধ্যে থেকে ঠিক একজনকে leader হিসেবে বেছে নেয় এবং বাকিরা সেই সিদ্ধান্ত মেনে নেয়।
দুটো জিনিস leader election-কে নির্ভরযোগ্য করে:
- Uniqueness — কোনো এক মুহূর্তে কার্যকরভাবে একজনই leader থাকা উচিত।
- Liveness — leader মরলে যেন সিস্টেম আটকে না থেকে দ্রুত নতুন leader বেছে নিতে পারে।
এই দুটোর মধ্যে টানাপোড়েন আছে — খুব দ্রুত নতুন leader বানাতে গেলে পুরোনোটা আসলে বেঁচে আছে কি না নিশ্চিত না হয়েই বানিয়ে ফেলা যায়, যা split-brain ডেকে আনে।
কীভাবে কাজ করে
Bully algorithm
প্রতিটা নোডের একটা unique ID আছে। যখন কেউ টের পায় leader আর সাড়া দিচ্ছে না, সে নিজের চেয়ে বড় ID-র সব নোডকে election message পাঠায়। কেউ সাড়া না দিলে সে নিজেই leader হয়ে সবাইকে জানায়। বড় ID-র নোড সবসময় ছোটকে "bully" করে সরিয়ে দেয় — তাই নাম।
Raft-style election
Raft consensus-এ সময়কে term নামের ধাপে ভাগ করা হয়।
| ভূমিকা | কাজ |
|---|---|
| Follower | leader-এর heartbeat শোনে |
| Candidate | heartbeat না পেলে নিজেকে candidate ঘোষণা করে ভোট চায় |
| Leader | সংখ্যাগরিষ্ঠ (quorum) ভোট পেলে leader হয় |
heartbeat timeout হলে follower candidate হয়, নতুন term শুরু করে সবার কাছে ভোট চায়। যে majority ভোট পায় সে leader। majority লাগে বলে দুই অংশে partition হলে শুধু বড় অংশই leader বানাতে পারে — split-brain ঠেকে।
Split-brain ও সুরক্ষা
Split-brain তখন ঘটে যখন network partition-এর কারণে দুই অংশ আলাদা leader বানিয়ে ফেলে। দুই leader একই ডেটায় বিপরীত write করলে ডেটা corrupt হয়।
দুটো প্রধান প্রতিরক্ষা:
- Lease: leader-শিপ একটা সময়সীমার ভাড়া। leader-কে নিয়মিত lease নবায়ন করতে হয়। নবায়ন না করলে অন্য কেউ leader হতে পারে — পুরোনো leader নিজেই জানে তার lease শেষ, তাই সে কাজ থামায়।
- Fencing token: প্রতি নতুন leader একটা ক্রমবর্ধমান নম্বর পায় (১, ২, ৩...)। downstream storage শুধু এ যাবৎ দেখা সর্বোচ্চ token-এর request মানে; পুরোনো leader ছোট token নিয়ে ফিরলে তার request প্রত্যাখ্যাত হয়।
প্রকারভেদ
ভাবো একটা ক্রিকেট দলের ক্যাপ্টেন। মাঠে একজনই ক্যাপ্টেন থাকা দরকার — তিনিই field সাজানোর সিদ্ধান্ত নেন, নইলে এগারো জন এগারো রকম জায়গায় দাঁড়াবে। ক্যাপ্টেন চোট পেলে দল নতুন একজনকে ভোটে/সিনিয়রিটিতে ক্যাপ্টেন বানায়। কিন্তু কল্পনা করো পুরোনো ক্যাপ্টেন মাঠের বাইরে গিয়েও ওয়াকিটকিতে নির্দেশ দিচ্ছেন, আর নতুন ক্যাপ্টেনও দিচ্ছেন — খেলোয়াড়রা দিশেহারা (split-brain)। সমাধান: আম্পায়ার একটা armband (fencing token) দেন, খেলোয়াড়রা শুধু সর্বশেষ armband-ধারীর কথা শোনে।
কৌশল
বাস্তবে কেউ নিজে থেকে leader election কোড লেখে না — এটা ভুল হওয়ার সম্ভাবনা প্রচুর। বদলে একটা পরীক্ষিত coordination service ব্যবহার করা হয়:
- ZooKeeper: ephemeral sequential node দিয়ে leader election — সবচেয়ে ছোট sequence-ধারী leader, সে মরলে তার ephemeral node মুছে যায়, পরেরজন leader হয়।
- etcd / Consul: lease ও distributed lock API দেয়, যার ওপর leader election বানানো যায়।
- Raft library (hashicorp/raft): consensus + election একসাথে দেয়।
কখন ব্যবহার করবে / করবে না
ব্যবহার করবে যখন কোনো কাজ ঠিক একজনকেই করতে হবে — primary database write, একটি scheduled job যেন একবারই চলে, distributed lock manager।
ব্যবহার করবে না যখন কাজটা stateless ও সবাই সমানভাবে করতে পারে (যেমন একগুচ্ছ web server load balancer-এর পেছনে) — সেখানে leader অপ্রয়োজনীয় bottleneck।
শুধু "leader আর heartbeat পাঠাচ্ছে না" দেখে নতুন leader বানিয়ে দিও না — পুরোনো leader হয়তো শুধু GC pause বা network glitch-এ আটকে ছিল, মরেনি। fencing token ছাড়া পুরোনো leader ফিরে এসে stale write করে ডেটা নষ্ট করতে পারে। তাই lease timeout সবসময় downstream-এর fencing token-এর সাথে মিলিয়ে ব্যবহার করো, শুধু timeout-এর ওপর ভরসা করো না।
বাস্তব উদাহরণ
- Kafka: আগে controller election-এর জন্য ZooKeeper ব্যবহার করত, এখন KRaft (Raft) দিয়ে নিজেই করে।
- Kubernetes: controller-manager ও scheduler লিডার লক (etcd lease) দিয়ে নিশ্চিত করে একসময় একটাই active instance থাকে।
- MongoDB / Elasticsearch: primary/master election করে replica set-এ একজনই write নেয়।
- HDFS: ZooKeeper-based failover দিয়ে active ও standby NameNode-এর মধ্যে leader ঠিক করে, fencing দিয়ে পুরোনো NameNode আটকায়।
ইন্টারভিউতে leader election বললে অবশ্যই split-brain আর তার সমাধান উল্লেখ করো — কারণ এটাই আসল কঠিন অংশ। বলো — "আমি majority quorum দিয়ে election করব যাতে দুই partition একসাথে leader না বানাতে পারে, আর downstream-এ fencing token রাখব যাতে পুরোনো leader ফিরে এসেও ক্ষতি করতে না পারে।" এই দুই স্তরের সুরক্ষা বোঝানোই key।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. distributed system-এ একজন leader রাখার মূল সুবিধা কী?
2. Split-brain বলতে কী বোঝায়?
3. Fencing token কীভাবে পুরোনো leader-কে ক্ষতি করা থেকে আটকায়?