Milline püsivara versioon on kõige "õigem" ja "töötavam"? Kui salvestussüsteem tagab tõrketaluvuse 99,9999%, kas see tähendab, et see töötab katkematult ka ilma tarkvarauuenduseta? Või vastupidi, maksimaalse veataluvuse saavutamiseks peaksite alati installima uusima püsivara? Püüame neile küsimustele vastata oma kogemuse põhjal.
Väike sissejuhatus
Me kõik mõistame, et iga tarkvaraversioon, olgu see siis operatsioonisüsteem või seadme draiver, sisaldab sageli defekte/vigu ja muid "funktsioone", mis ei pruugi "ilmuda" enne seadme kasutusea lõppu või "avaneda". ainult teatud tingimustel. Selliste nüansside arv ja olulisus oleneb tarkvara keerukusest (funktsionaalsusest) ja testimise kvaliteedist selle arendamise käigus.
Sageli jäävad kasutajad tehase püsivara juurde (kuulus "see töötab, nii et ärge segage sellega") või installivad alati uusima versiooni (nende arusaamise järgi tähendab uusim kõige töötavamat). Kasutame teistsugust lähenemist – vaatame kõige kasutatud kohta väljalaskemärkmeid seadmeid ja valige hoolikalt iga seadme jaoks sobiv püsivara.
Sellele järeldusele jõudsime, nagu öeldakse, kogemustega. Kasutades oma toimimisnäidet, räägime teile, miks salvestussüsteemide lubatud 99,9999% töökindlus ei tähenda midagi, kui te ei jälgi tarkvara värskendusi ja kirjeldusi kohe. Meie korpus sobib iga müüja salvestussüsteemide kasutajatele, kuna sarnane olukord võib juhtuda mis tahes tootja riistvaraga.
Uue salvestussüsteemi valimine
Eelmise aasta lõpus lisandus meie infrastruktuuri huvitav andmesalvestussüsteem: IBM FlashSystem 5000 sarja juuniormudel, mis ostuhetkel kandis nime Storwize V5010e. Nüüd müüakse seda küll FlashSystem 5010 nime all, kuid tegelikult on see sama riistvarabaas, mille sees on sama Spectrum Virtualize.
Muide, IBM FlashSystemi peamine erinevus on ühtse haldussüsteemi olemasolu. Noorema seeria mudelite puhul ei erine see praktiliselt produktiivsemate mudelite mudelitest. Konkreetse mudeli valimine annab ainult sobiva riistvarabaasi, mille omadused võimaldavad kasutada üht või teist funktsionaalsust või pakkuda kõrgemat skaleeritavust. Tarkvara tuvastab riistvara ja tagab selle platvormi jaoks vajaliku ja piisava funktsionaalsuse.
IBM FlashSystem 5010
Lühidalt meie mudelist 5010. See on algtaseme kahe kontrolleriga plokkide salvestussüsteem. See mahutab NLSAS-i, SAS-i, SSD-kettaid. NVMe paigutus pole selles saadaval, kuna see salvestusmudel on paigutatud selliste probleemide lahendamiseks, mis ei nõua NVMe-draivide jõudlust.
Salvestussüsteem osteti selleks, et mahutada arhiiviteavet või andmeid, millele sageli juurde ei pääseta. Seetõttu piisas meile selle funktsionaalsuse standardkomplektist: Tiring (Easy Tier), Thin Provision. NLSAS-ketaste jõudlus 1000-2000 IOPS tasemel oli ka meie jaoks üsna rahuldav.
Meie kogemus - kuidas me ei värskendanud püsivara õigel ajal
Nüüd tarkvarauuendusest endast. Ostuhetkel oli süsteemil juba Spectrum Virtualize tarkvara veidi aegunud versioon, nimelt 8.2.1.3.
Uurisime püsivara kirjeldusi ja kavandasime selle värskenduse 8.2.1.9. Kui oleksime olnud veidi tõhusamad, poleks seda artiklit olnud – viga poleks uuemas püsivara puhul ilmnenud. Teatud põhjustel lükati aga selle süsteemi uuendamine edasi.
Selle tulemusena põhjustas väike värskenduse viivitus äärmiselt ebameeldiva pildi, nagu lingi kirjelduses: .
Jah, selle versiooni püsivaras oli asjakohane niinimetatud APAR (Authorized Program Analysis Report) HU02104. See näeb välja järgmine. Koormuse korral hakkab vahemälu teatud tingimustel üle ajama, seejärel läheb süsteem kaitserežiimi, kus see keelab basseini sisendi/väljundi. Meie puhul nägi see välja nagu RAID grupi jaoks 3 ketta lahtiühendamine režiimis RAID 6. Ühenduse katkestamine toimub 6 minuti jooksul. Järgmisena taastatakse juurdepääs basseini mahtudele.
Kui keegi ei ole kursis loogiliste olemite struktuuri ja nimetamisega IBM Spectrum Virtualize kontekstis, siis selgitan nüüd lühidalt.
Salvestussüsteemi loogiliste elementide struktuur
Kettad kogutakse rühmadesse nimega MDisk (hallatud ketas). MDisk võib olla klassikaline RAID (0,1,10,5,6) või virtualiseeritud - DRAID (Distributed RAID). DRAID-i kasutamine võimaldab suurendada massiivi jõudlust, kuna... Kasutatakse kõiki rühma kettaid ja taastamisaeg väheneb, kuna taastada tuleb ainult teatud plokid, mitte kõik andmed ebaõnnestunud kettalt.
Andmeplokkide jaotus ketaste vahel, kui kasutatakse hajutatud RAID-i (DRAID) RAID-5 režiimis.
Ja see diagramm näitab loogikat, kuidas DRAID-i ümberehitamine töötab ühe ketta rikke korral:
DRAID-i taasehitamise loogika, kui üks ketas ebaõnnestub
Järgmiseks moodustavad üks või mitu MDiski nn basseini. Samas basseinis ei ole soovitatav kasutada sama tüüpi ketastel erineva RAID/DRAID tasemega MDiskit. Me ei lasku sellesse liiga sügavalt, sest... kavatseme seda käsitleda ühes järgmistest artiklitest. Noh, tegelikult on Pool jagatud köideteks, mis esitatakse hostidele ühe või teise blokeerimisprotokolli abil.
Niisiis, meie, punktis kirjeldatud olukorra tulemusena APAR HU02104, kolme ketta loogilise rikke tõttu lakkas MDisk töötamast, mis omakorda tõi kaasa basseini ja vastavate köidete rikke.
Kuna need süsteemid on üsna nutikad, saab neid ühendada pilvepõhise jälgimissüsteemiga IBM Storage Insights, mis saadab probleemi ilmnemisel automaatselt teenusepäringu IBMi toele. Luuakse rakendus ja IBM-i spetsialistid viivad distantsilt läbi diagnostika ja võtavad süsteemi kasutajaga ühendust.
Tänu sellele lahenes probleem üsna kiiresti ja tugiteenistuselt saadi kiire soovitus uuendada meie süsteem eelnevalt valitud püsivara 8.2.1.9-le, mis oli selleks ajaks juba parandatud. See kinnitab .
Tulemused ja meie soovitused
Nagu öeldakse: "Kõik on hästi, mis hästi lõpeb." Püsivara viga tõsiseid probleeme ei tekitanud – serverid taastati nii kiiresti kui võimalik ja ilma andmete kadumiseta. Mõned kliendid pidid virtuaalmasinaid taaskäivitama, kuid üldiselt olime valmis negatiivsemateks tagajärgedeks, kuna teeme igapäevaselt kõikidest taristuelementidest ja kliendimasinatest varukoopiaid.
Oleme saanud kinnitust, et isegi töökindlad süsteemid, mille lubatud saadavus on 99,9999%, nõuavad tähelepanu ja õigeaegset hooldust. Olukorra põhjal oleme teinud enda jaoks mitmeid järeldusi ja jagame soovitusi:
-
Tähtis on jälgida värskenduste väljalaskmist, uurida väljalaskemärkmeid potentsiaalselt kriitiliste probleemide paranduste osas ja viia plaanitud värskendused õigeaegselt läbi.
See on korralduslik ja isegi üsna ilmne punkt, millele näib, et ei tasu keskenduda. Sellel “tasasel pinnal” võib aga üsna kergesti komistada. Tegelikult lisas see hetk ülalkirjeldatud mured. Olge värskendusmääruste koostamisel väga ettevaatlik ja jälgige nende täitmist mitte vähem hoolikalt. See punkt on rohkem seotud "distsipliini" mõistega.
-
Alati on parem säilitada süsteem uusima tarkvaraversiooniga. Pealegi pole praegune see, millel on suurem numbriline tähistus, vaid see, millel on hilisem väljalaskekuupäev.
Näiteks hoiab IBM oma salvestussüsteemide jaoks ajakohasena vähemalt kahte tarkvaraversiooni. Selle kirjutamise ajal on need 8.2 ja 8.3. 8.2 värskendused ilmuvad varem. Sarnane värskendus versioonile 8.3 avaldatakse tavaliselt väikese viivitusega.
Versioonil 8.3 on mitmeid funktsionaalseid eeliseid, näiteks võimalus laiendada MDiski (DRAID-režiimis) ühe või mitme uue ketta lisamisega (see funktsioon on ilmunud alates versioonist 8.3.1). See on üsna elementaarne funktsioon, kuid versioonis 8.2 sellist funktsiooni kahjuks pole.
-
Kui värskendamine ei ole mingil põhjusel võimalik, siis Spectrum Virtualize'i tarkvara versioonidele, mis on varasemad versioonid 8.2.1.9 ja 8.3.1.0 (kus ülalkirjeldatud viga on asjakohane), soovitab IBMi tehniline tugi selle esinemise riski vähendamiseks. süsteemi jõudluse piiramine basseini tasemel, nagu on näidatud alloleval joonisel (pilt on tehtud GUI venestatud versioonis). Väärtus 10000 IOPS on näidatud näitena ja see valitakse vastavalt teie süsteemi omadustele.
IBM-i salvestusruumi jõudluse piiramine
-
On vaja õigesti arvutada laosüsteemide koormus ja vältida ülekoormust. Selleks võite kasutada kas IBM sizerit (kui teil on sellele juurdepääs) või partnerite abi või kolmandate osapoolte ressursse. Oluline on mõista salvestussüsteemi koormusprofiili, sest Jõudlus MB/s ja IOPS-is varieerub suuresti sõltuvalt vähemalt järgmistest parameetritest:
-
operatsiooni tüüp: lugemine või kirjutamine,
-
operatsiooniploki suurus,
-
lugemis- ja kirjutamisoperatsioonide protsent kogu I/O voos.
Samuti mõjutab toimingute kiirust see, kuidas andmeplokke loetakse: järjestikku või juhuslikus järjekorras. Kui sooritate rakenduse poolel mitut andmetele juurdepääsu toimingut, on olemas sõltuvate toimingute kontseptsioon. Samuti on soovitatav seda arvesse võtta. Kõik see võib aidata näha OS-i, salvestussüsteemi, serverite/hüperviisorite jõudlusloendurite andmete kogumit, samuti mõista rakenduste, DBMS-ide ja muude kettaressursside "tarbijate" tööfunktsioone.
-
-
Ja lõpuks veenduge, et varukoopiad oleksid ajakohased ja töötavad. Varundamise ajakava tuleks konfigureerida ettevõtte jaoks vastuvõetavate RPO väärtuste alusel ja varukoopiate perioodilisi terviklikkuse kontrollimisi tuleks kontrollida (üsna mitmel varundustarkvara müüjal on oma toodetes automaatne kontrollimine), et tagada vastuvõetav RTO väärtus.
Täname, et lugesite lõpuni.
Oleme valmis vastama teie küsimustele ja kommentaaridele kommentaarides. Samuti, milles korraldame regulaarseid tutvustusi (IaaS-i allahindlused ja VPS-is kuni 100% sooduskoodide kingitused), kirjutame huvitavaid uudiseid ja anname teada uutest artiklitest Habri ajaveebis.
Allikas: www.habr.com