हाइपरकन्भर्ज्ड समाधान AERODISK vAIR। आधार ARDFS फाइल प्रणाली हो

नमस्ते, Habr पाठकहरू। यस लेखको साथ हामीले एउटा शृङ्खला खोल्छौं जुन हामीले विकास गरेका हाइपरकन्भर्ज्ड प्रणाली AERODISK vAIR बारे कुरा गर्नेछौं। सुरुमा, हामी पहिलो लेखमा सबै कुराको बारेमा सबै कुरा बताउन चाहन्थ्यौं, तर प्रणाली धेरै जटिल छ, त्यसैले हामी भागहरूमा हात्ती खान्छौं।

प्रणालीको सृष्टिको इतिहासको साथ कथा सुरु गरौं, ARDFS फाइल प्रणाली, जुन VAIR को आधार हो, र रूसी बजारमा यस समाधानको स्थितिको बारेमा पनि थोरै कुरा गरौं।

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

के Aerodisk भण्डारण प्रणाली को बारे मा एक कहानी छ? वा हामीले किन पहिलो स्थानमा हाइपरकन्भरजेन्स गर्न थाल्यौं?

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

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

त्यो घटना पछि, हामी यो विचारबाट टाढा गयौं, तर हामी अझै पनि यो समस्या पूर्ण रूपमा समाधान गर्न योग्य छ भन्ने भावना थियो, र यस्तो समाधान को लाभ स्पष्ट भन्दा बढी थियो। पछि, विदेशी कम्पनीहरु को रिलीज HCI उत्पादनहरु मात्र यो भावना पुष्टि।

त्यसकारण, 2016 को मध्यमा, हामी पूर्ण उत्पादन सिर्जना गर्ने भागको रूपमा यो कार्यमा फर्कियौं। त्यतिबेला हाम्रो लगानीकर्तासँग कुनै सम्बन्ध थिएन, त्यसैले हामीले आफ्नै ठूलो पैसाको लागि विकास स्ट्यान्ड किन्नुपर्यो। Avito मा प्रयोग गरिएका सर्भरहरू र स्विचहरू सङ्कलन गरेपछि, हामी व्यवसायमा लाग्यौं।

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

पहिलो vAIR अवधारणा

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

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

हामीले फाइल प्रणालीको नामको साथ धेरै चिन्ता गरेनौं र संक्षिप्त रूपमा यसलाई ARDFS भनिन्छ (यसको अर्थ के हो अनुमान गर्नुहोस्))

यो प्रोटोटाइप राम्रो देखिन्थ्यो (दृश्य रूपमा होइन, अवश्य पनि, त्यहाँ कुनै भिजुअल डिजाइन थिएन) र प्रदर्शन र स्केलिंगको सन्दर्भमा राम्रो परिणामहरू देखायो। पहिलो वास्तविक नतिजा पछि, हामीले यो परियोजनालाई गतिमा सेट गर्यौं, पूर्ण विकास वातावरण र एक छुट्टै टोली संगठित गर्‍यौं जसले केवल vAIR सँग काम गर्यो।

त्यस समय सम्म, समाधानको सामान्य वास्तुकला परिपक्व भएको थियो, जुन अझै ठूलो परिवर्तन भएको छैन।

ARDFS फाइल प्रणालीमा डाइभिङ

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

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

क्लस्टरको सबै नोडहरू भित्र, ARDFS ले सबै उपलब्ध डिस्क स्पेसबाट तार्किक पूल व्यवस्थित गर्दछ। यो बुझ्न महत्त्वपूर्ण छ कि पूल अझै डाटा वा ढाँचा गरिएको ठाउँ होइन, तर केवल मार्कअप, अर्थात्। क्लस्टरमा थपिएको VAIR भएको कुनै पनि नोडहरू, स्वचालित रूपमा साझा 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 रोकिने छैन। जब पतित नोड सेवामा फर्कन्छ, स्वचालित डेटा रिकभरी/सिंक्रोनाइजेसन सुरु हुनेछ।

तल सामान्य मोडमा र असफल स्थितिमा RF-2 र RF-3 डेटाको वितरणका उदाहरणहरू छन्।

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

यदि कुनै नोडहरू असफल भएमा (उदाहरणका लागि, नोड नम्बर 3, जसमा B1 को प्रतिलिपि समावेश छ), यो प्रतिलिपि स्वचालित रूपमा नोडमा सक्रिय हुन्छ जहाँ यसको प्रतिलिपिको प्रतिलिपि छैन (अर्थात, B2 को प्रतिलिपि)।

यसरी, भर्चुअल डिस्क (र VM, तदनुसार) सजिलै संग RF-2 योजना मा एक नोड को विफलता बाँच्न सक्छ।

प्रतिकृति योजना, सरल र भरपर्दो हुँदा, RAID1 जस्तै समस्याबाट ग्रस्त छ - पर्याप्त प्रयोगयोग्य ठाउँ छैन।

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

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

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

यसलाई थप सरल रूपमा वर्णन गर्नको लागि, सार यो हो कि भर्चुअल ब्लक 2-8 मा विभाजित छ (किन 2 देखि 8 सम्म, तल हेर्नुहोस्) "टुक्राहरू", र यी टुक्राहरूको लागि समान मात्राको समानताको "टुक्राहरू" गणना गरिन्छ।

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

तल एउटा उदाहरण छ, उही 8 MB भर्चुअल मेसिन र 4 नोडहरू, तर EC 2+1 योजनाको साथ।

ब्लक A र B लाई 2 MB प्रत्येक दुई टुक्रामा विभाजन गरिएको छ (दुई 2+1 को कारण), त्यो हो, A1+A2 र B1+B2। प्रतिकृतिको विपरीत, A1 A2 को प्रतिलिपि होइन, यो एक भर्चुअल ब्लक A हो, दुई भागमा विभाजित, ब्लक B सँग समान। कुलमा, हामीले 4MB को दुई सेटहरू पाउँछौं, जसमध्ये प्रत्येकमा दुई दुई-एमबी टुक्राहरू छन्। त्यसपछि, यी प्रत्येक सेटहरूको लागि, समानता एक टुक्रा (अर्थात् 2 MB) भन्दा बढीको भोल्युमको साथ गणना गरिन्छ, हामी समानताको अतिरिक्त + 2 टुक्राहरू (AP र BP) प्राप्त गर्छौं। कुलमा हामीसँग 4×2 डाटा + 2×2 समानता छ।

अर्को, टुक्राहरू नोडहरू बीचमा "राखिएका" छन् ताकि डेटा तिनीहरूको समानतासँग काट्दैन। ती। A1 र A2 AP को रूपमा एउटै नोडमा हुनेछैन।

एउटा नोडको विफलताको अवस्थामा (उदाहरणका लागि, तेस्रो पनि), खसेको ब्लक B1 नोड नम्बर 2 मा भण्डारण गरिएको BP समानताबाट स्वचालित रूपमा पुनर्स्थापित हुनेछ, र त्यहाँ नोडमा सक्रिय हुनेछ। कुनै B-समानता छैन, अर्थात् बीपी को टुक्रा। यस उदाहरणमा, यो नोड नम्बर 1 हो

म पक्का छु कि पाठकको प्रश्न छ:

"तपाईंले वर्णन गर्नुभएको सबै कुरा प्रतियोगीहरू र खुला स्रोत समाधानहरूमा लामो समयदेखि लागू गरिएको छ, ARDFS मा EC को तपाईंको कार्यान्वयनमा के भिन्नता छ?"

र त्यसपछि त्यहाँ ARDFS को रोचक सुविधाहरू हुनेछ।

लचिलोपनमा ध्यान केन्द्रित गरी इरेजर कोडिङ

प्रारम्भमा, हामीले एकदमै लचिलो EC X+Y योजना प्रदान गरेका छौं, जहाँ X 2 देखि 8 सम्मको संख्याको बराबर छ, र Y 1 देखि 8 सम्मको संख्याको बराबर छ, तर सधैं X भन्दा कम वा बराबर छ। यो योजना प्रदान गरिएको छ। लचिलोपनको लागि। भर्चुअल ब्लक विभाजित भएको डाटा टुक्रा (X) को संख्या बढाउँदा ओभरहेड लागतहरू घटाउन अनुमति दिन्छ, अर्थात्, प्रयोगयोग्य ठाउँ बढाउन।
समानता खण्ड (Y) को संख्या बढाउँदा भर्चुअल डिस्कको विश्वसनीयता बढ्छ। Y मान जति ठूलो हुन्छ, क्लस्टरमा थप नोडहरू असफल हुन सक्छन्। निस्सन्देह, समानता भोल्युम बढाउँदा प्रयोगयोग्य क्षमताको मात्रा कम हुन्छ, तर यो विश्वसनीयताको लागि तिर्ने मूल्य हो।

EC सर्किटहरूमा प्रदर्शनको निर्भरता लगभग प्रत्यक्ष छ: अधिक "टुक्राहरू", कम प्रदर्शन यहाँ, निस्सन्देह, एक सन्तुलित दृश्य आवश्यक छ।

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

तल धेरै (सबै सम्भव छैन) RF र EC योजनाहरूको तुलना गर्ने तालिका छ।

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

फाइल प्रणालीको विश्वसनीयता र स्वायत्तता

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

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

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

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

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

यो चमत्कार कसलाई चाहिन्छ?

एकातिर, हामी भन्न सक्छौं कि बजारमा पहिले नै खेलाडीहरू छन् जससँग हाइपरकन्भरजेन्सको क्षेत्रमा गम्भीर समाधानहरू छन्, र यो हामी वास्तवमा जाँदैछौं। यस्तो देखिन्छ कि यो कथन सत्य हो, तर ...

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

भण्डारण प्रणाली GCS भन्दा राम्रो कहिले हुन्छ?

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

वास्तवमा, भण्डारण बजार वास्तवमा हाइपरकन्भर्जेन्स र समान समाधानहरू तिर गइरहेको छ, तर त्यहाँ सधैं "तर" हुन्छ।

पहिलो, डाटा सेन्टरहरू र IT पूर्वाधारहरू भण्डारण प्रणालीको साथ शास्त्रीय योजना अनुसार निर्माण गर्न सकिँदैन, त्यसैले त्यस्ता पूर्वाधारहरूको आधुनिकीकरण र समापन अझै 5-7 वर्षको लागि विरासत हो।

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

तेस्रो, त्यहाँ प्रति लेखन २ मिलिसेकेन्डको अतिरिक्त सानो ढिलाइमा विशुद्ध प्राविधिक सीमा छ (स्थानीय क्यास बाहेक), जुन वितरित भण्डारणको लागत हो।

ठिक छ, डिस्क सबसिस्टमको ठाडो स्केलिंग मन पराउने ठूला भौतिक सर्भरहरूको प्रयोगको बारेमा नबिर्सनुहोस्।

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

र कहाँ हाइपरकन्भर्जेड समाधानहरूले भण्डारण प्रणालीहरू भन्दा राम्रो काम गर्नेछ?

माथिका बिन्दुहरूमा आधारित, तीन स्पष्ट निष्कर्ष निकाल्न सकिन्छ:

1. जहाँ रेकर्डिङको लागि अतिरिक्त २ मिलिसेकेन्ड विलम्बता, जुन कुनै पनि उत्पादनमा लगातार हुन्छ (अब हामी सिंथेटिक्सको बारेमा कुरा गर्दैनौं, सिन्थेटिक्समा नानोसेकेन्ड देखाउन सकिन्छ), अत्यावश्यक छन्, हाइपरकन्भर्जेन्ट उपयुक्त छ।
2. जहाँ ठूला भौतिक सर्भरहरूबाट लोडलाई धेरै साना भर्चुअलहरूमा परिणत गर्न सकिन्छ र नोडहरू बीचमा वितरण गर्न सकिन्छ, त्यहाँ हाइपरकन्भरजेन्सले पनि राम्रोसँग काम गर्नेछ।
3. जहाँ तेर्सो मापन ठाडो मापन भन्दा उच्च प्राथमिकता हो, GCS ले त्यहाँ पनि राम्रो गर्नेछ।

यी समाधानहरू के हुन्?

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

हाल, यी कार्यहरूको लागि हामीले AERODISK vAIR बनाएका छौं र तिनीहरूमा हामी केन्द्रित छौं (अहिलेसम्म सफलतापूर्वक)। सायद यो चाँडै परिवर्तन हुनेछ, किनभने ... संसार स्थिर छैन।

तर…

यसले लेखहरूको ठूलो श्रृंखलाको पहिलो भाग पूरा गर्दछ; अर्को लेखमा हामी समाधानको वास्तुकला र प्रयोग गरिएका घटकहरूको बारेमा कुरा गर्नेछौं।

हामी प्रश्न, सुझाव र रचनात्मक विवाद स्वागत गर्दछौं।

स्रोत: www.habr.com