Welke firmwareversie is het meest “correct” en “werkend”? Als een opslagsysteem een fouttolerantie van 99,9999% garandeert, betekent dit dan dat het ook zonder software-update ononderbroken zal werken? Of moet u, integendeel, om maximale fouttolerantie te verkrijgen altijd de nieuwste firmware installeren? Wij zullen proberen deze vragen te beantwoorden op basis van onze ervaring.
Een kleine introductie
We begrijpen allemaal dat elke softwareversie, of het nu een besturingssysteem of een stuurprogramma voor een apparaat is, vaak defecten/bugs en andere ‘functies’ bevat die mogelijk pas ‘verschijnen’ aan het einde van de levensduur van de apparatuur, of ‘open’ zijn. alleen onder bepaalde voorwaarden. Het aantal en de betekenis van dergelijke nuances zijn afhankelijk van de complexiteit (functionaliteit) van de software en van de kwaliteit van het testen tijdens de ontwikkeling ervan.
Vaak blijven gebruikers op de ‘firmware uit de fabriek’ (het beroemde ‘het werkt, dus rommel er niet mee’) of installeren ze altijd de nieuwste versie (naar hun mening betekent de nieuwste de meest werkende). We gebruiken een andere aanpak: we kijken naar de release-opmerkingen voor alles wat wordt gebruikt apparatuur en selecteer zorgvuldig de juiste firmware voor elk apparaat.
We kwamen tot deze conclusie, zoals ze zeggen, met ervaring. Aan de hand van ons werkingsvoorbeeld zullen we u vertellen waarom de beloofde betrouwbaarheid van 99,9999% van opslagsystemen niets betekent als u software-updates en -beschrijvingen niet onmiddellijk controleert. Onze case is geschikt voor gebruikers van opslagsystemen van elke leverancier, aangezien een soortgelijke situatie zich kan voordoen met hardware van elke fabrikant.
Een nieuw opslagsysteem kiezen
Eind vorig jaar is er een interessant dataopslagsysteem aan onze infrastructuur toegevoegd: een juniormodel uit de IBM FlashSystem 5000-lijn, dat bij aanschaf Storwize V5010e heette. Nu wordt het verkocht onder de naam FlashSystem 5010, maar in feite is het dezelfde hardwarebasis met dezelfde Spectrum Virtualize erin.
De aanwezigheid van een uniform beheersysteem is overigens het belangrijkste verschil tussen IBM FlashSystem. Voor modellen uit de jongere series verschilt dit praktisch niet van modellen uit de productievere series. Het kiezen van een specifiek model biedt alleen de juiste hardwarebasis, waarvan de kenmerken het mogelijk maken om een of andere functionaliteit te gebruiken of een hoger niveau van schaalbaarheid te bieden. De software identificeert de hardware en zorgt voor de noodzakelijke en voldoende functionaliteit voor dit platform.
IBM FlashSysteem 5010
Kort over ons model 5010. Dit is een instapmodel blokopslagsysteem met dubbele controller. Het is geschikt voor NLSAS-, SAS- en SSD-schijven. NVMe-plaatsing is daarin niet beschikbaar, omdat dit opslagmodel is gepositioneerd om problemen op te lossen waarvoor de prestaties van NVMe-schijven niet vereist zijn.
Het opslagsysteem is aangeschaft om archiefinformatie of gegevens op te slaan die niet vaak worden gebruikt. Daarom was de standaardset van de functionaliteit voor ons voldoende: Tiering (Easy Tier), Thin Provision. De prestaties op NLSAS-schijven op het niveau van 1000-2000 IOPS waren voor ons ook behoorlijk bevredigend.
Onze ervaring - hoe we de firmware niet op tijd hebben bijgewerkt
Nu over de software-update zelf. Op het moment van aankoop beschikte het systeem al over een enigszins verouderde versie van de Spectrum Virtualize-software, namelijk: 8.2.1.3.
We hebben de firmwarebeschrijvingen bestudeerd en een update gepland 8.2.1.9. Als we wat efficiënter waren geweest, zou dit artikel niet hebben bestaan - de bug zou niet zijn opgetreden in een recentere firmware. Om bepaalde redenen werd de update van dit systeem echter uitgesteld.
Als gevolg hiervan leidde een kleine updatevertraging tot een uiterst onaangenaam beeld, zoals in de beschrijving op de link: .
Ja, in de firmware van die versie was de zogenaamde APAR (Authorized Program Analysis Report) HU02104 relevant. Het ziet er als volgt uit. Onder belasting begint de cache onder bepaalde omstandigheden over te lopen, waarna het systeem in de beschermende modus gaat, waarin het I/O voor de pool uitschakelt. In ons geval leek het erop dat 3 schijven werden losgekoppeld voor een RAID-groep in de modus RAID 6. De ontkoppeling duurt 6 minuten. Vervolgens wordt de toegang tot de volumes in de pool hersteld.
Als iemand niet bekend is met de structuur en naamgeving van logische entiteiten in de context van IBM Spectrum Virtualize, zal ik het nu kort uitleggen.
Structuur van de logische elementen van het opslagsysteem
Schijven worden verzameld in groepen genaamd MDisk (Managed Disk). MDisk kan een klassieke RAID zijn (0,1,10,5,6) of een gevirtualiseerde - DRAID (Distributed RAID). Door DRAID te gebruiken, kunt u de prestaties van de array verbeteren, omdat... Alle schijven in de groep zullen worden gebruikt en de herbouwtijd zal worden verkort, omdat alleen bepaalde blokken hoeven te worden hersteld en niet alle gegevens van de defecte schijf.
Verdeling van datablokken over schijven bij gebruik van Distributed RAID (DRAID) in RAID-5-modus.
En dit diagram toont de logica van hoe een DRAID-rebuild werkt in het geval van een schijfstoring:
Logica van het opnieuw opbouwen van DRAID wanneer één schijf defect raakt
Vervolgens vormen een of meer MDisks een zogenaamde Pool. Binnen dezelfde pool wordt het niet aanbevolen om MDisk met verschillende RAID/DRAID-niveaus te gebruiken op schijven van hetzelfde type. We zullen hier niet te diep op ingaan, omdat... we zijn van plan dit in een van de volgende artikelen te behandelen. Welnu, in feite is Pool verdeeld in volumes, die worden gepresenteerd met behulp van een of ander bloktoegangsprotocol aan de hosts.
Dus wij, als resultaat van de situatie beschreven in APAR HU02104, vanwege het logische falen van drie schijven, functioneerde MDisk niet meer, wat op zijn beurt resulteerde in het falen van de pool en de bijbehorende volumes.
Omdat deze systemen behoorlijk slim zijn, kunnen ze worden aangesloten op het cloudgebaseerde monitoringsysteem IBM Storage Insights, dat automatisch een serviceverzoek naar IBM-ondersteuning stuurt als er zich een probleem voordoet. Er wordt een applicatie gemaakt en IBM-specialisten voeren op afstand een diagnose uit en nemen contact op met de systeemgebruiker.
Dankzij dit werd het probleem vrij snel opgelost en werd er snel een aanbeveling ontvangen van de ondersteuningsdienst om ons systeem te updaten naar de eerder geselecteerde firmware 8.2.1.9, die op dat moment al was opgelost. Het bevestigt .
Resultaten en onze aanbevelingen
Zoals het gezegde luidt: “Eind goed, al goed.” De bug in de firmware veroorzaakte geen ernstige problemen: de servers werden zo snel mogelijk en zonder gegevensverlies hersteld. Sommige klanten moesten virtuele machines opnieuw opstarten, maar over het algemeen waren we voorbereid op meer negatieve gevolgen, omdat we dagelijks back-ups maken van alle infrastructuurelementen en clientmachines.
We hebben de bevestiging gekregen dat zelfs betrouwbare systemen met een beloofde beschikbaarheid van 99,9999% aandacht en tijdig onderhoud vereisen. Op basis van de situatie hebben wij voor onszelf een aantal conclusies getrokken en onze aanbevelingen gedeeld:
-
Het is absoluut noodzakelijk om de release van updates te monitoren, de Release Notes te bestuderen voor correcties van mogelijk kritieke problemen, en geplande updates tijdig uit te voeren.
Dit is een organisatorisch en zelfs heel voor de hand liggend punt, waarop het lijkt alsof het niet de moeite waard is om op te focussen. Op dit „vlakke terrein” kunt u echter vrij gemakkelijk struikelen. Eigenlijk was het dit moment dat de hierboven beschreven problemen toevoegde. Wees zeer voorzichtig bij het opstellen van de updatevoorschriften en controleer de naleving ervan niet minder zorgvuldig. Dit punt heeft meer betrekking op het concept van “discipline”.
-
Het is altijd beter om het systeem met de nieuwste softwareversie te houden. Bovendien is de huidige niet degene met een grotere numerieke aanduiding, maar eerder degene met een latere releasedatum.
IBM houdt bijvoorbeeld minimaal twee softwarereleases up-to-date voor zijn opslagsystemen. Op het moment van schrijven zijn dit 8.2 en 8.3. Updates voor 8.2 komen eerder uit. Een soortgelijke update voor 8.3 verschijnt doorgaans met een kleine vertraging.
Release 8.3 heeft een aantal functionele voordelen, bijvoorbeeld de mogelijkheid om MDisk uit te breiden (in DRAID-modus) door een of meer nieuwe schijven toe te voegen (deze functie is verschenen sinds versie 8.3.1). Dit is een vrij basisfunctionaliteit, maar in 8.2 bestaat een dergelijke functie helaas niet.
-
Als het om de een of andere reden niet mogelijk is om te updaten, raadt de technische ondersteuning van IBM voor versies van Spectrum Virtualize-software vóór versies 8.2.1.9 en 8.3.1.0 (waar de hierboven beschreven bug relevant is) aan om het risico van optreden ervan te verkleinen waardoor de systeemprestaties op poolniveau worden beperkt, zoals weergegeven in de onderstaande afbeelding (de afbeelding is gemaakt in de Russified-versie van de GUI). De waarde van 10000 IOPS wordt als voorbeeld weergegeven en wordt geselecteerd op basis van de kenmerken van uw systeem.
Beperking van de opslagprestaties van IBM
-
Het is noodzakelijk om de belasting van opslagsystemen correct te berekenen en overbelasting te voorkomen. Om dit te doen, kunt u de IBM-sizer gebruiken (als u er toegang toe heeft), of de hulp van partners of bronnen van derden. Het is absoluut noodzakelijk om het belastingsprofiel van het opslagsysteem te begrijpen, omdat De prestaties in MB/s en IOPS variëren sterk, afhankelijk van ten minste de volgende parameters:
-
type bewerking: lezen of schrijven,
-
grootte van bedieningsblokken,
-
percentage lees- en schrijfbewerkingen in de totale I/O-stroom.
Ook wordt de snelheid van de bewerkingen beïnvloed door de manier waarop datablokken worden gelezen: opeenvolgend of in willekeurige volgorde. Bij het uitvoeren van meerdere gegevenstoegangsbewerkingen aan de applicatiezijde bestaat het concept van afhankelijke bewerkingen. Het is ook raadzaam om hiermee rekening te houden. Dit alles kan helpen om het geheel aan gegevens te zien van prestatietellers van het besturingssysteem, opslagsysteem, servers/hypervisors, evenals inzicht in de operationele kenmerken van applicaties, DBMS'en en andere "consumenten" van schijfbronnen.
-
-
En tot slot: zorg ervoor dat back-ups up-to-date zijn en werken. Het back-upschema moet worden geconfigureerd op basis van acceptabele RPO-waarden voor het bedrijf, en periodieke integriteitscontroles van de back-ups moeten worden geverifieerd (een flink aantal leveranciers van back-upsoftware hebben geautomatiseerde verificatie geïmplementeerd in hun producten) om een acceptabele RTO-waarde te garanderen.
Bedankt voor het lezen tot het einde.
Wij staan klaar om uw vragen en opmerkingen te beantwoorden in de reacties. Ook, waarin we regelmatig promoties houden (kortingen op IaaS en weggeefacties voor promotiecodes tot 100% op VPS), interessant nieuws schrijven en nieuwe artikelen aankondigen op de Habr-blog.
Bron: www.habr.com