vSAN es compatible con las implementaciones de clúster ampliado que abarcan dos ubicaciones.
En vSAN 6.5 y versiones anteriores, el tráfico de vSAN entre sitios de datos es de multidifusión para los metadatos y de unidifusión para las operaciones de E/S.
En vSAN 6.6 y versiones posteriores, todo el tráfico es de unidifusión. En todas las versiones de vSAN, el tráfico testigo entre un sitio de datos y el host testigo es de unidifusión.
Capa 2 en todos los sitios
Puede configurar un clúster ampliado de vSAN en una red de capa 2, pero no se recomienda esta configuración.
Considere un diseño en el que el clúster ampliado de vSAN esté configurado en un diseño de capa 2 grande. Los sitios de datos 1 y 2 son donde se implementan las máquinas virtuales. El sitio 3 contiene el host testigo.
Para demostrar la capa 2 en todos los sitios de la forma más simple posible, utilizamos conmutadores (y no enrutadores) en las topologías.
Las redes de capa 2 no pueden tener bucles (varias rutas de acceso), por lo que se necesitan funciones como el protocolo de árbol de expansión (Spanning Tree Protocol, STP) para bloquear una de las conexiones entre el sitio 1 y el sitio 2. Ahora, suponga una situación en la que el vínculo entre el sitio 2 y el sitio 3 esté roto (el vínculo entre el sitio 1 y el sitio 2). El tráfico de red ahora se puede cambiar del sitio 1 al sitio 2 a través del host testigo del sitio 3. Como VMware admite un ancho de banda mucho menor y una latencia mucho mayor para el host testigo, se observa una disminución significativa del rendimiento si el tráfico de red de datos pasa a través de un sitio testigo de especificación más bajo.
Si el tráfico de conmutación entre sitios de datos a través del sitio testigo no afecta a la latencia de las aplicaciones y el ancho de banda es aceptable, se permite una configuración de capa 2 ampliada entre sitios. En la mayoría de los casos, una configuración de este tipo no es factible y agrega complejidad a los requisitos de red.
Con vSAN 6.5 o una versión anterior, que utiliza tráfico de multidifusión, debe configurar la intromisión IGMP en los conmutadores. Esto no es necesario con vSAN 6.6 y versiones posteriores. PIM no es necesario porque no hay enrutamiento de tráfico de multidifusión.
Configuraciones admitidas de un clúster ampliado de vSAN
vSAN admite configuraciones de clúster ampliado.
La siguiente configuración evita que el tráfico del sitio 1 se enrute al sitio 2 a través del host testigo, en caso de que se produzca un error en cualquiera de las redes de los sitios de datos. Esta configuración evita la degradación del rendimiento. Para asegurarse de que el tráfico de datos no se conmuta a través del host testigo, use la siguiente topología de red.
Entre el sitio 1 y el sitio 2, implemente una configuración de capa 2 con conmutador ampliado o una configuración de capa 3 enrutada. Ambas configuraciones están admitidas.
Entre el sitio 1 y el host testigo, implemente una configuración de capa 3 enrutada.
Entre el sitio 2 y el host testigo, implemente una configuración de capa 3 enrutada.
Estas configuraciones (L2+L3 y capa 3 en todos los sitios) se describen con las consideraciones que se proporcionan para la multidifusión en vSAN 6.5 y versiones anteriores, y solo para unidifusión, que está disponible en vSAN 6.6. El tráfico de multidifusión introduce pasos de configuración adicionales para la intromisión de IGMP y PIM para enrutar el tráfico de multidifusión.
Examinaremos una red de capa 2 ampliada entre los sitios de datos y una red con enrutamiento de capa 3 al sitio testigo. Para demostrar una combinación de capa 2 y capa 3 lo más simple posible, utilice una combinación de conmutadores y enrutadores en las topologías.
Capa 2 ampliada entre sitios de datos, Capa 3 al host testigo
vSAN admite configuraciones de capa 2 ampliada entre sitios de datos.
El único tráfico que se enruta en este caso es el tráfico testigo. Con vSAN 6.5 y versiones anteriores, que utilizan multidifusión, utilice la intromisión IGMP para el tráfico de multidifusión en vSAN de capa 2 ampliado entre los sitios de datos. Sin embargo, debido a que el tráfico testigo es de unidifusión, no es necesario implementar PIM en los segmentos de capa 3.
Con vSAN 6.6, que utiliza unidifusión, no es necesario tener en cuenta la intromisión IGMP ni PIM.
Capa 3 en todos los sitios
En esta configuración de clúster ampliado de vSAN, el tráfico de datos se enruta entre los sitios de datos y el host testigo.
Para implementar la capa 3 en todos los sitios de la forma más simple posible, utilice enrutadores y conmutadores de enrutamiento en las topologías.
Por ejemplo, supongamos un entorno con vSAN 6.5 o una versión anterior, que utiliza tráfico de multidifusión. En este caso, configure la intromisión de IGMP en los conmutadores del sitio de datos para administrar la cantidad de tráfico de multidifusión en la red. Esto no es necesario en el host testigo, ya que el tráfico testigo es de unidifusión. El tráfico de multidifusión se enruta entre los sitios de datos, por lo que debe configurar PIM para permitir el enrutamiento de multidifusión.
Con vSAN 6.6 y versiones posteriores, no es necesario la intromisión IGMP ni PIM porque todo el tráfico enrutado es de unidifusión.
Separar el tráfico testigo en los clústeres ampliados de vSAN
vSAN admite la separación del tráfico testigo en los clústeres ampliados.
vSAN 6.5 y versiones posteriores permiten separar el tráfico testigo del tráfico de vSAN en configuraciones de dos nodos. Esto significa que los dos hosts vSAN se pueden conectar directamente sin un conmutador de 10 Gb.
Esta separación de tráfico testigo solo se admite en implementaciones de dos nodos en vSAN 6.6. La separación del tráfico testigo en los clústeres ampliados de vSAN se admite en vSAN 6.7 y versiones posteriores.
Usar un clúster ampliado de vSAN para lograr el reconocimiento de los bastidores
Con los clústeres ampliados de vSAN, vSAN proporciona reconocimiento de los bastidores en un único sitio.
Si tiene dos bastidores de hosts vSAN, puede seguir ejecutando el clúster de vSAN después de un error de bastidor completo. En este caso, la disponibilidad de las cargas de trabajo de la máquina virtual se proporciona mediante el bastidor restante y un host testigo remoto.
En este ejemplo, si se produce un error en el bastidor 1, el bastidor 2 y el host testigo proporcionarán la disponibilidad de la máquina virtual. Esta configuración es un entorno previo a vSAN 6.6 y necesita que se configure multidifusión en la red. El host testigo debe estar en la red de vSAN. El tráfico testigo es de unidifusión. En vSAN 6.6 y versiones posteriores, todo el tráfico es de unidifusión.
Esta topología también se admite a través de capa 3. Coloque los puertos de VMkernel de vSAN en diferentes subredes o VLANs, y utilice una subred o VLAN independiente para cada bastidor.
Esta topología admite implementaciones con dos bastidores para lograr el reconocimiento de los bastidores (dominios de errores) con un clúster ampliado de vSAN. Esta solución utiliza un host testigo externo al clúster.
