NetApp Tech OnTap
     

Mesa redonda: Recuperación ante desastres para aplicaciones de Microsoft con VMware SRM y NetApp

En la publicación de Tech OnTap de febrero de 2010 se presentaba un artículo sobre la virtualización de aplicaciones de Microsoft con tecnologías VMware®, NetApp® y Cisco. Como seguimiento a este artículo, Tech OnTap se reunió con Wen Yu, de VMware, y Larry Touchette, de NetApp, para profundizar en los detalles de la recuperación ante desastres para aplicaciones de Microsoft® y descubrir por qué tiene un índice de adopción superior en entornos VMware o NetApp.

Tech OnTap: Parece que muchos se muestran reticentes a utilizar la recuperación ante desastres online de forma generalizada en entornos de aplicaciones de Microsoft. ¿Qué factores contribuyen a ello?


Wen Yu (VMware): En VMware, creemos que en general se debe a tres motivos fundamentales. En primer lugar y, quizás el más importante, al coste que implica la recuperación antes desastres. No sólo es necesario disponer de una segunda instalación, sino que también se necesitan servidores adicionales, otra infraestructura de red y el doble de almacenamiento. Estos costes pueden resultar prohibitivos independientemente del uso de servidores físicos o virtuales.

En segundo lugar, tradicionalmente ha existido un alto grado de complejidad asociado a la ejecución de tareas de recuperación ante desastres, en especial en entornos de servidores físicos que se incrementa a la hora de implementar la recuperación ante desastres en varias aplicaciones. Al final, acabará con una combinación confusa de productos y tecnologías necesarias para hacer el trabajo. Además, hay una gran cantidad de productos que necesitan una configuración idéntica en ambos lados, lo que contribuye al aumento del coste.

Por último, el ancho de banda de red necesario para lograr un objetivo de punto de recuperación puede suponer una limitación para muchos usuarios. Es posible que gran parte de los departamentos que usan Windows® no dispongan del ancho de banda necesario para llevar a cabo la replicación y que duden en invertir en ello para hacerla factible.

La solución conjunta que NetApp, Cisco y VMware han creado resuelve gran parte de estos problemas.

Larry Touchette (NetApp): Para ampliar la última cuestión que plantea Wen, NetApp y VMware han eliminado gran parte del coste y la complejidad de la recuperación ante desastres, para que el usuario pueda implementar una solución que cubre un mayor número de aplicaciones, incluso a la totalidad del entorno VMware si lo desea. Algunos clientes comunes han sido capaces de compensar o incluso financiar por completo el almacenamiento de un entorno de recuperación ante desastres con el dinero que se ahorran al utilizar la deduplicación de NetApp en el almacenamiento de VMware primario. Cualquiera lector habitual de Tech OnTap conoce las ventajas de la deduplicación de NetApp en combinación con VMware. [Nota del editor de TOT: este artículo es un excelente punto de partida para obtener más información sobre la deduplicación y la recuperación ante desastres de VMware.]

En relación al ahorro en ancho de banda, si la tecnología SnapMirror® de NetApp se utiliza en combinación con la deduplicación de NetApp, sólo replica bloques únicos, por lo que consigue un aprovechamiento muy eficiente del ancho de banda. NetApp ha agregado recientemente la funcionalidad de compresión de SnapMirror a Data ONTAP® para la aceleración de WAN. De este modo, se optimiza aún más su funcionamiento en entornos con ancho de banda limitado, con lo que se obtiene una reducción del uso del ancho de banda de hasta el 70% en función de la compresión de los datos. [Nota del editor de TOT: Un artículo reciente de Tech OnTap analizó en detalle la compresión de SnapMirror. ]

La adopción de la recuperación ante desastres en entornos VMware/NetApp conjuntos es muy alta, y creo que la causa es la unión de estos factores.

TOT: ¿Por qué se utiliza VMware Site Recovery Manager (SRM) en una configuración de recuperación ante desastres de VMware/NetApp?


Wen: La parte fundamental de la recuperación ante desastres para servidores de aplicaciones virtualizados es la ejecución de los pasos necesarios para conectar los equipos virtuales, realizar el inventario correspondiente, volver a configurarlos y activarlos en su centro de recuperación ante desastres. La ejecución manual de estas tareas puede resultar complicada y ser propensa a errores, especialmente si existen dependencias que requieren establecer prioridades a la hora de iniciar un equipo virtual antes que otro. Se pueden escribir secuencias de comandos para intentar automatizar los procesos de recuperación ante desastres y solucionar estos problemas, aunque sean difíciles de implantar y mantener.

Site Recovery Manager simplifica la gestión del proceso de recuperación ante desastres, incluidas la identificación, la configuración, la recuperación tras fallos y la prueba de recuperación ante desastres. El plan de recuperación que cree durante la fase de configuración de SRM le permitirá preconfigurar el plan entero. La funcionalidad de identificación integrada y la estrecha integración con vCenter aceleran el proceso.

Una vez creado el plan, se puede ejecutar automáticamente con una intervención mínima del usuario. SRM permite realizar todos los pasos necesarios e iniciar los equipos virtuales en el orden correcto. Por ejemplo, los equipos virtuales que admiten infraestructuras como Active Directory® (AD) y los servidores DNS se pueden iniciar primero, seguidos de los servidores de bases de datos, los de aplicaciones y los Web.

La capacidad para realizar pruebas supone otra enorme ventaja. Con la mayoría de las soluciones de recuperación ante desastres es casi imposible realizar pruebas sin interferir en las operaciones de producción y replicación continua habituales. SRM y NetApp convierten la prueba de recuperación ante desastres en una operación sencilla y eficiente. Por ejemplo, tendrá que crear una red de pruebas aislada para no tener, accidentalmente, dos instancias activas de cada equipo virtual de la red empresarial. SRM automatiza el proceso de forma que las pruebas permanezcan aisladas.

Larry: Si utiliza la tecnología FlexClone® de NetApp en combinación con pruebas de recuperación ante desastres de SRM, puede usar su centro de recuperación ante desastres y realizar pruebas en él sin necesidad de consumir una gran cantidad de almacenamiento adicional y sin interferir en la replicación continua entre sites ni en las operaciones que se realizan en el centro primario. Esto supone un modo sencillo de ejecutar pruebas para validar la recuperación ante desastres sin que se resientan el centro de producción o los acuerdos de nivel de servicio aprobados.

Algunas soluciones de replicación requieren el doble de funcionalidad para poder crear las réplicas de almacenamiento en el site de recuperación ante desastres y permitir que la replicación pueda continuar mientras el usuario realiza la prueba. Esto conlleva un desaprovechamiento y una reducción del tiempo que puede mantener activo el entorno de pruebas o de la frecuencia con que se realizan las pruebas. El uso de FlexClone reduce de manera significativa la cantidad de espacio necesario y acelera el proceso.

 

Requisito de almacenamiento incremental para pruebas de recuperación ante desastres con FlexClone.

Figura 1) Requisito de almacenamiento incremental para pruebas de recuperación ante desastres con FlexClone.

TOT: ¿Cuáles son los factores principales a tener en cuenta al implementar una solución de recuperación ante desastres con VMware SRM y soluciones de almacenamiento de NetApp?


Wen: Desde el punto de vista de SRM, existen varios factores. En primer lugar, es necesario un servidor VMware vCenter en cada centro, además de un servidor Microsoft SQL para almacenar la base de datos de SRM y de servidores que ejecutan las versiones compatibles de ESX.

Los centros primario y de recuperación deben estar conectados mediante una red IP fiable, además el centro de recuperación debe tener, acceso a las mismas redes públicas y privadas que el primario. Por último, pero no por ello menos importante, el centro de recuperación debe contar con servidores Active Directory y DNS actualizados.

En lo que respecta a la replicación real entre centros, SRM depende de las soluciones de almacenamiento, en este caso de NetApp, para llevarla a cabo. Los clientes que ejecutan aplicaciones de nivel 1 pueden lograr un objetivo de punto de recuperación de tiempo cero mediante la configuración de SnapMirror para replicación sincrónica. Además de la replicación, el mantenimiento de la coherencia en el nivel de SO y de aplicación es crucial.

Larry: NetApp utiliza una serie de componentes que proporcionan una replicación coherente para los propios equipos virtuales y para las aplicaciones de Microsoft (Exchange, SQL Server y SharePoint Server). El factor clave tanto para los equipos virtuales como para las aplicaciones no es tan sólo la replicación periódica de los datos, sino el hecho de que tengan que encontrarse en un estado coherente en todas las aplicaciones desde el que se puedan reiniciar todos los componentes. En un informe técnico reciente, describimos de manera detallada el método completo. Wen revisó este informe para garantizar que teníamos la información correcta de VMware.

Los equipos virtuales residen en almacenes de datos compartidos, ya sean VMFS (FC o LUN iSCSI) o NFS. NetApp SnapManager para infraestructuras virtuales proporciona copias Snapshot™ homogéneas y replicación de datos de equipos virtuales.

Un elemento clave del diseño es que los datos de aplicaciones son independientes de los almacenes de datos de equipos virtuales, ya que se almacenan en LUN RDM en modo físico (iSCSI o FC). Esto nos permite utilizar la suite de productos SnapManager de NetApp para crear puntos de recuperación coherentes para cada aplicación y poder tener diferentes programas de replicación para incorporar diferentes RPO a través de la creación de distintos números de puntos de recuperación.

 

Arquitectura de replicación.

Figura 2) Arquitectura de replicación.

TOT: Hemos trabajado mucho para conseguir tener varios puntos de recuperación desde los que se puedan reiniciar las aplicaciones. ¿Puedes ofrecer a nuestros lectores más datos al respecto?


Larry: Los productos SnapManager de NetApp para SQL Server, Exchange y SharePoint aumentan la flexibilidad, ya que permiten crear y verificar varios puntos de recuperación replicados en el centro de recuperación. Las aplicaciones de SnapManager crean backups completos, que se verifican para garantizar su coherencia entre aplicaciones, además de backups más frecuentes que incluyen únicamente los registros incrementales de los cambios realizados entre backups completos. Estos backups incrementales se denominan puntos de recuperación frecuentes o FRP. El ajuste del tiempo entre backups FRP proporciona flexibilidad para establecer el objetivo del punto de recuperación para cada aplicación de manera independiente.

Si se detecta algún problema con los datos de aplicación recuperados en el centro de recuperación, es posible restaurar aplicaciones individuales a cualquier punto de recuperación anterior. SnapManager puede poner al día cualquier registro de base de datos no comprometido si las aplicaciones se restauran en un punto de recuperación anterior para evitar la pérdida de datos nuevos registrados en el centro de recuperación tras fallos.

SRM permite insertar comandos personalizados en el plan de recuperación. Utilizamos esta funcionalidad para ejecutar un comando en el plan de recuperación que configura SnapDrive® para permitir la ejecución de equipos virtuales en el centro de recuperación ante desastres. De este modo, se puede ver el historial completo de backups replicados desde el centro de producción. Para aquellos que tengan acceso al centro de NetApp NOW™ (NetApp on the Web), este proceso se describe con más detalle en KB56952.

TOT: ¿Puede uno de vosotros explicar la importancia de Active Directory en un entorno SRM?


Wen: Las aplicaciones de Microsoft dependen en gran medida de Active Directory y DNS para su correcto funcionamiento, por lo que es fundamental que esté correctamente configurado en el site de recuperación. Cuando realice la prueba de recuperación ante desastres, se debe asegurar también de que cuenta con un servidor de Active Directory correctamente configurado y actualizado en la red de prueba aislada. Al realizar la recuperación en el centro primario desde el de recuperación, es preciso volver a asegurarse de que los servidores de Active Directory/DNS se gestionan correctamente. En caso contrario, se pueden producir problemas de recuperación del número de secuencias actualizadas (USN) y corrupción de bases de datos de Active Directory. Estos problemas se describen de manera más completa en el artículo 875495 de la base de conocimientos de Microsoft.

El modo más sencillo de asegurarse de que el Active Directory del centro de recuperación es correcto es mantener al menos un servidor de Active Directory en el centro de recuperación sincronizado con el primario.

Para la realización de pruebas de recuperación ante desastres, es preciso clonar este servidor de AD antes de llevar a cabo la prueba. Una vez realizado el clonado, pero antes de encender el equipo virtual, asegúrese de que el servidor de AD clonado esté conectado sólo a la red de prueba de recuperación ante desastres. Cuando se encienda el equipo virtual de AD en la red de prueba, deben aprovecharse cinco funciones FSMO (Flexible Single Master Operation) del bosque de Active Directory según el procedimiento descrito en el artículo 255504 de la base de conocimientos de Microsoft.

Este proceso de clonado no es necesario cuando tiene lugar una recuperación tras fallo real, aunque el aprovechamiento de las funciones FSMO sigue siendo necesario y debe realizarse manualmente. Una vez que se haya completado la recuperación, sea cual sea, y antes de la conmutación por recuperación, tendrá que volver a establecer los servicios de Active Directory en el centro original. Para ello, tendrá que recuperar los servidores AD en el centro y forzarlos a volver a sincronizarce con los servidores AD nuevos del centro de recuperación o estableciendo los servidores AD nuevos.

Todas estas acciones se tratan de manera detallada en NetApp TR-3822, que Larry ha mencionado anteriormente.

TOT: En resumen, ¿podríais hablar de los métodos disponibles para conmutar por recuperación el centro original?


Wen: Tal como acabo de sugerir, el primer paso que hay que dar cuando el centro original está en marcha y en ejecución es poner en marcha Active Directory. SRM todavía no proporciona operaciones de regresión y recuperación, aunque seguimos recomendando que se use para llevar a cabo la conmutación por recuperación cuando el software se vuelve a configurar para que falle en la dirección opuesta.

Larry: La conmutación por recuperación requiere que se sincronicen los datos entre el centro de recuperación y en el original. Es fácil invertir y volver a sincronizar las relaciones de SnapMirror. El proceso de resincronización dependerá en cierta medida del fallo que se haya producido. Si el centro original no ha quedado inservible después del desastre, SnapMirror sólo tendrá que realizar la replicación diferencial, es decir, los cambios ocurridos mientras el centro original estaba sin conexión. De lo contrario, será necesario realizar una nueva sincronización completa. Por supuesto, en cualquier caso la deduplicación de NetApp y la compresión de SnapMirror pueden reducir el impacto en la WAN. La deduplicación reduce la cantidad total de datos en el entorno VMware, ya que elimina la duplicación resultante de tener innumerables copias de los mismos sistemas operativos invitados; por su parte, la compresión asegura que los datos que se transmiten en la WAN utilizan el mínimo ancho de banda posible.

Esperamos que este resumen de la información tratada en la mesa redonda haya sido útil. Nos gustaría recibir sus comentarios acerca de este artículo. Para obtener información detallada y completa sobre los temas tratados, consulte TR-3822.

Centro de la comunidad
 ¿Qué opinas sobre la recuperación ante desastres con SRM y NetApp?

Formula preguntas, intercambia ideas y comparte opiniones en las comunidades online de NetApp.


Wen Yu

Wen Yu
Director Técnico de la Alianza
VMware

Wen forma parte de la plantilla VMware desde hace más de cinco años y ofrece soporte y formación sobre productos de virtualización que proporcionan disponibilidad continua, recuperación ante desastres y puestos de trabajo. Actualmente, es miembro del equipo de tecnología de infraestructura de la alianza.

Larry Touchette

Larry Touchette
Ingeniero Técnico de Marketing
NetApp

Larry trabaja en NetApp desde hace nueve años, donde realiza tares de soporte, implantación y diseño de soluciones de almacenamiento y recuperación ante desastres de NetApp. En la actualidad forma parte del equipo de marketing técnico de virtualización de servidores de NetApp.

 
Saber más