Datacore caído

Puede que tengas alguna solución de alta disponibilidad basado en dos servidores Datacore.

Datacore es el producto líder en virtualización de almacenamiento. Además hay que remarcar que no es una solución propietaria de los grandes fabricantes como IBM, HP, etc. sino que puede funcionar con la mayoría de cabinas del mercado.

Una configuración habitual con dos cabinas y dos nodos suele ser la siguiente:

Cabina1 ---> Datacore1 ---> Servidores
Cabina2 ---> Datacore2 ---> Servidores

Los servidores Datacore se encargan de la replicación de datos entre ellos.
Cada servidor Datacore sólo ve su Cabina.

Si se cae una cabina, no pasa nada porque el otro servidor Datacore seguirá dando servicio.

Durante las pruebas realizadas en abril de 2009, teniendo Oracle en auténtica ebullición, quité la fibra que conectaba uno de los Datacores a los switch de fibra. La base de datos ni se inmutó. El mérito aparte de Datacore es también del HP-UX por supuesto.

El caso es, que creo que es necesario tener claro qué hacer si algún día se caen los dos servidores Datacore.

El problema ante una caída simultanea es que no es suficiente con volver a arrancar las cabinas, los servidores Datacore, y los servidores finales (en ese orden), porque los servidores Datacore van a quedarse en estado de Double Failure hasta que hagamos una serie de acciones.

En la imagen se ven los volúmenes virtuales (Virtual Volume) en estado de Double Failure y en diagnóstico: "primary and secondary volumes down".

Cuando en la ventana de arriba seleccionamos un Virtual Volume concreto, en la sección de volúmenes lógicos (Logical Volumes) de abajo vemos que tanto el volumen primario como el secundario están caídos (estado Down).

Pero tranquilos que tiene solución:

Primero hay que elegir entre uno de los Datacores. La consistencia se ha perdido por la caída y tenemos que indicar cual de los dos tiene los datos "buenos".

En igualdad de condiciones mejor coger como buenos los volúmenes primarios, ya que los servidores se habrán configurado para que preferentemente utilicen estos (preferred path). Pero bueno, todo depende de cómo esté el datacore de los volúmenes primarios (averiado...), de si pensamos que uno se ha apagado antes que el otro, ...

Lo que hay que hacer es ir a Logical Volumes, coger el primario o el secundario, darle al botón derecho y "star recovery using this volume as recovery base". En unos cuantos minutos el volumen lógico pasará a estado UP como se ve en la imagen. En la sección del Virtual Volume, el volumen virtual estará todavía en estado: "redundancy compromised".

El otro volumen (en la imagen de arriba sería el secundario) empieza a recuperar los datos a partir del que esta up. En la descripción viene: "Down. Local full recovery pending". Este proceso puede tardar incluso 20 horas para un volumen de 1 Tb. Después de esa larga espera los Datacores volverán a tener el volumen con la replicación activa y mostrarán el estado "Healthy".

Importante:

Una vez tomada la decisión de elegir uno de los datacores para la recuperación, no se debe solicitar lo mismo para el otro datacore porque se perderían todos los datos.

Si como en mi caso, los 4 volúmenes son para un servidor Oracle, la lógica dice que recuperes todos los volúmenes del mismo servidor Datacore. Recuerda que si Oracle encuentra ficheros con distintas marcas de tiempo no va a arrancar.

Saludos.