IBM Systems Directorをプログラムから利用する

以前の本コラムでIBM Systems Directorのウェブ・ベースのGUIとコマンドライン・インタフェースを使ってデータ・センターを管理する方法についてご紹介しました。これらの選択肢にはそれぞれ利点があるのですが、組み合わせて使用するとデータ・センターをより堅牢に管理することができます。本稿では3つ目の選択肢であるAPIインタフェースを利用したプログラミングをご紹介します。この方法ではSDKとREST APIを使用してSystems Directorのデータとタスクを活用することでカスタム･アプリケーションを構築したり改良したりすることができます。ではさっそくカスタム･アプリケーションからSystems Director を利用するプログラミングの勉強を始めましょう。

Systems Management SDKを活用する

あなたがもしRESTインタフェースのエキスパートであればすぐに Systems Management SDKウェブ･ページをご覧になってください(他のSystems Managementリソースについては後述の「より詳しい情報」も参照ください)。このSDKをインストールする際には、ライセンス条項に同意しなければなりません。Systems Management SDKはRESTをSystems Director、VMControl、Active Energy Managerで使用する方法を学ぶ人のためのものです。このSDKのウェブ・ページには次の3つの主要なセクションへのリンクが記載されています。

• Systems Director Base SDK
• Systems Director VMControl SDK
• Active Energy Manager SDK

各セクションにはそれぞれの機能を利用するプログラミングを始めるのに必要なことがすべて記載されている他、ベストプラクティスやREST API自体、データモデルへの参照などもあります。これらについては後述します。まずはSystems Director Base SDKから始めることをお勧めします。というのもこのセクションにはどこから始めれば良いかやたくさんのコード例が記載されているからです。各SDKはそれぞれ異なるREST APIに焦点を当てていますが、実際には必要なAPIを組み合わせて使うことができます。たとえば、Systems Director Base APIを使用することでカスタム・アプリケーションにインベントリを収集させて特定のインベントリ・データを抽出してから、その詳細に応じて特定のVMControl APIやActive Energy Manager APIを使用して他のタスクを実行させることができます。

どのSDKのリリースにも微調整や新しい機能が含まれています。たとえばリリース6.2.1では、イベントAPIから返ってくるイベントのリストが最後に返ってきたものから順番に保存されます。これにより、APIから流れ込んでくるイベントを分析する方法が簡素化できます。ですからたとえば、下記の例で返ってくる最初の25個のイベントを受信した時、その25個が最新のものであることがわかります。

https://myserver:port/{webContext}/events?Start=0&Count=25

REST APIの基本に立ち返る

REST APIの詳細に入る前に基本的な事項について少し触れておきましょう。ここいくつかのリリースにおいてウェブ･ベースのAPIがたくさんSystems Directorに追加されました。これをREST APIと呼んでいます。このAPIはRepresentational State TransferまたはRESTと呼ばれるアーキテクチャ上に構築されたウェブ･ベースのプログラミング･インタフェースで、開発者はこれを使用して自分のプログラムから直接HTTP呼び出しをすることでSystems Directorのデータにアクセス(しかもSystems Directorのタスクを実行) できます。これがもたらすメリットはいくつかありますが、私が思うに一番大きなメリットはSystems Directorのデータを解析してSystems DirectorのタスクをリアルタイムにHTTPプロトコル経由で実行することで、カスタム･アプリケーションを作成または強化できるということです。さらに、ほとんどすべてのサーバーはネットワークに接続されていますから、固有のプロトコルについて心配する必要がないのです。

RESTはSystems Director とやりとりするためのごくシンプルなコンストラクトを提供しています。HTTPプロトコルを使用することで、使用しているプログラミング言語には依存せずどんなアプリケーションからもSystems DirectorのAPIにアクセスすることができます。やり取りをするための基本的な構造はユニフォーム・リソース識別子(URI: Uniform Resource Identifier)で、これはデータを取り出し、アクションを実行し、接続を開始するために転送される「通信パケット」です。皆さんが毎日使用しているウェブのアドレスであるURLはURIの一種であり、URLが指しているページがURIの中のリソースになっています。

利用可能なリソースの種類の例をいくつか示します。この中のいくつかは実際のデータ･センターのリソースであったりSystems Directorのリソースであったり、それらをグループ化したものであったりします。

• 管理しているエンド･ポイント: resources, relatedresources
• エンド･ポイントの状態を示すstatusオブジェクト: status, events, monitors, monitordata
• 実行するタスク: discover, inventory, access
• リソースの管理を容易にしてくれるオブジェクト: inventoryprofiles, tasks, groups, jobs

最後に、REST APIはデータを返してくれるだけでなくプログラムを賢くしてくれるコードを多数提供しています。以下にいくつか例を示しますが、SDKにはREST参照における戻りコードがすべて記載されています。

• 200: リクエストが正常に処理された
• 201: リソースが作成された
• 202: リクエストの処理が受信された
• 401: リクエストはユーザーの認証を必要とする

データモデルを理解する

REST APIを使用するにはSystems Directorの構造の基礎を理解しておかなければなりません。データ・センターをUI上で表現する方法を簡素化するのはユーザー・エクスペリエンス・デザイナーとしての私の仕事ですが、プログラムでSystems Directorを利用するときはデータがどのように整理されているかを理解しておくことが重要です。データモデル・リファレンスをすべて読んでおくことをお勧めします。

データモデルのドキュメントにはSystems Directorが処理できるすべてのタイプのリソース、特定のリソースのプロパティ/インベントリ、およびそのリソースの状態オプションが書かれています。たとえばChassisを探している場合Systems Directorは以下を提供することができます。

• Chassisオブジェクトの階層: この階層はPhysicalFrameのすべてのリソースを知りたい場合には有用で、特定のタイプのChassis だけでなくChassisやRackも含まれています。
• インベントリと進行中の管理で収集された属性: このリストは広範で、UIでは確認することのできない情報を提供します。
• Chassisとその他のオブジェクトの間の関係: Chassisの中身とその状態がここにあります。

プログラミングを始める

まず始めに、REST APIを使用するにはSystems Directorを安全な接続で実行できるように構成する必要があります。 SSL接続によりアプリケーションはAPIを介してSSL認証を渡すことができるようになります。アプリケーションはSSL認証を受信した後、Systems Directorに対してロールに基づいたアクセスをしなければなりません。言い換えれば、Systems Directorのユーザーとしてログオンしてからでないとアクションを実行できないということです。

Systems Directorが接続されればSDK中にある任意のREST APIを使用することができます。そのコア部分ではREST APIは以下の4つの方法のうちのいずれかを実行します。

• GET: このAPIは指定されたリソースに関する情報をSystems Directorから取り出します。
• PUT: このAPIは指定されたリソースにリソースが存在すればそれを更新します。
• POST: このAPIはHTTPリクエストのボディー中で渡された情報をもとにリソースの新しいインスタンスを作成します。
• DELETE: このAPIは指定されたリソースを削除します。

図1はRESTを使用して指定されたオペレーティング･システムを探すためのSDKの例です。

各REST呼び出しには終始一貫して共通の流れがあるのに気がつくと思います。

1. 使用するREST APIとインタフェースに必要な詳細(この場合、discoverタスクとIPアドレスのリスト)を指定する。
2. 接続権限を設定する(ログインの方法)。
3. 接続する。
4. RESTリクエストを送信する。
5. 結果を待つ。
6. 切断する。

この共通の流れの要領をつかんでしまえばREST APIから返ってくる値をすばやく理解することができます。REST APIから返ってくる用語はUI上で見慣れたものと必ずしも一致するとは限りません。これはAPIがデータをデータベースから直接引き出した結果であるのに対して、UIは生のデータモデルの用語をよりユーザーにわかりやすい言語に変形させています。残念ながらREST APIはこの生データを変形させるロジックを使用しません。しかし少し研究すれば用語が何を意味するのかをすばやく解読することができます。データモデル・リファレンスを使用するとデータモデルとユーザーモデルの違いを理解することも容易になります。

Systems Directorは複数のリリースでREST APIをサポートしています。対象としているリリースを指定してください。たとえば、図2ではISDAPIVersionを6.2.1.0に設定しています。

対象とするリリースを指定するのはとても重要です。アプリケーション結果的に、テストした時に使用したリリースとは異なるリリースに接続されるかもしれないからです。REST APIは以前のリリースからのリクエストを引き受けることができます。ただしそのリリースがどれであるかがわかる場合に限ります。

最後に、さらに高度な機能を利用できる準備が整っていれば以下のヒントを参考にしてみてください。

• イベントが起こったか、ジョブが完了したか、あるいは状態が変化したかを確認するために繰り返しデータをポーリングする代わりに、提供されているJavaメッセージ・サービス(JVS: Java Message Service)を使用してください。より効率的でパフォーマンスも高いです。
• 同じ接続オブジェクトを再利用してください。アクティブなセッションは処理時間を短縮できるからです。
• 下の例のように接続に「failover」キーワードを追加するだけでJMSを使用しているのであれば、アプリケーションを自動的に再接続可能にしてください。
  failover:(tcp://myserver.ibm.com:61616?initialReconnectDelay
  =120000&maxReconnectAttempts=20

より詳しい情報

今までご紹介した例に加え、Systems Directorはいくつかの試用例を提供しています。たとえば以下に示す例は関連するタスクを実行する方法を説明するものです。

• リソース: リソースの取り出し、編集、削除
• タスクとジョブ: 利用可能なタスクの一覧、ジョブの実行、ジョブの完了までの状態の監視
• メッセージングとイベント: 非同期メッセージングを使用したイベントの監視
• グループ: グループの作成と管理
• 状態: リソースの状態の入手

最後に、SDKは1つの流れの中でサイン・イン、システムの探索、システムへのアクセス要求、インベントリの収集、現在のロールで利用できるタスクの一覧の入手、Shut Down and Power Offタスクの実行といった始めから終わりまでのシナリオを提供しています。

アプリケーションの価値を増大させる

Systems Director SDKの豊富な情報とガイダンスにより、Systems Directorのデータとタスクを活用するためにプログラムをカスタマイズする最初の一歩を踏み出しやすくなります。そうすることでSystems Directorの価値を拡大できるだけでなく、Systems Directorがすでに知っていることを利用してアプリケーションの価値を増大させることもできます。

あわせて読みたい記事