¿Qué versión de firmware es la más “correcta” y “funcional”? Si un sistema de almacenamiento garantiza una tolerancia a fallos del 99,9999%, ¿eso significa que funcionará ininterrumpidamente incluso sin una actualización de software? ¿O, por el contrario, para obtener la máxima tolerancia a fallos, siempre deberías instalar el firmware más reciente? Intentaremos responder a estas preguntas basándonos en nuestra experiencia.
Una pequeña introducción
Todos entendemos que cada versión de software, ya sea un sistema operativo o un controlador para un dispositivo, a menudo contiene defectos/errores y otras "características" que pueden no "aparecer" hasta el final de la vida útil del equipo, o "abrirse". sólo bajo ciertas condiciones. La cantidad y la importancia de tales matices dependen de la complejidad (funcionalidad) del software y de la calidad de las pruebas durante su desarrollo.
A menudo, los usuarios se quedan con el “firmware de fábrica” (el famoso “funciona, así que no te metas con él”) o instalan siempre la última versión (en su opinión, la última significa la que mejor funciona). Usamos un enfoque diferente: miramos las notas de la versión para todo lo utilizado. equipo y seleccione cuidadosamente el firmware adecuado para cada equipo.
Llegamos a esta conclusión, como suele decirse, con experiencia. Usando nuestro ejemplo de operación, le diremos por qué la confiabilidad prometida del 99,9999% de los sistemas de almacenamiento no significa nada si no monitorea rápidamente las actualizaciones y descripciones del software. Nuestro caso es adecuado para usuarios de sistemas de almacenamiento de cualquier fabricante, ya que una situación similar puede ocurrir con hardware de cualquier fabricante.
Elegir un nuevo sistema de almacenamiento
A finales del año pasado se incorporó a nuestra infraestructura un interesante sistema de almacenamiento de datos: un modelo junior de la línea IBM FlashSystem 5000, que en el momento de la compra se llamaba Storwize V5010e. Ahora se vende con el nombre FlashSystem 5010, pero en realidad es la misma base de hardware con el mismo Spectrum Virtualize en su interior.
La presencia de un sistema de gestión unificado es, por cierto, la principal diferencia entre IBM FlashSystem. Para los modelos de la serie más joven, prácticamente no se diferencia de los modelos más productivos. La elección de un modelo específico solo proporciona la base de hardware adecuada, cuyas características permiten utilizar una u otra funcionalidad o proporcionar un mayor nivel de escalabilidad. El software identifica el hardware y proporciona la funcionalidad necesaria y suficiente para esta plataforma.
IBM FlashSystem 5010
Brevemente sobre nuestro modelo 5010. Este es un sistema de almacenamiento en bloque de controlador dual de nivel básico. Puede acomodar discos NLSAS, SAS, SSD. La ubicación de NVMe no está disponible en él, ya que este modelo de almacenamiento está posicionado para resolver problemas que no requieren el rendimiento de las unidades NVMe.
El sistema de almacenamiento se compró para acomodar información o datos de archivo a los que no se accede con frecuencia. Por lo tanto, el conjunto estándar de su funcionalidad fue suficiente para nosotros: Tiering (Easy Tier), Thin Provision. El rendimiento en discos NLSAS al nivel de 1000-2000 IOPS también fue bastante satisfactorio para nosotros.
Nuestra experiencia: cómo no actualizamos el firmware a tiempo
Ahora sobre la actualización del software en sí. En el momento de la compra, el sistema ya tenía una versión ligeramente desactualizada del software Spectrum Virtualize, a saber, 8.2.1.3.
Estudiamos las descripciones del firmware y planeamos una actualización para 8.2.1.9. Si hubiéramos sido un poco más eficientes, este artículo no habría existido; el error no habría ocurrido en un firmware más reciente. Sin embargo, por determinadas razones, la actualización de este sistema se pospuso.
Como resultado, un ligero retraso en la actualización provocó una imagen extremadamente desagradable, como se describe en el enlace: .
Sí, en el firmware de esa versión era relevante el llamado APAR (Informe de Análisis de Programa Autorizado) HU02104. Aparece de la siguiente manera. Bajo carga, bajo ciertas circunstancias, el caché comienza a desbordarse, luego el sistema entra en modo protector, en el que deshabilita la E/S para el grupo. En nuestro caso, parecía desconectar 3 discos para un grupo RAID en modo RAID 6. La desconexión se produce durante 6 minutos. A continuación, se restablece el acceso a los volúmenes del pool.
Si alguien no está familiarizado con la estructura y la denominación de entidades lógicas en el contexto de IBM Spectrum Virtualize, ahora lo explicaré brevemente.
Estructura de los elementos lógicos del sistema de almacenamiento.
Los discos se agrupan en grupos llamados MDisk (Disco administrado). MDisk puede ser un RAID clásico (0,1,10,5,6) o uno virtualizado: DRAID (RAID distribuido). El uso de DRAID le permite aumentar el rendimiento de la matriz, porque... Se utilizarán todos los discos del grupo y se reducirá el tiempo de reconstrucción, debido a que solo será necesario restaurar ciertos bloques y no todos los datos del disco fallido.
Distribución de bloques de datos entre discos cuando se utiliza RAID distribuido (DRAID) en modo RAID-5.
Y este diagrama muestra la lógica de cómo funciona una reconstrucción de DRAID en caso de falla de un disco:
Lógica de reconstrucción de DRAID cuando falla un disco
A continuación, uno o varios MDisks forman el llamado Pool. Dentro del mismo grupo, no se recomienda utilizar MDisk con diferentes niveles RAID/DRAID en discos del mismo tipo. No profundizaremos mucho en esto, porque... Planeamos cubrir esto en uno de los siguientes artículos. Bueno, de hecho, el Pool se divide en Volúmenes, que se presentan utilizando uno u otro protocolo de acceso en bloque a los hosts.
Entonces, nosotros, como resultado de la situación descrita en APAR HU02104, debido a la falla lógica de tres discos, MDisk dejó de ser funcional, lo que, a su vez, resultó en la falla del Pool y los Volúmenes correspondientes.
Debido a que estos sistemas son bastante inteligentes, se pueden conectar al sistema de monitoreo basado en la nube IBM Storage Insights, que envía automáticamente una solicitud de servicio al soporte de IBM si ocurre un problema. Se crea una aplicación y los especialistas de IBM realizan diagnósticos de forma remota y se ponen en contacto con el usuario del sistema.
Gracias a esto, el problema se resolvió con bastante rapidez y se recibió una pronta recomendación por parte del servicio de soporte para actualizar nuestro sistema al firmware 8.2.1.9 previamente seleccionado, que en ese momento ya había sido solucionado. lo confirma .
Resultados y nuestras recomendaciones
Como dice el refrán: “bien está lo que bien acaba”. El error en el firmware no causó problemas graves: los servidores se restauraron lo antes posible y sin pérdida de datos. Algunos clientes tuvieron que reiniciar las máquinas virtuales, pero en general estábamos preparados para consecuencias más negativas, ya que realizamos copias de seguridad diarias de todos los elementos de la infraestructura y de las máquinas cliente.
Hemos recibido confirmación de que incluso los sistemas confiables con una disponibilidad prometida del 99,9999% requieren atención y mantenimiento oportuno. Basándonos en la situación, hemos sacado una serie de conclusiones y compartimos nuestras recomendaciones:
-
Es imperativo monitorear el lanzamiento de actualizaciones, estudiar las Notas de la versión para corregir problemas potencialmente críticos y llevar a cabo las actualizaciones planificadas de manera oportuna.
Este es un punto organizativo e incluso bastante obvio, en el que, al parecer, no vale la pena centrarse. Sin embargo, en este “terreno llano” puedes tropezar con bastante facilidad. En realidad, fue este momento el que añadió los problemas descritos anteriormente. Tenga mucho cuidado a la hora de redactar las normas de actualización y controle con no menos atención su cumplimiento. Este punto se relaciona más con el concepto de “disciplina”.
-
Siempre es mejor mantener el sistema con la última versión del software. Además, el actual no es el que tiene una designación numérica mayor, sino el que tiene una fecha de lanzamiento posterior.
Por ejemplo, IBM mantiene actualizadas al menos dos versiones de software para sus sistemas de almacenamiento. En el momento de escribir este artículo, estos son 8.2 y 8.3. Las actualizaciones para 8.2 salen antes. Por lo general, se lanza una actualización similar para 8.3 con un ligero retraso.
La versión 8.3 tiene una serie de ventajas funcionales, por ejemplo, la capacidad de expandir MDisk (en modo DRAID) agregando uno o más discos nuevos (esta característica apareció desde la versión 8.3.1). Esta es una funcionalidad bastante básica, pero en 8.2, desafortunadamente, no existe tal característica.
-
Si no es posible actualizar por algún motivo, entonces para las versiones del software Spectrum Virtualize anteriores a las versiones 8.2.1.9 y 8.3.1.0 (donde el error descrito anteriormente es relevante), para reducir el riesgo de que ocurra, el soporte técnico de IBM recomienda limitando el rendimiento del sistema a nivel de grupo, como se muestra en la siguiente figura (la imagen fue tomada en la versión rusificada de la GUI). El valor de 10000 IOPS se muestra como ejemplo y se selecciona según las características de su sistema.
Limitar el rendimiento del almacenamiento de IBM
-
Es necesario calcular correctamente la carga de los sistemas de almacenamiento y evitar sobrecargas. Para hacer esto, puede utilizar el medidor de IBM (si tiene acceso a él), la ayuda de socios o recursos de terceros. Es imperativo comprender el perfil de carga en el sistema de almacenamiento, porque El rendimiento en MB/s e IOPS varía mucho dependiendo al menos de los siguientes parámetros:
-
tipo de operación: lectura o escritura,
-
tamaño del bloque de operación,
-
porcentaje de operaciones de lectura y escritura en el flujo total de E/S.
Además, la velocidad de las operaciones se ve afectada por la forma en que se leen los bloques de datos: secuencialmente o en orden aleatorio. Cuando se realizan múltiples operaciones de acceso a datos en el lado de la aplicación, existe el concepto de operaciones dependientes. También es recomendable tener esto en cuenta. Todo esto puede ayudar a ver la totalidad de los datos de los contadores de rendimiento del sistema operativo, el sistema de almacenamiento, los servidores/hipervisores, así como a comprender las características operativas de las aplicaciones, los DBMS y otros "consumidores" de recursos del disco.
-
-
Y por último, asegúrese de tener copias de seguridad actualizadas y funcionando. El programa de respaldo debe configurarse en función de valores de RPO aceptables para la empresa, y se deben verificar verificaciones periódicas de integridad de las copias de seguridad (bastantes proveedores de software de respaldo han implementado verificación automatizada en sus productos) para garantizar un valor de RTO aceptable.
Gracias por leer hasta el final.
Estamos listos para responder sus preguntas y comentarios en los comentarios. También, en el que realizamos promociones periódicas (descuentos en IaaS y obsequios de códigos promocionales de hasta el 100% en VPS), escribimos noticias interesantes y anunciamos nuevos artículos en el blog de Habr.
Fuente: habr.com