miércoles, 22 de mayo de 2013

Estrategias de Alta Disponibilidad


En general existen 3 estrategias de alta disponibilidad con Caché/Ensemble:

  • Cluster en Fail-Over de Sistema Operativo
  • HA Basada en Virtualización
  • Caché Database Mirroring

Cada una de ellas tiene una serie de diferencias, pros y contra dependiendo de la infraestructura y sistemas

Cluster Fail-Over
Consiste en utilizar soluciones de Fail-Over proporcionadas a nivel de sistema operativo.
Dos servidores idénticos compartiendo:

  • un dispositivo de almacenamiento (SAN)
  • una dirección IP.

Un servidor (activo) ejecuta el trabajo y el otro permanece en Standby (pasivo) preparado para la transición. Cuando se produce un corte de servicio en el servidor activo el controlador del cluster transfiere el control de la IP y del disco al nodo pasivo y posteriormente inicia los servicios incluyendo Caché.

Análisis de pros y contras:
Transición tras caída de la máquina física por perdida de corriente o similar: 
Se maneja de forma fluida 
Transición por Fallo o Corrupción en almacenamiento: 
Al utilizar un almacenamiento compartido no es posible la transición 
Transición por caída de Caché: 
Puede configurarse pero depende del sistema operativo 
Tiempo de recuperación en transición: 
Pueden ser minutos 
Sincronización de ficheros externos: 
Todos los ficheros están disponibles por ambos nodos 

Alta disponibilidad basada en virtualización
Tecnologías de virtualización como VMWare ESX, proporcionan capacidades de HA. Monitorizan la salud y viabilidad del HW así como de los OS en ejecución. En caso de fallo, el SW de HA automáticamente reinicia la VM que falló en un HW alternativo


Análisis de pros y contras:
Transición tras caída de la máquina física por perdida de corriente o similar: 
Maneja de forma fluida tanto la caída de la física como de la virtual 
Transición por Fallo o Corrupción en almacenamiento: 
Al utilizar un almacenamiento compartido no es posible la transición 
Transición por caída de Caché: 
Puede configurarse pero depende del sistema de VM 
Tiempo de recuperación en transición: 
Pueden ser minutos 
Sincronización de ficheros externos: 
Todos los ficheros están disponibles por ambos nodos 

Mirroring
Un mirror consiste en dos sistemas físicos Caché independientes, llamado failover members. Uno de los miembros tiene el rol de primario, el otro tiene el rol de backup. Los datos se replican desde el primario hacia el backup Es necesario utilizar una dirección IP virtual que es compartida por ambos nodos


Análisis de pros y contras:
Transición tras caída de la máquina física por perdida de corriente o similar: 
Por defecto no hay fail-over si el nodo primario no es alcanzable, en otro caso requiere planificación y configuración 

Transición por Fallo o Corrupción en almacenamiento: 
Utiliza almacenamiento independiente y replicación a nivel lógico de manera que resuelve muchos casos de corrupción 

Transición por caída de Caché: 
Detección rápida y muy configurable 

Tiempo de recuperación en transición: 
Pueden ser segundos 

Sincronización de ficheros externos: 
Solo las bases de datos son replicadas automáticamente no los ficheros externos 

Conclusiones
Si podemos manejar la carga de todo el sistema en uno o dos servidores es razonable configurar nodos en fail-over. Pero si se necesitan ocho servidores, entonces duplicarlos puede resultar demasiado caro comparado con N+X

La decisión sobre la configuración depende del tipo de las transacciones que serán manejadas (integridad transaccional, secuencialidad, etc.). Con todo lo anterior se pone de manifiesto la necesidad de realizar análisis y pruebas de capacidad previos al posible despliegue

jueves, 31 de enero de 2013

JobPerConnection y PoolSize

En una entrada anterior hablamos del tamaño de grupo o PoolSize (http://blogdeensemble.blogspot.com.es/2011/06/aclarando-el-concepto-tamano-de-grupo.html) ahora hablamos de otro setting que está relacionado.

En el caso especial de los adaptadores basados ​​en TCP (TCP, HTTP, SOAP, etc) el valor del setting PoolSize tiene un comportamiento ligeramente diferente al habitual y depende de la configuración de JobPerConnection.

Si el setting JobPerConnection se establece en "false" hay uno y sólo un listener (BusinessService Job) para cualquier valor de PoolSize mayor que "0" (PoolSize igual a "0" impediría que este adaptador funcionase).

Si el setting JobPerConnection se establece en "true" y el setting PoolSize es mayor que "1", este sirve como un límite en el número de jobs de conexión simultáneos que pueden crearse. En el caso de que se alcance el límite de jobs, el listener no aceptará ninguna conexión más hasta que uno de los jobs de conexión existentes termine o muera. Adicionalmente, en el caso de JobPerConnection = "true" el valor "1" en PoolSize se usa para posibilitar la creación ilimitada de nuevos jobs (excepto el límite puesto por el sistema operativo).

El setting QSize es importante en este caso porque si Qsize es igual a "0" Ensemble no permitirá que el sistema operativo acepte (encole) una conexión si el listener ha aceptado ya una conexión.

En general la configuración por defecto JobPerConnection="true", PoolSize="1" y Qsize=100 siempre nos vendrá bien.

Lo gracioso es que todo esto no viene en la ayuda. Al menos hasta la versión actual 2012.2. Así que si habeis llegado aqui buscando más información sobre esto. Enhorabuena !!