हायपरकन्व्हर्ज्ड सोल्यूशन AERODISK vAIR. आधार ARDFS फाइल सिस्टम आहे

नमस्कार वाचकहो. या लेखाद्वारे आम्ही एक मालिका उघडतो जी आम्ही विकसित केलेल्या हायपरकन्व्हर्ज्ड सिस्टम AERODISK vAIR बद्दल बोलेल. सुरुवातीला, आम्हाला पहिल्या लेखात प्रत्येक गोष्टीबद्दल सर्व काही सांगायचे होते, परंतु प्रणाली खूपच गुंतागुंतीची आहे, म्हणून आम्ही हत्ती भागांमध्ये खाऊ.

चला सिस्टमच्या निर्मितीच्या इतिहासासह कथेची सुरुवात करूया, एआरडीएफएस फाइल सिस्टमचा शोध घेऊया, जी व्हीएआयआरचा आधार आहे आणि रशियन मार्केटमध्ये या सोल्यूशनच्या स्थितीबद्दल थोडेसे बोलूया.

भविष्यातील लेखांमध्ये आम्ही विविध आर्किटेक्चरल घटकांबद्दल (क्लस्टर, हायपरवाइजर, लोड बॅलेंसर, मॉनिटरिंग सिस्टम इ.), कॉन्फिगरेशन प्रक्रिया, परवाना समस्या वाढवणे, स्वतंत्रपणे क्रॅश चाचण्या दाखवणे आणि अर्थातच, लोड चाचणीबद्दल अधिक तपशीलवार चर्चा करू. आकारमान आम्ही VAIR च्या समुदाय आवृत्तीसाठी एक स्वतंत्र लेख देखील समर्पित करू.

एरोडिस्क ही स्टोरेज सिस्टमची कथा आहे का? किंवा आपण प्रथम स्थानावर हायपरकन्व्हर्जन्स का करू लागलो?

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

आम्ही अनेक ओपन सोर्स सोल्यूशन्स वापरून पाहिले आणि शेवटी या समस्येचे निराकरण केले, परंतु उपाय खूप जटिल आणि पुनरावृत्ती करणे कठीण होते. याशिवाय, हा उपाय “हे कार्य करते का? स्पर्श करू नका! म्हणून, त्या समस्येचे निराकरण केल्यावर, आम्ही आमच्या कार्याच्या परिणामाचे पूर्ण उत्पादनात रूपांतर करण्याची कल्पना पुढे विकसित केली नाही.

त्या घटनेनंतर, आम्ही या कल्पनेपासून दूर गेलो, परंतु आम्हाला अजूनही अशी भावना होती की ही समस्या पूर्णपणे सोडवण्यायोग्य आहे आणि अशा उपायाचे फायदे स्पष्ट आहेत. त्यानंतर, परदेशी कंपन्यांच्या रिलीझ केलेल्या एचसीआय उत्पादनांनी केवळ या भावनेची पुष्टी केली.

म्हणून, 2016 च्या मध्यात, आम्ही पूर्ण उत्पादन तयार करण्याचा भाग म्हणून या कार्याकडे परत आलो. त्या वेळी आमचे गुंतवणूकदारांशी कोणतेही संबंध नव्हते, म्हणून आम्हाला आमच्या स्वत: च्या फार मोठ्या पैशासाठी विकास स्टँड विकत घ्यावा लागला. अविटो वर वापरलेले सर्व्हर आणि स्विचेस गोळा केल्यावर, आम्ही व्यवसायात उतरलो.

मुख्य सुरुवातीचे कार्य म्हणजे आमची स्वतःची, जरी साधी असली तरी, आमची स्वतःची फाइल सिस्टम तयार करणे हे होते, जे इथरनेटद्वारे इंटरकनेक्टद्वारे जोडलेल्या क्लस्टर नोड्सच्या nव्या क्रमांकावर व्हर्च्युअल ब्लॉक्सच्या स्वरूपात स्वयंचलितपणे आणि समान रीतीने डेटा वितरित करू शकते. त्याच वेळी, FS चांगले आणि सहजतेने मोजले पाहिजे आणि समीप प्रणालींपासून स्वतंत्र असावे, म्हणजे. "फक्त एक स्टोरेज सुविधा" च्या रूपात VAIR पासून दूर राहा.

पहिली vAIR संकल्पना

आमच्या स्वतःच्या विकासाच्या बाजूने स्ट्रेच्ड स्टोरेज (सेफ, ग्लुस्टर, लस्टर आणि यासारखे) आयोजित करण्यासाठी आम्ही जाणूनबुजून तयार मुक्त स्रोत उपायांचा वापर सोडून दिला, कारण आम्हाला त्यांच्यासोबत प्रकल्पाचा खूप अनुभव होता. अर्थात, हे उपाय स्वतःच उत्कृष्ट आहेत आणि Aerodisk वर काम करण्यापूर्वी, आम्ही त्यांच्यासोबत एकापेक्षा जास्त एकत्रीकरण प्रकल्प राबवले. परंतु एका ग्राहकासाठी विशिष्ट कार्य अंमलात आणणे, कर्मचाऱ्यांना प्रशिक्षण देणे आणि, कदाचित, मोठ्या विक्रेत्याचे समर्थन खरेदी करणे ही एक गोष्ट आहे आणि विविध कामांसाठी वापरल्या जाणाऱ्या सहजपणे नक्कल केलेले उत्पादन तयार करणे ही दुसरी गोष्ट आहे, जी आम्ही, विक्रेता, कदाचित आपल्याबद्दल माहित असेल की आम्ही करणार नाही. दुसऱ्या उद्देशासाठी, विद्यमान मुक्त स्त्रोत उत्पादने आमच्यासाठी योग्य नाहीत, म्हणून आम्ही स्वतः वितरित फाइल सिस्टम तयार करण्याचा निर्णय घेतला.
दोन वर्षांनंतर, अनेक विकसकांनी (ज्यांनी व्हीएआयआर वर क्लासिक इंजिन स्टोरेज सिस्टमवरील काम एकत्र केले) एक निश्चित परिणाम प्राप्त केला.

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

आम्ही फाईल सिस्टीमच्या नावाने जास्त त्रास दिला नाही आणि थोडक्यात त्याला एआरडीएफएस म्हटले (त्याचा अर्थ काय आहे याचा अंदाज घ्या))

हा प्रोटोटाइप चांगला दिसत होता (दृश्यदृष्ट्या नाही, अर्थातच, अद्याप कोणतेही व्हिज्युअल डिझाइन नव्हते) आणि कार्यप्रदर्शन आणि स्केलिंगच्या बाबतीत चांगले परिणाम दर्शवले. पहिल्या वास्तविक निकालानंतर, आम्ही संपूर्ण विकासाचे वातावरण आणि केवळ vAIR सोबत काम करणारी एक वेगळी टीम आयोजित करून हा प्रकल्प गतीमान केला.

तोपर्यंत, सोल्यूशनचे सामान्य आर्किटेक्चर परिपक्व झाले होते, ज्यामध्ये अद्याप मोठे बदल झाले नाहीत.

एआरडीएफएस फाइल सिस्टीममध्ये जाणे

ARDFS हा vAIR चा पाया आहे, जो संपूर्ण क्लस्टरमध्ये वितरित, दोष-सहिष्णु डेटा स्टोरेज प्रदान करतो. ARDFS चे एक (परंतु एकमेव नाही) विशिष्ट वैशिष्ट्य म्हणजे ते मेटाडेटा आणि व्यवस्थापनासाठी कोणतेही अतिरिक्त समर्पित सर्व्हर वापरत नाही. हे मूळतः सोल्यूशनचे कॉन्फिगरेशन सुलभ करण्यासाठी आणि त्याच्या विश्वासार्हतेसाठी कल्पना केली गेली होती.

स्टोरेज रचना

क्लस्टरच्या सर्व नोड्समध्ये, ARDFS सर्व उपलब्ध डिस्क स्पेसमधून लॉजिकल पूल आयोजित करते. हे समजून घेणे महत्त्वाचे आहे की पूल अद्याप डेटा किंवा स्वरूपित जागा नाही, परंतु फक्त मार्कअप, म्हणजे. व्हीएआयआर स्थापित असलेले कोणतेही नोड्स, क्लस्टरमध्ये जोडल्यावर, सामायिक केलेल्या एआरडीएफएस पूलमध्ये स्वयंचलितपणे जोडले जातात आणि डिस्क संसाधने संपूर्ण क्लस्टरमध्ये स्वयंचलितपणे सामायिक होतात (आणि भविष्यातील डेटा स्टोरेजसाठी उपलब्ध). हा दृष्टिकोन तुम्हाला आधीपासून चालू असलेल्या प्रणालीवर कोणताही गंभीर परिणाम न करता फ्लायवर नोड्स जोडण्यास आणि काढण्याची परवानगी देतो. त्या. प्रणाली "विटांमध्ये" मोजणे खूप सोपे आहे, आवश्यक असल्यास क्लस्टरमध्ये नोड्स जोडणे किंवा काढून टाकणे.

व्हर्च्युअल डिस्क्स (व्हर्च्युअल मशीनसाठी स्टोरेज ऑब्जेक्ट्स) ARDFS पूलच्या वर जोडल्या जातात, जे 4 मेगाबाइट आकाराच्या व्हर्च्युअल ब्लॉक्सपासून तयार केले जातात. व्हर्च्युअल डिस्क थेट डेटा संग्रहित करतात. फॉल्ट टॉलरन्स स्कीम व्हर्च्युअल डिस्क स्तरावर देखील सेट केली आहे.

तुम्ही आधीच अंदाज केला असेल की, डिस्क सबसिस्टमच्या फॉल्ट टॉलरन्ससाठी, आम्ही RAID (स्वतंत्र डिस्क्सचा रिडंडंट ॲरे) संकल्पना वापरत नाही, परंतु RAIN (स्वतंत्र नोड्सचा रिडंडंट ॲरे) वापरतो. त्या. दोष सहिष्णुता नोड्सच्या आधारे मोजली जाते, स्वयंचलित आणि व्यवस्थापित केली जाते, डिस्कवर नाही. डिस्क्स, अर्थातच, एक स्टोरेज ऑब्जेक्ट देखील आहेत, इतर सर्व गोष्टींप्रमाणेच त्यांचे परीक्षण केले जाते, आपण स्थानिक हार्डवेअर RAID एकत्र करण्यासह त्यांच्यासह सर्व मानक ऑपरेशन्स करू शकता, परंतु क्लस्टर विशेषत: नोड्सवर कार्य करते.

तुम्हाला खरोखर RAID हवा असेल अशा परिस्थितीत (उदाहरणार्थ, लहान क्लस्टर्सवर एकाधिक अपयशांना समर्थन देणारी परिस्थिती), तुम्हाला स्थानिक RAID कंट्रोलर्स वापरण्यापासून आणि स्ट्रेच्ड स्टोरेज आणि वर रेन आर्किटेक्चर तयार करण्यापासून काहीही प्रतिबंधित करत नाही. ही परिस्थिती अगदी लाइव्ह आहे आणि आमच्याद्वारे समर्थित आहे, म्हणून आम्ही 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 ची प्रत) नसते.

अशा प्रकारे, व्हर्च्युअल डिस्क (आणि व्हीएम, त्यानुसार) आरएफ -2 स्कीममधील एका नोडच्या अपयशातून सहजपणे टिकून राहू शकते.

प्रतिकृती योजना, सोपी आणि विश्वासार्ह असली तरीही, RAID1 सारखीच समस्या आहे - वापरण्यायोग्य जागा पुरेशी नाही.

2) वरील समस्या सोडवण्यासाठी इरेजर कोडिंग किंवा इरेजर कोडिंग ("रिडंडंट कोडिंग", "इरेजर कोडिंग" किंवा "रिडंडंसी कोड" म्हणूनही ओळखले जाते) अस्तित्वात आहे. EC ही एक रिडंडंसी योजना आहे जी प्रतिकृतीच्या तुलनेत कमी डिस्क स्पेस ओव्हरहेडसह उच्च डेटा उपलब्धता प्रदान करते. या यंत्रणेचे ऑपरेटिंग तत्त्व RAID 5, 6, 6P सारखे आहे.

एन्कोडिंग करताना, EC प्रक्रिया वर्च्युअल ब्लॉक (डिफॉल्टनुसार 4MB) EC योजनेनुसार अनेक लहान "डेटा भागांमध्ये" विभाजित करते (उदाहरणार्थ, 2+1 योजना प्रत्येक 4MB ब्लॉकला 2 2MB भागांमध्ये विभाजित करते). पुढे, ही प्रक्रिया "डेटा भाग" साठी "पॅरिटी भाग" तयार करते जे पूर्वी विभाजित भागांपैकी एकापेक्षा मोठे नाहीत. डीकोडिंग करताना, EC संपूर्ण क्लस्टरमधील "हयात" डेटा वाचून गहाळ भाग तयार करते.

उदाहरणार्थ, 2 क्लस्टर नोड्सवर लागू केलेली 1 + 4 EC योजना असलेली व्हर्च्युअल डिस्क, 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 चे दोन संच मिळतात, त्यातील प्रत्येकामध्ये दोन दोन-MB तुकडे असतात. पुढे, या प्रत्येक सेटसाठी, पॅरिटीची गणना एका भागापेक्षा जास्त नसलेल्या व्हॉल्यूमसह केली जाते (म्हणजे 2 MB), आम्हाला अतिरिक्त + 2 तुकडे पॅरिटी (AP आणि BP) मिळतात. एकूण आमच्याकडे 4×2 डेटा + 2×2 पॅरिटी आहे.

पुढे, नोड्समध्ये तुकडे "राखले" जातात जेणेकरून डेटा त्यांच्या समानतेला छेदत नाही. त्या. A1 आणि A2 AP सारख्या नोडवर नसतील.

एक नोड अयशस्वी झाल्यास (उदाहरणार्थ, तिसरा देखील), पडलेला ब्लॉक बी 1 आपोआप बीपी पॅरिटीमधून पुनर्संचयित केला जाईल, जो नोड क्रमांक 2 वर संग्रहित आहे, आणि जेथे आहे त्या नोडवर सक्रिय केला जाईल. बी-समानता नाही, म्हणजे बीपीचा तुकडा. या उदाहरणात, हा नोड क्रमांक 1 आहे

मला खात्री आहे की वाचकांना एक प्रश्न आहे:

"तुम्ही वर्णन केलेली प्रत्येक गोष्ट प्रतिस्पर्ध्यांनी आणि मुक्त स्त्रोत समाधानांमध्ये लागू केली गेली आहे, तुमच्या ARDFS मध्ये EC च्या अंमलबजावणीमध्ये काय फरक आहे?"

आणि मग एआरडीएफएसची मनोरंजक वैशिष्ट्ये असतील.

लवचिकतेवर लक्ष केंद्रित करून इरेजर कोडिंग

सुरुवातीला, आम्ही बऱ्यापैकी लवचिक EC X+Y योजना प्रदान केली, जिथे X 2 ते 8 मधील संख्येच्या बरोबरीचा आहे आणि Y 1 ते 8 मधील संख्येच्या बरोबरीचा आहे, परंतु नेहमी X पेक्षा कमी किंवा समान आहे. ही योजना प्रदान केली जाते. लवचिकतेसाठी. डेटा तुकड्यांची संख्या (X) वाढवणे ज्यामध्ये व्हर्च्युअल ब्लॉक विभागले गेले आहे ते ओव्हरहेड खर्च कमी करण्यास अनुमती देते, म्हणजेच वापरण्यायोग्य जागा वाढवते.
पॅरिटी चंक्स (Y) ची संख्या वाढवल्याने वर्च्युअल डिस्कची विश्वासार्हता वाढते. Y मूल्य जितके मोठे असेल तितके क्लस्टरमधील अधिक नोड्स अयशस्वी होऊ शकतात. अर्थात, पॅरिटी व्हॉल्यूम वाढल्याने वापरण्यायोग्य क्षमतेचे प्रमाण कमी होते, परंतु विश्वासार्हतेसाठी ही एक किंमत आहे.

ईसी सर्किट्सवरील कार्यक्षमतेचे अवलंबन जवळजवळ थेट आहे: जितके अधिक "तुकडे" तितके कमी कार्यप्रदर्शन, अर्थातच, एक संतुलित दृश्य आवश्यक आहे;

हा दृष्टीकोन प्रशासकांना जास्तीत जास्त लवचिकतेसह स्ट्रेच्ड स्टोरेज कॉन्फिगर करण्यास अनुमती देतो. एआरडीएफएस पूलमध्ये, आपण कोणत्याही दोष सहिष्णुता योजना आणि त्यांचे संयोजन वापरू शकता, जे आमच्या मते, खूप उपयुक्त आहे.

खाली अनेक (सर्व शक्य नाही) RF आणि EC योजनांची तुलना करणारी सारणी आहे.

टेबल दाखवते की अगदी सर्वात “टेरी” संयोजन EC 8+7, जे एकाच वेळी क्लस्टरमध्ये 7 नोड्स गमावण्यास अनुमती देते, मानक प्रतिकृतीपेक्षा कमी वापरण्यायोग्य जागा (1,875 विरुद्ध 2) “खाते” आणि 7 पट अधिक चांगले संरक्षण करते. , जे ही संरक्षण यंत्रणा बनवते, जरी ते अधिक जटिल असले तरी, मर्यादित डिस्क स्पेसच्या परिस्थितीत जास्तीत जास्त विश्वासार्हता सुनिश्चित करणे आवश्यक असलेल्या परिस्थितींमध्ये अधिक आकर्षक आहे. त्याच वेळी, आपल्याला हे समजून घेणे आवश्यक आहे की प्रत्येक "प्लस" ते X किंवा Y हे अतिरिक्त कार्यप्रदर्शन ओव्हरहेड असेल, म्हणून विश्वासार्हता, बचत आणि कार्यप्रदर्शन यांच्यातील त्रिकोणामध्ये आपल्याला अत्यंत काळजीपूर्वक निवडण्याची आवश्यकता आहे. या कारणास्तव, आम्ही कोडिंग साइझिंग मिटवण्यासाठी एक स्वतंत्र लेख देऊ.

फाइल सिस्टमची विश्वसनीयता आणि स्वायत्तता

एआरडीएफएस क्लस्टरच्या सर्व नोड्सवर स्थानिक पातळीवर चालते आणि समर्पित इथरनेट इंटरफेसद्वारे स्वतःचे माध्यम वापरून त्यांना समक्रमित करते. महत्त्वाचा मुद्दा असा आहे की ARDFS स्वतंत्रपणे केवळ डेटाच नाही तर स्टोरेजशी संबंधित मेटाडेटा देखील सिंक्रोनाइझ करते. ARDFS वर काम करत असताना, आम्ही एकाच वेळी अनेक विद्यमान उपायांचा अभ्यास केला आणि आम्हाला आढळून आले की बरेच जण बाह्य वितरित DBMS वापरून फाइल सिस्टम मेटा सिंक्रोनाइझ करतात, जे आम्ही सिंक्रोनाइझेशनसाठी देखील वापरतो, परंतु केवळ कॉन्फिगरेशन, FS मेटाडेटा नाही (याबद्दल आणि इतर संबंधित उपप्रणालींबद्दल पुढील लेखात).

बाह्य DBMS वापरून FS मेटाडेटा सिंक्रोनाइझ करणे अर्थातच एक कार्यरत उपाय आहे, परंतु नंतर ARDFS वर संग्रहित डेटाची सातत्य बाह्य DBMS आणि त्याच्या वर्तनावर अवलंबून असेल (आणि स्पष्टपणे सांगायचे तर, ती एक लहरी महिला आहे), ज्यामध्ये आमचे मत वाईट आहे. का? जर FS मेटाडेटा खराब झाला तर, FS डेटाला "अलविदा" देखील म्हटले जाऊ शकते, म्हणून आम्ही अधिक जटिल परंतु विश्वासार्ह मार्ग घेण्याचे ठरवले.

आम्ही स्वतः ARDFS साठी मेटाडेटा सिंक्रोनाइझेशन उपप्रणाली बनवली आहे आणि ती जवळच्या उपप्रणालींपासून पूर्णपणे स्वतंत्रपणे जगते. त्या. इतर कोणतीही उपप्रणाली एआरडीएफएस डेटा करप्ट करू शकत नाही. आमच्या मते, हा सर्वात विश्वासार्ह आणि योग्य मार्ग आहे, परंतु हे प्रत्यक्षात तसे आहे की नाही हे वेळच सांगेल. याव्यतिरिक्त, या दृष्टिकोनासह एक अतिरिक्त फायदा आहे. एआरडीएफएसचा वापर व्हीएआयआरपासून स्वतंत्रपणे केला जाऊ शकतो, जसे की स्ट्रेच्ड स्टोरेज, ज्याचा आम्ही भविष्यातील उत्पादनांमध्ये नक्कीच वापर करू.

परिणामी, ARDFS विकसित करून, आम्हाला एक लवचिक आणि विश्वासार्ह फाइल सिस्टीम प्राप्त झाली आहे जी तुम्ही क्षमतेवर बचत करू शकता किंवा कार्यक्षमतेवर सर्वकाही सोडून देऊ शकता किंवा वाजवी किंमतीत अल्ट्रा-विश्वसनीय स्टोरेज करू शकता, परंतु कार्यप्रदर्शन आवश्यकता कमी करू शकता.

एक साधे परवाना धोरण आणि लवचिक वितरण मॉडेल (पुढे पाहता, vAIR नोडद्वारे परवानाकृत आहे, आणि एकतर सॉफ्टवेअर किंवा सॉफ्टवेअर पॅकेज म्हणून वितरित केले जाते), हे तुम्हाला विविध प्रकारच्या ग्राहकांच्या गरजा पूर्ण करण्यासाठी अगदी अचूकपणे तयार करण्यास अनुमती देते आणि मग हा समतोल सहज राखता.

या चमत्काराची गरज कोणाला आहे?

एकीकडे, आम्ही असे म्हणू शकतो की बाजारात आधीच असे खेळाडू आहेत ज्यांच्याकडे हायपरकन्व्हर्जन्सच्या क्षेत्रात गंभीर उपाय आहेत आणि आम्ही प्रत्यक्षात जात आहोत. असे दिसते की हे विधान खरे आहे, परंतु ...

दुसरीकडे, जेव्हा आम्ही शेतात जातो आणि ग्राहकांशी संवाद साधतो, तेव्हा आम्ही आणि आमचे भागीदार पाहतो की हे सर्व बाबतीत नाही. हायपरकन्व्हर्जन्ससाठी बरीच कार्ये आहेत, काही ठिकाणी लोकांना हे माहित नव्हते की असे उपाय अस्तित्त्वात आहेत, इतरांमध्ये ते महाग वाटत होते, इतरांमध्ये पर्यायी उपायांच्या अयशस्वी चाचण्या होत्या आणि काही ठिकाणी ते मंजुरीमुळे खरेदी करण्यास मनाई करतात. सर्वसाधारणपणे, शेत नांगरलेले निघाले, म्हणून आम्ही व्हर्जिन माती वाढवायला गेलो))).

GCS पेक्षा स्टोरेज सिस्टीम केव्हा चांगली असते?

आम्ही मार्केटमध्ये काम करत असताना, आम्हाला नेहमी विचारले जाते की स्टोरेज सिस्टमसह क्लासिक योजना वापरणे केव्हा चांगले आहे आणि हायपरकन्व्हर्जेंट कधी वापरावे? GCS निर्मिती करणाऱ्या अनेक कंपन्या (विशेषत: ज्यांच्या पोर्टफोलिओमध्ये स्टोरेज सिस्टम नाहीत) म्हणतात: “स्टोरेज सिस्टम अप्रचलित होत आहेत, केवळ हायपरकन्व्हर्ज्ड!” हे एक धाडसी विधान आहे, परंतु ते संपूर्णपणे वास्तव दर्शवत नाही.

खरं तर, स्टोरेज मार्केट खरंच हायपरकन्व्हर्जन्स आणि तत्सम सोल्यूशन्सकडे वाटचाल करत आहे, परंतु नेहमीच एक "पण" असतो.

प्रथम, स्टोरेज सिस्टमसह शास्त्रीय योजनेनुसार तयार केलेली डेटा सेंटर्स आणि आयटी पायाभूत सुविधा सहजपणे पुन्हा तयार करता येत नाहीत, त्यामुळे अशा पायाभूत सुविधांचे आधुनिकीकरण आणि पूर्णत्व हा अजूनही 5-7 वर्षांचा वारसा आहे.

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

तिसरे म्हणजे, 2 मिलीसेकंद प्रति लेखन (अर्थातच स्थानिक कॅशे वगळून) अतिरिक्त लहान विलंबांमध्ये पूर्णपणे तांत्रिक मर्यादा आहे, जी वितरित स्टोरेजची किंमत आहे.

बरं, डिस्क सबसिस्टमचे अनुलंब स्केलिंग आवडते अशा मोठ्या भौतिक सर्व्हरच्या वापराबद्दल विसरू नका.

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

आणि हायपरकन्व्हर्ज्ड सोल्यूशन्स स्टोरेज सिस्टमपेक्षा कुठे चांगले काम करतील?

वरील मुद्द्यांवर आधारित, तीन स्पष्ट निष्कर्ष काढले जाऊ शकतात:

1. जिथे रेकॉर्डिंगसाठी अतिरिक्त 2 मिलिसेकंद विलंब, जो कोणत्याही उत्पादनामध्ये सातत्याने आढळतो (आता आम्ही सिंथेटिक्सबद्दल बोलत नाही, सिंथेटिक्सवर नॅनोसेकंद दाखवले जाऊ शकतात), अक्रिटिकल आहेत, हायपरकन्व्हर्जंट योग्य आहे.
2. जेथे मोठ्या भौतिक सर्व्हरवरील भार अनेक लहान वर्च्युअलमध्ये बदलला जाऊ शकतो आणि नोड्समध्ये वितरित केला जाऊ शकतो, तेथे हायपरकन्व्हर्जन्स देखील चांगले कार्य करेल.
3. जेथे क्षैतिज स्केलिंगला अनुलंब स्केलिंगपेक्षा उच्च प्राधान्य आहे, तेथे GCS देखील चांगले करेल.

हे उपाय काय आहेत?

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

सध्या, या कामांसाठीच आम्ही AERODISK vAIR बनवले आहे आणि त्यावरच आम्ही लक्ष केंद्रित करत आहोत (आतापर्यंत यशस्वीरित्या). कदाचित हे लवकरच बदलेल, कारण... जग स्थिर नाही.

त्यामुळे…

हे लेखांच्या मोठ्या मालिकेचा पहिला भाग पूर्ण करते; पुढील लेखात आपण सोल्यूशनच्या आर्किटेक्चर आणि वापरलेल्या घटकांबद्दल बोलू.

आम्ही प्रश्न, सूचना आणि रचनात्मक विवादांचे स्वागत करतो.

स्त्रोत: www.habr.com