Kuri programinės įrangos versija yra „teisingiausia“ ir „veikianti“? Jei saugojimo sistema garantuoja 99,9999% gedimų toleranciją, ar tai reiškia, kad ji veiks nepertraukiamai net ir be programinės įrangos atnaujinimo? Arba, priešingai, norėdami gauti didžiausią atsparumą gedimams, visada turėtumėte įdiegti naujausią programinę-aparatinę įrangą? Į šiuos klausimus bandysime atsakyti remdamiesi savo patirtimi.
Maža įžanga
Visi suprantame, kad kiekvienoje programinės įrangos versijoje, nesvarbu, ar tai būtų operacinė sistema, ar įrenginio tvarkyklė, dažnai yra defektų/klaidų ir kitų „ypatybių“, kurios gali „nepasirodyti“ iki įrangos eksploatavimo pabaigos arba „atsidaryti“. tik esant tam tikroms sąlygoms. Tokių niuansų skaičius ir reikšmė priklauso nuo programinės įrangos sudėtingumo (funkcionalumo) ir nuo testavimo kokybės ją kuriant.
Dažnai vartotojai lieka prie „gamyklinės programinės aparatinės įrangos“ (garsusis „veikia, todėl nesijaudink“) arba visada įdiegia naujausią versiją (jų supratimu, naujausia reiškia, kad ji veikia). Mes naudojame kitokį požiūrį – žiūrime į visko, kas naudojama, išleidimo pastabas įrangą ir atidžiai pasirinkite kiekvienai įrangai tinkamą programinę-aparatinę įrangą.
Tokią išvadą padarėme, kaip sakoma, turėdami patirties. Naudodamiesi mūsų veikimo pavyzdžiu, pasakysime, kodėl žadėtas 99,9999% saugojimo sistemų patikimumas nieko nereiškia, jei operatyviai nestebėsite programinės įrangos atnaujinimų ir aprašymų. Mūsų dėklas tinka bet kurio gamintojo saugojimo sistemų naudotojams, nes panaši situacija gali nutikti su bet kurio gamintojo aparatūra.
Naujos saugojimo sistemos pasirinkimas
Praėjusių metų pabaigoje mūsų infrastruktūrą papildė įdomi duomenų saugojimo sistema: IBM FlashSystem 5000 linijos jaunesnysis modelis, kuris pirkimo metu vadinosi Storwize V5010e. Dabar jis parduodamas pavadinimu „FlashSystem 5010“, tačiau iš tikrųjų tai yra ta pati aparatinės įrangos bazė su tuo pačiu „Spectrum Virtualize“ viduje.
Vieningos valdymo sistemos buvimas, beje, yra pagrindinis skirtumas tarp IBM FlashSystem. Jaunesnių serijų modeliams tai praktiškai nesiskiria nuo produktyvesnių modelių. Pasirinkus konkretų modelį gaunama tik atitinkama aparatinė bazė, kurios charakteristikos leidžia naudotis vienu ar kitu funkcionalumu arba užtikrina aukštesnį mastelio keitimo lygį. Programinė įranga identifikuoja aparatinę įrangą ir suteikia šiai platformai reikiamą ir pakankamą funkcionalumą.
IBM FlashSystem 5010
Trumpai apie mūsų modelį 5010. Tai pradinio lygio dviejų valdiklių blokų saugojimo sistema. Jis gali talpinti NLSAS, SAS, SSD diskus. Jame NVMe vieta negalima, nes šis saugojimo modelis skirtas išspręsti problemas, kurioms nereikia NVMe diskų našumo.
Saugojimo sistema buvo įsigyta siekiant talpinti archyvinę informaciją arba duomenis, kurie nėra dažnai pasiekiami. Todėl mums pakako standartinio jo funkcionalumo rinkinio: Tiring (Easy Tier), Thin Provision. NLSAS diskų našumas 1000–2000 IOPS lygiu taip pat buvo gana patenkintas.
Mūsų patirtis – kaip laiku neatnaujinome programinės įrangos
Dabar apie patį programinės įrangos atnaujinimą. Pirkimo metu sistema jau turėjo šiek tiek pasenusią „Spectrum Virtualize“ programinės įrangos versiją, būtent, 8.2.1.3.
Išstudijavome programinės įrangos aprašymus ir planavome atnaujinti 8.2.1.9. Jei būtume buvę šiek tiek veiksmingesni, šio straipsnio nebūtų buvę – naujesnėje programinėje aparatinėje programinėje įrangoje klaida nebūtų įvykusi. Tačiau dėl tam tikrų priežasčių šios sistemos atnaujinimas buvo atidėtas.
Dėl to nedidelis atnaujinimo delsimas lėmė labai nemalonų vaizdą, kaip nurodyta nuorodos aprašyme: .
Taip, tos versijos programinėje įrangoje buvo aktualus vadinamasis APAR (Authorized Program Analysis Report) HU02104. Tai atrodo taip. Esant apkrovai, esant tam tikroms aplinkybėms, talpykla pradeda perpildyti, tada sistema pereina į apsauginį režimą, kuriame išjungia įvesties / išvesties telkinį. Mūsų atveju atrodė, kad RAID grupei atjungiami 3 diskai RAID 6 režimu.Atjungimas vyksta 6 minutes. Tada atkuriama prieiga prie baseino tūrių.
Jei kas nors nėra susipažinęs su loginių objektų struktūra ir pavadinimais IBM Spectrum Virtualize kontekste, dabar trumpai paaiškinsiu.
Saugojimo sistemos loginių elementų struktūra
Diskai surenkami į grupes, vadinamas MDisk (valdomas diskas). MDisk gali būti klasikinis RAID (0,1,10,5,6) arba virtualizuotas – DRAID (Distributed RAID). DRAID naudojimas leidžia padidinti masyvo našumą, nes... Bus naudojami visi grupės diskai, o atkūrimo laikas sutrumpės dėl to, kad reikės atkurti tik tam tikrus blokus, o ne visus duomenis iš sugedusio disko.
Duomenų blokų paskirstymas diskuose naudojant paskirstytą RAID (DRAID) RAID-5 režimu.
Ir ši diagrama parodo logiką, kaip DRAID atkūrimas veikia vieno disko gedimo atveju:
DRAID atkūrimo logika, kai sugenda vienas diskas
Tada vienas ar keli MD diskai sudaro vadinamąjį baseiną. Tame pačiame telkinyje nerekomenduojama naudoti MDisk su skirtingais RAID / DRAID lygiais to paties tipo diskuose. Per daug nesigilinsime į tai, nes... planuojame tai aptarti viename iš šių straipsnių. Na, o iš tikrųjų Pool yra padalintas į Volumes, kurie pateikiami naudojant vienokį ar kitokį bloko prieigos protokolą prie šeimininkų.
Taigi, mes, kaip aprašyta situacija APAR HU02104, dėl loginio trijų diskų gedimo MDisk nustojo veikti, o tai savo ruožtu lėmė baseino ir atitinkamų tomų gedimą.
Kadangi šios sistemos yra gana išmanios, jas galima prijungti prie IBM Storage Insights debesyje pagrįstos stebėjimo sistemos, kuri, iškilus problemai, automatiškai siunčia paslaugų užklausą IBM palaikymo tarnybai. Sukuriama aplikacija ir IBM specialistai nuotoliniu būdu atlieka diagnostiką ir susisiekia su sistemos vartotoju.
Dėl šios priežasties problema buvo išspręsta gana greitai ir buvo gauta operatyvi palaikymo tarnybos rekomendacija atnaujinti mūsų sistemą į anksčiau pasirinktą programinę-aparatinę įrangą 8.2.1.9, kuri tuo metu jau buvo ištaisyta. Tai patvirtina .
Rezultatai ir mūsų rekomendacijos
Kaip sakoma: „Viskas gerai, kas gerai baigiasi“. Programinės įrangos klaida rimtų problemų nesukėlė – serveriai buvo atkurti kuo greičiau ir neprarandant duomenų. Kai kurie klientai turėjo iš naujo paleisti virtualias mašinas, tačiau apskritai buvome pasiruošę neigiamesnėms pasekmėms, nes kasdien darome visų infrastruktūros elementų ir klientų mašinų atsargines kopijas.
Gavome patvirtinimą, kad net ir patikimoms sistemoms, kurių 99,9999% žadėtas prieinamumas reikalauja dėmesio ir savalaikės priežiūros. Remdamiesi susidariusia situacija, padarėme keletą išvadų ir dalinamės rekomendacijomis:
-
Būtina stebėti naujinimų išleidimą, ištirti laidos pastabas, kad būtų galima pataisyti galimai svarbias problemas, ir laiku atlikti suplanuotus atnaujinimus.
Tai organizacinis ir net gana akivaizdus dalykas, į kurį, atrodytų, neverta kreipti dėmesio. Tačiau ant šios „lygios žemės“ galite gana lengvai suklupti. Tiesą sakant, būtent šis momentas pridėjo aukščiau aprašytų problemų. Būkite labai atidūs rengdami atnaujinimo taisykles ir ne mažiau atidžiai stebėkite jų laikymąsi. Šis punktas labiau susijęs su „disciplinos“ sąvoka.
-
Visada geriau išlaikyti sistemą su naujausia programinės įrangos versija. Be to, dabartinis yra ne tas, kuris turi didesnį skaičių, o tas, kurio išleidimo data vėlesnė.
Pavyzdžiui, IBM atnaujina bent du savo saugojimo sistemų programinės įrangos leidimus. Šio rašymo metu tai yra 8.2 ir 8.3. 8.2 naujinimai pasirodo anksčiau. Panašus 8.3 naujinimas paprastai išleidžiamas su nedideliu vėlavimu.
8.3 leidimas turi nemažai funkcinių pranašumų, pavyzdžiui, galimybė išplėsti MDisk (DRAID režimu) pridedant vieną ar daugiau naujų diskų (ši funkcija atsirado nuo 8.3.1 versijos). Tai gana pagrindinė funkcija, tačiau 8.2 versijoje, deja, tokios funkcijos nėra.
-
Jei dėl kokių nors priežasčių atnaujinti neįmanoma, Spectrum Virtualizavimo programinės įrangos versijoms, senesnėms nei 8.2.1.9 ir 8.3.1.0 versijoms (kur aktuali aukščiau aprašyta klaida), IBM techninė pagalba rekomenduoja sumažinti jos atsiradimo riziką. ribojančios sistemos veikimą baseino lygiu, kaip parodyta paveikslėlyje žemiau (nuotrauka daryta rusifikuotoje GUI versijoje). 10000 IOPS reikšmė parodyta kaip pavyzdys ir parenkama pagal jūsų sistemos charakteristikas.
IBM saugyklos našumo ribojimas
-
Būtina teisingai apskaičiuoti saugojimo sistemų apkrovą ir vengti perkrovos. Norėdami tai padaryti, galite naudoti IBM sizer (jei turite prieigą prie jo) arba partnerių pagalbą arba trečiųjų šalių išteklius. Būtina suprasti saugojimo sistemos apkrovos profilį, nes MB/s ir IOPS našumas labai skiriasi priklausomai nuo bent šių parametrų:
-
operacijos tipas: skaitymas arba rašymas,
-
operacijos bloko dydis,
-
skaitymo ir rašymo operacijų procentinė dalis bendrame įvesties/išvesties sraute.
Taip pat operacijų greičiui įtakos turi tai, kaip duomenų blokai nuskaitomi: nuosekliai ar atsitiktine tvarka. Atliekant kelias prieigos prie duomenų operacijas programos pusėje, yra priklausomų operacijų samprata. Taip pat patartina į tai atsižvelgti. Visa tai gali padėti pamatyti duomenų visumą iš OS, saugojimo sistemos, serverių/hipervizorių našumo skaitiklių, taip pat suprasti programų, DBVS ir kitų disko resursų „vartotojų“ veikimo ypatybes.
-
-
Galiausiai įsitikinkite, kad atsarginės kopijos yra atnaujintos ir veikia. Atsarginės kopijos kūrimo tvarkaraštis turėtų būti sukonfigūruotas remiantis verslui priimtinomis RPO reikšmėmis ir periodiškai tikrinamas atsarginių kopijų vientisumas (daugelis atsarginės programinės įrangos pardavėjų savo produktuose įdiegė automatinį patikrinimą), kad būtų užtikrinta priimtina RTO vertė.
Ačiū, kad perskaitėte iki galo.
Esame pasirengę atsakyti į jūsų klausimus ir komentarus komentaruose. Taip pat, kuriame reguliariai rengiame akcijas (nuolaidas IaaS ir dovanojame reklaminius kodus iki 100% VPS), rašome įdomias naujienas ir skelbiame naujus straipsnius Habr tinklaraštyje.
Šaltinis: www.habr.com