Datacenters de alta disponibilidad

[Julio Pacheco]

aams en uaemex.mx escribió:
> Me parece que realmente tu pregunta tiene mucho más de fondo.
> 
> Son las aplicaciones y su ambiente las que se pueden llegar a tener el
> "título " de alta disponibilidad.
> 
> Es el propio dueño de la aplicación quien define el grado de criticidad de
> su aplicación, actualmente antes que pensar en el número de nueves de
> disponibilidad, las empresas piensan en dos puntos: el RTO y el RPO
> 
> RTO es el Recovery Time Objective, es decir, cuánto tiempo puede pasar
> desde que la aplicación deja de estar disponible hasta que puedes
> levantarla en el mismo o en otro sistema.
> 
> RPO es el Recovery Point Objective y se refiere al punto en el tiempo en
> el que quieres recuperar tu información.
> 
> Voy a poner un ejemplo, soy una compañia para la cual una aplicación es
> crítica, y determino un RTO de 1 hr, es decir, si por cualquier cuasa mi
> aplicación sufre algún problema debo ponerla en funcionamiento antes de 1
> hr.
> 
> 
> SI determino un RPO de 30 min, quiere decir que una vez que levante mi
> aplicación después de la caída, yo quiero y debo asegurar que la
> información está consistente hasta al menos 30 min antes del problema,
> aquí estoy considerando que estoy aceptando perder los últimos 30 min de
> cambios en el sistema.
> 
> 
> Ahora estos valores son altos, si quieres bajarlos a cerca de 0, entonces
> tienes que invertir muchísimo en  infraestructura, planes, operatividad y
> varias cosas más.
> 
> Actualmente si hablas de disponibilidad, creo que los puntos que debes
> cubrir son:
> 
> 
> A nivel de Site:
> - Sistemas contra incendios, contra temblores, contra inundaciones
> - Lo principal, un site redundante a la distancia que te permita llevarte
> tu producción a un lugar lejano, en caso de por ejemplo una huelga, dicho
> site debe incluir además la capacidad para mover todo tu equipo d
> etrabajo, es decir, no únicamente el site, también las instalaciones para
> que todo tu equipo de sistemas pueda moverse para allá
> 
> 
> Cluster
> - Obviamente establecer un ambiente de cluster, esto aplica no sólo para
> cuando un equipo falla, sino aplica también apara procedimientos normales,
> Por ejemplo si vas a aplicar parches, pues mueves los servicios del
> cluster a un sólo nodo, aplicas parches o cambios sobre los demás y luego
> vas moviendo los recursos a los otros nodos sin perder nunca
> disponibilidad
> 
> Replicación
> - Obviamente si tienes un site remoto, pues necesitar replicar al
> información a él. la más fácil desde luego cintas, pero eso eleva tu RTO
> muchísimo, hoy día existen tecnologías a nivel de cajas de discos que
> permiten estar replicando constantemente la información de tus
> aplicaciones y levantar la aplicación en el site remoto con diferencia de
> minutos, obviamente, mientras más quieras replicar y más rápido es mucho
> más caro.
> 
> Respaldos.
> - Nunca deben de faltar, aunque tengas replicación.

A propósito de respaldos y RTO, toma en cuenta tus planes de respaldo y recuperación y las 
ventanas de tiempo asociadas, en particular la ventana de recuperación. Una pregunta que 
te sirve (informalmente) para dimensionarla es la siguiente:
En caso de una caída crítica, que requiere de recuperar los respaldos, ¿cuánto tiempo 
tienes antes de empezar a buscar trabajo? :)

Esto es porque en respaldo es muy fácil estirar el tema tratando de respaldar lo más 
rápido posible, sacando respaldos full en forma muy esporádica, y rellenando el resto del 
tiempo con incrementales, pero a la hora de recuperar, si tu RTO es corto, no tienes 
tiempo de recuperar el full mas el cerro de incrementales, lo que hace que el set de 
respaldo sea básicamente inútil (ha pasado más de una vez en el mundo real).

Otro punto importante: de vez en cuando prueba los respaldos. También ha pasado que todo 
el proceso anda bien, pero a la hora de la recuperación las cintas no son legibles.

> Plan de recuperación de desastres
> - este plan incluye los procedimientos de replicación, incluye tambipen
> quiénes y en qué tiempos se determina "desastre" y empieza a aplicar el
> plan.
> - Este plan es complejo, incluye también, quienes deben hacer los cambios,
> en qué orden deben levantarse las aplicaciones en el site alterno.
> - Algo bien importante, al menos 1 vez al año, probar el DRP.
> 
> Al menos de momento es lo que se me viene a la mente, son muchpisimas
> cosas más, pero espero puedan darte una idea.
> 
> 
> 
> 
> 
> 
> 
> 
> 


-- 
Julio Pacheco T.
Consultor Tecnológico
ProVectis S.A.