フェールオーバークラスター環境における効率的なHyper-V運用

～Windows Server 2008 R2 Beta版移行・導入・運用の豆情報～

はじめに

サーバ仮想化技術が広まり、1台の物理サーバ上で複数のシステムを稼働させるケースが多くなりました。サーバを集約することでリソースを有効利用できるなど多くのメリットがありますが、その一方で物理サーバに障害が発生した場合に複数システムへ影響を及ぼすなど考慮すべき点もあります。仮想システムのように集約率の高いシステムを安心して運用し続けるためにはフェールオーバークラスターによって可用性を高めることが効果的です。

Windows Server 2008 R2のフェールオーバークラスターでは新機能が追加され、集約された仮想システムの運用性がより一層向上しています。今回はその一例と、フェールオーバークラスター環境におけるHyper-Vの運用について検証を行った際の気付きを紹介します。

フェールオーバークラスターの新機能

新機能を使用した運用改善～検証での気付き～

まとめ

フェールオーバークラスターの新機能

Windows Server 2008 R2のフェールオーバークラスターでは、新機能（設定）として「永続的なモード」、「自動開始」、「ClusterGroupWaitDelay」が追加されました。

永続的なモード

図1 フェールオーバークラスターの新機能の設定

クラスタサービスに登録されたサービス/アプリケーション（以下「クラスタリソース」と記載）が起動する際に、管理者が最後にオンライン操作を行ったノードでオンラインとなるように制御します。クラスタリソースとしてHyper-Vの仮想マシンを登録した場合は、既定でオンになっています。

このノードは「既定の所有者」と呼ばれ、管理者が最後にクラスタリソースの起動や移動を行ったノードが自動的に記録されます。なお、フェールオーバーによってクラスタリソースのノード移動が発生した場合、「既定の所有者」に登録されているノードは変更されません。この「既定の所有者」の他に、管理者が明示的に起動するノードを指定する「優先する所有者」の設定があります。

自動開始

クラスタサービス開始時にクラスタリソースを自動開始するか制御します。Windows Server 2008 R2では、この設定をオフにすることでクラスタサービス開始時にクラスタリソースを必ずオフラインにできます。クラスタサービス開始時は優先度の低いクラスタリソースはオフラインになるように設定しておき、順次手動で起動するといった運用が可能になります。クラスタサービス開始時のクラスタリソースの起動状況について表1にまとめています。

表1 クラスタサービス開始時のクラスタリソースの起動状況
		クラスタサービス停止時のクラスタリソースの状態
		オンライン	オフライン
「自動開始」の設定	オン	オンライン（自動開始）	オフライン
「自動開始」の設定	オフ	オフライン	オフライン

「自動開始」の設定がオンの場合は、Windows Server 2008のクラスタサービスと同様の動きになります。

クラスタサービス停止時にクラスタリソースがオフラインでも、サービス起動時に「オンライン」とする場合、Windows Server 2008と同様に「PersistentState」というパラメータを別途変更する必要があります。

設定がオンの場合、クラスタサービス停止時にクラスタリソースがオンラインであった場合のみオンライン（自動開始）となります。オフの場合はクラスタサービス停止時にクラスタリソースがどのような状況であってもオフラインになります。設定は既定ではオンになっています。

ClusterGroupWaitDelay

クラスタサービス開始時に「優先する所有者」または「既定の所有者」のノード以外でクラスタリソースが起動しないよう、クラスタリソースの起動を待ち合わせる最長の時間です。既定では「30」が設定されており、クラスタリソースの起動が可能になった時点から30秒の待ち合わせを行います。

このパラメータの確認/変更はGUIから行えず、PowerShellまたはClusterコマンドを使用する必要があります。

「永続的なモード」と「自動開始」の設定はクラスタリソース、「ClusterGroupWaitDelay」の設定はクラスタサービスごとに設定できます。

フェールオーバークラスター環境でHyper-Vを構築する場合、これらの新機能を使用することで運用性の向上が期待できます。

ページの先頭へ

新機能を使用した運用改善～検証での気付き～

これまでのクラスタサービス運用の課題

Windows Server 2008でフェールオーバークラスタサービスのメンテナンスを行う場合、以下の課題がありました。

メンテナンス完了後にクラスタサービスを再開すると仮想マシンがランダムなノードで起動するため、特定のノードに片寄ってしてしまう。

このような場合、管理者がそれぞれの仮想マシンを適切なノードへ手動で移動する必要があったため、不要な仮想マシンの移動やそれに伴い管理者が誤操作をしてしまうことがありました。さらに、1ノードで同時に仮想マシンが起動するため、CPU/メモリなどのリソース使用率が一時的に高くなり各仮想マシンの起動（クラスタリソースの再開）時間が遅れるなどの課題もありました。

Windows Server 2008 R2フェールオーバークラスターによる課題解決

Windows Server 2008 R2で追加された新機能を使用して、フェールオーバークラスター環境での課題解決を図2の検証環境で試みました。

図2 検証環境

検証では以下に紹介する設定を行い、クラスタサービスのメンテナンスを実施します。管理者はメンテナンス完了時にクラスタサービスを開始するだけで仮想マシンが期待するノード（「優先する所有者」で設定したノード）に分散して自動的に起動します。

課題解決のための設定

クラスタサービス開始後に、仮想マシンを「優先する所有者」に設定したノードで起動するための設定を行います。クラスタサービス起動時にどのノードで仮想マシンが起動するかは「優先する所有者」および「永続的なモード」の設定により異なります。検証ではまず、図3【設定1】～【設定4】の4パターンで仮想マシンの起動ノードの動作確認を行いました。

図3「優先する所有者」と「永続的なモード」設定に対する動作の違い

図3に紹介した【設定1】～【設定4】における「ClusterGroupWaitDelay」の時間内の仮想マシンの起動ノードについて図4にまとめます。

図4「ClusterGroupWaitDelay」の時間内における仮想マシンの起動ノード

【設定2】の設定を行うことで、仮想マシンは「ClusterGroupWaitDelay」の時間内であれば「優先する所有者」でのみ起動を試みます。これにより、クラスタサービス再開時に仮想マシンの起動ノードを分散することができるため、クラスタサービス開始時の仮想マシンの片寄りを防止できます。以下にWindows Server 2008 R2で追加されたフェールオーバークラスターの新機能を含めた設定方法について紹介します。

「優先する所有者」の設定
仮想マシンを起動させたいノードを「優先する所有者」として設定します。この設定を行うことで、優先的に仮想マシンが起動するノードを指定できます。

Windows Server 2008では「優先する所有者」を設定していても、不特定のノードで仮想マシンが起動していたため、制御できませんでした。
「永続的なモード」の設定
「永続的なモード」はオフに設定します。「永続的なモード」がオンの場合、図3【設定1】のように「ClusterGroupWaitDelay」の時間内であっても、「既定の所有者」のノードが「優先する所有者」に設定したノードより先に起動すると「既定の所有者」のノードで仮想マシンが起動してしまいます。
「ClusterGroupWaitDelay」の設定
ノードの起動時間に合わせてパラメータをカスタマイズします。システム環境によっては既定の待ち合わせ時間（30秒）を越えるため、期待するノード以外で仮想マシンが起動してしまいます。タイムアウトしないように、「ClusterGroupWaitDelay」の値を十分にとるようにパラメータを変更します。

「ClusterGroupWaitDelay」の値が大きすぎるとサービス開始時間の遅れに繋がります。お客様の要件に合わせて値を検討してください。
「自動開始」の設定と「PersistentState」変更スクリプトの作成
「自動開始」の設定は既定のオンから変更しません。ただし、クラスタサービスメンテナンス時には全ての仮想マシンを停止するため、表1で紹介したようにクラスタサービス再開時には仮想マシンが自動的に起動しません。そこでクラスタサービスを再開したときに管理者が手動で各仮想マシンを手動で起動する必要がないように以下の工夫をしました。

それぞれの仮想マシンは「PersistentState」というパラメータを持っています。このパラメータによってクラスタサービス起動時に仮想マシンを自動起動させるか制御できます。既定では仮想マシンが自動起動しない「False」に設定されていますが、自動開始するように「True」に変更します。「PersistentState」の設定変更を一括して行えるように、事前にスクリプトを作成します。

「PersistentState」を変更しない場合は、クラスタサービス再開後に各仮想マシンを手動で起動する必要があります。

メンテナンス作業の流れ

フェールオーバークラスタサービスのメンテナンス手順を紹介します。

図5 メンテナンス作業の流れ

仮想マシンの停止
起動中の仮想マシンを事前に手動で停止します。クラスタサービスを停止することで稼働中の仮想マシンを一括停止する運用（）も考えられますが、仮想マシンがダーティシャットダウンとなる場合があります（図6参照）。

クラスタサービス停止時に稼働中の仮想マシンをどのように停止するか（シャットダウン、保存など）設定できます。

図6 仮想マシンがダーティシャットダウンした状態
「PersistentState」変更スクリプトの実行
「課題解決のための設定」で作成したスクリプト（“「自動開始」の設定と「PersistentState」変更スクリプトの作成”を参照）を実行します。
クラスタサービス停止
仮想マシン以外のクラスタリソースも含めてクラスタサービスを停止して問題ないことを確認します。問題なければクラスタサービスを停止します。
クラスタサービスのメンテナンス実施と再開
クラスタサービスのメンテナンスを行い、業務再開時にクラスタサービスを再開します。クラスタサービスの再開と連動して仮想マシンが「優先する所有者」に設定したノードで自動的に起動します。

ClusterGroupWaitDelayのタイムアウトを見据えた構成

「ClusterGroupWaitDelay」で設定したパラメータ値を越える待ち時間が発生した場合、「優先する所有者」以外のノードで仮想マシンを起動することで業務が継続されます。ただし、「優先する所有者」のノードが起動した後も仮想マシンは管理者が期待するノード以外で起動し続けるため、片寄った状態のまま運用を継続することになります。

このような場合に備えて「フェールバック」機能を設定しておきます。「フェールバック」機能では「優先する所有者」で設定したノードが起動した時点で、仮想マシンをQuick Migrationと同様に短い停止時間で移動させます。既定ではオフになっているため、クラスタサービスメンテナンス前に設定を行う必要があります。また、フェールバックを実行する時間帯を指定することもできるため、業務負荷の低い夜間にフェールバックを実行するといったお客様環境に合わせた運用も可能です。

図7 フェールバックの設定

ページの先頭へ

まとめ

今回はWindows Server 2008 R2のフェールオーバークラスターの新機能を使用したHyper-Vシステムの運用性向上と、特にフェールオーバークラスタサービスメンテナンス時の仮想マシン配置に関する課題解決について紹介しました。ここで紹介した設定で運用を行う際は、お客様の環境や要件に合わせて事前に十分な設計/検証を行ってください。

なお、クラスタ環境におけるHyper-Vの運用向上機能として、富士通のミドルウェア「ServerView Resource Coordinator VE」の「VMホームポジション」があります。クラスタ環境でHyper-Vを運用する中で仮想マシンの移動が多く行われた結果、特定のノードに仮想マシンが片寄るケースがあります。このような状態でも1アクションで仮想マシンを設計時のノードへ戻せるため、管理者が操作ミスをすることなく簡単な運用が期待できます。その他にも「ServerView Resource Coordinator VE」では、物理/仮想サーバの導入から運用を助ける有用な機能を提供します。