esxi 5.5

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.

multicorevcd

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

dispositivosvmrc

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

modificacionhwvcd55

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

descargavcd55ovf

  • 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).

catalogoperfilstorage

  • 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 suscripcióncatalogose 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).

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.

Intel NUC – laboratorio casero.. bueno, bonito y barato

Que tal gente quería platicarles sobre una nueva adquisición para mi laboratorio, es claro que todos queremos reducir costos y hacer mas con menos, en mi caso, mi laboratorio tiene un componente que le llamo “controlcenter” que básicamente es una VM que permite conectarme desde el exterior para poder encender todos los demás componentes de la infraestructura, a través de PXE (Servidores ESXi y almacenamiento). Claramente esta VM estaba siendo ejecutada en una workstation con 16GB de RAM y tenía ESXi instalado, el problema de esta Workstation es que tenía una fuente de poder algo poderosa para la simple tarea de mantener encendida dos vms de core y resultaba costoso mantenerla arriba. Me dí a la tarea de buscar un remplazo para esta workstation y así me encontré con la magnífica Intel NUC o Next Unit of Computing:

Esta pequeña, en verdad PEQUEÑA computadora nos ofrece interesantes propiedades dignas para un laboratorio basado en VMware, en mi caso pude adquirir el modelo “DC3217IYE” que a grandes rasgos tiene lo siguiente:

IntelNuc

  * Hasta 16GB de RAM DDR3 a 1600MHz (SODIMM)

  * 1 Puerto Gigabit de Intel

  * 2 interfaces mSATA

  * Procesador Intel Core i3 3217U dual core con HT y 1.80GHz

En mi caso adquirí un SSD de 240GB mSATA lo cual me permite almacenar localmente las VMs de core sin necesidad de tener encendido mi almacenamiento central, cosa que reduce bastante el consumo de energía.

Existe otro modelo de intel NUC que tiene un puerto thunderbolt, con el cual podrían tener 2 interfaces de red gigabit utilizando el convertidor de thunderbolt a gigabit ethernet de Mac. esto les permitiría armar un laboratorio solo a partir de Intel NUC. Una consideración es el hecho que la interfaz de red no es soportada por ESXi 5.5 (almenos en el beta) por lo que deben de agregar el vib de Intel que viene con ESXi 5.1 utilizando image builder, bastante sencillo.

Aquí podemos ver mi pequeña gran caja desplazando a una workstation que ademas de consumo energetico también generaba mucho calor:

nucesxi