銀行などのミッションクリティカルな環境では、サーバーに万全の冗長性を持たせるための構成が強く求められます。特にActive Directoryのような基盤サービスを支えるフェイルオーバークラスターを設計する際には、ストレージの選定は大きな分岐点になります。ストレージが原因でサービス継続が妨げられると、ビジネスに重大な影響を与えかねません。この記事では、フェイルオーバークラスターにおけるストレージ選択の理由や注意点を掘り下げ、最適な運用を実現するための具体的なヒントをご紹介します。クラウドとのハイブリッド構成やローカルストレージ活用の難しさなど、実際の運用を想定した解説も含め、トラブルを未然に防ぐための知識を幅広く提供します。
フェイルオーバークラスターにおけるストレージ選択の重要性
フェイルオーバークラスター（以下、クラスタとも呼びます）は、複数のノード（サーバー）で構成され、特定の役割（役務）を継続的に提供する仕組みです。どれだけ優れたハードウェアを用意しても、ストレージがボトルネックとなったり、データ共有の仕組みが不完全であったりすると、クラスタとしてのメリットを活かしきれません。ここでは、ストレージ選択がなぜ重要なのかを確認しましょう。
データの一貫性を保持する
クラスタのノードが複数あっても、そこに格納されるデータが分散・独立してしまえば、高可用性を実現するうえでの整合性を維持できません。つまり「どのノードからでも、同一のデータに対して、必要なタイミングで読み書きが行える」ことが大前提となります。フェイルオーバーによってアクティブノードが切り替わった時、データを継続して処理できることが肝心です。
障害時の自動切り替え
クラスタのノードの1台がダウンしても、別のノードが素早くサービスを引き継ぐことで、ダウンタイムを最小化できます。しかし、データが局所的に存在する状態であれば、引き継ぎ先ノードが必要なデータを即時に参照できず、サービス停止が長引くことになります。そのため、共有ストレージのように複数ノードから常時アクセス可能な構成が理想です。
共有ストレージのメリットと仕組み
フェイルオーバークラスターで一般的に推奨されるのが、共有ストレージを活用する方法です。Windows Serverでは「Cluster Shared Volumes(CSV)」という仕組みが標準で提供されており、多くのシーンで導入実績があります。
なぜ共有ストレージが推奨されるのか
共有ストレージを用いる最大の理由は、クラスタ内のどのノードも同じストレージ領域を参照できるからです。クラスタサービスのプロセスがどのサーバー上で動いていようとも、データを同一に扱えることで、障害発生時でもシームレスな切り替えが可能となります。加えて、下記のようなメリットも期待できます。
- 運用管理の容易化
共有ストレージであれば、バックアップポリシーやスナップショットの運用を一元化しやすいです。複数ノードに個別のバックアップソリューションを組む必要がないため、管理工数を大幅に削減できます。 - 高いスケーラビリティ
サーバーの台数やディスクの容量が増減しても、共有ストレージのスケールアップ・スケールアウトにより対応しやすいです。複数の物理ディスクをまとめて一つの大きな仮想ディスクとして扱える柔軟性も高可用性に寄与します。 - 冗長化のシンプル化
共有ストレージ自体をRAID構成や複数コントローラによる冗長化で高信頼化することで、データ損失リスクを最小限に抑えられます。クラスタのノード側に複雑なディスクミラーを設定する必要がなくなる点も利点の一つです。
Cluster Shared Volumes(CSV)の仕組み
CSVはWindows Serverのフェイルオーバークラスタ機能の一部として提供されている機能です。各クラスタノードはCSV上のディスクを同時に読み書きできるため、クラスター化された役割がどのノードで動作していても、ストレージへのアクセスが一貫して行えます。CSVを利用する具体的なメリットは以下の通りです。
- NTFSまたはReFSをベースにした運用が可能
共有ディスクを一つの論理ボリュームとして扱いつつ、通常のファイルシステムとしてアクセスできます。クラスタ外のソフトウェアとも互換性を保ちやすい点が魅力です。 - Live Migrationとの相性の良さ
仮想マシンをLive Migrationする際、ディスクがクラスタノード間でスムーズに移行されるため、運用中のサービス停止がほとんど発生しません。大規模環境で特に威力を発揮します。 - バックアップの柔軟性
VMごとのバックアップや複数ボリュームの同時バックアップがやりやすいので、大量の仮想マシンを抱える環境でも運用の手間を軽減できます。
ローカルストレージ運用のリスク
一部のケースでは、コスト削減のためにローカルストレージのみを使ってクラスタを構成しようとする動きが見られます。確かに小規模なテスト環境やPoC（概念実証）フェーズではローカルストレージだけでも最小限のクラスタ機能を試すことができます。しかし、本番環境や銀行などの重要インフラを運用する場合、ローカルストレージ構成には大きなリスクが存在します。
障害時のデータアクセス不可
ローカルストレージは、そのサーバー(ノード)に直結しています。仮にノードがダウンしたとき、ローカルディスク上のデータは他のノードから直接参照できません。このため、フェイルオーバーによる可用性を確保できず、サービス停止が長引く恐れがあります。
ノード間のデータ同期にコストがかかる
クラスタノード間でデータを同期させるには、サードパーティ製のミラーリングソフトや分散ファイルシステムを別途導入する必要が出てきます。これらを導入しても、結局は複雑な構成管理とパフォーマンス低下のリスクがつきまといます。
データの整合性リスク
アクティブノードが書き込んだ最新データを、パッシブノードが参照する際に整合性を確保できるかは大きな課題です。タイミングによっては古いデータを参照し、システム全体の信頼性を大きく損ねるリスクがあります。
クラウドとのハイブリッド構成での考慮ポイント
近年はオンプレミスのリソースだけでなく、Microsoft Azureや他のクラウドサービスと連携したハイブリッドクラウド構成が一般的になってきました。Azure上にバックアップのActive Directoryを配置し、オンプレミス環境がダウンした際にAzure側で冗長化を担うケースも多いでしょう。
オンプレミスのメイン環境は共有ストレージが基本
オンプレミスのメイン環境においては、高速かつ安定した共有ストレージを利用することで、障害が起きても素早くフェイルオーバーできるように備えます。ローカルストレージ運用ではクラウドとの連携以前に、オンプレミス環境内部の整合性が担保できず、クラウドへの切り替えもスムーズに行われません。
Azure FilesやAzure Shared Disksも視野に
ハイブリッド環境では、Azureの共有ディスク機能（Azure Shared Disks）やAzure Filesといったクラウドストレージが選択肢に含まれます。クラスタ全体をAzureへ移行しないまでも、バックアップ対象データやアーカイブ的なデータをクラウド上の共有ディスクに逃がしておくことで、オンプレミス側の負荷軽減やDR（災害復旧）対策が容易になります。
具体的な構成例とベストプラクティス
ここからは、実際のフェイルオーバークラスター構成を検討する際の具体的なベストプラクティスについてご紹介します。構成検討時には以下のポイントに特に注意する必要があります。
1. ストレージネットワークの冗長化
共有ストレージを利用するには、ストレージとサーバーを結ぶネットワークが安定していることが不可欠です。たとえばiSCSIベースのストレージを使う場合、ネットワークアダプタのチーミング（NIC Teaming）や複数のスイッチを用いた冗長化を行い、単一障害点を排除します。また、FC（Fibre Channel）を使う場合にも、複数のFCスイッチを挟むなどして、パス障害が発生しても影響を最小化できる構成をとるのが一般的です。
2. ストレージ自体の高信頼化
ハードウェアRAIDやストレージコントローラの2重化、予備電源（UPS）の導入など、ストレージ機器自体の信頼度を高める対策も必須です。ストレージが一元管理される分、そこが止まるとクラスタ全体が機能しなくなるおそれがあるため、妥協は禁物です。
3. CSVの設定と最適化
Windows Server上でCluster Shared Volumesを使う場合、推奨される構成ガイドに従ってネットワークやディスクの設定を最適化しましょう。特にCSVネットワークは高スループットかつ低遅延の通信が必要です。例えば下記のようなPowerShellコマンドを使ってノードとディスクの状態を確認し、最適な構成を施します。
# クラスター内のノード一覧を確認
Get-ClusterNode
# クラスター内のディスク一覧を確認
Get-ClusterDisk
# CSVにディスクを追加
Add-ClusterSharedVolume -Name "Cluster Disk 1"上記のように、Windows ServerのFailover Clusteringモジュールを活用することで、スクリプトベースでもクラスタ設定を管理できます。視覚的に管理するだけでなく、スクリプトを組むことで、障害対応の自動化や大規模環境での一括管理が容易になります。
運用管理面での留意事項
フェイルオーバークラスターは、一度構成を組んでしまえば終わりではなく、継続的な運用管理が求められます。運用管理面で、特に注意すべき点をいくつか挙げてみましょう。
クラスタノードの定期ヘルスチェック
冗長性があるからといって、ノード障害を放置すると徐々にクラスタ全体の耐障害性が下がります。定期的にノードの状態をテストし、OSやドライバ、ファームウェアのアップデートを適切なタイミングで実施しましょう。
バックアップとリストア手順の検証
バックアップが存在してもリストア手順が曖昧だと、万が一の際にスムーズに復旧できません。共有ストレージを使っている場合は「どのノードでどのボリュームをバックアップするのか」「クラスタごと一括でスナップショットを取るのか」など方針を明確にし、定期的にリストアテストを行うことが大切です。
DRサイトやクラウドへのレプリケーション
本記事冒頭のケースのように、Azure上にActive Directoryが待機する構成であれば、オンプレミス環境とクラウド環境の間でデータをレプリケートする仕組みを整備しておきましょう。フェイルオーバーが発動してクラウド側に切り替わった場合でも、ユーザーが障害をほとんど意識しない形でサービスを継続できるようにします。
トラブルシューティングのポイント
いくら設計や運用を徹底していても、突発的なトラブルに見舞われる可能性はゼロではありません。フェイルオーバークラスターとストレージ周りのトラブルシューティングで注目すべきポイントをいくつか紹介します。
イベントログとクラスタログ
Windows Serverには「Failover Clustering」専用のログが存在します。下記のPowerShellコマンドでクラスタログを生成し、障害発生時にどのような動きがあったのかを詳細に調査できます。
Get-ClusterLog -Destination C:\clusterlogs -TimeSpan 5このようにクラスタログとイベントログを併せて確認することで、ノードダウンの原因やストレージが切断されたタイミングなどを特定しやすくなります。
ノード間通信のネットワーク解析
共有ストレージが正常でも、ノード間ネットワークに問題があればフェイルオーバーが正しく行われないケースがあります。ネットワーク機器のログや使用率をリアルタイムで監視し、帯域不足や遅延が発生していないかを調べることも重要です。
ディスクI/Oパフォーマンスのモニタリング
共有ストレージにアクセスが集中すると、ディスクI/Oが逼迫し、システム全体のパフォーマンスが低下します。クラスタマネージャやPerformance Monitorなどを活用してディスクキューの長さやI/O待ち時間を定期的にチェックし、必要に応じてストレージのスケールアップを検討しましょう。
まとめ: フェイルオーバークラスターには共有ストレージが不可欠
ここまで解説してきたように、フェイルオーバークラスターを組む際には原則として共有ストレージを用いることが推奨されます。ローカルストレージ構成ではノードダウン時のデータアクセス確保が困難であり、可用性を確保する仕組みとしては不十分です。銀行や金融機関のような高い可用性を要求される環境であればなおさら、共有ストレージの導入が基本といえるでしょう。
さらにクラウドを組み合わせたハイブリッド構成を導入する際にも、オンプレミス環境は共有ストレージベースで運用することが望ましいです。そうすることで、Azureなどのクラウドリソースと連携しやすくなり、災害時のリカバリを迅速に行えるメリットが得られます。ストレージが安定稼働してこそ、フェイルオーバークラスターの真価が発揮されるのです。
最後に
フェイルオーバークラスターは「高可用性」という目標に直結する重要な仕組みであり、安定稼働のためにはストレージやネットワーク、ノード側の設計・運用が総合的に優れている必要があります。特にストレージはクラスタが利用するリソースの中心に位置しますから、正しい選択と適切な管理を心がけましょう。共有ストレージを活用したベストプラクティスを押さえ、定期的なメンテナンスと監視を徹底することで、クラスタ環境を最大限に生かすことができます。
コメント