Эта статья является статьей, подготовленной командой STE, работающей над системой байт-битинга.

Непрерывное обновление (далее именуемое «горячее обновление») сервисов системного уровня очень важно для быстрой итеративной разработки сервисов. К виртуальному коммутатору (vSwitch) как к входу в виртуальную сеть предъявляются изменяющиеся требования, но частое обновление и отключение сети будут влиять на службы, работающие на виртуальной машине. Кроме того, обычно на каждом хосте имеется только один виртуальный коммутатор, и в архитектуре непросто быть активным и резервным. Таким образом, технология горячего обновления имеет решающее значение для быстрой итерации vSwitch.

В этой статье рассказывается о нашем опыте использования технологии горячего обновления Open vSwtich на основе DPDK (далее именуемой ovs-dpdk), и мы надеемся обсудить ее с коллегами по отрасли.

статус кво

Существующее решение «горячего обновления» Open vSwitch (далее ovs) в основном реализовано для ovs-kernel. В ovs-kernel процесс vswitchd — это медленный путь, а модуль ядра — быстрый путь. При обновлении процесса vswitchd нет необходимости заменять модуль ядра, так что большая часть трафика перенаправляется через кеш потока в ядре, чтобы уменьшить помехи в сети. Обновление модуля ядра может иметь более длительный риск отключения. Для получения дополнительной информации об этом фрагменте перейдите по ссылке: http://docs.openvswitch.org/en/latest/intro/install/general/?highlight=hot%20upgrade#hot-upgrading
В ovs-dpdk как быстрый путь, так и медленный путь интегрированы в процесс vswitchd.Если просто перезапустить vswtichd, из-за инициализации DPDK (в основном инициализация большой страницы, 1G большая страница занимает около 600 мс), инициализация сетевой карты ( измеренная инициализация драйвера Mellanox CX5 занимает почти 1 с) отнимает много времени, поэтому будет отключение второго уровня.
Чтобы добиться быстрой итеративной разработки и уменьшить помехи для бизнеса, вызванные отключением сети, вызванным обновлением, необходимо разработать функцию горячего обновления ovs-dpdk.

Решения и компромиссы

Существует множество способов реализации горячих обновлений:

Обновление подключаемого модуля (называемое «горячей заплаткой»): Превратите логику обработки основного пакета в библиотеку с динамической компоновкой и избегайте трудоемкой инициализации dpdk и инициализации сетевой карты с помощью горячей загрузки подключаемых модулей. (режим master-slave DPDK также можно рассматривать как вариант этого подхода)
- Преимущества: время прерывания сети при регулярных обновлениях очень мало и может быть достигнуто за наносекунды.
- Недостатки: обновление платформы и обновление подключаемого модуля становятся двумя видами обновлений.Должны быть API-интерфейсы и общие структуры данных для вызова друг друга между платформой и подключаемым модулем.Разработчикам необходимо поддерживать согласованность ABI (бинарного интерфейса приложения) между Фреймворк и плагин. Простой пример: структура таблицы потоков может быть общей для фреймворка и плагина.Если обновление изменяет структуру таблицы потоков, фреймворк также необходимо обновить, иначе это вызовет ошибку памяти из-за несогласованности. .
Двойное обновление процесса (образ горячий): избыточность избыточна по аппаратным ресурсам, пусть новый и старый OVS сосуществуют при обновлении, старый OVS продолжает пересылаться, чтобы трафик не прерывался, новый OVS инициализируется, после инициализации взять на себя трафик.
- Преимущества: старый и новый ovs — это два процесса, которым не нужно быть совместимыми, а нужно только соблюдать протокол связи для синхронизации информации между старым и новым процессами.
- Недостатки: требуется избыточность ресурсов, требуется избыточность сетевой карты и памяти для удовлетворения требований по обновлению как старых, так и новых ов (2x RAM плюс 2x VF),Время отключения будет больше.

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

Принцип работы горячего обновления OVS не сложен, то есть при реализации нужно учитывать множество тривиальных инженерных тонкостей. В основном за счет точного контроля кода, чтобы сократить время отключения обновления.

двухступенчатая конструкция

Весь процесс горячего обновления мы делим на два этапа (двухэтапные), и конструкция здесь несколько заимствована из процесса горячей миграции виртуальных машин. На первом этапе служба переадресации сети не останавливается, а в случае сбоя обновления вся система может быть автоматически откатана. Только при достижении второго этапа сеть будет отключена. На втором этапе, в случае возникновения проблемы, сервис можно перезапустить только отключив сеть, и система уже не имеет возможности откатиться. В плане реализации мы открыли сервис JSON-RPC для ovs для горячего обновления. Когда процесс ovs запускается, он автоматически определяет, существует ли старый процесс. Если он существует, он будет активно инициировать запрос на горячее обновление через JSON-RPC. Процесс ovs, получивший запрос на горячее обновление, запускает двухэтапное обновление:

Первый этап:
- Старый процесс ovs освобождает различные эксклюзивные ресурсы: такие как блокировка базы данных ovsdb, переименование файла pid, путь к серверу unixctl и другие ресурсы. В это время старый ovs не может получить последнюю конфигурацию через ovsdb, но поток PMD все еще работает, и переадресация не остановлена.
- После высвобождения ресурсов новые и старые процессы начинают синхронизировать состояние, в основном это мегапотоковая синхронизация некоторых OVS, fd-синхронизация сетевых ответвителей и т. д.
- При этом старый овс будет бекапить все правила OpenFlow.
- После того, как все это будет сделано, старый процесс вернет ответ на запрос JSON-RPC. Если с вышеуказанным процессом нет проблем, он вернет успех, и обновление будет продолжено. В противном случае возвращается ошибка, новый процесс завершится и обновление завершится неудачно. При этом будет произведен откат старого процесса, а ранее освобожденные ресурсы будут повторно применены и возвращены в нормальное рабочее состояние.
- Новый процесс получает различную информацию о состоянии и начинает нормально инициализироваться. Включая память инициализации DPDK, ovs получает различные конфигурации, такие как мосты и сетевые карты, от ovsdb для запуска инициализации и т. д. Во время этого процесса, если возникает исключение и происходит сбой нового процесса, соединение сокета unix JSON-RPC будет прервано. Как только старый процесс обнаруживает, что соединение прервано, он считает, что новый процесс не смог инициализироваться, и автоматически выполняет откат.
- Новый процесс загружает ранее сохраненные правила OpenFlow. Изменения правил OpenFlow между ними будут записаны и доставлены локальным контроллером.
- Новый процесс инициирует запрос JSON-RPC второго этапа.
вторая стадия:
- Старый процесс завершается.
- Новый процесс запускает поток pmd для начала пересылки.
- Обновление завершено.

На следующем рисунке кратко показана схема последовательности обновления:

Из схемы последовательности обновления видно, что на первом этапе горячего обновления новый процесс ovs выполнил наиболее трудоемкую работу по инициализации, в то время как старый процесс ovs выполнял переадресацию, а сеть не отключалась. Отключение происходит только между выходом старых ов на втором этапе и запуском потока PMD новыми ов.

В процессе обновления мы воспользовались особенностью сетевой карты MLNX: одно и то же устройство сетевой карты может быть открыто двумя независимыми процессами dpdk одновременно, и трафик будет зеркалироваться обоим процессам одновременно. Если используются другие сетевые адаптеры, того же эффекта можно добиться, объединив несколько виртуальных функций с переключением правил таблицы потоков. Здесь нет дальнейшего повествования.

Оценка времени простоя

Мы изучили время отключения серверной части двух виртуальных сетевых карт:

Используя представитель + VF,
Используйте метод vhost-user + virtio.

Методы испытаний

Две виртуальные машины на двух хостах пингуют друг друга, используйтеping -i 0.01. Интервал между двумя пингами составляет 10 мс.И наконец, статистика находится в процессе обновления.Количество пинг-пакетов, которые не возвращаются, указывает на время отключения сети во время обновления.iperf -i 1Проверьте, не влияет ли это на пропускную способность TCP.

представитель + режим VF

проверка связи

Результаты 10 испытаний следующие:

1524 packets transmitted, 1524 received, +36 duplicates, 0% packet loss, time 16747ms
623 packets transmitted, 622 received, +29 duplicates, 0% packet loss, time 6830ms
662 packets transmitted, 662 received, +30 duplicates, 0% packet loss, time 7263ms
725 packets transmitted, 724 received, +28 duplicates, 0% packet loss, time 7955ms
636 packets transmitted, 635 received, +28 duplicates, 0% packet loss, time 6973ms
752 packets transmitted, 750 received, +27 duplicates, 0% packet loss, time 8251ms
961 packets transmitted, 961 received, +31 duplicates, 0% packet loss, time 10551ms
737 packets transmitted, 737 received, +29 duplicates, 0% packet loss, time 8084ms
869 packets transmitted, 869 received, +27 duplicates, 0% packet loss, time 9543ms
841 packets transmitted, 840 received, +28 duplicates, 0% packet loss, time 9228ms

Обнаружено, что происходит не более 1 потери пакета, что указывает на то, что время отключения составляет до 10 мс. Но нашел много дубликатов пакетов.Это связано с тем, что сетевая карта mlnx имеет баг в режиме switchdev: при наличии двойных процессов трафик должен зеркалироваться на другой процесс.В итоге сетевая карта mlnx позволяет одному процессу получить два повторяющихся пакета, а другой процесс не имеет пакета. В настоящее время mlnx подтвердил эту проблему.

иперф-тест

В период обновления было замечено, что скорость 1 с уменьшилась вдвое, с полной скорости 22 Гбит/с до 13 Гбит/с, что, по оценкам, связано с повторной передачей пакетов и отключением обновления, вызванным ошибкой MLNX. Он быстро вернулся к 22 Гбит / с через 1 с.

vhost-пользователь + режим virtio

проверка связи

Время отключения составляет около 70~80 мс. В результате анализа журнала было обнаружено, что старый процесс повторно подключается к виртуальному хосту после выхода. Продолжая оптимизировать это, время отключения сети будет еще больше сокращено. Здесь он не расширен.

иперф-тест

Подобно результату метода VF, пропускная способность в определенной степени уменьшится и восстановится сразу после завершения обновления.

Связанный код

Мы используем ovs-dpdk с открытым исходным кодом. Если вас интересует конкретная реализация горячего обновления, вы можете обратиться к файлу ndu.c в каталоге vswitchd. В каталоге утилит мы предоставляем инструмент ovs-nductl для тестирования сервисов JSON-RPC горячего обновления, который может имитировать горячие обновления. Сценарий обновления ссылается на файл ovs-hotupgrade.sh в каталоге утилит. Наша ссылка с открытым исходным кодом: https://github.com/bytedance/ovs-dpdk

поделиться больше

Техническая практика eBPF: высокопроизводительный ACL

Как автоматизированное эластичное масштабирование поддерживает распределенные пики и совместные расположения ядра на миллионном уровне | Обзор архитектурного салона

Эволюция системы хранения распределенных таблиц ByteDance

Команда STE отдела ByteDance Systems

Команда STE системного отдела ByteDance работала над созданием ядра операционной системы и виртуализации, созданием и оптимизацией производительности системного базового программного обеспечения и базовых библиотек, созданием стабильности и надежности гипермасштабируемых центров обработки данных, а также совместной разработкой нового аппаратного и программного обеспечения. Были реализованы научно-исследовательские и инженерные разработки в технической области, и он имеет комплексные базовые возможности разработки программного обеспечения для сопровождения бизнеса байтов верхнего уровня. В то же время команда активно следит за техническими тенденциями сообщества и использует открытый исходный код и стандарты. Приглашаем присоединиться к нам новых людей с высокими идеалами.Если вы заинтересованы, отправьте свое резюме на sysrecruitment@bytedance.com.

Добро пожаловать в техническую команду ByteDance