A comunicação de rede VM/Docker multi-host é LENTA, alguma prática recomendada?

Question

VM-1 on host-1 <[cable]> network router <[cable]> host-2 with VM-2

Se bem entendi, no caso de transferência de arquivos do aplicativo na VM-1 para o mesmo aplicativo na VM-2, os dados passarão pela seguinte jornada:

• Arquivo do aplicativo VM-1 lido no buffer de memória
  • chamadas relacionadas à linguagem de programação
  • chamadas em nível de sistema operacional
  • lógica seccomp/apparmor
  • lógica de permissões do sistema de arquivos
  • manipulação de arquivos e buffer do sistema operacional
• Dados do aplicativo VM-1 enviados para buffer de soquete de rede
  • chamadas do sistema operacional
  • lógica seccomp/apparmor
• Pilha de rede do sistema operacional VM-1
  • tabelas de roteamento
  • lógica de firewall
• Pilha de rede virtual do hipervisor host-1
  • interruptor virtual
  • tabelas de roteamento
• Pilha de rede do sistema operacional Host-1
  • tabelas de roteamento
  • lógica de firewall
• Buffer da placa de rede física Host-1
• Roteador de rede
• quase a mesma pilha de coisas espelhadas vai aqui para VM-2 no Host-2

Supondo que o arquivo seja grande, as etapas relacionadas a seccomp/apparmor, roteamento e firewall serão armazenadas em cache/omitidas para arquivos já abertos e transferidos.

Mas no caso de comunicação frequente entre máquinas virtuais com mensagens pequenas o suficiente para caber em 1-2 pacotes tcp, temos problemas

Cada chamada e processamento lógico precisará de várias centenas de ticks de CPU e o overstack descrito colocará uma carga significativa na CPU e desempenhará um papel na latência.

• ConformeTestando o desempenho da rede multi-host do Docker [agosto de 2016]tem pelo menos -13% de desempenho.
• EmLatência de E/S de rede no VMware vSphere® 5"Descobrimos que, em um sistema inativo, a sobrecarga de latência de ida e volta por VM é de aproximadamente 15 a 20 microssegundos. Esse número aumenta à medida que aumenta a contenção de recursos no vSphere, o que é esperado. O jitter era muito baixo, desde que o sistema não estivesse sobrecarregado .
• Além disso, a correção do Meltdown e do Spectre Intel resultará em ainda mais queda de desempenho.

Questões

1. O soquete de comunicação pré-aberto entre VMs omitirá alguma etapa da lista descrita?
2. FazSDNde alguma forma atenua esses problemas ou adiciona ainda mais sobreposições e cabeçalhos extras aos pacotes?
3. Eu realmente preciso do processo descrito para me comunicar entre VM-1 e VM-2 ou existe uma compilação especial do Linux "menos segura, mais desempenho, uso por sua conta e risco"?
4. Eu tenho que ficar com o Linux? Algum sistema mais rápido do tipo *BSD com suporte para docker?
5. Quais são as práticas recomendadas para mitigar esse gargalo e ajustar mais VMs com microsserviços no mesmo host como resultado?
6. Faça soluções comoProjeto Calicoajuda ou é mais sobre nível inferior?

Answer 1

O soquete de comunicação pré-aberto entre VMs omitirá alguma etapa da lista descrita?

O soquete pré-aberto entre VMs/contêineres funcionará devido à sobrecarga do handshake TCP; e ainda mais, se houver um TLS.

Embora seja aceito que a sobrecarga do handshake seja insignificantemente pequena, quando falamos de comunicação frequente, ela começa a desempenhar um papel significativo.

Ter o estado limite de M x N conexões abertas no caso de uma rede de contêineres tipo malha não é muito sábio. Uma solução simples de keep-alive com TTL baseada nas estatísticas de comunicação de seus próprios contêineres será melhor.

Tenha em mente que muitos threads mantendo conexões TCP ativas causarão outra sobrecarga, portanto, certifique-se de usar o epoll.

O SDN de alguma forma atenua esses problemas ou adiciona ainda mais sobreposições e cabeçalhos extras aos pacotes?

Ele adiciona mais sobreposições, muitas são bloqueadas pelo fornecedor, mas há pelo menos umatubulação SDNsolução relacionada descrita abaixo, que é sobre o ambiente Docker.

Eu realmente preciso do processo descrito para me comunicar entre VM-1 e VM-2 ou existe uma compilação especial do Linux "menos segura, mais desempenho, uso por sua conta e risco"?

Não encontrei uma compilação Linux "especial" com comunidade suficiente para confiar e suporte a atualizações, mas problemas com pilha TCP Linux lenta não são novos e há muitas opções para ignorar o kernel.Cloudflare faz isso.

Deartigos que encontrei, a pilha TCP Linux lenta é bem conhecida e não há opção de instalar o servidor Linux e vencer: você precisa ajustar o filho de Torvald para resolver seu próprio problema desta ou daquela maneira todas as vezes.

Eu tenho que ficar com o Linux? Algum sistema mais rápido do tipo *BSD com suporte para docker?

Não foram encontradas evidências de que sistemas Windows, MacOS ou *BSD-like tivessem uma rede melhor do que o Linux mais recente com sua pilha TCP lenta com bypass de kernel aplicado.

Quais são as práticas recomendadas para mitigar esse gargalo e ajustar mais VMs com microsserviços no mesmo host como resultado?

Portanto, existem dois gargalos: guest linux e host linux.

Para host linux, caso não seja utilizado apenas para hospedagem de containers, existe uma estratégia de bypass de kernel com grande variedade de opções descritas emBlog da Cloudflaree"Por que usamos a pilha TCP do kernel Linux?" artigopara escrever sua própria pilha TCP focada em aplicativos.

Para Linux convidadoMacvlanpode ser usado para ignorar a Camada 3 e conectar o contêiner docker diretamente à NIC com seu próprio endereço MAC. Isso émuito melhor que ponte, porque atenua muitos gargalos de rede Linux de convidado e host, mas certifique-se de estar pronto para explodir a tabela de endereços MAC do roteador com mais cem ou mil registros - provavelmente você terá que segmentar sua rede.

Também conformeTecnologias de comutação virtual e apresentação de ponte Linuxexiste uma opção SR-IOV que é ainda melhor que o Macvlan. Isso édisponível para docker 1.9+ para adaptadores Ethernet Mellanoxcomo plugin, incluído como um modo emtubulação SDN, dedicouPlug-in SRIOV da Clear Containers- mais do que suficiente para começar a pesquisar soluções focadas em aplicativos.

Soluções como o Projeto Calico ajudam ou são mais de nível inferior?

É totalmente outro nível e não terá impacto significativo em comparação com SRIOV e Macvlan, mas ajudam a simplificar o gerenciamento de rede com quase nenhuma sobrecarga além da solução de bypass que você escolher.

E sim...

Monitore seu Docker de perto, pois ele pode fazer coisas inesperadas. Por exemplo, ele modprobes nf_nate xt_conntrack, onde não há razão para o Macvlan ativado, leva a gastos extras de CPU.