SDS वास्तुकलाको संक्षिप्त तुलना वा उपयुक्त भण्डारण प्लेटफर्म खोज्नुहोस् (GlusterVsCephVsVirtuozzoStorage)

यो लेख तपाईंलाई आफ्नो लागि सही समाधान छनोट गर्न र Gluster, Ceph र Vstorage (Virtuozzo) जस्ता SDS बीचको भिन्नताहरू बुझ्न मद्दतको लागि लेखिएको थियो।

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

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

ग्लस्टर

Gluster सँग सुरु गरौं, जुन सक्रिय रूपमा भर्चुअल वातावरणका लागि खुला स्रोतमा आधारित SDS सँग हाइपरकन्भर्जेड प्लेटफर्महरूका निर्माताहरूद्वारा प्रयोग गरिन्छ र RedHat वेबसाइटमा भण्डारण खण्डमा फेला पार्न सकिन्छ, जहाँ तपाईं दुई SDS विकल्पहरूबाट छनौट गर्न सक्नुहुन्छ: Gluster वा Ceph।

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

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

यदि फाइलहरू लगभग एउटै साइज हो र भोल्युम मात्र एक समूह हो भने, त्यसपछि सबै ठीक छ, तर अन्य अवस्थाहरूमा निम्न समस्याहरू वर्णनबाट उत्पन्न हुनेछन्:

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

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

यी निष्कर्षहरू प्रयोगकर्ता अनुभवको विवरणसँग पनि सम्बन्धित छन् ग्लस्टर र तुलना गर्दा सेफ, र त्यहाँ यो अधिक उत्पादक र अधिक विश्वसनीय कन्फिगरेसन को समझ को लागी अग्रणी अनुभव को एक विवरण छ। "प्रतिकृति वितरित"।


तस्विरले दुई फाइलहरू लेख्दा लोड वितरण देखाउँछ, जहाँ पहिलो फाइलको प्रतिलिपिहरू पहिलो तीन सर्भरहरूमा वितरण गरिन्छ, जुन भोल्युम 0 समूहमा मिलाइन्छ, र दोस्रो फाइलको तीन प्रतिलिपिहरू दोस्रो समूह भोल्युम १ मा राखिएको हुन्छ। सर्भरहरू। प्रत्येक सर्भरमा एउटा डिस्क हुन्छ।

सामान्य निष्कर्ष यो हो कि तपाइँ Gluster प्रयोग गर्न सक्नुहुन्छ, तर त्यहाँ प्रदर्शन र त्रुटि सहिष्णुतामा सीमितताहरू छन् जसले हाइपरकन्भर्ज्ड समाधानको निश्चित परिस्थितिहरूमा कठिनाइहरू सिर्जना गर्दछ, जहाँ भर्चुअल वातावरणको कम्प्युटिङ भारहरूको लागि स्रोतहरू पनि आवश्यक पर्दछ भन्ने बुझेर।

त्यहाँ केही ग्लुस्टर कार्यसम्पादन सूचकहरू पनि छन् जुन निश्चित परिस्थितिहरूमा प्राप्त गर्न सकिन्छ, सीमित दोष सहिष्णुता।

सेफ

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

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

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

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

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

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

भण्डारण

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

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

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

यदि पहिले पुरानो लेखहरू प्रयोग गरेर Gluster र Ceph तुलना गर्न सम्भव थियो, तिनीहरूबाट सबैभन्दा महत्त्वपूर्ण लाइनहरू प्रयोग गरेर, त्यसपछि Virtuozzo सँग यो अझ गाह्रो छ। यस उत्पादनमा धेरै लेखहरू छैनन् र जानकारी केवल कागजातबाट प्राप्त गर्न सकिन्छ अ in्ग्रेजीमा वा रूसीमा यदि हामीले Vstorage लाई कम्पनीहरूमा केही हाइपरकन्भर्जेड समाधानहरूमा प्रयोग गरिएको भण्डारणको रूपमा विचार गर्छौं Rospplatforma र एक्रोनिस।

म यस वास्तुकलाको विवरणमा मद्दत गर्ने प्रयास गर्नेछु, त्यसैले त्यहाँ थोरै थप पाठ हुनेछ, तर कागजात आफैं बुझ्न धेरै समय लाग्छ, र अवस्थित कागजातहरू केवल तालिका परिमार्जन गरेर सन्दर्भको रूपमा प्रयोग गर्न सकिन्छ। सामग्री वा कीवर्ड द्वारा खोजी।

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

त्यो हो, एक डिस्क यस्तो ब्यारल को एक निश्चित संख्या हो, त्यो हो, डिस्क भोल्युम 256MB द्वारा विभाजित। प्रत्येक प्रतिलिपि एक नोडमा वितरण गरिएको छ, दोस्रो लगभग अर्को नोडको समानान्तरमा, आदि... यदि हामीसँग तीनवटा प्रतिकृतिहरू छन् र त्यहाँ क्यासका लागि SSD डिस्कहरू छन् (लगहरू पढ्न र लेख्नका लागि), त्यसपछि लेखनको पुष्टिकरण लेखन पछि हुनेछ। SSD मा लग गर्नुहोस्, र SSD बाट समानान्तर रिसेट HDD मा जारी रहनेछ, जस्तै पृष्ठभूमिमा। तीन प्रतिकृतिहरूको अवस्थामा, रेकर्ड तेस्रो नोडको SSD बाट पुष्टि पछि प्रतिबद्ध हुनेछ। यस्तो लाग्न सक्छ कि तीन SSD को लेखन गति को योग को तीन द्वारा विभाजित गर्न सकिन्छ र हामी एक प्रतिकृति को लेखन गति प्राप्त गर्नेछौं, तर प्रतिलिपिहरु समानान्तर लेखिएको छ र नेटवर्क लेटन्सी गति सामान्यतया SSD को भन्दा बढी छ, र वास्तवमा लेखन प्रदर्शन नेटवर्कमा निर्भर हुनेछ। यस सन्दर्भमा, वास्तविक IOPS हेर्नको लागि, तपाईंले सम्पूर्ण Vstorage लाई सही रूपमा लोड गर्न आवश्यक छ पद्धति, त्यो हो, वास्तविक लोड परीक्षण गर्दै, र मेमोरी र क्यास होइन, जहाँ यो खातामा सही डाटा ब्लक साइज, थ्रेडहरूको संख्या, आदि लिन आवश्यक छ।

SSD मा माथि उल्लेखित रेकर्डिङ लग यस्तो तरिकाले काम गर्दछ कि डाटा यसमा आउने बित्तिकै, यो सेवा द्वारा तुरुन्तै पढिन्छ र HDD मा लेखिन्छ। त्यहाँ प्रति क्लस्टर धेरै मेटाडेटा सेवाहरू (MDS) छन् र तिनीहरूको संख्या कोरम द्वारा निर्धारण गरिन्छ, जसले Paxos एल्गोरिदम अनुसार काम गर्दछ। ग्राहकको दृष्टिकोणबाट, FUSE माउन्ट पोइन्ट एक क्लस्टर भण्डारण फोल्डर हो जुन क्लस्टरमा सबै नोडहरूमा एकै साथ देखिने छ, प्रत्येक नोडमा यस सिद्धान्त अनुसार माउन्ट गरिएको क्लाइन्ट छ, त्यसैले यो भण्डारण प्रत्येक नोडमा उपलब्ध छ।

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

संक्षेपमा, हामी तीन मध्ये शीर्ष हाइलाइट गर्न सक्छौं: Virtuozzo भण्डारण प्रदर्शन र वास्तुकला को विश्वसनीयता को मामला मा पहिलो स्थान लिन्छ, Ceph दोस्रो स्थान लिन्छ, र Gluster तेस्रो स्थान लिन्छ।

मापदण्ड जसद्वारा Virtuozzo Storage चयन गरिएको थियो: यो आर्किटेक्चरल कम्पोनेन्टहरूको इष्टतम सेट हो, द्रुत मार्गको साथ यो फ्यूज दृष्टिकोणको लागि आधुनिकीकरण गरिएको, हार्डवेयर कन्फिगरेसनहरूको लचिलो सेट, कम स्रोत खपत र गणना (कम्प्युटिङ/भर्चुअलाइजेशन) सँग साझेदारी गर्ने क्षमता, अर्थात्, यो हाइपरकन्भर्जेड समाधानको लागि पूर्ण रूपमा उपयुक्त छ, जुन उहाँको भाग हो। दोस्रो स्थान Ceph हो किनभने यो ग्लुस्टरको तुलनामा अधिक उत्पादक वास्तुकला हो, ब्लकहरूमा यसको सञ्चालन, साथै थप लचिलो परिदृश्यहरू र ठूला क्लस्टरहरूमा काम गर्ने क्षमताको कारण।

त्यहाँ vSAN, Space Direct Storage, Vstorage र Nutanix Storage, HPE र Huawei उपकरणहरूमा Vstorage परीक्षण गर्ने, साथै Vstorage लाई बाह्य हार्डवेयर भण्डारण प्रणालीसँग एकीकृत गर्ने परिदृश्यहरू बीचको तुलना लेख्ने योजनाहरू छन्, त्यसैले यदि तपाईंलाई लेख मन पर्यो भने, यो हुनेछ। तपाईबाट प्रतिक्रिया प्राप्त गर्न पाउँदा खुसी लाग्यो, जसले तपाईको टिप्पणी र इच्छाहरूलाई ध्यानमा राख्दै नयाँ लेखहरूको लागि प्रेरणा बढाउन सक्छ।

स्रोत: www.habr.com