Автоматизация задач на серверах. Опыт поддержки однотипных *NIX серверов
Системные инженеры регулярно сталкиваются с проблемой нехватки времени. Количество серверов возрастает, а времени на их поддержку остается все меньше. Возникает вполне разумное желание автоматизировать часть работы по их обслуживанию, централизовать управление группами серверов. Реализовать это можно, используя написанные собственноручно решения и выделяя время на их поддержку, либо можно использовать готовые решения, имеющие нужную функциональность.
Свободное время хочется использовать по полной и как можно дальше от вычислительных центров. Именно в период отдыха зачастую приходят гениальные мысли и находятся ответы на долгожданные вопросы.
К сожалению, такое времяпровождение недоступно до тех пор, пока не будет обновлено программное обеспечение, не будет обеспечена исправная работа системы мониторинга и достоверность информации о состоянии систем и серверов. Обычно требуется также проверить, а не вышло ли долгожданное обновление ядра, которое, в случае его выхода, непременно нужно опробовать и внедрить на группе серверов, не забыв обновить изменившиеся файлы конфигурации и скопировать их на все сервера, где установлены соответствующие пакеты. Ну и конечно, в срочном порядке необходимо применить patch к текущей версии ОС на все сервера, дабы уберечься от грядущих сетевых атак.
Какое-то время автор делал все перечисленное "вручную", открывая терминал на каждом из серверов и по очереди выполняя цепочку одних и тех же команд. Желание повторять действия пропало после нескольких раз, но появились другие:
- освободить себя от тех рутинных задач, которые машина вполне может выполнять самостоятельно, а те, что она не может - сделать .
- по возможности централизовать выполнение задач для комфортного управления и быстрого обновления систем.
Начиналось все с такого shell-скрипта:
for hosts in "server1 server2 server3"
do ssh $host do_something
done
Какое-то время это выручало, но недостатки были видны сразу. Не устраивало следующее:
- медленно: каждый процесс начинает выполняться только по завершении предыдущего;
- вывод неудобен для вычитывания, поскольку нет явного указания, какая строка принадлежит выводу какого сервера;
- высокая сложность обслуживания для большого количества групп серверов и более сложных задач/команд.
В качестве быстрого решения на свет появился небольшой скрипт, который позволял запускать команды параллельно на группе серверов. Имя ему было присвоено невзрачное, но весьма понятное: farm_cmd ( http://a.linevich.com/files/farm_cmd ). По мере того, как скрипт исправно выполнял свою работу, в голове его автора вырисовывались общие черты совершенно необходимого законченного программного решения со следующими системными требованиями:
- скорость работы: желательно выполнить все до того, как выйдет очередной стабильный релиз ядра, и при этом успеть вечером на свидание; - открытый код: с одной стороны "религия" не позволяет использовать "черные ящики", а с другой - что еще делать в освободившееся время, как не разбираться в коде? Вдруг понадобиться дополнительная функциональность?
- простота инсталляции: слишком требовательные задачи не вдохновляют на творчество (видимо поэтому более крупные задачи разделяют на мелкие); - простота в использовании: идеально, если все останется так как и было ;-)
Всем известная поисковая система привела к следующим готовым решениям:
- Clusterit, http://www.garbled.net/clusterit.html - написан на C, скорее всего не развивается автором, выглядит как законченный проект, в основном для параллельного компилирования (мнение автора этой статьи).
- Tentakel, http://tentakel.biskalar.de/ - написан на python, на время просмотра не был готов к использованию.
- OpenPBS (Open Portable Batch System), http://www.openpbs.org/about.html - выглядит симпатично, есть даже веб-интерфейс, но разработчики перешли на коммерческую версию.
- Capistrano, http://manuals.rubyonrails.com/read/book/17 - написан на Ruby (незнакомом автору языке программирования), как проект весьма интересен, но слабо развивается и поддерживается. Показался трудным в использовании.
- Sun Grid Engine, http://gridengine.sunsource.net/ - написан на C, требует наличия запущенного сервиса (демона) на клиентских машинах. Не подошел именно из-за удаленного сервиса. Хочется использовать имеющиеся средства (ssh, telnet, scp, ftp) без установки дополнительных утилит на удаленных серверах.
- fanout, http://www.stearns.org/fanout/ - написан на BASH, на момент просмотра не уступал по функциональности farm_cmd, но при этом имел проблемы с обработкой вывода ошибок.
- mussh, http://sourceforge.net/projects/mussh/ - написан на BASH, не поддерживается с 2002 года.
- Cluster SSH - графическое приложение и неплохой выбор, когда требуется перенаправить стандартный ввод на несколько терминалов. Не подходит из- за другой направленности.
Решение было принято в пользу Clusterit, как законченного решения, вполне работоспособного и проверенного "в бою". Пакет содержит следующие компоненты:
- dsh - выполнение команды на кластере (от англ. группа) машин параллельно;
- run - выполнение команды на случайной ноде;
- pcp - копирование файлов на группу машин;
- pdf - вывод команды df в общий вид на группе машин;
- prm - удаление файлов на группе машин.
Дополнительно, имеются утилиты:
- barrier - синхронизация процессов на группе машин (требует установки barrierd на каждой из нод);
- barrierd - daemon для barrier;
- jsd - daemon для запуска команд на удаленной машине (требует установки на каждую из нод);
- jsh - запуск команд на удаленной машине.
Примеры использования clusterit:
- Проверка на наличие уязвимостей для FreeBSD:
dsh -e -g freebsd "sudo /usr/local/sbin/portaudit -Fda"
- Проверка уязвимостей для Linux Gentoo:
dsh -e -g gentoo,vds "glsa-check -ln afected"
Еще одним критичным вопросом является резервное копирование. Для бекапов данных сервера у каждого администратора находится свое решение. Для облегчения жизни и спокойного сна автор хотел содержать центральное хранилище для файлов конфигураций со всех серверов и получать уведомления в случае, если файлы изменились без его участия, когда системных инженеров несколько. Для этого была написана утилита backup2svn (http://backup2svn.sf.net/). Как backend в ней используется система хранения версий Subversion, а как транспорт для передачи файлов от удаленного сервера на сервер бекапов используется OpenSSH. Данное решение является несложным в использовании и настройке. Еще один его плюс - отсутствие необходимости устанавливать дополнительные утилиты на стороне клиента.
Пример использования backup2svn:
Начинаем backup:
$SSH_CMD bmw.kiev.ua sudo gtar -czf - /etc /usr/local/etc | /opt/sbin/backup2svn bmw.kiev.ua
Изменился файл /etc/ccd.conf:
--- etc/ccd.conf (revision 102)
+++ etc/ccd.conf (working copy)
@@ -4,7 +4,7 @@
+ccd0 16 none /dev/sd2e /dev/sd3e
-ccd0 16 none /dev/wd0a
Антон Линевич, Киев, Украина, chexov@colocall.net
Свободное время хочется использовать по полной и как можно дальше от вычислительных центров. Именно в период отдыха зачастую приходят гениальные мысли и находятся ответы на долгожданные вопросы.
К сожалению, такое времяпровождение недоступно до тех пор, пока не будет обновлено программное обеспечение, не будет обеспечена исправная работа системы мониторинга и достоверность информации о состоянии систем и серверов. Обычно требуется также проверить, а не вышло ли долгожданное обновление ядра, которое, в случае его выхода, непременно нужно опробовать и внедрить на группе серверов, не забыв обновить изменившиеся файлы конфигурации и скопировать их на все сервера, где установлены соответствующие пакеты. Ну и конечно, в срочном порядке необходимо применить patch к текущей версии ОС на все сервера, дабы уберечься от грядущих сетевых атак.
Какое-то время автор делал все перечисленное "вручную", открывая терминал на каждом из серверов и по очереди выполняя цепочку одних и тех же команд. Желание повторять действия пропало после нескольких раз, но появились другие:
- освободить себя от тех рутинных задач, которые машина вполне может выполнять самостоятельно, а те, что она не может - сделать .
- по возможности централизовать выполнение задач для комфортного управления и быстрого обновления систем.
Начиналось все с такого shell-скрипта:
for hosts in "server1 server2 server3"
do ssh $host do_something
done
Какое-то время это выручало, но недостатки были видны сразу. Не устраивало следующее:
- медленно: каждый процесс начинает выполняться только по завершении предыдущего;
- вывод неудобен для вычитывания, поскольку нет явного указания, какая строка принадлежит выводу какого сервера;
- высокая сложность обслуживания для большого количества групп серверов и более сложных задач/команд.
В качестве быстрого решения на свет появился небольшой скрипт, который позволял запускать команды параллельно на группе серверов. Имя ему было присвоено невзрачное, но весьма понятное: farm_cmd ( http://a.linevich.com/files/farm_cmd ). По мере того, как скрипт исправно выполнял свою работу, в голове его автора вырисовывались общие черты совершенно необходимого законченного программного решения со следующими системными требованиями:
- скорость работы: желательно выполнить все до того, как выйдет очередной стабильный релиз ядра, и при этом успеть вечером на свидание; - открытый код: с одной стороны "религия" не позволяет использовать "черные ящики", а с другой - что еще делать в освободившееся время, как не разбираться в коде? Вдруг понадобиться дополнительная функциональность?
- простота инсталляции: слишком требовательные задачи не вдохновляют на творчество (видимо поэтому более крупные задачи разделяют на мелкие); - простота в использовании: идеально, если все останется так как и было ;-)
Всем известная поисковая система привела к следующим готовым решениям:
- Clusterit, http://www.garbled.net/clusterit.html - написан на C, скорее всего не развивается автором, выглядит как законченный проект, в основном для параллельного компилирования (мнение автора этой статьи).
- Tentakel, http://tentakel.biskalar.de/ - написан на python, на время просмотра не был готов к использованию.
- OpenPBS (Open Portable Batch System), http://www.openpbs.org/about.html - выглядит симпатично, есть даже веб-интерфейс, но разработчики перешли на коммерческую версию.
- Capistrano, http://manuals.rubyonrails.com/read/book/17 - написан на Ruby (незнакомом автору языке программирования), как проект весьма интересен, но слабо развивается и поддерживается. Показался трудным в использовании.
- Sun Grid Engine, http://gridengine.sunsource.net/ - написан на C, требует наличия запущенного сервиса (демона) на клиентских машинах. Не подошел именно из-за удаленного сервиса. Хочется использовать имеющиеся средства (ssh, telnet, scp, ftp) без установки дополнительных утилит на удаленных серверах.
- fanout, http://www.stearns.org/fanout/ - написан на BASH, на момент просмотра не уступал по функциональности farm_cmd, но при этом имел проблемы с обработкой вывода ошибок.
- mussh, http://sourceforge.net/projects/mussh/ - написан на BASH, не поддерживается с 2002 года.
- Cluster SSH - графическое приложение и неплохой выбор, когда требуется перенаправить стандартный ввод на несколько терминалов. Не подходит из- за другой направленности.
Решение было принято в пользу Clusterit, как законченного решения, вполне работоспособного и проверенного "в бою". Пакет содержит следующие компоненты:
- dsh - выполнение команды на кластере (от англ. группа) машин параллельно;
- run - выполнение команды на случайной ноде;
- pcp - копирование файлов на группу машин;
- pdf - вывод команды df в общий вид на группе машин;
- prm - удаление файлов на группе машин.
Дополнительно, имеются утилиты:
- barrier - синхронизация процессов на группе машин (требует установки barrierd на каждой из нод);
- barrierd - daemon для barrier;
- jsd - daemon для запуска команд на удаленной машине (требует установки на каждую из нод);
- jsh - запуск команд на удаленной машине.
Примеры использования clusterit:
- Проверка на наличие уязвимостей для FreeBSD:
dsh -e -g freebsd "sudo /usr/local/sbin/portaudit -Fda"
- Проверка уязвимостей для Linux Gentoo:
dsh -e -g gentoo,vds "glsa-check -ln afected"
Еще одним критичным вопросом является резервное копирование. Для бекапов данных сервера у каждого администратора находится свое решение. Для облегчения жизни и спокойного сна автор хотел содержать центральное хранилище для файлов конфигураций со всех серверов и получать уведомления в случае, если файлы изменились без его участия, когда системных инженеров несколько. Для этого была написана утилита backup2svn (http://backup2svn.sf.net/). Как backend в ней используется система хранения версий Subversion, а как транспорт для передачи файлов от удаленного сервера на сервер бекапов используется OpenSSH. Данное решение является несложным в использовании и настройке. Еще один его плюс - отсутствие необходимости устанавливать дополнительные утилиты на стороне клиента.
Пример использования backup2svn:
Начинаем backup:
$SSH_CMD bmw.kiev.ua sudo gtar -czf - /etc /usr/local/etc | /opt/sbin/backup2svn bmw.kiev.ua
Изменился файл /etc/ccd.conf:
--- etc/ccd.conf (revision 102)
+++ etc/ccd.conf (working copy)
@@ -4,7 +4,7 @@
+ccd0 16 none /dev/sd2e /dev/sd3e
-ccd0 16 none /dev/wd0a
Антон Линевич, Киев, Украина, chexov@colocall.net
Сетевые решения. Статья была опубликована в номере 07 за 2008 год в рубрике бизнес
