VMware Site Recovery Manager SRM

Buenas a tod@s,

Esta es la primera entrada de una serie donde os mostraré como funciona y mejor aún como se instala Site Recovery Manager de VMware.

Antes de nada os contaré de que se trata este Software y cuales son sus funcionalidades.

Site Recovery Manager es una solución para recuperación ante desastres de VMware, se integra de forma nativa con VMware vSphere lo cual nos permite recuperar nuestro entorno en otra ubicación. La réplica de nuestro CPD permite realizarla con software de VMware como vSphere Replication, la cual nos permite replicar de forma asincrona con un mínimo de 15 minutos o mejor aún, integrarse con almacenamiento de los principales fabricantes y así mantener nuestro CPD replicado de forma sincrona usando para ello la replica incluida con nuestro almacenamiento.

Os muestro una imagen para que veáis de que estamos hablando.

1

Cómo podéis ver con SRM podemos mantener nuestro CPD protegido pero ¿como sabemos si funciona? Esto es lo mejor, SRM nos permite crear planes de recuperación y además probar si realmente están funcionando de una forma sencilla. Ya veremos como 😉

SRM se ofrece en dos versiones Estandar y Enterprise, en la versión Estandar podemos proteger hasta 75 máquinas virtuales y lo mejor es que podemos implementarlo desde VMware Essential Plus. Además si nuestro site secundario es solamente para recuperación, solamente debemos adquirir una licencia. Podéis encontrar más información sobre licenciamiento y preguntas frecuentes aquí.

En la Siguiente Entrada empezaremos la instalación de SRM paso a paso.

Saludos!!

7 Respuestas to “VMware Site Recovery Manager SRM

  • Buenos días.

    En empresas no muy grandes (unos 500 puestos de trabajo repartidos en 2 edificios adyacentes y comunicados con fibra, con servicios como: controlador de dominio, Exchange, Sharepoint, SQL, servidor FTP, servidores de impresión, y otros similares, es decir, cosas normales, todo virtualizado sobre VMw ESX y vCenter), ¿merece la pena montar SRM?

    Me explico, en el edificio principal hay un par de racks con toda la electrónica y servidores hardware que alojan los servidores que he comentado más arriba. Los servidores más críticos (controlador, SQL, Sharepoint) están redundados.

    ¿Que ventajas ofrecería montar SRM con un respaldo en el otro edificio respecto a si solamente se mueven los servidores redundantes de los servicios críticos a un armario que montemos con electrónica y servidores hardware en el otro edificio?

    Buen día!

    • Buenas tardes,

      si he entendido bien los servicios criticos estarán instalados en Cluster en los dos edificios y el controlador de dominio tendréis PDC en uno de ellos y BDC en el otro edificio.

      Pues bien, SRM te puede ofrecer la automatización de movimiento de máquinas entre el primer edificio y el segundo indistintamente, podrás crear flujos entre primer y segundo edificio y al contrario. La ventaja es proteger todo el entorno y no solo los servidores criticos que tenéis en cluster. Por ejemplo, ¿tenéis protegidos los servidores de ficheros entre ambos? si cae el primer edificio de forma completa podrán los trabajadores seguir accediendo a los ficheros? ¿En caso de caida y posterior vuelta a la normalidad estan contemplados los cambios que habría que realizar en las VMs?

      Al final SRM no es más que una gestión centralizada de sites con una definición de flujos de trabajo en caso de caida de sedes.

      No se si te he aclarado tu pregunta, aquí estoy para lo que necesites.

      Saludos.

      • Buenos días.

        En mi comentario olvidé poner que el servidor de ficheros también está redundado y sería uno de los que tendría el secundario en el otro edificio.

        Con su comentario sobre los flujos entre edificios y los cambios requeridos en VMs «recuperadas», creo que ya veo más claro uno de los elementos que justifican SRM:
        Con SRM, en caso de caida del site protected, la recuperación podría hacerse (días, semanas o meses después) «pasando» el escenario del site recovery al site protected de forma «automatizada» (aunque definir esos flujos de trabajo tenga su complejidad), pero sin SRM la tarea se complica (clonar VMs del secundario y llevarlas al primario, pero habría que modificarlas a mano).

        Una cosa es mantener el servicio (sin SRM) y otra tener un plan de contingencia que simplifique la vuelta a la normalidad en la explotación (con un site en producción y otro de recovery) una vez enmendado el problema «físico» (incendio, sabotaje, problemas en la electrónica de red …).

        ¿Es todo esto más o menos acertado?

        Muchas gracias por su atención.

Trackbacks & Pings

Escriba una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.