Miks on oluline kontrollida tarkvara teie kõrgelt saadavuses (99,9999%) säilitava salvestussüsteemi puhul?

Milline tarkvaraversioon on kõige "õigem" ja "töötav"? Kui salvestussüsteem tagab töökindluse 99,9999%, siis kas see tähendab, et see töötab ka pidevalt isegi ilma tarkvara uuendamiseta? Või tulles vastupidi, et maksimaalse töökindluse saavutamiseks tuleks alati installida uusim tarkvaraversioon? Proovime nendele küsimustele vastata, tuginedes oma kogemusele.

Lühike sissejuhatus

Me kõik mõistame, et igas tarkvaraversioonis, olgu see siis operatsioonisüsteem või seadme draiver, on tihti puudujääke/vead ja muid "eripära", mis võivad korraga mitte "ilmuda" kogu seadme tööea jooksul, või "välja tuua" ennast vaid teatud tingimustel. Selliste nüansside hulk ja olulisus sõltub tarkvara keerukusest (funktsionaalsusest) ja selle kvaliteedist testimise käigus. 

Tihti jäävad kasutajad "tehase tarkvarale" (kuulus - "töötab, siis ära sega") või paigaldavad alati viimase versiooni (nende arusaama järgi tähendab viimane kõige töökindlamat). Me aga kasutame teistsugust lähenemist - vaatame väljaande märkmeid kogu kasutatava jaoks mCloudsi pilves seadmest ja valime hoolikalt iga seadme jaoks sobiva tarkvaraversiooni.

Olemegi selleni jõudnud, nagu öeldakse, kogemuse põhjal. Oma ekspluateerimise näitel räägime, miks lubatud 99,9999% usaldusväärsus salvestussüsteemides ei tähenda midagi, kui te ei jälgi õigeaegselt tarkvara uuendamist ja kirjeldust. Meie juhtum sobib kõikide salvestussüsteemide kasutajate jaoks, kuna selline olukord võib juhtuda mistahes tootja seadmetega.

Uue andmete salvestussüsteemi valimine

Möödunud aastal lisandus meie infrastruktuuri huvitav andmete salvestussüsteem: IBM FlashSystem 5000 seeria noorem mudel, mida ostmise hetkel nimetati Storwize V5010e-ks. Praegu müüakse seda nime all FlashSystem 5010, kuid tegelikult on see sama riistvara sama Spectrum Virtualize'iga sees. 

Ühtse haldussüsteemi olemasolu on tegelikult IBM FlashSystemi peamine eristus. Madalama seeria mudelite puhul ei erine see praktiliselt tootlikumatest mudelitest. Teatud mudeli valimine annab vaid vastava riistvarabaasi, mille omadused võimaldavad kasutada teatud funktsioone või tagada kõrgemat skaleeritavuse taset. Tarkvara tuvastab riistvara ja pakub vajalikke ning piisavaid funktsioone sellele platvormile.

IBM FlashSystem 5010

Lühidalt meie mudelist 5010. See on algtaseme kaksikkontrolleritega plokkandmete salvestussüsteem. See suudab mahutada NLSAS, SAS, SSD kettaid. NVMe salvestuse kasutamine selles ei ole võimalik, kuna see mudel on suunatud ülesannetele, mis ei vaja NVMe ketaste jõudlust.

Salvestussüsteem osteti arkiviandmete või andmete jaoks, mida ei kasutata sageli. Seetõttu oli meil piisav tavapärane funktsionaalne paket: äratundmine (Easy Tier), Thin Provision. Jõudlus NLSAS ketaste peal tasemel 1000-2000 IOPS oli meile samuti täiesti piisav.

Meie kogemus — kuidas me ei uuendanud tarkvara õigel ajal

Nüüd siis tarkvara uuendamise juurde. Ostmisel oli süsteemil juba veidi aegunud versioon tarkvarast Spectrum Virtualize, nimelt, 8.2.1.3.

Me uurisime tarkvaraversioonide kirjeldusi ja plaanisime uuendamist versioonile 8.2.1.9. Kui me oleksime olnud natuke kiiremad, siis seda artiklit ei eksisteeriks — uuemas versioonis oleks viga olemata olnud. Kuid teatud põhjustel oli selle süsteemi uuendamine edasi lükatud.

Tulemuseks oli väike uuendamise viivitus, mis viis äärmiselt ebameeldiva olukorrani, nagu lingil kirjeldatud: https://www.ibm.com/support/pages/node/6172341. 

Jah, selle versiooni tarkvaras oli asjakohane nn APAR (Authorized Program Analysis Report) HU02104. See avaldub järgmiselt. Koormuse all teatud tingimustel hakkab vahemälu ületäituma, seejärel siseneb süsteem kaitserežiimi, milles lülitab sisse-välja jätmise välja (Pool). Meie puhul tundus see nagu kolme ketta väljalülitamine RAID 6 rühmas. Väljalülitamine kestab 6 minutit. Peale seda taastub juurdepääs puuli Tomidele.

Kui keegi ei tea IBM Spectrum Virtualize kontekstis loogiliste üksuste struktuuri ja nimetuste kohta, räägin nüüd natuke sellest.

HDD struktuuri loogilised elemendid

Kettad kogunevad rühmadesse, mida nimetatakse MDisk (Managed Disk). MDisk võib olla klassikaline RAID (0,1,10,5,6) või virtualiseeritud – DRAID (Distributed RAID). DRAID kasutamine võimaldab suurendada võrgu jõudlust, kuna kõik rühma kettad on aktiivsed ja vähendada taastamisaega, kuna tuleb taastada vaid teatud plokid, mitte kõik andmed defektsest kettast.

Andmeblokki jaotamine kettale DRAID'i kasutamisel RAID-5 režiimis.

See skeem näitab DRAID'i taastamisprotsessi loogikat, juhul kui üks ketas tõrkus:

DRAID'i taastamisprotsessi loogika ühe ketta tõrke korral

Seejärel moodustavad üks või mitmed MDisk nii nimetatud Pooli. Ühes puulis ei soovitata kasutada MDisk'i, millel on erinev RAID/DRAID tase sama tüüpi ketastel. Me ei kavatse sellesse liiga sügavale minna, kuna plaanime rääkida sellest ühes järgmistest artiklitest. Ja tegelikult jaguneb Pool Toma (Volumes), mis esitatakse erineva protokolli kaudu blokeeritud juurdepääsuks hostidele.

Noh, meil on tulemuseks olukord, mida kirjeldatakse APAR HU02104, kolme ketta loogilise tõrke tõttu lakkas funktsioneerimast MDisk, mis omakorda põhjustas Pooli ja vastavate Tomade töö seiskumise.

Kuna need süsteemid on üsna 'nutikad', saab neid ühendatakse IBM Storage Insights'i pilvesüsteemiga, mis automaatselt saadab hoolduse taotluse IBM-i tugiteenusele, kui tekkib tõrge. Koostatakse juhul ingliskeelne taotlus ja IBM-i spetsialistid viivad diagnoosimise läbi eemalt ning võtavad ühendust süsteemi kasutajaga. 

Tänu sellele lahendati probleem kiiresti ja toetasime väga soovitatud uuendamise meie süsteemile juba valitud versioonile 8.2.1.9, kus see probleem oli juba lahendatud. See kinnitab vastavat Release Note'i.

Kokkuvõtted ja meie soovitused

Nagu öeldakse: «hea on see, mis hästi lõppeb». Firmware'i viga ei toonud kaasa tõsiseid probleeme — serverite töö taastati lühiajalise ja andmete kaota. Mõned kliendid pidid virtuaalmasinad taaskäivitama, kuid tervikuna olime valmis halvemateks tagajärgedeks, kuna teeme igapäevaselt varukoopiaid kõigist infrastruktuuri elementidest ja kliendimasinatest. 

Saime kinnituse, et isegi usaldusväärsed süsteemid, mille lubatud kättesaadavus on 99,9999%, vajavad tähelepanu ja õigeaegset hooldust. Olukorrast lähtuvalt tegime endale mitmeid järeldusi ja jagame oma soovitusi:

• On oluline jälgida värskenduste väljalaskmist, tutvuda Release Notes'idega, et uurida potentsiaalselt kriitilisi parandusi, ja õigeaegselt teostada planeeritud värskendused.

  See on organisatoorne ja isegi üsna ilmselge punkt, millega ei tohiks, näiliselt, liiga palju tähelepanu pöörata. Siiski, just selle „tasase koha” peal on üsna lihtne komistada. Just see punkt tekitas eespool mainitud ebamugavusi. Suhtuge värskenduste regulatsiooni koostamisse väga tähelepanelikult ja jälgige hoolikalt selle järgimist. See punkt kuulub pigem distsipliini mõistetesse.

• Alati on parem hoida süsteemi koos ajakohase tarkvaraversiooniga. Ja ajakohane – ei ole see, millel on suurem numbriline tähis, vaid just viimasest väljalaske kuupäevast. 

  Näiteks hoiab IBM oma andmehoidlussüsteemide jaoks ajakohasena vähemalt kahte tarkvaraversiooni. Käesoleva artikli kirjutamise hetkel on need 8.2 ja 8.3. Värskendused 8.2 jaoks väljastatakse varem. Järgneb väikese viivitusega tavaliselt analoogne uuendus 8.3 jaoks.

  Versioon 8.3 on mitmeid funktsionaalset eelised, näiteks võimalus laiendada MDisk'i (DRAID-režiimis) ühe või mitme uue ketta lisamisega (see võimalus ilmus alates versioonist 8.3.1). See on üsna põhiline funktsionaalsus, kuid versioonis 8.2 kahjuks sellist võimalust pole.

• Kui uuendamine mingil põhjusel pole võimalik, siis Spectrum Virtualize'i tarkvaraversioonide puhul, mis eelnevad versioonidele 8.2.1.9 ja 8.3.1.0 (kus eespool kirjeldatud viga on aktuaalne), soovitab IBM'i tehniline tugi piirata süsteemi jõudlust tasemel, nagu on näidatud alloleval joonisel (ekraanipilt on tehtud vene keeles lokaliseeritud GUI-st). 10000 IOPS väärtus on näitlik ja valitakse vastavalt teie süsteemi omadustele.

IBM'i salvestusvõime piiramine

• On oluline õigesti arvutada salvestussüsteemide koormus ja vältida ülekoormust. Selleks saab kasutada kas IBM'i suurendajat (kui sellele on juurdepääs), partnerite abi või kolmandate osapoolte ressursse. Samuti on oluline mõista salvestussüsteemile koormuse profiili, kuna jõudlus MB/s ja IOPS erineb oluliselt vähemalt järgmistest parameetritest:

  • tehingu tüüp: lugemine või kirjutamine,

  • tehingu ploki suurus,

  • lugemise ja kirjutamise tehingute protsentuaalne suhe üldises sisendi/väljundi liikumises.

  Samuti mõjutab tehingute täitmise kiirus, kuidas andmablokid loetakse: järjestikku või juhuslikult. Andmete juurdepääsu mitme tehingu teostamise korral rakenduse poolel on sõltuvate tehingute mõisted. Seda on samuti soovitatav arvesse võtta. Kõik see võib aidata näha andmete kogumid operatsioonisüsteemi, salvestussüsteemi, serverite/hüpervõrkude jõudluse loenduritest, samuti mõista rakenduste, andmebaaside ja muude 'ketasressursse' tarbivate omadusi.

• Ja lõpuks, on väga oluline omada varukoopiaid, mis on ajakohased ja töökorras. Varukoopiate ajakava tuleb seadistada vastavalt äritegevuse jaoks vastuvõetavatele RPO väärtustele ja perioodiliselt tuleb kindlasti kontrollida varukoopiate terviklikkust (paljud varukoopia tarkvara tootjad on oma toodetes rakendanud automaatse kontrollimise), et tagada vastuvõetav RTO väärtus.

Aitäh, et viisite lõpuni.
Oleme valmis teie küsimustele ja märkustele kommentaarides vastama. Samuti kutsub teid liituma meie Telegrami kanaliga, kus me korraldame regulaarselt aktsioone (soodustused IaaS-ile ja loosimised kuni 100% VPS-idele mõeldud sooduskoodide kohta), jagame huvitavaid uudiseid ja kuulutame välja uusi artikleid Habr'i blogis.

Allikas: habr.com