クラスター対応更新の要件とベスト プラクティス

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Azure Stack HCI、バージョン 21H2 および 20H2

このセクションでは、クラスター対応更新 (CAU) を使用して Windows Server を実行しているフェールオーバー クラスターに更新プログラムを適用するために必要な要件と依存関係について説明します。

フェールオーバー クラスタリング機能とフェールオーバー クラスタリング ツールのインストール

CAU を利用するには、フェールオーバー クラスタリング機能とフェールオーバー クラスタリング ツールをインストールする必要があります。 フェールオーバー クラスタリング ツールには CAU ツール (clusterawareupdating.dll)、フェールオーバー クラスタリング コマンドレット、CAU 操作に必要なその他のコンポーネントが含まれています。 フェールオーバー クラスタリング機能のインストール手順については、「 フェールオーバー クラスタリング機能とツールのインストール」をご覧ください。

フェールオーバー クラスタリング ツールの厳密なインストール要件は、CAU がフェールオーバー クラスター上で (自己更新モードを利用して) クラスター化された役割として更新を調整するのか、リモート コンピューターから更新を調整するのかにより異なります。 CAU の自己更新モードを利用する場合、追加として、CAU ツールを利用し、フェールオーバー クラスターに CAU のクラスター化された役割をインストールする必要があります。

次の表は、2 つの CAU 更新モードの CAU 機能インストール要件をまとめたものです。

管理者アカウントの取得

CAU 機能を使用するには、次の管理者要件が必要です。

• CAU ユーザー インターフェイス (UI) またはクラスター対応更新コマンドレットを利用して更新アクションをプレビューまたは適用するには、すべてのクラスター ノードにローカル管理者権限とアクセス許可を持つドメイン アカウントを使用する必要があります。 アカウントに一部のノードに対する権限がない場合、アクションを実行するとき必要な資格情報を入力するようにクラスター対応更新ウィンドウで求められます。 クラスター対応更新コマンドレットを使用するために、コマンドレット パラメーターとして必要な資格情報を入力できます。

• クラスター ノードにローカル管理者権限とアクセス許可を持たないアカウントでサインインしているとき、リモート更新モードで CAU を使用する場合、Update Coordinator コンピューターでローカル管理者アカウントを利用し、または認証後にクライアントを偽装ユーザー権限を持つアカウントを利用し、管理者として CAU ツールを実行する必要があります。

• CAU ベスト プラクティス アナライザーを実行するには、クラスター ノードに対して管理特権を持ち、Test-CauSetup コマンドレットを実行するか、クラスター対応更新ウィンドウを利用してクラスター更新の準備を分析する際に使用するコンピューターに対してローカル管理特権を持つアカウントを使用する必要があります。 詳細は、「クラスター更新の準備のテスト」をご覧ください。

クラスター構成の検証

次は、CAU による更新をサポートするためのフェールオーバー クラスターの一般要件です。 ノードのリモート管理の追加構成要件はこのトピックの後半の「リモート管理のためのノードの構成」にあります。

• クラスターの定足数が確保されるだけ十分な数のクラスター ノードがオンラインになっている必要があります。

• すべてのクラスター ノードが同じ Active Directory ドメインにある必要があります。

• クラスター名は DNS を利用し、ネットワーク上で解決する必要があります。

• CAU がリモート更新モードで使用されている場合、Update Coordinator コンピューターがフェールオーバー クラスター ノードにネットワークで接続している必要があります。また、フェールオーバー クラスターと同じ Active Directory ドメインに入っている必要があります。

• すべてのクラスター ノードでクラスター サービスを実行している必要があります。 既定では、このサービスはすべてのクラスター ノードにインストールされ、自動的に開始するように構成されています。

• CAU 更新実行中に PowerShell の更新前スクリプトまたは更新後スクリプトを使用するには、スクリプトがすべてのクラスター ノードにインストールされていること、またはスクリプトがたとえば可用性の高いネットワーク ファイル共有ですべてのノードにアクセスできることを確認します。 スクリプトがネットワーク ファイル共有に保存される場合、Everyone グループの読み取りアクセスのフォルダーを構成します。

リモート管理のノードの構成

クラスター対応更新を使用するには、クラスターのすべてのノードがリモート管理用に構成されている必要があります。 既定では、リモート管理用にノードを構成するために実行する必要がある唯一のタスクは、自動再起動を許可するファイアウォール規則を有効にすることです。

次の表は、環境が既定の設定と異なる場合の、完全なリモート管理要件の一覧です。

これらの要件は、「フェールオーバー クラスタリング機能とツールのインストール」のイントール要件と本トピックの前のセクションで説明した一般的なクラスタリング要件に追加されるものです。

自動再起動を許可するファイアウォール規則の有効化

更新の適用後に自動再起動を有効にするには (更新のインストールに再起動が必要な場合)、Windows ファイアウォールまたはマイクロソフト以外のファイアウォールがクラスター ノードで使用されている場合、次のトラフィックを許可するファイアウォール規則をノードごとに有効にする必要があります。

• プロトコル:TCP

• 方向: 受信

• プログラム: wininit.exe

• ポート: RPC 動的ポート

• プロファイル: ドメイン

Windows ファイアウォールをクラスター ノードで使用する場合、クラスター ノードごとに [リモート シャットダウン] Windows ファイアウォール規則グループを有効にします。 クラスター対応更新ウィンドウを使用して、更新プログラムを適用し、自己更新オプションを構成すると、リモート シャットダウン Windows ファイアウォール規則グループが各クラスター ノードで自動的に有効になります。

リモート シャットダウン ファイアウォール規則グループは、–EnableFirewallRules パラメーターを指定して次の CAU コマンドレットを実行しても有効になります: Add-CauClusterRole、Invoke-CauRun、SetCauClusterRole。

次の PowerShell の例では、クラスター ノードで自動再起動を有効にする他の方法を示します。

Set-NetFirewallRule -Group "@firewallapi.dll,-36751" -Profile Domain -Enabled true

Windows Management Instrumentation (WMI) を有効にする

Windows Management Instrumentation (WMI) を利用し、すべてのクラスター ノードのリモート管理を構成する必要があります。 この機能は、既定では有効になっています。

リモート管理を手動で有効にするには、次のように操作します。

1. サービス コンソールで、[Windows リモート管理] サービスを開始し、起動タイプを [自動] に設定します。

2. Set-WSManQuickConfig コマンドレットを実行するか、管理者特権でのコマンド プロンプトから次のコマンドを実行します。

   winrm quickconfig -q
   

WMI リモート処理をサポートするには、クラスター ノードで Windows ファイアウォールが使用される場合、[Windows リモート管理 (HTTP 受信)] の受信ファイアウォール規則をノードごとに有効にする必要があります。 既定では、この規則は有効になっています。

Windows PowerShell と Windows PowerShell リモート処理の有効化

自己更新モードと、リモート更新モードの特定の CAU 機能を有効にするには、すべてのクラスター ノードでリモート コマンドを実行するために PowerShell をインストールし、有効にする必要があります。 PowerShell は既定でインストールされ、リモート処理が有効になります。

PowerShell のリモート処理を有効にするには、次のいずれかの方法を使用します。

• Enable-PSRemoting コマンドレットを実行します。

• Windows リモート管理 (WinRM) にドメイン レベルのグループ ポリシー設定を構成します。

PowerShell のリモート処理の有効化について詳しくは、リモート要件に関する記事をご覧ください。

.NET Framework 4.6 または 4.5 をインストールする

自己更新モードと、リモート更新モードの特定の CAU 機能を有効にするには、すべてのクラスター ノードに NET Framework 4.6 または .NET Framework 4.5 (Windows Server 2012 R2 上) をインストールする必要があります。 .NET Framework は既定でインストールされます。

まだインストールされていない場合に PowerShell を使用して .NET Framework 4.6 (または 4.5) をインストールするには、次のコマンドを使用します。

Install-WindowsFeature -Name NET-Framework-45-Core

クラスター対応更新の使用に関するベスト プラクティスの推奨事項

マイクロソフト更新適用の推奨事項

CAU を使用し、クラスターで既定の Microsoft.WindowsUpdatePlugin プラグインによる更新の適用を始めるとき、他の方法を利用してマイクロソフトのソフトウェア更新をクラスター ノードにインストールするのはやめることをお勧めします。

次のガイドラインに従うことをお勧めします。

• 最適な結果を得るために、たとえば、コントロール パネルの自動更新設定やグループ ポリシーを利用して構成される設定を利用し、クラスター ノードの自動更新設定を無効にすることをお勧めします。

  注意事項

  クラスター ノードの更新の自動インストールが CAU による更新のインストールに干渉し、CAU にエラーが発生することがあります。

  必要であれば、次の自動更新設定が CAU と共存します。管理者が更新インストールのタイミングを制御できるためです。

  • 更新のダウンロード前に通知するための設定とインストール前に通知するための設定

  • 更新を自動的にダウンロードするための設定とインストール前に通知するための設定

  ただし、自動更新が CAU 更新実行と同時に更新をダウンロードする場合、更新実行の完了に時間がかかることがあります。

• 自動的に (固定されたタイム スケジュールで) 更新プログラムをクラスター ノードに適用するように Windows Server Update Services (WSUS) などの更新システムを構成しないでください。

• WSUS サーバー、Windows 更新、マイクロソフト更新など、同じ更新元を利用するように、すべてのクラスター ノードを等しく構成する必要があります。

• 構成管理システムを使用してネットワーク上のコンピューターにソフトウェア更新を適用する場合は、必要な更新または自動更新からクラスター ノードを除外してください。 構成管理システムの例として、Microsoft Endpoint Configuration Manager や Microsoft System Center Virtual Machine Manager 2008 があります。

• 内部のソフトウェア配布サーバー (WSUS サーバーなど) を使用して更新プログラムを保持および展開する場合、クラスター ノードに対して承認された更新プログラムがそのサーバーで正しく識別されるようにしてください。

支店シナリオのマイクロソフト更新適用

特定の支店シナリオで Microsoft Update または Windows Update からクラスター ノードに Microsoft 更新プログラムをダウンロードするには、各ノードでローカル システム アカウント用のプロキシ設定を構成することが必要になる場合があります。 たとえば、支店のクラスターがローカル プロキシ サーバーを利用し、Microsoft Update または Windows Update にアクセスして更新をダウンロードする場合にこの作業が必要になります。

必要に応じて、ノードごとに WinHTTP プロキシ設定を変更し、ローカル プロキシ サーバーを指定し、ローカル アドレス例外 (つまり、ローカル アドレスのバイパス リスト) を構成します。 その場合、管理者特権のコマンド プロンプトでクラスター ノードごとに次のコマンドを実行できます。

netsh winhttp set proxy <ProxyServerFQDN >:<port> "<local>"

<ProxyServerFQDN> はプロキシ サーバーの完全修飾ドメイン名で、<port> は通信に使用されるポートです (通常はポート 443)。

たとえば、ローカル システム アカウントの WinHTTP プロキシ設定を構成し、プロキシ サーバー MyProxy.CONTOSO.com、ポート 443、ローカル アドレス例外を指定する場合は、次のコマンドを入力します。

netsh winhttp set proxy MyProxy.CONTOSO.com:443 "<local>"

Microsoft.HotfixPlugin を使用する場合の推奨事項

• 修正プログラムのルート フォルダーと構成ファイルにアクセス許可を設定し、これらのファイルの保管に使用されるコンピューターに対してローカル管理者にのみ書き込みアクセスを許可することをお勧めします。 それにより、無許可のユーザーがこれらのファイルを改ざんし、修正プログラムの適用時にフェールオーバー クラスターの機能を損なうような事態を防止できます。

• 修正プログラムのルート フォルダーにアクセスするために使用されるサーバー メッセージ ブロック (SMB) 接続のデータ完全性を維持するために、 SMB 共有フォルダーに SMB 暗号化を構成できる場合、それを構成する必要があります。 Microsoft.HotfixPlugin を利用するには、SMB 接続のデータ完全性を維持するように SMB 署名または SMB 暗号化を構成する必要があります。

  詳しくは、修正プログラムのルート フォルダーと構成ファイルへのアクセスの制限に関する記事をご覧ください。

その他の推奨事項

• 同じ時間にスケジュールされる可能性がある CAU 更新実行を邪魔しないように、スケジュールされている保守管理時間帯にクラスター名オブジェクトと仮想コンピューター オブジェクトにパスワード変更をスケジュールしないでください。

• 無許可のユーザーがこれらのファイルを改ざんしないように、ネットワーク共有フォルダーに保存される更新前スクリプトと更新後スクリプトに適切なアクセス許可を設定する必要があります。

• 自己更新モードで CAU を設定するには、CAU のクラスター化された役割の仮想コンピューター オブジェクト (VCO) を Active Directory で作成する必要があります。 CAU は、フェールオーバー クラスターに十分なアクセス許可があれば、CAU のクラスター化された役割が追加された時点でこのオブジェクトを自動的に作成できます。 ただし、一部の組織ではセキュリティ ポリシーにより、Active Directory にオブジェクトを事前登録する必要があります。 この手順については、「 クラスター化された役割のアカウントを事前登録するための手順」をご覧ください。

• IT 組織内で同様に更新する必要があるフェールオーバー クラスター全体に更新実行設定を保存し、再利用するために、更新実行プロファイルを作成できます。 また、更新モードにもよりますが、すべてのリモート Update Coordinator コンピューターまたはフェールオーバー クラスターにアクセスできるファイル共有に更新実行プロファイルを保存し、管理できます。 詳しくは、CAU の詳細オプションと更新実行プロファイルに関する記事をご覧ください。

クラスター更新の準備のテスト

CAU ベスト プラクティス アナライザー (BPA) モデルを実行すれば、フェールオーバー クラスターとネットワーク環境が、CAU でソフトウェア更新プログラムを適用するための要件の多くを満たしているかどうかをテストできます。 テストの多くでは、既定のプラグインである Microsoft.WindowsUpdatePlugin を利用し、マイクロソフト更新を適用する準備が環境で整っているかどうかが確認されます。

BPA は次の 2 通りの方法で実行できます。

1. CAU コンソールで [クラスター更新の準備の分析] を選択します。 BPA による準備状況のテストが完了すると、テスト レポートが表示されます。 クラスター ノードで問題が検出された場合、是正措置をとれるように、具体的な問題と問題が発生したノードが特定されます。 テストの完了には数分かかることがあります。

2. Test-CauSetup コマンドレットを実行します。 このコマンドレットは、Windows PowerShell 用のフェールオーバー クラスタリング モジュール (フェールオーバー クラスタリング ツールの一部) がインストールされているローカルまたはリモートのコンピューターで実行できます。 フェールオーバー クラスターのノードでもコマンドレットを実行できます。

クラスター更新の準備のテスト

次の表は、クラスター更新の準備のテスト、一部の共通問題、解消手順についてまとめたものです。

その他の参照情報

• クラスター対応更新の概要