Задача:Сконфигурировать два или более отказоустойчивых брандмауэра на базе IPF с функцией балансировки нагрузки
(далее - "FWLB") для кластера, предоставляющего сервис в сети Интернет.
Если один из брандмауэров приходит в негодность, то его функции будет выполнять второй.
В этом случае мы получим высокодоступную систему с черезвычайно малым временем простоя и,
как мы надеемся, сэкономит немало средств на специализированных устройствах.
Наша задача - получить нижепреведенную конфигурацию:
~~~
( net )
~~~
|
|
|
----------
| switch |
----------
/ \
/ VIP \
--------- --------
| fwlb1 | | fwlb2 |
--------- --------
\ VIP /
\ /
---------
| switch |
---------
/ \
/ \
--------- ---------
| server1 | | server2 |
--------- ---------
Где первый VIP (Virtual IP) это публичный IP адресс вашего сайта,
а второй - приватный IP согласно RFC 1918, который будет использоваться
серверами в качестве шлюза по умолчанию.
Требования:- Два сервера с FreeBSD-STABLE. У каждого из них - по 2 сетевые карты
- Два коммутатора/хаба
- Два или более серверов для кластера, на котором запущен предоставляемый сервис
- /usr/ports/net/pen
- /usr/ports/net/freevrrpd
- /usr/ports/sysutils/daemontools или /usr/ports/sysutils/runit
- Ядро, скомпилированное с опциями IPFILTER и IPFILTER_LOG
Pen является простым, но гибким балансировщиком.
FreeVRRPd будет обеспечивать отказоустойчивость.
Daemontools(или runit, с более дружественной лицензией и похожим функционалом) не является необходимым,
но весьма полезен для контроля и управления процессами, поэтому тоже рекомендован к использованию.
Выполнение:Часть 1: Брандмауэр
Создайте набор правил IPF(или IPFW, или PF), разрешающий трафик на стороне сервиса,
который нуждается в балансировке. По желанию, разрешите доступ к кластеру серверов через NAT,
если есть необходимость в исходящих соединениях. Конфигурирование IPF/IPNAT не рассматривается в данной статье,
но на эту тему написано достаточно много. Два пункта, которые очень важно иметь в виду,
заключаются в том, что вам необходимо удостовериться, что разрешен multicast между брандмауэрами
(необходимо для работы VRRP) и запрещен для всех других хостов (иначе возникнет угроза безопасности).
Для получения ополнительной информации по IPF, обратитесь к:
http://www.nwo.net/ipf/ipf-howto.html
http://coombs.anu.edu.au/~avalon/ip-filter.html
Скомпилировав ядро с опциями, указанными выше, вносим следующие изменения в /etc/rc.conf:
ipfilter_enable="YES"
ipfilter_rules="/etc/ipf.conf"
ipnat_rules="/etc/ipnat.conf"
ipnat_flags="-CF"
ipmon_enable="YES"И переносим набор правил в указанные места.
Часть 2: Балансировщик
1) Создаем необходимых пользователей и каталоги.
mkdir -p /etc/supervise/pen/log
mkdir -p /var/chroot/pen
mkdir -p /var/log/pen
pw useradd pen -s /bin/false -d /var/chroot/pen
pw useradd penlog -s /bin/false -d /var/chroot/pen
chown penlog:pen /var/log/pen2) Создаем файлы, необходимые для запуска pen.
cd /etc/supervise/pen
cat << _EOF_ > run
#!/bin/shexec 2>&1
exec pen -d -u pen -j /var/chroot/pen -C localhost:8888 -f -r 80 hostname1 hostname2_EOF_
chmod 755 run
cd log
cat << _EOF_ > run
#!/bin/sh
exec /usr/local/bin/setuidgid penlog /usr/local/bin/multilog s999999 n20 /var/log/pen_EOF_
chmod 755 run
Так мы сконфигурируем pen для запуска в pen в /var/chroot/pen и портом управления 8888.
Он будет балансировать входящий 80 порт на порт 80 hostname1 на hostname2.
Тип балансировки - round-robin - если необходимы постоянные сессии, удалите флаг "-r".
В этом примере pen запущен в режиме отладки, что упростит настройку.
При промышленном использовании можно удалить флаг "-d".
3) Запуск балансировщика нагрузки.cd /service
ln -s /etc/supervise/pen
echo "csh -cf '/usr/local/bin/svscanboot &'" >> /etc/rc.local
csh -cf '/usr/local/bin/svscanboot &'
sleep 5 && svstat penТеперь вы с помощью браузера можете удостовериться, что балансировка работает.
Так же изучите /var/log/pen/current на обоих брандмауэрах.
Часть 3: Отказоустойчивость
1) Сперва сконфигурируйте syslog для сбора сообщений VRRP.
touch /var/log/freevrrpd.log
cat << _EOF_ >> /etc/syslog.conf!freevrrpd
*.* /var/log/freevrrpd.log_EOF_
2) Конфигурирование FreeVRRPd
До этого пункта, обе машины были равноправны. Теперь вам необходимо выбрать, какой FWLB будет primary.
На этой машине скопируйте /usr/local/etc/freevrrpd.conf.sample в /usr/local/etc/freevrrpd.conf.Отредактируйте файл, как показано ниже:
# public-facing VRID
[VRID]
serverid = 1
interface = fxp0
priority = 255
addr = 198.123.111.1/32
password = vrid1
vridsdep = 2# backend VRID
[VRID]
serverid = 2
interface = fxp1
priority = 255
addr = 10.0.0.1/32
password = vrid2
vridsdep = 1В результате мы получим 2 VRID - один для внешней сети, второй для внутренней,
который будет использоваться кластером серверов.
В этом примере оба VRIDs сконфигурированы, чтобы считать этот хост главным при выборах VRRP.
Заметьте - оба VRID зависят друг от друга, что определено полем "vridsdep".
Это означает, что, если один из интерфейсов в FWLB падает, другой автоматически перейдет в резервный режим,
переводя оба интерфейса на резервный FWLB.Это позволит избежать попыток отправить данные через брандмауэр с упавшим внешним интерфейсом.
Теперь вы должны скопировать этот файл на slave FWLB, и изменить оба поля priority на значение 100.
Измените пароль на что-то более безопасное, чем на примере, но особо не расчитывайте на пароли VRRP
в плане безопасности. Если другой брандмауэр, находящийся вне связки сможет общаться с вашими по VRRP,
то у вас будут проблемы.
3) Запуск FreeVRRPdТеперь вы можете запустить freevrrpd на обоих брандмуэрах:
cp /usr/local/etc/rc.d/freevrrpd.sh{.sample,}
/usr/local/etc/rc.d/freevrrpd.sh start
Часть 4: Проверка отказоустойчивостиТеперь нам необходимо проверить получившуюся систему на отказоустойчивость.
Сперва только надо запустить на обоих FWLB SSH, чтобы была возможность
проверять правильность переключения интерфейсов. Попробуйте следующие сценарии:- С одной из машин кластера залогиньтесь по SSH на 10.0.0.1(внутренний интерфейс).
Убедитесь, что это именно master FWLB.
- Сделайте попытку соединения на 198.123.111.1(внешний интерфейс), порт 80 и
посмотрите /var/log/pen/current, чтобы проверить факт соединения.
- Отключить внешний интерфейс FWLB1.
- Проверьте логи на FWLB2. Сделайте попытку соединения на 198.123.111.1,
порт 80, чтобы проверить факт соединения.
- Зайдите по SSH на 10.0.0.1. Вы должны увидеть FWLB2 в баннере SSH.
- Подключите внешний интерфейс к FWLB1. Проверьте, что оба интерфейса FWLB1 вернулись в состояние master.Теперь повторите тест, отключая внутренний интерфейс. Если есть такое желание,
то можно просто нажать Reset на FWLB1.
Примечания:Удаление серверов из пула:
Pen не может перманентно удалить сервера из пула, но мы можем указать ему игнорировать сервер,
пока, например, идет его обновление или что-то подобное. Для этого выполните команду:penctl localhost:8888 server $servername blacklist 99999
Это поместит сервер в черный список на 99999 секунд. Для возвращения сервера в пул выполните команду:
penctl localhost:8888 server $servername blacklist 1
Так мы выставим таймаут черного списка в 1 секунду, после чего сервер вернется в пул.
Перманентное удаление или добавление серверов в пул:
В случае, если есть необходимость добавить или удалить из пула несколько серверов,
нужно отредактировать файл /service/pen/run. Просто добавьте имена хостов в конец команды запуска pen и выполните:svc -t /service/pen
Эта команда пошлет сигнал TERM и перезапустит pen. Хотя эта операция и не должна сказаться на доступности сервиса,
лучше такие вещи делать в специально определенное время.Ссылки:
http://www.faqs.org/rfcs/rfc2338.html
http://www.bsdshell.net/hut_fvrrpd.html
http://siag.nu/pen/
http://cr.yp.to/daemontools.html
http://smarden.org/runit
© 2004 David Thiel --- lx [@ at @] redundancy.redundancy.orgURL: http://redundancy.org/fbsd_lb.html
Обсуждается: http://www.opennet.me/tips/info/1725.shtml
man CARP
Статья 2004 года, а carp появился в FreeBSD только в апреле 2005 года (FreeBSD 5.4).
и смысл постить статью 2004 года в 2008?
а зачем выкладывать анахронизмы? :)
судя по схеме, каждый из switch'ей будут "single point of failure".
вообще да, отжиг. сделать две точки отказа вместо одной - тру.
Ну, свичей может быть и 10, если использовать HSRP
а как нам поможет HSRP? ;)
Там же шарится один ip-адрес.
HSRP не даёт балансировки нагрузки.
очень смущает последнее "svc -t /service/pen" , похоже что с Solaris писалось
откройте для себя daemontools от djb
VRRP очень даже полезен в плане связи роутера под FreeBSD с роутером на другой платформе, не поддерживаюшей CARP.
Был случай одновременного зависания двух роутеров на FreeBSD, а другая платформа может быть устойчива к определенному виду атаки.
Жаль только, что VRRP нет в ядерном режиме.