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.
