બે સાઇટનાં 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 સર્વરને લેખન સ્વીકારવા સક્ષમ રાખે છે, અને રાખે છે તે એટલું જ. લોડ બેલેન્સર આરોગ્ય તપાસ, 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
સભ્ય સૂચિની પ્લેસમેન્ટ ચિત્ર સાથે તુલના કરો. જો બે સભ્યો એક જ હોસ્ટ અથવા એક જ રેક પર ઉકેલાય, તો ચિત્ર ખોટું છે, ક્લસ્ટર નહીં, અને ખોટી ટોપોલોજી આસપાસ માપ બદલવાથી ફક્ત એ જ અટકાવની વધુ ખર્ચાળ આવૃત્તિ મળે છે.
કોઈપણ ત્રણ-મતદાર ડિઝાઇનને મંજૂરી આપતાં પહેલાં ચાર પ્રશ્નોના જવાબ આપો: કેટલા મતદાર એકસાથે વીજળી ગુમાવે છે, કોની સાઇટ ગુમાવવાથી હજી બહુમત રહે છે, ટનલ પડે ત્યારે નેતૃત્વ ક્યાં બેસે છે, અને બચેલી સાઇટ હજી શું કરી શકે છે. તેમાંથી કોઈપણ પર "ખાતરી નથી" એટલે ક્લસ્ટર હજી ઉચ્ચ ઉપલબ્ધ નથી. તે ત્રણ મશીન છે જે નસીબદાર હતાં.