Freigeben über

Zero Downtime Patching in SharePoint Server 2016

  • Artikel

This post was written by Philip Gwynn, Senior Consultant, Microsoft Services.

One of the exciting new IT Pro features of SharePoint Server 2016 is the ability to patch your farm without causing any downtime.  While updating the SharePoint 2016 PLA Operations Guide, we tested this feature and found it works quite well as long as the Web Front End (WFE) servers are removed from the load balancer while patching.  But before we go into the details, here is a bit of an overview of patching SharePoint for those who aren’t familiar with it.

The process of updating a SharePoint Server 2016 environment is a two-phase process: binary patching and build-to-build upgrade.

Patch phase

The patch phase has two steps, the patch deployment step and the binaries deployment step. During the patch deployment step, new binary files are copied to the server running SharePoint Server 2016. Services that use files that the patch has to replace are temporarily stopped. Stopping services reduces the requirement to restart the server to replace files that are being used.

The second step in the patch phase is the binaries deployment step. In this step, the installer copies support dynamic link library (.dll) files to the appropriate directories on the server that is running SharePoint Server 2016. This step ensures that all the web applications are running the correct version of the binary files and will function correctly after the update is installed. The update phase is complete after the binaries deployment step.

Build-to-build upgrade phase

The next and final phase to deploy software updates is the build-to-build upgrade phase. This phase modifies database schemas, updates objects in the farm, and updates site collections. After you finish the patch phase, you must complete the update installation by starting the build-to-build upgrade phase. The build-to-build upgrade phase is task intensive and, therefore, takes the most time to finish. The first action is to upgrade all the SharePoint processes that are running. After you upgrade the processes, the databases are crawled and upgraded. After you complete a farm upgrade on one server, you have to complete the process on all other servers to maintain compatibility.

Patching steps

Here is a diagram which shows a sample sequence of steps required to install an update on a typical SharePoint farm topology.

 

Note: DO NOT RUN the SharePoint Products Configuration Wizard until all servers have been patched (steps 1-12, below)

  1.     Remove half of the web servers (WFE#1) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.
  2.     Run the executable file to install the update on each web server that is out of the load-balancing rotation (WFE#1).
  3.     Add the updated web server (WFE#1) back into the load-balancing rotation.
  4.     Remove the remaining web server (WEB#2 from rotation in the load balancer.
  5.     Run the executable file to install the update on each web server that is still out of the load-balancing rotation (WFE#2).
  6.     Add the updated web server (WFE#2) back to the load-balancing rotation.
  7.     Run the executable file to install the update on the Central Administration server (APP#1).
  8.     Run the executable file to install the update on the second application server (APP#2).
  9.     Run the executable file to install the update on the first Search server (SRC#1).
  10.    Run the executable file to install the update on the second Search server (SRC#2).
  11.    Run the executable file to install the update on the first distributed cache server (DCH#1).
  12.    Run the executable file to install the update on the second distributed cache server (DCH#2).

At this point in the process, the databases and other components such as settings, features, and site-level data must still be upgraded because the SharePoint Products Configuration Wizard was not run on any of the farm servers. However, the farm should be capable of running in backward compatibility mode for a limited time.

Upgrade Servers

The following illustration shows the steps that upgrade the farm servers to finish the patching process.

  1.        (Optional) Use the Windows PowerShell Upgrade-SPContentDatabase cmdlet to upgrade each content database. This is an optional step, but it will help ensure that all content databases are upgraded first. It has the advantage of enabling some parallelism to reduce upgrade time. If it is not performed, all remaining non-upgraded content databases will be upgraded serially when you run the SharePoint Products Configuration Wizard to upgrade the farm servers.
  2.       Run the SharePoint Products Configuration Wizard on the Central Administration server (APP#1).
  3.      The SharePoint Products Configuration Wizard also starts an immediate upgrade of the configuration database and all other databases that are not already upgraded. Because it is likely that the content databases are the only databases that have already been upgraded, as described in the previous step, all the service application databases are also upgraded in this step.
  4.       Run the SharePoint Products Configuration Wizard on the remaining application server (APP#2).
  5.       Remove the first web server (WFE#1) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.
  6.       Run the SharePoint Products Configuration Wizard on the web servers (WFE#1)
  7.       Add the upgraded web server (WFE#1) back into rotation in the load balancer
  8.       Remove the first web server (WFE#2) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.
  9.       Run the SharePoint Products Configuration Wizard on the web servers (WFE#2)
  10.       Add the upgraded web server (WFE#2) back into rotation in the load balancer
  11.       Run the SharePoint Products Configuration Wizard on all remaining servers, one at a time (DCH#1, DCH#2, SRC#1, SRC#2)

 

Wrapping it up…

Maintaining SharePoint Server (any version) involves keeping it healthy. The SharePoint 2016 Product Line Architecture (PLA) includes a manual (the Operations Guide) with daily, weekly, and monthly checklists as well as detailed information like what's described in this post. The SharePoint 2016 PLA takes the best of Microsoft’s learnings from the cloud, projects with customers, Premier and broad support, and repeated consulting engagements to come up with a reference architecture and recommendations. Find out more by contacting your Microsoft Enterprise Services representative and by visiting the PLA blog.

Comments

  • Anonymous
    March 11, 2016
    Awesome Blog post
  • Anonymous
    March 24, 2016
    In what part is the zero downtime explained? We've been patching SharePoint this way for 10 years, what's new? As long as we take the WFEs out of the NLB and use PowerShell/UI to stop services before installing patches we don't have downtime, i.e., if done properly the patch phase doesn't incur in downtime in 2007, 2010 and 2013 versions. What causes downtime is the build-to-build upgrade, specifically the database upgrade phase. SharePoint 2013 introduced a -UseSnapshot parameter on the Upgrade-SPContentDatabase commandlet which allows us to have the site collections online while it's content database is upgraded (using a snapshot, i.e, a read-only mode) so we already had a "zero downtime patching" with SharePoint 2013 (as long as we used a SQL edition that supported snapshot of course). What's new on SharePoint 2016 about this? Unless I completely failed to see it, that is not explained.
  • Anonymous
    March 30, 2016
    Marco, you are correct in that there have always been ways to keep a farm up (read-only mode) while patching. What SharePoint 2016 brings is the ability to keep a farm up in read/write mode, without the headache of switching things back and forth between multiple farms.
  • Anonymous
    April 20, 2016
    Can we get the Operations Guide documentation from SharePoint 2016 PLA?