4 ms·
Interesting question :) 1. The most cost effective in terms of immediate capital outlay is active-passive - which is pretty much #1 that you described. This is
by jwilliams 18y ago
Interesting question :)
1. The most cost effective in terms of immediate capital outlay is active-passive - which is pretty much #1 that you described. This is generally also less effort... and is generally easy to test.
2. The most cost effective long term strategy is active-active as you get ongoing use of both sites. Particularly if the client is happy for reduced performance in a DR scenario... Even if this isn't the case, at least you get a performance boost from the DR site.
This is usually more effort as you need things like replication to work/perform... And you also need to test a whole new range of failure scenarios.
This approach does have some other advantages though. For example, you can do rolling deploys very easily (upgrade DR first, bring down Prod, upgrade Prod).
3. A common hybrid is to have two active sites on the Tomcat/Apache end and active-passive for the MySQL. Depending on the DB load this can be a best of both worlds scenario.
4. Some other solutions use a coherent cache solution - e.g. Tangosol, which works with Hibernate/MySQL. As long as the latency between the two sites is low, then this should work. Tangosol is a non-free product, now owned by Oracle afaik, but I don't think it's prohibitively expensive... I've seen this used a lot, and it's probably a very simple and elegant solution, but I personally don't like adding another moving part in. A lot of people I've met swear by it though, particularly Hibernate users.
- jwilliams 18y agoAs an aside.. I've been involved in doing the sums on DR-sites in the past and it quite often doesn't add up. So I'd recommend doing a cost-benefit analysis with the client. You've also got to look at all the intermediate threats. For example, a DR site may be on the same network as the Prod site... Or the client site might be on a single network. So you can spend a lot of money eliminating a sole single point of failure when there are dozens of others around (network failures are much more common than a site getting obliterated).
- dabeeeenster 18y agoThe problem is that my client's client (we are a subcontractor in this instance) is demanding it. I've explained that, in real terms, they will get little benefit from the large capital expenditure, but it's become a contractual requirement. My current hosting provider are excellent, and we have a > 99.99% uptime with them on this application according to pingdom (and this includes scheduled downtime!) but you know how clients are sometimes!
- dabeeeenster 18y agoThis response is exactly why I posted on HN! Love this site. In terms of active-active, I guess I need two physically disparate load balancers that heart beat with each other? I'm not really a network engineer, and I dont understand what happens to the packets when 1 data center goes down, in terms of routing around it? Thanks for your time.
- jwilliams 18y ago> In terms of active-active, I guess I need two physically disparate load balancers that heart beat with each other? Yeah - as the brk indicates in his post, you can use something like haproxy to do this. Afaik, you can get Apache to do this too... One advantage might be that Apache can be configured to do "sticky sessions" - which you'll need if you're not sync'ing sessions between sites (which in this scenario doesn't seem necessary). Never used haproxy, but it might do this too. In terms of your active-active setup, you can have two "legs" that are load balanced at the front, or you can have load balancing between each tier. If you're (a) not very experienced or (b) you don't have lots of bandwidth between sites, I'd go with the former and just have load balancing at the front end.
- bprater 18y agoAgreed, this is the type of information that is tough to find elsewhere, since it tends to be somewhat specialized. So for everyone posting -- thanks!