From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 Message-ID: <48047690.3000301@sakhalin.ru> Date: Tue, 15 Apr 2008 20:34:08 +1100 From: Dmitry Lebkov User-Agent: Thunderbird 2.0.0.12 (X11/20080304) MIME-Version: 1.0 To: slava@tangramltd.com References: <48044E44.6000408@tangramltd.com> <4804621E.5020006@tangramltd.com> <48046ACA.7000908@sakhalin.ru> <48047251.10201@tangramltd.com> In-Reply-To: <48047251.10201@tangramltd.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at sakhalin.ru Cc: ALT Linux sysadmin discuss Subject: Re: [Sysadmins] =?koi8-r?b?9dDSwdfMxc7JxSDaz87BzckgRE5T?= X-BeenThere: sysadmins@lists.altlinux.org X-Mailman-Version: 2.1.10b3 Precedence: list Reply-To: ALT Linux sysadmin discuss List-Id: ALT Linux sysadmin discuss List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 09:34:53 -0000 Archived-At: List-Archive: 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