Одной из слабых сторон Docker является просто все. Среди этого недлинного списка особо хочется отметить управление сетью. Когда нужно запустить три разных версии руби (например для сборочных тестов в разных дистрибутивах), все хорошо - отработало, и отвалилось. В более сложных случаях (миграция, например), нужно что-то делать с адресами и портами.

Осознание этой необходимости породило ряд решений по управлению сетевым трафиком внутри гипервизора или между ними. Некоторые проектировались именно с прицелом на Docker, и с пониманием того, что целевая система отстает от Red Hat на несколько лет, а в ряде ключевых моментов, принципиально не поддерживает ряд т.н. "ненужных" фич (например, как в случае упорного игнорирования systemd, мол "ненужно"). Тем не менее, система, повторимся, оказалась популярна, и это давление снизу заставляет проектировать решения в т.ч. и на ее основе. А это накладывает отпечаток на используемые технологии, разрешая полагаться лишь на доступный функционал.

Когда представитель Docker выступал в столице, на YaC 2014, он предложил новый класс компонентов, "Ambassador". Это прокси-сервер (прокси-серверы), принимающий соединения, и обладающий информацией об актуальной топологии распределенной системы, обновляющейся с помощью одного из существующих механизмов service discovery. Если контейнер мигрируется или перезапускается на другой машине, то Ambassador перевосстановит связь согласно изменившейся топологии. Ни клиент, ни контейнер, предоставляющий сервис, изменений не увидят, и соединение не пострадает. Одно скажем сразу - благодаря этому архитектурному элементу, ряд анонимных коллег-экспертов получил шанс понять, что средства service discovery, даже тот же Avahi, это не "ненужно", а очень даже нужная вещь.

Помимо концепции Ambassador, появились и другие варианты организации сети. Ambassador плох хотя бы тем, что если мы нарисуем схему того, как по нему идут пакеты данных, то увидим несколько нырков из ядра в юзерспейс и обратно. Хорош же он тем, что следуя концепции "лучше сделать быстро, чем хорошо" он прост и в реализации, и в использовании. Сложность там в основном идет на решение задачи о поддержании актуальной информации о топологии, ну и как то надо решать задачу связности системы (А видит B, B видит С, А и C не соединены напрямую - как передать данные от A к C?).

Надо отдельно упомянуть грустную, но вполне обычную картину слабости горизонтальных связей в больших компаниях. Под укреплением внутрикорпоративных связей девушками, на которых обычно и взваливается непонятная им задача повышения внутрикорпоративного духа, чаще всего понимается некая оффлайновая добровольно-приказная активность (хорошо если с алкоголем, а то порой и без него - нам рассказывали как-то печальную историю корпоративного мероприятия в США, в вегетарианском ресторане), где народ быстро разбивается по привычным кучкам, не изменяя конфигурацию кластера. Чего тут говорить, если на мероприятии Google I/O 2013, разработчики AudioFlinger, аналога Pulseaudio для Android, рассказалли, как они с удивлением ознакомились с подсистемой cgroups, разработанной несколько лет назад их же коллегами, буквально за соседней дверью? Если уж в настолько новаторской компании есть такой неосвоенный ресурс для улучшения ситуации, то что говорить о других? Так вот, в ряде организаций есть нездоровый недостаток общения между программистами / девопсами и бухгалтерией и инженерами NOC. Это выливается в то, что там, где можно стукнуть парой команд на Cisco-свитче, программист, не зная о том, что (и не зная как) задачу решили лет 30 назад, упорно долбится с отбойным молотком Golang. Результат скорее всего будет далек от оптимального.

Вариант poor-man's SDN Weave, от одноименной команды из разработчиков RabbitMQ, выглядит интереснее, т.к. помимо всего прочего они обещают решить задачу сложной, многозвенной топологии. Но какой ценой? Как выяснилось, ценой падения пропускной способности до 6% номинальной, и повышения latency в 4 раза. До 6 процентов от номинала, и в 4 раза, Карл!

Можно ли лучше? Можно! Тут то как раз и стоило бы обратиться к опыту коллег из NOC. Инкапсуляция трафика, отказоустойчивость точек его приема и обновление таблиц маршрутизации, это даже на слух не очень современная задача, и в ядре уже давно включены протоколы и механизмы, позволяющие делать это оптимальнее, чем поднимать из ядра в юзерспейс, принимать решение, заталкивать обратно в ядро, передавая дальше, по цепочке. Как раз flannel, о котором мы периодически упоминаем, и который уже включен в Fedora, может работать в т.ч. и на уровне ядра. Каковы же его показатели в сравнении с Weave и нативной сетью?

Name	TCP BW (MB/s)	TCP Lat (µs)	BW %	Lat %
Native	116	91.8	100.00	100.00
Weave	6.91	372	5.96	405.23
Flannel UDP	23	164	19.83	178.65
Flannel VXLan	112	129	96.55	140.52

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

Особо отметим, что тема SDN потеряла тэг "дивная зверушка", и переходит в раздел "надо попробовать". Мы некоторое время назад видели, как один из первых энтузиастов SDN в России был поставлен в тупик вопросом "кому это надо?" на одном из столичных мероприятий. Теперь, что уже понятно, такого не будет. Как мы видим, даже управляя трафиком из userspace можно получить приличную производительность, и некоторое падение показателей выглядит вполне допустимым, учитывая то, какие возможности открываются.

Основным открытым вариантом SDN пока является OpenDaylight. Недавно про него хорошую обзорную статью написали в Mirantis. Проект уже довольно серьезный, что немного пугает проприетарных вендоров, некоторые из них (VMware и Juniper - опять VMware, да что это с ними такое?) снижают степень вовлеченности в проект. Зря, кстати.

Проблема с открытыми SDN-системами ровно одна - законченных продуктов не было. До сих пор не было. Первого апреля был интересный анонс - CloudRouter, специализированный Linux-дистрибутив для создания роутеров для облачных систем. Среди участников есть дружественная нам Cloudius Systems, уже известные вам разработчики OSv и Seastar, и компания нашего соотечественника Игоря Сысоева, Nginx. Проект базируется на Fedora. Учитывая, что параллельно вовсю разрабатывается открытое аппаратное решение для роутеров уровня дата-центра, не стоило бы проприетарным вендорам отворачиваться от OpenDaylight. А ведь открытые SDN уже рассматриваются, как кандидаты для модернизации беспроводных сетей.