レベル: 中級 Neeraj Joshi (jneeraj@us.ibm.com), Advisory Software Engineer, IBM David Kaminsky (dlk@us.ibm.com), Senior Software Engineer, IBM
2008年 3月 11日 ポリシー・システムの基礎と概要を学んでください。この記事では Apache Imperius を例に、SPL 言語および評価エンジンについて説明し、SPL 環境をインストールする方法 SPL ポリシーを作成する方法、そして作成したポリシーを SPL エンジンを使って実行する方法を紹介します。SPL のおかげで日常の管理タスクがどれほど容易になるかがわかるはずです。
はじめに
時は 2 月、場所はアメリカの南部ですが、それでもかなり厳しい寒さです。寒さで冷え切った体を温めるには、熱いお茶を飲むに限ります。そこで、やかんに水を入れて火にかけ、お湯が沸くまで待つことにします。たまにやかんの様子を見て沸騰したかどうかを確かめます。寒さに凍えた体では時間が経つのが遅く感じられますが、やっとお湯の用意ができました。これで早速お茶を入れて体を温めることができます。
読者の皆さんは、「心温まる話だけど、それがポリシーとどう関係してくるのか」と思っていることでしょう。
システム管理者に必要な日常のタスクのなかには、お茶を入れる作業とそれほど変わらないものもあります。管理者はシステムを監視し、(水が沸騰するのと同じように) 特定の条件が発生すると何らかのアクションを取ります。
そこで活躍するのが、ポリシー・ベースの管理です。ポリシー・ベースの管理では、管理者がポリシー (Policy) を適用する一連の条件 (Condition)、そして該当する条件が当てはまる場合に帰結する一連の処理 (Decision) を表現することができます。ポリシーを使用すれば、管理者は人間が行う日常のタスクを自動化できるため、管理の負担が軽減されることになります。
当然のことながら、すべての管理タスクが日常的なタスクというわけではありません。管理タスクによっては、スキルが求められるものや、慎重に考慮しなければならないものもありますが、ポリシーを使用する目的は、管理者から日常的なタスクの負担を取り除き、その分、複雑で人間が行う価値のあるタスクに専念できるようにするということです。
この記事では、ポリシー・システムの概要、そして SPL 言語および評価エンジンについて説明します。また、SPL が日常の管理タスクを簡易化する仕組みについても学びます。SPL を使用するにはこの記事で説明する情報でほとんど事足りますが、プログラミング言語とシステム管理については十分理解している必要があります。
ポリシー言語
重要な点として前もって言っておきますが、ポリシー言語にはかなりの多様性があります。さらに付け加えると、何をもってポリシー言語とするかについては、意見がほとんど一致していません。この記事ではポリシー言語を列挙したり、SPL が正しい、または最高のポリシー言語であると主張するのではなく、ポリシー言語には多様性があること、そして SPL は数ある言語のなかの 1 つでしかないということを明記しておくにとどめます。
以上の点を断った上で、この記事では if-then ルールとして構成したポリシーを説明します。この場合、if 節が then 節を実行する条件を決定します。例えば、「前回、増分バックアップをしてからファイルシステム内のデータの 10% 以上が変更された場合 (= if)、増分バックアップを実行する (= then)」といったポリシーです。このようなポリシーを自動的に施行すると、管理者が「データ変更」ゲージを監視して手動でバックアップを開始する代わりに、ポリシー・システムがゲージを監視し、必要に応じてアクションを実行します。
これから詳しく説明しますが、if 節は極めて複雑にすることができます。最近のポリシー言語では、以下の内容をサポートしています。
- ブール代数: AND、OR、NOT など
- 広範な算術関数: 加算、減算、乗算など
- 集合の演算: 集合のうちの 1 つ以上、集合のすべて、など
これらの演算子が管理環境から収集された情報を結合し、then 節を実行しなければならない場合を判断します。
then 節はポリシー管理システムに何らかのアクションを実行させます。例えば、バックアップを開始する、実行中の作業の優先順位を変更するなどのアクションです。あるいは管理者に通知するだけという場合もあります。
then 節は管理環境に大きく依存します。つまり、ポリシー管理システムがリソースで実行可能なアクションは、(ほとんど) 全面的に管理環境が公開する関数呼び出しによって決まるということです。例えば管理環境がバックアップを開始するための呼び出しを提供していなかったり、優先順位の変更を許可していない場合には、それらのアクションは実行できません。
管理環境
ポリシー管理システムでの管理環境の重要性を考えると、管理環境とは何を意味するのかを簡単に説明しておく価値はあります。簡単に言うと、管理環境は、環境を操作するために公開された機能のインターフェース(API)とのやり取りを行うプログラムであるセンサーとエフェクターの集合です。
センサーは通常、if 節で使用されます。If 節で例えば「前回、増分バックアップをしてからファイルシステム内のデータの 10% 以上が変更された場合」と規定している場合には、変更されたデータのパーセンテージを示すセンサーが必要です。センサーがないとすれば、このような値の計算を可能にする十分な情報がなければなりません。
エフェクターが使用されるのは通常、then 節です。上記の例で言えば、ポリシーがシステムに「増分バックアップの開始」を要求した場合に、バックアップを開始することができるエフェクターがなければならないということになります。
then 節でセンサーが使用される場合もあります。その一例は、ポリシーで then 節がプロセスの優先順位を上げるように規定する場合です。その環境に優先順位を上げるエフェクターがないとしても、「優先順位取得」センサーと「優先順位設定」エフェクターがあれば、ポリシーで現行の優先順位を取得し、優先順位をより高い値に設定することで、結果的に優先順位を上げることができます。
SPL の構造
SPL は多種多様な管理環境に結合できるポリシー言語です。注目に値する点として、SPL は管理環境にはとらわれません。SPL ではやりとりの対象が Linux® サーバーであるか、データベースであるか、あるいは CIM (Common Information Model) ベースのストレージ・デバイスであるかに関わらず、ポリシーの構造はまったく同じです。
SPL ポリシーは 1 つ以上のアンカー・クラス内で作成されます。アンカー・クラスは、ポリシーを使って管理されているシステムの状態をカプセル化します。ポリシーをベースとして、ポリシー・エバリュエーターがアンカー・クラスのインスタンスに問い合わせを行い、条件を評価して、アクションを実行します。
リスト 1 に SPL ポリシーの典型的な構造を示します。
リスト 1. SPL 言語構文
Import Qualifier <namespace> Class <Class Name> : <instances>*;
Import ….
Strategy <strategy>
Policy (one or more)
{
Declaration {
<List of constant definition> (Optional)
<List of macro definitions> (Optional)
}
Condition { (Optional)
<If Condition> /* java-like boolean expression */
}
Decision { (Required)
<Then Decision> /* "small" workflow of action */
/* invocations */
}
} <priority>;
|
SPL ポリシーの主なコンポーネントは以下のとおりです。
- Import 文: ポリシー全体で参照されるアンカー・クラスとそのインスタンスを宣言します。
- Strategy 文: 複数のポリシー間での調停ストラテジーを指定します。
- Policy 文: 実際のポリシーを宣言します。
- Declaration 文: 定数および関数 (マクロ) を宣言できるようにします。
- Condition 文: ポリシーの if 部分をカプセル化するブール式です。
- Decision 文: ポリシーの then 部分をカプセル化する一連のアクションです。
- priority: ポリシー全体での相対重要度を決定するために使用される数値です。
これらの構成要素の使用法については、次のセクションで説明します。
SPL エンジンの構造は、環境にとらわれない設計を反映しています。図 1 の左側にあるのは、一般的な管理環境です。
図 1. SPL エンジン・アーキテクチャー
SPL エンジンの主なコンポーネントは以下のとおりです。
- ポリシー・データ・ストア (Policy data store) モジュール。ポリシーの読み取り/書き込みを行う物理的なリポジトリー (ポリシー・リポジトリー (Policy repository)) およびキャッシュ (Policy cache) とやりとりをします。
- ポリシー・パーサー (Policy parser)。テキストによるポリシーを実行可能なフォーマットに変換します。
- ポリシー・キャッシュ (Policy cashe)。ポリシーの読み取り/書き込みを効率化するメモリー内ストレージです。
- ポリシー・マネージャー (Policy manager)。ポリシーを評価し、他のポリシー・エンジン・コンポーネントのアクティビティーを調整します。
- データ・コレクター (Data collector)。管理環境とやりとりをして、ポリシーを評価するために必要な情報を収集します。
- アクチュエーター (Actuator)。ポリシー・エンジンが管理環境でアクションを実行することを可能にします。
- インスツルメンテーション層 (CIMOM [Common Information Model Object Manager] またはその他の層)(CIMOM or other instrumentation layer)。管理環境のインターフェース層として機能し、データをデータ・コレクターに提供し、アクチュエーターがアクションを実行できるようにします。
このシステムは、データ・コレクターおよびアクチュエーターのみがユーザーの環境を認識し、その他のコンポーネントはすべて環境にとらわれないように設計されているという点に注目してください。
SPL を使用して空き容量を管理する例
このセクションでは一例を用いて、SPL がコンピューター・システムの管理を簡易化する例を説明します。
問題の定義
ファイルシステムを簡潔に維持しようとどんなに徹底していても、いつかは不要なものでファイルシステムがいっぱいになってしまうものです。その結果、空き容量を見つけ出すために大慌てでファイルシステムを整理しなければならなくなりますが、不幸なことに、そしてよくありがちなこととして、実際には必要だったデータを削除してしまったことに気付き、愕然とすることがあります。
ソリューション
空き容量が危険なほどに少なくなるまで待つのではなく、定期的にファイルシステムの空き容量を計算する SPL ポリシーを作成し、実行します。このポリシーでは、空き容量が少なくなると Windows® のクリーンアップ・ツールを使って不要なデータを選択的にクリーンアップします。
SPL を使ってソリューションを構築する際に必要となる重要なステップは、以下の 2 つです。
- 動作環境の状態をカプセル化するアンカー・クラスを作成します。CIM を使用している場合、SPL を CIM 環境で実行していれば、CIMOM 内にある既存のCIM クラスの一部をそのまま再利用することができます。標準的な CIMOM には、システム内のさまざまな IT 成果物をカプセル化する多数のクラスが付属しています。
- ポリシーを作成します。
SPL のアンカー Java クラスを作成する
アンカー・クラスでは、ポリシーによって管理する対象となる環境をモデル化する必要があります。このシナリオでは、管理する対象となるのはファイルシステムですが、ファイルシステムの管理とは具体的には、ファイルシステムの空き容量がなくなりそうになったときにファイルシステムのクリーンアップを行うことです。
アンカー・クラスを作成するためには Java™ クラスを作成します。このクラスには (1) ファイルシステムの現在の空き容量を返すメソッド、(2) ポリシーがクリーンアップを開始するために呼び出すメソッドが必要です。この単純な例には 2 つのクラスしか必要ありませんが、実際の環境では、管理環境を記述するアンカー・クラスの数はこれよりも遥かに増えることになります。
リスト 2. SPL アンカー Java クラスの作成
Class WindowsComputerSystem {
float getFreeSpace();
void deleteFiles(String type);
}
|
注意する点として、アンカー・クラスのコンテンツやこのクラスに含まれるメソッドには何も制約がありません (このようなメソッドの実装についての詳細については、この記事では説明しませんが、後で説明するサンプル・コードを使用することもできます)。
SPL ポリシーを作成する
Apache 傘下でホストされている SPL 向けインキュベーター・プロジェクト、Apache Imperius には、SPL ポリシーを作成する際に使用できる Eclipse ベースのエディターが付属しています。サンプル・ポリシーの作成手順を実践してみたい場合は、「Apache Imperius SPL Editor Guide」(「参考文献」を参照) で SPL エディターのビルドおよび構成方法についての詳細を参照してください。
アンカー・クラスをインポートする
SPL ポリシー内での最初の文は Import 文です。この文は、アンカー・クラスとその 1 つ以上のインスタンスを宣言します。
リスト 3. アンカー・クラスのインポート
Import Class
org.apache.imperius.javaspl.samples.windowscomputersystem.WindowsComputerSystem:system1; |
上記では、アンカー・クラスとして WindowsComputerSystem、このクラスのインスタンスとして system1 をインポートしています。これらのクラスは別の場所で定義しておきます。
実行ストラテジーを指定する
複数のポリシーが1つにグルーピングされている場合、ポリシー作成者がそのグループのなかでどのポリシーを実行するかを制御しなければならないことがあります。このような制御を可能にするのが、実行ストラテジーです。実行ストラテジーでは、規定された優先順位に応じて、グループに含まれるポリシーのうちのどのポリシーを実行するかを制御することができます。すべての実行ストラテジーのリストを調べるには、「参考文献」を参照してください。
このシナリオでは適用可能なすべてのポリシーを実行しなければならないので、以下の文を追加します。
Strategy Execute_All_Applicable; |
定数を宣言する
警告しきい値と重大しきい値、そしてアラートの送信先とする E メール・アドレスを宣言します。from 定数と to 定数を有効な E メール・アドレスで更新してください。
リスト 4. 定数の宣言
Declaration {
warningFreeSpaceThreshold = 1 ;
criticalFreeSpaceThreshold = 5 ;
from = "xxx@mail.com";
to = "yyy@mail.com";
}
|
警告しきい値到達時のポリシー
最初のポリシーでは、「現在のファイルシステムの空き容量がその警告しきい値を下回った場合、ごみ箱を空にしてユーザーに E メールで通知する」と規定します。
リスト 5. 警告しきい値到達時のポリシー
Policy {
Condition {
system1.freeSpace < warningFreeSpaceThreshold
}
Decision {
system1.deleteFiles( "RecycleBin" ) -> SendMail(from,to,"Critical storage
situation","RecycleBin emptied")
}
}:1; // 1 specifies the priority of this policy. Higher number implies
// higher priority
|
重大しきい値到達時のポリシー
2 番目のポリシーでは、「現在のファイルシステムの空き容量がその重大しきい値を下回った場合、一時インターネット・ファイルを消去してユーザーに E メールで通知する」と規定します。
すべてのポリシーはストラテジーでの指定に従って実行されるため、空き容量がその重大しきい値を下回っている場合、警告しきい値ポリシーも、空き容量が警告しきい値を下回っているとして、同じく「真」であると評価されます。その結果、ごみ箱も空にされるというわけです。
リスト 6. 重大しきい値到達時のポリシー
Policy {
Condition {
system1.freeSpace < criticalFreeSpaceThreshold
}
Decision {
system1.deleteFiles( "TemporaryInternetFiles" ) -> SendMail(from,to,"Critical storage
situation","TemporaryInternetFiles deleted")
}
}:1;
|
ここをクリックすると、完全なポリシーを確認できます。参照用として、完成版ポリシーをダウンロードすることもできます。
ポリシーの実行
アンカー・クラスと SPL ポリシーの両方が作成できた今、後は Apache Imperius ポリシー・エンジンを使ってポリシーをデプロイして実行するだけです。まず初めに必要な作業として、Apache Imperius コードをダウンロードして、ビルドしてください。Apache Imperius のダウンロード・サイトへのリンクは「参考文献」に記載されています。
ポリシーを実行するには、アンカー・クラスをインスタンス化するラッパー・クラスを作成し、ポリシー・エンジンをインスタンス化し、ポリシーをデプロイします。そして最後に、アンカー・インスタンスを渡すことによってポリシーを実行します。
ポリシー・エンジン・クラスをインポートする
リスト 7 に、ポリシー・エンジン・クラスをインポートするためのコードを記載します。
リスト 7. ポリシー・エンジン・クラスのインポート
import org.apache.imperius.javaspl.Java_SPLPolicyRuleProvider;
import org.apache.imperius.spl.parser.exceptions.SPLException;
|
アンカー・クラスとポリシー・エンジンをインスタンス化する
アンカー・クラスとポリシー・エンジンをインスタンス化するには、リスト 8 のコードを使用します。
リスト 8. アンカー・クラスおよびポリシー・エンジンのインスタンス化
WindowsComputerSystem system1 = new WindowsComputerSystem();
Java_SPLPolicyRuleProvider jspl = new Java_SPLPolicyRuleProvider();
|
ファイルシステムからポリシー・ファイルを読み取る
リスト 9 に、ファイルシステムからポリシー・ファイルを読み取るためのコードを記載します。
リスト 9. ファイルシステムからのポリシーの読み取り
String aFile = policyToExecute + ".spl";
StringBuffer contents = new StringBuffer();
BufferedReader input = null;
try {
input = new BufferedReader( new FileReader(aFile) );
String line = null;
while (( line = input.readLine()) != null) {
contents.append(line);
contents.append(System.getProperty("line.separator"));
}
input.close();
} catch (FileNotFoundException ex) {
ex.printStackTrace();
} catch (IOException ex){
ex.printStackTrace();
}
boolean success = jspl.createPolicy("filesystempolicy", contents.toString());
|
ポリシーを実行する
ポリシーを実行するには、リスト 10 のコードを使用します。
リスト 10. ポリシーの実行
Map objMap = new Hashtable();
objMap.put("system1", system1);
Object result = jspl.executePolicy(policyToExecute, objMap);
|
ファイルシステム上の実際の空き容量が警告しきい値または重大しきい値を下回ると、Windows クリーン・マネージャーが起動され、E メールによる通知を受けることになります。
ここをクリックすると、ポリシー・エンジン・ラッパーの完全なコードを確認することができます。参照用として、このコードをダウンロードすることもできます。
完全なコードは、 Apache Imperius Web サイト (「参考文献」を参照) からも無料で入手できます。
それには、以下のステップに従えばよいだけです。
- SPL のソースおよびサンプルをダウンロードしてビルドします。
- samples/computersystem ディレクトリーにある手順説明にしたがって、ファイルシステムのサンプルを実行します。
まとめ
ポリシー管理システムは、システム管理を簡易化するための有力なツールです。SPL 標準をベースとしたオープンソースのポリシー・システム、Apache Imperius が提供するポリシー・エディターと評価環境を使用すれば、管理者は日常タスクの負担を軽減することができます。この記事では、SPL 環境をインストールする方法、SPL ポリシーを作成する方法、そしてそのポリシーを SPL エンジンを使って実行する方法を説明しました。
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| Code sample | ac-splsource.zip | 9KB | HTTP |
|---|
参考文献
著者について  | 
|  | Neeraj Joshi は、IBM Tivoli Autonomic Computing Policy グループの開発リーダーで、ポリシー、問題判別、セキュリティーの分野では 5 年以上の経験を積んでいます。彼は North Carolina State University でコンピューター・サイエンスの修士号を取得しました。 |
 | 
|  | David Kaminsky は IBM のオートノミック・コンピューティング・グループの Software Architect として、ポリシーに基づく管理システムに取り組んでいます。オートノミック・コンピューティングに関わる前には、ストレージ・システムやポータル、パーベイティブ・コンピューティング、Java 技術などに携わってきました。彼は IBM Master Inventor であり、エール大学では並列コンピューティングや分散コンピューティングを学び、コンピューター・サイエンスで博士号を取得しています。彼の成果による 2 種類の商用製品は今でも市販されています。 |
記事の評価
|