VMware Cloud Foundation 4 – Primeros Pasos – Parte 2: Arquitectura y Pre-requisitos

En el artículo anterior le echamos un vistazo a VMware Cloud Foundation, ¿qué es y para qué sirve?, el día de hoy vamos a conocer un poco más sus componentes y los pre-requisitos que debemos cumplir para instalar esta solución en nuestro ambiente.

Lo primero que tenemos que tener claro son algunos términos que estaremos utilizando frecuentemente ya que VCF se basa en el modelo de computación en la nube, de momento las estoy agregando en este glosario de la nube, y lo iré actualizando conforme avance el tiempo para que siempre lo tengan a mano.

Como mencioné en el artículo anterior esta serie se basa en la versión 4.0.1 de VCF, cuando hice mi primer despliegue de VCF me basé en las guías de Cormac Hogan (en inglés) que pueden ser consultadas acá. Vamos a comenzar por revisar los componentes básicos de la arquitectura de VCF, y luego pasaremos a ver los pre-requisitos y preparación necesaria para desplegar nuestro Dominio de Gestión. En posts futuros veremos el proceso para construir nuestro primer Dominio de Cargas de Trabajo (WLD), el despliegue de nuestro edge cluster de NSX-T y cómo implementar la solución de vSphere with Kubernetes.

Diseño Validado por VMware (VVD)

Arquitectura de Dominios de Cargas de Trabajo del Diseño Validado por VMware

Los VMware Validated Designs (VVD) son un conjunto de arquitecturas estandarizadas y escalables respaldadas por la pericia técnica de VMware y una Lista de Materiales (BOM) de software exhaustivamente verificada por compatibilidad e interoperación que se extiende al cómputo, almacenamiento, redes y administración. De igual manera los documentos VVD incluyen guias detalladas que sintetizan las mejores prácticas para desplegar, integrar y operar el SDDC garantizandose así el mayor desempeño, disponibilidad, seguridad y eficiencia operacional. VCF 4.0.1 se basa en la coleccion de VVD v6.0.1. Para mas información pueden revisar los documentos de VVD directamente en el site de docs.vmware.com (en inglés).

Lista de Materiales (BOM)

El Bill of Materials (BOM) es la lista de software ya testeado para compatibilidad e interoperabilidad en nuestra solución VCF, para la version 4.0.1 la lista es la siguiente:

Componente de SoftwareVersiónFechaNúmero de Build
Cloud Builder VM4.0.1.025 Junio 202016428904
SDDC Manager4.0.1.025 Junio 202016428904
VMware vCenter Server Appliance7.0.0b23 Junio 202016386292
VMware ESXi7.0b23 Junio 202016324942
VMware vSAN7.0b23 Junio 202016324942
VMware NSX-T Data Center3.0.123 Junio 202016404613
VMware vRealize Suite Lifecycle Manager8.1 Patch 121 Mayo 202016256499
Fuente: https://docs.vmware.com/en/VMware-Cloud-Foundation/4.0.1/rn/VMware-Cloud-Foundation-401-Release-Notes.html

Cloud Builder

Cloud Builder (Constructor de la Nube en inglés) es un appliance virtual provisto por VMware, es el formato que utilizamos para desplegar y configurar el dominio de gestión de VCF, y una vez que termina el despliegue, le cede el control al SDDC Manager.

SDDC Manager

Cuando terminamos el despliegue inicial con Cloud Builder, este nos redirige al SDDC Manager. Desde esta interfaz podemos realizar muchas funciones desde crear WLDs, generar certificados, instalar componentes adicionales (por ejemplo vRealize), comisionar nuevos hosts hasta manejar infraestructura componible si tenemos servidores DELL de la serie MX o HPE de la serie Synergy.

Dominio de Gestión

El Dominio de Gestión (Management Domain en inglés) se utiliza para hospedar los componentes de infraestructura necesarios para generar, administrar y monitorear la infraestructura de nuestro VCF. Este dominio se crea automáticamente cuando realizamos la configuración inicial de nuestro appliance Cloud Builder.

El Dominio de Gestión requiere 4 nodos ESXi y solo utiliza vSAN como almacenamiento principal.

Dominio de Cargas de Trabajo

Los WLDs crean una selección integrada de recursos de cómputo, almacenamiento y red para ejecutar las cargas de trabajo o workloads del negocio. Son una abstracción lógica de recursos provisionados automáticamente por el SDDC Manager que se administran y actualizan de manera independiente. VCF nos brinda un proceso totalmente automatizado para crear, extender y eliminar WLDs utilizando SDDC Manager. Hosts y clusters también pueden eliminarse de un WLD para reducir su tamaño.

Los WLDs requieren como mínimo 3 nodos ESXi y pueden utilizar storage vSAN (opción preferida y configurada por defecto), sin embargo, pueden consumir almacenamiento secundario en la forma de datastores NFS 3.x y almacenamiento de fibra.

Antes de Comenzar

Es importante que tengamos claras las distintas opciones de implementación de VCF:

ModeloNube PrivadaNube PrivadaNube Pública
Tipo de ImplementaciónImplementación de softwareSistemas integradosProveedores de servicios de computación en la nube
VMware Cloud FoundationvSAN ReadyNode calificadoDell EMC VxRack SDDC
FUJITSU PRIMEFLEX for VMware Cloud Foundation
Hitachi Unified Compute Platform (UCP) RS
QCT QxStack
VMware Cloud on AWS
IBM Cloud
CenturyLink
Rackspace
NTT Communications
Opciones de ImplementaciónEnsamblado y diseñado por el cliente (con la ayuda de un partner o PSO)Se diseña y se ensambla previamente en la fábrica, y se recibe listo para ejecutarSe adquiere como servicio
Fuente: https://www.vmware.com/latam/products/cloud-foundation.html

Para nuestros propósitos vamos a suponer que utilizamos vSAN ReadyNodes, ¿qué son? en palabras sencillas son sistemas ensamblados a gusto del cliente que cumplen con los requerimientos de la matriz de compatibilidad de VMware que se puede consultar acá.

Pre-requisitos

Hay varios pre-requisitos que cumplir para poder evaluar Cloud Foundation, voy a listar los necesarios para evaluar VCF en su versión completa así como todas sus funciones, sin embargo, en otro post les comentaré como poder implementarlo de manera anidada reduciendo los recursos necesarios. Ahora bien, necesitamos lo siguiente:

  • Infraestructura “Física”
    • Hardware – Management/Consodilated Domain
      • Servidores: 4 vSAN ReadyNodes en perfil All Flash (AF)
      • CPU: Configuraciones soportadas por el HCL de VMware
      • Memoria: 256 GB de Memoria por servidor
      • Almacenamiento (Boot): SATA-DOM o Tarjeta SD de 32 GB
      • Almacenamiento (Cache): 1.2TB de capacidad bruta para el Tier de Cache por host
      • Almacenamiento (Capacidad): 10TB de capacidad bruta para el Tier de Capacidad por host
      • Interfaces de Red: 2 Interfaces de 10GbE y 1 Interfaz de 1GbE
      • NOTA: Este hardware es solamente necesario si se quiere seguir la guía de instalación completa, en el siguiente artículo les comentaré como poder construir un ambiente anidado con solamente un host con menos recursos.
    • Redes
      • Jumbo Frames (9000 MTU) habilitado
      • Proximidad de BGP y los números de sistema autónomo BGP (AS IDs) – Solamente necesario si se quiere habilitar el enrutamiento dinámico con NSX, si no, se pueden utilizar rutas estáticas.
  • Infraestructura Lógica
    • Redes
      • Red de Administración: Debemos tener al menos una subred /27 con el MTU configurado en 1500 para los componentes de administración, principalmente la IP de Administración de los Servidores ESXi, preferiblemente con un VLAN tag separado.
      • Red vMotion: Debemos tener al menos una subred /27 distinta a la anterior, con el MTU configurado en 9000 para las IPs de vMotion de los Servidores ESXi, preferiblemente con un VLAN tag separado.
      • Red vSAN: Debemos tener al menos una subred /27 distinta a la anterior, con el MTU configurado en 9000 para las IPs de vSAN de los Servidores ESXi, preferiblemente con un VLAN tag separado.
      • Red Overlay NSX-T: Debemos tener al menos una subred /27 distinta a la anterior, con el MTU configurado en 9000 y DHCP habilitado para los Tunnel Endpoints (vTEPs) de los Servidores ESXi, preferiblemente con un VLAN tag separado.
      • Red Uplink NSX-T Edge 1 (Opcional): Debemos tener al menos una subred /27 distinta a la anterior, con acceso al ToR switch y con el MTU configurado en 9000 para los Tunnel Endpoints (vTEPs) de los NSX Edges, preferiblemente con un VLAN tag separado.
      • Red Uplink NSX-T Edge 2 (Opcional): Debemos tener al menos una subred /27 distinta a la anterior, con acceso al ToR switch y con el MTU configurado en 9000 para los Tunnel Endpoints (vTEPs) de los NSX Edges, preferiblemente con un VLAN tag separado.
      • Red Overlay NSX-T Edge (Opcional): Debemos tener al menos una subred /24 distinta a la anterior, con el MTU configurado en 9000 para rutas overlay de los NSX Edges, preferiblemente con un VLAN tag separado.
    • Servicios
      • DNS: Al menos un servidor DNS accesible desde la Red de Administración
      • NTP: Al menos un servidor DNS accesible desde la Red de Administración
      • DHCP: Al menos un servidor DHCP con un scope configurado correspondiente a la Red Overlay NSX-T, se necesita una IP por Interfaz física de cada Servidor ESXi, por ejemplo: si sus servidores tienen 2 pNICs y tiene 4 servidores, necesita tener al menos 8 IPs libres en el scope
      • Active Directory (Opcional): Al menos un controlador de dominio configurado en versión funcional no mayor a Windows 2016 Server (Workspace ONE aún no soporta la versión funcional Windows 2019)
    • Software
      • Appliance VMware Cloud Builder – Descargable en el portal my.vmware.com, VMUG Advantage o en el vExpert Portal si sos vExpert.
      • Libro de Excel de Parámetros de Despliegue – Descargable una vez importada el appliance de Cloud Builder.
      • Utilidad de Generación de Certificados – Descargable desde el KB 78246
    • Licencias
      • ESXi 7.0, vSphere with Kubernetes – Puede ser de Evaluación
      • vSAN 7.0 – Puede ser de Evaluación
      • vCenter 7.0 Standard – Puede ser de Evaluación
      • NSX-T Data Center Advanced o Enterprise – Puede ser de Evaluación
      • SDDC Manager 4.0 – Esta no está disponible para evaluación, solamente clientes que hayan comprado el producto, vExperts o miembros VMUG Advantage
      • vRealize Suite Advanced o Enterprise (Opcional)
      • Pro-tip: VMUG Advantage es la mejor opción a utilizar ya que nos incluye el EVALExperience que nos da derecho a todas las licencias que necesitamos y muchos otros más productos por ¡365 dias!, además incluye descuentos en Certificaciones, Cursos y pases al VMworld y muchas cosas mas por sólo $200 USD, y si de paso utilizan el código COSTARICA20 al adquirirlo reciben un 10% de descuento cortesía del VMUG Costa Rica.

¿Y Ahora?

Una vez que tengamos todos los prerequisitos, procedemos a instalar ESXi 7.0b en nuestros 4 servidores y a configurar las interfaces de red, así como los servicios de DNS, habiendo completado esto tenemos que aplicar la siguiente configuración en todos los hosts:

Accediendo al Host

Accedemos a nuestro host por la URL https://IP_o_nombre_del_host/ui/, ingresamos el usuario root y la contraseña configurada durante la instalacion. Si nuestro cliente cargara en idioma Inglés y quisieramos pasarlo a Español debemos realizar esta secuencia de clics:

Hacemos clic en el triángulo al lado del texto root@nombre_del_host > Settings > Language > Spanish

Configuracion NTP

Una vez con nuestra interfaz en Español vamos a configurar el servicio de NTP, para esto seguimos la secuencia de clics: Administrar > Sistema > Hora y fecha > Edit NTP Settings (OJO: NTP no PTP)

En esta pantalla vamos a habilitar el cliente NTP > cambiamos la Directiva de inicio del servicio a “Iniciar y detener con el host” > Escribimos nuestros servidores NTP (separados por coma) y hacemos clic en Guardar

Luego, desde la misma ventana hacemos clic en la pestaña Servicios > luego seleccionamos el servicio TSM-SSH > Acciones > modificamos la directiva para “Iniciar y detener con el host” > por último hacemos clic en iniciar. Debemos repetir el proceso pero ahora seleccionando el servicio ntpd.

Por último verificamos que ambos servicios se encuentren “En ejecución” y listo! Repetimos el proceso en todos los hosts que vamos a utilizar para nuestra solución.

Y con esto concluímos este post, ya a este punto nuestros ESXis se encuentran listos para el deployment inicial, en el siguiente artículo vamos a ver el proceso para desplegar Cloud Builder así como los parámetros que necesitamos cargar para ejecutar el proceso de levantado del SDDC. Espero que haya sido de su agrado y les invito a dejar sus comentarios.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s