Show page source of SIGMABLADE-SSC_2p6 #20771

'''[SIGMABLADE-SSC_2p1 SIGMABLADE+SigmaSystemCenterによる仮想マシンの自律運用システム]'''

== 物理サーバへのポリシー適用

仮想マシンの次は、物理サーバ用のポリシーを用意します。今回の目的は、「物理サーバの障害発生時に仮想マシンを残りの物理サーバに待避する」と「負荷状況に応じて仮想マシンの配置を最適化する」の2つです。設定が難しそうですが、実はこれらのルールはあらかじめVMサーバ用の標準ポリシーに定義されているので、そのまま物理サーバに適用するだけで利用できます。

== 物理サーバ障害発生時の仮想マシンの移動

VMサーバ用の標準ポリシーは、通常版と省電力版の2つが用意されています。ポリシー一覧で説明が「VMサーバ用省電力のポリシーテンプレート」となっているのが省電力版で、その下が通常版です。省電力版のポリシーには、通常版のルールに加え低負荷時に仮想マシンを少数の物理サーバに集約して余剰の物理サーバの電源をオフにするルールが追加されています。今回は省電力版を利用します。

[[Thumb(sigma2:2-09-01-policylist.png, size=450x400, caption=ポリシー一覧)]]

まずはどのようなルールが定義されているのかを確認しておきましょう。省電力版ポリシーの「プロパティ」アイコンをクリックしてポリシープロパティ設定画面を開き「監視イベント」タブをクリックします。ご覧のように、省電力版ポリシーには6つの監視イベントが設定されています。このうち、物理サーバの障害発生は「ターゲットアクセス不可」イベントです。このイベントの対応処置は「VMS上の全VM移動」となっています。

[[Thumb(sigma2:2-09-02-vmspolicy1.png, size=450x400, caption=省電力版ポリシーの「監視イベント」タブ)]]

「ターゲットアクセス不可」イベントの「編集」アイコンをクリックして詳しい設定内容を見てみましょう。ご覧のように、「区分全てのイベントを対象とする」がチェックされ、「イベント区分」は「その他」になっています。これは「ターゲットアクセス不可」イベントが複数のイベントをまとめた“合成イベント”であることを意味します。この合成イベントにどのようなイベントが含まれるているのかは「合成イベント一覧」のドロップダウンリストで確認できます。

[[Thumb(sigma2:2-09-03-vmspolicy2.png, size=450x400, caption=「ターゲットアクセス不可」イベントの詳細設定)]]

さて、このイベントに対するアクションとしては以下の3つが設定されています。

 * 通報/ E-mail通報、ESMPRO通報
 * マシン設定/ ステータス設定 故障
 * VMS操作/ VMS上の全てのVM移動(Hot Migration/Cold Migration, Failover)

すなわち、障害発生を通報してから、物理サーバのマシンステータスを故障に変更し、それから当該物理サーバに配置されていた仮想マシンを別な物理サーバに移動させるわけです。なお、VM操作アクションの括弧内に「Hot Migration/Cold Migration, Failover」と書かれているのは、仮想マシンを移動させる際に「Hot Migration/Cold Migration」(稼働状態を保持した移動)を試してみて、それが失敗した場合に「Failover」(移動先でのコールドブート)を実行することを意味します。もっとも、物理サーバにアクセス不可障害が検出された時点で「Hot Migration/Cold Migration」の成功は望み薄ですので、仮想マシンの状態保持よりも復旧時間の短縮を優先させたい場合はいきなり「Failover」を実行するようにしてもよいでしょう。その場合は3つ目のVMS操作アクションを「VMS操作/ VMS上の全てのVM移動(Failover)」に変更します。

監視イベントを確認したところで、次にこのポリシーを以下の手順で物理サーバに適用します。

 * タイトルバーの「運用」をクリック
 * ツリービューで対象グループ(ここでは「ESX」)をクリック
 * 「設定」メニューの「プロパティ」をクリック
 * 「全般」タブをクリック
 * 「ポリシー名」のドロップダウンリストで適用するポリシー、ここでは「標準ポリシー(仮想マシンサーバ 省電力)」を選択
 * 「戻る」をクリック

[[Thumb(sigma2:2-09-04-policyapply.png, size=450x400, caption=物理サーバへのポリシー適用)]]

== 動作テスト

ポリシーを適用したところで、ひとまず動作テストを行ってみます。今回は物理サーバ「esx2」の電源を落としてアクセス不可状態にしました。下は障害発生時の「オペレーションウィンドウ」の画面です。「オペレーションウィンドウ」はExpress5800シリーズに標準添付されている管理ソフトウェア、ESMPRO/ServerManagerの付属ツールで、これを使うと障害がどこで発生しているのか視覚的に把握することができます。この画面では、障害が発生したesx2が警告色の赤で表示されています。

[[Thumb(sigma2:2-10-01-policytest1.png, size=450x400, caption=障害発生時のオペレーションウィンドウ)]]

こちらは障害検出直後のSSCの運用ビュー(ESXグループの情報)です。異常が検出された「esx2」に通行止めマークが付いています。

[[Thumb(sigma2:2-10-02-policytest2.png, size=450x400, caption=障害発生時の運用ビュー)]]

こちらは障害検出直後の仮想ビューです。ツリービューを見るとわかるように、障害検出直後は仮想マシンの配置はまだ変わっていません。

[[Thumb(sigma2:2-10-03-policytest3.png, size=450x400, caption=障害発生時の仮想ビュー)]]

しばらくしたら仮想ビューの「操作」メニューにある「画面更新」をクリックします。下のようにesx2上にあった仮想マシンがesx1に移動していれば動作テストは成功です。

[[Thumb(sigma2:2-10-04-policytest4.png, size=450x400, caption=仮想マシン移動後の仮想ビュー)]]

----
=== 目次
 * [SIGMABLADE-SSC_2p1 1/8 システム構成と使用機材]
 * [SIGMABLADE-SSC_2p2 2/8 サブシステムとリソースの登録]
 * [SIGMABLADE-SSC_2p3 3/8 物理サーバグループと仮想マシングループの設定]
 * [SIGMABLADE-SSC_2p4 4/8 マスタマシンの登録と手動ライブマイグレーション]
 * [SIGMABLADE-SSC_2p5 5/8 仮想マシン用ポリシーの作成と適用]
 * 6/8 物理サーバ障害時の仮想マシン移動 <=
 * [SIGMABLADE-SSC_2p7 7/8 仮想マシンの最適配置]
 * [SIGMABLADE-SSC_2p8 8/8 仮想マシン最適配置の動作テスト]
----