Кукольный действительно великолепен. Никогда не пойми меня неправильно. За последние несколько лет это сэкономило мне массу времени и денег и позволило мне быстро и эффективно выполнять свою работу.
Тем не менее, у него действительно есть проблемы с масштабируемостью. Приблизительно после 20-30 клиентов, использующих WEBBrick, все немного падает.
У нас была эта проблема в Baseblack. Теперь у нас есть ~ 60 рабочих станций и рендеров, и все они используют Puppet для управления конфигурацией и развертывания программного обеспечения. Это здорово. Это значительно упрощает процесс развертывания обновлений и обновлений до новых сборочных машин.
Проблема, с которой мы столкнулись, была наиболее четко показана по частоте появления ошибки PSON.
"err: Could not retrieve catalog from remote server: Could not intern from pson: Could not convert from pson:"
И так далее.
Это всегда было преходящей ошибкой, и она исчезла бы, если бы вы запускали куколку 2-3 раза или более, и тогда она работала бы нормально. Это не действительно долгосрочное решение. Время от времени все в порядке, но возникает проблема надежности и «откуда вы знаете, когда он в последний раз запускается, если он не гарантированно работает каждый раз».
Я написал грязный упаковочный скрипт, который перезапустил бы его, если он потерпел неудачу, и так далее. Это работало немного лучше, но иногда все равно не работало.
Итак, сегодня мне хватило этой проблемы, и я решил заняться Apache2 / Mod_passenger. Во времена Puppet 0.24 / 0.25x это было немного больше боли в заднице, чем кажется сейчас. Тогда предпочтительным сервером был Mongrel, теперь это Passenger / mod_rack.
Просто следуйте этому руководству: http://docs.puppetlabs.com/guides/passenger.html
На самом деле это довольно хорошее объяснение шагов, и я не вижу необходимости повторять информацию здесь. Я сделал пару небольших модификаций.
- Файл config.ru ужасно устарел в данной форме, и я использовал эту вместо: https://github.com/puppetlabs/puppet/blob/master/ext/rack/files/config.ru
- Я изменил настройки apache2 по умолчанию для mpm_worker, чтобы он мог обрабатывать больше запросов, чем по умолчанию.
Кстати, эта штука классная . Кто-то написал безумно простую электронную таблицу «калькулятор» для OpenOffice и Excel, которая позволяет вам рассчитать достойные настройки для MaxClients.
<IfModule mpm_worker_module>
ServerLimit 150
StartServers 5
MinSpareThreads 5
MaxSpareThreads 10
ThreadLimit 5
ThreadsPerChild 5
MaxClients 750
MaxRequestsPerChild 0
</IfModule>
Я хотел иметь возможность обрабатывать наше собственное громоздкое стадо рабочих станций и рендеродов, так что это означало, что по умолчанию должен быть установлен ServerLimit и что он должен иметь возможность обрабатывать * много * больше потоков, чем по умолчанию.
Я также переместил «приложение» puppetmasterd из / usr / share / puppet в / srv / puppet, потому что, на мой взгляд (и FHS), это имеет больше смысла.
В процессе перемещения этого каталога есть некоторая оговорка, в том месте, где он находится, он должен быть разбит на кусочки: puppet. После этого все нормально.
Проблемы действительно начались для нас после этого. Это работало нормально с одной рабочей станцией, тестирующей это, но бросило 2+ в пассажира, и apache имел тенденцию убивать детей ruby.
Большая подсказка была в /var/log/apache2/error.log:
[Tue Feb 21 15:50:12 2012] [alert] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread [Tue Feb 21 15:50:15 2012] [error] (12)Cannot allocate memory: fork: Unable to fork new process
Итак, наш puppetmaster работает на Proxmox в качестве виртуальной машины. Proxmox является хостом виртуализации OpenVZ, и в результате он имеет жесткие ограничения, основанные на содержимом / proc / user_beancounters. Это то, что в основном мешает Apache создавать потоки для обработки запросов.
Здесь есть страница о том, как снять ограничения OpenVZ:
clear; cat /proc/user_beancounters vzctl set 101 –tcpsndbuf 999999999:999999999 –save vzctl set 101 –tcprcvbuf 999999999:999999999 –save vzctl set 101 –numtcpsock 999999999:999999999 –save vzctl set 101 –numflock 999999999:999999999 –save vzctl set 101 –othersockbuf 999999999:999999999 –save vzctl set 101 –numothersock 999999999:999999999 –save vzctl set 101 –numfile 999999999:999999999 –save vzctl restart 101
Где 101 — #id вашего контейнера VZ.
Мне также пришлось увеличить выделенную память с 512 МБ до 2 ГБ и увеличить размер подкачки (и почему нет) до 1 ГБ.
После быстрого перезапуска контейнера Puppet и последнего запуска apache я успешно запустил 56 puppetd. Один на каждом из узлов, все сразу, без единой ошибки.
Звучит как успех для меня.
—
Следующая проблема, которая в настоящее время сдерживает быстрое развертывание программного обеспечения и apt-updates, — это наш сервер apt-cacher-ng. Это тоже виртуальная машина Proxmox, и я изначально думал, что те же проблемы могут быть правдой, имея ограничение на соединение с OpenVZ, что не позволит вещам получить соединение.
Если я запускаю apt-get update на 50+ узлах одновременно, вероятность того, что некоторые из них будут иметь ошибку, что-то из-за сбоя соединения с http: // apt, будет довольно близка к P (1).
W: Failed to fetch http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu/dists/lucid/main/binary-amd64/Packages.gz Unable to connect to apt:3142: W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/lucid/main/binary-amd64/Packages.gz Unable to connect to apt:3142: E: Some index files failed to download, they have been ignored, or old ones used instead.
Бит 3142 объясняется тем, что у нас есть порт apt-cacher-ng, работающий на порту 3142, и строка в /etc/apt/apt.conf.d/, содержащая
Acquire::http { Proxy "http://apt:3142"; };
Это самый надежный способ убедиться, что * все * кэшируется, PPA и вся кухонная раковина. Это то, что мы хотим сделать, потому что наличие полного debmirror — это а) растрата дискового пространства, с чем мы всегда имеем преимущество, работая в VFX, а также, дисковое пространство дорого; особенно после наводнения в Таиланде.
Итак, мы используем apt-cacher-ng, и я лично не вижу, чтобы это изменилось в ближайшее время.
Правильно. Поэтому я увеличил ограничения в конфигурации openVZ, и все еще существует проблема, которая означает, что запросы apt не обрабатываются.
Я подозреваю, что поскольку протокол Apt — это просто HTTP, возможно, можно использовать что-то вроде Varnish или HAProxy и несколько бэкэндов apt-cacher-ng.
Похоже, что apt-cacher-ng может работать с несколькими потоками для обработки гораздо большего количества запросов в секунду.
root@apt:/# netstat -anp|grep 3142|wc -l 2964
Да, это может быть проблемой.
Тем не менее, я только что проверил его с помощью ab следующим образом:
tom.oconnor@charcoal-black:~$ ab -n25000 -c550 -X apt:3142 http://ppa.launchpad.net/mozillateam/firefox-stable/ubuntu/dists/lucid/main/binary-amd64/Packages.gz
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking ppa.launchpad.net [through apt:3142] (be patient)
Completed 2500 requests
...
Finished 25000 requests
Server Software: Debian
Server Hostname: ppa.launchpad.net
Server Port: 80
Document Path: /mozillateam/firefox-stable/ubuntu/dists/lucid/main/binary-amd64/Packages.gz
Document Length: 420 bytes
Concurrency Level: 550
Time taken for tests: 3.127 seconds
Complete requests: 25000
Failed requests: 0
Write errors: 0
Non-2xx responses: 25018
Total transferred: 20990102 bytes
HTML transferred: 10507560 bytes
Requests per second: 7994.07 [#/sec] (mean)
Time per request: 68.801 [ms] (mean)
Time per request: 0.125 [ms] (mean, across all concurrent requests)
Transfer rate: 6554.54 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 16 208.9 1 3002
Processing: 1 19 97.9 9 1478
Waiting: 1 19 97.9 9 1477
Total: 4 35 230.9 10 3023
Percentage of the requests served within a certain time (ms)
50% 10
66% 12
75% 13
80% 13
90% 16
95% 20
98% 128
99% 1056
100% 3023 (longest request)
25k запросов, при 550 одновременности, и я до сих пор не могу вернуть ошибки.
Таким образом, похоже, что проблема не в том, чтобы обслуживать файлы из кэша, а в том, что он загружает новые файлы одновременно и обслуживает одновременно.
Так что это блокировка. Ну, это эпический стек.
Вот еще несколько доказательств, подтверждающих мои выводы. Они используют Squid.
Они также используют Fabric для оркестровки. Интригующим.
Подробнее об этом позже .. Когда я на самом деле понял это.
Источник: http://tomoconnor.eu/blogish/puppet-apt-and-our-very-own-thundering-herd/