1

I want to be able to upgrade my hardware at any time without interruption in my web app i.e. switch off one of the computers at any time, swap/upgrade it, plug it back in, and set it up so it gets everything back, including all the changes to disk that happened to the other computer as well, while the wep app continued to run as normal on the other computer. And vice versa.

So basically, I wanna be able to do an across-the-board failover replication of my server.

What is the easiest way of making this happen, and still work properly?

And besides the easiest way, can this also be done at the web app level, so I can use/try different app servers (Glassfish, JBoss, etc.) for each computer, or must it be the same app server, (e.g. Glassfish+Glassfish, or JBoss+JBoss)? I'm not tied to any app server.

Navigateur
  • 1,852
  • 3
  • 23
  • 39
  • Many more details are needed for this type of question, such as what the application does, if it uses/depends a database, etc etc. There is no single solution. – matt b Oct 14 '11 at 14:45
  • You could of course manually copy things between apps as long as they're both running, but I'm not aware of any framework that will make that easy for you. Typically this stuff is done in the container because that means the app can largely ignore it, making it easier to port. The fact of the matter is that if you go from JBoss to Glassfish or something similar it probably won't be that much work to set up replication on the new server. The biggest problem in replication is usually keeping context of ongoing requests which you can easily mess up with statics etc. – Vala Oct 14 '11 at 14:48
  • @Navigateur: what are the requirements and how many "nines" do you want? Eliminating every single SPOF (Single Point Of Failure) can be very hard (and/or very expensive). Simply running your app in a VM (not a Java Virtual Machine, but a full virtualized OS) and then live-migrating the VM to more beefy hardware can be done on the cheap and requires basically zero work on the "Java side" and would already provide "across-the-board replication" (but no failover). More complex HA/failover setups can be done this way too. Would it be acceptable in your case to solve this not at the Java level? – TacticalCoder Oct 14 '11 at 15:13
  • @User988052, How many nines? As many as poss. I guess. Yeah I don't mind this being solved at any level. – Navigateur Oct 14 '11 at 18:08

1 Answers1

0

At the very minimum you need to have replication in the application layer - that is the application server, so if this is Tomcat (or something similar) you can read this article as a start. The basic idea is that the HA software would decide to which server to route the request. So in case something happens with srv1 then srv2 will automatically take over. But the most important thing is state-replication that is if you go to srv2 in case srv1 has failed then the users don't have to re-log or loose information. In order to achieve this you can use a shared database for state-related information or use a software, which helps you with this - the main idea behind the latter approach is that memory is replicated across the 2 (or more) instances of the application (in case you don't use a separate, shared database). Check this question (along with the answer) for more information

Community
  • 1
  • 1
LordDoskias
  • 3,121
  • 3
  • 30
  • 44