Datacenters de alta disponibilidad

[mramirez en iciuchile.cl]

A proposito, dada la recomendacion de mas abajo, existe algun pdf o libro
recomendable que hable del tema...?

Saludos,
Mario Ramirez

Quoting 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.
>
>
>
>
>
>
>
>