[SGVLUG] Hosting a Site over multiple locations and public IPs
Charles Wyble
charles at thewybles.com
Tue Dec 15 17:07:09 PST 2009
On Dec 15, 2009, at 4:59 PM, Edgar Garrobo wrote:
> It would be the same provider, Latisys, in both locations.
That helps things.
> I'm using IP address ranges provided by Latisys.
Is it from the same block? Independent blocks? Will they provide you with any fail over help? I've never heard of Latisys, so no comments. Perhaps others have.
> The two sites both have a private point to point 3Mbps link between each other.
Hmmmm. 3mbps isn't that much. This is bonded t3? Ethernet? Are you running a vpn solution over it? What do you have on each end of the link? Any wan accelerators?
> There's no load balancers since the budget ran out before that.
That's not a good sign. You could put up a linux box with LVS. That's super simple to do. Then have LVS at each site serving as a local traffic manager, and LVS at each site serving as (redundant) global traffic managers. Then use DNS round robin between them. This is used by many folks , and I've done it myself. With F5 and not LVS, but it's essentially the same. I do not particularly care for F5 products, as I've found them to be very prone to strange failures (loss of one VIP, sync issues in active/standby pair etc). I prefer doing as much as possible in software on commodity hardware. Certainly you want redundancy at the box/rack/switch level (raid/one box in each rack/each rack fed by separate power/dual pathed switches etc). Then use DNS for site level redundancy. Chances are, if you are somewhere with a blended IP solution you'll never go off the net (or the lost business will be less then paying for a fail over site).
> I'm not really looking for a "how to" just curious what others have done or seen done on this. In all likelihood, I'll have to just use DNS Round-Robin for the two sites to have any kind of failover.
That works fairly well actually.
>
> From: sgvlug-bounces at sgvlug.net [mailto:sgvlug-bounces at sgvlug.net] On Behalf Of Charles Wyble
> Sent: Tuesday, December 15, 2009 4:08 PM
> To: SGVLUG Discussion List.
> Subject: Re: [SGVLUG] Hosting a Site over multiple locations and public IPs
>
> You might want to ask on the UUASC.org and SFVLUG list, as well as here.
>
>
> This is a fairly advanced topic, and any advice you receive you should take with a hefty grain of salt.
>
> Some folks who have this experience might not be willing to share it for free. :) We can be bought though (usually after meeting dinner is sufficient, at least for me).
>
> I've worked on multi site applications (evite.com, several e-commerce disney properties such as disneyworld.com etc) and the only thing I can say with confidence is "it depends". One would need far more data on your setup then you have provided here.
>
> Do you have your own address space? What kind of links between the data centers? What sort of routing? What sort of load balancers? Is the provider the same one in two different locations?
>
> etc....
>
>
> On Dec 15, 2009, at 3:54 PM, Edgar Garrobo wrote:
>
>
> I'm on a project where we're hosting an application which has a web interface and a Citrix service interface. I've set up two co-location sites, one in Irvine, CA and one in Chicago, Il, for redundancy and to distribute the user load. I'm wondering what the LUG's opinions on the best way to hose a multi-location website? Both sites have separate public IP addresses but identical equipment and the data is replicated between sites at block level by the NetApp storage devices. Ideally a user would be able to go to www.mydomain.com and hit whichever site's web server responds first and if one location was to go down, the users wouldn't notice since they would be automatically connected to the other site without having to use a different URL.
>
> Any suggestions on the ideal setup for such a scenario?
>
> Thanks,
>
> Edgar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.sgvlug.net/pipermail/sgvlug/attachments/20091215/1d8eb79e/attachment.html
More information about the SGVLUG
mailing list