Continuidad de negocio y Recuperación de desastres (take two)

julio 19, 2016 — por Josep Mª Gris0

main

Assoc. Cat. VirtualitzacióVeeamVirtualizacionVMware

Continuidad de negocio y Recuperación de desastres (take two)

julio 19, 2016 — por Josep Mª Gris0

En mi anterior post sobre recuperación de desastres (take one), versaba por un lado entre Continuidad de Negocio y Recuperación de Desastres y veíamos a su vez como los dos podían estar enlazados el BC a un tema organizacional y el DR a los planes que deben tener los diversos departamentos.
También veíamos como el BC y el DR podían estar circunscritos ambos dentro del departamento de IT, y aunque siendo el sentido el mismo, el “scope” era mucho más de puertas para dentro del Departamento.

Quizás podíamos decir que la primera organización es más estratégica, mientras que la segunda es más táctica.Hoy vamos a bajar de nivel y vamos a hablar de puertas para adentro, en como puede afrontar el departamento de TI el BC y el DR con las ventajas que aporta la virtualización, y vamos a dividirlo en entornos de 1 solo “site” versus entornos donde hay un “site” de respaldo, y a su vez como podemos afrontar un fallo de servidor (computación, memoria, comunicaciones) versus un fallo de “storage”.

coche en problemas

Ante todo quiero dejar claro que este post no es una lista exhaustiva de todos los posibles fallos que puede tener un Centro de Datos, (muy ambicioso sería), sino los más evidentes y las herramientas que existen y usamos para cada caso. Si estáis interesados en el tema, indicadlo en los comentarios y posiblemente más adelante haga un Ebook sobre el tema.

Veamos estos casos:

Tenemos un “Site” de producción sin “Site” de recuperación.

Fallo de computación:

BC: En este caso, si disponemos de los suficientes servidores, o en otras palabras, un “cluster” donde está bien tarado el límite de tolerancia y admisión, HA de VMware nos dará un BC con un RTO de 2’ a 5’ (dependiendo de lo que tiene que levantar), mientras que Fault Tolerance (FT) si tenemos los recursos y la maquina cumple los requisitos, nos dará un RTO de 0.
DR: Aquí deberíamos de asumir que no tenemos ningún servidor “en espera”, por lo que tendríamos que tener algún tipo de acuerdo con el fabricante en cuanto a reparación o aprovisionamiento de Hardware. En estos casos los RTO son “no medibles” ni predecibles. Otra opción sería que pudiéramos parar temporalmente ciertas VM no criticas, mientras damos continuidad a las críticas.

Fallo de storage:

BC: En este caso, precisamos de un sistema de replicación de las SAN. Hoy por hoy existen muchas SAN capaces de replicar, aunque sistemas como Datacore establecen un sistema activo-activo, donde pueden proveernos un RTO y un RPO = 0, siendo un real BC.
DR: Entraríamos en el mundo del Backup. Ahí Veeam Backup no tiene competencia. Con su near-CDP puede llegar a un RTPO combinado de 15’ , aunque claro, si tenemos configurado a Veeam para hacer una copia al día, nuestro RPO podría llegar a ser de 24 h. Con herramientas como “Instant recovery” hemos hecho auténticos casi-milagros.

Vamos ahora a ver como gestionamos el BC y el DR disponiendo de un segundo site de contingencia

Fallo de computación:

DR: En este caso o no tenemos computación preparada (donde el RTPO se nos hunde), o tenemos un acuerdo con el fabricante,
BC: dos opciones “válidas”, o tener servidores propios/alquilados debidamente configurados, o bien rentar sistemas tipo “IAaS” convirtiéndose en un “DRAaS”. Ojo!. Para que este “plan” pueda funcionar, como en el anterior, es imprescindible que los datos ya estén en el segundo site.

Fallo de storage:

BC: Aquí tendríamos de nuevo a Datacore en una configuración “metrolan” o bien Datacore también dispone de un sistema “asíncrono”. El RPO podría ir desde 0 en el primer caso hasta los datos que no ha llegado a pasar (minutos) en la segunda configuración.
DR: Tenemos aquí a Veeam Backup&Replicator en la línea entre BC y DR, pero dado que el RTPO de sus Best practices está en 15’ lo pondremos dentro de DR pero con honores. Recordaros que para tener aceleradores “Wan” y elementos de aceleración, debe usarse la versión Enterprise Plus.

Site recovery y Orquestadores de recuperación:

He querido poner dentro de este apartado pero aparte a estos productos/fabricantes porque disponen de una serie de herramientas muy orientadas y muy especializadas en cuanto a recuperar “Sites” en RTPO casi 0. Entre ellas tenemos:

Zerto: Excelente orquestador de replicación y recuperación en un solo producto. Es capaz de indicarnos si la replicación se está ejecutando dentro de la SLA de RPO que tenemos establecida, es capaz asimismo de pasar la producción del “Site” siniestrado al “Site” de contingencia pulsando el “red button”.

Vision Solutions: Muy parecido al anterior, son los padres del ya famoso Double Take, gran sistema de replicación en entornos físicos que tantas alegrías ha proporcionado. Como digo es muy parecido al anterior pero tiene algunas diferencias muy primordiales como que puede replicar entornos físicos a virtuales como virtuales a físicos.

SRM / Replicator: Quizás el mas conocido de todos ellos, SRM ya lleva varias versiones entre nosotros y es un viejo conocido, con la incorporación de Replicator en vSphere, ha abierto sus posibilidades a SAN que antes no eran compatibles.
Como digo, este post no pretende ser una lista exhaustiva de circunstancias/tecnologías de recuperación, pretende enumerar las más obvias y las tecnologías que hoy por hoy más se está utilizando por el mercado y por nosotros mismos.
Espero que nos haya interesado el escrito y como siempre, si tenéis alguna duda o sugerencia, estoy a vuestra disposición.

Take care

Dejar comentario

Tu dirección de correo no será publicada Los campos requeridos están marcados con *

16 − Once =