Как организовать хранение конфигурации распределенного приложения?
Я размышляю над выбором решения для хранения динамической конфигурации для большого распределенного приложения.
Сейчас у нас самодельное решение которое rsync-ом раскидывает json файлы по нодам и watcher на каждой ноде обновляющий локальные базы и обновляющий конфигурацию процессов если это может быть сделано в рантайме.
Вводные примерно такие:
- 50+ физических нод
- 1000+ контейнеров (docker)
- 3000+ json файлов с конфигурацией
- 10M+ ключей в этих файлах
- 500Mb+ места на диске (json)
Хочется найти надежное KV решение со следующими свойствами:
- eventual consistency
- возможность подписки на изменение ключа или группы ключей по key prefix из приложения
- get ключа должен происходить локально (реплики будут на каждой физической ноде)
- заточен под максимально быстрое чтение (скорость репликации не критична)
Предполагаю посмотреть consul, etcd, zookeeper, couchDB. Если у кого-то есть соображения на эту тему и ценные советы, поделитесь пожалуйста :)
f0rk: ну кешировать не все, а выборочно, т.е что используются очень часто, остальное можно и медленно доставать.
Вообще 500Мб - это не конфиг, это уже база с данными (человек солько конфигов не напишет).
Как вариант, можете ещё попробовать хранить это в центральной БД, а при изменении посылать сообщение, что-б ноды выкачали данные себе, все равно вы их грузите в локальные БД.
lega: примерно так все и работает, часть конфигов грузится в рантайм, часть грузится в RocksDB на нодах. Проблема в том, что нам не нравится решение с брокером и необходимость синхронизировать ноды самописными скриптами. Ищем стабильное решение, которое позволит выбросить часть кода.
sim3x: distributed KV store - это не рокетсайенс конечно, но и не самое простое ПО. Чаще всего стреляет какой-нибудь race condition при деплое. А учитывая, что у нас еще и деплоймент самописный на баше, мест где все это барахло может поломаться достаточно много.
Могу только порекомендовать подсмотреть как это решили компании вроде Google и в проектах вроде Kubernetes, Terraform. Т.е. не обязательно полностью на них переходить, можно принципы подсмотреть.
Роман Мирр, не сказал бы, что нашлось решение, которое меня бы полностью устраивало. Ну и вводные поменялись за это время, теперь еще нужно реплицировать конфигурацию между несколькими датацентрами, и поддержка версионности конфигов добавилась. Сейчас под эту задачу у нас glusterfs + api на go и клиентская библиотека которая встраивается в приложения. Все еще бывают хитрые сценарии при которых в каком-то контейнере оказываются неактуальные версии, gluster иногда тупит... В общем, серебрянная пуля пока не найдена :)
Средний
Средний
Простой
