Nuevo fling – vSphere Replication Capacity Planning Appliance

Que tal gente, el día de hoy vamos a hablar rápidamente de un nuevo fling que nos entrega VMware Labs… vSphere Replication Capacity Planning Appliance (¿Nombre largo? :D). Recordemos que estos “flings” son herramientas o “previews” de tecnología que no tienen soporte por parte de VMware (aunque muchas veces estas tecnologías son agregadas a productos existentes).

¿Que es vSphere Replication Capacity Planning Appliance?

Este appliance virtual esta pensado para poder darnos una idea de la cantidad de información que estaremos replicando a través de vSphere Replication (replicación por medio de el hipervisor IP). Nos permite conocer el tráfico que estaría sucediendo a través de nuestros enlaces para replicar una VM en especifico, esto es muy útil ya que para poder dimensionar correctamente el ancho de banda y los RPOs para las VMs necesitamos conocer que tan “rápido” cambia la VM o esta teniendo cambios a nivel de los distintos bloques que constituyen su almacenamiento virtual, tratando de hacer esto de manera manual significa poder conocer el ritmo al cual cambia la VM, después tener esto a la mano debemos calcular lo que tomaría enviar estos cambios o “deltas” a través de nuestro enlace (sin considerar la replicación inicial de la VM donde se envía toda la VM), la formula se vería de la siguiente manera sin haber modificado ningún parámetro avanzado de buffers:

Size of changed data (bits) / Transfer speed (bps)= Transfer Time (seconds)

(esta fórmula la pueden encontrar en el articulo de Kene Wernebug, Sr. Technical Marketing Architect de  BC/DR en VMware)

Pero este cálculo manual tiende a poder fallar, a tomar mucho tiempo y no ser tan preciso, es por eso que parte del equipo de desarrolladores de vSphere Replication se dieron a la tarea de crear este fling sencillo de utilizar para podernos apoyar en el dimensionamiento de nuestras replicaciones a través de vSphere.

Básicamente este appliance simula la replicación de una VM en específico que nosotros seleccionemos, en base a esto nos muestra la cantidad de ancho de banda utilizado y el “delta” (cambios en la VM) o información que sería enviada a la ubicación de DR a través de el enlace.

¿Como utilizo este appliance?

Uno de los puntos que me gusto bastante es la simplicidad para configurar este appliance, simplemente importamos el appliance a vCenter a partir de un .OVF, configuramos su IP y ¡Voila! esta listo para utilizarse:

VRapplianceUna vez que tenemos arriba el appliance virtual a través de SSH debemos ejecutar un comando para poder definir que VM estará siendo analizada:

./bin/configureReplication –vc IPDEVM –vcuser USUARIODEVCENTER –vcpass PASSWORD –lwd IPDEAPPLIANCE –vmname NOMBREDEVMASERANALIZADA

Con este comando estaremos dictando que vCenter es el que aloja la VM que necesitamos analizar, el appliance de vSphere Replication Capacity Planning y las credenciales necesarias para poder acceder a vCenter, una vez ejecutado el comando podemos ver que se comienza con la simulación:

replicacioncomandoA partir de 10 a 15 minutos podemos abrir un navegador y apuntar a la IP de nuestro appliance para poder observar la información que esta recolectando, esta información es mostrada en intervalos de horas, días, semanas y meses considerando 2 valores, LWD traffic que sería el ancho de banda utilizado y Delta Size que se trata de la información enviada (que ha cambiado de la VM) con esto (tomando en cuenta que monitoreamos todo el ciclo de producción de la VM) podemos dimensionar vSphere Replication y definir los RPOs que seremos capaces de cumplir:

infosizingiis7hispavirt

¿Donde encuentro este Fling?

Recordemos que este y muchos mas flings son publicados en el sitio web de VMware labs:

labs.vmware.com

Los invito a darle un vistazo a todos los flings que están disponibles, existen bastantes que son muy útiles.

vSphere App HA deepdive

Que tal gente, el día de hoy vamos a hablar sobre una tecnología que a mis ojos parece tener bastante potencial, claramente estaremos hablando de una versión 1.0 del producto por lo que debemos comprender que muchas cosas iran siendo agregadas conforme el tiempo pase. Esta vez voy a hablarles de vSphere App High Availability, tecnología de VMware que fue liberada a con vSphere 5.5, como lo podemos notar en su nombre es alta disponibilidad para nuestras aplicaciones vamos a darle un vistazo:

¿Que es vSphere App HA?

Todos conocemos (¿O eso creo?) vSphere HA, que nos permite brindar alta disponibilidad a nivel de VM protegiéndola contra caídas de infraestructura… a grandes rasgos realiza un reinicio de las VMs fallidas en un servidor que se haya caído o tenga problemas. ¿Pero que pasa con las aplicaciones?, digamos que tenemos un servidor ESXi funcional, la VM con el servicio esta siendo ejecutada sin ningún problema, pero dentro de esta vm en el sistema operativo guest la aplicación/servicio esta caído, en este caso HA nunca reiniciaría la VM debido a que esto no forma parte de su “responsabilidad” aquí es donde entra vSphere App HA, que en conjunto con Hyperic nos brinda la capacidad monitorear los servicios que están dentro de una VM para poder definir políticas que nos permitan ejecutar acciones correctivas para mantener la disponibilidad del servicio o aplicación que tenga dicha VM.

El poder de este producto es brindado por hyperic, para poder tener monitoreo dentro de nuestras VMs necesitamos instalar el agente de Hyperic en cada VM que tenga servicios soportados que queramos protejer con App HA. En el laboratorio de Hispavirt podemos ver como tengo el appliance virtual de Hyperic para este fin:

HypericOVA En este servidor de Hyperic iremos agregando todos los agentes para que se puedan monitorear los servicios que existen en dichas VMs.

App HA interactua con vSphere y Hyperic a través de un plugin de NGC (Next Generation Client) o el vSphere Web Client, que nos permite apuntar a un servidor de hyperic para registrar el servicio (existen algunos pasos que debemos de realizar en hyperic para tener las alarmas de vCenter funcionando esto lo pueden encontrar aquí) este plugin lo brinda el appliance virtual de App HA:

hypericconfvcenter

Una vez lista la configuración podemos comenzar a crear políticas para proteger los servicios que son descubiertos por el agente de Hyperic en nuestras VMs, para esta versión se tiene una lista definida de servicios soportados donde podemos encontrar los siguientes:

  • Apache Tomcat 6 y 7
  • IIS 6, 7 y 8
  • MS SQL 2005, 2008, 2008 R2 y 2012
  • Sharepoint 2007 y 2010
  • SpringSource tc Runtime 6 y 7

En el laboratorio me di a la tarea de crear una VM con Windows 2008R2 y IIS7, donde instale y configuré el agente de Hyperic para que esta fuera registrada en el inventario:

instalacionhypericUna vez instalado debemos verificar que es presentado en el “auto discovery” de hyperic y lo agregamos a nuestros recursos:

autodiscoveryiishypericCuando ya tenemos lista la VM dentro de Hyperic podemos comenzar con la creación de políticas, para que estas sean asignadas a dichas VM y así proteger el servicio o aplicación que este ejecutándose dentro de ella, para motivos de la demostración seleccione las siguientes opciones para un servicio de IIS7:

RemediacionAppHA Que son las opciones de “remediación” ofrecidas en el caso que el servicio de la VM se encuentre abajo. Podemos notar que tenemos la principal función que es “reiniciar” el servicio, donde definimos cuanto tiempo le toma iniciar a este servicio, en este caso puse 2 minutos aunque claro que esto debe de ir de la mano de lo que se tarde en su ambiente, después seleccione la opción de “Restart the VM in the event that the service is unstable” que nos permite dictarle a App HA que si no es capaz de levantar el servicio en repetidas ocasiones durante una ventana de tiempo definida (en este caso 2 veces en 10 minutos) que proceda a reiniciar la VM ya que puede ser un problema mas complicado a nivel del sistema operativo y un reinicio ayude a resolverlo.

Aquí pueden ver que mi política quedo creada y lista para ser asignada a la VM que tiene IIS7:

politicadefinidaAppHADespués debemos asignar esta política a la VM que será protegida con AppHA, para esto vamos a nuestro vSphere Web Client y seleccionamos nuestro vCenter Server, donde veremos una pestaña llamada “Monitor” y dentro de esta pestaña tendremos una nueva sección agregada por App HA “Application Availability” donde podremos agregar nuestra política:

políticaAppHAaplicada

Una vez aplicada la política si tenemos una caída del servicio App HA nos dará un aviso en el “status” y tomará cartas en el asunto para poder levantarlo, también podemos notar que se envía una alarma de vCenter Server:

iis7abajoAppHaComo podemos ver la configuración, creación de políticas y el como trabaja App HA es bastante amigable, en mi caso no me tarde mas de 15 minutos en dejar lista la configuración de vCenter y Hyperic (de hecho me tarde mas tiempo en descargar los appliances de App HA y Hyperic). En esta versión tenemos la capacidad de proteger servicios con un mecanismo sencillo, claramente como lo dice su nombre se trata de “alta disponibilidad” a diferencia de una tolerancia a fallos que nos podría dar un servicio de cluster a nivel de la aplicación, pero para muchos casos de uso esta alta disponibilidad funciona cubre las necesidades o los SLAs definidos.

¿Que necesito para poder tener App HA?

Como han visto a lo largo del articulo necesitamos de algunos componentes “extra” de lo que viene siendo vSphere (ESXi y vCenter) que son:

  • Hyperic
  • App HA (appliance virtual)

En el caso de Hyperic podemos optar por el appliance virtual que ya incluye el servidor y la base de datos como parte de un vApp, para poder cubrir el máximo de agentes que están soportados por App HA que son 400,necesitaríamos una configuración “medium” para el servidor de Hyperic (4vCPUs y 8GB de RAM) mientras que para la base de datos necesitaríamos una configuración “medium” (4vCPUs y 6GB RAM), como podemos ver para Hyperic estaríamos hablando de una cantidad de recursos de alrededor de 14GB en RAM y 8vCPUs, esto sin considerar que tengamos mas de 500 agentes a monitorear lo cual no podría ser cubierto por un “conjunto” de vCenter + Hyperic + App HA (la relación es 1:1:1).

En el caso del appliance de App HA los requerimientos son bastante bajos, 2 vCPUs, 4GB RAM, 20GB en disco y 1Gbps en red. Con respecto a la plataforma que estará monitoreando vSphere App HA trabaja con Hyperic 5.7+, ESXi 5.5 y vCenter 5.5.

Una duda que he encontrado (que yo mismo tuve en su momento) fue el hecho de el licenciamiento de Hyperic, si consideramos que estaremos monitoreando varias instancias de sistema operativo podríamos pensar que necesitaríamos una licencia para cada uno de estos en lo que a Hyperic se refiere, pero esto no es correcto, con el simple hecho de importar el appliance virtual de Hyperic y contar con vSphere Ent+ tenemos todo cubierto, si… sin necesidad de licenciamiento de Hyperic.

 

 

 

vSphere 5.5 – ¿Que hay de nuevo? – Parte 2

Que tal gente, continuando con la serie de artículos sobre lo nuevo que nos trajo vSphere es momento de hablar sobre vCenter y vSphere replication.

vCenter 5.5

Con esta nueva versión de vSphere llegaron mas que nuevas capacidades, mejoras a nivel de vCenter tanto en su forma de appliance virtual como en la versión de Windows.

  • Escalabilidad – aquí podemos encontrar las mejoras específicamente hablando de el appliance virtual de vCenter (VCVA) donde la base de datos embebida (vPostgres) alcanza un máximo de 500 hosts ESXi y 5000 VMs lo que permite tener un ambiente BASTANTE grande sin necesidad de una base de datos externa ( solo soporta Oracle).
  • Soporte de sistemas operativos – se agrega Windows 2012  como como soportado para ser base de la instalación de vCenter.
  • Bases de datos para vCenter en Windows – En esta versión solo se soporta Oracle 12 R1, 11g R2 (11.2.0.4) ,MS SQL 2012 SP1 y 2008 64-bit R2. No se tiene soporte para DB2.
  • Alta disponibilidad – En la versión 5.5 se soportará oficialmente por parte de VMware algo que los clientes, consultores, arquitectos y demás han utilizado hace mucho tiempo, clusterizar la base de datos de vCenter. En el caso de vCenter para Windows se soportará oficialmente MSCS en MS SQL y RAC para Oracle, para el appliance virtual de vCenter (VCVA) se tendrá soporte para la base de datos externa en Oracle RAC.
  • vSphere Web Client – Algo que tal vez para quienes hemos tenido que acostumbrarnos al vSphere Web Client viniendo del muy “tradicional” cliente de C# es ha sido el hecho que este Web Client no es reconocido por responder de manera muy rápida, cosa que muchas veces nos regresaba al viejo amigo… En esta versión algo interesante es que la mejora en la velocidad del cliente web es TOTALMENTE notable en este punto podría decir que es un cliente cómodo con el cual trabajar.quickfilterswebclientDe igual manera se agregan capacidades para como los “quick filters” que nos permite crear filtros de manera muy rápida y sencilla en la busqueda. Se agrega soporte para drag & drop de objetos a nivel del inventario, permitiéndonos así tener una navegación y uso del cliente mucho mas amigable de lo que se tenia en versiones anteriores, por último algo que para mi (y ciertamente todos los usuarios de OSX) es increbile fue que oficialmente se agrega soporte para Mac OS con capacidades como la consola de HTML para visualizar e interactuar con las VMs, transferencia de OVFs y uso de ISOs locales.

Como pueden ver no todas son “nuevas” capacidades sino como lo dije al inicio del articulo son mejoras a lo ya existente.

vSphere Replication

En el área de vSphere Replication (sin considerar SRM) se tienen de igual manera mejoras y nuevas funcionalidades vamos a revisar que nos trajo vSphere 5.5 pero para esto vamos a recordar que es vSphere Replication a grandes rasgos.

HBR

vSphere Replication nos permite realizar replicación de tipo asíncrona de nuestras VMs, en este caso hablamos de replicación a nivel del vmkernel (hipervisor) por lo que no se requiere ni agentes, ni una arquitectura y/o tecnología uniforme ya que al trabajar a nivel del hipervisor todo este tipo de temas quedan abstraídos. Definimos un RPO o Recovery Point Objective (tiempo al cual queremos poder recuperar en el caso que se tenga un problema) y esto nos permite fijar los periodos de replicación, en versiones interiores este punto al cual podiamos regresar era unico, es decir, cada replicación sustituía a la anterior.

En esta versión se agrega algo bastante interesante, la capacidad de poder retener varios puntos hacia donde podemos recuperar una VM (o un VMDK en especifico) a esta funcionalidad se le llama MPIT “Multiple Points In Time”

mpit Esto nos permite el poder regresar a puntos específicos del tiempo donde tengamos distintos estados de la VM, algunos casos de uso pueden ser bastante amplios debido a la flexibilidad. Las distintas replicas o puntos a los que nos podemos recuperar se presentan como “Snapshots” por lo que nosotros seleccionamos el punto al que nos queremos recuperar como lo haríamos desde el snapshot manager (maximo 24 replicas).

Esta capacidad de MPIT o múltiples puntos de tiempo no esta disponible desde SRM solo a través de vSphere Replication.

snapsmpit

Otras mejoras:

  • Soporte para vSAN – esto es súper importante, debido a que un datastore de vSAN solo puede ser accedido por aquellos hosts que forman parte del cluster, esto nos permite replicar nuestras VMs hacia otro tipo de storage sea localmente o de manera remota.
  • Varios appliances de VR – esto nos permite replicar a múltiples localidades, distribuir cargas, etc.
  • Soporte para SvMotion – al migrar VMs con SvMotion aunque estas estén protegidas por VR la replicación continuará sin ningún problema, claramente esto agrega soporte para SDRS.

La gestión de vSphere Replication forma parte de la interfaz de vCenter, por lo que lo gestionamos desde una “pestaña” o sección de nuestro cliente.

Estén atentos para un articulo donde estaré cubriendo a profundidad vSphere Replication 5.5 y SRM 5.5.

 

vFlash Deepdive

Que tal gente, continuando con los artículos sobre lo nuevo que nos trajo VMworld (muchas cosas además de vSphere) es turno de meternos de lleno a lo que nos ofrece VMware con vFlash. Esta nueva funcionalidad nos permite acelerar operaciones de lectura a nivel de VMDK de máquina virtual, por lo cual dependiendo del caso de uso y tipo de aplicación puede ser de bastante interesante.

Debemos comenzar por definir algunos términos que estaremos manejando en el articulo:

  • Memoria Flash – este tipo de memoria no es volátil (a diferencia de la memoria RAM) y es de tipo electrónica por lo que no maneja ninguna parte móvil se tienen dos tipos principales de memoria flash, NOR y NAND siendo la última la mas común y utilizada ampliamente hoy en día.
  • SSDs – Tomando un fragmento de mi articulo “vSAN Deepdive” :

    “Solid State Drive”, este tipo de disco a diferencia del tradicional o mecánico no tiene partes móviles lo que permite tener tiempos de acceso mucho mas rápidos y menor latencia. Si lo comparamos con una memoria USB estos dos comparten algo en común, el hecho que ambos almacenan información en memoria flash, claramente los discos de estado solido tienen una estructura semejante a un disco tradicional y son mucho mas sofisticados que una simple memoria USB. La  cantidad de IOPS en un SSD se encuentra en el orden de los miles y a diferencia de un disco mecánico estos son mucho mejores en operaciones de lectura que en escritura, esto debido a que no se puede sobre escribir información sin que se ejecute un proceso llamado “garbage collection” lo que permite la escritura en esa ubicación cosa que no sucede en un disco mecánico de cualquier manera generalmente tienen mejor rendimiento que los discos mecánicos. Existen distintos tipos de SSDs, tenemos SSDs con interfaz SATA, SAS o tarjetas PCIe que contienen SSD o memoria Flash para poder acelerar operaciones de I/O a nivel del servidor. Cabe destacar que este pequeño intro a los SSDs no es tantito la vista completa de como trabaja un SSD, recuerden investigar mas sobre el tema.

  • Cache –el cache es memoria designada específicamente para la aceleración y almacenamiento temporal de operaciones de I/O, puede ser memoria RAM o disco (SSD) (hablando de operaciones a nivel de almacenamiento, claramente el término cache tiene distintos usos), en el caso de vFlash nos apoya a poder acelerar operaciones de lectura unicamente, esto debido a que se trata de cache “write through” por lo que no puede reducir los tiempos de respuesta en escritura como lo haría el cache de tipo “writeback”. vFlash en el espacio designado almacena los bloques de información que son accedidos con mayor intensidad, permitiendo así servir a las operaciones de lectura desde cache lo cual evita una consulta de estos bloques en el almacenamiento o backend (donde se encuentran los discos). Para tener una mejor idea de como trabaja el cache a nivel de almacenamiento (desde una perspectiva general y no especifica para algún fabricante) les recomiendo leer mi articulo “EMCISA – Intelligent Storage System”.
  • VFFS se trata de un sistema de archivos que deriva del afamado VMFS, en este caso VFFS esta pensado para agrupar todos los discos de estado solido SSD como una única entidad o grupo de recursos y optimizado para poder trabajar con este tipo de disco.

¿Que es vFlash?

Lo se, bastantes términos e introducción pero debemos sentar las bases para poder platicar de manera mas profunda sobre la funcionalidad… vFlash es una solución 100% basada en el hipervisor, es decir, existe como parte del core del hipervisor (ESXi) por lo que no depende de ningún appliance virtual u otro enfoque, nos permite acelerar operaciones de lecturas a nivel de VMDK de VM a través de SSDs locales que hacen las veces de cache y sin necesidad que estos sean exactamente iguales en cuanto a modelo, tamaños y demás. El administrador de la infraestructura deberá configurar el pool de recursos de vFlash (que estará construyendo el sistema de archivos VFFS) a partir de discos de estado solido conectados directamente a los servidores ESXi, esto lo podemos notar en la siguiente imagen:

SSDVFFS Aquí podemos notar que en mi laboratorio seleccione un SSD de 55GB (en realidad son 60GB) para ser formar parte de VFFS, una vez que dejamos listo el o los distintos discos de estado solido que conformaran nuestro pool de recursos solo es cuestión de repartir de manera individual este espacio disponible para cada VMDK de VM, es importante saber que nosotros tenemos la opción incluso de solo acelerar un disco de una VM que tenga mas discos o VMDKs esto nos da la posibilidad de tener un control mucho mas granular en la entrega de este cache basándonos en el perfil de I/O que presenta nuestras VMs. Una herramienta que nos puede ayudar en poder conocer que perfil de I/O manejan nuestras VMs es el ya confiable y ampliamente utilzado vscsiStats donde podemos conocer todo tipo de información como el tamaño de operaciones, latencia,entre otras, aquí les dejo algunos artículos de mi blog donde pueden leer mas sobre vscsiStats:

VCAP – Sección 3 – utilizar herramientas avanzadas para el monitoreo de performance

VCAP – Sección 6 – Troubleshooting de almacenamiento

Paso-a-paso – vscsiStats

Es importante conocer el patrón de I/O que presentan nuestras VMs debido a que en la configuración de vFlash a nivel de VDMK definiremos tamaño del cache y bloque del mismo (lo mejor es que sea el mismo que el utilizado por la aplicación/servicio):

vFlashconf

En cuanto a requerimientos para poder habilitar este cache a nivel del VMDK de nuestras VMs solo tenemos los siguientes:

  • VM compatibility (Hardware virtual) versión 10
  • SSD local en el host ESXi

La configuración de esta funcionalidad es únicamente a través del vSphere Web client, al igual que todas las funcionalidades nuevas que se han ido agregando a vSphere solo están y estarán disponibles desde el cliente basado en web. Una vez configurado el cache este es transparente para la VM pero tiene ciertas consideraciones de diseño que estaremos revisando más adelante.

Arquitectura

vFlash introdujo algunos nuevos componentes a ESXi y de igual manera al stack de I/O de la VM (solo en caso del VMDK que esta habilitado con vFlash) se tienen dos componentes nuevos:

  • vFlash infrastructure – aquí tenemos la librería (vFlashlib) con la cual trabaja el vmx para poder interactuar con el cache, de igual manera se encuentra un módulo de hipervisor interesante llamado FDS (File System Switch)  que esta colocado entre el adaptador vSCSI de la VM y el módulo de cache del hipervisor que permite la abstracción de los distintos SSDs que constituyen el pool de recursos de tal manera que se tiene una interacción común aún teniendo distintos dispositivos y por último tenemos el sistema de archivos VFFS como parte de este “vFlash infrastructure”
  • vFlash cache module – módulo del hipervisor encargado de manejar el cache y la interacción con el VFFS, este cache es transparente para VMs y aplicaciones.

El flujo  de información se vería mas o menos de esta manera:

flujovflashCada vez que se enciende una VM se crea su cache, es decir, este no es persistente a reincios y demás, vFlashlib lo crea una vez que el proceso de VM (VMM) comienza, el pool de recursos que a su vez construye el sistema de archivos VFFS es un sistema de archivos que existe a todo momento e incluso tiene un punto de montaje en /vmfs/devices/vflash/.

Interoperabilidad

En el momento que consideramos integrar vFlash en nuestros diseños de infraestructura la primera pregunta sería ¿Como afecta y/o como trabaja con otras funcionalidades como HA, vMotion,DRS, etc?, vamos a revisar cada una de las funcionalidades mas relevantes de vSphere:

  • vMotion, Storage vMotion y XvMotion (enhanced vMotion) todas estas operaciones son soportadas, nosotros como administradores decidiremos si es que queremos migrar el cache o recrearlo en el host destino, para el caso en especifico de Storage vMotion no tiene impacto esto debido a que no migramos de host. Claramente la decisión de migrar o no el cache impactara en la carga que se tendrá a nivel de red y el tiempo de migración debido a que se deberá copiar el cache en uso y si tomamos la decisión de migrar la VM sin su cache se tendrá un impacto en el rendimiento debido a que el cache será reconstruido con el tiempo (se deberá esperar tiempo para que se tenga información “caliente” en el cache”. Podemos ver en la imagen la migración con vFlash activado:

opcionesmigracionvflash

  • HA claramente en el momento de tener un evento de failover al reiniciarse de manera forzosa la VM en otro servidor del cluster el cache no viaja con ella y deberá ser reconstruido. Acá entra una decisión importante en cuanto a diseño se refiere y es el control de admisión, es decir, si tenemos nuestros SSDs 100% utilizados en cada host o no existen recursos suficientes de vFlash en el momento de requerir un reinicio de VM por un evento de HA esta simplemente no se reiniciará en otro host, por lo que debemos considerar cierto espacio libre en nuestros SSDs para eventos de HA.
  • DRS – DRS funciona sin ningún problema con vFlash, en este caso estará ocupado XvMotion para migrar la VM y copiar a la vez el cache. Aquí entramos a una consideración de diseño similar al caso de HA, y básicamente es que DRS al estar realizando el análisis del cluster para poder determinar recomendaciones y así realizar migraciones para el balanceo del cluster (dependiendo claramente de el nivel de automatización) sino encuentra los recursos suficientes de manera “continua” o en un mismo host (no fragmentados entre todo el cluster las VMs no serán candidatas a poderse migrar ya que no se puede satisfacer la cantidad de vFlash entregado.

Consideraciones extra

Acá podemos encontrar algunas consideraciones y limites de vFlash en esta versión:

  • El tamaño máximo de SSD soportado es de 4TB
  • Se soportan hasta 8 SSDs por VFFS lo cual nos da un total de 32TB para VFFS
  • Solo se soporta un VFFS por host ESXi
  • Se tiene un máximo de 400GB de cache por VM con un tamaño mínimo de bloque de 1KB hasta 1024KB
  • No se soporta SSDs compartidos (solo una partición)
  • No se soporta SSDs remotos
  • No se soporta FT
  • No se puede compartir un SSD entre vSAN y vFlash

Casos de uso

Podemos ver que esta versión inicial de vFlash puede cubrir ciertos requerimientos de aplicaciones, en general aplicaciones con muchas lecturas. vFlash nos permite agregar mayor cantidad de aplicaciones críticas, pero un caso de uso que a mi me llama mucho la atención es VDI, y ¿Porque VDI? pues es simple, podemos descargar bastantes operaciones de I/O (lecturas) del almacenamiento y que estas sean servidas a partir del mismo SSD local (mejorando drásticamente el rendimiento de dichas operaciones) esto se vería bastante claro en la carga que recibe la replica si estuviéramos hablando de horizon view.  En este punto Horizon View 5.2 no esta soportado para  vFlash, aunque técnicamente no tendría problema para funcionar esto no será soportado oficialmente por servicios de soporte VMware (Global Support Services, GSS).

Conclusión

vFlash nos permite reducir la carga a nivel de nuestro almacenamiento centralizado (sería bueno incluso hablar de vSAN :D) a través de disco “barato” porque al final del día es mas costoso adquirir mayor cantidad de IOPS a nivel de una SAN/NAS que entregándolos a partir de disco SSD local. Existen distintas soluciones allá afuera que ofrecen este tipo de funcionalidades con otras ventajas, como por ejemplo, PernixData FVP y Proximal Data AutoCache

Estén atentos a mis siguientes artículos, donde estaré cubriendo el monitoreo de vFlash, a través de linea de comando y de los distintos indicadores de rendimiento que fueron agregados a nivel de vCenter.

De igual manera les recomiendo leer los links que estaré actualizando en este articulo sobre vFlash:

FAQs por Duncan Epping (Yellow Bricks) Frequently asked questions about vSphere Flash Read Cache

vSphere 5.5 – ¿Que hay de nuevo? – Parte 1

Que tal gente el día de hoy les voy a hablar sobre lo nuevo que se agrego a vSphere 5.5, estaremos revisando de manera “profunda” todas las nuevas capacidades. Recordemos que en VMworld 2013 San Francisco Pat Gelsinger anunció la nueva versión de la plataforma entre otras noticias (vSAN (aunque este pertenece a vSphere), NSX, vCHS, etc.).

Computo – Host ESXi

La capacidad que podemos tener en un solo host ESXi tanto lógica como física aumento bastante en este release estos son los máximos que manejamos en esta versión:

  • 4TB de Memoria RAM por Host ESXi – ¿Mayor densidad?, claramente el tener la posibilidad de alcanzar este nivel de recursos no quiere decir que es algo recomendable, todo dependerá del caso de uso y el ambiente (ej. cargas no criticas vs cargas críticas, overcommitment vs recursos dedicados, etc.) Se tiene soporte experimental para 16TB de RAM. Es interesante saber que se tiene soporte para memoría de tipo “reliable” donde se tiene una copia o “mirror” de una sección de la memoría, ESXi identificará este espacio de memoría designado como “reliable” (claramente configurado previamente por el usuario/admin a nivel del host físico) y podrá colocar ciertos procesos como watchdog podemos verificar la cantidad de memoria “reliable” en uso con el comando:

esxcli hardware memory get

  • 320 CPUs físicos por Host y 4096 vCPUs (CPUs de VM) – nuevamente, una cantidad impresionante, numeros difícilmente utilizados o empleados en el campo.
  • C-States – se integra el manejo de CState además de los PStates de procesador para poder optimizar energía en distintos tiempos, los P-states básicamente son aquellos niveles de rendimiento (operacionales, frecuencia y voltaje) que ofrece el procesador mientras que el C-State permite desactivar ciertas capacidades propias del procesador para ahorrar energía extra entrando en distintos estados “idle”, todo esto ESXi lo realiza a través del ACPI.

Pstatescstates

Storage – Host ESXi

Una sección que recibió BASTANTES nuevas funcionalidades y mejoras a lo ya existente vamos a revisar que nos trae vSphere 5.5 del lado de storage:

  • vSAN  vSAN nos permite tener almacenamiento centralizado a partir de discos locales, lo interesante en esto es que se emplea SSD para poder realizar cache de lecturas y buffering de escrituras (write back cache) lo que nos permite tener almacenamiento verdaderamente escalable y con un excelente rendimiento, para saber mas sobre vSAN les recomiendo leer mi articulo vSAN Deepdive.  Es importante notar que no tiene nada que ver con VSA o la vSphere Storage Appliance, aunque ambas nos permiten entregar almacenamiento local de manera centralizada estan enfocadas para distintos segmentos y casos de uso, para esto les recomiendo leer el articulo de Rawlinson Rivera donde nos presenta una tabla comparativa entre ambas soluciones, leelo aquí.
    vsanhabiliar
  • vFlash Otra interesante funcionalidad que se agrega a vSphere 5.5 que nos permite dar read cache a las VMs, es importante saber que esto no ofrece aceleración de escrituras o writeback cache. Se habilita de manera granular por VMDK como lo podemos ver en la imagen. La aceleración es provista por SSDs locales en el host ESXi, estaré hablando mas a fondo sobre vFlash en un articulo futuro, tocando temas de mejores prácticas, arquitectura, etc.

virtualflashhabilitar

  • Microsoft Clustering Services se agrega soporte para el path selection policy (PSP) de Round Robin cuando utilizamos MSCS con Windows 2008 y 2012 (que emplean reservaciones SCSI3) el disco de quorum tiene que ser entregado como passthrough RDM. De igual manera se agrega soporte para iSCSI en las 3 distintas arquitecturas de MSCS soportadas (Cluster in a box, Cluster across boxes y N+1) ya sea con software iSCSI o hardware iSCSI.
  • VMDKs de 2TB+ Se cuenta con soporte de VMDKs de hasta 64TB (utilizables 63.36TB por metadata y demás), aunque debemos tener algunas consideraciones: Al utilizar NFS se tendrá la limitante del sistema de archivos que provee dicho punto de montaje, es decir, el tamaño de archivo máximo que maneja (ej. ext3 llega a 16TB), VMFS3 continua con la límitante de 2TB , No se puede extender un volumen en “vivo” u online de 2TB a un espacio mayor, esto tiene que ser con la VM apagada, No se soporta FT, VSAN no soporta VMDKs de 2TB+ y El adaptador Buslogic no es compatible. Se logro este incremento a través de 2 capas de direccionamiento indirecto de bloques. En el caso de tener snapshots para este tipo de discos de mas de 2TB+ los snaps serán creados automáticamente en formato sesparse (funcionalidad que solo esta presente para Horizon View en los linked clones).
  • Mejor manejo para PDL Se agregó un mecanismo que de manera automática remueve todos aquellos dispositivos de storage que se encuentren marcados con PDL o “Permanent Device Loss” que básicamente es la perdida de acceso al dispositivo (LUN) lo que evita futuras operaciones de I/O a nivel de dicho dispositivo y también nos permite liberar un dispositivo del máximo de 255 que se maneja.
  • Heap de VMFS  nos permite abrir hasta 64TB concurrentes por Host ESXi, cosa que en versiones anteriores era un problema, muchas veces necesitábamos modificar el heap de vmfs para poder tener acceso a mas archivos abiertos.
  • Soporte para EndtoEnd 16Gb FC   anteriormente se soportaba HBAs de 16Gb pero trabajando a 8Gb, ahora toda la fabric puede estar a 16Gb.
  • Soporte para Hot-plug de PCIe SSDs –  se soporta el agregar discos SSD en caliente (con el servidor operando) mientras que estos esten conectados a una controladora PCIe, esto extiende el soporte de hot-plug de discos donde se soportaba SAS y SATA.

Networking- Host ESXi

Del lado de networking se agregaron algunas funcionalidades interesantes, revisemos que tenemos nuevo en vSphere 5.5:

  • Traffic filtering & marking – se nos permite agregar ACLs a nivel de portgroup (se implementa y configura en cada portgroup), esto básicamente nos da la opción de permitir o tirar paquetes en base a distintos “calificadores”:opcionesacls
    De igual manera nos permite marcar con DSCP para brindar QoS en los paquetes y al igual que los ACLs nos permite definir los mismos calificadores, un caso de uso en para esta funcionalidad sería VoIP:

cosdscpqualifiers

  • pktcap-uw – esta herramienta que forma parte del hipervisor es similar a lo que vendría siendo TCPdump, nos permite recolectar paquetes para su analisis, realizar un trace y demás esta bastante interesante y nos brinda visibilidad y capacidad de poder realizar troubleshooting de a nivel de redes incluso permitiéndonos extraer los paquetes en formato .pcap para su analísis en Wireshark, aquí les muestro un ejemplo de captura de 1 paquete de iSCSI entre mi host ESXi y mi almacenamiento PX6 de LenovoEMC:

capturapktcap

  • Soporte para NICs de 40Gb – se agrega soporte para el manejo de tarjetas ethernet a 40Gbps esto permite tener una escalabilidad en términos de rendimiento bastante alta, en ambientes donde el crecimiento del host esta topado por cuestiones de bahias de expansión PCIe (ej. blades) hace mucho sentido (claramente debemos de contar con infraestructura de red capaz de manejarlo.
  • Mejoras en SR-IOV – desde la versión 5.1 de vSphere soportamos SRIOV o Single Root I/O Virtualization, que básicamente nos permite segmentar un mismo dispositivo físico que este conectado a través de PCIe en distintos dispositivos virtuales que son conocidos como “VFs” o Virtual Functions que son despúes presentados directamente a las VMs permitiendo así hacer un bypass de todo el stack de networking del vmkernel (hipervisor) reduciendo latencia y mejorando el throughput, en esta versión se agrega una funcionalidad de poder presentar las propiedades del Portgroup al cual esta conectado dicha VF ej. presentar modo promiscuo, vlans, etc.
  • Mejoras para LACP – Se cuentan con mejoras en LACP, desde la versión 5.1 se soportaba LACP. Con este release se agregan mas algoritmos de negociación, se soportan 64LACPs por ESXi y 64 por vDS, cosa que antes era 1 LACP por vDS y 1 por Host ESXi, estaré escribiendo un articulo puntual sobre esto.

Hardware virtual (VMs)

Con vSphere 5.5 también se liberó una nueva versión de hardware virtual o “VM compatibility”, versión 10:

vmhw10

¿Que beneficios nos brinda esta nueva compatibilidad de VM?

  • Hasta 128 vCPUs por VM
  • 2TB de Memoria RAM por VM
  • 64TB en un solo VMDK (utilizables son 63.36TB) y vRDMS de ~64TB (buslogic no soporta estos tamaños).
  • 4 adaptadores vSCSI y 30 discos por controladora lo cual nos da un total de 120 discos por VM
  • Adaptador SATA (AHCI), en este caso solo se soporta un máximo de 30 discos y cuatro controladoras
  • Soporte para GPUs de Nvidia y AMD
  • Aceleración de gráficos para Linux.

Como pueden ver se agregan capacidades interesantes a nivel de VM, en este caso desde mi punto de vista veo una que resalta entre las demás, soporte para VMDKs de 2TB+, existen muchos casos de uso donde se justifica tener discos de mayor tamaño y el configurar RDMs para estas VMs resulta un incremento el la administración tanto del storage como de VMware, aquí lo importante que debemos recordar es el hecho de que aunque podamos agregar discos de dicho tamaño debemos de tomar en cuenta temas como DR, BC, backups y demás, tomando como ejemplo que tengamos un datastore de 64TB donde coloquemos 5 VMs con VMDKs de 10TB imaginemos el tiempo que nos toma el respaldar esta info, el restaurar este LUN, replicación, etc y siempre apegandonos a los RPOs y RTOs definidos (¿comienza a complicarse cierto?) claramente existen muchos casos de uso donde será la opción utilizar VMDKs de gran tamaño pero debemos de comparar todos los “trade-offs” entre las distintas opciones para poder justificar nuestra decisión.

Esten atentos para el siguiente articulo donde estaré hablando de las mejoras en vSphere replication y vCenter Server.

vSAN Deepdive

Que tal gente el día de hoy les voy a hablar sobre vSAN, una tecnología que fue anunciada en VMworld 2013 SFO. vSAN en conjunto con NSX (sobre el cual estaremos hablando en otro artículo) y vCHS fueron de los anuncios mas relevantes y disruptivos que se tuvieron en VMworld claramente también tenemos una versión nueva de vSphere (de la cual estaremos hablando de igual manera en otro articulo mas adelante)vCD, etc, y todo esto llega a marcar nuevamente el liderato de VMware en muchos aspectos del Software Defined Data Center.  vSAN cubre la automatización y “abstracción” del almacenamiento de tal manera que nos permite tener arquitecturas distribuidas que no solo dependan de almacenamiento SAN o NAS, sino que puedan hacer uso de los recursos locales de disco en los servidores que constituyen el cluster y aún así mantener los SLAs definidos para cada una de las aplicaciones y/o servicios que alojamos dentro de el almacenamiento presentado a partir de recursos locales con un excelente rendimiento que nos permite albergar aplicaciones demandantes y críticas para el negocio.

Es importante recordar que vSAN esta disponible como beta público, todavía no es GA, podemos probar vSAN aplicando para el beta público en la siguiente liga:

http://www.vmware.com/vsan-beta-register

Conceptos básicos

Antes de comenzar a hablar de vSAN vamos a darnos algo de tiempo para explicar algunos conceptos básicos para que todas las audiencias entiendan perfectamente bien de lo que hablamos.

Con la llegada de vSAN debemos manejar y entender los siguientes términos:

  • SSD – “Solid State Drive”, este tipo de disco a diferencia del tradicional o mecánico no tiene partes móviles lo que permite tener tiempos de acceso mucho mas rápidos y menor latencia. Si lo comparamos con una memoria USB estos dos comparten algo en común, el hecho que ambos almacenan información en memoria flash, claramente los discos de estado solido tienen una estructura semejante a un disco tradicional y son mucho mas sofisticados que una simple memoria USB. La  cantidad de IOPS en un SSD se encuentra en el orden de los miles y a diferencia de un disco mecánico estos son mucho mejores en operaciones de lectura que en escritura, esto debido a que no se puede sobre escribir información sin que se ejecute un proceso llamado “garbage collection” lo que permite la escritura en esa ubicación cosa que no sucede en un disco mecánico de cualquier manera generalmente tienen mejor rendimiento que los discos mecánicos. Existen distintos tipos de SSDs, tenemos SSDs con interfaz SATA, SAS o tarjetas PCIe que contienen SSD o memoria Flash para poder acelerar operaciones de I/O a nivel del servidor. Cabe destacar que este pequeño intro a los SSDs no es tantito la vista completa de como trabaja un SSD, recuerden investigar mas sobre el tema.
  • Disk Group – en el momento de habilitar vSAN como funcionalidad del cluster tenemos que crear algo que se le conoce como “Disk Group”, básicamente este es un conjunto de HDDs y SSDs los cuales son presentados al cluster, como espacio en el caso de los HDDs y como cache (lecturas) y buffering (escrituras) en el caso de los SSDs. diskgroupvsanLos discos de estado solido están pensados para ofrecer cache y buffering enfrente de los discos mecánicos, es importante notar que no todos los hosts ESXi que participan en un cluster de vSAN necesitan presentar disk groups aunque si es necesario contar con al menos 3 servidores ESXi que entreguen espacio al cluster mientras que los otros 5 (tomando como base el máximo de 8 hosts ESXi en un cluster de vSAN) podrían estar teniendo acceso a dicho datastore sin necesidad de ofrecer espacio. Se recomienda una proporción de 1:10 hablando de SSDs a HDDs pero esto varia mucho dependiendo que tipo de SSD es el que estaremos utilizando. Para mejorar el rendimiento se utiliza RAID0 y dependiendo de la cantidad de “stripes” que definamos será la cantidad de discos duros a través de los cuales se distribuya la información para tener un mejor rendimiento (esto lo estaremos tocando mas adelante).
  • VM Storage Profiles – vSAN requiere de perfiles de almacenamiento para nuestras VMs, esto para poder asegurar y mantener los SLAs que distintas aplicaciones y/o servicios que vivan en ellas requieren. vSAN provee información a través de VASA, por lo que en el momento de crear un perfil de almacenamiento para nuestras VMs podemos seleccionar el proveedor VASA de vSAN y así seleccionar las distintas opciones o capacidades que nos ofrece este proveedorvmstorageprofile. En la imagen podemos notar las distintas capacidades que nos ofrece este proveedor VASA (vSAN) podemos definir disponibilidad, rendimiento etc. Es importante saber que no es 100% necesario crear perfiles de VMs para poder almacenar VMs en el datastore presentado por vSAN, esto es para poder gozar de las capacidades avanzadas que tiene este almacenamiento, mas adelante estaremos revisando cada una de las opciones y cuando debemos utilizarlas.

Arquitectura

Llego el momento de hablar sobre la arquitectura de esta nueva manera presentar almacenamiento en vSphere, comencemos revisando los pre requisitos para poder habilitar y utilizar vSAN en nuestro cluster:

  • Controladora RAID SAS- con modo “pass thru” o “hba”, es importante notar que la controladora debe de ser SAS no SATA, debido a que esta controladora puede manejar tanto interfaces SAS como SATA, puede que una controladora SATA nos permita crear el cluster pero esto no esta soportado. Se requiere tener el modo “pass thru” o “hba” en la controladora para que los discos que están siendo controlados sean accedidos directamente por el host ESXi sin RAID, para que vSAN se encargue de entregar la protección de los datos y rendimiento a nivel de software.
  • Red a 10Gbe – es importante notar que necesitamos un backbone de red para vSAN a 10Gbe esto debido a que 1Gbe puede convertirse en un cuello de botella, si lo comparamos contra soluciones que se encuentran en el mercado donde estamos hablando de “scale-out” estas generalmente requieren infiniband y/o 10Gbe, en el caso de vSAN solo se tiene el requerimiento de 10Gbe.
  • Discos SAS/SATA – Como lo comenté se requiere una proporción de 1:10 de SSDs a HDDs, estos pueden ser SAS o SATA dependiendo de los casos de uso en especifico estaremos determinando un diseño en especifico que cubra con las necesidades, sea SATA o SAS.

Una vez que entendimos los requerimientos básicos vamos a revisar la arquitectura:

vsanarchconceptual

Como podemos notar vSAN nos permite crear un sistema de archivos distribuido a partir de almacenamiento local de los servidores ESXi que participan en el cluster, en el momento que habilitamos vSAN y creamos nuestros Disk groups para definir que espacio y disco de estado solido estarán siendo utilizados para almacenar los datos se crea un sistema de archivos en el cual todos los servidores que pertenecen al cluster pueden acceder sin ningún problema, lo interesante esta en el funcionamiento “por debajo” o mas a fondo del sistema de archivos, me parece que esa imagen la estarán viendo en muchas presentaciones, webinars y demás, vamos a revisar a fondo como trabaja vSAN.

vSAN crea un sistema de archivos que ofrece protección de datos y rendimiento a través de una arquitectura de tipo “RAIN” o Redundant Array of Independent Nodes, esto permite que la capa de software (en este caso vSAN) se encargue de entregar todas las capacidades que un RAID estaría ofreciendo, lo interesante es que esto se realiza a través de nodos físicos (esxi) permitiendo tener rendimiento y protección de datos aún cuando un host ESXi no este disponible (claramente su almacenamiento local tampoco).

vsancmmds

Como podemos notar en la imagen, se requiere de una interfaz de vmkernel para la comunicación de vSAN, esta comunicación sucede a través de RDT o “Reliable Datagram Transport Protocol” que esta pensado para el envío de datagramas con una cantidad de información bastante grande de manera confiable, manteniendo prioridad en los paquetes (cosa que muchas veces en un ambiente TCP puede no asegurarse) y trabajando de la mano con el servicio de cluster que maneja vSAN llamado CMMDS “Cluster Monitoring, Membership and Directory Services” para poder determinar que conexiones y “paths” o caminos utilizar para el envio de esta información.

vmkernelvSAN

El servicio CMMDS se encarga de descubrir y mantener el listado de los nodos que pertenecen al cluster (hosts ESXi), dispositivos de almacenamiento, redes, etc. De igual manera almacena el metadata del sistema de archivos donde se encuentra información de la topología del sistema RAIN y políticas aplicas, por último detecta posibles fallas en los nodos. Algo interesante de este servicio es que tenemos un nodo del cluster ejecutando el rol “primario” mientras que otro tendrá el rol de “respaldo o backup” en el caso de tener problemas en la red o que un nodo se caiga y que este sea un nodo primario o de backup se sigue el mismo algoritmo de selección que maneja FDM (Fault Domain Manager, HA) para seleccionar sus nodos y sus roles (primario, respaldo o backup y “agent”).

Funcionamiento del sistema de archivos

Algo muy importante y que fue algo “dificil” entender para mi es que vSAN a diferencia de otros sistemas de archivos que VMware utiliza se basa en objetos, por lo que las VMs, discos, snapshots y demás son considerados “objetos”,  la manera de como se escribe a este sistema de archivos es bastante interesante y se define en gran parte por el perfil de almacenamiento de VM así que vamos a ver un caso práctico para poder entender todas las opciones que nos brinda el proveedor VASA de vSAN:

  1. Se requiere crear una VM, esta vm cuenta con ciertos SLAs definidos, Alta disponibilidad de tipo N+1,un requerimiento de 900 IOPS y que el espacio sea entregado de manera “thick”, para esto el administrador crea un perfil de VM que cumple con este SLA:vmstorageprofileejemplo
    Podemos notar en la imagen que se tienen los siguientes atributos o capacidades en el Perfil de almacenamiento de VM:*Number of disks stripes per object – aquí definimos entre cuantos discos se estará realizando un stripe del objeto (VM), tomando como el ejemplo , al requerir 900 IOPS con  base que nuestros discos nos ofrecen 150 IOPS necesitamos utilizar 6 discos para completar este requerimiento que forma parte del SLA. Se recomienda que se deje el valor por defecto de “1” esto pensando en que el cache de SSD podrá entregar los IOPS requeridos, en el momento que las lecturas o el “working set” no estén en cache (cache miss) ahí sería cuando estas estarían siendo entregadas a partir de los HDDs, todas las escrituras son servidas por HDDs de cualquier manera (aunque se realiza un buffer de estas en el SSD). Para motivos de este articulo no modifiqué el valor del stripe a 6, lo deje en el valor por defecto que es 1.* Number of failures to tolerate –  aquí definiremos la disponibilidad del objeto, en este caso seleccione 1 (n+1) por lo que el objeto será protegido por RAID1 en 2 hosts ESXi, esto permitiendo que se tenga una caída de un host ESXi y seguir manteniendo acceso al objeto o vm, es importante notar que vSAN utiliza un “witness” que vendría siendo un tercer host ESXi en este caso para poder mantener la disponibilidad del RAID1 (> 50% de los componentes), esto lo veríamos conceptualmente de la siguiente manera:numberfailures1
    Lo podemos ver mucho mas claro una vez que realizamos la entrega de la VM con ese nivel de disponibilidad desde el vSphere Web Client (importante notar que en la imagen modifiqué el stripe del objeto a que fuera 1 como es recomendado y es el valor por defecto):numberfailures1web
    Aquí notamos perfectamente el RAID1 que existe entre el host “vesxi-1” y “vesxi-3” mientras que el witness queda en el tercer host “vesxi-2”.  Claramente los escenarios que se pueden llegar a dar pueden ser muy complejos, es por eso que VMware recomienda mantener el valor por defecto de 1 lo cual nos dara tolerancia a caída de un host ESXi y podemos tener la estructura de RAID mucho mas sencilla. En un articulo futuro estaré tocando que casos podemos llegar a tener modificando estos valores.*Flash Read cache reservation – Esta propiedad nos permite dictar una reservación de flash read cache (espacio del disco SSD) para que sea utilizado por la VM/objeto en cuestión, de igual manera se recomienda dejarlo en 0% y que el hipervisor se encargue de entregar el cache bajo demanda de manera “mas” equitativa.

    *Force Provisioning – En este caso la VM es aprovisionada aún cuando no se cumpla con las características dictadas (ej. number of failures to tolerate) y cuando los recursos esten disponibles para poder cumplir dichas características estas serán aplicadas.

    *Object Space Reservation – Aquí definimos el porcentaje de disco que será entregado de manera “thick provision”.

Para la creación de la VM u el objeto se toman en cuenta todas las características definidas en el perfil de almacenamiento seleccionado, con esto tres componentes del sistema de archivos entran en acción (componentes que existen en cada uno de los hosts ESXi como parte del core del hipervisor), CLOM (cluster level object manager), DOM (Distributed object manager) y LSOM (Local Log-structured object manager), básicamente cuando se requiere crear una vm u objeto CLOM se encarga de definir y asegurarse que las características del almacenamiento y la distribución a través de los nodos ESXi que conforman el arreglo RAIN sea la correcta (que se cuenten con los disk groups para satisfacer las necesidades), esto lo realiza a través del CMMDS de cada nodo, una vez que se ha identificado que se tienen disk groups, DOM se encarga de crear los distintos componentes del objeto o VM de manera  local (a través de LSOM) y remotamente a a través de CMMDS que a su vez habla on DOM localmente en los otros nodos que estarán albergando la información (esto a través de RDT). Después del proceso de creación todas las escrituras y lecturas suceden de manera distribuida a través de DOM, todo esto esto es ejecutado “por debajo” de lo que nosotros como usuarios o administradores podemos ver, pero creo que es interesante conocer a fondo el como se maneja este sistema de archivos.

¿Como suceden las escrituras y lecturas en este sistema de archivos distribuido?

  • Escrituras – en el momento que la VM es encendida en un host, ejemplo host 5, este se vuelve “dueño” de dicho objeto (vDisk) considerando que tenemos una tolerancia a fallos de 1 este objeto o vDisk estará replicado en otro host ESXi ej. host 4, por lo que en el momento que sucede una escritura desde el Guest OS de la VM esta escritura es enviada a SSD para el buffer y en paralelo es replicada a través de la red de vSAN al host que tiene localmente la replica de dicho objeto, en este caso el host4, el “dueño” o host 5 espera un acknowledge por parte del host que tiene la replica (host 4) para que después de esto el sistema de archivos se encargue de realizar el flush del buffer de las operaciones que se tienen en SSD en ambos nodos hacia la capa de HDDs
  • Lecturas – en el momento que el guest OS realiza una lectura el “dueño” de dicho objeto (vdisk) consulta el cache de SSD para poder determinar si la información se encuentra en SSD, en caso de tener un read miss esta información será servida a partir de HDDs y posiblemente puede ser almacenada en cache (SSD) para su futuro uso. Si la operación es servida a través del cache esta lectura será distribuida a través de las distintas replicas que se tienen en el cluster (los nodos que forman parte del RAID1 de dicho objeto, maximizando el rendimiento).

Interoperabilidad y consideraciones

vSAN en su versión inicial es compatible con los siguientes productos y/o funcionalidades:

  • Snapshots de VMs
  • VMware HA (implementación específica para vSAN, esto lo tocaremos en un siguiente articulo)
  • DRS
  • vMotion
  • SvMotion
  • SRM/vSphere Replication
  • VDP/VDPA

No es compatible con los siguientes productos y/o funcionalidades:

  • SIOC
  • Storage DRS
  • DPM

vSAN no es compatible con SIOC debido a que vSAN maneja de manera independiente la optimización de las VMs. Para el caso de Storage DRS simplemente no es posible utilizarlo debido a que solo manejamos un datastore y como último DPM no puede ser activado ya que aunque el host ESXi en cuestión a ser “suspendido” no tenga VMs ejecutándose puede darse el caso que se este utilizando un disk group provisto por el mismo.

Casos de uso

Al utilizar almacenamiento local lo primero que estaremos reduciendo es el TCO o el costo de adquirir la solución, en este caso podríamos estar pensando en vSAN como un producto que nos ofrece acceso a almacenamiento con alto rendimiento, bajo costo y lo mejor de todo excelente para contar con un diseño simplificado, es decir, poder reproducir los “PODs” computacionales donde se incluya CPU, RAM, y Storage de tal manera que sea repetible (sabiendo perfectamente el rendimiento de cada POD) ¿Entonces donde haría sentido esta manera de “diseñar? Horizon View, desarrollo, QA, DR (solo se soporta vSphere Replication), otros casos de uso son naturales a este tipo de solución.

Otro punto a considerar la reducción en los tiempos operativos u OPEX, es tan simple como comparar el tiempo que toma entregar una LUN o almacenamiento a los Hosts ESXi vs trabajar con un datastore provisto por vSAN que crece y se expande conforme vamos agregando nodos que aporten almacenamiento a través de sus disk groups… ¿Alguien pensó en Software defined Storage?

¿Wake on LAN y DVS?

Que tal gente el día de hoy les voy a compartir una lección que aprendí trabajando en mi laboratorio. Como parte de la actualización que he estado realizando en el además de configurar acceso remoto a través de mi ISP y un servicio de DDNS necesitaba poder contar con encendido de los servidores y NAS de manera remota, esto como parte de mi esfuerzo en reducir el consumo de energía eléctrica que este genera.

Claramente lo primero que se me vino a la cabeza fue implementar Wake On LAN (WOL), para esto verifiqué que las tarjetas tuvieran soporte de WOL, que estuviera activada esta función en el BIOS/UEFI y que vCenter me presentase las tarjetas con soporte para el mismo:

WOLComo podemos ver, las tarjetas están soportadas (ambos servidores manejan los mismos puertos oboard, uno intel y otro realtek) verificandolo desde el cliente web de vSphere > seleccionando el host > mangage > networking > Physical Adapters:

Todo parecía estar correcto, por lo que decidí realizar una prueba con una aplicación gratuita de SolarWinds, especifiqué la MAC Address de la interfaz ethernet a la que se encuentra mapeado el puerto de vmkernel con la función de management, se envió el Magic Packet y nada sucedía…. Después de quebrarme varias horas la cabeza, estar desesperado y demás pude notar que los puertos de gestión los tenia en un switch distribuido, por lo que me di a la tarea de crear un segundo puerto de gestión que estaría compartiendo la vmnic o tarjeta de red que estaba mapeada al puerto de vmkernel que es utilizado por iSCSI y que viaja por su propio vSwitch (no distribuido):

vSwitchWOL

Me di a la tarea de realizar una nueva prueba con esta configuración y voilá ¡todo funcionaba como debía funcionar hace varias horas! 😉

El siguiente paso era simple, habilitar en mi NAS Iomega la función de Wake On LAN, por lo que simplemente ingresé a la consola de gestión (lifeline) y en “All Features > Energy Saving” confirmé que la casilla de Enable Wake On LAN estaba habilitada:

 

Screen Shot 2013-07-30 at 3.42.11 PM

Con esto ya desde cualquier ubicación sea nacional o internacional puedo hacer uso de mi laboratorio, trabajar, apagar mis equipos y tener ahorros de $$$.