Care versiune de firmware este cea mai „corectă” și „funcțională”? Dacă un sistem de stocare garantează o toleranță la erori de 99,9999%, înseamnă asta că va funcționa neîntrerupt chiar și fără o actualizare de software? Sau, dimpotrivă, pentru a obține toleranță maximă la erori, ar trebui să instalați întotdeauna cel mai recent firmware? Vom încerca să răspundem la aceste întrebări pe baza experienței noastre.
Mică introducere
Înțelegem cu toții că fiecare versiune de software, fie că este vorba despre un sistem de operare sau un driver pentru un dispozitiv, conține adesea defecte/bugi și alte „funcții” care pot să nu „apară” până la sfârșitul duratei de viață a echipamentului sau „deschise” numai in anumite conditii. Numărul și semnificația unor astfel de nuanțe depind de complexitatea (funcționalitatea) software-ului și de calitatea testării în timpul dezvoltării sale.
Adesea, utilizatorii rămân pe „firmware-ul din fabrică” (celebrul „funcționează, așa că nu te încurcă cu el”) sau instalează întotdeauna cea mai recentă versiune (după înțelegerea lor, cea mai recentă înseamnă cea mai funcțională). Folosim o abordare diferită - ne uităm la notele de lansare pentru tot ceea ce este folosit echipament și selectați cu atenție firmware-ul corespunzător pentru fiecare echipament.
Am ajuns la această concluzie, după cum se spune, cu experiență. Folosind exemplul nostru de operare, vă vom spune de ce fiabilitatea promisă de 99,9999% a sistemelor de stocare nu înseamnă nimic dacă nu monitorizați cu promptitudine actualizările și descrierile software. Carcasa noastră este potrivită pentru utilizatorii sistemelor de stocare de la orice furnizor, deoarece o situație similară se poate întâmpla cu hardware-ul de la orice producător.
Alegerea unui nou sistem de stocare
La sfârșitul anului trecut, infrastructurii noastre a fost adăugat un sistem interesant de stocare a datelor: un model junior din linia IBM FlashSystem 5000, care la momentul achiziției se numea Storwize V5010e. Acum este vândut sub numele FlashSystem 5010, dar de fapt este aceeași bază hardware cu același Spectrum Virtualize în interior.
Prezența unui sistem de management unificat este, de altfel, principala diferență între IBM FlashSystem. Pentru modelele din seria mai tânără, practic nu este diferită de modelele celor mai productive. Alegerea unui anumit model oferă doar baza hardware adecvată, ale cărei caracteristici fac posibilă utilizarea uneia sau alteia funcționalități sau oferă un nivel mai ridicat de scalabilitate. Software-ul identifică hardware-ul și oferă funcționalitatea necesară și suficientă pentru această platformă.
IBM FlashSystem 5010
Pe scurt despre modelul nostru 5010. Acesta este un sistem de stocare bloc cu controler dublu de nivel de intrare. Poate găzdui discuri NLSAS, SAS, SSD. Plasarea NVMe nu este disponibilă în acesta, deoarece acest model de stocare este poziționat pentru a rezolva probleme care nu necesită performanța unităților NVMe.
Sistemul de stocare a fost achiziționat pentru a găzdui informații de arhivă sau date care nu sunt accesate frecvent. Prin urmare, setul standard al funcționalității sale a fost suficient pentru noi: Tiring (Easy Tier), Thin Provision. Performanța pe discuri NLSAS la nivelul 1000-2000 IOPS a fost și ea destul de satisfăcătoare pentru noi.
Experiența noastră - cum nu am actualizat firmware-ul la timp
Acum despre actualizarea software-ului în sine. La momentul achiziției, sistemul avea deja o versiune ușor învechită a software-ului Spectrum Virtualize, și anume, 8.2.1.3.
Am studiat descrierile firmware-ului și am planificat o actualizare la 8.2.1.9. Dacă am fi fost puțin mai eficienți, acest articol nu ar fi existat - bug-ul nu ar fi apărut pe un firmware mai recent. Cu toate acestea, din anumite motive, actualizarea acestui sistem a fost amânată.
Drept urmare, o ușoară întârziere a actualizării a dus la o imagine extrem de neplăcută, ca în descrierea de la link: .
Da, în firmware-ul acelei versiuni era relevant așa-numitul APAR (Authorized Program Analysis Report) HU02104. Apare după cum urmează. Sub sarcină, în anumite circumstanțe, memoria cache începe să se depășească, apoi sistemul intră în modul de protecție, în care dezactivează I/O pentru pool. În cazul nostru, arăta ca deconectarea a 3 discuri pentru un grup RAID în modul RAID 6. Deconectarea are loc timp de 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 acum pe scurt.
Structura elementelor logice ale sistemului de stocare
Discurile sunt colectate în grupuri numite MDisk (Disc gestionat). MDisk poate fi un RAID clasic (0,1,10,5,6) sau unul virtualizat - DRAID (Distributed RAID). Utilizarea DRAID vă permite să creșteți performanța matricei, deoarece... Toate discurile din grup vor fi folosite, iar timpul de reconstrucție va fi redus, datorită faptului că doar anumite blocuri vor trebui restaurate și nu toate datele de pe discul eșuat.
Distribuția blocurilor de date pe discuri atunci când utilizați Distributed RAID (DRAID) în modul RAID-5.
Și această diagramă arată logica modului în care funcționează o reconstrucție DRAID în cazul unei erori de disc:
Logica reconstrucției DRAID atunci când un disc eșuează
Apoi, unul sau mai multe MDisk-uri formează un așa-numit Pool. În cadrul aceluiași pool, nu este recomandat să utilizați MDisk cu niveluri RAID/DRAID diferite pe discuri de același tip. Nu vom intra în asta prea profund, pentru că... intenționăm să acoperim acest lucru într-unul dintre articolele următoare. Ei bine, de fapt, Pool-ul este împărțit în volume, care sunt prezentate folosind unul sau altul protocol de acces bloc la gazde.
Deci, noi, ca urmare a situației descrise în APAR HU02104, din cauza defecțiunii logice a trei discuri, MDisk a încetat să mai fie funcțional, ceea ce, la rândul său, a dus la o defecțiune a Pool-ului și a volumelor corespunzătoare.
Deoarece aceste sisteme sunt destul de inteligente, pot fi conectate la sistemul de monitorizare bazat pe cloud IBM Storage Insights, care trimite automat o solicitare de service către suportul IBM dacă apare o problemă. Este creată o aplicație, iar specialiștii IBM efectuează diagnosticări de la distanță și contactează utilizatorul sistemului.
Datorită acestui fapt, problema a fost rezolvată destul de repede și a fost primită o recomandare promptă de la serviciul de asistență pentru a actualiza sistemul nostru la firmware-ul selectat anterior 8.2.1.9, care la acel moment fusese deja remediat. Se confirmă .
Rezultate și recomandările noastre
După cum se spune: „Totul este bine care se termină cu bine”. Bug-ul din firmware nu a cauzat probleme serioase - serverele au fost restaurate cât mai curând posibil și fără pierderi de date. Unii clienți au fost nevoiți să repornească mașinile virtuale, dar, în general, am fost pregătiți pentru consecințe mai negative, deoarece facem copii de rezervă zilnice ale tuturor elementelor de infrastructură și ale mașinilor client.
Am primit confirmarea că și sistemele fiabile cu disponibilitate promisă de 99,9999% necesită atenție și întreținere în timp util. Pe baza situației, am tras o serie de concluzii pentru noi înșine și împărtășim recomandările noastre:
-
Este imperativ să monitorizați lansarea actualizărilor, să studiați Notele de lansare pentru corectarea problemelor potențial critice și să efectuați actualizările planificate în timp util.
Acesta este un punct organizatoric și chiar destul de evident, asupra căruia, se pare, nu merită să ne concentrăm. Cu toate acestea, pe acest „teren nivelat” te poți împiedica destul de ușor. De fapt, tocmai acest moment a adăugat necazurile descrise mai sus. Fiți foarte atenți atunci când elaborați regulamentele de actualizare și monitorizați respectarea acestora, nu mai puțin atent. Acest punct se referă mai mult la conceptul de „disciplină”.
-
Este întotdeauna mai bine să păstrați sistemul cu cea mai recentă versiune de software. Mai mult, cel actual nu este cel care are o denumire numerică mai mare, ci mai degrabă cel cu o dată de lansare ulterioară.
De exemplu, IBM menține la zi cel puțin două versiuni de software pentru sistemele sale de stocare. La momentul scrierii acestui articol, acestea sunt 8.2 și 8.3. Actualizările pentru 8.2 au apărut mai devreme. O actualizare similară pentru 8.3 este de obicei lansată cu o ușoară întârziere.
Versiunea 8.3 are o serie de avantaje funcționale, de exemplu, capacitatea de a extinde MDisk (în modul DRAID) prin adăugarea unuia sau mai multor discuri noi (această caracteristică a apărut începând cu versiunea 8.3.1). Aceasta este o funcționalitate destul de simplă, dar în 8.2, din păcate, nu există o astfel de caracteristică.
-
Dacă nu este posibilă actualizarea dintr-un motiv oarecare, atunci pentru versiunile software-ului Spectrum Virtualize anterioare versiunilor 8.2.1.9 și 8.3.1.0 (unde eroarea descrisă mai sus este relevantă), pentru a reduce riscul apariției acestuia, suportul tehnic IBM recomandă limitarea performanței sistemului la nivel de bazin, așa cum se arată în figura de mai jos (poza a fost făcută în versiunea rusificată a GUI). Valoarea de 10000 IOPS este prezentată ca exemplu și este selectată în funcție de caracteristicile sistemului dumneavoastră.
Limitarea performanței stocării IBM
-
Este necesar să se calculeze corect sarcina pe sistemele de stocare și să se evite supraîncărcarea. Pentru a face acest lucru, puteți utiliza fie dimensiunea IBM (dacă aveți acces la acesta), fie ajutorul partenerilor, fie al resurselor terțelor părți. Este imperativ să înțelegeți profilul de încărcare pe sistemul de stocare, deoarece Performanța în MB/s și IOPS variază foarte mult în funcție de cel puțin următorii parametri:
-
tip de operație: citire sau scriere,
-
dimensiunea blocului de operare,
-
procentul operațiunilor de citire și scriere în fluxul total de I/O.
De asemenea, viteza operațiunilor este afectată de modul în care sunt citite blocurile de date: secvenţial sau în ordine aleatorie. Când se efectuează mai multe operațiuni de acces la date din partea aplicației, există conceptul de operații dependente. De asemenea, este recomandabil să țineți cont de acest lucru. Toate acestea pot ajuta la vizualizarea totalității datelor de la contoarele de performanță ale sistemului de operare, sistemul de stocare, servere/hypervisore, precum și înțelegerea caracteristicilor de operare ale aplicațiilor, DBMS-urilor și alți „consumatori” de resurse de disc.
-
-
Și, în sfârșit, asigurați-vă că aveți copii de rezervă actualizate și funcționale. Programul de backup ar trebui configurat pe baza valorilor RPO acceptabile pentru afacere, iar verificările periodice ale integrității backup-urilor ar trebui verificate (destul de mulți furnizori de software de backup au implementată verificarea automată în produsele lor) pentru a asigura o valoare RTO acceptabilă.
Vă mulțumesc că ați citit până la capăt.
Suntem gata să vă răspundem la întrebări și comentarii în comentarii. De asemenea, în care ținem promoții regulate (reduceri la IaaS și cadouri pentru coduri promoționale de până la 100% la VPS), scriem știri interesante și anunțăm noi articole pe blogul Habr.
Sursa: www.habr.com