vSAN – File Services

Que tal gente, seguro muchos de ustedes ya leyeron o incluso probaron esta nueva capacidad de vSAN, pero creo que es bueno que comparta mi punto de vista y además en tu idioma.

File Services nos permite aprovisionar exports de NFS y shares de SMB sobre nuestro cluster de vSAN como lo hacemos con VMs, VMDKs y otros objetos. Lo interesante es que al ser aprovisionados sobre vSAN también reciben todas las características como lo puede ser redundancia de datos, deduplicación etc y todo funciona bajo el mismo marco de SPBM.

¿Porque File Services de vSAN?

File services agrega una muy esperada capacidad a nuestros clusters de vSAN, servicios de archivos a través de NFS y SMB. Esto era esperado desde hace mucho, existían maneras de poder habilitar estos servicios pero con soluciones de terceros (VMs) corriendo sobre el datastore de vSAN o incluso configurando un File Server con Windows o un servidor de NFS con linux u otro gOS pero claramente esto tiene implicaciones debido a que no estamos hablando de un sistema de archivos compartido entre todas las appliances/VMs, entre estas implicaciones tenemos:

  • Complejidad operativa – Al tener que diseñar, configurar y operar VMs, etc.
  • Posibles implicaciones de rendimiento – al tener una VM corriendo sobre vSAN y que esta funcione como el servidor de NFS o SMB podría (dependiendo de muchos factores) impactar en el rendimiento de las operaciones de I/O.
  • Consideraciones de disponibilidad – la solución seleccionada debería de ser diseñada e implementada de manera correcta para poder tener alta disponibilidad y redundancia de datos, esto puede ser a través de HA, clusters, etc.

Arquitectura de vSAN File Services

Como ya sabemos vSAN es un almacenamiento basado en objetos y el tener VMs/appliances sobre vSAN directamente presentando los servicios de datos (SMB/NFS) implicaría que se crearía uno o multiples vmdks (un objeto a nivel de vSAN) por VM pero recordemos que el acceso a dichos VMDKs es a través de bloque a diferencia de un sistema de archivos compartido entre múltiples appliances que permite montarlo de manera simultánea, es por esto que se tiene un sistema de archivos sobre vSAN llamado VDFS.

Data Path

VDFS Es un sistema de archivos distribuido que se encuentra sobre vSAN, se trata de un sistema de archivos POSIX que tiene muchas de las capacidades que esperamos en la actualidad, como lo son snapshots, clones, etc.

VDFS técnicamente puede utilizar diferentes “back-ends” en este caso usa vSAN pero podemos hablar de S3 u otro backend que sea compatible con POSIX. vSAN provee lo siguiente a VDFS:

  • Redundancia de datos (RAID-1, erasure coding)
  • Checksum
  • Encripción
  • Deduplicación
  • Compresión
  • balanceo, etc.

En el momento de habilitar File Services vCenter hace deploy de “agent VMs” en cada uno de los hosts ESXi que forman parte del cluster de vSAN, estos agent VMs son gestionadas por EAM (ESX Agent Manager), dentro de estas VMs (FSVM) tenemos contenedores basados en docker que ejecutan los servidores de SMB (Samba) y NFS (Ganesha) en la siguiente imagen podemos ver estas FSVMs en mi ambiente de pruebas:

Estas Agent VMs son las encargadas de presentar los puntos de acceso de protocolo, por lo cual en el momento de registrar un export de NFS o un share de SMB tenemos que apuntar a la IP de la FSVM en cuestión (si, existen maneras de hacer balanceo, lo tocaremos mas adelante). Una vez que un cliente de NFS o SMB comienza a tener I/O esta FSVM habla con VDFS a través de un vsock (VMCI), aquí podemos ver en el .vmx que esta presente la interfaz VMCI, se usa VMCI habilita comunicación directa entre host y la VM, sin necesidad de utilizar red:

FSVM habla con VDFS a través del protocolo 9p usando Zero-copy (los datos se envían directamente a VDFS sin necesidad de buffers) lo cual permite mejorar el rendimiento de I/O. Este path de I/O lo podemos ver en el siguiente diagrama lógico:

I/O path

Como podemos notar una vez que las operaciones de I/O son enviadas a VDFS este a su vez habla con el backend que esta provisto por vSAN para que se encargue de el manejo de los datos y aplicación de políticas especificas de vSAN, claramente existen muchos otros sub-componentes que no están descritos en este post pero el objetivo es tener un entendimiento conceptual profundo, no el entender cada uno de los componentes.

¿Que hay de la disponibilidad de los servicios de datos?

Si observamos detenidamente podemos notar que cada FSVM tiene su propia IP y su vez tenemos una FSVM por host ESXi, la lógica nos diría que estaríamos atados a dicha IP y posiblemente al host ESXi. Pero claramente esto fue considerado al tratarse de un sistema de archivos distribuido, para resolver esto se tiene un componente que se llama endpoint controller, en otras fuentes pueden encontrar que se habla de un management y control plane de VDFS, este endpoint controller pertenece a dicho control plane. Su trabajo es monitorear la salud de los servicios y manejar el failover en caso que una FSVM no este brindando el servicio (tal vez el host ESXi esta fuera de producción). El failover consiste básicamente en lo siguiente:

  1. Se detecta que se tiene problemas con un FSVM
  2. se elige un nuevo DOM owner (vSAN) para los objetos que constituyen dicha FSVM
  3. se reconstruye el cache de memoria haciendo replay del log de transacciones
  4. El proxy de VDFS al no tener respuesta de el DOM owner pasado envía las transacciones de I/O al nuevo DOM owner, claramente aquí vSAN se encarga que solo el nuevo owner pueda tener acceso exclusivo a los objetos.

¿Como escalan los File Services?

Como ya comente cada FSVM recibe una IP (que nosotros proveemos) y esto lo podemos verificar desde Skyline Health en vSAN:

  • NFS – En la imagen pueden apreciar que cada servidor tiene su propia FSVM con una IP asignada. En el caso de NFS 4.1 se maneja un namespace global pero se tiene un re-direccionamiento al contenedor (FSVM) que esta entregando dicho share, el re-direccionamiento es parte de las capacidades de NFS 4.1, esto permite que escale ya que las shares van siendo asignadas y balanceadas entre las diferentes FSVMs.
  • SMB – Para SMB podemos configurar DNS Round Robin, lo cual permite tener un FQDN único que a su vez nos balancea entre múltiples IPs.

en vSphere 7 U2 tenemos la posibilidad de crear hasta 100 shares en un cluster de vSAN.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s