नेटप्प - रियलिटी बनाम मार्केटिंग

शुभ दिन

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

कौन परवाह करता है - बिल्ली में आपका स्वागत है।

यह सब कैसे शुरू हुआ

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

क्या कार्य थे

1. सक्रिय-सक्रिय मोड में दूरस्थ साइटें (वहां ठिकानों के हिस्से के अर्थ में, कुछ वहां, आरएसी नहीं)
2. पार्टियों में से एक के पतन की स्थिति में ओरेकल डेटा हानि - 0 सेकंड
3. डेटाबेस को दूसरी तरफ स्विच करने का समय - क्लस्टर सॉफ्टवेयर (वेरिटास) का उपयोग करके 5 मिनट तक
4. Vmware वर्चुअल मशीनों की निरंतर उपलब्धता

आखिरकार क्या हुआ

और यह वर्चुअल मशीनों के लिए MetroCluster (SyncMirror) विन्यास में डेटाबेस के लिए दो साइटों पर 2 FAS6280 सिस्टम, प्रत्येक में 2 नियंत्रक, SnapMirror प्रतिकृति + एक FAS3270 सिस्टम निकला । सभी प्रणालियों पर ओन्टैप संस्करण 8.1.2 है। हर जगह - FlexVol और RAIDDP ।

मैं तुरंत कहूंगा - FAS3270 मेट्रो क्लस्टर में कोई समस्या नहीं है। निश्चित रूप से। निश्चित रूप से। यह काम करता है और ठीक उसी तरह कार्य करता है जो इसे सौंपा गया था, लगभग 1000 आभासी मशीनों को खींचता है, जो साइटों के बीच आधे हिस्से में विभाजित है। कोई समस्या और नुकसान नहीं। यदि नियंत्रक रिबूट में चला जाता है, तो वर्चुअल मशीनें I / O पर 15 सेकंड के लिए फ्रीज हो जाती हैं और काम करना जारी रखती हैं जैसे कि कुछ भी नहीं हुआ था। जब नियंत्रक रिटर्न समय की एक ही राशि के बारे में लेता है तो स्विचिंग रिवर्स। इस प्रणाली के साथ, मैं सभी 200% से संतुष्ट हूं। लेकिन ईमानदार होने के लिए, इस पर लोड करना अभी भी लगभग 50% है और डिस्क I / O के लिए लगभग 25-30% (75 सक्रिय डिस्क / साइड पर 4500 डिस्क आयोप्स)। जैसा कि अभ्यास से पता चलता है, यह वह है जो उसे समस्याओं के बिना काम करने की अनुमति देता है।

नेटएप के साथ मिलकर, FAS6280 के लिए एक विनिर्देश तैयार किया गया था, साइज़िंग को अंजाम दिया गया था, और हमने उन सभी नुकसानों पर चर्चा की जो हमारी समस्याओं की स्थिति में उत्पन्न हो सकते हैं। हमें आश्वासन दिया गया था कि जैसा हम चर्चा करेंगे वैसा ही सब कुछ चलेगा। और हमने निम्नलिखित चित्र पर चर्चा की:

• प्रत्येक डेटाबेस में 3 खंड होते हैं: डेटा + इंडेक्स, संग्रह, फिर से करें + पूर्ववत करें।
• 20 डेटाबेस को 4 नियंत्रकों में विभाजित किया गया है, नियंत्रक की एक जोड़ी के बीच प्रतिकृति।
• 2 सेक्शन, डेटा + आर्क - एसिंक्रोनस स्नैपचिरर, प्रति मिनट एक बार। Redo सेक्शन एक सिंक्रोनस स्नेपिरर है।
• विकास को सभी 4 नियंत्रकों पर एक पतली परत के साथ लिटाया जाता है।

लॉन्च के समय, प्रत्येक नियंत्रक के लिए साइट पर निपटान लगभग 40% था, और डिस्क जल उत्पादन द्वारा उपयोग 20% था। जिससे हम यह निष्कर्ष निकाल सकते हैं कि सिस्टम सिर्फ गड़बड़ कर रहे थे।
अब, ऑन-साइट रीसाइक्लिंग लगभग 85% है, डिस्क पर औसतन लगभग 70%, 90% चोटियों पर है। यदि संख्या में - 100% उपयोग, यह 32,500 डिस्क संचालन प्रति नियंत्रक है। डिस्क संचालन! = Nfs पर iops की संख्या।

समस्या एक - सिंक्रोनस SnapMirror

वादा - नियंत्रक के लिए तुल्यकालिक प्रतिकृति के 30 सत्र। वह सब है। संकेत किया गया है के अलावा कोई विवरण नहीं - तुल्यकालिक प्रतिकृति विलंबता नेटवर्क के लिए बहुत संवेदनशील है। लोड दिशा के बारे में कोई विवरण नहीं।

वास्तव में, अलग-अलग दिशाओं में निर्देशित 2 सत्रों के साथ भी तुल्यकालिक प्रतिकृति टूट जाती है (हमें एहसास हुआ कि यह लगभग 2 महीने बाद कुंजी हो सकता है)।
ऐसा लग रहा था:

[fas6280a_1:wafl.nvlog.sm.sync.abort:notice]: NVLOG synchronization aborted for snapmirror source VOL_prod_ru, reason='Out of NVLOG files' [fas6280a_1:snapmirror.sync.fail:notice]: Synchronous SnapMirror from fas6280a_1:VOL_prod_ru to fas6280a_2:VOL_prod_ru failed. 

उन्होंने मामला खोला, सीधे नेटऐप इंजीनियरों से सलाह ली - फैसला हमेशा एक जैसा था - आपको नेटवर्क की समस्या है। हमने इस विषय पर अपना खुद का शोध किया, इस पर लगभग एक महीने का समय बिताया - हमारा फैसला, नेटवर्क क्रम में है, लगभग 0.5ms के भार के तहत विलंबता है और छोड़ नहीं है। NetApp की गहराई से एक तकनीकी द्वारा समाधान का संकेत दिया गया था - उन्होंने कहा कि इसे अलग-अलग दिशाओं में काम नहीं करना चाहिए, क्योंकि कुछ खुद कंसिस्टेंसी प्वाइंट (सीपी) तंत्र के साथ जुड़ा हुआ है, हम अभी भी विवरणों को नहीं समझते थे, लेकिन यह एक दिशा में प्रतिकृति तैनात करने के लायक था। - सब कुछ अच्छा हो गया।
चूँकि यह हमारे अनुरूप नहीं था, हमने 4 डिस्क अलमारियाँ खरीदीं और सभी Redo / Undo को FAS3270 में, मेट्रो क्लस्टर में ले गए, और एक क्लास के रूप में सिंक्रोनस प्रतिकृति समस्याओं के बारे में भूल गए। सच है, वर्चुअल मशीनों से स्पस्मोडिक लोड, Redo के लिए प्रतिक्रिया समय के लिए उच्च प्रोसेसर लोड और उच्च आवश्यकताओं ने हमें इस निर्णय पर रहने की अनुमति नहीं दी, लेकिन यह एक अलग कहानी है।

समस्या दो - एसिंक्रोनस SnapMirror

यहां सब कुछ सरल है - यदि हम एक मिनट में एक बार सिंक्रनाइज़ेशन सेट करते हैं, तो हमें एक सत्र मिलता है जो कभी समाप्त नहीं होता है, क्योंकि डेटा को आवंटित समय में अतिप्रवाह करने का समय नहीं है, परिवर्तन बहुत लंबा माना जाता है। हम प्रत्येक खंड के लिए 5 मिनट के समय पर 1 मिनट के लिए शिफ्ट हुए। जब डिस्क उपयोग के 80% तक लोड बढ़ गया है, तो हमारे पास लगातार 15-20 मिनट के आदेश के सबसे भारी डेटाबेस के लिए एक सिंक्रनाइज़ेशन अंतराल है, चरम लोड समय पर (उदाहरण के लिए, बैकअप, 90-95% उपयोग डिस्क), अंतराल अनिश्चित काल तक बढ़ जाता है। जिससे यह अनुसरण करता है कि 5 मिनट में कोई स्विचिंग नहीं हो सकती है, क्योंकि केवल सबसे अच्छा मामले में परिवर्तन वापस रोल कर रहा है प्रतिकृति के उलट होने के बाद 20 मिनट + रिवर्स पुनरुत्थान है, जो बड़े विभाजन पर बहुत लंबा समय लेता है, वही सबसे अच्छा मामले में 20 मिनट।

समस्या तीन - QOS, या NetApp शब्दावली - FlexShare

सिस्टम शेड्यूलर को नियंत्रित करता है, वॉल्यूम स्तर पर काम करता है, आपको सिस्टम की प्रक्रियाओं के सापेक्ष अन्य वॉल्यूम के सापेक्ष प्रत्येक वॉल्यूम के लिए 1 से 99 तक प्राथमिकताएं निर्धारित करने की अनुमति देता है। विवरण बहुत खूबसूरत है, ऐसा लगता है कि सब कुछ 2x2 की तरह है। वास्तव में:

• आप एक वॉल्यूम के लिए ऊपरी बार को सीमित नहीं कर सकते हैं, ठीक है, अगर अचानक कुछ एप्लिकेशन क्रैश हो जाता है और I / O को बहुत पीड़ा देना शुरू कर देता है, तो हर कोई पीड़ित होगा।
• इससे कोई फर्क नहीं पड़ता कि प्राथमिकता क्या सेट की गई है, बिक्री के लिए कहें 99, विकास के लिए - 1, विकास लोड अभी भी बिक्री को प्रभावित करेगा। लेकिन हां, यदि लोड स्थिर है, तो विकास खंड की प्रतिक्रिया समय थोड़ा खराब होगा।
• यदि विकास भार स्थिर नहीं है, लेकिन स्पस्मोडिक है, तो प्राथमिकता बिल्कुल काम नहीं करती है। उसे अनुकूल होने के लिए समय चाहिए।
• प्राथमिकता SnapMirror के निष्पादन को गति नहीं देती है, चाहे सिस्टम कितना भी ऊंचा हो।
• प्राथमिकता प्रणाली की समग्र विलंबता को बढ़ाती है, लेकिन बहुत अधिक नहीं। केवल बहुत अधिक भार पर ध्यान देने योग्य।
• बहुत उच्च नियंत्रक लोड के साथ, अधिकांश कमांड निष्पादित करना असंभव है, परिणाम लॉन्च होने के 3-5 मिनट बाद आता है, उदाहरण के लिए, आप प्रतिकृति स्थिति भी नहीं देख सकते हैं, और यह क्लस्टर सॉफ़्टवेयर के संचालन को रोकता है।

यह इसलिए है क्योंकि बाद में प्राथमिकता हमारे सिस्टम पर बंद हो जाती है। उन्होंने इस मुद्दे पर एक मामला खोला - कोई परिणाम नहीं है।

चौथी समस्या इकाई पर मुक्त स्थान है (एक स्थान में संयुक्त कई छापे समूहों का एक सेट) ।

जो लोग पिछले वर्षों के नेटएप में आए हैं, वे शायद जानते हैं कि अगर कुल मिलाकर 90% से अधिक डेटा भरा हो, तो सिस्टम बेहद आलसी हो जाता है और काम नहीं करना चाहता है। मार्केटर्स इस बात पर ज़िद करते हैं कि इस समस्या को वर्जन 8.1 (या हो सकता है कि 8.0 के बाद से भी पूरी तरह से समाप्त कर दिया गया हो, मुझे बिल्कुल याद नहीं है, ईमानदार होना)। वास्तव में - एक पूर्ण झूठ। हमने जगह का ध्यान नहीं रखा, हमने यूनिट को 93% से भर दिया - यही है, हैलो। एक पूरे के रूप में सिस्टम का प्रतिक्रिया समय लगभग 2 गुना बढ़ गया है। और यह प्रदान किया जाता है कि हम कटौती, संपीड़न, और अन्य अच्छाइयों का उपयोग नहीं करते हैं, केवल पतले प्रावधान हैं। 85% तक की जगह खाली करने के दौरान ही सिस्टम जारी किया गया था। बिंदु।
इसके अलावा, 85-95% तक कुल को भरने की कोशिश करें, अलग-अलग दिशाओं में एक दर्जन स्नैपशॉट सत्र बनाएं, सिस्टम को 80% I / O के साथ लोड करें, और फिर कुल मात्रा का 1/5 भाग हटा दें। परिणाम - एक घंटे से अधिक समय तक निष्क्रिय डेटाबेस इस तथ्य के कारण कि सिस्टम स्वयं में चला गया है, सभी वर्गों के लिए प्रतिक्रिया समय 300ms से 5s तक था। मैंने कंसोल पर कोई प्रतिक्रिया नहीं दी, मैंने भी नियंत्रक को रिबूट करने के बारे में सोचा था, लेकिन सबसे पहले हमने तुरंत इसे से सभी लोड को दूर करना शुरू कर दिया, जिससे प्राप्तकर्ता की ओर से मार डाला, और कुछ समय बाद सिस्टम ठीक होना शुरू हो गया। नेटएप की सिफारिश - एक समय में एक फाइल को मार डालो, वॉल्यूम नष्ट के माध्यम से तुरंत 12tb को न हटाएं।

पांचवीं समस्या - 2 इकाइयाँ

लेकिन मज़ाक यह है कि यदि आपके पास एक इकाई पर 100% भरी हुई डिस्क है, तो 10% के भार वाली दूसरी इकाई काम करने से इंकार कर देगी, और वहाँ विलंबता 100% के साथ एक इकाई के लिए तुलनीय होगी। और यह सीधे संबंधित है कि कैसे डेटा नेटएपी को लिखा जाता है।
तथ्य यह है कि, शास्त्रीय ब्लॉक स्टोरेज सिस्टम के विपरीत, जो डेटा को डिस्क (राइट-थ्रू) पर सीधे ड्राइव कर सकता है, यदि ब्लॉक का आकार एक निश्चित मूल्य (आमतौर पर 16kb या 32kb, लेकिन कॉन्फ़िगर किया जा सकता है) से अधिक है, तो NetApp कभी भी ऐसा नहीं करता है। अनिवार्य रूप से हमेशा WAFL की प्रकृति के कारण राइट-बैक लिखता है। यह वही है जो नियंत्रकों, यहां तक ​​कि छोटे मॉडलों पर बड़ी मात्रा में मेमोरी का कारण बनता है। और यही वह कारण है जो रिकॉर्डिंग के लिए सुपर-लो लेटेंसी का कारण बनता है, जो सिस्टम के भारी लोड न होने पर नेटएपी पर गर्व करता है। कैश सभी इकाइयों के लिए समान है, यह ओवरफ्लो हो जाता है, एक अनलोडेड यूनिट तक भी लिखना असंभव हो जाता है।

निष्कर्ष - यदि आप सिस्टम पर एक स्थिर कम विलंबता चाहते हैं, तो 60% से अधिक डिस्क लोड न करें। ठीक है, अगर आपके पास एक ही ड्राइव है, तो एक अलग इकाई बनाने का कोई मतलब नहीं है।

छोटे निष्कर्ष

• यदि 50 किमी तक DR समाधान बनाने का कार्य है, तो MetroCluster लें और इसके बारे में भी न सोचें। मूल्य अंतर हास्यास्पद है, मेजबानों के लिए पूरी तरह से पारदर्शी है। Minuses की - केंद्रों के बीच एक अलग अंधेरा प्रकाशिकी अत्यधिक वांछनीय है। लेकिन वास्तव में यह संसाधनों को विभाजित करते समय काम करता है, इसकी जाँच की जाती है। आप एक मौजूदा SAN में फिट हो सकते हैं, लेकिन मैंने आपको यह नहीं बताया।
• यदि कम विलंबता प्राप्त करने का कार्य है - ड्राइव को 50-60% (3.5 "SAS डिस्क पर 90-110 iops) से अधिक लोड न होने दें।
• स्पस्मोडिक लोडिंग से बचने की कोशिश करें, लोड जितना अधिक रैखिक होगा, उतना ही आसान नेटएप इसे पचाएगा।
• विभिन्न ब्लॉकों से लोडिंग से बचने की कोशिश करें। WAFL बेहद चिंताजनक है।
• यूनिट डेटा के 85% से अधिक लोड की अनुमति न दें।
• वारंटी के तहत हार्डवेयर बदलने के लिए तैयार हो जाओ। बहुत कुछ। बार-बार। लेकिन यह अब प्रवेश स्तर और मध्यवर्ती स्तर के सिस्टम के सभी निर्माताओं को प्रभावित कर रहा है।

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