{"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\/da\/blog\/administrirovanie\/pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999","title":{"rendered":"Hvorfor er det vigtigt at teste software p\u00e5 din h\u00f8jtilg\u00e6ngelige SAN (99,9999%)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hvorfor<\/p>\n

Hvilken firmware-version er den mest \"korrekte\" og \"funktionelle\"? Hvis en SAN garanterer en driftssikkerhed p\u00e5 99,9999%, betyder det s\u00e5, at den ogs\u00e5 vil fungere fejlfrit selv uden opdatering af softwaren? Eller er det modsatte g\u00e6ldende \u2014 for at opn\u00e5 maksimal fejlsikkerhed skal man altid installere den nyeste firmware? Vi vil fors\u00f8ge at besvare disse sp\u00f8rgsm\u00e5l baseret p\u00e5 vores erfaring.<\/p>\n

En lille introduktion<\/h3>\n

Vi forst\u00e5r alle, at der i hver version af software, hvad enten det er et operativsystem eller en driver til en enhed, ofte findes mangler\/bugs og andre \"specielle egenskaber\", som kan, som ikke \u2018kommer frem\u2019 f\u00f8r udstyrets levetid er slut, eller kun \u2018bliver afsl\u00f8ret\u2019 under specifikke forhold. Antallet og betydningen af \u200b\u200bs\u00e5danne nuancer afh\u00e6nger af kompleksiteten (funktionaliteten) af softwaren og kvaliteten af \u200b\u200btesten under dens udvikling. <\/p>\n

Ofte forbliver brugerne p\u00e5 \"den fabriksinstallerede firmware\" (det ber\u00f8mte \u2014 \u2018det virker, s\u00e5 lad v\u00e6re med at pille ved det\u2019) eller installerer altid den nyeste version (i deres forst\u00e5else betyder nyeste den mest funktionelle). Vi bruger en anden tilgang \u2014 vi ser p\u00e5 udgivelsesnoterne for det anvendte. i skyen mClouds<\/a><\/noindex> udstyr og v\u00e6lger omhyggeligt den passende firmware til hver enhed. <\/p>\n

Vi er n\u00e5et til denne konklusion gennem erfaring. Vi vil med vores eksempel p\u00e5 anvendelse fort\u00e6lle, hvorfor de lovede 99,9999% p\u00e5lidelighed fra SAN'en ikke betyder noget, hvis du ikke l\u00f8bende holder \u00f8je med opdateringer og beskrivelser af softwaren. Vores case er relevant for brugere af SAN fra enhver leverand\u00f8r, da en s\u00e5dan situation kan opst\u00e5 med hardware fra enhver producent.<\/p>\n

Valg af nyt datalagringssystem<\/h3>\n

I slutningen af sidste \u00e5r tilf\u00f8jede vi et interessant datalagringssystem til vores infrastruktur: den mindre model fra IBM FlashSystem 5000-serien, som ved k\u00f8bet blev kaldt Storwize V5010e. Nu s\u00e6lges den under navnet FlashSystem 5010, men det er faktisk den samme hardware med den samme Spectrum Virtualize indeni. <\/p>\n

Tilstedev\u00e6relsen af et ensartet administrationssystem \u2014 det er faktisk det prim\u00e6re kendetegn ved IBM FlashSystem. For modellerne i den lavere serie adskiller det sig praktisk talt ikke fra de mere potente modeller. Valget af en bestemt model giver kun en tilsvarende hardwareplatform, hvis specifikationer g\u00f8r det muligt at benytte visse funktioner eller sikre et h\u00f8jere niveau af skalerbarhed. Softwaren identificerer desuden hardwarekomponenten og tilbyder den n\u00f8dvendige og tilstr\u00e6kkelige funktionalitet til denne platform. <\/p>\n

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

Kort om vores model 5010. Dette er et to-controller bloklagringssystem i entry-level klassen. Det kan rumme NLSAS, SAS, SSD-diske. NVMe-plads i denne model er ikke tilg\u00e6ngeligt, da denne storage-l\u00f8sning er positioneret til opgaver, der ikke kr\u00e6ver NVMe-diskens ydeevne.<\/p>\n

Storage-l\u00f8sningen blev indk\u00f8bt til opbevaring af arkivinformation eller data, som ikke ofte tilg\u00e5s. Derfor var den standard funktionalitet tilstr\u00e6kkelig for os: tiering (Easy Tier), Thin Provision. Ydeevnen p\u00e5 NLSAS-diskene var p\u00e5 niveauet 1000-2000 IOPS, hvilket ogs\u00e5 var helt acceptabelt for os. <\/p>\n

Vores erfaring - hvordan vi ikke opdaterede firmwaren til tiden<\/h3>\n

Nu til selve softwareopdateringen. P\u00e5 det tidspunkt, hvor vi k\u00f8bte systemet, havde det allerede en lidt for\u00e6ldet version af Spectrum Virtualize-softwaren, nemlig 8.2.1.3.<\/strong><\/p>\n

Vi har unders\u00f8gt beskrivelsen af firmwares og planlagt en opdatering til 8.2.1.9<\/strong>. Hvis vi havde v\u00e6ret lidt mere hurtige, ville denne artikel ikke eksistere - et mere opdateret firmware ville have forhindret fejlen. Men af bestemte \u00e5rsager blev opdateringen af dette system udsat.<\/p>\n

Som resultat f\u00f8rte en lille forsinkelse i opdateringen til et ekstremt ubehageligt scenarie, som beskrevet i linket: https:\/\/www.ibm.com\/support\/pages\/node\/6172341<\/u><\/a><\/noindex>. <\/p>\n

Ja, i firmwaren til den version var der netop aktuelt den s\u00e5kaldte APAR (Authorized Program Analysis Report) HU02104. Den viser sig p\u00e5 f\u00f8lgende m\u00e5de. Under belastning, under visse omst\u00e6ndigheder, begynder cachen at overfyldes, hvorefter systemet g\u00e5r i beskyttelsestilstand, hvor det deaktiverer ind- og udf\u00f8rsel for puljen (Pool). I vores tilf\u00e6lde s\u00e5 det ud som deaktivering af 3 diskene til RAID-gruppen i RAID 6-mode. Deaktiveringen varer i 6 minutter. Herefter genoptages adgangen til volumerne i puljen.<\/p>\n

Hvis nogen ikke er bekendt med strukturen og navngivningen af logiske enheder i konteksten af IBM Spectrum Virtualize, vil jeg kort fort\u00e6lle om det nu.<\/p>\n

\"HvorforStrukturen af logiske elementer i SAN<\/p>\n

Diskene samles i grupper, der kaldes MDisk (Managed Disk). MDisk kan v\u00e6re klassisk RAID (0,1,10,5,6) eller virtualiseret \u2013 DRAID (Distributed RAID). Anvendelse af DRAID g\u00f8r det muligt at \u00f8ge ydeevnen af arrayet, da alle diske i gruppen vil blive anvendt, og reducere tiden for rebuiling, fordi der kun skal gendannes bestemte blokke i stedet for alle data fra den defekte disk.<\/p>\n

\"HvorforDistribution af data blokke p\u00e5 diske ved brug af Distributed RAID (DRAID) i RAID-5 mode.<\/p>\n

Og denne diagram viser logikken for DRAID rebuilding, hvis en disk fejler:<\/p>\n

\"HvorforLogik for DRAID rebuilding ved fejlen af en disk<\/p>\n

Dern\u00e6st danner en eller flere MDisk det, der kaldes en Pool. Inden for en enkelt pool anbefales det ikke at bruge MDisk med forskellige RAID\/DRAID-niveauer p\u00e5 diske af samme type. Vi vil ikke g\u00e5 for meget ind i det, da vi planl\u00e6gger at uddybe det i en af de kommende artikler. Og faktisk deles Pool i Volumes, som pr\u00e6senteres via en eller anden blokadekseringsprotokol til v\u00e6rter.<\/p>\n

S\u00e5ledes er vi i en situation, der er beskrevet i APAR HU02104<\/em>, p\u00e5 grund af det logiske fejlfald af tre diske, stoppede MDisk med at v\u00e6re funktionel, hvilket f\u00f8rte til et nederlag i Poolens funktionalitet og de tilsvarende Volumes.<\/p>\n

Da disse systemer er ret \"smarte\", kan de tilsluttes det cloud-baserede overv\u00e5gningssystem IBM Storage Insights, som automatisk, ved opst\u00e5en af en fejl, sender en servicemeddelse til IBM support. En ticket oprettes, og IBM-specialister udf\u00f8rer diagnosticering p\u00e5 afstand og kontakter brugeren af systemet. <\/p>\n

Dette gjorde, at problemet blev l\u00f8st relativt hurtigt, og jeg modtog en hurtig anbefaling fra supporten om at opgradere vores system til den firmware 8.2.1.9, vi tidligere havde valgt, hvori dette problem allerede var l\u00f8st. Dette bekr\u00e6fter den relevante Release Note<\/u><\/a><\/noindex>.<\/u><\/p>\n

Konklusioner og vores anbefalinger<\/h3>\n

Som sagt: \"det er godt, hvad der ender godt\". Fejlen i firmware medf\u00f8rte ikke alvorlige problemer \u2013 driften af serverne blev genoprettet hurtigst muligt og uden datatab. For nogle kunder var det n\u00f8dvendigt at genstarte de virtuelle maskiner, men generelt var vi parate til mere negative konsekvenser, da vi dagligt laver backup af alle elementer i infrastrukturen og kundemaskiner. <\/p>\n

Vi har f\u00e5et bekr\u00e6ftet, at selv p\u00e5lidelige systemer med 99,9999% lovet oppetid kr\u00e6ver opm\u00e6rksomhed og rettidig vedligeholdelse. Baseret p\u00e5 situationen har vi draget en r\u00e6kke konklusioner og deler vores anbefalinger:<\/p>\n