SDS आर्किटेक्चरची संक्षिप्त तुलना किंवा योग्य स्टोरेज प्लॅटफॉर्म शोधा (GlusterVsCephVsVirtuozzoStorage)

हा लेख तुम्हाला स्वतःसाठी योग्य उपाय निवडण्यात मदत करण्यासाठी आणि Gluster, Ceph आणि Vstorage (Virtuozzo) सारख्या SDS मधील फरक समजून घेण्यासाठी लिहिला गेला आहे.

मजकूर काही समस्यांच्या अधिक तपशीलवार प्रकटीकरणासह लेखांच्या दुव्यांचा वापर करतो, म्हणून वर्णन शक्य तितके संक्षिप्त असेल, अनावश्यक फ्लफ आणि प्रास्ताविक माहितीशिवाय मुख्य मुद्दे वापरून, तुमची इच्छा असल्यास, इंटरनेटवर स्वतंत्रपणे मिळवू शकता.

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

ग्लॅस्टर

चला Gluster सह प्रारंभ करूया, जो व्हर्च्युअल वातावरणासाठी ओपन सोर्सवर आधारित SDS सह हायपरकन्व्हर्ज्ड प्लॅटफॉर्मच्या निर्मात्यांद्वारे सक्रियपणे वापरला जातो आणि स्टोरेज विभागातील RedHat वेबसाइटवर आढळू शकतो, जेथे तुम्ही दोन SDS पर्यायांमधून निवडू शकता: Gluster किंवा Ceph.

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

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

जर फाइल्स अंदाजे समान आकाराच्या असतील आणि व्हॉल्यूममध्ये फक्त एक गट असेल तर सर्व काही ठीक आहे, परंतु इतर परिस्थितींमध्ये वर्णनांमधून खालील समस्या उद्भवतील:

• गटांमधील जागा असमानपणे वापरली जाते, ती फाइल्सच्या आकारावर अवलंबून असते आणि फाइल लिहिण्यासाठी गटामध्ये पुरेशी जागा नसल्यास, तुम्हाला एक त्रुटी प्राप्त होईल, फाइल लिहीली जाणार नाही आणि दुसर्या गटामध्ये पुनर्वितरित केली जाणार नाही. ;
• एक फाइल लिहिताना, IO फक्त एका गटाकडे जातो, बाकीचे निष्क्रिय असतात;
• एक फाइल लिहिताना तुम्हाला संपूर्ण व्हॉल्यूमचा IO मिळू शकत नाही;
• आणि ब्लॉक्समध्ये डेटा वितरणाच्या कमतरतेमुळे सामान्य संकल्पना कमी उत्पादक दिसते, जिथे समतोल राखणे आणि समान वितरणाची समस्या सोडवणे सोपे आहे, आणि आता संपूर्ण फाइल ब्लॉकमध्ये जात नाही.

अधिकृत वर्णनावरून आर्किटेक्चर क्लासिक हार्डवेअर RAID वर ग्लुस्टर फाईल स्टोरेज म्हणून कार्य करते हे देखील आम्हाला अनैच्छिकपणे समजले आहे. फायली ब्लॉक्समध्ये कापण्याचे (शार्डिंग) विकासाचे प्रयत्न झाले आहेत, परंतु हे सर्व आधीच अस्तित्वात असलेल्या आर्किटेक्चरल दृष्टीकोनावर कार्यक्षमतेचे नुकसान आणि फ्यूज सारख्या कार्यक्षमतेच्या मर्यादांसह अशा मुक्तपणे वितरित घटकांचा वापर करणारी जोड आहे. कोणत्याही मेटाडेटा सेवा नाहीत, जे ब्लॉकमध्ये फाइल्स वितरीत करताना स्टोरेजची कार्यक्षमता आणि दोष सहन करण्याची क्षमता मर्यादित करते. "वितरित प्रतिकृती" कॉन्फिगरेशनसह चांगले कार्यप्रदर्शन निर्देशक पाहिले जाऊ शकतात आणि इष्टतम लोड वितरणासह विश्वसनीय प्रतिकृती 6 आयोजित करण्यासाठी नोड्सची संख्या किमान 3 असावी.

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


चित्र दोन फाइल्स लिहिताना लोड वितरण दर्शविते, जिथे पहिल्या फाइलच्या प्रती पहिल्या तीन सर्व्हरवर वितरीत केल्या जातात, ज्या व्हॉल्यूम 0 गटात एकत्रित केल्या जातात आणि दुसऱ्या फाइलच्या तीन प्रती दुसऱ्या गट खंड 1 वर ठेवल्या जातात. सर्व्हर प्रत्येक सर्व्हरवर एक डिस्क असते.

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

काही ग्लुस्टर कार्यप्रदर्शन निर्देशक देखील आहेत जे काही विशिष्ट परिस्थितींमध्ये साध्य केले जाऊ शकतात, मर्यादित चुकीची सहनशीलता.

केफ

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

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

आर्किटेक्चरच्या वर्णनावरून, हृदय क्रश आहे, ज्यामुळे डेटा संचयित करण्यासाठी स्थान निवडले आहे. पुढे पीजी येतो - हे समजणे सर्वात कठीण अ‍ॅब्स्ट्रॅक्शन (तार्किक गट) आहे. CRUSH अधिक प्रभावी करण्यासाठी PGs आवश्यक आहेत. पीजीचा मुख्य उद्देश म्हणजे संसाधनांचा वापर कमी करण्यासाठी, कार्यप्रदर्शन आणि स्केलेबिलिटी वाढवण्यासाठी ऑब्जेक्ट्सचे गट करणे. वस्तूंना PG मध्ये एकत्र न करता थेट, वैयक्तिकरित्या संबोधित करणे खूप महाग असेल. ओएसडी ही प्रत्येक स्वतंत्र डिस्कसाठी सेवा आहे.

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

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

अर्थातच, कॅशिंग आणि कॅशे शेअरिंगद्वारे कार्यप्रदर्शन वाढवण्याचे पर्याय आहेत, परंतु यासाठी चांगले हार्डवेअर आवश्यक आहे आणि तरीही नुकसान होईल. पण एकंदरीत, सेफ उत्पादकतेसाठी ग्लुस्टरपेक्षा अधिक मोहक दिसते. तसेच, ही उत्पादने वापरताना, एक महत्त्वाचा घटक विचारात घेणे आवश्यक आहे - ही उच्च पातळीची क्षमता, अनुभव आणि व्यावसायिकता आहे ज्यात लिनक्सवर मोठ्या प्रमाणात भर दिला जातो, कारण सर्वकाही योग्यरित्या तैनात करणे, कॉन्फिगर करणे आणि देखरेख करणे खूप महत्वाचे आहे, जे प्रशासकावर अधिक जबाबदारी आणि ओझे लादते.

Vstorage

आर्किटेक्चर आणखी मनोरंजक दिसते व्हर्चुओझो स्टोरेज (Vstorage), ज्याचा वापर त्याच नोड्सवर हायपरवाइजरसह केला जाऊ शकतो ग्रंथी, परंतु चांगले कार्यप्रदर्शन साध्य करण्यासाठी सर्वकाही योग्यरित्या कॉन्फिगर करणे फार महत्वाचे आहे. म्हणजेच, आर्किटेक्चरच्या अनुषंगाने शिफारसी विचारात न घेता बॉक्समधून असे उत्पादन कोणत्याही कॉन्फिगरेशनवर तैनात करणे खूप सोपे असेल, परंतु उत्पादक नाही.

kvm-qemu हायपरवाइजरच्या सेवांच्या पुढे स्टोरेजसाठी काय एकत्र असू शकते आणि या फक्त काही सेवा आहेत जिथे घटकांची कॉम्पॅक्ट इष्टतम पदानुक्रम आढळली आहे: FUSE (सुधारित, ओपन सोर्स नाही), MDS मेटाडेटा सेवा द्वारे माउंट केलेली क्लायंट सेवा (मेटाडेटा सेवा), सर्व्हिस चंक सर्व्हिस डेटा ब्लॉक्स, जे भौतिक स्तरावर एका डिस्कच्या बरोबरीचे आहे आणि इतकेच. वेगाच्या बाबतीत, अर्थातच, दोन प्रतिकृतींसह दोष-सहिष्णु योजना वापरणे इष्टतम आहे, परंतु जर तुम्ही एसएसडी ड्राइव्हवर कॅशिंग आणि लॉग वापरत असाल, तर त्रुटी-सहिष्णु कोडिंग (कोडिंग पुसून टाका किंवा raid6) वर सभ्यपणे ओव्हरक्लॉक केले जाऊ शकते. हायब्रीड स्कीम किंवा सर्व फ्लॅशवर आणखी चांगली. EC (कोडिंग पुसून टाकणे) मध्ये काही गैरसोय आहे: एक डेटा ब्लॉक बदलताना, समानता रकमेची पुनर्गणना करणे आवश्यक आहे. या ऑपरेशनशी संबंधित नुकसान टाळण्यासाठी, Ceph EC ला विलंबाने पत्र लिहितो आणि विशिष्ट विनंती दरम्यान कार्यप्रदर्शन समस्या उद्भवू शकतात, जेव्हा, उदाहरणार्थ, सर्व ब्लॉक्स वाचणे आवश्यक आहे, आणि Virtuozzo स्टोरेजच्या बाबतीत, बदललेले ब्लॉक्स लिहिणे चालते. "लॉग-स्ट्रक्चर्ड फाइल सिस्टम" दृष्टिकोन वापरणे, जे समता गणना खर्च कमी करते. EC सह आणि त्याशिवाय कामाच्या प्रवेगसह अंदाजे पर्यायांचा अंदाज लावण्यासाठी, तेथे आहेत कॅल्क्युलेटर - उपकरणे निर्मात्याच्या अचूकतेच्या गुणांकावर अवलंबून आकडे अंदाजे असू शकतात, परंतु गणनेचा परिणाम कॉन्फिगरेशनचे नियोजन करण्यात चांगली मदत आहे.

स्टोरेज घटकांच्या साध्या आकृतीचा अर्थ असा नाही की हे घटक शोषत नाहीत लोह संसाधने, परंतु तुम्ही सर्व खर्चाची आगाऊ गणना केल्यास, तुम्ही हायपरवाइजरच्या पुढील सहकार्यावर विश्वास ठेवू शकता.
Ceph आणि Virtuozzo स्टोरेज सेवांद्वारे हार्डवेअर संसाधनांच्या वापराची तुलना करण्यासाठी एक योजना आहे.

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

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

वर वर्णन केलेल्या घटकांसह हायब्रीड हार्डवेअर कॉन्फिगरेशनमध्ये रेकॉर्डिंग प्रक्रियेचा विचार करूया: रेकॉर्डिंग नोडवर जाण्यास सुरुवात होते जिथून क्लायंटने सुरुवात केली (FUSE माउंट पॉइंट सेवा), परंतु मेटाडेटा सर्व्हिस (MDS) मास्टर घटक नक्कीच करेल. क्लायंटला थेट इच्छित भाग सेवा (स्टोरेज सर्व्हिस सीएस ब्लॉक्स) वर निर्देशित करा, म्हणजेच, एमडीएस रेकॉर्डिंग प्रक्रियेत भाग घेत नाही, परंतु फक्त आवश्यक भागापर्यंत सेवा निर्देशित करते. सर्वसाधारणपणे, आम्ही बॅरल्समध्ये पाणी ओतण्यासह रेकॉर्डिंगची उपमा देऊ शकतो. प्रत्येक बॅरल 256MB डेटा ब्लॉक आहे.

म्हणजेच, एक डिस्क म्हणजे अशा बॅरल्सची एक निश्चित संख्या, म्हणजेच, डिस्क व्हॉल्यूम 256MB ने विभाजित. प्रत्येक प्रत एका नोडला वितरीत केली जाते, दुसरी जवळजवळ दुसर्‍या नोडशी समांतर असते, इ. जर आमच्याकडे तीन प्रतिकृती असतील आणि कॅशेसाठी (लॉग वाचण्यासाठी आणि लिहिण्यासाठी) SSD डिस्क्स असतील, तर लेखनाची पुष्टी लिहिल्यानंतर होईल. SSD ला लॉग, आणि SSD वरून समांतर रीसेट HDD वर चालू राहील, जसे की बॅकग्राउंडमध्ये. तीन प्रतिकृतींच्या बाबतीत, तिसऱ्या नोडच्या SSD कडून पुष्टी केल्यानंतर रेकॉर्ड कमिट केले जाईल. असे दिसते की तीन SSD च्या लेखन गतीची बेरीज तीनने भागली जाऊ शकते आणि आम्हाला एका प्रतिकृतीची लेखन गती मिळेल, परंतु प्रती समांतर लिहिल्या जातात आणि नेटवर्क लेटन्सी गती सहसा SSD पेक्षा जास्त असते, आणि खरेतर लेखन कार्यप्रदर्शन नेटवर्कवर अवलंबून असेल. या संदर्भात, वास्तविक IOPS पाहण्यासाठी, तुम्हाला संपूर्ण Vstorage योग्यरित्या लोड करणे आवश्यक आहे पद्धत, म्हणजे, वास्तविक लोडची चाचणी करणे, आणि मेमरी आणि कॅशेची नाही, जेथे योग्य डेटा ब्लॉक आकार, थ्रेड्सची संख्या इ. विचारात घेणे आवश्यक आहे.

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

वर वर्णन केलेल्या कोणत्याही पध्दतीच्या कार्यप्रदर्शनासाठी, नियोजन आणि उपयोजनाच्या टप्प्यावर, नेटवर्क योग्यरितीने कॉन्फिगर करणे खूप महत्वाचे आहे, जेथे एकत्रीकरण आणि योग्यरित्या निवडलेल्या नेटवर्क चॅनेल बँडविड्थमुळे संतुलन असेल. एकत्रितपणे, योग्य हॅशिंग मोड आणि फ्रेम आकार निवडणे महत्वाचे आहे. वर वर्णन केलेल्या SDS पेक्षा खूप मजबूत फरक देखील आहे, हे Virtuozzo Storage मध्ये जलद मार्ग तंत्रज्ञानासह फ्यूज आहे. जे, आधुनिक फ्यूज व्यतिरिक्त, इतर ओपन सोर्स सोल्यूशन्सच्या विपरीत, IOPS मध्ये लक्षणीय वाढ करते आणि आपल्याला क्षैतिज किंवा अनुलंब स्केलिंगद्वारे मर्यादित न ठेवण्याची परवानगी देते. सर्वसाधारणपणे, वर वर्णन केलेल्या आर्किटेक्चरच्या तुलनेत, हे अधिक शक्तिशाली दिसते, परंतु अशा आनंदासाठी, अर्थातच, सेफ आणि ग्लुस्टरच्या विपरीत, आपल्याला परवाने खरेदी करणे आवश्यक आहे.

थोडक्यात, आम्ही तीनपैकी सर्वात वरती हायलाइट करू शकतो: वास्तुकलाची कार्यक्षमता आणि विश्वासार्हतेच्या बाबतीत Virtuozzo Storage प्रथम स्थान घेते, Ceph दुसऱ्या स्थानावर आणि Gluster तिसऱ्या स्थानावर आहे.

Virtuozzo Storage ची निवड ज्या निकषांद्वारे केली गेली: हा आर्किटेक्चरल घटकांचा इष्टतम संच आहे, या फ्यूज दृष्टिकोनासाठी जलद मार्गासह आधुनिकीकरण, हार्डवेअर कॉन्फिगरेशनचा एक लवचिक संच, कमी संसाधनांचा वापर आणि गणना (संगणन/व्हर्च्युअलायझेशन) सह सामायिक करण्याची क्षमता, म्हणजेच, ते हायपरकन्व्हर्ज्ड सोल्यूशनसाठी पूर्णपणे योग्य आहे, ज्याचा तो भाग आहे. दुसरे स्थान Ceph आहे कारण ते Gluster च्या तुलनेत अधिक उत्पादनक्षम आर्किटेक्चर आहे, ब्लॉक्समध्ये त्याचे ऑपरेशन, तसेच अधिक लवचिक परिस्थिती आणि मोठ्या क्लस्टरमध्ये काम करण्याची क्षमता यामुळे.

vSAN, Space Direct Storage, Vstorage आणि Nutanix Storage, HPE आणि Huawei उपकरणांवरील Vstorage ची चाचणी, तसेच Vstorage ला बाह्य हार्डवेअर स्टोरेज सिस्टीमसह एकत्रित करण्याच्या परिस्थितीमध्ये तुलना लिहिण्याची योजना आहे, त्यामुळे तुम्हाला लेख आवडला असेल तर तुमच्याकडून अभिप्राय मिळाल्याने आनंद झाला, ज्यामुळे तुमच्या टिप्पण्या आणि शुभेच्छा लक्षात घेऊन नवीन लेखांसाठी प्रेरणा वाढू शकते.

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