El hospital de la isla caribeña se reconstruye después del huracán con DataCore


La noche del 5 de septiembre de 2017 fue una noche para recordar para la isla caribeña de San Martín. Devastado por el huracán Irma, el único hospital en la parte administrada por Francia de la isla tuvo su techo arrancado y servidores, dispositivos de almacenamiento y respaldo empapados en lluvia y agua de mar.

Afortunadamente, el hospital tenía una segunda sala de servidores que replicaba la infraestructura primaria para garantizar que las actividades pudieran continuar si ocurriera un desastre. Sin embargo, el gran problema era que tomaría un año reconstruir la infraestructura destruida y volver al funcionamiento normal de TI.

¿Porque tan largo? Porque los productos equivalentes a los instalados habían evolucionado significativamente. Los que habían sido desplegados ya no estaban disponibles y la capacidad de sincronizar los dos sitios no estaba garantizada. En última instancia, la respuesta se encuentra en el almacenamiento definido por software, que permitió unir el hardware dispares.

“Tener dos salas de servidores en modo activo-activo ha sido un requisito del gobierno desde 2013 en el marco de registros electrónicos de pacientes “, dijo Jean-François Desrumaux, jefe de proyectos de TI en el Centro Hospitalario de Saint Martin.

“Entonces, como solo teníamos uno, todo el desarrollo del centro de datos se congeló. Mantuvimos las aplicaciones médicas y administrativas que teníamos, pero no pudimos arriesgarnos a instalar nuevas porque no podríamos cambiarnos a una infraestructura de respaldo en caso de algún problema “.

Finalmente, el equipo de Desrumaux restauró el suministro activo-activo del hospital mediante el despliegue DataCoreLa infraestructura de almacenamiento virtual SANsymphony.

Matrices de almacenamiento activo-activo

Volviendo a 2014, la infraestructura de TI en el Centro Hospitalario de Saint Martin comprendía una red central de 10 Gbps que distribuía cargas de trabajo de aplicaciones entre dos salas de servidores idénticas. En cada uno de estos había dos servidores VMware ESXi construidos en hardware IBM x3650M4, con ocho núcleos de Xeon 2.4GHz E5, 128 GB de RAM, dos unidades flash de 128 GB y dos puertos Fibre Channel de 8 Gbps.

Cada uno de estos puertos estaba conectado a uno de los dos conmutadores Fibre Channel que compartían conexiones a un IBM StorWize La matriz V3700, que ofrecía 10 TB de capacidad de almacenamiento, y el almacenamiento definido por software DataCore SANsymphony que se implementó en un IBM x3250M4. Este último funcionaba para servir volúmenes de almacenamiento a los dos servidores ESXi.

Entre las dos salas de servidores, redundancia fue asegurado en dos niveles.

En primer lugar, estaban los servidores virtuales que operaban bajo vSphere HA y DRSy que se comunicaron a través de la red Ethernet de 10 Gbps para garantizar que ejecutaran el mismo conjunto de máquinas virtuales (VM).

En segundo lugar, una conexión de canal de fibra dedicada entre las dos salas permitió que las dos matrices StorWize sincronizaran sus contenidos en tiempo real utilizando IBM Global Mirror.

Entonces, aunque había 20 TB en las dos habitaciones, se dividió en 10 TB en cada una.

A todo esto se agregó un sistema de respaldo en una sola habitación. Software de copia de seguridad de Dataclone (de Matrix) se ocupó del contenido de las máquinas virtuales con un NAS de 6 TB como objetivo, también de Matrix. Desafortunadamente, esto residía en la habitación destruida por el huracán.

Los servidores de IBM se reinician después de la inundación

Aproximadamente al final del tercer día después de que pasó el huracán, se restableció la electricidad y el equipo de Desrumaux volvió a encender el sistema de TI.

Debido a que la segunda sala de servidores ya no existía, se tomó la decisión de aumentar la memoria en los dos servidores ESXi guardados a 384 GB.

“Triplicar la cantidad de RAM nos pareció una solución satisfactoria para mantener el funcionamiento fluido de las aplicaciones”, dijo Desrumaux. “Significaba que no necesitábamos aumentar la potencia de procesamiento”.

Dado que estos dos servidores son los únicos que mantienen las aplicaciones en funcionamiento, el jefe del proyecto de TI no estaba dispuesto a molestarlos. Por lo tanto, no se trataba de eliminarlos para reemplazarlos con hardware de mejor rendimiento si eso significaba semanas sin disponibilidad.

Mientras tanto, se reiniciaron los dos servidores que tomaron un empapado.

“No se trataba de volver a ponerlos en producción para ejecutar aplicaciones, porque no podíamos estar seguros de su fiabilidad”, dijo Desrumaux. “Debido a que no teníamos ninguna redundancia, tuvimos la idea de brindar una protección mínima, colocar estos dos servidores en una habitación y usarlos como equipo de recuperación ante desastres de emergencia”.

“Entonces, les dimos a cada uno 5 TB de disco de los arreglos de almacenamiento y activamos la replicación, diariamente y asincrónico – para proteger el contenido de los servidores de producción ESXi “.

DataCore se conecta a través de matrices

Reemplazar el dispositivo Matrix en la sala de servidores reconstruida no representaba un problema porque funcionaba de manera relativamente independiente del resto de la infraestructura.

El desafío vino en la adquisición de infraestructura que podría sincronizarse entre las dos salas. Eso fue en 2017 y los productos propuestos por IBM eran muy diferentes de los que se habían implementado en 2014.

Por ejemplo, las matrices StorWize ahora se designaron V3700v2 con unidades SAS de 12 Gbps y tenían una nueva OS, mientras que los que estaban en producción en el hospital tenían unidades de 6 Gbps.

Por lo tanto, se llegó a la idea de efectuar la sincronización entre las dos matrices de discos al nivel del almacenamiento definido por software DataCore SANsymphony. Esto proporcionó la capacidad de agrupar la capacidad de diferentes matrices y presentarla como un único volumen lógico a los servidores.

SANsymphony presenta un único volumen de 10 TB a los servidores, con 20 TB planeados, porque Desrumaux planea duplicar la capacidad de almacenamiento para admitir nuevas aplicaciones.

La validación de esta configuración duró de diciembre de 2017 a noviembre de 2018. La dificultad adicional para resolver fue que la futura segunda sala de servidores todavía tenía su propio servidor SANsymphony. Esto presentaba un problema similar al de las matrices de almacenamiento. Es decir, la máquina física en la que se ejecutaba estaba construida con hardware diferente, un Lenovo x3250M6, que IBM comenzó a revender a su socio chino a fines de 2014.

Operacional en un día

Una vez que se realizaron las pruebas y se calibraron las configuraciones, el despliegue de la nueva sala del segundo servidor tomó solo un día. Ese fue el tiempo necesario para que el primer servidor SANsymphony replicara 8TB al nuevo sistema de almacenamiento.

Desde el punto de vista administrativo, hubiera sido suficiente redefinir las conexiones entre todos los servidores y matrices de discos en las dos salas. Para simplificar las cosas, los 10 TB adicionales se configuraron como un nuevo LUN. Todas las máquinas virtuales de las aplicaciones de noticias se configuraron desde la interfaz ESXi.

Y así, desde diciembre de 2018, el Centro Hospitalario de Saint Martin se ha beneficiado de dos salas de servidores en modo activo-activo y no se ha producido ningún problema técnico importante. Desrumaux no planea otra actualización importante antes de 2022.

Deberías leer:   Poco X2 comienza a recibir la actualización global estable de ROM MIUI 12 en India, informe de usuarios