Care este versiunea de firmware cea mai „corectă” și „funcțională”? Dacă un sistem de stocare garantează o disponibilitate de 99,9999%, înseamnă că va funcționa fără întreruperi chiar și fără actualizări de software? Sau, dimpotrivă, pentru a obține o disponibilitate maximă, ar trebui să instalăm întotdeauna cea mai recentă versiune de firmware? Vom încerca să răspundem la aceste întrebări, bazându-ne pe experiența noastră.
Introducere scurtă
Cu toții înțelegem că fiecare versiune a unui software, fie că este vorba despre un sistem de operare sau un driver pentru un dispozitiv, conține adesea neajunsuri/erori și alte „particularități” care pot, fie să nu „apară” până la sfârșitul duratei de viață a echipamentului, fie să se „reveleze” doar în anumite condiții. Numărul și semnificația acestor detalii depind de complexitatea (funcționalitatea) software-ului și de calitatea testării în timpul dezvoltării acestuia.
Adesea, utilizatorii rămân pe „firmware-ul din fabrică” (celebrul — „funcționează, deci nu interveni”) sau instalează întotdeauna cea mai recentă versiune (în înțelegerea lor, ultima înseamnă cea mai funcțională). Noi însă adoptăm o altă abordare — consultăm notele de lansare pentru tot software-ul utilizat echipamentului și alegem cu atenție firmware-ul potrivit pentru fiecare unitate de echipament.
Am ajuns la această concluzie, așa cum se spune, din experiență. Pe baza experienței noastre de utilizare, vom explica de ce cele promise 99,9999% disponibilitate de către un sistem de stocare nu contează nimic dacă nu urmăriți cu regularitate actualizările și descrierile software-ului. Cazul nostru se potrivește pentru utilizatorii de sisteme de stocare de orice furnizor, deoarece o situație similară se poate întâmpla cu hardware-ul oricărui producător.
Alegerea unui nou sistem de stocare a datelor
La sfârșitul anului trecut, infrastructura noastră a fost îmbogățită cu un sistem interesant de stocare a datelor: modelul de bază din gama IBM FlashSystem 5000, care la momentul achiziției era denumit Storwize V5010e. Acum este vândut sub numele de FlashSystem 5010, dar practic este aceeași bază hardware cu același Spectrum Virtualize în interior.
Prezența unui sistem unitar de gestionare este, de fapt, principala diferență a IBM FlashSystem. La modelele din seria inferioară, acesta nu diferă practic de modelele mai performante. Alegerea unui anumit model oferă doar baza hardware corespunzătoare, a cărei caracteristici permit utilizarea unui anumit set de funcționalități sau asigurarea unui nivel mai ridicat de scalabilitate. Software-ul identifică astfel partea hardware și oferă funcționalitatea necesară și suficientă pentru această platformă.
IBM FlashSystem 5010
Scurt despre modelul nostru 5010. Este un sistem de stocare a datelor cu două controlere, de nivel entry. Poate găzdui discuri NLSAS, SAS și SSD. Stocarea NVMe nu este disponibilă, deoarece acest model de sistem de stocare este destinat pentru soluționarea sarcinilor care nu necesită performanța discurilor NVMe.
Sistemul de stocare a fost achiziționat pentru arhivarea informațiilor sau datelor la care nu se face apel frecvent. De aceea, ne-a fost suficient setul standard de funcționalități: tiering (Easy Tier), Thin Provision. Performanța pe discurile NLSAS la nivel de 1000-2000 IOPS ne-a mulțumit de asemenea.
Experiența noastră — cum nu am actualizat firmware-ul la timp
Acum, să vorbim despre actualizarea software-ului. La momentul achiziției, sistemul avea deja o versiune de software Spectrum Virtualize puțin învechită, și anume, 8.2.1.3.
Am studiat descrierile firmware-urilor și am planificat actualizarea la 8.2.1.9. Dacă am fi fost puțin mai prompți, această articol nu ar fi existat — pe un firmware mai nou, bug-ul nu s-ar fi întâmplat. Totuși, din anumite motive, actualizarea acestui sistem a fost amânată.
În urma unei mici întârzieri în actualizare, am avut parte de o situație extrem de neplăcută, asemănătoare celei descrise în link: .
Da, în firmware-ul acelei versiuni tocmai se afla un APAR (Authorized Program Analysis Report) HU02104, care se manifestă în felul următor. Sub sarcină, în anumite circumstanțe, cache-ul începe să se suprasolicite, după care sistemul intră în modul de protecție, în care oprește intrările și ieșirile pentru pool (Pool). În cazul nostru, a părut ca deconectarea a 3 discuri din grupul RAID în modul RAID 6. Deconectarea durează 6 minute. Apoi, accesul la volumele din Pool este restabilit.
Dacă cineva nu este familiarizat cu structura și denumirea entităților logice în contextul IBM Spectrum Virtualize, voi explica pe scurt.
Structura elementelor logice ale sistemului de stocare
Discurile sunt grupate în unități numite MDisk (Managed Disk). MDisk poate reprezenta un RAID clasic (0,1,10,5,6) sau unul virtualizat – DRAID (Distributed RAID). Utilizarea DRAID permite creșterea performanței matricei, deoarece toate discurile grupului vor fi utilizate și reduce timpul de reconstrucție, deoarece va trebui să se recupereze doar blocuri specifice, nu toate datele de pe discul defect.
Distribuția blocurilor de date pe discuri atunci când se utilizează Distributed RAID (DRAID) în modul RAID-5.
Această schemă arată logica procesului de reconstrucție DRAID în cazul defectării unui disc:
Logica procesului de reconstrucție DRAID la defectarea unui disc
Apoi, unul sau mai multe MDisk formează așa-numitul Pool. În cadrul unui singur pool, nu se recomandă utilizarea de MDisk cu niveluri diferite de RAID/DRAID pe discuri de același tip. Nu ne vom aprofunda în acest aspect, deoarece plănuim să discutăm despre aceasta într-unul dintre articolele viitoare. De asemenea, Pool-ul este împărțit în Volume, care sunt prezentate printr-unul sau alt protocol de acces blocat către gazde.
Astfel, în urma apariției situației descrise în APAR HU02104, din cauza eșecului logic al trei discuri, MDisk-ul a devenit nefuncțional, ceea ce a dus la eșecul Pool-ului și a volumelor corespunzătoare.
Având în vedere că aceste sisteme sunt destul de „inteligente”, ele pot fi conectate la sistemul de monitorizare în cloud IBM Storage Insights, care, în caz de defectare, trimite automat o solicitare de service la suportul tehnic IBM. Se creează o cerere și specialiștii IBM efectuează diagnosticarea de la distanță și iau legătura cu utilizatorul sistemului.
Datorită acestui fapt, problema a fost rezolvată destul de repede, iar suportul tehnic a oferit o recomandare rapidă pentru actualizarea sistemului nostru la versiunea de firmware 8.2.1.9, pe care o alesese anterior, în care acest aspect era deja corectat. Acest lucru confirmă .
Concluzii și recomandările noastre
Așa cum se spune: „ce e bine se termină bine”. Bug-ul din firmware nu a dus la probleme serioase - funcționarea serverelor a fost restabilită în cel mai scurt timp și fără pierderi de date. La unii clienți a fost nevoie să repornim mașinile virtuale, dar, în general, am fost pregătiți pentru consecințe mai grave, întrucât realizăm zilnic copii de rezervă pentru toate elementele infrastructurii și mașinile clienților.
Am primit confirmarea că chiar și sistemele de încredere cu 99,9999% disponibilitate promisă necesită atenție și întreținere promptă. În funcție de situație, am tras câteva concluzii și împărtășim recomandările noastre:
Trebuie să urmăriți cu strictețe apariția actualizărilor, să studiați notele de lansare pentru a verifica corectarea potențialelor probleme critice și să efectuați la timp actualizările planificate.
Acesta este un aspect organizatoric și chiar destul de evident, asupra căruia, la prima vedere, nu ar trebui să ne concentrăm. Cu toate acestea, pe acest „teren plat” se poate călca ușor pe bec. De fapt, tocmai acest aspect a dus la neplăcerile menționate mai sus. Tratați cu seriozitate elaborarea regulilor de actualizare și urmăriți respectarea lor cu aceeași atenție. Acest punct este mai ales legat de noțiunea de „disciplina”.
Este întotdeauna mai bine să aveți sistemul cu versiunea actualizată a software-ului. Iar actualizată - nu înseamnă doar că are o denumire numerică mai mare, ci anume că a fost lansată mai recent.
De exemplu, IBM menține în stare actualizată pentru sistemele sale de stocare date măcar două versiuni ale software-ului. La momentul redactării acestui articol - acestea sunt 8.2 și 8.3. Actualizările pentru 8.2 sunt lansate mai devreme. Apoi, cu o mică întârziere, de obicei apare o actualizare similară pentru 8.3.
Versiunea 8.3 are o serie de avantaje funcționale, de exemplu, posibilitatea extinderii MDisk (în modul DRAID) prin adăugarea unuia sau mai multor discuri noi (această posibilitate a apărut începând cu versiunea 8.3.1). Acesta este un funcțional de bază, dar în 8.2, din păcate, nu există o astfel de posibilitate.
Dacă actualizarea din orice motiv nu este posibilă, pentru versiunile software Spectrum Virtualize anterioare versiunilor 8.2.1.9 și 8.3.1.0 (unde bug-ul descris mai sus este relevant), pentru a reduce riscul apariției acestuia, suportul tehnic IBM recomandă limitarea performanței sistemului la nivelul pool-ului, așa cum este prezentat în figura de mai jos (captura este realizată în varianta localizată a GUI-ului). Valoarea de 10000 IOPS este afișată ca exemplu și este aleasă conform specificațiilor sistemului dumneavoastră.
Limitarea performanței sistemului de stocare IBM
Este necesar să se calculeze corect încărcătura pe sistemele de stocare și să se evite supraîncărcarea. Pentru aceasta, se poate folosi fie dimensionalul IBM (dacă există acces la acesta), fie ajutorul partenerilor, fie resurse externe. Este esențial să se înțeleagă profilul încărcării pe sistemul de stocare, deoarece performanța în MB/s și IOPS variază considerabil în funcție de cel puțin următoarele parametrii:
tipul de operațiune: citire sau scriere,
dimensiunea blocului de operațiune,
raportul procentual al operațiunilor de citire și scriere în fluxul general de intrare-ieșire.
De asemenea, viteza de execuție a operațiunilor este influențată de modul în care sunt citite blocurile de date: secvențial sau aleator. În cazul executării mai multor operațiuni de acces la date pe partea aplicației există conceptul de operațiuni dependent. Acest aspect este de asemenea de dorit să fie luat în considerare. Timpul de acces la performanță al sistemului de operare, sistemului de stocare, serverelor/hypervisor-urilor, precum și înțelegerea caracteristicilor aplicațiilor, SGBD-urilor și altor „consumatori” de resursele de stocare, poate ajuta să se formeze o imagine de ansamblu.
Și nu în ultimul rând, este esențial să aveți copii de rezervă în stare actuală și de lucru. Programul de backup trebuie să fie configurat în funcție de valorile RPO acceptabile pentru afacere și să se verifice periodic integritatea copiilor de rezervă (multe dintre produsele software pentru backup au implementat în produsele lor o verificare automatizată) pentru a asigura o valoare acceptabilă a RTO.
Vă mulțumim că ați citit până la capăt.
Suntem pregătiți să răspundem la întrebările și comentariile dumneavoastră în comentarii. De asemenea,, în care organizăm regulat promoții (reduceri pentru IaaS și tombole cu coduri promoționale de până la 100% pentru VPS), publicăm știri interesante și anunțăm articole noi pe blogul Habr.
Sursa: habr.com
