CentOS7.3とoVirtとGlusterFSによるOSS版ハイパーコンバージドインフラ(構築編)の続きになります。
まず最初に、前回oVirtとGlusterFSで構築した仮想インフラ基盤上にゲストOSを作成する手順について詳細に説明していきます。
その後、作成したゲストOSを利用して、スナップショット作成、クローン作成、ライブマイグレーション、ゲストOS障害時のHA動作、ホストOS障害時のHA動作について、順番に確認していきたいと思います。
ゲストOSの作成
前回の記事でHosted Engineのデプロイ時にisoのブリックとして指定したディレクトリ(/gluster/iso/brick1)配下に以下のようなパスがありますので、ゲストOSのISOイメージをアップロードします(本記事ではホストOSと同じCentOS7.3をゲストOSとして作成します)。
# ls -al /gluster/iso/brick1/101b07ec-5cbb-4c72-b1f4-7020193681a5/images/11111111-1111-1111-1111-111111111111/
合計 4277248
drwxr-xr-x. 2 vdsm kvm 42 4月 1 22:15 .
drwxr-xr-x. 3 vdsm kvm 50 4月 1 21:49 ..
-rw-r--r--. 1 root root 4379901952 12月 24 16:24 CentOS-7-x86_64-DVD-1611.iso
ISOイメージファイルをアップロードしたら、 上部メニューの仮想マシンタブにある「新規仮想マシン」をクリックし、左側メニューの全般タブを選択して以下のように設定します(グレー部分も設定して下さい)。ここではvm1というホスト名の仮想マシンを作成します。
次に詳細オプションを表示してシステムタブを設定します。今回は仮想マシンのリソースはデフォルト値を利用しますのでそのままで、タイムゾーンの変更(GMT+9:00)のみ行いました。
続いて高可用タブを設定します。本設定を行うことでゲストOSが固まった際に再起動すること(ゲストOSのHA)が可能になります。以下のように設定して下さい。
最後にブートオプションタブを設定します。ブートシーケンスで最初にCD/DVD-ROMが起動するように修正し、CD/DVDをアタッチします。isoが表示されない際は右側の青いアイコンをクリックして下さい。
OKをクリックすると仮想マシンが完成します。続いてNICとディスクの割り当てを行います。
vm1が選択された状態で下部メニューにあるネットワークインターフェースタブを選択して「新規作成」をクリックします。今回はNICを1つだけ作成するためデフォルトのままOKをクリックします。
nic1が新規作成されましたので続けてDiskを割り当てます。
vm1が選択された状態で右上の方にあるGuide Meをクリックし、「仮想ディスクの作成」をクリックします。
ここではThin Provisioningで30GB割り当てることにします。
下部メニューのディスクタブから、作成した30GBのディスクが割り当てられていることを確認します。
以上でvm1を実行できる環境が整いましたので、vm1にコンソール接続するためのvirt-viewerをクライアントマシン(本環境ではWindows)にインストールします。
こちらのサイトから以下のようにリンクをたどってvirt-viewerをダウンロードしてインストールして下さい。
準備が整ったらvm1が選択された状態で実行ボタン(緑の逆三角マーク)をクリックします。
すぐに実行ボタン横のコンソールオプションが選択可能になるのでクリックします。
virt-viewerがインストールされた環境であれば図のようにコンソールがポップアップされるのでインストール作業を実施します。
インストール手順は割愛します。
インストールが完了したら再起動を実施しますが、ブートシーケンスの修正が必要なため、一度vm1の電源を落としてブートシーケンスを以下の図のように編集します。具体的にはvm1を編集してブートシーケンスの1番目のデバイスをハードディスクに変更し、CD/DVDをアタッチのチェックをはずしておきます。また、他のオプションについても先ほど設定した通りになっているか念のため確認します。
問題ないようなら編集を終了して実行ボタンからvm1を起動します。
起動したら、vm1に最新のGuest Agentのインストールします。
# yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm
# yum -y install ovirt-guest-agent
# systemctl start ovirt-guest-agent.service
# systemctl enable ovirt-guest-agent.service
以上でvm1の作成は終了です。
続いて、ゲストOSの代表的なオペレーションであるスナップショット作成、クローン作成、ライブマイグレーション、ゲストOS障害時のHA動作、ホストOS障害時のHA動作を順番に見ていきたいと思います。
スナップショット
上部メニューの仮想マシンタブのvm1を右クリックしてスナップショットを作成します。時間がかかるためメモリーを保存のチェックを外してOKをクリックします。
画面の最下部に「Snapshot 'test1' creation for VM 'cent1' has been completed.」のメッセージが出たらスナップショットの取得完了です。
スナップショットの確認のため、testという名前のファイルを作成します。後でスナップショット状態に戻した際に、このファイルが消えていることをもってスナップショット動作確認とします。
[root@vm1 ~]# ls
anaconda-ks.cfg
[root@vm1 ~]# touch test
[root@vm1 ~]# ls
anaconda-ks.cfg test
スナップショットの適用にはvm1の停止が必要なので一度シャットダウンします。
[root@vm1 ~]# shutdown -h now
下部メニューのスナップショットタブからプレビューをクリックします。
「Snapshot-Preview test1 for VM vm1 has been completed」のメッセージが出たら準備完了です。
test1が選択された状態でコミットをクリックします。
「VM vm1 restoring from Snapshot has been completed.」のメッセージが出たら完了です。
vm1を起動してスナップショット取得時の状態(testファイル作成前の状態)に戻っていることを確認します。
[root@vm1 ~]# ls
anaconda-ks.cfg
完了したらスナップショットを削除しておきます。少し時間がかかりますが、「Snapshot 'test1' deletion for VM 'vm1' has been completed.」のメッセージが表示されたら削除完了です。
クローン
私の試した限り、ゲストOSがオンライン状態ではクローンを作成できないようですので、シャットダウンした状態で上部メニューの仮想マシンタブにある「仮想マシンをクローン」をクリックします。クローン名はvm2とします。
最新メッセージが「VM vm2 creation has been completed.」になるまで待ちます(クローン対象のディスク容量に応じて時間がかかります。)
完了したらvm2を起動してコンソールで接続し、IPアドレスとホスト名を変更します(手順は割愛)。
ライブマイグレーション
host3で起動中のvm1をオンラインのままhost2に移します。
上部メニューの仮想マシンタブを選択し、vm1を右クリックして移行を選択し、「移行先のホストを選択」でhost2を選択します。
最新メッセージが「Migration completed...」になったら完了です。vm1のホストがhost2になっていることも確認します
ゲストOS障害時のHA動作確認
watchdogを使ってゲストOSの障害を検知したら強制的に再起動をかける機能です。
すでに仮想マシン作成時に設定は済んでいますが念のため再度確認しておきます。上部メニューの仮想マシンタブにあるvm1を選択した状態で編集をクリックし、高可用性タブを選択して以下の点を確認します。
- 高可用性にチェックが入っていること
- ウォッチドッグモデルが「i6300esb」になっていること
- ウォッチドッグアクションが「リセット」になっていること
上記の設定になっていない場合は一度ゲストOSをシャットダウンして修正後、起動します。
次に、ゲストOSにwatchdogをインストールします。
[root@vm1 ~]# lspci | grep watchdog -i
00:08.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
→Watchdog Timerを認識していることを確認
[root@vm1 ~]# yum install watchdog
[root@vm1 ~]# vi /etc/watchdog.conf
(省略)
watchdog-device = /dev/watchdog
→コメントアウトを外します。
[root@vm1 ~]# systemctl start watchdog
[root@vm1 ~]# systemctl enable watchdog
Created symlink from /etc/systemd/system/multi-user.target.wants/watchdog.service to /usr/lib/systemd/system/watchdog.service.
以上で準備完了です。下記コマンドでカーネルパニックを起こしてゲストOSが再起動することを確認します。
[root@cent2 ~]# echo c > /proc/sysrq-trigger
ホスト障害時のHA動作確認
本機能はホストマシンの障害時に、そのマシンで動作していた仮想マシンを別のマシンで起動する機能です。これまでのoVirtはホストHAの機能を生かすにはIPMIのような電源管理機能が必要でしたが、バージョン4.1からホストHAにストレージのロックの仕組みによるスプリットブレイン回避の機能が追加されたことで、自宅等のIPMI非搭載マシンでもホスト障害時にVMの自動フェイルオーバーが可能になりました。
vm1がhost2で動いていることを確認し、host2を強制電源断します。
1分程度で検知してhost3でvm1の起動を試みていること(ステータスがWait For Launchになっていること)が確認できます。
本環境では2.5分程度でhost3上でvm1が起動しました。
続いて上部メニューのホストタブを選択すると、host2のステータスが「Non Responsive」状態になっているので、host2を起動して正常にクラスタに組み込まれるか確認します。
本環境では5分程度で組み込まれました。下部の最新メッセージを広げてみると組み込まれるまでの様子を確認できます。
最後に
oVirtは商用の仮想化製品の提供する様々な機能を無償で利用できる上に(十分な検証を行ったわけではないですが)動作もそれなりに安定しているように感じましたが、開発速度が速いため本記事もすぐに陳腐化する可能性がありますし、それゆえ不具合を引くケースもあるかと思います。何かあればコミュニティMLに質問してみたりMLアーカイブを探してみて下さい。日本ではマイナーですがコミュニティーは活発なので解決できるケースも多いと思います。そしてもちろんクリティカルな環境への導入時にはRed Hat社のサポートが受けられるRHEVを使うことをお勧めします。
参考文献
Hyperconverged Infrastructure using oVirt and Gluster
CentOS7.1にKVMハイパーバイザーを構築してoVirtで管理してみる Part.1
oVirt Blog
oVirt Users Archive
oVirt and Gluster hyper-converged!