Datacenters de alta disponibilidad

[aams en uaemex.mx]

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.

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.