Que tal gente el día de hoy vamos a continuar con la serie de artículos introductorios a VMC, hoy nos toca hablar de almacenamiento. Estaremos tocando vSAN y también servicios de almacenamiento nativo de AWS que se integran con VMC.
vSAN y VMC
Como ya comentamos en el articulo anterior todo SDDC esta basado en vSAN, es una arquitectura de vCF con un diseño apegado al VVD (VMware Validated Design). Pero claramente al tratarse de un ambiente corriendo sobre AWS existen ciertas diferencias de como se maneja vSAN.
La configuración de vSAN dependerá del tipo de hardware (Servidor físico) que seleccionemos para nuestro SDDC. Contamos con la siguiente configuración en el caso de un perfil i3 :
Como podemos ver cada servidor de tipo i3 cuenta con 8 dispositivos de almacenamiento. En este caso estamos hablando de dispositivos NVMe, con esta configuración logramos lo siguiente:
- 10.4 TiB de almacenamiento crudo o “raw”
- Los servicios de encriptación, deduplicación y compresión de datos están activos.
- 2 Disk Groups, cada uno con 1 dispositivo NVMe para motivos de cache y 3 para motivos de almacenamiento persistente (1,788GB por cada NVMe).
- Estos dispositivos NVMe son encriptados “at rest” es decir, la información es encriptada en el ultimo paso del I/O tanto en el caso de buffer como en el destage de los datos hacia la capa persistente de almacenamiento. En el caso de VMC solo se puede usar el servicio de KMS de Amazon, lo cual es diferente para ambientes de vSphere nativos donde podemos utilizar cualquier solución de KMS que sea compatible con KMIP.
- Se cuenta con múltiples datastores en un solo cluster de vSAN, la razón de esta segmentación logica se debe al requerimiento de aislar las cargas de gestión de aquellas cargas especificas al cliente permitiendo que se puedan asignar permisos específicos a cada datastore, esto habilita casos de uso como respaldos de VADP.
Algo importante que debemos tener en mente es que en el caso de VMC los discos físicos (dispositivos NVMe) son asignados en su totalidad a vSAN mientras que se asigna un volumen de EBS (Elastic Block Storage) para motivos de boot del servidor:
Elastic vSAN
Tal vez en este punto se estarán preguntando que hay sobre los servidores de tipo R5, ¿Cual es la configuración física de discos? ¿Que capacidad se nos ofrece?, etc. Aquí viene otra nueva capacidad que existe para vSAN en un ambiente VMC, Elastic vSAN.
Elastic vSAN permite flexibilidad en cuanto a capacidad se refiere a instancias R5.metal (Bare metal de AWS). Básicamente en el caso de las instancias R5 el servidor físico es considerado “diskless”, se tiene un volúmen de EBS (Elastic Block Store) para motivos de boot y N cantidad de volumenes de EBS dependiendo de la cantidad de almacenamiento que se requiera:
En el caso de las instancias R5 se cuenta con 3 disk groups que pueden ofrecer de 15 hasta 35TiB (ajustable en incrementos de 5TiB, se cuenta con compresión, encriptación y deduplicación al igual que en el caso de las instancias de tipo i3. Las instancias R5 no cuentan con discos locales (NVMe en el caso de i3), todo el almacenamiento es provisto por volúmenes EBS GP2 (General Purpose SSD).
Como su nombre lo indica, Elastic vSAN permite crecer el espacio de datastore en demanda agregando volumenes de EBS.
¿En que me baso para seleccionar instancias de tipo i3 vs R5?
La siguiente tabla detalla los casos de uso que cada tipo de instancia puede ofrecer:
| i3 | R5 | |
| Características | 10 TiB de capacidad cruda basada en dispositivos NVMe Gran cantidad de IOPs | 15 – 35 TiB (en incrementos de 5 TiB) basados en volúmenes de EBS. Menor cantidad de IOPs vs i3. |
| Caso de uso | Cargas de trabajo altamente transaccionales | Cargas de trabajo que requieren una mayor cantidad de espacio de almacenamiento o un ancho de banda mayor. |
Estén atentos a mis próximos articulos ya que al terminar los artículos introductorios empezare a hondar muchísimo mas en temas técnicos de almacenamiento, computo, red, operaciones, etc.
Arquitectura en la Nube 