Melyik a "legtökéletesebb" és "működő" firmware verzió? Ha a tárolórendszer 99,9999% megbízhatóságot garantál, akkor ez azt jelenti, hogy működni fog zökkenőmentesen a szoftverfrissítések nélkül is? Vagy ennek ellentéte, hogy a maximális megbízhatóság érdekében mindig a legújabb firmware-t kell telepíteni? Próbáljuk meg ezekre a kérdésekre megválaszolni a tapasztalatainkra támaszkodva.
Rövid bevezetés
Mindannyian tudjuk, hogy a szoftver különböző verzióiban, legyen szó operációs rendszerről vagy egy eszköz meghajtójáról, gyakran vannak hibák és egyéb "különlegességek", amelyek nem "nyilvánulhatnak meg" a berendezés teljes élettartama alatt, vagy csak bizonyos körülmények között "tűnnek fel". Ezeknek a nüanszoknak a száma és jelentősége a szoftver összetettségétől (funkcionalitásától) és a tesztelés minőségétől függ.
Gyakran a felhasználók a “gyári firmware”-en maradnak (a híres „működik, tehát ne nyúlj hozzá”) vagy mindig a legújabb verziót telepítik (számukra a legújabb jelentése a legjobban működő). Mi azonban más megközelítést alkalmazunk - megnézzük a telepítési jegyzeteket minden használt készülékhez. és figyelmesen kiválasztjuk a megfelelő firmware-t minden egyes eszköz számára.
Ez a megállapítás a tapasztalatainkból származik. A saját tapasztalatunk alapján elmondjuk, miért nem jelentenek semmit a garantált 99,9999%-os megbízhatóságú tárolórendszerek, ha nem figyelünk az időben történő frissítésre és a szoftverleírásokra. Esetünk minden tárolórendszer felhasználó számára releváns, mivel hasonló helyzet előfordulhat bármely gyártó hardverével.
Új adatkezelési rendszer kiválasztása
Tavaly év végén egy érdekes adatkezelési rendszer került a infrastruktúránkba: az IBM FlashSystem 5000 sorozat alsó modellje, amely a beszerzés időpontjában Storwize V5010e néven volt ismert. Jelenleg FlashSystem 5010 néven értékesítik, de valójában ez ugyanaz a hardver alap, ugyanazzal a Spectrum Virtualize rendszerrel belül.
A központi kezelőrendszer megléte egyébként az IBM FlashSystem fő megkülönböztető jegye. Az alacsonyabb teljesítményű modellek gyakorlatilag nem különböznek a nagyobb teljesítményűektől. Egy adott modell kiválasztása csupán a megfelelő hardveralap biztosítását jelenti, amelynek jellemzői lehetővé teszik a különböző funkciók használatát vagy egy magasabb szintű skálázhatóság biztosítását. A szoftver e közben azonosítja a hardver részeit, és a platformhoz szükséges és elegendő funkciót biztosít.
IBM FlashSystem 5010
Röviden a 5010 modellünkről. Ez egy két vezérlős, belépő szintű tárolórendszer. Képes NLSAS, SAS és SSD meghajtók elhelyezésére. Az NVMe elhelyezés nem elérhető, mivel ez a modell olyan feladatokhoz kínál megoldásokat, ahol az NVMe meghajtók teljesítménye nem szükséges.
A tárolórendszert archiválási információk vagy olyan adatok tárolására vásárolták, amelyeket nem érintenek gyakran. Ezért a funkciójának standard készlete – például a tiering (Easy Tier) és Thin Provision – elegendő volt számunkra. Az NLSAS meghajtókon a teljesítmény 1000-2000 IOPS szinten szintén kielégítő volt számunkra.
Saját tapasztalatunk — ahogy nem frissítettük időben a firmware-t
Most pedig a szoftverfrissítésről. A vásárláskor a rendszer már egy kicsit elavult verzióval rendelkezett a Spectrum Virtualize-ból, nevezetesen, 8.2.1.3.
Megvizsgáltuk a firmware leírását, és megterveztük a frissítést a következő verzióra 8.2.1.9. Ha egy kicsit ügyesebbek lettünk volna, akkor nem lenne ez a cikk — egy frissebb firmware-rel a hiba nem lépett volna fel. Azonban bizonyos okok miatt a rendszer frissítése elhalasztásra került.
Ennek eredményeként a frissítés kis késlekedése rendkívül kellemetlen helyzetet szült, ahogy azt a linkelt leírás megmutatja: .
Igen, annak a verziónak a firmware-ben éppen aktuális volt a vonatkozó APAR (Authorized Program Analysis Report) HU02104. Ez a következőképpen nyilvánul meg. Megfelelő terhelés mellett bizonyos körülmények között a cache túlcsordul, ezt követően a rendszer védett üzemmódba lép, amely letiltja a be- és kimenetet a Poolhoz. A mi esetünkben ez úgy nézett ki, mint három lemez kikapcsolása a RAID 6 módban lévő RAID-csoporthoz. A kikapcsolás hat percig tart. Ezt követően a hozzáférés a Poolban lévő Volume-okhoz helyreáll.
Ha valaki nem ismeri az IBM Spectrum Virtualize kontextusában a logikai entitások struktúráját és elnevezését, most röviden elmondom.
A logikai elemek struktúrája
A lemezek csoportokba rendeződnek, amelyeket MDisk-nek (Managed Disk) neveznek. Az MDisk lehet klasszikus RAID (0,1,10,5,6) vagy virtualizált – DRAID (Distributed RAID). A DRAID használata növeli a tömb teljesítményét, mivel a csoport összes lemezét használni fogja, és csökkenti a helyreállítási időt, mivel csak bizonyos blokkokat kell helyreállítani, nem az összes adatot a meghibásodott lemezről.
A blokkok adatainak elosztása lemezek között Distributed RAID (DRAID) használata esetén RAID-5 módban.
Ez a séma a DRAID helyreállításának logikáját mutatja be, ha egy lemez meghibásodik:
A DRAID helyreállításának logikája egy lemez meghibásodása esetén
Ezt követően egy vagy több MDisk alkotja a nevezett Pool-t. Egy poolon belül nem ajánlott különböző RAID/DRAID szintű MDisk-eket használni az azonos típusú lemezeken. Ezt nem mélyen fogjuk elemezni, mivel ezt a témát a következő cikkek egyikében részletezzük. A Pool-t valamilyen blokkhozzáférési protokollon keresztül prezentálják a gazdagépek felé.
Nos, a helyzet, amelyről itt szó van, az alábbiak következtében alakult ki: APAR HU02104, három lemez logikai meghibásodása miatt egy MDisk üzemképtelenné vált, amely viszont a Pool és a hozzátartozó Volume-ok működésének leállását okozta.
Mivel ezek a rendszerek meglehetősen "intelligensek", csatlakoztathatók az IBM Storage Insights felhőalapú monitorozó rendszeréhez, amely automatikusan, ha meghibásodás következik be, karbantartási kérelmet küld az IBM ügyfélszolgálatának. Egy bejelentés készül, és az IBM szakemberei távoli módszert alkalmazva diagnosztizálnak és kapcsolatba lépnek a rendszer felhasználójával.
Ennek köszönhetően a kérdést viszonylag gyorsan megoldották, és az ügyfélszolgálattól gyors ajánlást kaptunk a már korábban kiválasztott 8.2.1.9-es firmware frissítésére, amelyben akkor már megoldották ezt a problémát. Ezt megerősíti .
Összefoglalás és ajánlásaink
Ahogy mondják: „jó az, ami jól végződik”. A firmware-ben jelentkező hiba nem váltott ki komoly problémákat — a szerverek működése a lehető leghamarabb helyreállt, és adatok elvesztése nélkül. Néhány ügyfelet újra kellett indítaniuk a virtuális gépeken, de összességében készen álltunk a rosszabb következményekre, mivel naponta készítünk biztonsági másolatokat az infrastruktúra minden eleméről és az ügyfélgépekről.
Megkaptuk a megerősítést, hogy még a megbízható rendszerek is, amelyek 99,9999%-os rendelkezésre állást ígérnek, figyelmet és időben történő karbantartást igényelnek. A helyzet alapján számos következtetést vontunk le, és megosztjuk ajánlásainkat:
Mindig figyelemmel kell kísérni a frissítések megjelenését, tanulmányozni a kiadási jegyzeteket a potenciálisan kritikus hibák javítása érdekében, és időben végezni a tervezett frissítéseket.
Ez egy szervezési, sőt, meglehetősen nyilvánvaló szempont, aminek látszólag nem kellene hangsúlyt fektetni rá. Azonban ezen a «sima» ponton viszonylag könnyű megbotlanunk. Valójában ez a tényező okozta a fent említett problémákat. Nagyon figyelmesen kell kezelni a frissítési szabályzat kidolgozását és legalább ennyire figyelni a betartására. Ez a pont inkább a «fegyelem» fogalmához kapcsolódik.
Mindig jobb, ha a rendszer naprakész szoftververziót használ. Ráadásul a naprakész nem azt jelenti, hogy a legmagasabb számú verzióval rendelkezik, hanem hogy a legújabb megjelenési dátummal.
Például az IBM a tárolórendszereihez legalább két szoftververziót tart naprakészen. Ennek a cikknek az írásakor ez a 8.2 és 8.3. Az 8.2 frissítései előbb jelennek meg. Ezután a 8.3-hoz hasonló frissítés szokott kisebb késéssel érkezni.
A 8.3-as kiadás számos funkcionális előnnyel bír, például az MDisk bővítésének lehetőségével (DRAID módban) egy vagy több új lemez hozzáadásával (ez a funkció a 8.3.1-es verziótól érhető el). Ez egy meglehetősen alapvető funkció, de az 8.2-es verzióban sajnos nincs ilyen lehetőség.
Ha bármilyen okból nem lehet frissíteni, a Spectrum Virtualize szoftver verzióinál, amelyek a 8.2.1.9 és 8.3.1.0 verziók előttiek (ahol a fenti hiba aktuális), az IBM technikai támogatása ajánlja, hogy korlátozzák a rendszer teljesítményét a tárolópultra, ahogy az alábbi ábrán látható (a kép orosz nyelvű GUI változatában készült). A 10000 IOPS érték példaként van feltüntetve, és a rendszer sajátosságai alapján kell beállítani.
IBM tároló teljesítménykorlátozása
Fontos, hogy helyesen számítsuk ki a tárolórendszerek terhelését és elkerüljük a túlterhelést. Ehhez használhatjuk az IBM méretezőt (ha van hozzá hozzáférés), vagy kérhetjük partnereink segítségét, vagy használhatunk harmadik féltől származó forrásokat. Fontos, hogy tisztában legyünk a tárolórendszer terhelési profiljával, mivel a teljesítmény MB/s és IOPS jelentősen eltér a következő paraméterek függvényében:
az operáció típusa: olvasás vagy írás,
az operáció blokk mérete,
az olvasási és írási operációk aránya az összes bemeneti/kimeneti folyamatban.
Ezenkívül az operációk végrehajtási sebességére hatással van, hogy hogyan olvassák a blokkokat: sorozatosan vagy véletlenszerűen. Amikor több adat-hozzáférési operációt hajtunk végre az alkalmazás oldalán, létezik a függő operációk fogalma. Ezt is figyelembe kell venni. Mindez segíthet megérteni az operációs rendszer, a tárolórendszer, a szerverek/hypervisorok teljesítménymérőinek összességét, valamint az alkalmazások, adatbázisok és egyéb
tárolási erőforrások "fogyasztóinak" működésének sajátosságait. Ráadásul mindenképpen szükséges, hogy a biztonsági másolatok naprakészen és működő állapotban legyenek. A biztonsági mentések ütemezését az üzlet számára elfogadható RPO értékek alapján kell beállítani, és időszakosan ellenőrizni kell a biztonsági másolatok épségét (sok biztonsági mentéshez készült szoftver gyártó beépített automatikus ellenőrzést valósított meg termékeiben) a megfelelő RTO érték biztosítása érdekében.
Köszönjük, hogy végigolvasta.
Szívesen válaszolunk kérdéseire és észrevételeire a megjegyzések között. Továbbá, amelyben rendszeresen akciókat tartunk (kedvezmények IaaS-ra és promóciós kódok sorsolása akár 100%-ig VPS-hez), érdekes híreket írunk és új cikkeket jelentetünk meg a Habr blogján.
Forrás: habr.com
