नमस्कार, हेब्र!

यह कोई रहस्य नहीं है कि आधुनिक अनुप्रयोगों के काम में बड़ी मात्रा में डेटा शामिल हैं, और उनका प्रवाह लगातार बढ़ रहा है। इस डेटा को अक्सर बड़ी संख्या में मशीनों से संग्रहीत और संसाधित करना पड़ता है, और यह एक आसान काम नहीं है। इसे हल करने के लिए, क्लाउड ऑब्जेक्ट स्टोर हैं। आमतौर पर वे सॉफ्टवेयर डिफाइंड स्टोरेज तकनीक का कार्यान्वयन करते हैं।

2018 की शुरुआत में, हमने क्लाउडियन हाइपरस्टोर पर आधारित अपना स्वयं का 100% S3- संगत संग्रहण लॉन्च किया (और लॉन्च किया)। जैसा कि यह निकला, नेटवर्क में क्लाउडियन के बारे में बहुत कम रूसी भाषा के प्रकाशन हैं, और इस समाधान के वास्तविक अनुप्रयोग के बारे में भी कम है।

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

यदि आप अपना S3 संग्रहण बना रहे हैं या इसे बनाए रखने में व्यस्त हैं, तो यह लेख आपके काम आएगा।

सबसे पहले, मैं बताऊंगा कि हमारी पसंद क्लाउडियन पर क्यों गिर गई। यह सरल है: इस जगह में बहुत कम योग्य विकल्प हैं। उदाहरण के लिए, कुछ साल पहले, जब हम सिर्फ निर्माण के बारे में सोच रहे थे, केवल तीन विकल्प थे:

• CEHP + RADOS गेटवे;
  
• Minio;
  
• क्लाउडियन हाइपरस्टोर।
  

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

और हां, सबसे महत्वपूर्ण (निश्चित रूप से!) सबसे महत्वपूर्ण बात यह है कि डेटालाइन और क्लाउडियन में समान कॉर्पोरेट रंग हैं। आपको मानना ​​होगा कि हम ऐसी सुंदरता का विरोध नहीं कर सकते।



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

कैसे Cloudian हाइपरस्टोर स्टोरेज काम करता है

आइए आरेख पर एक नज़र डालें और देखें कि क्लाउडियन समाधान कैसे काम करता है।


मुख्य घटक भंडारण योजना।

जैसा कि हम देख सकते हैं, सिस्टम में कई मुख्य घटक हैं:

• क्लाउडियन प्रबंधन नियंत्रण - प्रबंधन कंसोल ;
• व्यवस्थापक सेवा - आंतरिक प्रशासन मॉड्यूल ;
• एस 3 सेवा - एस 3 प्रोटोकॉल का समर्थन करने के लिए जिम्मेदार मॉड्यूल ;
• हाइपरस्टोर सेवा - वास्तविक भंडारण सेवा ;
• अपाचे कैसेंड्रा - सेवा डेटा का एक केंद्रीकृत भंडार ;
• रेडिस - सबसे अधिक बार पढ़े जाने वाले डेटा के लिए ।

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




ऊपर दिए गए आरेख में सामान्य सेवाओं से हमारा मतलब है S3, HyperStore, CMC और Apache Cassandra । पहली नज़र में, सब कुछ सुंदर और साफ है। लेकिन करीब से जांच करने पर यह पता चलता है कि केवल एक नोड की विफलता प्रभावी ढंग से काम करती है। और एक साथ दो नोड्स का एक साथ नुकसान क्लस्टर उपलब्धता के लिए घातक हो सकता है - रेडिस क्यूओएस (नोड 2 पर) में केवल 1 दास (नोड 3 पर) है। क्लस्टर प्रबंधन को खोने के जोखिम के साथ एक ही तस्वीर - कठपुतली सर्वर केवल दो नोड्स (1 और 2) पर है। हालांकि, एक बार में दो नोड्स की विफलता की संभावना बहुत कम है, और आप इसके साथ रह सकते हैं।

फिर भी, भंडारण की विश्वसनीयता बढ़ाने के लिए, हम न्यूनतम तीन के बजाय डेटालाइन में 4 नोड्स का उपयोग करते हैं। निम्नलिखित संसाधन वितरण प्राप्त किया जाता है:



एक और अति सूक्ष्मता तुरंत आपकी आंख को पकड़ लेती है - रेडिस क्रेडेंशियल्स को हर नोड पर नहीं रखा जाता है (जैसा कि ऊपर की आधिकारिक योजना से माना जा सकता है), लेकिन उनमें से केवल 3 पर। इस मामले में, आने वाले प्रत्येक अनुरोध के लिए Redis Credentials का उपयोग किया जाता है। यह पता चला है कि किसी और के रेडिस में जाने की आवश्यकता के कारण चौथे नोड के प्रदर्शन में कुछ असंतुलन है।

हमारे लिए, यह अभी तक महत्वपूर्ण नहीं है। तनाव परीक्षण के दौरान, नोड्स की प्रतिक्रिया की गति में महत्वपूर्ण विचलन पर ध्यान नहीं दिया गया था, लेकिन दर्जनों कामकाजी नोड्स के बड़े समूहों पर, इस बारीकियों को सही करने के लिए समझ में आता है।

6 नोड्स पर माइग्रेशन स्कीम इस तरह दिखती है:



आरेख दिखाता है कि नोड विफलता की स्थिति में सेवा माइग्रेशन कैसे लागू किया जाता है। प्रत्येक भूमिका के केवल एक सर्वर की विफलता को ध्यान में रखा जाता है। यदि दोनों सर्वर गिर जाते हैं, तो मैनुअल हस्तक्षेप की आवश्यकता होगी।

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

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



जब दो नोड्स विफल होते हैं तो यही होता है। आरेख स्पष्ट रूप से दिखाता है कि इस स्थिति में भी, डेटा सुरक्षित रहता है

उसी समय, डेटा और स्टोरेज की उपलब्धता स्थिरता सुनिश्चित करने की रणनीति पर निर्भर करेगी। डेटा, मेटाडेटा, पढ़ने और लिखने के लिए, इसे अलग से कॉन्फ़िगर किया गया है।

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

क्लाउडियन में क्वेरी प्रसंस्करण

नीचे हम Cloudian HyperStore, PUT और GET में आने वाले अनुरोधों के प्रसंस्करण के लिए दो योजनाओं पर विचार करेंगे। यह S3 सेवा और हाइपरस्टोर के लिए मुख्य कार्य है।

आइए इसकी शुरुआत करें कि लेखन अनुरोध कैसे संसाधित किया जाता है:



निश्चित रूप से आपने उल्लेख किया है कि प्रत्येक अनुरोध बहुत सारे चेक और डेटा पुनर्प्राप्ति उत्पन्न करता है, कम से कम 6 घटक से घटक तक हिट करता है। यह यहां से है कि रिकॉर्डिंग देरी और उच्च सीपीयू समय की खपत छोटी फाइलों के साथ काम करते समय दिखाई देती है।

बड़ी फाइलें चंक्स द्वारा प्रेषित की जाती हैं। अलग-अलग विराम को अलग-अलग अनुरोध नहीं माना जाता है और कुछ जांच नहीं की जाती है।

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



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

डेटा भंडारण और दोहराव

जैसा कि आप ऊपर दिए गए आरेखों से देख सकते हैं, Cloudian विभिन्न डेटा भंडारण और दोहराव योजनाओं का समर्थन करता है:

प्रतिकृति - प्रतिकृति का उपयोग करते हुए, सिस्टम में प्रत्येक डेटा ऑब्जेक्ट की एक कस्टम संख्या को बनाए रखना और प्रत्येक प्रतिलिपि को विभिन्न नोड्स पर संग्रहीत करना संभव है। उदाहरण के लिए, 3X प्रतिकृति का उपयोग करके, प्रत्येक ऑब्जेक्ट की 3 प्रतियां बनाई जाती हैं, और प्रत्येक प्रतिलिपि अपने स्वयं के नोड पर "झूठ" होती है।

इरेज़र कोडिंग - इरेज़र कोडिंग के साथ, प्रत्येक ऑब्जेक्ट डेटा टुकड़ों के एक कस्टम राशि (जिसे K नंबर के रूप में जाना जाता है) के साथ-साथ अतिरेक कोड (M नंबर) की एक कस्टम राशि में एन्कोड किया गया है। किसी वस्तु का प्रत्येक K + M अंश अद्वितीय होता है, और प्रत्येक खंड अपने नोड पर संग्रहीत होता है। किसी K अंशों का उपयोग करके किसी ऑब्जेक्ट को डिकोड किया जा सकता है। दूसरे शब्दों में, ऑब्जेक्ट पठनीय रहता है, भले ही एम नोड दुर्गम हो।

उदाहरण के लिए, 4 + 2 फॉर्मूला (4 डेटा टुकड़े प्लस 2 अतिरेक कोड टुकड़े) के अनुसार इरेज़िंग कोडिंग में, प्रत्येक ऑब्जेक्ट को 6 अलग-अलग नोड्स पर संग्रहीत 6 अद्वितीय टुकड़ों में विभाजित किया जाता है, और इस ऑब्जेक्ट को पुनर्स्थापित किया जा सकता है और पढ़ सकता है यदि 6 में से 4 टुकड़े उपलब्ध हैं ।

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

हाइपरस्टोर के अन्य कार्यों के बारे में संक्षेप में

जैसा कि मैंने इस लेख की शुरुआत में लिखा था, कई उपयोगी उपकरण हाइपरस्टोर में बनाए गए हैं। उनमें से हैं:

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

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

क्लाउडियन हाइपरस्टोर लॉजिक

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

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

हाइपरस्टोर में अपाचे कैसेंड्रा की भूमिका

HyperStore में, Cassandra का उपयोग ऑब्जेक्ट मेटाडेटा, उपयोगकर्ता खाता जानकारी और सेवा उपयोग डेटा को संग्रहीत करने के लिए किया जाता है। प्रत्येक हाइपरस्टोर पर एक विशिष्ट तैनाती में, कैसंड्रा डेटा को ओएस के समान ड्राइव पर संग्रहीत किया जाता है। सिस्टम प्रत्येक नोड पर समर्पित ड्राइव पर कैसेंड्रा डेटा का भी समर्थन करता है। कैसंड्रा डेटा हाइपरस्टोर डेटा डिस्क पर संग्रहीत नहीं है। जब vNodes होस्ट करने के लिए असाइन किए जाते हैं, तो उन्हें केवल हाइपरस्टोर स्टोरेज नोड्स में वितरित किया जाता है। vNodes उस ड्राइव को आवंटित नहीं किया जाता है जहाँ Cassandra डेटा संग्रहीत है।
क्लस्टर के अंदर, कैसंड्रा में मेटाडेटा को आपकी रिपॉजिटरी की नीति (रणनीति) के अनुसार दोहराया जाता है। कैसेंड्रा डेटा प्रतिकृति इस तरह vNodes का उपयोग करती है:

• एक नई कैसंड्रा ऑब्जेक्ट (प्राथमिक कुंजी और इसके संबंधित मान) बनाते समय, यह हैशेड होता है, और हैश का उपयोग किसी विशिष्ट vNode के साथ ऑब्जेक्ट को जोड़ने के लिए किया जाता है। सिस्टम जांचता है कि कौन सा होस्ट इस vNode को सौंपा गया है, और उसके बाद Cassandra ऑब्जेक्ट की पहली प्रतिकृति उस होस्ट पर Cassandra ड्राइव पर संग्रहीत की जाती है।
  
• उदाहरण के लिए, मान लीजिए कि एक होस्ट को हाइपरस्टोर डेटा डिस्क पर वितरित किए गए 96 vNodes असाइन किए गए हैं। कैसेंड्रा ऑब्जेक्ट्स जिनके हैश मान इन 96 vNodes में से किसी भी टोकन रेंज में आते हैं, इस होस्ट पर कैसेंड्रा ड्राइव को लिखा जाएगा।
  
• कैसेंड्रा ऑब्जेक्ट की अतिरिक्त प्रतिकृतियां (प्रतिकृतियों की संख्या आपके कॉन्फ़िगरेशन पर निर्भर करती है) निम्नलिखित अनुक्रम संख्या के साथ vNodes से जुड़ी होती हैं और इन vNodes को नोड पर संग्रहीत किया जाता है, बशर्ते कि यदि आवश्यक हो, तो vNodes को छोड़ दिया जाता है, ताकि Cassandra ऑब्जेक्ट की प्रत्येक प्रतिकृति किसी अन्य पर संग्रहीत हो मेजबान मशीन।
  

हाइपरस्टोर स्टोरेज कैसे काम करता है

हाइपरस्टोर क्लस्टर में S3 ऑब्जेक्ट्स की प्लेसमेंट और प्रतिकृति एक सुसंगत कैशिंग योजना पर आधारित है जो 0 से 2 ¹²⁷ -1 तक रेंज में पूर्णांक टोकन स्पेस का उपयोग करती है। इंटेगर टोकन हाइपरस्टोर नोड्स को सौंपा गया है। प्रत्येक S3 ऑब्जेक्ट के लिए, एक हैश की गणना की जाती है क्योंकि इसे स्टोरेज में लोड किया जाता है। ऑब्जेक्ट नोड में संग्रहीत किया जाता है जिसे टोकन के निम्नतम मूल्य को असाइन किया गया था, जो ऑब्जेक्ट के हैश मान के बराबर या उससे अधिक है। ऑब्जेक्ट को नोड्स पर संग्रहीत करके प्रतिकृति भी लागू की जाती है, जिसे टोकन सौंपा गया है, जिनका न्यूनतम मूल्य है।

"क्लासिक" सुसंगत हैश-आधारित भंडारण में, एक टोकन एक भौतिक नोड को सौंपा गया है। क्लाउडियन हाइपरस्टोर सिस्टम 1.2 संस्करण में कैसेंड्रा में पेश किए गए "वर्चुअल नोड" (vNode) की कार्यक्षमता का उपयोग करता है और विस्तारित करता है - प्रत्येक भौतिक मेजबान (अधिकतम 256) को बड़ी संख्या में टोकन सौंपे जाते हैं। वास्तव में, संग्रहण क्लस्टर में प्रत्येक भौतिक होस्ट पर बड़ी संख्या में वर्चुअल नोड (टोकन) के साथ "वर्चुअल नोड्स" की एक बहुत बड़ी संख्या होती है।

हाइपरस्टोर सिस्टम प्रत्येक भौतिक होस्ट पर प्रत्येक डिस्क पर टोकन (वर्चुअल नोड्स) का एक अलग सेट प्रदान करता है। मेजबान पर प्रत्येक डिस्क वस्तुओं के प्रतिकृतियों के अपने सेट के लिए जिम्मेदार है। डिस्क विफलता केवल उन वस्तुओं की प्रतिकृतियों को प्रभावित करती है जो उस पर हैं। होस्ट पर अन्य ड्राइव अपने डेटा भंडारण की जिम्मेदारियों को संचालित करना और जारी रखना जारी रखेंगे।

हम एक उदाहरण देते हैं और 6 हाइपरस्टोर मेजबानों के क्लस्टर पर विचार करते हैं, जिनमें से प्रत्येक में 4 एस 3 स्टोरेज डिस्क हैं। मान लें कि प्रत्येक भौतिक मेजबान को 32 टोकन दिए गए हैं और 0 से 960 तक एक सरलीकृत टोकन स्थान है, और इस प्रणाली में 192 टोकन का मूल्य (32 टोकन के 6 होस्ट) 0, 5, 10, 15, 20, और इसी तरह 955 तक है।

नीचे दिए गए आरेख में पूरे क्लस्टर में टोकन का संभावित वितरण दिखाया गया है। प्रत्येक होस्ट के 32 टोकन 4 डिस्क (समान डिस्क प्रति 8 टोकन) पर समान रूप से वितरित किए जाते हैं, और टोकन खुद बेतरतीब ढंग से क्लस्टर में वितरित किए जाते हैं।



अब मान लें कि आपने हाइपरस्टोर को S3 ऑब्जेक्ट्स को दोहराने के लिए 3X में कॉन्फ़िगर किया है। मान लेते हैं कि S3 ऑब्जेक्ट सिस्टम में लोड है, और इसके नाम पर लागू किया गया हैश एल्गोरिथ्म हमें 322 हैश मान (इस सरलीकृत हैश स्पेस में) देता है। नीचे दिए गए आरेख से पता चलता है कि किसी वस्तु में तीन उदाहरण या प्रतिकृतियां कैसे संग्रहीत की जाएंगी:

• 322 के नाम के हैश मूल्य के साथ, ऑब्जेक्ट की पहली प्रतिकृति 325 टोकन पर संग्रहीत की जाती है, क्योंकि यह सबसे छोटा टोकन मान है जो ऑब्जेक्ट के हैश मान से अधिक या बराबर है। 325 टोकन (आरेख पर लाल रंग में हाइलाइट किए गए) हाइपरस्टोर 2 को दिए गए हैं: डिस्क 2। तदनुसार, ऑब्जेक्ट की पहली प्रतिकृति को वहां संग्रहीत किया जाता है।
  

• दूसरी प्रतिकृति को डिस्क पर संग्रहीत किया जाता है जिसे अगला टोकन (330, नारंगी में हाइलाइट किया गया) सौंपा गया है, जो कि हाइपरस्टोर 4: डिस्क 2 पर है।
  
• तीसरी प्रतिकृति डिस्क में सहेजी जाती है, जिसे हाइपरस्टोर 3 - डिस्क 3 पर 330 - 335 (पीला) के बाद अगला टोकन सौंपा जाता है।
  

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

एक क्लस्टर के अंदर डिवाइस चलाएं

याद रखें कि प्रत्येक होस्ट में 32 टोकन हैं, और प्रत्येक होस्ट के टोकन समान रूप से इसके डिस्क के बीच वितरित किए जाते हैं। चलो हाइपरस्टोर 2: डिस्क 2 (नीचे दिए गए आरेख में) पर करीब से नज़र डालें। हम देखते हैं कि टोकन 325, 425, 370 और इसी डिस्क को सौंपा गया है।

चूंकि क्लस्टर 3X प्रतिकृति के लिए कॉन्फ़िगर किया गया है, इसलिए निम्न को हाइपरस्टोर 2 पर संग्रहीत किया जाएगा: Disk2:

325 डिस्क टोकन के अनुसार:

• 320 (विशेष रूप से) से 325 (समावेशी) के हैश मान के साथ वस्तुओं की पहली प्रतिकृतियां;
• 315 (विशेष रूप से) से 320 (समावेशी) के हैश मान के साथ वस्तुओं की दूसरी प्रतिकृतियां;
• 310 (विशेष रूप से) से 315 (समावेशी) के हैश मूल्य के साथ वस्तुओं की तीसरी प्रतिकृतियां।

425 डिस्क टोकन के अनुसार:

• 420 (विशेष रूप से) से 425 (समावेशी) तक हैश मूल्य वाली वस्तुओं की पहली प्रतिकृतियां;
• 415 (विशेष रूप से) से 420 (समावेशी) के हैश मान के साथ वस्तुओं की दूसरी प्रतिकृतियां;
• 410 (विशेष रूप से) से 415 (समावेशी) तक हैश मान के साथ वस्तुओं की तीसरी प्रतिकृतियां।

और इसी तरह।

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



यदि डिस्क 2 डिस्क 1, 3, और 4 पर क्रैश हो जाता है, तो डेटा संग्रहीत किया जाना जारी रहेगा, और डिस्क 2 पर ऑब्जेक्ट क्लस्टर में संग्रहीत किए जाएंगे, क्योंकि अन्य मेजबानों को दोहराया गया है।

टिप्पणी: इसके परिणामस्वरूप, हाइपरस्टोर क्लस्टर में प्रतिकृतियों और / या वस्तुओं के टुकड़े का वितरण कैसेंड्रा के डिजाइन पर आधारित है, जिसे फ़ाइल भंडारण की जरूरतों के लिए विकसित किया गया था। , , , , «» . . . , : , , .

, HyperStore . - . . () , .
, , , «Multi-Data Center Deployments».

HyperStore -. DC1 DC2. - 3 . , , 32 (vNodes), 0 960. -, 192 — 32 6 . .

, S3 -.

, S3 942 2 -:

• vNode 945 ( ), DC2, hyperstore5:Disk3.
  
• vNode 950 ( ) DC2, hyperstore6:Disk4.
  
• vNode 955 DC2, , vNode .
  
• vNode 0 () — DC1, hyperstore2:Disk3. , (955) (0).
  
• vNode (5) DC2, , vNode .
  
• vNode 10 () — DC1, hyperstore3:Disk3.
  

: , , , , . , .

Cloudian. , , . , , , , .
S3 DataLine, , !