Категория: FreeBSD, Хостинг Автор: Hottab :: Среда 10 марта 2010 в 16:04

Суть проблемы:

При установке расширения Gd для php возникла проблема - расширение просто не ставилось, на экран ничего не писалось.

Система: FreeBSD 7.2
Панель: ISPmanager-Lite 4.3.38
php: PHP 5.2.12

Решение:

Для начала посмотрим что пишет установщик в логах при попытке установки расширения.
Делаем следующим образом :

[server]# tail -f /usr/local/ispmgr/var/pkgctl.log

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

Нас интересуют строки, содержащие “return=1″ :

[47856] [1;36mEXTINFO Execute (PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; cd /usr/ports/graphics/php5-gd; make clean; make BATCH=yes install clean) return=1 exited

return=1 - означает что что-то пошло не так (отдельное спасибо разработчикам панели за такую "информативность" в логах, блин).

Пробуем выполнить это действие самостоятельно:

[server]# cd /usr/ports/graphics/php5-gd; make clean; make BATCH=yes install clean

и наблюдаем следующую проблему:

Found libtool-1.5.26, but you need to upgrade to libtool>=2.2

и решаем ее:

[server]# cd /usr/ports/devel/libtool22; make clean && make install clean

Снова запускаем установку расширения Gd в панели управления.
У меня больше проблем не возникло, все поставилось.


Категория: Linux, Хостинг Автор: Hottab :: Вторник 2 марта 2010 в 16:19

Потребовалось тут подключить два сервера к 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

все :)


Категория: FreeBSD, Хостинг Автор: Hottab :: Четверг 10 сентября 2009 в 12:13

Обновил тут Nagios до 3.2 (система FreeBSD 7.2) . И обнаружил что пункт “Map” в меню не работает. При более детальном рассмотрении оказалось что не собрались некоторые cgi-скрипты.

Как оказалось, configure при обновлении не увидел библиотек gd.

Лечится просто. Во-первых, убедитесь что gd установлена.
Во-вторых выполните configure со следующими параметрами:

# ./configure --with-command-group=nagios --with-gd-lib=/usr/local/lib --with-gd-inc=/usr/local/include

и потом

# make clean && make && make install

должно работать :)


Категория: Хостинг Автор: Hottab :: Понедельник 10 августа 2009 в 11:52
Nagios. Все ок.

Nagios. Все ок.

Отлично когда вот так :)
Скоро статья по настройке нагиоса и плагинов :)


Категория: Linux, Хостинг Автор: Hottab :: Среда 27 мая 2009 в 13:25

Довольно часто на одном 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 процессора достаточно большой, то это позволяет каждой ноде использовать весь объем процессорной мощности, и ограничения вступают в силу только в момент одновременной высокой нагрузке нескольких нод.

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


Copyright © 2009 Горячий [TAB].