я не нашел ни одного против, в тот момент, когда принимали решение перевода на «запуск по крону». Расскажите где именно потеря гибкости? (отсутствие puppetrun? — так есть же mcollective; или все же что-то еще?)
Мейнтенансы где именно? на том оборудовании, что выступает в качестве мастера?
Если все расписывать — еще на статью вытянем ;)
Основные задачи обычно связаны с: получением актуального списка нод, по заданным критериям; выполнение определенных команд; форсирование запуска паппет клиента.
Если вы конкретизируете вопрос — вероятно, отвечу ближе.
Вы о каких таймаутах? ;)
Storeconfig сам по себе и завязки на него в манифестах используете?
Кинуть сообщение в queue также быстрее, чем сразу в бд, если речь идет об удаленном географически дц(трансатлантика)
«в среднем 10, если ничего не нужно делать» — если ничего не нужно, то и паппет не нужен ;)
Если в вашем случае такое использование устраивает — оно ж прекрасно. Мы попробовали — не устроило — пошли дальше.
Всего у вас сколько хостов? Какой опционал из перечисленного мной вы используете у себя? Какое время обработки каталога на конечной машине(хотя это настолько относительно, насколько вы говорите о 100 модулях)
Также в статье есть сообщение о том, что «ваш вариант» тоже был опробован — не устроил.
Чуть выше в комментариях я написал о том, что сделали в puppetdb, что еще раз подтверждает правильность решения для asynchronous storeconfigs.
о разных, а именно:
unicorn — несколько процессов puppetmasterd (оперируя терминами ветки puppet 2.6.*)
nginx — балансировка от клиента до сервера, на котором уже в качестве puppetmasterd выступает unicorn, за которым скрывается не 1 процесс, а столько, сколько скажем поднять unicorn'у.
RabbitMQ был «как вариант», но как показывает практика — выбор ActiveMQ был правильнее по 2м причинам:
1. MCollective использует его же
2. puppet >=3.0.0 предлагает использовать PuppetDB, т.е. puppet queue они как deprecated объявили. Ну и как «на закуску» в PuppetDB они используют activemq.jar
например: nginx.conf на 400 серверах, с вариантами того, что какие-то строки в конфиге завязаны на что-то уникальное для конкретного сервера.
В этом случае конфигурация — это nginx.conf
, а управлять нужно именно для того, чтобы не делать все это руками.
В плане обычного модуля для puppet, со своими объявлениями, например того-же добавления ключа. Это то, что касается той части, которая необходима для работы.
По поводу UI — нужно подумать, но по-хорошему в этом тоже не должно быть никаких трудностей.
Единственный минус во всем этом — это то, что представлено оно будет скорее всего в том виде, в котором оно удобно нам. Но с другой стороны — это будет совсем наглядным примером, а внести изменения под конкретную инфраструктуру — дело не сложное.
Ну а в рамках «задача» приведете пример чего-либо, что вам приходится делать? неужели нет задачи, по генерации или контроля конфига какого-либо сервиса, того, чтобы он был, например един для некого «кластера», который обрабатывает конкретную задачу?
Мне просто довольно сложно представить ситуацию управления 500 серверами без централизации. Или для примера можно взять ситуацию, когда внезапно у нас случилось так, что в кластере, который отдает статику на машинах нагрузка ~30%, в то время как на тех машинах, что обрабатывают динамику в пиках нагрузка вырастает до ~80-90%. Очевидно, что мы можем выдернуть N машин с первого кластера во второй, но в случае ручной конфигурации нам потребуется сильно больше времени, нежели просто назначить нужные классы с конфигами для этих машин…
Тоесть решение задачи, при наличии puppet(ну или того инструмента, что по душе — тут предлагали много иного) сводится к тому, что мы просто назначаем нужные классы нашим серверам и получаем прибавку тому кластеру, которому уж очень тяжело.
В случае же, если общая конфигурация системы такая, что изменения в нее вносятся крайне редко, а также дополнительные поставки железа редки, то вполне возможно, что тогда та централизация, которую дает puppet — не сильно нужна.
Еще как пример — нужно обновить firmware на железе, по причине выхода критичного багфикса от вендора, но обновить не совсем везде, а только на специфичной платформе, ну например HP Proliant G7 P67. При наличии паппета это решится в 5 строк, с гарантией того, что все у вас обновится.
Не знаю, что привести еще в пример, думаю, что легче будет рассуждать только если вы немного обрисуете хотябы абстрактно то, чем приходится заниматься в повседневной работе.
Прочитав Ваш коммент на почту почти испугался, подумав о том, что я кому-то что-то обосновать должен.
Если не секрет — как много серверов вам приходится поддерживать?
Можем в режиме «задача-решение» обосновать вам возможность такого внедрения.
LDAP хорош все же при меньшей на него нагрузке, это тоже провереный факт. Если LDAP в организации используется для чего-то еще, то никто не мешает нам брать данные для генерации манифестов оттуда, а не из MySQL.
Splunk для сбора, агрегации логов и построения индексов, на основе которых мы можем видеть все, что нам нужно. Также мы ведем записи того, какой пользователь что именно делает/делал на хосте.
Мейнтенансы где именно? на том оборудовании, что выступает в качестве мастера?
Основные задачи обычно связаны с: получением актуального списка нод, по заданным критериям; выполнение определенных команд; форсирование запуска паппет клиента.
Если вы конкретизируете вопрос — вероятно, отвечу ближе.
Вы о каких таймаутах? ;)
Теперь вроде бы исправили, но оно нам уже не нужно.
Кинуть сообщение в queue также быстрее, чем сразу в бд, если речь идет об удаленном географически дц(трансатлантика)
«в среднем 10, если ничего не нужно делать» — если ничего не нужно, то и паппет не нужен ;)
Если в вашем случае такое использование устраивает — оно ж прекрасно. Мы попробовали — не устроило — пошли дальше.
Также в статье есть сообщение о том, что «ваш вариант» тоже был опробован — не устроил.
Чуть выше в комментариях я написал о том, что сделали в puppetdb, что еще раз подтверждает правильность решения для asynchronous storeconfigs.
unicorn — несколько процессов puppetmasterd (оперируя терминами ветки puppet 2.6.*)
nginx — балансировка от клиента до сервера, на котором уже в качестве puppetmasterd выступает unicorn, за которым скрывается не 1 процесс, а столько, сколько скажем поднять unicorn'у.
так несколько яснее? =)
1. MCollective использует его же
2. puppet >=3.0.0 предлагает использовать PuppetDB, т.е. puppet queue они как deprecated объявили. Ну и как «на закуску» в PuppetDB они используют activemq.jar
, тоесть наш изначальный выбор был корректным.
В этом случае конфигурация — это nginx.conf
, а управлять нужно именно для того, чтобы не делать все это руками.
По поводу UI — нужно подумать, но по-хорошему в этом тоже не должно быть никаких трудностей.
Единственный минус во всем этом — это то, что представлено оно будет скорее всего в том виде, в котором оно удобно нам. Но с другой стороны — это будет совсем наглядным примером, а внести изменения под конкретную инфраструктуру — дело не сложное.
Мне просто довольно сложно представить ситуацию управления 500 серверами без централизации. Или для примера можно взять ситуацию, когда внезапно у нас случилось так, что в кластере, который отдает статику на машинах нагрузка ~30%, в то время как на тех машинах, что обрабатывают динамику в пиках нагрузка вырастает до ~80-90%. Очевидно, что мы можем выдернуть N машин с первого кластера во второй, но в случае ручной конфигурации нам потребуется сильно больше времени, нежели просто назначить нужные классы с конфигами для этих машин…
Тоесть решение задачи, при наличии puppet(ну или того инструмента, что по душе — тут предлагали много иного) сводится к тому, что мы просто назначаем нужные классы нашим серверам и получаем прибавку тому кластеру, которому уж очень тяжело.
В случае же, если общая конфигурация системы такая, что изменения в нее вносятся крайне редко, а также дополнительные поставки железа редки, то вполне возможно, что тогда та централизация, которую дает puppet — не сильно нужна.
Еще как пример — нужно обновить firmware на железе, по причине выхода критичного багфикса от вендора, но обновить не совсем везде, а только на специфичной платформе, ну например HP Proliant G7 P67. При наличии паппета это решится в 5 строк, с гарантией того, что все у вас обновится.
Не знаю, что привести еще в пример, думаю, что легче будет рассуждать только если вы немного обрисуете хотябы абстрактно то, чем приходится заниматься в повседневной работе.
Если не секрет — как много серверов вам приходится поддерживать?
Можем в режиме «задача-решение» обосновать вам возможность такого внедрения.