Назад | Перейти на главную страницу

Высокий объем сетевого ввода-вывода между диспетчерами Docker Swarm

Сетевой трафик

Мы запускаем Docker Swarm с 3-мя управляющими узлами и 16-ю рабочими узлами. Сетевой ввод-вывод между двумя из трех управляющих узлов очень высок. Чтобы проиллюстрировать это, вот вывод из iftop для трех управляющих узлов:

vm71 (10.0.0.131)

vm71                 => 10.0.0.130            39.3Mb  47.5Mb  49.3Mb
                     <=                        802Kb  1.03Mb  1.07Mb

vm70 (10.0.0.130)

vm70                 => 10.0.0.131             798Kb  1.00Mb  1.00Mb
                     <=                       40.9Mb  44.8Mb  44.8Mb

vm75 (10.0.0.135)

vm75                 => 10.0.0.131            9.50Kb  10.1Kb  9.51Kb
                     <=                       7.83Kb  8.08Kb  7.56Kb

Как вы можете видеть выше, трафик между vm70 и vm71 примерно в 4000 раз больше, чем трафик между vm75 и двумя другими менеджерами. У нас есть правила, запрещающие запускать контейнеры ни в одном менеджере роя. Это было подтверждено запуском docker stats по каждому из них.

Сеть по процессам

Следующий очевидный вопрос заключался в том, какие процессы генерируют этот сетевой ввод-вывод. Выход netstat -tup ниже. Я показываю только строку, относящуюся к соответствующим портам из iftop.

tcp6       0     46 vm71:2377               10.0.0.130:39316        ESTABLISHED 791/dockerd

Обратите внимание, что это трафик tcp6.

Мы в тупике. Почему мы наблюдаем такой большой трафик между этими узлами-менеджерами? Если мы понижаем, а затем повышаем роль управляющих узлов, трафик на некоторое время очищается. Но со временем он снова увеличивается. Что могло быть причиной этого?

Я бы посоветовал записывать сетевые запросы с помощью tcpdump, вам понадобится инструмент / скрипт мониторинга, чтобы следить за тем, когда придет время, и выполнить его. Частой причиной является корреляция внезапного увеличения памяти, если у главного менеджера происходит внезапное увеличение использования памяти, это объяснимо. Глядя на ваш вывод, это выглядит как запрос, который попадает в менеджер 2 при балансировке нагрузки и передается лидеру.