В результате анализа причиной оказался высокий MTU, судя по technet MTU на 2003 VPN серверах по умолчанию 1400, соответственно после выставления значения MTU = 1200 и MRU = 1192 все заработало стабильно.

В последнее время в такой связке я разочаровался, mod_fastcgi не обеспечивает приемлемый уровень производительности и надежности для WEB проектов использующих язык PHP, в итоге решил протестировать связку Apache 2.2 + mod_fcgid + php.

Ограничения mod_fcgid:

1. 1 запрос – 1 процесс, mod_fcgid не умеет отправлять несколько паралельных запросов запущенному fastcgi процессу, в случае с PHP это и не требуется, так как для корректной работы данной связки параметр нужно использовать PHP_FCGI_CHILDREN=0.
2. Низкая эффективность различного рода opcode кешеров, так как каждый запущенный fastcgi не имеет доступ к разделяемой памяти других fastcgi процессов (это описано в документации по mod_fcgid, пока не тестировал)

Непосредственно настройка:

Считаем, что Apache 2.2 + suexec и PHP с поддержкой FastCGI у вас установлен, далее устанавливаем libapache2-mod-fcgid и изменяем стандартную конфигурацию:

Исходный код

cat /etc/apache2/mods-enabled/fcgid.conf 
 
<IfModule mod_fcgid.c>
  AddHandler	fcgid-script .fcgi
  FcgidConnectTimeout 20
 
  FcgidBusyTimeout 60
  FcgidBusyScanInterval 61
 
  SocketPath /var/lib/apache2/fcgid/sock
 
  FcgidMaxProcessesPerClass 100
  FcgidMaxProcesses 400
 
  FcgidPassHeader Authorization
  FcgidPassHeader Proxy-Authorization
  FcgidPassHeader HTTP_AUTHORIZATION
 
  AddHandler php-fcgi .php
  Action php-fcgi /php-fcgi/php.sh
 
  Action application/x-httpd-fastphp /php-fcgi/php.sh
  Action application/x-httpd-php /php-fcgi/php.sh
 
  AddType application/x-httpd-fastphp     .php
 
  <Location /php-fcgi/>
            Options ExecCGI FollowSymLinks
            SetHandler fcgid-script
  </Location>
 
</IfModule>

И выполняем 2-е команды: a2enmod fcgid && /etc/init.d/apache2 restart

Пример конфигурационного файла для VirtualHost в Apache 2.2:

Исходный код

<VirtualHost *:80>
	ServerName papyrus
	ServerAdmin webmaster@localhost
 
	DocumentRoot /var/www/papyrus/www/web
	<Directory />
		Options FollowSymLinks
		AllowOverride None
	</Directory>
	<Directory /var/www/papyrus/www/web>
		Options Indexes FollowSymLinks MultiViews
		AllowOverride All
		Order allow,deny
		allow from all
	</Directory>
 
	Alias           /php-fcgi/      /var/www/papyrus/cgi-bin/
 
	SuexecUserGroup papyrus papyrus
 
  Alias /sf /var/www/papyrus/symf/data/web/sf
  <Directory "/var/www/papyrus/symf/data/web/sf">
    AllowOverride All
    Allow from All
  </Directory>
 
<Directory "/var/www/papyrus/cgi-bin">
        AllowOverride None
        Options None
        Order allow,deny
        Allow from all
</Directory>
 
	ErrorLog /var/log/apache2/papyrus-error.log
 
	# Possible values include: debug, info, notice, warn, error, crit,
	# alert, emerg.
	LogLevel warn
 
	CustomLog /var/log/apache2/papyrus-access.log combined
 
</VirtualHost>

Данный конфигурационный файл используется для проекта написанного на Symfony, можете его отредактировать для своих нужд. Основные параметры:

/var/www/papyrus/cgi-bin/ – папка к которой находится файл php.sh, в случае запроса *.php скриптов именно этот скрипт служит как программа, которая вызывается для обработки таких запросов.

SuexecUserGroup – пользователь и группа с правами которого будут запускаться php скрипты, в данном случае это пользователь и группа papyrus, группа данного пользователя должна быть в группе www-data, иначе при выставленных правах 750 на папку /var/www/papyrus/ Apache не сможет прочитать статические файлы. Пример:

Исходный код

papyrus:x:1003:www-data

Пример файла php.sh:

Исходный код

#!/bin/sh
PHP_FCGI_CHILDREN=0
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /usr/bin/php5-cgi

После перезапуска Apache 2.2 и просмотра страницы http://papyrus/ у вас должен отработать PHP скрипт, в него можете поместить тотже phpinfo(). В случае проблем – смотрите логи, основной момент, про который обычно забывается – это права на папки и файлы, они должны быть аналогичные тем, который указаны в SuexecUserGroup.

По поводу скорости работы – на моем ноутбуке сопоставимо с mod_php, с учетом того, чт о в Apache использую MPM-Worker – все работает достаточно быстро и стабильно, через некоторое время проверю данную схему в какой-нибудь production среде, тогда дополню данную заметку.

Почему кстати используется PHP_FCGI_CHILDREN=0 – главный момент, это то, что PHP не управляет своими дочерними процессами, так как их нет, и в случае выпадения php5-cgi процесса в zombie, mod_fcgid должен будет корректно его перезапустить, кстати, аналогичную рекомендацию по настройке приводят и разработчики mod_fastcgi. Так что до тех пор, пока не будет доделан apache-like режим в php5-fpm, планирую использовать такую связку.

Для настройки Jira достаточно прочитать и выполнить действия описанные в документации, я опишу способ настройки автоматического импорта пользователей из AD.

Считаем, что вы можете успешно создать XML файл для создания пользователей в Jira, включили Jelly Runner, и можете через WEB интерфейс администрирования Jira выполнить созданный XML файл. Сама Jira у вас настроена, запускается и работает без проблем.

Для автоматизации всего процесса импорта пользователей из AD нужно сделать следующее:

Добавить в cron пользователя, с правами которого работет Jira следующую команду:

Исходный код

0       */1     *       *       *       cd ~/SOFT/jira-ldap-userimporter-1.1; java -jar jira-ldap-userimporter-1.1.jar > AD.export && ./buildADul.sh

Где папка:

~ – домашняя папка пользователя, с правами которого работает Jira, подразумевается, весь дистрибутив Jira распакован в эту директорию.

SOFT/jira-ldap-userimporter-1.1 – папка, в которой находится программа для импорта пользователей из AD и создания XML файла для JellyRunner.

Скрипт buildADul.sh – простой скрипт на bash следующего содержания:

Исходный код

#!/bin/bash
# Script to build userlist for Jira.
# ver 0.1
 
export PATH="/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin"
 
WRKP="~/SOFT/jira-ldap-userimporter-1.1/"
ADFILE="AD.export"
AD="AD"
 
cd $WRKP
 
echo "<JiraJelly xmlns:jira=\"jelly:com.atlassian.jira.jelly.JiraTagLib\">" > $AD
echo "<jira:Login username=\"CHANGE_ME\" password=\"CHANGE_ME\">" >> $AD
cat $ADFILE | grep -v "JiraJelly" >> $AD
echo "</jira:Login>" >> $AD
echo "</JiraJelly>" >> $AD

Вместо CHANGE_ME нужно указать логин и пароль пользователя Jira с правами администратора или пользователя с возможностью выполнения Jelly скриптов.

jira:login в данном случае требуется для выполнения авторизации в Jira, и создания нужных переменных в контексте выполнения Jelly скрипта, без этого вы будете получать ошибку при запуске созданного скрипта через com.atlassian.jira.jelly.service.JellyService.

Пример ошибки:

Исходный код

Tag CreateUser requires (jelly.username) variables to be set in the Context

Соответственно XML файл у нас создается в нужном формате, теперь можно создать сервис по запуску данного файла в Jira. Для этого переходим в Администрирование – Services и в разделе Add Service заполняем поля следующим образом:

Имя – AD Import

Class – com.atlassian.jira.jelly.service.JellyService

Delay – 720

Жмем Add Service и в поле Input File указываем полный путь в рамках локальной файловой системы сервера до XML файла с Jelly командами. Пользователь с правами которого работает Jira должен иметь возможность прочитать данный файл.

По идее все, теперь каждые 12 часов у вас будет происходить автоматический импорт пользователей из AD. Удаление пользователей должно производиться вручную, с переносом назначенных багов на кого-нибудь другого.

Исходный код

addgroup: The group `vboxusers' already exists and is not a system group. Exiting.
Unable to find a precompiled module for the current kernel
though module compilation denied by debconf setting.

Исходный код

virtualbox virtualbox/module-compilation-allowed boolean true
virtualbox virtualbox/delete-old-modules boolean true

И выполнить команду:

Исходный код

debconf-set-selections vboxconf

После этого установка VirtualBox пройдет без проблем.

Так что с LinuxDC++ пересел на него  и обратно переходить не собираюсь.

Для корректной работы NSCA у вас уже должна быть установлена и настроена система мониторинга Nagios, то есть как минимум пробники для сервера localhost должны проверяться и отображаться корректно. Далее, необходимо установить NSCA сервер, в RHEL 5 это можно сделать командой (предварительно подключив epel репозиторий):

Исходный код

yum install nsca

После установки управление демоном происходит при помощи скрипта /etc/init.d/nsca, управление конфигурацией происходит при помощи файла /etc/nagios/nsca.cfg. Необходимо проверить, что путь до command_file указан верный, либо исправить, если это не так. У меня данный параметр настрен следующим образом:

Исходный код

# COMMAND FILE
# This is the location of the Nagios command file that the daemon
# should write all service check results that it receives.
command_file=/var/log/nagios/rw/nagios.cmd

Все данные, что NSCA получает по сети он будет обрабатывать и записывать в этот файл, далее Nagios разберет полученную информацию, и, если нет ошибок, обработает и покажет в системе мониторинга.

После вышеописанных действий NSCA сервер настроен, осталось настроить клиента. Для этого устанавливаем его на сервере при помощи команды:

Исходный код

yum install nsca-client

Конфигурационный файл /etc/nagios/send_nsca.cfg в правках не нуждается, проверить корректность работы утилиты send_nsca можно следующим образом – запустить ее со следующими параметрами:

Исходный код

echo -e 'sql.lan.net\tMySQL Checksum Check\t0\tAll Good\n' | send_nsca nsca.server.hostname -p 5667

«echo -e» – передает на через pipe утилите send_nsca специальную строку с указанием сервера, сервиса, состояния (0 – все ок, 1 – Warning, 2 – Error, 3 – Unknown), параметр -e отвечает за обработку управляющих символов, то есть \t – табуляция, \n – перевод строки.

nsca.server.hostname – DNS адрес или IP адрес сервера.

После проверки при помощи send_nsca корректной работы связки nsca client – nsca server, осталось настроить систему мониторинга Nagios.

Для этого нужно создать шаблон для сервиса с типом passive, я использую следующий:

Исходный код

define service{
 name                            service_passive         ; The 'name' of this service template
 active_checks_enabled           1                       ; Active service checks are enabled
 passive_checks_enabled          1                       ; Passive service checks are enabled/accepted
 parallelize_check               1                       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
 obsess_over_service             1                       ; We should obsess over this service (if necessary)
 check_freshness                 1                       ; Default is to NOT check service 'freshness'
 check_command                   check_dummy!3!"Service check to old"
 freshness_threshold             100
 notifications_enabled           1                       ; Service notifications are enabled
 event_handler_enabled           1                       ; Service event handler is enabled
 flap_detection_enabled          1                       ; Flap detection is enabled
 failure_prediction_enabled      1                       ; Failure prediction is enabled
 process_perf_data               1                       ; Process performance data
 retain_status_information       1                       ; Retain status information across program restarts
 retain_nonstatus_information    1                       ; Retain non-status information across program restarts
 is_volatile                     0                       ; The service is not volatile
 check_period                    never                    ; The service can be checked at any time of the day
 max_check_attempts              1                       ; Re-check the service up to 4 times in order to determine its final (hard) state
 normal_check_interval           3                       ; Check the service every 5 minutes under normal conditions
 retry_check_interval            1                       ; Re-check the service every minute until a hard state can be determined
 contact_groups                  admins                  ; Notifications get sent out to everyone in the 'admins' group
 notification_options            w,u,c,r                 ; Send notifications about warning, unknown, critical, and recovery events
 notification_interval           0                       ; Re-notify about service problems every hour
 notification_period             24x7                    ; Notifications can be sent out at any time
 register                        0                       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
 }

Измените его под свои настройки Nagios, и проверте, что у вас есть timeperiod c именем never и содержимым:

Исходный код

# This one is a favorite: never 
define timeperiod{
timeperiod_name never
alias           Never
}

Этот период задает нулевую периодичность для проверки сервисов с типом passive. После вышеописанной настройки осталось настроить сам сервис, например так:

Исходный код

define service {
use                             service_passive
service_description             MySQL Checksum Check
name                            mysql_checksum_check
contact_groups                  admins, smsadmins
register                        0
}
define service {
use                             mysql_checksum_check
host_name                       sql.lan.net
}

Перезапускаем Nagios, для хоста, у которого мы настроили сервис MySQL Checksum Check он находится в состоянии pending, после отправки при помощи send_nsca сообщения указанного выше, через некоторое время он должен перейти в состояние ОК.

Название сервиса MySQL Checksum Check должно быть одинаковым как в конфигурации Nagios, так и для утилиты send_nsca, иначе Nagios не сможет обработать сообщение полученное от NSCA сервера.

Основной момент, это определиться с периодом проверки СУБД на идентичность, судя по моему опыту – это раз в неделю, либо после проблем с репликацией. Во всех остальных случаях, если разработчики знакомы с ограничениями MySQL при репликации данных, СУБД ведет себя достаточно стабильно.

Для автоматизации проверки я использую скрипт – mysql_consistency.sh. Скрипт достаточно простой, позволяет автоматизировать проверку СУБД на идентичность, с последующей нотификацией через систему Nagios о имеющихся проблемах.

Для его использования достаточно скачать его и скопировать в нужную вам директорию, в обязательном порядке нужно установить набор утилит Maatkit, иначе скрипт не будет работать, так как не будет необходимых программ для реализации проверки идентичности MySQL серверов.

Перед запуском скрипта необходимо указать в нем логин и пароль, при помощи которых он будет подключаться к СУБД, также, если требуется поддержка Nagios, нужно настроить следующие параметры:

Исходный код

###
# Nagios support variables
# 1 - enable nagios nsca support
# 0 - disable nagios nsca support
###
nagios_support=0
 
# Name of the nagios service
NAGIOS_SERVICE_NAME="MySQL Checksum Check"
 
# Set NSCA host and port
NSCA_HOST="localhost"
NSCA_PORT="5667"

nagios_support – включает/выключает поддержку Nagios.

NSCA_HOST  – определяет имя сервера, на котором установлен NSCA сервер.

После запуска скрипт запустит mk-table-checksum, который проверит master MySQL сервер, далее при помощи mk-table-sync проверит консистентность slave MySQL серверов. Если включена поддержка Nagios – скрипт отправит сообщение со статусом проверки, как положительным так и отрицательным, NSCA серверу при помощи утилиты send_nsca.

В следующей заметке напишу как настраивать систему мониторинга Nagios для работы с NSCA сервером, в этой настройке есть несколько моментов.

1) MySQL Cluster

2) MySQL Replication

Оба механизма имеют свои плюсы и минусы, но всетаки более популярен и доступен – это 2-ой вариант, то есть репликация данных между MySQL серверами. Настройка репликации отлично описана в документации, поэтому рассматривать мы ее не будем. Предмет данной заметки – проверка MySQL slave сервера на идентичность его данных MySQL master серверу.

Не все администраторы это знают, но из-за того, что репликация в MySQL 4.1-5.0 производится при помощи бинарных логов, в которые пишутся SQL запросы, которые в последствии выполняются MySQL slave сервером, данные на slave сервере могут отличаться от данных на master сервере, причем, как показывает практика, такие ситуацию случаются регулярно.

Соответственно, задача любого MySQL администратора – это обеспечить ежедневную проверку идентичности данных slave сервера с последующей синхронизацией данных, в случае необходимости.

Для проверки идентичности данных я использую утилиту mk-table-checksum из пакета Maatkit. Данная утилита умеет проверят идентичность данных между серверами, выборочно по базам данных или отдельным таблицам, с помощью разных алгоритмов (ACCUM, BIT_XOR, CHECKSUM), причем, как между серверами связанными репликацией, так и нет. Суть работы данной утилиты – конкатенация всех данных в таблице, с дальнейшим получением контрольного числа для данного объема данных. Для проверки я использую следующие параметры для запуска данной утилиты:

Исходный код

mk-table-checksum --quiet --algorithm BIT_XOR --chunk-size 500000 --nocrc --empty-replicate-table --float-precision 5 \
--function FNV_64 --optimize-xor --replicate=test.checksum --sleep-coef=0.5 --socket /tmp/mysql_socket_path.sock \
h=MYSQL_HOST,P=MYSQL_PORT,u=MYSQL_USER,p=MYSQL_PASS,A=cp1251

Ключевые параметры:

–algorithm BIT_XOR – алгоритм BIT_XOR, для получения финальной контрольного числа, данный алгоритм не учитывает очередность вставки данных в таблице, соответственно если на slave сервере данные находятся в другом порядке, чем на master сервере, то данный алгоритм не позволит это обнаружить, при такой ситуации нужно использовать алгоритм ACCUM.

–function FNV_64 – хеш функция для обработки контрольного числа полученного при помощи алгоритам BIT_XOR или ACCUM. Я использую функцию FNV_64, данная функция доступа после установки UDF модуля, исходный код данного модуля распространяется вместе с Maatkit.

Для проверки должен быть указан адрес MySQL master сервера, после запуска утилиты определяются БД для проверки и выполняются SQL запросы вида REPLACE с записью конечных данных в таблицу test.checksum, далее эти SQL запросы при помощи репликации передаются на slave сервер, где также выполняются. Соотвественно если результат выполнения одинх и техже запросов равен на master и slave сервере, значит считаем, что данные на серверах идентичны.

Далее для проверки и синхронизации данных, если это требуется, используем утилиту mk-table-sync. Я использую следующие параметры для запуска:

Исходный код

mk-table-sync --print --verbose --function FNV_64 --replicate test.checksum --sync-to-master \
h=MYSQL_HOST,P=MYSQL_PORT,u=MYSQL_USER,p=MYSQL_PASS,A=cp1251

Ключевые параметры:

–print – вывести информацию, если найдены различия, изменение данных не производится.

–sync-to-master – все изменения, если найдены различия, будут проводиться на MySQL  master сервере. Это особенно актуально в случае master-master репликации. В случае если вместо параметра –print будет параметр –execute, данная утилита определит какие данные между master и slave сервером различаются, подключится к master серверу и выполнит необходимые запросы (REPLACE, DELETE) для приведения slave сервера в идентичное состояние master серверу.

Также часто приходится пользоваться параметром –noforeign-key-checks, для отключения проверки foreign-key`s. Их выполнение все равно не нужно, если данные в итоге будут идентичны на обоих серверах.

Проводя такую нехитрую проверку каждый день, мы можем гарантировать, что данные между master и slave серверами идентичны, и в случае отказа master сервера MySQL администратор сможет без проблем задейстовать slave сервер для обеспечения дальнейшей работы WEB проекта.

В следующей заметке опишу способ простой автоматизации проверки идентичности MySQL master и slave серверов с последующей нотификацией, в случае проблем, при помощи системы мониторинга Nagios.

Либо можете добавить эту ленту в свои RSS клиенты.

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

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