Консольный сервер

1. Проблема

У вас есть компьютерный зал с множеством UNIX®-серверов и коммуникационным оборудованием. Каждой этой машине необходима последовательная консоль. Однако последовательные терминалы трудно найти и они достаточно дороги (особенно по сравнению с ПК, обладающими гораздо большими возможностями). И всё это в компьютерном зале занимает много места.

Вам необходим доступ к консоли, потому что когда что-то не работает, сообщения об ошибках направляются туда. И некоторые работы выполняются с консоли (к примеру, при возникновении проблем с загрузкой или при установке или обновлении ОС). Некоторые UNIX-системы позволяют переходить с консоли в режим монитора ПЗУ, который иногда является единственным способом заставить функционировать неработающую машину. Часто это осуществляется посылкой LINE BREAK на последовательный порт консоли.

Если мы собираемся поработать с консолями, то было бы великолепно осуществить ещё несколько вещей:

• Удалённый доступ. Даже в одном помещении было бы неплохо иметь доступ ко всем консолям с вашего рабочего места без необходимости передвигаться по компьютерному залу. А иногда машины расположены где-то далеко, может быть, даже в другой стране.

• Протоколирование. Если что-то идёт не так, вам не помешает возможность посмотреть предыдущую выдачу на консоль, чтобы понять происходящее. Обычные консольные экраны дают вам последние 25 строк. Чем таких строк будет больше, тем лучше.

• Независимость от сети. Решение должно функционировать даже при неработающей сети. В конце концов, больше всего консоли вам нужны именно при отключении сети! Ещё лучше добиться независимости от сети с возможностью удалённого доступа.

• Отсутствие одной точки, критичной для работы. Консольная система, которая приводит к неработоспособности всех машин при сбое, не нужна. Это особенно важно при использовании с UNIX-хостами Sun, так как они будут воспринимать выключение терминала как BREAK и будут переходить в режим ROM-монитора.

• Интерфейс с пейджинговым или другим подобным устройством подачи предупреждающих сообщений.

• Возможность удалённого выключения и повторного включения машин.

• Не слишком высокая стоимость. Ещё лучше, если система будет бесплатной!

2. Возможные решения

Если для ваших серверов вы используете ПК-оборудование, то одним из возможных решений является ''KVM-переключатель''. Такой KVM-переключатель позволяет использовать одну клавиатуру, видеомонитор и мышь с несколькими системными блоками. Это снижает остроту проблемы с физическим пространством, однако работает только с ПК-оборудованием (а не с любыми типами имеющихся коммуникационных устройств), и не обеспечивает доступ вне компьютерного зала. При этом даже отсутствует прокрутка истории или протоколирование, и вам нужно организовывать оповещение каким-то другим способом. Большим минусом является то, что это не работает с устройствами только с последовательным интерфейсом, таким, как коммуникационное оборудование. Это означает, что даже в зале, заполненном ПК-серверами, вам может оказаться нужным доступ к последовательной консоли.

Вы можете попытаться обойтись без консольного терминала, однако когда творятся странные вещи, вам действительно нужно видеть происходящее на консоли. И вам нужно использовать консоль для загрузки и выполнения таких действий, как установка или обновление ОС.

Вы можете попытаться выделить один консольный терминал и переключаться при необходимости между серверами, либо при помощи последовательного переключателя, либо просто подключая его к нужной машине. Последовательные переключатели также трудно найти и они не дёшевы, к тому же могут иметь проблемы с посылкой сигнала BREAK при переключении. И (если ваш компьютерный зал похож на наш) у вас никогда не будет совпадать комбинация кабелей для подключения к нужной машине, и даже если все кабели на месте, вы никогда с точностью не будете знать, какая именно комбинация окончаний DTE/DCE ведёт к конкретному оборудованию. Так что первые 10 минут вы потратите на возню с исходящими и входящими окончаниями, тогда как сервер не работает, а пользователи уже кричат. Конечно, это не удовлетворяет требованиям удалённого подключения к системе и протоколирования. И неизбежно консоль окажется не подключенной к нужной машине, так что вы потеряете все консольные сообщения, могущие рассказать вам о происходящем.

Одним из распространённых решений является использование аппаратного терминального сервера. Обычно последовательные порты подключены к консолям различных машин, и настроены на ''обратный telnet-доступ''. Это значит, что пользователь может подключиться по протоколу telnet к определённому IP/порту и оказаться подключенным к соответствующей консоли. Это может быть очень эффективным с точки зрения стоимости, так как подходящие старые терминальные серверы можно найти по достаточно низкой цене (полагаем, что пары таких у вас ещё нет). И, конечно, они доступны по сети, что подходит для организации управления из сети. Однако у них есть один большой недостаток: если сеть не работает, то вы теряете доступ к любой консоли, даже если находитесь прямо перед машиной. (Это может быть несколько не так, если у вас есть подходящий терминал, подключенный к одному из портов терминального сервера, с которого можно выполнять подключения, но программное обеспечение терминального сервера может этого и не поддерживать.) К тому же при этом отсутствует протоколирование и повтор консольных сообщений. Однако приложив некоторые усилия и используя определённое программное обеспечение, такое, как conserver (описано далее), эту систему можно заставить хорошо работать.

Ещё один подход, предложенный Броном Гондваной (Bron Gondwana), похож на описанное выше решение. Если ваши серверы имеют несколько последовательных портов, вы можете подключить каждый свободный последовательный порт к консольному порту ''ближайшего'' сервера, создав тем самым кольцо консольных соединений (в некотором порядке). Это может достаточно хорошо работать вместе с программным обеспечением conserver, однако, с другой стороны, может несколько запутывать (в смысле необходимости запоминания, какой порт к какой консоли подключен). И этого не получится, если вам нужно использовать последовательные порты в других целях (таких, как подключение модемов) либо на ваших машинах нет свободных портов.

Либо, если ваш бюджет превышает необходимость в хакерских решениях, вы можете приобрести одно из готовых решений. Они различаются по стоимости и своим возможностям. Посмотрите, к примеру, Lightwave, Perle, Avocent или Black Box. Эти решения могут оказаться достаточно дорогими - обычно от 100 до 400 долл. США за порт.

3. Наше решение

В свете требований выше мы выбрали решение на основе выделенного ПК под управлением UNIX с многопортовым последовательным адаптером и определённым программным обеспечением, предназначенным для работы с последовательными консолями.

Оно состоит из следующих элементов:

• Подержанный ПК. Мы использовали Pentium® 166 с шиной PCI, 2-гигабайтным жёстким диском и 64 мегабайтами ОЗУ. Это превышает требования выполняемой задачи, более чем достаточным будет P-100, 500 Мб, 32 Мб.

• UNIX-система для ПК. Мы использовали FreeBSD 4.3, так как в нашем офисе она использовалась и для других задач.

• Многопортовый последовательный адаптер. Мы выбрали 8-портовый адаптер EasyIO™ PCI компании Stallion Technologies. Это стоило нам порядка $AUD740, меньше чем $100 за порт, заплаченных Harris Technologies (у них есть много всего, но это не обязательно самое дешёвое место - поищите поблизости, вы можете найти место гораздо дешевле). Адаптер имеет сзади большой разъём DB80 и подключаемый кабель, имеющий блок из 8 гнёзд RJ-45. (Мы выбрали вариант с RJ-45, так как наша кабельная система полностью построена на RJ-45. Это позволяет нам переключать соединения от нужного блока к консольному серверу без дополнительных кабелей.) Это единственная вещь, которую нам пришлось приобрести, чтобы всё заработало.

  Замечание: В России, возможно, будет проще найти карты Omega PCI компании КБ "Кроникс" / Cronyx Engineering, менее $40 за порт. [прим. перев.].

• Мы построили два сервера, по одному для каждого машинного зала, с 8 портами в одном и 16 портами (двумя адаптерами EasyIO PCI) в другом. Если бы нам нужно было более 16 портов, то по стоимости более эффективным было бы использование других адаптеров Stallion. Теоретически мы можем поддерживать 128 портов на каждом сервере (при помощи 2 хост-адаптеров EasyConnect 8/64 и 8 16-портовых модулей RJ-45) общей стоимостью $AUD12,000.

• Модем для удалённого доступа к хосту консольного сервере при отсутствии сети. Мы ещё этого не делали, так как компьютерный зал находится рядом, но когда мы перенесем сервер в Сидней, мы добавим модем. Идея заключается в том, что при отсутствии сети вы можете позвонить, подключиться к серверной машине и запустить консольную программу локально. В целях безопасности мы, скорее всего, оставим модем выключенным, и попросим тамошних жителей Сиднея нажать хорошо видную кнопку при необходимости.

• Программа под названием conserver. Она выполняет всё, что требуется для включения удалённого доступа к консолям, обеспечивает повтор ввода, протоколирование и так далее. Она поставляется в виде двух блоков: сервер под именем conserver, работающий как даемон и подключающийся к последовательным портам, выполняющий ведение журналов и прочие действия, и клиентская программа под названием console, которая может подключаться к серверу, показывать консольные сообщения, посылать последовательности нажатий клавиш (и BREAK) и тому подобное.

Такая архитектура обеспечивает выполнение всех основных требований, кроме удалённого управления электропитанием:

• Удалённый доступ обеспечивается за счёт того, что клиентская программа console работает в сети.

• Протоколирование ведётся программой conserver.

• Если сеть не работает, то мы можем использовать консоль ПК для локального запуска клиента console. В случае географически удалённых мест мы можем добавить модем для коммутируемого доступа к командной строке сервера для запуска клиента.

• Установив патчи на серверы Solaris™ (обратитесь к Разд. 6), мы можем избежать неработоспособности всего компьютерного зала при сбое в консольном сервере на базе ПК (или при отключения электропитания, или по какой-то другой причине).

• У нас уже есть пейджинговое оповещение с другой установленной нами системы, однако на консольном сервере есть вся нужная информация журналов, так что при необходимости это может быть легко реализовано. И даже есть модем для звонка в пейджинговую компанию!

• На данный момент мы не поддерживаем удалённое управление электропитанием. Некоторые версии программы conserver это поддерживают, но это требует наличия специальных адаптеров, управляемых через последовательные соединения. У нас нет острой необходимости по удалённому выключению (у нас есть обслуживающий персонал в каждом удалённом офисе, который может это сделать под нашим руководством), так что это не большая проблема, и мы можем легко это добавить, если увидим в этом необходимость и получим соответствующее оборудование.

• Это решение было очень дешёвым. Общая стоимость 9-портового сервера составила $AUD750 за адаптеры ввода/вывода, так как мы использовали устаревший ПК и у нас имелось оборудование в виде специальных кабелей. Если бы мы всё покупали, то это обошлось бы всего лишь примерно в $AUD1500 за 8-портовый сервер.

4. Настройка сервера

# cd /dev/ && sh MAKEDEV cuaE0

# make DEFAULTHOST=consolehost install

% ./configure --with-master=consoleserver --with-port=782

LOGDIR=/var/log/consoles
gallows:/dev/cuaE0:9600p:&:
roo:/dev/cuaE1:9600p:&:
kanga:/dev/cuaE2:9600p:&:
%%
allow:  itga.com.au
trusted:	127.0.0.1 buzz

@rands = ();
foreach (0..4) {
	push(@rands, rand 64);
}

$salt = join '', ('.', '/', 0..9, 'A'..'Z', 'a'..'z')[@rands];

$salt = '$1$' . $salt . '$';

print 'Enter password: ';
`stty -echo`;
$cleartext = <>;
`stty echo`;
chop($cleartext);
print crypt($cleartext, $salt), "\n";

% openssl passwd -1
Password: password
$1$VTd27V2G$eFu23iHpLvCBM5nQtNlKj/

cuaE0	"/usr/local/sbin/conserver"	unknown	on	insecure

#!/bin/sh
#
# Startup for conserver
#

PATH=/usr/bin:/usr/local/bin

case "$1" in
	'start')
		TTY=/dev/cuaE7
		conserver -d > $TTY
		# get NL->CR+NL mapping so msgs look right
		stty < /dev/cuaE7 opost onlcr
		echo -n ' conserver'
		;;

	'stop')
		kill `cat /var/run/conserver.pid` && echo -n ' conserver'
		;;

	*)
		echo "Usage: $0 { start | stop }"
		;;

esac
exit 0

#
# The log files from conserver
/var/log/consoles/gallows	644  10    1000 *     Z /var/run/conserver.pid
/var/log/consoles/kanga		644  10    1000 *     Z /var/run/conserver.pid
/var/log/consoles/roo		644  10    1000 *     Z /var/run/conserver.pid

5. Подключение кабелей

Это всегда является самой сложной частью такого рода проблем. Для построения у нас имелось только около десятка кабелей/окончаний к ним, и ещё набор соответствующих инструментов и оборудования, так что мы сделали всё сами. Однако если вы к этому не готовы, либо вам нужно сделать большое количество кабелей, то вам можно приобрести их на заказ. Посмотрите справочники фирм, там найдётся на удивление много мест, где сделают всё нужное! Приобретение кабелей, сделанных на заказ, это хорошо, и вы получите более профессиональный результат, однако это может быть дороговато. К примеру, наборы переходников RJ-45 в DB-25, описываемые ниже, стоят около $10 каждый; кабели на заказ обойдутся примерно в два раза дороже (и будут доставлены через несколько недель). Подобным же образом изготовление переходника RJ-45 в RJ-45 обойдётся достаточно дёшево (скажем, по $5 каждый), но займёт много времени. Заказное гнездо RJ-45 с переходником RJ-45 стоит около $25 каждое.

Во всех случаях в офисе и компьютерном заде мы использовали кабель типа RJ-45 Cat-V. Сюда включается проброс монтажных кабелей между стойками в компьютерном зале. Для последовательных соединений мы используем подключаемые соединители, у которых на задней стенке есть гнёзда RJ-45. Это позволяет нам при необходимости организовывать соединения RJ-45–DB-25.

Которое также удобно, потому что есть множество неправильных способов организовать последовательные соединения на вилке RJ-45. Так что при пробросе кабелей нужно очень осторожно использовать правильное соответствие.

6. Про системы Sun и сигнал Break

Всякий, кто хоть раз выключал терминал, используемый в качестве консоли для сервера Sun, знает, что происходит в результате и почему это является проблемой. Оборудование Sun считает сигнал BREAK на консоли командой остановить систему и вернуться в монитор загрузчика. Сигнал BREAK — специальный срочный сигнал последовательного порта, заключающийся в активизации (установки в уровень ниже -5 В) сигнала TxD на время большее чем требуется на передачу двух символов (около 2 мс для скорости 9600 bps). К сожалению, этот сигнал часто возникает при включении или выключении коммуникационного оборудования. В частности, карты Stallion также генерируют BREAK при отключении питания компьютера. Если не предпринимать специальных действий, это может привести к остановке всех серверов Sun, подключенных к консольному серверу, при его отключении (при отказе блока питания, или в результате неосторожных действий оператора, или по еще каким-либо причинам). Ясно, что такая ситуация неприемлема.

К счастью, у компании Sun есть набор исправлений. Для ОС Solaris версии 2.6 и более поздних, при помощи команды kbd(1) можно запретить переход в монитор загрузчика по сигналу BREAK. Это уже неплохо для начала, но лишает вас шансов восстановить повисшую машину, вернув ее в загрузчик.

Начиная с Solaris версии 8, команду kbd можно использовать для установки альтернативной последовательности прерывания: kbd -a alternate. После активации, для возврата в монитор загрузки необходимо в течение 5 секунд выдать последовательность: Return ~ Ctrl-B. Эта возможность может быть включена на постоянной основе путем редактирования файла /etc/default/kbd; подробнее см. справочную страницу kbd(1). Отметим, что альтернативная последовательность активируется после перехода ядра в многопользовательский режим и обработки файла начальных установок. В период начальной загрузки (включение питания и в процессе загрузки ядра) и в однопользовательском режиме для возврата в монитор загрузки нужно использовать сигнал BREAK. Из консольного клиента его можно активировать последовательностью Esc c l 1.

Если у вас есть сервисный контракт с компанией Sun, вы можете скачать патчи, реализующие альтернативную последовательность прерывания, для Solaris версий 2.6 и 2.7. Solaris 2.6 требует патча 105924-10 или выше; Solaris 2.7 — 107589-02 или выше.

Мы применили этот патч на всех наших серверах Solaris 2.6 и добавили его (вместе с установкой для файла /etc/default/kbd) в стартовую конфигурацию, так чтобы любой новый сервер автоматически был правильно сконфигурирован.

Наши тесты показали, что ни маршрутизаторы Cisco 16xx, 26xx, ни коммутаторы Catalyst не подвержены проблеме сигнала BREAK, возникающего при потере питания картой Stallion. В настоящее время маршрутизаторы и коммутаторы Cisco реагируют на сигнал BREAK только в течение первых 30 секунд после включения питания или перезагрузки.

7. Использование последовательной консоли в FreeBSD

Подробно эта процедура описана в отдельной главе Руководства FreeBSD. Здесь мы приводим краткий перечень.

ttyv1   "/usr/libexec/getty Pc"	 cons25  on  secure

ttyd0   "/usr/libexec/getty std.9600"   dialup  off secure

ttyd0   "/usr/libexec/getty std.9600"   vt100   on secure

8. Соображения безопасности

Протокол "клиент-сервер" утилиты conserver требует от пользователя клиентской утилиты console ввода пароля. Этот пароль передается по сети в открытом виде! Как следствие, утилита conserver не особенно пригодна для использования в небезопасных сетях (в том числе в интернет). Использование уникальных паролей для conserver слегка смягчает проблему, однако любой, кто способен прослушать сетевой трафик между клиентом и сервером conserver, может легко получить консольный доступ, а с консоли использовать последовательность прерывания. Для удаленной работы используйте какие-либо защищенные протоколы, такие как SSH для регистрации на консольном сервере и запускайте консольный клиент непосредственно оттуда.

9. Различные версии Conserver

Программа conserver расслоилась на несколько независимых версий. Сайт, упоминаемый ниже, судя по всему, содержит последнюю и наиболее полную версию из доступных. На момент написания статьи (июль 2004 г.) это версия ''8.1.9''. Сайт поддерживается Брайаном Стэнселлом (Bryan Stansell), <bryan@conserver.com>, который свел воедино работу многих разработчиков (перечислены на его сайте).

Коллекция портов FreeBSD содержит conserver версии 8.5 в каталоге comms/conserver. Судя по всему, он более старый, и содержит меньше возможностей, чем 8.1.9 (в частности, не поддерживает консоли, соединенные с портами терминальных серверов, или файл паролей conserver.passwd), а также написан довольно своеобразно (используя препроцессор для генерации исходного текста на языке C). Версия 8.5 ведется Кевином Браунсдорфом (Kevin S. Braunsdorf) <ksb+conserver@sa.fedex.com>, в прошлом основным автором conserver; Брайан основывался на его разработках. Версия 8.5 поддерживает одну возможность, не поддерживаемую 8.1.9: управление питанием удаленных машин через специальный контроллер, управляемый по последовательному порту.

Начиная с декабря 2001 г., версия Брайана (в настоящее время 8.1.9) присутствует в дереве портов в каталоге comms/conserver-com. Мы рекомендуем использовать именно ее как более подходящую для построения консольного сервера.

10. Ссылки

11. Справочные страницы

• console(8)

• conserver(8)

• conserver.cf(5)