Japan [変更]

ホーム

製品

サービス & ソリューション

サポート & ダウンロード

マイアカウント

developerWorks Japan > Autonomic computing | Grid computing | Open source >

グリッド・システム「Platform LSF」へのオートノミック・コンピューティングの適用（3）：自己修復

ページオプション

JavaScript を要するドキュメントオプションは表示されません

レベル: 中級

石川　克也, ビジネス開発担当ディレクター, プラットフォームコンピューティング株式会社
有馬俊道 (ARIMA@jp.ibm.com), ソフトウェア開発研究所　オートノミック・コンピューティング　テクノロジー・センター, IBM
兼安祐介 (YUSKKNYS@jp.ibm.com), ソフトウェア開発研究所　オートノミック・コンピューティング・テクノロジー・センター, IBM

2006年 2月 24日
2006年 3月 03日更新

前回はLSFに対するオートノミックの問題判別テクノロジーの適用に関し、著者らが作成したログ変換アダプター、相関エンジン、シンプトンDBについて紹介しました。今回はオートノミック・コンピューティング・ツールキット R3のAME（Autonomic Management Engine）を用いてPlatform LSF 6.1に自己修復機能を実装するお話をします。

4. Platform LSF にオートノミックの自己修復機能を適用する

前回はLSFに対するオートノミックの問題判別テクノロジーの適用に関し、著者らが作成したログ変換アダプター、相関エンジン、シンプトンDBについて紹介しました。今回はオートノミック・コンピューティング・ツールキット R3のAME（Autonomic Management Engine）を用いてPlatform LSF 6.1に自己修復機能を実装するお話をします。

4.1 LSFのライセンス・エラー

本連載の第１回（２．１節）でご紹介したように、LSFのライセンス管理はマクロビジョン社のFLEXnet Managerを使用しています。このFLEXnet Managerが稼動しているサーバーは「ライセンス・サーバー」と呼ばれます。ＬＳＦクラスター内の或るマシンがＬＳＦマスターとなるためには、ライセンス・サーバーからマスター・ライセンスを取得しなければならず、また、ＬＳＦマスター権を放棄する際には、マスター・ライセンスをライセンス・サーバーに返却しなければなりません。ライセンス・サーバーからライセンスを所得することを「ライセンスをチェックアウトする」と言い、逆に返却することを「ライセンスをチェックインする」と言います。

LSFにはマスター・フェイルオーバーの機能があり、マスターの障害時に自動的に別のマシンにマスター機能を引き継ぐことが出来ます。ただ、障害の発生したマスターがライセンスをうまく返却できなかった場合は、フェイルオーバー先のマシンでライセンス・エラーが発生してしまうことがあります。この場合、通常はライセンスを持ったマスターから応答が無い状態が２時間ほど続くと、FLEXnet Managerによって自動的にライセンスの移動が行われますが、より迅速に対応するためには、オペレータによる強制的なライセンスのチェックイン操作を必要とします。

今回はこのケースでオートノミック・テクノロジーを用いて、人手を介さず早期に回復する仕組みを適用します。

4.2 自己修復の適用

今回対象とするようなライセンス・エラーが発生した場合、フェイルオーバー先のマシンのLSFログ・ファイルに特定のエラーメッセージが出力されることがわかっています。一方、ライセンス・エラーは先にも述べたチェックインコマンドを使って強制的に回復させることができます。そこで、該当するマシンのログをオートノミック・マネージャーで監視し、該当するエラーを検出したらチェックインコマンドで自己修復できるようにします。

オートノミック・コンピューティング・ツールキット R3で提供されているAMEは、ウェブサービスとして稼動するタイプとJavaスタンドアロン・アプリケーションとして稼動するタイプの2通りがありますが、ここでは後者を利用します。こちらはCIM(Common Information Model)クラスを定義・登録し、RMB（Resource Model Builder）上でリソースモデルを作成し、そしてこれをAMEのランタイムであるSARA（Simple Agent Reference Application）アプリケーションで実行して自律機能を実現させます。

4.3 自己修復の構成

構成の概略を図１に示しました。ライセンス・サーバによってライセンス管理が行われているLSFクラスターが今回の対象システムになります。ランセンスサーバは図1ではクラスター外のマシンとして示してありますが、クラスター内のマシン上に存在していても構いません。

フェイルオーバーによってマスターになりうるクラスター内マシンにはLSFログをCBE(Common Base Event)形式に変換するためにGLA（Generic Log Adapter）を、またこのCBEログを監視するためにAMEを配置します。そしてマスターのフェイルオーバーがうまくいかなかった際に、フェイルオーバー先のマシンがこれを検知してライセンスを強制チェックインするコマンドを実行します。このチェックインコマンドはライセンスサーバ・マシン上で実行させる必要があるためリモート通信としてSSHを用いて行います。

以下、この構成における自己修復の構築について順に述べていきます。

図 1　自己修復機能の構成

4.4 ログの連続監視

前回の問題判別の適用ではログ＆トレース・アナライザーにLSFログ変換アダプターをプラグインしてログ・ファイルを静的に調査しましたが、ここでは動的ログ変換が必要となります。GLAではログ変換アダプターを連続稼動モード（continuous mode）で動作させることでログの追加分だけを随時出力することができ、リアルタイムのログ変換が可能です。GLAで動的変換を行うためにアダプタファイルのパラメータcontinuousOperationをtrueに設定します。一定間隔でログを読みに行き、その間に新しく追加されたレコードだけをCBEに変換して出力します。また、ログが一定時間書き込まれないときは連続稼動モードはタイムアウトして監視を終了しますが、このタイムアウト時間は同じくアダプタファイルのパラメータmaximumIdleTime（単位は秒）で設定します。

(ログの連続監視モードのための設定・アダプタファイル)
連続稼動とするため continuousOperation を true に設定
タイムアウト値を適切に変更 : maximumIdleTime
    <cc:ContextInstance charset="UTF-8" continuousOperation="true" 

description="" isoCountryCode="US" isoLanguageCode="en" 
maximumIdleTime="20000" pauseInterval="10" uniqueID=" ">

adapterファイルの設定が済んだら、これを使ってGLAを起動し対象ファイルを連続稼動モードで随時変換します。

4.5 AMEによるログの監視とアクション

AME（Autonomic Management Engine）は、オートノミック・マネージャーの実装例の一つであり、その機能は定義された対象の状態を常時監視・分析し、その結果に応じて規定されているアクションを実行します。図2にあるように、AMEはリソースモデルを動作させ、規定された対象からデータを取得し、分析とアクションを行うことができます。システムの管理者はコマンドラインインタフェースでAMEの制御を行います。

図2：AME（Javaスタンドアロン・アプリケーション）の動作モデル

これらの監視対象や分析方法、アクションの規定はCIM（Common Information Model）クラスの定義と、これを利用したリソースモデルの記述によって決定されます。AMEで今回の自己修復機能を実施させるまでの手順を追って説明していきます。

4.5.1 MOFファイルを作成しCIMリポジトリに登録

まずMOFファイルをCIMリポジトリに登録してCIMクラスを定義します。今回監視する対象のCBE形式のログ・ファイル（GLAがCBEに変換したもの）をファイル名として登録し、これからアクションのトリガーとなるメッセージを検出する正規表現を定義します。これらを記述したMOFファイルをmofcompコマンドでCIMリポジトリに登録します。なお、リソースモデルを作成する環境はWindowsとなります。

設定内容：

[ Dynamic, M12_Instrumentation(
	"Java.com.tivoli.wmftools.ilt.logfileadapter.LogfileAdapter | "
	"FileName= [監視対象ファイル名] ; "
	"gnuRegExp='<CommonBaseEvent.*?"
		"msg=\"([^\"]*).*?"
		"</CommonBaseEvent>';"
	" cacheCount = 10; | ENUM"), 
	Provider("com.tivoli.dmunix.ep.touchpoint.cimom.ifc.M12JavaProvider")
]

class for_lsf_checkin
{
	[key]
	string FileName;
	[key]
	uint32 Offset;

	[ Dynamic, M12_Instrumentation(
			"Java.com.tivoli.wmftools.ilt.logfileadapter.LogfileAdapter | "
			"gnuRegExp='<CommonBaseEvent.*?"
				"msg=\"([^\"]*).*?"
				"</CommonBaseEvent>';"
			"SubExp=1; | GET"),
		Provider("com.tivoli.dmunix.ep.touchpoint.cimom.ifc.M12JavaProvider")
	]
	string msg;     
};

4.5.2 RMBでリソースモデルを定義

先ほど登録したCIMクラスを利用してRMB (Resource Model Builder)によってリソースモデルを作成します。Event triggerのストリングでライセンス・エラー発生時のログのメッセージ“licenses are currently used by”を指定します。以下は作成手順です。

RMBにおける設定手順：

Eclipseを起動してIBM Tivoli Managementパースペクティブを開く
ナビゲータパネルを右クリック、新規→CIM Resource Model(Basic)
プロジェクト名を記入
Script LanguageでJavaScriptを選択。また、該当プラットフォーム全てにチェック
CIM/WMI Data Source を選択
左ペインで先ほど登録したCIMクラスを選択
Msgパラメータを利用プロパティ(Selected Properties)として選択
Filtering Condition は選択しない
Event triggers でMsgパラメータを選択。（左ペインから→ペインに移す）
Referenced Domain NameはContains、ストリングは” licenses are currently used by”を記入
CBEのmsgパラメータに該当文字列が含まれているときをトリガーにする
イベント送信のオプションは外す→今回はTEC等にイベント送信は行わない
Logged Propertiesは選択しない
その他のData Sourceについては選択しない
Model Internal Nameはデフォルトのままでよい
サイクルタイムもデフォルトでよい
完了

作成されたJavaScriptファイルを編集して、トリガーにかかったときのアクションを定義します。

- Svc.SendEventEx…をコメントアウトする
- Svc.ShellCmd(“call.sh”);を同じところに書く
（Linuxマシンを想定しているのでアクションはシェルスクリプトの実行としてあります。）

シェルスクリプトcall.shの内容：
#!/bin/sh
/usr/bin/ssh root@platform2 /root/remove_lic.sh

最後に従属ファイルの追加で以下のファイルを追加し、リソースモデルをエクスポートします（メニューからRMB→Generate Package→AME(zip)を選択してリソースモデルファイルを作成）。

CIMにクラス登録したMOFファイル、
実行するシェルスクリプト(call.sh)
gnu-regexp-1.1.1.jar
itmcs_loggingtools.jar
itmcs_util.jar
jlog2_pdxml.jar
log.jar
m12provider.jar
wmftools.jar

※SSHの設定
上記コマンドを実行するためにSSHの設定が完了していることが前提です。ライセンス・サーバにはSSHサーバがインストールされていて、これに対してコマンドを実行するマシン上にはSSHのクライアントが存在します。また、自動で実行するためにSSHの鍵はサーバとクライアントのマシン間で交換済みになっていて、パスワードを要求されない設定になっている必要があります。

4.5.3 AMEによる監視の実行

作成したリソースモデルを利用して、GLAが変換しているログ・ファイルの監視を実行します。

起動時のコマンドは以下の通りです。

sara.sh/sara.bat を実行
saraコマンドライン= ready: が立ち上がる
以下、このコマンドラインで

startrme
Autonomic Management Engine を起動する
instrmtype [リソースモデルファイル]
リソースモデルタイプをインストールする
mkrminstance [ここで登録するインスタンス名] [リソースモデル名]
リソースモデルのインスタンスを作成する
startrminstance [上記インスタンス名]
リソースモデルのインスタンスを起動する

以上でCBEファイルの常時監視が実行されます。なお、各コマンドの詳細についてはAMEの導入ディレクトリー下に展開されるドキュメントame.pdfをご参照ください。

4.6. 自己修復の実施

以上、MOFファイルで定義された監視対象（この場合はGLAが変換出力したCBEログ・ファイル）から定義された文字列が抜き取られ、これがリソースモデルで定義した文字列“licenses are currently used by”と一致すると、JavaScriptに記述してあるコマンド（ここでは call.sh ）が実行されます。call.sh ではライセンス・サーバ上のシェルスクリプトremove_lic.sh が呼び出されライセンスの強制チェックインが行われます。以上によりライセンス不足によるマスター・フェイルオーバーの失敗が解消され、即時にフェイルオーバー先のマシンにマスターが移行します

remove_lic.shの例:
(MASTER_HOST、LSF_ENVDIRについてはシステムに合わせた変更が必要です。)

#!/bin/sh
# remove_lic
# Primariy master host
MASTER_HOST=ultra5
# set LSF_ENVDIR if LSF environmnet is not set.
LSF_ENVDIR=/home/yinokuma/products/lsf610/conf
# set License file name
# LM_LICENSE_FILE=/home/yinokuma/products/lsf610/conf/license.dat
# license features
FEATURES="lsf_base lsf_manager lsf_sched_fairshare lsf_sched_preemption 
lsf_sched_parallel lsf_sched_resource_reservation lsf_sched_advance_reservation 
lsf_sla"
# find lsf.conf
if [ "x$LSF_ENVDIR" = "x" ] 
then
  LSF_ENVDIR=/etc
fi
if [ -f $LSF_ENVDIR/lsf.conf -a -r $LSF_ENVDIR/lsf.conf ]  
then
  . $LSF_ENVDIR/lsf.conf
else
  echo "Cannot find lsf.conf." >&2
  exit 1
fi
if [ "x$LM_LICENSE_FILE" = "x" -a "x$LSF_LICENSE_FILE" != "x" ] 
then
  LM_LICENSE_FILE=$LSF_LICENSE_FILE
fi
if [ "x$LM_LICENSE_FILE" = "x" ] 
then  
  echo "Cannot find license file" >&2
  exit 1
fi
# find lmstat and lmremove
LMSTAT=`which lmstat 2>/dev/null`
LMREMOVE=`which lmremove 2>/dev/null`
if [ "x$LMSTAT" = "x" -o "x$LMREMOVE" = "x" ] 
then
  if [ -f $LSF_ENVDIR/profile.lsf -a -r $LSF_ENVDIR/profile.lsf ]
  then
    . $LSF_ENVDIR/profile.lsf
  else
    echo "Cannot find LSF environment" >&;2
    exit 1
  fi
  LMSTAT=`which lmstat 2>/dev/null`
  LMREMOVE=`which lmremove 2>/dev/null`
fi
if [ "x$LMSTAT" = "x" -o "x$LMREMOVE" = "x" ]
then
  echo "Cannot find lmstat and/or lmremove" >&2
  exit 1
fi
# get license information and remove it
for _f in $FEATURES
do
  _info=`$LMSTAT -c $LM_LICENSE_FILE -f $_f | grep $MASTER_HOST | 
		awk -F' ' '{print $1" "$2" "$3}'`
  $LMREMOVE -c $LM_LICENSE_FILE $_f $_info >/dev/null 2>&1
done

なお、マスター・フェイルオーバーが成功したかどうかの確認については今回実装していませんが、以下のコマンドを実行し、ファイルオーバー先のマシンをマスターとしてクラスターが構成され、正常に動作していることを確認することができます。

- lshosts: ホストとその静的リソースを表示する
- lsid: 現在のLSFバージョン番号やクラスター名、マスタホスト名を表示する

4.9 自己修復のメリット

LSFのマスター・フェイルオーバー時にライセンス・エラーとなってしまう場合に対応して、オートノミックの自己修復機能を実装した例を紹介しました。フェイルオーバーが失敗した際、長い時間投入プロセスが停滞することもなく、また、管理者によるチェックインコマンドも要さずに、即時の回復が可能となります。

上に戻る

まとめ

以上3回にわたってグリッド・コンピューティングとオートノミック・コンピューティング融合の試みについてご紹介してきました。グリッド・システムにおける問題判別適用、そして自己修復適用の例を見ていただきましたが、これらを通して両技術の連携が実際のシステム運用を効果的に助け、広く応用可能であることをお伝えできたなら幸いです。

参考文献

オートノミック・コンピューティング　ツールキットR3の詳細に関してはこちらをご覧ください。
オートノミック・コンピューティング　ツールキットR3はこちらよりダウンロードが可能です。

著者について


		石川克也（いしかわ　かつや）プラットフォームコンピューティング株式会社，ビジネス開発担当ディレクター日本アイ・ビー・エム株式会社，アクセンチュア株式会社等を経て，2004年プラットフォームコンピューティング株式会社にプロフェッショナルサービス担当として入社。2005年より現職。日本国内においてグリッドコンピューティングをビジネス領域に広めるべく，幅広く啓蒙活動等を行っている。


		有馬俊道（ありま　としみち）日本アイ・ビー・エム株式会社、ソフトウェア開発研究所　オートノミック・コンピューティング　テクノロジー・センターオートノミック・コンピューティング・テクノロジー・センター（ACTC)でオートノミック・コンピューティングのコンポーネントの開発、技術の検証、標準化などに従事している。オートノミック・コンピューティング・テクノジーの自己修復、問題判別、シンプトンDBが専門領域。IBMでは、これ以外に画像処理、画像認識についての開発を経験してきた。


		兼安祐介（かねやす　ゆうすけ）日本アイ・ビー・エム株式会社　ソフトウェア開発研究所　オートノミック・コンピューティング　テクノロジー・センターオートノミック・コンピューティング・テクノロジー・センター（ACTC)でオートノミック・コンピューティングのコンポーネントの開発、技術の検証、標準化などに従事している。オートノミック・コンピューティング・テクノジーの自己修復、問題判別、シンプトンDBが専門領域。

記事の評価

この記事を共有する

はてなブックマーク	livedoorクリップ	del.icio.us	Buzzurl（バザール）	Choix！


Saafブックマーク	FC2ブックマーク	MM/memo	ニフティクリップ	Yahoo!ブックマーク

CZブックマーク	newsing

上に戻る

日本IBMについて

プライバシー

お問い合わせ