On 10/3/07, Axel-Stéphane SMORGRAV <[EMAIL PROTECTED]> wrote: > > No matter which solution you choose, the real problem is to detect that > the server fails. > > If the server stops responding to requests, that's easy enough. However if > there is not a clear-cut failure, e.g. one server gradually slows down, or > still responds to the polls from the load balancer but not to certain > requests from clients the judgement call is harder... > > Apart from clustering solutions and HW load balancers, you could also add > Apache 2.2 and mod_proxy_balancer to the list. > > > Lot of suggestions are possible, but they all inflict pain. > A very clean and widspread solution is to have two identical webservers > (use a deployment script to keep the servers absolutely in sync) and use a > hardware loadbalancer in front of the two servers. This is likely to cause > financial pain. > > An alternative is to setup Linux HA-cluster. There are lot of how-tos > around. Still the learning curve is so steep, it means pain. Not > theoretically, but in practice, high-availability is only the goal. At > first, it just hurts. > > You could also try to go with the most simple solution and make your > server more stable. If you know you can cut your downtime by 50% by > investing a week of work in the server, then this is probably worth it. > Unless you need to cut it by 95% or 99%. But this would mean a lot of pain > anyways.
Thanks guys for your valuable suggestions, as our web servers is hosted at virtual machine (UML) in far data center it would be better to go for setup identical VM in some other collocation and keep it sync (using rsync) with the master and if master fails then switch to replica by doing little change in DNS zone file to points the web server IP to replica. Atm we are not looking for HA but fail over (even with some manual editing) solution in case one collocation get down we can switch to other one with little hassle and we can also afford 30 minutes down time :) Thanks and regards. Askar
