vCenter Virtual Infra

Con la integración de Apstra vCenter, tiene visibilidad de VM de sus entornos virtualizados. Esta característica ayuda a solucionar varios problemas de conectividad de VM. Se señalan las inconsistencias entre la configuración de red virtual (grupos de puertos de VMware) y las redes físicas (redes virtuales de Apstra) que puedan afectar a la conectividad de VM.

Para lograr esto, el software de Apstra identifica los hosts ESX/ESXi y, por lo tanto, las máquinas virtuales conectadas a los conmutadores leaf administrados por Apstra. La información LLDP transmitida por los hosts ESX/ESXi se usa para asociar interfaces de host con interfaces leaf. Para que esta función funcione, la transmisión 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 recopiladores de telemetría extensible de Apstra recopilan esta información. El recopilador se ejecuta en un agente de externa y utiliza pyVmomi para conectarse a vCenter. En la primera conexión, descarga toda la información necesaria y, a continuación, sondea vCenter cada 60 segundos en busca de nuevas actualizaciones. El recopilador actualiza los datos descubiertos en el almacén de datos de Apstra Graph, lo que permite generar consultas y alertas de VM sobre la falta de coincidencia entre la red física y virtual.

• Versiones compatibles
• Limitaciones

Cuando el software de Apstra administra la infraestructura virtual, puede consultar las máquinas virtuales por nombre. En el plano, vaya a Consulta > máquina virtual de > activa e introduzca 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 BGP hacia NSX-T Edge. En caso de que se elimine la vecindad de BGP en NSX-T Manager, se pueden ver las anomalías respectivas en el panel de Apstra.

Hay disponibles dos paneles de análisis predefinidos (como se enumeran a continuación) que crean instancias de sondas de infraestructura virtual predefinidas.

Panel de control de estado de Virtual Infra Fabric

• Sonda de discrepancia de MTU del hipervisor
• Sonda de comprobación de umbral MTU del hipervisor
• Sonda de no coincidencia de configuración LAG de hipervisor y estructura
• Sonda de no coincidencia de configuración de VLAN de hipervisor y estructura
• Falta la sonda de configuración LLDP del hipervisor
• Máquinas virtuales sin sondeo de VLAN configuradas por estructura

Panel de control de redundancia de infraestructura virtual

• Sonda de comprobaciones de redundancia del hipervisor

La correcció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 verificar los detalles e intervenir para mitigar las anomalías. La corrección automática de VxLAN es una política que se configura 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 discrepancia entre vSphere DPG (grupos de puertos de VMware) y VN en un plano determinado, o si hay una discrepancia de VLAN entre la infraestructura virtual y la estructura de Apstra, o si hay una discrepancia en la configuración de LAG en hipervisores y los puertos leaf correspondientes. El software Apstra proporciona una remediación guiada automática de tales anomalías.

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

• Cuando la política de corrección se establece en VLAN, es decir, local en rack, la zona de enrutamiento solo puede ser la predeterminada.
• Si el ID de VLAN para una red virtual que abarca varios hipervisores es el mismo, se asume un único dominio de difusión de capa 2. Para tales escenarios, 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 hoja de ToR conectados a diferentes hipervisores que tienen 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 la otra es de 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 infraestructura virtual diferentes en un plano y tienen los mismos ID de VLAN, la política de corrección automática de VXLAN lo comprueba como dos redes virtuales independientes.