07.05.2009

Установка Linux® на сервера IBM® System Z обычно проходит довольно легко, но неприятности все же бывают. Если у вас возникли трудности, попробуйте воспользоваться нашими советами по устранению следующих досадных ошибок при запуске Linux на системах S/390: сообщения «route-unknown», неправильная работа сетевого сервиса, повреждение файловой системы при выключении, слишком долгое определение устройств при загрузке, установка аппаратных средств виртуальной сети. Дополнительный бонус: предупреждение (и руководство по устранению) о двух проблемах в SUSE.

Linux — одна из операционных систем, широко используемых на платформе IBM S/390 (также известной как System Z), поскольку она позволяет консолидировать унаследованное ПО, Linux-программы и промежуточное ПО — Web, почту, серверы приложений, брандмауэры и т. д. Работая как нативная операционная система, Linux полностью использует аппаратную функциональность платформы S/390.

В этой статье мы делимся решениями для пяти ситуаций, которые могут возникнуть при использовании Linux на серверах серии System Z:

1. Защита от вторжения марсиан: "марсианские пакеты" — это пакеты с неизвестным маршрутом источника.
2. Управление сетевыми сервисами во время перезагрузки: иногда после запуска образа Linux на LPAR сетевой сервис не работает.
3. Предотвращение повреждения файловой системы во время выключения машины: существует три механизма, которые могут привести к повреждению файловой системы при выключении машины
4. Извлекаем всё возможное из опции cio_ignore или как уменьшить список устройств, анализируемых во время загрузки
5. Предотвращаем неприятности с VLAN: ищем физическое местоположение установочных файлов.

Эта статья ссылается на некоторые версии SUSE Linux, поэтому в виде бонуса я приведу описание нескольких ошибок в различных версиях SUSE и дам инструкции по их устранению.

1. Марсиане пытаются познакомиться

"Марсианскими" называют пакеты с неизвестным маршрутом к источнику. Получение таких пакетов не ожидается системой Linux, особенно учитывая то, откуда они прибыли (например, пакеты, получаемые от внутренней машины, но приходящие на внешний интерфейс).

Появление "марсианских пакетов" может быть спровоцировано неправильной конфигурацией (например, внутреннему сетевому интерфейсу назначен внешний IP адрес), неверной маской сети или подменой адреса (возможно, кто-то пытается сделать что-то нехорошее в вашей системе). Нужно обязательно проверить настройки системы и внести исправления, чтобы ликвидировать подобные сообщения.

Иногда такие пакеты генерируются коммутатором, особенно если к нему подключено много машин. В этом случае "марсианские пакеты", конечно, не являются результатом вредоносной деятельности, но тем не менее засоряют консоль с системным журналом. Чтобы от них избавиться, достаточно перезапустить коммутатор, но помните, что вы отключите от сети все машины, подключенные к этому коммутатору. А ведь некоторые серверы могут быть слишком важными, чтобы решать проблему таким способом.

Проблема: Переполнение системных журналов

Отладка с помощью сообщений системных журналов может стать очень трудоемким процессом, если приходится пробираться через кучу "марсианских пакетов" (см. рис. 1)

Решение: скроем маленького зеленого человечка

Очистить консоль ОС и скрыть сообщения о "марсианских пакетах" можно одним из следующих способов:

• Отключить журналирование пакетов

/proc/sys/net/ipv4/conf/eth0/log_martians 
Ex: echo "0" > /proc/sys/net/ipv4/conf/eth0/log_martians

• Понизить уровень журналирования в ядре до четвертого:

yast -> system -> /etc/sysconfig Editor -> System -> Logging -> KERNEL_LOGLEVEL (с 7 до 4)
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|

2. Плохое сетевое соединение, встаньте в угол!

После того как образ Linux на LPAR загружен, иногда можно обнаружить, что сетевая служба работает не так, как ожидается; даже при наличии IP адреса сеть может быть недоступна.

Проблема: пинг есть, авторизации нет

Пинг из консоли до соседней машины в сети проходит хорошо, и ipconfig выдаёт правильные данные, но когда вы пытаетесь авторизоваться (по ssh или telnet) с помощью программы putty, сессия недоступна.

Решение: перезапуск сетевых соединений

Пользователь root может перезапустить сетевые соединения, выполнив в консоли команду service network restart, как показано в листинге 1.

j8806_h117 (root): /opt/javabm/data >service network restart
Shutting down network interfaces:
 eth0
 eth0 configuration: qeth-bus-ccw-0.0.0420 done
Shutting down service network . . . . . . . . . . . . . done
Hint: you may set mandatory devices in /etc/sysconfig/network/config
Setting up network interfaces:
 lo
 lo IP address: 127.0.0.1/8 done
 eth0
 eth0 configuration: qeth-bus-ccw-0.0.0420
 eth0 IP address: 9.12.22.25/24 done
 vlan538
interface is not available
SIOCGIFFLAGS: No such device
Cannot enable interface vlan538.
interface vlan538 is not up failed
Setting up service network . . . . . . . . . . . . . . failed
SuSEfirewall2: Warning: ip6tables does not support state matching. 
 Extended IPv6 support disabled.
SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
SuSEfirewall2: batch committing...
SuSEfirewall2: Firewall rules successfully set

Эту команду может запустить только root. Если обнаружится, что шлюз указан неверно или вообще отсутствует, то потребуется внести необходимые изменения и перезапустить сеть. Это можно сделать с помощью следующих команд:

1. route add default gw 9.12.44.1
2. service network restart

В листинге на рисунке 2 приведены все шаги, необходимые для установки и запуска сетевых соединений. В случае, если сеть не поднимается, IP-адрес не будет отображен. Он указывается в файле /etc/sysconfig/network/ifcfg-eth-id-XX:XX:XX:XX:XX — там же указываются настройки VLAN и настройки брандмауэра. Вывод можно использовать для диагностики всех этапов настройки, если с сетью что-то не в порядке.

Чтобы изменения в любом из сетевых конфигурационных файлов (/etc/sysconfig/network/ifcfg-eth-id-XX:XX:XX:XX:XX, /etc/sysconfig/hardware/ifcfg-eth-id-XX:XX:XX:XX:XX и т.д.) вступили в силу, необходимо выполнить команду service network restart или /etc/init.d/network restart).

Выносим приговор неисправностям файловой системы

Иногда при завершении работы системы файловая система может быть испорчена по нескольким причинам:

• Работа образа системы Linux остановлена некорректно
• Файловые системы некорректно размонтированы
• Корневая файловая система заполнена на 100 процентов

В таких случаях запустить образ при последующей загрузке будет невозможно.

3. Проблема: входить или не входить

Давайте рассмотрим два сценария выхода из строя файловой системы:

1. 1.Повреждена сама корневая файловая система (/dev/dasda1). В этом случае нет доступа к командному интерпретатору системы.
2. 1.Повреждена другая, не корневая файловая система. В этом случае у нас есть доступ к командному интерпретатору, а также будут смонтированы все неповрежденные файловые системы.

Решение: запускаем fsck, хочет он того или нет

Единственное решение для обоих сценариев — это запустить fsck, как показано ниже:

1. Проблему, описанную в первом сценарии, можно разрешить, подняв корневой раздел (с помощью команды chccwdev -e <устройство_DASD>) на существующем образе Linux и принудительно запустив fsck Это принудительно запускает проверку файловой системы, помеченной как исправленная. Например: fsck -f /dev/dasdx1 (где x подразумевает букву недавно добавленного added dasd, для которого будет выполнена fsck).
2. Во втором сценарии fsck для поврежденной файловой системы запускается из командной строки, после авторизации. После проверки всех поврежденных устройств системе потребуется перезагрузка, после чего образ вернется к полноценной работе.

4. Сокращаем список для ускорения работы

Параметр ядра cio_ignore используется для анализа и определения всех доступных устройств, подключенных к машине. При загрузке Linux пытается определить и проанализировать все доступные устройства.

Параметр cio_ignore можно использовать, чтобы сократить список опрашиваемых устройств в процессе загрузки.

Проблема: очень долгая загрузка

В System z образ загружается довольно долго, поскольку к машине, как правило, подключается множество устройств (DASD, сетевые устройства и т. д.), необходимых для загрузки различных образов. Вне зависимости от того, нужно ли устройство образу или нет, система будет опрашивать и анализировать каждое из возможных устройств во время загрузки, тем самым замедляя процесс.

Решение: закомментировать некоторые или все устройства, стоящие в очереди

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

• cio_ignore=all: игнорируются все устройства
• cio_ignore=all, !0.0.b100-0.0.b1ff, !0.0.a100: игнорируются все устройства, кроме диапазона адресов от 0.0.b100 до 0.0.b1ff, и устройство с адресом 0.0.a100. (Настройка очень гибкая!)

5. Находим физические файлы для виртуальной сети

Виртуальная сеть — это группа устройств, входящих в одну или несколько сетей, настроенных (с помощью управляющего ПО) для взаимодействия друг с другом, чем создаётся иллюзия подключения к общему физическому коммутатору (хотя на самом деле они расположены в разных сегментах локальной сети).

Вследствие их логического, а не физического объединения виртуальные сети обладают невероятной гибкостью. Фреймы VLAN полностью аналогичны фреймам Ethernet, за исключением одного дополнительного поля, содержащего идентификационный номер виртуальной сети. Этот номер называется маркером VLAN.

Проблема: где же в действительности находится маркер?

Свежая установка Linux (SuSE или RedHat) на сервере System z не возможна, если для него настроена VLAN и нет доступа к невиртуальному OSA-порту (Ethernet-интерфейс для System z).

Новая система Linux (SUSE) на раздел LPAR обязательно ставится по сети. Машину с LPAR (z-машину) необходимо соединить точно с тем сервером, на котором расположены установочные файлы. Перед началом установки система задаёт несколько вопросов для настройки сети, ни один из которых не указывает на то, где можно настроить соединение для работы в существующем сегменте VLAN. Если машина (z-сервер) уже настроена для работы с VLAN, то она будет принимать только пакеты с конкретным маркером VLAN

Решение: сначала устанавливаем, затем настраиваем

Ни Suse ни RedHat не поддерживают настройку VLAN на сетевом интерфейсе во время установки, поэтому единственным решением здесь будет настроить обычное сетевое соединение, установить систему и затем уже настроить VLAN.

Перед новой установкой в системе не должно быть оборудования, помеченного как VLAN. Во время установки не нужно настраивать аппаратуру для подключения по VLAN.

Бонус: обзор двух ошибок SuSE

И, наконец, две специфичные для SuSE ошибки, о которых следует знать.

Ошибка 1: проблемы с маркером VLAN на некоторых SLES 9

Первая ошибка относится к SLES 9 с очень старыми GA-ядрами — в них не поддерживаются VLAN-устройства, что может спровоцировать kernel panic (ситуацию, когда система генерирует сообщение об ошибке, сбрасывает образ памяти ядра на диск для "посмертной" отладки и затем ожидает ручной перезагрузки либо инициирует её автоматически). С ядром SLES9 SP4 подобного не происходит.

Ошибка 2: ошибка выполнения Awk скриптов в SLES10

Выполнение Awk-скрипта в SLES10 и SLES10 SP2 вызывает следующую ошибку:

 

rapdistro7:~ # awk -f sample_test.awk get_build.messages
section 1
*** glibc detected *** awk: double free or corruption (fasttop): 
0x0000000080055060 ***
======= Backtrace: =========

......

======= Memory map: ========

......

3ffff952000-3ffff967000 rw-p 3ffff952000 00:00 0 
[stack]
Aborted
rapdistro7:~ #

Тот же самый сценарий прекрасно работает на SLES9. Отчет об этой ошибке был опубликован в bugzilla. И, кстати, решение тут следующее: export LC_ALL = C. В версиях старше SLES10/SP2 ошибка была исправлена.