¿Cuál es la versión de firmware más "correcta" y "funcional"? Si el almacenamiento garantiza una disponibilidad del 99,9999%, ¿significa que funcionará sin interrupciones incluso sin actualizar el software? ¿O, por el contrario, para lograr la máxima disponibilidad, siempre hay que instalar la versión más reciente? Intentaremos responder a estas preguntas basándonos en nuestra experiencia.
Una pequeña introducción
Todos entendemos que en cada versión de software, ya sea un sistema operativo o un controlador para un dispositivo, a menudo hay fallos y otras "particularidades" que pueden o no "manifiestarse" durante la vida útil del equipo, y que pueden "salir a la luz" solo 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 realizadas durante su desarrollo.
A menudo, los usuarios se quedan con el "firmware de fábrica" (el famoso "si funciona, no lo toques") o siempre instalan la versión más reciente (en su entendimiento, la última significa la más funcional). Nosotros utilizamos un enfoque diferente: revisamos las notas de lanzamiento de todo lo que usamos. y elegimos cuidadosamente el firmware adecuado para cada unidad de hardware.
A esta conclusión llegamos, por así decirlo, con experiencia. A partir de nuestra propia explotación, explicaremos por qué los prometidos 99,9999 % de fiabilidad del almacenamiento no significan nada si no se supervisa y actualiza el software puntualmente. Nuestro caso es relevante para los usuarios de almacenamiento de cualquier proveedor, ya que esta situación puede ocurrir con el hardware de cualquier fabricante.
Selección de un nuevo sistema de almacenamiento de datos
A finales del año pasado, nuestra infraestructura se amplió con un sistema de almacenamiento interesante: el modelo más pequeño de la línea IBM FlashSystem 5000, que en el momento de la compra se conocía como Storwize V5010e. Ahora se vende bajo el nombre de FlashSystem 5010, pero en realidad es la misma base de hardware con el mismo Spectrum Virtualize en su interior.
La existencia de un sistema de gestión unificado es, por cierto, la principal diferencia del IBM FlashSystem. En los modelos de la serie más baja, es prácticamente indistinguible de los modelos más potentes. La elección de un modelo determinado solo ofrece la base de hardware correspondiente, cuyas características permiten utilizar ciertas funcionalidades o garantizar un mayor nivel de escalabilidad. El software, en este caso, identifica la parte de hardware y proporciona la funcionalidad necesaria y suficiente para esta plataforma.
IBM FlashSystem 5010
Breve resumen sobre nuestro modelo 5010. Es un sistema de almacenamiento de bloques de nivel de entrada con dos controladores. Puede albergar discos NLSAS, SAS y SSD. No es posible el uso de NVMe en este modelo de almacenamiento, ya que está diseñado para tareas que no requieren el rendimiento de los discos NVMe.
El almacenamiento fue adquirido para albergar información de archivo o datos a los que no se accede con frecuencia. Por lo tanto, nos bastó con el conjunto estándar de funcionalidades: tiering (Easy Tier), Thin Provision. El rendimiento en los discos NLSAS, de entre 1000 y 2000 IOPS, también nos satisfacía.
Nuestra experiencia: cómo no actualizamos el firmware a tiempo
Ahora, sobre la actualización del software. En el momento de la compra, el sistema contaba con una versión ligeramente desactualizada del software Spectrum Virtualize, a saber, 8.2.1.3.
Estudiamos la descripción de los firmwares y planeamos la actualización a 8.2.1.9. Si hubiéramos sido un poco más ágiles, este artículo no existiría: en un firmware más reciente no habría ocurrido el error. Sin embargo, por razones específicas, la actualización de este sistema se pospuso.
Como resultado, un pequeño retraso en la actualización provocó una situación extremadamente desagradable, como se describe en el enlace: .
Sí, en esa versión del firmware estaba vigente el llamado APAR (Authorized Program Analysis Report) HU02104. Se manifiesta de la siguiente manera. Bajo carga, en ciertas circunstancias, comienza a desbordarse la caché, y luego el sistema entra en modo de protección, en el que desactiva la entrada/salida del pool. En nuestro caso, se vio como la desactivación de 3 discos para un grupo RAID en modo RAID 6. La desactivación dura 6 minutos. Luego, el acceso a los volúmenes en el pool se restaura.
Si alguien no está familiarizado con la estructura y la nomenclatura de las entidades lógicas en el contexto de IBM Spectrum Virtualize, ahora explicaré brevemente.
Estructura de elementos lógicos de almacenamiento
Los discos se agrupan en conjuntos denominados MDisk (Disco Gestionado). MDisk puede representar un RAID clásico (0,1,10,5,6) o uno virtualizado: DRAID (RAID Distribuido). El uso de DRAID permite aumentar el rendimiento del arreglo, ya que se utilizarán todos los discos del grupo y disminuir el tiempo de reconstrucción, gracias a que solo se necesitará restaurar bloques específicos y no todos los datos del disco que falló.
Distribución de bloques de datos en discos al utilizar RAID Distribuido (DRAID) en modo RAID-5.
Este esquema muestra la lógica de reconstrucción de DRAID en caso de que falle un disco:
Lógica de reconstrucción de DRAID al fallar un disco
A continuación, uno o varios MDisk forman lo que se llama un Pool. Dentro de un mismo pool no se recomienda utilizar MDisk con diferentes niveles de RAID/DRAID en discos del mismo tipo. No vamos a profundizar mucho en esto, ya que planeamos abordarlo en uno de los próximos artículos. Y, por supuesto, el Pool se divide en Volúmenes, que se presentan a través de uno u otro protocolo de acceso por bloques hacia los hosts.
Así que, como resultado de la situación descrita en APAR HU02104, debido a la falla lógica de tres discos, el MDisk dejó de ser operativo, lo que a su vez provocó la falla del Pool y de los Volúmenes correspondientes.
Dado que estos sistemas son bastante "inteligentes", se pueden conectar al sistema de monitoreo en la nube IBM Storage Insights, que automáticamente, al ocurrir una falla, envía una solicitud de servicio al soporte de IBM. Se crea un ticket y los especialistas de IBM realizan el diagnóstico de manera remota y se comunican con el usuario del sistema.
Gracias a esto, el asunto se resolvió de manera bastante rápida y se recibió una recomendación oportuna del soporte para actualizar nuestro sistema a la versión de firmware 8.2.1.9 que previamente habíamos elegido, en la que este problema ya había sido corregido. Esto es confirmado por .
Conclusiones y nuestras recomendaciones
Como se dice: «lo bueno es lo que termina bien». El error en el firmware no resultó en problemas graves: el funcionamiento de los servidores se restauró en el menor tiempo posible y sin pérdida de datos. Algunos clientes tuvieron que reiniciar sus máquinas virtuales, pero en general estábamos preparados para consecuencias más negativas, ya que diariamente hacemos copias de seguridad de todos los elementos de la infraestructura y de las máquinas de los clientes.
Hemos recibido confirmación de que incluso los sistemas confiables con un 99,9999% de disponibilidad garantizada requieren atención y mantenimiento oportuno. A partir de la situación, hemos sacado varias conclusiones y compartimos nuestras recomendaciones:
Es fundamental estar al tanto de las actualizaciones, estudiar las Notas de la Versión en busca de correcciones de puntos potencialmente críticos y realizar actualizaciones programadas de manera oportuna.
Este es un aspecto organizacional y, de hecho, bastante obvio, que a simple vista no debería ser un problema. Sin embargo, en este «terreno llano» es bastante fácil tropezar. De hecho, fue este aspecto el que causó los problemas descritos anteriormente. Presta mucha atención a la elaboración del reglamento de actualizaciones y asegúrate de cumplirlo con igual esmero. Este punto se relaciona más con el concepto de «disciplina».
Siempre es mejor mantener el sistema con la versión actual del software. Y por «actual», no nos referimos a la que tiene un número mayor, sino a la que ha sido lanzada más recientemente.
Por ejemplo, IBM mantiene al día al menos dos versiones de software para sus sistemas de almacenamiento de datos. En el momento de escribir este artículo, son la 8.2 y la 8.3. Las actualizaciones para la 8.2 se lanzan primero. Luego, con un pequeño retraso, generalmente aparece la actualización correspondiente para la 8.3.
La versión 8.3 tiene varias ventajas funcionales, como la capacidad de expandir MDisk (en modo DRAID) añadiendo uno o más discos nuevos (esta posibilidad se introdujo a partir de la versión 8.3.1). Es una funcionalidad bastante básica, pero en la 8.2, lamentablemente, no existe tal opción.
Si por alguna razón no es posible realizar una actualización, para las versiones del software Spectrum Virtualize anteriores a las versiones 8.2.1.9 y 8.3.1.0 (donde el error mencionado anteriormente es relevante), para reducir el riesgo de su aparición, el soporte técnico de IBM recomienda limitar el rendimiento del sistema al nivel del grupo, como se muestra en la imagen a continuación (la captura fue tomada en la versión en español de la GUI). El valor de 10000 IOPS se muestra como ejemplo y se ajusta según las características de su sistema.
Limitación del rendimiento del almacenamiento IBM
Es necesario calcular correctamente la carga en los sistemas de almacenamiento y evitar la sobrecarga. Para ello, se puede utilizar el tamaño de IBM (si se tiene acceso) o la ayuda de socios, o recursos externos. Es importante entender el perfil de carga en el sistema de almacenamiento, ya que el rendimiento en MB/s e IOPS varía considerablemente según al menos los siguientes parámetros:
tipo de operación: lectura o escritura,
tamaño del bloque de operación,
proporción de operaciones de lectura y escritura en el flujo general de entrada/salida.
Además, la velocidad de ejecución de las operaciones se ve afectada por cómo se leen los bloques de datos: de manera secuencial o aleatoria. Al realizar múltiples operaciones de acceso a datos en el lado de la aplicación, existe el concepto de operaciones dependientes. Esto también se debe tener en cuenta. Todo esto puede ayudar a visualizar la suma de datos de los contadores de rendimiento del sistema operativo, el sistema de almacenamiento, los servidores/hypervisores, así como comprender las características de funcionamiento de aplicaciones, bases de datos y otros 'consumidores' de recursos de disco.
Y por último, es imprescindible tener copias de seguridad en estado actualizado y operativo. La programación de copias de seguridad debe configurarse según los valores de RPO aceptables para el negocio y se deben verificar periódicamente la integridad de las copias de seguridad (muchos proveedores de software de copias de seguridad han implementado en sus productos una verificación automatizada) para garantizar un valor RTO aceptable.
Gracias por leer hasta el final.
Estamos listos para responder a sus preguntas y comentarios en los comentarios. También, donde realizamos promociones regulares (descuentos en IaaS y sorteos de códigos promocionales de hasta el 100% en VPS), compartimos noticias interesantes y anunciamos nuevos artículos en el blog de Habr.
Fuente: habr.com
