0

Maybe my question is a little bit stupid, but idea is to have a reserve web server, which will be activated WHEN main web server becomes inactive (DDos, or any other incident).

Please name common practices for this solution. Operation system will be freeBSD. Im really interesting in package names, methods how to sync files almost in realtime, with a minimum delay, especially database server because payments and sessions and stuff like that, must stay as it was started on the first server. My first idea is rsync, but this sounds lame for me if you thing about how many stuff needs to be transferred... I even would agree to clone memory stack =))

p.s. even if you guys don't understand what i'm talking about, or I need to be more specific, shoot all your ideas, for various kind of syncing =) Thnx.

EDIT:

Thank you guys, now I have plenty ideas about failovers. I'll probably will use HA Cluster with load-balansing.

Improve this question
2
  • I would suggest you separate the web/app and database tiers into different questions.
    – HTTP500
    Dec 3, 2010 at 16:44
  • Is the Database Server a separate server? Or is it running on the webserver? This is the first thing I'd change if they are both on the same server, it will complicate any attempts at having sessions survive a fail-over.
    – BillN
    Dec 3, 2010 at 16:50

5 Answers 5

Reset to default
1

On a high level what you want to do is create a two node High Availability cluster with failover.

http://www.todoo.biz/cluster_ha_freebsd.php

What type of page is the web server hosting? Is there a database involved?

Improve this answer
4
  • there will be plenty of virtualizations in there, database server included... about 500k people per day...
    – holms
    Dec 3, 2010 at 15:40
  • 1
    I would focus on having multiple front end web servers with shared storage. The shared storage could then be a high end/redundant array, with fail over etc so if anything goes wrong there you have a backup. For the front end servers you can either have it setup just to failover in case the main server goes down or even better as long as you have the hardware you can have multiple front end servers deliver the requests with round robin architecture.
    – cpgascho
    Dec 3, 2010 at 17:13
  • great idea! which method is best to share storage between servers? i'm afraid about performance stuff
    – holms
    Dec 5, 2010 at 5:09
  • 1
    Your shared storage should ideally be high performance storage array which is accessed by fiber channel that will give you the best performance, otherwise a good SAN would be your next best bet.
    – cpgascho
    Dec 8, 2010 at 18:43
1

You may want to grab some litterature about GGATED on FreeBSD, but if you're willing to use another OS for your MySQL database storage then DRBD with HeartBeat is a good solution for mirroring data in realtime and handling automatic failover of the mySQL cluster.

EDIT: That would not mitigate a DDOS attack on your External IP either.

Improve this answer
1

In the Linux space the web servers would mount a cluster file system (e.g. OCFS2). I don't know if there is a "real" cluster file system in FreeBSD land. You could use NFS with "noac" mount option but the performance is terrible so it's not really recommended as a robust/scalable solution.

Cheers

Edit: As for the reserve nature of the web server, use a proxy/load balancer like nginx that backhands the two servers. nginx's configuration actually specifies the reserve as "backup".

Improve this answer
1

Why failover instead of using smart load-balancing? There's a lot of things which could go wrong during a failover operation - with load-balancing it's not an issue.

For realtime file replication, have a look at AFS or its derivatives, or use a common HD with a cluster filesystem. For non-realtime, rsync or unison. For database replication....well that depends on your current DB.

Improve this answer
2
  • database is mysql. hmz, does load-balansing more common solution then failover these days? if so why =)?
    – holms
    Dec 5, 2010 at 5:13
  • "There's a lot of things which could go wrong during a failover" and its not something you want to test regularly, and load balancing has additional benefits for capacity. For mysql - use master-master replication - but read up on seeding / incrementing autoincrement values
    – symcbean
    Dec 6, 2010 at 14:00
0

the idea is to fail over when the main server goes down. this can be accomplished very easy if there is not constraint into this problem domain, as you don't have a component as session affinity or a central database.

now if you have this type of constraints you can still do it but in a more restrict manner. for example if you want to have one server in australia and one in usa will be more difficult for the servers to share a common database over the internet.

however if you can live with fail over into the same datacenter (network) the only issue in this case where you keep the sessions - if they are into the db then you are all set because both servers can read that data.

for server content even though you feel rsync is lame ... is not it just does the job. there are other solutions as having a common file system etc.

in case that you have servers geographical separated you can look into a non sql database that is distributed over the internet ( look at appengine from google :) or use one of the tools that maxwell suggested.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .