Que versión de firmware é a máis "correcta" e "funciona"? Se un sistema de almacenamento garante unha tolerancia a fallos do 99,9999 %, significa iso que funcionará sen interrupcións aínda sen unha actualización de software? Ou, pola contra, para obter a máxima tolerancia a fallos, sempre debe instalar o firmware máis recente? Tentaremos responder a estas preguntas a partir da nosa experiencia.
Pequena introdución
Todos entendemos que cada versión de software, xa sexa un sistema operativo ou un controlador para un dispositivo, adoita conter defectos/erros e outras "funcións" que poden non "aparecer" ata o final da vida útil do equipo ou "abertos". só baixo determinadas condicións. O número e a importancia destes matices dependen da complexidade (funcionalidade) do software e da calidade das probas durante o seu desenvolvemento.
Moitas veces, os usuarios permanecen no "firmware de fábrica" (o famoso "funciona, así que non te metas con el") ou sempre instalan a versión máis recente (según o seu entendemento, a máis recente significa que máis funciona). Usamos un enfoque diferente: miramos as notas de versión para todo o que se usa equipos e seleccione coidadosamente o firmware axeitado para cada equipo.
A esta conclusión chegamos, como din, con experiencia. Usando o noso exemplo de funcionamento, dirémosche por que a fiabilidade prometida do 99,9999 % dos sistemas de almacenamento non significa nada se non supervisas rapidamente as actualizacións e as descricións do software. O noso caso é axeitado para usuarios de sistemas de almacenamento de calquera vendedor, xa que unha situación similar pode ocorrer con hardware de calquera fabricante.
Escolla un novo sistema de almacenamento
A finais do ano pasado engadiuse á nosa infraestrutura un interesante sistema de almacenamento de datos: un modelo junior da liña IBM FlashSystem 5000, que no momento da compra chamábase Storwize V5010e. Agora véndese co nome de FlashSystem 5010, pero en realidade é a mesma base de hardware co mesmo Spectrum Virtualize no seu interior.
A presenza dun sistema de xestión unificado é, por certo, a principal diferenza entre IBM FlashSystem. Para os modelos da serie máis nova, practicamente non é diferente dos modelos máis produtivos. A elección dun modelo específico só proporciona a base de hardware adecuada, cuxas características permiten utilizar unha ou outra funcionalidade ou proporcionar un maior nivel de escalabilidade. O software identifica o hardware e proporciona a funcionalidade necesaria e suficiente para esta plataforma.
IBM FlashSystem 5010
Brevemente sobre o noso modelo 5010. Este é un sistema de almacenamento en bloque de dobre controlador de nivel de entrada. Pode acomodar discos NLSAS, SAS, SSD. A colocación de NVMe non está dispoñible nela, xa que este modelo de almacenamento está posicionado para resolver problemas que non requiren o rendemento das unidades NVMe.
O sistema de almacenamento comprouse para acomodar información de arquivo ou datos aos que non se accede con frecuencia. Polo tanto, o conxunto estándar da súa funcionalidade foi suficiente para nós: Tiring (Easy Tier), Thin Provision. O rendemento nos discos NLSAS ao nivel de 1000-2000 IOPS tamén foi bastante satisfactorio para nós.
A nosa experiencia - como non actualizamos o firmware a tempo
Agora sobre a propia actualización do software. No momento da compra, o sistema xa tiña unha versión lixeiramente desactualizada do software Spectrum Virtualize, a saber, 8.2.1.3.
Estudamos as descricións do firmware e planeamos unha actualización 8.2.1.9. Se foramos un pouco máis eficientes, este artigo non existiría: o erro non se produciría nun firmware máis recente. Non obstante, por certos motivos, a actualización deste sistema foi aprazada.
Como resultado, un lixeiro atraso de actualización levou a unha imaxe extremadamente desagradable, como na descrición na ligazón: .
Si, no firmware desa versión era relevante o chamado APAR (Authorized Program Analysis Report) HU02104. Aparece do seguinte xeito. Baixo carga, en determinadas circunstancias, a caché comeza a desbordarse e despois o sistema pasa ao modo de protección, no que desactiva a E/S para o grupo. No noso caso, parecía desconectar 3 discos para un grupo RAID en modo RAID 6. A desconexión prodúcese durante 6 minutos. A continuación, restablece o acceso aos volumes da piscina.
Se alguén non está familiarizado coa estrutura e a denominación das entidades lóxicas no contexto de IBM Spectrum Virtualize, agora explicarei brevemente.
Estrutura dos elementos lóxicos do sistema de almacenamento
Os discos recóllense en grupos chamados MDisk (Disco xestionado). O MDisk pode ser un RAID clásico (0,1,10,5,6) ou un virtualizado - DRAID (RAID Distribuido). Usar DRAID permítelle aumentar o rendemento da matriz, porque... Utilizaranse todos os discos do grupo e reducirase o tempo de reconstrución, debido a que só haberá que restaurar determinados bloques e non todos os datos do disco que fallou.
Distribución de bloques de datos entre discos cando se usa Distributed RAID (DRAID) no modo RAID-5.
E este diagrama mostra a lóxica de como funciona unha reconstrución de DRAID en caso de falla dun disco:
Lóxica da reconstrución de DRAID cando falla un disco
A continuación, un ou máis discos MDisk forman o chamado Pool. Dentro do mesmo grupo, non se recomenda utilizar MDisk con niveis RAID/DRAID diferentes en discos do mesmo tipo. Non afondaremos nisto, porque... pensamos cubrir isto nun dos seguintes artigos. Ben, de feito, Pool divídese en volumes, que se presentan mediante un ou outro protocolo de acceso de bloque aos hosts.
Entón, nós, como resultado da situación descrita en APAR HU02104, debido á falla lóxica de tres discos, o MDisk deixou de ser funcional, o que, á súa vez, provocou o fallo do Pool e dos volumes correspondentes.
Debido a que estes sistemas son bastante intelixentes, pódense conectar ao sistema de monitorización baseado na nube IBM Storage Insights, que envía automaticamente unha solicitude de servizo ao soporte de IBM se se produce un problema. Créase unha aplicación e os especialistas de IBM realizan diagnósticos de forma remota e póñense en contacto co usuario do sistema.
Grazas a isto, o problema resolveuse con bastante rapidez e recibiuse unha rápida recomendación do servizo de soporte para actualizar o noso sistema ao firmware 8.2.1.9 previamente seleccionado, que naquel momento xa estaba solucionado. Confirma .
Resultados e as nosas recomendacións
Como di o refrán: "todo ben o que acaba ben". O erro no firmware non causou problemas graves: os servidores restauráronse o antes posible e sen perda de datos. Algúns clientes tiveron que reiniciar máquinas virtuais, pero en xeral estabamos preparados para consecuencias máis negativas, xa que facemos copias de seguridade diarias de todos os elementos da infraestrutura e das máquinas cliente.
Recibimos confirmación de que incluso os sistemas fiables cunha dispoñibilidade prometida do 99,9999 % requiren atención e mantemento oportuno. En función da situación, extraemos unha serie de conclusións para nós mesmos e compartimos as nosas recomendacións:
-
É imperativo supervisar a publicación de actualizacións, estudar as notas de lanzamento para corrixir problemas potencialmente críticos e levar a cabo as actualizacións planificadas de forma oportuna.
Este é un punto organizativo e mesmo bastante obvio no que, ao parecer, non paga a pena centrarse. Non obstante, neste "terreno nivelado" podes tropezar con bastante facilidade. En realidade, foi este momento o que engadiu os problemas descritos anteriormente. Teña moito coidado ao redactar as normas de actualización e vixíase o seu cumprimento non menos coidadosamente. Este punto refírese máis ao concepto de "disciplina".
-
Sempre é mellor manter o sistema coa última versión do software. Ademais, o actual non é o que ten unha designación numérica maior, senón o que ten unha data de lanzamento posterior.
Por exemplo, IBM mantén actualizadas polo menos dúas versións de software para os seus sistemas de almacenamento. No momento de escribir este artigo, estes son os 8.2 e 8.3. As actualizacións para 8.2 aparecen antes. Unha actualización similar para 8.3 adoita lanzarse cun lixeiro atraso.
A versión 8.3 ten unha serie de vantaxes funcionais, por exemplo, a posibilidade de expandir MDisk (en modo DRAID) engadindo un ou máis discos novos (esta característica aparece desde a versión 8.3.1). Esta é unha funcionalidade bastante básica, pero en 8.2, desafortunadamente, non existe tal característica.
-
Se non é posible actualizar por algún motivo, para as versións do software Spectrum Virtualize anteriores ás versións 8.2.1.9 e 8.3.1.0 (onde o erro descrito anteriormente é relevante), para reducir o risco de que se produza, o soporte técnico de IBM recomenda limitando o rendemento do sistema a nivel de piscina, como se mostra na figura a continuación (a imaxe foi tomada na versión rusificada da GUI). O valor de 10000 IOPS móstrase como exemplo e selecciónase segundo as características do seu sistema.
Limitación do rendemento do almacenamento de IBM
-
É necesario calcular correctamente a carga dos sistemas de almacenamento e evitar a sobrecarga. Para iso, pode utilizar o dimensionador de IBM (se ten acceso a el), ou a axuda de socios ou recursos de terceiros. É imperativo comprender o perfil de carga no sistema de almacenamento, porque O rendemento en MB/s e IOPS varía moito dependendo polo menos dos seguintes parámetros:
-
tipo de operación: lectura ou escritura,
-
tamaño do bloque operativo,
-
porcentaxe de operacións de lectura e escritura no fluxo total de E/S.
Ademais, a velocidade das operacións vese afectada pola forma en que se len os bloques de datos: secuencialmente ou en orde aleatoria. Cando se realizan varias operacións de acceso a datos no lado da aplicación, existe o concepto de operacións dependentes. Tamén é recomendable telo en conta. Todo isto pode axudar a ver a totalidade dos datos dos contadores de rendemento do sistema operativo, o sistema de almacenamento, os servidores/hipervisores, así como a comprensión das características operativas das aplicacións, os DBMS e outros "consumidores" de recursos de disco.
-
-
E, finalmente, asegúrate de ter copias de seguranza actualizadas e funcionando. O programa de copia de seguridade debe configurarse en función de valores de RPO aceptables para a empresa e deben verificarse comprobacións periódicas de integridade das copias de seguridade (bastantes provedores de software de copia de seguridade implementaron verificación automatizada nos seus produtos) para garantir un valor RTO aceptable.
Grazas por ler ata o final.
Estamos preparados para responder ás túas preguntas e comentarios nos comentarios. Tamén, na que realizamos promocións periódicas (descontos en IaaS e agasallos por códigos promocionais ata o 100% en VPS), escribimos noticias interesantes e anunciamos novos artigos no blog Habr.
Fonte: www.habr.com