Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm considering the following setup:

  • 2 virtual servers with local C: drive
  • 1 filesystem on a SAN
  • Database server software installed on both, database on the SAN filesystem
  • 1 virtual server does production, the other one is a spare server
  • Both virtual servers are configured to be 100% identical, except for IP address, and only one of them may be connected to the SAN filesystem at the same time

This way, when upgrading/patching the database server to a newer version, we could do this:

  • Upgrade the spare server's database server software
  • Disconnect users
  • Move primary server to a different IP address and disconnect from the SAN filesystem
  • Move the secondary server to the production IP address and connect to the SAN filesystem
  • Reconnect users, so that they now use the secondary server
  • Upgrade primary server's database server software

After this, the roles are switches, making the primary server become the spare, and vice versa. As far as I see it, the total downtime for this should be a few seconds.

Is this a viable setup? Are there any things that I should be careful about?

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

That is a perfectly acceptable setup. Depending on your choice of DB engines, I would only suggest that perhaps you setup a 2nd copy of your database as well, and perhaps implement a mirroring or log shipping plan. In the remote chance that any corruption occurs in one db, you could failover to the other DB. But I digress :)

To get back to your question, there are some additional considerations - what the planned amount of time is for the switchover, and this will will affect your user-base.

share|improve this answer
    
How long time do you think the switchover would take? –  Lars D Dec 17 '09 at 8:44
add comment

This can work. The only place you might get in trouble is with the DB itself. It may not like being upgraded with no data attached (on the backup machine), and my not like having the data re-appear after the upgrade(after the backup is made primary).

Definitely test this on your DB software in a lab before going into production,as you can potentially corrupt your DB. One way to protect against this is to take a SAN snapshot before switching over, so you can switch back again on the original server and the snapshot if disaster strikes.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.