SharePoint Server 2016 零停机时间修补步骤
**上一次修改主题:**2016-10-21
零停机时间修补 (ZDP) 在 SharePoint Server 2016 中可用。在你修补你的 SharePoint Server 2016 场时,用户可继续操作、保存并搜索文档。
零停机时间修补 (ZDP) 是在 SharePoint Online 中开发的一种修补和升级方法。其开发意图是在允许管理员修补服务的同时,让用户继续使用其订阅。换句话说,这种经过测试的方法旨在允许在相关人员积极使用其文件、搜搜爬网和显示器结果时在 SharePoint Server 场中进行修补。这是“零停机时间”代表的含义。
讨论 ZDP 时要注意的几个事项(我们将在本文的后续部分中讨论这些元素)。
在 SharePoint Server 2016 中使用 MinRole 可以改进你的 ZDP 体验,但是 MinRole 不是必备项。
为什么 MinRole 可以发挥作用?
你的场必须具备高可用性 (HA) 才能从 ZDP 中获益。高度可用的 SharePoint Server 2016 场是使用 ZDP 的必备项。
为什么需要具备高可用性?
切记 ZDP 的目标是用户的运行时间,因此在本文中,涉及修补和重新启动场的所有决策都将以此为前提。
重要
即使 SharePoint Server 2016 场中的所有服务器都被配置为使用“自定义”角色,你仍然可以手动配置高度可用的场。documents on TechNet(TechNet 中的文档)将帮助你构建高度可用的场,且容错(具有冗余硬件)和高可用性(具有用于支持故障转移和运行时间延续的系统和软件)的主体是相同的。注意在更为复杂的高度可用或自定义场中,应额外注意以支持 HA 的方法修补搜索服务器,例如一次修补一个索引副本,绝不同时修补或升级同一个分区中的索引副本。
ZDP 进程
本示例对使用 MinRole 设置的 SharePoint Server 2016 场使用 ZDP。环境示例如下所示:
要将此结构分解,请将两个 Web 前端 (WFE)(SPWeb01 和 02)连接到一个负载平衡器,此时两者都在处理请求。有两个应用程序服务器(SPApp01 和 02)、两个分布式缓存服务器(SPDCH01 和 02)和两个搜索服务器(SPSRCH01 和 02)。在此结构之后但却未直接包含在 ZDP 进程中的是 SQL Server 群集(例如,SQL Server Always-On)。
可以假想在该图表的场中间从上到下画一条线。此线的一侧是最终位于“01”(列 1)的所有服务器,而“02”中的冗余服务器则位于另一侧(列 2)。我们将利用该双重结构来使场在修补期间处于可供用户使用的运行状态。
多数情况下,你在此线一侧(对 01 服务器)执行的任何操作,都会对 02 重复完全一致的操作。在这个相对简单的两个阶段的 ZDP 进程中涉及的所有步骤中,WFE(SPWeb01 和 02)使用的步骤最为复杂。我们将从此处开始。
备注
有关 SharePoint Server 2016 的软件更新的常规信息可以在此处找到。请注意指向有关 SharePoint Server 2016 的 permissions settings(权限设置)的文档的文章链接。请根据需要查看这些文章,并请注意修补部分涉及数据库更新。例如,如果你更改了 SharePoint 帐户安装后的 SQL Server 权限,则你需要查看这些文章。
请确保已重启并测试 WFE,然后再从负载平衡器中移除任意一个 WFE,以避免要首先修补的 WFE 被移除了循环而其他 WFE 无法处理生成负载的情况发生。场中的所有服务器都应通过重启刷新并且运行状况良好,然后才能进行修补。此外,在升级或修补窗口时,注意停止搜索爬网和配置文件导入。
重要
进行升级前应启用并行文件复制进程。即使正在升级或移除位于指定 WFE 的静态文件,并行运行也可以保证场中的所有 Web 前端在升级时处理相同的静态内容。并行功能内置于 PSCONFIG,但是必须被启用。即使在更改和更新文件系统文件时,此功能也可确保用户在浏览 SharePoint 和使用其文件时具有相同的网站体验。
若要启用并行升级功能,需要打开 SharePoint 2016 命令行管理程序 并在所有的 SharePoint 服务器上运行以下命令:$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
请注意管理员可以将“enableSideBySide”值设置为 $false 来选择退出并行功能。注意此操作可能会影响用户在浏览时查看到的内容。他们可能在一次浏览中看到升级的 UI,但在另一次浏览中又看不到,或者可能会遇到一些问题,例如,在他们浏览时 javascript 正在进行更改或者升级。
阶段 1 - 修补程序安装
第一个阶段是在服务器上获取修补程序二进制文件,并将其安装在服务器上。
-
从负载平衡器中移除第一个 WFE (SPWeb01),然后使用“STS”和“WSS”程序包修补它,完成修补后重启服务器,然后将此服务器返回负载平衡器中的循环。
-
从负载平衡器中移除第二个 WFE (SPWeb02),然后使用“STS”和“WSS”程序包修补它,完成修补后重启服务器,然后直至整个升级过程完成后再将此服务器返回负载平衡器。
备注
如果未在维护窗口中运行升级,且该场具有大量负载,则可以直至准备好运行 PSCONFIG 时再将此 WFE 返回网络负载平衡器。
-
对于列 1 中的每一个 SPApp、SPDCH 和 SPSRCH,都要使用“STS”和“WSS”程序包进行修补,并在其修补完成后将其重启。(由 SPWeb01 发送的工作将落到列 2 中的服务器上。)
-
现在对列 2 重复“修补和重启”操作。对于列 2 中的每一个 SPApp02、SPDCH02 和 SPSRCH02,都要使用“STS”和“WSS”程序包进行修补,并在其修补完成后将其重启。(如图所示,由 SPWeb01 发送的工作现在将落到列 1 中的服务器上。)
阶段 2 - PSCONFIG 升级
SharePoint Server 2016 场中的每个节点都已安装修补程序,且全部都已重启。现在应该执行内部版本升级了。
备注
在 ZDP 进程中,可以运行 Upgrade-SPContentdatabase 来缩短运行完 PSCONFIG 所需的总时间。在具有大量数据库或选择了大型数据库时考虑使用此操作。
-
返回已移除负载平衡器循环的 WFE (SPWeb02),打开 SharePoint 2016 命令行管理程序,然后运行此 PSCONFIG 命令:
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secrureresources -cmd services -install
命令完成后,将该 WFE (SPWeb02) 返回负载平衡器。该服务器已完全完成修补和升级。
提示
PSCONFIG 进程中的最后一步保证了将对用户界面 (UI) 的更新从 /layouts 文件夹复制到指定版本的文件夹。这是并行 UI 更新的一部分,可允许浏览你的场的用户在升级完成和你准备好切换到新界面前享有一种 UI 体验。
若要确认并行复制已成功,请检查相关的日志文件。默认情况下,该日志文件位于 C:\program files\common files\Microsoft shared\web server extensions\16\logs. 下。(你的根驱动器号可能会有所不同!)
如果由于某些原因,PSCONFIG 未成功复制 UI 文件,则请运行此命令 Copy-SidebySideFiles 来手动复制他们。 -
将 SPWeb01 从负载平衡器移除,打开 SharePoint 2016 命令行管理程序,然后运行相同的 PSCONFIG 命令:
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
将此 WEF (SPWeb01) 返回到负载平衡器。现在该服务器也已完全完成修补和升级。
两个 WFE 都已进行修补和升级。转至场的剩余部分,但是请确保一次只在一个服务器上运行所需的 Microsoft PowerShell 命令,而不并行运行。这意味着,对于列 1 中的全部项,你要一次只在一个服务器上运行这些命令。然后对列 2 中的服务器,一次只在一个服务器上运行这些命令,不能重叠。最终目标是维护运行时间。按顺序运行 PSCONFIG 命令是完成 ZDP 进程的最安全最可预测的方法,因此这也是我们要采取的方法。
-
对于列 1 中剩余的服务器(SPApp01、SPDCH01、 SPSRCH01),在 SharePoint 2016 命令行管理程序 中运行相同的 PSCONFIG 命令。在每个服务器上执行此操作,一次只在一个服务器上进行,直至列 1 中的所有服务器都已升级。
重要
注意运行 PSCONFIG 前先正确地 remove the Distributed Cache(移除分布式缓存)并在完成后重新 add the Distributed Cache to the server(将分布式缓存添加至服务器)。
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
-
对于列 2 中的所有剩余服务器(SPApp02、SPDCH02、SPSRCH02),在 SharePoint 2016 命令行管理程序 中运行相同的 PSCONFIG 命令。在每个服务器上执行此操作,一次只在一个服务器上进行,直至列 2 中的所有服务器都已升级。
重要
注意运行 PSCONFIG 前先正确地 remove the Distributed Cache(移除分布式缓存)并在完成后重新 add the Distributed Cache to the server(将分布式缓存添加至服务器)。
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
重要
所有服务器都已成功完成 PSCONFIG 后,注意运行下方的 SharePoint 2016 命令行管理程序 命令来切换至新的用户界面文件并完成并行进程:
$webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
$webapp.WebService.update()
现在你已大功告成,该场已在使用过程中完全完成升级,且无任何故障时间。
为什么 MinRole 可以发挥作用?
谈论 ZDP 时,还应阐释 MinRole 的概念。MinRole 是 SharePoint Server 2016 安装中的一个选项。它将场的配置划分为前端 (WFE)、应用程序服务器 (App)、分布式缓存 (DCache)、搜索或自定义(用于自定义代码或第三方产品)等角色。该配置将平均为你提供四种服务器 – 两个 WFE、两个应用程序服务器、两个分布式缓存服务器和两个搜索服务器。
默认情况下,调整 WFE 以实现低延迟,调整应用程序服务器以实现高吞吐量。同样,绑定搜索组件(这样调用则不必从它们发出的框中离开)使搜索服务器工作效率提高。MinRole 的最大优势之一是它内置默认容错功能。
为什么需要具备高可用性?
HA 在 SharePoint 中是一个广泛的主题。网上有关于它的完整的白皮书和文章,例如 TechNet 中的 本文档。若要简化此概念,至少在本文中,要实现在 SharePoint Online (SPO) 中发出的 ZDP(也称为 MinRole)。在 SPO 中,虚拟化的服务器具有内置冗余,这样两个具有来自同一个 SharePoint 场的相同服务器角色的服务器将不会位于同一个主机或机架上。这可以使 SPO 容错能力更为强大。可以让两个具有每种 SharePoint 服务器角色的服务器位于自己的服务中心不同机架上的独立主机上,机架间存在共享的路由器或缆线来使通信更快,以此来模拟相同的情形。还可以只在测试环境中设置每种 SharePoint 服务器角色的两个物理服务器(为场的每一半选择独立的电源插排,并确保服务器集之间的路由快速,并且如果可以,绕过较宽广的网络通信以实现低延迟)。
此处的目标是高可用性和容错功能。这意味着最优先执行的操作是将机架或服务器上的角色分开,确保配备具有每种角色的两个服务器,加快这两层之间的网络流量,并确保设置已使系统准备就绪可以监测数据库服务器并自动进行故障转移。对于在 SharePoint 中手动安装服务(选择“自定义”角色时),服务在场中具有冗余很重要。例如,分布式缓存聚集,你的场具有多个 WFE,将应用程序和搜索服务器成对设置。这样,在一个服务器存在严重问题时,另一个可以处理用户负载。
在此处使用的示例中,我绘制了物理服务器以使概念更易理解。规划 ZDP 时,应绘制自己的环境,无论其位于何处(包括机架名称/编号和服务器名称,其中可在服务器名称中找到每种 SharePoint 服务器角色)。无论安装程序的大小如何,这是隔离可能已潜入安装程序的任何角色冗余和容错目标冲突的最快捷方法之一。