क्या दो साइट वाले 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
सदस्य सूची की प्लेसमेंट चित्र से तुलना करें। अगर दो सदस्य एक ही होस्ट या एक ही रैक पर हल होते हैं, तो गलत चित्र है, क्लस्टर नहीं, और गलत टोपोलॉजी के आसपास आकार बदलना उसी रुकावट का केवल महँगा संस्करण खरीदता है।
किसी भी तीन-मतदाता डिज़ाइन को मंज़ूरी देने से पहले चार सवालों के जवाब दें: कितने मतदाता एक साथ बिजली खोते हैं, किस साइट के जाने पर अब भी बहुमत बचता है, सुरंग गिरने पर नेता कहाँ बैठता है, और बची हुई साइट अब भी क्या कर सकती है। इनमें से किसी पर भी "पक्का नहीं" का मतलब है कि क्लस्टर अभी उच्च उपलब्ध नहीं है। यह तीन मशीनें हैं जिनकी किस्मत अच्छी रही।