Quina versió de firmware és la més "correcta" i "funcionant"? Si un sistema d'emmagatzematge garanteix una tolerància a errors del 99,9999%, vol dir això que funcionarà sense interrupcions fins i tot sense una actualització de programari? O, per contra, per obtenir la màxima tolerància a errors, sempre hauríeu d'instal·lar el firmware més recent? Intentarem respondre aquestes preguntes a partir de la nostra experiència.
Petita introducció
Tots entenem que cada versió de programari, ja sigui un sistema operatiu o un controlador per a un dispositiu, sovint conté defectes/errors i altres "característiques" que poden no "aparèixer" fins al final de la vida útil de l'equip o "obertes" només sota determinades condicions. El nombre i la importància d'aquests matisos depèn de la complexitat (funcionalitat) del programari i de la qualitat de les proves durant el seu desenvolupament.
Sovint, els usuaris es queden al "firmware de fàbrica" (el famós "funciona, així que no t'hi fiquis") o sempre instal·len l'última versió (segons el que entenen, l'última significa que més funciona). Utilitzem un enfocament diferent: mirem les notes de la versió per a tot el que s'utilitza equip i seleccioneu acuradament el firmware adequat per a cada equip.
Hem arribat a aquesta conclusió, com diuen, amb experiència. Utilitzant el nostre exemple de funcionament, us explicarem per què la promesa fiabilitat del 99,9999% dels sistemes d'emmagatzematge no significa res si no controleu ràpidament les actualitzacions i les descripcions del programari. El nostre estoig és adequat per a usuaris de sistemes d'emmagatzematge de qualsevol proveïdor, ja que una situació similar pot passar amb el maquinari de qualsevol fabricant.
Escollir un nou sistema d'emmagatzematge
A finals de l'any passat es va afegir a la nostra infraestructura un interessant sistema d'emmagatzematge de dades: un model júnior de la línia IBM FlashSystem 5000, que en el moment de la compra es deia Storwize V5010e. Ara es ven amb el nom de FlashSystem 5010, però de fet és la mateixa base de maquinari amb el mateix Spectrum Virtualize a l'interior.
La presència d'un sistema de gestió unificat és, per cert, la principal diferència entre IBM FlashSystem. Per als models de les sèries més joves, pràcticament no és diferent dels models de les més productives. L'elecció d'un model específic només proporciona la base de maquinari adequada, les característiques de la qual permeten utilitzar una o altra funcionalitat o proporcionar un nivell d'escalabilitat superior. El programari identifica el maquinari i proporciona la funcionalitat necessària i suficient per a aquesta plataforma.
IBM FlashSystem 5010
Breument sobre el nostre model 5010. Aquest és un sistema d'emmagatzematge de blocs de dos controladors d'entrada. Pot acomodar discs NLSAS, SAS, SSD. La ubicació de NVMe no hi està disponible, ja que aquest model d'emmagatzematge està posicionat per resoldre problemes que no requereixen el rendiment de les unitats NVMe.
El sistema d'emmagatzematge es va comprar per acollir informació d'arxiu o dades a les quals no s'accedeix amb freqüència. Per tant, el conjunt estàndard de la seva funcionalitat ens va ser suficient: Tiring (Easy Tier), Thin Provision. El rendiment dels discs NLSAS al nivell de 1000-2000 IOPS també va ser bastant satisfactori per a nosaltres.
La nostra experiència: com no vam actualitzar el firmware a temps
Ara sobre l'actualització del programari en si. En el moment de la compra, el sistema ja tenia una versió una mica obsoleta del programari Spectrum Virtualize, és a dir, 8.2.1.3.
Hem estudiat les descripcions del firmware i hem planificat una actualització 8.2.1.9. Si haguéssim estat una mica més eficients, aquest article no hauria existit; l'error no s'hauria produït en un firmware més recent. Tanmateix, per certs motius, l'actualització d'aquest sistema es va ajornar.
Com a resultat, un lleuger retard en l'actualització va provocar una imatge extremadament desagradable, com a la descripció de l'enllaç: .
Sí, al firmware d'aquesta versió era rellevant l'anomenat APAR (Informe d'anàlisi de programes autoritzat) HU02104. Apareix de la següent manera. Sota càrrega, en determinades circumstàncies, la memòria cau comença a desbordar-se i, a continuació, el sistema entra en mode de protecció, en què desactiva l'E/S per a la piscina. En el nostre cas, semblava desconnectar 3 discs per a un grup RAID en mode RAID 6. La desconnexió es produeix durant 6 minuts. A continuació, es restaura l'accés als volums de la piscina.
Si algú no està familiaritzat amb l'estructura i la denominació de les entitats lògiques en el context d'IBM Spectrum Virtualize, ara ho explicaré breument.
Estructura dels elements lògics del sistema d'emmagatzematge
Els discos es recullen en grups anomenats MDisk (Disc gestionat). L'MDisk pot ser un RAID clàssic (0,1,10,5,6) o un de virtualitzat: DRAID (RAID distribuït). L'ús de DRAID us permet augmentar el rendiment de la matriu, perquè... S'utilitzaran tots els discos del grup i es reduirà el temps de reconstrucció, a causa del fet que només caldrà restaurar certs blocs i no totes les dades del disc fallat.
Distribució de blocs de dades entre discs quan s'utilitza Distributed RAID (DRAID) en mode RAID-5.
I aquest diagrama mostra la lògica de com funciona una reconstrucció de DRAID en cas de fallada d'un disc:
Lògica de reconstrucció de DRAID quan falla un disc
A continuació, un o més discs d'MD formen l'anomenat Pool. Dins del mateix grup, no es recomana utilitzar l'MDisk amb diferents nivells de RAID/DRAID en discs del mateix tipus. No aprofundirem en això, perquè... tenim previst tractar-ho en un dels articles següents. Bé, de fet, Pool es divideix en volums, que es presenten mitjançant un o un altre protocol d'accés de bloc als amfitrions.
Així doncs, nosaltres, com a conseqüència de la situació descrita a APAR HU02104, a causa de la fallada lògica de tres discos, l'MDisk va deixar de ser funcional, fet que, al seu torn, va provocar la fallada del Pool i dels volums corresponents.
Com que aquests sistemes són bastant intel·ligents, es poden connectar al sistema de supervisió basat en núvol d'IBM Storage Insights, que envia automàticament una sol·licitud de servei al suport d'IBM si es produeix un problema. Es crea una aplicació i els especialistes d'IBM realitzen diagnòstics de forma remota i contacten amb l'usuari del sistema.
Gràcies a això, el problema es va resoldre amb força rapidesa i es va rebre una recomanació ràpida del servei d'assistència per actualitzar el nostre sistema al firmware 8.2.1.9 prèviament seleccionat, que en aquell moment ja s'havia solucionat. Es confirma .
Resultats i les nostres recomanacions
Com diu la dita: "tot està bé el que acaba bé". L'error del microprogramari no va causar problemes greus: els servidors es van restaurar el més aviat possible i sense pèrdua de dades. Alguns clients van haver de reiniciar les màquines virtuals, però en general estàvem preparats per a conseqüències més negatives, ja que fem còpies de seguretat diàries de tots els elements de la infraestructura i de les màquines client.
Hem rebut la confirmació que fins i tot els sistemes fiables amb una disponibilitat prometida del 99,9999% requereixen atenció i un manteniment puntual. A partir de la situació, hem extret una sèrie de conclusions per nosaltres mateixos i compartim les nostres recomanacions:
-
És imprescindible supervisar el llançament de les actualitzacions, estudiar les notes de la versió per corregir problemes potencialment crítics i dur a terme les actualitzacions planificades de manera oportuna.
Es tracta d'un punt organitzatiu i fins i tot força evident, en el qual, sembla, no val la pena centrar-se. Tanmateix, en aquest "terren pla" podeu ensopegar amb força facilitat. De fet, va ser aquest moment el que va afegir els problemes descrits anteriorment. Aneu amb molt de compte a l'hora d'elaborar la normativa d'actualització i vigileu el compliment d'aquestes no menys acuradament. Aquest punt es relaciona més amb el concepte de "disciplina".
-
Sempre és millor mantenir el sistema amb l'última versió del programari. A més, l'actual no és la que té una designació numèrica més gran, sinó la que té una data de llançament posterior.
Per exemple, IBM manté actualitzades almenys dues versions de programari per als seus sistemes d'emmagatzematge. En el moment d'escriure aquest article, aquests són 8.2 i 8.3. Les actualitzacions per a la 8.2 surten abans. Normalment, una actualització similar per a la 8.3 es publica amb un lleuger retard.
La versió 8.3 té una sèrie d'avantatges funcionals, per exemple, la possibilitat d'ampliar MDisk (en mode DRAID) afegint un o més discs nous (aquesta característica ha aparegut des de la versió 8.3.1). Aquesta és una funcionalitat bastant bàsica, però a la 8.2, malauradament, no hi ha aquesta característica.
-
Si no és possible actualitzar per algun motiu, per a les versions del programari Spectrum Virtualize anteriors a les versions 8.2.1.9 i 8.3.1.0 (on l'error descrit anteriorment és rellevant), per reduir el risc que es produeixi, el suport tècnic d'IBM recomana limitant el rendiment del sistema a nivell de piscina, tal com es mostra a la figura següent (la imatge es va fer a la versió russificada de la GUI). El valor de 10000 IOPS es mostra com a exemple i es selecciona segons les característiques del vostre sistema.
Limitació del rendiment d'emmagatzematge d'IBM
-
Cal calcular correctament la càrrega dels sistemes d'emmagatzematge i evitar la sobrecàrrega. Per fer-ho, podeu utilitzar el dimensionador d'IBM (si hi teniu accés) o l'ajuda de socis o recursos de tercers. És imprescindible entendre el perfil de càrrega del sistema d'emmagatzematge, perquè El rendiment en MB/s i IOPS varia molt segons almenys els paràmetres següents:
-
tipus d'operació: llegir o escriure,
-
mida del bloc d'operacions,
-
percentatge d'operacions de lectura i escriptura en el flux total d'E/S.
A més, la velocitat de les operacions es veu afectada per com es llegeixen els blocs de dades: seqüencialment o en ordre aleatori. Quan es realitzen múltiples operacions d'accés a dades en el costat de l'aplicació, hi ha el concepte d'operacions dependents. També és recomanable tenir-ho en compte. Tot això pot ajudar a veure la totalitat de les dades dels comptadors de rendiment del sistema operatiu, sistema d'emmagatzematge, servidors/hipervisors, així com una comprensió de les característiques operatives d'aplicacions, DBMS i altres "consumidors" de recursos de disc.
-
-
I, finalment, assegureu-vos de tenir còpies de seguretat actualitzades i que funcionin. La programació de còpies de seguretat s'ha de configurar en funció de valors de RPO acceptables per a l'empresa i s'han de verificar les comprovacions periòdiques d'integritat de les còpies de seguretat (uns quants proveïdors de programari de còpia de seguretat tenen implementada la verificació automatitzada als seus productes) per garantir un valor de RTO acceptable.
Gràcies per llegir fins al final.
Estem preparats per respondre les vostres preguntes i comentaris als comentaris. També, en què fem promocions periòdiques (descomptes en IaaS i obsequis de codis promocionals fins al 100% en VPS), escrivim notícies interessants i anunciem nous articles al blog Habr.
Font: www.habr.com