Cila është versioni më "i duhuri" dhe "funksional" i firmware? Nëse sistemi i ruajtjes garanton disponueshmëri prej 99,9999%, a do të thotë kjo se ai do të funksionojë pa ndërprerje edhe pa përmirësime të softuerit? Apo për të arritur maksimumin e disponueshmërisë, a duhet gjithmonë të instalojmë versionin më të fundit të firmware? Do të përpiqemi të përgjigjemi në këto pyetje duke u mbështetur në përvojën tonë.
Një hyrje e vogël
TĂ« gjithĂ« ne kuptojmĂ« se nĂ« çdo version tĂ« softuerit, qofshin ato sisteme operative ose drejtuese pĂ«r pajisje tĂ« ndryshme, shpesh ka mangĂ«si/bugs dhe karakteristika tĂ« tjera "veçanta" qĂ« mund tĂ« "shtjellohen" para pĂ«rfundimit tĂ« shĂ«rbimit tĂ« pajisjeve ose tĂ« "shfaqen" vetĂ«m nĂ« kushte tĂ« caktuara. Numri dhe rĂ«ndĂ«sia e kĂ«tyre nuancave varet nga kompleksiteti (funksionaliteti) i softuerit dhe nga cilĂ«sia e testimit gjatĂ« zhvillimit tĂ« tij.Â
Shpesh pĂ«rdoruesit qĂ«ndrojnĂ« nĂ« "firmware-in e fabrikĂ«s" (e njohur ndryshe si "ndikon, pra mos e prek") ose gjithmonĂ« instalojnĂ« versionin mĂ« tĂ« fundit (nĂ« kuptimin e tyre, mĂ« e fundit do tĂ« thotĂ« mĂ« funksionale). Ne pĂ«rdorim njĂ« qasje tjetĂ«r â shikojmĂ« shĂ«nimet e lĂ«shimit pĂ«r tĂ« gjithĂ«èœŻwaren e pĂ«rdorur pajisjet dhe pĂ«rzgjedhim me kujdes firmware-in e duhur pĂ«r çdo njĂ«si pajisjeje.
Kemi arritur në këtë përfundim përmes përvojës. Do t'ju tregojmë përvojën tonë përse 99,9999% e besueshmërisë së sistemit të ruajtjes nuk do të thotë asgjë nëse nuk e ndjekni rregullisht përmirësimin dhe përshkrimin e softuerit. Rasti ynë do t'i përgjigjet përdoruesve të sistemeve të ruajtjes nga çdo prodhues, sepse një situatë e tillë mund të ndodhë me pajisje nga çdo prodhues.
Zgjedhja e një sistemi të ri ruajtjeje të të dhënave
NĂ« fund tĂ« vitit tĂ« kaluar, infrastruktura ynĂ« u pasurua me njĂ« sistem interesant ruajtjeje tĂ« tĂ« dhĂ«nave: modeli mĂ« i vogĂ«l nga linja IBM FlashSystem 5000, i cili nĂ« momentin e blerjes quhej Storwize V5010e. Tani shitet nĂ«n emrin FlashSystem 5010, por nĂ« tĂ« vĂ«rtetĂ« kjo Ă«shtĂ« e njĂ«jta bazĂ« harduerike me tĂ« njĂ«jtĂ«n Spectrum Virtualize brenda.Â
Prania e njĂ« sistemi tĂ« vetĂ«m menaxhimi â kjo Ă«shtĂ« pĂ«r ndryshe dallimi kryesor i IBM FlashSystem. Modelet e serisĂ« mĂ« tĂ« vogĂ«l praktikisht nuk duken ndryshe nga modelet mĂ« tĂ« performancĂ«s. Zgjedhja e njĂ« modeli tĂ« caktuar thjesht jep bazĂ«n pĂ«rkatĂ«se harduerike, karakteristikat e tĂ« cilĂ«s ofrojnĂ« mundĂ«sinĂ« pĂ«r pĂ«rdorimin e funksionaliteteve tĂ« ndryshme ose pĂ«r tĂ« siguruar njĂ« nivel tĂ« lartĂ« tĂ« shkallĂ«zueshmĂ«risĂ«. Softueri nĂ« kĂ«tĂ« rast identifikon harduerin dhe ofron funksionalitetin e nevojshĂ«m dhe tĂ« mjaftueshĂ«m pĂ«r kĂ«tĂ« platformĂ«.
IBM FlashSystem 5010
Në përmbledhje për modelin tonë 5010. Ky është një sistem ruajtjeje të dhënash dy kontrollorësh në nivel fillestar. Ai mund të vendosë disqe NLSAS, SAS, SSD. Vendosja e NVMe në të nuk është e mundur, pasi ky model sistemi ruajtjeje është pozicionuar për zgjidhjen e detyrave që nuk kërkojnë performancë nga disqet NVMe.
Sistemi i ruajtjes u ble për të mbajtur informacionin arkiv dhe të dhënat që nuk shihen shpesh. Prandaj, na mjaftonte grupi standard i funksionalitetit të saj: tiering (Easy Tier), Thin Provision. Performanca mbi disqet NLSAS në nivelin 1000-2000 IOPS ishte gjithashtu e pranueshme për ne.
PĂ«rvoja jonĂ« â si nuk e pĂ«rmirĂ«suam firmware-in nĂ« kohĂ«
Tani të kalojmë në përmirësimin e softuerit. Në momentin e blerjes, sistemi kishte një version të pakët të vjetër të softuerit Spectrum Virtualize, konkretisht, 8.2.1.3.
Kemi shqyrtuar pĂ«rshkrimin e firmware dhe kemi planifikuar pĂ«rmirĂ«simin nĂ« 8.2.1.9. Sikur tĂ« ishim pak mĂ« tĂ« shpejtĂ«, kjo artikull nuk do tĂ« ishte ekzistues â nĂ« firmware mĂ« tĂ« freskĂ«t nuk do tĂ« kishte ndodhur ky problem. MegjithatĂ«, pĂ«r disa arsye, pĂ«rmirĂ«simi i kĂ«saj sistemi u vonua.
Si rezultat, njĂ« vonesĂ« e vogĂ«l nĂ« pĂ«rmirĂ«sim çoi nĂ« njĂ« situatĂ« shumĂ« tĂ« pakĂ«ndshme, siç Ă«shtĂ« pĂ«rshkruar nĂ« lidhjen: .Â
Po, në firmware-in e asaj versioni përkatës ishte aktuale raporti i njohur si APAR (Authorized Program Analysis Report) HU02104. Ai shfaqet në këtë mënyrë. Nën ngarkesë, në rrethana të caktuara, fillon të mbushet cache, dhe më pas sistemi kalon në modin mbrojtës, në të cilin çon në ndikim të hyrjeve/daljeve për grupin (Pool). Në rastin tonë, vërehej si shtypja e 3 disqeve për grupin RAID në modin RAID 6. Ndërprerja ndodhte për 6 minuta. Më pas, qasja në vëllimet e Pool-it rikthehej.
Nëse dikush nuk është i njohur me strukturën dhe emërtimin e entiteteve logjike në kontekstin e IBM Spectrum Virtualize, tani do të shpjegoj shkurtimisht.
Struktura e elementeve logjike të sistemit të ruajtjes
Disqet grumbullohen në grupe, të cilat quhen MDisk (Disk të Menaxhuar). MDisk mund të përfaqësojë RAID klasik (0,1,10,5,6) ose të virtualizuar - DRAID (RAID i Distribuar). Përdorimi i DRAID lejon rritjen e performancës së grupit, pasi do të përdoren të gjithë disqet e grupit dhe do të zvogëlohet koha e rikonstruksionit, falë faktit se do të duhet të rikuperohen vetëm blloqet e caktuara, jo të gjitha të dhënat nga disku që ka dalë jashtë funksionit.
Shpërndarja e blloqeve të të dhënave në disqe kur përdoret Distributed RAID (DRAID) në mënyrën RAID-5.
Dhe ky skemë tregon logjikën e punës së rikonstruksionit DRAID në rast se një disk dështoi:
Logjika e punës së rikonstruksionit DRAID kur një disk dështoi
Pastaj, një ose më shumë MDisk formojnë atë që quhet Pool. Brenda një pool nuk rekomandohet të përdoren MDisk me nivele të ndryshme RAID/DRAID në disqe të një lloji. Nuk do të thellohemi shumë në këtë, pasi planifikojmë të flasim për të në një nga artikujt e ardhshëm. Në të vërtetë, Pool ndahet në Toma (Volumes), të cilat prezantohen përmes një protokolli të caktuar të aksesit në bllok në drejtim të hosteve.
Pra, na ndodhi që në situatën e përshkruar në APAR HU02104, për shkak të një dështimi logjik të tre disqeve, një MDisk të cilin ndryshe e dështoi, duke çuar kështu në dështimin e Pool dhe Tomave përkatës.
TĂ« gjitha kĂ«to sisteme janĂ« mjaft "tĂ« mençura", mund tĂ« lidhen me sistemin cloud tĂ« monitorimit IBM Storage Insights, i cili automatikisht, nĂ« rast tĂ« njĂ« dĂ«shtimi, dĂ«rgon njĂ« kĂ«rkesĂ« pĂ«r suport nĂ« shĂ«rbimin e mbĂ«shtetjes IBM. Krijohet njĂ« kĂ«rkesĂ« dhe specialistĂ«t e IBM zhvillojnĂ« diagnostikimin nĂ« distancĂ« dhe kontaktojnĂ« pĂ«rdoruesin e sistemit.Â
Falë kësaj, problemi u zgjidh mjaft shpejt dhe nga shërbimi i mbështetjes u mor një rekomandim të shpejtë për të rinovuar sistemin tonë në versionin e zgjedhur më herët 8.2.1.9, në të cilin atëherë ky problem ishte tashmë zgjidhur. Kjo konfirmon .
PĂ«rmbledhje dhe rekomandimet tona
Si thonĂ«: "e mira Ă«shtĂ« ajo qĂ« pĂ«rfundon mirĂ«". Gabimi nĂ« firmware nuk u shndĂ«rrua nĂ« probleme serioze - funksionimi i serverĂ«ve u rikuperua nĂ« kohĂ« tĂ« shkurtĂ«r dhe pa humbje tĂ« dhĂ«nash. Disa klientĂ« kishin nevojĂ« tĂ« rinisnin makinat virtuale, por nĂ« pĂ«rgjithĂ«si ishim tĂ« pĂ«rgatitur pĂ«r pasojat mĂ« negative, pasi pĂ«r çdo ditĂ« bĂ«jmĂ« kopje rezervĂ« tĂ« tĂ« gjitha elementeve tĂ« infrastrukturĂ«s dhe makinave tĂ« klientĂ«ve.Â
Kemi marrë konfirmim se edhe sistemet e besueshme me 99,9999% disponibilitet të premtuar kërkojnë kujdes dhe mbështetje në kohë. Në bazë të situatës ne kemi bërë disa përfundime dhe po ndajmë rekomandimet tona:
Nuk duhet të harrohet të ndiqni daljen e përditësimeve, të studioni Shënimet e Lëshimit për zgjidhjen e përmbledhjeve kritikale dhe të realizoni në kohë përditësimet e planifikuara.
Ky është një moment organizativ dhe madje edhe mjaft i dukshëm, për të cilin duket se nuk duhet të fokusohemi shumë. Megjithatë, në këtë "vend të nivelit" mund të pengoheni lehtë. Në të vërtetë, ky ishte momenti që solli shqetësimet e përshkruara më lart. Merrni parasysh përgatitjen e rregullave të përditësimeve me kujdes të madh dhe ndiqni me të njëjtin kujdes përmbushjen e tyre. Ky pikë lidhet me konceptin e "disciplines".
GjithmonĂ« Ă«shtĂ« mĂ« mirĂ« tĂ« mbani sistemin me versionin mĂ« tĂ« ri tĂ« softuerit. Dhe, nĂ« kĂ«tĂ« rast, i fundit nuk Ă«shtĂ« ai qĂ« ka njĂ« numĂ«r mĂ« tĂ« madh, por ai me datĂ«n mĂ« tĂ« re tĂ« daljes.Â
Për shembull, IBM për sistemet e saj të ruajtjes së të dhënave mban në gjendje aktuale të paktën dy lëshime softueri. Në momentin kur po shkruhej ky artikull - këto janë 8.2 dhe 8.3. Përditësimet për 8.2 dalin më herët. Pas tyre, me një vonesë të vogël zakonisht dalin përditësime të ngjashme për 8.3.
Lëshimi 8.3 ka disa përparësi funksionale, për shembull, mundësinë e zgjerimit të MDisk (në mënyrën DRAID) duke shtuar një ose më shumë disqe të rinj (kjo mundësi u shfaq që nga versioni 8.3.1). Ky është një funksionalitet mjaft bazik, por në 8.2, fatkeqësisht, nuk ka një mundësi të tillë.
Nëse për ndonjë arsye nuk keni mundësi të përditësoni, atij për versionet e softuerit Spectrum Virtualize, që përpara versioneve 8.2.1.9 dhe 8.3.1.0 (ku gabimi i përshkruar mbi është i aktualizuar), për të zvogëluar rrezikun e shfaqjes së tij, mbështetje teknike IBM rekomandon kufizimin e performancës së sistemit në nivelin e pool, ashtu siç është paraqitur në imazhin më poshtë (skanimi është marrë në versionin e gjuhës ruse të GUI). Vlera 10000 IOPS tregohet për shembuj dhe përcaktohet sipas karakteristikave të sistemit tuaj.
Kufizimi i performancës së SCD IBM
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« llogaritet saktĂ« ngarkesa nĂ« sistemet e ruajtjes dhe tĂ« mos lejohet mbingarkesa. PĂ«r kĂ«tĂ«, mund tĂ« pĂ«rdorni ose mjetin IBM (nĂ«se keni akses) ose ndihmĂ«n e partnerĂ«ve, ose burime tĂ« jashtme. ĂshtĂ« thelbĂ«sore tĂ« kuptoni profilin e ngarkesĂ«s nĂ« sistemin e ruajtjes, pasi performanca nĂ« MB/s dhe IOPS ndryshon ndjeshĂ«m nĂ« varĂ«si tĂ« tĂ« paktĂ«n parametrave tĂ« mĂ«poshtĂ«m:
Tipi i operacionit: lexim apo shkruar,
Shuma e bllokut të operacionit,
Raporti përqindor i operacioneve të leximit dhe shkruar në tërësinë e fluksit të hyrjes dhe daljes.
Gjithashtu, shpejtësia e realizimit të operacioneve ndikohet nga mënyra se si lexohen blloqet e të dhënave: në mënyrë të renditur apo rastësisht. Kur kryhen disa operacione qasje në të dhëna nga ana e aplikacionit, ekziston koncepti i operacioneve të varura. Kjo gjithashtu është e këshillueshme të merret parasysh. E gjithë kjo mund të ndihmojë në shikimin e të dhënave të mbledhura nga numëruesit e performancës së OS, sistemin e ruajtjes, serverët/hypervisors, si dhe kuptimin e veçorive të funksionimit të aplikacioneve, DBMS dhe konsumatorëve të tjerë të burimeve të diskut.
Dhe përfundimisht, është e domosdoshme të keni kopje rezervë që janë në gjendje dhe funksionale. Orari i kopjimit të rezervave duhet të konfigurohet duke u bazuar në vlerat e pranueshme të RPO për biznesin dhe të kontrollohet rregullisht integriteti i kopjeve rezervë (mjaft prodhues software për kopje rezervë e kanë implementuar këtë verifikim automatizuar në produktet e tyre) për të siguruar një vlerë të pranueshme të RTO.
Faleminderit që lexuat deri në fund.
Jemi të gatshëm t'ju përgjigjemi pyetjeve dhe vërejtjeve tuaja në komentet. Përveç kësaj,, ku organizojmë akcione të rregullta (zbritje në IaaS dhe shpërblime të kodëve promocional deri në 100% për VPS), shkruajmë lajme interesante dhe njoftojmë artikuj të rinj në blogun Habr.
Burimi: habr.com
