BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Este contenido es parte de Guía Esencial: Guía Esencial: Optimice su proceso de virtualización de TI
Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

¿Es la replicación basada en software mejor para su configuración de DR?

Mantener sus datos a salvo de desastres internamente significa decidir si la replicación basada en hardware o en software es la mejor opción.

La recuperación de desastres y el respaldo dentro de una nueva infraestructura de VMware es, a menudo, la última cosa a tener en cuenta al configurar el entorno. No debería ser así. No hay excusa para que una empresa de cualquier tamaño razonable no lo haga. ¿Cuánto le costarían seis horas de tiempo de inactividad a su empresa? Mucho más que una configuración razonable de DR con certeza.

Hoy en día, con las pilas de virtualización moderna, la capacidad de configurar, ejecutar y utilizar sitios de recuperación de desastres (DR) es sencillo y barato. La conmutación por error y la conmutación por recuperación de sitios enteros se puede hacer con unos pocos clics del mouse. La conmutación por error se ha convertido en una operación trivial en la superficie de la misma con productos como Site Recovery Manager (SRM) de VMware, y ofertas de Zerto y Veeam.

El respaldo y la DR son diferentes bestias, pero ambos son de vital importancia. El respaldo es asegurarse de que usted tiene copias seguras y consistentes de todos los datos críticos fuera de las instalaciones. Estas copias de seguridad se deben verificar con frecuencia con restauraciones de prueba para garantizar la integridad y la disponibilidad de los datos.

La recuperación de desastres, por otro lado, es una opción de conmutación por error bien pensada, probada con frecuencia y siempre disponible. En una configuración de mundo virtual, DR es mucho más fácil de usar de lo que era y mucho menos costosa. Existe una amplia variedad de opciones de DR, pero se dividen en dos tipos generales: la replicación basada en hardware y la replicación basada en software.

Replicación basada en hardware

Los productos de DR basados en hardware, como SRM combinado con LUNs replicados basados ​​en hardware, tratan con replicar LUN enteras en lugar de máquinas virtuales (VM) individuales. Esta vez fue una vez la única manera de hacer la conmutación por error en un entorno VMware. La complejidad de la configuración de SRM requiere una cantidad significativa de configuración y el uso de LUN replicados entre los sitios de producción y DR. Soportar esta tecnología es complejo y costoso. El alto costo viene de necesitar varias licencias para cubrir tanto la SAN como el entorno VMware. Para soportar la infraestructura, se requeriría un administrador muy experimentado, que no solo entiende VMware, sino también la complejidad de la gestión de SAN y la replicación de mapeo en bruto del dispositivo.

El otro problema con los productos de tipo SRM es que carecen de control de grano fino sobre lo que se conmuta. Cuando el LUN se replica en su totalidad, máquinas virtuales no deseadas pueden ser replicadas y VM deseadas se pueden perder si no están en el LUN correcto o si no se replica todo el clúster.

Replicación basada en software

Compare y contraste esto con la replicación basada en software de la talla de Veeam y Zerto. Para ser franco, estas ofertas son mucho más fáciles de usar. Permiten la configuración de forma mucho más granular, lo que significa que puede escoger y elegir una única máquina virtual o un grupo de máquinas virtuales que se habiliten para la conmutación por error, en lugar de todo un LUN. Contrariamente a la replicación basada en hardware, no hay una gestión compleja de matrices de almacenamiento o licencias de replicación requeridos con la replicación basada en software.

La DR basada en software es bastante simple en su diseño e implementación. La mayor parte de las ofertas giran en torno a un estilo de herramientas de gestión de VM estándares, con un agente en cada host y un servidor virtual para controlar el flujo de replicación entre ambos sitios. El servidor de gestión tiene enfrente una interfaz gráfica de usuario que se utiliza para administrar cuándo y qué se replica y otra información crítica. Aunque Veeam y Zerto difieren en algunos aspectos, ambos utilizan un sistema basado en estos escenarios de configuración de DR virtualizados.

Factores clave a tener en cuenta

Antes de que nadie salga y haga una compra, el departamento de TI tiene que tomar algunas decisiones. Uno de los principales factores en la recuperación de desastres es el Objetivo de Tiempo de Recuperación (RTO) y el Objetivo de Punto de Recuperación (RPO). RTO es cuánto tiempo puede estar antes de que el sistema tenga que estar en ejecución en el lado de DR. El RPO se refiere a qué tan hasta la fecha tiene que estar la información replicada. Si se necesita cada pieza de datos, tal como con una empresa con base financiera, un RTO de 15 minutos es generalmente la norma. Esto requeriría una gran cantidad de recursos para garantizar la coherencia y la correcta replicación. Cuanto más actual necesite ser la información, mayor el número de los recursos necesarios –y por lo tanto el costo– para proporcionar el RTO.

Pero RPO y RTO son más decisiones de negocios que de TI. Ellos, no obstante, proporcionan un punto de partida desde el que los programas pueden ser diseñados y construidos. Sin embargo, puede haber otros problemas que le obligarán a ir hacia una oferta basada en software, como el hecho de que su producto de almacenamiento actual no hace replicación, o que la sobrecarga de replicación o el costo de hacer la réplica demuestra ser prohibitivo. Aquí es donde el almacenamiento basado en software puede entrar a tallar.

Las ofertas basadas en software de Zerto y de Veeam pueden funcionar en cualquier tipo de ambiente, y no tienen ninguna licencia de almacenamiento cara. Las configuraciones de replicación basadas en software son agnósticas respecto al proveedor e ideales para todos los niveles de la estrategia de DR. Tratar cualquiera de estos productos es bastante sencillo y la infraestructura física y virtual adicional es bastante barata. Un cluster de tres nodos podría hacerse a la DR competente por alrededor de 4,000 dólares con bastante facilidad, con exclusión de los requisitos de hardware. Esto también significa que no hay hardware propietario o licencias de replicación del lado de SAN costosos.

Los productos de DR basados ​​en software son una apuesta segura, especialmente si su equipo no está entrenado en almacenamiento. Los errores de almacenamiento podrían agravar la situación. Algunas de las mayores empresas del mundo, incluyendo muchas de Fortune 500, se están moviendo hacia una configuración DR virtual y se alejan de los costosos sistemas basados ​​en SAN,  ahorrando una pequeña fortuna en el proceso.

Cómo garantizar la confiabilidad

Una cosa a tener en cuenta es la interdependencia potencial entre las máquinas virtuales. Un ejemplo de esto sería una clásica aplicación alojada en tres niveles. Para invocar efectivamente la DR, usted tendría que tener todas las máquinas virtuales en un estado coherente. Esto por encima de otras dependencias, como la infraestructura de gestión y autenticación necesarias.

El problema de la coherencia se trata con una tecnología conocida como grupos de consistencia. Los grupos de consistencia, como su nombre lo indica, agrupan máquinas virtuales que deben mantenerse juntas para evitar la posible corrupción y garantizar la coherencia. Esto completa totalmente o falla totalmente, garantizando así que el grupo de invitados se encuentre en un estado coherente.

Próximos pasos

Quizás le interese revisar también:

Guía para planear la recuperación de desastres (DR) de TI

Mejore su gestión de proyectos de recuperación de desastres

¿Plan de Recuperación de Desastres (DRP)? Sí, gracias

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close