Балансировка нагрузки · 6 min read · Oct 08, 2025

Идеальный кластер веб-серверов с балансировкой нагрузки и высокой доступностью с 2 серверами, работающими под Xen на Ubuntu 8.04 Hardy Heron - Страница 6

12. Настройка балансировщиков нагрузки (lb1, lb2)

12.1 Включение IPVS на балансировщиках нагрузки

Сначала мы должны включить IPVS на наших балансировщиках нагрузки. IPVS (IP Virtual Server) реализует балансировку нагрузки на транспортном уровне внутри ядра Linux, так называемое переключение уровня 4.

echo ip_vs_dh >> /etc/modules
echo ip_vs_ftp >> /etc/modules
echo ip_vs >> /etc/modules
echo ip_vs_lblc >> /etc/modules
echo ip_vs_lblcr >> /etc/modules
echo ip_vs_lc >> /etc/modules
echo ip_vs_nq >> /etc/modules
echo ip_vs_rr >> /etc/modules
echo ip_vs_sed >> /etc/modules
echo ip_vs_sh >> /etc/modules
echo ip_vs_wlc >> /etc/modules
echo ip_vs_wrr >> /etc/modules

Затем мы делаем следующее:

modprobe ip_vs_dh
modprobe ip_vs_ftp
modprobe ip_vs
modprobe ip_vs_lblc
modprobe ip_vs_lblcr
modprobe ip_vs_lc
modprobe ip_vs_nq
modprobe ip_vs_rr
modprobe ip_vs_sed
modprobe ip_vs_sh
modprobe ip_vs_wlc
modprobe ip_vs_wrr

12.2 Установка Ultra Monkey (пакеты) на балансировщики нагрузки

Установите Ultra Monkey (пакеты) на балансировщики нагрузки, выполнив следующее:

apt-get install ipvsadm ldirectord heartbeat

12.3 Включение пересылки пакетов на балансировщиках нагрузки

Балансировщики нагрузки должны иметь возможность маршрутизировать трафик к узлам Apache. Поэтому мы должны включить пересылку пакетов на балансировщиках нагрузки. Добавьте следующие строки в /etc/sysctl.conf:

vi /etc/sysctl.conf

# Включает пересылку пакетов
net.ipv4.ip_forward = 1

Затем сделайте это:

sysctl -p

12.4 Настройка heartbeat и ldirectord

Теперь нам нужно создать три конфигурационных файла для heartbeat (осторожно с пробелами и табуляцией, если вы редактируете в некоторых текстовых редакторах, ldirectord очень чувствителен!) :

на lb1 и lb2

vi /etc/ha.d/ha.cf

logfacility local0
bcast eth0 # Linux
mcast eth0 225.0.0.1 694 1 0
auto_failback on
node lb1.example.com
node lb2.example.com
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

Важно: В качестве имен узлов мы должны использовать вывод обоих :

uname -n

vi /etc/ha.d/haresources

lb1.example.com \
 ldirectord::ldirectord.cf \
 LVSSyncDaemonSwap::master \
 IPaddr2::192.168.1.106/24/eth0/192.168.1.255 \
 IPaddr2::192.168.1.107/24/eth0/192.168.1.255

IP-адреса 192.168.1.106 и 107 будут использоваться позже для веб-сайтов (example.com и yoursite.com).

Этот файл должен быть одинаковым на обоих узлах, независимо от того, начинаете ли вы создавать файл на lb1 или lb2!

vi /etc/ha.d/authkeys

auth 3 3 md5 somerandomstring

somerandomstring — это пароль, который два демона heartbeat на lb1 и lb2 используют для аутентификации друг друга. Используйте свою собственную строку здесь. У вас есть выбор между тремя механизмами аутентификации. Я использую md5, так как считаю его самым безопасным.

/etc/ha.d/authkeys должен быть доступен только для чтения пользователю root, поэтому мы делаем это:

chmod 600 /etc/ha.d/authkeys

ldirectord — это фактический балансировщик нагрузки. Мы собираемся настроить наши два балансировщика нагрузки (lb1.example.com и lb2.example.com) в активной/пассивной конфигурации, что означает, что у нас есть один активный балансировщик нагрузки, а другой является горячим резервом и становится активным, если активный выходит из строя. Чтобы это работало, мы должны создать конфигурационный файл ldirectord /etc/ha.d/ldirectord.cf, который также должен быть идентичен на lb1 и lb2.

vi /etc/ha.d/ldirectord.cf

checktimeout=5
checkinterval=5
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=no
#fork=yes

#ДЛЯ SMTP
virtual=192.168.1.106:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect
virtual=192.168.1.107:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect

#ДЛЯ DNS - CONNECT НЕ РАБОТАЕТ, НУЖНО ПАТЧИТЬ, НО PING В ПОРЯДКЕ
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=none
        scheduler=wlc
        checktype=ping
        protocol=udp
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=dns
        scheduler=wlc
        checktype=ping
        protocol=tcp
#ДЛЯ HTTP
virtual=192.168.1.106:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Connected to MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800
virtual=192.168.1.107:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Connected to MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800

#ДЛЯ WEBMAIL
virtual=192.168.1.106:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Connected to MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
virtual=192.168.1.107:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Connected to MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
#ДЛЯ POP3
virtual=192.168.1.106:110
        real=192.168.1.104:110 gate
        fallback=192.168.1.105:110 gate
        service=pop
        checktype = connect
        scheduler=wlc
        protocol=tcp
#ДЛЯ IMAP
virtual=192.168.1.106:143
        real=192.168.1.104:143 gate
        fallback=192.168.1.105:143 gate
        service=imap
        scheduler=wlc
        protocol=tcp
#ДЛЯ HTTPS
###Раскомментируйте эту часть, если вы будете использовать HTTPS
#virtual=192.168.1.106:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirectord.php"
#        receive="Connected to MySQL"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#
#virtual=192.168.1.107:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirector.html"
#        receive="Test Page"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#ДЛЯ IMAP SSL
virtual=192.168.1.106:993
        real=192.168.1.104:993 gate
        fallback=192.168.1.105:993 gate
        service=imaps
        scheduler=wlc
        protocol=tcp
#ДЛЯ POP3 SSL
virtual=192.168.1.106:995
        real=192.168.1.104:995 gate
        fallback=192.168.1.105:995 gate
        service=pops
        checktype = ping
        scheduler=wlc
        protocol=tcp
#ДЛЯ MONIT MONITORING #1
virtual=192.168.1.106:10001
        real=192.168.1.104:10001 gate
        checktype = on
#ДЛЯ MONIT MONITORING #2
virtual=192.168.1.106:20001
        real=192.168.1.105:20001 gate
        checktype = on

virtual — это виртуальный IP адрес служб (например, 192.168.1.106 и 107)

real — это реальные IP адреса серверов в кластере (192.168.1.104 и 105)

fallback — это резервный сервер. Если реальный IP выходит из строя, запросы перенаправляются на резервный IP, но они не балансируются по нагрузке.

Эта конфигурация основана на моем личном опыте. Некоторые службы балансируются по нагрузке, другие — нет. Все, что связано с почтой, не балансируется. Вы не хотите, чтобы одно сообщение пришло на первый сервер, а второе — на другой (если только у вас нет общего хранилища). Если у вас нет очень высокого трафика почты, нет смысла балансировать почту (но она все равно будет высокодоступной), то же самое касается DNS. Позже мы синхронизируем сообщения на втором сервере, чтобы у нас была резервная копия на случай, если первый сервер выйдет из строя.

Что касается порта 81. Мы будем использовать его для веб-почты. Также я использую его для администрирования нашего веб-сайта электронной коммерции из-за загрузки изображений. Позже мы настроим rsync с web1.example.com на web2.example.com, но не наоборот. В основном вы не хотите загружать файл на web2.example.com (если только вы не используете общее хранилище).

Если вы хотите получить больше информации по этой теме, поищите “ldirectord man”.

После этого мы создаем системные ссылки для запуска heartbeat и удаляем ссылки для ldirectord, потому что ldirectord будет запущен демоном heartbeat:

update-rc.d -f ldirectord remove

Наконец, мы запускаем heartbeat (и с ним ldirectord):

/etc/init.d/ldirectord stop
/etc/init.d/heartbeat start

12.5 Тестирование балансировщиков нагрузки

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

ip addr sh eth0

Активный балансировщик нагрузки lb1.example.com должен перечислять виртуальные IP-адреса (192.168.1.106 и 192.168.1.107):

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.102/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.106/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.107/24 brd 192.168.1.255 scope global secondary eth0

Горячий резерв (lb2.example.com) должен показывать что-то вроде этого:

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:29:34:d7:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.103/24 brd 192.168.1.255 scope global eth0

Теперь попробуйте :

ldirectord ldirectord.cf status

Вывод на активном балансировщике нагрузки (lb1) :

ldirectord for /etc/ha.d/ldirectord.cf is running with pid: 5321

Вывод на горячем резервном балансировщике (lb2) :

ldirectord is stopped for /etc/ha.d/ldirectord.cf

Теперь мы проверим, правильно ли перенаправлены порты :

ipvsadm -L -n | grep :80

Вы должны увидеть что-то вроде этого на lb1.example.com:

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

И ничего на lb2.example.com.

Последний тест :

/etc/ha.d/resource.d/LVSSyncDaemonSwap master status

Вывод на активном балансировщике:

master running (ipvs_syncmaster pid: 5470)

Вывод на горячем резерве:

master stopped

12.6 Тестирование переключения балансировщиков нагрузки

lb1.example.com

/etc/init.d/heartbeat stop

Команда ipvsadm :

ipvsadm -L -n | grep :80

должна не выводить ничего.

На lb2.example.com

ipvsadm -L -n | grep :80

и вы должны увидеть следующее :

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

Перезапустите службу heartbeat на lb1.example.com :

/etc/init.d/heartbeat start

Если вы повторите команду ipvsadm на обоих, вы увидите, что lb1.example.com теперь активен, в то время как lb2.example.com вернулся в резервный режим.

Если ваш тест прошел успешно, вы можете продолжать.

Share: X/Twitter LinkedIn
#Балансировка нагрузки

Get new posts in your inbox

No spam. Unsubscribe anytime.