Comments 19
Как решается проблема split-brain в кластере? Если сеть моргнула и кластер рассекло на две независимые части.
Srsly, это те самые ребята, которые сделали популярнейший DNS-сервер (потому что его пихают во все дистры), но при этом на который не ругался только ленивый (из-за постоянных брешей в безопасности)? Я бы поостерегся это пускать в продакшен. Очень буду признателен, если переубедите меня.
ISC – это те же ребята, которые разрабатывают наши любимые bind и dhcpd.
Первой ассоциацией была жуткая дырявость их софта, "любимые" следовало в кавычки взять.
Kea – разработана на базе BIND 10.
Непонятно каким образом dhcp сервер сделали на базе dns сервера.
Поддержу, я, к сожалению, не могу найти ссылку на статью, где было описано по полочкам, почему ISС BIND такой нехороший, и какое негативное влияние имела ISC на развитие всей экосистемы вокруг DNS.
Касательно
Kea – разработана на базе BIND 10.
Очень интересно разложена внутренняя структура тут:
https://www.opennet.ru/opennews/art.shtml?num=39598
Так что действительно Kea сделана на базе BIND10 (насколько это вообще возможно)....
Вы утверждаете, что ожидаете 2000 запросов в секунду. При этом в конфиг-файлах резервируете пул в 200 адресов… Похоже, это тренировочный конфиг, выпадающий из темы статьи.
Если вы планируете двумя серверами покрыть 2 млн выдаваемых адресов, значит, вы должны затранслировать мак-адреса клиентов из локальных сегментов «наверх». Полагаю, это планируется сделать с помощью DHCP-ретранслятора. Но как тогда быть с коллизиями маков «на самом верхнем уровне»? В компании с парой тысяч устройств в сети уже бывают коллизии мак-адресов, даже у техники, у которой изменить его не представляется возможным (принтеры, роутеры, телефоны).
Правильно ли я понимаю, что централизацию DHCP вы планируете использовать только для авторизации устройств по мак-адресу? Или есть еще какие-то причины это делать?
В компании с парой тысяч устройств в сети уже бывают коллизии мак-адресов, даже у техники, у которой изменить его не представляется возможным (принтеры, роутеры, телефоны).
Проблема реальна? Я почему спрашиваю — я реально всегда думал, что mac является уником и это гарантируется самим вендором и я действительно не сталкивался с проблемами вида "2 устройства в корп сети имеют одинаковый MAC-адрес". Очевидно, что если два таких устройства попадут на один WiFi точку, то работать все будет… от слова никак.
ах да, делаем через инклуд
<?include "/etc/kea/clients/nsk/subnet-123.conf"?>,
а это пример класса и пула
«client-classes»: [
{
«test»: "(substring(relay4[2].text,-17,17) == '00:21:91:8d:8c:87') and (substring(relay4[1].hex,-1,1) == 0x1)",
«name»: «nsk-344-2-12dl1.2206.1»
}
],
«shared-networks»: [
{
«name»: «clients»,
«interface»: «ens33»,
«subnet4»: [
{
«relay»: {
«ip-address»: «10.174.16.254»
},
«pools»: [
{
«client-class»: «nsk-344-2-12dl1.2206.1»,
«pool»: «10.174.16.225/32»
},
],
«subnet»: «10.174.16.224/27»,
«option-data»: [
{
«name»: «routers»,
«data»: «10.174.16.254»
}
]
}
]
}
],
make
sudo make install
Есть, такая, категория людей, которым, какой из дистрибутивов linux не дай, они из него сделают слаку (при всей моей любви к слаке).
Ну есть же готовый спек файл, от федоры, с минимальными телодвижениями его можно приспособить для centos. Зачем же из системы помойку делать и новичков плохому учить.
Согласен, есть другие способы, но я все же склонен всегда придерживаться «официального мануала»(если он есть)
Прошу прощения, но это не официальный мануал, а путь в никуда. Как выше коллега отметил — make install в системе оставляет такие хвосты, которые потом руками приходится вычищать. Оптимально — устанавливать пакетным менеджером, ну, на худой конец предложили бы коллегам, которые хотят протестировать продукт, докер-образ готовый.
Я, к сожалению, нередко сталкиваюсь с ситуацией, когда есть специалисты. Реально специалисты в своей области. Но они не могут сделать что-то смежное с их областью. Например, собрать правильный rpm/deb. Или сделать красивый мониторинг для приложения. Или что-то еще.
Отказоустойчивый DHCP сервер на базе Kea