Проблема управления большим количеством систем далеко не нова, но особенно она стала актуальна при появлении кластеров и облачных сервисов. Как результат появление разнообразных инструментов решающих ее каждый по своему. Synctool разработанный для голландского фонда SURFsara обеспечивающего суперкомпьютеры для учебных заведений ориентирован в первую очередь на кластеры, но его гибкость позволяет использовать практически в любой ситуации, а простота не требует долгого изучения.
СМ-системы
*nix системы изначально оснащаются средствами удаленного управления, а сам способ хранения и формат конфигурационных файлов, позволяет быстро распространять обновленную версию настроек простым копированием на узел. До определенного количества систем такая схема вполне удовлетворяет. Когда же число серверов исчисляется десятками без специального инструмента не справиться. Вот здесь и появляется интерес к системам управления конфигурации позволяющих настраивать сервера не руками, а программным способом. Системы настраиваются быстро и с меньшим количеством возможных ошибок, админ получает отчет. Также СМ-система умеет следить за всеми изменениями сервером поддерживая нужную конфигурацию.
Прародителями СМ-систем стал CFEngine созданный в 1993 году норвежским ученым Марком Бургесом из университа города Осло. На сегодня существует уже большое количество систем Chef, Puppet, SaltStack, CFEngine, Ansible, BCfg2, SyncTool и т.д. Каждая изначально проектировалась под определенные задачи и выделяется своими особенностями, в большинстве случаев используется собственный язык настройки, при помощи которого описывается конфигурация узлов, доступны разные механизмы абстракции и стили управления. Одни описывают состояние узлов (декларативные), другие (императивные) позволяет контролировать процесс внедрения изменений. В итоге чтобы освоить любую из них потребуется некоторое время. Но это не значит что выбранная СМ-система будет идеально подходить под задачи и все придется начинать сначала.
Возможности Synctool
Разработка утилиты управления конфигурацией для синхронизации кластеров [Synctool](heiho.net/synctool) началось в 2003 году Walter de Jong экспертом голландского фонда SURFsara обеспечивающего суперкомпьютеры и сети для учебных заведений и с тех пор используется в реальной работе на больших вычислительных узлах. Его главный плюс — здравый смысл, то есть ничего нового изучать не придется, а SyncTool по сути просто надстройка над привычными инструментами и практиками *nix. В нем нет языка сценариев, при необходимости используется язык оболочки или любой скриптовый, и в задачах нет стремления автоматизировать абсолютно все аспекты администрирования систем.
Основная задача Synctool обеспечение синхронизации и аутентичности конфигурационных файлов. То есть он не предназначен для полной установки системы, хотя может использоваться для быстрого конфигурирования новых узлов.
Для этого создается репозитарий файлов, а мастер-узел периодически их сверяет с остальными нодами. В случае различий (разная контрольная, сумма, время создания и т.п.) производится обновление, после чего запускается специальная команда synctool-client производящая необходимые действия. Кстати вполне возможно выполнять synctool-client на узле вручную, в этом случае будет проверятся только локальная копия репозитория. Синхронизация с хранилищем на мастер-сервере не производится, здесь инициатором всегда является главный узел.
Предусмотрено три режима работы — предупреждение об отклонениях, автоматическое обновление или безусловное обновление файлов. Узлы могут управляться индивидуально, являться частью одной или нескольких логических групп или все вместе. Группы могут быть вложенными.
Возможно расширение функционала при помощи самописных плагинов-скриптов. При этом нет никаких ограничений на используемый язык. Сценарии могут быть связаны с файлами для выполнения действий после обновления файла, шаблоны файлов могут генерироваться на лету (например подставляться IP), специальный тип файлов заканчивающийся на .post, позволяют задавать команды выполняющиеся при обновлении файла (например, перезапустить сервис). Скрипты могут иметь определенную группу свойств.
Для распространения файлов используется SSH (аутентификация с использованием SSH ключей или hostbased) и непосредственно копирование производится при помощи rsync. Ни каких агентов на управляемые системы устанавливать не нужно.
Работает SyncTool в интерактивном режиме. В комплекте идет несколько специально разработанных команд упрощающих конкретные задачи, которые легко использовать в сочетании с другими инструментами. Например, dsh позволяет выполнять команды сразу на нескольких узлах. Хотя параметров у утилит много, набор основных функций очень небольшой и во всем легко разобраться.
Установка SyncTool
Написан SyncTool на Python, поэтому установка проблем не вызывает. В качестве зависимостей указанны — python, ssh (лучше OpenSSH 5.6+), rsync и ping. Все это обычно уже есть в дистрибутивах. SSH лучше настроить на беспарольную аутентификацию иначе придется подтверждать учетные данные, в Сети есть достаточно руководств по этому вопросу. Единственный момент, что все утилиты подключаются к удаленной систем от имени root, а например в Ubuntu по умолчанию такой учетной записи нет. Чтобы не править исходники, лучше рута все же завести, не забыв разрешить ему подключаться по SSH. В целях безопасности также следует ограничить sshd только интерфейсом внутренней сети (ListenAddress в sshd_config), ведь «светящийся» 22 порт это приманка для ботов.
Далее скачиваем архив с офсайта, распаковываем и выполняем:
$ sudo ./setup.sh -f
Если запустить setup.sh без ключа «-f» будет произведена «dry run» т. е. проверка без установки. По умолчанию установка производится в каталог /opt/synctool, лучше оставить как есть. Если он все таки не подходит, то чтобы изменить его добавляем параметр —installdir. Внутри будет образовано несколько подкаталогов. Скрипты (их 9) находятся в synctool/bin (по большому счету почти все являются ссылками на synctool/sbin), его желательно сразу добавить в PATH, чтобы было проще работать.
$ sudo nano /etc/profile
PATH=$PATH:/opt/synctool/bin
export PATH
После чего перелогинимся.
Клиентское ПО на узлах, как говорилось выше ставить ненужно. Мастер узел автоматически устанавливает и обновляет SyncTool на нодах. Исполняемые файлы, необходимые для них находятся в synctool/sbin, который синхронизируются с узлами каждый раз при запуске утилиты synctool.
Конфигурационный файл SyncTool
Прежде чем приступить к работе необходимо настроить SyncTool. Все установки производятся в конфигурационном файле /opt/synctool/etc/synctool.conf, в котором описывается как выглядит кластер (узлы, группы, роли), и как SyncTool может с ними связаться, плюс журналирование, бэкап и т.п. Изначально нет необходимости пробовать создавать сложную систему из разветвленных групп, это обычно путает, а конфигурацию можно позже в любой момент перестроить, окончательно разобравшись. В комплекте поставки идет пример synctool.conf.example, который можно использовать в качестве заготовки. Параметров не очень много, все они расписаны в [документации](heiho.net/synctool/doc/chapter4.html), хотя в некоторых случаях и не достаточно внятно. Тем более что вариантов написания некоторых может быть несколько и постоянно добавляются новые. Остановлюсь только на основных.
Первым делом необходимо сказать SyncTool, какой узел будет за главного. Для этого в параметре master указывается его полное доменное имя.
master n1.cluster.org
Имя можно получить при помощи «synctool-config —fqdn«.
Зависимость всей структуры от одного узла это не очень хорошо сточки зрения надежности, необязательный параметр slave позволяет определить дополнительные куда будет отправляться полная копия репозитория.
Сами узлы задаются при помощи параметра node, после которого указывается имя узла или узлов, группы, как связаться и параметры синхронизации.
node < имя> < группа> [ipaddress:] [hostname:] [hostid:] [rsync:]
Имя узла — любой буквенно-цифровой символ, при чем имя не обязательно должно указывать на хостнейм или соответствовать записи в DNS т.е. в его качестве можно использовать любую информацию удобную для понимания. Но без каких то других указаний SyncTool будет искать узел по имени через DNS. Поэтому для удобства можно прописать алиас в /etc/hosts, но в этом случае придется контролировать два файла, а это чревато ошибками. Поэтому разработчики предлагают свой вариант. Если прописанное имя невозможно определить через DNS или по другим причинам (например работа в автономном режиме), IP-адрес или хостнейм узла указывается при помощи необязательных параметров ipaddress и hostname.
Узел может входить в состав нескольких групп, но важность групп соответствует их порядку перечисления (т.е. первая главная). Спецификатор hostid используется в том случае когда одно имя может иметь несколько узлов, поэтому для определения текущего, используется файл размещенный на целевом узле, какой нод ответит при доступе к файлу, тот и будет проверяться на обновление.
По умолчанию SyncTool производит синхронизацию со всеми узлами. Но в некоторых случаях в этом нет необходимости (например, узлы используют общеe хранилище NFS), установка «rsync:no», позволит запретить синхронизацию с этим узлом.
Так как в файле обязательно должен быть описан каждый узел, а кластер может содержать их сотни, предоставлена возможность задавать имена и параметры при помощи диапазона:
node node[1-9] ubuntu ipaddress:node[1]-cluster1
node node[10-19] ubuntu ipaddress:192.168.1.[10]
В случае если планируется синхронизировать при помощи SyncTool и master узел, он также определяется через параметр node, но разработчики не рекомендуют такой метод синхронизации.
В терминах SyncTool узлы собираются в группы, но говоря о группе фактически подразумеваются свойства узла. Ключевое слово group определяет составные группы, определяющие нескольких подгрупп в единую группу:
group [..]
Если подгруппы еще не существуют, они определяются автоматически, как новые/ пустые группы. Имя узла также можно использован в качестве группы.
Встроенная группа «All» позволяет применять настройки ко всем узлам.
Кроме этого файл может содержать и ряд других полезных параметров: ignore* (позволяют исключить узлы или группы), colorize* (раскрашивает вывод), include
подключает внешний файл с настройками (при разветвленной структуре управляемой несколькими админами это очень удобно).
Для проверки файла используется команда synctool-config. Список узлов можно проверить при помощи параметра -l:
$ sudo synctool-config -l
Теперь, когда есть минимальные установки можно попробовать запустить synctool на удаленном узле:
$ sudo synctool -n node1
В ответ получим отзыв нода, который означает что все работает. Можем попробовать запустить задачу на всех узлах:
$ sudo synctool
DRY RUN, not doing any updates
Каждый узел прописанный в файле, должен ответить. Теперь осталось его нагрузить работой. Забегая наперед скажу об одной особенности о которой нужно помнить, утилита synctool запущенная глобально, требует опцию -f (—fix), иначе она будет запущенна в режиме проверки «dry run». Это позволяет спасти от случайных ошибок.
$ sudo synctool -f
Если указываются какие то параметры, то -f использовать обычно не нужно.
Файлы и каталоги SyncTool
Файлы которые следует синхронизировать располагаются в строго определенных каталогах, имеющих свое назначение:
- /opt/synctool/var/overlay — файлы, которые должны быть скопированы на целевые узлы, при отсутствии или обнаружении разницы между файлом в репозитарии и клиенте;
- /opt/synctool/var/delete — файлы, которые должны быть удалены. Для этого достаточно просто поместить пустой файл с нужным именем.
- /opt/synctool/var/purge — каталоги, которые копируются на целевые системы «как есть» без сравнения, если файл на конечно системе отсутствует он удаляется.
- /opt/synctool/scripts — каталог со скриптами, которые могут быть выполнены на конечной системе при помощи команды dsh.
Суть SyncTool, что имя логических групп совпадает с названием каталога или является расширением каталога/файла размещенных в подкаталогах overlay. В настройках по умолчанию все файлы должны иметь расширение. Например, каталог overlay/all содержит файлы предназначенные для всех систем (хотя разработчики рекомендуют держать его пустым). Как вариант просто добавить расширение ._all к имени файла. Здесь проще показать на примере:
- overlay/all/etc._group1/ – файлы в каталоге /etc получат ноды входящие в группу group1
- overlay/all/etc/hosts._group2 – файл /etc/hosts для группы group2
- overlay/all/etc/hosts._all — файл /etc/hosts для всех
- overlay/group3/etc/hosts._all — файл /etc/hosts для всех узлов группы group3
Символические ссылки тоже используются при синхронизации, с расширением гупппы они будут показывать в «пустоту», но на конечной системе они будут показывать на нужный файл. Например, /etc/motd является ссылкой на файл file, который на мастер сервере имеет имя file._all. То есть ссылка работать не будет, но после копирования и разыменования все будет работать как нужно.
overlay/all/etc/motd._all -> file
overlay/all/etc/file._all
Вероятно первое время с группами и расширениями придется немного повозиться, чтобы понять систему именования. В случае ошибки в имени SyncTool выдаст, что-то вроде «there is no such group».
Теперь когда хранилища заполнены можем провести синхронизацию. Параметров у synctool много. Например, нам нужно синхронизировать отдельный узел:
$ synctool -n node1
node1: DRY RUN, not doing any updates
node1: /etc/issue updated (file size mismatch)
Или отдельный файл:
$ synctool -n node1 -u /etc/issue
Опция —diff позволяет просмотреть различия между файлами, в том виде как выводит их одноименная утилита.
$ synctool -n node1 --diff /etc/issue
В отличие от overlay файлы в purge не используют расширения групп, поэтому SyncTool копирует все поддерево и удаляет любые файлы на целевой узел отсутствующие в исходном дереве. Таким образом purge идеально подходит для начального изменения конфигурации или глобальной перестройки серверов.
После изменения конфигурационного файла, следует перезапустить сервис. SyncTool для этого предлагает простой механизм — все команды которые необходимо выполнить после копирования заносятся в файл с расширением “.post”. Например, у нас есть в репозитарии конфигурационный файл веб-сервера Apache:
overlay/all/etc/apache/apache.conf._all
Для перезапуска сервиса создаем файл overlay/all/etc/apache/apache.conf.post такого содержания:
service apache2 reload
И делаем его исполняемым:
$ sudo chmod +x apache.conf.post
В примере скрипт не имеет расширения групп, а значит будет актуален для всех. Но при необходимости выполнять различные действия на узлах, можно его также использовать (apache.conf.post_ubuntu). Post-скрипт по умолчанию выполняется в том же каталоге в котором размещается конфигурационный файл.
Параметры некоторых конфигурационных файлов могут генерироваться динамически (например, прописывается IP адрес узла), можно для каждого нода загрузить файл индивидуально, но если систем много это будет не очень весело. Для генерации подобных конфигурационных файлов используются шаблон — файл с расширением ._template. В паре к нему идет ._template.post скрипт, который запускает специальную утилиту synctool-template для генерации файла конфигурации на удаленной системе. Во время работы _template.post скрипт вычисляет значение переменной и экспортирует ее через функцию export (имя переменной может быть любое или их может быть несколько):
export VALUE
/opt/synctool/bin/synctool-template "$1" >"$2"
В шаблоне в нужно место просто вставляем @VALUE@. Утилита synctool-template получит значение переменной и запишет в файл.
Утилиты SyncTool
В поставке SyncTool идет несколько утилит. В общем их имен начинаются на dsh* и synctool*. Первые позволяют выполнять некоторые операции на удаленных системах, вторые относятся непосредственно к работе различных составляющих SyncTool. Часть из них вспомогательная и их обычно не приходится запускать вручную. А вот некоторые интересны. Названия нодов и групп берутся из synctool.conf, поэтому для выполнения требуется минимум параметров. Например, dsh-ping позволяет проверить какие из узлов отвечают. Если ввести без параметров, то будут опрошены все системы:
$ dsh-ping
Все утилиты SyncTool имеют сходные опции, поэтому почти все сказанное dsh касается и остальных. Например, -q и -a позволяют сделать вывод менее болтливым, опция -v наоборот, дает подробный вывод.
Но самая приметная из первого списка это собственно dsh, представляющая собой некий командный менеджер, позволяющий выполнять команды и скрипты на группе узлов.
$ dsh uptime
Или на
отдельном узле и группе:
$ dsh -n node1 ifconfig
$ dsh -g ubuntu date
Создав скрипт в каталоге scripts мы можем его легко выполнить на любом узле (задавать полный путь не требуется):
$ dsh -g ubuntu script.sh
После запуска процесс выполнения на всех узлах начинается параллельно. В некоторых случаях в этом нет необходимости, поэтому можно ограничить количество процессов при помощи —numproc, а -z позволяет указать задержку между командами для разных узлов. Запуск только одного процесса за один раз:
$ dsh --numproc=1 uptime
То же, но с 5 секундной задержкой.
$ dsh -z 5 uptime
Менеджер пакетов dsh-pkg является фактически универсальной оберткой над всеми популярными инструментами для установки приложений в Linux и BSD, так что можно управлять любым из них, используя только одну команду и набор аргументов. Это полезно когда в группе работают узлы с разными ОС. По умолчанию менеджер определяется автоматически, но в некоторых случаях его можно в synctool.conf задать вручную:
package_manager apt-get
Используя dsh-pkg очень просто произвести любые операции на удаленных системах
$ sudo dsh-pkg -n node1 --list
$ sudo dsh-pkg -g ubuntu --install wget
$ sudo dsh-pkg --update
$ sudo dsh-pkg —upgrade
Последние две команды обновят списки пакетов и установят обновления на всех системах.
h3 class=»MsoNormal» style=»text-align: center;»***
Назвать SyncTool сложным нельзя, чтобы разобраться с базовыми возможностями достаточно поэкспериментировать пару часов. Как результат получим удобный и надежный инструмент управления большим количеством серверов.