Простая и оригинальная схема, реализованная мной у клиентов.
A. Исходные:
Есть локальная сеть 25 рабочих станций (на схеме - "клиенты"), которые используют Linux-сервер (unix1) как шлюз в Сеть.
На этом боксе работают :
Сервер unix1, а через него локальная сеть, соединяется с Интернетом через двух провайдеров:
Распределение трафика по каналам выполнено с помощью iptables/netfilter таким образом, чтобы ключевые сервисы ходили через более надежный, но дорогой кабельный канал, а трафик от squid и ёмкие внешние закачки - через неограниченный по объему трафика, но менее устойчивый и менее быстрый беспроводной канал. Для этого на unix1 задействованы два сетевых интерфейса - один (eth0) непосредственно соединяется с кабельным модемом, второй (eth1) через общий коммутатор ЛС - с Wimax устройством.
И вот, все это хозяйство успешно работает несколько лет, иногда правда случаются неприятности - то винчестер ахнет, то провайдер тихо умрет на неопределенный срок. Для минимизации неприятных последствий, от этого есть защита - полное резервное копирование жесткого диска с возможностью загрузки и работы со второго запасного диска, а также набор скриптов, которые смотрят круглосуточно через оба канала и переключают трафик в зависимости от доступности провайдеров.
Однако, нет пока защиты от полного выхода из строя сервера unix1!
Тут на ум приходят сами слова Server Pool - не для того, чтобы раскидать по кластеру огромный, но однообразный трафик, а для того, чтобы дублировать функции основного сервера и в случае его поломки немедленно восстановить все рабочие процессы.
B. Server Pool
Итак, закупаем необходимое железо и собираем в 1U-корпусе сервер-"дублер" unix2, после чего устанавливаем на него в точности то же самое ПО, которое работает на основном сервере. Но лучше сразу сообразить, какие адреса поставить на сетевых интерфейсах. Очевидно, нужно выбрать IP в тех же сегментах WAN и LAN, что и на основном сервере. Для этого в схему подключения добавляется простой хаб для микса обоих серверов unix1 и unix2 на входе кабельного модема.
Здесь конечно можно бы и остановиться - действительно, когда работают два одинаковых сервера (но с разными IP-адресами), в случае поломки основного всегда есть возможность за какое-то время перенести все функции на запасной сервер. Например, написать скрипт, который бы менял на unix2 IP адреса на те же, что были у поломанного unix1, затем перезагрузка и вроде бы все снова заработает. Однако, есть та проблема, что коммутатор держит у себя в памяти таблицу соответствия MAC-адресов, поэтому для реальной замены нужно будет еще и как-то перегрузить эту таблицу на коммутаторе (flush). Если коммутатор может выполнить эту процедуру удаленно, например, по SNMP, то и замечательно. Однако, в противном случае придется после замены IP еще и перезагружать коммутатор. Можно попробовать еще и MAС-адреса на unix2 изменить, но все равно у такой схемы достаточно много минусов - взять хотя бы синхронизацию серверов до и после переключения ! Это нетривиальная задача, если вдуматься.
Конечно, было бы неплохо подключить оба сервера через некоторое устройство, которое бы их мониторило и переключало трафик с основного на запасной, как это делается после Health Monotoring Probe на дорогих моделях Cisco Catalyst. Ведь тогда нам не придется менять адреса на запасном сервере. Если же такого устройства нет и менять адреса мы не хотим, тогда очевидно на всех рабочих станциях локальной сети после замены сервера пришлось бы переписать настройки браузеров, Outlook и т.п., что конечно тоже возможно, но крайне нежелательно.
Итак? Вперед в магазин за Cisco ..? 3000$ ??
Нет, для нашего случая достаточно 200$ - нужно купить небольшой load balancer (LB) на два WAN-выхода. Неважно, чтобы он сам переключал каналы - достаточно, чтобы это можно было сделать через веб-интерфейс администратора. Также добавим по третьей сетевой карте (eth2, 10.0.0.0) на оба сервера, если их там еще нет, но лучше сразу motherboard с тремя.
WAN-выходы с LB направим на эти дополнительные сетевые интерфейсы серверов - WAN1 -> unix1, WAN2 -> unix2. Соединим один из восьми входов LB с коммутатором ЛС и присвоим LB адрес из сегмента нашей ЛС.
Перепишем настройки на клиентах ЛС - укажем как gateway адрес LB, а в качестве адреса прокси и почтового сервера - некоторый фиктивный IP адрес в сегменте 172.16.0.0, который на серверах пусть будет недостижим, но пакеты на который будет отлавливать netfilter и перенаправлять на свои порты:
$IPTABLES -A POSTROUTING -o eth1 -p tcp -m tcp -d 172.16.0.1 -j SNAT --to-source 192.168.4.201 -t nat
$IPTABLES -A PREROUTING -s 10.0.0.202 -i eth2 -p tcp -m tcp --dport 3128 -d 172.16.0.1 -j REDIRECT --to-ports 3128 -t nat
$IPTABLES -A PREROUTING -s 10.0.0.202 -i eth2 -p tcp -m tcp --dport 993 -d 172.16.0.1 -j REDIRECT --to-ports 993 -t nat
$IPTABLES -A PREROUTING -s 10.0.0.202 -i eth2 -p tcp -m tcp --dport 25 -d 172.16.0.1 -j REDIRECT --to-ports 25 -t nat
Теперь осталось запустить на unix2 скрипты, которые будут смотреть на unix1 через оба интерфейса eth0 и eth1 (таким образом выполняя health monitoring probe) и при обнаружении факта "падения" основного сервера переключать wget-скриптом трафик через LB с WAN1 на WAN2.
A. Исходные:
Есть локальная сеть 25 рабочих станций (на схеме - "клиенты"), которые используют Linux-сервер (unix1) как шлюз в Сеть.
На этом боксе работают :
- а) squid (прокси-сервер) - для брожения по Интернету;
- б) Cyrus IMAP - для складирования корпоративной почты; непосредственно из локальной сети (ЛС) он принимает почту от sendmail; с POP3 у провайдера почту ему периодически доставляет fetchmail.
- в) sendmail - для отправки почты из ЛС на relay-сервер провайдера, или на свой Cyrus (см. выше);
- г) cacheing DNS-сервер named - нужен и для squid, и для sendmail;
- д) HTTP-сервер apache - для возможности извне скачивать файлы со своего веб-узла;
- е) Samba-сервер,чтобы из ЛС можно было складировать файлы в папки apache.
Сервер unix1, а через него локальная сеть, соединяется с Интернетом через двух провайдеров:
И вот, все это хозяйство успешно работает несколько лет, иногда правда случаются неприятности - то винчестер ахнет, то провайдер тихо умрет на неопределенный срок. Для минимизации неприятных последствий, от этого есть защита - полное резервное копирование жесткого диска с возможностью загрузки и работы со второго запасного диска, а также набор скриптов, которые смотрят круглосуточно через оба канала и переключают трафик в зависимости от доступности провайдеров.
Однако, нет пока защиты от полного выхода из строя сервера unix1!
Тут на ум приходят сами слова Server Pool - не для того, чтобы раскидать по кластеру огромный, но однообразный трафик, а для того, чтобы дублировать функции основного сервера и в случае его поломки немедленно восстановить все рабочие процессы.
B. Server Pool
Итак, закупаем необходимое железо и собираем в 1U-корпусе сервер-"дублер" unix2, после чего устанавливаем на него в точности то же самое ПО, которое работает на основном сервере. Но лучше сразу сообразить, какие адреса поставить на сетевых интерфейсах. Очевидно, нужно выбрать IP в тех же сегментах WAN и LAN, что и на основном сервере. Для этого в схему подключения добавляется простой хаб для микса обоих серверов unix1 и unix2 на входе кабельного модема.
Здесь конечно можно бы и остановиться - действительно, когда работают два одинаковых сервера (но с разными IP-адресами), в случае поломки основного всегда есть возможность за какое-то время перенести все функции на запасной сервер. Например, написать скрипт, который бы менял на unix2 IP адреса на те же, что были у поломанного unix1, затем перезагрузка и вроде бы все снова заработает. Однако, есть та проблема, что коммутатор держит у себя в памяти таблицу соответствия MAC-адресов, поэтому для реальной замены нужно будет еще и как-то перегрузить эту таблицу на коммутаторе (flush). Если коммутатор может выполнить эту процедуру удаленно, например, по SNMP, то и замечательно. Однако, в противном случае придется после замены IP еще и перезагружать коммутатор. Можно попробовать еще и MAС-адреса на unix2 изменить, но все равно у такой схемы достаточно много минусов - взять хотя бы синхронизацию серверов до и после переключения ! Это нетривиальная задача, если вдуматься.
Конечно, было бы неплохо подключить оба сервера через некоторое устройство, которое бы их мониторило и переключало трафик с основного на запасной, как это делается после Health Monotoring Probe на дорогих моделях Cisco Catalyst. Ведь тогда нам не придется менять адреса на запасном сервере. Если же такого устройства нет и менять адреса мы не хотим, тогда очевидно на всех рабочих станциях локальной сети после замены сервера пришлось бы переписать настройки браузеров, Outlook и т.п., что конечно тоже возможно, но крайне нежелательно.
Итак? Вперед в магазин за Cisco ..? 3000$ ??
Нет, для нашего случая достаточно 200$ - нужно купить небольшой load balancer (LB) на два WAN-выхода. Неважно, чтобы он сам переключал каналы - достаточно, чтобы это можно было сделать через веб-интерфейс администратора. Также добавим по третьей сетевой карте (eth2, 10.0.0.0) на оба сервера, если их там еще нет, но лучше сразу motherboard с тремя.
WAN-выходы с LB направим на эти дополнительные сетевые интерфейсы серверов - WAN1 -> unix1, WAN2 -> unix2. Соединим один из восьми входов LB с коммутатором ЛС и присвоим LB адрес из сегмента нашей ЛС.
Перепишем настройки на клиентах ЛС - укажем как gateway адрес LB, а в качестве адреса прокси и почтового сервера - некоторый фиктивный IP адрес в сегменте 172.16.0.0, который на серверах пусть будет недостижим, но пакеты на который будет отлавливать netfilter и перенаправлять на свои порты:
$IPTABLES -A POSTROUTING -o eth1 -p tcp -m tcp -d 172.16.0.1 -j SNAT --to-source 192.168.4.201 -t nat
$IPTABLES -A PREROUTING -s 10.0.0.202 -i eth2 -p tcp -m tcp --dport 3128 -d 172.16.0.1 -j REDIRECT --to-ports 3128 -t nat
$IPTABLES -A PREROUTING -s 10.0.0.202 -i eth2 -p tcp -m tcp --dport 993 -d 172.16.0.1 -j REDIRECT --to-ports 993 -t nat
$IPTABLES -A PREROUTING -s 10.0.0.202 -i eth2 -p tcp -m tcp --dport 25 -d 172.16.0.1 -j REDIRECT --to-ports 25 -t nat
Теперь осталось запустить на unix2 скрипты, которые будут смотреть на unix1 через оба интерфейса eth0 и eth1 (таким образом выполняя health monitoring probe) и при обнаружении факта "падения" основного сервера переключать wget-скриптом трафик через LB с WAN1 на WAN2.
