Hvaða vélbúnaðarútgáfa er „réttust“ og „virkust“? Ef geymslukerfi tryggir bilanaþol upp á 99,9999%, þýðir það þá að það virki án truflana jafnvel án hugbúnaðaruppfærslu? Eða þvert á móti, til að fá hámarks bilanaþol, ættirðu alltaf að setja upp nýjustu vélbúnaðinn? Við munum reyna að svara þessum spurningum út frá reynslu okkar.
Lítil kynning
Við skiljum öll að hver útgáfa af hugbúnaði, hvort sem það er stýrikerfi eða rekla fyrir tæki, inniheldur oft galla/galla og aðra „eiginleika“ sem „birtist“ kannski ekki fyrr en í lok endingartíma búnaðarins, eða „opnir“ aðeins við ákveðnar aðstæður. Fjöldi og mikilvægi slíkra blæbrigða fer eftir því hversu flókið (virkni) hugbúnaðurinn er og gæðum prófana meðan á þróun hans stendur.
Oft eru notendur áfram á „fastbúnaðinum frá verksmiðjunni“ (hið fræga „það virkar, svo ekki skipta sér af því“) eða setja alltaf upp nýjustu útgáfuna (að þeirra skilningi þýðir það nýjasta að virka). Við notum aðra nálgun - við skoðum útgáfuskýringarnar fyrir allt sem notað er búnað og veldu vandlega viðeigandi fastbúnað fyrir hvern búnað.
Við komumst að þessari niðurstöðu, eins og sagt er, með reynslu. Með því að nota dæmi okkar um rekstur, munum við segja þér hvers vegna lofað 99,9999% áreiðanleiki geymslukerfa þýðir ekkert ef þú fylgist ekki tafarlaust með hugbúnaðaruppfærslum og lýsingum. Taskan okkar hentar notendum geymslukerfa frá hvaða söluaðila sem er, þar sem svipað ástand getur gerst með vélbúnað frá hvaða framleiðanda sem er.
Að velja nýtt geymslukerfi
Í lok síðasta árs var áhugavert gagnageymslukerfi bætt við innviði okkar: yngri gerð úr IBM FlashSystem 5000 línunni, sem við kaupin hét Storwize V5010e. Nú er það selt undir nafninu FlashSystem 5010, en í raun er það sama vélbúnaðargrunnurinn með sama Spectrum Virtualize inni.
Tilvist sameinaðs stjórnunarkerfis er, við the vegur, aðalmunurinn á IBM FlashSystem. Fyrir gerðir af yngri seríunni er það nánast ekkert frábrugðið líkönum af afkastameiri. Að velja sérstakt líkan veitir aðeins viðeigandi vélbúnaðargrunn, þar sem eiginleikar þess gera það mögulegt að nota eina eða aðra virkni eða veita hærra stig sveigjanleika. Hugbúnaðurinn auðkennir vélbúnaðinn og veitir nauðsynlega og fullnægjandi virkni fyrir þennan vettvang.
IBM FlashSystem 5010
Stuttlega um líkanið okkar 5010. Þetta er inngangs-stigs geymslukerfi með tvístýringu. Það getur hýst NLSAS, SAS, SSD diska. NVMe staðsetning er ekki fáanleg í því, þar sem þetta geymslulíkan er staðsett til að leysa vandamál sem krefjast ekki frammistöðu NVMe drif.
Geymslukerfið var keypt til að koma til móts við geymsluupplýsingar eða gögn sem ekki er oft aðgangur að. Þess vegna var staðlað sett af virkni þess nóg fyrir okkur: Tiering (Easy Tier), Thin Provision. Frammistaða á NLSAS diskum á stigi 1000-2000 IOPS var líka alveg viðunandi fyrir okkur.
Reynsla okkar - hvernig við uppfærðum ekki fastbúnaðinn á réttum tíma
Nú um hugbúnaðaruppfærsluna sjálfa. Þegar það var keypt var kerfið þegar með örlítið úrelta útgáfu af Spectrum Virtualize hugbúnaðinum, þ.e. 8.2.1.3.
Við skoðuðum vélbúnaðarlýsingarnar og skipulögðum uppfærslu á 8.2.1.9. Ef við hefðum verið aðeins duglegri hefði þessi grein ekki verið til - villan hefði ekki átt sér stað á nýrri vélbúnaðar. Uppfærslu þessa kerfis var hins vegar frestað af ákveðnum ástæðum.
Fyrir vikið leiddi lítilsháttar seinkun á uppfærslu til afar óþægilegrar myndar, eins og í lýsingunni á hlekknum: .
Já, í fastbúnaði þeirrar útgáfu átti svokölluð APAR (Authorized Program Analysis Report) HU02104 við. Það birtist sem hér segir. Undir álagi, undir vissum kringumstæðum, byrjar skyndiminni að flæða yfir, þá fer kerfið í verndarham, þar sem það slekkur á I/O fyrir sundlaugina. Í okkar tilviki leit það út eins og að aftengja 3 diska fyrir RAID hóp í RAID 6 ham. Aftengingin á sér stað í 6 mínútur. Næst er aðgangur að bindum í lauginni endurheimtur.
Ef einhver kannast ekki við uppbyggingu og nafngiftir á rökréttum einingum í samhengi við IBM Spectrum Virtualize, mun ég nú útskýra stuttlega.
Uppbygging geymslukerfis rökrétta þætti
Diskum er safnað í hópa sem kallast MDisk (Managed Disk). MDisk getur verið klassískt RAID (0,1,10,5,6) eða sýndargerð - DRAID (Dreift RAID). Notkun DRAID gerir þér kleift að auka afköst fylkisins, vegna þess að... Allir diskar í hópnum verða notaðir og endurbyggingartími mun styttast, vegna þess að aðeins þarf að endurheimta ákveðnar blokkir en ekki öll gögn frá bilaða disknum.
Dreifing gagnablokka yfir diska þegar dreift RAID (DRAID) er notað í RAID-5 ham.
Og þessi skýringarmynd sýnir rökfræði hvernig DRAID endurbygging virkar ef ein diskbilun verður:
Rökfræði DRAID endurbyggingar þegar einn diskur bilar
Næst mynda einn eða fleiri MDiskar svokallaðan Pool. Innan sömu laugar er ekki mælt með því að nota MDisk með mismunandi RAID/DRAID stigum á diskum af sömu gerð. Við munum ekki fara djúpt í þetta, því... við ætlum að fjalla um þetta í einni af eftirfarandi greinum. Jæja, í raun er Pool skipt í bindi, sem eru kynnt með einni eða annarri blokkaðgangsreglu fyrir gestgjafana.
Þannig að við, vegna ástandsins sem lýst er í APAR HU02104, vegna rökrænnar bilunar þriggja diska, hætti MDisk að vera virkur, sem aftur leiddi til bilunar í lauginni og samsvarandi bindi.
Vegna þess að þessi kerfi eru nokkuð snjöll er hægt að tengja þau við IBM Storage Insights skýjabundið eftirlitskerfi sem sendir sjálfkrafa þjónustubeiðni til stuðningsþjónustu IBM ef vandamál koma upp. Forrit er búið til og sérfræðingar IBM framkvæma fjargreiningar og hafa samband við kerfisnotandann.
Þökk sé þessu var málið leyst nokkuð fljótt og tafarlaus tilmæli bárust frá stuðningsþjónustunni um að uppfæra kerfið okkar í áður valinn fastbúnað 8.2.1.9, sem á þeim tíma hafði þegar verið lagaður. Það staðfestir .
Niðurstöður og ráðleggingar okkar
Eins og orðatiltækið segir: "allt er gott sem endar vel." Villan í fastbúnaðinum olli ekki alvarlegum vandamálum - netþjónarnir voru endurheimtir eins fljótt og auðið var og án gagnataps. Sumir viðskiptavinir þurftu að endurræsa sýndarvélar, en almennt vorum við viðbúin neikvæðari afleiðingum, þar sem við gerum daglega afrit af öllum innviðaþáttum og biðlaravélum.
Við höfum fengið staðfestingu á því að jafnvel áreiðanleg kerfi með 99,9999% lofað framboð krefjast athygli og tímanlega viðhalds. Miðað við ástandið höfum við dregið ýmsar ályktanir fyrir okkur og deilum ráðleggingum okkar:
-
Nauðsynlegt er að fylgjast með útgáfu uppfærslna, rannsaka útgáfuskýringar fyrir leiðréttingar á hugsanlegum mikilvægum atriðum og framkvæma fyrirhugaðar uppfærslur tímanlega.
Þetta er skipulagslegur og jafnvel alveg augljós liður, sem að því er virðist ekki vert að einblína á. Hins vegar geturðu auðveldlega hrasað á þessum „sléttu jörðu“. Reyndar var það þetta augnablik sem bætti við vandræðum sem lýst er hér að ofan. Verið mjög varkár við gerð uppfærslureglugerða og fylgist ekki síður vel með því að farið sé að þeim. Þetta atriði tengist meira hugtakinu „aga“.
-
Það er alltaf betra að hafa kerfið með nýjustu hugbúnaðarútgáfunni. Þar að auki er núverandi ekki sá sem hefur stærri tölulega heiti, heldur sá sem er með síðari útgáfudag.
Til dæmis heldur IBM að minnsta kosti tveimur hugbúnaðarútgáfum uppfærðum fyrir geymslukerfi sín. Þegar þetta er skrifað eru þetta 8.2 og 8.3. Uppfærslur fyrir 8.2 koma út fyrr. Svipuð uppfærsla fyrir 8.3 er venjulega gefin út með smá seinkun.
Útgáfa 8.3 hefur ýmsa hagnýta kosti, til dæmis möguleikann á að stækka MDisk (í DRAID ham) með því að bæta við einum eða fleiri nýjum diskum (þessi eiginleiki hefur birst síðan útgáfa 8.3.1). Þetta er frekar grunnvirkni, en í 8.2 er því miður enginn slíkur eiginleiki.
-
Ef það er ekki hægt að uppfæra af einhverjum ástæðum, þá fyrir útgáfur af Spectrum Virtualize hugbúnaði fyrir útgáfur 8.2.1.9 og 8.3.1.0 (þar sem villan sem lýst er hér að ofan á við), til að draga úr hættunni á að hann komi upp, mælir tækniaðstoð IBM með takmarka afköst kerfisins á laugarstigi, eins og sýnt er á myndinni hér að neðan (myndin var tekin í rússuðu útgáfunni af GUI). Gildið 10000 IOPS er sýnt sem dæmi og er valið í samræmi við eiginleika kerfisins þíns.
Takmarka afköst IBM geymslu
-
Nauðsynlegt er að reikna út álag á geymslukerfi rétt og forðast ofhleðslu. Til að gera þetta geturðu notað annað hvort IBM stærðarbúnaðinn (ef þú hefur aðgang að honum), eða hjálp samstarfsaðila eða tilföng þriðja aðila. Það er mikilvægt að skilja álagssniðið á geymslukerfinu, vegna þess að MB/s og IOPS árangur er mjög mismunandi eftir að minnsta kosti eftirfarandi breytum:
-
gerð aðgerða: lesa eða skrifa,
-
stærð aðgerðablokkar,
-
hlutfall les- og skrifaaðgerða í heildar I/O straumnum.
Einnig hefur hraði aðgerða áhrif á hvernig gagnablokkir eru lesnar: í röð eða í handahófi. Þegar margar gagnaaðgangsaðgerðir eru framkvæmdar á forritahliðinni er hugmyndin um háðar aðgerðir. Það er líka ráðlegt að taka tillit til þessa. Allt þetta getur hjálpað til við að sjá heildar gagna frá frammistöðuteljara stýrikerfisins, geymslukerfisins, netþjóna/hypervisora, sem og skilning á rekstrareiginleikum forrita, DBMS og annarra „neytenda“ diskaauðlinda.
-
-
Og að lokum, vertu viss um að hafa öryggisafrit uppfærð og virka. Afritunaráætlunin ætti að vera stillt út frá ásættanlegum RPO gildum fyrir fyrirtækið og reglubundnar heilleikaathuganir á afritunum ættu að vera sannreyndar (nokkrir afritahugbúnaðarframleiðendur hafa sjálfvirka sannprófun innleidda í vörur sínar) til að tryggja ásættanlegt RTO gildi.
Þakka þér fyrir að lesa til enda.
Við erum tilbúin til að svara spurningum þínum og athugasemdum í athugasemdunum. Einnig, þar sem við höldum reglulega kynningar (afsláttur á IaaS og uppljóstrun fyrir kynningarkóða allt að 100% á VPS), skrifum áhugaverðar fréttir og tilkynnum nýjar greinar á Habr blogginu.
Heimild: www.habr.com