¿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 Comercial y 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 desde los entornos locales, implementar nuevas máquinas virtuales (VM) y consumir servicios de Azure desde las nubes privadas. Para obtener información sobre el Acuerdo de Nivel de Servicio, consulte la página Azure contratos de nivel de servicio.

Azure VMware Solution es una solución validada de VMware con validación continua y pruebas de 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 el diagrama se muestra la adyacencia entre nubes privadas y redes virtuales en Azure, servicios Azure y entornos locales. El acceso de red desde nubes privadas a servicios de Azure o redes virtuales proporciona una integración de los puntos de conexión de servicio de Azure controlada por SLA. Global Reach de ExpressRoute conecta el entorno local a la nube privada de Azure VMware Solution.

Azure VMware Solution tipos de nube privada

Azure VMware Solution proporciona dos generaciones de nube privada diferentes:

1. Azure VMware Solution Generation 1 proporciona clústeres de VMware vSphere creados a partir de hosts bare-metal dedicados implementados en instalaciones de centros de datos de Azure. Los circuitos ExpressRoute administrados por Microsoft proporcionan conectividad entre hosts de VMware vSphere y recursos de Azure nativos implementados en redes virtuales.

2. Azure VMware Solution Generation 2 proporciona clústeres de VMware vSphere creados a partir de hosts de Azure sin sistema operativo dedicados. Azure VMware Solution Generation 2 incluye una arquitectura de red actualizada en la que los hosts de VMware vSphere están conectados directamente a Azure Virtual Networks. Esta oferta solo se admite en la SKU av64.

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.

Un clúster de Azure VMware Solution requiere un número mínimo de tres hosts. Puede usar hosts del mismo tipo solo en una 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.

*Los detalles están disponibles a través de la calculadora de precios de Azure.

**Requisito previo de AV64: se requiere una Azure VMware Solution nube privada implementada con AV36, AV36P o AV52 antes de agregar AV64.

Raw se basa en el estándar internacional de unidades (SI) notificado por los fabricantes de discos. Ejemplo: 1 TB raw = 1000000000000 bytes. El espacio calculado por un proceso en binario (1 TB en binario = 1099511627776 bytes en binario) es igual a 931,3 gigabytes convertidos del decimal sin formato.

ESA se aplica a las implementaciones de AV64 Gen 2.

Puede implementar nubes privadas nuevas o existentes a través del portal de Azure o CLI de Azure.

Azure VMware Solution extensión de nube privada con tamaño de nodo AV64

La AV64 es una SKU de host de la Solución de Azure VMware, que está disponible para expandir la nube privada de la Solución de Azure VMware ya creada con la SKU existente de AV36, AV36P o AV52. Si desea implementar AV64 directamente, consulte Azure VMware Solution en un Azure Virtual Network. Use la documentación de Microsoft para comprobar la disponibilidad de la SKU de AV64 en la región.

Requisito previo para la expansión de AV64 en AV36, AV36P y AV52

Consulte los siguientes requisitos previos para la implementación del clúster de AV64.

• Se crea una solución de VMware de nube privada de Azure usando AV36, AV36P, AV48 o AV52 en region/AZ.

• Necesita un bloque de direcciones /23 o tres (contiguas o no contiguas) /25 para la administración de clústeres de AV64.

Compatibilidad con escenarios de cliente

Cliente con nube privada existente de Azure VMware Solution: cuando un cliente tiene una nube privada de Azure VMware Solution implementada, puede escalar la nube privada agregando por separado un clúster de nodos vCenter de AV64 a esa nube privada. En este escenario, los clientes deben seguir estos pasos:

1. Obtenga la aprobación de cuota AV64 de Microsoft con un mínimo de tres nodos. Agregue otros detalles sobre la Azure VMware Solution nube privada que planea ampliar mediante AV64.
2. Utilizar un flujo de trabajo existente de Azure VMware Solution para agregar clústeres con hosts AV64 para ampliar.

Customer planea crear una nueva nube privada Azure VMware Solution: cuando un cliente quiere una nueva nube privada Azure VMware Solution que puede usar la SKU de AV64, pero solo para la expansión. En este caso, el cliente cumple los requisitos previos de tener una nube privada 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:

1. Obtenga la aprobación de cuota de AV36, AV36P, o AV52, y AV64 de Microsoft con un mínimo de tres nodos cada uno.
2. Cree una nube privada de Azure VMware Solution usando AV36, AV36P o AV52 SKU.
3. Utilice un flujo de trabajo existente de Azure VMware Solution para agregar un clúster con hosts AV64 para expandirse.

Azure VMware Solution nube privada de clústeres extendidos: el SKU de AV64 no es compatible con Azure VMware Solution nube privada de clústeres extendidos. Esto significa que una expansión basada en AV64 no es posible para una nube privada de clústeres extendidos Azure VMware Solution.

Compatibilidad mejorada con vMotion (EVC) con la extensión AV64

Agregar nodos AV64 a una nube privada de Azure VMware Solution crea un entorno heterogéneo, lo que da lugar a problemas de Enhanced vMotion Compatibility (EVC) entre clústeres de AV64 y clústeres de SKU base mediante SKU de AV36, AV36P o AV52. Los clústeres de AV64 usan el modo Icelake EVC debido a sus CPU de Intel Icelake, mientras que los clústeres AV36, AV36P y AV52, basados en CPU intel anteriores, no tienen habilitado el modo EVC explícito. Los detalles sobre las generaciones de CPU para cada SKU se proporcionan anteriormente.

La heterogeneidad de los modos de EVC entre clústeres presenta desafíos para las operaciones de vMotion activas, tal como se define en Broadcom, en función del escenario y la dirección específicos de la migración. En la sección siguiente se proporciona un resumen de la experiencia del usuario al realizar live vMotion entre AV64 y los clústeres base.

• Clúster de vMotion a AV64 desde el clúster de SKU base: esto funciona bien, ya que la máquina virtual se migra mediante vMotion desde un clúster con modo EVC inferior a uno con modo EVC superior.

• vMotion desde el clúster AV64 al clúster SKU base: dos escenarios

  • Si la máquina virtual se movió previamente desde el clúster base y no se ha ciclo de energía, la instancia de vMotion activa se realiza correctamente.

  • Si la máquina virtual se creó en el clúster AV64 o se reinició, aunque anteriormente se trasladó mediante vMotion desde el clúster de SKU base, vMotion en vivo producirá un error de compatibilidad de EVC.

Los clientes pueden evitar problemas de vMotion en directo entre la SKU base y los clústeres de AV64 configurando el modo EVC al nivel de la máquina virtual para que coincida con el EVC del clúster base inferior, o bien apagando la máquina virtual y realizando un vMotion en frío.

Diseño y recomendaciones de dominio de error de vSAN de clúster de AV64 (FD)

Los clústeres de hosts Azure VMware Solution tradicionales no tienen una configuración explícita de vSAN FD. El razonamiento es que la lógica de asignación de host garantiza, dentro de los clústeres, que ningún host resida en el mismo dominio de fallos físico, dentro de una región de 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 host de Azure VMware Solution AV64 tienen una configuración explícita de dominio de error de vSAN (FD). Azure VMware Solution plan de control configura siete dominios de fallo de vSAN (FD) para clústeres 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 tipos de host para la zona de disponibilidad de la región de Azure para obtener más información.

Recomendación de tamaño de clúster

El tamaño mínimo de clúster de nodo de vSphere admitido por la solución Azure VMware es de 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

A causa de la configuración del dominio de fallo vSAN (FD) del clúster AV64 y la necesidad de equilibrar los hosts a través de todos los FDs, la eliminación del host del clúster AV64 difiere de los clústeres tradicionales de hosts de Azure VMware Solution con otras 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 fallan y demuestran diferentes métodos que se pueden usar para quitar hosts sin provocar un desequilibrio en el dominio de fallos de vSAN (FD).

• Al quitar un host, se crea un desequilibrio de FDs de vSAN con una diferencia de hosts entre el FD más poblado y el menos poblado que sea superior a uno. En el ejemplo siguiente, los usuarios deben quitar uno de los hosts de FD 1 antes de quitar hosts de otros FD.

  Diagrama que muestra cómo los usuarios deben eliminar uno de los hosts de FD 1 antes de quitar los hosts de otros FD.

• Se realizan varias solicitudes de eliminación de anfitrión al mismo tiempo y ciertas eliminaciones de anfitrión crean un desequilibrio. En este escenario, el control plane de Azure VMware Solution quita solo los hosts, lo cual no crea 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.

  Diagrama que muestra cómo 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.

• La eliminación de un host seleccionado provoca que haya menos de tres FD activos de vSAN. No se espera que este escenario se produzca dado que todas las regiones de AV64 tienen cinco o siete FD. Al agregar hosts, el Azure VMware Solution plano de control 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.

  Diagrama que muestra cómo 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

Esta tabla proporciona la lista de configuraciones de RAID compatibles y los requisitos de host 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 vSAN de RAID-5 FTT1 para clústeres AV64 con seis o más nodos para cumplir con el acuerdo de nivel de servicio (SLA). Consulte la tabla de asignación de tipos de host por zona de disponibilidad de la región de Azure para obtener más información.

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 Azure servicios de almacenamiento, 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.

Networking

Azure VMware Solution ofrece un entorno de nube privada accesible desde sitios locales y recursos basados en Azure. Los servicios como Azure ExpressRoute, 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 (vNet) 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), lo que permite conectar Global Reach con la ubicación de interconexión local. Permite conectar varias instancias de Azure VMware Solution en una región a la misma ubicación de emparejamiento.

Las máquinas virtuales implementadas en la nube privada son accesibles para Internet a través de la Azure Virtual WAN ip pública funcionalidad. 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

Las nubes privadas de Azure VMware Solution utilizan el control de acceso basado en roles de vSphere para mejorar la seguridad. Puede integrar las funcionalidades LDAP de SSO de vSphere con 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

En la tabla siguiente se enumeran las versiones de software que se usan en nuevas implementaciones de Azure VMware Solution nubes privadas.

Si el número de compilación enumerado no coincide con el número de compilación que aparece en las notas de la versión, se debe a que se aplicó una revisión personalizada para los proveedores de nube.

La versión de software en ejecución actual se aplica a los nuevos clústeres que se agregan 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 de la nube privada Azure VMware Solution y el software de VMware garantizan que los conjuntos de características, estabilidad y seguridad más recientes se ejecutan en las nubes privadas. 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 hayas implementado Azure VMware Solution en tu suscripción, se generan automáticamente los registros Azure Monitor.

En la nube privada, puede:

• Recopilar registros en cada una de las máquinas virtuales.
• Descargue e instale el agente MMA en máquinas virtuales Linux y Windows.
• Habilite la extensión 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 la Azure VMware Solution son similares a Azure máquinas virtuales dentro de la plataforma IaaS. Para obtener más información y procedimientos, consulte Supervisión de máquinas virtuales de Azure con Azure Monitor.

Comunicación al cliente

Puede encontrar problemas de servicio, mantenimiento planeado, avisos de estado y notificaciones de avisos de seguridad publicados a través de Service Health en el portal de Azure. Puede realizar acciones oportunas al configurar las alertas del registro de actividad para estas notificaciones. Para obtener más información, consulte Create Service Health alerts using the Azure portal.

Captura de pantalla de notificaciones de Service Health.

matriz de responsabilidades de Azure VMware Solution: Microsoft frente a cliente

Azure VMware Solution implementa un modelo de responsabilidad compartida que define roles y responsabilidades distintos de las dos partes implicadas en la oferta: cliente y Microsoft. 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.

Pasos siguientes

El siguiente paso es aprender los conceptos clave de arquitectura de nube privada.