{"id":95870,"date":"2020-10-04T13:41:59","date_gmt":"2020-10-04T11:41:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999"},"modified":"2020-10-04T13:41:59","modified_gmt":"2020-10-04T11:41:59","slug":"pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999","title":{"rendered":"Por qu\u00e9 es importante verificar el software en su sistema de almacenamiento de alta disponibilidad (99,9999%)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Por<\/p>\n

\u00bfCu\u00e1l es la versi\u00f3n del firmware m\u00e1s \u201ccorrecta\u201d y \u201cfuncional\u201d? Si un sistema de almacenamiento garantiza disponibilidad del 99,9999%, \u00bfsignifica eso que funcionar\u00e1 sin interrupciones, incluso sin actualizar el software? \u00bfO, por el contrario, para lograr la m\u00e1xima disponibilidad, es necesario siempre instalar la versi\u00f3n m\u00e1s reciente? Intentaremos responder a estas preguntas bas\u00e1ndonos en nuestra experiencia.<\/p>\n

Una peque\u00f1a introducci\u00f3n<\/h3>\n

Todos entendemos que cada versi\u00f3n de software, ya sea un sistema operativo o un controlador para alg\u00fan dispositivo, a menudo contiene errores o \u201cparticularidades\u201d que pueden no \u201cmanifiestarse\u201d hasta el final de la vida \u00fatil del equipo, o \u201crevelarse\u201d solo bajo ciertas condiciones. La cantidad y el impacto de tales detalles dependen de la complejidad (funcionalidad) del software y de la calidad de las pruebas realizadas durante su desarrollo. <\/p>\n

A menudo, los usuarios se quedan con la \u201cversi\u00f3n de f\u00e1brica\u201d (el famoso \u2014 \u201csi funciona, no lo toques\u201d) o siempre instalan la versi\u00f3n m\u00e1s reciente (en su entendimiento, la \u00faltima significa la m\u00e1s funcional). Nosotros utilizamos un enfoque diferente: revisamos las notas de la versi\u00f3n de todos los sistemas que usamos. en la nube mClouds<\/a><\/noindex> y elegimos cuidadosamente el firmware adecuado para cada unidad de hardware. <\/p>\n

A esta conclusi\u00f3n llegamos, por as\u00ed decirlo, con experiencia. A partir de nuestra propia explotaci\u00f3n, explicaremos por qu\u00e9 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\u00f3n puede ocurrir con el hardware de cualquier fabricante.<\/p>\n

Selecci\u00f3n de un nuevo sistema de almacenamiento de datos<\/h3>\n

A finales del a\u00f1o pasado, se agreg\u00f3 a nuestra infraestructura un interesante sistema de almacenamiento de datos: el modelo m\u00e1s peque\u00f1o de la l\u00ednea IBM FlashSystem 5000, que en el momento de la adquisici\u00f3n se conoc\u00eda como Storwize V5010e. Ahora se vende bajo el nombre FlashSystem 5010, pero de hecho, es la misma base de hardware con el mismo Spectrum Virtualize en su interior. <\/p>\n

La existencia de un sistema \u00fanico de gesti\u00f3n \u2014 este, por cierto, es el principal diferenciador del IBM FlashSystem. En los modelos de la serie m\u00e1s peque\u00f1a, es pr\u00e1cticamente id\u00e9ntico al de modelos m\u00e1s potentes. La elecci\u00f3n de un modelo espec\u00edfico simplemente proporciona una base de hardware cuyas caracter\u00edsticas permiten utilizar ciertas funcionalidades o garantizar un nivel m\u00e1s alto de escalabilidad. El software, a su vez, identifica la parte de hardware y proporciona las funcionalidades necesarias y suficientes para esta plataforma. <\/p>\n

\"PorIBM FlashSystem 5010<\/p>\n

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\u00e1 dise\u00f1ado para tareas que no requieren el rendimiento de los discos NVMe.<\/p>\n

El almacenamiento fue adquirido para albergar informaci\u00f3n de archivo o datos a los que no se accede con frecuencia. Por lo tanto, nos bast\u00f3 con el conjunto est\u00e1ndar de funcionalidades: tiering (Easy Tier), Thin Provision. El rendimiento en los discos NLSAS, de entre 1000 y 2000 IOPS, tambi\u00e9n nos satisfac\u00eda. <\/p>\n

Nuestra experiencia: c\u00f3mo no actualizamos el firmware a tiempo<\/h3>\n

Ahora, sobre la actualizaci\u00f3n del software. En el momento de la compra, el sistema contaba con una versi\u00f3n ligeramente desactualizada del software Spectrum Virtualize, a saber, 8.2.1.3.<\/strong><\/p>\n

Estudiamos la descripci\u00f3n de los firmwares y planificamos la actualizaci\u00f3n a 8.2.1.9<\/strong>. Si hubi\u00e9ramos sido un poco m\u00e1s \u00e1giles, este art\u00edculo no existir\u00eda: en un firmware m\u00e1s reciente no habr\u00eda ocurrido el error. Sin embargo, por razones espec\u00edficas, la actualizaci\u00f3n de este sistema se pospuso.<\/p>\n

Como resultado, un peque\u00f1o retraso en la actualizaci\u00f3n provoc\u00f3 una situaci\u00f3n extremadamente desagradable, como se describe en el enlace: https:\/\/www.ibm.com\/support\/pages\/node\/6172341<\/u><\/a><\/noindex>. <\/p>\n

S\u00ed, en esa versi\u00f3n 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\u00e9, y luego el sistema entra en modo de protecci\u00f3n, en el que desactiva la entrada\/salida del pool. En nuestro caso, se vio como la desactivaci\u00f3n de 3 discos para un grupo RAID en modo RAID 6. La desactivaci\u00f3n dura 6 minutos. Luego, el acceso a los vol\u00famenes en el pool se restaura.<\/p>\n

Si alguien no est\u00e1 familiarizado con la estructura y la nomenclatura de las entidades l\u00f3gicas en el contexto de IBM Spectrum Virtualize, ahora explicar\u00e9 brevemente.<\/p>\n

\"PorEstructura de elementos l\u00f3gicos de almacenamiento<\/p>\n

Los discos se agrupan en conjuntos denominados MDisk (Disco Gestionado). MDisk puede representar un RAID cl\u00e1sico (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\u00e1n todos los discos del grupo y disminuir el tiempo de reconstrucci\u00f3n, gracias a que solo se necesitar\u00e1 restaurar bloques espec\u00edficos y no todos los datos del disco que fall\u00f3.<\/p>\n

\"PorDistribuci\u00f3n de bloques de datos en discos al utilizar RAID Distribuido (DRAID) en modo RAID-5.<\/p>\n

Este esquema muestra la l\u00f3gica de reconstrucci\u00f3n de DRAID en caso de que falle un disco:<\/p>\n

\"PorL\u00f3gica de reconstrucci\u00f3n de DRAID al fallar un disco<\/p>\n

A continuaci\u00f3n, 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\u00f3ximos art\u00edculos. Y, por supuesto, el Pool se divide en Vol\u00famenes, que se presentan a trav\u00e9s de uno u otro protocolo de acceso por bloques hacia los hosts.<\/p>\n

As\u00ed que, como resultado de la situaci\u00f3n descrita en APAR HU02104<\/em>, debido a la falla l\u00f3gica de tres discos, el MDisk dej\u00f3 de ser operativo, lo que a su vez provoc\u00f3 la falla del Pool y de los Vol\u00famenes correspondientes.<\/p>\n

Dado que estos sistemas son bastante \"inteligentes\", se pueden conectar al sistema de monitoreo en la nube IBM Storage Insights, que autom\u00e1ticamente, al ocurrir una falla, env\u00eda una solicitud de servicio al soporte de IBM. Se crea un ticket y los especialistas de IBM realizan el diagn\u00f3stico de manera remota y se comunican con el usuario del sistema. <\/p>\n

Gracias a esto, el asunto se resolvi\u00f3 de manera bastante r\u00e1pida y se recibi\u00f3 una recomendaci\u00f3n oportuna del soporte para actualizar nuestro sistema a la versi\u00f3n de firmware 8.2.1.9 que previamente hab\u00edamos elegido, en la que este problema ya hab\u00eda sido corregido. Esto es confirmado por la correspondiente Nota de Lanzamiento<\/u><\/a><\/noindex>.<\/u><\/p>\n

Conclusiones y nuestras recomendaciones<\/h3>\n

Como se dice: \u00ablo que bien acaba, bien est\u00e1\u00bb. El error en el firmware no result\u00f3 en problemas graves: el funcionamiento de los servidores se restableci\u00f3 en el menor tiempo posible y sin p\u00e9rdida de datos. Algunos clientes tuvieron que reiniciar m\u00e1quinas virtuales, pero en general est\u00e1bamos listos para consecuencias m\u00e1s negativas, ya que diariamente hacemos copias de seguridad de todos los elementos de la infraestructura y de las m\u00e1quinas de los clientes. <\/p>\n

Hemos recibido confirmaci\u00f3n de que incluso los sistemas confiables con un 99,9999% de disponibilidad garantizada requieren atenci\u00f3n y mantenimiento oportuno. A partir de la situaci\u00f3n, hemos sacado varias conclusiones y compartimos nuestras recomendaciones:<\/p>\n