![Сетевое взаимодействие виртуальных машин/Docker с несколькими хостами МЕДЛЕННОЕ. Есть ли какие-либо рекомендации?](https://rvso.com/image/717757/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B5%20%D0%B2%D0%B7%D0%B0%D0%B8%D0%BC%D0%BE%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D0%B2%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D1%85%20%D0%BC%D0%B0%D1%88%D0%B8%D0%BD%2FDocker%20%D1%81%20%D0%BD%D0%B5%D1%81%D0%BA%D0%BE%D0%BB%D1%8C%D0%BA%D0%B8%D0%BC%D0%B8%20%D1%85%D0%BE%D1%81%D1%82%D0%B0%D0%BC%D0%B8%20%D0%9C%D0%95%D0%94%D0%9B%D0%95%D0%9D%D0%9D%D0%9E%D0%95.%20%D0%95%D1%81%D1%82%D1%8C%20%D0%BB%D0%B8%20%D0%BA%D0%B0%D0%BA%D0%B8%D0%B5-%D0%BB%D0%B8%D0%B1%D0%BE%20%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D0%B0%D1%86%D0%B8%D0%B8%3F.png)
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-пакета, у нас возникают проблемы.
Каждый вызов и обработка логики потребуют нескольких сотен тиков ЦП, а описанный перестек приведет к значительной нагрузке на ЦП и сыграет свою роль в задержке.
- СогласноТестирование производительности сети Docker с несколькими хостами [август 2016 г.]это как минимум -13% производительности.
- ВЗадержка сетевого ввода-вывода в VMware vSphere® 5«Мы обнаружили, что в бездействующей системе задержка приема-передачи на ВМ составляет около 15–20 микросекунд. Это число увеличивается по мере увеличения конкуренции за ресурсы в vSphere, что и ожидалось. Джиттер был очень низким, пока система не была перегружена».
- Кроме того, исправление Meltdown и Spectre от Intel приведет к еще большему падению производительности.
Вопросы
- Будет ли заранее открытый коммуникационный сокет между виртуальными машинами пропускать какие-либо шаги в описанном списке?
- ДелаетСДНкак-то смягчает такие проблемы или добавляет еще больше наложений и дополнительных заголовков к пакетам?
- Действительно ли мне нужен описанный процесс для связи между VM-1 и VM-2 или существует специальная сборка Linux «менее безопасная, но более производительная, используемая на свой страх и риск»?
- Мне вообще обязательно использовать Linux? Есть ли более быстрые *BSD-подобные системы с поддержкой Docker?
- Каковы наилучшие методы устранения этого узкого места, чтобы в результате разместить больше виртуальных машин с микросервисами на одном хосте?
- Есть ли решения, какПроект Каликопомощь или это больше касается более низкого уровня?
решение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, это приводит к дополнительным тратам тиков ЦП.