Приветствую, хаброжители.
После того, как на моем любимом стареньком «сервере» сгорел БП, что привело к простою в полдня, я в очередной раз задумался об отказоустойчивом DHCP.
Конечно, многие сейчас скажут, что кластер рулит. Я даже соглашусь с тем фактом, что сейчас организация кластера проще, т.к. нет необходимости в САНе или закупке какого-то внешнего винчестера, вполне подойдет обычный НАС, построенный, например на FreeNAS с настроенным iSCSI-конектором… Но:
1. У меня нет платформы под НАС (как и потребности в нем).
2. У меня нет желания подымать кластер исключительно под DHCP, а для других нужд кластер мне пока не нужен.
Заглянув в MSDN (куда без него), я увидел, что второй путь, предлагаемый мелкомягкими для организации отказоустойчивой конфигурации, является настройка 2-х серверов по принципу 80/20, т.е. первый сервер будет обслуживать 80% рабочей области, второй оставшиеся 20%. Заманчиво, но (люблю все перечислять по пунктах):
1. Такая организация не позволит в полной мере использовать функционал DHCP (например, ограничение доступа к прокси-серверу по IP).
2. Необходимо обслуживание 2-х серверов, что требует больше человеко-часов.
3. В сетях с высоким коэффициентом использования диапазона, оставшихся 20% может оказаться просто недостаточно для удовлетворения потребностей всех клиентов.
Ну что же, и мы ведь «не пальцем деланы», смекалка нам на что?
Так я себе подумал и родил «гениальную» мысль. А что, если создать DFS-ресурс, подключить к нему 2 сервера и разместить на нем хранилище конфигурации DHCP. Сказано, сделано.
Поднято 2 сервера на виртуальной платформе, настроено домен, настроены репликации, создан ресурс и запущена кольцевая репликация между 2-мя прилинкованными серверами. DHCP поднят и перестроен в соответствующий ресурс. Ура, первый сервер работает. Пришло время тестов.
Останавливаем первый сервер, практически мгновенно происходит репликация данных между ресурсами, переходим ко второму, запускаем службу и испытываем первый прилив восторга – работает!
Полдела сделано. Останавливаем бекап, запускаем первый, создаем новую резервацию и брутально выключаем основной сервер. Переходим ко второму, запускаем службу и первое чувство счастья сменяется на ошеломление, если не сказать «сильнее»…
Да, DHCP не стартует, выключается и всячески ругается на файлы журналов и БД (нужно было внимательнее читать MSDN, данная проблема описывается в разделе про кластеры).
Итог – резервный «сервер», возле которого необходимо побегать полдня чтобы запустить его в работу. Причем на нем будет полностью отсутствовать какие-либо изменения, произошедшие после остановки службы.
Но праздный ум на этом не останавливается.
Как известно, сервер по таймауту производит бекап всей базы (по-умолчанию каждые 60 минут), следовательно можно переместить на DFS только папку бекапа и «будет мне счастье».
Перенастройка заняла 10 минут. Тестирование – дополнительных полдня.
Результат опять плачевен. Бекапы делаются и DFS честно передает доступные файлы на бекапный сервер, но система продолжает их удерживать конфигурационный файл, без которого бекапы теряют весь смысл.
Итог – работающий DHCP, который можно запустить после «падения» Мастера, но у которого отсутствуют все изменения. Т.е. результативность немногим выше 0.
Выход конечно-же был найден. Банальный, как и всегда.
Ежечасно скриптом экспортируется дамп DHCP в текстовый файл:
netsh dhcp server 192.168.0.1 dump > C:\Dhcp\Dhcpcfg.dmpФайл ложится на DFS-шару (куда-же без нее, как-то я с ней уже породнился после всего пережитого вместе), которая успешно реплицируется между обоими серверами.
В час Ч на втором сервере просто импортируется дамп:
netsh exec dhcpcfg.dmpи сервер готов к работе.
Единственный минус – разные названия классов на системах с разными языками. Но, это просто «лечится» обычной заменой в файле. Кроме того, у меня системы с одинаковыми языками, так что проблема обошла меня стороной.
К чему я это все…
Да просто для того, чтобы кто-то почитал и сразу решил для себя все без тестов.
Кто-то понял какие-то вещи, которых не понял раньше.
Кто-то перечитал MSDN внимательнее.
И все мы решили, что отрицательный результат, также результат, т.к. содержит бесценный опыт.
Собственно, MSDN.
