तपाईको उच्च उपलब्धता भण्डारण (९९.९९९९%) मा सफ्टवेयर प्रमाणीकरण गर्न किन महत्त्वपूर्ण छ

कुन फर्मवेयर संस्करण सबैभन्दा "सही" र "काम" हो? यदि भण्डारण प्रणालीले 99,9999% को गल्ती सहिष्णुताको ग्यारेन्टी दिन्छ, के यसको मतलब यो सफ्टवेयर अद्यावधिक बिना पनि निर्बाध काम गर्नेछ? वा, यसको विपरित, अधिकतम गल्ती सहिष्णुता प्राप्त गर्न, तपाइँ सधैं नवीनतम फर्मवेयर स्थापना गर्नुपर्छ? हामी हाम्रो अनुभवको आधारमा यी प्रश्नहरूको जवाफ दिने प्रयास गर्नेछौं।

सानो परिचय

हामी सबैले बुझ्दछौं कि सफ्टवेयरको प्रत्येक संस्करण, यो एक अपरेटिङ सिस्टम होस् वा यन्त्रको लागि ड्राइभर, प्रायः दोष/बगहरू र अन्य "विशेषताहरू" समावेश गर्दछ जुन उपकरणको सेवा जीवनको अन्त्यसम्म वा "खुल्ला" नभएसम्म "न देखा" हुन सक्छ। केवल केहि सर्तहरूमा। त्यस्ता सूक्ष्मताहरूको संख्या र महत्त्व सफ्टवेयरको जटिलता (कार्यात्मकता) र यसको विकासको क्रममा परीक्षणको गुणस्तरमा निर्भर गर्दछ। 

प्रायः, प्रयोगकर्ताहरू "फ्याक्ट्रीबाट फर्मवेयर" मा रहन्छन् (प्रसिद्ध "यसले काम गर्दछ, त्यसैले यसमा गडबड नगर्नुहोस्") वा सधैं नवीनतम संस्करण स्थापना गर्नुहोस् (उनीहरूको बुझाइमा, नवीनतम भनेको सबैभन्दा काम गर्ने हो)। हामी फरक दृष्टिकोण प्रयोग गर्दछौं - हामी प्रयोग गरिएका सबै चीजहरूको लागि रिलीज नोटहरू हेर्छौं mClouds बादलमा उपकरण र उपकरणको प्रत्येक टुक्राको लागि उपयुक्त फर्मवेयर सावधानीपूर्वक चयन गर्नुहोस्।

हामी यो निष्कर्षमा आएका छौं, तिनीहरूले भनेजस्तै, अनुभवको साथ। हाम्रो सञ्चालनको उदाहरण प्रयोग गरेर, हामी तपाईलाई बताउनेछौं किन प्रतिज्ञा गरिएको 99,9999% भण्डारण प्रणालीको विश्वसनीयताको कुनै मतलब छैन यदि तपाईंले सफ्टवेयर अद्यावधिकहरू र विवरणहरू तुरुन्तै अनुगमन गर्नुहुन्न भने। हाम्रो केस कुनै पनि विक्रेताबाट भण्डारण प्रणालीका प्रयोगकर्ताहरूका लागि उपयुक्त छ, किनकि कुनै पनि निर्माताको हार्डवेयरसँग यस्तै अवस्था हुन सक्छ।

नयाँ भण्डारण प्रणाली छनोट गर्दै

गत वर्षको अन्त्यमा, हाम्रो पूर्वाधारमा एक रोचक डाटा भण्डारण प्रणाली थपियो: IBM FlashSystem 5000 लाइनबाट जुनियर मोडेल, जुन खरिदको समयमा Storwize V5010e भनिन्थ्यो। अब यो FlashSystem 5010 नाम अन्तर्गत बेचिएको छ, तर वास्तवमा यो समान स्पेक्ट्रम भर्चुअलाइज भित्रको समान हार्डवेयर आधार हो। 

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

IBM FlashSystem 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 स्पेक्ट्रम भर्चुअलाइजको सन्दर्भमा तार्किक संस्थाहरूको संरचना र नामकरणसँग परिचित छैन भने, म अब संक्षिप्त रूपमा व्याख्या गर्नेछु।

भण्डारण प्रणाली तार्किक तत्वहरूको संरचना

डिस्कहरू MDisk (प्रबन्धित डिस्क) भनिने समूहहरूमा सङ्कलन गरिन्छ। MDisk क्लासिक RAID (0,1,10,5,6) वा भर्चुअलाइज गरिएको हुन सक्छ - DRAID (वितरित RAID)। DRAID प्रयोग गर्नाले तपाईंलाई array को कार्यसम्पादन बढाउन अनुमति दिन्छ, किनकि... समूहका सबै डिस्कहरू प्रयोग गरिनेछन्, र पुन: निर्माण समय घटाइनेछ, यस तथ्यको कारणले कि केवल निश्चित ब्लकहरू पुनर्स्थापना गर्न आवश्यक छ, र असफल डिस्कबाट सबै डाटा होइन।

RAID-5 मोडमा वितरित RAID (DRAID) प्रयोग गर्दा डिस्कहरूमा डाटा ब्लकहरूको वितरण।

र यो रेखाचित्रले एउटा डिस्क विफलताको अवस्थामा कसरी DRAID पुनर्निर्माणले काम गर्छ भन्ने तर्क देखाउँछ:

एक डिस्क असफल हुँदा DRAID पुनर्निर्माणको तर्क

अर्को, एक वा धेरै MDisks एक तथाकथित पूल बनाउँछ। एउटै पूल भित्र, एउटै प्रकारको डिस्कहरूमा फरक 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