Ktorá verzia firmvéru je tá „správna“ a „funkčná“? Ak úložný systém garantuje odolnosť voči chybám na úrovni 99,9999%, znamená to, že bude fungovať bez prerušenia aj bez aktualizácie softvéru? Alebo naopak, na dosiahnutie maximálnej odolnosti voči chybám je potrebné vždy inštalovať najnovšiu verziu firmvéru? Pokúsime sa odpovedať na tieto otázky, vychádzajúc z našich skúseností.
Krátke úvodné slovo
Všetci chápeme, že v každej verzii softvéru, nech už ide o operačný systém alebo ovládač pre nejaké zariadenie, zvyčajne sú prítomné nedostatky/bugy a iné „špecifiká“, ktoré sa môžu buď neprejaviť až do konca životnosti zariadenia, alebo sa „ukázať“ len za určitých podmienok. Počet a význam týchto nuansí závisí od zložitosti (funkčnosti) softvéru a od kvality testovania pri jeho vývoji.
Často zostávajú používatelia na „firmvéri z výroby“ (známe – „funguje, tak sa do toho nezasahuj“) alebo vždy inštalujú najnovšiu verziu (v ich chápaní posledná verzia je tá najspoľahlivejšia). My však používame iný prístup – sledujeme vydania poznámok pre všetok používaný hardware a starostlivo vyberáme vhodný firmvér pre každý kus vybavenia.
K tomuto záveru sme dospeli, ako sa hovorí, s praxou. Na našich skúsenostiach vám prerozprávame, prečo sľubovaných 99,9999 % spoľahlivosti úložného systému nič neznamená, ak nebudete včas sledovať aktualizácie a popisy softvéru. Náš prípad bude vhodný pre používateľov úložných systémov akéhokoľvek dodávateľa, pretože podobná situácia sa môže vyskytnúť aj s hardvérom akéhokoľvek výrobcu.
Výber nového systému na ukladanie dát
Na konci minulého roka sa k našej infraštruktúre pridala zaujímavá úložná jednotka: základný model z línie IBM FlashSystem 5000, ktorý sa pri kúpe nazýval Storwize V5010e. Teraz sa predáva pod názvom FlashSystem 5010, ale v podstate ide o tú istú hardvérovú základňu so tým istým Spectrum Virtualize vo vnútri.
Jednotná správa systému je v skutočnosti hlavný rozdiel IBM FlashSystem. U modelov nižšej série sa prakticky nelíši od výkonnejších modelov. Výber konkrétneho modelu iba poskytuje zodpovedajúcu hardvérovú základňu, ktorej parametre umožňujú využívať rôznu funkcionalitu alebo zabezpečiť vyššiu úroveň škálovateľnosti. Softvér pritom identifikuje hardvérovú časť a poskytuje nevyhnutnú a dostatočnú funkcionalitu pre túto platformu.
IBM FlashSystem 5010
Stručne o našom modeli 5010. Ide o dvojkontrolérový blok úložného systému základnej úrovne. Je schopný ukladať disky NLSAS, SAS, SSD. Umiestnenie NVMe na ňom nie je dostupné, keďže tento model SÚI je určený na riešenie úloh, ktoré nevyžadujú výkon NVMe diskov.
SÚI bola zakúpená na uloženie archívnych informácií alebo údajov, k ktorým sa nepristupuje často. Preto nám stačil štandardný súbor jej funkcií: tiering (Easy Tier), Thin Provision. Výkon na diskoch NLSAS na úrovni 1000-2000 IOPS nás tiež celkom uspokojoval.
Naša skúsenosť — ako sme nestihli včas aktualizovať firmvér
Teraz pridáme konkrétny popis aktualizácie softvéru. V čase zakúpenia mala sústava už trochu zastaranú verziu softvéru Spectrum Virtualize, a to konkrétne, 8.2.1.3.
Preskúmali sme popis firmvérov a naplánovali sme aktualizáciu na 8.2.1.9. Keby sme boli trochu pohotovejší, táto článok by neexistoval — na novšej firme by k tejto chybe nedošlo. Z určitých dôvodov bolo však aktualizovanie tejto sústavy odložené.
V dôsledku drobného oneskorenia aktualizácie došlo k mimoriadne nepríjemnej situácii, ako je popísané v odkaze: .
Áno, vo firme tej verzie bol v skutočnosti relevantný takzvaný APAR (Authorized Program Analysis Report) HU02104. Prejavuje sa to nasledovne. Pod záťažou sa za určitých okolností začína pretekať vyrovnávacia pamäť, následne systém prejde do ochranného režimu, v ktorom vypne vstup-výstup pre pool (Pool). V našom prípade to vypadalo ako vypnutie 3 diskov pre RAID skupinu v režime RAID 6. Vypnutie trvá 6 minút. Potom sa prístup k objemom v poole obnoví.
Ak niekto nie je oboznámený so štruktúrou a názvami logických entít v kontexte IBM Spectrum Virtualize, teraz vám to stručne vysvetlím.
Štruktúra logických prvkov SÚS
Disky sú zoskupené do skupín, ktoré sa nazývajú MDisk (Managed Disk). MDisk môže predstavovať klasický RAID (0,1,10,5,6) alebo virtualizovaný – DRAID (Distributed RAID). Použitie DRAID umožňuje zvýšiť výkon poľa, pretože budú používané všetky disky skupiny, a skrátiť čas obnovy, pretože je potrebné obnovovať len určité bloky, nie všetky údaje z nefunkčného disku.
Rozdelenie blokov údajov na disky pri použití Distributed RAID (DRAID) v režime RAID-5.
A tento diagram ukazuje logiku práce obnovy DRAID v prípade zlyhania jedného disku:
Logika práce obnovy DRAID pri zlyhaní jedného disku
Ďalej jeden alebo viac MDisk tvoria tzv. Pool. V rámci jedného poolu sa neodporúča používať MDisk s rôznymi úrovňami RAID/DRAID na diskoch rovnakého typu. Nechceme sa do toho veľmi zaoberať, pretože plánujeme o tom rozprávať v rámci jedného z nasledujúcich článkov. No a vlastne, Pool sa rozdeľuje na Témy (Volumes), ktoré sa prezentujú prostredníctvom toho alebo iného protokolu blokového prístupu smerom k hostiteľom.
Takže, v dôsledku vzniku situácie, ktorá bola popísaná v APAR HU02104, z dôvodu logického zlyhania troch diskov, prestal byť funkčný MDisk, čo viedlo k zlyhaniu Poolu a príslušných Tém.
Keďže tieto systémy sú dosť 'inteligentné', je možné ich pripojiť k cloudovému monitorovaciemu systému IBM Storage Insights, ktorý automaticky po vzniku poruchy odošle požiadavku na servis do technickej podpory IBM. Vytvorí sa tiket a odborníci IBM v diaľkovom režime vykonávajú diagnostiku a kontaktujú používateľa systému.
Vďaka tomu sa otázka vyriešila pomerne rýchlo a zo strany technickej podpory bola poskytnutá okamžitá doporučenie na aktualizáciu nášho systému na už skôr vybranú verziu firmvéru 8.2.1.9, v ktorej bol tento problém už vyriešený. To potvrdzuje .
Zhrnutie a naše odporúčania
Ako sa hovorí: „dobre je to, čo dobre končí“. Chyba v softvéri sa neobrátila na vážne problémy – činnosť serverov bola obnovená v krátkom čase a bez straty dát. U niektorých klientov bolo potrebné reštartovať virtuálne stroje, ale celkovo sme boli pripravení na horšie následky, pretože každý deň robíme zálohy všetkých komponentov infraštruktúry a klientských strojov.
Dostali sme potvrdenie, že aj spoľahlivé systémy s 99,9999 % sľubovanej dostupnosti potrebujú pozornosť a pravidelnú údržbu. Na základe situácie sme si vyvodili niekoľko záverov a delíme sa o naše odporúčania:
Je potrebné neustále sledovať vydanie aktualizácií, študovať Release Notes na opravu potenciálne kritických bodov a včas vykonávať naplánované aktualizácie.
Toto je organizačný a dokonca dosť zrejmý moment, na ktorom by sa nemalo zaostávať. Napriek tomu je možné sa o neho celkom ľahko potknúť. Práve tento moment prispel k vyššie popísaným nepríjemnostiam. Venovať sa zostaveniu predpisu o aktualizácii veľmi dôkladne a rovnako pozorne sledovať jeho dodržiavanie. Tento bod sa viac týka pojmu „disciplína“.
Vždy je lepšie udržiavať systém s aktuálnou verziou softvéru. A aktuálna verzia nie je len tá, ktorá má vyššie číselné označenie, ale konkrétne s neskorším dátumom vydania.
Napríklad IBM pre svoje systémy ukladania dát udržuje aspoň dve verzie softvéru aktuálne. V čase písania tohto článku sú to 8.2 a 8.3. Aktualizácie pre 8.2 vychádzajú skôr. Nasleduje ich podobné aktualizácie pre 8.3, obyčajne s malým oneskorením.
Verzia 8.3 má niekoľko funkčných výhod, ako napríklad možnosť rozšírenia MDisk (v režime DRAID) pridaním jedného alebo viacerých nových diskov (táto možnosť sa objavila od verzie 8.3.1). Je to pomerne základná funkcia, ale v 8.2 táto možnosť, žiaľ, neexistuje.
Ak sa nemôžete z nejakého dôvodu aktualizovať, pre verzie softvéru Spectrum Virtualize predchádzajúce verziám 8.2.1.9 a 8.3.1.0 (kde je uvedená chyba relevantná), IBM odporúča obmedziť výkon systému na úrovni poolu, ako je znázornené na obrázku nižšie (snímka bola urobená v lokalizovanej verzii GUI). Hodnota 10000 IOPS je uvedená ako príklad a prispôsobuje sa podľa charakteristík vášho systému.
Obmedzenie výkonu úložného systému IBM
Je potrebné správne vypočítať záťaž na úložné systémy a vyhnúť sa preťaženiu. Na tento účel môžete využiť buď size-r, pokiaľ máte k nemu prístup, alebo pomoc partnerov, alebo externé zdroje. Nevyhnutné je pritom porozumieť profilu záťaže na úložný systém, keďže výkon v MB/s a IOPS sa značne líši v závislosti minimálne od nasledujúcich parametrov:
typ operácie: čítanie alebo zápis,
veľkosť bloku operácie,
percentuálny pomer operácií čítania a zápisu v celkovom toku vstupov a výstupov.
Rovnako, na rýchlosť vykonávania operácií vplýva, ako sa bloky dát čítajú: sekvenčne alebo náhodne. Pri vykonávaní viacerých operácií prístupu k údajom na strane aplikácie existuje pojem závislých operácií. To by sa tiež malo zohľadniť. Všetky tieto faktory môžu pomôcť získať celkový obraz údajov z výkonových čítačov OS, úložného systému, serverov/hypervizorov, ako aj pochopenie špecifík fungovania aplikácií, DBMS a iných „spotrebiteľov“ diskových zdrojov.
A napokon, určite majte záložné kópie v aktuálnom a funkčnom stave. Rozvrh zálohovania by ste mali nastavovať na základe prijateľných hodnôt RPO a pravidelne kontrolovať integritu záložných kópií (množstvo výrobcov softvéru na zálohovanie implementovalo v svojich produktoch automatizovanú kontrolu) pre zabezpečenie prijateľnej hodnoty RTO.
Ďakujeme, že ste dočítali až do konca.
Sme pripravení odpovedať na vaše otázky a pripomienky v komentároch. Taktiež, v ktorom pravidelne usporadúvame akcie (zľavy na IaaS a súťaže o promo kódy až do 100 % na VPS), píšeme zaujímavé novinky a oznamujeme nové články na blogu Habr.
Zdroj: habr.com
