Hvilken firmwareversion er den mest "korrekte" og "fungerende"? Hvis et lagersystem garanterer en fejltolerance på 99,9999 %, betyder det så, at det vil fungere uafbrudt selv uden en softwareopdatering? Eller tværtimod, for at opnå maksimal fejltolerance, bør du altid installere den nyeste firmware? Vi vil forsøge at besvare disse spørgsmål baseret på vores erfaring.
Lille introduktion
Vi forstår alle, at hver version af software, hvad enten det er et operativsystem eller en driver til en enhed, ofte indeholder defekter/fejl og andre "funktioner", som måske ikke "vises" før slutningen af udstyrets levetid, eller "åbne" kun under visse betingelser. Antallet og betydningen af sådanne nuancer afhænger af softwarens kompleksitet (funktionalitet) og kvaliteten af test under udviklingen.
Ofte forbliver brugere på "firmwaren fra fabrikken" (det berømte "det virker, så lad være med at rode med det") eller installerer altid den nyeste version (efter deres forståelse betyder den seneste den mest fungerende). Vi bruger en anden tilgang - vi ser på udgivelsesnoterne for alt brugt udstyr, og vælg omhyggeligt den passende firmware til hvert udstyr.
Vi kom til denne konklusion, som de siger, med erfaring. Ved at bruge vores eksempel på drift vil vi fortælle dig, hvorfor den lovede 99,9999% pålidelighed af lagersystemer ikke betyder noget, hvis du ikke omgående overvåger softwareopdateringer og beskrivelser. Vores etui er velegnet til brugere af lagersystemer fra enhver leverandør, da en lignende situation kan ske med hardware fra enhver producent.
Valg af nyt lagersystem
I slutningen af sidste år blev der tilføjet et interessant datalagringssystem til vores infrastruktur: en juniormodel fra IBM FlashSystem 5000-linjen, som på købstidspunktet hed Storwize V5010e. Nu sælges det under navnet FlashSystem 5010, men faktisk er det den samme hardwarebase med samme Spectrum Virtualize indeni.
Tilstedeværelsen af et samlet ledelsessystem er i øvrigt hovedforskellen mellem IBM FlashSystem. For modeller af den yngre serie er det praktisk talt ikke anderledes end modeller af mere produktive. At vælge en specifik model giver kun den passende hardwarebase, hvis egenskaber gør det muligt at bruge en eller anden funktionalitet eller give et højere niveau af skalerbarhed. Softwaren identificerer hardwaren og giver den nødvendige og tilstrækkelige funktionalitet til denne platform.
IBM FlashSystem 5010
Kort om vores model 5010. Dette er et entry-level dual-controller bloklagringssystem. Den kan rumme NLSAS, SAS, SSD-diske. NVMe-placering er ikke tilgængelig i den, da denne lagermodel er placeret til at løse problemer, der ikke kræver ydeevnen af NVMe-drev.
Lagersystemet blev købt for at rumme arkivoplysninger eller data, der ikke tilgås ofte. Derfor var standardsættet af dets funktionalitet nok for os: Tiering (Easy Tier), Thin Provision. Ydeevne på NLSAS-diske på niveauet 1000-2000 IOPS var også ganske tilfredsstillende for os.
Vores erfaring - hvordan vi ikke opdaterede firmwaren til tiden
Nu om selve softwareopdateringen. På købstidspunktet havde systemet allerede en lidt forældet version af Spectrum Virtualize-softwaren, nemlig, 8.2.1.3.
Vi studerede firmwarebeskrivelserne og planlagde en opdatering til 8.2.1.9. Hvis vi havde været lidt mere effektive, ville denne artikel ikke have eksisteret – fejlen ville ikke være opstået på en nyere firmware. Af visse grunde blev opdateringen af dette system dog udskudt.
Som et resultat førte en lille opdateringsforsinkelse til et ekstremt ubehageligt billede, som i beskrivelsen på linket: .
Ja, i firmwaren til den version var den såkaldte APAR (Authorized Program Analysis Report) HU02104 relevant. Det fremstår som følger. Under belastning begynder cachen under visse omstændigheder at flyde over, hvorefter systemet går i beskyttende tilstand, hvor det deaktiverer I/O for poolen. I vores tilfælde lignede det at afbryde 3 diske til en RAID-gruppe i RAID 6-tilstand. Afbrydelsen sker i 6 minutter. Derefter gendannes adgangen til Volumes in the Pool.
Hvis nogen ikke er bekendt med strukturen og navngivningen af logiske enheder i forbindelse med IBM Spectrum Virtualize, vil jeg nu kort forklare.
Opbygning af logiske elementer i lagersystemet
Diske er samlet i grupper kaldet MDisk (Managed Disk). MDisk kan være en klassisk RAID (0,1,10,5,6) eller en virtualiseret - DRAID (Distributed RAID). Brug af DRAID giver dig mulighed for at øge ydeevnen af arrayet, fordi... Alle diske i gruppen vil blive brugt, og genopbygningstiden vil blive reduceret, på grund af det faktum, at kun visse blokke skal gendannes, og ikke alle data fra den fejlede disk.
Fordeling af datablokke på tværs af diske ved brug af distribueret RAID (DRAID) i RAID-5-tilstand.
Og dette diagram viser logikken i, hvordan en DRAID-genopbygning fungerer i tilfælde af en diskfejl:
Logik i DRAID-genopbygning, når en disk fejler
Dernæst danner en eller flere MDiske en såkaldt Pool. Inden for den samme pulje anbefales det ikke at bruge MDisk med forskellige RAID/DRAID-niveauer på diske af samme type. Vi vil ikke gå for dybt ind i dette, fordi... vi planlægger at dække dette i en af de følgende artikler. Tja, faktisk er Pool opdelt i Volumes, som præsenteres ved hjælp af en eller anden blokadgangsprotokol til værterne.
Så vi, som følge af situationen beskrevet i APAR HU02104, på grund af den logiske fejl på tre diske, ophørte MDisk med at være funktionel, hvilket igen resulterede i svigt af puljen og de tilsvarende mængder.
Fordi disse systemer er ret smarte, kan de forbindes til IBM Storage Insights cloud-baserede overvågningssystem, som automatisk sender en serviceanmodning til IBM support, hvis der opstår et problem. Der oprettes en applikation, og IBM-specialister udfører fjerndiagnosticering og kontakter systembrugeren.
Takket være dette blev problemet løst ret hurtigt, og der blev modtaget en hurtig anbefaling fra supporttjenesten om at opdatere vores system til den tidligere valgte firmware 8.2.1.9, som på det tidspunkt allerede var blevet rettet. Det bekræfter .
Resultater og vores anbefalinger
Som man siger: "alt er godt, der ender godt." Fejlen i firmwaren forårsagede ikke alvorlige problemer - serverne blev gendannet så hurtigt som muligt og uden tab af data. Nogle klienter skulle genstarte virtuelle maskiner, men generelt var vi forberedt på flere negative konsekvenser, da vi dagligt tager backup af alle infrastrukturelementer og klientmaskiner.
Vi har modtaget bekræftelse på, at selv pålidelige systemer med 99,9999 % lovet tilgængelighed kræver opmærksomhed og rettidig vedligeholdelse. På baggrund af situationen har vi draget en række konklusioner for os selv og deler vores anbefalinger:
-
Det er bydende nødvendigt at overvåge udgivelsen af opdateringer, studere Release Notes for rettelser af potentielt kritiske problemer og udføre planlagte opdateringer rettidigt.
Dette er et organisatorisk og endda ret indlysende punkt, som det ser ud til, ikke er værd at fokusere på. På denne "plan jord" kan du dog nemt snuble. Faktisk var det dette øjeblik, der tilføjede problemerne beskrevet ovenfor. Vær meget forsigtig, når du udarbejder opdateringsreglerne, og overvåg overholdelsen af dem ikke mindre omhyggeligt. Dette punkt vedrører mere begrebet "disciplin".
-
Det er altid bedre at beholde systemet med den nyeste softwareversion. Desuden er den nuværende ikke den, der har en større numerisk betegnelse, men derimod den med en senere udgivelsesdato.
For eksempel holder IBM mindst to softwareudgivelser opdateret til sine lagersystemer. I skrivende stund er disse 8.2 og 8.3. Opdateringer til 8.2 udkommer tidligere. En lignende opdatering til 8.3 udgives normalt med en lille forsinkelse.
Release 8.3 har en række funktionelle fordele, for eksempel muligheden for at udvide MDisk (i DRAID-tilstand) ved at tilføje en eller flere nye diske (denne funktion er dukket op siden version 8.3.1). Dette er en ret grundlæggende funktionalitet, men i 8.2 er der desværre ikke en sådan funktion.
-
Hvis det af en eller anden grund ikke er muligt at opdatere, anbefaler IBM teknisk support for versioner af Spectrum Virtualize-software før version 8.2.1.9 og 8.3.1.0 (hvor den ovenfor beskrevne fejl er relevant) for at reducere risikoen for dens forekomst. begrænser systemets ydeevne på poolniveau, som vist i figuren nedenfor (billedet er taget i den russificerede version af GUI). Værdien af 10000 IOPS vises som et eksempel og vælges i henhold til dit systems egenskaber.
Begrænsning af IBM-lagerydeevne
-
Det er nødvendigt at beregne belastningen på lagersystemer korrekt og undgå overbelastning. For at gøre dette kan du bruge enten IBM sizer (hvis du har adgang til det), eller hjælp fra partnere eller tredjepartsressourcer. Det er bydende nødvendigt at forstå belastningsprofilen på lagersystemet, fordi Ydeevne i MB/s og IOPS varierer meget afhængigt af mindst følgende parametre:
-
operationstype: læse eller skrive,
-
operationsblokstørrelse,
-
procentdel af læse- og skriveoperationer i den samlede I/O-strøm.
Også hastigheden af operationer påvirkes af, hvordan datablokke læses: sekventielt eller i tilfældig rækkefølge. Når du udfører flere dataadgangsoperationer på applikationssiden, er der konceptet med afhængige operationer. Det er også tilrådeligt at tage højde for dette. Alt dette kan hjælpe med at se helheden af data fra ydeevnetællere for operativsystemet, lagringssystemet, servere/hypervisorer samt en forståelse af driftsfunktionerne i applikationer, DBMS'er og andre "forbrugere" af diskressourcer.
-
-
Og endelig skal du sørge for at have sikkerhedskopier opdateret og fungerende. Sikkerhedskopieringsplanen skal konfigureres baseret på acceptable RPO-værdier for virksomheden, og periodiske integritetstjek af sikkerhedskopierne skal verificeres (en hel del leverandører af backupsoftware har automatiseret verifikation implementeret i deres produkter) for at sikre en acceptabel RTO-værdi.
Tak fordi du læste med til slutningen.
Vi er klar til at besvare dine spørgsmål og kommentarer i kommentarerne. Også, hvor vi afholder regelmæssige kampagner (rabatter på IaaS og giveaways for kampagnekoder op til 100 % på VPS), skriver interessante nyheder og annoncerer nye artikler på Habr-bloggen.
Kilde: www.habr.com