1. Был у меня на предыдущей работе развернут DHCP с «дыркой» в каждый vlan. В итоге сетевые настройки сервера превращались в что-то нечитаемое. И любой перенос этого сервера превращался в очень такую серьезную задачу.
Кроме того, это нереально, если vlan терминируются (маршрутизируются) на разных железках, объединенных через отдельную сеть и через ospf. В случае с relay — всё норм. Эта конфигурация гибче, хоть и естественно сложнее.
2. Не сталкивался с этим софтом в работе, а так как требовалось поднять быстро и надолго, то не стал уходиьт от знакомого.
3. Как средней руки *nix'оид могу сказать, что тут Вы не совсем правы.
Момент первый: Если лягут все DC, то большая часть сети и так ляжет, так как вся авторизация идет через домен.
Второе, на что регулярно указывают мне коллеги, когда я везде проталкиваю *nix, — найти у нас в провинции «виндового админа» всё равно проще пока что, чем человека с опытом администрирования *nix.
Третье — надежность windows домена проверена просто огромным множеством корпоративных (очень крупных) клиентов, к тому же и инструментов по резервированию этого всего уже придумано достаточно.
Правда DaemonGloom в том, что дополнительно поднимать 2 сервера, хоть и виртуальных, возможно не совсем целесообразно, хотя конечно isc-dhcp в плане ресурсов системы очень и очень скромен. Со своей стороны могу сказать, что на тот момент я не знал про Windows практически ничего, потому этот вариант не рассматривал
Операционная система, в т.ч. и серверная — это всего лишь инструмент. Задачи решает ПО, которое «крутится» под конкретной операционкой. Один инструмент лучше для одного, другой — для другого, это ещё и от ситуации во многом зависит, так что огульно писать, что «Венду в топку» не стоит.
Но мне моё решение всё равно нравится, может и статья будет полезна кому-либо.
Ключевое слово — при нормальной работе. Если прочитаете преамбулу статьи, поймете, что многое идет не совсем «корректно». Опять же — нужно где-то держать базу MAC адресов, а компы постоянно переезжают, причем иной раз и без ведома IT службы и т.п. Поэтому-то и нужен failover. :(
Поясню свою мысль:
При нормальной работе есть 2 группы клиентов: динамические и динамические с привязкой конкретного IP по MAC-адресу клиента. В этом случае «привязанные» клиенты получают их IP-адреса, а «динамические» клиенты — адреса из пула. Срок резервирования IP увеличен до недели.
В случае отсутствия failover при падении primary сервера «динамические» клиенты получат новые адреса, так как secondary сервер ничего не знает о lease'ах, которые хранятся на упавшем сервере.
В случае failover же primary и secondary обмениваются информацией и lease, соответственно даже «динамические» клиенты получат тот же самый адрес.
Не исключено, что я где-то ошибаюсь, если поправите — буду признателен.
Признал — если интересно — посмотрите комменты выше. Но забыл в статье поправить, тут уж простите великодушно.
Разные могут быть адреса в одном VLAN-е, что тоже является bad practices.
Согласен, но пока нет организационной возможности сразу выделить VLAN на группу клиентов. Поэтому переход плавный — сначала их на новую адресацию, в т.ч. и с разными диапазонами в одном VLAN, а затем уже эту группу клиентов обособлять в отдельный.
Что касается основной части Вашего комментария, попробую проверить на «полигоне» — по результатам скорее всего завтра напишу. Заинтриговали.
Да, конечно Вы правы, потому я и написал «ситуация является больше ненормальной и искусственно смоделированной», но есть ньюанс.
Сразу оговорюсь, чтобы были понятна ситуация — тесты других конфигураций были очень ограниченными, так как добившись рабочего и тестированного конфига, система была выпущена в продакшн без рассмотрения особых альтернатив.
В текущем варианте (ISC-DHCP с раздачей адресов на основании relay agent circuit-id) на «secondary» диапазоны можно привязывать IP по MAC, т.е. работают статические lease.
Вероятнее всего всё это реализуемо и под Windows DHCP (хотя «с наскоку» это у меня с коллегой и не получилось), и в случае ISC-DHCP с раздачей адресов на основании giaddr, но утверждать этого не стану, пока не протестирую.
Сейчас коллега протестировал Вашу конфигурацию. Всё работает отлично за исключением одной тонкости: диапазон, из которого будет выдаваться IP-адрес клиенту выбирается на основе IP того интерфейса dhcp relay agent'а, на который пришел запрос от клиента первоначально, а не на основе поля в dhcp-пакете.
Если на этом интерфейсе висит несколько адресов из разных VLAN, то область выбирается на основе первичного IP-адреса. Когда первичный IP-адрес выбирался не из нужного диапазона (а в сети есть сегменты со смешанной адресацией 192.168. и 10.), то адрес клиенту в нужную область не раздавался.
Конечно эта ситуация является больше ненормальной и искусственно смоделированной, но в случае, когда диапазон выбирается на основе поля в dhcp option 82, такой ситуации не возникает.
Проблема в том, что за годы существования без DHCP и без DNS как такового, на предприятии у некоторых сотрудников выработалась любовь к обозначению компов на основании IP. Соответственно, при падении сервера, адреса изменятся, что может вызвать отказы в сети.
Очень интересный и важный момент. К сожалению, тонкости лицензирования и лицензионной политики часто ускользают от внимания руководства и тех.персонала, в т.ч. и меня, так как в серверном плане начинал с *nix систем, и некоторые привычки порой сложно преодолеть.
Сейчас коллега протестировал Вашу конфигурацию. Всё работает отлично за исключением одной тонкости: диапазон, из которого будет выдаваться IP-адрес клиенту выбирается на основе IP того интерфейса dhcp relay agent'а, на который пришел запрос от клиента первоначально, а не на основе поля в dhcp-пакете.
Если на этом интерфейсе висит несколько адресов из разных VLAN, то область выбирается на основе первичного IP-адреса. Когда первичный IP-адрес выбирался не из нужного диапазона (а в сети есть сегменты со смешанной адресацией 192.168. и 10.), то адрес клиенту в нужную область не раздавался.
Конечно эта ситуация является больше ненормальной и искусственно смоделированной, но в случае, когда диапазон выбирается на основе поля в dhcp option 82, такой ситуации не возникает.
Этой директивой и пользуюсь активно. Одна проблема — include не умеет смотреть в каталог или искать файлы по маске. В параметре ожидается только уникальное имя файла и победить это я не смог.
Один вариант решения я описал в предпоследнем абзаце в статье, так как мне он на ум пришел уже при написании статьи, Ваш вариант с Makefile и регулярная генерация конфига мне кажутся излишними, так как сегменты добавляются достаточно редко.
Из консольных понравился https://github.com/naggie/dsnet. Без докера, но хранит всё в файле, позволяет многое. Вдруг кому пригодится.
Работа:
Тестовые режимы проверки барабана
PS:
Прошу прощения за качество — снималось на древнюю нокию несколько лет назад.
Кроме того, это нереально, если vlan терминируются (маршрутизируются) на разных железках, объединенных через отдельную сеть и через ospf. В случае с relay — всё норм. Эта конфигурация гибче, хоть и естественно сложнее.
2. Не сталкивался с этим софтом в работе, а так как требовалось поднять быстро и надолго, то не стал уходиьт от знакомого.
3. Как средней руки *nix'оид могу сказать, что тут Вы не совсем правы.
Но мне моё решение всё равно нравится, может и статья будет полезна кому-либо.
При нормальной работе есть 2 группы клиентов: динамические и динамические с привязкой конкретного IP по MAC-адресу клиента. В этом случае «привязанные» клиенты получают их IP-адреса, а «динамические» клиенты — адреса из пула. Срок резервирования IP увеличен до недели.
В случае отсутствия failover при падении primary сервера «динамические» клиенты получат новые адреса, так как secondary сервер ничего не знает о lease'ах, которые хранятся на упавшем сервере.
В случае failover же primary и secondary обмениваются информацией и lease, соответственно даже «динамические» клиенты получат тот же самый адрес.
Не исключено, что я где-то ошибаюсь, если поправите — буду признателен.
Признал — если интересно — посмотрите комменты выше. Но забыл в статье поправить, тут уж простите великодушно.
Согласен, но пока нет организационной возможности сразу выделить VLAN на группу клиентов. Поэтому переход плавный — сначала их на новую адресацию, в т.ч. и с разными диапазонами в одном VLAN, а затем уже эту группу клиентов обособлять в отдельный.
Что касается основной части Вашего комментария, попробую проверить на «полигоне» — по результатам скорее всего завтра напишу. Заинтриговали.
Сразу оговорюсь, чтобы были понятна ситуация — тесты других конфигураций были очень ограниченными, так как добившись рабочего и тестированного конфига, система была выпущена в продакшн без рассмотрения особых альтернатив.
В текущем варианте (ISC-DHCP с раздачей адресов на основании relay agent circuit-id) на «secondary» диапазоны можно привязывать IP по MAC, т.е. работают статические lease.
Вероятнее всего всё это реализуемо и под Windows DHCP (хотя «с наскоку» это у меня с коллегой и не получилось), и в случае ISC-DHCP с раздачей адресов на основании giaddr, но утверждать этого не стану, пока не протестирую.
Именно так, спасибо за уточнение. Хотел написать «несколько адресов из разных диапазонов», но как обычно всё перепутал.
Если на этом интерфейсе висит несколько адресов из разных VLAN, то область выбирается на основе первичного IP-адреса. Когда первичный IP-адрес выбирался не из нужного диапазона (а в сети есть сегменты со смешанной адресацией 192.168. и 10.), то адрес клиенту в нужную область не раздавался.
Конечно эта ситуация является больше ненормальной и искусственно смоделированной, но в случае, когда диапазон выбирается на основе поля в dhcp option 82, такой ситуации не возникает.
Один вариант решения я описал в предпоследнем абзаце в статье, так как мне он на ум пришел уже при написании статьи, Ваш вариант с Makefile и регулярная генерация конфига мне кажутся излишними, так как сегменты добавляются достаточно редко.