Failover clusters II: DB failover clustering

En la lista TIC recibí un comentario y se dió escribir la segunda parte del artículo.
http://groups.google.com/group/comunidadit/browse_thread/thread/9444930357eff750

---
>Te consulto yaco, por que clusterizar el sistema operativo completo y no un 
>servicio determinado? Que clientes o industrias lo esan haciendo y para 
>que? Algun ejemplo para discutirlo. 

Industrias? Ví clustering de DBs (configurado a nivel DB en casi todos los casos), en lugares como bancos hasta grandes cadenas de electrodomésticos.

Sigo abajo con la primer parte de la pregunta

Gracias por el pie :-)

> La alta disponibilidad de una base de datos no debiera estar sujeta a un
> esquema de fail over recostado en el sistema operativo. Ninguna base de
> datos te garantiza consistencia basada en el os. Menciono esto x el ejemplo
> que usaste.

El clustering del OS normalmente se utiliza en otros servicios que no son de base de datos (pero, en el ejemplo del PostgreSQL que mencioné, sí se utiliza el clustering de OS para brindar failover capabilities).

La clusterización activo / pasivo permite servicios en un server y si este falla, los mismos servicios van a continuar corriendo en el nodo secundario (que se vuelve activo). Por ejemplo: samba, postfix, etc. en Linux,

Dar ejemplos para Windows es un poco más truculento ya que la mayoría de los servicios importantes suele usar como backend una DB (y volvemos a ver el issue que mencionó Guido). Servicios de Windows de ejemplo: cualquiera que no use una DB como backend.

En ese tipo de esquema, el storage compartido es necesario porque permite que los datos que tenga guardados una aplicación, sean limpiamente reutilizados desde el segundo servidor.

Si hablamos de que el servicio es una base de datos (y no Samba, Postfix, etc.), se da que:

En el evento de un failover (que implica que nodo primario dejó de responder por algun motivo), se utilizan las capacidades ACID y la DB contínúa(ría) funcionando normalmente. Sí, es muy factible una cierta pérdida de datos, esto es lo que mencionaba Guido: aquí no hay garantías desde la DB, que no se "entera" que hubo un cambio de hardware y ello puede traer problemas. Por otro lado, las pérdidas de datos, hasta cierto punto, si lo pensamos bien, igualmente hubieran tenido lugar al fallar y salir de servicio en un server físico  stand-alone, sin clusterización (de vuelta, no hay nada seguro, y qué tan bien funcione la DB luego de un failover de clustering a nivel de OS depende muchísimo del escenario particular donde se implemente).

http://es.wikipedia.org/wiki/ACID

Hay algun modo de mejorar las probabilidades de que una DB siga funcionando bien luego de un failover, sí:

Por las debilidades mencionadas del clustering a nivel sistema operativo para clusterizar bases de datos, las DBs suelen tener sus propias capacidades para configurar failover clusters directamente desde la DB  (y esto ya es otro tipo de clustering).

Por ejemplo

Oracle RAC
http://en.wikipedia.org/wiki/Oracle_RAC

Create a New SQL Server Failover Cluster (Setup)
http://msdn.microsoft.com/en-us/library/ms179530.aspx

How To Set Up A Postgresql 9.0 Hot Standby Streaming Replication Server With Repmgr On OpenSUSE 11.4
http://www.howtoforge.com/how-to-set-up-a-postgresql-9.0-hot-standby-streaming-replication-server-with-repmgr-on-opensuse-11.4

Con un poco de ayuda de
http://repmgr.org/