Entradas con la etiqueta ‘cluster’

Como integrar tácticas de Alta Disponibilidad en infraestructuras virtuales

La virtualización de servidores permite a las empresas reducir el número de servidores físicos, en ocasiones en un ratio de 20 a 1. Cada Host físico es capaz de ejecutar múltiples cargas de trabajo en producción. Por lo tanto, en un entorno de virtualización somos muy dependientes de la disponibilidad de los Host sobre los que se ejecutan nuestras máquinas virtuales.

Dependiendo del tipo de empresa, es probable que necesiten que sus aplicaciones estén funcionando continuamente. Con el objetivo de garantizar una alta disponibilidad a nuestra aplicaciones, podemos utilizar una combinación de técnicas. Actualmente existen principalmente cuatro técnicas de hacer que las aplicaciones ejecutándose en nuestras máquinas virtuales estén siempre disponibles:

  • Clusters de Host físicos.
  • Clusters Guest Failover.
  • Clusters Network Load Balancing (NLB).
  • Máquinas virtuales tolerantes a fallos.

Cada una de estas opciones puede dar a nuestras máquinas virtuales un nivel específico de disponibilidad. La importancia de que una determinada aplicación esté siempre funcionando marcará el método a escoger.

Utilizar una configuración en cluster de alta disponibilidad (HA) nos permite poder tratar potenciales incidencias en nuestro entorno:

Protegemos el sistema de fallos en los Hosts físicos: en la mayoría de los sistemas de alta disponibilidad, cuando un Host falla las máquinas virtuales que ejecuta son migradas a otros Hosts (incurriendo en pérdida de servicio durante el reinicio de la máquina virtual); o las aplicaciones que se ejecutan dentro de una máquina virtual son movidas a otras máquinas virtuales (resultando en una menor pérdida de servicio). También nos podemos proteger contra pérdidas de servicio utilizando técnicas como la tolerancia a fallos. Por ejemplo VMware tiene el producto VMware Fault Tolerance que nos permite tener una máquina virtual imagen protegiéndonos frente a corrupción de datos y pérdidas de servicio.

Podemos seguir ejecutando aplicaciones durante períodos de mantenimiento de los Host físicos: las máquinas virtuales serán migradas a los otros Hosts disponibles en el cluster evitando pérdidas de servicio.

Dinámicamente podemos mover las cargas de trabajo de una máquina a otra: nos aseguramos de que las aplicaciones se ejecutan con un rendimiento óptimo.

¿Qué estrategia HA es mejor?

La importancia de la aplicación para la empresa determinará qué método deberemos utilizar. Como mínimo deberemos configurar un cluster HA entre los Host físicos.

 

Un cluster HA nos permitirá obtener dos niveles de continuidad de servicio:

  • Ejecución no-continua de máquinas virtuales. Si un Host falla, todas las máquinas que está ejecutando serán transferidas a otros hosts reiniciándose automáticamente.
  • Ejecución continua de máquinas virtuales durante operaciones de mantenimiento. Podemos transferir las máquinas a otros hosts disponibles sin pérdida de servicio.

Single-Site y Multi-Site Clusters

Los clusters single-site se basan en la utilización de almacenamiento compartido. Por ejemplo, VMware utiliza dos tecnologías para construir un cluster de alta disponibilidad: HA y su sistema de ficheros VMFS (sistema de ficheros que permite a múltiples hosts físicos conectarse al mismo contenedor de almacenamiento). VMFS requiere un sistema de almacenamiento SAN (iSCSI o Fiber Channel) o NFS. Los clusters VMware pueden soportar hasta 32 nodos.

Los sistemas Citrix también utilizan un sistema de almacenamiento compartido y pools de recursos. A diferencia de otros sistemas que se basan en un sistema de base de datos para gestionar la alta disponibilidad, cada Host Citrix XenServer almacena su propia copia de la configuración de pool de recursos. De este modo se elimina un potencial punto de fallo. Al igual que VMware, los clusters Citrix soportan hasta 32 nodos.

Por último, Microsoft Hyper-V utiliza la tecnología Windows Server 2008 Failover Clustering para crear clusters HA. Los cluster Hyper-V single-site requieren un sistema de almacenamiento compartido y soportan hasta 16 nodos. Hyper-V también soporta clusters multi-site que abarcan más de una localización física. De este modo podemos hacer frente a desastres que afecten a uno de nuestros centros de datos. Para dar soporte a clusters multi-site, Hyper-V soporta tecnologías DAS (no requiere almacenamiento compartido) que deben ser sincronizadas mediante herramientas de replicación.

En todos estos sistemas, cuando un cluster detecta que un nodo falla de manera completa, el servicio de cluster mueve las máquinas virtuales a otros nodos disponibles. A diferencia de una migración en vivo entre nodos, este proceso de migración reinicia la máquina virtual en el nuevo nodo, incurriendo en una pérdida de servicio.

Hay que recordar que se deben tener recursos disponibles en cada Host físico del cluster para soportar el movimiento de máquinas virtuales. Por ejemplo, VMware muestra un mensaje de error si los recursos disponibles no son suficientes.

Clusters tolerantes a fallos

Como hemos comentado, un cluster a nivel de Host no incluye a las aplicaciones que se están ejecutando en las máquinas virtuales. Por lo tanto, no se asegura que la aplicación se ejecute en caso de que un Host falle.

Algunas aplicaciones como Microsoft Exchange no se comportan adecuadamente bajo este modelo y pueden incurrir en pérdidas de datos cuando tiene lugar una transferencia entre Hosts. Para este tipo de aplicaciones tenemos que pensar en construir clusters de alta disponibilidad a nivel de máquina virtual. De este modo aseguraremos la disponibilidad y estabilidad de nuestras aplicaciones en caso de fallo físico o de aplicación.

Estos clusters tolerantes a fallos trabajan sólo para cargas de trabajo stateful. Para cargas de trabajo stateless tendremos que utilizar clusters NLB, también soportado a nivel de capa de máquina virtual.

Para construir este tipo de soluciones, tendremos que preparar complejas configuraciones a nivel de máquina virtual (ver imagen inferior un ejemplo). A diferencia de otros fabricantes, VMware dispone del producto Fault Tolerance. Gracias a este producto creamos imágenes en vivo de máquinas virtuales que se sincronizan continuamente permitiéndonos obtener de manera sencilla alta disponibilidad a todos los niveles.

Share

vSphere Storage DRS. Nueva funcionalidad de vSphere 5

Ayer os presentábamos a grandes rasgos las mejoras introducidas en la versión 5 de vSphere. Hoy vamos a profundizar en una de las innovaciones introducidas: Storage DRS.

En vSphere 4 apareció el concepto DRS (Distributed Resource Scheduler) aplicado a procesamiento. Esta característica permitía de manera automática distribuir la ejecución de las máquinas virtuales entre los hosts disponibles en función de la carga de éstos.

Ahora VMware aplica el concepto DRS al almacenamiento. De este modo, vSphere es capaz de alojar dinámicamente máquinas virtuales en un determinado «storage» en función de las entradas/salidas (I/O) y el espacio ocupado en el mismo. De este modo se reducen los esfuerzos en las decisiones a tomar en el alojamiento de una determinada máquina virtual así como en la monitorización del almacenamiento.

Para poder aplicar DRS, vSphere 5 introduce el concepto de cluster de datastore. Un cluster de almacenamiento es, desde la perspectiva de un administrador, un conjunto de discos (datastores) agregados en una única unidad. Cuando se crea un cluster de este tipo, Storage DRS puede administrar los recursos de almacenamiento de igual manera a como hace DRS a nivel de procesamiento para un cluster de hosts, balanceando la carga entre los discos disponibles en el cluster.

En la siguiente imagen se muestra un cluster de 12TB formado por cuatro datastores de 3TB.

 

En este esquema, durante la creación de una máquina virtual es posible seleccionar un cluster DRS como destino para almacenar sus discos virtuales. A continuación, el sistema es capaz de detectar, en función de la carga en I/O y espacio utilizado, el datastore sobre el que se almacenará inicialmente la máquina virtual. De este modo se minimiza el riesgo de cuellos de botella e impactos en el rendimiento por agregar una nueva máquina virtual.

Storage DRS también permite crear reglas de afinidad (affinity rules) que controlan que discos virtuales deberían estar alojadas o no en un mismo datastore dentro de un cluster. Aunque por defecto, los discos virtuales de una misma máquina virtual se alojan juntos en el mismo datastore, existen tres tipos de reglas de afinidad:

  • VMDK Anti-Affinity: discos virtuales de una máquina virtual con múltiples discos virtuales son alojados en diferentes datastores.
  • VMDK Affinity: discos virtuales son alojados juntos en un mismo datastore.
  • VM Anti-Affinity: dos máquinas virtuales específicas, incluídos sus discos, son alojados en diferentes datastores.

 

Share

Bienvenido a Virtualizamos

Virtualizamos es un proyecto de la empresa nerion que nace con el objetivo de convertirse en un portal de referencia en el mundo de la virtualización y el cloud computing.
Suscripción a Virtualizamos
Entradas antiguas por mes
Twitter
nerion - Registro Dominios, Hosting y Housing Profesional