¿Porque 100 VMs x host en Horizon View & VSAN?

Que tal gente, el día de hoy voy a explicar algo que me han preguntado en varias ocasiones, ¿Porque se tiene un “limite” de 100 VMs por host al pertenecer a un cluster de VSAN en ambientes de Horizon View?

Primero tenemos que entender uno de los principios básicos de VSAN, que es el como se almacenan los datos. VSAN es un sistema de almacenamiento basado en objetos donde se asegura la disponibilidad, rendimiento y otras características de la información que vive en el cluster a través de la distribución de componentes de estos “objetos” almacenados.

VSAN, objetos y componentes

Como lo comente antes, VSAN es un sistema de almacenamiento basado en objetos. Este tipo de sistemas de almacenamiento brindan alta disponibilidad a los datos que viven en ellos debido a que distribuyen copias (en caso de VSAN “componentes”) de la información en múltiples nodos del cluster (arquitectura RAIN o Redundant Array of Independent Nodes), en este caso VSAN no es diferente. Vamos a darle un vistazo rápido a que es un objeto y que en un componente:

Screen Shot 2014-12-30 at 1.51.45 AM

  • Objetos – En el caso de almacenamiento basado en objetos estos sustituyen a las construcciones lógicas que todos conocemos como LUNs (Logical Unit Number), por lo que vienen siendo el elemento fundamental de almacenamiento para VSAN y otras ofertas en el mercado. Estos “objetos” son compatibles con instrucciones SCSI y se crean bajo demanda con un tamaño dependiendo de la información que se estará almacenando, un ejemplo sería un VMDK, si creamos un VMDK de 40GB VSAN estará creando un objeto en su datastore para almacenar ese VMDK, en este caso VSAN siempre utiliza Thin Provisioning a menos que utilicemos capacidad de “object space reservation” (que en realidad es mas complejo que Thick provisioning y me gustaría platicar mas a fondo en un articulo futuro). Estos objetos están compuestos por “componentes” o copias de los mismos objetos, también lo podríamos comparar con un RAID1 o “mirror” . Se pueden tener distintos tipos de objetos en VSAN, los mas comunes son:- VMDKs
    – Archivo Swap (.vswp)
    – Snaphots/Deltas
    – Carpeta de VM o “Home Directory”

    En las siguientes imagenes podemos ver este “objeto” (VMDK) creado tanto el el vSphere Web client como desde el RVC de VSAN:

Screen Shot 2014-12-30 at 2.07.13 AM

Vista desde vSphere web client

Screen Shot 2014-12-30 at 2.08.50 AMVista desde RVC (vsan.vm_object_info)

  • Componentes – los componente son las copias o “pedazos” de información del objeto como tal, estos componentes están pensadas para poder ofrecer alta disponibilidad y/o rendimiento (Stripe width, *PUEDE* dar mayor rendimiento en ciertos casos de uso). Si vemos la primera imagen de el articulo podemos ver unos “puntos” o información distribuida en el cluster, estos serían los componentes, la estructura o distribución de estos estará dependiendo de la política que nosotros asignamos a los objetos. Existe un componente “peculiar” llamado Witness, este componente se encarga de definir quorum para los objetos en caso de fallas de hw dentro de VSAN.

¿Porque un límite de 100 VMs de Horizon View sobre VSAN?

Este límite no es “duro”, sino que es un límite recomendado en base a pruebas por parte de QA/QE dentro de VMware. Es importante notar que VSAN tiene límites específicos en cuanto a la cantidad de objetos y componentes, estos son 3,000 objetos por Host ESXi y 64 componentes por objeto. En la siguiente imagen podemos notar como a través de RVC de VSAN podemos consultar estos límites:

Screen Shot 2014-12-31 at 1.58.11 AMAquí podemos ver un límite de 750 componentes por host ESXi debido a la memoría ram del mismo (nested ESXi/8GB)
se requiere al menos 32GB para poder contar con la mayor cantidad de componentes y también de Disk groups.

En base a estos límites es por lo que se recomienda 100 VMs por Host en el caso de hablar de Horizon view, Pero se preguntaran ¿Porque solo para Horizon View?, vamos a entender el calculo que esta por detrás de esta recomendación, la siguiente tabla la podemos encontrar en el documento “Horizon with View and Virtual SAN Reference Architecture”:

Screen Shot 2015-01-04 at 2.29.44 AM

Si tomamos los escritorios de tipo linked clones dedicados con disco “disposable” podemos ver que se tiene un total de 7 objetos por escritorio, que son el namespace (carpeta), snapshot o delta, disco de tipo “internal” (usado en operaciones de customización del escritorio, sysprep/quickprep y para refresh), disco disposable, disco persistente y archivo de swap (.vswp), esto lo podemos ver de manera gráfica en la siguiente imagen:

Screen Shot 2014-12-31 at 2.10.30 AM(Los archivos de Swap y deltas de snapshots no se muestran en esta vista gráfica)

En base a estos numeros y tomando como referencia la siguiente formula también encontrada en el mismo documento podemos notar que facilmente podemos exceder el límite de 3,000 componentes por host ESXi:

Objects x [FTT x 2 + 1]

Si usamos los siguientes valores:

  • 7 Componentes por escritorio virtual
  • política de VSAN & Horizon View default, FTT=1 y Stripe width=1
  • 100 escritorios virtuales

Los cálculos se verían de la siguiente manera:

  • 100 escritorios virtuales x 7 componentes = 700 componentes
  • 700 componentes x [1 x 2 + 1] = 2,100 componentes

Con esto podemos ver que teniendo solo 100 escritorios por host ESXi podemos estar peligrosamente cerca de el límite de componentes, 150 escritorios nos daría un total de 3,150 componentes por host ESXi lo cual estaría por encima de el límite de componentes por host ESXi. Por esta razón es que se recomienda 100 VMs por host ESXi.

 

 

One comment on “¿Porque 100 VMs x host en Horizon View & VSAN?

Leave a Reply