Melyik firmware-verzió a „leghelyesebb” és „működő”? Ha egy tárolórendszer 99,9999%-os hibatűrést garantál, az azt jelenti, hogy szoftverfrissítés nélkül is megszakítás nélkül fog működni? Vagy éppen ellenkezőleg, a maximális hibatűrés érdekében mindig a legújabb firmware-t kell telepítenie? Ezekre a kérdésekre igyekszünk tapasztalataink alapján válaszolni.
Kis bemutatkozás
Mindannyian megértjük, hogy a szoftver minden verziója, legyen az operációs rendszer vagy egy eszköz illesztőprogramja, gyakran tartalmaz olyan hibákat/hibákat és egyéb „funkciókat”, amelyek „meg nem jelennek” a berendezés élettartamának végéig, vagy „megnyílnak”. csak bizonyos feltételek mellett. Az ilyen árnyalatok száma és jelentősége a szoftver összetettségétől (funkcionalitásától), valamint a fejlesztés során végzett tesztelés minőségétől függ.
A felhasználók gyakran maradnak a „gyári firmware”-nél (a híres „működik, úgyhogy ne foglalkozz vele”), vagy mindig a legújabb verziót telepítik (értelemük szerint a legújabb jelenti a legműködőbbet). Más megközelítést alkalmazunk – minden használathoz megnézzük a kiadási megjegyzéseket berendezést, és gondosan válassza ki a megfelelő firmware-t minden egyes berendezéshez.
Erre a következtetésre, ahogy mondani szokás, tapasztalattal jutottunk. Működési példánkkal eláruljuk, hogy a tárolórendszerek ígért 99,9999%-os megbízhatósága miért nem jelent semmit, ha nem figyeli azonnal a szoftverfrissítéseket és leírásokat. Tokunk bármely gyártó tárolórendszerének felhasználói számára alkalmas, hiszen hasonló helyzet bármely gyártó hardverével előfordulhat.
Új tárolórendszer kiválasztása
Tavaly év végén egy érdekes adattároló rendszerrel bővült az infrastruktúránk: egy junior modell az IBM FlashSystem 5000 termékcsaládból, amely a vásárláskor Storwize V5010e néven szerepelt. Jelenleg FlashSystem 5010 néven árulják, de valójában ugyanaz a hardverbázis, benne ugyanaz a Spectrum Virtualize.
Az egységes felügyeleti rendszer jelenléte egyébként a fő különbség az IBM FlashSystem között. A fiatalabb sorozat modelljeinél ez gyakorlatilag nem különbözik a termelékenyebb modellektől. Egy adott modell kiválasztása csak a megfelelő hardverbázist biztosítja, amelynek jellemzői lehetővé teszik egyik vagy másik funkcionalitás használatát, vagy magasabb szintű skálázhatóságot. A szoftver azonosítja a hardvert, és biztosítja a szükséges és elegendő funkcionalitást ehhez a platformhoz.
IBM FlashSystem 5010
Röviden az 5010-es modellünkről. Ez egy belépő szintű, kétvezérlős blokktároló rendszer. NLSAS, SAS, SSD lemezek befogadására alkalmas. NVMe elhelyezés nem érhető el benne, mivel ez a tárolási modell olyan problémák megoldására szolgál, amelyek nem igénylik az NVMe meghajtók teljesítményét.
A tárolórendszert azért vásárolták meg, hogy elférjen az archív információk vagy a nem gyakran elért adatok. Ezért nekünk elég volt a funkcionalitásának standard készlete: Tiering (Easy Tier), Thin Provision. Az 1000-2000 IOPS szintű NLSAS lemezeken a teljesítmény is elég kielégítő volt számunkra.
Tapasztalataink - hogyan nem frissítettük időben a firmware-t
Most magáról a szoftverfrissítésről. A rendszer a vásárláskor már rendelkezett a Spectrum Virtualize szoftver kissé elavult verziójával, nevezetesen 8.2.1.3.
Tanulmányoztuk a firmware-leírásokat, és terveztük a frissítést 8.2.1.9. Ha egy kicsit hatékonyabbak lettünk volna, ez a cikk nem létezett volna – a hiba nem fordult volna elő egy újabb firmware-nél. Bizonyos okok miatt azonban ennek a rendszernek a frissítését elhalasztották.
Ennek eredményeként egy kis frissítési késés rendkívül kellemetlen képet eredményezett, mint a linken található leírásban: .
Igen, ennek a verziónak a firmware-ében az úgynevezett APAR (Authorized Program Analysis Report) HU02104 volt releváns. A következőképpen jelenik meg. Terhelés alatt bizonyos körülmények között a gyorsítótár túlcsordulni kezd, majd a rendszer védelmi módba lép, amelyben letiltja a készlet I/O-ját. A mi esetünkben úgy nézett ki, hogy egy RAID csoporthoz 3 lemezt leválasztunk RAID 6 módban, a leválasztás 6 percig tart. Ezután visszaáll a hozzáférés a medencében lévő kötetekhez.
Ha valaki nem ismeri a logikai entitások felépítését és elnevezését az IBM Spectrum Virtualize kontextusában, akkor most röviden elmagyarázom.
Tárolórendszer logikai elemeinek felépítése
A lemezeket MDisk (Managed Disk) nevű csoportokba gyűjtik. Az MDisk lehet klasszikus RAID (0,1,10,5,6) vagy virtualizált - DRAID (Distributed RAID). A DRAID használatával növelheti a tömb teljesítményét, mert... A csoport összes lemeze felhasználásra kerül, és az újraépítési idő csökken, mivel csak bizonyos blokkokat kell visszaállítani, és nem minden adatot a meghibásodott lemezről.
Adatblokkok elosztása a lemezek között, ha elosztott RAID-et (DRAID) használ RAID-5 módban.
És ez a diagram azt a logikát mutatja, hogyan működik a DRAID újraépítés egyetlen lemezhiba esetén:
A DRAID újraépítés logikája, ha az egyik lemez meghibásodik
Ezután egy vagy több MD-lemez egy úgynevezett készletet alkot. Ugyanazon a készleten belül nem javasolt az MDisk használata különböző RAID/DRAID szintekkel azonos típusú lemezeken. Nem megyünk ebbe túl mélyen bele, mert... ezt a következő cikkek egyikében tervezzük tárgyalni. Nos, valójában a Pool kötetekre oszlik, amelyeket egyik vagy másik blokk-hozzáférési protokoll segítségével mutatnak be a gazdagépeknek.
Tehát mi, a pontban leírt helyzet eredményeként APAR HU02104, három lemez logikai hibája miatt az MDisk nem működött, ami viszont a Pool és a megfelelő kötetek meghibásodásához vezetett.
Mivel ezek a rendszerek meglehetősen okosak, csatlakoztathatók az IBM Storage Insights felhőalapú megfigyelőrendszerhez, amely probléma esetén automatikusan szolgáltatáskérést küld az IBM támogatásának. Létrejön egy alkalmazás, és az IBM szakemberei távolról diagnosztikát végeznek, és kapcsolatba lépnek a rendszer felhasználójával.
Ennek köszönhetően a probléma meglehetősen gyorsan megoldódott, és azonnali javaslat érkezett a támogatási szolgálattól, hogy frissítsük rendszerünket a korábban kiválasztott 8.2.1.9-es firmware-re, amely akkor már javítva volt. Megerősíti .
Eredmények és javaslataink
Ahogy a mondás tartja: "Minden jó, ha jó a vége." A firmware hibája nem okozott komoly problémákat - a szervereket a lehető leghamarabb és adatvesztés nélkül helyreállították. Néhány kliensnek újra kellett indítania a virtuális gépeket, de általában felkészültünk a negatívabb következményekre is, hiszen minden infrastruktúra elemről és kliensgépről naponta készítünk biztonsági mentést.
Megerősítést kaptunk, hogy még a megbízható, 99,9999%-os ígért rendelkezésre állású rendszerek is figyelmet és időben történő karbantartást igényelnek. A kialakult helyzet alapján számos következtetést vontunk le magunknak, és megosztjuk javaslatainkat:
-
Feltétlenül figyelemmel kell kísérni a frissítések megjelenését, tanulmányozni kell a kiadási megjegyzéseket a potenciálisan kritikus problémák javítása érdekében, és időben végre kell hajtani a tervezett frissítéseket.
Ez egy szervezeti, sőt egészen nyilvánvaló szempont, amelyre – úgy tűnik – nem érdemes összpontosítani. Ezen a „sík terepen” azonban meglehetősen könnyen megbotlik. Valójában ez a pillanat növelte a fent leírt problémákat. Legyen nagyon óvatos a frissítési szabályzat elkészítésekor, és nem kevésbé gondosan ellenőrizze a betartásukat. Ez a pont inkább a „fegyelem” fogalmához kapcsolódik.
-
Mindig jobb, ha a rendszert a legújabb szoftververzióval használja. Sőt, a jelenlegi nem a nagyobb számjelzésű, hanem a későbbi megjelenési dátumú.
Például az IBM legalább két szoftverkiadást tart naprakészen tárolórendszereihez. Az írás idején ezek a 8.2 és 8.3. A 8.2-es frissítések korábban jelennek meg. A 8.3-as verzióhoz hasonló frissítés általában kis késéssel jelenik meg.
A 8.3-as kiadás számos funkcionális előnnyel rendelkezik, például az MDisk bővíthetősége (DRAID módban) egy vagy több új lemez hozzáadásával (ez a szolgáltatás a 8.3.1-es verzió óta jelent meg). Ez egy meglehetősen alapvető funkció, de a 8.2-ben sajnos nincs ilyen funkció.
-
Ha valamilyen oknál fogva nem lehetséges a frissítés, akkor a Spectrum Virtualize szoftver 8.2.1.9 és 8.3.1.0 előtti verzióihoz (ahol a fent leírt hiba releváns) az IBM műszaki támogatása az előfordulás kockázatának csökkentése érdekében javasolja. a rendszer teljesítményének korlátozása a medence szintjén, amint az az alábbi ábrán látható (a kép a grafikus felhasználói felület oroszosított verziójában készült). Az 10000 IOPS érték példaként látható, és a rendszer jellemzőinek megfelelően van kiválasztva.
Az IBM tárolási teljesítményének korlátozása
-
Szükséges a tárolórendszerek terhelésének helyes kiszámítása és a túlterhelés elkerülése. Ehhez használhatja az IBM sizer-t (ha van hozzáférése), vagy a partnerek segítségét, vagy harmadik féltől származó erőforrásokat. Feltétlenül ismerni kell a tárolórendszer terhelési profilját, mert A teljesítmény MB/s-ban és IOPS-ben nagymértékben változik, legalább a következő paraméterektől függően:
-
művelet típusa: olvasás vagy írás,
-
műveleti blokk mérete,
-
az olvasási és írási műveletek százalékos aránya a teljes I/O adatfolyamban.
A műveletek sebességét az is befolyásolja, hogy az adatblokkok hogyan kerülnek beolvasásra: szekvenciálisan vagy véletlenszerű sorrendben. Ha több adatelérési műveletet hajt végre az alkalmazás oldalon, akkor létezik a függő műveletek fogalma. Ezt is célszerű figyelembe venni. Mindez segíthet az operációs rendszer, a tárolórendszer, a szerverek/hipervizorok teljesítményszámlálóiból származó adatok összességének áttekintésében, valamint az alkalmazások, DBMS-ek és a lemez erőforrások más „fogyasztói” működési jellemzőinek megértésében.
-
-
Végül pedig ügyeljen arra, hogy a biztonsági másolatok naprakészek legyenek és működjenek. A biztonsági mentés ütemezését a vállalkozás számára elfogadható RPO-értékek alapján kell konfigurálni, és ellenőrizni kell a biztonsági mentések időszakos integritását (jó néhány biztonsági mentési szoftver gyártója automatizált ellenőrzést implementált termékeibe), hogy biztosítsa az elfogadható RTO-értéket.
Köszönöm, hogy a végéig elolvastad.
Készen állunk válaszolni kérdéseire és megjegyzéseire a megjegyzésekben. Is, amelyben rendszeres promóciókat tartunk (kedvezmények az IaaS-en és promóciós kódok ajándéka akár 100%-ig a VPS-en), érdekes híreket írunk és új cikkeket hirdetünk a Habr blogon.
Forrás: will.com