Slava Dubrovskiy пишет:
Dmitry Lebkov пишет:
LDAP в виде backend'а может и имеет смысл при несильно нагруженных
запросами
зонах. Более прямой путь -- генерация файлов зон из данных,
содержащихся в
ldap-каталогах, с последующим rndc reload [zone], imho.
Ну вообщем-то так и предполагается. Только тут если использовать СУБД
то все равно что-то будет мастером. А от этого хотелось убежать.
Вроде как OpenLDAP 2.4.x умеет multi-master replication.
Еще есть некоторый опыт использования mydns. Вполне работает. Но под
большой нагрузкой не очень (когда досят битыми запросами на udp:53)
мускуль достаточно сильно нагружается (LA до 5-20).
C LDAP-сервером в виде backend'а возможно будет получше, чем с SQL.
Хотя однозначно это утверждать не возьмусь. Надо сравнивать. Ну и скорее
всего, это будет на быстрее чем BIND c обычными текстовыми файлами зон.
Значит вывод такой:
1. Зоны держать в базе (LDAP или mysql). LDAP предпочтительней т.к. есть
master/master. Хотя говорят для mysql тоже есть мастер/мастер.
2. Реплицировать на каждый сервер
Если источник изменений таки один - лучше воспользоваться схемой 'hidden
master DNS + many slave DNSes' и делать transfer зон через AXFR.
3. Генерировать зоны на каждом сервере из базы, затем дергать бинд на
релоад зоны
См. выше. В той схеме дергать нужно будет только hidden master.
4. Иметь веб морду по редактированию базы.
Это да. Но тут уже каждый делает то, что ему удобнее. Вплоть до правки
через gq/phpMyAdmin ;)
Я правильно понял задачу?
И неужели еще такого не придумали? Все руками зоны правят?
Придумали много чего. Вот только универсальной "синей пилюли" не
существует. ;)
--
WBR, Dmitry Lebkov
_______________________________________________
Sysadmins mailing list
[email protected]
https://lists.altlinux.org/mailman/listinfo/sysadmins
