вторник, 22 марта 2011 г.

Без Cisco делаем Server Pool

Простая и оригинальная схема, реализованная мной у клиентов.

A. Исходные:

Есть локальная сеть 25 рабочих станций (на схеме - "клиенты"), которые используют Linux-сервер (unix1) как шлюз в Сеть.

На этом боксе работают :
  • а) squid (прокси-сервер) - для брожения по Интернету; 
  • б) Cyrus IMAP - для складирования корпоративной почты; непосредственно из локальной сети (ЛС) он принимает почту от sendmail; с POP3 у провайдера почту ему периодически доставляет fetchmail
  • в) sendmail - для отправки почты из ЛС на relay-сервер провайдера, или на свой Cyrus (см. выше); 
  • г) cacheing DNS-сервер named - нужен и для squid, и для sendmail
  • д) HTTP-сервер apache - для возможности извне скачивать файлы со своего веб-узла; 
  • е) Samba-сервер,чтобы из ЛС можно было складировать файлы в папки apache.

Сервер 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.



среда, 2 марта 2011 г.

Filezilla and Co. - Обзор ПО для managed FTP под Линукс. D. Motivation File Browse

4. Motivation File Browse

Лицензия GPL
февраль 2011

программа является сокращенным вариантом GPL-релиза моей perl-программы tmm (http://sourceforge.net/projects/tclub). Для работы используется javascript-интерфейс; админы и клиенты видят разные окна одной программы, похожие, но с разными наборами функций. Например, админ может создать логин клиента, задать или изменить пароль.


В этой оригинальной программе у веб-пользователей совсем нет домашних каталогов, вместо них есть "тикеты" на закачку файлов, которые хранятся в базе данных. Таким образом, авторизовавшись на входе в программу, клиент видит таблицу своих тикетов. В каждом тикете указаны срок действия тикета, название файла, ссылка на старт закачки и комментарии создавшего тикет админа.

Контроль за файлами осуществляется через Samba; каких-то дополнительных функций по работе с файловой системой у самой программы не предусмотрено, кроме пожалуй, возможности автоматически  удалять временные файлы после из успешной закачки.

В качестве "рабочей" лошади http-сервера использован популярный GPL пакет perlball. Для хранения и обработки пользовательских данных используется СУБД PostgreSQL; для javascript- интерфейса - библиотеки Mootools.

Ниже приведен отчет о "боевых" сравнительных  испытаниях Motivation File Browse и GoAnywhere Services:

GoAnywhere Services vs. Motivation File Browse

1. Условия тестирования

Скачивался пробный файл (37 Mb), время скачивания на скорости 100 Kbyte/sec ~ 6 минут.

Во время скачивания я устраивал следующие "неприятности":

A. Выключал и снова включал интерфейс скачивания (ifconfig);
Б. Перезапускал сеть (network restart);
С. Включал/выключал запрет на пакеты на порт скачивания (iptables)

==============
1. GA Services имеет 2 интерфейса HTTPS:
 
a) Enhanced
b) Basic

Работа в интерфейсе Enhanced начинается с запуска Java-апплета. Апплет удачно стартует на моем браузере Firefox 3.6 с установленным обновлением Java, но только с первого запуска.
 
Попытки поменять интерфейс с Enhanced на Basic и обратно на Enhanced в браузере после запуска апплета почти всегда приводят к тому, что окно Enhanced-апплета повторно не появляется - требуется перезапуск браузера.

Кроме того, в Enhanced-интефейсе нельзя приостановить начатую загрузку, т.е. у апплета нет такой функции. Можно совсем отменить закачку, перегрузив апплет.


NB: После того, как закачка началась, обновление страницы браузера (т.е. перезапуск апплета) приводит к отмене загрузки !

Устойчивость к помехам - нулевая. Иначе говоря, любая из "неприятностей", указанных выше, убивает закачку и требует перезапуска апплета.

Интерфейс Basic не требует запуска Java-апплета и использует Firefox Download Manager, однако как указанные помехи, так и просто попытка приостановить закачку через функцию Download Manager убивает закачку. Похоже на то, что сервер не поддерживает Range-запросы.

=============
Моя программа:

Для скачивания используется Firefox Download Manager. Закачка может быть приостановлена и возобновлена в Download Manager без всяких проблем, в 100% случаев. Кроме того, только в одном случае (выключение  и повторное включение канала скачивания), и то в одном эпизоде, произошла отмена закачки; во всех остальных случаях устраиваемых "неприятностей" закачка успешно возобновлялась с того места, на котором была остановлена помехой.