OCIで共有ディスク型WSFCのファイル・サーバーを構成する

1. はじめに

この記事では、OCI上でWindows Server Failover Cluster（以下WSFC）を利用したクラスター構成のファイル・サーバーを構築する手順をご紹介します。

SMBプロトコルを使用するファイル・サーバーやSQL Serverなどを冗長構成したいときに、Windows Serverに標準機能として備わっているWSFCは有効な手段となります。

本記事では共有ディスク型のWSFCを構成します。共有ディスク型でWSFCを構成するメリットはクラスターで単一のディスクを使用できる点で、データ・ボリュームにかかるストレージコストを削減でき、データ・ミラー型のように複数ボリューム間のミラー同期について考慮する必要もありません。
OCIのブロック・ボリュームはSCSI-3 Persistent Reservationに対応しており、共有ディスク型のWSFCの構成要件を満たすことができます。また、ブロック・ボリュームはデフォルトで冗長化が行われているので、共有ディスク型でもストレージの冗長性を確保することができます。

2. 概要

以下、本記事で作成する成果物および手順の概要を示します。

構成

下記の構成図のリソースを作成します。

主な構成要素は以下の通りです。

• VCN : 各インスタンスを配置する仮想・クラウド・ネットワーク
• コンピュート・インスタンス
  1. Domain Controller: ADDSをホストするドメイン・コントローラー
  2. Client: ファイル・サーバーに接続するためのWindowsクライアント
  3. FS-Node1: ファイル・サーバー機能を持つクラスターの1つ目のノード
  4. FS-Node2: ファイル・サーバー機能を持つクラスターの2つ目のノード
• Block Volume: ファイル・サーバーのデータ・ボリュームとして2つのインスタンスから共有アタッチするブロック・ボリューム

ネットワークについて

今回はあくまで検証目的のネットワーク構成にしています。FS-Node1、FS-Node2のインスタンスをドメインに参加させることができ、クライアントがファイル・サーバーにアクセスできることが主な条件です。

クラスターのノード間で共用するIPアドレスは、所有者ノード（クラスターのアクティブ・ノード）のvNIC（仮想ネットワーク・インターフェイス・カード）に割り当てておきます。
本記事の構成では、フェイルオーバーの際にスタンバイからアクティブに昇格したインスタンスが自vNICへクラスターのIPアドレスを引き取るような動きになります。

クラウドのネットワークの制約上、OS側の設定でIPアドレスを変更するだけではIPフェイルオーバーさせることができません。IPフェイルオーバーを実現するためにはOCIのAPIを使用する必要があり、この記事ではAPI操作用のスクリプトを使用します。

ストレージについて

共有ディスク型で構成するため、1つのブロック・ボリュームを共用のデータ・ボリュームとして2つのインスタンスにアタッチします。
排他制御はSCSI-3 Persistent Reservationをボリュームで有効化することで可能になります。

SCSI-3 Persistent Reservationを使用する上での制約として、マルチパス対応アタッチメントが無効となります。ブロック・ボリュームの最大IOPSは50,000 IOPSに制限されます。
参考：OCIドキュメント

3. 準備

WSFCを構成するための事前準備として、ネットワーク、コンピュート・インスタンス、ブロック・ボリューム、Windowsドメインの作成・設定を行っていきます。

VCNの作成

任意のCIDRブロックとサブネットを構成したVCNを用意します。
ノード間のハートビートやクラスタの管理通信などを考慮して、NSGやセキュリティ・リストで必要な通信を許可するように設定します。
参考：Microsoft社のドキュメント

Domain ControllerをホストするWindows Serverインスタンスの作成（ドメインを新規作成する場合）

後ほどWSFCを構成する上で、クラスターの各ノードをActive Directoryのドメインに参加させます。
本記事の検証環境には既存のドメインがなかったため、VCN内にWindows Serverインスタンスを作成し、新規でActive Directory Domain Serviceをインストールしました。
以下にドメインを新規作成する場合の大まかな手順を記載します。

まずインスタンスを作成します。
ドメイン・コントローラー用インスタンス

• 名前 : DomainController
• 配置 : AD-1 / FD-1
• シェイプ : VM.Standard.E6.Flex
  • 1 OCPU
  • 8 GB メモリー
• イメージ : Windows Server 2025
• VCN : 使用するVCN
• サブネット : 使用するサブネット

インスタンスが作成できたら、インスタンスにリモートデスクトップ接続をして、一般的な手順を参考に構成します。

OCI特有の設定は特にありませんが、上記のMicrosoft社のドキュメントに記載されていない下記の点についてご注意ください。

• Windows Server OS上でローカル管理者のパスワードをあらかじめ設定しておく必要があります。
• Active Directory Domain Serviceインストール後にドメイン・コントローラーに昇格させるウィザードのオプションで、DNSサーバーの機能にチェックされていることを確認してください。WSFCの各ノードがドメインに参加する際に、DNSでドメインを引き当てる必要があるので、ドメイン・コントローラーにDNSサーバーの機能を持たせる必要があります。
  

WSFC管理用ユーザーの作成

このあとWSFCを構成するために、クラスターを作成・管理するためのユーザーを用意します。
Active Directory Administrative Centerを開いて、ウィンドウ右下のユーザー（User）のタブでNew（新規作成）-> User（ユーザー）をクリックして、表示されたウィンドウでユーザーを作成します。

例えば、wsfc-adminという名前で作成します。

Administratorsのグループに参加させて、権限を付与します。

パスワードをリセットしてユーザーを有効化させれば、ユーザー作成は完了です。

ファイル・サーバー用のWindows Serverインスタンスx2とブロック・ボリュームを作成

次に、ファイルサーバー機能をもつクラスターの各ノードとなるインスタンスと、ノード間で共用するデータ・ボリュームとして使用するブロック・ボリュームを作成します。

コンピュート・インスタンスの作成

今回は2ノードのクラスターを作成しますので、2つのWindows Serverインスタンスを作成します。
例えば、以下の構成で作成します。

1つ目のノード用インスタンス

• 名前 : FS-Node1
• 配置 : AD-1 / FD-1
• シェイプ : VM.Standard.E6.Flex
  • 1 OCPU
  • 8 GB メモリー
• イメージ : Windows Serevr 2025
• VCN : 使用するVCN
• サブネット : 使用するサブネット

2つ目のノード用インスタンス

• 名前 : FS-Node2
• 配置 : AD-1 / FD-2
• シェイプ : VM.Standard.E6.Flex
  • 1 OCPU
• イメージ : Windows Serevr 2025
• VCN : 使用するVCN
• サブネット : 使用するサブネット

データセンター内での分散配置を考慮して、2つのインスタンスのフォルト・ドメインを分けて作成しています。なお、ブロック・ボリュームを共用するため、可用性ドメインを分散させることはできません。

また、インスタンス作成時にイメージとシェイプの拡張オプションで、Oracle Cloudエージェントの「ブロック・ボリューム管理」のプラグインを有効化しておくことをおすすめします。

↓プルダウン・メニューを開いて、ブロック・ボリューム管理にチェックをつける

※作成時に有効化しなかった場合は、コンソールの作成済みのインスタンスの詳細画面の管理タブから有効化することもできます。

このプラグインを有効化しておくことで、後ほどブロック・ボリュームをアタッチしたときに、OS上でiSCSIコマンドを手動で実行しなくても、Oracle Cloudエージェントが自動でiSCSI接続を完了させてくれます。

ブロック・ボリュームの作成・アタッチ

インスタンスに共有アタッチするデータ・ボリューム用のブロック・ボリュームを作成します。

任意の名前、サイズ、パフォーマンスで作成します。
ADはFS-Node1、FS-Node2のインスタンスと同じADを選択します。

作成時に「予約の有効化」のトグルボタンをクリックして、SCSI-3 Persistent Reservationを有効化します。

ブロック・ボリュームの作成が完了したら、ボリュームをインスタンスにアタッチします。
コンソールで「アタッチされたインスタンス」->「インスタンスにアタッチ」をクリックしてアタッチのメニューを開きます。

予約の有効化を設定したボリュームのため、通常とは異なる表示となります。
「クラスタ・ファイル・システムをインストールして構成する前に～」という確認にチェックをつけます。

アタッチするインスタンスを選択する箇所で、まずFS-Node1にアタッチします。

画面の下部に「ブロック・ボリューム管理のプラグイン」を使用してiSCSI接続を自動化するオプションがあるので、トグルボタンを押してこのオプションを使用するように設定します。

「アタッチ」のボタンを押してしばらくするとインスタンスへのアタッチが完了します。

FS-Node1インスタンスへのアタッチが完了したら、続けてFS-Node2インスタンスにも同様の手順でアタッチします。

2つのインスタンスへのアタッチが完了すると、「アタッチされたインスタンス」のリストに2つのインスタンスの名前が表示されますので、これでアタッチ完了です。

各ノードをドメインに参加させる

作成したFS-Node1、FS-Node2のそれぞれのインスタンスをドメイン参加させるために、以下の作業を2つのインスタンスそれぞれで行います。

まず、インスタンスにリモートデスクトップ接続して、opcユーザーで初期パスワードを入力してログインします。

ログインが完了したら、設定（Setting）-> ネットワークとインターネット（Network & Internet）-> イーサネット（Ethernet）の設定を開いて、DNSをマニュアル設定に切り替えて、ドメイン・コントローラーのインスタンスのプライベートIPアドレスを入力して保存します。

次に、サーバーマネージャーを開いて、ローカル・サーバーのプロパティを変更して、ドメインに参加させます。

初期状態でWORKGROUPとなっているワークグループをクリックします。

表示されたウィンドウで参加するドメインを入力します。

ユーザー名とパスワードの入力が求められるので、ここで先ほど作成したユーザー名（wsfc-admin）とそのパスワードを入力して、設定を完了させます。
完了すると再起動を促すポップアップが表示されますが、あとで再起動するようにして、再起動前にもう1つ作業を行います。

まだwsfc-adminユーザーでログインすることができないので、設定（Setting）-> システム（System）-> リモートデスクトップ接続（Remote Desktop）-> リモートデスクトップ・ユーザーの設定を開いて、リモートデスクトップ接続できるユーザーを追加します。

追加（Add）を押すと出てくるウィンドウで、ユーザー名（wsfc-admin）とそのパスワードを入力して、リモートデスクトップ接続可能なユーザーとして追加します。

追加できたら再起動を実行して、ドメインの変更を反映させます
この作業をFS-Node1とFS-Node2それぞれで完了させて、両インスタンスにwsfc-adminユーザーでログインすることを確認できたら、ドメインの設定は完了です

ディスクの初期化とフォーマット

アタッチしたばかりのブロック・ボリュームを使用可能な状態にしていきます。
wsfc-adaminユーザーでFS-Node1インスタンスにログインして、コンピューターの管理（Computer Management）を開いて、ディスクの管理（Disk Management）から、まず初期化を行います。

「Disk 1」と表示されているあたりを右クリックすると、ディスクの初期化のオプションが出てくるので左クリックします。
※もし「Reserved」と表示されていて予約済みの状態でディスクの操作ができない場合は、FS-Node2でログインして同じ操作を試みてください。

初期化のウィンドウが表示されたら、特にデフォルトから変更せずGPT形式で初期化を実行します。

初期化が完了したら、次にディスクのフォーマットを行います。
未割当て（Unallocated）と表示されている領域のところで右クリックして、新しいシンプルボリューム（New Simple Volume...）を左クリックします。

ウィザードが表示されるので、こちらも特にデフォルトから変更せず、NTFSのファイルシステムとしてフォーマットを実行します。

初期化とフォーマットを行って、次のように表示されていれば作業は完了です。

これで準備がすべて終わりました。
※必要に応じてブート・ボリュームのバックアップを取ることをおすすめします。

4. WSFCの構成

ここからは、WSFCの構成を行います。

フェールオーバー・クラスターをインストール

以下、FS-Node1とFS-Node2それぞれで同じ作業を行います。

まず、リモートデスクトップ接続をしてwsfc-adminユーザーでログインします。
サーバーマネージャーで管理（Manage）-> 役割と機能の追加（Add Role and Feature）をクリックして、ウィザードを表示させます。

デフォルトのまま次へ（Next）を押して、機能（Features）の画面で「フェールオーバー クラスタリング（Failover Clustering）」をチェックします。

次の画面に進んで、インストールを実行します。

クラスターの構成

インストールが完了したら、Failover Cluster Manager（フェールオーバー クラスター マネージャー）を開いて、クラスターの作成を行っていきます。
ここからは、FS-Node1もしくはFS-Node2のどちらか一方のインスタンスでFailover Cluster Managerを開きます。

念のため構成の検証（Validate Configuration）から始めて、クラスターを作成する前にチェックを実行します。

クラスターに含めるFS-Node1とFS-Node2をサーバーとして選択します。

全てのテストを実行します。

しばらく待つと実行結果が表示されます。

1. まず、緑で囲ったボタンを押すとレポートがブラウザで表示されるので確認しておきます。いくつか警告が出るものもありますが、致命的な問題でなければ無視して進みます。
2. 赤で囲ったチェックボックスをマークして、このままクラスターの作成に進みます。

構成チェックのウィザード閉じると、作成のウィザードが立ち上がります。
クラスター名とクラスターIPを入力して、次の確認画面で構成が合っていれば、次に進んで作成します。
今回は 10.0.0.10 をクラスター用のIPアドレスに使用します。

ディスクの追加

後ほどファイル・サーバーを構成する際にデータ領域として割り当てるアタッチ済みの共有ディスクを、クラスターが使用するディスクとして追加します。
Failover Cluster Managerのディスクのセクションで、ディスクの追加（Add Dsik）をクリックして、ディスクを追加します。

事前に準備していおいた共有ディスクが表示されるので、選択してディスクをクラスターに追加します。

ファイル・サーバーを構成

作成したクラスターにファイル・サーバーの役割を付与して、ファイル・サーバーの機能を持たせます。

役割の構成（Configure Role）をクリックします。

役割を選択する画面で、ファイル・サーバーを選択します。

デフォルト設定のまま汎用ファイル・サーバーにします。

任意の名前を入力したら、アドレスの箇所で 10.0.0.11 と入力します。このIPアドレスでファイル・サーバーがホストされます。

さきほど追加したディスクを選択したら、そのまま進んでロールを構成します。

これでファイル・サーバーが構成できました。

IPアドレスの割り当て

OS側でクラスターが使用するIPアドレスを指定しましたが、まだインスタンスは実際にIPアドレスを使用できません。OCIコンソールでvNICにIPアドレスを割り当てていきます。

クラウドのネットワーク仕様の制約上、同じIPアドレスを2つのインスタンスにまたがって割り当てることはできないので、所有者ノード（アクティブ、プライマリとして機能しているノード）にIPアドレスを割り当てます。
フェールオーバー・クラスター・マネージャーのクラスターの情報にクラスターの所有者ノードの情報が表示されるので、こちらを参考に確認します。

上記はFS-Node1が所有者ノードとなっている状態です。

OCIコンソールで所有者ノードとなっているインスタンスの詳細画面の「ネットワーク」のタブから、vNICの詳細画面を表示します。vNICの詳細画面の「IP管理」のタブを開いてIPアドレスの設定を行います

セカンダリIPのアサインを行って、次の2つのIPアドレスをvNICに割り当てます。

• クラスターIP : 10.0.0.10
• ファイル・サーバーのIP : 10.0.0.11

コンソールの表示が上記のようになっていれば完了です。

クォーラム監視の設定

クォーラム監視として今回はディスク監視を設定します。
※クォーラム監視の詳細はMicrosoft社のドキュメントをご確認下さい。

フェールオーバー・クラスター・マネージャーで、クラスタークォーラム設定の構成（Configere Cluster Quorum Setting）を開きます。

表示されるウィザードで、クォーラム監視を選択するところにチェックして進みます。

ディスク監視の構成をチェックして進みます。

クラスターに追加したディスクを選択して構成します。

完了すると、ディスクのセクションでディスク監視が設定されていることが確認できます。

構成の確認

WSFCの構成が完了したのでここで一度構成を確認してみます。
まず、クラスターを作成したユーザー（wsfc-admin）が、Power ShellでWSFCに関連するコマンドを実行できるようにするために、以下の手順を実施します。後続の手順で使用するIPフェイルオーバーのスクリプトの中でも、wsfc-adminユーザーでコマンドを実行する箇所があるので、この手順は必須です。

Power Shellを管理者で実行を選択して開いて、下記のコマンドの <domain>の部分を自身のドメイン名に置き換えて実行します。

Grant-ClusterAccess -User "<domain>\wsfc-admin" -Full

上記のコマンドで権限が付与出来たら、Power Shellを通常のユーザーで開いて、確認のため次のコマンドを実行してみます。

Get-ClusterResource

例えば次のような結果が表示されます。

出力例

Name                       State  OwnerGroup         ResourceType
----                       -----  ----------         ------------
Cluster Disk 1             Online FS-Cluster         Physical Disk
Cluster IP Address         Online Cluster Group      IP Address
Cluster Name               Online Cluster Group      Network Name
File Server (\\FS-Cluster) Online FS-Cluster         File Server
FS-Cluster                 Online FS-Cluster         Network Name
IP Address 10.0.0.11       Online FS-Cluster         IP Address
Storage Qos Resource       Online Cluster Group      Storage QoS Policy Manager
User Manager               Online User Manager Group User Manager

結果からクラスターのサービスや、ファイル・サーバー機能、ネットワークなどが正常の機能していることを確認できます。

Failover Cluster ManagerでGUIでも同様の情報を確認することができます。

5. IPフェイルオーバーの設定

概要で述べたとおり、IPフェイルオーバーを実行させるためにはvNICに割り当てるIPアドレスをOCIのAPIから変更する必要があります。今回はpythonスクリプトを使用した構成方法を用います。

今回使用するスクリプトはこちらです。cloud-asset-oci-msfailoverclusterを私がフォークして若干の修正を加えたものです。

実行環境の準備

Pythonの実行環境が必要なので、FS-Node1、FS-Node2の両方のインスタンスで、Pythonをインストールします。今回はver. 3.14.0をインストールしました。

続いて、OCI SDK for Pythonをインストールします。
以下のpipコマンドでインストールできます。

pip install oci

IPフェイルオーバー用のスクリプトの設定

以下、スクリプトの使用方法について簡潔に解説します。

まず oci_config にOCIテナンシの情報を記載します。今回はインスタンス・プリンシパルの認証を使用するので、APIキーに関連する変数の部分（fingerprintとkey_file）は入力不要です。

次に、settings.json にクラスターに関連する情報を入力します。

入力例

{
    "node1_name": "FS-Node1",
    "node2_name": "FS-Node2",
    "sql_cluster_name": "FS-Cluster",
    "private_ip_id_default_cluster": "ocid.------",
    "private_ip_id_sql_cluster":"ocid.------",
    "skip_dr_node_name":"",
    "vnic_1": "ocid.------",
    "vnic_2": "ocid.------"
}

入力する上でのポイントは次の通りです。

• node1_name node2_name sql_cluster_nameの箇所は、スクリプト内で実行されるPower Shellの Get-ClusterGroup コマンドの結果の文字列と一致させる必要があります。コマンドを実行して確認するのが確実です。
• private_ip_id_default_cluster はクラスターのIPアドレス（10.0.0.10）のOCIDです。vNICに割り当てられているIPアドレスのOCIDを入力します。
• private_ip_id_sql_cluster はファイル・サーバーのIPアドレス（10.0.0.11）のOCIDです。vNICに割り当てられているIPアドレスのOCIDを入力します。
• vnic_1 vnic_2 はそれぞれのノードのvNICのOCIDを入力します。

ここまでの情報が正しく入力できていれば、oci-mscluster-instance-principals.pyを実行できます。先ほどの2つのファイルと同じディレクトリに配置して実行します。
もしエラーが出た場合は入力値などを訂正します。
（※同リポジトリにある oci-mscluster.py のスクリプトは今回使用しません）

シェルで実行してみて、問題なく実行できていれば次のようなメッセージが表示されます。

実行結果の例

New MASTER DEFAULT NODE detected --> FS-Node1
New MASTER SQL NODE detected --> FS-Node1
Nothing to change on OCI, FS-Node1 is the MASTER DEFAULT NODE
Nothing to change on OCI, FS-Node1 is the MASTER SQL NODE
Nothing to change on OCI, FS-Node1 is the MASTER DEFAULT NODE
Nothing to change on OCI, FS-Node1 is the MASTER SQL NODE
--以下繰り返し--

あとはこのスクリプトがインスタンス起動時に自動で実行されるように、タスクスケジューラ（Task Scheduler）で設定します。
タスクスケジューラを開いて oci-mscluster-scheduler.xml をインポートすれば設定できます。

xmlファイルの下記の箇所を、自身の環境に合わせて書き換えて設定します。

例

<Command>C:\Users\<UserName>\AppData\Local\Programs\Python\Python314\python</Command>
<Arguments>C:\Users\<UserName>\cloud-asset-oci-msfailovercluster\oci-mscluster-instance-principals.py</Arguments>

スクリプトを自動で実行する設定ができたら、これでIPフェールオーバーの設定も完了です。WSFCのすべての構成が終わりました。

6. フェイルオーバーのテスト

実際にフェイルオーバーが作動するかテストしてみます。

ファイル共有のマウント

ファイル・サーバーのをクライアントからマウントします。
構成図の中で「Client」と記載しているクライアント用のインスタンスを用意して、ファイル共有をマウントします。

クライアント用のインスタンスで、エクスプローラからネットワークの場所の追加（Add a network location）のウィザードを開きます。

ファイル・サーバーに割り当てたIPアドレスとファイル共有名のパスを入力すればマウントできます。

完了すると、ネットワークの場所としてさきほど構成したファイル・サーバーが表示されます。

マウントしたクライアントのユーザーがファイルを読み書きできるように、必要に応じて権限を設定しておいてください。

所有者ノードを停止させる準備

FS-Node1もしくはFS-Node2のいずれかで、Power Shell上で次のコマンドを実行して、所有者ノードを確認します。

get-ClusterGroup

下記の実行例は、FS-Node1が所有者ノードであることを示しています。

実行例

PS C:\WINDOWS\system32> get-ClusterGroup

Name              OwnerNode State
----              --------- -----
Available Storage FS-Node1  Offline
Cluster Group     FS-Node1  Online
FS-Cluster        FS-Node1  Online

※Failover Cluster ManagerのGUIからでも同様に確認できます。

OCIコンソールを開き、コンピュート→インスタンスで、インスタンスの一覧から、確認した所有者ノードになっているインスタンスの詳細画面を開きます。
アクション→停止で確認画面を開いて、停止させる準備をします。ここではまだ停止ボタンを押さないでください。

実際の障害時に近い挙動を確認するために、あえて強制停止にチェックをつけて、OSを急に停止させてみます。まだ停止のボタンは押しません。

テスト

停止させる準備ができたら、テストを実施してみます。
テスト用のファイルを送信して、送信中にフェイルオーバーが正しく行われるか試してみたいと思います。

ファイル送信を開始して、送信中に所有者ノード（FS-Node1）をOCIコンソールから停止させます。停止させると、ファイル送信が一時的にストップします。

およそ30-40秒ほどでフェイルオーバーが完了して、ファイル送信が再開されました。

ダウンを検知するまでの時間や、所有者ノード変更後にAPIリクエストでIPアドレスを移動させる処理時間などがかかるため、瞬時の切り替わりとはなりませんが、比較的短い時間で正しくフェイルオーバーすることが確認できました。

FS-Node2にwsfc-adminユーザーでログインして、Power Shellでクラスターの情報を確認すると、所有者ノードがFS-Node2に変更されていることが確認できます。

PS C:\WINDOWS\system32> get-ClusterGroup

Name              OwnerNode State
----              --------- -----
Available Storage FS-Node2  Offline
Cluster Group     FS-Node2  Online
FS-Cluster        FS-Node2  Online

7. おわりに

本記事では、OCI上で共有ディスク型のWSFCを構成して、ファイル・サーバーとして使用する手順について記載しました。また、フェイルオーバーのテストを行って、アクティブ・ノードの障害時にスタンバイ・ノードに切り替わることも確認できました。クラウドならではの工夫が必要な部分もありますが、クラウド上でWindowsインスタンスの冗長性を実現するソリューションとしてWSFCに一定の有効性を認めることができると思います。

またなにより、フェイルオーバーが実際に動作するところを観察すると気持ちがよくて達成感があるので、WSFC構成は、OCIのIaaSやサーバークラスタリング、Windows Server、Windowsドメインなどをざっくりと理解するための応用的な題材として、勉強にもちょうどいい内容かもしれません。