レベル: 中級 石川 克也, ビジネス開発担当ディレクター, プラットフォームコンピューティング株式会社
有馬 俊道 (ARIMA@jp.ibm.com), ソフトウェア開発研究所 オートノミック・コンピューティング テクノロジー・センター, IBM
兼安 祐介 (YUSKKNYS@jp.ibm.com), ソフトウェア開発研究所 オートノミック・コンピューティング・テクノロジー・センター, IBM
2006年 2月 10日 本稿ではグリッド・コンピューティングとオートノミック・コンピューティングを融合させる試みについてご紹介します。今回から三回に渡りPlatform Computing社のグリッド製品Platform LSF 6.1にオートノミック・テクノロジーの問題判別（Problem Determination：PD）と自己修復機能を適用していきます。第一回目の今回はPlatform LSFの紹介、およびLSFにオートノミックを適用する意義についてお話しします。
1. はじめに
本稿ではグリッド・コンピューティングとオートノミック・コンピューティングを融合させる試みについてご紹介します。今回から三回に渡りPlatform Computing社のグリッド製品Platform LSF 6.1にオートノミック・テクノロジーの問題判別（Problem Determination：PD）と自己修復機能を適用していきます。第一回目の今回はPlatform LSFの紹介、およびLSFにオートノミックを適用する意義についてお話しします。
2. グリッド・システム「Platform LSF」とオートノミック・コンピューティングの融合の意義
2.1. 「Platform LSF」について
Platform LSFは、Platform Computing社の現CEOソニアン ゾウのカリフォルニア大学バークレー校における博士論文テーマであった「大規模ヘテロ環境計算システムにおける負荷共有」が技術ベースになっています。ゾウ博士がこのテーマで博士号を取得したのは1985年のことです。その後彼は、カナダ、トロント大学に助教授として移り、そこで現Platform LSFのプロトタイプを構築、1992年にはPlatform Computing社を起業し、LSFは商業ベースで使われるようになりました。
通説のようにグリッドという言葉が始めて使われたのが1997年とすると、Platform LSF自体はその12年以上も前に構想・研究され、その5年前には商業ベースで使われていたことになります。今でも、現実のグリッドコンピューティングを牽引しながら発展を続けています。
その主な適用例としては、半導体、電気機器、自動車などの設計・製造、金融工学、化学・生物・薬品、宇宙、原子力等などにおける各種シミュレーションや大規模計算などで、いわゆるHPC（ハイ パフォーマンス コンピューティング）の裏で多く利用されています。
LSFはもともと"Load Sharing Facility"の略で，バッチ処理型のアプリケーションを対象としています。後ろに控える複数の計算リソースをユーザーには単一の大きな計算機に見せながら、裏では負荷を計算リソース間でうまくバランスさせることで無駄を排除し、全体の稼働率を高めようというものです。グリッドコンピューティングを大きなアーキテクチャーで捉えた場合には、その中の仮想化およびリソーススケジューリングと呼ばれている部分を担う、極めて本質的なコンポーネントになります。学術的にはPlatform LSF単体でグリッドと呼ぶかどうかの議論はあると思いますが、LSFを利用した商業ベースの実稼働環境は現実にグリッドと呼ばれています。
今後の方向性としては、その「計算リソースの仮想化による稼動率、管理効率向上」、「ビジネスポリシーに基づくリソース割当て、およびその高い柔軟性」、「高可用性」といった特徴を生かし、いわゆるオンデマンド・コンピューティングを実現する中心コンポーネントとして、HPCだけではなく企業ITの様々なビジネスアプリケーションを支えるインフラとなるべく発展していきます。
それでは分散環境においてLSFが無い場合とある場合について比べながら，LSFの働きを見てみましょう。LSFが無い場合（図-1），ユーザーは複数の計算機の中から自分のタスクを最適に実行できる計算機を自分で選択しなければなりません。ユーザーにとってそれは大変苦痛です。一台一台の計算機ホスト名やそのタイプ，能力を控えておき，さらに実行したい時点におけるそれぞれの稼動状態（運転しているか，停止しているか，運転しているなら負荷状態はどうかなど・・・）を調べた上で実行計算機を決定し，タスクを投入しなければなりません。いちいちそんなことをしなければならないのでしたら，手元の1台の計算機で全部やってしまった方が結局は速いかもしれませんね。分散処理できる環境であるにもかかわらず，結局は使われない計算機ということにもなりかねません。
図-1
それでは，LSFを使うとどうなるでしょうか（図-2）。分散環境内の各計算機にLSFを導入することで，LSFクラスターが形成され，その中の1台がマスターになります。マスターは別のインストールをするわけではなく，単にどれをマスターにするかを設定するだけですので，どの計算機もマスターになることができます。マスターは，LSFクラスター内の各計算機（ノードと呼ばれます）についての静的情報（CPUの数，タイプ，CPUの能力，メモリー搭載容量，OSの種類など）と，動的情報（CPU負荷，メモリー空き容量，処理実行中プロセス数など）を常に把握していると同時に，ユーザーに対して「キュー」を提供します。ユーザー（あるいはアプリケーション）は，このキューに対して自分の実行したいタスクと，さらにオプションとしてそのタスクの実行条件を投げることで，マスターがLSFクラスター内の最適なノードを選択して実行，結果を返してくれます。すなわち，ユーザーから見ると，複数計算機からなるLSFクラスターはキューにつながれた大きな一つの計算機に見えることになります。
図-2
LSFの大きな特徴は，タスクの実行条件の豊富さ（すなわち，タスク実行に最適なノードを選択する基準の豊富さ），複数のタスクがキューに投げられたときの実行順序を制御するスケジューリングのきめ細やかさ，そして大規模クラスターを構築できるスケーラビリティーです（LSFバージョン6.1では，3,000ノード，50万タスク投入で，ノードの平均CPU利用率90%を達成しています）。
もう一つの忘れてはならない重要な特徴は，グリッドの生まれながらの性質とも言うべき，耐障害性です。LSFクラスター内のノードのうちいくつかが動作を止めてしまったとしても，それはユーザーには全く見えず，そして投入されたタスクは何も無かったがごとく実行されます（もちろん，タスク実行可能な稼動ノードがある限りではありますが）。見えたとしても若干，処理に時間がかかるように見える程度です。LSFマスターについても同様で，クラスター内計算機の中から，プライマリー以外にあらかじめセカンダリー，ターシャリー，・・・を定義しておくことで，障害時には自動的にこの順番にノードがマスター役を担っていきます。（マスターは単に設定ファイル内の定義であることを思い出してください）。このようにLSFクラスターはミッションクリティカル業務を支えることのできるレベルの高い可用性を提供することができます。
LSFでは，このように複数の計算機を対象としなければなりませんので（多い場合には数千ノード），そのライセンス管理には集中型管理形態を採用しています。具体的には，マクロビジョン社のFLEXnet Manager（旧FLEXlm）を利用しています。FLEXnet ManagerはLSFクラスターを監視し，ライセンス数を超えた利用や許諾されていないコンポーネントの利用を拒否します。
2.2. 「Platform LSF」にオートノミック・コンピューティングを適用する意義
さて，本稿は「Platform LSFへのオートノミック・コンピューティングの適用」というタイトルですので，Platform LSFから見たときの，オートノミック・コンピューティングへの期待について触れたいと思います。それはズバリ次の3つです。
- ログ解析を容易にしたい
- ログ解析の結果，原因がわかれば，可能な限り自動的に修正したい
- ログを継続的に解析することで，より良いパラメターに自動構成したい
LSFは多くの種類のログを書き出します。それらにはクラスターレベルのログから，ノード毎のログ，そしてLSFデーモンプロセス毎のログが含まれます。障害が起きたときに，まずはこれらのログの中で問題箇所を短時間でピンポイントしたい。そして，さらにその部分の前後，および他のログとの関連性（時間の観点での関連，イベントに注目したときの関連など）を示すことができれば，その後の問題解析に大いに役立つことでしょう。
もちろん，原因がわかった時，あらかじめ修復手順が決められるような障害であれば，それを自動的に実行して欲しい。
LSFにはやはり多くの設定ファイル，設定パラメターがあります。これは過去13年以上にわたりお客様からのご要望を組み入れてきた結果ですが，一方複雑さを増す面も持ち合わせています。もちろん，デフォルト設定で十分動作しますが，お客様環境に合わせてチューニングすることで，より良いパフォーマンスを上げることが可能な場合があります。LSFの稼動状況を見ながら，パラメターを自動変更しつつ，徐々により良い状態に移行させていくような適応機能を追加できたら何とすばらしいことでしょう。
次回の内容
次回は、グリッド・システムに対してオートノミック・コンピューティングの問題判別機能を適用した例についてご紹介します。
参考文献
-
プラットフォームコンピューティング株式会社に関してはこちらをご覧ください。
-
IBMのグリッド・コンピューティングに関してはこちらをご覧ください。
-
オートノミック・コンピューティング ツールキットR3の詳細に関してはこちらをご覧ください。
-
オートノミック・コンピューティング ツールキットR3はこちらよりダウンロードが可能です。
著者について  | | | 石川克也（いしかわ かつや）
プラットフォームコンピューティング株式会社，ビジネス開発担当ディレクター
日本アイ・ビー・エム株式会社，アクセンチュア株式会社等を経て，2004年プラットフォームコンピューティング株式会社にプロフェッショナルサービス担当として入社。2005年より現職。日本国内においてグリッドコンピューティングをビジネス領域に広めるべく，幅広く啓蒙活動等を行っている。 |
| | | 有馬俊道（ありま としみち）
日本アイ・ビー・エム株式会社、ソフトウェア開発研究所 オートノミック・コンピューティング テクノロジー・センター
オートノミック・コンピューティング・テクノロジー・センター（ACTC)でオートノミック・コンピューティングのコンポーネントの開発、技術の検証、標準化などに従事している。オートノミック・コンピューティング・テクノジーの自己修復、問題判別、シンプトンDBが専門領域。IBMでは、これ以外に画像処理、画像認識についての開発を経験してきた。 |
| | | 兼安祐介（かねやす ゆうすけ）
日本アイ・ビー・エム株式会社 ソフトウェア開発研究所 オートノミック・コンピューティング テクノロジー・センター
オートノミック・コンピューティング・テクノロジー・センター（ACTC)でオートノミック・コンピューティングのコンポーネントの開発、技術の検証、標準化などに従事している。オートノミック・コンピューティング・テクノジーの自己修復、問題判別、シンプトンDBが専門領域。
|
記事の評価
| 
