Сетевое взаимодействие виртуальных машин/Docker с несколькими хостами МЕДЛЕННОЕ. Есть ли какие-либо рекомендации?

Сетевое взаимодействие виртуальных машин/Docker с несколькими хостами МЕДЛЕННОЕ. Есть ли какие-либо рекомендации?
VM-1 on host-1 <[cable]> network router <[cable]> host-2 with VM-2

Если я правильно понимаю, в случае передачи файла из приложения на ВМ-1 в то же приложение на ВМ-2 данные пройдут следующий путь:

  • Файл приложения VM-1 считан в буфер памяти
    • вызовы, связанные с языком программирования
    • вызовы уровня операционной системы
    • логика seccomp/apparmor
    • Логика разрешений файловой системы
    • обработка файлов операционной системы и буфер
  • Данные приложения VM-1 отправляются в буфер сетевого сокета
    • вызовы операционной системы
    • логика seccomp/apparmor
  • Сетевой стек операционной системы VM-1
    • таблицы маршрутизации
    • логика брандмауэра
  • Стек виртуальной сети гипервизора Host-1
    • виртуальный коммутатор
    • таблицы маршрутизации
  • Сетевой стек операционной системы Host-1
    • таблицы маршрутизации
    • логика брандмауэра
  • Буфер физической сетевой карты Host-1
  • Сетевой маршрутизатор
  • почти тот же стек вещей, отраженный здесь для VM-2 на хосте-2

Если предположить, что файл будет большим, то шаги, связанные с seccomp/apparmor, маршрутизацией и брандмауэром, будут кэшированы/пропущены для уже открытого и передаваемого файла.

Но в случае частого обмена данными между виртуальными машинами с сообщениями, достаточно маленькими, чтобы уместиться в 1-2 TCP-пакета, у нас возникают проблемы.

Каждый вызов и обработка логики потребуют нескольких сотен тиков ЦП, а описанный перестек приведет к значительной нагрузке на ЦП и сыграет свою роль в задержке.

Вопросы

  1. Будет ли заранее открытый коммуникационный сокет между виртуальными машинами пропускать какие-либо шаги в описанном списке?
  2. ДелаетСДНкак-то смягчает такие проблемы или добавляет еще больше наложений и дополнительных заголовков к пакетам?
  3. Действительно ли мне нужен описанный процесс для связи между VM-1 и VM-2 или существует специальная сборка Linux «менее безопасная, но более производительная, используемая на свой страх и риск»?
  4. Мне вообще обязательно использовать Linux? Есть ли более быстрые *BSD-подобные системы с поддержкой Docker?
  5. Каковы наилучшие методы устранения этого узкого места, чтобы в результате разместить больше виртуальных машин с микросервисами на одном хосте?
  6. Есть ли решения, какПроект Каликопомощь или это больше касается более низкого уровня?

решение1

Будет ли заранее открытый коммуникационный сокет между виртуальными машинами пропускать какие-либо шаги в описанном списке?

Предварительно открытый сокет между виртуальными машинами/контейнерами может оказаться полезным из-за накладных расходов на TCP-рукопожатие; и даже больше, если используется TLS.

Хотя принято считать, что накладные расходы на рукопожатие пренебрежимо малы, но когда мы говорим о частом общении, они начинают играть существенную роль.

Наличие граничного состояния M x N открытых соединений в случае сети контейнеров типа «сетка» не очень разумно. Простое решение keep-alive с TTL, основанное на статистике коммуникаций ваших собственных контейнеров, будет лучше.

Помните, что слишком большое количество потоков, поддерживающих TCP-соединения активными, приведет к дополнительным накладным расходам, поэтому обязательно используйте epoll.

Смягчает ли каким-либо образом SDN подобные проблемы или добавляет еще больше наложений и дополнительных заголовков к пакетам?

Он добавляет больше оверлеев, многие из которых привязаны к поставщику, но есть по крайней мере одинтрубопровод SDNНиже описано соответствующее решение, посвященное среде Docker.

Действительно ли мне нужен описанный процесс для связи между VM-1 и VM-2 или существует специальная сборка Linux «менее безопасная, но более производительная, используемая на свой страх и риск»?

Я не нашел «специальной» сборки Linux с поддержкой сообщества enought-to-trust и обновлений, но проблемы с медленным стеком TCP Linux не новы, и существует множество вариантов обхода ядра.Cloudflare делает это.

Отстатьи, которые я нашелМедленный стек TCP в Linux хорошо известен, и нет возможности установить сервер Linux и победить: вам придется тонко настраивать это детище Торвальда, чтобы каждый раз решать свою собственную проблему тем или иным способом.

Мне вообще обязательно использовать Linux? Есть ли более быстрые *BSD-подобные системы с поддержкой Docker?

Не обнаружено никаких доказательств того, что Windows, MacOS или *BSD-подобные системы имели лучшую сетевую производительность, чем новейший Linux с его медленным стеком TCP с применением обхода ядра.

Каковы наилучшие методы устранения этого узкого места, чтобы в результате разместить больше виртуальных машин с микросервисами на одном хосте?

Итак, есть два узких места: гостевой Linux и хостовый Linux.

Для хост-системы Linux, в случае если она используется не только для хостинга контейнеров, существует стратегия обхода ядра с большим количеством опций, описанных вБлог CloudflareиСтатья «Почему мы используем стек TCP ядра Linux?»к написанию собственного стека TCP, ориентированного на приложения.

Для гостевого LinuxМаквланможет быть использован для обхода уровня 3 и подключения контейнера Docker напрямую к сетевой карте с его собственным MAC-адресом. Этогораздо лучше, чем мост, поскольку он устраняет множество узких мест как гостевых, так и хостовых сетей Linux, но убедитесь, что вы готовы расширить таблицу MAC-адресов маршрутизатора еще сотней или тысячей записей — скорее всего, вам придется сегментировать свою сеть.

Также согласноТехнологии виртуальной коммутации и презентация Linux Bridgeесть вариант SR-IOV, который даже лучше, чем Macvlan. Этодоступно для docker 1.9+ для адаптеров Mellanox Ethernetкак плагин, включенный как режим втрубопровод SDN, посвятилПлагин SRIOV от Clear Containers- более чем достаточно, чтобы начать искать решение, ориентированное на конкретное приложение.

Помогают ли такие решения, как Project Calico, или они больше касаются более низкого уровня?

Это совершенно другой уровень и он не окажет существенного влияния по сравнению с SRIOV и Macvlan, но он помогает упростить управление сетью практически без накладных расходов в дополнение к выбранному вами обходному решению.

И да...

Внимательно следите за своим Docker, так как он может делать неожиданные вещи. Например, он modprobes nf_natи xt_conntrack, где нет причин при включенном Macvlan, это приводит к дополнительным тратам тиков ЦП.

Связанный контент