Recuperacion de desastres con VMware Site Recovery Manager 5

November 16, 2011 by
Wetcom admin

Hoy me toca hablar de una rama delicada de la informática: La continuidad de negocios, también conocida como recuperación de desastres.

Los “business continuity plans” o “disaster recovery exercises” son cosa de todos los días del otro lado del Ecuador, donde las leyes hace ya muchos años exigen a diversas empresas la ejecución de uno o dos de estos ejercicios al año, la correcta y actualizada documentación del plan en el que se amparan, etc. teniendo como fin principal, aunque no único, la protección de la información y el dinero de los clientes de las mismas, ya sean financieras, de seguros, o de algún otro de los rubros que se ven afectados.

Vale destacar que también en muchos casos, la adopción de estas políticas no es necesariamente obligada por la ley. Ya mucho hemos oído sobre atentados, ataques biológicos, epidemias, terremotos y diversas catástrofes que sufre con frecuencia el pueblo estadounidense, es lógico que los empresarios busquen una alternativa que les permita continuar proveyendo servicios, generando ganancias, y protegiendo sus negocios frente a lo imprevisto… Que lamentablemente por esas latitudes sucede muy frecuentemente.

En los últimos años, ya sea por el episodio de la gripe N1H1, por el devastador terremoto sufrido en Chile, o por la sanción de alguna ley nueva, las empresas pertenecientes a nuestro hemisferio están tomando conciencia de la importancia que tiene incorporar estas prácticas activamente a la organización, y la posición que adopte del departamento de TI frente a ellas es crucial para su éxito o fracaso: No es lo mismo un enfoque clásico con equipos duplicados en un sitio secundario y recuperación desde copias de resguardo, que réplicas a nivel cajón, o la incorporación de aplicaciones como Veeam vPower, VMware SRM… No son los mismos tiempos de recuperación, no se puede garantizar el mismo RPO, y por supuesto el costo no es el mismo. Como en cualquier trabajo de consultoría, es importante analizar el caso de cada organización para poder darle lo que necesita dentro del presupuesto que pueda manejar, pero eso es un tema que hoy no nos compete.

En materia de soluciones de VMware, la estrella de la recuperación de desastres es Site Recovery Manager: SRM se ampara en las ventajas de la virtualización qure ya conocemos (independencia de hardware, aplicativo y SO, confiabilidad, estabilidad etc) para brindar un tiempo de recuperación más rápido, automatizando el inicio de las máquinas virtuales de nuestra infraestructura, permitiéndonos ponerles una prioridad y un órden de inicio que puede o no ser simultáneo, y además brindando no sólo protección ante caídas de servicio imprevistas, sino también una alternativa en caso de mantenimiento planificado del datacenter, además de que con SRM no es necesario tener hardware 100% ocioso en el sitio de contingencia.

Implementación típica de SRM 4.1 – Fuente: VMware

Dentro de los requerimientos de la versión 4.1 teníamos:

  • Un vCenter por sitio
  • Un servidor dedicado para SRM por sitio
  • SRA del proveedor de storage compatible
  • Storage compatible idéntico en ambos sitios

Lamentablemente al momento de implementar, requerimientos como el de una compra doble de un storage de determinadas características le quitaba la posibilidad de gozar de estas ventajas a muchas empresas. Además, el manejo de réplicas a nivel datastore complejizaba un poco el diseño de la solución provista con la herramienta ya que nos encontrábamos en la tarea de reacomodar las VMs a replicar para llevar al sitio secundario el volumen completo, las VMs debíamos respaldarlas incluyendo todos sus discos, y además la réplica inicial de un sitio al otro consumía una gran cantidad de recursos y si el enlace era requerido para otras tareas a veces era necesario planificar el evento.

Para alegría de muchos, se han dado modificaciones en la versión 5 de Site Recovery Manager que permiten el acceso al producto por parte de muchos más sectores, además de alivianar estos puntos antes mencionados, a saber:

  • Réplica nativa de SRM: Se puede replicar VMs independientemente del tipo de storage sobre el que se encuentran, habilitando también la posibilidad de replicar máquinas entre dispositivos de almacenamiento heterogéneos.
  • Manejo de réplicas a nivel VM: La réplica comienza a manejarse como una propiedad de la máquina virtual y no del datastore. Podemos elegir replicar uno o más discos de la VM y ubicarlos donde nos plazca.
  • Manejo de réplica simplificado: El administrador puede proveer la copia inicial para ahorrar consumo de ancho de banda.
  • Especificaciones de réplica: Los cambios en los discos de origen son seguidos por el ESX, no por el storage, y los deltas generados son enviados al sitio remoto.

Éstas son a grandes rasgos las modificaciones que se han visto en la nueva versión, que abren las puertas para nuevas aplicaciones de SRM, ahora sí cada vez más independiente del hardware y mas granulado, para favorecer la inversión que hacemos en el hardware del sitio secundario y el aprovechamiento que hacemos del mismo.

Para más información sobre licenciamiento de SRM 5, podemos referirnos al gurú de la continuidad de negocios de Wetcom, Nicolás Solop en este artículo. Si lo que necesitamos es ampliar nuestro conocimiento sobre teoría de las soluciones de SRP, podemos referirnos al mismo autor en este otro artículo.

Hasta la próxima publicación!