2ノードのフェイルオーバークラスターは、最小限のサーバー構成で高い可用性を実現できるため、多くの企業や組織で採用されています。システム障害時でも安定してサービスを提供するためには、各ノード間やクラスター自体が利用するIPアドレスの管理がとても重要です。適切なIPアドレス設計を行うことで、障害切り替え(フェイルオーバー)が円滑に進み、安定性と保守性を高めることができます。
フェイルオーバークラスター構築時に必要な基本IPアドレス
2ノード構成のフェイルオーバークラスターでは、一般的に以下のIPアドレスを割り当てるケースが多くみられます。それぞれの役割を明確にしておくことで、トラブルシューティングの際にも役立ちます。
1. 各ノードのIPアドレス
2台のノードそれぞれに、管理やアプリケーション通信に利用するIPアドレスを割り当てます。たとえば以下のように、サブネット192.168.0.xを利用するケースを考えてみましょう。
- ノードA: 192.168.0.10
- ノードB: 192.168.0.11
それぞれに通常のネットワークインターフェースを用意し、ゲートウェイやDNSを設定しておくことで、他のネットワーク機器やクライアントPCからアクセスできるようにしておきます。
2. クラスター用の仮想IPアドレス
クラスター全体を論理的に識別するためのIPアドレスです。クライアントやサービスがクラスターにアクセスする際には、この仮想IPアドレスを利用します。ノードどちらかがダウンしても、このアドレスを通じてサービスを提供し続けられるため、高可用性を実現するうえで欠かせない存在です。
例: 192.168.0.20
3. ハートビート用ネットワークのIPアドレス
ノード間の生死監視(ハートビート)に用いるIPアドレスです。ハートビート用に専用ネットワークを用意する場合は、LANスイッチを冗長構成にする、もしくはクロスケーブル(ダイレクト接続)でつなぐなど、障害が起きにくい設計を心がけましょう。
例: 10.10.10.1 (ノードA), 10.10.10.2 (ノードB)
4. バックアップ用ネットワークのIPアドレス
バックアップトラフィックが業務ネットワーク帯を圧迫するのを避けるため、専用のネットワークを用意する場合があります。大容量のデータ転送が行われても、ほかの通信帯域に影響を与えにくくなるメリットがあります。
例: 172.16.0.10 (ノードA), 172.16.0.11 (ノードB)
追加で検討すべきネットワーク構成
単純に上記の4つだけで済む場合もあれば、冗長化をさらに強化したい場合や管理効率を高めたい場合に、追加でIPアドレスが必要になることがあります。
管理用ネットワーク
システム管理者のみが接続する、セキュアな管理用ネットワークを別途設けるケースです。運用管理用ツールや監視ツールへのアクセスなど、外部からのアクセスを制限しつつ安全に行うことができます。
例: 10.20.20.10 (ノードA), 10.20.20.11 (ノードB)
NICチーミング(アダプター冗長化)
物理NICのリンク障害対策として、NICチーミングを構成する場合があります。複数の物理NICを1つの論理インターフェースとして扱うことで、可用性とパフォーマンスを高める設計です。チーミング構成を行う場合、チームに割り当てるIPアドレスや、チーミング前後で設定が異なる点などを事前に把握しておきましょう。
複数サブネットへのまたがり
拠点間でクラスターを組む場合など、複数のサブネットをまたぐ構成であれば、それぞれのサブネットにIPアドレスを用意する必要があります。サブネットの切り分け方によっては、クラスターに所属するノードが異なる拠点に存在し、それぞれが違うゲートウェイを利用するケースも考えられます。
例: 地理的分散クラスター
- 東京拠点サブネット: 192.168.100.x
- 大阪拠点サブネット: 192.168.200.x
- クラスターネットワークとしての統合サブネット: 10.10.10.x
このような場合、フェイルオーバークラスター自体がサイト間でどのようにIPを切り替えるか、DNSの登録をどのように行うかなど、詳細な設計が必要となります。
Windows Serverフェイルオーバークラスターにおける具体的な構築例
ここでは、Windows Serverで2ノードのフェイルオーバークラスターを構成する例を挙げて、各種IPアドレスをどのように設定するかのイメージを示します。
基本構成例
下記のようにネットワークを3セグメントに分割します。
- 業務用ネットワーク(クライアント通信など)
- ハートビート用ネットワーク(ノード間通信)
- バックアップ用ネットワーク(大容量データ転送用)
| ノード | 業務用NW IP | ハートビートNW IP | バックアップNW IP |
|---|---|---|---|
| Node A | 192.168.0.10 | 10.10.10.1 | 172.16.0.10 |
| Node B | 192.168.0.11 | 10.10.10.2 | 172.16.0.11 |
| Cluster Virtual IP | 192.168.0.20 | – | – |
PowerShellでのクラスター作成例
Windows Serverでは、フェイルオーバークラスターの作成や管理をPowerShellで行えます。以下は簡易的な例です。
# クラスター機能のインストール
Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -ComputerName "NodeA","NodeB"
# クラスターの準備チェック
Test-Cluster -Node "NodeA","NodeB"
# クラスターの作成
New-Cluster -Name "MyCluster" `
-Node "NodeA","NodeB" `
-StaticAddress 192.168.0.20
# クラスターのネットワーク設定例
Get-ClusterNetwork | Format-Table Name, Address, Role, Metric, AutoMetric上記のコマンドにより、クラスターネーム「MyCluster」を構築し、仮想IPとして192.168.0.20を割り当てます。クラスター作成後にハートビートネットワークやバックアップネットワークなどの役割が自動判定されるケースがありますが、必要に応じて手動で設定・修正も可能です。
ネットワーク設計時の注意点とベストプラクティス
フェイルオーバークラスターにおいてネットワークが複雑化しがちなのは、複数の専用ネットワークを用いるからです。どのようにトラフィックを振り分けるのか、どこを監視対象にするのかなど、あらかじめ整理しておきましょう。
1. ネットワーク冗長化の重要性
ハートビート用の通信が途絶えると、クラスターノード同士が「相手ノードが落ちている」と誤認識し、フェイルオーバーが誤作動する恐れがあります。NICチーミングや複数経路の確保などで冗長化を図ると安心です。
2. VLANの適切な利用
1つの物理スイッチで複数の論理ネットワークを扱う場合はVLANの設定が必須です。トラフィックの混在を避けつつ、セキュリティも高められます。ただし設定ミスでハートビートと業務用の通信が同一ブロードキャストドメインに混在しないように注意が必要です。
3. DNSおよび名前解決の整合性
クラスターIPや各ノードのIPアドレスをDNSに登録するとき、フェイルオーバー後も名前解決が正常に行えるようにTTL(生存期間)の設定や動的更新の仕組みを確認してください。DNS情報が古いまま残り、切り替え後にクライアントが到達できないことがないようにしましょう。
4. ファイアウォールおよびセキュリティポリシーの調整
クラスターノード間の通信がファイアウォールに遮断されないよう、必要なポートやプロトコルを許可する設定を行いましょう。ハートビート通信やクラスターコントロール通信などがブロックされると、正常な運用ができません。
IPアドレス設計のまとめ
最終的に必要なIPアドレス数は、環境や要件によって変動します。最低限、以下を確保すれば2ノードクラスタの基本動作は可能です。
- 各ノードのIP(1ノードにつき1つ以上)
- クラスター用仮想IP
- ハートビート用IP
- 必要に応じてバックアップ用IP
しかし実際には、冗長化やセキュリティ対策の観点から、管理用やNICチーミング用に追加IPを確保する場面が多くあります。要件定義段階でしっかりと将来の運用も考慮に入れて、余裕をもったIPアドレス設計を行いましょう。
IPアドレス設計例(最小構成)
| 目的 | IP割り当て数 | 備考 |
|---|---|---|
| ノード用 | 2(各ノード1つずつ) | 業務用と管理を兼用 |
| クラスター仮想IP | 1 | クライアント側からのアクセス先 |
| ハートビート用 | 1 or 2(ノードごと) | 専用ネットワークか否かで変動 |
| バックアップ用 | 1 or 2(ノードごと) | 大容量トラフィックを分離 |
クラスタ構築後の運用ポイント
ここまでIPアドレスの話を中心にしてきましたが、実運用ではネットワークだけでなく、クラスタ上で動作するアプリケーションやストレージの監視・保守も求められます。
1. 監視とアラート
- クラスタログ(Event Viewer、Failover Cluster Manager)の定期チェック
- ネットワーク遅延やパケットロスを監視するためのツール導入
- リソース不足やディスク容量のアラートメール設定
2. 定期的なフェイルオーバーテスト
本番環境で予期せぬ障害が発生した際に、うまくフェイルオーバーできなければ意味がありません。定期的にテストを行い、切り替えに要する時間やサービスへの影響範囲を把握しておきましょう。
3. Windows Update適用時の順序
フェイルオーバークラスタでは、Windows Updateやソフトウェアパッチの適用順序に注意が必要です。先にNode Aをメンテナンスモードにしてアップデートを適用、次にNode BにフェイルオーバーしてからNode Bをアップデートする、という手順で行えば、サービスのダウンタイムを最小限に抑えられます。
4. バックアップと復旧手順の明確化
ノード間のバックアップが正しく動いているか、復旧手順に漏れがないかを常に確認しておくことは大切です。クラスタ構成のバックアップ(構成情報やレジストリ)に加えて、各種アプリケーションデータのバックアップも確実に取得しておきましょう。
トラブルシューティングのポイント
複数のネットワークを駆使するフェイルオーバークラスターでは、トラブルの原因がネットワークなのかストレージなのか、それともOSの問題なのかを切り分けるのが難しい場合もあります。以下のポイントを意識しておくと、問題解決がスムーズになります。
1. まずはログの確認
クラスタログやイベントビューアにエラーや警告が記録されていることが多いです。特にMicrosoft-Windows-FailoverClustering関連のイベントIDや、ネットワークインターフェースのイベントログをチェックすることで、問題の手掛かりを得られます。
2. ネットワーク疎通確認
pingでノード間通信を確認Test-Connectionコマンドレット(PowerShell)でパケットロスやRTT値を把握- ネットワークアダプタの有効化・無効化や、スイッチポート設定を再確認
3. クラスタ検証ウィザード(Test-Cluster)の活用
構築後でもTest-Clusterを実行すると、構成に問題がないかを検証できます。特にネットワーク関連の設定ミスは早期に発見できるので、トラブル発生時には積極的に活用しましょう。
4. ストレージ関連のエラー
クラスターによっては共有ストレージが必須の構成もあります。その場合、ディスクのパス設定やクォーラム構成に不備があると、ノードがオンラインになれないトラブルが起きがちです。ストレージの接続設定やドライバの更新状況も合わせて確認します。
まとめ: IP設計と運用の両面を考慮して安定稼働を実現
2ノードのフェイルオーバークラスターを構築する際は、最低限のIPアドレスとして「各ノード用」「クラスター仮想IP」「ハートビート」「バックアップ(必要に応じて)」を用意しましょう。さらに、管理用やNICチーミングなどの追加ネットワークを取り入れる場合は、それぞれに専用のIPアドレスが必要となります。
運用面では、ハートビート用通信の安定確保、ネットワークやストレージの冗長化、適切な監視と定期テストが大きな鍵を握ります。事前に綿密な設計をしておくことで、本番運用時のトラブルリスクを最小化できるでしょう。
可用性の高いシステムを実現するためにも、IPアドレスの割り当てをはじめとするネットワーク設計は、システム規模や将来的な拡張性を考慮してしっかり行うことが肝要です。
コメント