Föreställ dig det.

Vilken firmware-version är den mest "rätta" och "arbetsvänliga"? Om lagringssystemet garanterar tillgänglighet på 99,9999 %, betyder det att det också kommer att fungera utan avbrott även utan programuppdateringar? Eller krävs det tvärtom för maximal tillgänglighet att man alltid installerar den senaste firmware-versionen? Vi ska försöka svara på dessa frågor baserat på vår erfarenhet.

En kort introduktion

Vi förstår alla att varje version av programvaran, vare sig det är operativsystem eller drivrutiner för någon enhet, ofta innehåller brister/baggar och andra "särskildheter" som kanske inte "visar sig" förrän utrustningen är slut av sin livslängd, eller "blottas" endast under vissa förhållanden. Antalet och betydelsen av sådana detaljer beror på komplexiteten (funktionaliteten) i programvaran och kvaliteten på testningen under utvecklingen. 

Många användare stannar kvar på "fabriksinställningarna" (det berömda - "fungerar, rör inte") eller installerar alltid den senaste versionen (i deras ögon innebär senast att den är mest funktionell). Vi använder dock en annan strategi - vi kollar på release-noterna för all använd programvara. i molnet mClouds utrustning och väljer noggrant lämplig firmware för varje enhet.

Denna slutsats har vi kommit fram till, så att säga, genom erfarenhet. Genom vår egen användning skall vi berätta varför de utlovade 99,9999 % tillförlitlighet hos lagringssystemet egentligen inte betyder något om du inte ser till att följa upp programuppdateringar och dokumentationen. Vårt fall är tillämpligt för användare av lagringssystem från vilken leverantör som helst, eftersom en liknande situation kan inträffa med hårdvara från vilken tillverkare som helst.

Val av nytt datalagringssystem

I slutet av förra året tillfördes vår infrastruktur ett intressant datalagringssystem: den yngre modellen från IBM FlashSystem 5000-linjen, som vid köpet kallades Storwize V5010e. Nu säljs den under namnet FlashSystem 5010, men det är i praktiken samma hårdvarubas med samma Spectrum Virtualize inuti. 

Att ha ett enhetligt hanteringssystem är för övrigt det huvudsakliga kännetecknet för IBM FlashSystem. För modellerna i den lägre serien är den nästan identisk med de mer kraftfulla modellerna. Valet av en viss modell ger bara en motsvarande hårdvarubas, vars egenskaper möjliggör användningen av vissa funktioner eller erbjuder en högre nivå av skalbarhet. Programvaran identifierar den hårdvarukomponent som används och tillhandahåller den nödvändiga och tillräckliga funktionalitet för plattformen.

IBM FlashSystem 5010

Kort om vår modell 5010. Detta är ett två-kontroller blocklagringssystem på ingångsnivå. Det kan hantera NLSAS, SAS, SSD-diskar. NVMe-installation är inte tillgänglig, eftersom denna modell av lagringssystemet är positionerat för att lösa uppgifter som inte kräver prestanda från NVMe-diskar.

Lagringssystemet införskaffades för att lagra arkivinformation eller data som inte regelbundet åtkoms. Därför var den standardsats av funktionalitet tillräcklig för oss: tiering (Easy Tier), Thin Provision. Prestanda på NLSAS-diskar på nivån 1000-2000 IOPS var också helt acceptabel för oss.

Vår erfarenhet - hur vi inte uppdaterade programvaran i tid

Nu till själva programvaruuppdateringen. Vid tidpunkten för inköpet hade systemet redan en något föråldrad version av programvaran Spectrum Virtualize, nämligen, 8.2.1.3.

Vi studerade beskrivningen av firmware-versionerna och planerade att uppdatera till 8.2.1.9. Om vi hade varit lite mer vaksamma skulle denna artikel inte finnas - med en nyare firmware-version skulle buggen inte ha inträffat. Men av vissa skäl blev uppdateringen av detta system fördröjd.

Resultatet av en liten försening av uppdateringen ledde till en extremt obehaglig situation, som beskrivs i länken: https://www.ibm.com/support/pages/node/6172341. 

Ja, i firmware-versionen var den så kallade APAR (Authorized Program Analysis Report) HU02104 aktuellt. Det yttrar sig på följande sätt. Under belastning, under vissa omständigheter, börjar cachen översvämmas, och systemet går sedan in i skyddsläge, där det stänger av in- och utmatning för poolen. I vårt fall såg det ut som att tre diskar stängdes av för RAID-gruppen i RAID 6-läget. Avstängningen varade i 6 minuter. Därefter återställs åtkomsten till volymerna i poolen.

För dem som inte är bekanta med strukturen och namngivningen av logiska enheter i kontexten av IBM Spectrum Virtualize, kommer jag nu att kortfattat förklara.

Strukturen för logiska enheter i lagringssystem

Diskar samlas i grupper som kallas MDisk (Managed Disk). MDisk kan representera antingen klassisk RAID (0,1,10,5,6) eller virtualiserad – DRAID (Distributed RAID). Användningen av DRAID möjliggör ökad prestanda för arrayen, eftersom alla diskar i gruppen kommer att användas, och det minskar tiden för ombyggnad, eftersom endast vissa block behöver återställas, istället för att återställa alla data från den trasiga disken.

Fördelning av datablokkar på diskar vid användning av Distributed RAID (DRAID) i RAID-5-läget.

Den här schemat visar logiken för ombyggnad av DRAID om en disk går sönder:

Logiken för ombyggnad av DRAID vid fel på en disk

Därefter bildar en eller flera MDisk så kallade Poolar. Inom en pool rekommenderas det inte att använda MDisk med olika nivåer av RAID/DRAID på diskar av samma typ. Vi ska inte gå för djupt in på detta, eftersom vi planerar att berätta mer i en av de kommande artiklarna. Och i själva verket delas Poolar upp i Volymer, som presenteras via en eller annan blockåtkomstprotokoll mot värdar.

Så i vår situation som beskrivs i APAR HU02104, på grund av ett logiskt fel på tre diskar, slutade MDisk att fungera, vilket i sin tur ledde till att Pool och dess Volymer slutade fungera.

Eftersom dessa system är ganska "intelligenta" kan de kopplas till IBM Storage Insights, ett molnbaserat övervakningssystem, som automatiskt skickar en serviceförfrågan till IBM:s support vid fel. En begäran skapas och IBM:s specialister genomför fjärrdiagnostik och kontaktar systemanvändaren. 

Tack vare detta löstes frågan ganska snabbt, och vi fick en omedelbar rekommendation från supporten att uppgradera vårt system till den tidigare valda versionen 8.2.1.9, där denna fråga redan var åtgärdad. Detta bekräftas av den aktuella Release Note.

Sammanfattning och våra rekommendationer

Som man säger: "det som är bra slutar bra". Buggen i programvaran ledde inte till allvarliga problem – servernas drift återställdes snabbt och utan dataförlust. För vissa kunder var det nödvändigt att starta om de virtuella maskinerna, men i stort sett var vi förberedda på mer negativa konsekvenser, eftersom vi dagligen säkerhetskopierar alla delar av infrastrukturen och kundmaskinerna. 

Vi har fått bekräftelse på att även pålitliga system med 99,9999% lovad tillgänglighet kräver uppmärksamhet och regelbundet underhåll. Baserat på situationen har vi dragit några slutsatser och delar med oss av våra rekommendationer:

• Det är absolut nödvändigt att hålla koll på uppdateringar, studera Release Notes för att hitta potentiellt kritiska punkter och genomföra schemalagda uppdateringar i tid.

  Detta är en organisatorisk och faktiskt ganska uppenbar punkt, som man skulle kunna tro inte behöver betonas. Men på detta "lika flata ställe" kan man ganska lätt snubbla. Just denna punkt bidrog faktiskt till de ovan beskrivna problemen. Behandla utarbetandet av uppdateringsregler noggrant och övervaka dess efterlevnad med samma noggrannhet. Denna punkt handlar mer om begreppet "disciplin".

• Det är alltid bättre att hålla systemet uppdaterat med den senaste programversionen. Och med senaste avses inte den som har ett högre siffervärde, utan den som har ett senare release-datum. 

  Till exempel håller IBM för sina datalagringssystem minst två versioner av programvaran aktuella. Vid tidpunkten för skrivandet av denna artikel är det 8.2 och 8.3. Uppdateringar för 8.2 släpps först. Därefter kommer ett liknande uppdatering för 8.3 med en liten fördröjning.

  Release 8.3 har en rad funktionella fördelar, till exempel möjligheten att utöka MDisk (i DRAID-läge) genom att lägga till en eller flera nya diskar (denna funktionalitet tillkom från version 8.3.1). Det är en ganska grundläggande funktion, men tyvärr finns det ingen sådan möjlighet i 8.2.

• Om det av någon anledning inte är möjligt att uppgradera, rekommenderar IBM:s tekniska support att begränsa systemets prestanda i poolen för versioner av mjukvaran Spectrum Virtualize som föregår versionerna 8.2.1.9 och 8.3.1.0 (där den beskrivna buggen är aktuell), för att minska risken för dess uppkomst. Detta visas i bilden nedan (screenshoten är tagen från den ryskspråkiga versionen av GUI). Värdet 10000 IOPS är angivet som exempel och justeras utifrån din systems specifikationer.

Begränsning av IBM:s lagringssystems prestanda

• Det är viktigt att korrekt beräkna belastningen på lagringssystemen och undvika överbelastning. För detta kan man använda antingen IBM:s storleksberäkning (om tillgång finns till den), hjälp från partners eller externa resurser. Det är också viktigt att förstå profileringen av belastningen på lagringssystemet, eftersom prestandan i MB/s och IOPS varierar ganska mycket beroende på minst följande parametrar:

  • typ av operation: läsning eller skrivning,

  • storleken på operationsblocket,

  • förhållandet mellan läs- och skrivoperationer i den totala I/O-strömmen.

  Dessutom påverkas hastigheten för att utföra operationer av hur datablok den läses: sekventiellt eller slumpmässigt. När flera åtkomstoperationer genomförs från applikationens sida finns begreppet beroende operationer. Detta bör också beaktas. Allt detta kan hjälpa till att få en helhetsöversikt av data från operativsystemets, lagringssystemets, servernas/hypervisorernas prestanda räknare, samt förståelsen för hur applikationerna, databashanteringssystemen och andra "diskresurskonsumenter" fungerar.

• Och sist men inte minst, se till att ha aktuella och fungerande säkerhetskopior. Schemat för säkerhetskopiering bör ställas in utifrån acceptabla nivåer av RPO och kontrolleras regelbundet för integritet (många programvarutillverkare för säkerhetskopiering har implementerat automatiserade kontroller i sina produkter) för att säkerställa acceptabla värden av RTO.

Tack för att du läste hela vägen till slut.
Vi är redo att svara på dina frågor och kommentarer i kommentarerna. Dessutom inbjuder vi dig att prenumerera på vår Telegram-kanal., där vi genomför regelbundna kampanjer (rabatter på IaaS och utlottning av rabattkoder upp till 100% på VPS), publicerar intressanta nyheter och annonserar nya artiklar på Habra-bloggen.

Källa: habr.com