Автоматизируем тестирование железа с помощью StressLinux::Журнал СА 7.2006
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Архив номеров
Контакты
   

  Опросы
  Статьи

Рынок труда  

Системные администраторы по-прежнему востребованы и незаменимы

Системные администраторы, практически, есть везде. Порой их не видно и не слышно,

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 9878
Комментарии: 0
Потоковая обработка данных

 Читать далее...

19.03.2018г.
Просмотров: 8092
Комментарии: 0
Релевантный поиск с использованием Elasticsearch и Solr

 Читать далее...

19.03.2018г.
Просмотров: 8193
Комментарии: 0
Конкурентное программирование на SCALA

 Читать далее...

19.03.2018г.
Просмотров: 5190
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 5867
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

Друзья сайта  

 Автоматизируем тестирование железа с помощью StressLinux

Архив номеров / 2006 / Выпуск №7 (44) / Автоматизируем тестирование железа с помощью StressLinux

Рубрика: Администрирование /  Автоматизация

Дмитрий Волков

Автоматизируем тестирование железа с помощью StressLinux

На основе компьютера с ОС Linux и StressLinux можно создать инструмент для автоматического тестирования железа всех узлов локальной сети.

Бывают дефекты оборудования, которые могут проявиться только при высоких нагрузках, в этом случае поможет дистрибутив Linux, который может использовать ресурсы ваших комплектующих на 100%. В первую очередь тестирование будет полезно для компьютеров, на которых возлагаются задачи, требующие большой загрузки процессора. Такие компьютеры должны работать 24 часа в сутки и не давать сбоев. Поэтому их как следует нужно проверить на прочность.

В настоящее время существует множество утилит для тестирования железа как из Windows, так из Linux. Но необязательно, что на компьютерах находятся две ОС: Linux и Windows. Поэтому для тестирования удобно использовать дистрибутивы LiveCD. Но такой путь ведет к потере времени, если у вас много хостов, требующих тестирования. Каждый компьютер необходимо загружать с CD/DVD и прогонять тесты вручную, при этом другие узлы сети будут простаивать и ждать своей очереди. Для решения проблемы можно использовать тестирование с загрузкой тестов через сеть по вашему собственному сценарию, при этом все результаты тестирования будут сохраняться на сервере. Что мы и попытаемся реализовать.

На сегодняшний день существует единственный специализированный для тестирования LiveCD-дистрибутив – StressLinux. Он работает только в режиме консоли и занимает порядка 50 Мб, но этого будет достаточно чтобы провести полноценное тестирование. StressLinux содержит основные утилиты для тестирования комплектующих компьютера при высоких нагрузках, утилиты для считывания информации с датчиков процессорной платы, а также обладает высокой гибкостью в настройках сценариев для тестирования. Вы сами сможете задавать сценарии тестирования, добавляя или убирая тесты. В качестве оболочки в StressLinux используется busybox. Она содержит набор общих UNIX-утилит для работы в Linux, позаимствованных из GNU пакетов fileutils, shellutils и т. д. С помощью busybox можно создать ОС Linux, умещающуюся на одну дискету. Подробную информацию о проекте вы можете найти на сайте http://www.busybox.net.

Как насчет гарантии?

Разработчики тестов, входящих в состав StressLinux, сообщают: «Эти программы разработаны для создания высокой нагрузки процессоров, поэтому неохлаждаемые, разогнанные или по другой причине «непрочные» (weak) системы при прохождении тестирования могут вызвать потерю данных (повреждение файловой системы), также есть вероятность нанести повреждения компонентам микросхем».

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

Конфигурация тестового комплекса

Комплекс для тестирования будет состоять из сервера и одной рабочей станции, соединенных в одну сеть.

Требования к рабочей станции – наличие сетевой карты с поддержкой PXE. Список поддерживаемых карт можно узнать здесь: (http://www.bootix.com/adapters/adapters_en.html). В качестве рабочей станции я буду использовать VMWare, так как это удобно для создания скриншотов в моменты загрузки системы. Тесты загружать в VMWare бесполезно, потому что при тестировании будет использоваться только та часть ресурсов, которая выделена под виртуальную систему. Поэтому тестирование надо проводить на реальной машине. А вот настройки загрузки через сеть StressLinux под VMWare проводить очень удобно, не придется бегать от сервера к клиенту и проверять, что же там опять не работает.

Со стороны сервера потребуется:

  • дистрибутив StressLinux;
  • дистрибутив Linux, функционирующий на сервере (я использую ASP Linux 9.0);
  • серверная часть пакетов: pxe, dhcp, tftp, nfs.

Как будет работать тестовый комплекс

Перезапускаем клиентскую машину и в BIOS выбираем загрузку по сети. После перезагрузки сетевая карта будет выполнять поиск dhcp-сервера. Сервер принимает запрос и присваивает клиенту IP-адрес, pxe предлагает выбрать загрузку:

  • Local boot – с жесткого диска;
  • PXELinux – появится меню для выбора загрузки одного из ядер StressLinux, или загрузки отдельного теста, например теста памяти – memtest.

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

Конфигурация сервера

Я использую дистрибутив ASP Linux 9.0 на rpm-пакетах. Вам нужно использовать пакеты, входящие в состав вашего Linux.

Для начала скачиваем последнюю версию дистрибутива StressLinux 0.3.1 с http://www.stresslinux.org/release/stresslinux-0.3.1.pxe.tgz с поддержкой загрузки через PXE. Распаковываем каталог с корневой системой StressLinux (_stresslinux) в директорию на сервере /tftpboot/X86PC/_stresslinux.

Скачиваем http://www.stresslinux.org/release/stresslinux-0.3.1.pxe_sample_configs.tgz архив с примерами конфигурационных файлов pxe, dhcp, tftp, nfs. Распаковываем в каталог /tftpboot/X86PC/pxelinux содержимое из папки pxes. Этот каталог будет использоваться для создания сценариев загрузки рабочих станций через pxe. Каждой рабочей станции можно присвоить свой сценарий загрузки на основе её IP-адреса, за подробной информацией можно обратиться на сайт http://syslinux.zytor.com/pxe.php. Применим одинаковый сценарий загрузки для всех клиентов – default. В файл внесем изменения, указав в nfsroot адрес вашего сервера и расположение корневого каталога _stresslinux. Сервер имеет IP-адрес: 192.168.12.191. После изменений файл /tftpboot/X86PC/pxelinux/pxelinux.cfg/default будет выглядеть так:

default stress

prompt 1

timeout 600

display loader.msg

F1 loader.msg

label stress     # Stresslinux

  kernel ../_stresslinux/boot/vmlinuz

  append rw video=vesafb:640x480-32@75,nomtrr,ywrap root=/dev/nfs \

    nfsroot=192.168.12.191:/tftpboot/X86PC/_stresslinuxip=dhcp hda=scsi hdb=scsi hdc=scsi hdd=scsi

  • default – имя сценария для загрузки по умолчанию;
  • prompt – может принимать значения 1 или 0. Если значение 1, то перед загрузкой будет выведена строка «boot: <Имя загружаемого сценария>». Если же значение 0, то эта строка выводится только при: нажатии <Alt> или <Shift>, или при включенном CapsLock, или Scroll lock;
  • timeout – содержит количество секунд до начала автоматической загрузки;
  • display – параметр, указывающий на файл-приветствие, будем использовать по умолчанию loader.msg:

Welcome to StressLinux Boot Server!

0fTo start the stresslinux distribution enter press ?

    <return>.07

Available boot options:

  stress        - Boot Stresslinux via PXE with initrd

09F1:0f Stresslinux

  • F1 – здесь можно создать файл-help и указать все возможные параметры ядер;
  • label – это имя сценария загрузки, а сценарий может содержать в себе 3 параметра:
  • kernel – путь к ядру Linux или к отдельной загружаемой программе, например memtest;
  • append – список параметров, передаваемых ядру;
  • ippappend – параметр, используемый PXELinux для указания настроек сети. Он нам не нужен, так как предполагаем, что загрузка для всех узлов сети общая. Параметры сети для каждого клиента указывает dhcp сервер. Описание всех возможных конфигураций файла default можно узнать (http://syslinux.zytor.com/faq.php).

Далее будем настраивать dhcp-сервер. Для этого необходимо установить его из вашего дистрибутива Linux, в ASP Linux это rpm – Uvh dhcp-3.0pl1-23.i386.rpm, а если же такого под рукой не имеется, тогда скачиваем его с http://ftp.isc.org/isc/dhcp. На момент написания статьи последней версией была – 3.0.4. Создаем конфигурационный файл /etc/dhcpd.conf, указав MAC-адрес одного из клиентов. Я буду указывать MAC-адрес VMWare. После изменений файл должен выглядеть так:

Subnet 192.168.12.0 netmask 255.255.255.0 {

    option subnet-mask 255.255.255.0;

    default-lease-time 21600;

    max-lease-time 43200;

    host some_host{

           # Указываю MAC-адрес VMWare

           hardware ethernet 00:0C::29:50:84:D7;

           fixed-adress 192.168.12.242;

           option vendor-class-identifier "PXEClient"

    }

}

Надо уделить внимание опции ‘option vendor-class-identifier “PXEClient”’. Она требуется для того, чтобы dhcp передал управление серверу pxe в момент присвоения IP-адреса клиенту, а pxe в свою очередь смог отобразить меню для выбора загрузки (это меню появляется путем запуска бинарного файла pxelinux.0 на сетевой карте). Службы dhcp и tftp можно запустить на разных узлах сети, тогда необходимо добавить в конфигурационный файл параметр next-server, указывающий на имя или IP-адрес tftp-сервера. Мы же будем использовать один хост, поэтому этот параметр не указываем.

Перейдем к настройке предзагрузочной среды запуска – pxe. Для её установки в ASP Linux выполняю rpm –Uvh pxe-0.1-36.i386.rpm, если в вашем дистрибутиве такого пакета нет, то скачиваем с сайта http://www.kano.org.uk/projects/pxe. Изменяем конфигурационный файл /etc/pxe.conf, установив 2 значения:

  • interface – номер интерфейса на сервере, по которому соединены сервер с клиентом;
  • default_address – IP-адрес сервера.

Остальные параметры оставляем без изменений. Вид файла после изменений смотрите на рис. 1.

Рисунок 1. Пример конфигурационного файла pxe.conf

Рисунок 1. Пример конфигурационного файла pxe.conf

Устанавливаем tftp-server, взяв его из дистрибутива (tftp-server-0.33-1asp.i386.rpm) или с http://www.kernel.org/pub/software/network/tftp. Tftp-сервер будет использоваться для передачи ядра и образа ядра клиентам. Запуск его можно реализовать из-под xinetd, для этого в файле /etc/xinet.d/tftp исправить значение параметра disable с «yes» на «no» и убедиться, что в качестве рабочего каталога установлен /tftpboot. А запуск из консоли можно выполнить:

# in.tftpd –v –l –s /tftpboot

Теперь подходим к финальному шагу по настройке загрузки StressLinux – конфигурированию nfs, который будет использоваться для доступа к корневой файловой системе StressLinux загружаемыми станциями.

Устанавливаем nfs-utils, в ASP Linux выполнив rpm –Uvh nfs-utils-1.0.1-2.9.i386.rpm), иначе скачиваем с ресурса http://prdownload.sourceforge.net/nfs). Все настройки nfs сводятся к конфигурации трех файлов:

  • /etc/exports – указывает каталоги, доступные через nfs;
  • /etc/hosts.allow и /etc/hosts.deny – файлы управления доступом к серверу.

Переходим непосредственно к конфигурации nfs-сервера – файлу /etc/exports. Более подробно о настройках nfs можно узнать на http://nfs.sourceforge.net/nfs-howto. Откроем доступ к каталогу /tftpboot/X86PC/_stresslinux на чтение и запись для всех узлов сети 192.168.12.0/24, указав строку:

/tftpboot/X86PC/_stresslinux 192.168.12.0/255.255.255.0 (rw,insecure,sync,no_root_squash)

Теперь запускаем программы dhcpd, pxe, tftp, nfs. Перезагружаем клиента и выбираем загрузку по сети, в результате появится приглашение (см. рис. 2).

Рисунок 2. Приглашение для выбора варианта загрузки

Рисунок 2. Приглашение для выбора варианта загрузки

Выбираем PXELinux (см. рис. 3). Отображается меню StressLinux для выбора загрузочного ядра в нашем случае  – это будет одно-единственное 2.6.16. Но это пока, в дальнейшем можно будет расширить список ядер и отдельных программ для тестирования.

Рисунок 3. Отображение содержимого файла loader.msg

Рисунок 3. Отображение содержимого файла loader.msg

Выбираем ядро и загружаемся. Если оно загрузилось успешно, тогда выводится приглашение (см. рис. 4) для ввода логина. Вводим root без пароля.

Рисунок 4. Пример успешной загрузки ядра

Рисунок 4. Пример успешной загрузки ядра

Друг за другом появятся 2 меню для выбора раскладки клавиатуры и выбора процессорной платы соответственно (см. рис. 5, 6).

Рисунок 5. Программа для ручного выбора типа клавиатуры

Рисунок 5. Программа для ручного выбора типа клавиатуры

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

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

Если на вашей процессорной плате есть сенсоры температуры и напряжений, то тогда во время тестирования можно будет наблюдать за состоянием компьютера. Вывод данных реализован программой sensors из пакета lm_sensors. Список поддерживаемых процессорных плат можно узнать на http://secure.netroedge.com/~lm78/supported.html. Для поиска требуемых модулей можно воспользоваться программой sensors-detect.

В этой версии StressLinux используется ядро 2.6.16. Если вас устраивает это ядро, тогда следующий пункт можно пропустить, если же нет, тогда перейдем к настройке собственного ядра.

Конфигурация нового ядра

Ядро, входящее в дистрибутив StressLinux, не имеет поддержки некоторых SCSI-контроллеров. Поэтому можно использовать собственное ядро с поддержкой всего необходимого железа. При нго конфигурировании необходимо не забыть установить параметр CONFIG_ROOT_NFS, для того чтобы использовать корневую файловую систему nfs. Также можно добавить последнюю версию пакета lm_sensors. Для загрузки нового ядра копируем его в каталог /tftpboot/X86PC/_stresslinux/boot/ и назовем vmlinuz-<номер версии ядра>. Все модули этого ядра копируем в /tftpboot/X86PC/_stresslinux/lib/<номер версии ядра>. Добавляем следующие строки в файл /tftpboot/X86PC/pxelinux/pxelinux.cfg/default:

label  my  # Stresslinux (my kernel)

  kernel ../_stresslinux/boot/vmlinuz-<номер версии ядра>

  append initrd= rw video=vesafb:640x480-32@75,nomtrr,ywrap \

    root=/dev/nfs nfsroot=192.168.12.191:/tftpboot/X86PC/_stresslinux ip=dhcp hda=scsi hdb=scsi hdc=scsi hdd=scsi

Не забываем добавить пункт в файл loader.msg. Перезапускаем клиента и выбираем созданное ядро.

Список доступных утилит для тестирования

Список основных утилит представлен в файле /tftpboot/X86PC/_stresslinux/etc/motd (см. рис. 7).

Рисунок 7. Список программ для тестирования с кратким описанием

Рисунок 7. Список программ для тестирования с кратким описанием

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

  • серию программ для высокой загрузки процессоров – burn-оптимизированных под разные процессоры (http://pages.sbcglobal.net/redelm);
  • stress – используемую в качестве инструмента для установки определенной загрузки процессора, памяти, ввода/вывода, жесткого диска (http://weather.ou.edu/%7Eapw/projects/stress);
  • netio – для тестирования производительности сети;
  • smartctl – для тестирования устройств с поддержкой S.M.A.R.T.;
  • lshw – для сбора информации обо всей системе;
  • x86info – информация о процессорах;
  • программы мониторинга – hddtemp, sensors.

Сценарии тестирования

Для создания сценария достаточно создать скрипт на bash или другом языке программирования и указать его выполнение в файле /tftpboot/X86PC/_stresslinux/etc/bash.bashrc.

Создадим сценарий – test.sh и разместим его в /tftpboot/X86PC/_stresslinux/etc/init.d/. Предполагаем, что компьютеров для тестирования будет много, поэтому результаты прохождения тестов для каждого узла будем сохранять в отдельную папку, в качестве имени папки будем использовать IP-адрес этого узла. Реализовать это можно следующим образом:

#!/bin/bash

// Получаем IP-адрес узла

IP=`ifconfig|grep inet|perl -nle @ar=split(/\s+/,$_);@ar2=split(/\:/,\\$ar[2]); print \\$ar2[1]`

// Создаем каталог, если такого еще не существует

if[ ! -d /home/result/$IP ]

then

echo

Making results dir /home/result/$IP

/bin/mkdir -p result/$IP

fi

// все результаты тестирования будем записывать сюда

cd /home/result/$IP

Далее загружаем модули для вывода информации, модули для вашей процессорной платы можно определить с помощью скрипта detect-sensors.

VAL=`/sbin/lsmod | grep i2c-isa`

if [

x$VAL

 ==

x

 ]

then

echo

trying insert module i2c-isa

modprobe i2c-isa

fi

Перед тестированием собираем информацию об узле и сохраняем ее на сервере:

echo

Collecting information

# собираем информацию о PCI-устройствах

/sbin/lspci | tee lspci

sleep5

# собираем информацию о процессорах

/usr/bin/x86info | tee x86info

sleep5

# собираем расширенную информацию о системе

/usr/bin/lshw | tee lshw

sleep5

Программа tee выдает результаты на экран и одновременно записывает в указанный ей файл на сервер.

Переходим к тестированию. В этой части сценария каждый волен запускать свои тесты, я же приведу пример одного из тестов на вычисление квадратного корня программой stress:

TM=20 # Таймер

echo

Starting 1st test

 | tee stress1

echo

Spanning 10 workers spinning on sqrt()

| tee -a stress1

echo

waiting for $TM seconds

| tee -a stress1

/usr/bin/stress -v -c 10 -t $TM | tee -a stress1 &

Запускаем stress с порождением 10 процессов на период, указанный в переменной $TM, равной 20 секундам. Результаты сохраняем в файл stress1. Пример успешного завершения теста приведен на рис. 8.

Рисунок 8. Пример успешного завершения теста по вычислению квадратного корня

Рисунок 8. Пример успешного завершения теста по вычислению квадратного корня

В результате видим, что все 10 процессов запустились и завершились успешно, тест был проведен в течение 20 секунд. Если вы загрузили модули для считывания информации с датчиков, то после каждого теста можно использовать функцию, которая будет отображать состояние системы с интервалом в  1 секунду.

sens "Spanning 10 workers spinning on sqrt() stress1" "$TM"

SENSORS=`/usr/bin/sensors | grep 'No sensors found'`

sens()

{

    if [ "x$SENSORS" == "x" ]

    then

      for((i=1;i<=$2;i++))

        do

                /usr/bin/clear

                /usr/bin/sensors

                echo "Time limit $2 s"

                echo "seconds $i $1"

                sleep1

        done

    fi

}

Постоянное отображение состояния системы с периодичностью в 2 секунды можете наблюдать на /dev/tty12. Пример состояния системы во время тестирования представлен на рис. 9.

Рисунок 9. Пример считывания информации с датчиков процессорной платы

Рисунок 9. Пример считывания информации с датчиков процессорной платы

Напутствие

На этом базовую настройку автоматического тестирования можно считать законченной, но это совсем не значит, что  ничего больше сделать нельзя.

Дальнейшая функциональность тестирования может быть расширена добавлением других программ в составе StressLinux, и не только. Например, можно добавить образы дискет загружаемых по сети для конфигурирования сетевых карт 3com или позаимствовать некоторые dos-утилиты для восстановления mbr из дистрибутива Ultimate Boot CD. Дальнейшие улучшения будут зависеть только от ваших фантазий и времени, которое вы можете затратить.

Желаю успешного тестирования!


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru