Hi All,
I'm attempting to devise a method which will provide continuous operation of
certain resources in the event of a disaster at a single facility.
The types of resources that need to be available in the event of a disaster are
ecommerce applications and other business critical resources.
On Jun 3, 2009, at 7:09 PM, Drew Weaver wrote:
What is the best way to handle the routing? Obviously two devices
cannot occupy the same IP address at the same time, so how do you
provide that instant 'cut-over'?
Avoid 'cut-over' entirely - go active/active/etc., and use DNS-based
GSLB
interconnecting your sites for
your IBGP session.
-Original Message-
From: Drew Weaver [mailto:drew.wea...@thenap.com]
Sent: Wednesday, June 03, 2009 8:10 AM
To: 'nanog@nanog.org'
Subject: Facility wide DR/Continuity
Hi All,
I'm attempting to devise a method which will provide
On the subject of DNS GSLB, there's a fairly well known article on the subject
that anyone considering implementing it should read at least once :)
http://www.tenereillo.com/GSLBPageOfShame.htm
and part 2
http://www.tenereillo.com/GSLBPageOfShameII.htm
Yes it was written in 2004. But all
On Wed, Jun 3, 2009 at 8:09 AM, Drew Weaverdrew.wea...@thenap.com wrote:
I'm attempting to devise a method which will provide continuous
operation of certain resources in the event of a disaster at a single facility.
Drew,
If you can afford it, stretch the LAN across the facilities via fiber
gb10hkzo-na...@yahoo.co.uk writes:
On the subject of DNS GSLB, there's a fairly well known article on the
subject that anyone considering implementing it should read at least
once :)
http://www.tenereillo.com/GSLBPageOfShame.htm
and part 2
On Wed, Jun 3, 2009 at 9:37 AM, William Herrin herrin-na...@dirtside.comwrote:
On Wed, Jun 3, 2009 at 8:09 AM, Drew Weaverdrew.wea...@thenap.com wrote:
snip
If you can't afford the fiber or need to put the DR site too far away
for fiber to be practical, you can still build a network which
, 3 June, 2009 15:42:24
Subject: Re: Facility wide DR/Continuity
gb10hkzo-na...@yahoo.co.uk writes:
On the subject of DNS GSLB, there's a fairly well known article on the
subject that anyone considering implementing it should read at least
once :)
http://www.tenereillo.com
On Wed, Jun 3, 2009 at 7:09 AM, Drew Weaver drew.wea...@thenap.com wrote:
Hi All,
I'm attempting to devise a method which will provide continuous operation
of certain resources in the event of a disaster at a single facility.
The types of resources that need to be available in the event of
On Jun 3, 2009, at 9:37 PM, William Herrin wrote:
If you can afford it, stretch the LAN across the facilities via fiber
and rebuild the critical services as a load balanced active-active
cluster.
I would advise strongly against stretching a layer-2 topology across
sites, if at all possible
On Wed, Jun 3, 2009 at 10:53 AM, gb10hkzo-na...@yahoo.co.uk wrote:
- whether you are after an active/active or active/passive solution
In practice, active/passive DR solutions often fail. You rarely need
to fail over to the passive system. When you finally do need to fail
over, there are a dozen
On Jun 3, 2009, at 10:05 PM, William Herrin wrote:
You rarely need to fail over to the passive system.
And management will never, ever let you do a full-up test, nor will
they allow you to spend the money to build a scaled-up system which
can handle the full load, because they can't
to whoever said ...
F5's if you like commercial solutions
F5s if you like expensive commercial solutions .
Those with a less bulging wallet may wish to speak to the guys at Zeus
Technology (http://www.zeus.com/) who have a lot of experience in the area and
a more reasonable price tag.
(by the way before the accusations start flying of spamming , no I don't
work for Zeus or have any incentive to mention their name... just happen to
know their product)
On Wed, Jun 3, 2009 at 11:15 AM, Roland Dobbinsrdobb...@arbor.net wrote:
Active/passive is an obsolete 35-year-old mainframe paradigm, and it
deserves to die the death. With modern technology, there's just really no
excuse not to go active/active, IMHO.
Roland,
Sometimes you're limited by
Roland Dobbins wrote:
On Jun 3, 2009, at 10:05 PM, William Herrin wrote:
You rarely need to fail over to the passive system.
And management will never, ever let you do a full-up test, nor will they
allow you to spend the money to build a scaled-up system which can
handle the full
On Jun 3, 2009, at 10:36 PM, William Herrin wrote:
Sometimes you're limited by the need to use applications which aren't
capable of running on more than one server at a time.
All understood - which is why it's important that app devs/database
folks/sysadmins are all part of the virtual
On Jun 3, 2009, at 10:38 PM, Seth Mattinen wrote:
Some things just don't active/active nicely on a budget.
Sure, because of inefficient legacy design choices.
Distribution and scale is ultimately an application architecture
issue, with networking and ancillary technologies playing an
Some things just don't active/active nicely on a budget.
Sure, because of inefficient legacy design choices.
Roland,
I'm not sure I understand your argument here.
Budget is very much an issue when choosing between active/active and
active/passive. Nothing to do with inefficient legacy
On Wed, 3 Jun 2009, Drew Weaver wrote:
Should the additional sites be connected to the primary site
(and/or the Internet directly)?
Yes, because any out-of-band synchronization method between the servers at
the production site and the servers at the DR site is likely to be more
On Wed, Jun 3, 2009 at 12:47 PM, Bill Woodcock wo...@pch.net wrote:
On Wed, 3 Jun 2009, Drew Weaver wrote:
Should the additional sites be connected to the primary site
(and/or the Internet directly)?
Yes, because any out-of-band synchronization method between the servers at
the
On Jun 4, 2009, at 12:53 AM, Brandon Galbraith wrote:
Or you use RFC1918 address space at each location, and NAT each side
between
public anycasted space and your private IP space. Prevents internal IP
conflicts, having to deal with site to site NAT, etc.
With all due respect, both of
On Thu, 4 Jun 2009, Roland Dobbins wrote:
With all due respect, both of these posited choices are quite ugly and
tend to lead to huge operational difficulties, susceptibility to DDoS,
etc. Definitely not recommended except as a last resort in a difficult
situation, IMHO.
23 matches
Mail list logo
