Hvilken version af firmware er den "rigtigste" og "arbejdende"? Hvis SAN'en garanterer en driftsikkerhed på 99,9999%, betyder det så, at den også vil fungere uden afbrydelse, selv uden opdatering af softwaren? Eller omvendt, for at opnå maksimal driftsikkerhed skal man altid installere den nyeste firmware? Lad os forsøge at besvare disse spørgsmål baseret på vores erfaring.
En 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 fejl og andre "karakteristika", som måske ikke "vises" i hele udstyrens levetid, men kun "kan komme frem" under bestemte forhold. Antallet og betydningen af sådanne nuancer afhænger af kompleksiteten (funktionaliteten) af softwaren og kvaliteten af testningen under udviklingen.
Ofte forbliver brugerne på "fabriksfirmwaren" (den berømte – "det virker, så lad være med at pille ved det") eller installerer altid den nyeste version (i deres forståelse betyder den nyeste den mest funktionelle). Vi benytter derimod en anden tilgang – vi ser på udgivelsesnoterne for alt det, vi bruger. udstyr og vælger omhyggeligt den passende firmware til hver enhed.
Vi er nået til denne konklusion gennem erfaring. Vi vil med vores eksempel på anvendelse fortælle, hvorfor de lovede 99,9999% pålidelighed fra SAN'en ikke betyder noget, hvis du ikke løbende holder øje med opdateringer og beskrivelser af softwaren. Vores case er relevant for brugere af SAN fra enhver leverandør, da en sådan situation kan opstå med hardware fra enhver producent.
Valg af nyt datalagringssystem
I slutningen af sidste år tilføjede vi et interessant datalagringssystem til vores infrastruktur: den lavere model fra IBM FlashSystem 5000-serien, som på tidspunktet for købet blev kaldt Storwize V5010e. Nu sælges den under navnet FlashSystem 5010, men det er faktisk den samme hardwareplatform med det samme Spectrum Virtualize indeni.
Eksistensen af et ensartet administrationssystem er faktisk den vigtigste forskel ved IBM FlashSystem. For modellerne i den lavere serie adskiller det sig næsten ikke fra de mere kraftfulde modeller. At vælge en bestemt model giver blot det relevante hardwaregrundlag, hvis specifikationer muliggør brugen af den givne funktionalitet eller sikrer et højere niveau af skalerbarhed. Softwaren identificerer den hardwaredel og leverer den nødvendige og tilstrækkelige funktionalitet til denne platform.
IBM FlashSystem 5010
Kort om vores model 5010. Dette er et to-controller bloklagringssystem i entry-level klassen. Det kan rumme NLSAS, SAS, SSD-diske. NVMe-plads i denne model er ikke tilgængeligt, da denne storage-løsning er positioneret til opgaver, der ikke kræver NVMe-diskens ydeevne.
Storage-løsningen blev indkøbt til opbevaring af arkivinformation eller data, som ikke ofte tilgås. Derfor var den standard funktionalitet tilstrækkelig for os: tiering (Easy Tier), Thin Provision. Ydeevnen på NLSAS-diskene var på niveauet 1000-2000 IOPS, hvilket også var helt acceptabelt for os.
Vores erfaring - hvordan vi ikke opdaterede firmwaren til tiden
Nu til selve softwareopdateringen. På det tidspunkt, hvor vi købte systemet, havde det allerede en lidt forældet version af Spectrum Virtualize-softwaren, nemlig 8.2.1.3.
Vi studerede beskrivelsen af firmware og planlagde opdateringen til 8.2.1.9. Hvis vi havde været lidt mere hurtige, ville denne artikel ikke eksistere - et mere opdateret firmware ville have forhindret fejlen. Men af bestemte årsager blev opdateringen af dette system udsat.
Som resultat førte en lille forsinkelse i opdateringen til et ekstremt ubehageligt scenarie, som beskrevet i linket: .
Ja, i firmwaren til den version var der netop aktuelt den såkaldte APAR (Authorized Program Analysis Report) HU02104. Den viser sig på følgende måde. Under belastning, under visse omstændigheder, begynder cachen at overfyldes, hvorefter systemet går i beskyttelsestilstand, hvor det deaktiverer ind- og udførsel for puljen (Pool). I vores tilfælde så det ud som deaktivering af 3 diskene til RAID-gruppen i RAID 6-mode. Deaktiveringen varer i 6 minutter. Herefter genoptages adgangen til volumerne i puljen.
Hvis nogen ikke er bekendt med strukturen og navngivningen af logiske enheder i konteksten af IBM Spectrum Virtualize, vil jeg kort fortælle om det nu.
Strukturen af logiske elementer i SAN
Diskene samles i grupper, der kaldes MDisk (Managed Disk). MDisk kan være klassisk RAID (0,1,10,5,6) eller virtualiseret – DRAID (Distributed RAID). Anvendelse af DRAID gør det muligt at øge ydeevnen af arrayet, da alle diske i gruppen vil blive anvendt, og reducere tiden for rebuiling, fordi der kun skal gendannes bestemte blokke i stedet for alle data fra den defekte disk.
Distribution af data blokke på diske ved brug af Distributed RAID (DRAID) i RAID-5 mode.
Og denne diagram viser logikken for DRAID rebuilding, hvis en disk fejler:
Logik for DRAID rebuilding ved fejlen af en disk
Dernæst danner en eller flere MDisk det, der kaldes en Pool. Inden for en enkelt pool anbefales det ikke at bruge MDisk med forskellige RAID/DRAID-niveauer på diske af samme type. Vi vil ikke gå for meget ind i det, da vi planlægger at uddybe det i en af de kommende artikler. Og faktisk deles Pool i Volumes, som præsenteres via en eller anden blokadekseringsprotokol til værter.
Således er vi i en situation, der er beskrevet i APAR HU02104, på grund af det logiske fejlfald af tre diske, stoppede MDisk med at være funktionel, hvilket førte til et nederlag i Poolens funktionalitet og de tilsvarende Volumes.
Da disse systemer er ret "smarte", kan de tilsluttes det cloud-baserede overvågningssystem IBM Storage Insights, som automatisk, ved opståen af en fejl, sender en servicemeddelse til IBM support. En ticket oprettes, og IBM-specialister udfører diagnosticering på afstand og kontakter brugeren af systemet.
Dette gjorde, at problemet blev løst relativt hurtigt, og jeg modtog en hurtig anbefaling fra supporten om at opgradere vores system til den firmware 8.2.1.9, vi tidligere havde valgt, hvori dette problem allerede var løst. Dette bekræfter .
Konklusioner og vores anbefalinger
Som man siger: „Det er godt, når det ender godt“. Fejlen i firmwaren resulterede ikke i alvorlige problemer – servernes drift blev genoprettet på kort tid og uden datatab. Nogle kunder måtte genstarte deres virtuelle maskiner, men vi var generelt forberedte på mere negative konsekvenser, da vi dagligt tager backups af alle elementer i infrastrukturen og kundemaskinerne.
Vi har fået bekræftet, at selv pålidelige systemer med 99,9999% lovet oppetid kræver opmærksomhed og rettidig vedligeholdelse. Baseret på situationen har vi draget en række konklusioner og deler vores anbefalinger:
Det er vigtigt at holde øje med, hvornår opdateringer udgives, at studere Release Notes for potentielle kritiske rettelser og rettidigt udføre planlagte opdateringer.
Dette er et organisatorisk og faktisk ret oplagt punkt, som man umiddelbart kunne tro ikke kræver særlig opmærksomhed. Dog kan man faktisk snuble over det på denne „plan“. Dette punkt gav anledning til de beskrevne ubehageligheder. Vær meget omhyggelig, når du udformer opdateringsreglerne, og hold også nøje øje med, at de overholdes. Dette punkt hører mere hjemme under begrebet „disciplin“.
Det er altid bedre at holde systemet med den nyeste version af softwaren. For der er ikke tale om den version, der har det højeste nummer, men netop den, der har den seneste udgivelsesdato.
For eksempel holder IBM sine lagringssystemer opdaterede med mindst to versioner af softwaren. På tidspunktet for skrivningen af denne artikel er det versionerne 8.2 og 8.3. Opdateringer til 8.2 udgives først. Derefter kommer et lignende opdatering til 8.3 med en lille forsinkelse.
Udgivelsen 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 blev tilgængelig fra version 8.3.1). Det er en ret grundlæggende funktion, men desværre er der ikke denne mulighed i 8.2.
Hvis der af en eller anden grund ikke er mulighed for at opgradere, anbefaler IBM's tekniske support at begrænse systemets ydeevne på niveauet for poolen for versioner af Spectrum Virtualize, der er forud for versionerne 8.2.1.9 og 8.3.1.0 (hvor den ovennævnte fejl er relevant) for at reducere risikoen for dens fremkomst, som vist på billedet nedenfor (skærmbillede taget i den danske version af GUI). Værdien 10000 IOPS er angivet som et eksempel og vælges i henhold til din systems specifikationer.
Begrænsning af ydeevne for IBM SAN
Det er nødvendigt at beregne belastningen på lagersystemerne korrekt og undgå overbelastning. Til dette kan du bruge enten IBM's dimensioneringsværktøj (hvis du har adgang til det), eller få hjælp fra partnere eller tredjepartsressourcer. Det er også vigtigt at forstå belastningsprofilen for lagersystemet, da ydeevnen i MB/s og IOPS varierer kraftigt afhængigt af mindst følgende parametre:
operationstype: læsning eller skrivning,
størrelse af operationens blokke,
procentdel af læse- og skriveoperationer i det samlede input/output-flow.
Desuden påvirker den måde, data blokeres på, hastigheden af operationerne: sekventielt eller tilfældigt. Når der udføres flere dataadgangsoperationer fra applikationssiden, findes der begrebet afhængige operationer. Dette bør også tages i betragtning. Alt dette kan hjælpe med at se samlet set data fra ydeevnemetrics fra OS, lagersystemer, servere/hypervisorer, samt en forståelse af, hvordan applikationer, databasesystemer og andre "ressourceforbrugere" fungerer.
Og sidst men ikke mindst, sørg for at have backupkopier i aktuel og funktionsdygtig stand. Planlægningen af backup skal indstilles baseret på acceptable RPO-værdier for virksomheden og kontrol af backup-integritet skal periodisk udføres (mange softwareproducenter til backup har implementeret automatiserede tjek i deres produkter) for at sikre acceptable RTO-værdier.
Vi takker for, at du læste til ende.
Vi er klar til at svare på dine spørgsmål og kommentarer i kommentarerne. Også, hvor vi regelmæssigt afholder kampagner (rabatter på IaaS og lodtrækninger af kampagnekoder op til 100% på VPS), deler interessante nyheder og annoncerer nye artikler på Habr-bloggen.
Kilde: habr.com
