Потребовалось тут подключить два сервера к Nagios`у.
В числе прочих параметров необходимо мониторить состояние Raid массива.
Оба сервера - Centos 5.4

# uname -a
Linux serv.serv 2.6.18-164.2.1.el5.028stab066.10ent #1 SMP Sat Dec 12 13:31:54 MSK 2009 i686 i686 i386 GNU/Linux
# lsb_release -a
LSB Version: :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.4 (Final)
Release: 5.4
Codename: Final


Контроллеры разные: 3ware 9650SE и Adaptec 2405, оба SATA.

Для контроллера 3ware 9650SE все оказалось достаточно просто:

1. Скачиваем с сайта 3ware по ссылке консольную утилиту tw_cli.


2. tar -xzf ./tw_cli-linux-x86-9.5.3.tgz
3. cp ./tw_cli /usr/bin/tw_cli
4. chmod 0550 /usr/bin/tw_cli


tw_cli установлена.

Теперь можем смотреть состояние Raid массива из командной строки, например так:

[serv1]# tw_cli /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
——————————————————————————
u0 RAID-1 OK - - - 298.013 W ON
VPort Status Unit Size Type Phy Encl-Slot Model
——————————————————————————
p0 OK u0 298.09 GB SATA 0 - WDC WD3200AAKS-00B3
p1 OK u0 298.09 GB SATA 1 - WDC WD3200AAKS-00B3


Дальше подключаем утилиту к плагину Nagios`a.

С контроллером Adaptec 2405 возникла небольшая проблема.
Для мониторинга будем использовать утилиту arcconf

1. Для начала качаем пакет Storage Manager с официального сайта (ссылка).

2. Устанавливаем пакет

[serv2]# rpm -ihU asm_linux_i386_v5_10_17173.rpm

Пакет устанавливается в директорию /usr/StorMan

Пробуем запустить :

[serv2]# /usr/StorMan/arcconf

и получаем ошибку:

/usr/StorMan/arcconf: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory


Не хватает библиотеки libstdc++.so.5

3. Ищем в какой пакет входит библиотека libstdc++.so.5

[serv2]# yum whatprovides libstdc++.so.5
compat-libstdc++-33.i386 : Compatibility standard C++ libraries


4. Устанавливаем:

[serv2]# yum install compat-libstdc++-33.i386


Запускаем arcconf:

[serv2]# /usr/StorMan/arcconf GETCONFIG 1
Controllers found: 1
———————————————————————-
Controller information
———————————————————————-
Controller Status : Optimal
Channel description : SAS/SATA
Controller Model : Adaptec 2405
Controller Serial Number : 8B311083165
Physical Slot : 2
Temperature : 79 C/ 174 F (Normal)
Installed memory : 128 MB
Copyback : Disabled
Background consistency check : Enabled
Automatic Failover : Enabled
Defunct disk drive count : 0
Logical devices/Failed/Degraded : 1/0/0
….


Подключаем утилиту arcconf к плагину Nagios`a

все

Потребовалось тут установить php версии 4.3.5 на пятую Centos.
Думалось что задача тривиальная, но оказалось что не совсем.
Во первых - в репозиториях уже нет php4.3.5
Во вторых - так просто и сорсов он не компилился.

Вот об этом “во вторых” подробнее.

Сначала пришлось установить несколько devel пакетов.
В моем случае потребовались следующие:

#yum install gd-devel flex bison httpd-devel libjpeg-devel libpng-devel libxml2-devel libxslt-devel

Затем скачал с php.net нужную версию и приступил к компиляции ( компилировал модулем apache 2.2).

#./configure --with-apxs2=/usr/sbin/apxs --prefix=/usr/local/php --with-mysql --enable-mbstring --with-config-file-path=/usr/local/etc --enable-ftp --enable-libxml --with-dom-xslt --with-libxml-dir=/usr/local --enable-reflection --enable-force-cgi-redirect --enable-fastcgi --with-iconv --with-regex=php --disable-ipv6 --prefix=/usr --mandir=/usr/local/man --infodir=/usr/local/info/ --with-gd=/usr --with-dom --enable-gd-native-ttf=/usr --with-jpeg-dir=/usr --with-png-dir=/usr --with-ttf --with-zlib-dir=/usr --disable-posix --enable-inline-optimization --without-pear --disable-debug

Конфигурация прошла без ошибок а вот make не пошел.
Первая ошибка при make :

sapi_apache2.c:38:25: error: apr_strings.h: No such file or directory
In file included from /home/src/php-4.3.5/sapi/apache2handler/sapi_apache2.c:39:

Лечится это симлинками :

# ln -s /usr/bin/apu-1-config /usr/bin/apu-config
# ln -s /usr/bin/apr-1-config /usr/bin/apr-config

Делаем make clean && make и оппа - вторая ошибка:

....
sapi_apache2.c:38:
/usr/include/apr-1/apr-i386.h:270: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘apr_off_t’

Это исправляется в два действия.
1. Выполняем следующее:

# apr-config –cppflags –cflags

На экран выведется примерно такое :

-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread

2. Копируем эту строку и вставляем ее в файл Makefile.global , в строку DEFS.
Должно получится примерно так:

DEFS = -DPHP_ATOM_INC -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread -I$(top_builddir)/include -I$(top_builddir)/main -I$(top_srcdir)

Опять

# make clean && make && make install

и все. Должно работать

Довольно часто на одном VE сервере должны работать несколько нод, с разным приоритетом (в зависимости от выполняемых задач, тарифных планов и т.п.).

Было опробовано два метода разделения ресурсов.

Первый - жестко задавался CPULIMIT.

Этот метод выделяет ноде как бы виртуальный процессор (в процентах CPULIMIT от реального процессора), то есть нода работает, к примеру, на процессоре 200Mzh .

Второй - CPULIMIT устанавливается в ноль, то есть не ограничевается, но для каждой ноды прописывается ее “удельный вес“, параметр CPUUNITS. Объясню данный метод на примере.

Есть две ноды, одна с критичными задачами, другая - техническая, к примеру, для бэкапов. Первой ноде присваиваем CPUUNITS=200, второй CPUUNITS=100.

В результате получаем следующую ситуацию. При загрузке обоих нод на 100 процентов, первой ноде (CPUUNITS=200) будет выделено 66% процессорных ресурсов, а второй (CPUUNITS=100) - 33% .

Резюме:
Теперь о том что получилось на практике.

При балансировке первым методом каждой ноде выделялось определенное количество процессорных ресурсов, которых с трудом хватало на выполнение задач (apache, mysql). В результате высокий LA на самой ноде, ошибки TCP на VE, и более высокий LA, как следствие, на всем VE.

При использовании второго метода ресурсы CPU для каждой ноды не имеют жестких ограничений. Это значит что каждая нода может использовать процессор на максимальную мощность, в каждый момент времени (в соотвествии с “удельным весом“). Так как в реальности idle процессора достаточно большой, то это позволяет каждой ноде использовать весь объем процессорной мощности, и ограничения вступают в силу только в момент одновременной высокой нагрузке нескольких нод.

Для разных задач можно использовать как каждый метод по отдельности, так и комплексно.