Infraestructura virtual de vCenter

Con la integración de Apstra vCenter, tiene visibilidad de VM de sus entornos virtualizados. Esta función ayuda a solucionar varios problemas de conectividad de VM. Se marcan las inconsistencias entre la configuración de red virtual (grupos de puertos de VMware) y las redes físicas (Apstra Virtual Networks) que podrían afectar la conectividad de vm.

Para lograr esto, el software Apstra identifica los hosts ESX/ESXi y, por lo tanto, las máquinas virtuales conectadas a conmutadores leaf administrados por Apstra. La información de LLDP transmitida por los hosts ESX/ESXi se utiliza para asociar interfaces de host con interfaces leaf. Para que esta función funcione, la transmisión de LLDP debe estar habilitada en el conmutador virtual distribuido de VMware.

El software Apstra también se conecta a vCenter para recopilar información sobre máquinas virtuales, hosts ESX/ESXi, grupos de puertos y VDS. Los recolectores de telemetría extensible de Apstra recopilan esta información. El recopilador se ejecuta en un agente offbox y usa pyVmomi para conectarse a vCenter. Al conectar primero, descarga toda la información necesaria y, a continuación, sondea vCenter cada 60 segundos para ver nuevas actualizaciones. El recopilador actualiza los datos descubiertos en el almacén de datos de gráficos de Apstra, lo que permite que las consultas y alertas de VM se planteen en la discordancia de la red física y virtual.

• Versiones compatibles
• Limitaciones

Cuando el software Apstra administra la infraestructura virtual, puede consultar máquinas virtuales por nombre. Desde el plano, vaya a Active > Query > VM y escriba los criterios de búsqueda. Las máquinas virtuales incluyen los siguientes detalles:

Puede validar la infraestructura virtual con análisis basados en la intención. Apstra valida la sesión del BGP hacia el borde NSX-T. En caso de que se elimine la vecindad del BGP en el administrador de NSX-T, se pueden ver las respectivas anomalías en el panel de Control de Apstra.

Hay dos paneles de análisis predefinidos (como se enumeran a continuación) que instancian las pruebas de infraestructura virtuales predefinidas.

Panel de verificación de estado de Virtual Infra Fabric

• Sonda de discordancia de MTU del hipervisor
• Sondeo de comprobación de umbral de MTU del hipervisor
• Sonda de discordancia de configuración LAG de estructura y hipervisor
• Sonda de discordancia de configuración de VLAN de estructura y hipervisor
• Prueba de configuración de LLDP faltante
• Máquinas virtuales sin sonda de VLAN configuradas por estructura

Panel de control de redundancia de infraestructuras virtuales

• Sonda de comprobación de redundancia del hipervisor

Para obtener más información, consulte Panel de análisis y pruebas.

La reparación automática de anomalías de red virtual está disponible sin intervención del usuario. Esto puede reducir el costo operativo cuando los operadores de red no necesitan investigar cada anomalía y comprobar los detalles e intervenir para mitigar las anomalías. La corrección automática de VxLAN es una política configurada al agregar vCenter/NSX-T a un plano. La corrección de anomalías se realiza de acuerdo con esta política.

Un enfoque de corrección automática basado en políticas le notifica automáticamente si hay una discordancia entre vSphere DPG (VMware Port Groups) y VN en un plano determinado, o si hay una discordancia de VLAN entre la infraestructura virtual y la estructura de Apstra, o si hay una discordancia en la configuración DE LAG en los hipervisores y los puertos leaf correspondientes. El software Apstra proporciona una reparación guiada automática de estas anomalías.

A continuación, se enumeran algunas de las restricciones y validaciones que tienen lugar antes de la reparación:

• Cuando la política de corrección se establece en VLAN, es decir, local de rack, la zona de enrutamiento solo puede ser la predeterminada.
• Si el ID de VLAN para redes virtuales que abarcan varios hipervisores es el mismo, se asume un dominio de difusión de una sola capa 2. Para tales situaciones, la política de corrección de VLAN debe establecerse en VXLAN, ya que para las anomalías de VLAN faltantes, se comprueba en todos los dispositivos leaf ToR conectados a diferentes hipervisores que tengan una red virtual con el mismo ID de VLAN. Si se elige por error como tipo de VLAN, se generan errores de validación.
• Los errores se marcan para diferentes tipos de políticas de corrección (por ejemplo, si una es de tipo VXLAN y otra es tipo VLAN) se encuentran conectadas a diferentes infraestructuras virtuales (como dos servidores vCenter diferentes) que tienen el mismo ID de VLAN en anomalías.
• Si se asignan dos servidores de infraestructuras virtuales diferentes en un plano y tienen los mismos IDENTIFICADORes de VLAN, se comprueba como dos redes virtuales independientes mediante la política de corrección automática de VXLAN.