Redundancia de vServers para enfrentar fallos


([N1] Spicer) #1

Queridos compañeros,

Tengo una VPS que ocupo para testing, en un proveedor cualquiera. De esas que uno piensa que nunca jamás van a fallar. Pues bien… dejó de funcionar por un “issue” que me ha tenido sin la maquina un par de días. Por suerte que era de testing y no de producción, porque en ese caso, sí que la hubiera visto de cuadritos.

Y eso me llevó a pensar… qué pasaría si la maquina virtual de producción dejara de estar online por un problema del proveedor… ¿qué hacer? entonces se me ocurrió una metodología:

  • Tener DOS vServers de producción (primario y secundario), activados con licencias distintas
  • Tener UNA carpeta de datos, y UNA carpeta de cajas, sincronizada entre ambos, ocupando DFS (Windows Server) o GlusterFS (Linux)
  • Tener el vServer secundario deshabilitado, de modo que los archivos sólo sean accesados por el vServer primario

Entonces, en caso de falla del vServer primario, el plan sería el siguiente:
a) Deshabilitar la réplica, para que los archivos de cajas y datos sean accesibles sólo desde el vServer secundario
b) Arrancar el vServer que ya está activado en el secundario
c) Decirle a los clientes que en vez de conectarse a la IP primaria, se conecten a la secundaria (pensé en cambiar la IP en el DNS, pero en caso de falla sería más rápido que digiten la IP secundaria a que esperen el cambio en su DNS)

Luego, cuando vuelva el primario, deshabilitar el vServer secundario, volver a activar la réplica para que sincronicen los datos, mantener el secundario deshabilitado, y activar el primario.

¿Tiene sentido esto? ¿Alguien ha hecho algo así? ¿O quizá tiene una mejor idea?

Muchas gracias!


([N1] wikan) #2

Depende de lo crítico que sea el sistema y lo que el cliente esté dispuesto a invertir en seguridad.

En un mundo empresarial normal quizás parar el servicio durante unas horas tampoco sea tanto si contando el número de hora de servicio al año.
Ten en cuenta que un SLA del 99.9 son casi 9 horas de parada al año, si ya nos vamos al 99% estaríamos hablando de parar durante 3 días.

De todas formas, habría que probar como se lleva las base de datos con la redundancia.


([N1] Spicer) #3

Estoy de acuerdo contigo en que quizá 99.9% está bien en términos globales. Pero si el vServer falla y te empiezan a llamar por teléfono los clientes, enojados, entonces será bueno tener una estrategia probada para restablecer el servicio rápido (no instantáneo, pero, digamos, 15 minutos…).


([N1] aztecmexico) #4

A mi me parece una buena idea, el tema es que te asegures que todos tengan conocimiento de la dirección alterna del vServer secundario y que a tí o a quien designes responsable esten siempre al pendiente o disponibles para activarlo.

Tambien sería conveniente que copiaras o replicaras al secundario las carpetas de las cajas y configuración del vServer primario al secundario, porque donde te falte algún usuario o el secundario no tenga replicada la solucion actualizada, ya te quiero ver.

Saludos.


([N1] wikan) #5

A lo mejor el problema es el “proveedor cualquiera”. Mejor para sistemas críticos usar proveedores de confianza.
Mira por ejemplo los cloud de Velneo, rara vez tienen caídas. Pueden que en algún momento vayan mejor o peor pero el servicio siempre está online.


([N3] pacosatu) #6

Hola Spicer.

Planteas un tema interesante que creo tiene un punto débil, la sincronizaciñon de los datos en un sistema transaccional.
No es tan fácil como conectar a la nueva IP cuando un Cliente te llama desesperado.

En un entorno de unos pocos usuarios y pocas transacciones por minuto, puede funcionar, pero en entornos con mucha carga de trabajo lo más adecuado es que sea el VServer el encargado de replicar los datos, algo que de momento no es posible.

Por lo tanto en entornos críticos, yo también creo que lo más adecuado es confiar en un Proveedor que nos garantize lo más cercano a 24x365.

Saludos
Paco Satué


([N1] Spicer) #7

Estimados,

Muchas gracias por sus aportaciones. Efectivamente, lo mejor es elegir un buen proveedor para el ambiente de producción, para que así la probabilidad de fallos sea mínima. El de testing que me falló es uno que elegí porque era barato, lo cual fue muy bueno porque me recordó aquel refrán que reza “Lo barato cuesta caro”.

Saludos a todos


([N4] Jorge) #8

Os paso alguna referencia de como montar un cluster en linux:
http://www.nexolinux.com/clustering-alta-disponibilidad-en-linux-heartbeat/
http://www.alcancelibre.org/staticpages/index.php/como-cluster-heartbeat-centos

Si os animáis… ya tenéis tarea.
Por mi parte aporto una cuestión clara: La teoría dice que tiene que funcionar en modo Activo-Pasivo o en modo Activo-Activo mediante dos instancias corriendo en A-P / P-A. Yo me lo creo, ya que si tiro abajo el motor (Mato el proceso vServer)… cuando se inicia el vServer a continuación se deshacen las transacciones no completadas (creo que internamente Velneo trabaja con un modo de aislamiento bastante fuerte). La practica está por verse…

En escenarios 24/7 hay que dar garantías acordes a la SLA fijada. Si tus infraestructuras están en el rango de la SLA perfecto, pero no solo es cuestión del proveedor de infraestructuras. También el servicio puede fallar (cosas que tiran el vServer). Alguna hay, os lo aseguro (como ejemplo… en la 7.18.1 si en el ON_INIT_SERVER creas procesos transaccionales largos que tienen que procesar registros sobre tablas nuevas que se están creando en ese mismo momento el vServer puede caer).

PD: Creo que estaría bien que alguien lo probase o que Velneo informase.