DRS

VCAP – Sección 3 – implementar y mantener soluciones complejas de DRS

Que tal gente, continuando con los temas de VCAP-DCA410 nos toca hablar de DRS, tocando temas especifico como reglas de afinidad, anti afinidad, DPM, entre otras.

Reglas de Afinidad y Anti-afinidad

Las reglas de afinidad y anti afinidad nos permiten especificar ciertas políticas en cuanto a que VMs se ejecutan en los hosts ESX/ESXi que pertenezcan a nuestro cluster de DRS. Con la llegada de vSphere se agregó un nuevo tipo de regla conocida como VM to Host affinity rule, tenemos los siguientes tipos de reglas:

  • VM-VM affinity rule: Básicamente aquí nosotros podremos definir que máquinas deberán ejecutarse en el mismo hosts por cuestiones de performance.

  • VM-VM anti-affinity rule: Aquí nosotros podremos definir que maquinas no queremos que ese ejecuten en un mismo Host ESX/ESXi, esto es perfecto para poder mantener separadas vms que consuman una gran cantidad de recursos, por lo cual no sería una buena idea que se ejecutaran en un mismo host.

  • VM to Host: Con estas reglas lo que podemos lograr es definir en que host(s) no se deberán ejecutar las maquinas virtuales seleccionadas. Aquí requerimos crear grupos tantos de VMs como de Hosts para poder definir las reglas,

Grupo de VMs

Grupo de Hosts

  • Una vez creados los grupos tanto de VMs como de hosts, solo es cuestión de crear nuestra regla, en ella podemos definir lo que se conoce como reglas preferenciales y requeridas, vamos a conocer que reglas son preferenciales y cuales son requeridas:
  1. preferenciales (preferential): “Should run on hosts in group” , “Should Not run on hosts in group” , aquí básicamente diremos que grupo de vms tendrán (o no tendrán) que ejecutarse en un cierto grupo de hosts, esta regla puede ser violada en casos específicos. Ejemplo creamos una regla para mantener ciertas vms ejecutándose en distintos grupos de servidores físicos, Grupo A y Grupo B. En el caso que el Grupo A tenga problemas y no pueda ejecutar dichas vms, estas podrán ser ejecutadas en el Grupo B.
  2. Requeridas (required):“Must run on hosts in group”, “Must Not run on hosts in group” , en este caso nosotros podemos definir un grupo de VMs que deberán ejecutarse (o no ejecutarse) en un grupo de hosts. Estas reglas no pueden ser violadas en ningún caso.

Aquí como mejor practica debemos de tener en cuenta que para permitir que DRS se encargue de mejor manera de los recursos que tenemos en nuestro cluster debemos de utilizar la menor cantidad posible de reglas “required”  ya que limita la capacidad de selección en cuanto a hosts se refiere para la distribución de cargas. La ocasión en la que visto el uso de estas reglas es para mantener máquinas ejecutándose en un host debido a que el licenciamiento de dicho software así lo requiere.

identificar requerimientos para el uso de DPM

DPM (Distributed Power Management) esta capacidad de VMware fue liberada desde la versión 3.5, esta funcionalidad trabaja de la mano con DRS continuamente monitorea nuestro cluster para determinar el uso de nuestros hosts (periodos de 20 minutos), en el caso que el uso de los mismos se vea reducido y se tenga la posibilidad de consolidar las cargas en un numero menor de hosts este se encargará de migrar las todas las vms que se ejecuten en los hosts que se necesiten poner en modo “standby”.

Con esto nos ahorraremos consumos eléctricos y hace un mejor uso de los servidores encendidos. DPM requiere al menos una de las siguientes tecnologías para poder operar:

  1. Intelligent Platform Management Interface (IPMI)
  2. Integrated Lights-Out (iLO)
  3. Wake on LAN (WOL)

En el caso que se nuestros servidores soporten las 3 tecnologías el orden de precedencia sera ipmi,iLO,WOL.

¿Qué debo configurar para permitir el funcionamiento de DPM?

Debemos configurar los parámetros de red para poder accesar nuestros servidores ya sea por IPMI o iLO:

Una vez configurados los parámetros en el BIOS, debemos también configurarlos dentro de nuestros Hosts ESX/ESXi, para esto vamos a Configuration>Power Management>”Properties…”:

En el caso de utilizar WOL (wake on lan), debemos habilitar dicha funcionalidad en el BIOS de nuestro servidor.

¿Cómo puedo verificar el funcionamiento de DPM?

  • Verificar que nuestro host es capaz de entrar en modo Stand-by

  • Reducir el consumo de recursos para que EVC consolide las vms en menos servidores.

¿Cómo configuro los niveles de DPM?

Seleccionamos nuestro cluster, click derecho>edit settings y vamos a la sección de Power Management. Aquí veremos que al igual que DRS tenemos distintos nivels  y tresholds para la aplicación de DPM:

Tenemos la capacidad de definir estos niveles directamente por cada host, para eso vamos a “Power Management>Host Options”:

Identificar requerimientos, baselines y componentes de EVC

EVC (Enchanced VMotion Compatibility) esta funcionalidad nos permite utilizar CPUs de distintas familias mediante el uso de plantillas o baselines de procesadores. Estos baselines muestran y/o esconden ciertas instrucciones de los CPUs para que en el caso que tengamos un cluster con distintas familias de cpus podamos realizar VMotion sin problemas. Tenemos baselines para hosts con procesadores AMD e Intel:

Requerimientos para EVC:

  • Misma fabricante de procesadores sea AMD o Intel.
  • Esx 3.5 U2 en adelante
  • Tener habilitado AMD-V en el caso de AMD y para Intel Intel-VT
  • Habilitar AMD No eXecute (NX) y para Intel eXecute Disable (XD)

En el siguiente kb de VMware podemos encontrar las compatibilidades entre procesadores:

Enhanced VMotion Compatibility (EVC) processor support

Entender el algoritmo de DRS basado en el tamaño de nuestros slots

Honestamente aquí yo les recomendaría leer el articulo de Dunca Epping “DRS Deepdive”, para mi guest no existe mejor y completa explicación de como funciona DRS.

Planear correctamente los recursos que daremos a cada VM para optimizar DRS

Aquí solo me gustaría comentarles que siempre debemos considerar la menor cantidad de recursos posibles para una máquina virtual mientras cumpla con los recursos requeridos para poder dar el servicio, dado que entre mas recursos de memoria  agregamos el overhead (cantidad de memoria requerida del lado de nuestro host ESX/ESXi para poder ejecutar dicha world o proceso de la VM) se ve aumentado y también aumenta el tamaño de nuestro slot size.

Recordemos que no por tener una gran cantidad de recursos debemos dar una alta cantidad de recursos a cada VM ya que esto nos traerá problemas a la larga.

Niveles de automatización DRS a nivel VM

En un cluster habilitado con DRS tenemos niveles de automatización a nivel cluster y a nivel VM, nosotros podemos hacer un “override” del valor que tenemos asignado al cluster para una o varias vms, para esto editamos nuestro cluster y en la sección de DRS vamos a virtual machine options:

Configurar alarmas para DRS y DPM

Para configurar alarmas seleccionamos nuestro cluster y vamos a la pestaña de “alarms”, donde tendremos todas las definiciones de las alarmas disponibles:

¿DRS para nuestro almacenamiento?

¿Alguna vez han querido darle cierta preferencia a una vm en cuanto al vmfs se refiere? Bueno, pues esto puede ser una realidad, en varios posts en la web se ha hablado de una nueva posible característica que VMware incluirá en un próximo release de vSphere ¿El nombre? Storage I/O Control (SIOC), les recomiendo que lean el post del gurú de performance en VMware Scott Drummonds, que lo pueden encontrar en este link : http://vpivot.com/2010/05/04/storage-io-control/#more-515.

Todos sabemos que muchas veces la perdida de performance en una infraestructura VMware se debe a una mala configuración de nuestro almacenamiento , o a que el mismo no tiene la capacidad de entregar la cantidad de IOPS que nuestra infraestructura requiere , SIOC lo que nos permitirá es definir shares de disco pero esta vez no a nivel servidor ESX, sino a nivel arreglo, es decir esto aplicara para todos los servidores ESX que estén accediendo a un VMFS determinado en algún arreglo de discos esto lo podemos ver en las siguientes imágenes :

En esta primera  imagen podemos ver claramente que la distribución de nuestro arreglo está totalmente dispareja, la vm C está teniendo 50% del Queue del almacenamiento, mientra s las otras maquinas se reparten el otro 50%.

En esta segunda imagen podemos ver él como SIOC en base a los shares que tenemos configurados para cada máquina virtual , asignará los respectivos porcentajes de queue a nuestras vms, repartiendo el acceso al arreglo de una manera más equitativa.

SIOC se basará en la latencia que está presentando nuestro vmfs , y esto como nos comenta Scott , se basa en el total de latencias que están teniendo todas las vms que residen en dicho vmfs. Cuando este valor sobrepase el valor que nosotros configuramos como tope, se reducirá el acceso a nuestro arreglo a las maquinas con menos shares, permitiendo así que las maquinas criticas puedan mantener un buen funcionamiento.

Recuerden que esta funcionalidad no ha sido revelada oficialmente, hasta ahora solo se ha comentado que se está trabajando en ella,  aquí les dejo un link de vmware donde pueden lver una presentación del vmworld 2009 sobre SIOC:

http://vmworld.com/docs/DOC-3855