注目トピック

Wikiガイド

最近の更新

2018-08-20
2013-10-30
2013-02-06
2011-06-22
2010-08-13
2009-03-27
2008-11-14
2008-11-13
2008-10-01
2008-09-19

SIGMABLADE+SigmaSystemCenterによる
仮想マシンの自律運用システム

エンタープライズコンピューティングの分野において、この5年間で最も大きな変化の1つが「仮想化」です。メインフレームなどの大規模コンピュータでは以前から仮想化技術が使われていましたが、ハードウェアの高性能化により現在では一般的なPCサーバでも仮想化技術が使えるようになりました。仮想化はコンピュータリソースを“プール”として抽象化するために必須の技術となりつつあり、これをうまく導入することで企業は自社のリソースを効率よく分配することが可能になります。

一方、システム管理者にとって仮想化技術の導入は、管理レイヤの増加も意味します。管理レイヤが増えて管理の手間が増えるようでは、仮想化の導入メリットも半減してしまいます。そこでここではNECのブレードサーバ「SIGMABLADE」と管理ツールの「SigmaSystemCenter 2.0」(SSC)を用いて、仮想マシンシステムを構築する手順を紹介します。SSCは仮想化に対応した統合管理プラットフォームであり、物理的なサーバで動作するホストと仮想マシンで動作するホストを単一のコンソールから統一的に管理することが可能です。

SSCで実現する機能

今回構築するシステムでは、以下の2つの機能を実現することを目標とします。

  • 物理サーバ(ブレード)の障害を検出し、その上で動作していた仮想マシンを別な物理サーバ上で自動的に起動する。
  • 負荷状況に応じて仮想マシンの物理サーバへの割り当てを最適化する。

なお、SSCは仮想化プラットフォームとしてVMware ESX ServerとCitrix XenServerの2つに対応していますが、今回はESX Serverを利用することにしました。作業内容にわずかな違いはあるものの、XenServerを利用する場合でも上記の目標は実現できます。ちなみにSSCの将来のバージョンでは、MicrosoftのHyper-Vにも対応する予定です。

システム構成と使用機材

今回構築するシステムの構成は以下のとおりです。

  • 管理対象サーバ
    • 物理サーバ(SIGMABLADE Express5800/120Bb-6×2台)
      • VMware ESX Server
      • ホスト名:IPアドレス
        • esx1:192.168.1.231
        • esx2:192.168.1.232
    • 仮想マシン(3台)
      • Windows Server 2003 Standard Edtion
      • ホスト名:IPアドレス
        • VM-01:192.168.1.236
        • VM-02:192.168.1.237
        • VM-03:192.168.1.238
  • 収納ユニット(SIGMABLADE-M
  • ストレージ(iStorage S1500(FC接続))
  • 管理サーバ(Express5800/120Rh-2)
    • Windows Server 2003 Standard Edtion
    • VMware VirtualCenter
    • SigmaSystemCenter
    • ホスト名:IPアドレス
      • 120Rh-2:192.168.1.120

上記のように、2台のブレードサーバ上で3台の仮想マシンを運用します。仮想マシンは4台でも5台でもかまいませんが、仮想マシンの必要とするリソースが物理サーバのキャパシティを超えないようにサイジングには十分注意する必要があります。

事前の作業

管理サーバにはあらかじめVirtualCenterをインストールしておきます。また、DHCPサーバとIIS、ASP.NETもWindows Serverのインストールメディアからインストールしておきます。

一方、ブレードにはESX Serverをインストールし、仮想マシンの作成とOSのインストールを済ませておいてください。今回はマイグレーション(物理サーバ間での仮想マシンの移動)を利用する関係上、仮想マシンの構成ファイル群を共有ストレージ上に配置する必要があります。それとブレードにはSIGMABLADEおよびExpress5800の管理ツール「ESMPRO/ServerAgent」もインストールしておきます。このServerAgentは、ブレードの障害監視を行うために必要となります。

このほか、事前に済ませておく作業には以下のものがあります。これらの手順はこちらの記事ですでに説明していますので、詳しくはそちらを参照してください(下記のリンクをクリックすると当該作業の解説箇所が参照できます)。

なお、管理対象サーバのDPMへの登録は物理サーバと仮想マシンの双方で行う必要があります。同様にSSCエージェント(実際はDPMのエージェント)も物理サーバと仮想マシンの両方にインストールしてください。ESX ServerはLinuxベースなのでLinux版のエージェントをインストールします。一方、今回仮想マシンではWindowsを利用するので仮想マシンにはWindows用のエージェントをインストールします。


目次



2ページ目


サブシステムの登録

管理機能がコンポーネント化(サブシステム化)されているSigmaSystemCenter(SSC)では、あるサブシステムの機能を利用するためには、そのサブシステムをSSC本体に登録しておく必要があります。

まず、DeploymentManager(DPM)を登録します。DPMはシステム構成管理機能を提供するサブシステムです。SSCの管理ビューを開き(タイトルバーの「管理」をクリック)、左ペインのツリービューにある「サブシステム」をクリックします。右サイドバーの「設定」メニューにある「サブシステム追加」をクリックすると下の画面が表示されるので、「サブシステム種類」ドロップダウンリストで「Webサーバ for DPM」を選択、「パスワード」および「パスワード確認」にSSCのインストール時に設定したDPMの管理パスワードを入力して「OK」をクリックします。

サブシステムの一覧画面に戻ったら、再度「設定」メニューの「サブシステム追加」をクリックして、仮想化サブシステムを追加します。今回はVMwareを利用するので、「サブシステム種類」で「VMware VirtualCenter」を選択します。残りの項目は以下のように設定します。

  • ホスト名:VirtualCenterがインストールしてあるサーバのホスト名もしくはIPアドレス
  • ポート:VirtualCenterの待ち受けポート番号
  • アカウント名:VirtualCenterの管理アカウント名
  • パスワード/パスワード確認:管理アカウントのパスワード

上記の項目を入力したら「OK」をクリックしてください。

さて、SSCにはVMware用のサブシステムとして「VMware VirtualCenter」のほかに「VMware ESX Server」があります。ただし、こちらはVirtualCenterを登録するとそのVirtualCenterで管理しているESX Serverが自動的に検出/登録されるので、手動で登録する必要はありません。VirtualCenter登録後に「サブシステム一覧」画面の「操作」メニューで「画面更新」をクリックすると、ESXサーバがサブシステム一覧に追加されているはずです(追加されていない場合は少し時間を置いて画面を更新してみてください)。

もっとも、ESX Serverが検出されただけでは、後ほど説明する「Failover」などの操作をSSCから実行することができません。そこで追加の設定を行います。「サブシステム一覧」のESX Serverの右端にある「編集」ボタンをクリックして下の画面を開いてください。「ホスト名」および「ポート」には自動検出された値が設定されているので、「アカウント」に管理者アカウントの「root」を入力し、「パスワード更新」をチェックして「パスワード」と「パスワード確認」にrootのパスワードを入力して「OK」をクリックします。今回は物理サーバが2台なので、2台それぞれで追加の設定を行います。

なお、今回は仮想マシンの構成ファイルを格納するために共有ストレージ(iStorage)を利用しますが、物理サーバ間で1つのボリュームを共有する(個々の物理サーバごとに特定のボリュームをひも付ける必要がない)ため、SSCからはiStorageを意識する必要はありません。そのため、「iStorageManager」サブシステムは登録してなくても結構です。

リソースの登録

サブシステムの登録が終わったら、次に管理対象となるマシンをSigmaSystemCenter(SSC)に登録します。マシン登録の基本的な手順は次のようになります。

  1. グループの作成
  2. グループにマシンを登録

まず、グループを作成しましょう。タイトルバーの「リソース」をクリックしてリソースビューを開き、ツリービューの「マシン」をクリックして「マシン一覧」画面に移動します。

グループを作成するには「設定」メニューの「グループ追加」をクリックします。すると、下の画面が開くので、「名前」に分かりやすいグループ名を付けて「OK」ボタンをクリックします。今回は物理サーバのグループ「SIGMABLADE」と仮想マシンのグループ「VM」を作成しました。

下はグループ作成後の「マシン一覧」画面です。ツリービューの「マシン」の下に作成したグループが追加されているのが分かります。

次に、グループにマシンを登録します。「設定」メニューの「マシン登録」をクリックしてください。すると、下の「管理外のマシン一覧」画面になります。ここでは登録するマシンにチェックを入れ、下の「親のリソース」から所属グループを選択して「OK」をクリックします。まず「esx1」と「esx2」をチェックして「親のリソース」で「SIGMABLADE」を選択して「OK」をクリック。再度「管理外のマシン一覧」画面を開いて「VM-01」、「VM-02」、「VM-03」にチェックを入れ「親のリソース」で「VM」を選択して「OK」をクリックします。

マシン登録後の「マシン一覧」画面です。

以上でマシン登録は終了です。


目次



3ページ目


運用設定

ここまでの作業で、管理対象リソースをSigmaSystemCenter(SSC)に登録することができました。ここからは、登録したリソースをどのような用途でどのように利用するのかといった設定を定義していきます。このような運用に関する設定は運用ビュー(タイトルバーの「運用」をクリック)で行います。

カテゴリ/グループの作成

運用ビューで最初に行う作業は“カテゴリ”の作成です。カテゴリはリソースを用途ごとに分類するための概念で、「受発注システム」や「文書管理システム」といったようなシステムの用途ごとに作成します。

カテゴリを作成するには、運用ビューの「設定」メニューにある「カテゴリ追加」をクリックします。すると下の画面が表示されるので、「名前」にカテゴリ名を入力して「OK」をクリックしてください。ここでは「生産システム」というカテゴリを作成しました。

カテゴリを追加したら、次にそのカテゴリにグループを追加します。グループはシステムを構成するサーバの種類ごとに作成します。今回のシステムでは2台の物理サーバ上で3台の仮想マシンを運用します。そのため、物理サーバのグループ「ESX」と仮想マシンのグループ「VM」を作成することにします。運用ビューの「設定」メニューにある「グループ追加」をクリックし、下の画面を開きます。「名前」にグループ名を入力し、「OS種別」のドロップダウンリストから当該グループで利用するOSを選んで「OK」をクリックします。ESX ServerはLinuxベースなので、「ESX」グループの「OS種別」は「Linux」にします。同様に仮想マシンのグループ「VM」も作成してください。

グループ追加後の運用ビュー(カテゴリ/グループ一覧)です。

物理サーバグループの設定

次にグループの詳細設定を行います。ツリービューにあるグループ名(ここでは「ESX」)をクリックすると、下の画面のように対象グループの情報が表示されます。グループの設定を編集するには、「設定」メニューの「プロパティ」をクリックしてグループのプロパティ設定画面を開きます。

グループの設定項目は、複数のタブに分けて分類されています。最初に設定するのは「モデル」タブです。「モデル一覧」に右上にある「追加」をクリックすると、その下に「モデル追加」の枠が表示されます。ここの「名前」にはサーバの機種名などを設定します(ここでは「120Bb-6」)。また「種別」のドロップダウンリストでは「物理」、「VM」、「VMサーバ」の中からそのサーバに合致するものを選択します。ESXグループのように仮想マシンのホストとなるグループでは「VMサーバ」を選択してください。「OK」をクリックしてモデルを追加します。

次に「ホスト」タブに移動します。「ホスト一覧」の右上にある「追加」をクリックすると「ホスト追加」の枠が表示されるので、「ホスト名」を入力して「OK」をクリックします。ここでは物理サーバのホスト名「esx1」を入力しました。

ホスト追加後の「ホスト」タブの画面です。「ホスト一覧」に追加したホスト「esx1」が表示されていますが、esx1のIPアドレスは「自動取得」となっています。そこで、固定アドレスを割り当てるように設定を変更します。ホストの設定を変更するには、当該ホストの行にある「プロパティ」アイコンをクリックします。

ホスト設定画面が開いたら「ネットワーク」タブをクリックします。IPアドレスを設定するには、NICの枠内にある「追加」をクリックします。すると下に「IPアドレス設定」の枠が表示されるので、「IPアドレス」、「サブネットマスク」、「デフォルトゲートウェイ」をそれぞれ入力して「OK」をクリックします。複数のNICを利用するサーバでは、NICのタブを切り替えてNICごとにIPアドレスを割り当ててください。

IPアドレス設定後の「ネットワーク」タブです。設定したIPアドレスは「管理用IPアドレス」のドロップダウンリストに追加されているので、SSCからの管理に用いるIPアドレスを選択して「戻る」ボタンをクリックします。

以上で物理サーバのホスト「esx1」が設定できました。同様の手順(ホスト追加~IPアドレスの設定)を繰り返して、「esx2」も設定してください。下はesx2設定後のホスト一覧(グループプロパティの「ホスト」タブ)です。

仮想マシングループの設定

続けて仮想マシンのグループ「VM」も設定します。手順は物理サーバグループ「ESX」のときとほとんど同じで、「モデル追加」→「ホスト追加」→「IPアドレス設定」の順に作業します。ただし、モデルを定義する際は「種別」で「VM」を選択する点に注意してください。また「名前」にはそれが仮想マシンであることが分かるような名前を付けるとよいでしょう。

ホスト追加とIPアドレス設定の方法は物理サーバのときとまったく同じです。下は3台の仮想マシン「VM-01」、「VM-02」、「VM-03」にそれぞれIPアドレスを設定した状態のホスト一覧(グループプロパティ設定の「ホスト」タブ)です。


目次



4ページ目


マスタマシンの登録

ここまでの作業で、システムを構成するサーバの定義をSigmaSystemCenter(SSC)に追加することができました。次はこのサーバの定義にリソースを割り当てます。まずはESXグループのホストにリソースを割り当ててみましょう。運用ビューのツリービューでESXグループをクリックすると、グループの情報が表示されます。「ホスト一覧」の中からリソースを割り当てるホスト(ここでは「esx1」)をチェックし、アクションメニューから「マスタマシン登録」を選択してください。

すると、割り当てるマシンを選択する画面が表示されます。ここには登録済みのリソースの中から、対象ホストのモデルに適合するものだけがリストアップされます。割り当てるマシンのラジオボタンをチェックして「次へ」をクリックします。

マスタマシン登録の確認画面が表示されるので、間違ったマシンを選択していないことを確認してから「完了」をクリックしてください。

グループの情報画面に戻るので、同じ手順で2台目の物理サーバホスト「esx2」にもマスタマシンを登録します。下は、2台の物理サーバにマスタマシンを登録した状態です。

仮想マシンのホスト定義にも物理サーバと同じようにしてマスタマシンを登録します。下は、3台の仮想マシンにマスタマシンを登録した状態です。

手動でのライブマイグレーション

以上の作業により、システム構成定義と管理対象サーバ(リソース)の対応関係がSSCに設定されました。目標の自律運用を実現するには運用ポリシーを作成して適用する必要がありますが、この段階でも手動での制御はSSC上から行えます。そこで、テストを兼ねて手動でのライブマイグレーションを行ってみることにしましょう。“ライブマイグレーション”(VMwareの用語では「VMotion」)は、仮想マシンを稼働させたままの状態で、物理サーバ間で移動させることを指します。

SSCでは、仮想マシンの状態確認や手動での制御は仮想ビューから行います(タイトルバーの「仮想」をクリック)。ツリービューを確認すると、物理サーバ「esx1」上で仮想マシン「VM-01」、「VM-02」が動作しており、物理サーバ「esx2」上で仮想マシン「VM-03」が動作していることが分かります。ここではVM-02をesx1からesx2に移動してみます。ちなみに仮想マシンの制御は運用ビューから行うこともできますが、仮想ビューのほうが仮想マシンの配置状況が把握しやすいのでオペレーションミスの発生を防ぎやすいでしょう。

仮想マシンを移動させるには、まずツリービュー上で当該仮想マシンが使用している物理サーバをクリックして選択します。表示された画面を中ほどまでスクロールすると「稼働中VM一覧」という枠があるので、移動させる仮想マシンをチェックして、アクションメニューの「VM移動」をクリックしてください。

「VM移動」をクリックすると、移動先の物理サーバと移動方法を選択する画面が表示されます。今回は物理サーバが2台しかないので、移動先候補は「esx2」だけが表示されています。移動先候補が複数存在する場合は適切な移動先をチェックしてください。一方、移動方法としては以下の3つが用意されています。

  • Hot Migration/Cold Migrationを行います:仮想マシンを稼働状態を保持したまま移動します。
  • Moveを行います:いったん仮想マシンをシャットダウンし、ディスクイメージを物理サーバ間で移動させてから移動先で仮想マシンを起動します
  • Failoverを行います:仮想マシンを障害が発生した物理サーバから正常稼働中の物理サーバに移動します。仮想マシンの稼働状態は保持されず、コールドブートします。

このうち、「Hot Migration/Cold Migrationを行います」と「Failoverを行います」は共有ストレージ上に仮想マシンの構成ファイルが存在する場合にのみ利用することができます。残りの「Moveを行います」は仮想マシンの構成ファイルを物理サーバのローカルディスク上に置く場合の移動方法となります。ここでは、仮想マシンを稼働させたまま移動させたいので「Hot Migration/Cold Migrationを行います」をチェックします。移動先と移動方法を選択したら「OK」をクリックします。

下は仮想マシンを移動させたあとの仮想ビューです。ツリービューを見ると、「VM-02」が「esx2」に移動していることが分かります。なお、仮想マシンの移動がツリービューに反映されていない場合は「操作」メニューの「画面更新」をクリックしてみてください。


目次



5ページ目


運用ポリシーの設定

ここからは障害発生時や負荷変動に応じて仮想マシンを制御するための運用ポリシーの設定を行います。このポリシーは「あるイベントが発生した際にどのようなアクションを実行するか」というルールの集まりです。ポリシーの設定は管理ビュー(タイトルバーの「管理」をクリック)で行います。管理ビューを開いたらツリービューにある「ポリシー」をクリックし、「ポリシー一覧」を表示させます。

ご覧のように、ポリシー一覧にはあらかじめ3種類の標準ポリシーが用意されています。ただし、これらの標準ポリシーは物理サーバ用のもので、仮想マシン用のものは用意されていません。そこで最初に仮想マシン用ポリシーを作成することにします。

なお、物理サーバ用のポリシーを作成する際は「標準ポリシーをコピーして変更を加える」という方法を取るのが一般的です。しかし、(当然のことですが)仮想マシンではハードウェア障害は発生しませんから、細かなルールを定義する必要はありません。仮想マシンにアクセスできなくなったら、その理由が何であれ再起動を実行するといったルールを定義しておけば十分でしょう。そこで、仮想マシン用のポリシーは一から作成することにします。

仮想マシン用ポリシーの作成

ポリシーを一から作成するにはポリシー一覧の画面で「設定」メニューにある「ポリシー追加」をクリックします。すると、下のポリシー追加画面が表示されるので、「名前」にポリシー名を入力して「OK」をクリックします。ここではポリシー名を「VM用ポリシー」としました。

ポリシー一覧に中身が空の新しいポリシーが追加されます。当該ポリシーの「プロパティ」アイコンをクリックしてください。

ポリシープロパティ設定画面が開いたら、「監視イベント」タブをクリックします。ご覧のように監視イベントは一つも登録されていません。そこで監視イベントを追加するためにアクションメニューの「追加」をクリックします。

この画面(対応処置詳細設定(新規))では、監視するイベントの情報とそのイベントが発生した際に実行するアクションを設定します。イベント情報の項目は以下のように設定します。

  • 名前:イベント発生時に実行する対応処置(アクション)の名前。ここでは「VMアクセス不可能状態」としました。
  • イベント区分:イベントのタイプ。ドロップダウンリストから選択します。ここでは「マシンアクセス不可能状態」を選択しました。このイベントはSSCから対象サーバにアクセス出来なくなった際に発生します。アクセスできなくなった理由については問われません。
  • 通報元:イベントの通報元となるサブシステム。ドロップダウンリストから選択します。ここでは「VMwareProvider」を選択しました。
  • イベント:イベントのタイプ。ドロップダウンリストから選択します。ここでは「Alarm Virtual Machine Heatbeat on VM changed form green to red」を選択しました。これはVMwareの仮想マシンがハートビート信号に応答しなくなったときに発生するイベントです。
  • イベント名:イベントの名前。標準では「イベント」と同じ内容が入力されます。特に書き換える必要はありません。

イベントの情報を定義したら、「イベントに対する復旧処理」の枠内で実行するアクションを設定します。ここでは、1番目のアクションとして「通報/ E-mail通報、ESMPRO通報」を設定し、2番目のアクションとして「マシン操作/ マシン再起動」を設定しました。イベントの記録を残すために1番目のアクションには「通報」を必ず設定するようにしてください。

イベント追加後のポリシープロパティ設定画面(「監視イベント」タブ)です。次に、作成したポリシーを仮想マシンに適用します。

ポリシーの適用は、運用ビューのグループプロパティ設定画面で行います。手順は以下のとおりです。

  • タイトルバーの「運用」をクリック
  • ツリービューで対象グループ(ここでは「VM」)をクリック
  • 「設定」メニューの「プロパティ」をクリック
  • 「全般」タブをクリック
  • 「ポリシー名」のドロップダウンリストで適用するポリシー(ここでは「VM用ポリシー」)を選択
  • 「戻る」をクリック

以上で仮想マシンへのポリシー適用は終了ですが、仮想マシンのOSによっては多少手を加える必要があります。たとえば、Windows Serverには回復不可能なシステムエラー(いわゆる“ブルースクリーン”)が発生したときに自動的にシステムを再起動する機能が備わっていますが、この機能とSSCからの再起動指令がバッティングする可能性があります。Windows Serverの自動再起動はブルースクリーン発生時にしか機能しませんが、SSCからの再起動指令はそれ以外の場合(たとえば何らかのサービスがスタックしてOS全体が反応しなくなったような場合)でも有効です。そこでWindows Server側の当該機能はオフにしておいてください。Windows Server 2003の場合は、コントロールパネルの「システム」→「詳細設定」タブ→「起動と回復」の「設定」ボタンと進み、「システムエラー」の「自動的に再起動する」のチェックを外します。

なお、上記の画面には「デバッグ情報の書き込み」というセクションがあります。これはシステムがクラッシュした際にメモリダンプを採取するためのオプションですが、これを利用する場合はメモリダンプ中にSSCからの指令で再起動が掛からないようにアクション実行に遅延時間を設定してください。そのためには、ポリシープロパティ設定画面(「管理ビュー」→「ポリシー」→「ポリシー一覧」→当該ポリシーの「プロパティ」アイコンをクリック)の「全般」タブで「抑制設定」にある「サーバアクセス不可障害の抑制(仮想コンピュータ)」をチェックし、遅延時間(秒数)を設定します。メモリダンプの所要時間はメモリ割り当て量やディスク性能によって変動しますので、適宜調整する必要があります。


目次



6ページ目


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

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

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

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

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

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

さて、このイベントに対するアクションとしては以下の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」)をクリック
  • 「設定」メニューの「プロパティ」をクリック
  • 「全般」タブをクリック
  • 「ポリシー名」のドロップダウンリストで適用するポリシー、ここでは「標準ポリシー(仮想マシンサーバ 省電力)」を選択
  • 「戻る」をクリック

動作テスト

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

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

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

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


目次



7ページ目


仮想マシンの最適配置

最後に負荷変動に応じて仮想マシンの配置が最適化されるようにします。下は先ほども登場した省電力版ポリシーの「監視イベント」タブです。省電力版ポリシーには仮想マシンの配置ルールが2つ用意されています。1つは「高負荷検出(SysmonPerf)」イベントに対応する「負荷分散」アクションで、もう1つは「低負荷検出(SysmonPerf)」イベントに対応する「省電力」アクションです。前者は、ある物理サーバが高負荷状態になったときにより低負荷な物理サーバに仮想マシンを移動させて負荷分散を図るルールで、通常版のポリシーにも登録されています。後者は物理サーバの負荷が低くなった際に仮想マシンを集約して稼働状態の物理サーバを減少させるルールで、こちらは省電力版ポリシーのみに登録されています。

まずは「高負荷検出(SysmonPerf)」イベントの詳細設定を見てみましょう。下の画面のように「通報元」に「SystemMonitorPerf」が設定されています。これはSigmaSystemCenter(SSC)に付属する「SystemMonitor性能監視」(SystemMonitor)ツールのことです。SSCはこのSystemMonitorから高負荷検出イベントを受け取ると、仮想マシンの移動による負荷分散を図ります。

次は「低負荷検出(SysmonPerf)」イベントの詳細設定です。こちらでもSystemMonitorから低負荷検出イベントを受け取ると、SSCが仮想マシンの集約と余剰物理サーバの電源オフを実行するようになっています。

上記のように標準ポリシーには仮想マシンの配置を最適化するルールが組み込まれていますが、これらのルールを有効に機能させるには2つほど追加の設定を施す必要があります。1つは、どの程度のCPU使用率で低負荷あるいは高負荷と判断するのかその閾値の設定です。そしてもう1つは、仮想マシンの移動を実行するタイミングの設定です。

閾値は、物理サーバのハードウェアスペックに依存するのでモデルのプロパティで設定します。運用ビューのツリービューで物理サーバのグループ(ESX)を選択し、「設定」メニューの「プロパティ」をクリックしてグループプロパティ設定画面が開きます。「モデル」タブをクリックするとモデル一覧が表示されるので、対象モデル(ここでは「120Bb-6」)の「プロパティ」アイコンをクリックしてください。

モデルプロパティ設定画面が開いたら、「VM最適配置」タブに移動します。ここでは、「VM最適配置を有効にする」をチェックし、「高負荷境界」、「稼働目標域」、「低負荷境界」のそれぞれのフィールドに閾値となるCPU使用率を設定します。ここではそれぞれのフィールドを以下のように変更しました。

  • 高負荷境界:70%
  • 稼働目標域:10 - 60%
  • 低負荷境界:5%

「VM最適配置」タブには、もう1つ重要な項目があります。画面の下にある「マシン台数」のドロップダウンリストで、その上の説明書きにあるように、ここには電源を落とさずに待機させておく余剰物理サーバの台数を設定します。たとえば、3台の物理サーバが存在するシステムで「低負荷検出(SysmonPerf)」イベントの発生によりすべての仮想マシンが1台の物理サーバに集約されたとします。このとき余剰物理サーバは2台になりますが、2台とも電源を落としてしまうと急激に負荷が上昇した際にスムーズな負荷分散が行えません。そこで、電源を落とさずに待機させておく物理サーバを確保しておくわけです。待機物理サーバの数を減らせば消費電力を削減できますが、その分、急激な負荷変動に追従できないおそれが出てきます。そのため、待機物理サーバの数は、システム規模(物理サーバの台数)や仮想マシンの稼働パターンを考慮して決めるようにしてください。

SystemMonitorの設定

上で説明したように、SSCはSystemMonitorからサーバの負荷情報を取得します。そこで次にSystemMonitorの設定を行います。スタートメニューから「すべてのプログラム」→「SigmaSystemCenter」→「SystemMonitor管理コンソール」を選択して、SystemMonitorを起動してください。SystemMonitorを最初に起動した際には、下のログオン画面が表示されます。ここには、管理サーバにログオンするためのユーザ名とパスワードを入力して「OK」をクリックします。

SystemMonitorのメインウィンドウが表示されたら、ツリービューの右クリックメニューから「グループ設定」を選択して、監視対象グループを設定する画面を表示します。この画面の「全般」タブでは、「グループ名」にSSCの運用ビューで設定したカテゴリ名(ここでは「生産システム」)を入力します。さらに、「SystemProvisioningのグループ/モデルから構成を反映する」をチェックし、その下の「パス」欄に監視対象サーバのモデル情報へのパスを「カテゴリ名\グループ名\モデル名」の形式で入力します(ここでは「生産システム\ESX\120Bb-6」)。最後に「構成反映時にIPアドレス情報を配下のマシンに反映する」をチェックします。

「全般」タブの設定が済んだら、次に「接続」タブを開きます。「接続」タブでは監視対象サーバにアクセスするための情報を設定します。「アカウント」には「root」を、「パスワード/パスフレーズ」にはrootのパスワードを入力します。なお、「プロトコル」には「Telnet」を選択すれば良いでしょう。設定が済んだら、「OK」をクリックします。

SystemMonitorのメイン画面が表示されたら、「ツール」メニューから「SystemProvisioning 構成一括反映」を選択します。これにより、SSC本体から管理対象ホストと閾値の情報がインポートされて、ツリー上にグループ名とその配下の物理サーバが表示されます。このグループ名を右クリックし、表示されたメニューで「閾値監視設定」を選択すると下の画面が表示されます。ここでは、右上の「閾値定義」にある「高負荷閾値監視定義」を選択して「変更」をクリックします。

閾値定義設定画面が開くので「通報設定」タブを開いてください。この「通報設定」タブではどのタイミングで高負荷検出イベントをSSC本体に通報するのかを設定します。サーバを運用していると、負荷のが瞬間的に上昇してすぐに下降する“スパイク”現象が観測されることがよくありますが、こうしたスパイクが発生するたびに高負荷検出イベントを通報すると無駄な仮想マシン移動が行われることになります。そこで高負荷状態が継続している場合にのみ、高負荷検出イベントを通報するようにするわけです。デフォルトでは、10回のチェックで10回、閾値超過が確認された場合に通報が行われるようになっています。また、その下の「閾値超過状態から回復しない場合、[ ]回毎に再通報を行う」をチェックすると、高負荷検出イベントを再通報する際のインターバルが設定できます。どれくらいのタイミングで最初の通報を行うかインターバルをどれくらい取るのかは、システムの負荷変動パターンに併せて調整する必要があります。基本的な考え方としては、短期間で収束する負荷変動を無視するために最初の通報までのチェック回数を多めに取って、インターバルのチェック回数は少なめにするとよいでしょう。「OK」をクリックすると、閾値監視設定画面に戻るので、同様の手順で「低負荷閾値監視定義」の通報タイミングの設定も行います。

グラフの設定

通報タイミングを設定したことで、SystemMonitorとSSCが連携できる状態になりました。ただし、このままではサーバの負荷状況が把握しにくいので、負荷状況をグラフ化する設定も行います。SystemMonitorの「グラフ」メニューから「グラフ」→「新規作成」を選択すると、下のグラフ設定画面が開きます。この「表示対象」タブでは、監視するサーバや性能情報、グラフ化する際の統計計算方法を設定します。性能情報と統計計算方法はデフォルト(CPU使用率の平均値をプロット)のままで十分なので、「ノード」セクションにある「追加」をクリックして監視対象サーバを登録します。

「ノード」セクションの「追加」をクリックすると別ウィンドウで「ノード参照」画面が開きます。ここでは、監視対象とする物理サーバ(esx1とesx2)をチェックして「OK」をクリックします。

グラフ設定画面に戻ったら、「時間軸」タブに移動します。ここでは、グラフの時間軸に関する設定を行います。ここでは、グラフの種類を「リアルタイムグラフ」とし、過去15分間のグラフを1秒間隔で更新するようにしました。今回は動作テストの時間を考慮して表示期間を短くしましたが、実際の運用では15分間は短すぎると思われますので適宜調整してください。

「時間軸」タブの次は「閾値表示」タブに移動します。このタブでは、低負荷および高負荷の閾値をグラフ上に表示する設定を行います。「閾値領域をグラフに表示する」をチェックし、「閾値定義を参照」をクリックします。これでSSCからインポートした閾値が下の各フィールドに反映されます。ここまでの設定が済んだら、「OK」をクリックしてグラフ設定画面を閉じます。

以上でグラフの設定は完了です。下はグラフ設定後のSystemMonitorの画面です。


目次



8ページ目


仮想マシン最適配置の動作テスト

最後に仮想マシンの最適配置設定が期待通りに機能するか動作テストを行います。初期状態の仮想マシンの配置は下の画面のように「esx1」上で「VM-01」が動作し、「esx2」上で「VM-02」と「VM-03」が動作しています。

今回は3台の仮想マシン上で負荷ツールを実行し、負荷状況を意図的に変更してみました。以下のようにVM-02とVM-03にはCPU使用率20%の負荷を掛け続け、VM-01のみ40%→0%→40%とCPU使用率を変更しました。

仮想マシンのCPU使用率

時間軸 Aエリア Bエリア Cエリア
VM-01 40 0 40
VM-02 20 20 20
VM-03 20 20 20

下は上記の実験でプロットされたグラフです。

このグラフでは、Bエリアの入り口でVM-01をホストしていたesx1の負荷が急激に下がっています。esx1の負荷が急激に下がったあと、esx1とesx2の両方に小さなスパイクが発生していますが、これはライブマイグレーションの実行によるものです。スパイク発生後にSSCの仮想ビューを確認すると、下のように3台の仮想マシンがすべてesx2に集約されていました。

次にCエリアでは、VM-01の負荷上昇に伴いesx2の負荷が急激に上昇して高負荷境界を超えています。これにより負荷分散アクションが実行されVM-01がesx1に移動し、結果として初期状態と同じ配置に戻りました。

なお、負荷分散アクションを実行する際は、どの仮想サーバをどの物理サーバに移動させるのが効率がよいのかを、SSCが自動的に判断します。そのため、管理者は負荷分散の細かな制御ルールを気にせずに物理サーバや仮想マシンを追加/削除することができるわけです。

従来のシステム構築ではピーク時のリソース要求を満たすようにサーバの選定が行われてきましたが、その結果、企業内にはさまざまなスペックのサーバが増え続け、同時に個々のサーバがアイドル時にリソースをもてあます状態に陥っていました。幸いCPUの性能向上とマルチコア化のおかげで、従来なら4CPUのマシンが必要だったシステムでも現在なら単体のブレードサーバで運用することができます。ブレードサーバを社内システムの標準コンポーネントとしてそこに仮想化を導入することで、企業は均質なコンピュータリソースプール構築し、リソースを無駄なく利用できるようになります。


目次