Hi Geoff, Thinking about it for a minute i guess your question is valid but complicating the situation. My assumption is that this is more a simple question of how we can get out of the single point of failure in a simpler manner some thing more on the lines of what Silvia has suggested. DR is usually as expensive as HA and is usually entailing DB synchronizations and file system replication on the fly. The DR solution we are suggesting here is the cheap scape and will lead to the problems that ma.gnolia.com had encountered, where a loss of UGC had made them stop the service for a year due to DB backup corruption. Cheers, Y.
On Thu, Jan 7, 2010 at 10:35 AM, Yuval Ararat <yara...@gmail.com> wrote: > Hi Geoff, > I think it is very clear that the discussion is over DR and not HA since we > are talking about redundancy and not performance issues. > Cheers, > Y. > > On Thu, Jan 7, 2010 at 8:00 AM, Geoff McQueen - Hiive Systems < > geoff.mcqu...@hiivesystems.com> wrote: > >> Phil, >> >> >> >> When we look at this stuff, we distinguish between High Availability (HA) >> and Disaster Recovery (DR). The two are very different. >> >> >> >> HA is where you want to minimise/eliminate single points of failure, and >> usually the kit or approach needs to be in the same hosting environment as >> your primary kit. This approach is generally more expensive and more complex >> to set up, but it means you can actually pull the plug out of the back of >> one of your machines and the website will keep on going, automatically, when >> set up right. >> >> >> >> DR is where you’re preparing for the end of the world occurring in your >> main hosting facility – plane flying into building, etc. This requires >> geographical distribution and is more akin to backup principles with an >> aspect of planning to run the site temporarily from a secondary location. A >> VPS as Silvia suggested is a good plan here, as they’re inexpensive to have >> in the background, and can usually be scaled up as you need them fairly cost >> effectively. >> >> >> >> Which aspects of the two above are you focusing on with your redundancy? >> >> >> >> Geoff >> >> >> >> *From:* silicon-beach-australia@googlegroups.com [mailto: >> silicon-beach-austra...@googlegroups.com] *On Behalf Of *Phil Sim >> *Sent:* Wednesday, 6 January 2010 7:31 PM >> *To:* silicon-beach-australia >> *Subject:* [SiliconBeach] Redundant Servers >> >> >> >> Hi all, we're finally moving to put in place a redundant server and >> failover. >> >> >> >> We've running a local primary server and a redundant server on rackspace. >> I'm interested in what other people are doing in terms of failover. Are you >> automating it, and if so how are you doing it? Semi-automation? Manual? Not >> a lot of system experience here, so any advice welcomed. >> >> >> >> phil >> >> -- >> You received this message because you are subscribed to the Silicon Beach >> Australia mailing list. >> >> Guidelines on discussion: http://tr.im/ujKF >> >> No lurkers! It is expected that you introduce yourself: http://tr.im/ujMm >> >> To post to this group, send email to >> silicon-beach-australia@googlegroups.com >> To unsubscribe from this group, send email to >> silicon-beach-australia+unsubscr...@googlegroups.com<silicon-beach-australia%2bunsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/silicon-beach-australia?hl=en?hl=en >> > >
-- You received this message because you are subscribed to the Silicon Beach Australia mailing list. Guidelines on discussion: http://tr.im/ujKF No lurkers! It is expected that you introduce yourself: http://tr.im/ujMm To post to this group, send email to silicon-beach-australia@googlegroups.com To unsubscribe from this group, send email to silicon-beach-australia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/silicon-beach-australia?hl=en?hl=en
