Portal Home > Knowledgebase > Articles Database > How to keep sincronized two servers (to use failover)
How to keep sincronized two servers (to use failover)
Posted by pedrojose, 04-21-2009, 08:04 PM |
Hello,
We want to provide failover service at our server using dnsmadeeasy service.
So we have already buy the "failover server" (running linux/plesk), and now we are looking to find the most adequate / best way in order to keep the 2 servers sincronized, in order that if "main server" goes down, all the traffic can be redirect to the "backup server" using dnsmadeeasy.
Any advices on scripts/software to keep 2 linux servers sincronized in a failover setup?
Thanks
|
Posted by squirrelhost, 04-21-2009, 09:32 PM |
why not use both servers in production, i.e. redundancy.
then use dnsmadeeasy to remove a failed server from production.
either way you have some issues using a database, or with sessions, if you have two servers in production, but there are off-the-shelf answers to both issues anyway.
|
Posted by TailoredVPS, 04-21-2009, 09:43 PM |
Might be off topic, but you spelt syncronize wrong.
I just get bugged by spelling mistakes (not sure why).
|
Posted by UNIXy, 04-21-2009, 09:56 PM |
The short answer is there's no easy way to keep the two servers synchronized. There are many variables at play. I don't know much about Plesk but we've developed a methodology for cPanel and it isn't simple. I wouldn't be surprised if one would face the same challenges with Plesk.
Best
|
Posted by squirrelhost, 04-21-2009, 10:07 PM |
If you're simply running your own websites which you manage yourself then it's not difficult, and there need be no issues with databases or losing sessions in switching over to another server. If you're hosting others' websites and looking after their services like email/ftp as well, then it's much more difficult indeed. If you're not technically advanced then probably best to not even bother trying, until there's an off-the-peg plug and play solution offered by someone someday.
|
Posted by mwatkins, 04-21-2009, 10:47 PM |
So did you
So do it, to some extent.
|
Posted by mwatkins, 04-21-2009, 11:01 PM |
You really should know what the total solution is before buying hardware.
There are many types of high availability solutions, some of which include failing over some component of the solution. In my big iron Unix days we sold highly available solutions that would as a side benefit also heat your office nicely.
Two machines, special high speed disc interfaces or storage area networks, a common central data store (shared storage on a SAN or specialized external storage unit), some heartbeat mechanism to trigger the backup server to take over when the primary has died. Some machines took this to extremes by having "hot spares" for RAM. You can imagine this could get costly.
Dual power supplies in the SAN; dual network interfaces, hot spares in the SAN. Is "hot standby" used? if not, how is application and data state dealt with? Lots of questions. If I was still in the big iron biz I could give you some specific answers and a big bill.
Or you go the other way - as another has suggested - and use all the equipment all of the time. The less complicated way of dealing with this is with a storage area network or direct attached storage with a ton of redundancy built in (lots of disc, redundant power supplies, network/attach method) - and everything else (servers, network components, power, etc) is provisioned n+1. Data remains the big point of failure, but no worse than say a switch in the rack.
If you really want big time high availability you've got to have geographic diversity as well, but then you really do have big time data replication issues far beyond the scope of this thread. If your need is that big, you can hire a professional at professional rates to design the solution for you.
|
Posted by mugo, 04-22-2009, 02:30 AM |
I do this exact thing, with DNSmadeeasy.
I simply use rsync to copy over web sites, mysqldump do dump databases directly to the other mysql, and also "modularize" my httpd.conf, using includes, which you can also rsync over.
My VPSs are exact mirrors, I use load balancing on some sites, others are just waiting for failover.
Works great, and you can copy your ssh public key to the receiving servers authorized_hosts, you don't even need a password, or to setup rsync server. Or put each on both so you can do any ssh / rsync with no password from trusted server to server.
Ping me if you want my method....I've been doing this for years, have it honed to a science.
|
Posted by mchristen85, 04-22-2009, 09:57 AM |
Heh.. if you run a mysql database you can use a master-master cluster to synchronize your data and use rsync to keep your web files in sync. That takes care of 99% of web scripts out there. Sessions are easy to take care of too, just load your cookies with *.yourdomain.com... although that can cause problems if you run other subdomains.
So in short, you can have a completely redundant geographically diverse cluster for cheap if you run a simple php/mysql site.
|
Posted by squirrelhost, 04-22-2009, 10:02 AM |
sessions are written to server(s), cookies are on user's desktop.
it's a no-brainer to write sessions to both servers, can read from either one, whichever is up and running (or the slightly more complicated method I use), a standard trick. having user's suddenly 'logged-out' or losing their shopping cart contents isn't too much of a problem, but writing sessions on both servers prevents that anyway.
|
Posted by mchristen85, 04-22-2009, 10:16 AM |
That's the point... both servers have the session and both will receive the SAME cookie from the user.
|
Posted by squirrelhost, 04-22-2009, 10:17 AM |
but you don't need to rsync anything to do that... writing session data to 2 servers is straightforward
|
Posted by squirrelhost, 04-22-2009, 10:18 AM |
and usually done using totally separate servers, i.e. yahoo's login servers, etc..
|
Posted by mchristen85, 04-22-2009, 10:37 AM |
No... but you can use rsync to keep your site files up to date. Say you need to upload a new version of your site.. why bother uploading to two servers(or ten) when you can have an rsync cron job that does it automatically?
Did you actually read my post or are you just trying to pick a fight?
|
Posted by mwatkins, 04-22-2009, 10:41 AM |
It's true that commodity hardware and software and especially networking bandwidth availability and prices have lowered the bar dramatically although I wouldn't put that type of architecture in the same league. Database replication / clustering and simple synchronization of file systems may be enough for 80% or more of the web application needs out there. They won't be enough for high volume transaction processing, but that isn't the realm of PHP and MySQL anyway.
In the 80's and in particularly in the early 1990's when big iron Unix really got moving on HA solutions, MySQL was but a glint in someone's eyes. It would take more than a decade more before MySQL could even do subqueries, views or stored procedures.
Today's commodity hardware, network and software allows us to lots of machines, really beef up your disc storage, a model tends to work pretty well, and is very inexpensive relative to the power you get.
Last edited by mwatkins; 04-22-2009 at 10:44 AM.
|
Posted by Syslint, 04-22-2009, 10:51 AM |
if you need a high availability ( like wordpress.org ) , PM me I can setup for you
|
Posted by squirrelhost, 04-22-2009, 11:03 AM |
exactly, buy 'em cheap, rack 'em high. on the database side though, when you're really scaling, Oracle (and sybase if it's still in business) can't be beat.
|
Posted by mugo, 04-22-2009, 11:49 AM |
In addition to my last post, for the "cookie" issue, and for general failover, there are a few programs that are not hard to implement. "balance" is opensource, works great, and has IP session persistence. A few creative ways to set it up using existing boxes, but best way get a 10 buck VPS to be your LB box.
Or two, and use DNSMadeeasy to do failover.
This *works*. I've ran many many sites over years this way, in addition to the method previously posted.
There are higher tech ways, but, they cost $$$, and ultimately are complicated and introduce failure. I'm a fan of the KISS method. Simple, direct, self checking, fool proof, FREE.
|
Posted by squirrelhost, 04-22-2009, 11:59 AM |
yes, you can do most everything opensource, or for very little - i've never seen any difference between the products of ultradns and dnsmadeeasy, except ultradns would bankrupt me!
even the most expensive 'foolproof' solutions can be fallible. we had a case at Yahoo, where one engineer removed every server behind an alteon, and assumed that the other alteon (over in dublin) would take over all the load there - a little bug meant the alteon in London, seeing no servers there return a 'status' check, assumed it was a network glitch and all servers MUST be therefore up and healthy - no website for UK viewers for a while!
|
Posted by mugo, 04-22-2009, 12:13 PM |
For what it's worth, I've used both, and DNSMadeEasy I actually use for IP failover at a company I work for, used the service the last 4 years, and I can't say enough about it. It works, never had an issue. Ultradns is WAY to expensive, IMHO.
|
Posted by hodfords, 05-06-2009, 02:36 AM |
Not all ISP's honour the TTL response times; how to deal with DNS caching when using a solution like DNS Made Easy
|
Posted by mugo, 05-06-2009, 02:44 AM |
True, but usually only a problem when TTLs are extremely low.
I've had no issues using TTL of 90 on 20 domains ran by a $40M annual revenue company for the last 4 years, and every cent comes from the web sites (I get in major trouble when they are down), so, take that for what it's worth.
It's worked excellent for us.
I've started using DNSMadeEasy for personal IT service business, also, works like a charm.
I admin many DNS servers (one of my services), so I @dig around a lot, never ran into an issue w/ non-honored TTL's w/ the service.
|
Posted by plumsauce, 05-06-2009, 06:21 AM |
True, to a very minor degree.
But, when your choices are a solution that works for most of your audience, or no solution at all ...
Sorta like having a hot date, with a choice of a pickup truck or the bus for picking up the date.
|
Add to Favourites Print this Article
Also Read