У меня есть марионеточный хозяин и рабы в разных центрах обработки данных. Задержка между ними составляет ~ 40 мс. Когда я запускаю "puppet agent --test" на ведомом устройстве, чтобы применить последний манифест, для завершения требуется ~ 360 секунд.
Покопавшись, я понял, что основная причина замедления - передача файлов. Кажется, на передачу каждого файла уходит ~ 10 секунд. Файлы очень маленькие (файлы конфигурации), поэтому я не могу понять, почему они занимают так много времени.
Это пример файла в моем манифесте:
file { "/etc/rsyncd.conf" :
owner => "root",
group => "root",
mode => 644,
source => "puppet:///files/rsyncd/rsyncd.conf"
}
Запуская puppet-profiler вижу вот это:
10.21s - File[/etc/rsyncd.conf]
Также кажется, что я не могу обновить более одного сервера одновременно с помощью марионетки. Если я запускаю два сервера одновременно, puppet занимает в два раза больше времени.
Я сменил мастера марионеток с webrick на mongrel, но это, похоже, не помогает. Это делает развертывание изменений болезненным. Внедрение простого изменения конфигурации на все серверы может занять час.
Отказ от ответственности: я один из разработчиков Puppet.
Когда вы исходите из файлов с puppet:// URL-адреса, Puppet сделает два SSL-подключения обратно к файловому серверу - одно для метаданных, включая контрольную сумму, а другое для содержимого. Вторая сделана, надеюсь, как и ожидалось, только если содержимое на диске устарело.
Сама передача осуществляется по стандартному протоколу HTTPS, ничего особенного не происходит, поэтому, помимо накладных расходов SSL и затрат на задержку двух подключений, нет причин, по которым Puppet должен быть таким медленным.
Puppet также будет проверять контрольную сумму файла на обеих сторонах, на клиенте и на сервере, когда дело доходит до проверки его актуальности. Это может быть медленным, если ваш резервный магазин тоже медленный.
Наконец, вы должны проверить, не работает ли ваше сетевое соединение медленным из-за насыщения или чего-то в этом роде. Это будет не первый случай, когда большие буферы приводят к ужасной производительности сети - и кто-то поместил в середину формирователь трафика, который сделал пинги сверхбыстрыми. ;)
Помимо этого, я предлагаю вам отправить отчет об ошибке. Включение деталей и сетевых трассировок очень помогло бы нам решить эту проблему.
То, что вы описываете, безусловно, ненормально, и это не то, что мы ожидаем увидеть для небольших файлов конфигурации в достаточно быстрой сети, такой как вы описываете. (Кроме того, это не то, что видят другие, поэтому очевидно, что в вашей установке происходит что-то необычное.)
По моему опыту, более старые версии марионетки сериализовали и DE-сериализовали все данные ФАЙЛА при их передаче туда и обратно. А особенно плохо было и с переносом больших (много мегабайт) двоичных файлов.
Г-н Питтман предполагает, что это больше не так, но вы можете копнуть глубже и посмотреть, есть ли такая оптимизация в используемой вами версии марионетки.
Похоже, что изменение коснулось марионетки 0.25 - см. Ошибку 583 (http://projects.puppetlabs.com/issues/583) при конвертации из xlrpc в покой.
Мое решение в то время заключалось в использовании марионетки для отправки предварительных общих ключей rsync и использования демона rsync для обслуживания файлов (только для чтения) для конечных клиентов. Rsync может быть довольно эффективным и передавать и обновлять множество двоичных данных.
Поэтому проверьте версии марионеток, но также посмотрите, может ли rsync работать на вас в качестве сравнения производительности.
Я нашел проблему. Похоже, что хотя я настроил свой Apache для запуска puppetmaster через пассажира, конфигурационный файл так и не попал в мой httpd.conf. Мой кукловод по-прежнему использовал настройки по умолчанию. (netstat -anp | grep 8140 показал, что apache не использует этот порт).
После устранения этих проблем и проверки того, что Apache прослушивает 8140, моим марионеточным клиентам теперь требуется 8 секунд, по сравнению с 380 секундами.
Проверьте комментарий, который я оставил http://projects.puppetlabs.com/issues/3365 о наличии большего количества файлов в целевом каталоге.
Салудо!