Cargando

Ir a contenido


A fondo con la disponibilidad en VMware vSphere

Una palabra troncal en el mundo de la virtualización es consolidación. Esta tecnología nos permite utilizar al máximo los recursos disponibles quitando la limitación de 1:1 (Un servidor / Un Sistema).

Síguenos!

Comentarios Recientes



Dependiendo qué tan potente sea el equipamiento que disponemos y los recursos necesarios para nuestros sistemas, tendremos un ratio promedio de máquinas virtuales por servidor.

 

Pongamos por ejemplo el mantenimiento programado de un servidor en el Centro de Cómputos. Algunos años atrás si éste no era parte de un clúster, el sistema contenido en el equipo quedaría fuera de línea, por consecuente los usuarios también se verían afectados y/o el personal involucrado en el mantenimiento debía trabajar en ventanas de tiempo reducidas (por no decir incómodas).

 

En el caso de un ambiente virtualizado, las máquinas virtuales simplemente pueden “moverse o migrarse” a otro integrante de un clúster y es posible apagar el equipo para trabajar en él. Problema resuelto.

 

Comencemos a ver situaciones donde la falta de servicio no es programada.

 

Monitoreo de máquinas virtuales y aplicaciones

Cada vez que creamos una máquina virtual es recomendable instalarle un compendio de aplicaciones y drivers que optimizan el comportamiento del hardware virtual en su totalidad (disponible para Windows, Mac OS, Linux y otros SO). Estas herramientas, llamadas VMTools, entre otras cosas incluyen la posibilidad de que el host realice un monitoreo de la máquina virtual (a través de heartbeats, como en los clúster). De no responder en un período determinado, reinicia su Sistema Operativo.

 

Un caso similar sucede con el monitoreo de aplicaciones, pero primero es necesario obtener el SDK apropiado (o estar usando una aplicación que soporte Monitoreo de Aplicaciones de VMware).

 

Pero... ¿qué sucede si la falla es de hardware?

 

El clúster anteriormente mencionado es la primera capa de la solución.

 

Almacenamiento compartido
Donde todos los integrantes del clúster tienen acceso a las máquinas virtuales.

 

Teaming de red
Ante la falla de una placa las restantes continúan administrando el tráfico.

 

Múltiples caminos (multipathing)
Para el almacenamiento no sólo optimizarán el acceso sino también le darán redundancia.

 

A grandes rasgos, estas tres tecnologías mitigan el tiempo en que nuestra información es inaccesible. Ahora, dependiendo del licenciamiento que tengamos, también podremos disponer de dos funcionalidades muy interesantes: Alta Disponibilidad (HA) y Tolerancia a Fallos (FT).

 

En ambos casos requerimos de un clúster con almacenamiento compartido. Sin necesidad de instalar software adicional, es posible habilitar y configurar HA de forma tal que ante la falla de un servidor o máquina virtual en el clúster automáticamente se iniciará en otro integrante del mismo. Vale aclarar que HA no está pensado para VMs (máquinas virtuales) de misión crítica. Así que el tiempo estimado sin servicio será: "Arranque del Sistema Operativo + Inicio de los servicios".

 

Cantidad de fallas de host soportadas por el clúster

Tenemos X cantidad de máquinas virtuales distribuidas en Y servidores de un clúster.

 

¿Cuántos hosts pueden fallar sin afectar la disponibilidad y performance de nuestro entorno virtual?

 

Es posible configurar HA para que soporte una cantidad específica de fallos de servidores, asegurando que en la recuperación haya suficientes recursos restantes.

 

HA divide en porciones los recursos disponibles de un clúster teniendo en cuenta CPU y RAM configurada y consumida por nuestras máquinas virtuales de una forma muy conservativa. Toma la mayor reserva de CPU configurada de cualquier VM en cada host del clúster y luego la mayor reserva de memoria y su exceso. De no haber reserva configurada, tomará un mínimo de 32 Mhz por VM para CPU y 0 Mb de RAM + su exceso.

 

Con estos números asume que cada máquina virtual utiliza consumirá esa CPU y memoria, entonces genera un valor llamado tamaño de slot (slot size). Con este valor, se determina cuantos slots hay disponibles/utilizados por cada host.

 

 

 

 

El problema se plantea cuando por ejemplo tenemos una sola máquina con una gran reserva de CPU y memoria. Al tomarse reservas configuradas, es muy probable que el resto de nuestras máquinas virtuales realmente no necesiten esos recursos, resultando en una menor cantidad de slots para nuestro clúster.

 

Porcentaje de los recursos del clúster como capacidad para fallas

A diferencia de la opción anterior, esta va muy bien cuando se dispone de VMs con configuraciones de CPU y memoria altamente variables.

 

Es posible configurar valores porcentuales de CPU y memoria por separado, siendo de esta forma aún más flexible y por consecuente ahorra recursos. Por lo general, este es el método preferido para configurar HA.

 

Hosts para conmutación por error

Este es la típica configuración de clúster en espera. Principalmente se da esta opción ya que algunas organizaciones mantienen políticas que indican que debe haber servidores en espera ante cualquier desastre. Dado que VMware hace una buena administración de la tolerancia a fallas, tal vez esta sería la opción cuando los recursos abundan… pero definitivamente, no es la mejor.

 

vMotion: Migraciones en vivo

La migración en vivo permite mover máquinas virtuales en funcionamiento de un servidor físico a otro manteniendo su conexión de red e identidad. Se transfiere la memoria activa (los procesos en ejecución) a través de la red de alta velocidad. Todo el proceso lleva menos de 5 segundos en una red de gigabit.

 

Es posible mover la VM, los archivos que ésta utiliza o ambos y el procedimiento se puede hacer con la máquina encendida o apagada. En este último caso, lo llamamos “migración en frío” y si la máquina se encuentra en ejecución, lo llamaremos vMotion.

 

Usos y beneficios de vMotion
  • Reorganización de las VMs, optimizando de esta manera los recursos. Quitarlas de servidores con tendencias a fallas o saturados.
  • Optimización automática de los recursos disponibles (trabajo en conjunto con Dynamic Resource Scheduler o DRS).
  • Hacer mantenimiento de la infraestructura subyacente sin necesidad de programación de mantenimiento o interrupción del funcionamiento del negocio.

 

Cada uno de los componentes del estado de la VM se maneja de forma diferente durante la migración. La configuración general es lo más simple, no se mueve sino que se re-crea en el equipo destino.

 

Como el disco no puede ser re-creado en tan poco tiempo, es necesario disponer de almacenamiento compartido. El estado actual de la memoria se copia gradualmente hacia el host destino, al finalizar la copia se comparan las diferencias existentes que surgieron durante la migración, se congela el estado de la VM origen y activa el Sistema Operativo en la VM destino.

 

Debido a que en algunos casos la opción de reiniciar la máquina no es lo ideal, para misión crítica disponemos de la Tolerancia a Fallos (Fault Tolerance). Lo que se desea en estos casos que en ningún momento deje de funcionar, inclusive si su host falla. La única forma que hay para que esto sea posible es si la VM estuviera funcionando en dos lugares al mismo tiempo. Se configura a nivel de máquina virtual y generará una copia exacta de la VM, manteniéndola replicada en todo momento al 100% en otro servidor, por lo que ante una falla de hardware simplemente continuará funcionando su gemela sin pérdida de información alguna. Interesante ¿no?

 

 

 

 

Si sólo de recursos se tratara, habilitaríamos FT en todas las máquinas virtuales de nuestro centro de cómputos, pero en versiones anteriores de vSphere nos encontrábamos con algunas limitaciones, la más importante: No era posible habilitar FT en máquinas que utilizaran más de un procesador virtual. Por suerte, en la última versión del producto, soporta hasta 4 procesadores virtuales simultáneamente por máquina protegida, de todas formas habrá que considerar el licenciamiento:

 

El número de vCPUs soportador por una VM con FT habilitado está limitado por el nivel de licenciamiento adquirido para vSphere.

 

Fault Tolerance es soportado de la siguiente manera:

  • vSphere Standard y Enterprise. Permite hasta 2 vCPUs.
  • vSphere Enterprise Plus. Permite hasta 4 vCPUs.

 

Ese no es el único requerimiento del sistema.

 

Almacenamiento
Las VMs deben poseer almacenamiento compartido. No es posible utilizar RDM físico (Raw Devide Mapping).

 

Red
Es necesario disponer de al menos dos placas virtuales (vmnics), una para vMotion y la otra (de de 10 gbps) para FT Logging. Es un nuevo requerimiento de la versión 6 (previamente, se necesitaban placas de 1 gbps)

 

Procesador
Los procesadores y Sistemas Operativos deben ser compatibles con FT (y entre ellos).

 

Limitaciones
  • No es posible tomar instantáneas (snapshots) de las VMs que estén siendo protegidas con FT y los mismos deben ser eliminados previo a la habilitación de esta función.
  • Discos virtuales (VMDK) mayores a 2 Tb.
  • Existe una lista de dispositivos y características específicas en la documentación de VMware.

 

Y también existe una limitación en la cantidad de VMs por servidor: un máximo de 4 máquinas protegidas por host u 8 vCPUs protegidos (al límite que se llegue primero). Estos máximos incluyen la máquina primaria y secundaria (y vCPUs)

 

Diferencias entre FT legacy (anterior) y el actual

 

IPv6
Legacy FT = No soportado por las placas de red configuradas para FT logging

FT = Soportado

 

APIs vStorage – Backup con Data Protection
Legacy FT = No soportado

FT = Soportado

 

Disco virtual
Legacy FT = EZT (Eager Zeroed Thick)

FT = Todos los tipos, incluyendo thick y thin

 

Redundancia vmdk (disco virtual)
Legacy FT = Copia única

FT = La máquina Primaria y Secundaria mantienen copias independientes, esto permite almacenarlas en distintos datastores e incrementar la redundancia

 

Ancho de banda placa de red
Legacy FT = Se recomienda una 1-Gb NIC dedicada

FT = Se recomienda una 10-Gb NIC dedicada

 

CPU y compatibilidad de host
Legacy FT = Requiere el mismo modelo de CPU y familia. Versiones de vSphere casi idénticas

FT = Los CPUs deben ser compatibles con vSphere vMotion o EVC. La versión de vSphere debe ser compatible con vSphere vMotion

 

Activar/Desactivar FT con la máquina en funcionamiento
Legacy FT = No siempre soportado

FT = Soportado

 

Recordar que FT protege ante la falla de hardware del servidor, no fallas de Sistemas Operativos o aplicaciones.

 

vCenter Server Watchdog es una funcionalidad embebida de la versión 6.x. Periódicamente verifica el estado de los servicios que componen vCenter, reiniciará los procesos de administración o la VM si fuera necesario.

 

 


TE PUEDE INTERESAR

ÚLTIMAS NOTICIAS


1 Comentarios

Me ha encantado el artículo. Esclarecedor para tema vSphere y los que estamos dentro de este mundo de virtualizacion entiende porque lo digo.
No esperes más y entra en Solvetic
Deja tus comentarios y aprovecha las ventajas de la cuenta de usuario ¡Únete!
Suscribirse