آیا د دوو سایټونو Kubernetes کلسټر ته درې etcd رایې ورکوونکي ته اړتیا ده؟
په دوو VPN سایټونو کې درې کنټرول-پلین نوډونه لاهم کورم له لاسه ورکوي کله چې لوی سایټ بند شي. ریښتیني etcd رایې ورکوونکي وشمېرئ او هغه زیان وټاکئ چې ژوندی پاتې کیږئ.
د کنټرول-پلین درې VMونه د یوې بدې شپې ژوندي پاتې کېدو لپاره درې چانسونه ښکاري۔ خو داسې نه دي، او د دې دوو باورونو ترمنځ فاصله هغه څه ده چې یو منظم درې-نوډ ډیزاین په داسې کلسټر وروګرځوي چې کله یو ساختمان بریښنا له لاسه ورکړي، لیکل منل بندوي۔ د سایټونو ترمنځ VPN لینک ماشینونه یو بل ته د رسېدو وړ ګرځوي او ستونزه د حل کولو پرځای پټوي۔ رایې د هر etcd غړي له مخې شمېرل کیږي، او د هغو غړو دوه کولای شي لا هم د یو سویچ، یو UPS او یوې کرښې شاته ناست وي۔
د کنټرول درې نوډونه، یو د ناکامۍ ډومین
تاسو kubectl get nodes چلوئ، د کنټرول-پلین درې ننوتنې ګورئ او کلسټر د لوړ لاسرسي په توګه ثبتوئ۔ هغه شمېره د پلان وړ ظرفیت بیانوي، نه ژوندی پاتې کېدل۔ په kubeadm کې چې پرته له بهرني etcd ساتل کیږي، هر کنټرول-پلین نوډ یو غړی هم کوربه کوي، نو درې نوډونه واقعاً درې رایې ورکوونکي درکوي۔ آیا هغه رایې ورکوونکي په خپلواک ډول ناکام کیږي، دا بېله پوښتنه ده چې د نوډ لیست یې ځواب نشي ورکولای۔
په یو هایپروایزر دوه 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 لومړنی وي او تاسو منئ چې د هغې له لاسه ورکول تر هغه چې څوک اقدام وکړي د کنټرول-پلین لیکنو له لاسه ورکول دي۔ هغه څه چې دا نقص ګرځوي، د هغې پریکړې پټه پریښودل دي۔ دا په runbook کې ولیکئ: ستاسو کنټرول پلین له کوم سایټ څخه ژوندی پاتې کیږي، او کله چې بل سایټ 03:00 بجې بند شي، عملیات کوونکی څه کوي۔
که اړتیا پرځای دا وي چې "هر سایټ کولای شي ناکام شي"، نو ځای پرځای کول باید په هر سایټ کې اکثریت ولري، او پر دوو سایټونو درې رایې ورکوونکي دا نشي کولای۔ تاسو یا واقعاً خپلواک دریم ډومین زیاتوئ — د بل عرضه کوونکي کوچنی سیمه کار کوي که هلته لاره ثابته وي — یا په دوه کلسټرونو وویشل شئ چې جلا etcd لري او د هغه ویش عملیاتي لګښت ومنئ۔ هېڅ شاهدي لنډه لاره له دې نه تېږي: etcd کې سپک منځګړی غړی نشته، نو دریم رایې ورکوونکی بشپړ غړی دی چې خپلې ډیسک، حافظې او شبکې اړتیاوې لري۔ پر ډیاګرام د "شاهدي" په لیکل شوې صندوقه کېندل شاهدي نه جوړوي۔
کورم له خدمت سره یو شان نه دی
etcd کورم API سرور د لیکلو منلو وړ ساتي، او همدا یې ټول ساتل دي۔ د بار انډول کوونکي روغتیایي ازموینې، ingress، د تونل له لارې CNI لاسرسی، د حجمونو د تړلو زونونه او د اپلیکیشن تکرار هر یو خپل ځواب ته اړتیا لري۔ یو کلسټر کولای شي پاک اکثریت ولري او بیا هم کاروونکو ته هېڅ ګټور شی وړاندې نه کړي۔
بیا هغه غړیتوب تایید کړئ چې فکر کوئ لرئ، ځکه ډیاګرامونه ښویېږي:
kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table
د غړو لیست د ځای پرځای کولو انځور سره پرتله کړئ۔ که دوه غړي ورته کوربه یا ورته ریک ته حل شي، انځور غلط دی نه کلسټر، او د غلطې ټوپولوژي شاوخوا اندازه بدلول یوازې د همدې ځنډ ګرانې بڼه اخلي۔
مخکې له دې چې هر درې-رایې ډیزاین تایید کړئ، څلور پوښتنو ته ځواب ووایئ: څو رایې ورکوونکي یوځای بریښنا له لاسه ورکوي، د کوم سایټ له لاسه ورکول لا هم اکثریت پاتې کوي، کله چې تونل ولوېږي مشر چېرته ناست دی، او ژوندی پاتې سایټ لا څه کولای شي۔ په هر یو کې "ډاډه نه یم" مانا دا ده چې کلسټر لا هم لوړ لاسرسی نه لري۔ دا درې بختوره ماشینونه دي۔