Геораспределенный кластер на Windows 2008 Server

Задача на первый взгляд не сложная, за исключением нескольких моментов:



  • кластер было необходимо построить без использования SAN-хранилища;

  • узлы данного кластера должны располагаться в разных сетях (т.е. территориально распределены) и не иметь между собой прямого соединения;

  • количество узлов в кластере равно двум.


Понятно, что основная задача – не кластеризовать сервер печати, а проверить как можно и можно ли построить геораспределенный кластер в таких условиях.


До этого я ни разу не сталкивался с такой задачей – делалось все в первый раз. Стоит отметить, что делалось на виртуальных машинах Hyper-V – сейчас это модно, внедрение повсеместное;) Поэтому хотел бы поделиться некоторыми моментами (вопросами), которые могут у кого-нибудь возникнуть в процессе развертывания гео-распределенного кластера.


Вообще говоря, кластер – это группа компьютеров объединенных вместе для увеличения доступности StateFull-приложений и служб – читай для обеспечения отказоустойчивости.


Для создания отказоустойчивого кластера необходим, как минимум, один общий ресурс, доступный всем узлам кластера. К данному ресурсу в определенный момент времени может иметь доступ и управлять им, только один из узлов кластера. Ресурс этот, как не трудно догадаться, некое хранилище информации. Организовать его можно двумя способами – используя iSCSI или SAN хранилище. Стоит отметить, что SAN-хранилище очень не дешевое удовольствие. Тем не менее оно есть ;) Но использовать его для тестов и поднятия Сервера Печати не целесообразно. У iSCSI, по утверждениям многих, нет будущего – да оно и не нужно (имеется в виду организовывать iSCSI-хранилище). Поэтому было решено воспользоваться программной реализацией iSCSI-цели – утилитой StarWind. Тем более что iSCSI-инициатор уже встроен в операционную систему Windows 2008 Server. Плюс утилита StarWind позволяет абсолютно бесплатно подключать хранилища объемом не более 2 Гб – этого вполне достаточно как для проведения тестов, так и промышленного использования сервера печати.


Как все должно выглядеть в конечном итоге. Скажем в городе А находиться один узел кластера. В городе Б находиться второй узел кластера. Оба узла подключены к общему хранилищу. Кластер выполняет роль SQL-сервера. Если выходит из строя один из узлов кластера, являющийся в данный момент его владельцем (и фактически предоставляющий доступ к базе данных SQL), его функции тут же подхватывает второй узел. В результате сервис остается доступным – все клиенты просто перенаправляются ко второму узлу кластера. При этом не забываем, что узлы кластера находятся в разных городах. Это и есть геораспределенный кластер.


Настройку iSCSI-цели, ее подключение и настройку ролей серверов описывать не буду – в интернете достаточно документации на эту тему. Скажу лишь, что в качестве модели Кворума была выбрана модель Node and File Share Majority.


Первая проблема, которая возникла – как заставить кластер работать с узлами в разных сетях. Оказалось, что проблемы здесь нет – кластер без проблем подключает узлы в разных сетях и подсетях. При необходимости, можно дополнительно прописать адреса (см. рисунок).



Геораспределенный кластер на Windows 2008 ServerГеораспределенный кластер на Windows 2008 Server
Геораспределенный кластер на Windows 2008 ServerГеораспределенный кластер на Windows 2008 Server

Опытным путем, был установлен механизм работы кластера, который заключается в следующем – при создании новой службы кластер создает в DNS запись типа A с IP-адресом и именем данного кластера. При выходе из строя одного из узлов кластера, DNS-запись перезаписывается. Таким образом, имя кластера остается прежним, но IP-адрес изменяется. Если узел, который становиться главным, находиться в другой подсети – то и адрес кластера также будет из той же подсети (адрес задается предварительно при создании кластера). Соответственно все запросы клиентов будут перенаправляться в нужную подсеть.


Вторая проблема, которая возникла – время жизни записи кластера в DNS. По умолчанию оно составляет 20 минут, т.е. если один из узлов кластера выходит из строя – клиенты не узнают об этом в течении 20 минут (в худшем варианте). Время подхвата функций вышедшего из строя узла составляет порядка 15-20 секунд. Т.е. работоспособность сервиса восстанавливается в течении 20 секунд, но клиенты об этом узнают только через 20 минут. Это не приемлемо. Вручную задать время жизни DNS-записи не получается – при выходе из строя одного из узлов запись в DNS перезаписывается полностью, вместе со значением поля TTL. Менять же TTL для всей DNS-зоны значит многократно увеличивать нагрузку на DNS-сервера. Уменьшить значения поля TTL оказалось возможно с помощью команды cluster:


cluster /cluster:<ClusterName> res <NetworkNameResource> /priv HostRecordTTL=<TimeInSeconds>

Вот собственно и все основные моменты, о которых хотелось бы рассказать. Обо всем остальном, что связанно с кластерами можно без особого труда найти документацию в интернете.

Зарубин Иван Эксперт по Linux и Windows

Парашютист со стажем. Много читаю и слушаю подкасты. Люблю посиделки у костра, песни под гитару и приближающиеся дедлайны. Люблю путешествовать.

Вдохновлен

Комментарии (1)

  • Dan

    Вы видимо ошиблись говоря “Плюс утилита StarWind позволяет абсолютно бесплатно подключать хранилища объемом не более 2 Гб”. Насколько я помню 2Тб ограничение