Mantenimiento y migración al blog

Que tal, solo para comentarles que es posible tener ciertos contratiempos accesando mi blog durante los proximos dias, ya que estaré migrando mi hosting, todo para poder incluir nuevas funcionalidades y capacidades al blog.

 

Saludos!!!

Tips de Diseño – VADC y oficinas remotas con Horizon view 5.3

Que tal gente el día de hoy vamos a revisar algunos tips o puntos para considerar cuando diseñamos una solución distribuida de Horizon View (branch offices). Estos puntos fueron comentados en una lista de distribución interna en VMware y me parece que es importante compartirla con ustedes.

Para conocer mas sobre VADC (View Agent Direct Connect), les sugiero los siguientes artículos:

• http://blogs.vmware.com/euc/2013/10/read-all-about-it-vmware-horizon-view-5-3.html

• http://myvirtualcloud.net/?p=4125

• http://myvirtualcloud.net/?p=4150

• http://blog.hispavirt.com/2013/08/05/pcoip-y-modem-de-telmex/

Básicamente VADC nos permite tener una conexión de PCoIP directa desde un cliente de Horizon View hacia un agente de Horizon View en un escritorio virtual, esto sin necesidad de tener un Connection Server de pormedio.Aquí lo interesante es que debemos tener en consideración cuando estemos integrando VADC en nuestros diseños distribuidos de Horizon View, vamos a echarle un ojo a los puntos importantes que debemos tener en mente:

• VADC no es un remplazo para un servidor de Conexión, este “plugin” del agente esta pensado para ambientes multi tenant (DaaS) y donde debemos de asegurar la operación de los escritorios aún cuando se tenga un problema en la conexión entre sitios y oficinas remotas (WAN).

• Siempre debemos de intentar colocar un servidor de Conexión para poder realizar las tareas de aprovisionamiento y manejo de sesiones.

• La limitante de separar Servidores de Conexión (standard y sus replicas) a través de WAN continua, esto debido a la base de datos de ADAM local.

• A partir de la versión 5.2 de Horizon View se soportaba la separación geográfica de agentes y clientes a través de WAN, lo interesante aquí es que con la disponibilidad de VADC ahora podemos combinar ambientes distribuidos con gestión de Connection Servers, es decir, podemos instalar el “plugin” de VADC en el agente de los escritorios que estarán sirviendo a oficinas remotas y que estos sean entregados y gestionados a través de View Manager. En el caso de una falla en el enlace de el Servidor de conexión y los escritorios los clientes locales de las oficinas remotas continuarán teniendo acceso a su escritorio debido a VADC.

Como pueden ver son puntos bastante sencillos pero que vale la pena tener en mente cuando comencemos un diseño distribuido de Horizon View incluyendo VADC.

¿Que hay de nuevo en Horizon View 5.3?

Que tal gente, el día de hoy vamos a hablar sobre lo nuevo que se agrega con este release de Horizon View 5.3, en su principio la versión internamente estaba considerada como 5.2.1, pero es claro que la cantidad de capacidades e impacto de las mismas modificó esto y se entregó como una versión diferente.

¿Que tenemos de nuevo?

• Soporte para VSAN – esto esta bastante interesante ya que podemos tener escritorios virtuales completos o de linked clones residiendo en un datastore presentado por VSAN, recordemos que VSAN en este momento se encuentra como beta por lo que Horizon View 5.3 entrega esta capacidad como “tech preview”. VSAN tiene muchas ventajas, si alguna vez tuvieron el tiempo de leer un whitepaper de VMware sobre stateless desktops donde se empleaba almacenamiento local y SSDs para las replicas podían darse cuenta de lo práctico que es esa arquitectura, esto debido a que no requerimos de almacenamiento centralizado.Con VSAN tenemos almacenamiento en cluster y distribuido por lo que gozamos de todas las capacidades de cluster que VMware ofrece y además conforme se requiera podemos ir agregando nodos (hosts ESXi con SATA/SAS y SSDs) y así ir creciendo este almacenamiento distribuido. Si quieren leer mas sobre VSAN les recomiendo mi articulo de Deepdive: VSAN deepdive.
  Es importante saber que en esta versión no se soporta SPBM (Storage Policy-Based Management) entre Horizon View y VSAN, solo se puede utilizar el datastore para almacenar las VMs con la política de VSAN por default para todos los objetos (vmdk, vmx, vswp…)

• Soporte para escritorios basados en Microsoft Windows 2008 R2 – Desde mi perspectiva esto es “GRANDE” ¿Porque? porque ya podemos comenzar a hablar de DaaS a un precio razonable, si quieren conocer como afecta el licenciamiento de sistemas operativos de Microsoft para usuario final en un ambiente DaaS les recomiendo buscar en google SPLA y VDA pra enterense como es mas caro tener una estrategía de escritorios virtuales como servicio basados en Windows7/8  que ofrecer escritorios virtuales basados en sistemas operativos de servidor (suena ilógico, pero así son nuestros buenos amigos de Microsoft). Con esto ya tenemos la opción de entregar escritorios basados en Windows 2008 R2 (SE REQUIERE SP1) y cumplir SPLA (Service Provider License Agreeement), existen algunas modificaciones manuales que tenemos que realizar para poder instalar el agente y poder mostrar los escritorios en horizon view manager, primero tenemos que modificar la base de ADAM local de Horizon View Manager y encontrar el siguiente objeto “Object: CN=Common,OU=Global,OU=Properties”, en sus propiedades podemos encontrar “Set pae-EnableWindowsServerMachines”, esto tendrá que ser modificado para poder considerar Windows 2008 R2 como un sistema soportado en Horizon View… Por último, la instalación del agente debe de realizarse con el siguiente parámetro /V”VDM_FORCE_DESKTOP_AGENT=1”.

• Soporte completo para vDGA – vDGA o “Virtual Dedicated Graphics Acceleration” nos permite asignar un GPU de una tarjeta física hacía una VM, esta VM utiliza dicho dispositivo como hardware directo esto habilita el uso de gráficas aceleradas por hardware en una VM. Esta funcionalidad hace uso de Intel VT–d para redireccionar a través de un passthrough el GPU en específico hacia una VM, por lo que cada VM habilitada con vDGA estará utilizando un GPU dedicado gestionado por el driver de gráficos NVIDIA.

• Soporte completo para VCAI – VAAI para NFS así de simple, antes de esta versión, VCAI o “View Composer Array Integration” era soportado únicamente como tech preview con la llegada de Horizon View 5.3 da soporte completo e incluso ya existe un partner de storage 100% certificado con VCAI.

• Soporte para Windows 8.1 – Se agrega Windows 8.1 como gOS soportado para los escritorios virtuales.

• View Direct Connect Agent –  También conocido como VADC, este add–on de Horizon View agent ya existía desde versiones anteriores solo que era entregado únicamente a partners que proveían y proveen escritorios como servicio (DaaS), un ejemplo de esto sería Desktone (Ahora parte de VMware), donde la conexión hacía los escritorios virtuales sucedía directamente al agente y no a través de un broker (Horizon View Connection Server).
  Existen múltiples casos de uso para este add–on, como ya lo dijmos uno sería DaaS, otro podría ser branch offices para no depender de una WAN, cuando la cantidad de escritorios no justifique tener un servicio de brokering completo y muchos mas. En mi articulo “PCoIP y Modem de Telmex” pueden ver como accedo a mi ambiente de laboratorio utilizando VADC, bastante práctico y un rendimiento excelente por PCoIP.

• Soporte para ThinApp 5.0 – Se agrega soporte para la última versión de ThinApp.

• Soporte para Horizon Mirage – Esto también lo considero como “GRANDE” ya que el soporte de Horizon Mirage en ambientes de escritorios ha sido esperado desde hace mucho tiempo, ya podemos gozar de lo mejor de los dos productos con las versiones Horizon View 5.3 y Horizon Mirage 4.3. Estense atentos para la semana del 12 de noviembre, donde podré compartir con ustedes datos mas técnicos :D.

• Mejoras en el protocolo Blast – se agregan capacidades interesantes al protocolo basado en HTML5, donde ya contamos con reproducción de audio, portapapeles (una implementación especial a través de un recuadro donde pegamos el texto), full screen y mejoras a nivel del despliegue.

• Soporte para RTAV en Linux – se agrega soporte para clientes basados en Linux para RTAV o “Real Time Audio & Video”, si quieren conocer que es RTAV aquí les dejo mi articulo sobre el feature pack 2 de Horizon View 5.2 donde fue agregada esta capacidad “Novedades de Horizon View 5.2 – Feature pack 2″.

• Mejoras en View persona Management –

• Soporte para MMR en Windows – MMR permite el redireccionamiento de video para que este sea procesado por el endpoint (dispositivo donde nos conectamos), con esto logramos reducir consumos de ancho de banda debido a que el contenido original de multimedia (video, específicamente MPEG-4/H.264) es enviado al endpoint para su procesamiento, debido a esto se requiere que el endpoint sea windows7 u 8. Aparte de reducir consumos en ancho de banda también logramos una reducción en el consumo de los recursos en nuestros servidores ESXi ya que el procesamiento ya no sucede en la VM y es enviado a través de PCoIP. Es importante saber que MMR solo envia el video y no el audio, debido a que el video será procesado por el cliente este deberá contar con una GPU compatible con DXVGA (DirectX Video Acceleration).
  

Intense School, buena fuente de información y entrenamiento

Que tal gente, solo una pequeña noticia/anuncio, comencé a escribir para un sitio llamado Intense School, donde pueden encontrar recursos de entrenamiento en distintos productos de manera gratuita. Intense School provee entrenamiento personalizado y en sitio para profesionales de TI, les recomiendo dar un vistazo a todos los articulos gratuitos que tienen de distintas tecnologías.

Pueden encontrar todo este material en la siguiente liga:

resources.intenseschool.com

Aquí podrán encontrar los distintos artículos que estaré escribiendo, cabe destacar que esta en ingles. Mi primer articulo lo encuentran en esta liga:

http://resources.intenseschool.com/delivering-euc-enabling-byod-with-vmware-horizon-suite/

Espero puedan tomarse el tiempo para leer mis artículos, donde trato de no  ser 100% técnico como usualmente escribo sino revisar algunos otros tipos de consideraciones.

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:

Una 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:

A 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:

¿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:

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:

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:

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

Cuando 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:

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:

Despué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:

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:

Como 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.

 

 

 

vCloud Director 5.5 – ¿Que hay de nuevo?

Que tal gente, el día de hoy vamos a hablar de lo nuevo que nos ofrece vCD 5.5, hemos estado revisando lo nuevo que nos ofrecerá vSphere 5.5 en el momento que sea liberado al publico (GA), pero todavía no tocamos otros productos que también fueron mejorados entre los cuales se encuentra vCD.

Mejoras a nivel de vApp

Aquí estaremos revisando las mejoras que impactan directamente a nuestras VMs o servicios:

• Soporte para vm compatibility o harware virtual versión 10 –  permitiéndonos  utilizar adaptadores SATA para los discos de las VMs y CD/DVD.

• Multi–core vCPUs – Esto nos permite definir múltiples cores en cada socket de vCPU, generalmente esto nos beneficia en temas de licenciamiento. Recordemos que la manera de realizar la asignación de pCPUs vs vCPUs a nivel del host ESXi es exactamente igual, un core virtual o un vCPU uni core son asignado de la misma manera por el scheduler de el vmkernel.

• Uso de dispositivos USB desde el cliente de VMRC – en versiones anteriores podíamos redireccionar dispositivos como CDs y floppys, ahora se agrega la capacidad de poder redireccionar dispositivos USB.

• Modificación de hardware en “caliente” – esto puede resultar bastante interesante, tenemos la posibilidad de modificar el hardware virtual de una VM dentro de un vApp. Podemos agregar, quitar y crecer en “caliente” discos duros, de igual manera podemos agregar tarjetas de red (vNICs) en caliente, removerlas, conectarlas y desconectarlas (esto no es posible solo a nivel de la vNIC principal). Por último podemos agregar vCPUs multicore en caliente.

• Personalización de templates de vApp – Tenemos la posibilidad de modificar el hardware virtual de un template de vApp antes de agregarlo a nuestra “nube”, esto nos permite modificar la o las VMs que pertenezcan a este vApp a nivel de vCPU, RAM, y discos duros. Debemos de tener las siguientes consideraciones, solo se soporta hw virtual 8 en adelante, no podemos modificar la cantidad de cores, no podemos re dimensionar discos con snapshots y/o que sean fast provisioned y en el caso que agreguemos espacio a un disco a nivel del gOS necesitamos configurar el OS para utilizar dicho espacio.

• Importar y exportar OVFs – se nos permite en esta versión importar vApps directamente desde templates y de igual manera exportar un vApp como OVF. Algo bastante interesante es la capacidad de poder “resumir” conexiones interrumpidas, por lo que si tenemos un problema al importar un OVF de varios GB podemos resumir la transferencia. También se nos permite la descarga desde el catálogo de distintos archivos, como ISOs, vApps, etc. (estaremos hablando un poco sobre la capacidad de los catálogos mas adelante)

• Operaciones a nivel de vApp con estado de memoria activo (encendida) – Se nos brinda la capacidad de poder clonar la memoria activa de un vApp que puede estar en funcionamiento o suspendida. Esto nos permite 3 tipos de operaciones, clonar un vApp encendida/suspendida, capturar al catálogo un vApp encendida/suspendida y exportar un vApp suspendido a OVF. Esto es posible a través de snapshots que suceden a nivel de vCenter, es importante notar que si exportamos un vApp con estado de memoria OVF y lo deseamos importar en otra instancia de vCenter la memoria será descartada.

• Personalización de Guests – las capacidades que se tienen a nivel de vCenter para personalizar y modificar los gOS al momento de realizar la entrega a partir de templates ya es exactamente la misma que tenemos a nivel de vCD, también se agrega la capacidad de poder importar especificaciones a través de xml.

• Shadow VMs – el mecanismo de “shadow vm” existe desde la versión 1.5 de vCD, esto fue pensado para aquellas vApps que utilizan Fast Provision, básicamente al realizar la entrega de un vApp que este basado en Fast Provisioning este dependerá de la imagen base (muy parecido a lo que tenemos a nivel de Horizon View con linked clones), el problema surgía en el momento de tener entrega de vApps a través de distintos datastores que puedan incluso estar en distintos vCenters, para esto se realiza una copia de la imagen base en el datastore destino a partir de la cual los clones estarían accediendo. En la versión 5.5 tenemos la opción de realizar un “eagerly provision” que básicamente estará creando estos shadow VMs en el background, toma en cuenta un concepto de “hubs” que para nosotros serían resource pools (pVDC) y storage profiles presentados a dicho pVDC o “hub”, en el momento que se detecta que un datastore con un consumo alto (alerta amarilla) se creará en otro datastore que pertenezca a dicho storage profile el shadow vm para no tener impacto a nivel del aprovisionamiento de nuevos vApps (básicamente espera para la creación de los shadow VMs). Esto no esta habilitado por defecto tenemos que habilitarlo a través del archivo global.properties

Catálogos

En esta sección tenemos capacidades que vienen a cubrir distintas peticiones por los usuarios de vCD, podemos ver casos de uso distribuidos, tiering etc. Vamos a conocer las nuevas capacidades:

• Soporte para distintos perfiles de almacenamiento – En versiones anteriores de vCD el catálogo de una organización era colocado en el perfil de almacenamiento que era asignado a el pVDC a partir del cual se proveian recursos a la misma, esto generalmente impactaba de manera negativa teniendo información con un requerimiento de almacenamiento distinto a las vApps de producción. En la versión 5.5 podemos asignar un perfil de almacenamiento en específico para que el catálogo sea almacenado (ej. Tier3 / SATA).

• Publicación, suscripción y almacenamiento remoto – En el momento de la creación de un catálogo podemos definir si este tendrá la capacidad de ser publicado de tal manera que otros catálogos puedan sincronizarse con el, es decir, poder copiar la información (vApps, ISOs, etc) que viven en el. Todo cambio que es realizado en el content catalog origen será reflejado en aquellos catálogos que estan suscritos al mismo, esto se maneja a través de versiones de el catálogo, aquí podemos pensar en distintos casos de uso, por ejemplo, publicación de un catálogo a distintas organizaciones, ambientes distribuidos geograficamente, distintas instancias de vCD, etc. El catálogo a ser suscrito deberá presentar una password y el link para suscribirse, una vez que este esta suscrito a través de un protocolo llamado vCSP (VMWare Content Suscription Protocol) se realizarán las deciciones si se necesita actualizar cierto archivo que tenga una nueva versión o que sea nuevo en el catálogo, todo esto sucede siempre a través de un “pull”, es decir, el catálogo suscrito descargará la información del catálogo origen, nunca se tendrá un “Push” de información.  Algo interesante es que los suscriptores pueden seleccionar un modelo “on–demand” que unicamente descarga el metadata de dicho catalogo y no la información en su totalidad, el listado de objetos mostrará todo el contenido y en el caso de requerir un objeto (ej. ISO) se realiza una sincronización manual con un click derecho y “syncrhonize”.
  Se permite que el “publicador” (al cual los catálogos se sincronizan) no sea un catálogo existente sino almacenamiento que pueda trabajar con JSON (Java Script Object Notation) para publicar y sincronizar los archivos que puedan ser almacenados en este mismo… (¿OpenStack Swift?)….
  Por último es interesante saber que el catálogo ya puede almacenar todo tipo de objetos, no solo ISOs, templates, etc..

Acceso y configuración

• Soporte para CentOS 6.x como gOS donde instalar vCD.

• Preparación de Hosts para vCD 5.5  – en versiones anteriores se requeria de manera forzosa preparar los Hosts ESXi que serían utilizados por vCD, esto entre otras tareas instalaba el agente de vCD o vslad. En la versión 5.5 a menos que se requiera de VCNI (vCloud Network Isolation) se tendrá que instalar el agente, si no es necesario y los hosts son versión 5.5 de vSphere no se requerirá el agente de vCD.

• Storage Profiles – vCD 5.5 puede trabajar con Profile Driven Storage y  Storage Policy Based Management (SPBM) que esta disponible en la versión 5.5, ambos los presenta como storage profiles… Para conocer mas sobre SPBM les sugiero leer el siguiente articulo de la oficina del CTO de VMware “Storage Directions for the software defined datacenter”

• HTML5 – para los clientes basados en OSX (Firefox y Chrome) se ofrece acceso a la consola de la VM a través de HTML5 sin necesidad de un plugin. No se trata de un sustituto para el VMRC, ya que este no soporta dispositivos USB, CDs, etc, no realiza un “grab” o capturado del cursor, no toma las combinaciones de teclas, etc.. es muy parecido a VNC.

Extensibilidad

vCD 5.5 tiene la capacidad de registrar dos extensiones para interactuar con ellas, vFabric Data Director y Cloud Foundry. Esto permite a los administradores presentar a las organizaciones servicios de DBaaS (Database As A Service) y SaaS (Software As A Service).

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

NOTA: Aquí comparto con ustedes lo que yo he aprendido a lo largo del tiempo, no es la verdad absoluta ni pretendo ser experto en el tema (al menos en el momento que escribo este articulo) por lo que si en este articulo notan errores o áreas que puedan ser mejoradas, modificadas, etc. Por favor ¡Comenten!  Recuerden que estamos acá para compartir conocimiento y ser lo mas acertados posible.

Que tal gente, el día de hoy les voy a hablar sobre algo que esta en todos,TODOS lados… que al igual que el cloud computing o “computo de nube” ha sido repetido una y otra vez hasta que nos (Hemos ¿cansado?) familiarizado con el. En esta ocasión estaré hablando sobre Openstack, daremos un vistazo a que es Openstack, que necesidades o casos de uso cubre y donde exactamente estaría situado en nuestro datacenter o en el stack de software y de igual manera estaré hablando de que NO es openstack.

En VMworld asistí a varias sesiones de Openstack debido a que mi interés ha crecido bastante por lo que me dí a la tarea de dejar de ser alguien que lee sobre el tema y pasar a ser alguien que conozca openstack y pueda contribuir a la comunidad de habla hispana sobre este tema.

¿Que es Openstack?

Openstack es un conjunto de proyectos “open-source” o de codigo abierto, en sus inicios quienes contribuyeron con mas código fué rackspace y la NASA. Este conjunto de proyectos y grupo de empresas/desarrolladores tienen como objetivo el construir una plataforma de nube, como tal Openstack podría considerarse como un CMP o “Cloud Management Platform” que permite orquestrar y gestionar distintos aspectos de una infraestructura para dar servicios de nube. Si quisieramos hacer una analogía contra el stack de VMware, Openstack estaría al mismo nivel de vCAC (aunque podría compararse en ciertos puntos con vCD).

Lo interesante de OpenStack es su capacidad de extensibilidad a través de APIs que son “faciles” de consumir (muy al estilo de AWS), públicos y son “vendor free”, por lo que muchos service providers han volteado a ver a OpenStack como un posible elemento clave para su infraestructura. Esta pensado de manera modular de tal manera que en base a los requerimientos de “nube” que se necesiten entregar podemos ir integrando distintos proyectos a nuestra arquitectura.

Existen varios proyectos que conforman a Openstack, vamos a revisar los mas relevantes (para quienes venimos de un mundo VMware):

Imagen compartida por Scott Lowe @scott_lowe

• OpenStack Compute (Nova)  – Este componente y/o proyecto de OpenStack se encarga de el ciclo de vida de las “instancias” que si lo comparamos con vSphere serían “VMs”, se comunica con los distintos hipervisores a través de APIs específicos a cada uno (KVM, ESXi, QEMU, Xen, y demás) para instanciar o crear estas VMs decidiendo donde deberán ser ejecutas las mismas y brindando los distintos servicios que estas requieren. Al igual que todos los componentes de OpenStack tiene APIs para su integración y consumo del servicio. En el caso especifico de VMware OpenStack ofrece dos “drivers” vmwareapi.VMwareESXDriver y vmwareapi.VMwareVCDriver para integrarse y poder hablar con vSphere, el primer driver nos permite consumir recursos de ESXi directamente mientras que el segundo permite consumir recursos desde un vCenter (construcciones lógicas como un cluster de DRS).

(Cluster de vCenter registrado en Nova)

• Glance – este servicio nos permite almacenar “imágenes” para nuestras “instancias” o VMs, estas imágenes pueden ser almacenadas en formatos como ISO, OVF, etc.. Puede trabajar en conjunto con Swift para poder contar con almacenamiento sea local,  S3 de Amazon, etc.

(imagenes disponibles vistas desde horizon)

(Detalles de la imagen a través de glance)

• Swift – almacenamiento de “objetos”, nos permite almacenar archivos considerados como objetos, pero estos al final del día no serán montados como directorios o utilizados como puntos de montaje, tiene una estructura de contenedores donde serán almacenados los distintos objetos.

• Cinder – Cinder nos permite presentar almacenamiento de bloque directamente a las instancias, este proyecto surgió como la evolución de nova–volume (que forma parte de nova) que permite montar almacenamiento de bloque a través iSCSI directamente a las instancias para que a través de LVM estas puedan utilizar dicho espacio como persistente. De igual manera nos permite presentar NFS a las instancias.

(Prueba de volumen 1GB)

• Neutron (antes Quantum) – este proyecto nos permite entregar networking a nuestras instancias, trabaja de la mano de distintos fabricantes para entregar el acceso, por ejemplo VMware a través de NSX, Cisco, etc…

• Horizon – este proyecto nos ofrece gestión de OpenStack desde una interfaz web, aquí podemos crear instancias, modificarlas, gestionar swift, conectarnos a una consola de VM, etc, etc…

• Keystone – servicio de identidad, maneja el autenticación, acceso y permisos a distintos componentes como nova, swift, cinder, y demás. Tiene su propio API (RESTful) para el consumo e integración con 3eros. Nos permite gestionar usuarios, grupos y roles. Trabaja a través de “tokens” para brindar acceso a los demás servicios una vez que se ha autenticado a un usuario.

Como podemos ver distintos proyectos conforman el “framework” de OpenStack, en este articulo no tocamos todos los proyectos que están allá afuera, pero estaré escribiendo artículos de mayor profundidad en los proyectos y tratar de hablar sobre los que aquí no fueron descritos.

¿Que NO es Openstack?

OpenStack no es:

• Un producto – como lo hemos visto a lo largo del articulo se trata de un conjunto de servicios, que constituyen una nube. Es open source, por lo que el código esta allá afuera y lo podemos modificar para nuestras necesidades e incluso contribuir de vuelta a la comunidad. Este conjunto de código es mantenido y controlado por la fundación OpenStack.

• Virtualización (hipervisor) – pudimos ver que Nova compute habla con hipervisores para poder crear instancias y demás, pero quien virtualiza es el hipervisor en cuestión… ej. ESXi, XenServer, KVM, etc… No nos confundamos, cuando estamos creando un ambiente de nube no necesitamos decidir si vamos a irnos por VMware o por OpenStack (al menos en esa capa de virtualización) ya que OpenStack esta en una capa muy arriba de la nube, podría competir con vCD y vCAC hablando específicamente de VMware y con otras CMPs de 3eros que están allá afuera.

• 100% Gratis – Recordemos que aunque el código sea abierto y que nosotros podemos construir nuestra infraestructura a partir de OpenStack no quiere decir que los costos para mantenerlo, entrenamiento, troubleshooting, gestión y mantenimiento de capas que estén por debajo (ej. vSphere, networking, storage, etc.) sean gratuitas. Los Distros mas grandes de Linux están comenzando a ofertar su “sabor” o flavor de OpenStack, tenemos a Red Hat, a Canonical, etc. en este caso claramente se tendrá un costo no por el código si no por el soporte y demás.

• Solo para Service Providers – OpenStack puede ser utilizado por cualquier tipo de empresa, no solo SPs, claramente la modularidad y facilidad de consumo a través de APIs es lo que hace tan interesante OpenStack para los SPs.

Algunos casos de Uso

OpenStack ofrece la capacidad de IaaS muy al estilo de AWS, donde las cargas,instancias o VMs, como nosotros nos guste llamarlas no son del todo tratadas a un nivel tan especifico como lo podemos hacer a nivel de vSphere+vCD, vSphere+vCD+vCAC, esto debido a que no existen mecanismos para el control de los SLAs (alta disponibilidad, control de “noisy neighbors (NetIOC,SIOC, etc)”, donde tal vez el brindar alta disponibilidad lo realizamos a través de la aplicacion/gOS, donde básicamente tenemos que diseñar para el fallo. Ambientes enterprise donde manejemos aplicaciones tier1 que tienen que cumplir al 100% con sus SLAs, tener manera de asegurar el rendimiento y demás (básicamente consentirlas mas :D) en este punto se verían mas beneficiadas de ambientes basados en vSphere.

Les recomiendo TOTALMENTE leer dos artículos de Massimo Re Ferre @mreferre sobre este tema donde podrán entender el principio de como se tratan a las cargas en distintos tipos de nube y cuales son indicadas para que tipo de aplicación y/o servicio:

http://it20.info/2012/12/vcloud-openstack-pets-and-cattle/

http://it20.info/2011/04/tcp-clouds-udp-clouds-design-for-fail-and-aws/

Entonces, regresando al tema de VMware vs OpenStack, mas bien les diría que piensen en OpenStack sobre “(aquí va el hipervisor/CMP)”…

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.De 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.

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”

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.

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:

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):

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:

Cada 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 re–crearlo 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:

• 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