Как контролировать узлы веб-сервера через HA-прокси с помощью Icinga/Nagios в CentOS 6
В этом руководстве я совсем не фокусируюсь на настройке прокси-сервера HA или на том, почему вы хотите это сделать. Если у вас есть и вы хотите правильно контролировать его с помощью Icinga, вот идея, как вы могли бы сделать это.
Итак, вот потенциальный сценарий:
- 2 дата-центра A и B
- 1 HA прокси-узел на центр обработки данных
- Каждый прокси-сервер HA указывает на 2 веб-сервера в каждом центре обработки данных A1, A2, B1, B2
- Веб-серверы в этом сценарии на самом деле являются конечной точкой веб-службы, и простой HTTP GET для URL-адреса мало что говорит о фактическом состоянии системы.
Следите за тем, чтобы вы могли согласиться на внешнюю проверку (например, pingdom или что-то еще) ваших текущих активных узлов. Это будет иметь некоторые последствия, хотя:
- Вы не будете тестировать пассивные узлы, что означает, что перед переключением узла вы не уверены, работают ли пассивные узлы.
- Отказ одного узла не даст вам четкого указания на то, что не так
Так вот подход параноиков:
- Я хочу отслеживать каждый узел с внешнего IP-адреса, через прокси-сервер HA и в систему, чтобы уловить любой сбой на этом пути.
- Я хочу сделать реальный вызов веб-службы для внутренней службы, чтобы убедиться, что она работает - очевидно, неприменимо, если вы тестируете обычный веб-сайт
Тогда доберемся до этого...
1 ответ
Прежде всего вам нужно включить вставку файлов cookie в haproxy и назначить каждому внутреннему узлу свой уникальный ключ. Обычно это используется для обеспечения стабильности сеанса - т.е. вы не хотите, чтобы кто-то посещал ваш сайт, чтобы всегда получать один и тот же внутренний конечный узел, если он все еще доступен. Но его также можно использовать для мониторинга отдельных узлов, отправив соответствующий файл cookie. Поэтому, если нет, добавьте куки в определения вашего сервера haproxy:
cookie SERVERID insert indirect nocache
server webA1 10.0.0.1:80 cookie S1
server WebA2 10.0.0.2:80 cookie S2
Во-вторых, вам нужно выяснить, что имеет смысл проверять больше всего, в этом вам нужно будет подумать и поиграть самостоятельно, чтобы выяснить, что имеет смысл и как это проверить, используя удивительный nagios check_http. Для полноты ниже приведу сложный пример того, как можно протестировать POST для внутреннего веб-сервиса. Для этого примера сценария требования:
- Post data should be <echo>Hello</echo>
- A successful execution will return the echo string back
- Disable any cache through HTTP headers
- Set content-type to text/xml and expect the same back
- SSL should be used
- Host name is example.com
- Port is 443
- URI is /service
- Max response time is 3 seconds
Об этом позаботятся следующие аргументы check_http (/usr/lib64/nagios/plugins/check_http в Cent OS 6)
-P "<echo>Hello</echo>"
-r 'Hello'
-k "Cache-Control: no-cache" -k "Pragma: no-cache"
-k "Content-Type: text/xml; charset=UTF-8" -k "Accept: text/xml"
-S
-H example.com
-p 443
-u /service
-t 3
Теперь все это вместе должно дать вам хороший вывод ОК, сначала запустите это.
Затем настало время для некоторых пользовательских аспектов, включающих выбор узла через cookie-файл и, при необходимости, отправку IP-адреса, который можно использовать для переопределения DNS, если вы, например, хотите проверить путь через пассивный центр обработки данных. Для этого мы напишем небольшую оболочку сценария оболочки вокруг check_http, которая будет принимать один параметр в качестве имени хоста внутреннего узла (для удобства, давайте используем то, что icinga считает именем хоста), и необязательный параметр, переопределяющий IP сервера для проверки (в обход поиска DNS). Все это приводит к тому, что скрипт оболочки выглядит примерно так (я предлагаю поместить его в / usr / lib64 / nagios / plugins / и chown,chmod так же, как и в других там плагинах):
#/bin/bash
if [ -z "$1" ]
then
echo "Usage: $0 host-name [haproxy-ip]"
exit 2
fi
if [[ $# -eq 2 ]]; then
APPEND_OPTS=" -I $2"
fi
#Map icinga/nagios host names to haproxy node names in case these differ and you don't want to expose them on the internetz
declare -A nodes
nodes=(["webA1"]="S1"
["webA2"]="S2"
["webB1"]="S3"
["webB2"]="S4")
node=${nodes["$1"]}
/usr/lib64/nagios/plugins/check_http -P "<echo>Hello</echo>" -r 'Hello' -k "Cache-Control: no-cache" -k "Pragma: no-cache" -k "Content-Type: text/xml; charset=UTF-8" -k "Accept: text/xml" -S -H example.com -p 443 -u /service -t 3 -k "Cookie: SERVERID=$node" $APPEND_OPTS
Обратите внимание, что SERVERID - это имя файла cookie, установленного в haproxy.
Как только это будет сделано, вы можете определить команды проверки nagios, подобные следующим:
#Check path through av A fw and haproxy
define command{
command_name check_node_external_a
command_line $USER1$/check_node '$HOSTNAME$' '<A external IP>'
}
Где check_node - это имя сценария оболочки, а "Внешний IP" - это IP-адрес, используемый для доступа к системе в центре обработки данных A.
Это сэкономило бы мне много времени в последние несколько дней, поэтому я надеюсь, что оно также может направить вас в правильном направлении.