vSphere y Openstack, entendiendo su interacción – parte 1

Screen Shot 2013-12-10 at 10.39.06 PM

Que tal gente, el día de hoy les voy a hablar sobre como Openstack y VMware trabajan a nivel del hipervisor. En este caso no estaremos hablando de la integración que puede llegar a tener Openstack en otros productos del stack de VMware como lo puede ser vCAC.

Les sugiero leer mi articulo sobre que es y que no es Openstack, lo pueden encontrar en esta liga:

Openstack… ¿Que es?, ¿Que NO es?

¿Como interactuan vSphere y Openstack?

Tenemos dos distintos modos para interactuar con vSphere desde Openstack hablando desde la perspectiva de nova-compute, podemos hacerlo a nivel de servidor ESXi o a nivel de vCenter. Los siguientes drivers nos permiten realizar esto:

  • vmwareapi.VMwareESXDriver – este driver permite tener granularidad a nivel de ESXi, es decir, no entiende construcciones lógicas como lo puede ser un cluster y claramente tampoco puede hacer uso de servicios distribuidos como HA, DRS, etc. Este driver tiene poco desarrollo debido a que no permite utilizar todas estas capacidades interesantes.
  • vmwareapi.VMwareVCDriver – este driver nos permite utilizar vCenter Server, fue creado por VMware y liberado en la versión Grizzly de Openstack. Permite utilizar servicios como DRS y HA debido a que toda la “complejidad” que existe a nivel de vCenter+ESXi esta siendo escondida hacia nova-compute, en el release de Havana se soportan ambientes “multi cluster”. Nova-compute ve a vCenter Server y sus distintos clusters como una sola instancia de computo, por lo que quien esta a cargo de los servicios distribuidos a nivel de vSphere es vCenter.

Como pueden ver el camino a tomar es utilizar el driver de vmwareapi.VMwareVCDriver ya que nos permite beneficiarnos de algunas capacidades distribuidas que nos ofrece vSphere.

 

Entendiendo de mejor manera el driver “vmwareapi.VMwareVCDriver”

Screen Shot 2013-12-10 at 11.48.15 PMComo podemos ver en la imagen, tenemos en la parte superior algo llamado “OpenStack Compute Scheduler”, que básicamente es el encargado de decidir donde colocar las cargas de VMs, o en otras palabras que nodo de computo debe de ejecutarla. En este caso podemos ver que el scheduler tiene a su “cargo” 2 distintos nodos de computo o dos instancias del servicio de nova compute, de igual manera noten que aquí ya se muestran dos clusters manejados por una sola instancia de nova-compute (a través de el driver vmwareapi.VMwareVCDriver) esto lo podemos ver en el archivo nova.conf:

Screen Shot 2013-12-11 at 9.26.49 AM

Que si lo vieramos desde la perspectiva de vSphere sería así

Screen Shot 2013-12-12 at 12.40.32 AM

En mi ambiente pueden ver que estoy utilizando el appliance virtual de VOVA ya con Havana, permitiéndome utilizar este esquema desde solo una instancia de nova-compute.

Para tomar decisión de como coloca las cargas o instancias de VMs en las distintas unidades de computo Nova scheduler toma en cuenta múltiples criterios, a estos se les conoce como “filtros” y “pesos”. Podemos notar en el archivo de configuración “nova.conf” que tenemos activo el driver que soporta estos filtros y pesos:

Screen Shot 2013-12-11 at 10.07.44 AM Este driver “scheduler_driver = nova.scheduler.filter_scheduler.FilterScheduler” soporta múltiples filtros para decidir como colocar las cargas de VMs. Por default utiliza los siguientes filtros, que deben de ser agregados al archivo de configuración “nova.conf”:

scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter
  • RamFilter – Este filtro identifica solo aquellos nodos de computo que tienen una cantidad de RAM disponible que cumpla con el criterio, por defecto tiene un criterio de 50% de “overcommit”, tomando el ejemplo de la documentación si tuvieramos un host ESXi con 1GB de RAM con la configuración por defecto de este filtro podriamos tener hasta 1.5GB utilizados en el host ESXi. El valor utilizado o permitido de overcommit se dicta a través del archivo de nova.conf agregando la línea:

ram_allocation_ratio=X

  • ComputeFilter –Este filtro define que nodos de computo tienen recursos para ejecutar la instancia de VM y que son compatibles con la misma, es decir, si es una instancia de VM para KVM claramente no podría ser ejecutada en el nodo de computo de vSphere.
  • AvailabilityZoneFilter este filtro definirá que “Zonas de disponibilidad” son candidatas para ejecutar la instancia de VM. El termino “Availability Zone” fue algo dificil de comprender para mi viniendo de un mundo de VMware, básicamente nos permite definir un grupo de servidores en base a su disponibilidad y donde se encuentra geográficamente. Con estos availability zones un usuario puede decidir en que zona encender su VM, por ejemplo, tenemos las zonas de disponibilidad “Mexico Sur” y “Mexico Centro” y cada una de estas zonas podrían tener distintas capacidades, solo sería cuestión de darle al usuario la zona donde estaría iniciando sus VMs para tener los SLAs definidos. (no se preocupen mucho por esto en este momento ya que estaré escribiendo un articulo sobre la arquitectura de OpenStack).

Aquí esta una imagen gráfica sobre este proceso:

filteringWorkflow1

Existen múltiples filtros extras que podemos utilizar con este driver, estaremos revisando en posts futuros como funcionan. Después de que el scheduler paso a los nodos de computo a través de estos filtros y que se seleccionaron los nodos que cumplen ahora es momento de tomar un segundo criterio, que se forma a partir de dos conceptos “Weight” y “Cost”, esto permite obtener un valor o score númerico de cada host (Conocido como weight, seleccionando aquel con el valor mas bajo)para decidir porfin donde se colocará dicha instancia de VM. Se aplican tres criterios para medir a los hosts:

  • nova.scheduler.least_cost.compute_fill_first_cost_fn este algoritmo toma en cuenta la cantidad de memoria RAM consumida en los hosts, por defecto intentará llenar aquellos hosts con mayor consumo (lo cual le daría un mejor weight al dichos hosts) aunque tenemos la opción de tener un esquema donde se tome en cuenta a aquellos hosts con menor consumo para poder esparcir la carga antes de estar saturando a los hosts, para esto tenemos que definir en el archivo nova.conf un valor “negativo” o que vaya restando weight.
compute_fill_first_cost_fn_weight=-1.0
  • nova.scheduler.least_cost.retry_host_cost_fn – esta función le va agregando peso a los hosts que han presentado problemas para instanciar una VM, esto permite que los hosts vayan siendo “ignorados” y que no se trate de ejecutar VMs en ellos.
  • nova.scheduler.least_cost.noop_cost_fn esta función devuelve un valor de “1” en cuestión de costo para todos los hosts por lo que no realiza ninguna selección. Esto generalmente no se utiliza.

 

vCenter, DRS y nova-scheduler

Con estos dos procesos se determina el mejor nodo de computo para ejecutar la VM, en el caso de VMware utilizando el driver vmwareapi.VMwareVCDriver estaría seleccionando entre los nodos de nova-compute, si revisáramos el caso de mi ambiente (ver imagen de cluster de vSphere) el appliance de VOVA es una instancia de nova-compute y controla 2 clusters, por lo que al analizar el único nodo de compto que tiene (que es la instancia de VOVA) decide hablar con vCenter para iniciar las VMs, una vez que habla con vCenter es decisión de vCenter donde colocarlas, en versiones anteriores a Havana, solo podíamos tener un cluster por vCenter pero en este caso tenemos soporte para múltiples clusters.

Haciendo pruebas en mi lab instanciando 6 distintas VMs desde Horizon (todas con el mismo perfil):

Screen Shot 2013-12-12 at 12.40.06 AMPude notar que una vez que se analizaban los nodos de computo (no había mucho que hacer puesto que solo era una VOVA) la distribución por vCenter era equitativa entre los hosts en diferentes clusters, es decir, una a una quedando 3 instancias de VMs en cada Host:

 

Screen Shot 2013-12-12 at 12.38.01 AM

Claramente aquí DRS no tenía mucho que hacer debido a que se trataba de un solo vESXi por cluster, pero si hubiéramos tenido 2 hosts ESXi por cluster se habrían distribuido tomando decisiones de DRS.

Tengo como tarea investigar una vez que se decide en que nodo de computo  debe de ir la VM, hablando de vSphere con múltiples clusters, como es que se decide vCenter a que cluster irá cada VM (ya que DRS no aplica fuera de un cluster).

 

Fuentes:

http://docs.openstack.org/trunk/openstack-config/content//costs-and-weights.html

http://docs.openstack.org/developer/nova/devref/filter_scheduler.html#weights

https://www.ibm.com/developerworks/community/blogs/e93514d3-c4f0-4aa0-8844-497f370090f5/entry/openstack_nova_scheduler_and_its_algorithm27?lang=en

http://cloudarchitectmusings.com/2013/06/26/openstack-for-vmware-admins-nova-compute-with-vsphere-part-2/

Leave a Reply