Около трёх лет я занимался интеграцией продуктов компании Инфотекс. За это время я близко познакомился с большинством её продуктов и в целом, считаю, что они заслуженно получили столь широкое распространение в России. Среди основных их преимуществ можно отметить наличие сертификатов ФСБ и ФСТЭК, широкий ассортимент продуктов, включающий как программные, так и программно-аппаратные решения, легкое и удобное масштабирование и администрирование сети, хорошую техподдержку, удобное лицензирование, простоту установки и настройки, ну и конечно же цена по сравнению с аналогами. Есть, конечно, и недостатки, но у кого их нет? Однако, самый, на мой взгляд, неудачный продукт из всей линейки это отказоустойчивый кластер ViPNet Failover и далее я объясню почему.
Как гласит документация, режим кластера горячего резервирования предназначен для горячей замены функций одного из серверов с ПО ViPNet другим сервером в случае сбоя первого. Кластер горячего резервирования серверов состоит из двух взаимосвязанных компьютеров, один из которых (активный) выполняет функции сервера (координатора) ViPNet, а другой компьютер (пассивный) находится в режиме ожидания. В случае сбоев, критичных для работоспособности ПО ViPNet на активном сервере (в первую очередь в случае сбоев в работе сети или сетевого оборудования), пассивный сервер переключается в активный режим, принимая на себя нагрузку и выполняя функции координатора вместо сервера, который зафиксировал сбой. При работе в режиме кластера горячего резервирования система защиты от сбоев также выполняет функции одиночного режима, то есть обеспечивает постоянную работоспособность основных служб, входящих в состав ПО ViPNet Coordinator Linux.
Отмечу, что сам по себе Vipnet Coordinator Linux неплох, и всё портит сама схема горячего резервирования.
Весь кластер, с точки зрения других компьютеров сети, имеет один IP-адрес на каждом из своих сетевых интерфейсов. Этим адресом обладает сервер, находящийся в данный момент в активном режиме. Сервер, находящийся в пассивном режиме, имеет другой IP-адрес, который не используется другими компьютерами для связи с кластером. В отличие от адресов активного режима, в пассивном режиме каждый из серверов имеет свой собственный адрес на каждом из интерфейсов, эти адреса для двух серверов не совпадают.
В конфиге failover.ini содержатся 3 типа разделов параметров. В разделе [channel] описываются IP-адреса резервируемых интерфейсов:
[channel]
device= eth1
activeip= 192.168.10.50
passiveip= 192.168.10.51
testip= 192.168.10.1
ident= if-1
checkonlyidle= yes
В разделе [network] описываются параметры резервирования:
[network]
checktime= 10
timeout= 2
activeretries= 3
channelretries= 3
synctime= 5
fastdown= yes
В [sendconfig] прописывается адрес сетевого интерфейса второго сервера, по которому будет синхронизироваться работа кластера:
[sendconfig]
device= eth0
Опять же приведу алгоритм резервирования из документации:
Алгоритм работы на активном сервере следующий. Через каждые checktime секунд проводится проверка работоспособности каждого из приведенных в конфигурации интерфейсов. Если параметр checkonlyidle установлен в yes, то анализируется входящий и исходящий сетевой трафик, прошедший через интерфейс. Если разница в количестве пакетов между началом и концом интервала положительна, то считается, что интерфейс функционирует нормально, и счетчик отказов для этого интерфейса обнуляется. Если в течение данного интервала не было послано и принято ни одного пакета, то включается дополнительный механизм проверки, заключающийся в посылке эхо-запросов до ближайших маршрутизаторов. Если параметр checkonlyidle установлен в no, то механизм дополнительной проверки используется вместо основного, то есть каждые checktime секунд посылаются пакеты до адресов testip. Затем в течение времени timeout ожидаются ответы. Если на каком-либо интерфейсе ответа нет ни от одного адреса testip, то его счетчик сбоев увеличивается на единицу. Если хотя бы на одном интерфейсе счетчик сбоев не равен нулю, то немедленно посылаются новые пакеты до всех testip и ожидается ответ в течение timeout. Если в процессе новых посылок на интерфейс, счетчик сбоев которого не равен нулю, приходит ответ, его счетчик сбоев обнуляется. Если после какой-либо посылки счетчики сбоев на всех интерфейсах становятся равны нулю, то происходит возврат в основной цикл, новое ожидание в течение checktime и так далее. Если же после какого-то числа новых посылок счетчик сбоев хотя бы одного интерфейса достигнет значения channelretries, то фиксируется полный отказ интерфейса и начинается перезагрузка системы. Таким образом, максимальное время неработоспособности интерфейса до того, как система защиты от сбоев сделает вывод об этом, равно checktime + (timeout * channelretries).
На пассивном сервере алгоритм немного отличается. Раз в checktime секунд производится удаление записей в системной ARP-таблице для всех activeip. Затем посылаются UDP-запросы со всех интерфейсов на адреса activeip, в результате чего система сначала посылает ARP-запрос и только в случае получения ответа посылает UDP-запрос. После окончания интервала ожидания ответа timeout проверяется наличие ARP-записи для каждого activeip в системной ARP-таблице, по наличию которой делается вывод о работоспособности соответствующего интерфейса на активном сервере. Если ни от одного интерфейса не был получен ответ, счетчик сбоев (он один на все интерфейсы) увеличивается. Если хотя бы от одного интерфейса ответ был получен, счетчик сбоев обнуляется. Если счетчик сбоев достигает значения activeretries, то производится переключение в активный режим. Максимальное время, проходящее от перезагрузки активного сервера до обнаружения пассивным сервером этого факта, равно checktime + (timeout * activeretries).
Общее время неработоспособности системы при сбое может быть немного больше, чем checktime * 2 + timeout * (channelretries + activeretries). Это связано с тем, что после начала перезагрузки сбойного сервера система переводит его интерфейсы в нерабочее состояние не сразу, а через некоторое время, после остановки других подсистем. Поэтому, например, если проверяются два интерфейса и только на одном произошел сбой, то адрес второго интерфейса будет доступен еще некоторое время, в течение которого пассивный сервер будет получать от него ответы. Обычно время от начала перезагрузки до выключения интерфейсов не превышает 30 секунд, однако оно может сильно зависеть от быстродействия компьютера и количества работающих на нем сервисов.
На первый взгляд всё верно, как только с активным сервером неполадки, он перезагружается, а его место занимает пассивный. Что же мы имеем на практике?
- Нельзя просто взять и подключить защищаемый ресурс (например, сервер 1С) к файловеру через неуправляемый коммутатор, точнее, конечно можно, но в таком случае в качестве тестового IP необходимо будет указать адрес самого защищаемого ресурса. В следствие чего при перезагрузке сервера 1С, например, для планового обслуживания или обновлении ПО, файловер тоже будет вырубаться. Это, конечно, не проблем если защита доступа к нему является единственной задачей, но в большинстве случаев это не так.
- Отказоустойчивость файловера зависит от отказоустойчивости каждого из тестовых адресов, и становится меньше с каждым дополнительным сетевым интерфейсом. В моей практике был случай, когда какой-то работник ЦОДа случайно отключил от питания коммутатор служащий тестовым узлом, в результате кластер вошёл в непрерывный цикл перезагрузки, из-за чего локальные машины с Vipnet клиентами не могли подключиться к домену и их работа была парализована, до тех пор пока нас не пустили в ЦОД.
Получается, что отказоустойчивость файловера возможна лишь в сферическом вакууме, где вся сетевая инфраструктура работает без сбоев. Кто-то может сказать, что это вынужденная мера, но если что-то случиться с одним из серверов, например, вылетит сетевой интерфейс, то он перезагрузится, его работоспособность восстановится и алгоритм резервирования докажет свою полезность. Однако, на практике был случай когда один из интерфейсов файловера действительно заглючил, и он стал перезагружаться согласно описанной выше схеме, при этом проблема после перезагрузки никуда не делась. Чтобы избавиться от глюка пришлось вручную отключить питание, так что и в этом случае отказоустойчивость видна лишь на бумаге.
Всё это можно было исправить, если бы алгоритм включал в себя ещё одно условие: активный сервер не должен перезагружаться, если пассивный выключен. Вроде бы нехитрое условие, обеспечивающее реальную отказоустойчивость, так и не было добавлено разработчиками. Я могу лишь предполагать, что это связано с необходимостью внесения изменений в ядро и его повторной сертификации.
В случае же исправного сетевого окружения и серверного оборудования аптайм серверов был практически непрерывным. Один из первых файловеров, который мне пришлось установить работает уже 3 года и за это время схема горячего резервирования отрабатывала только во время модернизации ПО или из-за общих технических работ в ЦОДе. В общем реальная польза от такой схемы возможна лишь в случае аппаратного сбоя в одной из нод кластера, чего в моей практике ещё не случалось.
Была надежда, на Vipnet Cluster Windows, но Инфотекс, к сожалению, его не осилил, а жаль, схема резервирования была очень многообещающей.
В общем, мой совет таков, если вам не нужен отказоустойчивый криптошлюз для галочки, то с файловером лучше не заморачиваться, а пользоваться обычным Vipnet Linux координатором, он сам по себе достаточно надёжен, особенно если его не трогать ;)
Автор: malan
