Tenga en cuenta las características de red que pueden proporcionar disponibilidad, seguridad y ancho de banda garantizado en un clúster de Virtual SAN.

Para obtener detalles sobre la configuración de red de Virtual SAN, consulte Guía de diseño y dimensionamiento de VMware Virtual SAN y Guía de diseño de red de Virtual SAN.

Conmutación por error y equilibrio de carga de red

Virtual SAN utiliza la directiva de formación de equipos y conmutación por error que está configurada en el conmutador virtual de respaldo solamente para redundancia de red. Virtual SAN no utiliza la directiva conmutación por error ni formación de equipos de NIC .

Si tiene planificado configurar un equipo de NIC para obtener disponibilidad, tenga en cuenta estas configuraciones de conmutación por error.

Algoritmo de formación de equipos

Configuración de conmutación por error de los adaptadores del equipo

Enrutar según el puerto virtual de origen

Activa/pasiva

Route based on IP hash (Enrutar según el hash de IP)

Activa/activa con EtherChannel estático para conmutador estándar y canal de puerto LACP para conmutador distribuido

Enrutar según carga de adaptador de red físico

Activa/activa con canal de puerto LACP para conmutador distribuido

Virtual SAN admite equilibrio de carga para hash de IP, pero no puede garantizar una mejora en el rendimiento para todas las configuraciones. Puede beneficiarse del hash de IP cuando Virtual SAN se encuentra entre su gran cantidad de consumidores. En este caso, el hash de IP realiza el equilibrio de carga. Si Virtual SAN es el único consumidor, es posible que no note ninguna mejora. Este comportamiento se aplica específicamente a los entornos 1 GbE. Por ejemplo, si usa cuatro adaptadores físicos 1 GbE con hash de IP para Virtual SAN, es posible que no pueda aprovechar más de 1 Gbps. Este comportamiento se aplica también a todas las directivas de formación de equipos de NIC que son compatibles con VMware.

Virtual SAN no admite varios adaptadores de VMkernel en la misma subred. Puede usar varios adaptadores de VMkernel en subredes diferentes, como otra VLAN o un tejido físico independiente. Si se utilizan varios adaptadores de VMkernel para proporcionar disponibilidad, existen desventajas de configuración, que afectan, por ejemplo, a vSphere y la infraestructura de red. La disponibilidad de red Network mediante la formación de equipos de adaptadores de red físicos se logra más fácilmente y con menos requisitos de configuración.

Consideraciones de multidifusión en una red Virtual SAN

Es posible habilitar la multidifusión en los conmutadores físicos para habilitar el latido y el intercambio de metadatos entre los hosts y el clúster de Virtual SAN. Puede configurar un solicitante de intromisiones de IGMP en los conmutadores físicos para la entrega de mensajes de multidifusión únicamente por medio de los puertos de conmutadores físicos que están conectados a los adaptadores de red de host Virtual SAN. En caso de que haya varios clústeres de Virtual SAN en la misma red, antes de implementar un clúster adicional de Virtual SAN para producción, cambie la dirección de multidifusión del nuevo clúster, de modo que los hosts miembros no reciban mensajes de multidifusión no relacionados de otro clúster. Para obtener más información sobre cómo asignar una dirección de multidifusión a un clúster de Virtual SAN, consulte Cambiar la dirección de multidifusión para un clúster de Virtual SAN.

Asignar ancho de banda para Virtual SAN mediante Network I/O Control

Si el tráfico de Virtual SAN usa adaptadores de red físicos de 10 GbE que se comparten con otros tipos de tráfico del sistema, como tráfico de vSphere vMotion, tráfico de vSphere HA, tráfico de máquinas virtuales, etc., puede usar vSphere Network I/O Control en vSphere Distributed Switch para garantizar la cantidad de ancho de banda que se necesita para Virtual SAN.

En vSphere Network I/O Control, puede configurar la reserva y los recursos compartidos para el tráfico saliente de Virtual SAN.

  • Configure una reserva para que Network I/O Control garantice que el ancho de banda mínimo esté disponible en el adaptador físico para Virtual SAN.

  • Configure recursos compartidos de modo que, cuando se sature el adaptador físico para Virtual SAN, haya un cierto ancho de banda disponible para Virtual SAN, y también para evitar que Virtual SAN consuma toda la capacidad del adaptador físico durante las operaciones de reconstrucción y sincronización. Por ejemplo, es posible que el adaptador físico se sature cuando se produce un error en otro adaptador físico del equipo y todo el tráfico del grupo de puertos se transfiere a los demás adaptadores del equipo.

Por ejemplo, es posible configurar ciertos recursos compartidos y ancho de banda en un adaptador físico de 10 GbE que controla tráfico para Virtual SAN, vSphere vMotion y máquinas virtuales.

Tabla 1. Ejemplo de configuración de Network I/O Control para un adaptador físico que controla Virtual SAN

Tipo de tráfico

Reserva (Gbps)

Shares (Recursos compartidos)

Virtual SAN

1

100

vSphere vMotion

0.5

70

Máquina virtual

0.5

30

Si el adaptador 10 GbE se satura, Network I/O Control asigna 5 Gbps a Virtual SAN en el adaptador físico.

Para obtener más información sobre cómo utilizar vSphere Network I/O Control para configurar la asignación de ancho de banda para el tráfico de Virtual SAN, consulte el documento Redes de vSphere.

Marcar tráfico de Virtual SAN

El etiquetado prioritario es un mecanismo que permite indicar a los dispositivos de red conectados que el tráfico de Virtual SAN tiene grandes exigencias de calidad de servicio (QoS). Puede asignar tráfico de Virtual SAN a una determinada clase y, en consecuencia, marcar el tráfico con un valor de clase de servicio (CoS) de 0 (baja prioridad) a 7 (alta prioridad) mediante la directiva de filtrado y marcado de tráfico de vSphere Distributed Switch.

Segmentar tráfico de Virtual SAN en una VLAN

Considere la posibilidad de aislar el tráfico de Virtual SAN en una VLAN a fin de obtener seguridad y rendimiento mejorados, especialmente si comparte la capacidad del adaptador físico de respaldo entre varios tipos de tráfico.

Tramas gigantes

Si tiene planificado usar tramas gigantes con Virtual SAN para mejorar el rendimiento de las CPU, compruebe que las tramas gigantes estén habilitadas en todos los dispositivos de red y en todos los hosts del clúster.

De manera predeterminada, las características de descarga de segmentación TCP (TSO) y descarga de recepción grande (LRO) están habilitadas en ESXi. Evalúe si el uso de las tramas gigantes mejorará el rendimiento lo suficiente para justificar el costo que implica habilitarlas en todos los nodos de la red.