Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I searched around and I was surprised that I couldn't find an answer to this question. My assumption is that you have multiple servers. Normally they both will be doing their specific take (for the rest of this I will assume a simple website). Now lets say server A & B need updates. Do you update server A while server B keeps pushing out the webpage and then when server A is okay you update server B? This seems like it would work in small scale but seems horrible in large scale due to the fact that you'd need twice the power that you normally have. When dealing with a large number of servers do you update small sections at a time? I thought the problem with this would be if server A can't work alongside server B C D E or F any-longer that's not that bad. But when you start updating you slowly lose this small percentage.

What is the proper way to deal with updates like this?

share|improve this question

closed as unclear what you're asking by Sven, MadHatter, TheCleaner, Shane Madden, Ward Jun 28 '13 at 3:05

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

The larger the scale, the easier it is. In small scale, you need two servers instead of one. In large scale, you need 804 servers instead of 803. (And, of course, would probably have a few more servers than you absolutely need anyway.) – David Schwartz Jun 27 '13 at 22:14

The "proper" way of doing updates is to take a server out of the operating pool, update it, then put it back in after the maintenance period. It's as easy as it sounds and often times you can find tools to do this for you. For example, in the use case of a website, typically you'd have a cluster sitting behind a load balancer (like haproxy, or even an appliance) and just taking the server offline is enough to re-balance the load.

The point of clustering is to have room for growth. That is, you'd want enough spare capacity to handle a server suddenly dropping out of the pool - planned or unplanned. That said, you'd also want to do this during off-peak hours as well to reduce the chance of overload.

And finally, if all else fails, make it a scheduled downtime and serve static pages off a CDN if you have to. In the case of *nix hosts, 99% of the updates don't even require restarts aside from the daemons affected, so there's that too.

share|improve this answer
But what about the incompatibility issues? – Griffin Jun 27 '13 at 20:35
This is where "testing" comes into play. You should never update production servers without verifying things will play nice. Always update a server in a testing environment to be sure it'll work. – Nathan C Jun 27 '13 at 21:02
I'm talking about the ones that won't play nice and are unavoidable. – Griffin Jun 27 '13 at 21:03
Do you have an example? Speculating won't help much. I haven't heard of simple system updates rendering a website of all things completely broken. – Nathan C Jun 27 '13 at 21:04
Upgrading may be the wrong word. I'm talking more like Windows to Linux (for servers I find this is a upgrade) or from one database type to a more efficient one (thinking Oracle to Microsoft but not sure if they'd play along). – Griffin Jun 28 '13 at 0:14

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