Windows Server のフェールオーバー クラスタリングを計画する

完了

Windows Server のフェールオーバー クラスターには、ハードウェアとソフトウェアに関してスタンドアロン サーバーより厳しい要件があります。 そのため、実装には追加の計画タスクが必要です。 実装の要件を調べて入念に計画することで、クラスターのプロビジョニング プロセスが効率化されます。

フェールオーバー クラスターの計画に関する考慮事項

Windows Server フェールオーバー クラスターの展開を計画するときは、最初に適切なワークロードを特定してから、そのワークロードに必要なリソースを検討します。

フェールオーバー クラスタリングのワークロード

フェールオーバー クラスタリングが常に適切であるとは限らないので、フェールオーバー クラスタリング テクノロジを実装する前に、クラスター化されたリソースとして実行でき、実行する必要のあるサービスとアプリケーションを、確認する必要があります。

フェールオーバー クラスタリングでは次ものがサポートされます。

  • 共有記憶域へのデータの格納をサポートするさまざまなステートフル アプリケーション。
  • 独自のネイティブ データ レプリケーション メカニズムを使用し、そのデータの 1 つの書き込み可能なコピーを保持しているホスト ステートフル アプリケーション。

どちらのシナリオも、Microsoft SQL Server などのデータベース管理システムでよく見られるものです。 フェールオーバー クラスタリングは、Hyper-V VM とそのオペレーティング システム内で実行されているステートフル アプリケーションにも適しています。

フェールオーバー クラスタリングの容量

フェールオーバー クラスターの容量を計画するときは、次のガイドラインを使用してください。

  • 障害が発生したノードからの高可用性ワークロードをバランスの取れた方法で分散させます。 フェールオーバー クラスター内のすべてのノードがアクティブになっている場合、障害が発生したノードからの高可用性サービスまたはアプリケーションを、1 つのノードに過負がかかり過ぎないよう、残っている他のノードにフェールオーバーする必要があります。
  • 別のノードで障害が発生したときに割り当てられる高可用性のサービスまたはアプリケーションを処理するのに十分な容量が、各ノードにあることを確認します。 この容量は、追加のリソース需要に十分対応できる必要があります。
  • クラスターのすべてのノードで、似た容量のハードウェアを使用します。 これにより、フェールオーバーの計画プロセスが簡単になり、残っているノードに均等に分散できます。
  • 容量計画を簡単にするため、スタンバイ サーバーの使用を検討します。 クラスター内のパッシブ ノードにより、複雑な容量計画の必要性を最小限に抑えることができます。

フェールオーバー クラスタリングの回復性

クラスター構成のすべてのコンポーネントを調べて、単一障害点を特定します。 冗長記憶域コントローラーのような構成、ミラーリングやパリティなどのマルチディスク構成、チーム化されたネットワーク アダプター、マルチパス ソフトウェアを使用して、単一障害点を解決します。 これらのソリューションにより、1 つのデバイスの障害がフェールオーバー クラスターの安定性に悪影響を与える可能性が少なくなります。

注意

一般に、サーバー ハードウェアには、電源の冗長性を提供する複数の電源装置や、Redundant Array of Independent Disks (RAID) コントローラーが組み込まれています。

ハードウェアに関する一般的な推奨事項と要件

フェールオーバー クラスターは、次のハードウェア ガイドラインに準拠している必要があります。

  • ハードウェアは、Windows Server 用に認定されている必要があります。
  • 各フェールオーバー クラスター ノードには、同一または類似のハードウェアを設置する必要があります。
  • 各ノードでは、同じプロセッサ アーキテクチャと、同じプロセッサ ファミリが実行されている必要があります。
  • Serial Attached SCSI (SAS) またはファイバー チャネル記憶域接続を使用する場合、クラスター記憶域専用の大容量記憶装置コントローラーは、すべてのクラスター化されたサーバーで同一のものにし、同じバージョンのファームウェアを使用する必要があります。
  • インターネット SCSI (iSCSI) 記憶域接続を使用する場合は、クラスター化された各サーバーで、クラスター記憶域専用の 1 つ以上のネットワーク アダプターまたはホスト バス アダプターを使用する必要があります。 iSCSI 記憶域ターゲットへの接続に使用するネットワーク アダプターは、クラスター化されたすべてのサーバーで同一にする必要があります。

重要

iSCSI 記憶域接続に使用するネットワークを、記憶域以外のネットワーク通信に使用しないでください。

ネットワーク要件

一般的なハードウェア要件に加えて、次のようなネットワーク固有の要件があります。

  • 各ノードのネットワーク アダプターは、同一のもので、速度、二重化、フロー制御の機能が同じである必要があります。
  • クラスター ネットワーク内のネットワーク アダプターでは、同じ IP アドレス割り当て方法 (静的、または DHCP を使用する動的) が使用されている必要があります。
  • ネットワーク インフラストラクチャの他の部分へルーティングされないプライベート ネットワークがある場合は、それらの各プライベート ネットワークで一意のサブネットが使用されていることを確認します。 これは、各ネットワーク アダプターに固有の IP アドレスを割り当てる場合であっても必要です。

インフラストラクチャの要件

フェールオーバー クラスターは、インフラストラクチャ サービスに依存する場合があります。 Windows Server では、複数のドメイン クラスターとワークグループ クラスターがサポートされています。

注意

複数のドメイン クラスターとワークグループ クラスターを展開することはできますが、Hyper-V クラスターまたはファイル サーバー クラスターにはこの構成を使用しないでください。

各ノードには、Windows Server の同じ機能と役割をインストールする必要があります。 クラスターのノードの構成に一貫性がないと、不安定になり、パフォーマンスの問題が発生する可能性があります。 また、Active Directory Domain Services (AD DS) には独自のフォールト トレランス メカニズムがあるため、クラスターのどのノードにも AD DS の役割をインストールしないでください。

フェールオーバー クラスターには、次の表で説明するネットワーク インフラストラクチャ要素が必要です。

要素 説明
DNS クラスター内のサーバーでは、名前解決にドメイン ネーム システム (DNS) が使用されます。
ドメインのメンバーシップ Windows Server フェールオーバー クラスターのクラスター ノードは、同じドメインのメンバーである必要はありません。
管理アカウント 初めてクラスターを作成するとき、またはクラスターにサーバーを追加するときは、そのクラスター内のすべてのサーバーに対する管理特権を持つアカウントでドメインにサインインする必要があります。

重要

管理アカウントは、各クラスター ノードでローカルの Administrators グループのメンバーになっている場合は、Domain Admins グループのメンバーである必要はありません。 ただし、そのアカウントが Domain Admins グループのメンバーでない場合は、クラスター ノードがホストされているドメインでのコンピューター オブジェクト作成アクセス許可を持っている必要があります。

注意

Windows Server 2016 以降では、このアクセス許可の割り当てを必要としない、いわゆる "デタッチされたクラスター" を作成できます。

Windows Server では、クラスター サービス アカウントを持っている必要はありません。 代わりに、クラスター サービスは、サービスに必要な特定のアクセス許可と資格情報が提供される特別なコンテキストで自動的に実行されます。 フェールオーバー クラスターが作成され、対応するコンピューター オブジェクトが AD DS 内に作成されるとき、そのオブジェクトは誤って削除されないように構成されます。 さらに、クラスター ネットワーク名リソースに追加される正常性チェック ロジックにより、ネットワーク名リソースを表すコンピューター オブジェクトの正常性とプロパティが定期的に確認されます。

フェールオーバー クラスターの実装に関するソフトウェアの要件

ベスト プラクティスとして、各クラスター ノードでは、同じエディションの Windows Server (Windows Server 2025 Standard または Windows Server 2025 Datacenter) が実行されている必要があります。 ノードには、同じソフトウェア更新プログラムがインストールされている必要があります。 クラスター ノードとして Windows Server 2025 の Server Core のインストールを使用することもできますが、それは展開するワークロードとサーバーの役割に依存します。