👨‍👦 🈷️ 👩🏽‍🤝‍👨🏾 3.4 3.4: भंडारण विश्वसनीयता और सुरक्षा अनुसंधान 🏸 🏷️ 🎥

ध्यान दें perev। : इस लेख की सामग्री हमारे ब्लॉग की पूरी तरह से विशिष्ट नहीं है। हालाँकि, जैसा कि बहुत से लोग जानते हैं, कॉर्डर्नस के दिल में स्थित है, यही वजह है कि विश्वसनीयता के क्षेत्र में एक स्वतंत्र सलाहकार द्वारा आयोजित यह अध्ययन, इस प्रणाली को संचालित करने वाले इंजीनियरों के बीच दिलचस्प निकला। इसके अलावा, यह दिलचस्प है कि ओपन सोर्स-प्रोजेक्ट्स जो पहले से ही उत्पादन में खुद को साबित कर चुके हैं, इतने "कम" स्तर पर भी सुधार किए जा रहे हैं।

की-वैल्यू (KV) आदि वॉल्ट एक डिस्ट्रिब्यूटेड डेटाबेस है जो रेज़ल कंसिस्टेंट एल्गोरिथ्म पर आधारित है। 2014 में किए गए एक विश्लेषण में , हमने पाया कि etcd 0.4.1 डिफ़ॉल्ट रूप से तथाकथित बासी रीड से प्रभावित था(रीड ऑपरेशंस जो सिंक्रोनाइज़ेशन में देरी के कारण पुराना, अप्रासंगिक मान लौटाते हैं - लगभग। अनुवाद।) । हमने फिर से विश्वसनीयता और सुरक्षा के क्षेत्र में इसकी क्षमता का विस्तार से मूल्यांकन करने के लिए (इस समय - 3.4.3 संस्करण के लिए) लौटने का फैसला किया।

हमने पाया है कि "की-वैल्यू" की जोड़ियों के साथ ऑपरेशन सख्ती से क्रमबद्ध है और यह कि ऑब्जर्वर (घड़ियों) की प्रक्रियाएं ऑर्डर की में हर बदलाव को डिलीवर करती हैं। हालांकि, etcd में ताले मूलभूत रूप से असुरक्षित हैं, और उनके साथ जुड़े जोखिम को बग द्वारा समाप्त कर दिया गया है, जिसके परिणामस्वरूप लॉक की प्रतीक्षा के बाद पट्टे की प्रासंगिकता की जांच नहीं की जाती है । आप प्रोजेक्ट ब्लॉग पर हमारी रिपोर्ट पर etc डेवलपर्स की टिप्पणी पढ़ सकते हैं ।

यह अध्ययन द क्लाउड फाउंडेशन के हिस्से क्लाउड नेटिव कंप्यूटिंग फाउंडेशन (सीएनसीएफ) द्वारा प्रायोजित किया गया था । यह जेपसेन नैतिक नीतियों के पूर्ण अनुपालन में किया गया था ।

1। पृष्ठभूमि

Etc KV रिपॉजिटरी एक वितरित प्रणाली है जिसे समन्वय के लिए एक आधार के रूप में उपयोग करने के लिए डिज़ाइन किया गया है। जैसा Zookeeper और कौंसुल , दुकानों शायद ही कभी अद्यतन राज्यों की थोड़ी मात्रा etcd ( 8 जीबी के लिए डिफ़ॉल्ट ऊपर से मुख्य-मान नक्शे के रूप में) और प्रदान करता है सख्ती से serializable पढ़ने, लिखने और microtransactions डेटा गोदाम भर है, साथ ही की तरह समन्वय पुरातन ताले , ट्रैकिंग (घड़ियों) और नेता चयन। कई वितरित सिस्टम, जैसे कुबेरनेट्स और ओपनस्टैक , क्लस्टर मेटाडेटा को स्टोर करने के लिए etcd का उपयोग करते हैं, डेटा के समन्वित विचारों का समन्वय करते हैं, एक नेता चुनते हैं, आदि।

2014 में, हमने पहले से ही etcd.1.1 का मूल्यांकन किया । तब हमने पाया कि डिफ़ॉल्ट रूप से यह अनुकूलन के कारण बासी रीड के लिए प्रवण है। जबकि बेड़ा सिद्धांतों पर काम थ्रेड्स में रीड ऑपरेशंस को विभाजित करने और व्यवहार्यता सुनिश्चित करने के लिए एक सर्वसम्मति प्रणाली के माध्यम से पारित करने की आवश्यकता पर चर्चा करता है, etcd नए लीडर पर अधिक वर्तमान स्थिति की जांच किए बिना किसी भी नेता पर स्थानीय रूप से पढ़ता है। Etcd विकास दल कार्यान्वित वैकल्पिक कोरम झंडा , और etcd संस्करण 3.0 एपीआई में , linearizability पर नज़र रखने के संचालन को छोड़कर सभी कार्यों के लिए दिखाई दिया डिफ़ॉल्ट रूप से । Thedd 3.0 एपीआई एक केवी फ्लैट मैप पर केंद्रित है जहां चाबियाँ और मान अपारदर्शी हैं

( अपारदर्शी ) बाइट सरणियाँ। श्रेणी के प्रश्नों का उपयोग करके, आप पदानुक्रमित कुंजी का अनुकरण कर सकते हैं। उपयोगकर्ता कुंजियों को पढ़ सकते हैं, लिख सकते हैं और हटा सकते हैं, साथ ही एक कुंजी या श्रेणी की कुंजियों के लिए अपडेट के प्रवाह की निगरानी कर सकते हैं। Thedd टूलकिट पट्टों (एक सीमित जीवनकाल के साथ चर वस्तुओं, जो ग्राहक के दिल की धड़कन-अनुरोधों द्वारा सक्रिय स्थिति में बनाए रखा जाता है), लॉक्स (पट्टे के लिए बाध्य समर्पित वस्तुएं) और नेताओं की पसंद के साथ पूरक है।

3.0 संस्करण में, etcd एक सीमित लेनदेन एपीआई प्रदान करता हैकई चाबियों के साथ परमाणु संचालन के लिए। इस मॉडल में, एक लेन-देन एक सशर्त अभिव्यक्ति है जो एक विधेय, एक सच्ची शाखा और एक झूठी शाखा के साथ है। एक कुंजी कई प्रमुख तुलनाओं का एक संयोजन हो सकती है: समानता या विभिन्न असमानताएं, एक कुंजी के संस्करणों के अनुसार, वैश्विक पुनरीक्षण आदि, या वर्तमान प्रमुख मूल्य। सच्ची और झूठी शाखाओं में कई पढ़ने और लिखने के कार्य शामिल हो सकते हैं; उन सभी को परमाणु अनुमान के आधार पर लागू किया जाता है।

1.1 प्रलेखन में स्थिरता की गारंटी

अक्टूबर 2019 तक, एपीआई के लिए इनडर्ड डॉक्यूमेंट में कहा गया है कि "सभी एपीआई कॉल लगातार स्थिरता प्रदर्शित करते हैं - वितरित सिस्टम पर उपलब्ध स्थिरता गारंटी का सबसे मजबूत रूप।" ऐसा नहीं है: सुसंगत संगति रैखिकता की तुलना में कड़ाई से कमजोर है, और वितरित प्रणालियों में रैखिकता निश्चित रूप से प्राप्त करने योग्य है। इसके अलावा, प्रलेखन में कहा गया है कि "रीड ऑपरेशन के दौरान, etcd हस्तांतरण के बारे में गारंटी नहीं देता है [सबसे हाल ही में (क्वेरी के पूरा होने के बाद बाहरी घड़ी द्वारा मापा गया)] मूल्य क्लस्टर के किसी भी प्रतिनिधि पर उपलब्ध है" यह भी एक बहुत ही रूढ़िवादी कथन है: अगर etcd रैखिकता प्रदान करता है, तो रीड ऑपरेशन हमेशा रैखिक क्रम में सबसे हाल ही में प्रतिबद्ध राज्य के साथ जुड़े होते हैं।

दस्तावेज़ीकरण यह भी दावा करता है कि etcd क्रमिक अलगाव की गारंटी देता है: सभी ऑपरेशन (यहां तक कि जो कई कुंजियों को प्रभावित करते हैं) कुछ सामान्य क्रम में किए जाते हैं। लेखकों ने श्रेणीबद्ध अलगाव का वर्णन "वितरित प्रणालियों में उपलब्ध सबसे मजबूत अलगाव स्तर" के रूप में किया है। यह ("अलगाव स्तर" से आपका क्या अर्थ है) यह भी सच नहीं है; सख्त सीरियज़ेबिलिटी सिंपल सीरिज़ेबिलिटी से अधिक मजबूत है, जबकि पूर्व वितरित सिस्टम में भी प्राप्त करने योग्य है।

प्रलेखन का कहना है कि etcd में सभी संचालन (ट्रैकिंग को छोड़कर) डिफ़ॉल्ट रूप से रैखिक हैं। इस मामले में, रैखिकता को कमजोर रूप से सिंक्रनाइज़ वैश्विक घड़ियों के साथ स्थिरता के रूप में परिभाषित किया गया है। यह ध्यान दिया जाना चाहिए कि ऐसी परिभाषा रैखिकता की परिभाषा के साथ न केवल असंगत हैHerlihy और विंग, लेकिन यह भी कार्य-कारण के उल्लंघन का तात्पर्य करता है: अग्रणी घंटों के नोड्स उन ऑपरेशनों के परिणामों को पढ़ने की कोशिश करेंगे जो अभी भी शुरू नहीं हुए हैं। हम मानते हैं कि etcd अभी भी टाइम मशीन नहीं है, और चूंकि यह रफ़ एल्गोरिथम पर आधारित है, इसलिए रैखिकता की आम तौर पर स्वीकृत परिभाषा को लागू किया जाना चाहिए।

चूंकि etcd में KV संचालन क्रमबद्ध और रैखिक है, इसलिए हम सोचते हैं कि वास्तव में etcd डिफ़ॉल्ट रूप से सख्त क्रमांकन प्रदान करता है । यह समझ में आता है, चूँकि सभी कुंजियाँ एक ही राज्य मशीन में होती हैं, और रफ इस राज्य मशीन पर सभी कार्यों के पूर्ण आदेश प्रदान करता है। वास्तव में, संपूर्ण वार्म डेटासेट एकल रेखीय वस्तु है।

वैकल्पिक ध्वज serializable कमकड़ाई से नियमित क्रमिक स्थिरता के लिए रीड ऑपरेशन का स्तर, एक पुरानी प्रतिबद्ध स्थिति के पढ़ने की अनुमति देता है। ध्यान दें कि ध्वज serializableकहानी की क्रमिकता को प्रभावित नहीं करता है; केवी संचालन वगैरह सभी मामलों में क्रमबद्ध हैं।

2. परीक्षण विकास

एक परीक्षण सूट बनाने के लिए , हमने उपयुक्त जेपसेन पुस्तकालय का उपयोग किया। वर्जन 3.4.3 (अक्टूबर'19 के अनुसार नवीनतम) का विश्लेषण किया गया, जिसमें 5 स्टोड्स वाले डेबियन स्ट्रेच क्लस्टर्स पर काम किया गया। हमने नेटवर्क समूहों सहित इन समूहों में कई दोषों को लागू किया है, अलग-अलग नोड्स को अलग करना, क्लस्टर को बहुमत और अल्पसंख्यक में विभाजित करना, साथ ही अतिव्यापी बहुमत के साथ गैर-सकर्मक विभाजन। उन्होंने "गिरा दिया" और नोड्स के यादृच्छिक सबसेट को निलंबित कर दिया, और जानबूझकर अक्षम नेताओं को भी। कई सौ सेकंड तक के अस्थायी विकृतियों को मल्टीसेकंड अंतराल और मिलीसेकंड वाले (तेज "झिलमिलाहट") दोनों में पेश किया गया था। चूंकि etcd गतिशील रूप से घटकों की संख्या को बदलने का समर्थन करता है, इसलिए हमने परीक्षण के दौरान यादृच्छिक रूप से जोड़े और हटाए गए नोड्स को जोड़ा।

परीक्षण भार में केवी पर परिचालन की जाँच के लिए रजिस्टर, सेट और लेन-देन के परीक्षण और साथ ही ताले और घड़ियों के लिए विशेष भार शामिल थे।

२.१ रजिस्टर

KV संचालन के दौरान etcd की विश्वसनीयता का मूल्यांकन करने के लिए, एक रजिस्टर टेस्ट विकसित किया गया था , जिसके दौरान यूनिट कीज़ पर यादृच्छिक रीड, राइट, तुलना-और-सेट ऑपरेशन किए गए थे । तुलना / स्थापना रजिस्टर मॉडल और संस्करण जानकारी का उपयोग करके नोज़ोस लीनरिज़ेबिलिटी टूल का उपयोग करके परिणामों का मूल्यांकन किया गया था ।

2.2 सेट

बासी मात्रा को निर्धारित करने के लिए, एक परीक्षण विकसित किया गया था जो एक एकल कुंजी से पूर्णांकों के सेट को पढ़ने के लिए एक तुलना-और-सेट लेनदेन का उपयोग करता था और फिर इस सेट में एक मूल्य जोड़ता है। परीक्षण के दौरान, हमने पूरे सेट का एक समानांतर रीडिंग भी किया। परीक्षण के पूरा होने के बाद, परिणामों का विश्लेषण मामलों की घटना के लिए किया गया था जब तत्व, जिसे सेट में मौजूद होने के लिए जाना जाता था, पढ़ने के परिणामों में अनुपस्थित था। इन मामलों का इस्तेमाल बासी रीड और खोए हुए अपडेट को निर्धारित करने के लिए किया गया था।

2.3 परिशिष्ट परीक्षण

सख्त अनुक्रमिकता को सत्यापित करने के लिए, एक परिशिष्ट परीक्षण विकसित किया गया था, जिसके दौरान लेन-देन समानांतर और अनूठे मूल्यों के अनूठे सेटों की सूची में जोड़ा गया था। प्रत्येक सूची को एक etcd कुंजी में संग्रहीत किया गया था, और प्रत्येक लेनदेन में परिवर्धन किए गए थे, प्रत्येक कुंजी को पढ़ना जो एक लेनदेन में बदलना आवश्यक था , और फिर इन चाबियों को लिखा गया था और दूसरे लेनदेन में पढ़े गए थे , जिसे संरक्षित किया गया थायह सुनिश्चित करने के लिए कि पहले पढ़े जाने के बाद से कोई रिकॉर्ड की गई कुंजी नहीं बदली गई है। परीक्षण के अंत में, हमने वास्तविक समय की प्राथमिकता के आधार पर लेन-देन के बीच संबंध और पढ़ने और संचालन को जोड़ने के संबंध को साजिश रची। लूप्स के लिए इस ग्राफ की जाँच करने से यह निर्धारित करना संभव हो गया कि संचालन सख्ती से अनुक्रमिक थे या नहीं।

जबकि etc लेनदेन में एक ही कुंजी को कई बार लिखने से रोकता है, आप प्रति कुंजी एक रिकॉर्ड तक लेनदेन बना सकते हैं। हमने यह भी सुनिश्चित किया कि उसी लेन-देन के भीतर पढ़ने के संचालन ने उसी लेनदेन से पिछले लेखन कार्यों को प्रतिबिंबित किया।

2.4 ताले

एक समन्वय सेवा के रूप में, etcd वितरित लॉकिंग के लिए अंतर्निहित समर्थन का वादा करता है । हमने इन तालों की दो तरह से जांच की। सबसे पहले, यादृच्छिक लॉक और अनलॉक अनुरोध उत्पन्न हुए थे , प्रत्येक लॉक के लिए एक पट्टा प्राप्त करना और रिलीज़ keepalive होने तक जावा क्लाइंट में बिल्ट-इन आदि क्लाइंट का उपयोग करके इसे खुला छोड़ना । हमने यह देखने के लिए कि उन्होंने लॉक सेवा का एक रैखिक क्रियान्वयन किया है, नोजोस के साथ परिणामों का परीक्षण किया। अधिक व्यावहारिक परीक्षण के लिए (और लॉक विफलताओं की आवृत्ति को निर्धारित करने के लिए), हमने इन-मेमोरी में सेट को अपडेट करते समय आपसी बहिष्कार को व्यवस्थित करने के लिए ताले और etcd का उपयोग किया।

और इस सेट में खोए हुए अपडेट की खोज की। इस परीक्षण ने हमें सीधे पुष्टि करने की अनुमति दी है कि क्या म्यूटेक्स के रूप में कॉर्क का उपयोग करने वाले सिस्टम आंतरिक स्थिति को सुरक्षित रूप से अपडेट कर सकते हैं।

लॉक टेस्ट के तीसरे संस्करण में लीज कुंजी पर गार्ड शामिल हैं जो कि सेट में संग्रहीत संग्रह को संशोधित करने के लिए हैं।

2.5 ट्रैकिंग

यह सत्यापित करने के लिए कि घड़ियाँ प्रत्येक मुख्य अद्यतन के बारे में जानकारी प्रदान करती हैं, परीक्षण के हिस्से के रूप में एक कुंजी बनाई गई और नेत्रहीन अद्वितीय पूर्णांक मान असाइन किए गए । इस बीच, ग्राहकों ने एक बार में कई सेकंड के लिए इस कुंजी को साझा किया। हर बार घड़ी की दीक्षा के बाद, ग्राहक उस संशोधन के साथ शुरू हुआ जिस पर उसने पिछली बार रोक दिया था।

इस प्रक्रिया के अंत में, हमने यह सुनिश्चित किया कि प्रत्येक ग्राहक मुख्य परिवर्तनों के क्रम को देखे।

3। परिणाम

3.1 0 संशोधन से ट्रैकिंग

कुंजी को ट्रैक करते समय, ग्राहक एक प्रारंभिक संशोधन निर्दिष्ट कर सकते हैं , जो "एक वैकल्पिक संशोधन है जिसके साथ ट्रैकिंग शुरू होती है (समावेशी)"। यदि उपयोगकर्ता प्रत्येक कुंजी को एक निश्चित कुंजी के साथ देखना चाहता है, तो वह etcd के पहले संशोधन को निर्दिष्ट कर सकता है। ये कैसा ऑडिट है? डेटा मॉडल और शब्दकोष इस प्रश्न का उत्तर प्रदान नहीं करते हैं; संशोधनों को नीरस रूप से 64-बिट काउंटरों को बढ़ाने के रूप में वर्णित किया गया है, लेकिन यह स्पष्ट नहीं है कि etcd 0 से शुरू होता है या 1. यह मान लेना उचित है कि उलटी गिनती खरोंच से है (बस मामले में)।

काश, यह गलत है। 0 वें संशोधन का अनुरोध करना, आदि अपडेट को प्रसारण शुरू करने का कारण बनता है, सर्वर पर वर्तमान संशोधन के साथ शुरू होता है प्लस, लेकिन बहुत पहले के साथ नहीं। 1 संशोधन के लिए अनुरोध सभी परिवर्तन देता है। यह व्यवहार कहीं भी प्रलेखित नहीं है ।

हमारा मानना है कि व्यवहार में इस सूक्ष्मता से उत्पादन में समस्याएँ पैदा होने की संभावना नहीं है, क्योंकि अधिकांश क्लस्टर पहले संशोधन पर नहीं टिकते हैं। इसके अलावा, etcd समय के साथ वैसे भी कहानी को संपीड़ित करता है, इसलिए वास्तविक-दुनिया के अनुप्रयोगों में, सबसे अधिक संभावना है, किसी भी मामले में, 1 संशोधन के साथ शुरू होने वाले सभी संस्करणों को पढ़ने की आवश्यकता नहीं है। ऐसा व्यवहार उचित है, लेकिन यह प्रलेखन में संबंधित विवरण को चोट नहीं पहुंचाएगा।

3.2 पौराणिक ताले

ताले के लिए एपीआई प्रलेखन बताता है कि बंद कुंजी "लेन-देन के साथ संयोजन में उपयोग की जा सकती है ताकि यह सुनिश्चित हो सके कि अपडेट तभी हो जब लॉक का स्वामित्व हो।" अजीब है, लेकिन यह स्वयं ताले के लिए कोई गारंटी प्रदान नहीं करता है और उनके उद्देश्य की व्याख्या नहीं की जाती है।

हालांकि, अन्य सामग्रियों में, अनुरक्षक etcd अभी भी ताले के उपयोग के बारे में जानकारी साझा करते हैं। उदाहरण के लिए, etc 3.2 रिलीज की घोषणाetcdctl डिस्क पर फ़ाइल साझाकरण परिवर्तनों को अवरुद्ध करने के लिए एक एप्लिकेशन का वर्णन करती है । इसके अलावा, ताले के विशिष्ट उद्देश्य के बारे में एक सवाल के साथ GitHub पर एक समस्या , आदि डेवलपर्स में से एक को प्रोत्साहित किया गया है:

etcd , ( ) , ( etcd), - :

etcd;
- ( , etcd);
.

इस तरह के एक उदाहरण में दिया गया है etcdctl: टीम की सुरक्षा के लिए एक लॉक का उपयोग किया गया था put, लेकिन अपडेट के लिए लॉक कुंजी को बाँध नहीं किया।

काश, यह सुरक्षित नहीं है क्योंकि यह कई ग्राहकों को एक साथ एक ही लॉक रखने की अनुमति देता है। समस्या प्रक्रियाओं, नेटवर्क क्रैश या विभाजन के निलंबन से बढ़ी है, हालांकि, यह किसी भी बाहरी विफलताओं के बिना पूरी तरह से स्वस्थ समूहों में भी हो सकती है। उदाहरण के लिए, इस टेस्ट रन में, प्रोसेस नंबर 3 सफलतापूर्वक लॉक सेट करता है, और प्रोसेस 1 को समानांतर में भी वही लॉक मिलता है, जबकि प्रोसेस 3 में इसे हटाने का अवसर होता है:

छोटे टीटीएल के साथ पट्टों पर म्यूटेक्स का उल्लंघन सबसे अधिक ध्यान देने योग्य था: 1, 2 और 3 सेकंड के टीटीएल केवल कुछ मिनटों के परीक्षण (स्वस्थ समूहों में भी) के बाद पारस्परिक बहिष्कार प्रदान करने में सक्षम नहीं थे। प्रक्रिया निलंबन और नेटवर्क विभाजन के कारण समस्याएं और भी तेजी से बढ़ीं।

हमारे एक लॉक-टेस्ट वेरिएंट में, etcd म्यूटेक्स का उपयोग पूर्णांक के एक सेट के संयुक्त अद्यतन को संरक्षित करने के लिए किया गया था (जैसा कि दस्तावेजीकरण etcd से पता चलता है)। प्रत्येक अपडेट में इन-मेमोरी नमूना मूल्य पढ़ा जाता है, और, लगभग एक सेकंड के बाद, इस संग्रह को एक अद्वितीय तत्व के अतिरिक्त के साथ वापस लिखता है। दो सेकंड के टीटीएल के साथ पट्टों के साथ, पांच समानांतर प्रक्रियाएं, और हर पांच सेकंड में एक प्रक्रिया रोकती है, हम लगभग 18% अद्यतित अद्यतनों के लगातार नुकसान का कारण बन सकते हैं।

इस समस्या को वगैरह में आंतरिक लॉकिंग तंत्र द्वारा समाप्त कर दिया गया था। यदि क्लाइंट दूसरे क्लाइंट के लिए इसे अनलॉक करने के लिए इंतजार कर रहा है, तो उसने अपना लीज खो दिया है, और उसके बाद लॉक जारी किया गया था, सर्वर ने यह सुनिश्चित करने के लिए लीज को डबल-चेक नहीं किया कि यह क्लाइंट को सूचित करने से पहले अभी भी मान्य है कि लॉक अब इसके पीछे है।

एक अतिरिक्त पट्टे की जांच, साथ ही लंबे टीटीएल के चयन और चुनाव के समय की सावधानीपूर्वक सेटिंग को शामिल करने से इस समस्या की आवृत्ति कम हो जाएगी। हालाँकि, म्यूटेक्स उल्लंघनों को पूरी तरह से समाप्त नहीं किया जा सकता है, क्योंकि वितरित ताले मूल रूप से अतुल्यकालिक प्रणालियों में असुरक्षित हैं। डॉ। मार्टिन क्लेपमैन ने अपने लेख में इसका वर्णन किया हैवितरित ताले के बारे में। उनके अनुसार, अतुल्यकालिक प्रणालियों में व्यवहार्यता बनाए रखने के लिए ब्लॉकिंग सेवाओं को शुद्धता का त्याग करना चाहिए: यदि ब्लॉकिंग को नियंत्रित करते समय प्रक्रिया क्रैश हो जाती है, तो ब्लॉकिंग सेवा को ब्लॉकिंग को अनलॉक करने के लिए मजबूर करने के लिए किसी तरह की आवश्यकता होती है। हालांकि, अगर प्रक्रिया वास्तव में नहीं गिरती है, लेकिन बस धीरे-धीरे चलती है या अस्थायी रूप से अनुपलब्ध है, तो इसे अनलॉक करने से इसे एक ही समय में कई स्थानों पर आयोजित किया जा सकता है।

लेकिन भले ही वितरित अवरुद्ध सेवा कुछ प्रकार के जादू विफलता डिटेक्टर का उपयोग करती है, कहती है, और वास्तव में कुछ गैर-स्थानीय संसाधनों के मामले में आपसी बहिष्कार की गारंटी दे सकती है, फिर भी इसका उपयोग असुरक्षित होगा। मान लीजिए कि प्रक्रिया A लॉक रखते हुए डेटाबेस D को संदेश भेजती है। उसके बाद, ए क्रैश की प्रक्रिया करें, और प्रक्रिया बी को एक लॉक प्राप्त होता है और आधार डी को एक संदेश भी भेजता है। समस्या यह है कि प्रक्रिया ए से एक संदेश (अतुल्यकालिक के कारण) प्रक्रिया बी से एक संदेश के बाद आ सकता है, उस पारस्परिक अपवाद का उल्लंघन करते हुए जिसे ताला प्रदान करना चाहिए था। ।

इस समस्या को रोकने के लिए, इस तथ्य पर भरोसा करना आवश्यक है कि भंडारण प्रणाली स्वयं लेनदेन की शुद्धता का समर्थन करेगी या, यदि लॉकिंग सेवा ऐसा तंत्र प्रदान करती है, तो उपयोग करें" फेंसिंग" टोकन जो ताला धारक द्वारा किए गए सभी कार्यों में शामिल किया जाएगा। यह सुनिश्चित करेगा कि पिछले लॉक होल्डर का कोई भी संचालन वर्तमान लॉक मालिक के संचालन के बीच अचानक न हो। उदाहरण के लिए, Google की चॉबी ब्लॉकिंग सेवा में, इन टोकन को सीक्वेंसर कहा जाता है । Etcd में, आप लॉक की रिवीजन का उपयोग कर सकते हैं क्योंकि विश्व स्तर पर ब्लॉकिंग टोकन का आदेश दिया गया है।

इसके अलावा, etcd में लॉक कीज़ का उपयोग etcd में ट्रांसेक्शनल अपडेट को सुरक्षित रखने के लिए किया जा सकता है। लेन-देन के भाग के रूप में लॉक कुंजी संस्करण की जाँच करना, अगर कोई लॉक नहीं है (यानी लॉक कुंजी संस्करण शून्य से अधिक है), तो उपयोगकर्ता लेनदेन को रोक सकते हैं। हमारे परीक्षणों में, इस दृष्टिकोण ने हमें पठन-संशोधित-लेखन कार्यों को सफलतापूर्वक अलग करने की अनुमति दी, जिसमें लेखन केवल लॉकिंग द्वारा संरक्षित लेनदेन था। यह दृष्टिकोण बैराज टोकन के समान अलगाव प्रदान करता है, लेकिन (बैराज टोकन की तरह) परमाणुता की गारंटी नहीं देता है: एक प्रक्रिया कई ऑपरेशन से अपडेट होने के दौरान एक म्यूटेक्स को क्रैश या खो सकती है, जिससे तार्किक रूप से असंगत स्थिति हो सकती है।

परियोजना के मुद्दों में काम के परिणाम:

संशोधन 0 से शुरू होने वाली घड़ियाँ बाद में शुरू होती हैं - निर्णय नहीं लिया जाता;
स्वामित्व की जांच के बिना अवरुद्ध होने के बाद ताले लौटे - मास्टर में;
ताले को असुरक्षित के रूप में प्रलेखित नहीं किया जाता है - हल नहीं किया जाता है।

4। चर्चा

हमारे परीक्षणों में, 3.4.3 केवी संचालन के बारे में अपेक्षाओं पर खरा उतरा: हमने प्रक्रियाओं, क्रैश, घड़ी और नेटवर्क के हेरफेर, साथ ही साथ क्लस्टर सदस्यों की संख्या में बदलाव के बावजूद, पढ़ने, लिखने और यहां तक कि बहु-कुंजी लेनदेन की क्रमिक स्थिरता देखी। । केवी संचालन में डिफ़ॉल्ट रूप से सख्ती से क्रमबद्ध व्यवहार लागू किया गया था; ध्वज serializableसेट के साथ रीडिंग का प्रदर्शन बासी रीड की उपस्थिति के रूप में हुआ (जैसा कि प्रलेखन में वर्णित है)।

मॉनिटर (घड़ियों) सही ढंग से काम करने के लिए - कम से कम व्यक्तिगत कुंजियों पर। जब तक इतिहास के संपीड़न ने पुराने डेटा को नष्ट नहीं किया, तब तक घड़ी ने प्रत्येक कुंजी को सफलतापूर्वक जारी किया।

हालाँकि, यह पता चला है कि वगैरह में ताले (जैसे सभी वितरित ताले) पारस्परिक बहिष्कार प्रदान नहीं करते हैं। विभिन्न प्रक्रियाएं एक ही समय में ताला पकड़ सकती हैं - यहां तक कि पूरी तरह से सिंक्रनाइज़ घड़ियों के साथ स्वस्थ समूहों में भी। लॉकिंग एपीआई के साथ प्रलेखन ने इस बारे में कुछ नहीं कहा, और प्रस्तुत ताले के उदाहरण असुरक्षित थे। हालांकि, ताले के साथ कुछ समस्याओं को इस पैच के जारी होने के बाद जाना था ।

हमारे सहयोग के परिणामस्वरूप, etcd टीम ने प्रलेखन में कई संशोधन किए (वे पहले से ही GitHub पर दिखाई दिए हैं और परियोजना वेबसाइट के भविष्य के संस्करणों में प्रकाशित किए जाएंगे)। GitHub वारंटियों API पेज अब बताता है कि डिफ़ॉल्ट रूप से etcd सख्ती से क्रमबद्ध हैऔर दावा है कि धारावाहिक और अनुक्रमिक वितरण प्रणाली में उपलब्ध स्थिरता का सबसे मजबूत स्तर हटा दिया गया है। संशोधनों के संबंध में, अब यह संकेत दिया गया है कि शुरुआत इकाई (1) से होनी चाहिए , हालांकि एपीआई प्रलेखन अभी भी यह नहीं कहता है कि 0 वें संशोधन से शुरू करने का प्रयास "वर्तमान पुनरीक्षण प्लस 1 के बाद होने वाली घटनाओं का उत्पादन" करेगा। उम्मीद के बजाय "सभी घटनाओं के प्रेषण।" लॉक सुरक्षा मुद्दों का दस्तावेज़ीकरण विकास के अधीन है ।

कुछ दस्तावेज़ीकरण परिवर्तन, जैसे कि पढ़ने के लिए प्रयास करने के दौरान एईआरडी के विशेष व्यवहार का वर्णन करना, एक शून्य संशोधन के साथ शुरू करना, अभी भी ध्यान देने की आवश्यकता है।

हमेशा की तरह, हम इस बात पर जोर देते हैं कि जेपसेन सुरक्षा सत्यापन के लिए एक प्रयोगात्मक दृष्टिकोण पसंद करते हैं: हम बग की उपस्थिति की पुष्टि कर सकते हैं, लेकिन उनकी अनुपस्थिति नहीं। समस्याओं को खोजने के लिए काफी प्रयास किए जा रहे हैं, लेकिन हम सामान्य ज्ञान को सही नहीं साबित कर सकते हैं।

4.1 सिफारिशें

यदि आप वगैरह में ताले का उपयोग करते हैं, तो इस बारे में सोचें कि क्या आपको सुरक्षा के लिए उनकी आवश्यकता है या केवल संभावना को सीमित करके प्रदर्शन को बढ़ाने के लिए। Etcd के ताले का उपयोग प्रदर्शन को बढ़ाने के लिए किया जा सकता है, लेकिन सुरक्षा उद्देश्यों के लिए उनका उपयोग करना जोखिम भरा हो सकता है।

विशेष रूप से, यदि आप किसी साझा संसाधन जैसे फ़ाइल, डेटाबेस या सेवा को सुरक्षित करने के लिए etcd लॉक का उपयोग करते हैं, तो इस संसाधन को ब्लॉक किए बिना सुरक्षा की गारंटी देनी चाहिए । इसे प्राप्त करने का एक तरीका नीरस बैराज टोकन का उपयोग करना है । यह हो सकता है, उदाहरण के लिए, वर्तमान होल्ड लॉक कुंजी के साथ जुड़ा हुआ एक पुराना संशोधन। साझा संसाधन को यह सुनिश्चित करना होगा कि एक बार क्लाइंट ने टोकन का उपयोग किया होyकुछ ऑपरेशन करने के लिए, टोकन वाले किसी भी ऑपरेशन को x < yअस्वीकार कर दिया जाएगा। यह दृष्टिकोण परमाणुता को सुनिश्चित नहीं करता है, लेकिन यह गारंटी देता है कि लॉकिंग के ढांचे के भीतर संचालन क्रम में किया जाता है, और रुक-रुक कर नहीं।

हमें संदेह है कि आम उपयोगकर्ताओं को इस समस्या का सामना करने की संभावना नहीं है। लेकिन अगर आप फिर भी पहले संशोधन से शुरू होने वाले etcd से सभी परिवर्तनों को पढ़ने पर भरोसा करते हैं , तो याद रखें कि आपको पैरामीटर के रूप में 1, न कि 0 पास करने की आवश्यकता है। हमारे प्रयोगों से पता चलता है कि इस मामले में एक शून्य संशोधन का अर्थ है "वर्तमान संशोधन", और नहीं। "जल्द से जल्द।"

अंत में, ताले और etcd (सभी वितरित ताले की तरह) उपयोगकर्ताओं को गुमराह करते हैं: वे उन्हें नियमित रूप से ताले के रूप में उपयोग करना चाहते हैं, लेकिन वे बहुत आश्चर्यचकित होंगे जब उन्हें पता चलेगा कि ये ताले पारस्परिक बहिष्कार प्रदान नहीं करते हैं। GitHub पर एपीआई प्रलेखन, ब्लॉग पोस्ट, मुद्दे इस जोखिम के बारे में कुछ नहीं कहते हैं। हम अनुशंसा करते हैं कि आप ऐसी जानकारी शामिल करें जिसमें अन्य जानकारी शामिल न हो, जो लॉक्स पारस्परिक बहिष्करण प्रदान नहीं करते हैं और उन बैटरियों के टोकन का उपयोग करने के उदाहरणों को साझा करने की स्थिति के बजाय साझा संसाधनों की स्थिति को अपडेट करने के लिए प्रदान करते हैं, जिससे अपडेट का नुकसान हो सकता है।

४.२ आगे की योजना

वार्म प्रोजेक्ट को कई वर्षों के लिए स्थिर माना गया है: इसके आधार पर रफ एल्गोरिथ्म ने अच्छी तरह से काम किया है, केवी संचालन के लिए एपीआई सरल और सीधा है। हालाँकि कुछ अतिरिक्त सुविधाओं को हाल ही में एक नया एपीआई मिला है, इसके शब्दार्थ अपेक्षाकृत सरल हैं। हम मानते हैं कि हम पहले से ही की तरह पर्याप्त बुनियादी आज्ञाओं का अध्ययन किया है getऔर put, लेन-देन को अवरुद्ध और ट्रैकिंग। हालांकि, अन्य परीक्षण हैं जिन्हें निष्पादित किया जाना चाहिए।

फिलहाल, हमने विलोपन का पर्याप्त विस्तृत मूल्यांकन नहीं किया है ।: संस्करण और संशोधन से जुड़े सीमा मामले हो सकते हैं, जब ऑब्जेक्ट लगातार बनाए जाते हैं और हटाए जाते हैं। भविष्य के परीक्षणों में, हम निष्कासन कार्यों को अधिक सावधानीपूर्वक अध्ययन के अधीन करने का इरादा रखते हैं। हमने कई कुंजियों के साथ श्रेणी क्वेरी या ट्रैकिंग संचालन का परीक्षण नहीं किया, हालांकि हमें संदेह है कि उनके शब्दार्थ एकल कुंजी के साथ संचालन के समान हैं।

परीक्षणों में, हमने प्रक्रियाओं के निलंबन, दुर्घटनाओं, घड़ी के साथ जोड़तोड़ का उपयोग किया, नेटवर्क विभाजित किया गया और क्लस्टर की संरचना बदल गई; पर्दे के पीछे एक नोड के स्तर पर डिस्क क्षति और अन्य बीजान्टिन विफलताओं जैसी समस्याएं थीं । भविष्य के शोध में इन अवसरों का पता लगाया जा सकता है।

काम को क्लाउड नेटिव कम्प्यूटिंग फाउंडेशन द्वारा समर्थित किया गया था ।, लिनक्स फाउंडेशन का हिस्सा है , और जेपसेन की नैतिक नीतियों का अनुपालन करता है । हम उनकी मदद के लिए कॉर्ड टीम और विशेष रूप से निम्नलिखित प्रतिनिधियों को धन्यवाद देना चाहते हैं: क्रिस अनीज़्ज़ेक, ग्युहो ली, जियांग ली, हितोशी मितके, जिंगी हू और ब्रैंडन फिलिप्स।

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

3.4 3.4: भंडारण विश्वसनीयता और सुरक्षा अनुसंधान