हाइपरकन्वर्ज्ड समाधान एयरोडिस्क वैर। आधार ARDFS फाइल सिस्टम है

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

आइए सिस्टम के निर्माण के इतिहास के साथ कहानी शुरू करें, ARDFS फ़ाइल सिस्टम के बारे में गहराई से जानें, जो vAIR का आधार है, और रूसी बाज़ार में इस समाधान की स्थिति के बारे में भी थोड़ी बात करते हैं।

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

क्या एयरोडिस्क भंडारण प्रणालियों के बारे में एक कहानी है? या हमने सबसे पहले हाइपरकन्वर्जेंस क्यों शुरू किया?

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

हमने कई ओपन सोर्स समाधान आज़माए और अंततः इस समस्या का समाधान किया, लेकिन समाधान बहुत जटिल था और इसे दोहराना मुश्किल था। इसके अलावा, यह समाधान "क्या यह काम करता है?" श्रेणी में था। मत छुओ! इसलिए, उस समस्या को हल करने के बाद, हमने अपने काम के परिणाम को पूर्ण उत्पाद में बदलने का विचार आगे विकसित नहीं किया।

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

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

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

पहली वीएआईआर अवधारणा

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

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

हमने फ़ाइल सिस्टम के नाम के बारे में ज़्यादा चिंता नहीं की और संक्षेप में इसे ARDFS नाम दिया (अंदाज़ा लगाएं कि इसका क्या मतलब है))

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

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

ARDFS फ़ाइल सिस्टम में गोता लगाना

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

भंडारण संरचना

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

वर्चुअल डिस्क (वर्चुअल मशीनों के लिए स्टोरेज ऑब्जेक्ट) ARDFS पूल के शीर्ष पर जोड़े जाते हैं, जो 4 मेगाबाइट आकार के वर्चुअल ब्लॉक से बनाए जाते हैं। वर्चुअल डिस्क सीधे डेटा स्टोर करती है। दोष सहनशीलता योजना वर्चुअल डिस्क स्तर पर भी सेट की गई है।

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

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

भंडारण दोष सहनशीलता योजनाएँ

vAIR में वर्चुअल डिस्क के लिए दो दोष सहनशीलता योजनाएँ हो सकती हैं:

1) प्रतिकृति कारक या केवल प्रतिकृति - दोष सहन करने की यह विधि एक छड़ी और रस्सी जितनी सरल है। सिंक्रोनस प्रतिकृति 2 (प्रति क्लस्टर 2 प्रतियां) या 3 (क्रमशः 3 प्रतियां) के कारक के साथ नोड्स के बीच की जाती है। RF-2 एक वर्चुअल डिस्क को क्लस्टर में एक नोड की विफलता का सामना करने की अनुमति देता है, लेकिन उपयोगी वॉल्यूम का आधा हिस्सा "खा लेता है", और RF-3 क्लस्टर में 2 नोड्स की विफलता का सामना करेगा, लेकिन 2/3 को सुरक्षित रखता है इसकी आवश्यकताओं के लिए उपयोगी मात्रा। यह योजना RAID-1 के समान है, अर्थात, RF-2 में कॉन्फ़िगर की गई वर्चुअल डिस्क क्लस्टर में किसी एक नोड की विफलता के लिए प्रतिरोधी है। इस मामले में, डेटा के साथ सब कुछ ठीक हो जाएगा और यहां तक ​​कि I/O भी नहीं रुकेगा। जब गिरा हुआ नोड सेवा में वापस आएगा, तो स्वचालित डेटा पुनर्प्राप्ति/सिंक्रनाइज़ेशन शुरू हो जाएगा।

सामान्य मोड में और विफलता की स्थिति में आरएफ-2 और आरएफ-3 डेटा के वितरण के उदाहरण नीचे दिए गए हैं।

हमारे पास 8MB अद्वितीय (उपयोगी) डेटा की क्षमता वाली एक वर्चुअल मशीन है, जो 4 vAIR नोड्स पर चलती है। यह स्पष्ट है कि वास्तव में इतनी कम मात्रा होने की संभावना नहीं है, लेकिन एक ऐसी योजना के लिए जो एआरडीएफएस ऑपरेशन के तर्क को दर्शाती है, यह उदाहरण सबसे अधिक समझने योग्य है। एबी 4एमबी वर्चुअल ब्लॉक हैं जिनमें अद्वितीय वर्चुअल मशीन डेटा होता है। RF-2 इन ब्लॉकों की क्रमशः A1+A2 और B1+B2 दो प्रतियां बनाता है। इन ब्लॉकों को एक ही नोड पर समान डेटा के प्रतिच्छेदन से बचने के लिए सभी नोड्स में "बिछाया" जाता है, अर्थात, कॉपी A1 कॉपी A2 के समान नोड पर स्थित नहीं होगी। बी1 और बी2 के साथ भी ऐसा ही।

यदि कोई एक नोड विफल हो जाता है (उदाहरण के लिए, नोड नंबर 3, जिसमें बी1 की एक प्रति है), तो यह प्रतिलिपि स्वचालित रूप से उस नोड पर सक्रिय हो जाती है जहां इसकी प्रतिलिपि की कोई प्रतिलिपि नहीं है (अर्थात, बी2 की एक प्रति)।

इस प्रकार, वर्चुअल डिस्क (और तदनुसार वीएम) आरएफ-2 योजना में एक नोड की विफलता से आसानी से बच सकती है।

प्रतिकृति योजना, सरल और विश्वसनीय होते हुए भी, RAID1 जैसी ही समस्या से ग्रस्त है - पर्याप्त उपयोग योग्य स्थान नहीं।

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

एन्कोडिंग करते समय, EC प्रक्रिया एक वर्चुअल ब्लॉक (डिफ़ॉल्ट रूप से 4MB) को EC योजना के आधार पर कई छोटे "डेटा खंडों" में विभाजित करती है (उदाहरण के लिए, 2+1 योजना प्रत्येक 4MB ब्लॉक को 2 2MB खंडों में विभाजित करती है)। इसके बाद, यह प्रक्रिया "डेटा खंड" के लिए "समता खंड" उत्पन्न करती है जो पहले विभाजित भागों में से किसी एक से बड़े नहीं होते हैं। डिकोडिंग करते समय, ईसी पूरे क्लस्टर में "जीवित" डेटा को पढ़कर लापता हिस्सों को उत्पन्न करता है।

उदाहरण के लिए, 2 क्लस्टर नोड्स पर कार्यान्वित 1 + 4 EC योजना वाली एक वर्चुअल डिस्क, RF-2 की तरह ही क्लस्टर में एक नोड की विफलता को आसानी से झेल लेगी। इस मामले में, ओवरहेड लागत कम होगी, विशेष रूप से, आरएफ-2 के लिए उपयोगी क्षमता गुणांक 2 है, और ईसी 2+1 के लिए यह 1,5 होगा।

इसे और अधिक सरल रूप से वर्णित करने के लिए, सार यह है कि वर्चुअल ब्लॉक को 2-8 (2 से 8 तक क्यों, नीचे देखें) "टुकड़ों" में विभाजित किया गया है, और इन टुकड़ों के लिए समान मात्रा की समता के "टुकड़ों" की गणना की जाती है।

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

नीचे एक उदाहरण दिया गया है, समान 8 एमबी वर्चुअल मशीन और 4 नोड्स के साथ, लेकिन ईसी 2+1 योजना के साथ।

ब्लॉक ए और बी को 2 एमबी के दो टुकड़ों में विभाजित किया गया है (दो क्योंकि 2+1), यानी, ए1+ए2 और बी1+बी2। प्रतिकृति के विपरीत, A1 A2 की प्रतिलिपि नहीं है, यह एक वर्चुअल ब्लॉक A है, जो दो भागों में विभाजित है, ब्लॉक B के साथ भी ऐसा ही है। कुल मिलाकर, हमें 4MB के दो सेट मिलते हैं, जिनमें से प्रत्येक में दो दो-MB टुकड़े होते हैं। इसके बाद, इनमें से प्रत्येक सेट के लिए, समता की गणना एक टुकड़े (यानी 2 एमबी) से अधिक की मात्रा के साथ की जाती है, हमें समता के अतिरिक्त + 2 टुकड़े (ए-पी और बी-पी) मिलते हैं। कुल मिलाकर हमारे पास 4×2 डेटा + 2×2 समता है।

इसके बाद, टुकड़ों को नोड्स के बीच "बिछाया" जाता है ताकि डेटा उनकी समता के साथ न कटे। वे। A1 और A2 A-P के समान नोड पर नहीं होंगे।

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

मुझे यकीन है कि पाठक का एक प्रश्न है:

"आपने जो कुछ भी वर्णित किया है वह लंबे समय से प्रतिस्पर्धियों और ओपन सोर्स समाधानों दोनों द्वारा लागू किया गया है, एआरडीएफएस में ईसी के आपके कार्यान्वयन के बीच क्या अंतर है?"

और फिर ARDFS की दिलचस्प विशेषताएं होंगी।

लचीलेपन पर ध्यान देते हुए कोडिंग मिटाएँ

प्रारंभ में, हमने एक काफी लचीली ईसी एक्स+वाई योजना प्रदान की, जहां एक्स 2 से 8 तक की संख्या के बराबर है, और वाई 1 से 8 तक की संख्या के बराबर है, लेकिन हमेशा एक्स से कम या उसके बराबर है। लचीलेपन के लिए. डेटा टुकड़ों (एक्स) की संख्या में वृद्धि जिसमें वर्चुअल ब्लॉक विभाजित है, ओवरहेड लागत को कम करने की अनुमति देता है, यानी, उपयोग करने योग्य स्थान में वृद्धि करता है।
पैरिटी चंक्स (Y) की संख्या बढ़ने से वर्चुअल डिस्क की विश्वसनीयता बढ़ जाती है। Y मान जितना बड़ा होगा, क्लस्टर में उतने ही अधिक नोड विफल हो सकते हैं। बेशक, समता मात्रा बढ़ाने से प्रयोग करने योग्य क्षमता की मात्रा कम हो जाती है, लेकिन यह विश्वसनीयता के लिए भुगतान की जाने वाली कीमत है।

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

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

नीचे कई (सभी संभव नहीं) आरएफ और ईसी योजनाओं की तुलना करने वाली एक तालिका है।

तालिका से पता चलता है कि यहां तक ​​कि सबसे "टेरी" संयोजन EC 8+7, जो एक क्लस्टर में एक साथ 7 नोड्स तक के नुकसान की अनुमति देता है, मानक प्रतिकृति की तुलना में कम उपयोग करने योग्य स्थान (1,875 बनाम 2) को "खाता है", और 7 गुना बेहतर सुरक्षा करता है। , जो इस सुरक्षा तंत्र को, हालांकि अधिक जटिल, उन स्थितियों में अधिक आकर्षक बनाता है जहां सीमित डिस्क स्थान की स्थितियों में अधिकतम विश्वसनीयता सुनिश्चित करना आवश्यक है। साथ ही, आपको यह समझने की आवश्यकता है कि एक्स या वाई के लिए प्रत्येक "प्लस" एक अतिरिक्त प्रदर्शन ओवरहेड होगा, इसलिए विश्वसनीयता, बचत और प्रदर्शन के बीच त्रिकोण में आपको बहुत सावधानी से चयन करने की आवश्यकता है। इस कारण से, हम कोडिंग साइज़िंग को मिटाने के लिए एक अलग लेख समर्पित करेंगे।

फ़ाइल सिस्टम की विश्वसनीयता और स्वायत्तता

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

बाहरी DBMS का उपयोग करके FS मेटाडेटा को सिंक्रनाइज़ करना, निश्चित रूप से, एक कार्यशील समाधान है, लेकिन फिर ARDFS पर संग्रहीत डेटा की स्थिरता बाहरी DBMS और उसके व्यवहार (और, स्पष्ट रूप से कहें तो, यह एक सनकी महिला है) पर निर्भर करेगी, जो कि हमारी राय ख़राब है. क्यों? यदि एफएस मेटाडेटा क्षतिग्रस्त हो जाता है, तो एफएस डेटा को भी "अलविदा" कहा जा सकता है, इसलिए हमने अधिक जटिल लेकिन विश्वसनीय रास्ता अपनाने का फैसला किया।

हमने ARDFS के लिए मेटाडेटा सिंक्रोनाइज़ेशन सबसिस्टम स्वयं बनाया है, और यह आसन्न सबसिस्टम से पूरी तरह स्वतंत्र है। वे। कोई अन्य सबसिस्टम ARDFS डेटा को दूषित नहीं कर सकता। हमारी राय में, यह सबसे विश्वसनीय और सही तरीका है, लेकिन समय ही बताएगा कि वास्तव में ऐसा है या नहीं। इसके अलावा, इस दृष्टिकोण का एक अतिरिक्त लाभ भी है। ARDFS का उपयोग vAIR से स्वतंत्र रूप से, स्ट्रेच्ड स्टोरेज के रूप में किया जा सकता है, जिसे हम निश्चित रूप से भविष्य के उत्पादों में उपयोग करेंगे।

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

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

इस चमत्कार की जरूरत किसे है?

एक ओर, हम कह सकते हैं कि बाजार में पहले से ही ऐसे खिलाड़ी हैं जिनके पास हाइपरकन्वर्जेंस के क्षेत्र में गंभीर समाधान हैं, और हम वास्तव में यहीं जा रहे हैं। ऐसा लगता है कि यह कथन सत्य है, लेकिन...

दूसरी ओर, जब हम बाहर जाते हैं और ग्राहकों से संवाद करते हैं, तो हम और हमारे साझेदार देखते हैं कि ऐसा बिल्कुल नहीं है। हाइपरकन्वर्जेन्स के लिए कई कार्य हैं, कुछ स्थानों पर लोगों को पता ही नहीं था कि ऐसे समाधान मौजूद हैं, दूसरों में यह महंगा लग रहा था, दूसरों में वैकल्पिक समाधानों के असफल परीक्षण थे, और दूसरों में वे प्रतिबंधों के कारण बिल्कुल भी खरीदने पर रोक लगाते थे। सामान्य तौर पर, खेत बिना जुताई वाला निकला, इसलिए हम कुंवारी मिट्टी उठाने गए)))।

भंडारण प्रणाली जीसीएस से बेहतर कब है?

जैसा कि हम बाजार के साथ काम करते हैं, हमसे अक्सर पूछा जाता है कि स्टोरेज सिस्टम के साथ क्लासिक स्कीम का उपयोग करना कब बेहतर है, और हाइपरकन्वर्जेंट का उपयोग कब करना है? जीसीएस का उत्पादन करने वाली कई कंपनियां (विशेष रूप से जिनके पोर्टफोलियो में स्टोरेज सिस्टम नहीं हैं) कहती हैं: "स्टोरेज सिस्टम अप्रचलित हो रहे हैं, केवल हाइपरकन्वर्ड हो गए हैं!" यह एक साहसिक बयान है, लेकिन यह पूरी तरह से वास्तविकता को प्रतिबिंबित नहीं करता है।

सच में, भंडारण बाजार वास्तव में हाइपरकन्वर्जेंस और इसी तरह के समाधानों की ओर बढ़ रहा है, लेकिन हमेशा एक "लेकिन" होता है।

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

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

तीसरा, प्रति लेखन 2 मिलीसेकंड की अतिरिक्त छोटी देरी (निश्चित रूप से स्थानीय कैश को छोड़कर) में एक विशुद्ध रूप से तकनीकी सीमा है, जो वितरित भंडारण की लागत है।

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

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

और हाइपरकन्वर्ज्ड समाधान भंडारण प्रणालियों से बेहतर कहां काम करेंगे?

उपरोक्त बिंदुओं के आधार पर, तीन स्पष्ट निष्कर्ष निकाले जा सकते हैं:

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

ये समाधान क्या हैं?

1. सभी मानक अवसंरचना सेवाएँ (निर्देशिका सेवा, मेल, ईडीएमएस, फ़ाइल सर्वर, छोटे या मध्यम ईआरपी और बीआई सिस्टम, आदि)। हम इसे "सामान्य कंप्यूटिंग" कहते हैं।
2. क्लाउड प्रदाताओं का बुनियादी ढांचा, जहां ग्राहकों के लिए बड़ी संख्या में वर्चुअल मशीनों को जल्दी और मानकीकृत क्षैतिज रूप से विस्तारित करना और आसानी से "कट" करना आवश्यक है।
3. वर्चुअल डेस्कटॉप इंफ्रास्ट्रक्चर (वीडीआई), जहां कई छोटी उपयोगकर्ता वर्चुअल मशीनें चलती हैं और एक समान क्लस्टर के भीतर चुपचाप "फ्लोट" करती हैं।
4. शाखा नेटवर्क, जहां प्रत्येक शाखा को 15-20 वर्चुअल मशीनों के मानक, दोष-सहिष्णु, लेकिन सस्ते बुनियादी ढांचे की आवश्यकता होती है।
5. कोई भी वितरित कंप्यूटिंग (उदाहरण के लिए बड़ी डेटा सेवाएँ)। जहां भार "गहराई में" नहीं, बल्कि "चौड़ाई में" जाता है।
6. परीक्षण वातावरण जहां अतिरिक्त छोटी देरी स्वीकार्य है, लेकिन बजट प्रतिबंध हैं, क्योंकि ये परीक्षण हैं।

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

तो ...

यह लेखों की एक बड़ी श्रृंखला का पहला भाग पूरा करता है; अगले लेख में हम समाधान की वास्तुकला और उपयोग किए गए घटकों के बारे में बात करेंगे।

हम प्रश्नों, सुझावों और रचनात्मक विवादों का स्वागत करते हैं।

स्रोत: www.habr.com