Как с помощью обвиртуализовывания всего и вся получить отряд хорошо вышколенных сервисов вместо цирка-шапито в виде нагромождения демонов на голом железе и какой вообще в этом смысл.
Давным-давно, когдалюди не умели добывать огонь всё сервисы (приложения, базы данных, http-бэкенды, etc) жили прямо на серверах, волхвов админов еженощно будили звонками бдительные (время реакции ~30 минут, хехе) мониторщики. Потому что то один, то другой демон выходил из повиновения и отжирал что-нибудь свободное — диск/память/циклы процессора…
Были и умельцы из числа разработчиков, способные наваять генерилку xml-ек, которая держала в памяти до 8ти гигабайт оных.
Один сервис — один контейнер.
Сервис — http-фронтэнд, http-бэкенд, applications, databases, что угодно.
Поскольку контейнерам лимиты выдаются только по результатам нагрузочного тестирования (нет результатов — не коммерческой эксплуатации), то сервис может сходить с ума сугубо в рамках этих лимитов. Иногда бывает, что один контейнер даёт LA на всю машину, но ioprio совсем жестко не зажмёшь.
Базы бэкапятся через mysqldump и pg_dump на один жирный в плане дисков хост.
Всякие мелкие файлы — настройки, контент, etc — складываются в бакулу. Проекты и так есть в svn и git.
Кроме этого, мы используем «теплое» резервирование — примерно на каждую 6ю машину еженощно делается rsync`ом копия запущенных на других 5ти нодах контейнеров. Контейнеры с mysql по окончания синка поднимаются с левым адресом и делается check table.
Итого — у нас забэкаплено в том или ином виде «ваще всё» и у нас есть возможность руками дежурных быстро-быстро вернуть в строй контейнеры с упавшей железки.
Машины с heartbeat и drbd не в счет.
Если в распоряжении имеется от трех-четырёх сотен контейнеров, то помимо «обычного» мониторинга, при такой схеме особенно важно знать когда и где случились удары в лимиты и какая в настоящий момент загрузка хост-машин.
Навскидку ничего подходящего не нагуглилось, по крайней мере, 2 года назад, поэтому нашими силами были написаны Yabeda и Harvester.
Yabeda умеет показывать в консоли какой контейнер в какой параметр постучался с момента последнего запуска, а также писать сие знание в базу и ябедничать по джабберу.
Harvester умеет:
— Для хост-нод — собирать в базу доступные обещанные (commited) память (privvmpages и shmpages), cpu units и дисковое пространство;
— Для впсов — собирать основные параметры и складывать в базу изменения;
— Для людей — показывать текущую картину в целом и подробную историю в частности (см django-фронтенд к базе harvester-web).
Ещё есть самописная же обвязка к ps и vzpid для снимков повпсного списка процессов на хост-машине, посколько htop не умеет делать вывод в текстовые файлы.
Если я что-то явно не описал, спрашивайте!
Художественное вступление
Давным-давно, когда
Были и умельцы из числа разработчиков, способные наваять генерилку xml-ек, которая держала в памяти до 8ти гигабайт оных.
Схема
Один сервис — один контейнер.
Сервис — http-фронтэнд, http-бэкенд, applications, databases, что угодно.
Поскольку контейнерам лимиты выдаются только по результатам нагрузочного тестирования (нет результатов — не коммерческой эксплуатации), то сервис может сходить с ума сугубо в рамках этих лимитов. Иногда бывает, что один контейнер даёт LA на всю машину, но ioprio совсем жестко не зажмёшь.
«Используйте Bacula, если вы не планируете восстанавливать файлы из бэкапа»
Базы бэкапятся через mysqldump и pg_dump на один жирный в плане дисков хост.
Всякие мелкие файлы — настройки, контент, etc — складываются в бакулу. Проекты и так есть в svn и git.
Кроме этого, мы используем «теплое» резервирование — примерно на каждую 6ю машину еженощно делается rsync`ом копия запущенных на других 5ти нодах контейнеров. Контейнеры с mysql по окончания синка поднимаются с левым адресом и делается check table.
Итого — у нас забэкаплено в том или ином виде «ваще всё» и у нас есть возможность руками дежурных быстро-быстро вернуть в строй контейнеры с упавшей железки.
Машины с heartbeat и drbd не в счет.
Управление
Если в распоряжении имеется от трех-четырёх сотен контейнеров, то помимо «обычного» мониторинга, при такой схеме особенно важно знать когда и где случились удары в лимиты и какая в настоящий момент загрузка хост-машин.
Навскидку ничего подходящего не нагуглилось, по крайней мере, 2 года назад, поэтому нашими силами были написаны Yabeda и Harvester.
Yabeda умеет показывать в консоли какой контейнер в какой параметр постучался с момента последнего запуска, а также писать сие знание в базу и ябедничать по джабберу.
Harvester умеет:
— Для хост-нод — собирать в базу доступные обещанные (commited) память (privvmpages и shmpages), cpu units и дисковое пространство;
— Для впсов — собирать основные параметры и складывать в базу изменения;
— Для людей — показывать текущую картину в целом и подробную историю в частности (см django-фронтенд к базе harvester-web).
Ещё есть самописная же обвязка к ps и vzpid для снимков повпсного списка процессов на хост-машине, посколько htop не умеет делать вывод в текстовые файлы.
Если я что-то явно не описал, спрашивайте!
