VMware Cloud Foundation – Arquitecturas y recomendaciones de diseño

Que tal gente el día de hoy quiero platicarles de consideraciones de diseño en un ambiente de VCF. Vamos a revisar las opciones de topologías soportadas (sin stretched clusters, esto será visto en otro post), ventajas de multiples WLD vs WLDs con múltiples clusters, etc.

Topologías de VCF

Existen dos opciones cuando se esta diseñando un ambiente de VCF, arquitectura estándar o colapsada.

Arquitectura Estándar

• En esta arquitectura tenemos un Management Workload domain que es instalado y puesto a punto durante el proceso incial de “bring-up”, Se agregarán WLDs de VI bajo demanda conforme se vaya requiriendo mas recursos o una segmentación de los diferentes casos de uso.

• Recordemos que cada que se agregue un nuevo WLD de VI se hará deploy de un vCenter para gestionar dicho WLD que se ejecutara dentro de el WLD de management, esto para aislar las cargas de trabajo de aquellas que solo son de gestión. También se podrá optar en compartir un NSX Manager Existente o hacer deploy de uno dedicado que al igual que vCenter estará siendo ejecutado en el mgmt WLD. Algunas de las razones por las cuales se tiene un mapeo de 1:1 de vCenters y WLDs son la gestión de licenciamiento, escalabilidad y gestión de ciclo de vida independientes.

• Se requiere al menos 7 hosts ESXi en una arquitectura estándar, esto debido a que es mandatorio contar con 4 hosts para el mgmt WLD y al menos 3 hosts ESXi para un WLD de VI.

• Se soporta múltiples clusters en cada WLD (los limites están definidos por aquellos limites de clusters en un vCenter).

Arquitectura Consolidada

• En este modelo de arquitectura tenemos solo un WLD que es el de gestión, este MGMT WLD estará ejecutando cargas de trabajo productivas y aquellas de infraestructura/management.

• Se hace uso de Resource Pools para segmentar los recursos entre cargas productivas y de gestión, pero estarán siendo ejecutadas en el mismo WLD.

• Se puede migrar de un modelo consolidado a un modelo estandar haciendo commission de al menos 3 hosts para poder crear un WLD de VI asumiendo que se cree un network pool o se tenga un pool existente con suficientes IPs, una vez creado el nuevo WLD se migran las cargas con Cross-vCenter vMotion.

• Este modelo soporta múltiples clusters gestionados por la única instancia de vCenter Server de el MGMT WLD.

Múltiples clusters por WLD

Dentro de un Workload domain podemos tener uno o mas clusters, existen muchas razones por las cuales pudiéramos querer crear diferentes clusters en el contexto de un WLD (bajo la gestión de un vCenter dedicado):

• Segmentación de cargas de trabajo con licenciamiento basado en CPUs, Cores, etc. De esta manera podemos restringir en que hosts pueden estar ejecutándose las VMs con dichas aplicaciones y poder siempre estar en cumplimiento del EULA.

• Tipo de almacenamiento, podemos tener requerimientos específicos en términos de que almacenamiento se debe de usar segun los casos de uso, SLAs, etc. Para esto podemos crear múltiples clusters en un solo WLD que tengan diferentes tipos de almacenamiento principal, por ejemplo, cluster1 – NFS, Cluster2-vSAN y Cluster3-VMFS en FC.

• Podemos crear clusters para casos de uso específicos como lo pueden ser VDI (GPUs) ML/AI, (GPUs), apps con requerimientos de espacio en disco muy alto pero menos computo (pocos hosts con mucho espacio en disco con vSAN, FC o NFS), Apps criticas, Kubernetes, etc. También un caso de uso muy interesante sería tener clusters con disponibilidad local y otros que tengan un nivel de resiliencia mayor empleando vSAN stretched clusters, todos estos clusters pueden formar parte del mismo WLD.

La siguiente tabla provee una comparativa entre un ambiente con múltiples WLDs vs Múltiples clusters por WLD.

Múltiples WLDs	Múltiples Clusters
Los Workload Domains pueden ser utilizados como limites/demarcaciones de seguridad	El usar un dominio de NSX puede reducir la complejidad de red.
Cada WLD puede tener ruteo y red diferentes/independientes.	Es mas dificil proveer multi-tenancy en un ambiente de Múltiples clusters.
Se tiene un máximo de 14 WLDs de VI, si solo se tiene un cluster por WLD se tendrá un máximo de 64 Hosts ESXi.	Al tener menor cantidad de WLDs se reduce la cantidad de vCenter Servers lo cual reduce la necesidad de mas recursos en el WLD de MGMT.
Es posible tener que agregar capacidad al WLD de MGMT para poder ejecutar las cargas de gestión que se van incrementando según el número de WLD de VI incrementa.	Las políticas de Storage son mas faciles de gestionar.
	Puedes escalar hasta 2,000 hosts por vCenter.

Espero les sea de útilidad esta información 🙂 esperen los próximos articulos de arquitectura de red, Lifecycle management, entre otros.