Segmentación trafico DR

Hola Antonio,

La guía que mencionas habla de mejores prácticas para utilizar la solución de DR de Nutanix, por lo que asumo que tu consulta es sobre eso.

Antes de profundizar en el tema, me gustaría entender cuál es el propósito que tienes en mente para enviar el tráfico de DR por una ruta distinta. ¿Cuántos enlaces tienes entre los 2 sitios? 

Hola Roberto, 

Gracias por el mensaje. Te pongo un poco en contexto sobre el diseño de la solución:

Actualmente estamos en proceso de implantar un entorno de Metro Availability compuesto por dos clústeres y una Witness VM. El cliente nos ha trasladado su preocupación debido a que en el pasado sufrieron incidentes graves con Spanning Tree que provocaron el aislamiento de los CPDs.

En un escenario similar, si se perdiera simultáneamente la comunicación entre ambos clústeres y el Witness, la solución entraría en estado decoupled (desacoplado), dejando el entorno inactivo y todas las máquinas virtuales sin servicio.

Para mitigar este riesgo de aislamiento por red, nuestra intención es configurar y enrutar el tráfico de Disaster Recovery (DR) de forma directa entre ambos CPDs, aprovechando un enlace dedicado que ya utilizan actualmente para la réplica de cabinas de almacenamiento.

Quedo a tu disposición por si necesitas cualquier aclaración o detalle técnico adicional.

Gracias

Hola Antonio y Roberto,

las preguntas de Roberto me parecen muy pertinentes. Es importante entender las razones para esa segregación de tráfico (Nutanix recomienda, por simplicidad, no hacerlo, pero es cierto que determinados escenarios lo requieren).

Si te fijas en los diagramas que figuran en nuestra documentación:
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v7_5:wc-segmented-unsegmented-networks-difference-c.html

Se puede aislar el tráfico de Management (que está asociado siempre al interfaz eth0 de la CVM), el tráfico de backplane (tráfico intra-cluster), el de RDMA, el de Nutanix Volumes y el de DR. 
En la ilustración de la página que te comentaba ves un ejemplo en el que se dedican dos interfaces de red al tráfico de DR (en el caso de AHV los interfaces eth2 y eth3 de los hosts) segregados en un vSwitch diferente. Esto implica la creación de un interfaz de red adicional en la CVM.
En términos de resiliencia, no cambian los criterios de diseño: es necesario contar con dos interfaces de red por cada host y, si es posible, dos caminos diferentes entre los centros de datos que alojan al clúster primario y al secundario. El tráfico se puede llevar por una VLAN extendida entre ambos o enrutando el tráfico entras las VLAN de cada datacenter, como ocurre en un escenario sin segmentación.
Si hablamos de replicación síncrona, también aplicaría la regla de 5 ms RTT entre clústeres como latencia máxima soportada.

Esta otra página te recuerda los prerequisitos a tener en cuenta antes de activar la segmentación de tráfico:
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v7_5:wc-network-segmentation-prerequisites-r.html

Un saludo.

Buenas Pepe, 

Tienes razón, se me paso indicarlo, actualmente tenemos 2 virtual switches (vs0 y vs1), uno para MGMT y otro para Vms.
En los nodos tenemos 2 puertos mas, en los que estaba pensando crear un nuevo vs para esta trafico de DR.
 

Gracias Antonio,

segmentar el tráfico agrega complejidad, pero te permite reducir el impacto del fallo de algún componente de red y evita competencia por el ancho de banda entre tráficos de distinta naturaleza.

Siempre y cuando mantengas la alta disponibilidad en toda la infraestructura de red y tengas en cuenta la latencia máxima, no se me ocurre ningún efecto adverso en esta configuración.

Saludos,

                        Pepe López

Hola Pepe, 

Gracias de nuevo por tu respuesta.

La duda que tengo es si realmente es necesario realizar algún tipo de configuración adicional a nivel de Metro Availability, en lo que respecta a las Availability Zones (AZ), protection policies y recovery plan.
Asimismo, me gustaría confirmar cuál sería la forma adecuada de asegurar que el tráfico asociado a este escenario esté pasando efectivamente por el enlace previsto.

Saludos
 

Antonio Maeso

Gracias Pepe por la documentación.

Algunos puntos importantes,

1. Segmentación no es lo mismo que virtual switch.

Lo que Pepe te comenta es que hay una opción para que la CVM tenga una vNIC dedicada exclusivamente para backend traffic. Lo mismo pasaría si configuras segmentación para DR. Esto no es necesario para la mayoría de escenarios. De acuerdo a lo que describes, me parece un escenario muy tradicional y desde mi punto de vista, no hay necesidad de entrar en diagramas más complejos.

2. STP genera problemas también en Nutanix. Hay que configurar todos los puertos que utilizan los nodos como Edge o FastPort, que es lo mismo pero el nombre depende del modelo del switch, para que no participen en la tabla de enrutamiento de STP.

Existen documentos con mejores practicas para varias marcas de switches. En todos se menciona que hay que sacar los puertos de STP.

Volviendo al tema de DR:

Nutanix incluye controles de ancho de banda para DR y un enlace dedicado no es necesario.

Prescindir de un enlace dedicado podría presentar una oportunidad de ahorro para el cliente, o si no tienen una ruta alternativa para el enlace metro, pueden considerar mejor utilizarlo como enlace secundario y ampliar las opciones de alta disponibilidad y balanceo de carga.

Si no es posible deshacerse del enlace y además no puede utilizarse como enlace para metro, por la latencia o por cualquier otra razón, entonces sí hace sentido configurar la segmentación para aprovechar el enlace.