SharePoint Server のダウンタイムなしの修正プログラムの適用手順
適用対象:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
ダウンタイムなしのパッチ適用 (ZDP) は、SharePoint Server 2016、SharePoint Server 2019、および SharePoint Server サブスクリプション エディションで使用できます。 SharePoint Server ファームに修正プログラムを適用するときに、ドキュメントの作業、保存、検索をユーザーに許可します。
ダウンタイムなしのパッチ適用は、Microsoft 365 の SharePoint で開発されたパッチ適用とアップグレードの方法です。 ユーザーによるサブスクリプションの使用と、管理者によるサービスのパッチ適用が同時にできるように設計されました。 つまり、このテスト済みのメソッドは、SharePoint Server ファームでユーザーがファイルを作業したり、検索のクロールや結果の表示を行ったりしている間に、パッチを適用できるように設計されています。 これが、'ゼロ ダウンタイム' という言葉の意味です。
ZDP を説明する際の注意点は次のとおりです (これらの要素については、記事で後述します)。
SharePoint Server で MinRole を使用することで ZDP エクスペリエンスを強化できますが、MinRole は必須 ではありません 。
ファームは、ZDP のメリットを享受するために高可用性 (HA) を活用する必要があります。 高可用性 SharePoint Server ファーム は、 ZDP の要件です。
ZDP の目的がユーザーの稼働時間であることを覚えておくことが重要です。そのため、この記事では、このことを念頭に置いてファームのパッチ適用と再起動に関連するすべての決定が行われます。
重要
SharePoint Server ファーム内のすべてのサーバーが "カスタム" ロールを使用するように構成されている場合でも、高可用性ファームを手動で構成できます。 高可用性ファームの構築に役立つ 記事 があり、フォールト トレランス (冗長ハードウェアを持つ) と高可用性 (フェールオーバーとアップタイムの継続をサポートするシステムとソフトウェアを用意する) の原則は同じです。 より複雑な高可用性ファームまたはカスタム ファームでは、HA をサポートする方法で検索サーバーにパッチを適用する必要があることに注意してください。たとえば、一度に 1 つのインデックス レプリカにパッチを適用し、同じパーティションのインデックス レプリカを同時に修正またはアップグレードすることはありません。
ZDP プロセス
この例では、MinRole を使用して SharePoint Server ファームのセットアップに対して ZDP を使用します。 環境の例は次のようになります。
この構造体を分解すると、2 つの Web フロントエンド (WFE) (SPWeb01 と 02) がロード バランサーに接続されおり、この時点では両方とも要求を処理しています。 2 つのアプリケーション サーバー (SPApp01 と 02)、2 つの分散キャッシュ サーバー (SPDCH01 と 02)、2 つの検索サーバー (SPSRCH01 と 02) があります。 この構造体の背後にあり、ZDP プロセスに直接的には含まれていないものは、SQL Server クラスターです (SQL Server Always-On など)。
イデオロギー的には、この図にあるファームの中央を横切る線を上から下に引くことができます。 線の片側 (列 1) は末尾が '01' のすべてのサーバーで、他方の側 (列 2) は末尾が '02' の冗長サーバーです。 このデュアル構築を活用して、パッチ適用中にファームを最新の状態に保ちます。
基本的には、線の片側で (01 サーバーに対して) 実行したことを、02 に対してもすべて同じように実行します。 比較的単純な 2 つのフェーズの ZDP プロセスに関係するすべての手順のうち、WFE (SPWeb01 と 02) を使用するプロセスが最も複雑です。 ここから始めます。
注:
SharePoint Server のソフトウェア更新プログラムに関する一般的な情報 については、こちらを参照してください。 この記事は、SharePoint Server の アクセス許可設定 に関するドキュメントにリンクしていることに注意してください。 必要に応じてこれらの記事を確認し、パッチの適用にデータベースの更新が含まれることに留意してください。 インストール後の SharePoint アカウントに対して SQL Server のアクセス許可を変更した場合などは、これらの記事を確認する必要があります。
最初にパッチを適用する WFE が循環から除外されて、他方の WFE が結果のロードを処理しない状況を回避するため、WFE のいずれか一方をロード バランサーから除外する前に、必ず WFE を再起動してテストしてください。 ファーム内のすべてのサーバーは、パッチ適用の前に再起動して更新し、正常な状態にする必要があります。 また、アップグレード中またはパッチ適用中は検索のクロールとプロファイルのインポートを停止することも検討してください。
重要
side-by-side で実行することにより、指定した WFE で静的ファイルがアップグレード中または置き換え中であっても、ファーム内のすべての Web フロントエンドがアップグレード中に同じ静的コンテンツを常に提供できるようになります。 サイド バイ サイドは PSCONFIG に組み込まれていますが、有効にする必要があります。 この機能により、ファイル システムのファイルが変更中や更新中であっても、ユーザーが SharePoint を参照したりファイルを作業したりするときに、サイトで同じエクスペリエンスが提供されます。
サイド バイ サイド機能を有効にするには、いずれかのコンテンツ Web アプリケーションの URL を使用して、次の PowerShell スクリプトを 1 回実行します。
$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
SharePoint Server 2016 以降の KB3178672 (2017 年 3 月の更新) の時点で、PSCONFIG は、 16-HIVE\TEMPLATE\LAYOUTS フォルダー内のすべての .js、.css、.htm ファイルを 16-HIVE\TEMPLATE\LAYOUTS\<NEW BUILD NUMBER> フォルダーに自動的にコピーします。そのためには、 フェーズ 2 - PSCONFIG のアップグレード (4) の後のトピックで説明するように、新しいユーザー インターフェイス ファイルに切り替えてサイドバイサイド プロセスを完了する必要があります。
フェーズ 1 - パッチのインストール
最初のフェーズでは、サーバーでパッチ バイナリを取得して、インストールします。
Take the first WFE (SPWeb01) out of the load balancer and patch it with the 'STS' and 'WSS' packages.
Reboot the server when patching is done.
Return the server to rotation in the load balancer.
Take the second WFE (SPWeb02) out of the load balancer and patch it with the 'STS' and 'WSS' packages.
Reboot the server when patching is done.
Leave this server out of the load balancer until the entire upgrade is complete.注:
メンテナンス期間にアップグレードを実行しておらず、ファームに大量のロードがある場合は、PSCONFIG を実行する準備が整うまで、この WFE をネットワーク ロード バランサーに戻すことができます。
For each of SPApp, SPDCH, and SPSRCH in column 1, patch with 'STS' and 'WSS' packages.
Reboot them when they're done. (The work sent by SPWeb01 will fall on servers in column 2).
Now you repeat the 'patch and reboot' for column 2. For each of SPApp02, SPDCH02, and SPSRCH02 in column 2, patch with 'STS' and 'WSS' packages.
Reboot them when they're done. (As you can see, work sent by SPWeb01 will now fall on servers in column 1.)
フェーズ 2 - PSCONFIG のアップグレード
SharePoint Server ファーム内のすべてのノードにパッチがインストールされ、すべて再起動されています。 ビルド間のアップグレードを実行することをお勧めします。
注:
ZDP プロセスの過程で、Upgrade-SPContentdatabase を実行して、PSCONFIG の実行を完了するまでにかかる全体的な時間を短縮できます。 多数のデータベースがある場合はこれを検討するか、大規模なデータベースを選択してください。
負荷分散のローテーションが切れている WFE (SPWeb02) に戻り、SharePoint 管理シェルを開き、次の PSCONFIG コマンドを実行します。
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -installコマンドが完了した後、この WFE (SPWeb02) をロード バランサーに戻します。 このサーバーは完全にパッチが適用され、アップグレードされます。
ヒント
PSCONFIG プロセスの最後の手順で、ユーザー インターフェイス (UI) への更新プログラムが /layouts フォルダーからバージョン固有のフォルダーにコピーされることを確認します。 これは、side-by-side UI 更新の一環であり、アップグレードが完了して、新しいインターフェイスに切り替えるための準備が整うまで、ファームを参照するユーザーに対して 1 つの UI エクスペリエンスが提供されます。
サイド バイ サイド コピーが成功したことを確認するには、関連付けられているログ ファイルを確認します。 既定では、これは次の下にあります。
C:\program files\common files\Microsoft shared\web サーバー拡張機能\16\logs。 (ルート ドライブ文字は異なる場合があります)。
何らかの理由で PSCONFIG が UI ファイルを正常にコピーしなかった場合は、このコマンドを実行して Copy-SidebySideFiles を手動でコピーしてください。
Remove SPWeb01 from the load-balancer. > SharePoint 管理シェルを開き、同じ PSCONFIG コマンドを実行します。
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -installこの WEF (SPWeb01) をロード バランサーに戻します。 これで、完全にパッチが適用され、アップグレードされました。
両方の WFE にパッチが適用され、アップグレードされました。 ファームの残りの部分に進みますが、必要な Microsoft PowerShell コマンドを並列ではなく、一度に 1 つのサーバーで実行することを確認します。 つまり、列 1 のすべてに対して、一度に 1 つのサーバーでコマンドを実行します。 次に、列 2 のサーバーに対して、重複することなく、一度に 1 つのサーバーでコマンドを実行します。 最終的な目標は、稼働時間を維持することです。 PSCONFIG コマンドを順次実行することは、ZDP プロセスを完了する最も安全で予測可能な手段であるため、これを実行することにします。
列 1 (SPApp01、SPDCH01、SPSRCH01) の残りのすべてのサーバーについて、SharePoint 管理シェルで同じ PSCONFIG コマンドを実行します。 列 1 のすべてのサーバーがアップグレードされるまで、一度に 1 つずつ、各サーバーでこれを実行します。
重要
PSCONFIG を実行する前に、分散キャッシュを削除し、完了したら、分散キャッシュを追加し直してください。
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
列 2 (SPApp02、SPDCH02、SPSRCH02) の残りのすべてのサーバーに対して、SharePoint 管理シェルで同じ PSCONFIG コマンドを実行します。 列 2 のすべてのサーバーがアップグレードされるまで、一度に 1 つずつ、各サーバーでこれを実行します。
重要
PSCONFIG を実行する前に、分散キャッシュを削除し、完了したら、分散キャッシュを追加し直してください。
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install重要
すべてのサーバーで PSCONFIG が正常に実行されたら、以下の SharePoint Management Shell コマンドを実行して新しいユーザー インターフェイス ファイルに切り替え、サイド バイ サイド プロセスを完了してください。
$webapp = Get-SPWebApplication <webappURL>$webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
$webapp.WebService.update()
これで完了しましたので、使用中にダウンタイムが発生することなく、ファームが完全にアップグレードされました。
MinRole が役に立つ理由
ZDP について説明する際には、MinRole の概念も説明する必要があります。 MinRole は、SharePoint Server 2016、SharePoint Server 2019、および SharePoint Server サブスクリプション エディションのインストールのオプションです。 MinRole は、ファームの構成をフロントエンド (WFE)、アプリケーション サーバー (App)、分散キャッシュ (DCache)、Search、Custom (カスタム コードやサード パーティ製品の場合) などのロールに分割します。 この構成により、平均で次の 4 つのサーバーが提供されます - 2 つの WFE、2 つの App サーバー、2 つの DCache サーバー、2 つの Search サーバー。
既定では、WFE は低待機時間用に微調整され、App サーバーは高スループット用に微調整されます。 同様に、呼び出し元のボックスから呼び出しが離れる必要がないように検索コンポーネントをバンドルすると、Search サーバーがより効率的に機能します。 MinRole の最大のメリットの 1 つは、フォールト トレランスに組み込まれていることです。
高可用性が必要な理由
HA は SharePoint の中で幅広いトピックです。 このドキュメントなど、ホワイトペーパー全体とオンラインに関する記事があります。 概念を簡略化するために、少なくともこの記事では、ZDP (および MinRole) が Microsoft 365 の SharePoint で発生していることを理解してください。 Microsoft 365 の SharePoint では、仮想化されたサーバーに冗長性が組み込まれているため、同じ SharePoint ファームの同じサーバーの 2 つの役割が同じホストまたはラックに存在しません。 これにより、SharePoint のフォールト トレラント性が高くなります。 通信を高速化するためにラック間で共有ルーターまたはケーブル接続を使用して、独自のデータセンターにある異なるラック上の個別のホストで各 SharePoint Server ロールを 2 つずつ持つことで、同じ状況をモデル化できます。 また、テスト環境でセットアップされている各 SharePoint Server ロールに対して 2 つの物理サーバーだけを持つことも可能です (ファームの半分ごとに個別の電源バーを選択して、常にサーバーのセット間のルーティングが高速であり、可能な場合は、低待機時間のためにより広範なネットワーク トラフィックをバイパスするようにします)。
ここでの目標は、高可用性とフォールト トレランスです。 つまり、最も優先度が高いのは、ラックまたはサーバー間でロールを分離すること、各ロールを 2 つずつ持つこと、これらの 2 つの層の間で高速のネットワーク トラフィックを促進すること、データベース サーバーを監視して自動的にフェールオーバーするためのシステムをセットアップすることです。 SharePoint でサービスを手動でインストールする ('Custom' ロールを選択する場合など) という点では、ファーム内でサービスに冗長性があることが重要です。 たとえば、分散キャッシュをクラスター化すると、ファームには複数の WFE が存在するため、App サーバーと Search サーバーをペアでセットアップします。 このため、1 つのサーバーに深刻な問題が発生した場合は、他のサーバーがユーザー ロードを処理します。
ここで使用する例では、物理サーバーを描画して、概念を理解しやすくしています。 ZDP の計画を立てるときは、お客様自身の環境をどこに置いておくべきか (ラック名/番号と、各 SharePoint Server ロールが見つかるサーバー名を含む) を作成する必要があります。 これは、セットアップのサイズに関係なく、セットアップに潜んでいる、ロールの冗長性とフォールト トレランスの目標の違反を分離するための最も簡単な方法の 1 つです。