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

Недавно появилась задача создать и протестировать отказоустойчивый кластер на 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.

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

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

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

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