Отказоустойчивый DHCP. История неудачного теста

[@achekalin]

Не буду оригинальным: обычный ISC-DHCP сервер имеет режим failover, когда один из двух dhcp-серверов отзывается на запросы из сети. Притом база юзеров общая, так что друг другу эти две машины дорогу не перебегают, и не выдают адреса, которые уже выданы другой машиной. Упала машина — вторая продолжит раздавать за двоих. Главное, чтобы время на двух машинах было одинаковое.

Я бы даже советовал поставить что-то вроде Vyatta, у нее dhcp-сервер есть (точнее, его можно там поднять на каждом VLAN-е, что часто удобно), и он конфигурируется из веб-морды, так что по цене бросового, взятого из под стола, старого железа Вы приобретете отказоустойчивый DHCP-сервер в каждом VLAN-е, чего винда (2003 точно, про 2008 не уверен) не умеет.

[@roman_tik]

1. Такая организация не позволит в полной мере использовать функционал DHCP (например, ограничение доступа к прокси-серверу по IP).

Это почему же?
Для настройки сетевого доступа обычно используются статические IP-адреса. А значит в случае использования DHCP-сервера для таких хостов делаются резервирования (чтобы на один и тот же MAC-адрес выдавался всегда один фиксированный IP-адрес).
В случае двух DHCP-серверов просто любое резервирование в DHCP дублируете сразу на двух серверах. В случае падения одного сервера второй сервер обслужит все резервирования. DHCP-сервер обслуживает резервирование, даже если зарезервированный адрес не входит в диапазон его выдаваемых динамически адресов. Просто каждую IP-подсеть делите на скоупы между двумя DHCP-серверами в пропорции 80/20, чтобы каждая подсеть присутствовала на каждом из двух DHCP.

2. Необходимо обслуживание 2-х серверов, что требует больше человеко-часов.

Какие человекочасы? Один раз настроил и забыл. Новые скоупы и резервирования добавляешь скриптом — и тут уже по трудозатратам неважно на один сервер или сразу на два.

3. В сетях с высоким коэффициентом использования диапазона, оставшихся 20% может оказаться просто недостаточно для удовлетворения потребностей всех клиентов.

Считается, что лиза на выданные IP-адреса достаточно продолжительная (обычно несколько дней). Поэтому за время восстановления DHCP-сервера обновлять сетевые настройки понадобится далеко не всем хостам в сети, а значит 20% запаса адресов на обновления хватит. А те, кто получил сетевые настройки с упавшего сервера будет спокойно продолжать их использовать даже при недоступности того DHCP до тех пор, пока клиенту не понадобится обновить сетевые настройки (например, истечение срока аренды или появление нового хоста в сети). Вы же после падения DHCP-сервера не побежите на всех рабочих станциях в сети вручную обновлять сетевые настройки:
ipconfig /release && ipconfig /renew.

Зато эта схема резервирования с двумя абочими узлами (active-active) лучше предложенной вами схемы (active-passive) тем, что резервирование срабатывает автоматически без ручного вмешательства (и без необходимости админу быть на рабочем месте при этом), а значит без простоя сервиса.

[@Sing]

Я немного не понимаю аудиторию публикации. Если Вы писали для прожженных сисадминов — я думаю, они и так эти проблемы давно решили (и судя по комментарию roman_tik, успешнее). Если для любопытных и несвязанных со сферой деятельности, вроде меня, то в статье слишком много сокращений, без объяснений или ссылок на «где почитать», типа:

Конечно, многие сейчас скажут, что кластер рулит. Я даже соглашусь с тем фактом, что сейчас организация кластера проще, т.к. нет необходимости в САНе или закупке какого-то внешнего винчестера, вполне подойдет обычный НАС, построенный, например на FreeNAS с настроенным iSCSI-конектором…

[@roman_tik]

Если для любопытных и несвязанных со сферой деятельности, вроде меня, то в статье слишком много сокращений, без объяснений или ссылок на «где почитать»

Вот вам ссылка на комментарий из другого топика для первичного ознакомления с тематикой NAS/SAN:
habrahabr.ru/blogs/open_source/98463/#comment_3036550

[@roman_tik]

т.к. нет необходимости в САНе или закупке какого-то внешнего винчестера, вполне подойдет обычный НАС, построенный, например на FreeNAS с настроенным iSCSI-конектором…

Кстати, у вас тут видно явное непонимание того, что такое SAN, а что такое NAS, и в чём их принципиальное отличие.

Если к серверу прицеплены какие-то диски (например, SCSI/SATA/SAS/PATA-диски), на дисках на стороне этого сервера создана файловая система, на этой файловой системе хранятся какие-то файлы, и в сеть эти файлы раздаются по высокоуровневым файловым протоколам: SMB/CIFS, NFS, FTP, SFTP, HTTP, WebDAV и др. — тогда этот сервер является NAS (Network-attached storage).

А если к серверу прицеплены какие-то диски, и эти диски презентуются другим серверам, подключённым в сеть хранения данных (СХД), на низком уровне в виде дисковых томов (блочных устройств) — тогда это уже элемент инфраструктуры SAN (Storage area network). В этом случае созданием файловой системы и размещением на ней файлов занимается уже тот сервер, которому этот дисковый том (LUN) презентован. Если в SAN передача SCSI-команд между дисковым устройством и использующим этот диск сервером физически реализована по оптическим каналам, то это Fibre Channel (FC), а если SCSI-команды передаются по каналам Ethernet (SCSI over IP), то это iSCSI.

Т.е. принципиальное отличие в том, что в NAS данные передаются по сети на файловом уровне, а в случае SAN доступ к данным осуществляется на блочном уровне.

И упомянутое вами программное решение FreeNAS может использоваться как для реализации NAS, так и для реализации SAN на базе iSCSI (при этом FreeNAS может выступать и в роли сервера [iSCSI target], т.е. может презентовать в сеть диски по iSCSI, и в роли клиента [iSCSI initiator], т.е. может сам подключать откуда-то внешние диски по iSCSI).
И если вы используете FreeNAS в качестве iSCSI target, то он у вас явно участвует в инфраструктуре SAN, а не просто как файловый сервер в сети (NAS).

Кстати, насколько я знаю, развитие проекта FreeNAS уже пару лет как остановилось. Сейчас просто исправляют найденные баги и периодически переносят его на очередную версию ядра FreeBSD, на котором он базируется. А автор FreeNAS решил переписать его с нуля на базе уже не ядра FreeBSD, а на базе ядра Linux (а точнее на базе дистрибутива Debian Linux). Этот продукт получил название OpenMediaVault (релиз намечен на осень 2011).

[@uksus]

У самого на работе на сервере DHCP стоит такая архивация. Просто и легко. Советую всем.