multi-master with mysql backend
Gordon A. Lang
glang at goalex.com
Mon Feb 14 18:34:47 UTC 2011
In case anyone is actually paying attention, I just re-read
my own post, and I'd like to clarify my plural reference to
the service addresses...
I have one service address for DDNS and separate service
address for zone transfers. So, technically we have to
change two static host-routes, not just one. But the
simplicity is still intact.
And also, I'd like to point out that my simple "promote"
script has a sister script called "demote," and these
scripts bring up or bring down the service addresses on
loopbacks as well as restart the "named" process.
And, by the way, we have NEVER needed to change masters
since mid-2005 when it was first deployed. I am anxiously
waiting for an actual failure to justify all my work.!!!
--
Gordon A. Lang
----- Original Message -----
From: "Gordon A. Lang" <glang at goalex.com>
To: <bind-users at lists.isc.org>
Cc: "Mike Mitchell" <Mike.Mitchell at sas.com>
Sent: Monday, February 14, 2011 1:18 PM
Subject: Re: multi-master with mysql backend
> FWIW, I feel compelled to chime in -- for those who haven't already begun
> to filter out this thread.....
>
> We have many thousands of records (internally) in hundreds of zones,
> mostly dynamic.
>
> We have 8 DNS servers providing authoritative and recursive service to
> thousands of internal clients.
>
> All DNS servers are slaves to a single, semi-hidden master.
>
> The master's "service addresses" is statically host routed to the servers
> currently providing the master DNS service, with the service addresses
> being assigned to loopback interface on the server.
>
> If the active master dies, then I run a simple script on another working
> DNS server to promote it to master, and I change a static host route in
> the layer-3 switches to direct zone transfer and DDNS traffic to the new
> server. I can restore the master DNS functionality on any other DNS
> server within seconds.
>
> The weakness of this system is that I don't trust an automatic failover,
> so zone transfers and new DDNS requests have to wait until someone on my
> team is notified of the problem, and they log in, and implement the flip.
>
> We do have a mysql-based management system, but only for the non-dynamic
> zones, and the zone files are pushed out to the active master using scp
> and rndc. I would never install the database on an actual DNS server --
> for many, many reasons.
>
> Sorry if I come across as harsh, but the thought of installing a database
> system on every DNS server that might need to become master seems
> extremely insane.
>
> Ah. There, I feel much better now having said that.
>
> --
> Gordon A. Lang / 313-819-7978
> ----- Original Message -----
> From: Mike Mitchell
> To: fddi
> Cc: bind-users at lists.isc.org
> Sent: Monday, February 14, 2011 10:52 AM
> Subject: RE: multi-master with mysql backend
>
>
> I'd keep two copies of the BIND config, one that has all the zones as
> "master", and one that has all the zones as "slave". When the master dies,
> run a little script on a slave that freezes the zones, edits the SOA to make
> that server the MNAME and increment the serial, then thaws the zone. Swap
> out the config with the "master" config, and now you have a new master.
>
> Before the broken master comes back online, swap out its config with the
> "slave" config.
>
> No need for rsync or mysql, BIND replication does all the work for you.
> Just be sure the updates go to the server listed in the MNAME field of the
> SOA.
>
> Mike Mitchell
>
>
>
>
>
> From: bind-users-bounces+mike.mitchell=sas.com at lists.isc.org
> [bind-users-bounces+mike.mitchell=sas.com at lists.isc.org] on behalf of Bill
> Larson [wllarso.dns at gmail.com]
> Sent: Monday, February 14, 2011 10:39 AM
> To: fddi
> Cc: bind-users at lists.isc.org
> Subject: Re: multi-master with mysql backend
>
>
> On Feb 13, 2011, at 9:06 AM, fddi wrote:
>
>
> I do not know why you really don't liket this mysql solution.
> OK I am talking of a DNS for HA purposes for grid computing services for
> exampe, so DNS
> resolution must be always working at any cost.
> The David solution can be OK, but I want to be sure not to have issues with
> serial numbers on the two servers
> and the mysql solution looks safer to me. You do not have to rsync anything,
> just have mysql properly configured.
>
>
>
> This list is read by many people with extreme experience with DNS and DNS
> operations. Using the information that you have provided, many solutions
> have been provided to meet the requirements that you have stated. I would
> suggest that you at least consider this other solutions and not be as
> adamant about using your proposed MySQL solution.
>
>
> You state that you have a "HA" requirement. Please understand that this is
> not an uncommon requirement for a DNS operation. In fact, almost all DNS
> operations have this same requirement. Just imagine if the root servers did
> not have a require for "high availability". The same goes for the "com",
> "net", "org" servers ("it" also). This is not an unusual requirement and a
> standard BIND DNS server provides this very well.
>
>
> Now, I would also suggest that a MySQL DNS server may not be the best
> solution for a critical DNS operation. Please take a look at the benchmark
> work done comparing BIND using various backend systems, including MySQL.
> This can be found at http://bind-dlz.sourceforge.net/perf_tests.html, which
> is part of the work that the people that developed DLZ for BIND. The
> standard BIND server could provide 16,000 queries per second. The same BIND
> server using a MySQL backend could handle less than 700 qps.
>
>
> BIND DLZ using MySQL is NOT what I would consider to be a high performance
> solution for a DNS operation. Now, granted, these results were not using a
> "current" version of BIND, nor was this being run on any "high power"
> hardware. Performance of BIND DLZ using a MySQL backend may have easily
> been improved, but so has the performance of the base system too. A 20 to 1
> performance advantage for a straight BIND solution will be hard to overcome.
>
>
> So, performance isn't something that a MySQL backend provides to a DNS
> operation and high availability is something that all DNS server do provide,
> so your real requirement must be something else, such as being able to
> update multiple servers at the same time. But Doug Barton has identified
> that using "nsupdate" to update both (all) servers also provides a solution
> to meet this requirement.
>
>
> So, your "the mysql solution looks safer to me", may be your viewpoint which
> is not universally agreed upon. You also have stated "just have mysql
> properly configured". This statement is not unique to MySQL but to BIND
> also. BIND also needs to be properly configured, no different than with
> MySQL - nothing unique here.
>
>
> Now, my single belief for any DNS operation is to follow the KISS principle,
> "keep it simple, stupid". A less complex system will be more reliable than
> a more complex system, because of having less potential points of failure.
> This reliability is the single most important requirement for a DNS
> operation. A DNS operation that requires running both BIND and MySQL will
> be inherently less reliable than one running just BIND.
>
>
> The complexity of a MySQL BIND server makes for a less reliable system than
> one just using BIND. The performance of a MySQL based BIND server is much
> less than a standard BIND server. Managing DNS information using dynamic
> DNS provides a simple solution to updating the zone information. So, what
> is the actual advantage of using a MySQL backend to BIND? I'm not convinced
> that there is any advantage and I am sure that there are many downsides to
> using this.
>
>
> Using MySQL for a backend to BIND is a fairly commonly proposed solution but
> it's actual implementation is not followed up on. I looked at using MySQL,
> but the performance limitations were an absolute deal killer. I set up a
> simple BIND/MySQL system and benchmarked it and duplicated the performance
> trends from the BIND-DLZ developers. Maybe this has been improved, but
> these results have not be published so we don't know about it.
>
>
> If you do implement your MySQL solution, please, please, please, keep us
> informed about how it works for you. We would like to know more and are
> always willing to look at new technologies but aren't too accepting of hand
> waving.
>
>
> Bill Larson
>
>
> Riccardo
>
> On 2/12/11 11:33 PM, Doug Barton wrote:
>
> On 02/11/2011 01:51 PM, fddi wrote:
>
> I understand you, but the advantage of having mysql backend is that
>
> if one of the two servers dies, the other keeps running with up to
>
> date informations, and can also be updated wit new informations. When
>
> the other server comes up again it will automatically sync itself
>
> using mysql replica mechanism. if I use file backend I have to
>
> manually sync it, and how to keep tracks of modifications ?
>
>
>
> for this I choose mysql backend
>
>
>
> Two questions, how often do you anticipate one of the masters failing, and
> how much data are you talking about? Generally the number of times a server
> fails is going to be pretty small, if it's not, you've got bigger problems.
>
>
>
> If you're not talking about a huge amount of data here (and from what you've
> described in previous posts, you're not) then you are fairly dramatically
> over-architecting your solution here. Personally I think David had a great
> idea in regards to using nsupdate to update both masters at the same time.
> If you really think that one of them is going to fail often enough to
> justify an automated solution than scripting something that utilizes rsync
> shouldn't be too hard.
>
>
>
>
>
> hth,
>
>
>
> Doug
>
>
>
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
>
>
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110214/f4dfcd66/attachment.html>
More information about the bind-users
mailing list