Cisco UCS Director Open Automation 開発者ガイド、リリース 5.0
独自のインベントリ コレクタの開発
独自のインベントリ コレクタの開発

独自のインベントリ コレクタの開発

この章は、次の内容で構成されています。

インベントリ コレクタの概要

コレクタ フレームワークを使用して独自のインベントリ コレクタを実装することで、新規デバイスのサポートを導入できます。 新規デバイスのサポートを追加する際は、データベース内のデータの収集と持続性を処理するインベントリ コレクタを実装する必要があります。

インベントリ コレクタ フレームワークには、データを表示するための一連のレポートが付属しています。 レポートの詳細については、レポートの概要を参照してください。

モジュール開発のガイドライン

新しいデバイスをサポートする新しいモジュールを開発する場合、モジュールの開発は、デバイス ファミリを対象に行う必要があります。 つまり、類似したデバイスをサポートするモジュールは、1 つだけにします。 これはまた、ネットワーク スイッチとストレージ コントローラの両方をサポートするモジュールは開発すべきではなく、2 つのモジュールに分割する必要があることも意味します。 理想的には、1 つのモジュールは同じカテゴリに属するデバイスのみをサポートすべきであるため、1 つのモジュールはコンピューティング デバイス、ネットワーク デバイス、ストレージ デバイスのいずれかのみを処理することになります。 この区別の他に、同じモジュールでサポートされるデバイスは、比較的類似しているべきでもあります。 別々の目的に適した異なるモデルに同じデバイスが使用されることがあります。そういったケースでは、異なるモデルは異なるモジュールでサポートする方が適切な場合があります。

デバイスへの接続(NodeConnectorIf)

接続フェーズを処理する実装は、NodeConnectorIf インターフェイスを実装します。 NodeConnectorIf は、次のフローの各項目で使用されます。

  • connect()、CollectorFactory で指定した ItemIf ごとに使用

  • getItem()

  • disconnect()

connect メソッドは、ConnectorCredential および ConnectionProperties を提供します。 ConnectorCredential には、試行中の接続先デバイスの詳細情報(IP アドレス、ログイン、パスワード クレデンシャルなど)を提供するメソッド toInfraAccount があります。 このデータを使用して接続ロジックを実行し、ConnectionStatus の新規インスタンスを返して、ConnectionStatus オブジェクトの connected を true または false に設定する必要があります。

getItem メソッドは、NodeIDInventoryCollector の作成時に指定したものと同じ)と、現在収集しようとしているデータを表す ItemIf を提供します。 デバイスの詳細情報が必要な場合は、NodeID を使用して取得できます。 ItemIf では、収集しようとしているデータを知ることができます。 収集ロジックをこのメソッドで実行した後、ItemResponse にラップして返します。 ItemResponse は収集されたデータと、NodeID および ItemIf への参照を保持しているため、後のフェーズで使用できます。

disconnect メソッドは、収集が完了した後のクリーンアップの処理に使用します。

収集/解析したデータの POJO へのバインド(ItemDataObjectBinderIf)

バインド フェーズでは、収集または解析したあらゆるデータを POJO に変換して、持続性のための準備を整える必要があります。 このプロセスは、bind メソッドを使用して行います。 バインドされたオブジェクトは InventoryDBItemIf インターフェイスを実装する必要があります。 このインターフェイスの目的は、accountName フィールドを POJO に確実に含めることです。 このプロセスにより、レポート、リソース制限の計算などでアカウント名のフィルタが可能になります。

詳細については、サンプル コードの com.cloupia.feature.foo.inventory.model.DummyInterface および com.cloupia.feature.foo.inventory.DummyBinder を参照してください。

汎用インフラ アカウント レポートを使用したアカウント管理の簡素化

インベントリ コレクタ タスクを使用する準備が整ったので、コレクタの使用をシステムに通知する必要があります。 システムがコレクタを特定し、収集を開始するようトリガーするアカウントを追加するための、何らかの方法が必要です。

このタスクを実行する最も簡単な方法は、システムに新規アカウントを追加し、アカウントの編集と削除を可能にするベースの実装を提供する、GenericInfraAccountReport を拡張することです。 その後、固有のアカウント タイプとアカウント カテゴリを指定できます。 レポートはこの場所で、[物理] > (指定するタイプに応じて)[コンピューティング]/[ネットワーク]/[ストレージ] から使用可能です。

また、同じ場所に表示するその他のレポートも指定する必要があります。 GenericInfraAccountReport が提供するレポート行でドリル ダウンすると、指定したその他のレポートが表示されます。 独自のレポートの実装に関する詳細については、レポートの概要を参照してください。

このレポートでは、いくつかの基本的なアカウント管理アクションを使用できるため、それらのアクションを自分で作成する必要がありません。 特定のアカウントでドリル ダウンすると、ドリル ダウン レポートとして指定したレポートが表示されます。

はじめる前に

インベントリ コレクタ タスクを使用する準備が整いました。

インベントリ収集コンポーネントおよびアカウント管理レポートの登録

この時点で、独自のインベントリ収集コンポーネントおよびアカウント管理レポートの実装をすでに行っているはずです。 最後のステップは、これらすべてのコンポーネントを AbstractCloupiaModule に登録することです。 具体的には、getReports()createAccountType() を実装する必要があります。 コレクタとレポートの新規インスタンスをインスタンス化して返すと、システムに登録できます。

テスト接続ハンドラ(オプション)

新規のコンピューティングまたはストレージ コレクタを開発する際、すべてのアカウントの詳細情報は、[管理] > [物理アカウント] の下の [物理アカウント] レポートに格納されます。 ユーザが行を選択すると、[テスト接続] オプションが表示されます。 CollectorFactory にテスト接続ハンドラを指定している場合、ユーザがこのテスト アクションを実行すると、このハンドラが呼び出されて接続ステータスを取得します。

Cisco UCS Director には、このテスト接続ハンドラの実装、com.cloupia.service.cIM.inframgr.GenericInfraAccountConnectionTestHandler が用意されています。 この接続ステータス オプションを設定するには、1 つの関数、testConnectionTo を実装する必要があります。 InfraAccount オブジェクトを使用して、テスト対象のデバイスの詳細情報を取得できます。 StringBuffer を使用すれば、その他の情報をユーザに表示できます。 テスト接続は、接続が成功すると true を、失敗すると false を返します。

統合スタック ビルダー(オプション)

Cisco UCS Director では、UI の [統合基盤] タブに、データセンターのデバイスの統合スタックが表示されます。 新規の CollectorFactory を開発する際、デバイスを統合 UI で表示する場合は、独自の ConvergedStackComponentBuilderIf、デバイスとアイコンのマッピング ファイル、および表示するアイコンを指定する必要があります。


(注)  


データセンターの型は Generic にする必要があります。 Open Automation を使用して導入したデバイスは、データセンターの型が Generic に指定されている場合に、統合 UI でのみ表示できます。 VSPEX、FlexPod やその他の製品を指定すると、デバイスはこれらのスタックの一部と見なされないため、表示されません。
はじめる前に

サンプル コードに含まれるファイルには次のものがあります。

  • device_icon_mapping.xml

  • dcom.cloupia.feature.foo.inventory.DummyConvergedStackBuilder

  • すべてのイメージを含む resources フォルダ

手順
    ステップ 1   ConvergedStackComponentBuilderIf の実装を指定します。

    抽象実装 com.cloupia.service.cIM.inframgr.reports.contextresolve.AbstractConvergedStackComponentBuilder を拡張します。

    ステップ 2   デバイスとアイコンのマッピング ファイルを指定します。

    この XML ファイルを使用して、ConvergedStackComponentBuilderIf で指定したデータを、UI で使用される実際のイメージにマップします。 この XML ファイルの名前は必ず device_icon_mapping.xml とし、jar にパッケージ化する必要があります。

    重要:

    XML ファイル内の各エントリについて、DeviceType は ComponentBuilder の Model と必ず一致し、Vendor は ComponentBuilder の Vendor と必ず一致する必要があります。 フレームワークでは、デバイスを一意に識別し、使用するアイコンを特定するために、ベンダーとモデルを使用します。 また XML ファイル内で、IconURL の値は常に /app/uploads/openauto で始まる必要があります。 すべてのイメージはこの場所にダンプされます。

    ステップ 3   イメージは、resources というフォルダ内の module.zip に必ずパッケージ化します。

    フレームワークはすべてのイメージを resources にコピーし、それらを uploads フォルダに配置します。


    スタック ビュー プロバイダー(オプション)

    デバイス固有のデータを、[仮想] > [コンピューティング] > [VM] > [スタックビュー] の下にあるスタック ビューに表示したい場合は、com.cloupia.model.cIM.stackView.StackViewItemProviderIf の独自の実装を CollectorFactory に指定できます。

    このインターフェイスには、デバイス カテゴリに固有のいくつかの実装が用意されています。

    • ストレージ カテゴリ デバイスを扱う場合は、com.cloupia.service.cIM.inframgr.stackView.AbstractOAStorageStackViewProvider を使用します。

    • ネットワーク カテゴリ デバイスを扱う場合は、com.cloupia.service.cIM.inframgr.stackView.AbstractOANetworkStackViewProvider を使用します。

    • コンピューティング カテゴリ デバイスを扱う場合は、com.cloupia.service.cIM.inframgr.stackView.AbstractOAComputeStackViewProvider を使用します。

    それぞれの実装について、デバイスを仮想マシン(VM)スタックに適用させるか、UI にどのようなデータを表示するかを決定する必要があります。


    (注)  


    プロビジョニングに vCenter を使用すると、現時点では VM スタックが動作しますが、HyperV を使用する場合は動作しない可能性があります。