0

We just rebooted our WSS 3.0 servers for patching, and since the patch had a problem, our Sharepoint instance was unavailable to users for almost three hours. Now we need to redesign our setup so that patches don't incur any downtime in the future (i.e. users can access sharepoint through Server A when Server B is being patched, and vice versa).

Our current layout consists of:

  • 1 Server that runs Central administration and serves as the app server / WFE
  • 1 Server that runs the SQL db

Adding more servers is no problem: I figured we could just add two more servers that clone these roles and we should be good to go. However, I was told you can't duplicate the Central Administration server, so users will always be unable to access Sharepoint when you patch that server.

Is this true? How do we make our WSS 3.0 farm highly available?

Thanks!

How

|improve this question
1

It is not possible to apply a SharePoint patch to part of a farm at a time as SP Patches affect both the local file system on each server as well as all databases used by SharePoint. The entire farm is effectively disabled while a SharePoint patch is being applied.

The only way to accomplish what you are attempting would be to mirror the entire farm, make it Read Only (to prevent users from losing changes during the patch) and route traffic there while the primary farm is being patched. Once the primary farm is patched, route traffic back to the primary farm and then patch the backup farm. The best case is that the content would be read-only during the patch.

What I've usually done is to :

  1. Test the patching process on Dev and QA farms so that we have a feel for the impact and duration of the patch
  2. Schedule an outage for the farm at a time with the lowest possible usage, which is usually Sunday Mornings
  3. Redirect requests to a "Maintenance" page on a server not in the farm during the patch
  4. Make complete backups of all content and servers. Snapshot all VMs (if possible)
  5. Apply and test the patch
  6. Redirect requests back to the patched farm

What it sounds like you are shooting for would be nearly identical to a "Hot" failover farm that would be used in Disaster Recovery scenarios. Unfortunately, most DR scenarios assume that the primary and backup farms remain the same version throughout the full cycle of the DR event so they are not 100% applicable to what you are attempting to do.

|improve this answer
  • Thanks for the detailed answer. This is unfortunate news, however, as it implies Sharepoint doesn't really work as an Enterprise product. If you're committed to a five nines level of uptime, having servers inaccessible every time there's a critical windows update seems crazy. I love your idea of setting up a read-only mode workaround, but it's hard to believe Microsoft didn't design this kind of feature into the product. Having every Sharepoint farm in the world go offline every time there is a patch Tuesday seems like a serious problem. – Scrub A Dub Jun 19 '12 at 21:26
  • A WINDOWS Update? Yes, those can usually be applied in the way you mention-two servers in the farm and direct traffic to one while patching the other. However, some SP services are server-specific (Central Admin, Excel Services, Search Index, etc..) and those services will be unavailable if the server they are on needs to be restarted after the patch. There are ways to minimize this as well but you will likely need to scale your farm out a bit more than you have now, including multiple Web Front Ends and multiple App servers. technet.microsoft.com/en-us/library/cc748832.aspx – Dave Wise Jun 19 '12 at 21:54
  • FWIW - five-nines is a very high standard for any application and if you are seeking that level of uptime then it can be done with SharePoint but you should probably engage Microsoft directly. – Dave Wise Jun 19 '12 at 22:33
1

Without a complex architecture, this is really hard to do. Because, after all of the bits are updated on the servers, you need to run the config wizard which updates the databases. If you have a server whose version doesn't match the database, many times that server will throw errors when trying to access content.

The best way I could see this happening is this:

2 farms, 1 production, 1 maintenance. The maintenace farm has it's own DB server/cluster which mirrors the DB's from production. Before your maintenance window, you make all of your databases on the mirror readonly, turn off/pause the mirroring and change dns/redirect traffic to here from the production system.

Then you fully update the production system since no users are hitting that system. Once you have verified everything is working correctly, change dns/redirect traffic back to the production system. Then you update your maintenance computers, make the mirror db's not readonly and reenable mirroring.

I don't know if there is a better way but this is what popped in my mind. Still not perfect.

|improve this answer
  • Another great answer. Very clever proposal given the constraints of the system, but it's disappointing to hear there's not a standard procedure for applying windows updates to a farm without incurring downtime. – Scrub A Dub Jun 19 '12 at 21:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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