[118774] in North American Network Operators' Group
RE: Redundant Data Center Architectures
daemon@ATHENA.MIT.EDU (Stefan Fouant)
Wed Oct 28 17:40:12 2009
From: Stefan Fouant <sfouant@novadatacom.com>
To: Darren Bolding <darren@bolding.org>, Roland Dobbins <rdobbins@arbor.net>
Date: Wed, 28 Oct 2009 17:39:28 -0400
In-Reply-To: <5a318d410910281357i34876c8aq6fd6670f89303c3d@mail.gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> -----Original Message-----
> From: Darren Bolding [mailto:darren@bolding.org]
> Sent: Wednesday, October 28, 2009 4:57 PM
> To: Roland Dobbins
> Cc: NANOG list
> Subject: Re: Redundant Data Center Architectures
>=20
> Also, commercial solutions from F5 (their GTM product and their old 3-
> DNS
> product).
>=20
> Using CDN's is also a way of handling this, but you need to be prepared
> for
> all your traffic to come from their source-ip's or do creative things
> with
> x-forwarded-for etc.
>=20
> Making an active/active datacenter design work (or preferably one with
> enough sites such that more than one can be down without seriously
> impacted
> service) is a serious challenge. Lots of people will tell you (and
> sell you
> solutions for) parts of the puzzle. My experience has been that the
> best
> case is when the architecture of the application/infrastructure have
> been
> designed with these challenges in mind from the get-go. I have seen
> that
> done on the network and server side, but never on the software side-
> that
> has always required significant effort when the time came.
>=20
> The "drop in" solutions for this (active/active database replication,
> middleware solutions, proxies) are always expensive in one way or
> another
> and frequently have major deployment challenges.
>=20
> The network side of this can frequently be the easiest to resolve, in
> my
> experience. If you are serving up content that does not require
> synchronized data on the backend, then that will make your life much
> easier,
> and GSLB, a CDN or similar may help a great deal.
Thanks everyone who has responded so far. =20
I should have clarified my intent a bit in the original email. I am defini=
tely interested in architectures which support synchronized data between da=
ta center locations in as close to real-time as possible. More specificall=
y, I am interested in designs which support zero down-time during failures,=
or as close to zero down-time as possible. GSLB, Anycast, CDNs... those t=
ypes of approaches certainly have their place especially where the pull-mod=
el is employed (DNS, Netflix, etc.). However, what types of solutions are =
being used for synchronized data and even network I/O on back-end systems? =
I've been looking at the VMware vSphere 4 Fault Tolerance stuff to synchro=
nize the data storage and network I/O across distributed virtual machines, =
but still worried about the consequences of doing this stuff across WAN lin=
ks with high degrees of latency, etc. From the thread I get the feeling th=
at L2 interconnects (VPLS, PWs) are generally considered a bad thing, I gat=
hered as much as I figured there would be lots of unintended consequences w=
ith regards to designated router elections and other weirdness. Besides co=
nnecting sites via L3 VPNs, what other approaches are others using? Also, =
would appreciate any comments to the synchronization items above.
Thanks,
--
Stefan Fouant
