¿Qué es Azure VMware Solution?
Azure VMware Solution proporciona nubes privadas que contienen clústeres de VMware vSphere creados a partir de una infraestructura dedicada de Azure sin sistema operativo. Azure VMware Solution está disponible en Azure Commercial y en Azure Government. La implementación mínima inicial es de tres hosts, con la opción de agregar más hosts, hasta un máximo de 16 por clúster. Todas las nubes privadas aprovisionadas tienen VMware vCenter Server, VMware vSAN, VMware vSphere y VMware NSX. Como resultado, puede migrar cargas de trabajo de sus entornos locales, implementar nuevas máquinas virtuales y usar servicios de Azure desde sus nubes privadas. Para obtener información sobre el Contrato de nivel de servicio, consulte la página de Acuerdos de nivel de servicio de Azure.
Azure VMware Solution es una solución validada de VMware con validación y pruebas continuas de sus mejoras y actualizaciones. Microsoft administra y mantiene la infraestructura y el software de la nube privada, lo que le permite centrarse en desarrollar y ejecutar cargas de trabajo en sus nubes privadas para brindar valor comercial.
En este diagrama se muestra la adyacencia entre las nubes privadas y las redes virtuales en Azure, los servicios de Azure y los entornos locales. El acceso a la red desde nubes privadas a servicios o redes virtuales de Azure proporciona una integración controlada mediante Acuerdo de Nivel de Servicio de los puntos de conexión de servicio de Azure. Global Reach de ExpressRoute conecta su entorno local y la nubes privada de Azure VMware Solution.
Hosts, clústeres y nubes privadas
Los clústeres de Azure VMware Solution se basan en una infraestructura hiperconvergida. En la tabla siguiente se muestran las especificaciones de CPU, memoria, disco y red del host.
| Tipo de host | CPU (Núcleos/GHz) | RAM (GB) | Nivel de caché de vSAN (TB, sin procesar***) | Nivel de capacidad de vSAN (TB, sin procesar***) | Disponibilidad regional |
|---|---|---|---|---|---|
| AV36 | CPU Dual Intel Xeon Gold 6140 (microarquitectura Skylake) con 18 núcleos/CPU a 2.3 GHz, para un total de 36 núcleos físicos (72 núcleos lógicos con hyperthreading) | 576 | 3.2 (NVMe) | 15.20 (SSD) | Regiones seleccionadas (*) |
| AV36P | CPU Dual Intel Xeon Gold 6240 (microarquitectura Cascade Lake) con 18 núcleos/CPU a 2.6 GHz/3.9 GHz Turbo, total de 36 núcleos físicos (72 núcleos lógicos con hyperthreading) | 768 | 1.5 (Intel Cache) | 19.20 (NVMe) | Regiones seleccionadas (*) |
| AV52 | CPU Dual Intel Xeon Platinum 8270 (microarquitectura Cascade Lake) con 26 núcleos/CPU a 2.7 GHz/4.0 GHz Turbo, total de 52 núcleos físicos (104 núcleos lógicos con hyperthreading) | 1536 | 1.5 (Intel Cache) | 38.40 (NVMe) | Regiones seleccionadas (*) |
| AV64 | CPU Intel Xeon Platinum 8370C duales (microarquitectura de Ice Lake) con 32 núcleos/CPU @ 2,8 GHz / 3,5 GHz Turbo, Total 64 núcleos físicos (128 núcleos lógicos con hiperproceso) | 1024 | 3.84 (NVMe) | 15.36 (NVMe) | Regiones seleccionadas (**) |
Un clúster de Azure VMware Solution requiere un número mínimo de tres hosts. Solo puede usar hosts del mismo tipo en una sola nube privada de Azure VMware Solution. Los hosts que se usan para crear o escalar clústeres provienen de un grupo de hosts aislado. Esos hosts superaron las pruebas de hardware, y se eliminaron todos los datos de forma segura antes de agregarlos al clúster.
Todos los tipos de host anteriores tienen un rendimiento de interfaz de red de 100 Gbps.
(*) detalles disponibles a través de la calculadora de precios de Azure.
(**) Requisito previo de AV64: se requiere una nube privada de Azure VMware Solution implementada con AV36, AV36P o AV52 antes de agregar AV64.
(***) El valor sin procesar se basa en el Sistema internacional de unidades (SI) notificado por el fabricante del disco. Ejemplo: 1 TB Raw = 1000000000000 bytes, el espacio calculado por el equipo en binario (binario de 1 TB = binario de 1099511627776 bytes) equivale a 931,3 Gigabytes convertidos a partir de decimales sin formato.
Puede implementar nubes privadas nuevas o escalar las existentes mediante Azure Portal o la CLI de Azure.
Extensión de nube privada de Azure VMware Solution con tamaño de nodo AV64
AV64 es un nuevo SKU de host de Azure VMware Solution que está disponible para expandir (no crear) la nube privada de Azure VMware Solution creada con el SKU AV36, AV36P o AV52 existente. Use la documentación de Microsoft para comprobar la disponibilidad de la SKU de AV64 en la región.
Requisito previo para el uso de AV64
Consulte los siguientes requisitos previos para la implementación del clúster de AV64.
Se crea una nube privada de Azure VMware Solution mediante AV36, AV36P o AV52 en la región o zona de disponibilidad admitidas de AV64.
Necesita un bloque de direcciones /23 o tres (contiguos o no contiguas) /25 para la administración de clústeres de AV64.
Compatibilidad con escenarios de cliente
Cliente con la nube privada de Azure VMware Solution existente: cuando un cliente tiene una nube privada de Azure VMware Solution implementada, puede escalar la nube privada agregando un clúster de nodos vCenter de AV64 independiente a esa nube privada. En este escenario, los clientes deben seguir estos pasos:
- Obtenga una aprobación de cuota de AV64 de Microsoft con el mínimo de tres nodos. Agregue otros detalles sobre la nube privada de Azure VMware Solution que planea ampliar mediante AV64.
- Use un flujo de trabajo del clúster de complementos de Azure VMware Solution existente con hosts AV64 para la expansión.
Planes de cliente para crear una nueva nube privada de Azure VMware Solution: cuando un cliente quiere una nueva nube privada de Azure VMware Solution que puede usar el SKU AV64, pero solo para la expansión. En este caso, el cliente cumple los requisitos previos de tener una nube privada de Azure VMware Solution creada con AV36, AV36P o SKU de AV52. El cliente debe comprar un mínimo de tres nodos del SKU AV36, AV36P o AV52 antes de expandirse mediante AV64. Para este escenario, siga estos pasos:
- Obtenga la aprobación de cuota de AV36, AV36P, o AV52, y AV64 de Microsoft con un mínimo de tres nodos cada uno.
- Creación de una nube privada de Azure VMware Solution mediante el SKU AV36, AV36P o AV52.
- Use un flujo de trabajo del clúster de complementos de Azure VMware Solution existente con hosts AV64 para la expansión.
Nube privada de clústeres extendidos de Azure VMware Solution: el SKU AV64 no se admite con la nube privada de clústeres extendidos de Azure VMware Solution. Esto significa que una expansión basada en AV64 no es posible para una nube privada de clústeres extendidos de Azure VMware Solution.
[!NOTE]
Todo el tráfico de un host AV64 hacia una red del cliente usará la dirección IP de la interfaz de red 1 de VMKernel.
Diseño y recomendaciones de dominio de error de vSAN de clúster de AV64 (FD)
Los clústeres de hosts tradicionales de Azure VMware Solution no tienen una configuración explícita de FD de vSAN. El razonamiento es que la lógica de asignación de hosts garantiza, dentro de los clústeres, que no residan dos hosts en el mismo dominio de error físico dentro de una región Azure. Esta característica aporta intrínsecamente resistencia y alta disponibilidad para el almacenamiento, que se supone que trae la configuración de FD de vSAN. Puede encontrar más información sobre FD de vSAN en la documentación de VMware.
Los clústeres de hosts AV64 de Azure VMware Solution tienen una configuración explícita de dominio de error de vSAN (FD). El plano de control de Azure VMware Solution configura siete dominios de error de vSAN (FD) para clústeres de AV64. Los hosts se equilibran uniformemente entre los siete FD a medida que los usuarios escalan verticalmente los hosts de un clúster de tres a 16 nodos. Algunas regiones de Azure todavía admiten un máximo de cinco FD como parte de la versión inicial de la SKU de AV64. Consulte la tabla de asignación de la zona de disponibilidad de la región de Azure (AZ) a SKU para más información.
Recomendación de tamaño de clúster
El tamaño mínimo admitido para el clúster de nodos de vSphere de Azure VMware Solution es tres. La redundancia de datos de vSAN se controla asegurándose de que el tamaño mínimo del clúster de tres hosts está en diferentes FD de vSAN. En un clúster de vSAN con tres hosts, cada uno de ellos en un FD diferente, si se produce un error de FD (por ejemplo, se produce un error en la parte superior del conmutador de bastidor), se protegerán los datos de vSAN. Se produciría un error en las operaciones como la creación de objetos (nueva máquina virtual, VMDK y otras). Lo mismo sucede con las actividades de mantenimiento en las que un host ESXi se coloca en modo de mantenimiento o se reinicia. Para evitar escenarios como estos, la recomendación es implementar clústeres de vSAN con un mínimo de cuatro hosts ESXi.
Procedimientos recomendados y flujo de trabajo de eliminación de hosts de AV64
Debido a la configuración del dominio de error vSAN (FD) del clúster de AV64 y a la necesidad de hosts equilibrados entre todos los FD, la eliminación del host del clúster de AV64 difiere de los clústeres host de Azure VMware Solution tradicionales con otros SKU.
Actualmente, un usuario puede seleccionar uno o varios hosts que se van a quitar del clúster mediante el portal o la API. Una condición es que un clúster debe tener un mínimo de tres hosts. Sin embargo, un clúster de AV64 se comporta de forma diferente en determinados escenarios cuando AV64 usa FD de vSAN. Cualquier solicitud de eliminación de host se comprueba contra el posible desequilibrio de FD de vSAN. Si una solicitud de eliminación de host crea un desequilibrio, la solicitud se rechaza con la respuesta http 409-Conflict. El código de estado de respuesta http 409-Conflict indica un conflicto de solicitud con el estado actual del recurso de destino (hosts).
Los tres escenarios siguientes muestran ejemplos de instancias que normalmente generan errores y muestran diferentes métodos que se pueden usar para quitar hosts sin crear un desequilibrio de dominio de error de vSAN (FD).
Al quitar un host, se crea un desequilibrio de FD de vSAN con una diferencia de hosts entre la mayoría y el FD menos rellenado para que sea más de uno. En el ejemplo siguiente, los usuarios deben quitar uno de los hosts de FD 1 antes de quitar hosts de otros FD.
Cuando se realizan varias solicitudes de eliminación de host al mismo tiempo y ciertas eliminaciones de host crean un desequilibrio. En este escenario, el plano de control de Azure VMware Solution elimina solo los hosts, que no crean desequilibrio. En el ejemplo siguiente, los usuarios no pueden tomar ambos hosts de los mismos FD a menos que reduzcan el tamaño del clúster a cuatro o menos.
Si se elimina el host seleccionado provoca menos de tres FD de vSAN activos. No se espera que este escenario se produzca dado que todas las regiones de AV64 tienen cinco o siete FD. Al agregar hosts, el plano de control de Azure VMware Solution se encarga de agregar hosts de los siete FD uniformemente. En el ejemplo siguiente, los usuarios pueden quitar uno de los hosts de FD 1, pero no de FD 2 o 3.
Identificación del host que se puede quitar sin causar un desequilibrio de FD de vSAN: un usuario puede ir a la interfaz de cliente de vSphere para obtener el estado actual de los FD de vSAN y los hosts asociados a cada uno de ellos. Esto ayuda a identificar los hosts (en función de los ejemplos anteriores) que se pueden quitar sin afectar al equilibrio de FD de vSAN y evitar errores en la operación de eliminación.
Configuración de RAID compatible con AV64
En esta tabla se proporciona la lista de requisitos de host y compatibles con la configuración de RAID en los clústeres de AV64. Las directivas RAID-6 FTT2 y RAID-1 FTT3 se admiten con la SKU AV64 en algunas regiones. En las regiones de Azure que están actualmente restringidas a cinco FD, Microsoft permite a los clientes usar la directiva de almacenamiento de VSAN de RAID-5 FTT1 para clústeres de AV64 con seis o más nodos para cumplir el Acuerdo de Nivel de Servicio (SLA). Consulte la tabla de asignación de la zona de disponibilidad de la región de Azure (AZ) a SKU para más información.
| Configuración de RAID | Errores tolerables (FTT) | Hosts mínimos requeridos |
|---|---|---|
| Configuración predeterminada de RAID-1 (creación de reflejo). | 1 | 3 |
| RAID-5 (codificación de borrado) | 1 | 4 |
| RAID-1 (Creación de reflejo) | 2 | 5 |
| RAID-6 (codificación de borrado) | 2 | 6 |
| RAID-1 (Creación de reflejo) | 3 | 7 |
Storage
Azure VMware Solution admite la expansión de la capacidad del almacén de datos más allá de lo que se incluye con vSAN mediante los servicios de almacenamiento de Azure, lo que le permite expandir la capacidad del almacén de datos sin escalar los clústeres. Para obtener más información, consulte opciones de expansión de capacidad del almacén de datos.
Redes
Azure VMware Solution ofrece un entorno de nube privada accesible desde sitios locales y recursos basados en Azure. Servicios como Azure ExpressRoute y las conexiones VPN o Azure Virtual WAN proporcionan la conectividad. No obstante, estos servicios requieren intervalos de direcciones de red y puertos de firewall específicos para habilitar los servicios.
Cuando implementa una nube privada, se crean redes privadas para la administración, el aprovisionamiento y vMotion. Estas redes privadas se usan para acceder a VMware vCenter Server y VMware NSX Manager, así como a vMotion o a la implementación de la máquina virtual.
Global Reach de ExpressRoute se usa para conectar las nubes privadas a entornos locales. Conecta circuitos directamente en el nivel de Microsoft Edge. La conexión requiere una red virtual con un circuito ExpressRoute en el entorno local en su suscripción. El motivo es que las puertas de enlace de red virtual (puertas de enlace de ExpressRoute) no pueden hacer transitar el tráfico, lo que significa que puede conectar dos circuitos a la misma puerta de enlace, pero no envía tráfico de un circuito al otro.
Cada entorno de Azure VMware Solution es su propia región de ExpressRoute (su propio dispositivo MSEE virtual), que le permite conectar Global Reach a la ubicación de emparejamiento "local". Permite conectar varias instancias de Azure VMware Solution de una región a la misma ubicación de emparejamiento.
Nota
Para las ubicaciones en las que Global Reach de ExpressRoute no está habilitado, por ejemplo, debido a normativas locales, tiene que crear una solución de enrutamiento mediante máquinas virtuales IaaS de Azure. Para ver algunos ejemplos, consulte Azure Cloud Adoption Framework: topología de red y conectividad para Azure VMware Solution.
Las máquinas virtuales implementadas en la nube privada son accesibles a través de Internet mediante la funcionalidad de IP pública de Azure Virtual WAN. De forma predeterminada, el acceso a Internet está deshabilitado para las nuevas nubes privadas.
Para obtener más información, consulte Arquitectura de redes.
Acceso y seguridad
Para mejorar la seguridad, las nubes privadas de Azure VMware Solution usan el control de acceso basado en rol de vSphere. Puede integrar las funcionalidades LDAP del inicio de sesión único de vSphere en Microsoft Entra ID. Para más información, consulte la página Arquitectura de acceso y de identidad.
El cifrado de datos en reposo de vSAN está habilitado de forma predeterminada y se usa para proporcionar seguridad al almacén de datos de vSAN. Para más información, consulte Arquitectura del almacenamiento.
Residencia de datos y datos de clientes
Azure VMware Solution no almacena los datos de los clientes.
Versiones de software de VMware
Las versiones de software de las soluciones de VMware usadas en las nuevas implementaciones de nubes privadas de Azure VMware Solution son:
| Software | Versión |
|---|---|
| VMware vCenter Server | 8.0 U2d |
| VMware ESXi | 8.0 U2b |
| vSAN de VMware | 8.0 U2 |
| Formato en disco de vSAN VMware | 19 |
| Arquitectura de almacenamiento de VMware vSAN | OSA |
| VMware NSX | 4.1.1 |
| VMware HCX | 4.9.1 |
| VMware Site Recovery Manager | 8.8.0.3 |
| VMware vSphere Replication | 8.8.0.3 |
La versión de software que se está ejecutando actualmente se aplica a los nuevos clústeres agregados a una nube privada existente, si la versión de vCenter Server la admite.
Mantenimiento del ciclo de vida del host y del software
Las actualizaciones periódicas del software de VMware y de la nube privada de Azure VMware Solution garantizan que las nubes privadas disfruten de la seguridad, estabilidad y los conjuntos de características más recientes. Para más información, consulte Mantenimiento del host y administración del ciclo de vida.
Supervisión de una nube privada
Una vez que haya implementado Azure VMware Solution en la suscripción, se generan registros de Azure Monitor automáticamente.
En la nube privada, puede:
- Recopilar registros en cada una de las máquinas virtuales.
- Descargar e instalar el agente MMA en máquinas virtuales Linux y Windows.
- Habilite la extensión de Azure Diagnostics.
- Creación y ejecución de nuevas consultas.
- Ejecute las mismas consultas que normalmente ejecuta en las máquinas virtuales.
Los patrones de supervisión dentro de Azure VMware Solution son similares a los de Azure Virtual Machines en la plataforma IaaS. Para obtener información adicional y de procedimientos, consulte Supervisión de máquinas virtuales de Azure con Azure Monitor.
Comunicación al cliente
Puede buscar notificaciones de problemas de servicio, mantenimiento planificado, avisos de estado y avisos de seguridad publicados mediante Service Health en Azure Portal. Puede realizar acciones oportunas al configurar las alertas del registro de actividad para estas notificaciones. Para más información, consulte Creación de alertas de Service Health mediante Azure Portal.
Matriz de responsabilidad de Azure VMware Solution: Microsoft y el cliente
Azure VMware Solution implementa un modelo de responsabilidad compartida que define roles y responsabilidades distintos de las dos partes implicadas en la oferta: Microsoft y el cliente. Las responsabilidades del rol compartido se ilustran con más detalle en las dos tablas siguientes.
En la tabla de matriz de responsabilidad compartida se describen las tareas principales que los clientes y Microsoft controlan en la implementación y administración de las cargas de trabajo de la nube privada y de la aplicación del cliente.
En la tabla siguiente se proporciona una lista detallada de roles y responsabilidades entre el cliente y Microsoft, que abarca las tareas y definiciones más frecuentes. Si tiene más preguntas, póngase en contacto con Microsoft.
| Rol | Tarea y detalles |
|---|---|
| Microsoft Azure VMware Solution | Infraestructura física
(opcional) VMware HCX se implementa con un perfil de proceso totalmente configurado en el lado de la nube como complemento (opcional) VMware SRM implementa, actualiza y escala verticalmente Compatibilidad: plataformas de nube privada y VMware HCX |
| Customer | Solicita a Microsoft una cuota de alojamiento de Azure VMware Solution Planear y crear una solicitud de nube privada en Azure Portal con:
Adición o eliminación de solicitudes de hosts al clúster desde Azure Portal Implementación y administración del ciclo de vida de soluciones de asociados (terceros) |
| Ecosistema del asociado | Soporte técnico para su producto o solución. Como referencia, a continuación se muestran algunos de los productos o soluciones de asociados de Azure VMware Solution compatibles:
|
Pasos siguientes
El siguiente paso es aprender los conceptos clave de arquitectura de nube privada.