Master/master named replication
slepnoga 19 октября, 2013 - 20:08
Добрый день,
Интересует что нибудь дла организации мастер-мастер репликации в named для установки >2 мастер серверов.
Или прийдерся велосипедить с рсинком и ssh ?
»
- Для комментирования войдите или зарегистрируйтесь
slepnoga написал(а): Добрый
С добрым.
Ну тут 2 варика готов предложить.
1 - это bind + dlz храним в мускуле и добиваемся репликации мастер-мастер через средства мускуля или инструментов для работы с онным.
2 - это DRBD + Heartbeat... кстати этот вариант реализовывал, но только в мастер-слейв. Мастер-мастер как то не было нужды реализовывать.
/
В таком случае скорее LDAP-backend, там популярный и востребованный вопрос multi-master репликации заявлен и даже должен работать, хоть у меня и есть некоторый скепсис относительно полноты оного решения.
Но думается мне, вопрос не в этом…
:wq
--
Live free or die
это DRBD + Heartbeat...
С точки зрения DNS это все равно будет мастер/слейв, причем дурацкий - слейв включится только при падении мастера.
А что, named.conf оно тоже хранит в sql ?
Впринципе вопрос в репликации конфига бинда, ибо зоны тянуть можно довольно просто. НУ и не хочется завязыварся при <200 доменах на мускуль или чего еще сложнее
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
[/code]С точки зрения DNS
НА самом деле тебе должно быть пофиг что отваливается. Чинишь, потом меняешь мастер и слейв тупо местами. То есть слейв делаешь мастером.
И репликация начинается на упавшую ноду, если она была мастером. А если слейв упал, то тут и так все понятно.
НУ как вариант еще один могу подсказать - делаешь через GIT репозиторий и хуки. Когда делаешь комит и отправляешь его, хук сразу синкает его
на второй сервер средствами гита. Там потом в хуках можно и зоны перегрузить. Костыль - да знаю (хотя задержки там будут минимальные),
но имеет право на существование, и работает.
Очевидно, я плохо
Очевидно, я плохо сформулировал задачу - есть 5 серваков , по одному на континент, все оно прописаны в зоне у регистратора, который отдает их RR.
задача - обеспечить конситентность зоны
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
а какие задерки по передаче
а какие задерки по передаче пакетов? Какой темп модификаций?
И требования по допустимому рассогласованию?
Может не стоит огород городить и достаточно классической схемы (1 мастер (на HA-кластере?) на 4 вторичных)? Cейчас делаю похожую схему, только в каждом ДЦ (всего 9 на 4 континентах) по 2 виртуальных сервера на кластерном хосте. да, и еще, - мастер планируем дома держать... ;)
SysA написал(а): а какие
Интересненько, а опытом поделитесь ? ;)
Ну как бы не в тему... там
Ну как бы не в тему... там gentoo и близко не лежало...
задержек быть не должно ,
задержек быть не должно , максимальный темп модификации равен минимальному TTL - 5 минут.
П.С это не ригистратор, зона всего 1.
П.С .С при вашей схеме атака на мастер кладет всю зону при достаточной интенсивности атаки. К тому же подумайте на тему : как быстро поменять днсы при ддосе .
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
У нас внутри датацентров зоны
У нас внутри датацентров зоны бинда копирутся рсинком между серверами.
П.С. от ддос вас врятли чтото спасет, ибо если захотят, то ататка будет на все ваши днс сервера одновременно)
П.С.С на внешке у нас ultradns.net
ага, ответ профессионала:
ага, ответ профессионала: "...задержек быть не должно..." - при передаче с между континентами... :D
а на 5мин прекрасно отработают штатные средства BIND'a, как я уже говорил.
Кстати, DDOS мы держим... ;) по-крайней мере до 9Gbps на сайт, больше пока не было, слава богу... :).
Предупреждая вопросы, скажу, что одна из мер борьбы - BGP, про другие лучше умолчу, но аппаратные и кое-какие еще спец.средства тоже задействованы... ;)
И у нас тоже только свои зоны... не одна, конечно, но в пределах десятка-двух...
зоны бинда копирутся рсинком
в чем проблема перечитывать зону после копирования ? :) и и задержек нет
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а): зоны
ну да, rsync - он же через гипер-пространство передает, там же задержек не бывает, как же я мог забыть?! :(
И на загруженном сервере зоны считываются мгновенно... и чего это кто-то какие-то технические характеристики продумал - компьютер ведь может делать все и сразу... ;)
А может вам пора узнать о AXFR/IXFR? А конфиги должны бы распространяться через Configuration Management, но это уже совсем другая история...
Но это ваше "проклятое" Виндовское прошлое (?!) тянет вас делать "все в одном"... :D
А теперь серьезно. :))) я 100
А теперь серьезно. :)))
я 100 лет как знаю про AXFR/IXFR,
и если бы ты читал внимателнее, то вопрос не в передаче __зоны__, а в синхронизации named.conf
( если мы не добавляли __зону__, то естественно конфиг не меняется ).
Навелосипедить самому всю эту катавасию мне совершенно не трудно ( инотфай на named.конф, ремотный релоад конфигов/измененных зон, мониторинг ( бинд уже давно отдает по хттп дату для мониторинга) ....)
Просто я крайне не люблю рожать, тем более велосипеды с квадратными колесами
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Это тебе надо научиться четче
Это тебе надо научиться четче выражать свои мысли - ну где в формулировке проблемы было хотя бы упомянуто о named.conf?
Да и из дискуссии это далеко не очевидно...
А по теме - опять же, повторюсь, - на корпоративном уровне все изменения конфигов только через Configuration Management, иначе ССЗБ! Да и на орг.уровне руководство обычно не толерирует подобные поделки...
да все это понятно, если у
да все это понятно, если у вас гугл, однокласники или там межделмаш. Пока что я один :)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)