¿Cuál es la característica que más cambia el juego en vSphere 5.1? Es sin duda la Replicación de vSphere y el impacto que tiene en la recuperación de desastres (DR). Me atrevería a decir que es la revolución más significativa en la RD después de la propia virtualización de servidores. Hace que la recuperación de desastres sea una posibilidad asequible incluso para las empresas más pequeñas, y lo hace mucho más sencillo.
¿Qué es la recuperación de desastres (DR)?
La continuidad de las actividades es fundamental para todas las organizaciones y un plan de recuperación en caso de desastre debidamente elaborado puede determinar la capacidad de una empresa para continuar después de un desastre.
Un plan de recuperación de desastres es un intento de hacer una lista de posibles desastres y de estar lo más preparado posible para hacerles frente. Un desastre suele implicar un suceso importante que afecta a toda la empresa desde un sitio específico, lo que obliga a la empresa a trasladar muchas de sus operaciones críticas a otro sitio. Nuestro papel como profesionales de la informática es prever tales escenarios y su impacto en la sala de ordenadores/servidores o en el centro de datos.
Por supuesto, las posibilidades de desastres son infinitas, e incluso la imaginación más creativa no puede considerar todos los escenarios posibles. Además, protegerse de cada desastre cuesta dinero, por lo que se crea un plan de continuidad de negocio basado en su presupuesto, la probabilidad del desastre y el impacto en el negocio.
Un plan puede ser tan simple como enviar copias de seguridad fuera de línea para poder restaurarlas en otro lugar o tan caro como replicar todo en el sitio activo a otro sitio de RD. A menudo, un plan es una combinación de muchos métodos.
Cómo la virtualización cambió la recuperación de desastres
En el pasado, un sitio de recuperación de desastres incluía un número de servidores casi idéntico al de los servidores de producción en cuanto a especificaciones y capacidades. Esos servidores físicos pueden pasar su vida útil sin ser utilizados, esperando un desastre que esperemos que no ocurra. Además, la costosa replicación basada en el almacenamiento era, en muchos casos, la única opción disponible para reproducir los cambios escritos en los sistemas de producción en el sitio de recuperación de desastres. La replicación de almacenamiento a menudo necesitaba un almacenamiento idéntico y costoso del mismo proveedor.
¿Cómo de caro? Mi empleador pagó un millón de dólares por el almacenamiento de la producción, el almacenamiento de DR y las licencias necesarias para unos cinco años. Nos dijeron que los servidores blade, los conmutadores de tela, los transceptores de fibra a IP, la SAN de fibra y todo lo demás debía ser del mismo proveedor para asegurar la estabilidad.
El costo y el bloqueo de proveedores no eran las únicas preocupaciones que tenía con esta solución: La idea se basaba en un libro de tareas que los administradores deben realizar manualmente si se produce un desastre. El plan no era fácilmente comprobable y la única oportunidad que teníamos de probarlo era para la reubicación de nuestro centro de datos en una nueva sede. Después de meses de preparación, tomó más de 24 horas de trabajo continuo para poner todo en marcha de nuevo. Si hubiera sido un verdadero desastre que hubiera requerido un administrador sustituto para seguir el libro de ejecución, habría tomado aún más tiempo.
La transformación de los servidores en máquinas virtuales separa el sistema operativo y las aplicaciones que se ejecutan en él del hardware subyacente, lo que permite que se ejecute en servidores que pueden ser diferentes en cuanto a las especificaciones, la configuración y/o el proveedor. VMware Site Recovery Manager (SRM) añade a eso un libro de ejecución totalmente automatizado que proporciona pruebas no disruptivas.
La replicación basada en el almacenamiento solía ser un requisito para el SRM. Eso cambió durante VMworld 2011, cuando VMware introdujo la replicación basada en hipervisor como parte de SRM 5.0. Esto supuso un enorme recorte de costes para las organizaciones que planeaban crear un plan de recuperación de desastres. vSphere Replication permite el uso de almacenamientos diferentes, lo que supone un ahorro en los costes de licencia de almacenamiento e incluso permite utilizar discos locales para alojar réplicas de VM. Además de recortar los costos, vSphere Replication se basa en la flexibilidad. Por ejemplo, puede proteger las máquinas virtuales individualmente, en lugar de proteger todo el almacén de datos de VMFS.
Entonces, ¿qué hay de nuevo en la Replicación de vSphere 5.1?
La diferencia más significativa en 5.1 es que la Replicación de vSphere está disponible sin cargo adicional y viene como parte de la plataforma de vSphere, mientras que en 5.0 sólo vino con una licencia SRM. Esto hace que la recuperación de desastres sea más asequible incluso para los clientes de PYMES que utilizan el vSphere Essentials Plus.
Como todas las nuevas características de vSphere 5.1, la réplica de vSphere sólo se gestiona mediante el cliente web. El nuevo vSphere Replication es un dispositivo virtual fácil de desplegar que utiliza su propia base de datos interna. Cada Appliance de Replicación vSphere desplegado puede ser usado para configurar y administrar las replicaciones de hasta 500 máquinas virtuales. Al utilizar su base de datos incorporada, VMware ha simplificado enormemente la implementación de vSphere Replication.
Para ahorrar ancho de banda, replica sólo los bloques cambiados e incluso puede ser configurado por disco. Por ejemplo, puede poner su intercambio de sistema operativo en un disco separado y excluirlo de la replicación, ya que de todos modos será inútil para una máquina virtual recuperada. Además, a vSphere Replication no le importa si sus discos primarios son delgados o gruesos, y es independiente de las instantáneas.
Para ahorrar tiempo y ancho de banda, vSphere Replication puede usar un VM de semillas. Por ejemplo, puede exportar el VM primario a medios externos y luego importarlo en el sitio secundario para ser usado como objetivo de la replicación. Los cambios se rastrean y el VM de destino se sincroniza con el primario, usando el menor ancho de banda posible para replicar sólo las diferencias desde que el VM fue exportado. Incluso si mover un VM exportado no es fácil, se puede usar un VM recién instalado del mismo SO como una semilla para salvar de la replicación de los archivos comunes del SO.
La nueva vSphere Replication ha mejorado mucho la integración con los Servicios de Copia de Sombra de Volumen (VSS) de Microsoft para asegurar la consistencia de la aplicación al replicar los VM. Esto es especialmente importante para aplicaciones como SQL y Exchange. vSphere Replication no sólo solicita la quietud del sistema operativo, sino que también pide a las herramientas de VMware que eliminen cualquier aplicación o escritura de base de datos antes de tomar una réplica consistente.
¿Hay algún inconveniente en la Replicación de vSphere 5.1?
Una de las limitaciones más notables de la Replicación de vSphere es que tiene un objetivo mínimo de punto de recuperación (RPO) de 15 minutos y un máximo de 24 horas. Mucho puede suceder en 15 minutos y para algunas empresas, los datos perdidos en ese tiempo son simplemente inaceptables. Es posible que esas empresas todavía tengan que depender del almacenamiento o de la replicación sincrónica de las aplicaciones. La replicación síncrona significa que cualquier operación de escritura no se confirma en la aplicación de front-end hasta que los datos se escriben tanto en el sitio primario como en el secundario, lo que garantiza que si ocurre un desastre, no haya pérdida de datos.
Otra limitación significativa es que la Replicación de la vSfera sólo replica los VMs encendidos. Esto significa que no se puede utilizar para replicar plantillas en los sitios y no se puede replicar una colección de archivos ISO en un almacén de datos.
Al igual que muchas otras funciones de vSphere, la replicación de vSphere no es compatible con la tolerancia a fallos de VMware. Tampoco es compatible con clones vinculados o con RDM físico. Sin embargo, le sorprenderá saber que la replicación de vSphere no es compatible con Storage vMotion y Storage DRS.
vSphere Replication implementation
En este punto, estoy seguro de que están ansiosos por probar la Replicación de vSphere y aprender sobre los escenarios de implementación comunes. En un artículo de la próxima semana, explicaré en detalle cómo integrar la Replicación de vSphere en un solo entorno vCenter y a través de sitios que son gestionados por diferentes vCenters. Así que manténgase en sintonía!
¿Listo para poner a prueba tus habilidades en VMware? Vea cómo se acumulan con esta evaluación de Smarterer. Inicie esta prueba de VMware ahora.