Как контролировать узлы веб-сервера через 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.

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

Другие вопросы по тегам