Планирование эксплуатационного обслуживания сервера (продолжение)

Для того чтобы эффективно работать с пользователями, системный администратор должен знать, какими прикладными программами пользуются в своей повседневной работе пользователи Х-терминалов. Для автоматического составления такого списка можно воспользоваться нехитрым сценарием на языке Perl, который необходимо запустить на выполнение в фоновом режиме:

#!/usr/bin/perl -w

my $log_dir = 'udata/';
my %user_tasks = ();
$|=1;

print "Logging all user tasks\n";
while(1) {
    # Получаем список уникальных процессов
    my @procs = `ps axh -o "user comm" | sort | uniq`;
    for (@procs) {
	my ($user, $ps_name) = split /\s+/;
	${ $user_tasks{$user} }{$ps_name} = 1;
    }

    # Цикл по процессам пользователей
    for (keys %user_tasks) {
	my %task_by_user = %{ $user_tasks{$_} };
	my $fn_save = $log_dir.$_;
	open (FUTASK, ">$fn_save") or die "Can't save file $!\n";
	print FUTASK join ("\n", sort keys %task_by_user);
	close(FUTASK);
    }
    print '.';
    sleep 30;
}

Его запуск приводит к сбору статистики о процессах, выполняемых от имени всех пользователей системы, при этом статус суперпользователя вовсе не требуется. Как видно из текста сценария, он с интервалом в 30 секунд записывает в директорию, указанную в переменной $log_dir (в сценарии это каталог udata) файлы, совпадающие по именам с пользователями, работающими в системе. Содержимое этих файлов – список процессов, которые запускал пользователь, например:

$ cat udata/nata
ROX-Filer
icewm
icewm-session
icewmbg
icewmtray
kdeinit
sim
soffice.bin

Для получения более детальной информации о том какие программы, когда и как часто запускают пользователи, необходимо создать более совершенные сценарии. Благо, в распоряжении системного администратора для этих целей в операционной системе Linux есть все средства. Например, если вас интересует информация о том сколько по времени был запущен тот или иной пользовательский процесс, то для ответа на этот вопрос можно использовать предыдущий сценарий, но немного в модифицированной форме:

#!/usr/bin/perl -w

my $log_dir = 'udata/';
my %user_tasks = ();
$|=1;

print "Logging all user tasks and count\n";
while(1) {
    # Получаем список уникальных процессов
    my @procs = `ps axh -o "user comm" | sort | uniq`;
    for (@procs) {
	my ($user, $ps_name) = split /\s+/;
	${ $user_tasks{$user} }{$ps_name}++;
    }

    # Цикл по процессам пользователей
    for (keys %user_tasks) {
	my %task_by_user = %{ $user_tasks{$_} };
	my $fn_save = $log_dir.$_;
	my @result_array = map { $_ . "\t" . $task_by_user{$_}  } sort keys %task_by_user;
	open (FUTASK, ">$fn_save") or die "Can't save file $!\n";
	print FUTASK join ("\n", @result_array);
	close(FUTASK);
    }
    print '.';
    sleep 30;
}

Теперь если взглянуть на содержимое файлов директории udata, можно заметить, что имени процесса соответствует числовое значение частоты присутствия его в виртуальной памяти сервера Х-терминалов. Например, чтобы просмотреть любимые процессы пользователя с именем ula, отсортированные по частоте использования, можно применить такую простую команду (первыми идут те процессы, которые пользователь запускает чаще):

$ sort -k 2 -n -r udata/ula
wombat  246
ssh-agent       246
oafd    246
icewmtray       246
icewm-session   246
icewmbg 246
icewm   246
evolution-alarm 246
bonobo-moniker- 246
ROX-Filer       178
soffice.bin     165
klines  131
kdeinit 131

Разделив число напротив имени процесса на 2 вы получите примерное время работы его на сервере в минутах. Понятно, что процессы завершающиеся за очень короткое время скорее всего не попадут в этот список. К еще одному недостатку данного сценария можно отнести невозможность определения того сколько процессорного времени тратит тот или иной процесс, то есть реально ли работает с этой программой пользователь или просто она запущена в фоновом режиме. Для ответа на этот и другие более сложные вопросы можно обратится к статистическим данным предоставляемым системой /proc.

Если рассмотреть процесс администрирования сервера Х-терминалов и обычного однопользовательского компьютера, то сразу заметным станет главное отличие: работы по администрированию Х-терминал сервера следует выполнять в определенное запланированное время, а для обычного компьютера такого жесткого планирования может и не быть. Чтобы эта идея стала более понятной, приведу реальный случай. Решил я как-то сделать резервную копию пользовательских данных, общих папок и каталога конфигурации системы. Написал для этих целей простенький сценарий и запустил его от имени суперпользователя. Дело происходило в рабочее время и я стал свидетелем того, как работающие в системе пользователи ощутили на себе все "прелести" 20-ти минутного фонового процесса, нагружающего на 100% центральный процессор (программа gzip) и дисковую подсистему (программа tar). Не следует забывать также, что задача работала от имени суперпользователя, а стало быть, имела больший приоритет. Этого горького опыта мне с лихвой хватило, чтобы понять как важно правильно выбирать время для выполнения задач администрирования. За основу принятия решения о необходимости выполнения действий по администрированию, я рекомендую использовать такой алгоритм:

1. Определяем проблему;
2. Вырабатываем метод решения проблемы;
3. Если решение проблемы - процесс не длительный и он не отнимает много системных ресурсов, то применяем его сразу;
4. В противном случае планируем время запуска административного сценариям;
5. Для выполнения задач регулярного администрирования используем утилиту crontab, а для разовых заданий - утилиту at.

Как уже было замечено ранее, для выполнения задач требующих значительных вычислительных ресурсов, лучше подходит ночное время. Чтобы не нагружать сервер Х-терминалов понапрасну, рекомендуется запускать задания в автоматическом режиме в разное время, например, с интервалом в несколько минут.

Кроме администрирования, Х-терминал сервер требует и обыкновенного профилактического обслуживания. Чтобы с аппаратным обеспечением, а как следствие, и программным все было в порядке, необходимо обеспечить приемлемые условия для работы сервера Х-терминалов. Во-первых, сервер должен быть размещен на устойчивой, неподвижной поверхности. Лучше, если это будет специальный шкаф для коммуникационного оборудования. Во-вторых, во избежание выхода техники из строя необходимо обеспечить нормальный температурный режим того помещения, где будет расположен сервер. Никаких фантастических характеристик по температуре и влажности соблюдать не нужно, хватит вполне нормальных условий от 18 до 24 (??? градусов Цельсия). В-третьих, важно бороться с пылью, которая может попасть внутрь корпуса Х-терминал сервера. Сама по себе пыль опасности не представляет, но то, что она проводит электрический ток, а также забивает вентиляторы и мешает циркуляции воздуха внутри корпуса, представляет значительную опасность. Если помещение достаточно запыленное, то хотя бы раз в три месяца рекомендуется производить чистку системного блока Х-терминал сервера. С примером неправильного размещения сервера Х-терминалов вы можете ознакомится на рис. 5.2.

Рис. 5.2. Неправильное расположение компьютеров (слева, сервер Х-терминалов)

Неплохо также иметь средства мониторинга температуры внутри корпуса сервера. Так как перегрев - это причина не только выхода из строя аппаратного обеспечения, а еще и составляющая сложно уловимых ошибок в работе оборудования. Любой дисковый накопитель обязан иметь дополнительное охлаждение. Вентилятор для "винчестера" стоит не дорого и позволяет значительно повысить надежность хранения информации на вашем сервере.

Хорошего администратора от плохого отличает то, что пользователи практически не замечают работы первого. Умение предвидеть проблему до ее появления – это настоящее искусство, которому довольно сложно научиться. Своеобразный парадокс системного администрирования связан с тем, что чем больше времени потратить на настройку системы, тем меньше потом она требует обслуживания. Работа с Х-терминал сервером только подтверждает это правило. Если сервер настроен правильно, то кроме работы с пользователями он практически не требует вмешательства в свои дела со стороны человека. В идеальном варианте вы должны получить самодостаточную систему, администрировать которую одно удовольствие.

По своему опыту знаю, что работа администратора операционной системы Linux содержит меньше рутинных операций, чем, например, администрирование операционных систем win32. Более интенсивное использование командной оболочки позволяет выполнять те же действия, но за более короткое время. Хотите верьте, хотите нет, но после перехода к использованию операционной системы Linux на рабочем месте у меня перестало болеть запястье правой руки (сказывается уменьшение времени использования манипулятора "мышь"). Я снова стал пользоваться клавиатурой! Когда пользователи начали переходить от традиционных персональных компьютеров с Linux к Х-терминалам, то работа по системному администрированию стала еще проще.

Несмотря на то, что администрирование Х-терминал сервера связано с определенными тонкостями и нюансами, неоспоримым остается факт, что обслуживание N пользователей Х-терминалов значительно проще, чем обслуживание N пользователей традиционных персональных компьютеров.

Пока интересно, читаем дальше!