Управление 2 серверами DHCP в одной сети
Можно хотеть рассмотреть использование надлежащего программного обеспечения кластеризации. Redhat (или CentOS) Кластерный Комплект или ClusterWare Oracle. Они могут использоваться для установки активно-пассивных кластеров и могут использоваться для перезапуска сервисов и сбоя между узлами, когда существуют серьезные проблемы. Это по существу, что Вы ищете.
Все эти кластерные решения включены в соответствующие лицензии на ОС, таким образом, Вы, вероятно, спокойны на стоимости. Они действительно требуют некоторого способа совместно используемой памяти - или NFS монтируется, или физический диск, к которому получают доступ оба узла с кластерной файловой системой. Примером последнего были бы диски SAN с несколькими, размещают доступ, предоставленный, отформатированный с OCFS2 или GFS. Я полагаю, что можно использовать совместно используемые диски VMware для этого.
Кластерное программное обеспечение используется для определения 'сервисов', которые работают на узлах все время, или только когда тот узел 'активен'. Узлы связываются через heartbeat и также контролируют те сервисы. Они могут перезапустить их, если они замечают отказы и перезагрузку, если они не могут быть зафиксированы.
Вы в основном настроили бы единственный 'общий' IP-адрес, к которому будет направлен трафик. Затем апач и любые другие необходимые сервисы, могут определяться также и только работаться активный сервер. Совместно используемый диск использовался бы для всего Вашего веб-контента, любых загруженных файлов и Ваших апачских каталогов конфигурации. (с httpd.conf, и т.д.)
По моему опыту, это работает невероятно хорошо.
- Нет никакой потребности в циклическом алгоритме DNS или любой другой подсистемы балансировки нагрузки единой точки отказа - все поражает один IP/FQDN.
- Пользователь загрузил файлы, входят в ту совместно используемую память и таким образом не заботятся, заменяет ли Ваша машина.
- Разработчики загружают содержание на тот единственный IP/FQDN с нулевым дополнительным обучением, и это всегда актуально, если это заменяет.
- Администратор может взять офлайновую машину, исправить heck из него, перезагрузку, и т.д. Затем замените активный узел. То, чтобы заставлять обновление занять минимальное время простоя.
- Это теперь устаревший узел может быть сохранено неисправленным некоторое время, делая возврат к состоянию до сбоя одинаково легким процессом. (Более быстрый, чем снимки VMware)
- Изменения в конфигурации Apache совместно используются, так, чтобы ничего странного не происходило во время обработки отказа, потому что администратор забыл вносить изменения на офлайновом поле.
- Christopher Karel
Независимо от того, что вы делаете, вы не можете помешать «другому человеку» отправить DHCPOFFER «вашим» клиентам.
Серьезно сбивает с толку, когда два разработчика работают с программным обеспечением таким образом, что им необходимо предоставлять dhcp.
При этом можно реструктурировать сеть с двумя независимыми широковещательными доменами через две подсети. Это может быть выполнено с помощью двух физических коммутаторов, подключенных через маршрутизатор, или двух виртуальных локальных сетей в одном коммутаторе.
Вероятно, вы захотите, чтобы специализированный сетевой специалист взялся за такую работу.