Milline on kõige "õigem" ja "töötav" versioon? Kui salvestussüsteem garanteerib katkestusteta töö 99,9999% ulatuses, kas see tähendab, et see töötab pidevalt ka ilma tarkvara uuendamise vajaduseta? Või peaks maksimaalse katkestusteta töö tagamiseks alati kasutama kõige uuemat tarkvara versiooni? Püüame nendele küsimustele vastata, tuginedes oma kogemusele.
Lühike sissejuhatus
K kõik mõistame, et igas tarkvara versioonis, olgu selleks operatsioonisüsteem või draiver mõne seadme jaoks, on sageli puudusi/buge ja muid "eripärasid", mis võivad mitte "ilmuda" kogu seadme elu vältel või "tulla esile" alles kindlates tingimustes. Selliste nüansside arv ja olulisus sõltub tarkvara keerukusest (funktsionaalsusest) ja selle arendamise kvaliteedist.
Kasutajad jäävad sageli „tehasesätetesse“ (kuulus — „kui töötab, siis ei puutu“) või panevad alati kõige uuema versiooni (nende arusaama järgi tähendab viimane versioon alati kõige töökorras olevat). Me kasutame aga teistsugust lähenemist — vaatame kõiki väljaande märkmeid. seadmestikku ning valime hoolikalt välja sobiva tarkvara iga seadme jaoks.
Sellise järelduseni jõudsime, nagu öeldakse, kogemuse kaudu. Oma kogemuse põhjal räägime, miks lubadused 99,9999% usaldusväärsust laoruumides ei tähenda midagi, kui te ei jälgi õigeaegselt tarkvara uuendusi ja kirjeldusi. Meie juhtum sobib kõigi laoruumide kasutajatele, kuna selline olukord võib tekkida iga tootja riistvaraga.
Uue andmesalvestussüsteemi valimine
Eelmisel aastal lisandus meie infrastruktuuri huvitav andmesalvestussüsteem: väiksem mudel IBM FlashSystem 5000 seeriast, mille ostmise ajal nimetati seda Storwize V5010e'ks. Praegu müüakse seda nime all FlashSystem 5010, kuid tegelikult on see sama riistvarabaas sama Spectrum Virtualize sisuga.
Ühtse haldussüsteemi olemasolu on IBM FlashSystemi üks peamisi eristavaid omadusi. Noorema seeria mudelite puhul ei erine see peaaegu üldse tootlikumate mudelite omadustest. Kindla mudeli valik annab vaid vastava riistvara, mille omadused võimaldavad kasutada teatud funktsionaalsust või saavutada kõrgemat skaleeritavuse taset. Tarkvara tuvastab riistvara ja pakub vajalikku ja piisavat funktsionaalsust selle platvormi jaoks.
IBM FlashSystem 5010
Lühidalt meie mudelist 5010. See on kahe kontrolleriga algtaseme andmesalvestussüsteem. See toetab NLSAS, SAS ja SSD ketaste kasutamist. NVMe ketaste kasutamine selles mudelis ei ole võimalik, kuna seda salvestussüsteemi turustatakse ülesannete lahendamiseks, kus NVMe ketaste jõudlus ei ole vajalik.
Seda salvestussüsteemi osteti arhivaalide või harva kasutatavate andmete salvestamiseks. Seetõttu oli meil piisav standardne funktsionaalsete võimaluste komplekt: tasandamine (Easy Tier), Thin Provision. Meid rahuldas ka NLSAS ketaste jõudlus vahemikus 1000–2000 IOPS.
Meie kogemus - kuidas me ei uuendanud tarkvara õigel ajal
Nüüd aga uuendusest endisest. Ostmise hetkel oli süsteemil juba veidi aegunud versioon Spectrum Virtualize tarkvarast, nimelt, 8.2.1.3.
Oleme uurinud tarkvaravärskenduste kirjeldusi ja plaaninud uuendust versioonile 8.2.1.9. Kui oleksime olnud natukenegi kiiremad, poleks seda artiklit kunagi kirjutatud - värskemas versioonis sealset viga ei olnuks. Siiski, teatud põhjustel lükati selle süsteemi uuendus edasi.
Kuna uuenduse edasilükkamine tõi kaasa äärmiselt ebameeldiva olukorra, nagu selles lingis kirjeldatud: .
Jah, tolle versiooni tarkvaras oli tegelikult asjakohane nn APAR (Authorized Program Analysis Report) HU02104. See avaldub järgmiselt: koormuse all ja teatud asjaoludel hakkab vahemälu ületäitumiseks, seejärel läheb süsteem kaitserežiimi, kus väljastamine ja sisend lülitatakse välja (Pool). Meie puhul nägi see välja nagu kolme ketta väljalülitamine RAID-grupis, mis töötab RAID 6 režiimis. Väljalülitus kestab kuus minutit. Seejärel taastatakse juurdepääs Pooletihedusele.
Kui keegi ei tunne IBM Spectrum Virtualize loogiliste üksuste struktuuri ja nimetamist, räägin sellest nüüd lühidalt.
Loogiliste elementide struktuur SRA-d
Kettad kogunevad gruppidesse, mida nimetatakse MDisk (Managed Disk). MDisk võib olla klassikaline RAID (0,1,10,5,6) või virtuaalne – DRAID (Distributed RAID). DRAID kasutamine võimaldab suurendada massiivi jõudlust, kuna kasutatakse kõiki grupi kettaid, ja vähendada rebuild'i aega, kuna tuleb taastada ainult teatud plokid, mitte kõiki andmeid rikutud kettalt.
Andmiplokkide jaotus kettaste vahel Distributed RAID (DRAID) režiimis RAID-5.
See diagramm näitab DRAID'i rebuild'i loogikat, kui üks ketas ebaõnnestub:
DRAID'i rebuild'i loogika ühe ketta ebaõnnestumise korral
Seejärel moodustavad üks või mitu MDisk nn Pooli. Ühe puutöödeldes ei soovitata kasutada MDisk'e erineva RAID/DRAID tasemega ühe tüübi kettadel. Sügavama arutelu jätmiseks plaanime rääkida sellest järgmistes artiklites. Ja põhimõtteliselt jaguneb Pool Volume'iteks, mis esindatakse blokipöörde protokolli kaudu hostide poole.
Nii et meil tekkis olukord, mida kirjeldatakse APAR HU02104, kolme ketta loogilise rikke tõttu lakkas MDisk töötamast, mis omakorda põhjustas Pooli ja vastavate mahu rikke.
Kuna need süsteemid on üsna «nutikad», saab need ühendada IBM Storage Insightsi pilvesüsteemiga, mis automaatselt, rikke korral, saadab hoolduspalve IBM-i tugiteenusele. Koostatakse pood, ja IBM-i spetsialistid teevad kaugdiagnostikat ning võtavad ühendust süsteemi kasutajaga.
Selle tõttu lahendati küsimus üsna kiiresti ja tugiteenuskeskusest saadi kiire soovitus meie süsteemi uuendamiseks juba varem valitud tarkvaraversioonile 8.2.1.9, kus see probleem oli juba lahendatud. See kinnitab .
Kokkuvõtted ja meie soovitused
Nagu öeldakse: "hästi, kui hästi lõpeb." Tarkvaraviga ei põhjustanud tõsiseid probleeme — serverite töö taastati kiiresti ja andmeid ei kaotatud. Mõnede klientide puhul tuli virtuaalmasinad uuesti käivitada, kuid üldiselt olime tõsiste tagajärgede suhtes ettevalmistatud, kuna teeme igapäevaselt varukoopiaid kogu infrastruktuurist ja klientide masinatest.
Saime kinnitust, et isegi usaldusväärsed süsteemid, mille lubatud kättesaadavus on 99,9999%, vajavad tähelepanu ja õigeaegset hooldust. Oleme olukorrast lähtuvalt teinud endale mitmeid järeldusi ning jagame meie soovitusi:
Oluline on jälgida värskenduste väljalaskmist, tutvuda Release Notes'iga võimalike kriitiliste probleemide parandamiseks ja õigeaegselt teostada planeeritud värskendused.
See on organisatsiooniline ja isegi üsna ilmne moment, millele ei tohiks ju tähelepanu pöörata. Siiski, just sellel "ühetaolisel kohal" võib üsna kergesti komistada. Tegelikult on just see moment tekitanud eespool mainitud ebameeldivused. Suhtuge värskendusreegli koostamisse väga tähelepanelikult ja jälgige selle täitmist samasuguse tähelepanuga. See punkt seondub rohkem mõistega "distsipliin".
On alati parem hoida süsteem ajakohase tarkvaraversiooniga. Juhul, kui ajakohane ei tähenda lihtsalt kõrgemat numbrimärki, vaid just hilisema väljalaskekuupäevaga versiooni.
Näiteks hoiab IBM oma andmesalvestussüsteemide jaoks ajakohasena vähemalt kahte tarkvaraversiooni. Selle artikli kirjutamise hetkel on need 8.2 ja 8.3. Värskendused 8.2-le ilmuvad varem. Järgneb tavaliselt väikese viivitusega analoogne värskendus 8.3-le.
Versioon 8.3 sisaldab mitmeid funktsionaalseid eeliseid, näiteks MDisk'i laiendamise võimalust (DRAID-režiimis), uute ketaste lisamisega (see võimalus sai kätte alates versioonist 8.3.1). See on üsna põhipunkt, kuid versioonis 8.2 seda võimalust kahjuks pole.
Kui uuendamine mingil põhjusel ei ole võimalik, siis soovitab IBM-i tehniline tugi versioonidele Spectrum Virtualize, mis eelnevad versioonidele 8.2.1.9 ja 8.3.1.0 (kus eespool kirjeldatud viga on aktuaalne), vähendada süsteemi jõudlust basseini tasemel, nagu on näidatud alloleval joonisel (taskufoto on tehtud venekeelses GUI-s). Väärtus 10000 IOPS on näitena ja sobitatakse vastavalt teie süsteemi omadustele.
IBM-i salvestuslahenduse jõudluse piiramine
Oluline on õigesti arvutada andmehoidlate koormus ja vältida ülekoormust. Selleks võib kasutada kas IBM-i suurendajat (kui sellele on juurdepääs), partnerite abi või kolmandate osapoolte ressursse. Samuti on hädavajalik mõista andmehoidla koormuse profiili, kuna jõudlus MB/s ja IOPS varieerub sõltuvalt vähemalt järgmistest parameetritest:
operatsiooni tüüp: lugemine või kirjutamine,
operatsiooni ploki suurus,
lugemise ja kirjutamise operatsioonide protsentuaalne suhe üldises sisend-väljundvoo voos.
Lisaks mõjutab operatsioonide täitmise kiirus, kuidas andmeblokeid loetakse: järjestikku või juhuslikult. Andmete juurdepääsu täitmise ajal rakenduse poolel on olemas sõltuvate operatsioonide mõisted. Seda tuleks samuti arvesse võtta. Kõik see aitab näha andmete kogumit operatsioonisüsteemi, andmehoidla, serverite/virtualiseerijate jõudlusmeetmete loenditest ning mõista rakenduste, andmebaasihaldussüsteemide ja muude "kettajõudluse" tarbijate töö eripära.
Ja lõpuks, ärge unustage tagada, et varukoopiad oleksid ajakohased ja töötavad. Varundamise ajakava tuleks seadistada vastavalt äri nõuetele RPO ja regulaarselt tuleb kontrollida varukoopiate terviklikkust (paljud varundustarkvara tootjad on oma toodetes rakendanud automaatset kontrolli), et tagada vastuvõetav RTO.
Aitäh, et lugesite lõpuni.
Oleme valmis vastama teie küsimustele ja märkustele kommentaarides. samuti, kus korraldame regulaarselt kampaaniaid (allahindlused IaaS-ile ja loosimised, kus on kuni 100% VPS-i soodustusi), jagame huvitavaid uudiseid ja anname teada uutest artiklitest Habr blogis.
Allikas: habr.com
