Watter firmware weergawe is die mees "korrekte" en "werk"? As 'n bergingstelsel fouttoleransie van 99,9999% waarborg, beteken dit dat dit ononderbroke sal werk, selfs sonder 'n sagteware-opdatering? Of, inteendeel, om maksimum fouttoleransie te verkry, moet jy altyd die nuutste firmware installeer? Ons sal probeer om hierdie vrae te beantwoord op grond van ons ervaring.
Klein inleiding
Ons verstaan almal dat elke weergawe van sagteware, of dit nou 'n bedryfstelsel of 'n drywer vir 'n toestel is, dikwels defekte/foute en ander "kenmerke" bevat wat dalk nie "verskyn" tot aan die einde van die toerusting se dienslewe, of "oop" slegs onder sekere voorwaardes. Die aantal en betekenis van sulke nuanses hang af van die kompleksiteit (funksionaliteit) van die sagteware en van die kwaliteit van toetsing tydens die ontwikkeling daarvan.
Dikwels bly gebruikers op die "firmware van die fabriek" (die bekende "dit werk, so moenie daarmee mors nie") of installeer altyd die nuutste weergawe (in hul verstaan beteken die nuutste die werkendste). Ons gebruik 'n ander benadering - ons kyk na die vrystellingnotas vir alles wat gebruik word toerusting en kies noukeurig die toepaslike firmware vir elke stuk toerusting.
Ons het tot hierdie gevolgtrekking gekom, soos hulle sê, met ervaring. Deur ons voorbeeld van werking te gebruik, sal ons jou vertel hoekom die beloofde 99,9999% betroubaarheid van bergingstelsels niks beteken as jy nie stiptelik sagteware-opdaterings en beskrywings monitor nie. Ons tas is geskik vir gebruikers van stoorstelsels van enige verskaffer, aangesien 'n soortgelyke situasie met hardeware van enige vervaardiger kan gebeur.
Die keuse van 'n nuwe bergingstelsel
Aan die einde van verlede jaar is 'n interessante databergingstelsel by ons infrastruktuur gevoeg: 'n junior model van die IBM FlashSystem 5000-lyn, wat ten tyde van aankoop Storwize V5010e genoem is. Nou word dit onder die naam FlashSystem 5010 verkoop, maar in werklikheid is dit dieselfde hardewarebasis met dieselfde Spectrum Virtualize binne.
Die teenwoordigheid van 'n verenigde bestuurstelsel is terloops die belangrikste verskil tussen IBM FlashSystem. Vir modelle van die jonger reeks verskil dit feitlik nie van modelle van meer produktiewe nie. Die keuse van 'n spesifieke model bied slegs die toepaslike hardewarebasis, waarvan die eienskappe dit moontlik maak om een of ander funksionaliteit te gebruik of 'n hoër vlak van skaalbaarheid te bied. Die sagteware identifiseer die hardeware en verskaf die nodige en voldoende funksionaliteit vir hierdie platform.
IBM FlashSystem 5010
Kortliks oor ons model 5010. Dit is 'n intreevlak-dubbelbeheerblokbergingstelsel. Dit kan NLSAS-, SAS-, SSD-skywe akkommodeer. NVMe-plasing is nie daarin beskikbaar nie, aangesien hierdie bergingsmodel geposisioneer is om probleme op te los wat nie die werkverrigting van NVMe-aandrywers vereis nie.
Die bergingstelsel is aangekoop om argiefinligting of data te akkommodeer wat nie gereeld verkry word nie. Daarom was die standaardstel van sy funksionaliteit genoeg vir ons: Tiering (Easy Tier), Thin Provision. Prestasie op NLSAS-skywe op die vlak van 1000-2000 IOPS was ook vir ons redelik bevredigend.
Ons ervaring - hoe ons nie die firmware betyds opgedateer het nie
Nou oor die sagteware-opdatering self. Ten tyde van aankoop het die stelsel reeds 'n effens verouderde weergawe van die Spectrum Virtualize-sagteware gehad, naamlik, 8.2.1.3.
Ons het die firmwarebeskrywings bestudeer en 'n opdatering beplan 8.2.1.9. As ons 'n bietjie meer doeltreffend was, sou hierdie artikel nie bestaan het nie - die fout sou nie op 'n meer onlangse firmware voorgekom het nie. Om sekere redes is die opdatering van hierdie stelsel egter uitgestel.
As gevolg hiervan het 'n effense opdateringsvertraging gelei tot 'n uiters onaangename prentjie, soos in die beskrywing by die skakel: .
Ja, in die firmware van daardie weergawe was die sogenaamde APAR (Authorized Program Analysis Report) HU02104 relevant. Dit verskyn soos volg. Onder lading, onder sekere omstandighede, begin die kas oorloop, dan gaan die stelsel in beskermende modus, waarin dit I/O vir die swembad deaktiveer. In ons geval het dit gelyk soos om 3 skywe vir 'n RAID-groep te ontkoppel in RAID 6-modus. Die ontkoppeling vind vir 6 minute plaas. Vervolgens word toegang tot die Volumes in the Pool herstel.
As iemand nie vertroud is met die struktuur en benaming van logiese entiteite in die konteks van IBM Spectrum Virtualize nie, sal ek nou kortliks verduidelik.
Struktuur van stoorstelsel logiese elemente
Skywe word versamel in groepe genaamd MDisk (Managed Disk). MDisk kan 'n klassieke RAID (0,1,10,5,6) of 'n gevirtualiseerde een wees - DRAID (Distributed RAID). Deur DRAID te gebruik, kan jy die werkverrigting van die skikking verhoog, want... Alle skywe in die groep sal gebruik word, en herboutyd sal verminder word, as gevolg van die feit dat slegs sekere blokke herstel sal moet word, en nie alle data van die mislukte skyf nie.
Verspreiding van datablokke oor skywe wanneer verspreide RAID (DRAID) in RAID-5-modus gebruik word.
En hierdie diagram toon die logika van hoe 'n DRAID-herbou werk in die geval van een skyffout:
Logika van DRAID-herbou wanneer een skyf misluk
Vervolgens vorm een of meer MDisks 'n sogenaamde Pool. Binne dieselfde poel word dit nie aanbeveel om MDisk met verskillende RAID/DRAID-vlakke op skywe van dieselfde tipe te gebruik nie. Ons gaan nie te diep hierop in nie, want... ons beplan om dit in een van die volgende artikels te dek. Trouens, Pool word in volumes verdeel, wat aangebied word met behulp van een of ander bloktoegangprotokol aan die gashere.
Dus, ons, as gevolg van die situasie beskryf in APAR HU02104, as gevolg van die logiese mislukking van drie skywe, het MDisk opgehou om funksioneel te wees, wat op sy beurt gelei het tot die mislukking van die swembad en die ooreenstemmende volumes.
Omdat hierdie stelsels redelik slim is, kan hulle gekoppel word aan die IBM Storage Insights-wolkgebaseerde moniteringstelsel, wat outomaties 'n diensversoek na IBM-ondersteuning stuur as 'n probleem opduik. 'n Toepassing word geskep en IBM-spesialiste voer diagnose op afstand uit en kontak die stelselgebruiker.
Danksy dit is die probleem redelik vinnig opgelos en 'n spoedige aanbeveling is van die ondersteuningsdiens ontvang om ons stelsel op te dateer na die voorheen geselekteerde firmware 8.2.1.9, wat op daardie tydstip reeds reggestel is. Dit bevestig .
Resultate en ons aanbevelings
Soos die spreekwoord sê: "Alles goed wat goed eindig." Die fout in die firmware het nie ernstige probleme veroorsaak nie - die bedieners is so gou moontlik en sonder dataverlies herstel. Sommige kliënte moes virtuele masjiene herbegin, maar oor die algemeen was ons voorbereid op meer negatiewe gevolge, aangesien ons daagliks rugsteun van alle infrastruktuurelemente en kliëntmasjiene maak.
Ons het bevestiging ontvang dat selfs betroubare stelsels met 99,9999% beloofde beskikbaarheid aandag en tydige instandhouding vereis. Op grond van die situasie het ons 'n aantal gevolgtrekkings vir onsself gemaak en ons aanbevelings deel:
-
Dit is noodsaaklik om die vrystelling van opdaterings te monitor, vrystellingnotas te bestudeer vir regstellings van potensieel kritieke kwessies, en beplande opdaterings betyds uit te voer.
Dit is 'n organisatoriese en selfs redelik voor die hand liggende punt, waarop dit blykbaar nie die moeite werd is om op te fokus nie. Op hierdie “vlak grond” kan jy egter redelik maklik struikel. Eintlik was dit hierdie oomblik wat die probleme hierbo beskryf het bygevoeg. Wees baie versigtig wanneer u die opdateringsregulasies opstel en monitor die nakoming daarvan nie minder noukeurig nie. Hierdie punt hou meer verband met die konsep van "dissipline".
-
Dit is altyd beter om die stelsel met die nuutste sagteware weergawe te hou. Boonop is die huidige een nie die een wat 'n groter numeriese benaming het nie, maar eerder die een met 'n latere vrystellingsdatum.
Byvoorbeeld, IBM hou ten minste twee sagtewarevrystellings op datum vir sy bergingstelsels. Ten tyde van hierdie skrywe is dit 8.2 en 8.3. Opdaterings vir 8.2 kom vroeër uit. 'n Soortgelyke opdatering vir 8.3 word gewoonlik met 'n effense vertraging vrygestel.
Vrystelling 8.3 het 'n aantal funksionele voordele, byvoorbeeld die vermoë om MDisk uit te brei (in DRAID-modus) deur een of meer nuwe skywe by te voeg (hierdie kenmerk het verskyn sedert weergawe 8.3.1). Dit is 'n redelik basiese funksionaliteit, maar in 8.2 is daar ongelukkig nie so 'n kenmerk nie.
-
As dit om een of ander rede nie moontlik is om op te dateer nie, dan vir weergawes van Spectrum Virtualize-sagteware voor weergawes 8.2.1.9 en 8.3.1.0 (waar die fout wat hierbo beskryf is relevant is), om die risiko dat dit voorkom te verminder, beveel IBM tegniese ondersteuning aan die beperking van stelselprestasie op die swembadvlak, soos in die figuur hieronder getoon (die foto is geneem in die Russified weergawe van die GUI). Die waarde van 10000 IOPS word as 'n voorbeeld getoon en word gekies volgens die kenmerke van jou stelsel.
Beperk IBM-bergingprestasie
-
Dit is nodig om die las op stoorstelsels korrek te bereken en oorlading te vermy. Om dit te doen, kan jy óf die IBM sizer gebruik (as jy toegang daartoe het), óf die hulp van vennote, of derdeparty-hulpbronne. Dit is noodsaaklik om die lasprofiel op die stoorstelsel te verstaan, want Werkverrigting in MB/s en IOPS verskil baie, afhangende van ten minste die volgende parameters:
-
tipe operasie: lees of skryf,
-
operasie blok grootte,
-
persentasie lees- en skryfbewerkings in die totale I/O-stroom.
Die spoed van bewerkings word ook beïnvloed deur hoe datablokke gelees word: opeenvolgend of in ewekansige volgorde. Wanneer meervoudige datatoegangsbewerkings aan die toepassingskant uitgevoer word, is daar die konsep van afhanklike bewerkings. Dit is ook raadsaam om dit in ag te neem. Dit alles kan help om die geheel van data van prestasietellers van die bedryfstelsel, bergingstelsel, bedieners/hipervisors te sien, sowel as 'n begrip van die bedryfskenmerke van toepassings, DBBS'e en ander "verbruikers" van skyfhulpbronne.
-
-
En ten slotte, maak seker dat rugsteun op datum is en werk. Die rugsteunskedule moet gekonfigureer word op grond van aanvaarbare RPO-waardes vir die onderneming, en periodieke integriteitskontroles van die rugsteun moet geverifieer word ('n hele paar rugsteunprogrammatuurverskaffers het outomatiese verifikasie in hul produkte geïmplementeer) om 'n aanvaarbare RTO-waarde te verseker.
Dankie dat jy tot die einde gelees het.
Ons is gereed om u vrae en kommentaar in die kommentaar te beantwoord. Ook, waarin ons gereelde promosies hou (afslag op IaaS en geskenke vir promosiekodes tot 100% op VPS), skryf interessante nuus en kondig nuwe artikels op die Habr-blog aan.
Bron: will.com