તમારા ઉચ્ચ ઉપલબ્ધતા સ્ટોરેજ (99,9999%) પર સૉફ્ટવેરને માન્ય કરવું શા માટે મહત્વપૂર્ણ છે

કયું ફર્મવેર વર્ઝન સૌથી "સાચું" અને "કાર્યકારી" છે? જો સ્ટોરેજ સિસ્ટમ 99,9999% ની ખામી સહિષ્ણુતાની ખાતરી આપે છે, તો શું તેનો અર્થ એ છે કે તે સોફ્ટવેર અપડેટ વિના પણ અવિરત કામ કરશે? અથવા, તેનાથી વિપરીત, મહત્તમ દોષ સહિષ્ણુતા મેળવવા માટે, તમારે હંમેશા નવીનતમ ફર્મવેર ઇન્સ્ટોલ કરવું જોઈએ? અમે અમારા અનુભવના આધારે આ પ્રશ્નોના જવાબ આપવાનો પ્રયત્ન કરીશું.

નાનો પરિચય

અમે બધા સમજીએ છીએ કે સૉફ્ટવેરના દરેક સંસ્કરણ, તે ઑપરેટિંગ સિસ્ટમ હોય અથવા ઉપકરણ માટે ડ્રાઇવર હોય, તેમાં ઘણીવાર ખામી/બગ્સ અને અન્ય "સુવિધાઓ" હોય છે જે સાધનની સેવા જીવનના અંત સુધી "દેખાતી નથી" અથવા "ખુલ્લી" હોઈ શકે છે. માત્ર અમુક શરતો હેઠળ. આવી ઘોંઘાટની સંખ્યા અને મહત્વ સોફ્ટવેરની જટિલતા (કાર્યક્ષમતા) અને તેના વિકાસ દરમિયાન પરીક્ષણની ગુણવત્તા પર આધારિત છે. 

મોટે ભાગે, વપરાશકર્તાઓ "ફેક્ટરીમાંથી ફર્મવેર" પર રહે છે (વિખ્યાત "તે કામ કરે છે, તેથી તેની સાથે ગડબડ કરશો નહીં") અથવા હંમેશા નવીનતમ સંસ્કરણ ઇન્સ્ટોલ કરે છે (તેમની સમજમાં, નવીનતમ એટલે સૌથી વધુ કાર્યકારી). અમે એક અલગ અભિગમનો ઉપયોગ કરીએ છીએ - અમે ઉપયોગમાં લેવાતી દરેક વસ્તુ માટે પ્રકાશન નોંધો જોઈએ છીએ mClouds વાદળમાં સાધનસામગ્રી અને દરેક સાધનસામગ્રી માટે યોગ્ય ફર્મવેર કાળજીપૂર્વક પસંદ કરો.

અમે આ નિષ્કર્ષ પર આવ્યા, જેમ તેઓ કહે છે, અનુભવ સાથે. અમારા ઑપરેશનના ઉદાહરણનો ઉપયોગ કરીને, અમે તમને કહીશું કે શા માટે સ્ટોરેજ સિસ્ટમ્સની વચન આપેલ 99,9999% વિશ્વસનીયતાનો કોઈ અર્થ નથી જો તમે સૉફ્ટવેર અપડેટ્સ અને વર્ણનોનું તાત્કાલિક નિરીક્ષણ ન કરો. અમારો કેસ કોઈપણ વિક્રેતાની સ્ટોરેજ સિસ્ટમના વપરાશકર્તાઓ માટે યોગ્ય છે, કારણ કે આવી જ પરિસ્થિતિ કોઈપણ ઉત્પાદકના હાર્ડવેર સાથે થઈ શકે છે.

નવી સ્ટોરેજ સિસ્ટમ પસંદ કરી રહ્યા છીએ

ગયા વર્ષના અંતમાં, અમારા ઈન્ફ્રાસ્ટ્રક્ચરમાં એક રસપ્રદ ડેટા સ્ટોરેજ સિસ્ટમ ઉમેરવામાં આવી હતી: IBM FlashSystem 5000 લાઇનનું જુનિયર મોડલ, જે ખરીદી સમયે Storwize V5010e તરીકે ઓળખાતું હતું. હવે તે FlashSystem 5010 નામથી વેચાય છે, પરંતુ વાસ્તવમાં તે એક જ હાર્ડવેર બેઝ છે જેની અંદર સમાન સ્પેક્ટ્રમ વર્ચ્યુઅલાઈઝ છે. 

એકીકૃત મેનેજમેન્ટ સિસ્ટમની હાજરી, માર્ગ દ્વારા, 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 સ્પેક્ટ્રમ વર્ચ્યુઅલાઈઝના સંદર્ભમાં લોજિકલ એન્ટિટીની રચના અને નામકરણથી પરિચિત નથી, તો હું હવે ટૂંકમાં સમજાવીશ.

સ્ટોરેજ સિસ્ટમ લોજિકલ તત્વોનું માળખું

ડિસ્કને એમડીસ્ક (મેનેજ્ડ ડિસ્ક) તરીકે ઓળખાતા જૂથોમાં એકત્રિત કરવામાં આવે છે. MDisk એ ક્લાસિક RAID (0,1,10,5,6) અથવા વર્ચ્યુઅલાઈઝ્ડ - DRAID (ડિસ્ટ્રિબ્યુટેડ RAID) હોઈ શકે છે. DRAID નો ઉપયોગ તમને એરેની કામગીરી વધારવા માટે પરવાનગી આપે છે, કારણ કે... જૂથમાંની બધી ડિસ્કનો ઉપયોગ કરવામાં આવશે, અને પુનઃનિર્માણનો સમય ઘટાડવામાં આવશે, કારણ કે માત્ર ચોક્કસ બ્લોક્સને પુનઃસ્થાપિત કરવાની જરૂર પડશે, અને નિષ્ફળ ડિસ્કમાંથી તમામ ડેટા નહીં.

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, સ્ટોરેજ સિસ્ટમ, સર્વર/હાઈપરવાઈઝર, તેમજ એપ્લીકેશન, ડીબીએમએસ અને ડિસ્ક સંસાધનોના અન્ય "ગ્રાહકો" ની ઓપરેટિંગ સુવિધાઓની સમજણના પરફોર્મન્સ કાઉન્ટર્સમાંથી ડેટાની સંપૂર્ણતા જોવામાં મદદ કરી શકે છે.

• અને છેલ્લે, બેકઅપ અપ ટુ ડેટ અને કાર્યરત હોવાની ખાતરી કરો. બેકઅપ શેડ્યૂલ વ્યવસાય માટે સ્વીકાર્ય RPO મૂલ્યોના આધારે ગોઠવેલું હોવું જોઈએ, અને સ્વીકાર્ય RTO મૂલ્યની ખાતરી કરવા માટે બેકઅપની સમયાંતરે અખંડિતતાની ચકાસણી ચકાસવી જોઈએ (કેટલાક બેકઅપ સોફ્ટવેર વિક્રેતાઓએ તેમના ઉત્પાદનોમાં સ્વચાલિત ચકાસણી લાગુ કરી છે).

અંત સુધી વાંચવા બદલ આભાર.
અમે તમારા પ્રશ્નો અને ટિપ્પણીઓમાં જવાબ આપવા માટે તૈયાર છીએ. પણ અમે તમને અમારી ટેલિગ્રામ ચેનલ પર સબ્સ્ક્રાઇબ કરવા માટે આમંત્રિત કરીએ છીએ, જેમાં અમે નિયમિત પ્રમોશન રાખીએ છીએ (IaaS પર ડિસ્કાઉન્ટ અને VPS પર 100% સુધીના પ્રમોશનલ કોડ માટે ભેટ), રસપ્રદ સમાચાર લખીએ છીએ અને Habr બ્લોગ પર નવા લેખોની જાહેરાત કરીએ છીએ.

સોર્સ: www.habr.com