Koja verzija firmvera je „najispravnija“ i „najradnija“? Ako sistem za skladištenje garantuje toleranciju grešaka od 99,9999%, da li to znači da će raditi bez prekida čak i bez ažuriranja softvera? Ili, naprotiv, da biste postigli maksimalnu toleranciju grešaka, uvijek biste trebali instalirati najnoviji firmver? Pokušat ćemo odgovoriti na ova pitanja na osnovu našeg iskustva.
Mali uvod
Svi mi razumijemo da svaka verzija softvera, bilo da se radi o operativnom sistemu ili drajveru za uređaj, često sadrži defekte/bugove i druge "karakteristike" koje se možda neće "pojaviti" do kraja vijeka trajanja opreme ili "otvoriti" samo pod određenim uslovima. Broj i značaj takvih nijansi zavisi od složenosti (funkcionalnosti) softvera i od kvaliteta testiranja tokom njegovog razvoja.
Često korisnici ostaju na "firmware-u iz tvornice" (poznato "radi, pa nemoj se petljati s njim") ili uvijek instaliraju najnoviju verziju (po njihovom razumijevanju, najnovija znači da najviše radi). Koristimo drugačiji pristup - gledamo napomene o izdanju za sve korišteno opremu i pažljivo odaberite odgovarajući firmver za svaki komad opreme.
Do ovog zaključka došli smo, kako kažu, iskustvom. Koristeći naš primjer rada, reći ćemo vam zašto obećana pouzdanost sistema za skladištenje od 99,9999% ne znači ništa ako odmah ne pratite ažuriranja i opise softvera. Naše kućište je pogodno za korisnike sistema za skladištenje podataka bilo kog proizvođača, jer se slična situacija može desiti sa hardverom bilo kog proizvođača.
Odabir novog sistema za pohranu podataka
Krajem prošle godine u našu infrastrukturu je dodan zanimljiv sistem za skladištenje podataka: junior model iz linije IBM FlashSystem 5000, koji se u trenutku kupovine zvao Storwize V5010e. Sada se prodaje pod imenom FlashSystem 5010, ali u stvari je ista hardverska baza sa istim Spectrum Virtualize unutra.
Usput, prisutnost jedinstvenog sistema upravljanja je glavna razlika između IBM FlashSystem-a. Za modele mlađe serije, praktički se ne razlikuje od modela produktivnijih. Odabirom određenog modela osigurava se samo odgovarajuća hardverska baza, čije karakteristike omogućavaju korištenje jedne ili druge funkcionalnosti ili pružaju viši nivo skalabilnosti. Softver identificira hardver i pruža potrebnu i dovoljnu funkcionalnost za ovu platformu.
IBM FlashSystem 5010
Ukratko o našem modelu 5010. Ovo je početni sistem za pohranu blokova sa dva kontrolera. Može da primi NLSAS, SAS, SSD diskove. NVMe plasman nije dostupan u njemu, jer je ovaj model skladištenja pozicioniran da rešava probleme koji ne zahtevaju performanse NVMe drajvova.
Sistem za skladištenje je kupljen za smeštaj arhivskih informacija ili podataka kojima se ne pristupa često. Stoga nam je dovoljan standardni skup njegove funkcionalnosti: Tiering (Easy Tier), Thin Provision. Performanse na NLSAS diskovima na nivou od 1000-2000 IOPS su nam takođe bile sasvim zadovoljavajuće.
Naše iskustvo - kako nismo ažurirali firmver na vrijeme
Sada o samom ažuriranju softvera. U trenutku kupovine, sistem je već imao malo zastarjelu verziju softvera Spectrum Virtualize, tj. 8.2.1.3.
Proučili smo opise firmvera i planirali ažuriranje 8.2.1.9. Da smo bili malo efikasniji, ovaj članak ne bi postojao - greška se ne bi pojavila na novijem firmveru. Međutim, iz određenih razloga, ažuriranje ovog sistema je odloženo.
Kao rezultat toga, malo kašnjenje ažuriranja dovelo je do izuzetno neugodne slike, kao u opisu na linku: .
Da, u firmveru te verzije bio je relevantan takozvani APAR (Authorized Program Analysis Report) HU02104. Čini se kako slijedi. Pod opterećenjem, pod određenim okolnostima, keš se počinje prelijevati, tada sistem prelazi u zaštitni način rada, u kojem onemogućuje I/O za skup. U našem slučaju, to je izgledalo kao isključivanje 3 diska za RAID grupu u režimu RAID 6. Isključivanje se dešava 6 minuta. Zatim se vraća pristup volumenima u bazenu.
Ako neko nije upoznat sa strukturom i imenovanjem logičkih entiteta u kontekstu IBM Spectrum Virtualize, sada ću ukratko objasniti.
Struktura logičkih elemenata sistema skladištenja
Diskovi se skupljaju u grupe koje se zovu MDisk (Managed Disk). MDisk može biti klasični RAID (0,1,10,5,6) ili virtuelizirani - DRAID (Distributed RAID). Korištenje DRAID-a vam omogućava da povećate performanse niza, jer... Koristit će se svi diskovi u grupi, a vrijeme rebuild-a će biti smanjeno zbog činjenice da će se morati vratiti samo određeni blokovi, a ne svi podaci s neispravnog diska.
Distribucija blokova podataka po diskovima kada se koristi distribuirani RAID (DRAID) u RAID-5 modu.
A ovaj dijagram pokazuje logiku kako DRAID rebuild radi u slučaju kvara jednog diska:
Logika ponovne izgradnje DRAID-a kada jedan disk pokvari
Zatim, jedan ili više MD diskova formiraju takozvani Pool. Unutar istog bazena, ne preporučuje se korištenje MDisk s različitim RAID/DRAID razinama na diskovima istog tipa. Nećemo ulaziti previše u ovo, jer... planiramo to obraditi u jednom od sljedećih članaka. Pa, u stvari, Pool je podijeljen na Volume, koji se hostovima prikazuju korištenjem jednog ili drugog protokola za pristup bloku.
Dakle, mi, kao rezultat situacije opisane u APAR HU02104, zbog logičkog kvara tri diska, MDisk je prestao da radi, što je zauzvrat rezultiralo kvarom Pool-a i pripadajućih volumena.
Budući da su ovi sistemi prilično pametni, mogu se povezati s IBM Storage Insights sistemom za nadzor u oblaku, koji automatski šalje zahtjev za uslugu IBM podršci ako se pojavi problem. Kreira se aplikacija i IBM stručnjaci daljinski provode dijagnostiku i kontaktiraju korisnika sistema.
Zahvaljujući tome, problem je prilično brzo riješen i primljena je brza preporuka od službe podrške da ažuriramo naš sistem na prethodno odabrani firmware 8.2.1.9, koji je u to vrijeme već bio popravljen. To potvrđuje .
Rezultati i naše preporuke
Kako kažu: "Sve je dobro što se dobro završi." Greška u firmveru nije izazvala ozbiljne probleme - serveri su vraćeni u najkraćem mogućem roku i bez gubitka podataka. Neki klijenti su morali da restartuju virtuelne mašine, ali generalno smo bili spremni na više negativnih posledica, jer svakodnevno pravimo rezervne kopije svih elemenata infrastrukture i klijentskih mašina.
Dobili smo potvrdu da čak i pouzdani sistemi sa 99,9999% obećane dostupnosti zahtijevaju pažnju i pravovremeno održavanje. Na osnovu situacije, sami smo izvukli niz zaključaka i podijelili svoje preporuke:
-
Neophodno je pratiti izdavanje ažuriranja, proučavati napomene o izdanju za ispravke potencijalno kritičnih problema i izvršiti planirana ažuriranja na vrijeme.
Ovo je organizaciona i čak sasvim očigledna tačka, na koju se, čini se, ne vredi fokusirati. Međutim, na ovom "ravnom terenu" možete se vrlo lako spotaknuti. Zapravo, upravo je ovaj trenutak dodao gore opisane probleme. Budite vrlo pažljivi kada sastavljate ažurirane propise i ne manje pažljivo pratite njihovu usklađenost. Ova tačka se više odnosi na koncept „discipline“.
-
Uvijek je bolje držati sistem s najnovijom verzijom softvera. Štaviše, trenutni nije onaj koji ima veću numeričku oznaku, već onaj s kasnijim datumom izlaska.
Na primjer, IBM ažurira najmanje dva izdanja softvera za svoje sisteme skladištenja. U vrijeme pisanja ovog teksta, to su 8.2 i 8.3. Ažuriranja za 8.2 izlaze ranije. Slično ažuriranje za 8.3 obično se izdaje s malim zakašnjenjem.
Izdanje 8.3 ima niz funkcionalnih prednosti, na primjer, mogućnost proširenja MDisk-a (u DRAID modu) dodavanjem jednog ili više novih diskova (ova funkcija se pojavila od verzije 8.3.1). Ovo je prilično osnovna funkcionalnost, ali u 8.2, nažalost, nema takve funkcije.
-
Ako iz nekog razloga nije moguće ažurirati, tada za verzije Spectrum Virtualize softvera prije verzija 8.2.1.9 i 8.3.1.0 (gdje je gore opisana greška relevantna), kako bi se smanjio rizik od njenog pojavljivanja, IBM tehnička podrška preporučuje ograničavanje performansi sistema na nivou bazena, kao što je prikazano na slici ispod (slika je snimljena u rusifikovanoj verziji GUI). Vrijednost od 10000 IOPS prikazana je kao primjer i odabrana je prema karakteristikama vašeg sistema.
Ograničavanje performansi IBM memorije
-
Potrebno je pravilno izračunati opterećenje sistema za skladištenje i izbjeći preopterećenje. Da biste to učinili, možete koristiti ili IBM sizer (ako mu imate pristup), ili pomoć partnera ili resurse treće strane. Imperativ je razumjeti profil opterećenja na sistemu za skladištenje, jer Performanse u MB/s i IOPS uvelike variraju ovisno o barem sljedećim parametrima:
-
tip operacije: čitanje ili pisanje,
-
veličina operativnog bloka,
-
postotak operacija čitanja i pisanja u ukupnom I/O toku.
Također, na brzinu operacija utječe način na koji se blokovi podataka čitaju: uzastopno ili slučajnim redoslijedom. Kada se obavljaju višestruke operacije pristupa podacima na strani aplikacije, postoji koncept zavisnih operacija. Preporučljivo je i ovo uzeti u obzir. Sve ovo može pomoći da se sagleda sveukupnost podataka sa brojača performansi OS-a, sistema za skladištenje podataka, servera/hipervizora, kao i razumevanju operativnih karakteristika aplikacija, DBMS-a i drugih „potrošača“ resursa diska.
-
-
I na kraju, budite sigurni da su sigurnosne kopije ažurirane i da rade. Raspored pravljenja rezervnih kopija treba da bude konfigurisan na osnovu prihvatljivih RPO vrednosti za poslovanje, a periodične provere integriteta rezervnih kopija treba da budu verifikovane (neki proizvođač softvera za pravljenje rezervnih kopija ima automatsku verifikaciju implementiranu u svojim proizvodima) kako bi se osigurala prihvatljiva vrednost RTO.
Hvala vam što ste pročitali do kraja.
Spremni smo odgovoriti na vaša pitanja i komentare u komentarima. Također, u kojoj održavamo redovne promocije (popusti na IaaS i poklone za promotivne kodove do 100% na VPS), pišemo zanimljive vijesti i najavljujemo nove članke na Habr blogu.
izvor: www.habr.com