VM-1 on host-1 <[cable]> network router <[cable]> host-2 with VM-2
Si entiendo correctamente, en caso de transferencia de archivos desde la aplicación en VM-1 a la misma aplicación en VM-2, los datos pasarán por el siguiente viaje:
- Archivo de aplicación VM-1 leído en la memoria intermedia
- llamadas relacionadas con lenguajes de programación
- llamadas a nivel del sistema operativo
- lógica seccomp/apparmor
- lógica de permisos del sistema de archivos
- manejo de archivos y buffer del sistema operativo
- Datos de la aplicación VM-1 enviados al búfer del socket de red
- llamadas al sistema operativo
- lógica seccomp/apparmor
- Pila de red del sistema operativo VM-1
- tablas de enrutamiento
- lógica del cortafuegos
- Pila de red virtual del hipervisor Host-1
- interruptor virtual
- tablas de enrutamiento
- Pila de red del sistema operativo Host-1
- tablas de enrutamiento
- lógica del cortafuegos
- Búfer de tarjeta de red física Host-1
- Enrutador de red
- casi la misma pila de cosas reflejadas va aquí para VM-2 en host-2
Suponiendo que el archivo será grande, los pasos relacionados con seccomp/apparmor, enrutamiento y firewall se almacenarán en caché/se omitirán para el archivo ya abierto y transferido.
Pero en caso de comunicación frecuente entre máquinas virtuales con mensajes lo suficientemente pequeños como para caber en 1 o 2 paquetes tcp, tenemos un problema.
Cada llamada y procesamiento lógico necesitará varios cientos de tics de CPU y el exceso de apilamiento descrito supondrá una carga significativa para la CPU y desempeñará un papel en la latencia.
- segúnPrueba del rendimiento de la red Docker multihost [agosto de 2016]es al menos -13% en rendimiento.
- EnLatencia de E/S de red en VMware vSphere® 5"Descubrimos que en un sistema inactivo, la sobrecarga de latencia de ida y vuelta por VM es de aproximadamente 15 a 20 microsegundos. Este número aumenta a medida que aumenta la contención de recursos en vSphere, lo cual es de esperar. La fluctuación era muy baja siempre que el sistema no estuviera demasiado comprometido .
- Además, la corrección de Meltdown y Spectre Intel dará como resultado una caída aún mayor del rendimiento.
Preguntas
- ¿El socket de comunicación abierto previamente entre máquinas virtuales omitirá algún paso en la lista descrita?
- HaceSDN¿mitiga de alguna manera estos problemas o agrega aún más superposiciones y encabezados adicionales a los paquetes?
- ¿Realmente necesito el proceso descrito para comunicarme entre VM-1 y VM-2 o hay una compilación especial de Linux "menos segura, con más rendimiento, bajo su propio riesgo"?
- ¿Tengo que seguir con Linux? ¿Algún sistema tipo *BSD más rápido con soporte para Docker?
- ¿Cuáles son las mejores prácticas para mitigar ese cuello de botella y, como resultado, adaptar más máquinas virtuales con microservicios en el mismo host?
- Hacer soluciones comoProyecto Calicó¿Ayuda o se trata más de un nivel inferior?
Respuesta1
¿El socket de comunicación abierto previamente entre máquinas virtuales omitirá algún paso en la lista descrita?
El socket previamente abierto entre máquinas virtuales/contenedores funcionará debido a la sobrecarga del protocolo de enlace TCP; y más aún, si existe un TLS.
Aunque se acepta que la sobrecarga del apretón de manos es insignificante, cuando hablamos de comunicación frecuente, comienza a desempeñar un papel importante.
No es muy inteligente tener el estado límite de M x N conexiones abiertas en el caso de una red de contenedores tipo malla. Será mejor una solución simple de mantenimiento de actividad con TTL basada en las estadísticas de comunicación de sus propios contenedores.
Tenga en cuenta que demasiados subprocesos que mantienen activas las conexiones TCP provocarán otra sobrecarga, así que asegúrese de utilizar epoll.
¿SDN mitiga de alguna manera estos problemas o agrega aún más superposiciones y encabezados adicionales a los paquetes?
Agrega más superposiciones, muchas están bloqueadas por el proveedor, pero hay al menos unatubería SDNLa solución relacionada que se describe a continuación trata sobre el entorno Docker.
¿Realmente necesito el proceso descrito para comunicarme entre VM-1 y VM-2 o hay una compilación especial de Linux "menos segura, con más rendimiento, bajo su propio riesgo"?
No encontré una compilación de Linux "especial" con una comunidad lo suficientemente confiable y soporte de actualizaciones, pero los problemas con la pila TCP lenta de Linux no son nuevos y hay muchas opciones para omitir el kernel.Cloudflare hace eso.
Deartículos que encontré, la pila TCP de Linux lenta es bien conocida y no hay opción de instalar el servidor Linux y ganar: tienes que ajustar al hijo de Torvald para resolver tu propio problema de esta o aquella manera cada vez.
¿Tengo que seguir con Linux? ¿Algún sistema tipo *BSD más rápido con soporte para Docker?
No he encontrado evidencia de que Windows, MacOS o sistemas similares a *BSD tuvieran mejores conexiones de red que el último Linux con su pila TCP lenta con bypass del kernel aplicado.
¿Cuáles son las mejores prácticas para mitigar ese cuello de botella y, como resultado, adaptar más máquinas virtuales con microservicios en el mismo host?
Entonces, hay dos cuellos de botella: Linux invitado y Linux anfitrión.
Para el host Linux, en caso de que se utilice no solo para el alojamiento de contenedores, existe una estrategia de omisión del kernel con una gran variedad de opciones que se describen enblog de nubeflarey"¿Por qué utilizamos la pila TCP del kernel de Linux?" artículohasta escribir su propia pila TCP centrada en aplicaciones.
Para Linux invitadomacvlanse puede utilizar para omitir la Capa 3 y conectar el contenedor acoplable directamente a la NIC con su propia dirección MAC. Esmucho mejor que el puente, porque mitiga muchos cuellos de botella de la red Linux tanto de invitados como de host, pero asegúrese de estar listo para explotar la tabla de direcciones mac de su enrutador con otros cien o mil registros; lo más probable es que tenga que segmentar su red.
También segúnPresentación de tecnologías de conmutación virtual y puente LinuxExiste una opción SR-IOV que es incluso mejor que Macvlan. Esdisponible para Docker 1.9+ para adaptadores Ethernet Mellanoxcomo complemento, incluido como modo entubería SDN, se ha dedicadoComplemento SRIOV de Clear Containers- más que suficiente para empezar a buscar una solución centrada en la aplicación.
¿Soluciones como Project Calico ayudan o se trata más de un nivel inferior?
Es totalmente otro nivel y no tendrá un impacto significativo en comparación con SRIOV y Macvlan, pero ayudan a simplificar la administración de la red casi sin gastos generales además de la solución de derivación que usted elija.
Y si...
Supervise de cerca su Docker, ya que puede hacer cosas inesperadas. Por ejemplo, modifica pruebas nf_naty xt_conntrack, cuando no hay ningún motivo con Macvlan activado, genera un gasto adicional de ticks de CPU.