इसे स्वयं बनाएं: हमने छोटे होस्टरों के लिए अमेज़ॅन-शैली का भंडारण कैसे किया

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

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

परिचय

मैक पर विंडोज चलाने के लिए समाधान के एक डेवलपर के रूप में हबल पाठकों के विशाल बहुमत समानताएं के बारे में जानते हैं। दर्शकों का एक और हिस्सा हमारे कंटेनर वर्चुअलाइजेशन उत्पादों के बारे में जानता है - भुगतान समानताएं Virtuozzo कंटेनर और समानताएं सर्वर नंगे धातु , साथ ही साथ ओपन-सोर्स ओपनवीजेड । कंटेनरों में आने वाले विचारों का उपयोग क्लाउड और यैंडेक्स क्लाउड प्रदाताओं द्वारा एक डिग्री या किसी अन्य के लिए किया जाता है। लेकिन सामान्य तौर पर, समानताएं का मजबूत बिंदु छोटे और / या तेजी से बढ़ते सेवा प्रदाताओं के लिए सॉफ्टवेयर है। कंटेनर होस्टर्स को एक सर्वर पर ऑपरेटिंग सिस्टम की कई प्रतियां चलाने की अनुमति देते हैं। यह हाइपरविजर की तुलना में आभासी वातावरण का 3-4 गुना अधिक घनत्व देता है। इसके अतिरिक्त, कंटेनरीकृत वर्चुअलाइजेशन भौतिक मशीनों के बीच आभासी वातावरण के प्रवास की अनुमति देता है, और यह मेजबान या क्लाउड प्रदाता द्वारा किसी का ध्यान नहीं जाता है।

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

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

पीसीएस आर्किटेक्चर: पहला स्ट्रोक

हमने इस तथ्य से शुरू किया कि वितरित भंडारण की हमारी व्याख्या यथासंभव सरल होनी चाहिए। और हम एक ऐसे कार्य से आगे बढ़े जो सरल भी था: सिस्टम को आभासी मशीनों और कंटेनरों के कामकाज को सुनिश्चित करना चाहिए।

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

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

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

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

इसके अलावा, हम चाहते थे कि हमारी भंडारण प्रणाली में कई शानदार विशेषताएं हों:

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

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

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

यह निर्णय लिया गया था: हम पूरे डेटा ऐरे को एक निश्चित आकार (हमारे मामले में 64-128 एमबी) के टुकड़ों में विभाजित करते हैं, हम उन्हें दी गई प्रतियों में दोहराएंगे और उन्हें पूरे क्लस्टर में वितरित करेंगे।

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

क्लोन हमला

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

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

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

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

संस्करणों की निगरानी मेटाडेटा सर्वर (MDS) द्वारा की जाएगी। उसी समय, सफल रिकॉर्डिंग पर संस्करण को अपडेट करना आवश्यक नहीं है, यह केवल तभी आवश्यक है जब किसी एक सर्वर ने किसी कारण से रिकॉर्ड नहीं किया और हम इसे बाहर कर दें। इसलिए, सामान्य मोड में, डेटा उच्चतम संभव गति से दर्ज किया जाता है।

दरअसल, समाधान वास्तुकला इन सभी निष्कर्षों से बना है। इसमें तीन घटक होते हैं:

• ग्राहक जो नियमित ईथरनेट के माध्यम से भंडारण के साथ संवाद करते हैं।
• एमडीएस, जो इस बारे में जानकारी संग्रहीत करता है कि कौन सी फाइलें झूठ हैं और टुकड़े के वर्तमान संस्करण कहां स्थित हैं।
• सर्वरों के स्थानीय हार्ड ड्राइव पर वितरित किए गए टुकड़े स्वयं।

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

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

अधिक संकेत

यहां कुछ ट्रिक्स दी गई हैं जिन्हें हमने अपने वितरित क्लाउड स्टोरेज को बनाने की प्रक्रिया में लागू किया है।

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

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

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

परिणाम और निष्कर्ष

नतीजतन, हमें एक डेटा स्टोरेज सिस्टम मिला, जो संपत्तियों द्वारा होस्टरों को उनके बुनियादी ढांचे पर तैनात करने के लिए उपयुक्त है, क्योंकि इसके लिए निम्नलिखित विकल्प हैं:

• आभासी मशीनों और कंटेनरों को सीधे स्टोरेज से चलाने की क्षमता, जैसा कि हमारी प्रणाली मजबूत स्थिरता शब्दार्थ प्रदान करती है।
• कई सर्वरों और ड्राइव पर पेटाबाइट वॉल्यूम को स्केल करने की क्षमता।
• डेटा चेकसम और एसएसडी कैशिंग के लिए समर्थन।

प्रदर्शन के बारे में कुछ शब्द। यह entreeza भंडारण सुविधाओं के प्रदर्शन के साथ तुलनीय निकला। हमने इंटेल से 4x HDD के साथ 14 सर्वरों का एक क्लस्टर लिया और साधारण SATA हार्ड ड्राइव पर बहुत छोटी (4 KB) फ़ाइलों के साथ प्रति सेकंड 13 हजार यादृच्छिक I / O संचालन प्राप्त किया। यह काफी है। SSD कैशिंग ने परिमाण के लगभग दो आदेशों द्वारा एक ही भंडारण के कार्य को तेज किया - हमने प्रति सेकंड 1 मिलियन i / o संचालन का संपर्क किया। एक टेराबाइट डेटा की रिकवरी की गति 10 मिनट थी, और डिस्क की संख्या जितनी अधिक होगी, उतनी ही तेजी से रिकवरी होगी।

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

***

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