Vilken firmwareversion är den mest "korrekta" och "fungerande"? Om ett lagringssystem garanterar feltolerans på 99,9999 %, betyder det att det kommer att fungera utan avbrott även utan en mjukvaruuppdatering? Eller tvärtom, för att få maximal feltolerans bör du alltid installera den senaste firmwaren? Vi kommer att försöka svara på dessa frågor utifrån vår erfarenhet.
En liten introduktion
Vi förstår alla att varje version av programvaran, oavsett om det är ett operativsystem eller en drivrutin för en enhet, ofta innehåller defekter/buggar och andra "funktioner" som kanske inte "visas" förrän i slutet av utrustningens livslängd, eller "öppna" endast under vissa förutsättningar. Antalet och betydelsen av sådana nyanser beror på programvarans komplexitet (funktionalitet) och kvaliteten på testningen under dess utveckling.
Ofta stannar användare på "firmware from the factory" (det berömda "det fungerar, så bråka inte med det") eller installerar alltid den senaste versionen (i deras förståelse betyder den senaste den mest fungerande). Vi använder ett annat tillvägagångssätt - vi tittar på release notes för allt som används utrustning och välj noggrant lämplig firmware för varje utrustning.
Vi kom till denna slutsats, som de säger, med erfarenhet. Med vårt exempel på drift kommer vi att berätta varför den utlovade 99,9999% tillförlitligheten hos lagringssystem inte betyder något om du inte omedelbart övervakar programuppdateringar och beskrivningar. Vårt fodral är lämpligt för användare av lagringssystem från alla leverantörer, eftersom en liknande situation kan inträffa med hårdvara från vilken tillverkare som helst.
Att välja ett nytt lagringssystem
I slutet av förra året lades ett intressant datalagringssystem till vår infrastruktur: en juniormodell från IBM FlashSystem 5000-linjen, som vid köptillfället hette Storwize V5010e. Nu säljs den under namnet FlashSystem 5010, men i själva verket är det samma hårdvarubas med samma Spectrum Virtualize inuti.
Förekomsten av ett enhetligt hanteringssystem är förresten den största skillnaden mellan IBM FlashSystem. För modeller av den yngre serien skiljer det sig praktiskt taget inte från modeller av mer produktiva. Att välja en specifik modell ger bara den lämpliga hårdvarubasen, vars egenskaper gör det möjligt att använda en eller annan funktionalitet eller ge en högre nivå av skalbarhet. Programvaran identifierar hårdvaran och tillhandahåller nödvändig och tillräcklig funktionalitet för denna plattform.
IBM FlashSystem 5010
Kort om vår modell 5010. Detta är ett lagringssystem med dubbla kontroller på ingångsnivå. Den kan rymma NLSAS, SAS, SSD-diskar. NVMe-placering är inte tillgänglig i den, eftersom den här lagringsmodellen är placerad för att lösa problem som inte kräver prestanda hos NVMe-enheter.
Lagringssystemet köptes för att rymma arkivinformation eller data som inte nås ofta. Därför räckte standarduppsättningen av dess funktionalitet för oss: Tiering (Easy Tier), Thin Provision. Prestanda på NLSAS-diskar på nivån 1000-2000 IOPS var också ganska tillfredsställande för oss.
Vår erfarenhet - hur vi inte uppdaterade firmware i tid
Nu om själva mjukvaruuppdateringen. Vid köptillfället hade systemet redan en något föråldrad version av programvaran Spectrum Virtualize, nämligen, 8.2.1.3.
Vi studerade firmwarebeskrivningarna och planerade en uppdatering till 8.2.1.9. Om vi hade varit lite mer effektiva hade den här artikeln inte funnits – buggen skulle inte ha inträffat på en nyare firmware. Men av vissa skäl sköts uppdateringen av detta system upp.
Som ett resultat ledde en liten uppdateringsfördröjning till en extremt obehaglig bild, som i beskrivningen på länken: .
Ja, i den fasta programvaran för den versionen var den så kallade APAR (Authorized Program Analysis Report) HU02104 relevant. Det ser ut som följer. Under belastning, under vissa omständigheter, börjar cachen att svämma över, sedan går systemet in i skyddsläge, där det inaktiverar I/O för poolen. I vårt fall såg det ut som att koppla bort 3 diskar för en RAID-grupp i RAID 6-läge. Frånkopplingen sker i 6 minuter. Därefter återställs åtkomsten till volymerna i poolen.
Om någon inte är bekant med strukturen och namngivningen av logiska enheter i IBM Spectrum Virtualizes sammanhang, ska jag nu kort förklara.
Struktur av lagringssystem logiska element
Diskar samlas in i grupper som kallas MDisk (Managed Disk). MDisk kan vara en klassisk RAID (0,1,10,5,6) eller en virtualiserad - DRAID (Distribuerad RAID). Genom att använda DRAID kan du öka arrayens prestanda, eftersom... Alla diskar i gruppen kommer att användas, och återuppbyggnadstiden kommer att minska, på grund av att endast vissa block kommer att behöva återställas, och inte all data från den trasiga disken.
Distribution av datablock över diskar vid användning av distribuerad RAID (DRAID) i RAID-5-läge.
Och det här diagrammet visar logiken i hur en DRAID-ombyggnad fungerar i händelse av ett diskfel:
Logik för DRAID-återuppbyggnad när en disk misslyckas
Därefter bildar en eller flera MDiskar en så kallad Pool. Inom samma pool rekommenderas inte att använda MDisk med olika RAID/DRAID-nivåer på diskar av samma typ. Vi ska inte gå in på detta för djupt, för... vi planerar att täcka detta i en av följande artiklar. Tja, faktiskt, Pool är uppdelad i volymer, som presenteras med ett eller annat blockåtkomstprotokoll för värdarna.
Så vi, som ett resultat av den situation som beskrivs i APAR HU02104, på grund av det logiska felet på tre diskar, upphörde MDisk att fungera, vilket i sin tur resulterade i fel på poolen och motsvarande volymer.
Eftersom dessa system är ganska smarta kan de kopplas till IBM Storage Insights molnbaserade övervakningssystem, som automatiskt skickar en serviceförfrågan till IBMs support om ett problem uppstår. En applikation skapas och IBM-specialister utför diagnostik på distans och kontaktar systemanvändaren.
Tack vare detta löstes problemet ganska snabbt och en snabb rekommendation mottogs från supporttjänsten att uppdatera vårt system till den tidigare valda firmware 8.2.1.9, som vid den tidpunkten redan hade åtgärdats. Det bekräftar .
Resultat och våra rekommendationer
Som ordspråket säger: "allt är bra som slutar bra." Felet i den fasta programvaran orsakade inga allvarliga problem - servrarna återställdes så snart som möjligt och utan dataförlust. Vissa klienter var tvungna att starta om virtuella maskiner, men i allmänhet var vi beredda på mer negativa konsekvenser, eftersom vi gör dagliga backuper av alla infrastrukturelement och klientmaskiner.
Vi har fått bekräftat att även pålitliga system med 99,9999 % utlovad tillgänglighet kräver uppmärksamhet och underhåll i tid. Baserat på situationen har vi dragit ett antal slutsatser för oss själva och delar våra rekommendationer:
-
Det är absolut nödvändigt att övervaka utgivningen av uppdateringar, studera Release Notes för korrigeringar av potentiellt kritiska problem och genomföra planerade uppdateringar i tid.
Detta är en organisatorisk och till och med ganska självklar punkt, som det verkar inte är värt att fokusera på. Men på denna "plana mark" kan du snubbla ganska lätt. Det var faktiskt detta ögonblick som lade till problemen som beskrivits ovan. Var mycket försiktig när du utarbetar uppdateringsreglerna och övervaka efterlevnaden av dem inte mindre noggrant. Denna punkt relaterar mer till begreppet "disciplin".
-
Det är alltid bättre att behålla systemet med den senaste mjukvaruversionen. Dessutom är den nuvarande inte den som har en större numerisk beteckning, utan snarare den med ett senare releasedatum.
Till exempel håller IBM minst två programvaruversioner uppdaterade för sina lagringssystem. När detta skrivs är dessa 8.2 och 8.3. Uppdateringar för 8.2 kommer ut tidigare. En liknande uppdatering för 8.3 släpps vanligtvis med en liten fördröjning.
Release 8.3 har ett antal 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 funktion har dykt upp sedan version 8.3.1). Detta är en ganska grundläggande funktionalitet, men i 8.2 finns det tyvärr ingen sådan funktion.
-
Om det inte är möjligt att uppdatera av någon anledning, för versioner av Spectrum Virtualize-programvaran före versionerna 8.2.1.9 och 8.3.1.0 (där buggen som beskrivs ovan är relevant), rekommenderar IBM teknisk support för att minska risken för att det inträffar. begränsa systemets prestanda på poolnivå, som visas i figuren nedan (bilden togs i den russifierade versionen av GUI). Värdet på 10000 IOPS visas som ett exempel och väljs i enlighet med egenskaperna hos ditt system.
Begränsar IBMs lagringsprestanda
-
Det är nödvändigt att korrekt beräkna belastningen på lagringssystem och undvika överbelastning. För att göra detta kan du använda antingen IBM sizer (om du har tillgång till den), eller hjälp av partners eller tredjepartsresurser. Det är absolut nödvändigt att förstå belastningsprofilen på lagringssystemet, eftersom Prestanda i MB/s och IOPS varierar mycket beroende på åtminstone följande parametrar:
-
operationstyp: läsa eller skriva,
-
operationsblockstorlek,
-
procentandel läs- och skrivoperationer i den totala I/O-strömmen.
Operationshastigheten påverkas också av hur datablock läses: sekventiellt eller i slumpmässig ordning. När du utför flera dataåtkomstoperationer på applikationssidan finns konceptet med beroende operationer. Det är också lämpligt att ta hänsyn till detta. Allt detta kan hjälpa till att se helheten av data från prestandaräknare för operativsystemet, lagringssystem, servrar/hypervisorer, såväl som en förståelse för funktionsfunktionerna för applikationer, DBMS och andra "konsumenter" av diskresurser.
-
-
Och slutligen, se till att ha säkerhetskopior uppdaterade och fungerande. Säkerhetskopieringsschemat bör konfigureras baserat på acceptabla RPO-värden för verksamheten, och periodiska integritetskontroller av säkerhetskopiorna bör verifieras (en hel del leverantörer av backupprogramvara har automatiserad verifiering implementerad i sina produkter) för att säkerställa ett acceptabelt RTO-värde.
Tack för att du läste till slutet.
Vi är redo att svara på dina frågor och kommentarer i kommentarerna. Också, där vi håller regelbundna kampanjer (rabatter på IaaS och giveaways för kampanjkoder upp till 100 % på VPS), skriver intressanta nyheter och tillkännager nya artiklar på Habr-bloggen.
Källa: will.com