Pse është e rëndësishme të vërtetoni softuerin në hapësirën tuaj ruajtëse me disponueshmëri të lartë (99,9999%)

Cili version i firmuerit është më "i saktë" dhe "funksional"? Nëse një sistem ruajtjeje garanton tolerancën e gabimeve prej 99,9999%, a do të thotë kjo se do të funksionojë pa ndërprerje edhe pa një përditësim softueri? Ose, përkundrazi, për të marrë tolerancën maksimale të gabimeve, duhet të instaloni gjithmonë firmware-in më të fundit? Ne do të përpiqemi t'u përgjigjemi këtyre pyetjeve bazuar në përvojën tonë.

Paraqitje e vogël

Ne të gjithë e kuptojmë se çdo version i softuerit, qoftë ai një sistem operativ apo një drejtues për një pajisje, shpesh përmban defekte/defekte dhe "karakteristika" të tjera që mund të mos "shfaqen" deri në fund të jetës së shërbimit të pajisjes ose "të hapura". vetëm në kushte të caktuara. Numri dhe rëndësia e nuancave të tilla varet nga kompleksiteti (funksionaliteti) i softuerit dhe nga cilësia e testimit gjatë zhvillimit të tij. 

Shpesh, përdoruesit qëndrojnë në "firmware nga fabrika" (e famshmja "funksionon, prandaj mos u ngatërroni me të") ose instalojnë gjithmonë versionin më të fundit (sipas kuptimit të tyre, i fundit do të thotë më i efektshmi). Ne përdorim një qasje të ndryshme - ne shikojmë shënimet e lëshimit për gjithçka që përdoret në renë mClouds pajisje dhe zgjidhni me kujdes firmuerin e duhur për secilën pjesë të pajisjes.

Ne arritëm në këtë përfundim, siç thonë ata, me përvojë. Duke përdorur shembullin tonë të funksionimit, ne do t'ju tregojmë pse besueshmëria e premtuar 99,9999% e sistemeve të ruajtjes nuk do të thotë asgjë nëse nuk monitoroni menjëherë përditësimet dhe përshkrimet e softuerit. Rasti ynë është i përshtatshëm për përdoruesit e sistemeve të ruajtjes nga çdo shitës, pasi një situatë e ngjashme mund të ndodhë me pajisje nga çdo prodhues.

Zgjedhja e një sistemi të ri ruajtjeje

Në fund të vitit të kaluar, një sistem interesant i ruajtjes së të dhënave u shtua në infrastrukturën tonë: një model i ri nga linja IBM FlashSystem 5000, i cili në kohën e blerjes quhej Storwize V5010e. Tani ajo shitet me emrin FlashSystem 5010, por në fakt është e njëjta bazë harduerike me të njëjtin Spectrum Virtualize brenda. 

Prania e një sistemi të unifikuar të menaxhimit është, nga rruga, ndryshimi kryesor midis IBM FlashSystem. Për modelet e serive më të reja, praktikisht nuk ndryshon nga modelet e atyre më produktive. Zgjedhja e një modeli specifik siguron vetëm bazën e duhur harduerike, karakteristikat e së cilës bëjnë të mundur përdorimin e një ose një tjetër funksionaliteti ose ofrimin e një niveli më të lartë të shkallëzimit. Softueri identifikon harduerin dhe ofron funksionalitetin e nevojshëm dhe të mjaftueshëm për këtë platformë.

IBM FlashSystem 5010

Shkurtimisht rreth modelit tonë 5010. Ky është një sistem ruajtjeje blloku me kontrollues të dyfishtë të nivelit fillestar. Mund të strehojë disqe NLSAS, SAS, SSD. Vendosja e NVMe nuk është e disponueshme në të, pasi ky model ruajtjeje është i pozicionuar për të zgjidhur problemet që nuk kërkojnë performancën e disqeve NVMe.

Sistemi i ruajtjes është blerë për të akomoduar informacione arkivore ose të dhëna që nuk aksesohen shpesh. Prandaj, grupi standard i funksionalitetit të tij ishte i mjaftueshëm për ne: Tiering (Easy Tier), Sigurimi i hollë. Performanca në disqet NLSAS në nivelin 1000-2000 IOPS ishte gjithashtu mjaft e kënaqshme për ne.

Përvoja jonë - si nuk e përditësuam firmuerin në kohë

Tani për vetë përditësimin e softuerit. Në kohën e blerjes, sistemi kishte tashmë një version pak të vjetëruar të softuerit Spectrum Virtualize, përkatësisht, 8.2.1.3.

Ne studiuam përshkrimet e firmuerit dhe planifikuam një përditësim të tij 8.2.1.9. Nëse do të kishim qenë pak më efikas, ky artikull nuk do të kishte ekzistuar - gabimi nuk do të kishte ndodhur në një firmware më të fundit. Megjithatë, për disa arsye, përditësimi i këtij sistemi u shty.

Si rezultat, një vonesë e lehtë e përditësimit çoi në një pamje jashtëzakonisht të pakëndshme, si në përshkrimin në lidhjen: https://www.ibm.com/support/pages/node/6172341. 

Po, në firmware-in e atij versioni i ashtuquajturi APAR (Authorized Program Analysis Report) HU02104 ishte i rëndësishëm. Ajo shfaqet si më poshtë. Nën ngarkesë, në rrethana të caktuara, cache fillon të tejmbushet, më pas sistemi kalon në modalitetin mbrojtës, në të cilin çaktivizon hyrjen / daljen për pishinën. Në rastin tonë, dukej si shkëputja e 3 disqeve për një grup RAID në modalitetin RAID 6. Shkëputja ndodh për 6 minuta. Më pas, rikthehet qasja në vëllimet në pishinë.

Nëse dikush nuk është i njohur me strukturën dhe emërtimin e entiteteve logjike në kontekstin e IBM Spectrum Virtualize, tani do ta shpjegoj shkurtimisht.

Struktura e elementeve logjike të sistemit të ruajtjes

Disqet mblidhen në grupe të quajtura MDisk (Managed Disk). MDisk mund të jetë një RAID klasik (0,1,10,5,6) ose i virtualizuar - DRAID (RAID i shpërndarë). Përdorimi i DRAID ju lejon të rritni performancën e grupit, sepse... Të gjithë disqet në grup do të përdoren dhe koha e rindërtimit do të reduktohet, për shkak të faktit se vetëm disa blloqe do të duhet të restaurohen, dhe jo të gjitha të dhënat nga disku i dështuar.

Shpërndarja e blloqeve të të dhënave nëpër disqe kur përdorni RAID të shpërndarë (DRAID) në modalitetin RAID-5.

Dhe ky diagram tregon logjikën se si funksionon një rindërtim DRAID në rast të dështimit të një disku:

Logjika e rindërtimit DRAID kur një disk dështon

Më pas, një ose më shumë MDDiskë formojnë një të ashtuquajtur Pool. Brenda të njëjtit grup, nuk rekomandohet përdorimi i MDisk me nivele të ndryshme RAID/DRAID në disqe të të njëjtit lloj. Ne nuk do të hyjmë në këtë shumë thellë, sepse ... ne planifikojmë ta mbulojmë këtë në një nga artikujt e mëposhtëm. Epo, në fakt, Pool është i ndarë në Vëllime, të cilat paraqiten duke përdorur një ose një tjetër protokoll të hyrjes në bllok te hostet.

Pra, ne, 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 tjetër, rezultoi në dështimin e Pool dhe vëllimeve përkatëse.

Për shkak se këto sisteme janë mjaft të zgjuara, ato mund të lidhen me sistemin e monitorimit të bazuar në renë kompjuterike IBM Storage Insights, i cili dërgon automatikisht një kërkesë shërbimi në mbështetjen e IBM nëse shfaqet një problem. Krijohet një aplikacion dhe specialistët e IBM kryejnë diagnostifikimin në distancë dhe kontaktojnë përdoruesin e sistemit. 

Falë kësaj, çështja u zgjidh mjaft shpejt dhe u mor një rekomandim i menjëhershëm nga shërbimi mbështetës për të përditësuar sistemin tonë në firmware-in e zgjedhur më parë 8.2.1.9, i cili në atë kohë ishte rregulluar tashmë. E konfirmon Shënimi përkatës i lëshimit.

Rezultatet dhe rekomandimet tona

Siç thotë shprehja: "Gjithçka është mirë që përfundon mirë". Defekti në firmware nuk shkaktoi probleme serioze - serverët u rivendosën sa më shpejt të jetë e mundur dhe pa humbje të të dhënave. Disa klientë duhej të rinisnin makinat virtuale, por në përgjithësi ishim të përgatitur për pasoja më negative, pasi bëjmë kopje rezervë të përditshme të të gjithë elementëve të infrastrukturës dhe makinerive të klientëve. 

Ne kemi marrë konfirmimin se edhe sistemet e besueshme me disponueshmëri të premtuar 99,9999% kërkojnë vëmendje dhe mirëmbajtje në kohë. Bazuar në situatën, ne kemi nxjerrë një sërë përfundimesh për veten tonë dhe ndajmë rekomandimet tona:

• Është e domosdoshme të monitorohet lëshimi i përditësimeve, të studiohen Shënimet e Publikimit për korrigjimet e çështjeve potencialisht kritike dhe të kryhen përditësimet e planifikuara në kohën e duhur.

  Kjo është një pikë organizative dhe madje mjaft e dukshme, në të cilën, siç duket, nuk ia vlen të përqendrohemi. Sidoqoftë, në këtë "troje të nivelit" mund të pengoheni mjaft lehtë. Në fakt, ishte ky moment që shtoi telashet e përshkruara më sipër. Jini shumë të kujdesshëm kur hartoni rregulloret e përditësimit dhe monitoroni pajtueshmërinë me to jo më pak me kujdes. Kjo pikë lidhet më shumë me konceptin e "disiplinës".

• Është gjithmonë më mirë ta mbani sistemin me versionin më të fundit të softuerit. Për më tepër, ky aktual nuk është ai që ka një emërtim numerik më të madh, por më tepër ai me një datë të mëvonshme të lëshimit. 

  Për shembull, IBM mban të përditësuar të paktën dy versione të softuerit për sistemet e saj të ruajtjes. Në kohën e këtij shkrimi, këto janë 8.2 dhe 8.3. Përditësimet për 8.2 dalin më herët. Një përditësim i ngjashëm për 8.3 zakonisht lëshohet me një vonesë të vogël.

  Release 8.3 ka një sërë avantazhesh funksionale, për shembull, aftësinë për të zgjeruar MDisk (në modalitetin DRAID) duke shtuar një ose më shumë disqe të rinj (kjo veçori është shfaqur që nga versioni 8.3.1). Ky është një funksionalitet mjaft themelor, por në 8.2, për fat të keq, nuk ka një veçori të tillë.

• Nëse nuk është e mundur të përditësohet për ndonjë arsye, atëherë për versionet e softuerit Spectrum Virtualize përpara versioneve 8.2.1.9 dhe 8.3.1.0 (ku defekti i përshkruar më sipër është i rëndësishëm), për të zvogëluar rrezikun e shfaqjes së tij, rekomandon mbështetja teknike e IBM duke kufizuar performancën e sistemit në nivelin e pishinës, siç tregohet në figurën më poshtë (fotografia është marrë në versionin e Rusifikuar të GUI). Vlera prej 10000 IOPS tregohet si shembull dhe zgjidhet sipas karakteristikave të sistemit tuaj.

Kufizimi i performancës së ruajtjes së IBM

• Është e nevojshme të llogaritet saktë ngarkesa në sistemet e ruajtjes dhe të shmanget mbingarkesa. Për ta bërë këtë, mund të përdorni ose madhësinë e IBM (nëse keni akses në të), ose ndihmën e partnerëve, ose burime të palëve të treta. Është e domosdoshme të kuptohet profili i ngarkesës në sistemin e ruajtjes, sepse Performanca në MB/s dhe IOPS ndryshon shumë në varësi të të paktën parametrave të mëposhtëm:

  • lloji i funksionimit: lexoni ose shkruani,

  • madhësia e bllokut të funksionimit,

  • përqindja e operacioneve të leximit dhe shkrimit në rrjedhën totale të I/O.

  Gjithashtu, shpejtësia e operacioneve ndikohet nga mënyra se si lexohen blloqet e të dhënave: në mënyrë sekuenciale ose në mënyrë të rastësishme. Kur kryeni operacione të shumëfishta të aksesit të të dhënave në anën e aplikacionit, ekziston koncepti i operacioneve të varura. Është gjithashtu e këshillueshme që të merret parasysh kjo. E gjithë kjo mund të ndihmojë për të parë tërësinë e të dhënave nga numëruesit e performancës së OS, sistemit të ruajtjes, serverëve/hipervizorëve, si dhe të kuptuarit e veçorive të funksionimit të aplikacioneve, DBMS-ve dhe "konsumatorëve" të tjerë të burimeve të diskut.

• Dhe së fundi, sigurohuni që të keni kopje rezervë të përditësuar dhe funksionale. Orari i rezervimit duhet të konfigurohet bazuar në vlerat e pranueshme RPO për biznesin dhe kontrollet periodike të integritetit të kopjeve rezervë duhet të verifikohen (mjaft shitës të softuerëve rezervë kanë verifikim të automatizuar të zbatuar në produktet e tyre) për të siguruar një vlerë të pranueshme RTO.

Faleminderit që lexuat deri në fund.
Ne jemi të gatshëm t'u përgjigjemi pyetjeve dhe komenteve tuaja në komente. Gjithashtu Ju ftojmë të abonoheni në kanalin tonë në telegram, në të cilin ne mbajmë promovime të rregullta (zbritje në IaaS dhe dhurata për kode promocionale deri në 100% në VPS), shkruajmë lajme interesante dhe shpallim artikuj të rinj në blogun Habr.

Burimi: www.habr.com