vSAN/HCI

Diseño de redes de vSAN – Actualización 2019

En 2017, se escribieron tres blog posts que cubrían algunas opciones comunes de diseño de redes de vSAN:

Diseño de redes vSAN: ¿interfaces dedicadas o compartidas?

Diseño de redes vSAN: ¿Por qué debo usar el conmutador distribuido?

Diseño de redes vSAN – ¿Usando múltiples interfaces?

Sería una buena idea discutir cómo han envejecido estos blog posts y qué nuevas preguntas han surgido.

 

¿Necesito interfaces dedicadas para vSAN?

Para entornos de alto rendimiento, las interfaces dedicadas han ganado popularidad. Todas las aplicaciones All-flash vSAN y de nivel 1 pueden beneficiarse de no tener que depender de NIOC. Las interfaces y switches dedicados también pueden ayudar a resolver problemas al aislar la causa del tráfico en un switch. Para compensar el costo de las interfaces dedicadas, una configuración común es poner vMotion en los mismos switches, y tener vMotion predeterminado para switch A, vSAN para switch B y hacer que solo necesiten NIOC en caso de una interrupción del switch.

Han surgido nuevas preguntas en esta área:

¿Qué tipo de interruptores debo comprar para sitios remotos pequeños?

Anteriormente, para entornos híbridos pequeños, se consideraría la red de 1 Gbps para reducir los costos y permitir la re-utilización de los switches existentes. Esta implementación, aunque rara vez se considera como una opción de 2 nodos de conexión directa, ha eliminado este caso de uso. La recomendación es utilizar switches de 10Gbps o más. 

¿Qué debo tener en cuenta al comprar un switch?

Esta pregunta es más fácil de explicar con algunas cosas a considerar:

  • Evite los switches que no son switches – los switches que no pueden enviar paquetes de un puerto a otro directamente sin pasar por otro switch. Si bien es mucho más raro que en 2019, estos dispositivos de “Extensión de tela” todavía existan y no se deben considerar para el tráfico de alto rendimiento de East West, como vMotion o Almacenamiento.
  • No todos los switches de 10 Gbps son iguales – Tenga cuidado con los switches que se venden como “switches de acceso”. A menudo tendrán capacidades limitadas de supervisión y gestión. Estos switches a menudo pueden tener buffers y rendimiento muy limitados. El hecho de que se venda un switch de acceso más barato en 2019 no significa que no se base en un ASIC lanzado por primera vez en 2010.
  • Tenga en cuenta los switches con buffers de puertos pequeños – el hecho de que un dispositivo tenga interfaces de 10 Gbps no significa que funcionará bien bajo carga. Cuando un puerto se satura, los buffers agregarán una pequeña cantidad de latencia a costa de dejar caer el paquete y obligar a un paquete TCP a retransmitir (lo que tiende a ser mucho más impactante en el rendimiento). Ahora, si un puerto se está saturando con regularidad a velocidades más rápidas (25 Gbps en comparación con 10 Gbps), LACP (con hashes port de TCP de origen y destino avanzados) también puede ayudar. Si bien no es necesario que cada cluster de vSAN tenga buffers de 1 GB+, se debe esperar que un switch con buffer de 32 MB supere a un switch con buffer de 4 MB.
  • Tenga en cuenta los buffers de puertos compartidos – si bien un switch puede tener 32MB de buffer, a menudo se dividirá en unidades más pequeñas como puertos, grupos de puertos o cores. Es posible que el buffer total en el switch no esté saturado pero los paquetes aún se hayan caído. Si un switch se comparte entre vSAN y el tráfico de la VM normal, este comportamiento puede evitar que una gran ráfaga de tráfico a través de un uplink sobre-suscrito elimine todo el buffer disponible. En algunos casos, los switches pueden tener diferentes métodos de equilibrio de buffer que se pueden elegir. Si un solo puerto uplink con tráfico no-vSAN está consumiendo los buffers, cambiar los modos de asignación de buffer puede llevar a una mejora. Mientras que los uplinks no-bloqueantes son un gran punto de partida. Para los clusters que usan más de 6 hosts, se recomienda 16 MB (o más) de buffer en el switch. Para clusters más grandes y de alto rendimiento, considere los switches de buffer profundo (que proporcionan más de 1 GB de buffer compartido). Para los switches que aprovechan la cola de salida virtual (VoQ o Virtual Output Queue), confirme que al menos 1 MB de buffer por puerto esté disponible.
  • Los buffers no reemplazan las velocidades de enlace más rápidas – Los buffers solo son útiles cuando existe una disputa por el uso de un puerto que conduce a una demanda momentánea de más recursos, si todos los puertos están operando por debajo de su velocidad nominal de línea, no mejorará el rendimiento. Si un puerto va a estar restringido por un tiempo continuo prolongado, entonces un buffer no mejorará el rendimiento. En este punto, lo que se necesita para mejorar esta contención es aumentar la velocidad de enlace o la calidad de servicio (DSCP/CoS) que priorizan el tráfico vSAN sobre el tráfico que no es vSAN.
  • 25Gbps es el nuevo 10Gbps – si bien muchos de ustedes no necesitan el rendimiento, la compra de un switch de 25Gbps hoy lo prepara para futuras actualizaciones. También se asegura de que esté utilizando un ASIC más moderno, ya que los switches de 10 Gbps más baratos pueden usar silicona de 6 años (¡o más!). Esto también es válido para las tarjetas de red. A pesar de que sus switches sean de 10 Gbps, la compra de las NIC de 25GBps con ASIC más nuevas puede beneficiar el rendimiento.

 

¿Cómo debo configurar y administrar mis switches?

  • Monitoree sus switches – los buenos switches de clase empresarial le permitirán registrar errores de puerto. Los errores de CRC apuntarán a problemas con los cables físicos (fibra sucia, cables doblados, interferencias en cables no blindados). Esto a menudo también puede ser monitoreado por SNMP. Recomendaría configurar los switches con syslog para LogInsight y hacer que vRealize Operations monitoree los contadores SNMP en los switches, para ayudar a identificar rápidamente este tipo de problemas. Si un switch no es compatible de syslog, o SNMP, esto es potencialmente una advertencia de que esto también carecerá de rendimiento. Para controlar el agotamiento del buffer, los intervalos de sondeo de SNMP son demasiado largos. Considere utilizar alarmas de switch que notifiquen sobre el agotamiento del buffer, o configure sistemas de monitoreo de buffer de switch específicos.
  • Monitoree sus hosts – el hecho de que un switch no muestre un paquete caído no significa que no haya un problema. El control de flujo puede estar limitando un puerto saturado, las retransmisiones de TCP pueden ocurrir debido a una entrega fuera de orden, los hashes de LACP configurados incorrectamente pueden depender del entorno y ser visibles desde el host. SNMP y la monitorización tradicional se limitan al seguimiento de problemas de bursting. Para solucionar este problema, vSAN 6.7 incluye el modo de diagnóstico de red para ayudar con el sondeo de 1 segundo de las estadísticas clave de rendimiento de la red. El monitoreo adicional realizado en el lado ASIC del switch también puede admitir un monitoreo más granular de los buffers. Ejemplos de esto incluyen Arista LANZ, Cisco Active Buffer Monitoring
  • Considere el ciclo de vida del switch – históricamente, la actualización del código que se ejecuta en un switch requiere que se reinicie el switch y se produzcan unos pocos minutos de interrupción para este switch. Si bien este proceso se puede mitigar con rutas de switches redundantes, esto típicamente fue algo que limitó la cantidad de parches realizados, así como cambió estos parches a una ventana de mantenimiento específica. Los costosos switches de chasis con supervisores redundantes a menudo mitigaron este problema. Como punto medio, algunos nuevos switches de top-of-rack pueden admitir ISSU (actualizaciones de software en servicio). Tenga en cuenta que a veces hay advertencias y límites solo para actualizaciones menores. Esta funcionalidad puede ayudar a mantener los interruptores actualizados.
Vale la pena señalar que gran parte de esta guía también se aplica a iSCSI y NFS. En general, a todo el tráfico de almacenamiento de VMware le gusta tener una red de alta disponibilidad, baja latencia, bajo jitter y baja pérdida de paquetes.