HAProxy

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

Синтаксис файла настроек

Синтаксис достаточно прост - сначала объявляем секцию (global, default, listen), после чего с отступом начниаем объявлять как секция себя ведёт.

global
  chroot /var/lib/haproxy # Корневая директория для запуска демона
  daemon # Производить детач от консоли (демонизироваться)
  user haproxy # Пользователь, от которого будет запущен процесс
  group haproxy # Группа, от которой будет запущен сервис
  maxconn [1-65536] # Количество подключений
  nbproc [0-9] # Количество процессов
  pidfile /var/rub/haproxy.pid # Путь до PID файла
listen <caption>
  log <dest> <marker> <facility> # Настройки логов
  maxconn [1-65535] # Количество подключений
  option # различные опции
  retries [0-9] # Количество попыток обращения к бэкенду прежде, чем он будет считаться утраченным
  timeout <type> <duration> # Настройки различных таймаутов
  bind <ip:port> # Выбор адреса и порта, на котором будет слушать данный сервис
  mode <mode> # Режим работы сервиса
  server <name> <addr:port> <options> # Описание непосредственно бэкенда

Общие настройки

Секция default будет применяться ко всем остальным секциям, так что сюда можно вынести всевозможные таймауты, а так же настройки логов и количества подключений

haproxy.cfg
defaults
  log  global
  maxconn  65536
  option  redispatch
  retries  3
  timeout  http-request 10s
  timeout  queue 1m
  timeout  connect 10s
  timeout  client 1m
  timeout  server 1m
  timeout  check 10s

Fail-Over

Одной из самых распространённых схем HA является схема Master-Slave, которая позволяет в случае отказа мастера без потерь переключиться на горячий резерв1), тем самым сведя к минимуму простой сервиса.

Настраивается в общем и целом он достаточно просто:

haproxy.cfg
listen service_http
  bind 10.100.0.12:80
  log /dev/log local0 debug
  mode http
  option  forwardfor
  option  httpchk GET /haproxy HTTP/1.1\r\nHost:\ service.example.com
  server app-01.service.example.com 10.100.0.20:80 check
  server app-02.service.example.com 10.100.0.21:80 check backup

Из данного куска конфига мы видим, что сервис service_http слушает на адресе 10.100.0.12 на порту 80, отправляет логи в syslog, работает в режиме http.

Опция forwardfor позволяет передать дальше IP-адрес клиента, поскольку без этой опции в логах бэкендов будет светиться IP-адрес HAProxy.

Опция httpchk позволяет производить проверку доступности сервиса по http. В данном конкретном случае производится проверка, что по адресу http://service.example.com/haproxy отдаётся код 200. Обычно люди выешают эту проверку на какой-либо метод внутри своего ПО, чтобы проверять его доступность, но лично я проверяю только то, что бэкенд жив по HTTP.

Дальше идёт описание серверов. check говорит о том, что для этого сервера надо производить проверки, а backup говорит о том, что на этот сервер надо переключать трафик только в случае смерти мастера.

1)
не везде и не всегда