Hvilken fastvareversjon er den mest "riktige" og "fungerende"? Hvis et lagringssystem garanterer feiltoleranse på 99,9999 %, betyr det at det vil fungere uavbrutt selv uten en programvareoppdatering? Eller tvert imot, for å oppnå maksimal feiltoleranse, bør du alltid installere den nyeste fastvaren? Vi vil prøve å svare på disse spørsmålene basert på vår erfaring.
Liten introduksjon
Vi forstår alle at hver versjon av programvare, det være seg et operativsystem eller en driver for en enhet, ofte inneholder defekter/feil og andre "funksjoner" som kanskje ikke "vises" før slutten av utstyrets levetid, eller "åpne" bare under visse forhold. Antallet og betydningen av slike nyanser avhenger av kompleksiteten (funksjonaliteten) til programvaren og kvaliteten på testingen under utviklingen.
Ofte forblir brukere på "fastvaren fra fabrikken" (den berømte "det fungerer, så ikke rot med det") eller installerer alltid den nyeste versjonen (i deres forståelse betyr den nyeste den mest fungerende). Vi bruker en annen tilnærming – vi ser på utgivelsesnotatene for alt som brukes utstyr og velg nøye riktig firmware for hvert utstyr.
Vi kom til denne konklusjonen, som de sier, med erfaring. Ved å bruke vårt eksempel på drift, vil vi fortelle deg hvorfor den lovede 99,9999% påliteligheten til lagringssystemer ikke betyr noe hvis du ikke umiddelbart overvåker programvareoppdateringer og beskrivelser. Dekselet vårt passer for brukere av lagringssystemer fra enhver leverandør, siden en lignende situasjon kan skje med maskinvare fra enhver produsent.
Velge et nytt lagringssystem
På slutten av fjoråret ble et interessant datalagringssystem lagt til infrastrukturen vår: en juniormodell fra IBM FlashSystem 5000-linjen, som på kjøpstidspunktet het Storwize V5010e. Nå selges det under navnet FlashSystem 5010, men faktisk er det samme maskinvarebase med samme Spectrum Virtualize inni.
Tilstedeværelsen av et enhetlig styringssystem er forresten hovedforskjellen mellom IBM FlashSystem. For modeller av den yngre serien er det praktisk talt ikke forskjellig fra modeller av mer produktive. Å velge en spesifikk modell gir bare den passende maskinvarebasen, hvis egenskaper gjør det mulig å bruke en eller annen funksjonalitet eller gi et høyere nivå av skalerbarhet. Programvaren identifiserer maskinvaren og gir nødvendig og tilstrekkelig funksjonalitet for denne plattformen.
IBM FlashSystem 5010
Kort om vår modell 5010. Dette er et lagringssystem med to kontroller på inngangsnivå. Den kan romme NLSAS, SAS, SSD-disker. NVMe-plassering er ikke tilgjengelig i den, siden denne lagringsmodellen er posisjonert for å løse problemer som ikke krever ytelsen til NVMe-stasjoner.
Lagringssystemet ble kjøpt for å imøtekomme arkivinformasjon eller data som ikke brukes ofte. Derfor var standardsettet med funksjonalitet nok for oss: Tiering (Easy Tier), Thin Provision. Ytelse på NLSAS-disker på nivået 1000-2000 IOPS var også ganske tilfredsstillende for oss.
Vår erfaring - hvordan vi ikke oppdaterte fastvaren i tide
Nå om selve programvareoppdateringen. På kjøpstidspunktet hadde systemet allerede en litt utdatert versjon av Spectrum Virtualize-programvaren, nemlig, 8.2.1.3.
Vi studerte fastvarebeskrivelsene og planla en oppdatering til 8.2.1.9. Hvis vi hadde vært litt mer effektive, ville denne artikkelen ikke eksistert – feilen ville ikke ha oppstått på en nyere fastvare. Av visse grunner ble imidlertid oppdateringen av dette systemet utsatt.
Som et resultat førte en liten oppdateringsforsinkelse til et ekstremt ubehagelig bilde, som i beskrivelsen på lenken: .
Ja, i fastvaren til den versjonen var den såkalte APAR (Authorized Program Analysis Report) HU02104 relevant. Det ser ut som følger. Under belastning, under visse omstendigheter, begynner cachen å renne over, deretter går systemet inn i beskyttende modus, der det deaktiverer I/O for bassenget. I vårt tilfelle så det ut som å koble fra 3 disker for en RAID-gruppe i RAID 6-modus. Frakoblingen skjer i 6 minutter. Deretter gjenopprettes tilgangen til volumene i bassenget.
Hvis noen ikke er kjent med strukturen og navngivningen av logiske enheter i sammenheng med IBM Spectrum Virtualize, vil jeg nå kort forklare.
Struktur av lagringssystem logiske elementer
Disker er samlet inn i grupper kalt MDisk (Managed Disk). MDisk kan være en klassisk RAID (0,1,10,5,6) eller en virtualisert - DRAID (Distribuert RAID). Ved å bruke DRAID kan du øke ytelsen til arrayet, fordi... Alle disker i gruppen vil bli brukt, og gjenoppbyggingstiden vil bli redusert, på grunn av at bare enkelte blokker må gjenopprettes, og ikke alle data fra den mislykkede disken.
Distribusjon av datablokker på tvers av disker ved bruk av distribuert RAID (DRAID) i RAID-5-modus.
Og dette diagrammet viser logikken for hvordan en DRAID-gjenoppbygging fungerer i tilfelle en diskfeil:
Logikken for DRAID-gjenoppbygging når en disk svikter
Deretter danner en eller flere MDisker en såkalt Pool. Innenfor samme basseng anbefales det ikke å bruke MDisk med forskjellige RAID/DRAID-nivåer på disker av samme type. Vi skal ikke gå for dypt inn i dette, fordi... vi planlegger å dekke dette i en av de følgende artiklene. Vel, faktisk er Pool delt inn i volumer, som presenteres ved hjelp av en eller annen blokkadgangsprotokoll til vertene.
Så vi, som et resultat av situasjonen beskrevet i APAR HU02104, på grunn av den logiske feilen til tre disker, sluttet MDisk å være funksjonell, noe som igjen resulterte i feil i bassenget og de tilsvarende volumene.
Fordi disse systemene er ganske smarte, kan de kobles til IBM Storage Insights skybaserte overvåkingssystem, som automatisk sender en tjenesteforespørsel til IBM-støtte hvis det oppstår et problem. En applikasjon opprettes og IBM-spesialister utfører fjerndiagnostikk og kontakter systembrukeren.
Takket være dette ble problemet løst ganske raskt, og det ble mottatt en rask anbefaling fra støttetjenesten om å oppdatere systemet vårt til den tidligere valgte fastvaren 8.2.1.9, som på det tidspunktet allerede var fikset. Det bekrefter .
Resultater og våre anbefalinger
Som ordtaket sier: "alt er bra som ender bra." Feilen i fastvaren forårsaket ikke alvorlige problemer - serverne ble gjenopprettet så snart som mulig og uten tap av data. Noen klienter måtte starte virtuelle maskiner på nytt, men generelt var vi forberedt på mer negative konsekvenser, siden vi tar daglige sikkerhetskopier av alle infrastrukturelementer og klientmaskiner.
Vi har fått bekreftelse på at selv pålitelige systemer med 99,9999 % lovet tilgjengelighet krever oppmerksomhet og rettidig vedlikehold. Basert på situasjonen har vi trukket en rekke konklusjoner for oss selv og deler våre anbefalinger:
-
Det er viktig å overvåke utgivelsen av oppdateringer, studere utgivelsesnotater for rettelser av potensielt kritiske problemer og gjennomføre planlagte oppdateringer i tide.
Dette er et organisatorisk og til og med ganske åpenbart poeng som, det ser ut til, ikke er verdt å fokusere på. På denne "jevne bakken" kan du imidlertid snuble ganske lett. Faktisk var det dette øyeblikket som la til problemene beskrevet ovenfor. Vær svært forsiktig når du utarbeider oppdateringsforskriften og overvåk etterlevelsen av dem ikke mindre nøye. Dette punktet er mer knyttet til begrepet "disiplin".
-
Det er alltid bedre å beholde systemet med den nyeste programvareversjonen. Dessuten er den nåværende ikke den som har en større numerisk betegnelse, men snarere den med en senere utgivelsesdato.
For eksempel holder IBM minst to programvareutgivelser oppdatert for lagringssystemene sine. I skrivende stund er disse 8.2 og 8.3. Oppdateringer for 8.2 kommer ut tidligere. En lignende oppdatering for 8.3 utgis vanligvis med en liten forsinkelse.
Utgivelse 8.3 har en rekke funksjonelle fordeler, for eksempel muligheten til å utvide MDisk (i DRAID-modus) ved å legge til en eller flere nye disker (denne funksjonen har dukket opp siden versjon 8.3.1). Dette er en ganske grunnleggende funksjonalitet, men i 8.2 er det dessverre ingen slik funksjon.
-
Hvis det av en eller annen grunn ikke er mulig å oppdatere, anbefaler IBM teknisk støtte for versjoner av Spectrum Virtualize-programvare før versjoner 8.2.1.9 og 8.3.1.0 (hvor feilen beskrevet ovenfor er relevant), for å redusere risikoen for at det oppstår. begrense systemytelsen på bassengnivå, som vist i figuren nedenfor (bildet ble tatt i den russifiserte versjonen av GUI). Verdien på 10000 IOPS vises som et eksempel og velges i henhold til egenskapene til systemet ditt.
Begrenser IBMs lagringsytelse
-
Det er nødvendig å beregne belastningen på lagringssystemer riktig og unngå overbelastning. For å gjøre dette, kan du enten bruke IBM-størrelsen (hvis du har tilgang til den), eller hjelp fra partnere eller tredjepartsressurser. Det er viktig å forstå lastprofilen på lagringssystemet, fordi Ytelsen i MB/s og IOPS varierer sterkt avhengig av minst følgende parametere:
-
operasjonstype: les eller skriv,
-
operasjonsblokkstørrelse,
-
prosentandel av lese- og skriveoperasjoner i den totale I/O-strømmen.
Også hastigheten på operasjoner påvirkes av hvordan datablokker leses: sekvensielt eller i tilfeldig rekkefølge. Når du utfører flere datatilgangsoperasjoner på applikasjonssiden, er det konseptet med avhengige operasjoner. Det er også lurt å ta hensyn til dette. Alt dette kan bidra til å se helheten av data fra ytelsestellere til operativsystemet, lagringssystemet, servere/hypervisorer, samt en forståelse av driftsfunksjonene til applikasjoner, DBMS-er og andre "forbrukere" av diskressurser.
-
-
Og til slutt, sørg for å ha sikkerhetskopier oppdatert og fungerer. Sikkerhetskopieringsplanen bør konfigureres basert på akseptable RPO-verdier for virksomheten, og periodiske integritetskontroller av sikkerhetskopiene bør verifiseres (ganske mange leverandører av backupprogramvare har automatisert verifisering implementert i produktene sine) for å sikre en akseptabel RTO-verdi.
Takk for at du leste til slutten.
Vi er klare til å svare på dine spørsmål og kommentarer i kommentarene. Også, der vi holder regelmessige kampanjer (rabatter på IaaS og giveaways for kampanjekoder opptil 100 % på VPS), skriver interessante nyheter og annonserer nye artikler på Habr-bloggen.
Kilde: www.habr.com