{"id":95870,"date":"2020-10-04T13:41:59","date_gmt":"2020-10-04T11:41:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999"},"modified":"2020-10-04T13:41:59","modified_gmt":"2020-10-04T11:41:59","slug":"pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999","title":{"rendered":"Perl 5.32.2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Perl<\/p>\n

Welke firmwareversie is de \"juiste\" en \"functionele\" versie? Als een opslagapparaat een beschikbaarheid van 99,9999% garandeert, betekent dit dan dat het ook onderbroken zal blijven functioneren, zelfs zonder software-updates? Of moet men juist de nieuwste firmware installeren om de maximale beschikbaarheid te bereiken? We zullen proberen deze vragen te beantwoorden op basis van onze ervaring.<\/p>\n

Korte inleiding<\/h3>\n

We begrijpen allemaal dat elke versie van software, of het nu een besturingssysteem of een driver voor een apparaat is, vaak tekortkomingen\/bugs en andere \"kenmerken\" bevat die, net zoals niet \"zich kunnen voordoen\" gedurende de levensduur van de apparatuur, alleen onder bepaalde voorwaarden \"aan het licht kunnen komen\". Het aantal en de betekenis van zulke nuances hangen af van de complexiteit (functionaliteit) van de software en de kwaliteit van de tests tijdens de ontwikkeling. <\/p>\n

Vaak blijven gebruikers op de \"fabrieksfirmware\" (het beroemde - \"werkt, dus niet aan raken\") of installeren ze steeds de laatste versie (in hun begrip betekent de laatste versie dat deze de meest functionele is). Wij hanteren een andere benadering - we bekijken de release-opmerkingen van alle gebruikte software. in de cloud mClouds<\/a><\/noindex> apparatuur en kiezen zorgvuldig de geschikte firmware voor elk stuk apparatuur. <\/p>\n

Tot deze conclusie zijn we gekomen door ervaring. We zullen aan de hand van ons eigen gebruik toelichten waarom de beloofde 99,9999% betrouwbaarheid van de opslagomgeving niets betekent als je niet tijdig let op updates en beschrijvingen van de software. Onze casus is geschikt voor gebruikers van opslagomgevingen van elke leverancier, aangezien een dergelijke situatie zich met hardware van elke fabrikant kan voordoen.<\/p>\n

Kiezen van een nieuw datasysteem<\/h3>\n

Aan het einde van vorig jaar is er een interessant opslagsysteem aan onze infrastructuur toegevoegd: het instapmodel uit de serie IBM FlashSystem 5000, dat op het moment van aankoop de naam Storwize V5010e droeg. Tegenwoordig wordt het verkocht onder de naam FlashSystem 5010, maar feitelijk is het dezelfde hardware met hetzelfde Spectrum Virtualize er binnenin. <\/p>\n

De aanwezigheid van een enkel beheersysteem - dat is overigens het belangrijkste kenmerk van IBM FlashSystem. Bij de modellen uit de instapklasse verschilt het praktisch niet van de modellen met hogere prestaties. De keuze voor een bepaald model biedt alleen de bijbehorende hardwarebasis, waarvan de specificaties het mogelijk maken om bepaalde functionaliteiten te gebruiken of een hoger niveau van schaalbaarheid te waarborgen. De software identificeert ondertussen de hardwarecomponent en biedt de noodzakelijke en voldoende functionaliteit voor dit platform. <\/p>\n

\"PerlIBM FlashSystem 5010<\/p>\n

Kort over ons model 5010. Dit is een tweedelige controller block storage systeem voor de instapklasse. Het kan NLSAS-, SAS-, en SSD-schijven huisvesten. Het plaatsen van NVMe is niet beschikbaar omdat dit model van de SAN is gepositioneerd voor taken die geen NVMe-prestaties vereisen.<\/p>\n

De SAN is aangeschaft voor het opslaan van archiefinformatie of gegevens die niet vaak worden geraadpleegd. Daarom was een standaard set van functionaliteit voldoende voor ons: tiering (Easy Tier), Thin Provision. Ook de prestaties op NLSAS-schijven van 1000-2000 IOPS waren voor ons volledig acceptabel. <\/p>\n

Onze ervaring \u2014 hoe we de firmware niet op tijd hebben bijgewerkt<\/h3>\n

Laten we nu echt praten over de software-update. Op het moment van aankoop had het systeem al een iets verouderde versie van de Spectrum Virtualize-software, namelijk, 8.2.1.3.<\/strong><\/p>\n

We hebben de beschrijvingen van de firmwares bestudeerd en een update naar 8.2.1.9<\/strong>. Als we iets sneller waren geweest, zou dit artikel niet zijn geschreven \u2014 met een recentere firmware zou de bug zich niet hebben voorgedaan. Echter, om bepaalde redenen werd de update van dit systeem uitgesteld.<\/p>\n

Als resultaat leidde een kleine vertraging in de update tot een zeer onaangenaam beeld, zoals beschreven in de link: https:\/\/www.ibm.com\/support\/pages\/node\/6172341<\/u><\/a><\/noindex>. <\/p>\n

Ja, in de firmware van die versie was er inderdaad het zogenaamde APAR (Authorized Program Analysis Report) HU02104. Dit manifesteert zich als volgt: onder belasting begint de cache onder bepaalde omstandigheden vol te lopen, waarna het systeem in een beschermingsmodus gaat, waarin invoer-uitvoer voor de pool (Pool) wordt uitgeschakeld. In ons geval leek dit op het uitschakelen van 3 schijven voor de RAID-groep in RAID 6-modus. De uitschakeling duurt 6 minuten. Daarna wordt de toegang tot de volumes in de pool hersteld.<\/p>\n

Als iemand niet bekend is met de structuur en naamgeving van logische entiteiten in de context van IBM Spectrum Virtualize, zal ik dit nu kort uitleggen.<\/p>\n

\"PerlStructuur van logische elementen van opslag systemen<\/p>\n

Schijven worden in groepen samengebracht, die MDisk (Managed Disk) worden genoemd. MDisk kan een klassieke RAID (0,1,10,5,6) of een gevirtualiseerde versie zijn - DRAID (Distributed RAID). Het gebruik van DRAID verhoogt de prestaties van de array, omdat alle schijven in de groep worden gebruikt, en vermindert de hersteltijd, omdat alleen specifieke blokken hoeven te worden hersteld in plaats van alle gegevens van de defecte schijf.<\/p>\n

\"PerlVerspreiding van datablocks over schijven bij het gebruik van Distributed RAID (DRAID) in RAID-5 modus.<\/p>\n

Dit schema toont de logica van het DRAID-herstel in het geval van een defecte schijf:<\/p>\n

\"PerlLogica van het DRAID-herstel bij het falen van een enkele schijf<\/p>\n

Vervolgens vormen een of meer MDisk wat we een Pool noemen. Binnen een enkele pool is het niet aanbevolen om MDisk met verschillende RAID\/DRAID-niveaus op schijven van hetzelfde type te gebruiken. We zullen hier niet te diep op ingaan, aangezien we van plan zijn dit in een van de volgende artikelen verder uit te leggen. En de Pool wordt verdeeld in Volumes, die worden gepresenteerd via een bepaald bloktoegangsprotocol naar de hosts.<\/p>\n

Dus, in ons geval, als gevolg van de situatie beschreven in APAR HU02104<\/em>, stopte een MDisk, als gevolg van de logische storing van drie schijven, met functioneren, wat op zijn beurt leidde tot het falen van de Pool en de bijbehorende Volumes.<\/p>\n

Aangezien deze systemen behoorlijk 'slim' zijn, kunnen ze worden aangesloten op de cloudgebaseerde monitoringsystemen van IBM Storage Insights, die automatisch, bij het optreden van een defect, een verzoek voor service naar de IBM-ondersteuningsdienst verzendt. Er wordt een ticket aangemaakt en IBM-specialisten voeren op afstand diagnostiek uit en nemen contact op met de gebruiker van het systeem. <\/p>\n

Hierdoor werd het probleem vrij snel opgelost en ontving de ondersteuningsdienst een snelle aanbeveling om ons systeem bij te werken naar de eerder door ons gekozen firmware 8.2.1.9, waarin dit probleem al was opgelost. Dit bevestigt de bijbehorende Release Note<\/u><\/a><\/noindex>.<\/u><\/p>\n

Conclusies en onze aanbevelingen<\/h3>\n

Zoals men zegt: 'het einde is beter dan het begin'. De bug in de firmware leidde niet tot ernstige problemen \u2014 de servers werden in een mum van tijd hersteld zonder dataverlies. Sommige klanten moesten hun virtuele machines opnieuw opstarten, maar over het algemeen waren we voorbereid op ernstigere gevolgen, aangezien we dagelijks back-ups maken van alle infrastructuurelementen en klantmachines. <\/p>\n

We hebben bevestiging gekregen dat zelfs betrouwbare systemen met 99,9999% beloofde beschikbaarheid aandacht en tijdig onderhoud vereisen. Op basis van de situatie hebben we een aantal conclusies getrokken en delen we onze aanbevelingen:<\/p>\n