Mirror Configuration

[Kevin Darcy]

Here's my mini-dissertation on the topic:

> To do this with DNS, there's no really *good* way until all clients know
> about
> "SRV" records. These relatively-new resource records add a layer of
> indirection
> to the resource-location process, and have "preference" values
> associated with
> them, so clients using them know exactly in what order servers should be
> tried.
> Unfortunately, SRV-aware web clients are probably years away.
>
> The simple-minded DNS-based approach is to just change the A record for
> the
> website when the main box goes down (possibly using some sort of
> automated
> script, possibly making the change via Dynamic Update). The main problem
> with
> the simple-minded approach is caching: anyone who has the old record
> cached in
> some intermediate nameserver will still go to the "dead" server even if
> the A
> record has been changed on the master and the change has been propagated
> to all
> of the slaves. Unlike NOTIFY in the master/slave context, there's no
> practical
> way to tell every caching nameserver on the 'Net that a particular A
> record has
> changed, and that they should all come and fetch the new value.
>
> A refinement of the simple-minded approach is to have the name of the
> website
> resolve to *both* addresses, and arrange for them to always be given out
> in the
> appropriate order, i.e. main website first, backup second. This can be
> achieved
> by specifying a "fixed" rrset-order on the master and all slaves for the
> zone
> (you need at least BIND 8.2 for this, and for security reasons that
> means you'd
> be wanting to run BIND 8.2.2 patchlevel 5). Some applications are smart
> enough to
> automatically failover, so for those clients this means more
> availability
> (after a short failover delay) during a failure of the main box, even if
> they
> get a "stale" RRset. Then again, some clients are *not* smart enough to
> do this
> failover, so it's a partial solution at best. Moreover, caching
> complicates
> things here as well: for multi-valued A records, intermediate caching
> servers
> will tend to randomize/round-robin the order of the answers they give
> out. This
> re-ordering effect actually *helps* you in failure mode -- it means that
> approximately 50% of the clients getting a stale RRset will still be
> able to
> connect without any failover delay -- but the flip side is that under
> normal
> circumstances, when the main box is up, it means that there will be a
> certain
> amount of "leakage" to the backup webserver. If you don't want to
> continually
> mirror the website contents, you can of course deal with this leakage
> traffic
> straightforwardly via a web redirect on the backup webserver, but that
> will add
> latency. When the main website fails, then remove its A record from the
> RRset
> and turn off the redirect (if any).
>
> Note that with either approach, you can mitigate -- but not completely
> eliminate -- the effects of intermediate caching servers by making the
> address
> records volatile (by reducing their TTL values). But this will greatly
> increase
> the traffic to your nameservers for that name, not to mention the extra
> work
> you'll cause for all other nameservers on the 'Net to constantly
> re-query the
> name. Overall, it's a Bad Thing, but many folks resort to it
> nonetheless.
>
> There are non-DNS solutions to this problem, of course. The obvious one
> is to
> just have lots of redundant network paths so that access is "never"
> (never say
> never) lost to the main webserver, and of course the webserver itself
> should be
> clustered or high-availability so that it "never" goes down, but this
> "brute
> force" approach can get expensive. And then there are specialized
> hardware/software failover solutions, which also tend to be expensive.
> Some of
> these make *both* servers look like the same IP address, and the
> failover
> happens transparently. Some of them also integrate dynamic
> load-balancing
> between webservers, which is probably something you want if you outgrow
> your
> current webserver capacity.
>


- Kevin

Mitchell Krog wrote:

> Hi All
>
> I have searched high and low for information on this type of configuration
> and haven't found either a positive or negative answer to my question yet.
>
> Hence ... I am now finally posting this here so hopefully someone can answer
> my question.
>
> I have some very important websites which are on my servers which need
> 24/7/365
> reliability which we can meet at present however, sometimes lines go down
> etc
> especially with the bad lightning we have in South Africa.
>
> I have two servers one sitting on a 196.*.*.* subnet and the other on a
> 216.*.*.*
> subnet ... the main web server is on the 196.*.*.* and the websites on this
> server
> automatically replicate to the other server at specified intervals. That is
> no problem
> I have that all working.
>
> However lets say the lines supplying bandwidth to the 196.*.*.* subnet go
> down, is there
> a way for the server at 216.*.*.* to automatically takeover ??
> Can Bind be configured in such a way as to do this or am I sadly mistaken ??
> I would just like to be able to have a fully redundant service .. if there
> is such
> a thing.
>
> Any help on this matter would be most appreciated.
>
> Regards
> Mitchell Krog