দুই সাইটের Kubernetes ক্লাস্টারের কি তিনটি etcd ভোটার দরকার?
দুই VPN সাইট জুড়ে তিনটি কন্ট্রোল-প্লেন নোড বড় সাইটটি অন্ধকার হয়ে গেলে এখনও কোরাম হারায়। প্রকৃত etcd ভোটার গণনা করুন এবং কোন ক্ষতি আপনি সহ্য করবেন তা বেছে নিন।
তিনটি কন্ট্রোল-প্লেন VM একটি খারাপ রাত থেকে বেঁচে যাওয়ার তিনটি সুযোগের মতো মনে হয়। কিন্তু তা নয়, এবং এই দুই বিশ্বাসের মধ্যকার দূরত্বই একটি পরিচ্ছন্ন তিন-নোড ডিজাইনকে এমন ক্লাস্টারে পরিণত করে যা একটি ভবন বিদ্যুৎ হারালে লেখা গ্রহণ করা বন্ধ করে দেয়। সাইটগুলোর মধ্যে একটি VPN লিঙ্ক মেশিনগুলোকে একে অপরের কাছে পৌঁছনীয় করে এবং সমস্যাটি সমাধান না করে লুকিয়ে রাখে। ভোট গণনা করা হয় প্রতি etcd সদস্যের ভিত্তিতে, এবং সেই সদস্যদের দুজন এখনও একটি সুইচ, একটি UPS এবং একটি আপলিংকের পেছনে বসে থাকতে পারে।
তিনটি কন্ট্রোল-প্লেন নোড, একটি ব্যর্থতার ডোমেইন
আপনি kubectl get nodes চালান, তিনটি কন্ট্রোল-প্লেন এন্ট্রি দেখেন এবং ক্লাস্টারটিকে উচ্চ-প্রাপ্যতা হিসেবে নথিভুক্ত করেন। এই সংখ্যাটি নির্ধারণযোগ্য সক্ষমতা বর্ণনা করে, বেঁচে থাকার ক্ষমতা নয়। বাহ্যিক etcd ছাড়া রাখা kubeadm-এ প্রতিটি কন্ট্রোল-প্লেন নোডও একটি সদস্য হোস্ট করে, তাই তিনটি নোড সত্যিই আপনাকে তিনটি ভোটার দেয়। সেই ভোটাররা স্বাধীনভাবে ব্যর্থ হয় কি না, তা একটি আলাদা প্রশ্ন যার উত্তর নোড তালিকা দিতে পারে না।
একটি হাইপারভাইজারে দুটি VM, একটি বিদ্যুৎ সরবরাহে দুটি র্যাক, একটি ISP থেকে দুটি আপলিংক: প্রতিটি জোড়া দুটি হোস্টনাম পরা একটি একক ডোমেইন। প্লেসমেন্টটি লিখে রাখুন এবং প্রতিটি ভোটার কী শেয়ার করে তা চিহ্নিত করুন — হাইপারভাইজার, PDU, টপ-অফ-র্যাক সুইচ, স্টোরেজ অ্যারে, NAT ডিভাইস, VPN কনসেনট্রেটর। তারপর কাগজে প্রতিটি শেয়ার্ড বস্তু সরিয়ে ফেলুন এবং অবশিষ্ট ভোট আবার গণনা করুন। যে ক্লাস্টার একটি ব্যর্থ হোস্টের কাছে দুটি ভোটার হারায়, সেটি শুরু থেকেই এক-ভোটার ক্লাস্টার ছিল; কেউ তাকে প্রশ্নটি জিজ্ঞাসা করেনি।
দুই সাইটের বিভাজন কী সহ্য করতে পারে আর কী পারে না
দুই সাইট জুড়ে তিনটি ভোটার দুই ও এক হিসেবে বসানো হলে, অন্য সাইটটি উধাও হলে বড় দিকটি কোরাম ধরে রাখে এবং এক-ভোটারের দিকটি কখনও ধরে না। এই অসমতা গণিত, টিউনিং নয়। ঠিক দুইটি স্বাধীন সাইটে ছড়ানো যেকোনো সংখ্যাগরিষ্ঠতা-ভিত্তিক etcd ক্লাস্টার "যেকোনো একটি সাইট হারিয়ে কমিট চালিয়ে যান" পরীক্ষায় ব্যর্থ হয়, কারণ একই সময়ে উভয় দিককেই অর্ধেকের বেশি ভোট ধরে রাখতে হতো।
নিচের সারণিটি আপনি আসলে কোন ব্যর্থতাগুলো কিনেছেন তা দেখার দ্রুততম উপায়। প্রতিটি সারি এভাবে পড়ুন: আজ রাতে যদি এই পুরো সারিটি উধাও হয়ে যায়, তবে বেঁচে থাকা সদস্যরা কি এখনও একটি লেখা কমিট করতে পারবে?
| What disappears | Voters left | Writes still commit |
|---|---|---|
| Site B, holding voter 3 | 2 of 3 | Yes |
| Site A, holding voters 1 and 2 | 1 of 3 | No |
| One hypervisor carrying any two voters | 1 of 3 | No |
| The inter-site VPN only | 2 of 3 on one side | Only on the majority side |
কেন টানেল কখনও একটি ভোট যোগ করে না
VPN একটি পরিবহন, সদস্য নয়। এটি একটি দূরবর্তী ভোটারকে পৌঁছনীয় করতে পারে এবং একটি বিভাজনকে ধীর টাইমআউটের মতো দেখতে কিছুতে পরিণত করতে পারে, এবং কোরামে এটাই তার পুরো অবদান। এটি যা যোগ করে তা হলো খরচ, কারণ প্রতিটি কমিটকে লিঙ্কটি অতিক্রম করতে হয় এবং etcd raft লগ স্পর্শ করা লেখায় সেই যাতায়াতের খরচ দেয়। যে পথ দুলতে থাকে, সে প্রতিলিপিকে পুনরায় চেষ্টা ও নির্বাচনে পরিণত করে।
বিভাজন হলো সেই জায়গা যেখানে মানুষ জাদু আশা করে, তাই সেগুলো নিয়ে সুনির্দিষ্ট থাকুন। যদি লিঙ্কটি পড়ে যায় যখন পুরনো নেতা এক-ভোটারের দিকে বসে থাকে, সেই দিকটি কমিট করতে পারে না এবং নির্বাচনী সময়সীমা শেষ হলে নেতা পদত্যাগ করে, আর দুই-ভোটারের দিকটি একটি প্রতিস্থাপক নির্বাচন করে। etcd-এর ব্যর্থতা-মোড গাইড আচরণটি স্পষ্টভাবে বর্ণনা করে: সংখ্যাগরিষ্ঠ দিকে অব্যাহত সেবা, বিচ্ছিন্ন দিকে কোনো দ্বিতীয় লেখনযোগ্য ক্লাস্টার নেই।
আপনি কোন বিভ্রাট কিনছেন তা ঠিক করুন
দুই যোগ এক একটি বৈধ ডিজাইন যখন সাইট A প্রাথমিক এবং আপনি মেনে নেন যে এটি হারানো মানে কেউ ব্যবস্থা নেওয়া পর্যন্ত কন্ট্রোল-প্লেন লেখা হারানো। এটিকে ত্রুটিতে পরিণত করে সেই সিদ্ধান্তটি অস্পষ্ট রেখে দেওয়া। এটি রানবুকে লিখুন: আপনার কন্ট্রোল প্লেন কোন সাইট থেকে বেঁচে থাকে, এবং অন্য সাইটটি 03:00-এ অন্ধকার হলে একজন অপারেটর কী করেন।
যদি প্রয়োজনীয়তা বরং "যেকোনো সাইট ব্যর্থ হতে পারে" হয়, তবে প্লেসমেন্টকে প্রতিটি সাইটে সংখ্যাগরিষ্ঠতা ধরে রাখতে হবে, এবং দুই সাইটে তিনটি ভোটার তা করতে পারে না। আপনি হয় সত্যিকারের স্বাধীন তৃতীয় ডোমেইন যোগ করেন — অন্য প্রদানকারীতে একটি ছোট অঞ্চল কাজ করে যদি সেখানে পথটি স্থিতিশীল থাকে — নয়তো আলাদা etcd সহ দুটি ক্লাস্টারে বিভক্ত হন এবং সেই বিভক্তির পরিচালন ব্যয় মেনে নেন। কোনো সাক্ষী শর্টকাট এটি এড়ায় না: etcd-এর হালকা আরবিটার সদস্য নেই, তাই তৃতীয় ভোটার হলো নিজস্ব ডিস্ক, মেমরি ও নেটওয়ার্ক চাহিদাসহ একটি পূর্ণ সদস্য। ডায়াগ্রামে "সাক্ষী" লেখা একটি বাক্স আঁকা একটি সাক্ষী তৈরি করে না।
কোরাম সেবার সমান নয়
etcd কোরাম API সার্ভারকে লেখা গ্রহণ করতে সক্ষম রাখে, এবং এটুকুই রাখে। লোড ব্যালেন্সার স্বাস্থ্য পরীক্ষা, ইনগ্রেস, টানেল জুড়ে CNI পৌঁছনীয়তা, ভলিউম সংযুক্তি অঞ্চল এবং অ্যাপ্লিকেশন প্রতিলিপি — প্রত্যেকের নিজস্ব উত্তর দরকার। একটি ক্লাস্টার পরিষ্কার সংখ্যাগরিষ্ঠতা ধরে রেখেও ব্যবহারকারীদের জন্য উপযোগী কিছু পরিবেশন করতে পারে না।
তারপর আপনি যে সদস্যপদ আছে বলে মনে করেন তা নিশ্চিত করুন, কারণ ডায়াগ্রামগুলো সরে যায়:
kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table
সদস্য তালিকাটি প্লেসমেন্ট অঙ্কনের সাথে তুলনা করুন। যদি দুটি সদস্য একই হোস্ট বা একই র্যাকে সমাধান হয়, তবে ভুলটি ক্লাস্টারে নয়, অঙ্কনে, এবং ভুল টপোলজির চারপাশে আকার পরিবর্তন শুধু একই বিভ্রাটের আরও ব্যয়বহুল সংস্করণ কিনে।
যেকোনো তিন-ভোটার ডিজাইনে সায় দেওয়ার আগে চারটি প্রশ্নের উত্তর দিন: কতজন ভোটার একসাথে বিদ্যুৎ হারায়, কার সাইট হারালেও সংখ্যাগরিষ্ঠতা থাকে, টানেল পড়ে গেলে নেতা কোথায় বসে, এবং বেঁচে থাকা সাইটটি এখনও কী করতে পারে। এদের যেকোনোটিতে "নিশ্চিত নই" মানে ক্লাস্টারটি এখনও উচ্চ-প্রাপ্য নয়। এটি তিনটি মেশিন যা ভাগ্যবান ছিল।