LVEE 2007 08

Материал из Linux Vacation/Eastern Europe (LVEE).

Автоматизация задач на серверах. Опыт поддержки однотипных *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:
  Index: 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