Комментарии 11
Эх, а я надеялся, что вы через MDK сделали :). Но Consul тоже хорошее решение, оно вроде как для таких вещей и предназначено, насколько я понимаю.
Мы одно время думали перевести часть конфигов на mdk, но в данном случае это не решило бы проблемы с залипающими серверами, потому что у mdk тоже 2 фазы (копирование нужных файлов и переключение симлинка). Нужна была именно pull модель, а тут хорошо подошел Consul. Все подводные камни и ограничения всплывали по мере того, как AutoConfig набирал популярность. При этом не все ограничения изначально были отражены в документации Consul, какие то вещи я находил уже в исходниках.
Инвертировать не проще? Пусть сервера сами ходят за конфигом в общее хранилище.
Сделать абсолютно надежное хранение файликов решаемо. Обновление упрощается до обновления файлика в хранилище. Там все в одном экземпляре и обновление тривиально.
Сделать абсолютно надежное хранение файликов решаемо. Обновление упрощается до обновления файлика в хранилище. Там все в одном экземпляре и обновление тривиально.
Так ведь схема с Consul это и есть инвертированный подход и в качестве абсолютно надежного хранилища выступает Consul (у нас насколько знаю 5 серверных нод консула)
Просто у Consul-а есть свои ограничения, которые постепенно всплывали в процессе эксплуатации и нужно было адаптироваться под них.
Основной же акцент в статье именно на событийную модель, когда данные читаются из хранилища только тогда когда они обновились, а не в цикле с заданной периодичностью (хотя и это тоже рабочий вариант и я об этом написал)
Ну и немаловажный аргумент: мы изначально хотели сделать новый транспорт используя существующую инфраструктуру. Если делать задачу из расчета, что можно засетапить отдельный кластер редиса/кассандры/т.п., то и подход к решению задачи был бы другим.
Просто у Consul-а есть свои ограничения, которые постепенно всплывали в процессе эксплуатации и нужно было адаптироваться под них.
Основной же акцент в статье именно на событийную модель, когда данные читаются из хранилища только тогда когда они обновились, а не в цикле с заданной периодичностью (хотя и это тоже рабочий вариант и я об этом написал)
Ну и немаловажный аргумент: мы изначально хотели сделать новый транспорт используя существующую инфраструктуру. Если делать задачу из расчета, что можно засетапить отдельный кластер редиса/кассандры/т.п., то и подход к решению задачи был бы другим.
А не было попыток заменить redis/cassandra на scylladb ?
вообще само по себе выглядит странным поднимать кластер C*/scylladb ради хранения конфигов. Но если без привязки к этому, то мы пока только присматриваемся к scylladb, но пока не больше этого. У нее есть свои на количество нод в кластере для open-source версии
приходите в https://t.me/ru_scylladb если будут вопросы
Вы все равно файлики раскладываете. А почему бы не ходить по сети за конфигами? Допустим в s3. Надежнее некуда. Куда их можно класть через любую удобную систему генерации.
Конфиг это не что-то требующее миллисекундных задержек. Все равно роллинг апдейты, пробы, блю грин, да и вообще и на прошлом конфиге сервис тоже неплохо работал. Рестарт требует хорошо если минут, а то и десятки минут могут выйти.
Читать постоянно надежнее. Это не то место где стоило бы экономить. Объемы смешные, читать файлик дешево. Чем проще тем лучше. Ловить баги в таких местах совсем не хочется.
Кластер в век менеджед БД стоит недорого. Тем более маленький и очень важный кластер. Ноды поменьше, штук побольше, l3 балансировка конечно. Ломаться нечему.
Конфиг это не что-то требующее миллисекундных задержек. Все равно роллинг апдейты, пробы, блю грин, да и вообще и на прошлом конфиге сервис тоже неплохо работал. Рестарт требует хорошо если минут, а то и десятки минут могут выйти.
Читать постоянно надежнее. Это не то место где стоило бы экономить. Объемы смешные, читать файлик дешево. Чем проще тем лучше. Ловить баги в таких местах совсем не хочется.
Кластер в век менеджед БД стоит недорого. Тем более маленький и очень важный кластер. Ноды поменьше, штук побольше, l3 балансировка конечно. Ломаться нечему.
Все верно говорите. Только вот заранее городить такую схему не хотелось, учитывая что изначально система делалась под конкретную задачу (выключалка хостов), и только со временем превратилась в систему общего назначения. На мой взгляд любая система должна развиваться итерационно. Учитывая, что сам транспорт скрыт от пользователя, мы можем прозрачно перейти на новый траспорт (например, тот же s3)
Основной посыл статье про сам подход — pull модель, вместо push модели (а не показать насколько хороша схема с Consul-ом)
конфиги бывают разные и для каждого типа есть свои требования к скорости доставки на сервера. AutoConfig используется там где важна именно скорость, а для остальных конфигов мы продолжаем использовать традиционный подход (mcode в нашем случае)
Основной посыл статье про сам подход — pull модель, вместо push модели (а не показать насколько хороша схема с Consul-ом)
Конфиг это не что-то требующее миллисекундных задержек. Все равно роллинг апдейты, пробы, блю грин, да и вообще и на прошлом конфиге сервис тоже неплохо работал. Рестарт требует хорошо если минут, а то и десятки минут могут выйти.
конфиги бывают разные и для каждого типа есть свои требования к скорости доставки на сервера. AutoConfig используется там где важна именно скорость, а для остальных конфигов мы продолжаем использовать традиционный подход (mcode в нашем случае)
А если под задачи доставки конфигов поднять GlusterFS и просто класть в него свежие файлы с конфигами на одной из нод, а GlusterFS сам позаботится о доставке их на остальные сервера. Если одна из нод тупит — остальным это не помешает. Сам пока не пробовал, не те масштабы на данный момент.
Не работал с этой файловой системой, поэтому не могу сказать насколько она бы зашла тут. Да и как я уже писал ранее наша задача была найти альтернативный транспорт используя существующую инфраструктуру. Учитывая, что консул агент уже был на всех серверах, то не было необходимости настраивать/поднимать что-то новое
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Run, config, run: как мы ускорили деплой конфигов в Badoo