senthilraja P wrote:
We are planning to setup a Live Backup server for our blog application. The
requirement is that one of the server should act as backup server, and when
the load peaks up, it should share the load. During normal times, the main
server would be handling all the loads. When the main server fails for some
reason, the backup server should take on automatically, and any data
updation has to be synchronised with the main server, once its up.
You need to make sure the code is identical + the machine setup needs to
also be near identical and make sure there is no user or system state
being maintained which is local machine specific.
I'd guess you are using a db for state and app-data, so make sure you
mirror that information to both machines as well. Replication has its
uses's - many people argue that failover is not one of them. The same
people argue for shared storage. That comes with its own issues. But see
what works for you, try different options.
For inbound load sharing you could do some really nice stuff with nginx
as a http proxy in front of your httpd services. Even load specific or
time specific policies are trivial to implement. And you get cheap wins
for things like static content cache's etc.
For the failover/disaster recovery, a shared IP Heartbeat based setup
works well ( for millions of people ) - if your machines are close
enough, and the ISP is ok with you setting up something like that, a
VirtualIP/SharedIP scenario works well.
Finally, most people consder failover/disaster recovery to be orthogonal
to load sharing and would address system setup based on what role you
are playing for. If you are small enough, you can dualrole the entire
infrastructure - but make sure your sysadmins know exactly what is going
on and how it all works. When disaster recovery policies need to go in,
it usually means something is quite badly broken :)
play around, if you get stuck or need more info about anything, feel
free to email!
- KB
_______________________________________________
To unsubscribe, email [EMAIL PROTECTED] with
"unsubscribe <password> <address>"
in the subject or body of the message.
http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
