Que tal gente, el día de hoy regreso a escribir sobre un tema que me encanta, VCF. Lo que me gusta de VCF es que integra todas las tecnologías que mas me gustan de el stack de VMware, vSAN, NSX y claramente vSphere y esto permite que tenga casos de uso súper interesantes y claramente desde una perspectiva de diseño lo hace bastante atractivo para mi.
¿Que es VCF?
Vamos a comenzar hablando desde una perspectiva general, VCF es un “stack” de productos que integra todos las tecnologías definidas por software de VMware, vSphere y diferentes productos para la gestión del ciclo de vida de la misma plataforma, todos estos productos han sido probados y están listados en un BOM (Bill Of Materials), la siguiente imagen nos muestra las diferentes versiones de los componentes incluidos en VCF 4.0:
Lo interesante de tener un BOM es el hecho que no tenemos que poner tiempo en verificar y asegurarnos que los diferentes componentes que nosotros queremos incluir en un diseño van a trabajar de manera correcta entre si, no vamos a encontrarnos sorpresas o problemas ya que VMware engeneering ha puesto bastantes horas en verificar compatibilidad, escalabilidad y también el identificar posibles bugs para que la puesta a punto y operación de un ambiente de VCF sea predecible.
Existen dos componentes que son únicos a VCF:
- Cloud Builder – Aunque no encontramos este componente dentro del diagrama conceptual es un elemento clave para VCF. Su rol es el de instalar los componentes necesarios para poder hacer hand-off a SDDC Manager y que este continúe con toda la puesta a punto de VCF. Tiene la capacidad de incluso instalar ESXi directamente en servidores físicos que no tengan el hipervisor aún, para esto usa un componente llamado VIA o VMware Imaging Appliance, además de poder hacer la instalación del hipervisor también realiza la instalación de vSpher (vCenter, PSC), la configuración de vSAN, instalación de NSX-T y componentes de la suite de vRealize.
- SDDC Manager – Este es el corazón de las operaciones en un ambiente basado en VCF, desde SDDC Manager se entregan todos los Workload domains (hablaremos de esto mas adelante), instala y gestionamos el ciclo de vida de componentes de software y de la misma plataforma, se realizan cambios de configuración en objetos gestionados, gestión de certificados, passwords, parches de vSphere y demás.
Todos los demás componentes de software ya los conocemos, como lo son vSAN, NSX, vCenter y log insight. Podemos entregar soluciones como PKS y Workspace ONE y diferentes productos de la suite de vRealize dentro de VCF siguiendo lo que se le conoce como “prescriptive guidance” (VVD) o un “Manual Guidance”.
¿Que es un Workload Domain?
Desde la perspectiva de VCF un Workload Domain (WLD) se considera como un SDDC lógico que puede estar constituido por uno o mas clusters de vSphere, existen dos tipos de WLDs, un WLD de Management (el cual es configurado durante el inicial de “bring-up”) y los WLDs de VI o computo, es importante notar que todo WLD tiene su propia instancia de vCenter Server dedicada y una instancia de NSX-T dedicada o compartida con otros WLDs:
Desde SDDC Manager podemos configurar nuevos WLDs y sus instancias de vCenter estarán conectando a los existentes a través de Enhanced Linked Mode (ELM), se tiene un máximo de 15 WLDs (incluyendo el WLD de management). Claramente esta segmentación logica con WLDs nos permite crear ambientes dedicados a diferentes tipos de carga de trabajo, como Servidores, contenedores, VDI, etc. Es importante notar que al tener la capacidad de agregar múltiples clusters por WLD nuestras opciones de diseño son bastante amplias, podemos tener diferentes perfiles de hardware para temas de rendmiento, SLAs, distribución entre racks, etc, estaré escribiendo un articulo exclusivamente para temas de diseño en el contexto de WLDs.
Management Workload Domain
El Management Workload domain es donde se ejecutan todos los componentes de administración, como SDDC Manager, vCenter, la instancia de NSX Manager y un clúster de NSX Edge para admitir redes virtuales AVN / Application (si está habilitado durante el Bringup, hablaremos de AVN en artículos futuros). Se tienen algunas consideraciones para el WLD de Management:
- Se requieren al menos 4 hosts para este WLD a diferencia de los WLDs de VI donde puedes tener un mínimo de 3 hosts.
- Este WLD tiene como almacenamiento principal vSAN.
- Se puede tener NFS como almacenamiento secundario, para crear datastores de NFS.
Existe un modelo de arquitectura consolidada donde podemos ejecutar cargas de trabajo de VI dentro del mismo Management WLD en este caso la segmentación de recursos entre los componentes de gestión y las cargas de trabajo será realizada con Resource Pools. Estaremos hablando de las diferentes topologías soportadas para VCF en un articulo separado.
Virtual Infrastructure Workload Domain
Los VI WLDs será donde estaremos ejecutando las cargas de trabajo, asumiendo que estamos hablando de una arquitectura standard de VCF (MGMT + VI WLDs) y no de una colapsada. La creación de estos VI WLDs se realiza desde SDDC Manager, una vez creados tendremos lo siguiente:
- Instancia dedicada de vCenter Server estará siendo ejecutada dentro del MGMT WLD, dicha instancia de vCenter formara parte del mismo SSO, debido a esto es que tenemos un máximo de 15 WLDs ya que ELM (Enhanced Linked Mode) tiene un máximo de 15 vCenter Servers federados. En el caso de VCF 4.0 los PSCs (que corren embebidos dentro de vCenter) forman una arquitectura de tipo “ring”, es decir, PSC02 (VI WLD 01) se registra con PSC01 (MGMT WLD), PSC03 con PSC04 etc hasta que la ultima PSC se registra con la PSC inicial, esto entrega un nivel de resiliencia bastante alto.
- Se tiene uno o mas clusters de vSphere, lo interesante acá es que tenemos múltiples opciones disponibles para el almacenamiento VMFS (FC, iSCSI), NFS y vSAN. Si quisiéramos crear un VI WLD que contenga FC como almacenamiento principal lo podemos hacer (a partir de la versión 3.9 de VCF) solo será cuestión de hacer la reclamación de los hosts desde SDDC Manager que previamente hayan sido zonificados para los LUNs de FC. Esta flexibilidad de contar con múltiples tipos de almacenamiento además de vSAN permite casos de uso como lo puede ser Tiering según SLAs (con base a hardware especifico y almacenamiento), migración de ambientes de almacenamiento tradicional a vSAN y claramente el aprovechamiento de inversiones existentes.
- Tenemos la opción de contar con una instancia dedicada de NSX-T o compartida.
- Podemos decidir si gestionar el ciclo de vida con Update Manager o vLCM (Lifecycle Manager).
La siguiente imagen nos deja ver como se vería un inventario de vSphere con un MGMT WLD y un VI WLD, creo que así nos queda mas claro 🙂
Estén pendientes a artículos futuros donde estaré yendo mucho mas profundo en temas técnicos y de diseño de VCF 🙂 espero les sea de utilidad.
Saludos!
Arquitectura en la Nube 