VM-1 on host-1 <[cable]> network router <[cable]> host-2 with VM-2
Если я правильно понимаю, в случае передачи файла из приложения на ВМ-1 в то же приложение на ВМ-2 данные пройдут следующий путь:
Предполагая, что файл будет большим, шаги, связанные с seccomp / apparmor, маршрутизацией и брандмауэром, будут кэшироваться / опускаться для уже открытого и передаваемого файла.
Для каждого вызова и логической обработки потребуется несколько сотен тактов ЦП, а описанное превышение стека приведет к значительной нагрузке на ЦП и сыграет роль в задержке.
Будет ли предварительно открытый коммуникационный сокет между виртуальными машинами пропускать какие-либо шаги из описанного списка?
Предварительно открытый сокет между виртуальными машинами / контейнерами поможет из-за накладных расходов на рукопожатие TCP; и даже больше, если есть TLS.
Хотя принято считать, что накладные расходы на рукопожатие ничтожно малы, но когда мы говорим о частом общении, они начинают играть важную роль.
Наличие граничного состояния M x N открытых соединений в случае сети ячеистых контейнеров не очень разумно. Простое решение для поддержания активности с TTL на основе вашей собственной статистики связи контейнеров будет лучше.
Имейте в виду, что слишком много потоков, поддерживающих соединения TCP, вызовут дополнительные накладные расходы, поэтому убедитесь, что вы используете epoll.
SDN как-то смягчает такие проблемы или добавляет в пакеты еще больше наложений и дополнительных заголовков?
Он добавляет больше оверлеев, многие из них привязаны к поставщику, но есть как минимум один трубопровод SDN связанное решение, описанное ниже, которое касается среды Docker.
Действительно ли мне нужен описанный процесс для связи между VM-1 и VM-2, или существует специальная сборка linux «менее безопасная-большая-производительность-использование-на-ваш-собственный-риск»?
Я не нашел "специальной" сборки Linux с достаточно доверенным сообществом и поддержкой обновлений, но проблемы с медленным стеком TCP Linux не новы, и есть много вариантов обхода ядра. Cloudflare делает это.
Из статьи, которые я нашел, медленный TCP-стек linux хорошо известен, и нет возможности подключиться к Linux-серверу и победить: вам нужно точно настроить это дитя Торвальда, чтобы каждый раз решать вашу проблему тем или иным способом.
Обязательно ли мне вообще использовать linux? Какие-нибудь более быстрые * BSD-подобные системы с поддержкой докеров?
Не обнаружено никаких доказательств того, что Windows, MacOS или * BSD-подобная система имела лучшую сеть, чем последняя версия Linux с ее медленным стеком TCP с примененным обходом ядра.
Каковы оптимальные методы устранения этого узкого места, чтобы в результате разместить больше виртуальных машин с микросервисами на одном хосте?
Итак, есть два узких места: гостевой Linux и хост-Linux.
Для host linux, если он используется не только для размещения контейнеров, существует стратегия обхода ядра с большим разнообразием опций из описанных в Блог Cloudflare и «Почему мы используем TCP-стек ядра Linux?» статья для написания собственного стека TCP, ориентированного на приложения.
Для гостевого linux Macvlan может использоваться для обхода уровня 3 и подключения контейнера докеров напрямую к сетевой карте с собственным MAC-адресом. это намного лучше, чем мост, поскольку он устраняет множество узких мест как в гостевой, так и в хост-сети Linux, но убедитесь, что вы готовы взорвать таблицу MAC-адресов вашего маршрутизатора с помощью еще сотен или тысяч записей - скорее всего, вам придется сегментировать свою сеть.
Также согласно Презентация технологий виртуальной коммутации и моста Linux есть вариант SR-IOV, который даже лучше, чем Macvlan. это доступно для докеров 1.9+ для Ethernet-адаптеров Mellanox как плагин, включенный как режим в трубопровод SDN, посвятил Плагин SRIOV от Clear Containers - более чем достаточно, чтобы начать поиск решения, ориентированного на приложения.
Помогают ли такие решения, как Project Calico, или это более низкий уровень?
Это совершенно другой уровень, и он не будет иметь существенного влияния по сравнению с SRIOV и Macvlan, но они помогают упростить управление сетью практически без накладных расходов на решение обхода, которое вы выберете.
И да...
Внимательно следите за своим Docker, так как он может делать неожиданные вещи. Например это modprobes nf_nat и xt_conntrack, если нет причин для включения Macvlan, это приводит к дополнительным расходам CPU.