NetApp Tech OnTap
     

Caso práctico: Disponibilidad continua de datos

Combinación de MetroCluster y V-Series de NetApp

Hay ciertas aplicaciones para las que la disponibilidad es de vital importancia. Para los proveedores de energía del suroeste de Estados Unidos, algunas aplicaciones esenciales son necesarias para lograr una disponibilidad del 99,999% (o aún mayor). En realidad, las normativas le exigen a mi empresa y a otras que, una semana cada trimestre, activen aplicaciones de energía esenciales desde una instalación secundaria para demostrar que las funcionalidades de recuperación ante desastres funcionan correctamente.

Cuatro meses antes de que implementáramos la solución MetroCluster de NetApp® que se describe en este artículo, sufrimos un incidente que provocó que nuestra aplicación esencial estuviera inactiva durante más de dos horas y que perdiera datos equivalentes a cuatro horas: una auténtica pesadilla. Teníamos que hacer un cambio y hacerlo rápido.

En este artículo, voy a describir el tratamiento de nuestros problemas de disponibilidad realizado por una combinación de MetroCluster y los sistemas de virtualización V-Series de NetApp a la vez que nos permitía conservar nuestra inversión existente en Hitachi Storage. Incluiré detalles de nuestra implementación y analizaré las diferentes lecciones que hemos aprendido desde que implementamos la solución NetApp.

En un artículo que se publicará más adelante, describiré nuestra manera de utilizar NetApp y NFS para que dé soporte a nuestro variado entorno de virtualización de servidores, que incluye tanto VMware® como Oracle® VM. Hace veinte meses, no contábamos con ningún almacenamiento NetApp. Ahora, hemos crecido hasta alcanzar casi medio petabyte de almacenamiento NetApp, y nuestro crecimiento no parece tener fin.

¿Por qué elegir MetroCluster y V-Series de NetApp?

Durante los cinco años que precedieron a la implementación de MetroCluster, nuestra aplicación esencial se ejecutaba en un servidor Windows® que se asentaba en una red segura. La aplicación funciona realizando el procesamiento por lotes contrastándolo con una base de datos y, a continuación, escribiendo los ficheros de salida en un almacenamiento local. Acto seguido, los usuarios de la aplicación tienen acceso a los archivos de salida.

Se utilizaba el software Double-Take para replicar periódicamente una imagen de ese servidor en otra instalación. En el mejor de los casos, una recuperación de Double-Take no era realmente capaz de cumplir nuestros objetivos de disponibilidad del 99,999%. Cuando se produjo el fallo mencionado anteriormente, hubo un problema con la ronda de replicación más reciente, lo que hizo que se produjera un tiempo de inactividad más largo de lo esperado que comportó una pérdida de datos importante.

Lo que nuestro cliente interno quería hacer era implementar una solución en la que se dispusiera de servidores de aplicación ejecutados sobre WebLogic en una configuración dual con un servidor de aplicaciones en la instalación A y un segundo servidor de aplicaciones en la instalación B, a unos 30 kilómetros de distancia. Un equilibrador de carga situado delante de ellos, se encargaría, a continuación, de propagar la carga de trabajo en ambos servidores en circunstancias normales. (Contamos con un enlace WAN rápido entre ambas ubicaciones, por lo que no supondría un problema en los casos en los que las solicitudes van del servidor en la instalación A al de la instalación B, o viceversa.)

Para que esto funcione correctamente, los archivos de salida tendrían, a continuación, que escribirse en un volumen compartido al que puedan acceder ambos servidores. Disponíamos de unos 15 TB de almacenamiento Hitachi SAN disponibles dentro de este entorno de aplicación aislado y seguro, pero Hitachi no tenía una solución realmente viable para satisfacer nuestras necesidades de disponibilidad, por lo que empezamos a interesarnos por las puertas de enlace NAS.

Hacía poco que habíamos implementado un NetApp FAS3070 con recursos compartidos CIFS y estábamos contentos con el resultado, así que nos pusimos en contacto con NetApp para ver si podían ofrecernos un recurso compartido CIFS de alta disponibilidad. En última instancia, NetApp nos ayudó a decantarnos por una solución que utiliza dos sistemas de virtualización V-Series de NetApp (uno en cada instalación) con la interfaz de nuestro almacenamiento Hitachi existente con el objeto de conservar esa inversión en disco. MetroCluster de NetApp ofrecía un mirroring síncrono entre los dos sistemas V-Series, lo que permitía que los mismos recursos compartidos CIFS estuvieran accesibles en ambas ubicaciones sin retrasos, y que la recuperación se hiciera de forma instantánea y sin pérdida alguna de datos en caso de producirse un problema.

Estuvimos analizando un amplio abanico de tecnologías ofrecidas por otros distribuidores (algunos de los cuales ofrecían menores costes iniciales), pero la complejidad de administración y gestión que exigían esas soluciones, habría hecho que se dispararan los costes acumulables.

Detalles de la implementación

En la figura 1 se muestra una descripción detallada de nuestro entorno MetroCluster.

Figura 1) Descripción de la implementación MetroCluster/V-Series.

Como se puede ver, casi todo es redundante (incluidos los enlaces Fibre Channel entre las instalaciones) para garantizar la mayor disponibilidad posible. MetroCluster en los nodos V3020 de NetApp crea una réplica exacta de todos los volúmenes compartidos en ambas instalaciones. En la actualidad tenemos tres recursos compartidos diferentes: uno para la producción, otro para el desarrollo y un tercero para la realización de pruebas.

Los sistemas de V-Series permiten utilizar todas las funciones de NetApp (incluido MetroCluster) con nuestro almacenamiento existente. Nuestros sistemas de almacenamiento Hitachi ya estaban suministrando almacenamiento para un componente de base de datos de la aplicación. Como este entorno se encuentra aislado del resto de nuestras operaciones, no pudimos aprovechar el almacenamiento no utilizado en los dos sistemas Hitachi (15 TB de espacio libre en cada uno) para otros usos, por lo que lo mejor era utilizarlo para guardar estos recursos compartidos CIFS (1,5 TB) en lugar de comprar almacenamiento NetApp.

Pruebas iniciales

Para probar la configuración antes de iniciar la etapa de producción, simulamos una amplia variedad de fallos: quitar el cable en un nodo de almacenamiento, interrumpir las conexiones de red y de Fibre Channel, desactivar uno de los dos directores Cisco, entre otros. El funcionamiento de la recuperación fue inmediato y correcto en todos los casos. También probamos las funciones manuales de recuperación para hacer que la instalación B fuera la primaria (en lugar de la A). Como hemos apuntado anteriormente, tenemos que realizar este cambio al menos una vez al trimestre. No encontramos ni un solo problema durante el curso de las pruebas. Todo funcionó según lo esperado y sin problemas.

Resultados obtenidos

Desde que instalamos la configuración de MetroCluster no hemos tenido ningún problema. Las conexiones de Fibre Channel entre las instalaciones se han desactivado en alguna ocasión debido a tareas de mantenimiento programadas, y MetroCluster siempre se vuelve a sincronizar sin necesidad de intervenir. Recibimos un correo electrónico de MetroCluster en el que se explica que la conexión se ha desactivado. Cuando vuelve a estar activa, nos mandan una segunda notificación con la confirmación de activación y con el aviso de que MetroCluster se está sincronizando de nuevo.

Además de admitir MetroCluster, los sistemas V-Series nos permiten sacar partido del resto de funciones de NetApp (como Snapshot™) en nuestro almacenamiento de disco Hitachi. La estrategia de backup y recuperación implementada en toda nuestra infraestructura de TI (no sólo MetroCluster) es pasar de backups en cinta a backups online. Para ello, solemos crear copias Snapshot de nuestros recursos compartidos MetroCluster. Gracias al mirroring síncrono disponemos de copias Snapshot en ambas instalaciones en caso de que fuera necesario recuperar algún dato después de producirse un fallo. Aparte de la configuración de MetroCluster, utilizamos SnapMirror® para ofrecer una funcionalidad parecida de backup y recuperación ante desastres para aplicaciones menos esenciales, donde es adecuado aplicar la replicación asíncrona.

Lecciones aprendidas

El único problema de verdad que tuvimos durante la instalación de MetroCluster se debió al hecho de que, desde el principio, no acabábamos de comprender las conexiones de Fibre Channel existentes entre las dos instalaciones. Habíamos “heredado” estas redes y no disponíamos de los datos exactos sobre la configuración. Terminamos teniendo que aprender sobre la marcha cómo estaba configurada la red, por lo que perdimos un tiempo muy valioso.

Mi recomendación para cualquiera que tenga intención de implementar MetroCluster es que realice de antemano una evaluación completa con NetApp para resolver los pormenores y para validar la configuración. Algunos de los datos iniciales que suministramos a NetApp no eran del todo correctos, lo que originó retrasos en la implementación. En mi opinión, un acuerdo con los servicios profesionales de preventa habría facilitado en gran medida la implementación y, visto en retrospectiva, habría sido un dinero bien invertido.

Conclusión

La tecnología de NetApp nos ha permitido llevar toda nuestra infraestructura de TI en una dirección que ha resultado ser muy productiva para toda la empresa. A día de hoy, una sola persona, que trabaja a jornada completa, gestiona la totalidad de los 480 TB de almacenamiento NetApp. Los contratos de mantenimiento del almacenamiento Hitachi en la configuración de MetroCluster están próximos a su renovación. Estamos gestionando la sustitución de esos costosos sistemas por dos clusters de NetApp adicionales con el objeto de suministrar almacenamiento para la gestión de la base de datos de la aplicación. Añadiremos bandejas de disco a nuestro cluster V-Series ya existente para ofrecer almacenamiento a los recursos compartidos CIFS que duplicamos con MetroCluster.

También nos plantearemos la posibilidad de implementar la deduplicación en nuestros recursos compartidos de MetroCluster. Utilizamos la deduplicación en el resto de nuestro entorno, lo que nos proporciona un ahorro de hasta el 90% en entornos de virtualización del servidor, del 35% en recursos compartidos CIFS que no son de MetroCluster y de entre el 60% y el 65% en recursos compartidos NFS. Huelga decir que, cuando se duplican los datos, la reducción de la cantidad total de datos que hay que almacenar puede producir un enorme ahorro en el almacenamiento, por no mencionar el ahorro en la banda ancha necesaria para duplicar dichos datos entre las distintas instalaciones.

También nos planteamos la posibilidad, a largo plazo, de añadir una tercera instalación de recuperación ante desastres a una distancia mínima de 240 kilómetros. Con esta configuración, MetroCluster ofrecería una disponibilidad de datos constante y dispondríamos también de una tercera copia SnapMirror de los datos en una tercera instalación, que proporcionaría una recuperación ante desastres total en caso de que las operaciones de nuestras instalaciones principal y secundaria se vieran afectadas por un desastre regional. Se trata de un método acorde con las prácticas recomendadas de NetApp para aplicaciones esenciales.

¿Qué opina sobre MetroCluster?

Formule preguntas, intercambie ideas y comparta sus opiniones en las comunidades online de NetApp.

Joshua Konkle

Dave Larson
Supervisor de arquitectura de infraestructuras

Antes de incorporarse a su actual empresa hace siete años, Dave trabajó en diferentes puestos relacionados con TI en Digital Equipment Corporation y en otras empresas, y consiguió una amplia experiencia en almacenamiento con productos de proveedores líderes, como EMC, Hitachi y HP StorageWorks. En su puesto actual, se encarga de la gestión de los equipos SAN, UNIX® y Oracle Database de su empresa, lo que le proporciona una perspectiva única y amplia sobre los retos de la infraestructura de TI.

 
En profundidad