ハイパーコンバージドインフラストラクチャ(HCI)が世間的に盛り上がっている(?)なか、お金がないという理由でしょうがなく旧来の3レイヤ構成Hyper-Vクラスターを組むことになった。まだまだ高いよHCI...
正直なとこ自分は3レイヤ構成で構築したことがなく、その上物理機器もない。あるのは割と高スペックなパソコンのみ。
このままではとても不安なので、構築の流れだけでも把握できるように、なんとかして疑似環境を組むことにした。
要件としてはホストサーバー2台でクラスターを構成し、ライブマイグレーションおよび障害時のフェイルオーバーが可能なものとする。
検証環境
ルートホストサーバー上に全要素を仮想マシンで構築する。
- ルートホストサーバー: Windows 10 Pro (1703)
- ストレージサーバー: CentOS 7.4
- クラスタ管理ADサーバー: WindowsServer 2016 Standard 評価版
- ホストサーバー1: WindowsServer 2016 Standard 評価版
- ホストサーバー2: WindowsServer 2016 Standard 評価版
- Windowsゲストサーバー: WindowsServer 2016 Standard 評価版
- Linuxゲストサーバー: CentOS 7.4
物理NICは1つしかないため、本来分けるべきネットワークが分けられていない。よって、全仮想マシンは全て同じネットワークのアドレスを持つ。以下にIPアドレス割り当てを示す。
- ルートホストサーバー: DHCP
- ストレージサーバー: 192.168.1.80/24
- クラスタ管理ADサーバー: 192.168.1.81/24
- ホストサーバー1: 192.168.1.82/24
- ホストサーバー2: 192.168.1.83/24
- クラスタ管理用アドレス: 192.168.1.84/24
- Windowsゲストサーバー: DHCP
- Linuxゲストサーバー: DHCP
ホストサーバーに対してNestedHyper-Vを有効にする
Windows10(WindowsServer2016)からHyper-Vの仮想マシン上でHyper-Vサーバーを構築できるNested Hyper-V機能を有効に出来るようになった。
ルートホストサーバー上に仮想マシンを作成したら停止し、以下の手順でホストサーバー1とホストサーバー2のNestedHyper-Vを有効にすること。
Set-VMProcessor -VMName <VM-NAME> -ExposeVirtualizationExtensions $true
ストレージサーバーの構築
CentOS上にiSCSIターゲットを作成する。OSの基本的な設定は済ませてあること。
iSCSIを利用するにあたり、事前にIQNを決めておかなければいけないので、以下のように決めておいた。
- ホストサーバー1: iqn.2017-09.com.test:host-sv1
- ホストサーバー2: iqn.2017-09.com.test:host-sv2
- ストレージサーバー: iqn.2017-09.com.test:storage
iSCSIターゲット機能のインストール
# yum install targetcli
# systemctl enable target
iSCSIターゲットの作成
Hyper-Vクラスター向けに作るため、ターゲット上にクォーラムディスクと共有ディスクの2つのLUNを設定する。
# mkdir /iscsi_disks
# targetcli
--- 以下、targetcli上での操作 ---
> cd backstores/fileio
> create disk0 /iscsi_disks/disk0.img 1G
> create disk1 /iscsi_disks/disk1.img 300G
> cd /iscsi
> create iqn.2017-09.com.test:storage
> cd iqn.2017-09.com.test:storage/tpg1/luns
> create /backstores/fileio/disk0
> create /backstores/fileio/disk1
> cd ../acls
> create iqn.2017-09.com.test:host-sv1
> create iqn.2017-09.com.test:host-sv2
> exit
クラスタ管理ADサーバーの構築
クラスターを構成するためには、別途ActiveDirectoryサーバーが必要になる。
ちなみにホストサーバー上にクラスタ管理ADの役割も持たせるといったズルをすると、後で設定が進められなくなるので注意すること。
ActiveDirectoryインストールとクラスター用ドメインの作成
サーバーマネージャーを開いて「Active Directory ドメインサービス」の役割を追加する。必要な機能も自動で選択されるので、一緒に入れておくこと。
クラスター用ドメインを作成し、ドメインコントローラーに昇格する。
- ドメイン名: cluster.local
- フォレストレベル: Windows Server 2016
- ドメインレベル: Windows Server 2016
ホストサーバーの構築
iSCSIストレージに接続する
iSCSIイニシエーターにアクセスして自身のIQNを確認する。iSCSIターゲット側で設定したIQNと違っていれば直すこと。
IQNを修正したら、iSCSIターゲットのIPアドレスを入力して接続する。
ターゲット側のIQNが表示され、接続完了となっていればOK。
iSCSIストレージをフォーマットする
この作業はホストサーバー1でのみ行う事！
ディスクの管理にアクセスし、接続されたたクォーラムディスクと共有ディスクをオンラインにしてGPTで初期化する。
その後、両方のディスクをNTFSでフォーマットする。ドライブレターは割り当てなくともよい。
iSCSIストレージをオンラインにする
ホストサーバー1は既にオンラインになっているため、ホストサーバー2も同様にオンラインにする。
こちらもドライブレターを割り当てる必要はない。ホストサーバー1でフォーマット済みであるため、オンラインにした時点でNTFSフォーマットになっていることが確認できる。
Hyper-Vをインストールする
サーバーマネージャーを開いて「Hyper-V」の役割を追加する。必要な機能も自動で選択されるので、一緒に入れておくこと。
フェールオーバークラスタリングをインストールする
サーバーマネージャーを開いて「フェールオーバークラスタリング」の機能を追加する。必要な機能も自動で選択されるので、一緒に入れておくこと。この時点では特に設定は必要ない。
クラスター用ドメインに参加する
ホストサーバーを2台とも普通にドメイン参加する。
Hyper-Vの構築
Hyper-Vマネージャーを起動して仮想スイッチを作成する。
今回はNICが1つしかないためネットワークアダプタは管理用オペレーティングシステムと共用させている。
なお、マイグレーション時に仮想スイッチの設定が完全に一致している必要がある。スイッチ名や構成はクラスターを構成するホストサーバー同士で合わせておくこと。
Hyper-Vクラスターの構築
ホストサーバー1にて作業を行う。以降の作業はクラスター用ドメインの管理者ユーザーでログインして作業すること。
クラスターを構築する
ホストサーバー1のフェールオーバークラスターマネージャーを起動する。
左ツリーのフェールオーバークラスターマネージャーを右クリックし、クラスターの作成を選択する。
クラスターに参加させたい全てのホストサーバーを入力し、「追加」ボタンで追加していく。追加が終わったら「次へ」で進む。
検証するかどうか聞かれるので、念のため検証を行っておく。
今回は無理やり1NICで設定したため、いくつか警告が出ている。気にせず完了する。
クラスタ名とクラスタ管理用の仮想IPを聞かれるので、任意の設定を入力して次へ進む。
以降は次々と進めて、クラスターの作成を完了させる。
ディスクサイズを見て自動判断しているのか、クォーラムディスクと共有ディスクが自動で設定されていた。
共有ディスクをクラスター共有ボリュームに変換する
iSCSIディスクはホストサーバーでアクセス可能になっているが、クラスター用に変換されていない。
共有ディスクを選択して、右にあるメニューから「クラスターの共有ボリューム」を押す。変換はすぐ終わる。
変換されると、適用先名が「クラスターの共有ボリューム」に変わる。
ディスクの管理でみても、NTFSからCSVFSという専用フォーマットになっている。
C:\ClusterStorage\にクラスタ専用領域が作成されている。
クラスタ専用領域は基本的にHyper-V仮想マシン構成ファイル以外のファイルを置くことは推奨されないとのこと。むやみに触れないことにする。
また、クラスタ専用領域はアンチウィルスソフトの検索から除外することも忘れずに。(クラスターが破損する危険性がある。)
クラスターに接続できることを確認する
ホストサーバー2のフェールオーバークラスターマネージャーを起動する。
左ツリーのフェールオーバークラスターマネージャーを右クリックし、「クラスターへの接続」を選択する。
どのサーバーのクラスタに接続するか聞かれるので、「<このサーバー上のクラスター...>」を選択して「OK」を押す。
問題なく作成済みのクラスタに接続できれば、ホストサーバー1と同様にクラスタにアクセスすることができる。
仮想マシンの作成
ここまでくれば、あとは仮想マシンを作成するだけとなる。ただし、Hyper-Vマネージャーからではなく、フェールオーバークラスターマネージャー上で作成しなければ、マイグレーションやフェイルオーバーが動作しない。
ホストは後でマイグレーション出来るのでどれでも良い。
あとは見慣れたウィザードでこれまで通りに仮想マシンを作成するだけだが、仮想マシンの構成ファイルをクラスタ専用領域に指定しなければならない点に注意すること。
これで、マイグレーション可能なHyper-Vクラスタが構築できた。
あとはマイグレーションのテストや障害発生のテストを粛々とするとよい。
動作検証メモ
ライブマイグレーションの挙動
| ゲストOS | 可否 |
|---|---|
| WindowsServer2016 | OK |
| CentOS7.4 | NG |
恐らくLinux系はライブマイグレーション不可なのではないかと。
ライブマイグレーション実行時の仮想マシンの挙動は以下のように想定される。
- 指定先クラスタノードに仮想マシンを移動
- 仮想マシンを再開
クイックマイグレーションの挙動
| ゲストOS | 可否 |
|---|---|
| WindowsServer2016 | OK |
| CentOS7.4 | OK |
Windows・LinuxともにOK
クイックマイグレーションの仮想マシンの挙動は以下のように想定される。
- 仮想マシンを一時停止
- 指定先クラスタノードに仮想マシンを移動
- 仮想マシンを再開
フェールオーバーの挙動
| ゲストOS | 可否 |
|---|---|
| WindowsServer2016 | OK |
| CentOS7.4 | OK |
フェイルオーバー発生時の仮想マシンの挙動は以下のように想定される。
- 電源断(故意の障害発生)
- クラスタノードに通信が出来なくなったことをクラスタが検知
- 5分程度待機
- 有効なクラスタノードに仮想マシンを移動(優先順位は設定できるが、場合によりけり)
- 仮想マシンを起動
自動で生きているノードで起動しようとするが、結局は電源断が発生しているので仮想マシンが壊れる可能性がある。
フェイルオーバー後の障害ノード復旧後の挙動
例えばホストサーバー2が異常終了後、復旧させると有効なクラスタノードとして再認識される
ただし、フェイルオーバーで移動した仮想マシンは戻らない。(フェールバックが無効になっているから？)
気になる点として、復旧までの時間にActiveDirectoryみたいに時間制限があるのかどうかが気になる。(ActiveDirectoryはあまりにも長い時間復旧しないと、復旧が難しくなる。)
フェイルオーバーに関して
WindowsServer2012R2時代のクラスターはノード障害を検知すると即座にフェイルオーバーしていたが、WindowsServer2016のクラスターは猶予時間(4分)がある模様。
実機上でブルースクリーンを疑似的に発生させてみたがフェイルオーバーせず、2-3分ほどでノードが再起動完了してしまうためフェイルオーバーに至らなかった。
この設定を変更するには以下のコマンドをいずれかのノード上のPowerShellで実行すれば変更できた。
# (Get-Cluster).ResiliencyDefaultPeriod=0
# (Get-Cluster).ResiliencyDefaultPeriod
0
上記設定がデフォルトでは2400(4分)となっているはず。
参考