Создание отказоустойчивого кластера DNS на базе MS Windows Server 2008 R2

Необходимое предисловие от 30.03.17: Сегодня с удивлением обнаружил, что данное произведение (написанное как наполовину серьёзное по мотивам давнего эпичного обсуждения на «зелёном») некоторыми коллегами всерьёз рассматривается  (например, как здесь) в качестве инструкции по созданию рабочего отказоустойчивого решения для размещения зон DNS. Так вот, ответственно заявляю: эта статья — не инструкция по созданию отказоустойчивой DNS. Отказоустойчивость DNS достигается куда более простыми средствами: вторичными серверами зон. Использование же для построения отказоустойчивой системы DNS решения из этой статьи по сути  аналогично ректальному способу удаления гланд из известного анекдота: возможно, но трудно. Впрочем, описанные здесь техники, если к ним подходить творчески, могут пригодиться для кластеризации других нагрузок, напрямую службой кластеризации Windows не поддерживаемых. Короче, я вас предупредил.

Введение

Думаю, каждый системный администратор понимает важность сохранения работоспособности подведомственной ему информационной системы даже в случае возникновения сбоев или отказов некоторых ее компонентов. Одним из наиболее эффективных способов обеспечения устойчивости к отказам и сбоям в таких случаях является использование кластерных технологий, позовляющих дублировать критически важные элементы системы и, в случае отказа основных элементов системы, автоматически подключать в работу дублирующие элементы. Фирма Microsoft предоставляет возможность создавать отказоустойчивые кластеры на базе редакций Entrprise и Datacenter своей серверной операционной системы Windows Server 2008 R2.

Одной из важнейших служб в современных компьютерных сетях является система именования доменов (DNS), преобразующая имена компьютеров в их сетевые адреса, и позволяющая, таким образом, использовать при обращении к различным сетевым службам эти удобные для восприятия человеком имена, вместо неудобных числовых сетевых адресов. К сожалению, фирма Microsoft не предлагает в числе кластеризуемых служб Windows Server варианта отказоустойчивый кластеризации сервера DNS. тем не менее, пользуясь этим руководством, Вы можете самостоятельно исправить это упущение.

В качестве исходного пункта для построения нашего отказоустойчивого кластера DNS возьмем двухузловой кластер с общим хранилищем на базе двух рядовых серверов в домене. Например, можно взять в качестве основы отказоустойчивый кластер файлового сервера, пошаговое руководство по установке которого есть  в MS Technet Library.  Серверы — узлы кластера, на примере которых в данном руководстве объясняется процесс построение кластера DNS называются в нашем примере NODE1 и NODE2, сам кластер — FTC01.

Описание процедуры создания кластерного сервера DNS.

Этап 1. Установка роли сервера DNS
На обоих узлах будущего кластера DNS устанавливаем роль DNS Server.

Поскольку эта операция описана во многих руководствах, здесь она подробно не рассматривается.

Этап 2. Предварительное конфигурирование службы сервера DNS
На каждом из узлов кластера заходим в оснастку управления сервером DNS и останавливаем сервер DNS

На всякий случай, чтобы не было никаких фокусов с регистрацией имен DNS — удаляем в реестре старое имя сервера DNS: значение PreviousLocalHostName в ключе HKLM\System\CurrentControlSet\services\DNS\Parameters (потому что в случае, если запомненное в этом значении имя не совпадает с текущим именем хоста, то сервер DNS пытается отменить регистрацию этого запомненного имени).

Этап 3. Создане кластерной службы DNS
Для создания кластерной службы DNS запускаем оснастку Failover Cluster Manager, выбираем узел Services and applications и с помощью пункта Configure a Service or Application запускаем мастер High Availability Wizard.

Проходим с помощью кнопки Next через страницу приветствия (Before you begin) и попадаем на страницу выбора типа  службы и приложения. В случае сервера DNS проще всего кластеризовать его как службу, поэтому выбираем пункт Generic Service

Нажимаем кнопку Next и попадаем на следующую страницу — страницу выбора службы. На ней указываем нужную службу — DNS Server

По кнопке Next переходим на страницу настройки точки доступа для клиентов.
На ней необходимо указать имя и IP-адрес, которые клиенты смогутиспользовать для доступа к службе.

Имя можно указать произвольное, главное чтобы он не не совпадало ни с одним именем компьютера или другой кластерной службы или приложения. Для доступа клиентов к серверу DNS оно не используется — клиенты используют только адрес IP. В нашем примере имя кластера DNS — FTC01DNS. Т.к. мы используем статические адреса IP для адаптеров сети для подключения клиентов, то адрес точки доступа необходимо назначить вручную.

По нажатию кнопки Next переходим на страницу настройки репликации разделов реестра. Здесь нужно указать ветви реестра, в которых кластеризуемая служба хранит свою конфигурацию. Для сервера DNS надо ввести значения, указанные на рисунке

Указанные здесь ветви реестра будут копироваться в базу данных кластера и реплицироваться на все его узлы. Т.е., их содержимое будет одинаковым на всех узлах кластера. Кстати, менять значения в этих ветвях (не важно, как — через интерфейс ли программы управления или же напрямую в редакторе реестра) можно только на активном узле кластера DNS — иначе изменения будут потеряны. И на это нам придется обратить внимание на одном из дальнейших шагов настройки. Жмем несколько раз кнопку Next, проходя все оставшиеся страницы и дожидаемся окончания процесса конфигурации.

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

Прежде всего, хотя сервер DNS в Windows хранит свои настройки в реестре, но содержимое зон, для которых этот сервер является полномочным, хранится в файловой системе — в файлах зон. Хотя файлы зон и меняются редко и только администратором сервера — если не разрешено автоообновление записей, что для зон, размещенных на рядовом сервере DNS не рекомендуется, т.к. на нем невозможно обеспечить безопасное обновление  — но лучше не придумывать способ их самопальной синхронизации между узлами, а перенести их на кластерный диск: он будет доступен именно тому узлу, на котором выполняется кластерный сервер DNS — благо при наличии общего хранилища мы имеем возможность использовать кластерные диски. Процедура, как это делается описана ниже.

Этап 4. Создание кластерного диска для кластера серверов DNS
Самое первое, что надо сделать — это, собственно, создать само логическое дисковое устройство (LUN) в хранилище для будущего кластерного диска, и предоставить доступ к нему обоим узлам кластера. Как это сделать, здесь рассматриваться не будет, это зависит от модели хранилища и объясняется в соответствующем руководстве.

После того, как LUN создан и доступ к нему для узлов кластера предоставлен, необходимо удостовериться, что оба узла кластера имеют к нему доступ. Для этого на каждом из узлов в Диспечере Сервера заходим в узел Storage/Disk management и проверяем, что соответствующее дисковое устройство появилось в списке. При этом устройство будет находиться на обоих узлах в автономном (offline) состоянии.

Далее, для создания кластерного диска вновь созданный диск необходимо проинициализовать. Для этого на любом из узлов переводим с помощью команды локального меню этот диск в оперативное (online) состояние

инициализуем его, опять-таки, с помощью локального меню как базовый диск (обратите внимание — динамические диски службой кластеризации не поддерживаются)

После этого, чтобы сделать вновь созданное устройство доступным для службы кластеризации,  запускаем Диспетчер отказоустойчивого кластера, слева в иерархическом списке переходим к узлу дерева Storage и запускаем процедуру добавления диска с помощью локального меню этого узла.

Выбираем вновь созданный и проиницализованный диск

и добавляем его в список устройств внешней памяти, доступных для кластера.

Теперь нужно добавить это устройство в наш кластер DNS. Переходим к узлу нашего кластера FTC01DNS в Services and Applications и добавляем с помощью команды локального меню вновь созданный диск в в кластер DNS:


Добавленное устройство теперь будет принадлежать тому же узлу кластера, которому принадлежат и остальные ресурсы кластерного сервера DNS — имя, адрсес IP — и на котором выполняется сервис DNS Server. В нашем случае этим узлом оказался узел NODE1.

Теперь на кластерном диске надо создать раздел, в файловой системе которого будут храниться зоны кластерного сервера DNS. Для этого на узле, где выполняется сейчас кластерный сервис DNS (NODE1 в нашем примере), в Диспетчере Сервера переходим в узел Storage\Disk Management и создаем на кластерном диске (он должен находиться сейчас в режиме online) раздел, назначаем ему букву (для примера — Q) и форматируем его

Итак, мы создали кластерный диск для хранения зон DNS.

Этап 5. Настрока зависимостей для кластерного сервера DNS
Теперь укажем службе , что сервис DNS зависит от доступности кластерного диска, который мы добавили на предыдущем этапе, чтобы служба кластеризации не пыталась запускать сервис DNS Server в случае, если этот диск и хранящиеся на нем файлы зон недоступны.

Для этого в Диспетчере отказоустойчивого кластера выбираем слева в панели дерева в узле Services and Applications наш кластерный сервер DNS, и заходим в диалоговое окно свойств сервиса DNS Server его через локальное меню в панели просмотра

Переходим на вкладку Dependencies и добавляем во вторую строчку созданный на этапе 4 кластерный диск. Указываем в первом столбце, чтодля успешного запуска сервиса Server DSN необходимо оперативное (online) состояние и имени кластерного сервера, и кластерного диска- выбираем вариант AND

Теперь мы готовы перенести папку, в которой будут храниться файлы зон, на кластерный диск

Этап 6. Перенос папки для файлов зон.
Место расположения папки с фалами зон для сервера DNS задается в реестре, значением параметра DatabaseDirecory в ключеHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS. По умолчанию, т.е. если этого значения не существует, сервер DNS использует для хранения файлов зон папку DNS, находящуюся в папке %SystemRoot%\system32 (т.е. при установке в расположение по умолчанию — в папке C:\WINDOWS\system32). Эту папку мы скопируем впоследствии на кластерный диск DNS, но прежде нужно внести изменения в реестр — создать параметр DatabaseDirecory типа REG_SZ в укзанном ключе и установить нужное значение

Редактировать реестр нужно обязательно на том узле, где выполняется кластерный сервер DNS и обязательно при условии, что если кластерный сервер DNS находится в оперативном (online) режиме — в противном случае внесенные изменения будут перезаписаны содержимым этого ключа, реплицируемым из кластерной базы данных (как вы помните, мы указали при создании кластера, что этот ключ необходимо реплицировать на все узлы).

И только теперь можно перевести кластерный сервер DNS в автономный(offline) режим

чтобы скопировать папку DNS на кластерный диск.

Копируем папку DNS из папки C:\WINDOWS\system32 в корень диска Q:

После копирования папки можно перевести сервер опять в оперативный режим.
Теперь файлы зон DNS для кластерного сервера хранятся на кластерном диске.

Осталось несколько последних штрихов.

Этап 7 Настройка кластерного сервера DNS на прослушивание только кластерного IP
В принципе, это можно и не делать, но для красоты решения укажем, что наш кластерный сервер должен прослушивать порты DNS только на IP-адресе своего кластера. Изменения опять-таки надо вносить на узле, на котором выполняется в данный момент кластерный сервер DNS.

Для удобства управления имеет смысл внести изменения в сохраненные консоли DNS на узлах кластера — удалить из них сервер с именем узла и добавить туда сервер с именем кластера, чтобы можно было настраивать DNS, не задумываясь, на каком сейчас узле выполняется кластерный сервер.

Все, кластерный сервер DNS готов к работе.

Что дальше.

Реализацию кластерного сервера DNS можно усовершенствовать. Дело в том, что выбранный вариант реализации, через Generic Service, отличаясь простотой, имеет тот недостаток, что служба кластеризации не обнаруживает отказы сервера DNS, не приводящие к падению службы или остановке сервера-узла кластера. Например, если служба сервера DNS зависнет и перестанет отвечать на запросы, то это не будет обнаружено службой кластеризации. Это происходит, потому что функция обратного вызова IsAlive для Generic Service проверяет лишь, что соответствующая служба запущена, но не проверяет ее работспособность. Чтобы устранить этот недостаток, можно реализовать кластерный сервер DNS с помощью сценария (Generic Script) — тогда в подпрограмме сценария IsAlive можно будет делать все необходимые проверки работоспособности службы.

Реклама
  1. хаюшки, с почином. заходи в гости http://mossdevel.blogspot.com/

    • Sergant
    • 04.09.2012

    Спасибо за статью. Entrprise — можно поправить. А хорошо ли переводят статьи на портале technet?

    • Аноним
    • 13.03.2014

    Зачем? А как же репликация и второй контроллер домена??
    Придумываете велосипед

  2. Эта запись — в некотором роде шутка. Навеяна вот этим эпическим обсуждением на зеленом форуме: http://sysadmins.ru/topic170387.html.
    Соль шутки в том, что DNS изначально предусматривает отказоустойчивость на уровне самого приложения: одну зону могут обслуживать несколько серверов имён. И никакой необходимости обеспечивать дополнительную отказоустойчивость DNS поэтому нет.
    Но в каждой шутке есть доля шутки: эта статья иллюстрирует как именно можно кластеризовать изначально не предназначенную для этого службу.

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: