Cili version i firmware-it Ă«shtĂ« mĂ« âi duhuriâ dhe mĂ« âstabiliâ? NĂ«se sistemi i ruajtjes garanton tolerancĂ« ndaj dĂ«shtimeve prej 99,9999%, a do tĂ« thotĂ« kjo se do tĂ« funksionojĂ« pa ndĂ«rprerje edhe pa pĂ«rditĂ«sim tĂ« softuerit? Apo, pĂ«rkundrazi, pĂ«r tĂ« arritur tolerancĂ«n maksimale ndaj dĂ«shtimeve duhet instaluar gjithmonĂ« firmware-i mĂ« i fundit? Do tĂ« pĂ«rpiqemi tâu pĂ«rgjigjemi kĂ«tyre pyetjeve duke u mbĂ«shtetur nĂ« pĂ«rvojĂ«n tonĂ«.
Një hyrje e shkurtër
TĂ« gjithĂ« e kuptojmĂ« se çdo version i softuerit, qoftĂ« sistem operativ apo driver pĂ«r njĂ« pajisje tĂ« caktuar, shpesh pĂ«rmban mangĂ«si/bug-e dhe âveçoriâ tĂ« tjera, tĂ« cilat mund tĂ« mos shfaqen deri nĂ« fund tĂ« jetĂ«s sĂ« pajisjes, ose tĂ« dalin nĂ« pah vetĂ«m nĂ« kushte tĂ« caktuara. Numri dhe rĂ«ndĂ«sia e kĂ«tyre nuancave varen nga kompleksiteti (funksionaliteti) i softuerit dhe nga cilĂ«sia e testimit gjatĂ« zhvillimit tĂ« tij.Â
Shpesh pĂ«rdoruesit qĂ«ndrojnĂ« te âfirmware-i nga fabrikaâ (shprehja e njohur: «nĂ«se funksionon, mos e prek») ose instalojnĂ« gjithmonĂ« versionin mĂ« tĂ« fundit (sipas tyre, mĂ« i fundit do tĂ« thotĂ« edhe mĂ« i qĂ«ndrueshmi). Ne pĂ«rdorim njĂ« qasje tjetĂ«r â shqyrtojmĂ« release notes pĂ«r tĂ« gjithĂ« pajisjen qĂ« pĂ«rdorim dhe zgjedhim me kujdes firmware-in e pĂ«rshtatshĂ«m pĂ«r secilĂ«n njĂ«si.
Në këtë përfundim kemi arritur, siç thuhet, me përvojë. Nga praktika jonë e përdorimit do të shpjegojmë pse 99,9999 % e besueshmërisë së premtuar për sistemin e ruajtjes nuk do të thonë asgjë nëse nuk ndiqni në kohë përditësimet dhe përshkrimet e softuerit. Rasti ynë është i vlefshëm për përdoruesit e sistemeve të ruajtjes të çdo prodhuesi, sepse një situatë e tillë mund të ndodhë me pajisje të çdo marke.
Zgjedhja e një sistemi të ri të ruajtjes së të dhënave
NĂ« fund tĂ« vitit tĂ« kaluar, infrastrukturĂ«s sonĂ« iu shtua njĂ« sistem interesant i ruajtjes sĂ« tĂ« dhĂ«nave: modeli bazĂ« i linjĂ«s IBM FlashSystem 5000, i cili nĂ« momentin e blerjes quhej Storwize V5010e. Tani ai shitet me emrin FlashSystem 5010, por nĂ« thelb Ă«shtĂ« e njĂ«jta platformĂ« harduerike me tĂ« njĂ«jtin Spectrum Virtualize brenda.Â
Prania e një sistemi të unifikuar menaxhimi është, në fakt, edhe dallimi kryesor i IBM FlashSystem. Te modelet e serisë bazë, ai pothuajse nuk ndryshon nga modelet më të fuqishme. Zgjedhja e një modeli të caktuar thjesht siguron bazën përkatëse harduerike, karakteristikat e së cilës bëjnë të mundur përdorimin e këtij apo atij funksionaliteti ose ofrimin e një niveli më të lartë shkallëzueshmërie. Ndërkohë, softueri identifikon pjesën harduerike dhe ofron funksionalitetin e nevojshëm dhe të mjaftueshëm për këtë platformë.
IBM FlashSystem 5010
Shkurtimisht për modelin tonë 5010. Kjo është një sistem ruajtjeje të dhënash me blloqe, me dy kontrollues, i nivelit fillestar. Ai mbështet disqe NLSAS, SAS dhe SSD. Vendosja e NVMe në të nuk është e disponueshme, pasi ky model i sistemit të ruajtjes pozicionohet për zgjidhjen e detyrave që nuk kërkojnë performancën e disqeve NVMe.
Sistemi i ruajtjes u ble pĂ«r vendosjen e informacionit arkivor ose tĂ« dhĂ«nave qĂ« nuk aksesohen shpesh. Prandaj, pĂ«r ne ishte i mjaftueshĂ«m seti standard i funksioneve tĂ« tij: tiering (Easy Tier), Thin Provision. Edhe performanca prej 1000â2000 IOPS nĂ« disqet NLSAS na pĂ«rshtatej plotĂ«sisht.
PĂ«rvoja jonĂ« â si nuk e pĂ«rditĂ«suam firmware-in nĂ« kohĂ«
Tani, konkretisht për vetë përditësimin e softuerit. Në momentin e blerjes, sistemi kishte tashmë një version disi të vjetëruar të softuerit Spectrum Virtualize, përkatësisht, 8.2.1.3.
Ne studiuam pĂ«rshkrimin e firmware-eve dhe planifikuam pĂ«rditĂ«simin nĂ« 8.2.1.9. Po tĂ« kishim qenĂ« pak mĂ« tĂ« shpejtĂ«, ky artikull nuk do tĂ« ekzistonte â nĂ« njĂ« firmware mĂ« tĂ« ri ky bug nuk do tĂ« ishte shfaqur. MegjithatĂ«, pĂ«r arsye tĂ« caktuara, pĂ«rditĂ«simi i kĂ«tij sistemi u shty.
Si rezultat, njĂ« vonesĂ« e vogĂ«l nĂ« pĂ«rditĂ«sim çoi nĂ« njĂ« situatĂ« jashtĂ«zakonisht tĂ« pakĂ«ndshme, siç pĂ«rshkruhet nĂ« lidhjen mĂ« poshtĂ«: .Â
Po, nĂ« firmware-in e atij versioni ishte pikĂ«risht aktual i ashtuquajturi APAR (Authorized Program Analysis Report) HU02104. Ai shfaqet nĂ« kĂ«tĂ« mĂ«nyrĂ«. NĂ«n ngarkesĂ«, nĂ« rrethana tĂ« caktuara, cache fillon tĂ« mbushet tej mase; mĂ« pas sistemi kalon nĂ« modalitet mbrojtĂ«s, nĂ« tĂ« cilin çaktivizon input/output pĂ«r Pool-in. NĂ« rastin tonĂ«, kjo u duk si çaktivizim i 3 disqeve pĂ«r grupin RAID nĂ« modalitetin RAID 6. Ăaktivizimi zgjat 6 minuta. MĂ« pas, qasja te Volumet nĂ« Pool rikthehet.
Nëse dikush nuk është i njohur me strukturën dhe emërtimin e entiteteve logjike në kontekstin e IBM Spectrum Virtualize, do ta shpjegoj shkurt tani.
Struktura e elementeve logjike të sistemit të ruajtjes
Disqet grupohen nĂ« njĂ«si qĂ« quhen MDisk (Managed Disk). MDisk mund tĂ« pĂ«rfaqĂ«sojĂ« njĂ« RAID klasik (0,1,10,5,6) ose njĂ« variant tĂ« virtualizuar â DRAID (Distributed RAID). PĂ«rdorimi i DRAID lejon rritjen e performancĂ«s sĂ« array-t, pasi pĂ«rdoren tĂ« gjithĂ« disqet e grupit, dhe ul kohĂ«n e rebuild-it, sepse duhet tĂ« rikthehen vetĂ«m blloqe tĂ« caktuara, jo tĂ« gjitha tĂ« dhĂ«nat nga disku qĂ« ka dalĂ« jashtĂ« funksionit.
Shpërndarja e blloqeve të të dhënave nëpër disqe gjatë përdorimit të Distributed RAID (DRAID) në modalitetin RAID-5.
Ndërsa kjo skemë tregon logjikën e funksionimit të rebuild-it të DRAID në rast të dështimit të një disku:
Logjika e funksionimit të rebuild-it të DRAID në rast të dështimit të një disku
Më pas, një ose disa MDisk formojnë të ashtuquajturin Pool. Brenda të njëjtit pool, nuk rekomandohet përdorimi i MDisk me nivele të ndryshme RAID/DRAID mbi disqe të të njëjtit lloj. Nuk do të hyjmë shumë në këtë temë, pasi planifikojmë ta trajtojmë në një nga artikujt e ardhshëm. Dhe, në thelb, Pool ndahet në Volumes, të cilat prezantohen drejt hosteve përmes njërit ose tjetrit protokoll të aksesit në nivel blloku.
Kështu, si rezultat i situatës së përshkruar në APAR HU02104, për shkak të dështimit logjik të tre disqeve, MDisk pushoi së funksionuari, gjë që nga ana e vet shkaktoi ndërprerjen e funksionimit të Pool dhe Volumes përkatëse.
MeqenĂ«se kĂ«to sisteme janĂ« mjaft âinteligjenteâ, ato mund tĂ« lidhen me sistemin cloud tĂ« monitorimit IBM Storage Insights, i cili, nĂ« mĂ«nyrĂ« automatike, kur ndodh njĂ« defekt, dĂ«rgon njĂ« kĂ«rkesĂ« shĂ«rbimi te mbĂ«shtetja e IBM. Krijohet njĂ« tiketĂ« dhe specialistĂ«t e IBM kryejnĂ« diagnostikim nĂ« distancĂ« dhe kontaktojnĂ« pĂ«rdoruesin e sistemit.Â
Falë kësaj, çështja u zgjidh mjaft shpejt dhe nga shërbimi i mbështetjes morëm një rekomandim të menjëhershëm për të përditësuar sistemin tonë në firmware-in 8.2.1.9, të zgjedhur më herët prej nesh, ku në atë kohë ky problem ishte tashmë i korrigjuar. Këtë e konfirmon .
PĂ«rfundimet dhe rekomandimet tona
Siç thuhet: «çdo gjĂ« Ă«shtĂ« mirĂ« kur pĂ«rfundon mirë». Defekti nĂ« firmware nuk shkaktoi probleme serioze â funksionimi i serverĂ«ve u rikthye nĂ« kohĂ«n mĂ« tĂ« shkurtĂ«r dhe pa humbje tĂ« tĂ« dhĂ«nave. PĂ«r disa klientĂ« u desh tĂ« ristartonim makinat virtuale, por nĂ« pĂ«rgjithĂ«si ishim tĂ« pĂ«rgatitur pĂ«r pasoja mĂ« negative, pasi çdo ditĂ« krijojmĂ« kopje rezervĂ« tĂ« tĂ« gjithĂ« elementĂ«ve tĂ« infrastrukturĂ«s dhe tĂ« makinave tĂ« klientĂ«ve.Â
Morëm konfirmimin se edhe sistemet e besueshme me 99,9999% disponueshmëri të premtuar kërkojnë vëmendje dhe mirëmbajtje në kohë. Nisur nga kjo situatë, nxorëm disa përfundime dhe po ndajmë rekomandimet tona:
Duhet patjetër të ndiqni publikimin e përditësimeve, të shqyrtoni Release Notes për korrigjimet e çështjeve potencialisht kritike dhe të kryeni në kohë përditësimet e planifikuara.
Ky është një aspekt organizativ dhe madje mjaft i dukshëm, ndaj në pamje të parë duket sikur nuk ia vlen të ndalemi te ai. Megjithatë, pikërisht në një situatë të tillë të thjeshtë mund të gabosh lehtësisht. Në fakt, ishte pikërisht ky moment që solli vështirësitë e përshkruara më sipër. Qasjuni hartimit të rregullores së përditësimit me shumë kujdes dhe po aq me përpikëri monitoroni zbatimin e saj. Kjo pikë lidhet më shumë me nocionin e «disiplinës».
ĂshtĂ« gjithmonĂ« mĂ« mirĂ« ta mbani sistemin me versionin mĂ« aktual tĂ« softuerit. PĂ«r mĂ« tepĂ«r, aktual nuk Ă«shtĂ« ai qĂ« ka njĂ« numĂ«r mĂ« tĂ« madh versioni, por ai me datĂ«n mĂ« tĂ« vonshme tĂ« publikimit.Â
Për shembull, IBM për sistemet e saj të ruajtjes së të dhënave mban të përditësuara të paktën dy release të softuerit. Në momentin e shkrimit të këtij artikulli, këto janë 8.2 dhe 8.3. Përditësimet për 8.2 publikohen më herët. Më pas, zakonisht me një vonesë të vogël, del edhe përditësimi analog për 8.3.
Release 8.3 ka një sërë përparësish funksionale, për shembull mundësinë e zgjerimit të MDisk (në modalitetin DRAID) duke shtuar një ose më shumë disqe të reja (kjo mundësi është në dispozicion që nga versioni 8.3.1). Ky është një funksionalitet mjaft bazë, por në 8.2, për fat të keq, kjo mundësi mungon.
Nëse për çfarëdo arsye përditësimi nuk është i mundur, atëherë për versionet e Spectrum Virtualize para 8.2.1.9 dhe 8.3.1.0 (ku defekti i përshkruar më sipër është i pranishëm), për të ulur rrezikun e shfaqjes së tij, mbështetja teknike e IBM rekomandon kufizimin e performancës së sistemit në nivel pool-i, siç tregohet në figurën më poshtë (pamja është marrë nga versioni i lokalizuar në rusisht i GUI-së). Vlera 10000 IOPS jepet si shembull dhe përcaktohet sipas karakteristikave të sistemit tuaj.
Kufizimi i performancës së sistemit të ruajtjes IBM
Ngarkesa mbi sistemet e ruajtjes duhet llogaritur saktë dhe nuk duhet lejuar mbingarkesa. Për këtë mund të përdorni ose mjetin e dimensionimit të IBM-së (nëse keni qasje në të), ose ndihmën e partnerëve, ose burime të palëve të treta. Njëkohësisht, është thelbësore të kuptohet profili i ngarkesës së sistemit të ruajtjes, sepse performanca në MB/s dhe IOPS ndryshon ndjeshëm të paktën në varësi të parametrave të mëposhtëm:
lloji i operacionit: lexim apo shkrim,
madhësia e bllokut të operacionit,
raporti përqindor i operacioneve të leximit dhe shkrimit në fluksin e përgjithshëm të hyrje-daljes.
Në shpejtësinë e ekzekutimit të operacioneve ndikon edhe mënyra se si lexohen blloqet e të dhënave: në mënyrë sekuenciale apo rastësore. Gjatë kryerjes së disa operacioneve të aksesit në të dhëna nga ana e aplikacionit ekziston edhe koncepti i operacioneve të varura. Edhe kjo është e dëshirueshme të merret parasysh. E gjithë kjo mund të ndihmojë për të parë panoramën e plotë bazuar në të dhënat nga numëruesit e performancës së OS, të sistemit të ruajtjes, serverëve/hipervizorëve, si edhe nga kuptimi i veçorive të funksionimit të aplikacioneve, DBMS-ve dhe konsumatorëve të tjerë të burimeve të diskut.
Dhe së fundi, është e domosdoshme të keni kopje rezervë në gjendje aktuale dhe funksionale. Orari i kopjimit rezervë duhet të konfigurohet sipas vlerave të RPO që janë të pranueshme për biznesin, dhe integriteti i kopjeve rezervë duhet të kontrollohet periodikisht (mjaft prodhues të softuerëve për backup e kanë zbatuar verifikimin e automatizuar në produktet e tyre) për të siguruar një vlerë të pranueshme të RTO.
Faleminderit që lexuat deri në fund.
Jemi gati tâu pĂ«rgjigjemi pyetjeve dhe komenteve tuaja nĂ« komente. Gjithashtu, ku organizojmĂ« rregullisht promocione (ulje pĂ«r IaaS dhe shpĂ«rndarje kodesh promocionale deri nĂ« 100% pĂ«r VPS), publikojmĂ« lajme interesante dhe njoftojmĂ« pĂ«r artikuj tĂ« rinj nĂ« blogun e Habr.
Burimi: habr.com
