सीएफएचएफएस बनाम ग्लस्टर एफएस

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

डिस्क्लेमर: पहले इस ब्लॉग में आप GlusterFS के लेख देख सकते थे। मेरा इन लेखों से कोई लेना-देना नहीं है। यह हमारे क्लाउड की परियोजना टीम के लेखक का ब्लॉग है और इसके प्रत्येक सदस्य अपनी कहानी बता सकते हैं। उन लेखों के लेखक हमारे ऑपरेशन समूह के इंजीनियर हैं और उनके अपने कार्य और अपने अनुभव हैं, जिन्हें उन्होंने साझा किया है। यदि आपको अचानक कोई अंतर दिखाई देता है तो कृपया इसे ध्यान में रखें। मैं इस अवसर पर उन लेखों के लेखक के बारे में बताता हूं!

क्या चर्चा होगी

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

शब्दावली

लेख को पूर्ण और सभी के लिए समझने योग्य बनाने के लिए, आइए दोनों प्रणालियों की मूल शब्दावली को देखें:

सिफ शब्दावली:

RADOS (विश्वसनीय स्वायत्त वितरित वस्तु भंडार) एक स्व-निहित वस्तु भंडारण है, जो कि सेफ प्रोजेक्ट का आधार है।
सीएफएचएफएस , आरबीडी ( आरडीओएस ब्लॉक डिवाइस), आरजीडब्ल्यू (आरएडब्लू गेटवे) - आरएडओएस के लिए उच्च-स्तरीय गैजेट, जो कि राडोस को विभिन्न इंटरफेस के साथ अंतिम उपयोगकर्ता प्रदान करते हैं।
विशेष रूप से, CephFS एक POSIX-compliant फ़ाइल सिस्टम इंटरफ़ेस प्रदान करता है। वास्तव में, सेफोस डेटा को RADOS में संग्रहीत किया जाता है।
OSD (ऑब्जेक्ट स्टोरेज डेमॉन) एक RADOS क्लस्टर में एक अलग डिस्क / ऑब्जेक्ट स्टोरेज को परोसने वाली प्रक्रिया है।
RADOS पूल (पूल) - कई ओएसडी नियमों के एक सामान्य सेट से एकजुट होते हैं, जैसे कि, उदाहरण के लिए, एक प्रतिकृति नीति। डेटा पदानुक्रम के दृष्टिकोण से, एक पूल एक निर्देशिका या वस्तुओं के लिए एक अलग (फ्लैट, कोई उपनिर्देशिका) नाम स्थान है।
पीजी (प्लेसमेंट ग्रुप) - बेहतर समझ के लिए मैं संदर्भ में थोड़ी देर बाद पीजी की अवधारणा को पेश करूंगा।

चूंकि RADOS वह नींव है जिस पर CephFS बनाया गया है, इसलिए मैं अक्सर इसके बारे में बात करूंगा और यह स्वचालित रूप से CephFS पर लागू होगा।

GlusterFS शब्दावली (इसके बाद gl):

ईंट एकल डिस्क की सेवा करने वाली एक प्रक्रिया है, RADOS शब्दावली में OSD का एक एनालॉग है।
वॉल्यूम - मात्रा जिसमें ईंट एकजुट हैं। टॉम RADOS में एक पूल एनालॉग है, इसमें ईंटों के बीच एक विशिष्ट प्रतिकृति टोपोलॉजी भी है।

डेटा वितरण

इसे स्पष्ट करने के लिए, एक साधारण उदाहरण पर विचार करें जिसे दोनों प्रणालियों द्वारा लागू किया जा सकता है।

उदाहरण के रूप में उपयोग किया जाने वाला सेटअप:

• 2 सर्वर (S1, S2) प्रत्येक में समान आयतन (sda, sdb, sdc) के 3 डिस्क के साथ;
• 2 प्रतिकृति के साथ मात्रा / पूल।

दोनों प्रणालियों को सामान्य ऑपरेशन के लिए कम से कम 3 सर्वरों की आवश्यकता होती है। लेकिन हम इस पर आंखें मूंद लेते हैं, क्योंकि यह एक लेख के लिए सिर्फ एक उदाहरण है।

Gl के मामले में, यह 3 प्रतिकृति समूहों से युक्त एक वितरित-प्रतिकृति मात्रा होगी:

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

"आरेख" पर यह इस तरह दिखेगा:

मानो पहले आर्किटेक्चरल फीचर पहले से ही प्रकट थे:

• समूहों में जगह का असमान रूप से निपटान किया जाता है, यह फ़ाइल आकारों पर निर्भर करता है;
• एक फ़ाइल लिखते समय, IO केवल एक समूह में जाता है, बाकी बेकार होते हैं;
• आपको एक फ़ाइल लिखते समय पूरे वॉल्यूम का IO नहीं मिल सकता है;
• यदि फ़ाइल लिखने के लिए समूह में पर्याप्त जगह नहीं है, तो आपको एक त्रुटि मिलेगी, फ़ाइल नहीं लिखी जाएगी और दूसरे समूह में पुनर्वितरित नहीं होगी।

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

अब आइए सिफ्फ़ को देखें। ऊपर वर्णित RADOS दृश्य में प्रवेश करता है। RADOS में, प्रत्येक डिस्क को एक अलग प्रक्रिया - OSD द्वारा परोसा जाता है। हमारे सेटअप के आधार पर, हमें उनमें से केवल 6, प्रत्येक सर्वर पर 3 मिलते हैं। अगला, हमें डेटा के लिए एक पूल बनाने और इस पूल में पीजी और डेटा प्रतिकृति कारक की संख्या निर्धारित करने की आवश्यकता है - हमारे मामले में 2।
मान लीजिए कि हमने 8 पीजी के साथ एक पूल बनाया है। इन PGs को लगभग OSD में समान रूप से वितरित किया जाएगा:

यह स्पष्ट करने का समय है कि पीजी एक तार्किक समूह है जो कई वस्तुओं को जोड़ता है। चूंकि हम प्रतिकृति तथ्य 2 को सेट करते हैं, प्रत्येक पीजी में किसी अन्य सर्वर पर कुछ अन्य ओएसडी पर एक प्रतिकृति है (डिफ़ॉल्ट रूप से)। उदाहरण के लिए, पीजी 1, जो सर्वर एस 1 पर ओएसडी -1 पर है, ओएसडी -6 पर एस 2 पर एक जुड़वां है। पीजी (या ट्रिपल, यदि प्रतिकृति 3) की प्रत्येक जोड़ी में प्राथमिक पीजी है, जिसे दर्ज किया जा रहा है। उदाहरण के लिए, PG4 के लिए PRIMARY S1 पर है, लेकिन PG3 के लिए PRIMARY S2 पर है।

अब जब आप जानते हैं कि RADOS कैसे काम करता है, हम अपने ब्रांड के नए पूल में फाइल लिखने के लिए आगे बढ़ सकते हैं। हालांकि RADOS एक पूर्ण-संग्रहण है, लेकिन इसे फ़ाइल सिस्टम के रूप में माउंट करना या ब्लॉक डिवाइस के रूप में उपयोग करना संभव नहीं है। इसे सीधे डेटा लिखने के लिए, आपको एक विशेष उपयोगिता या लाइब्रेरी का उपयोग करने की आवश्यकता है।

हम उपरोक्त उदाहरण के रूप में एक ही तीन फाइलें लिखते हैं:

RADOS के मामले में, सब कुछ किसी भी तरह से अधिक जटिल हो गया है, सहमत हैं।

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

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

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

अब मान लीजिए कि हमने RADOS पूल के शीर्ष पर CephFS को ढेर कर दिया है जो पिछले उदाहरण में चित्रित किया गया था। अब विचाराधीन सिस्टम पूरी तरह से एक समान पायदान पर हैं और एक समान फ़ाइल एक्सेस इंटरफ़ेस प्रदान करते हैं।

यदि हम अपनी परीक्षण फ़ाइलों को एकदम नए सिफ्फ़्स में लिखते हैं, तो हम ओएसडी पर डेटा का एक बिल्कुल अलग, लगभग समान वितरण पाएंगे। उदाहरण के लिए, 2GB आकार की फाइल 2 को 512 टुकड़ों में विभाजित किया जाएगा, जिसे विभिन्न पीजी में वितरित किया जाएगा और, परिणामस्वरूप, अलग-अलग ओएसडी में लगभग समान रूप से, और यह व्यावहारिक रूप से ऊपर वर्णित डेटा वितरण के साथ समस्याओं को हल करता है।

हमारे उदाहरण में, केवल 8 पीजी का उपयोग किया जाता है, हालांकि एक ओएसडी पर ~ 100 पीजी करने की सिफारिश की जाती है। और आपको काम करने के लिए सीफएचएस के लिए 2 पूलों की आवश्यकता है। सिद्धांत में काम करने के लिए आपको RADOS के लिए कुछ सर्विस डेमोंस की भी आवश्यकता है। ऐसा मत सोचो कि सब कुछ इतना सरल है, मैं विशेष रूप से बहुत कुछ छोड़ देता हूं, ताकि सार से विदा न हो।

तो अब सेफहफ अधिक दिलचस्प लगता है, है ना? लेकिन मैंने एक और महत्वपूर्ण बिंदु का उल्लेख नहीं किया, इस बार gl के बारे में। Gl में फ़ाइलों को काटने और DHT के माध्यम से उन विखंडू को चलाने के लिए एक तंत्र है। तथाकथित शार्किंग ( शेयरिंग )।

पांच मिनट का इतिहास

21 अप्रैल, 2016 को, सिफ विकास टीम ने "गहना" जारी किया, पहला सिफ रिलीज जिसमें सेफह्स को स्थिर माना जाता है।

यह अब सभी बाएं और दाएं चिल्ला रहा है कि सेफफ्स के बारे में चिल्ला रहा है! और 3-4 साल पहले इसका उपयोग करने के लिए कम से कम एक संदिग्ध निर्णय होगा। हमने अन्य समाधानों की तलाश की, और ऊपर वर्णित वास्तुकला के साथ gl कोई अच्छा नहीं था। लेकिन हम सीएफएचएफएस की तुलना में इसमें अधिक विश्वास करते थे, और तेज करने के लिए इंतजार कर रहे थे, जो रिलीज की तैयारी कर रहा था।

और यहाँ यह X दिन है:

4 जून, 2015 - ग्लस्टर कम्युनिटी ने आज ग्लस्टरएफएस 3.7 ओपन सॉफ्टवेयर-डिफॉल्ट स्टोरेज सॉफ्टवेयर की सामान्य उपलब्धता की घोषणा की।

3.7 - gl का पहला संस्करण, जिसमें शार्किंग को एक प्रयोगात्मक अवसर के रूप में घोषित किया गया था। मंच पर पैर जमाने के लिए सीएफएफएस की स्थिर रिलीज से पहले वे लगभग एक साल पहले थे ...

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

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

यह पहले बगफिक्स और "उत्पादन के लिए तैयार" की स्थिति का इंतजार करने के लिए बना रहा। लेकिन सब कुछ इतना रोबीला नहीं निकला ... लेख को तेज करने से संबंधित महत्वपूर्ण बगों की सूची के साथ नहीं खींचा गया, अब और फिर अगले संस्करणों में उठने के बाद, मैं केवल यह कह सकता हूं कि अंतिम "प्रमुख मुद्दा" निम्नलिखित विवरण के साथ:

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

रिलीज़ 3.13.2, 20 जनवरी, 2018 को बंद कर दिया गया था ... शायद यह आखिरी नहीं है?

इस बारे में हमारे एक लेख पर टिप्पणी , इसलिए पहले से बोलना है।

RedHat वर्तमान RedHat Gluster Storage 3.4 के लिए अपने प्रलेखन में नोट करता है कि केवल एक ही शार्डिंग केस जो वे समर्थन करते हैं वह VM डिस्क के लिए भंडारण है।

साझाकरण का एक समर्थित उपयोग मामला है: Red Hat Enterprise वर्चुअलाइजेशन के लिए स्टोरेज डोमेन के रूप में Red Hat Gluster Storage प्रदान करने के संदर्भ में, लाइव वर्चुअल मशीन छवियों के लिए भंडारण प्रदान करने के लिए। ध्यान दें कि इस उपयोग के मामले के लिए शार्डिंग भी एक आवश्यकता है, क्योंकि यह पिछले कार्यान्वयन पर महत्वपूर्ण प्रदर्शन सुधार प्रदान करता है।

मुझे नहीं पता कि इस तरह का प्रतिबंध क्यों है, लेकिन आपको मानना ​​होगा कि यह चिंताजनक है।

अब मेरे पास तुम्हारे लिए यहाँ सब कुछ है

दोनों सिस्टम डिस्क में डेटा के छद्म यादृच्छिक वितरण के लिए हैश फ़ंक्शन का उपयोग करते हैं।

RADOS के लिए, यह कुछ इस तरह दिखता है:

PG = pool_id + "." + jenkins_hash(object_name) % pg_coun # eg pool id=5 => pg = 5.1f OSD = crush_hash_based_on_jenkins(PG) # eg pg=5.1f => OSD = 12 

Gl तथाकथित सुसंगत हैशिंग का उपयोग करता है। प्रत्येक ईंट को "32-बिट हैश स्पेस के भीतर सीमा" मिलती है। यही है, सभी ईंटें पूरे रेखीय पता हैश स्थान को सीमा या छेद के बिना साझा करती हैं। क्लाइंट फ़ाइल नाम को हैश फ़ंक्शन के माध्यम से चलाता है, और फिर निर्धारित करता है कि प्राप्त हैश किस रेंज में हैश में आता है। इस प्रकार ईंट का चयन किया जाता है। यदि प्रतिकृति समूह में कई ईंटें हैं, तो उन सभी में समान हैश रेंज है। कुछ इस तरह:

यदि हम दो प्रणालियों के काम को एक निश्चित तार्किक रूप में लाते हैं, तो यह कुछ इस तरह से बाहर निकलेगी:

 file -> HASH -> placement_unit 

जहां RADOS के मामले में प्लेसमेंट_ यूनाइट पीजी है, और gl के मामले में यह कई ईंटों का एक प्रतिकृति समूह है।

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

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

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

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

डेटा प्रतिकृति

हमारे परीक्षण पूल और वॉल्यूम में 2. का एक प्रतिकृति कारक होता है। दिलचस्प बात यह है कि इस संख्या की प्रतिकृतियां प्राप्त करने के लिए सिस्टम में प्रश्न अलग-अलग तरीकों का उपयोग करते हैं।

RADOS के मामले में, रिकॉर्डिंग योजना कुछ इस प्रकार है:

क्लाइंट पूरे क्लस्टर की टोपोलॉजी जानता है, लिखने के लिए एक विशिष्ट पीजी का चयन करने के लिए CRUSH (चरण 0) का उपयोग करता है, OSD-0 (चरण 1) पर प्राथमिक पीजी को लिखता है, फिर OSD-0 सिंक्रोनाइज़ेशन डेटा को SECERTARY PG (चरण 2) के लिए, और केवल उसके बाद बताता है सफल / असफल चरण 2, OSD क्लाइंट (चरण 3) के संचालन की पुष्टि नहीं करता / करती है। दो OSD के बीच डेटा प्रतिकृति क्लाइंट के लिए पारदर्शी है। ओएसडी आमतौर पर डेटा प्रतिकृति के लिए एक अलग "क्लस्टर", तेज नेटवर्क का उपयोग कर सकते हैं।

यदि ट्रिपल प्रतिकृति कॉन्फ़िगर किया गया है, तो यह प्राथमिक OSD से दो SECONDARY तक, क्लाइंट के लिए पारदर्शी ... अच्छी तरह से, केवल उस लेटेंसी के उच्चतर होने पर भी चलता है।

Gl अलग तरीके से काम करता है:

क्लाइंट वॉल्यूम की टोपोलॉजी जानता है, वांछित ईंट को निर्धारित करने के लिए DHT (चरण 0) का उपयोग करता है, फिर उसे लिखता है (चरण 1)। सब कुछ सरल और स्पष्ट है। लेकिन यहाँ हम याद करते हैं कि प्रतिकृति समूह की सभी ईंटों की रेंज समान हैश है। और यह मामूली विशेषता पूरी छुट्टी बनाती है। क्लाइंट उन सभी ईंटों के समानांतर लिखता है जिनमें एक उपयुक्त हैश रेंज होती है।

हमारे मामले में, दोहरे प्रतिकृति के साथ, ग्राहक दो अलग-अलग ईंटों पर समानांतर में दोहरी रिकॉर्डिंग करता है। ट्रिपल प्रतिकृति के दौरान, ट्रिपल रिकॉर्डिंग क्रमशः की जाएगी, और 1MB डेटा क्लाइंट से 3MB नेटवर्क ट्रैफ़िक में gl- सर्वर की तरफ लगभग बदल जाएगा। सहमत हैं, सिस्टम की अवधारणाएं लंबवत हैं।

इस तरह की योजना में, ग्लॉ क्लाइंट को अधिक काम सौंपा जाता है, और परिणामस्वरूप, उसे अधिक सीपीयू की आवश्यकता होती है, ठीक है, मैंने पहले ही नेटवर्क के बारे में कहा था।

एएफपी अनुवादक (स्वचालित फ़ाइल प्रतिकृति) द्वारा प्रतिकृति किया जाता है - एक क्लाइंट-साइड एक्सलेटर जो तुल्यकालिक प्रतिकृति करता है। प्रतिकृति प्रतिकृति की सभी ईंटों को लिखता है → एक लेनदेन मॉडल का उपयोग करता है।

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

यह दिलचस्प है कि यदि आप मूल gl क्लाइंट के माध्यम से काम नहीं करते हैं, लेकिन अंतर्निहित एनएफएस सर्वर के माध्यम से gl में लिखते हैं, तो हमें RADOS के समान व्यवहार मिलेगा। इस मामले में, ग्राहक हस्तक्षेप के बिना डेटा को दोहराने के लिए AFP का उपयोग gl डेमॉन में किया जाएगा। लेकिन अंतर्निहित एनएफएस ग्ल वी 4 में सुरक्षित है, और यदि आप इस व्यवहार को चाहते हैं, तो एनएफएस-गणेश का उपयोग करने की सिफारिश की जाती है।

वैसे, एनएफएस और देशी ग्राहक का उपयोग करते समय इतने अलग व्यवहार के कारण, आप पूरी तरह से अलग प्रदर्शन संकेतक देख सकते हैं।

क्या आपके पास एक ही क्लस्टर है, केवल "घुटने पर"?

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

हम पांचवें साल से सिफ के साथ रह रहे हैं। हमने एक ही वॉल्यूम के डिस्क के साथ शुरुआत की, अब हम अधिक कैपेसिटिव का परिचय देते हैं। सेफ के साथ, आप डिस्क को हटा सकते हैं और इसे बिना किसी वास्तु संबंधी कठिनाइयों के एक और बड़े या थोड़े छोटे से बदल सकते हैं। Gl के साथ, सब कुछ अधिक जटिल है - एक 2 टीबी डिस्क निकाल लिया - एक ही डाल दीजिए, कृपया। खैर, या पूरे समूह को एक पूरे के रूप में वापस ले लें, जो बहुत अच्छा नहीं है, सहमत हैं।

उछाल प्रसंस्करण

हम पहले से ही दो समाधानों की वास्तुकला से थोड़ा परिचित हो गए और अब हम इस बारे में बात कर सकते हैं कि इसके साथ कैसे रहना है और सर्विसिंग करते समय क्या विशेषताएं हैं।

मान लीजिए हमने s1 पर sda मना कर दिया है - एक सामान्य बात।

Gl के मामले में:

• समूह में शेष लाइव डिस्क पर डेटा की एक प्रति स्वचालित रूप से अन्य समूहों के लिए पुनर्वितरित नहीं होती है;
• जब तक डिस्क को प्रतिस्थापित नहीं किया जाता है, तब तक डेटा की केवल एक प्रति बनी रहती है;
• जब एक नए के साथ एक असफल डिस्क की जगह, प्रतिकृति एक काम करने वाली डिस्क से एक नया (1 पर 1) के लिए किया जाता है।

यह कई RAID-1s के साथ एक शेल्फ परोसने जैसा है। हां, ट्रिपल प्रतिकृति के साथ, यदि कोई ड्राइव विफल हो जाती है, तो एक प्रति नहीं रहती है, लेकिन दो, लेकिन फिर भी इस दृष्टिकोण में गंभीर कमियां हैं, और मैं उन्हें RADOS के साथ एक अच्छा उदाहरण दिखाऊंगा।

मान लीजिए कि हमने S1 (OSD-0) पर sda विफल कर दिया है - एक सामान्य बात:

• OSD-0 पर आने वाले PG को 10 मिनट (डिफ़ॉल्ट) के बाद स्वचालित रूप से अन्य OSDs में भेज दिया जाएगा। हमारे उदाहरण में, ओएसडी 1 और 2 पर। यदि अधिक सर्वर थे, तो बड़ी संख्या में ओएसडी पर।
• पीजी जो डेटा की दूसरी जीवित प्रति को संग्रहीत करते हैं, वे स्वचालित रूप से उन ओएसडी को दोहराएंगे जहां बहाल किए गए पीजी को स्थानांतरित किया जाता है। यह कई-से-कई प्रतिकृति निकलता है, न कि ग्लोब की तरह एक-से-एक प्रतिकृति।
• जब एक नया डिस्क पेश किया जाता है, तो एक टूटे हुए के बजाय, कुछ ओएस नए ओएसडी में अपने वजन के अनुसार जमा हो जाएंगे और अन्य ओएसडी से डेटा को पुनर्वितरित किया जाएगा।

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

स्केलिंग

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

सीएफएचएफएस से पहले के दिनों में, हमने डेटा पेटाबाइट्स के लिए समाधान तैयार किया और ग्ल को देखा। तब हमें gl की मापनीयता के बारे में संदेह था और हमें मेलिंग सूची के माध्यम से पता चला। यहाँ एक उत्तर है (प्रश्न: मेरा प्रश्न):

मैं 60 सर्वरों का उपयोग कर रहा हूं, जिनमें से प्रत्येक में 26x8TB डिस्क है, जिसमें कुल 1560 डिस्क 16 + 4 EC वॉल्यूम के साथ 9PB उपयोग करने योग्य स्थान है।

प्रश्न: क्या आप ग्राहक पक्ष पर libgfapi या FUSE या NFS का उपयोग करते हैं?

मैं FUSE का उपयोग करता हूं और मेरे पास लगभग 1000 ग्राहक हैं।

प्रश्न: आपके वॉल्यूम में कितनी फाइलें हैं?
प्रश्न: फाइलें ज्यादा बड़ी या छोटी होती हैं?

मेरे पास 1M से अधिक फाइलें हैं और क्लस्टर का% 13 उपयोग किया जाता है जो औसत फ़ाइल आकार 1GB बनाता है।
न्यूनतम / अधिकतम फ़ाइल का आकार 100 एमबी / 2 जीबी है। हर दिन 10-20TB नया डेटा वॉल्यूम में प्रवेश करता है।

क्यू: कितनी तेजी से "एलएस" काम करता है)?

आपकी अपेक्षा के अनुसार मेटाडेटा संचालन धीमा है। मैं एक निर्देशिका में 2-3K से अधिक फ़ाइलों को नहीं रखने की कोशिश करता हूं। मेरा उपयोग मामला बैकअप / संग्रह के लिए है इसलिए मैं शायद ही कभी मेटाडेटा ऑपरेशन करता हूं।

फ़ाइलों का नाम बदलें

वापस हैश फ़ंक्शंस के लिए। हमने यह पता लगाया कि विशिष्ट डिस्क के लिए विशिष्ट फ़ाइलों को कैसे रूट किया जाता है, और अब सवाल प्रासंगिक हो जाता है, लेकिन फ़ाइलों का नाम बदलने पर क्या होगा?

आखिरकार, यदि हम फ़ाइल का नाम बदलते हैं, तो उसकी ओर से हैश भी बदल जाएगा, जिसका अर्थ है कि इस फाइल का स्थान किसी अन्य डिस्क पर (एक अलग हैश रेंज में) या RADOS के मामले में किसी अन्य PG / OSD पर। हां, हम सही तरीके से सोचते हैं, और यहां दो प्रणालियों में सब कुछ फिर से लंबवत है।

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

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

प्रतिकृति 2.5

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

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

और ग्राहकों के बारे में क्या?

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

लेकिन फियो (लचीले I / O परीक्षक) ने लंबे समय तक और सफलतापूर्वक libgfapi का समर्थन किया है, लेकिन यह libcephfs का समर्थन नहीं करता है। यह एक प्लस gl है, क्योंकि Fio का उपयोग करना वास्तव में सीधे gl का परीक्षण करने के लिए अच्छा है। केवल libpfapi के माध्यम से यूजरस्पेस से काम करने पर आपको gl से सब कुछ प्राप्त हो सकता है।

लेकिन अगर हम POSIX फाइल सिस्टम के बारे में बात कर रहे हैं और इसे कैसे माउंट करते हैं, तो gl केवल FUSE क्लाइंट, और अपस्ट्रीम कर्नेल में CephFS कार्यान्वयन की पेशकश कर सकता है। यह स्पष्ट है कि कर्नेल मॉड्यूल में आप ऐसी चाल कर सकते हैं कि FUSE बेहतर प्रदर्शन दिखाएगा। लेकिन व्यवहार में, FUSE हमेशा संदर्भ स्विचिंग पर एक उपरि है। मैंने व्यक्तिगत रूप से एक से अधिक बार देखा है कि कैसे FUSE ने अकेले सीएस के साथ एक दोहरे सॉकेट सर्वर को झुका दिया।
किसी तरह लिनस ने कहा:

Userspace फाइल सिस्टम? समस्या वहीं की वहीं है। हमेशा से रहा है। जो लोग सोचते हैं कि उपयोगकर्तास्पेस फाइल सिस्टम कुछ भी करने के लिए यथार्थवादी हैं, लेकिन खिलौने सिर्फ गुमराह हैं।

Gl डेवलपर्स, इसके विपरीत, सोचते हैं कि FUSE शांत है। यह कर्नेल संस्करणों से अधिक लचीलापन और डिटैच देने के लिए कहा जाता है। मेरे लिए, वे FUSE का उपयोग करते हैं क्योंकि gl गति के बारे में नहीं है। किसी तरह यह लिखा है - ठीक है, यह सामान्य है, और कर्नेल में कार्यान्वयन के साथ परेशान करना वास्तव में अजीब है।

उत्पादकता

कोई तुलना नह) ं होगी।

यह बहुत जटिल है। समरूप सेटअप पर भी वस्तुनिष्ठ परीक्षण करना बहुत कठिन है। वैसे भी, टिप्पणियों में कोई होगा जो 100500 पैरामीटर देगा जो सिस्टम में से एक को "गति" देगा और कहेगा कि परीक्षण बकवास हैं। इसलिए, यदि रुचि हो, तो स्वयं का परीक्षण करें, कृपया।

निष्कर्ष

विशेष रूप से, RADOS और CephFS, समझने में, सेटिंग में और रखरखाव में दोनों एक अधिक जटिल समाधान हैं।

लेकिन व्यक्तिगत रूप से, मैं RADOS की वास्तुकला को पसंद करता हूं और ग्लस्टरएफएस से अधिक सीएफएफएस के शीर्ष पर चल रहा हूं। अधिक हैंडल (PG, OSD वजन, CRUSH पदानुक्रम, आदि), CephFS मेटाडेटा जटिलता बढ़ाता है, लेकिन अधिक लचीलापन देता है और इस समाधान को मेरी राय में अधिक प्रभावी बनाता है।

सीएफएच वर्तमान एसडीएस मानदंडों के लिए बहुत बेहतर है और मुझे अधिक आशाजनक लगता है। लेकिन यह मेरी राय है, आपको क्या लगता है?