Amin 's Blog

Пример 1.
У нас есть 200 серверов на CentOS, и на каждом из них надо установить обновления и назначить перезапуск на 4:30 утра. Какие есть варианты ?
1). Скрипт-вульгарис, с циклом обыкновенным. Проблема его в том, что такой скрипт выполняется последовательно. И пока очередной сервер не закончит обновления - следующие обновляться не начнут. Если операция долгая - то скрипт может выполняться сутками.
2). Скрипт многопоточный. Уже лучше, но а) писать и отлаживать сложнее б) не так удобно мониторить состояние каждого сервера в) в случае непредвиденных ошибок на каком-либо из серверов ручное вмешательство затруднительно.
3). Открыть в konsole 200 вкладок и в каждой вкладке ручками запустить требуемое. Шутка =) Реально такое окно неудобно в управлении, памяти оно сожрет вагон, а от ручного ввода 200 копий одной и той же команды даже через буфер обмена - пальцы скурвятся.
И тут на помощь нам приходит такой замечательный пакет, как ClusterSSH. В репозитариях Федоры он есть, ставится как обычно. Для его использования сперва надо получить список IP-адресов одной строкой, где адреса разделены пробелами. Затем выполняем такую команду:

cssh -l root 12.135.75.1  12.135.75.3  12.135.76.12 ... 81.56.158.88

При этом у нас появится маленькое серое окошко с полем ввода и несколько окошек xterm-a, в каждом из которых будет открыт свой сервер из списка. Работает оно просто, как каменный топор - ввод в окошко xterm-а посылается только заданному серверу, а ввод в поле ввода на сером окошке отправляется сразу всем серверам, до которых удалось установить соединение. То есть в нашем случае вводим в общую консоль такие команды:

yes
echo "reboot" | at 2011-10-25 04:30
yum update -y

Первая - на случай, если сервер еще не добавлен в список известных хостов, вторая позволяет сразу указать, что в 25 октября в 4:30 надо ребутнуться, а самую долгую по времени выполнения команду (обновление) даем в самом конце, после чего спокойно идем обедать. По возвращении смотрим добрым взглядом в каждое из окошек xterm-a, и если все в порядке - просто его закрываем, сервер ночью сам перезагрузится. Если нет - оставляем окошко как есть и смотрим следующие. После чего спокойно разбираемся с теми машинами, где обновление по каким-либо причинам не прошло.
Как видим, в этом случае мы посылаем одну и ту же команду параллельно сразу куче машин, и при этом имеем возможность визуально контролировать ход процесса, вмешиваясь по необходимости только там, где это реально нужно.

Пример 2.
У нас есть 600 управляемых свитчей (в наборе 5 разных моделей), на которых надо обновить прошивки. Для начала готовим списки для каждой из моделей, чтобы за один сеанс обновлять только одну модель устройств.
Но тут выясняется такая вещь - одна модель из пяти не умеет работать по SSH, а умеет только telnet. В этом случае сперва генерим стандартный конфиг с помощью такой команды:

cssh -u > ~/.csshrc

после чего в этом файле исправляем следующее:

method=telnet
telnet=/usr/bin/telnet
telnet_args=

Все, с таким конфигом ClusterSSH превращается в ClusterTelnet. Раньше телнет и rsh были вынесены как отдельные утилиты ctel и crsh, но позднее оставили только одну уитилиту cssh + конфиги. Вот пример скриншота, на котором запечатлен процесс обновления прошивок сразу на 83 управляемых свитчах: Число 83 в заголовке серого окошка - это количество окон xterm, то бишь количество железок, обновляемых за данный сеанс. Все данные вводятся в главное окно. Логин, пароль, download firmware_fromTFTP... - и все 83 свичта начинают одновременно выкачивать прошивку с TFTP-сервера. Ждем минут 5, смотрим и проверяем, что все свитчи обновились. Иногда обновление упорно не хочет запускаться, (как например на окошке внизу слева), или может писать нечто подобное:

#download firmware_fromTFTP 10.22.1.1 3526_6.10.B52.had image_id 1

Command: download firmware_fromTFTP 10.22.1.1 3526_6.10.B52.had image_id 1

Connecting to server................... Done. 
Download firmware......................  45 %
Fail!

- в подобных случаях с помощью истории команд повторяем команду строго для проблемного свитча, пока не примет (некоторые свитчи, стоящие где-нить за WiFi-мостом, могут нормально закачать прошивку только раза так с 15-го... [что впрочем не удивительно]). Когда все железки обновлены - даем общую команду save config (мало ли кто из коллег чего менял в конфиге), после чего пишем команду reboot, чтобы загрузиться уже на новых прошивках. Железки просят подтверждения, жмем [y] ... и отправляем все 83 свитча в ребут разом. Только при этом желательно заранее предупредить всех, кого следует, иначе увидев в мониторинге падение сразу кучи железок, может и с сердцем плохо стать... Закрываем ClusterSSH, и через минуту-две пробуем открыть снова. Смотрим внимательно - везде должны быть обновленные прошивки. При таком раскладе даже в случае наличия нескольких свитчей "в цепочку", соединенных по магистральным оптическим портам, инет у конечного пользователя пропадет максимум на 1-2 минуты. Ага, ни-единава-разрыва .
Опять же, все работает параллельно, и мы можем легко контролировать процесс перепрошивки каждой из железок, включая проблемные. Без всяких мутных и кривых скриптов.

P.S. Если у вас не особо мощная машина (одноядерный проц, гиг памяти, куча всего запущено), то при попытке открытия сеанса с 300-400 окошками (даже такими легкими, как XTerm), графическая оболочка может начать ощутимо подлагивать. Ну что можно на это сказать ? - Грузите апельсины бочками Обновляйте прошивки небольшими партиями по 80-100 свитчей за сеанс.
P.S.S. Как делать тоже самое скриптами - напишу в следующий раз, когда мне это понадобится.