vExpert

VMware 101 – partedUtil y particiones de diagnostico

rsz_vmware

Que tal gente, el día de hoy les voy a platicar de un tema muy “básico” aunque me tomo un buen tiempo recordar e investigar para poderlo configurar… es impresionante como con el tiempo vamos perdiendo práctica en temas que consideramos “sencillos” o “básicos” es por eso que quiero compartir este procedimiento para todos aquellos […]

VSAN 6.2 – Erasure coding

rsz_vmware

Que tal gente, el día de hoy les estaré hablando sobre dos nuevos mecanismos para protección de datos que nos ofrece VSAN 6.2 a través del uso de Erasure Coding, versiones anteriores de Virtual SAN solo ofrecían protección de datos (objetos y sus componentes) a través de Raid-1 o “mirroring”. Primero me enfocaré en explicar […]

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?