Desde mis tiempos en Sema/Schlumberger/Atos lo de la continuidad del negocio era un requisito ineludible, por la tipología de nuestros clientes. Por ello, siempre que he tenido la oportunidad he leido, visto y probado los productos que me han ido surgiendo: Veeam, Nakivo, Symantec.. los típicos. Algún ilustre no he tenido la oportunidad, aún así (Commvault).

Hoy voy a hacer una pequeña intro de ZERTO. Es un producto relativamente nuevo y relativamente poco conocido en el ámbito de los disaster recovery para entornos virtualizados. Digo relativamente nuevo porque lleva en el mercado desde 2010 y relativamente poco conocido porque la mayoría de las empresas que lo montan son grandes empresas y también proveedores de servicios cloud. En España, los únicos que lo montaban eran Telefónica y Colt. A día de hoy, Nexica también lo monta y lo tiene como servicio de DR para sus clientes.

Por ubicar ZERTO, es un producto que está enfocado a la recuperación de desastres y continuidad de negocio. La lógica que sigue es bastante simple, replica las VM a un site secundario (que puede ser tuyo o un proveedor) y en caso necesario, las arranca. Pero tiene unas cuantas peculiaridades. La principal es que replica hablando directamente con el hipervisor y olvidándose de que tipo de storage hay debajo. Es decir, podemos replicar entre diferentes vendedores de almacenamiento. Por otro lado, se ‘incrusta’ dentro del hipervisor. De esta forma, es capaz de capturar las operaciones de escritura y enviarlas al site remoto, independientemente del hipervisor destino. Es decir, no hay snapshots ni se replican snapshots. Lo que se envían son operaciones de escritura, con lo cual se pueden replicar y mezclar diferentes hipervisores, por ejemplo, podemos replicar nuestro entorno VMWARE en un entorno secundario Hyper-V. O viceversa.

 

cross-hypervisor

Otras cosas que personalmente me gustan mucho:

  • Se puede probar la replicación sin entorpecer el entorno productivo. Podemos probar que el SLA que tenemos contratado o el tiempo que tengamos estipulado en nuestro plan de contingencias, se puede cumplir.
  • RPO muy bajo. Teóricamente, hasta 6 segundos (!!!) Es decir, podemos asegurar que solo perderíamos 6 segundos en caso de perdida. Una de las opciones a la hora de configurar la replicación es decidir cada cuanto quieres replicar. Como solo estamos enviando comandos en lugar de dato puro y duro, nos permite llegar a tener unos tiempos de replicación (=RPO en este caso) muy bajos.
  • Protección de aplicaciones. En ZERTO no necesitamos replicar todo nuestro entorno VMWARE o Hyper-V. Quizá solo necesitemos proteger con RPO de segundos determinadas aplicaciones que residen en determinadas VM. Simplemente, agrupamos en ZERTO estas VM y las ponemos los parámetros de replica. Todos esos parámetros aplican para todas las máquinas. Además, podemos definir el orden de arranque de las VM, en caso de que haya dependencias entre ellas para que no haya errores a la hora de recuperar.
  • Puede replicar a Amazon AWS. Si lo que queremos es tener un entorno DR a precio contenido, esta puede ser una opción valida para muchas organizaciones

¿Pero, entonces….tiene algún problema esto de ZERTO? Todo lo que he contado hasta ahora suena todo muy bien, pero tiene un problema importante: el precio. No es nada barato (Si alguien tiene curiosidad, que me pregunte en privado 🙂 ). Pero claro, la cuestión como con todo lo relativo a backup y DR es… ¿cuanto cuesta el estar parado? ¿Es más barato estar parado 4 , 5 , 6 horas o garantizarte que en 1 hora estás funcionando de nuevo? Es una pregunta complicada, de respuesta nada fácil y que depende de cada organización.

En cualquier caso, es una opción muy interesante. Quizá no para montártelo en tu casa, pero para tener un entorno DR para proteger tu aplicación megacrítica que te da un pampurrio en caso de que pares más de 10 minutos con un coste mensual en un proveedor cloud puede ser una opción muy valida.