Glusterfs + erasure कोडिंग: जब आपको बहुत, सस्ते और विश्वसनीय की आवश्यकता होती है

कुछ लोगों के पास रूस में एक ग्लेस्टर है, और कोई भी अनुभव दिलचस्प है। हमारे पास यह बड़ी और औद्योगिक है और, अंतिम पोस्ट में चर्चा द्वारा, मांग को देखते हुए। मैंने एंटरप्राइज स्टोरेज से लेकर Glusterfs तक के बैकअप के माइग्रेशन के अनुभव के बारे में बात की।

यह पर्याप्त कट्टर नहीं है। हम रुके नहीं और कुछ और गंभीर इकट्ठा करने का फैसला किया। इसलिए, यहाँ हम इरेज़िंग कोडिंग, शार्किंग, रीबैलेंसिंग और इसके थ्रॉटलिंग, स्ट्रेस टेस्टिंग इत्यादि जैसी चीजों के बारे में बात करेंगे।

• अधिक वॉल्यूम / सबवोलम सिद्धांत
• गर्म स्पेयर
• चंगा / चंगा पूर्ण / असंतुलन
• रिबूट 3 नोड्स के बाद निष्कर्ष (ऐसा कभी न करें)
• विभिन्न वीएम से अलग-अलग गति से रिकॉर्डिंग और सबवोल्यूम लोड को कैसे प्रभावित करता है?
• डिस्क के प्रस्थान के बाद असंतुलन
• तेजी से असंतुलन

तुम क्या चाहते थे

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

आवेदन (क्रमिक IO) :

- बैकअप
- टेस्ट इन्फ्रास्ट्रक्चर
- भारी मीडिया फ़ाइलों के लिए परीक्षण का भंडारण।
हम यहां हैं।
- बैटल फाइल और गंभीर टेस्ट इंफ्रास्ट्रक्चर
- महत्वपूर्ण डेटा के लिए भंडारण।

पिछली बार की तरह, मुख्य आवश्यकता ग्लेस्टर उदाहरणों के बीच नेटवर्क की गति है। 10G पहली बार में ठीक है।

सिद्धांत: छितरी हुई मात्रा क्या है?

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

एक सबवोल्यूम क्या है?

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



यह तय किया गया था कि 6 नोड्स पर वितरित-फैलाया गया 4 + 2 कॉन्फ़िगरेशन काफी विश्वसनीय लगता है, हम डेटा तक पहुंच जारी रखते हुए प्रत्येक सबवूफ़र के भीतर 2 सर्वर या 2 डिस्क खो सकते हैं।

हम अपने निपटान में 12 डिस्क स्लॉट और 48x2TB 3.5 SATA ड्राइव के साथ 6 पुराने DELL PowerEdge R510 पर थे। सिद्धांत रूप में, अगर 12 डिस्क स्लॉट्स वाला एक सर्वर है, और बाजार में 12 टीबी ड्राइव तक है, तो हम 576 टीबी तक उपयोग करने योग्य स्थान पर भंडारण एकत्र कर सकते हैं। लेकिन यह मत भूलो कि भले ही अधिकतम एचडीडी आकार साल-दर-साल बढ़ता रहे, लेकिन उनका प्रदर्शन अभी भी बरकरार है और 10-12TB डिस्क के पुनर्निर्माण के लिए आपको एक सप्ताह लग सकता है।



वॉल्यूम सृजन:
ईंटों को कैसे तैयार किया जाए, इसका विस्तृत विवरण आप मेरी पिछली पोस्ट में पढ़ सकते हैं

gluster volume create freezer disperse-data 4 redundancy 2 transport tcp \ $(for i in {0..7} ; do echo {sl051s,sl052s,sl053s,sl064s,sl075s,sl078s}:/export/brick$i/freezer ; done) 

हम बनाते हैं, लेकिन हम लॉन्च और माउंट करने की जल्दी में नहीं हैं, क्योंकि हमें अभी भी कई महत्वपूर्ण मापदंडों को लागू करना है।

हमें क्या मिला:



सब कुछ काफी सामान्य लग रहा है, लेकिन एक चेतावनी है।

इसमें ईंटों पर इस तरह की मात्रा दर्ज करना शामिल है:
फ़ाइलों को एक-एक करके सबवूम्स में रखा जाता है, और समान रूप से उनके बीच में नहीं फैलता है, इसलिए, जितनी जल्दी या बाद में हम इसके आकार में चलेंगे, और पूरे वॉल्यूम के आकार से नहीं। इस रिपॉजिटरी में हम जो अधिकतम फाइल साइज़ डाल सकते हैं, वह सबवूफ़र माइनस का प्रयोग करने योग्य आकार है, जिस पर पहले से ही कब्जा है। मेरे मामले में, यह <8 Tb है।

क्या करें? कैसे हो सकता है?
इस समस्या को शार्पिंग या स्ट्राइप वॉल्यूम द्वारा हल किया जाता है, लेकिन, जैसा कि अभ्यास से पता चला है, स्ट्राइप बहुत बुरी तरह से काम करता है।

इसलिए, हम पैनापन की कोशिश करेंगे।

विस्तार क्या है, यहां विस्तार से ।

संक्षेप में क्या है :
प्रत्येक फ़ाइल जिसे आप वॉल्यूम में रखते हैं, उसे भागों (शर्ड्स) में विभाजित किया जाएगा, जो अपेक्षाकृत समान रूप से सबवे में व्यवस्थित होते हैं। शार्क का आकार प्रशासक द्वारा निर्दिष्ट किया गया है, मानक मूल्य 4 एमबी है।

वॉल्यूम बनाने के बाद शार्किंग चालू करें, लेकिन शुरू होने से पहले :

 gluster volume set freezer features.shard on 

हमने शार्द का आकार निर्धारित किया है (जो कि इष्टतम है। OVirt से मिलने वाले चित्र 512MB की अनुशंसा करते हैं) :

 gluster volume set freezer features.shard-block-size 512MB 

जाहिर है, यह पता चला है कि छितरी मात्रा 4 + 2 का उपयोग करते समय ईंटों में शार्क का वास्तविक आकार हमारे ब्लॉक 512M / 4 = 128M में शार्क-ब्लॉक-आकार / 4 के बराबर है।

इरेज़र कोडिंग लॉजिक के अनुसार प्रत्येक शार्क इन टुकड़ों के साथ सबवर्ल्ड के ढांचे के भीतर ईंटों के अनुसार विघटित होती है: 4 * 128M + 2 * 128M

इस कॉन्फ़िगरेशन के साथ चमकने वाले विफलता मामलों को ड्रा करें:
इस कॉन्फ़िगरेशन में, हम एक ही सबवोल्यूम के भीतर किसी भी डिस्क के 2 नोड्स या 2 के गिरने से बच सकते हैं।

परीक्षणों के लिए, हमने अपने क्लाउड के तहत परिणामी भंडारण को पर्ची करने और आभासी मशीनों से फियो चलाने का फैसला किया।

हम 15 वीएम से अनुक्रमिक रिकॉर्डिंग चालू करते हैं और निम्नलिखित करते हैं।

पहली नोड का रिबूट:
17:09
यह अनियंत्रित दिखता है (पिंग.टाइमआउट पैरामीटर द्वारा अनुपलब्धता के ~ 5 सेकंड)।

17:19
पूरा भर दिया।
हील प्रविष्टियों की संख्या केवल बढ़ रही है, शायद क्लस्टर के लेखन के उच्च स्तर के कारण।

17:32
वीएम से रिकॉर्डिंग बंद करने का निर्णय लिया गया।
हील प्रविष्टियों की संख्या में गिरावट शुरू हुई।

17:50
चंगा किया।

रिबूट 2 नोड्स:

उसी परिणाम को 1 नोड के साथ देखा जाता है।

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

लेकिन 15 में से 4 वीएम नहीं उठ सके। मैंने हाइपरविजर पर त्रुटियाँ देखीं:

 2018.04.27 13:21:32.719 ( volumes.py:0029): I: Attaching volume vol-BA3A1BE1 (/GLU/volumes/33/33e3bc8c-b53e-4230-b9be-b120079c0ce1) with attach type generic... 2018.04.27 13:21:32.721 ( qmp.py:0166): D: Querying QEMU: __com.redhat_drive_add({'file': u'/GLU/volumes/33/33e3bc8c-b53e-4230-b9be-b120079c0ce1', 'iops_rd': 400, 'media': 'disk', 'format': 'qcow2', 'cache': 'none', 'detect-zeroes': 'unmap', 'id': 'qdev_1k7EzY85TIWm6-gTBorE3Q', 'iops_wr': 400, 'discard': 'unmap'})... 2018.04.27 13:21:32.784 ( instance.py:0298): E: Failed to attach volume vol-BA3A1BE1 to the instance: Device 'qdev_1k7EzY85TIWm6-gTBorE3Q' could not be initialized Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/ic/instance.py", line 292, in emulation_started c2.qemu.volumes.attach(controller.qemu(), device) File "/usr/lib64/python2.7/site-packages/c2/qemu/volumes.py", line 36, in attach c2.qemu.query(qemu, drive_meth, drive_args) File "/usr/lib64/python2.7/site-packages/c2/qemu/_init_.py", line 247, in query return c2.qemu.qmp.query(qemu.pending_messages, qemu.qmp_socket, command, args, suppress_logging) File "/usr/lib64/python2.7/site-packages/c2/qemu/qmp.py", line 194, in query message["error"].get("desc", "Unknown error") QmpError: Device 'qdev_1k7EzY85TIWm6-gTBorE3Q' could not be initialized qemu-img: Could not open '/GLU/volumes/33/33e3bc8c-b53e-4230-b9be-b120079c0ce1': Could not read image for determining its format: Input/output error 

शार्पिंग के साथ हार्ड 3 नोड्स का भुगतान बंद कर दिया

 Transport endpoint is not connected (107) /GLU/volumes/e0/e0bf9a42-8915-48f7-b509-2f6dd3f17549: ERROR: cannot read (Input/output error) 

हम डेटा भी खो देते हैं, इसे पुनर्स्थापित करना संभव नहीं है।

शार्पिंग के साथ 3 नोड्स को धीरे से चुकाएं, क्या डेटा भ्रष्टाचार होगा?
वहाँ है, लेकिन बहुत कम (संयोग?), मैंने 30 में से 3 ड्राइव खो दिए।

निष्कर्ष:

1. इन फ़ाइलों का चंगा अंतहीन रूप से लटका हुआ है, पुनर्संतुलन मदद नहीं करता है। हम यह निष्कर्ष निकालते हैं कि तीसरी नोड बंद होने पर सक्रिय रिकॉर्डिंग करने वाली फाइलें हमेशा के लिए खो जाती हैं।
2. कभी भी उत्पादन में 4 + 2 विन्यास में 2 से अधिक नोड लोड न करें!
3. यदि आप वास्तव में 3+ नोड को रिबूट करना चाहते हैं तो डेटा कैसे न खोएं? P आरोह बिंदु पर रिकॉर्डिंग रोकना और / या वॉल्यूम रोकना।
4. जितनी जल्दी हो सके नोड्स या ईंटों को प्रतिस्थापित किया जाना चाहिए। इसके लिए, उदाहरण के लिए, उच्च प्रतिस्थापन के लिए प्रत्येक नोड में 1-2 ला हॉट-स्पेयर ईंटों के लिए यह बहुत ही वांछनीय है। और नोड डंप के मामले में ईंटों के साथ एक और अतिरिक्त नोड।

ड्राइव रिप्लेसमेंट मामलों का परीक्षण करना भी बहुत महत्वपूर्ण है

रिश्वत (डिस्क) के विभाग:
17:20
हम एक ईंट बाहर दस्तक देते हैं:

 /dev/sdh 1.9T 598G 1.3T 33% /export/brick6 

17:22

 gluster volume replace-brick freezer sl051s:/export/brick_spare_1/freezer sl051s:/export/brick2/freezer commit force 

आप ईंट की जगह पर इस तरह की कमी देख सकते हैं (1 स्रोत से रिकॉर्ड):



प्रतिस्थापन की प्रक्रिया काफी लंबी है, प्रति क्लस्टर रिकॉर्डिंग के छोटे स्तर और 1 टीबी की डिफ़ॉल्ट सेटिंग्स के साथ, इसे ठीक होने में एक दिन लगता है।

उपचार के लिए समायोज्य पैरामीटर:

 gluster volume set cluster.background-self-heal-count 20 # Default Value: 8 # Description: This specifies the number of per client self-heal jobs that can perform parallel heals in the background. gluster volume set cluster.heal-timeout 500 # Default Value: 600 # Description: time interval for checking the need to self-heal in self-heal-daemon gluster volume set cluster.self-heal-window-size 2 # Default Value: 1 # Description: Maximum number blocks per file for which self-heal process would be applied simultaneously. gluster volume set cluster.data-self-heal-algorithm diff # Default Value: (null) # Description: Select between "full", "diff". The "full" algorithm copies the entire file from source to # sink. The "diff" algorithm copies to sink only those blocks whose checksums don't match with those of # source. If no option is configured the option is chosen dynamically as follows: If the file does not exist # on one of the sinks or empty file exists or if the source file size is about the same as page size the # entire file will be read and written ie "full" algo, otherwise "diff" algo is chosen. gluster volume set cluster.self-heal-readdir-size 2KB # Default Value: 1KB # Description: readdirp size for performing entry self-heal 

विकल्प: disperse.background-heals
डिफ़ॉल्ट मान: 8
विवरण: इस विकल्प का उपयोग समानांतर हील्स की संख्या को नियंत्रित करने के लिए किया जा सकता है

विकल्प: disperse.heal-Wait-qlength
डिफ़ॉल्ट मान: 128
विवरण: इस विकल्प का उपयोग उस चंगाई की संख्या को नियंत्रित करने के लिए किया जा सकता है जो प्रतीक्षा कर सकती है

विकल्प: disperse.shd- अधिकतम-थ्रेड्स
डिफ़ॉल्ट मान: १
विवरण: समानांतर चंगा एसएचडी की अधिकतम संख्या प्रति स्थानीय ईंट कर सकती है। यह काफी हद तक कम समय को ठीक कर सकता है, लेकिन अगर आपके पास इसका समर्थन करने के लिए भंडारण हार्डवेयर नहीं है, तो यह आपकी ईंटों को भी कुचल सकता है।

विकल्प: disperse.shd-Wait-qlength
डिफ़ॉल्ट मान: 1024
विवरण: इस विकल्प का उपयोग एसएचडी में प्रति उपवृत्त की प्रतीक्षा कर सकने वाले उपचारों की संख्या को नियंत्रित करने के लिए किया जा सकता है

विकल्प: disperse.cpu- एक्सटेंशन
डिफ़ॉल्ट मान: ऑटो
विवरण: गैलप फील्ड संगणना में तेजी लाने के लिए उपयोग किए जाने वाले सीपीयू एक्सटेंशन को मजबूर करें।

विकल्प: disperse.self-heal-window-size
डिफ़ॉल्ट मान: १
विवरण: प्रति फ़ाइल अधिकतम संख्या ब्लॉक (128KB) जिसके लिए स्व-उपचार प्रक्रिया एक साथ लागू की जाएगी।

exhibi:

 disperse.shd-max-threads: 6 disperse.self-heal-window-size: 4 cluster.self-heal-readdir-size: 2KB cluster.data-self-heal-algorithm: diff cluster.self-heal-window-size: 2 cluster.heal-timeout: 500 cluster.background-self-heal-count: 20 cluster.disperse-self-heal-daemon: enable disperse.background-heals: 18 

नए मापदंडों के साथ, 1 टीबी डेटा 8 घंटे (3 गुना तेज!) में पूरा हो गया था।

अप्रिय क्षण यह है कि इसका परिणाम जितना बड़ा था उससे कहीं ज्यादा बड़ा है

यह था:

 Filesystem Size Used Avail Use% Mounted on /dev/sdd 1.9T 645G 1.2T 35% /export/brick2 

वह बन गया:

 Filesystem Size Used Avail Use% Mounted on /dev/sdj 1.9T 1019G 843G 55% /export/hot_spare_brick_0 

इसे समझना आवश्यक है। संभवतः बात पतली डिस्क को भड़का रही है। बढ़ी हुई ईंट के बाद के प्रतिस्थापन के साथ, आकार समान रहा।

पुनर्संतुलन:
किसी वॉल्यूम को (माइग्रेटिंग डेटा के बिना) एक वॉल्यूम (ऐड-ब्रिक और रिमू-ब्रिक कमांड का उपयोग करके) विस्तार या सिकुड़ने के बाद, आपको सर्वर के बीच डेटा को रिबैलेंस करना होगा। गैर-प्रतिरूपित मात्रा में, सभी ईंटों को ईंट के संचालन (स्टार्ट विकल्प) को बदलने के लिए होना चाहिए। एक प्रतिकृति वॉल्यूम में, प्रतिकृति में ईंट का कम से कम एक होना चाहिए।

आकार देने के असंतुलन:

विकल्प: क्लस्टर। क्रेबल-थ्रॉटल
डिफ़ॉल्ट मान: सामान्य
विवरण: असंतुलित संचालन के दौरान नोड पर अनुमत समानांतर फ़ाइल माइग्रेशन की अधिकतम संख्या सेट करता है। डिफ़ॉल्ट मान सामान्य है और अधिकतम [[($ (प्रसंस्करण इकाइयां) - ४) / २), २] फाइलों को बी की अनुमति देता है
ई एक समय में पलायन कर गया। आलसी एक समय में केवल एक फ़ाइल को माइग्रेट करने की अनुमति देगा और आक्रामक अधिकतम [($ (प्रसंस्करण इकाइयों) - 4) / 2), 4] की अनुमति देगा।

विकल्प: क्लस्टर.लॉक-माइग्रेशन
डिफ़ॉल्ट मान: बंद
विवरण: यदि यह सुविधा सक्षम है, तो रिबैलेंस के दौरान फाइल से जुड़े पॉसिक्स लॉक को माइग्रेट करेगा

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

लेखन की तुलना, और फिर एक ही फियो मापदंडों (प्रदर्शन परीक्षणों के अधिक विस्तृत परिणाम - पीएम में) को पढ़ना:)

 fio --fallocate=keep --ioengine=libaio --direct=1 --buffered=0 --iodepth=1 --bs=64k --name=test --rw=write/read --filename=/dev/vdb --runtime=6000 

यदि यह दिलचस्प है, तो ट्रैफ़िक में rsync गति की तुलना Glaster नोड्स से करें:





यह देखा जा सकता है कि लगभग 170 एमबी / एस / 110 एमबी / एस / पेलोड के लिए यातायात। यह पता चला है कि यह अतिरिक्त ट्रैफ़िक का 33% है, जैसा कि इरेज़र कोडिंग अतिरेक का 1/3 है।

लोड के साथ और बिना सर्वर साइड पर मेमोरी की खपत में बदलाव नहीं होता है:




क्लस्टर पर लोड वॉल्यूम पर अधिकतम लोड के साथ होस्ट करता है: