तुमच्या उच्च उपलब्धता स्टोरेज (99,9999%) वर सॉफ्टवेअर सत्यापित करणे का महत्त्वाचे आहे

कोणती फर्मवेअर आवृत्ती सर्वात "योग्य" आणि "कार्यरत" आहे? जर स्टोरेज सिस्टम 99,9999% च्या फॉल्ट टॉलरन्सची हमी देत ​​असेल, तर याचा अर्थ असा आहे की सॉफ्टवेअर अपडेट न करताही ती अखंडपणे काम करेल? किंवा, त्याउलट, जास्तीत जास्त दोष सहिष्णुता प्राप्त करण्यासाठी, आपण नेहमी नवीनतम फर्मवेअर स्थापित केले पाहिजे? आम्ही आमच्या अनुभवावर आधारित या प्रश्नांची उत्तरे देण्याचा प्रयत्न करू.

लहान परिचय

आम्ही सर्वजण समजतो की सॉफ्टवेअरची प्रत्येक आवृत्ती, मग ती ऑपरेटिंग सिस्टीम असो किंवा डिव्हाइससाठी ड्रायव्हर असो, त्यात अनेकदा दोष/बग आणि इतर "वैशिष्ट्ये" असतात जी उपकरणाच्या सेवा आयुष्याच्या समाप्तीपर्यंत "दिसत नाहीत" किंवा "उघड" असतात. फक्त काही विशिष्ट परिस्थितीत. अशा बारकावेंची संख्या आणि महत्त्व सॉफ्टवेअरच्या जटिलतेवर (कार्यक्षमता) आणि त्याच्या विकासादरम्यान चाचणीच्या गुणवत्तेवर अवलंबून असते. 

बर्‍याचदा, वापरकर्ते "फॅक्टरीमधील फर्मवेअर" वर राहतात (प्रसिद्ध "हे कार्य करते, म्हणून त्यात गोंधळ करू नका") किंवा नेहमी नवीनतम आवृत्ती स्थापित करतात (त्यांच्या समजुतीनुसार, नवीनतम म्हणजे सर्वात कार्यरत). आम्ही एक वेगळा दृष्टिकोन वापरतो - आम्ही वापरलेल्या प्रत्येक गोष्टीसाठी रिलीझ नोट्स पाहतो mClouds ढग मध्ये उपकरणे आणि प्रत्येक उपकरणासाठी योग्य फर्मवेअर काळजीपूर्वक निवडा.

ते म्हणतात त्याप्रमाणे आम्ही अनुभवाने या निष्कर्षापर्यंत पोहोचलो. आमच्या ऑपरेशनचे उदाहरण वापरून, आम्ही तुम्हाला सांगू की स्टोरेज सिस्टमच्या 99,9999% विश्वासार्हतेचा काही अर्थ नाही जर तुम्ही सॉफ्टवेअर अपडेट्स आणि वर्णनांचे त्वरित निरीक्षण केले नाही. आमची केस कोणत्याही विक्रेत्याकडील स्टोरेज सिस्टमच्या वापरकर्त्यांसाठी योग्य आहे, कारण अशीच परिस्थिती कोणत्याही निर्मात्याकडील हार्डवेअरसह होऊ शकते.

नवीन स्टोरेज सिस्टम निवडत आहे

गेल्या वर्षाच्या शेवटी, आमच्या इन्फ्रास्ट्रक्चरमध्ये एक मनोरंजक डेटा स्टोरेज सिस्टम जोडली गेली: IBM FlashSystem 5000 लाइनचे एक कनिष्ठ मॉडेल, ज्याला खरेदीच्या वेळी Storwize V5010e म्हणतात. आता ते FlashSystem 5010 या नावाने विकले जाते, परंतु प्रत्यक्षात ते समान स्पेक्ट्रम Virtualize सह हार्डवेअर बेस आहे. 

युनिफाइड मॅनेजमेंट सिस्टमची उपस्थिती, तसे, IBM FlashSystem मधील मुख्य फरक आहे. तरुण मालिकेच्या मॉडेल्ससाठी, ते अधिक उत्पादनक्षम मॉडेल्सपेक्षा व्यावहारिकदृष्ट्या वेगळे नाही. विशिष्ट मॉडेल निवडणे केवळ योग्य हार्डवेअर बेस प्रदान करते, ज्याची वैशिष्ट्ये एक किंवा दुसरी कार्यक्षमता वापरणे किंवा उच्च पातळीचे स्केलेबिलिटी प्रदान करणे शक्य करते. सॉफ्टवेअर हार्डवेअर ओळखते आणि या प्लॅटफॉर्मसाठी आवश्यक आणि पुरेशी कार्यक्षमता प्रदान करते.

IBM फ्लॅशसिस्टम 5010

आमच्या मॉडेल 5010 बद्दल थोडक्यात. ही एक एंट्री-लेव्हल ड्युअल-कंट्रोलर ब्लॉक स्टोरेज सिस्टम आहे. हे NLSAS, SAS, SSD डिस्क सामावून घेऊ शकते. यामध्ये NVMe प्लेसमेंट उपलब्ध नाही, कारण हे स्टोरेज मॉडेल NVMe ड्राइव्हच्या कार्यक्षमतेची आवश्यकता नसलेल्या समस्यांचे निराकरण करण्यासाठी स्थित आहे.

संग्रहण प्रणाली संग्रहित माहिती किंवा डेटा ज्यामध्ये वारंवार प्रवेश केला जात नाही ते सामावून घेण्यासाठी खरेदी केली गेली. म्हणून, त्याच्या कार्यक्षमतेचा मानक संच आमच्यासाठी पुरेसा होता: टायरिंग (सुलभ टियर), पातळ तरतूद. 1000-2000 IOPS च्या स्तरावर NLSAS डिस्क्सवरील कार्यप्रदर्शन देखील आमच्यासाठी खूप समाधानकारक होते.

आमचा अनुभव - आम्ही फर्मवेअर वेळेवर कसे अपडेट केले नाही

आता सॉफ्टवेअर अपडेटबद्दल. खरेदीच्या वेळी, सिस्टममध्ये आधीपासूनच स्पेक्ट्रम व्हर्च्युअलाइज सॉफ्टवेअरची थोडी जुनी आवृत्ती होती, म्हणजे, 8.2.1.3.

आम्ही फर्मवेअर वर्णनांचा अभ्यास केला आणि अद्यतनाची योजना केली 8.2.1.9. जर आम्ही थोडे अधिक कार्यक्षम झालो असतो, तर हा लेख अस्तित्त्वात नसता - अधिक अलीकडील फर्मवेअरवर बग आला नसता. मात्र, काही कारणांमुळे या प्रणालीचे अपडेट पुढे ढकलण्यात आले.

परिणामी, दुव्यावरील वर्णनाप्रमाणे, थोडासा अद्यतन विलंबाने अत्यंत अप्रिय चित्र निर्माण केले: https://www.ibm.com/support/pages/node/6172341. 

होय, त्या आवृत्तीच्या फर्मवेअरमध्ये तथाकथित APAR (अधिकृत प्रोग्राम विश्लेषण अहवाल) HU02104 संबंधित होता. ते खालीलप्रमाणे दिसते. लोड अंतर्गत, विशिष्ट परिस्थितीत, कॅशे ओव्हरफ्लो होण्यास सुरवात होते, त्यानंतर सिस्टम संरक्षक मोडमध्ये जाते, ज्यामध्ये ते पूलसाठी I/O अक्षम करते. आमच्या बाबतीत, RAID 3 मोडमध्ये RAID गटासाठी 6 डिस्क डिस्कनेक्ट केल्यासारखे दिसते. डिस्कनेक्शन 6 मिनिटांसाठी होते. पुढे, पूलमधील व्हॉल्यूममध्ये प्रवेश पुनर्संचयित केला जातो.

IBM Spectrum Virtualize च्या संदर्भात तार्किक घटकांची रचना आणि नामकरण कोणाला माहीत नसेल, तर मी आता थोडक्यात स्पष्टीकरण देईन.

स्टोरेज सिस्टम लॉजिकल घटकांची रचना

MDisk (व्यवस्थापित डिस्क) नावाच्या गटांमध्ये डिस्क गोळा केल्या जातात. MDisk हे क्लासिक RAID (0,1,10,5,6) किंवा वर्च्युअलाइज्ड असू शकते - DRAID (वितरित RAID). DRAID वापरल्याने तुम्हाला अॅरेची कार्यक्षमता वाढवता येते, कारण... गटातील सर्व डिस्क वापरल्या जातील, आणि पुनर्बांधणीची वेळ कमी केली जाईल, कारण केवळ काही ब्लॉक्स पुनर्संचयित करणे आवश्यक आहे, आणि अयशस्वी डिस्कमधील सर्व डेटा नाही.

RAID-5 मोडमध्ये डिस्ट्रिब्युटेड RAID (DRAID) वापरताना डिस्कवर डेटा ब्लॉक्सचे वितरण.

आणि हा आकृती एक डिस्क अयशस्वी झाल्यास DRAID पुनर्बांधणी कशी कार्य करते याचे तर्क दर्शविते:

जेव्हा एक डिस्क अयशस्वी होते तेव्हा DRAID पुनर्बांधणीचे तर्क

पुढे, एक किंवा अधिक एमडीस्क एक तथाकथित पूल तयार करतात. त्याच पूलमध्ये, एकाच प्रकारच्या डिस्कवर वेगवेगळ्या RAID/DRAID स्तरांसह MDisk वापरण्याची शिफारस केलेली नाही. आम्ही यात फार खोलात जाणार नाही, कारण... आम्ही पुढीलपैकी एका लेखात हे कव्हर करण्याची योजना आखत आहोत. बरं, खरं तर, पूल व्हॉल्यूममध्ये विभागलेला आहे, जो होस्टला एक किंवा दुसर्या ब्लॉक ऍक्सेस प्रोटोकॉलचा वापर करून सादर केला जातो.

तर, आम्ही, मध्ये वर्णन केलेल्या परिस्थितीचा परिणाम म्हणून APAR HU02104, तीन डिस्क्सच्या तार्किक बिघाडामुळे, MDisk ने कार्य करणे बंद केले, ज्यामुळे, पूल आणि संबंधित खंड अयशस्वी झाले.

या प्रणाली अतिशय स्मार्ट असल्यामुळे, ते IBM स्टोरेज इनसाइट्स क्लाउड-आधारित मॉनिटरिंग सिस्टमशी कनेक्ट केले जाऊ शकतात, जे समस्या उद्भवल्यास स्वयंचलितपणे IBM समर्थनास सेवा विनंती पाठवते. एक अनुप्रयोग तयार केला जातो आणि IBM विशेषज्ञ दूरस्थपणे निदान करतात आणि सिस्टम वापरकर्त्याशी संपर्क साधतात. 

याबद्दल धन्यवाद, समस्येचे त्वरित निराकरण केले गेले आणि आमच्या सिस्टमला पूर्वी निवडलेल्या फर्मवेअर 8.2.1.9 वर अद्यतनित करण्यासाठी समर्थन सेवेकडून त्वरित शिफारस प्राप्त झाली, जे त्या वेळी आधीच निश्चित केले गेले होते. याची पुष्टी होते संबंधित रिलीझ नोट.

परिणाम आणि आमच्या शिफारसी

या म्हणीप्रमाणे: "सर्व चांगले आहे जे चांगले आहे." फर्मवेअरमधील बगमुळे गंभीर समस्या उद्भवल्या नाहीत - सर्व्हर शक्य तितक्या लवकर आणि डेटा गमावल्याशिवाय पुनर्संचयित केले गेले. काही क्लायंटना व्हर्च्युअल मशीन्स रीस्टार्ट कराव्या लागल्या, परंतु सर्वसाधारणपणे आम्ही अधिक नकारात्मक परिणामांसाठी तयार होतो, कारण आम्ही सर्व पायाभूत घटक आणि क्लायंट मशीन्सचा दररोज बॅकअप घेतो. 

आम्हाला पुष्टी मिळाली आहे की 99,9999% वचन दिलेली उपलब्धता असलेल्या विश्वसनीय प्रणालींना देखील लक्ष आणि वेळेवर देखभाल आवश्यक आहे. परिस्थितीच्या आधारे, आम्ही स्वतःसाठी अनेक निष्कर्ष काढले आहेत आणि आमच्या शिफारसी सामायिक केल्या आहेत:

• अद्यतनांच्या प्रकाशनाचे निरीक्षण करणे, संभाव्य गंभीर समस्यांच्या दुरुस्तीसाठी प्रकाशन नोट्सचा अभ्यास करणे आणि नियोजित अद्यतने वेळेवर पार पाडणे अत्यावश्यक आहे.

  हा एक संघटनात्मक आणि अगदी स्पष्ट मुद्दा आहे, ज्यावर लक्ष केंद्रित करणे योग्य नाही असे दिसते. तथापि, या "पातळीवर" आपण अगदी सहजपणे अडखळू शकता. वास्तविक, याच क्षणाने वर वर्णन केलेल्या त्रासांची भर पडली. अद्ययावत नियम तयार करताना खूप सावधगिरी बाळगा आणि त्यांचे पालन कमी काळजीपूर्वक करा. हा मुद्दा "शिस्त" या संकल्पनेशी अधिक संबंधित आहे.

• नवीनतम सॉफ्टवेअर आवृत्तीसह सिस्टम ठेवणे केव्हाही चांगले. शिवाय, वर्तमान हे मोठे संख्यात्मक पदनाम नसून नंतरच्या प्रकाशन तारखेसह आहे. 

  उदाहरणार्थ, IBM त्याच्या स्टोरेज सिस्टमसाठी किमान दोन सॉफ्टवेअर रिलीझ अद्ययावत ठेवते. या लेखनाच्या वेळी, हे 8.2 आणि 8.3 आहेत. 8.2 साठी अपडेट्स आधी येतात. 8.3 साठी समान अद्यतन सामान्यतः थोड्या विलंबाने रिलीझ केले जाते.

  रिलीज 8.3 चे अनेक कार्यात्मक फायदे आहेत, उदाहरणार्थ, एक किंवा अधिक नवीन डिस्क जोडून MDisk (DRAID मोडमध्ये) विस्तृत करण्याची क्षमता (हे वैशिष्ट्य आवृत्ती 8.3.1 पासून दिसून आले आहे). ही बर्‍यापैकी मूलभूत कार्यक्षमता आहे, परंतु 8.2 मध्ये, दुर्दैवाने, असे कोणतेही वैशिष्ट्य नाही.

• काही कारणास्तव अपडेट करणे शक्य नसल्यास, स्पेक्ट्रम व्हर्च्युअलाइज सॉफ्टवेअरच्या आवृत्त्यांसाठी 8.2.1.9 आणि 8.3.1.0 (जेथे वर वर्णन केलेले बग संबंधित आहे) आधीच्या आवृत्त्यांसाठी, त्याच्या घटनेचा धोका कमी करण्यासाठी, IBM तांत्रिक समर्थन शिफारस करतो. खालील आकृतीमध्ये दर्शविल्याप्रमाणे पूल स्तरावर सिस्टम कार्यप्रदर्शन मर्यादित करणे (चित्र GUI च्या Russified आवृत्तीमध्ये घेण्यात आले होते). 10000 IOPS चे मूल्य उदाहरण म्हणून दाखवले आहे आणि तुमच्या सिस्टमच्या वैशिष्ट्यांनुसार निवडले आहे.

IBM स्टोरेज कामगिरी मर्यादित करणे

• स्टोरेज सिस्टमवरील लोडची अचूक गणना करणे आणि ओव्हरलोडिंग टाळणे आवश्यक आहे. हे करण्यासाठी, तुम्ही एकतर IBM साइजर वापरू शकता (जर तुम्हाला त्यात प्रवेश असेल), किंवा भागीदारांची मदत किंवा तृतीय-पक्ष संसाधने. स्टोरेज सिस्टमवरील लोड प्रोफाइल समजून घेणे अत्यावश्यक आहे, कारण किमान खालील पॅरामीटर्सवर अवलंबून MB/s आणि IOPS मधील कामगिरी मोठ्या प्रमाणात बदलते:

  • ऑपरेशन प्रकार: वाचा किंवा लिहा,

  • ऑपरेशन ब्लॉक आकार,

  • एकूण I/O प्रवाहातील वाचन आणि लेखन ऑपरेशन्सची टक्केवारी.

  तसेच, डेटा ब्लॉक्स कसे वाचले जातात यावर ऑपरेशन्सचा वेग प्रभावित होतो: क्रमवार किंवा यादृच्छिक क्रमाने. ऍप्लिकेशनच्या बाजूला एकाधिक डेटा ऍक्सेस ऑपरेशन्स करत असताना, अवलंबून ऑपरेशन्सची संकल्पना आहे. हे देखील लक्षात घेणे उचित आहे. हे सर्व OS, स्टोरेज सिस्टम, सर्व्हर/हायपरव्हायझर्स, तसेच ऍप्लिकेशन्स, DBMSs आणि डिस्क संसाधनांच्या इतर "ग्राहक" च्या ऑपरेटिंग वैशिष्ट्यांबद्दल समजून घेण्यासाठी कार्यप्रदर्शन काउंटरवरील डेटाची संपूर्णता पाहण्यात मदत करू शकतात.

• आणि शेवटी, बॅकअप अप टू डेट आणि कार्यरत असल्याची खात्री करा. बॅकअप शेड्यूल व्यवसायासाठी स्वीकार्य RPO मूल्यांच्या आधारे कॉन्फिगर केले जावे आणि स्वीकार्य RTO मूल्य सुनिश्चित करण्यासाठी बॅकअपच्या नियमित अखंडतेची पडताळणी केली जावी (काही बॅकअप सॉफ्टवेअर विक्रेत्यांनी त्यांच्या उत्पादनांमध्ये स्वयंचलित पडताळणी लागू केली आहे).

शेवटपर्यंत वाचल्याबद्दल धन्यवाद.
आम्ही टिप्पण्यांमध्ये आपल्या प्रश्नांची आणि टिप्पण्यांची उत्तरे देण्यास तयार आहोत. तसेच आम्ही तुम्हाला आमच्या टेलिग्राम चॅनेलची सदस्यता घेण्यासाठी आमंत्रित करतो, ज्यामध्ये आम्ही नियमित जाहिराती (IaaS वर सवलत आणि VPS वर 100% पर्यंत प्रमोशनल कोडसाठी गिफ्टवे) ठेवतो, मनोरंजक बातम्या लिहितो आणि Habr ब्लॉगवर नवीन लेखांची घोषणा करतो.

स्त्रोत: www.habr.com