Использование haproxy/iptables + etcd + confd для автоматического...
TRANSCRIPT
Использование haproxy/iptables + etcd + confd для автоматического service-discovering’а в переменчивых сетях
Сергей Пузырёв
Service-oriented architecture
1. Приложение состоит из множества слабо связанных сервисов, которые общаются друг с другом с использованием четко определённого API.
2. Сервисы ничего не знают о клиентах, их задача – оказывать сервис.
3. Клиента не волнует, каким образом работает сервис.
4. Сервисы используют другие сервисы.
Service-oriented architecture
Что такое сервис?
1. У сервиса есть интерфейс – API.2. Сервис имеет точку входа (endpoint) – обычно пара
IP:port.3. Сервис может пользоваться другими сервисами. В
этом случае он должен быть правильно сконфигурирован.
Service-oriented architecture
Пример сервиса - memcached:1. API: стандартный протокол memcached.2. Endpoint: например, 10.0.0.7:11211.3. Сервисы, которыми пользуется memcached,
отсутствуют.
Client Memcached
Service-oriented architecture
Пример сервиса - mcrouter: (github.com/facebook/mcrouter)1. API: стандартный протокол memcached.2. Endpoint: например, 10.0.0.6:11211.3. Mcrouter пользуется двумя сервис memcached.
Endpoint сервиса memcached забит в конфиг mcrouter.
Client Mcrouter
MemcachedMemcached
Service-oriented architecture
Несложное PHP-приложение:
Php-fpm
Memcached
MySQLslave
Nginx
Php-fpm
MySQLmaster Memcached
Mcrouter
Staticstorage
16 отношений client<->service
Service-oriented architecture
Сложное приложение (мопед не мой):
Как связывать сервисы друг с другом?Дешево и сердито: хардкод endpoint’ов в конфиги.
Плюсы:1. Очень быстрый старт.2. Просто, нужен только vim.3. Ничего не ломается само.
Минусы:4. Не работает в большом проекте.5. Требуется вручную поддерживать документацию.6. Сложно вносить массовые изменения, подключать
новые инстансы сервисов, мигрировать сервисы.
Как связывать сервисы друг с другом?Дешево и сердито: DNS + хардкод.
Плюсы:1. Лишь немного сложнее хардкода IP-адресов.2. Почти так же просто, нужен только vim и DNS-
сервер.3. Проще вносить массовые изменения.
Минусы:4. По прежнему не работает в большом проекте.5. Так же требуется вручную поддерживать
документацию.6. Сложно подключать новые инстансы сервисов.7. Асинхронность внесения изменений, лаги.8. Софт часто не перерезолвливает записи.
Появляются сотни сервисов. Потом тысячи.
Как связывать сервисы друг с другом?Системы управления конфигурацией (Puppet, SaltStack, etc.).
Плюсы:1. При правильной организации проще вносить
изменения.2. Один инструмент для всего.
Минусы:3. Медленно!4. При неправильной организации вносить изменения
становится очень сложно.5. Неактуальная документация продолжает
существовать.
Как связывать сервисы друг с другом?Пусть роботы всё делают за нас!Системы service-discovering’а.
Service-discovering
Что это такое?
Система обнаружения сервисов (СОС) – специальный сервис, в котором другие сервисы могут делать две вещи:1. Регистрироваться (записывать свой endpoint).2. Находить другие сервисы (читать предварительно
зарегистрированные endpoint’ы других сервисов).
Часто системы обнаружения сервисов предоставляют также сервис распределённых блокировок.
Примеры:Zookeeper, etcd, consul, SkyDNS, etc.
Service-discovering
Etcd: что это такое и как с этим жить?github.com/coreos/etcd
Etcd - высоконадёжное распределенное хранилище параметров конфигурации, задаваемых в форме key->value.
Etcd также можно использовать как систему распределенных блокировок.
Service-discovering
Confd: что это такое и зачем оно нужно?www.confd.io
Confd - легковесная система конфигурации, специально созданная для отслеживания данных в etcd, шаблонизирования конфигов и перезапуска приложений при изменении данных в etcd.
NB: нередко вместо Confd можно использовать скрипт на bash, наподобие while true ; do smth ; done .
Service-discovering
Etcd
Client
Confd
Announcer
Mcrouter
Announcer
Memcached
Announcer
Memcached
Confd
Как связывать сервисы друг с другом?Системы service-discovering’а:
Плюсы:1. Очень быстрое внесение изменений.2. Не требуется документировать, что где работает и
как должно быть сконфигурировано.
Минусы:3. Сложно.4. Страшно – “а вдруг развалится?”.5. Внешние сущности в виде confd и announcer’а. В
идеале нужно обучать сервисы общаться с etcd напрямую.
Как связывать сервисы друг с другом?Что мы хотели?
1. Приложения не должны постоянно перезапускаться (до свидания, confd).
2. Мы не хотели привязывать тонны legacy-кода наших приложений к СОС.
3. Облегчить миграцию сервисов на новые endpoint’ы, не требующую переконфигурации тысяч других сервисов (ради чего и затевалось).
4. Приложение не должно деградировать в условиях сломавшейся СОС, выключившегося датацентра, тормозящей сети и т.п. более, чем деградировало бы без СОС.
Как связывать сервисы друг с другом?
Как связывать сервисы друг с другом?Трудно связать сервисы друг с другом?
Давайте инкапсулируем связь между сервисами в отдельный сервис!
Etcd + iptables/HAproxy + confdБыло так:
Etcd
Client
Confd
Announcer
Mcrouter
Announcer
Memcached
Announcer
Memcached
Confd
Etcd + iptables/HAproxy + confdА стало так:
Etcd
Client
Confd
Announcer
Mcrouter
Announcer
Memcached
Announcer
Memcached
Confd
HAProxy
Etcd + iptables/HAproxy + confdПочему так?
1. Некоторые приложения трудно перезапускать.2. Постоянно писать шаблоны к разному софту
утомляет.3. Бесплатная статистика от HAproxy.4. В простых кейсах получаем еще и бесплатную
балансировку.
Что плохо?
1. HAproxy не умеет в UDP.
Etcd + iptables/HAproxy + confdА iptables DNAT умеет:
Confd Confd
Etcd
iptablesDNAT
iptablesDNAT
Client statsdCarbon
(Graphite)
Результат
1. Миграции сервисов становятся безболезненными.2. Добавление новых инстансов сервисов в простых
кейсах (когда можно просто добавить инстанс в пул HAProxy) происходит очень легко.
3. Нельзя забыть что-то переконфигурировать.4. Новых конфигов требуют только новые типы
сервисов.
