🚼 ⏱️ ⏰ लेकिन आप कहते हैं कि सिफ ... क्या वह इतना अच्छा है? 🚹 🗄️ 😬

मुझे सेफ से प्यार है। मैं उसके साथ 4 साल से काम कर रहा हूं (0.80.x - ~~12.2.6~~ , 12.2.5)। कभी-कभी मैं उसके बारे में इतना भावुक हो जाता हूं कि मैं उसकी कंपनी में शाम और रातें बिताता हूं, न कि अपनी प्रेमिका के साथ। मुझे इस उत्पाद में विभिन्न समस्याओं का सामना करना पड़ा है, और मैं आज भी कुछ लोगों के साथ रहना चाहता हूं। कभी-कभी मैं आसान फैसलों पर हर्षित होता हूं, और कभी-कभी मैं अपने आक्रोश को व्यक्त करने के लिए डेवलपर्स के साथ मिलने का सपना देखता हूं। लेकिन सिफ को अभी भी हमारे प्रोजेक्ट में उपयोग किया जाता है और यह संभव है कि इसका उपयोग नए कार्यों में किया जाएगा, कम से कम मेरे द्वारा। इस कहानी में, मैं ऑपरेटिंग सिफ के अपने अनुभव को साझा करूंगा, किसी तरह मैं इस विषय पर खुद को व्यक्त करूंगा कि मुझे इस समाधान के बारे में क्या पसंद नहीं है और शायद उन लोगों की मदद करें जो इसे देख रहे हैं। लगभग एक साल पहले शुरू हुई घटनाओं को जब मैं डेल ईएमसी स्केलियो लाया था, जिसे अब डेल ईएमसी वीएक्सफ़्लेक्स ओएस के रूप में जाना जाता है, ने मुझे इस लेख को लिखने के लिए प्रेरित किया।

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

विकल्प। यह 4 अंकों की संख्या है!

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

हथौड़ा:

> ceph daemon mon.a config show | wc -l 863

चमकदार:

 > ceph daemon mon.a config show | wc -l 1401

यह दो वर्षों में ~ 500 नए मापदंडों को दर्शाता है। सामान्य तौर पर, पैरामीटराइज़ेशन शांत होता है, यह ठंडा नहीं होता है कि इस सूची के 80% को समझने में कठिनाइयां होती हैं। प्रलेखन मेरे अनुमानों से वर्णन करता है ~ 20% और कुछ स्थानों पर अस्पष्ट है। अधिकांश मापदंडों के अर्थ की समझ को परियोजना के गिटब या मेलिंग सूचियों में पाया जाना चाहिए, लेकिन यह हमेशा मदद नहीं करता है।

यहाँ कई मापदंडों का एक उदाहरण है जो मुझे अभी हाल ही में दिलचस्पी थी, मैंने उन्हें एक सेफ़-गेदफ्लाई के ब्लॉग में पाया:

 throttler_perf_counter = false // enable/disable throttler perf counter osd_enable_op_tracker = false // enable/disable OSD op tracking

सर्वोत्तम प्रथाओं की भावना में कोड टिप्पणियाँ। जैसे कि, मैं शब्दों को समझता हूं और मोटे तौर पर भी कि वे किस बारे में हैं, लेकिन यह मुझे क्या देगा, यह नहीं है।

या यहाँ: Luminous में osd_op_threads चला गया और केवल स्रोतों ने नया नाम खोजने में मदद की: osd_peering_wq थ्रेड

मुझे यह भी पसंद है कि विशेष रूप से समग्र विकल्प हैं। यहाँ दोस्त दिखाता है कि rgw_num _rados_handles बढ़ाना अच्छा है :

और दूसरा दोस्त सोचता है कि> 1 असंभव है और खतरनाक भी।

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

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

 > ceph tell osd.12 injectargs '--filestore_fd_cache_size=512'

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

उदाहरण के लिए:

 > ceph tell mon.* injectargs '--mon_allow_pool_delete=true' mon.c: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart) mon.a: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart) mon.b: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)

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

VxFlex OS के बारे में क्या? सोम (वीएक्सफ़्लेक्स में यह एमडीएम है) जैसी समान प्रक्रियाएं, ओएसडी (वीएक्सफ़्लेक्स में एसडीएस) में कॉन्फ़िगरेशन फाइलें भी हैं, जिसमें सभी के लिए दर्जनों पैरामीटर हैं। सच है, उनके नाम भी कुछ नहीं कहते हैं, लेकिन अच्छी खबर यह है कि हमने कभी भी सिफ के साथ जितना जलने के लिए उनका सहारा नहीं लिया।

तकनीकी ऋण

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

गहना से पहले, सिफ प्रक्रियाओं को जड़ के रूप में चलाया गया। गहना ने फैसला किया कि उन्हें उपयोगकर्ता 'सेफ' से काम करना चाहिए और इसके लिए उन सभी निर्देशिकाओं के स्वामित्व में बदलाव की आवश्यकता है जो सिफ सेवाओं द्वारा उपयोग की जाती हैं। ऐसा लगता होगा कि यह? एक ओएसडी की कल्पना करें जो एक 2 टीबी पूर्ण क्षमता SATA चुंबकीय डिस्क की सेवा करता है। तो, इस तरह के एक डिस्क का गला, पूर्ण डिस्क उपयोग के साथ समानांतर में (विभिन्न उपनिर्देशिकाओं के लिए) 3-4 घंटे लगते हैं। उदाहरण के लिए, कल्पना कीजिए कि आपके पास ऐसे सैकड़ों डिस्क हैं। यहां तक कि अगर आप नोड्स को अपडेट करते हैं (तुरंत 8-12 डिस्क्स चांस), तो आपको एक लंबा अपडेट मिलता है, जिसमें क्लस्टर में विभिन्न संस्करणों का ओएसडी होगा और सर्वर अपडेट होने के समय डेटा की एक प्रतिकृति कम होती है। सामान्य तौर पर, हमने सोचा कि यह बेतुका था, सेफ पैकेज को फिर से बनाया गया और ओएसडी को रूट के रूप में छोड़ दिया। हमने फैसला किया कि जैसे ही हम ओएसडी में प्रवेश करेंगे या प्रतिस्थापित करेंगे, हम उन्हें एक नए उपयोगकर्ता को स्थानांतरित कर देंगे। अब हम प्रति माह 2-3 ड्राइव बदल रहे हैं और 1-2 जोड़ रहे हैं, मुझे लगता है कि हम इसे 2022 तक संभाल सकते हैं)।

CRUSH ट्यूनबल्स

CRUSH सिफ का दिल है, सब कुछ इसके चारों ओर घूमता है। यह वह एल्गोरिथ्म है जिसके द्वारा, छद्म यादृच्छिक तरीके से, डेटा स्थान का चयन किया जाता है और धन्यवाद जिसके लिए RADOS क्लस्टर के साथ काम करने वाले ग्राहक यह पता लगा लेंगे कि जिस ओएसडी के डेटा (ऑब्जेक्ट) उनकी ज़रूरत है, वे संग्रहीत हैं। CRUSH की प्रमुख विशेषता यह है कि किसी भी मेटाडेटा सर्वर की जरूरत नहीं है, जैसे कि Luster या IBM GPFS (अब स्पेक्ट्रम स्केल)। CRUSH ग्राहकों और OSD को एक दूसरे से सीधे बातचीत करने की अनुमति देता है। हालांकि, निश्चित रूप से, आदिम RADOS ऑब्जेक्ट भंडारण और फ़ाइल सिस्टम की तुलना करना मुश्किल है, जो मैंने एक उदाहरण के रूप में दिया था, लेकिन मुझे लगता है कि विचार स्पष्ट है।

CRUSH ट्यूनबल, बदले में, पैरामीटर / झंडे का एक सेट है जो CRUSH के संचालन को प्रभावित करते हैं, इसे कम से कम सिद्धांत रूप में अधिक कुशल बनाते हैं।

इसलिए, जब हैमर से गहना (प्राकृतिक रूप से परीक्षण) में अपग्रेड किया गया, तो एक चेतावनी दिखाई दी, जिसमें कहा गया था कि ट्यूनबल्स प्रोफाइल में ऐसे पैरामीटर हैं जो वर्तमान संस्करण (गहना) के लिए इष्टतम नहीं हैं और प्रोफ़ाइल को इष्टतम एक में बदलने की सिफारिश की गई है। सामान्य तौर पर, सब कुछ स्पष्ट है। डॉक कहता है कि यह बहुत महत्वपूर्ण है और यह सही तरीका है, लेकिन यह भी कहा जाता है कि डेटा स्विचिंग के बाद 10% डेटा का विद्रोह होगा। 10% - यह डरावना नहीं है, लेकिन हमने इसका परीक्षण करने का फैसला किया है। एक क्लस्टर के लिए, यह एक ठेस से लगभग 10 गुना कम है, प्रति ओएसडी पीजी की समान संख्या के साथ, परीक्षण डेटा से भरा, हमें 60% का विद्रोह मिला! उदाहरण के लिए, 100TB डेटा के साथ, उदाहरण के लिए, 60TB OSDs के बीच जाना शुरू करता है और यह निरंतर विलंबता के साथ क्लाइंट लोड के साथ है! यदि मैंने अभी तक नहीं कहा है, तो हम s3 प्रदान करते हैं और हमारे पास रात में भी rgw पर बहुत कम लोड नहीं है, जिनमें से 8 और 4 स्थैतिक वेबसाइटों के अंतर्गत हैं। सामान्य तौर पर, हमने तय किया कि यह हमारा तरीका नहीं था, खासकर नए संस्करण पर ऐसा पुनर्निर्माण करने के बाद, जिसके साथ हमने ठेस में काम नहीं किया था, कम से कम बहुत आशावादी था। इसके अलावा, हमारे पास बड़े बाल्टी इंडेक्स थे जो बहुत खराब पुनर्निर्माण कर रहे हैं और यह भी स्विचिंग प्रोफ़ाइल में देरी का कारण था। सूचकांकों के बारे में अलग से थोड़ा कम होगा। अंत में, हमने बस चेतावनी को हटा दिया और बाद में इस पर लौटने का फैसला किया।

और जब प्रोफ़ाइल को परीक्षण में बदल रहा है, तो cephfs- क्लाइंट जो कि CentOS 7.2 kernels में हैं, बंद हो गए क्योंकि वे नई प्रोफ़ाइल के नए हैशिंग एल्गोरिथ्म के साथ काम नहीं कर सके। हम उत्पादों में cephfs का उपयोग नहीं करते हैं, लेकिन अगर हम करते थे, तो यह प्रोफ़ाइल को स्विच न करने का एक और कारण होगा।

वैसे, गोदी का कहना है कि अगर विद्रोह के दौरान क्या होता है, तो यह आपके अनुरूप नहीं है, आप प्रोफ़ाइल को वापस रोल कर सकते हैं। वास्तव में, हैमर संस्करण की एक साफ स्थापित करने और गहना में अपग्रेड करने के बाद, प्रोफ़ाइल इस तरह दिखाई देती है:

 > ceph osd crush show-tunables { ... "straw_calc_version": 1, "allowed_bucket_algs": 22, "profile": "unknown", "optimal_tunables": 0, ... }

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

CRUSH व्यापार-का

जैसा कि आप जानते हैं, इस दुनिया में सब कुछ संतुलित है और नुकसान सभी फायदे पर लागू होते हैं। CRUSH का नुकसान यह है कि पीजी को बाद के समान वजन के साथ अलग-अलग OSDs में असमान रूप से वितरित किया जाता है। साथ ही, अलग-अलग पीजी को अलग-अलग गति से बढ़ने से रोकता है, जबकि हैश फ़ंक्शन गिर जाएगा। विशेष रूप से, हमारे पास 48-84% के ओएसडी उपयोग की एक सीमा है, इस तथ्य के बावजूद कि उनका आकार समान है और, तदनुसार, वजन। हम सर्वर को वजन के बराबर बनाने की भी कोशिश करते हैं, लेकिन ऐसा सिर्फ हमारी पूर्णतावाद के लिए है। और इस तथ्य के साथ कि अंजीर को डिस्क में असमान रूप से वितरित किया जाता है, सबसे बुरी बात यह है कि जब आप क्लस्टर में कम से कम एक ओएसडी की पूर्ण स्थिति (95%) तक पहुंचते हैं, तो पूरी रिकॉर्डिंग बंद हो जाती है और क्लस्टर आसानी से चला जाता है। पूरा क्लस्टर! और इससे कोई फर्क नहीं पड़ता कि क्लस्टर अभी भी अंतरिक्ष से भरा है। सब कुछ, फाइनल, बाहर आओ! यह CRUSH की एक वास्तुशिल्प विशेषता है। कल्पना कीजिए कि आप छुट्टी पर हैं, कुछ ओएसडी ने 85% (डिफ़ॉल्ट रूप से पहली चेतावनी) के निशान को तोड़ दिया, और आपके पास रिकॉर्डिंग को रोकने के लिए स्टॉक में 10% है। और सक्रिय रूप से रिकॉर्डिंग के साथ 10% इतना / लंबा नहीं है। आदर्श रूप से, इस तरह के डिजाइन के साथ, सेफ को एक ऐसे व्यक्ति की आवश्यकता होती है जो ऐसे मामलों में तैयार निर्देशों का पालन कर सकता है।

इसलिए, हमने तय किया कि इसका मतलब क्लस्टर में डेटा को असंतुलित करना है, क्योंकि कई OSD नज़दीकी निशान (85%) के करीब थे।

कई तरीके हैं:

ड्राइव जोड़ें

सबसे आसान तरीका थोड़ा बेकार है और बहुत प्रभावी नहीं है, क्योंकि डेटा स्वयं भीड़ ओएसडी से स्थानांतरित नहीं हो सकता है या आंदोलन नगण्य होगा।

ओएसडी (वजन) का स्थायी वजन बदलें

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

गैर-स्थायी OSD वजन बदलें (REWEIGHT)

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

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

आप शायद कहेंगे कि तकनीकी ऋण विशुद्ध रूप से हमारी समस्या है और मैं शायद सहमत होऊंगा। लेकिन सिफ में ठेस के साथ चार साल के लिए, हमारे पास केवल एक डाउनटाइम एस 3 दर्ज था, जो पूरे 1 घंटे तक चला। और फिर, समस्या RADOS में नहीं थी, लेकिन RGW में, जिसने अपने डिफ़ॉल्ट 100 धागे टाइप किए, तंग तंग किया और अधिकांश उपयोगकर्ताओं ने अनुरोधों को पूरा नहीं किया। यह अभी भी हैमर पर था। मेरी राय में, यह एक अच्छा संकेतक है और यह इस तथ्य के कारण हासिल किया जाता है कि हम अचानक आंदोलन नहीं करते हैं और सिफ पर सब कुछ के बारे में संदेह करते हैं।

जंगली जी.सी.

जैसा कि आप जानते हैं, डिस्क से डेटा हटाना सीधे काम की मांग है और उन्नत प्रणालियों में, हटाने में देरी हो रही है या बिल्कुल नहीं किया गया है। सिफ भी एक उन्नत प्रणाली है, और आरजीडब्ल्यू के मामले में, जब एक एस 3 ऑब्जेक्ट को हटा दिया जाता है, तो इसी RADOS ऑब्जेक्ट्स को डिस्क से तुरंत हटा नहीं दिया जाता है। RGW s3 ऑब्जेक्ट्स को हटाए गए के रूप में चिह्नित करता है, और एक अलग जीसी-स्ट्रीम सीधे RADOS पूल से ऑब्जेक्ट हटाता है और तदनुसार, डिस्क से स्थगित कर दिया जाता है। ल्यूमिनस को अपडेट करने के बाद, जीसी के व्यवहार में विशेष रूप से बदलाव आया, यह अधिक आक्रामक तरीके से काम करना शुरू कर दिया, हालांकि जीसी पैरामीटर समान रहे। स्पष्ट रूप से, मेरा मतलब है कि हमने जीसी को विलंबता कूदने के लिए सेवा की बाहरी निगरानी पर काम करना शुरू किया। यह rgw.gc. पूल में एक उच्च IO के साथ था लेकिन जिस समस्या का हम सामना कर रहे हैं वह सिर्फ IO की तुलना में बहुत अधिक महाकाव्य है। जब जीसी चल रहा होता है, तो फॉर्म के बहुत सारे लॉग उत्पन्न होते हैं:

 0 <cls> /builddir/build/BUILD/ceph-12.2.5/src/cls/rgw/cls_rgw.cc:3284: gc_iterate_entries end_key=1_01530264199.726582828

जहां शुरुआत में 0 लॉगिंग स्तर है जिस पर यह संदेश छपा है। जैसा कि यह था, शून्य से नीचे कम लॉगिंग कहीं नहीं है। नतीजतन, ~ 1 जीबी लॉग एक घंटे में एक ओएसडी द्वारा उत्पन्न किया गया था, और सब कुछ ठीक हो जाता था यदि सेफ नोड्स डिस्क रहित नहीं होते थे ... हम ओएस को पीएक्सई के माध्यम से सीधे मेमोरी में लोड करते हैं और सिस्टम विभाजन के लिए स्थानीय डिस्क या एनएफएस, एनबीडी का उपयोग नहीं करते हैं। (/)। यह स्टेटलेस सर्वर को बदल देता है। रिबूट के बाद, पूरे राज्य को स्वचालन द्वारा लुढ़का हुआ है। यह कैसे काम करता है, मैं किसी तरह एक अलग लेख में वर्णन करूंगा, अब यह महत्वपूर्ण है कि 6 जीबी मेमोरी "/" के लिए आवंटित की जाती है, जिनमें से ~ 4 आमतौर पर मुफ्त है। हम सभी लॉग ग्रेगल में भेजते हैं और एक आक्रामक लॉग रोटेशन पॉलिसी का उपयोग करते हैं और आमतौर पर डिस्क / रैम ओवरफ्लो के साथ किसी भी समस्या का अनुभव नहीं करते हैं। लेकिन हम इसके लिए तैयार नहीं थे, 12 ओएसडी के साथ, "/" सर्वर बहुत जल्दी से भर गया, समय पर उपस्थित लोगों ने ज़ैबिक्स में ट्रिगर का जवाब नहीं दिया और ओएसडी बस एक लॉग लिखने में असमर्थता के कारण बंद करना शुरू कर दिया। नतीजतन, हमने जीसी की तीव्रता कम कर दी, क्योंकि टिकट शुरू नहीं हुआ था यह पहले से ही था, और हमने एक स्क्रिप्ट को क्रोन में जोड़ा, जिसमें हम ओएसडी लॉग्स को थरथराने के लिए मजबूर करते हैं जब एक निश्चित राशि को लॉगोटेट के इंतजार के बिना पार किया जाता है। वैसे, लॉगिंग का स्तर बढ़ा हुआ था।

प्लेसमेंट समूह और प्रशंसनीय स्केलेबिलिटी

मेरी राय में, पीजी को समझना सबसे कठिन अमूर्तता है। CRUSH को अधिक प्रभावी बनाने के लिए PG की आवश्यकता है। पीजी का मुख्य उद्देश्य संसाधन की खपत को कम करने, उत्पादकता और मापनीयता को बढ़ाने के लिए समूह की वस्तुओं को देना है। वस्तुओं को सीधे, व्यक्तिगत रूप से संबोधित करना, उन्हें पीजी में शामिल किए बिना बहुत महंगा होगा।

पीजी की मुख्य समस्या एक नए पूल के लिए उनकी संख्या निर्धारित कर रही है। सिफ ब्लॉग से:

"अपने क्लस्टर के लिए पीजी की सही संख्या चुनना थोड़ी काली कला है-और एक दुःस्वप्न है।"

यह हमेशा एक विशेष स्थापना के लिए बहुत विशिष्ट है और बहुत अधिक विचार और गणना की आवश्यकता होती है।

मुख्य सिफारिशें:

ओएसडी पर बहुत सारे पीजी खराब हैं, उनके रखरखाव और ब्रेक के लिए संसाधनों का ओवरस्पीडिंग होगा / रिबैलेंस / रिकवरी के दौरान।
OSD पर कुछ PG खराब हैं, परफॉर्मेंस खराब होगी और OSD असमान रूप से आबाद हो जाएंगे।
पीजी की संख्या 2 डिग्री होनी चाहिए। इससे "CRUSH की शक्ति" प्राप्त करने में मदद मिलेगी।

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

"एक पूल के पीजी काउंट को बढ़ाना सीफ़ क्लस्टर में सबसे प्रभावी घटनाओं में से एक है, और यदि संभव हो तो उत्पादन समूहों के लिए बचा जाना चाहिए।"

इसलिए, यदि संभव हो, तो आपको भविष्य के बारे में तुरंत सोचने की आवश्यकता है।

एक वास्तविक उदाहरण।

14x2 टीबी ओएसडी के साथ 3 सर्वरों का एक समूह, कुल 42 ओएसडी। प्रतिकृति 3, उपयोगी स्थान ~ 28 टीबी। S3 के तहत उपयोग किए जाने के लिए, आपको डेटा पूल और इंडेक्स पूल के लिए PG की संख्या की गणना करने की आवश्यकता है। आरजीडब्ल्यू अधिक पूल का उपयोग करता है, लेकिन दोनों प्राथमिक हैं।

हम पीजी कैलकुलेटर में जाते हैं (ऐसा कैलकुलेटर है), हम ओएसडी पर अनुशंसित 100 पीजी के साथ विचार करते हैं, हमें केवल 1312 पीजी मिलते हैं। लेकिन सब कुछ इतना सरल नहीं है: हमारे पास एक परिचयात्मक है - क्लस्टर निश्चित रूप से एक वर्ष के भीतर तीन बार बढ़ेगा, लेकिन लोहे को थोड़ी देर बाद खरीदा जाएगा। हम "लक्ष्य पीजी प्रति ओएसडी" को तीन गुना बढ़ाकर 300 कर देते हैं और हमें 4480 पीजी मिलता है।

संबंधित पूल के लिए PGs की संख्या निर्धारित करें - हमें एक चेतावनी मिलती है: बहुत सारे PG प्रति OSD ... पहुंचे। 200 (Luminous) की सीमा के साथ OSD पर ~ 300 PG प्राप्त किया। वैसे यह 300 हुआ करता था। और सबसे दिलचस्प बात यह है कि सभी अनावश्यक पीजी को पियरिंग की अनुमति नहीं है, अर्थात यह केवल एक चेतावनी नहीं है। नतीजतन, हम मानते हैं कि हम सब कुछ सही कर रहे हैं, सीमाएं बढ़ा रहे हैं, चेतावनी को बंद कर रहे हैं, और आगे बढ़ रहे हैं।

एक और वास्तविक उदाहरण अधिक दिलचस्प है।

एस 3, 152 टीबी प्रयोग करने योग्य मात्रा, 1.81 टीबी पर 252 ओएसडी, ओएसडी पर ~ 105 पीजी। क्लस्टर धीरे-धीरे बढ़ता गया, हमारे देश में नए कानूनों के साथ सब कुछ ठीक था जब तक कि 1 पीबी, यानी + ~ 850 टीबी के विकास की आवश्यकता थी, और साथ ही आपको प्रदर्शन बनाए रखने की आवश्यकता थी, जो अब एस 3 के लिए बहुत अच्छा है। मान लीजिए कि हम 6 (5.7 वास्तविक) टीबी के डिस्क लेते हैं और प्रतिकृति 3 को ध्यान में रखते हुए हम + 447 ओएसडी प्राप्त करते हैं। वर्तमान को ध्यान में रखते हुए, हम 37 पीजी के साथ 699 ओएसडी प्राप्त करते हैं, और यदि हम अलग-अलग वजनों को ध्यान में रखते हैं, तो यह पता चलता है कि पुराने ओएसडी में केवल एक दर्जन पीजी हैं। तो आप मुझे बताइए कि यह कितने धीरज से काम करेगा? पीजी की एक अलग संख्या के साथ एक क्लस्टर का प्रदर्शन कृत्रिम रूप से मापना काफी मुश्किल है, लेकिन मैंने जो परीक्षण किए, वे बताते हैं कि इष्टतम प्रदर्शन के लिए यह 50 पीजी से 2 टीबी ओएसडी के लिए आवश्यक है। और आगे की वृद्धि के बारे में क्या? पीजी की संख्या में वृद्धि के बिना, आप पीजी की मैपिंग के लिए ओएसडी 1: 1 पर जा सकते हैं। शायद मुझे कुछ समझ में नहीं आ रहा है?

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

मुझे खुशी है कि सेफ के डेवलपर्स समझते हैं कि पीजी उपयोगकर्ता के लिए एक जटिल और अतिश्योक्तिपूर्ण अमूर्तता है और वह इसके बारे में नहीं जानना बेहतर है।

"चमकदार में हमने अपने क्लस्टर को ड्राइव करने के लिए अंत में सबसे आम तरीकों में से एक को खत्म करने के लिए बड़े कदम उठाए हैं, और आगे देखते हुए हम अंततः पीजी को पूरी तरह से छिपाने का लक्ष्य रखते हैं ताकि वे कुछ ऐसा न करें जो अधिकांश उपयोगकर्ताओं को कभी भी जानना होगा या के बारे में सोचो ”।

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

"SP1 की प्रतीक्षा करने की आवश्यकता है"

"सफलता" की एक और कहानी। जैसा कि आप जानते हैं, RADOS सबसे प्रमुख की-वैल्यू स्टोरेज है। S3, RADOS के शीर्ष पर लागू किया गया है, यह भी आदिम है, लेकिन अभी भी थोड़ा अधिक कार्यात्मक है। , S3 . , , RGW . — RADOS-, OSD. . , . OSD down. , , . , scrub' . , - 503, .

Bucket Index resharding — , (RADOS-) , , OSD, .

, , Jewel ! Hammer, .. -. ?

Hammer 20+ , , OSD Graylog , . , .. IO . Luminous, .. . Luminous, , . , . IO index-, , . , IO , . , … ; , :

, . , .. , .

, Hammer->Jewel - . OSD - . , OSD .

— , , . Hammer s3, . , . , , etag, body, . . , . Suspend . "" . , .

, 2 — , Cloudmouse. , Ceph, , .

vxFlex OS 2 . , . , . , . , , , Dell EMC.

. , ? . , . , Ceph, vxFlex . - . , .

9 ceph-devel : , CPU ( Xeon' !) IOPS All-NVMe Ceph 12.2.7 bluestore.

, , "" Ceph . ( Hammer) Ceph , s3 . , ScaleIO Ceph RBD . Ceph, — CPU. RDMA InfiniBand, jemalloc . , 10-20 , iops, io, Ceph . vxFlex . — Ceph system time, scaleio — io wait. , bluestore, , , -, , Ceph. ScaleIO . , , Ceph Dell EMC.

, , PG. (), IO. - PG IO, , . , nearfull. , .

vxFlex - , . ( ceph-volume), , .