Cisco UCS Central の管理機能の一覧と簡単な説明を次の表に示します。

Cisco UCS Central は、複数の Cisco UCS ドメインを管理するための Cisco UCS ドメイン グループの階層を作成します。Cisco UCS Central には、次のドメイン グループのカテゴリがあります。

• ドメイン グループ：複数の Cisco UCS ドメインを含むグループ。管理を容易にするため、1 つのドメイン グループの下に同様の Cisco UCS ドメインをグループ化できます。

• グループ化されていないドメイン：新しい Cisco UCS ドメインが Cisco UCS Central に登録されると、グループ化されていないドメインに追加されます。グループ化されていないドメインを任意のドメイン グループに割り当てることができます。

ドメイン グループ ポリシーを作成しており、新しい登録済み Cisco UCS ドメインがポリシーで定義された条件を満たしている場合、そのドメインはポリシーで指定されたドメイン グループの下に自動的に配置されます。それ以外の場合は、グループ化されていないドメイン カテゴリに配置されます。このグループ化されていないドメインを、任意のドメイン グループに割り当てることができます。

各 Cisco UCS ドメインは、1 つのドメイン グループにのみ割り当てることができます。Cisco UCS ドメインのメンバーシップは、任意の時点で割り当てまたは再割り当てすることができます。Cisco UCS ドメインをドメイン グループに割り当てると、その Cisco UCS ドメインは、ドメイン グループに対して指定されたすべての管理ポリシーを継承します。

Cisco UCS ドメインをドメイン グループに追加する前に、その Cisco UCS ドメインのポリシー解決制御をローカルに変更してください。これにより、その Cisco UCS ドメインに固有のサービス プロファイルおよびメンテナンス ポリシーが誤って上書きされるのを防止します。Cisco UCS ドメインの自動検出をイネーブルにしている場合でも、ローカル ポリシー解決をイネーブルにすると、ポリシーが誤って上書きされることから Cisco UCS ドメインを保護します。

Cisco UCS Central は、登録済み Cisco UCS ドメイン のグローバル ポリシー サーバとして動作します。グローバル Cisco UCS Central ポリシーをリモート Cisco UCS ドメインに設定するには、ドメインを登録し、登録済みドメインをドメイン グループに割り当てる必要があります。

さらに、ポリシー インポート機能により、ローカル ポリシーを Cisco UCS Central 内でグローバル化できます。その後、これらのグローバル ポリシーを他の登録済み Cisco UCS ドメインに適用できます。

登録済み Cisco UCS ドメインの Cisco UCS Manager で解決されるグローバル ポリシーを、Cisco UCS Central に定義できます。

ポリシー ブラウザは、登録された UCS ドメインから取得したポリシーに関する情報を保有し、ユーザ照会から取得した重要なビジネス関連情報を提供します。この情報は、参加している UCS ドメインからポリシーをインポートするために使用されることがあります。

サポートされる機能は次のとおりです。

• 複数の UCS ドメインにわたる複数のポリシーの管理を、集約ビューを提供して簡素化します。

• 管理者は個々の UCS ドメインのポリシーを定義でき、それらのポリシーを各ドメインから Cisco UCS Central へインポートできます。

• 地域、タイプ、またはポリシーに基づいて最も単純な形式で情報をプルするためのシームレスなビューが提供されます。

• より高レベルの管理制御機能によって、 Cisco UCS Central に組み込まれている強力な UCS 管理ドメインのポリシーをインポートすることより、移行が容易になっています。

ポリシー ブラウザの構造は、複数の UCS 管理ドメインの管理者向けに設計されています。管理者を支援して、ポリシーに対称性を持たせるとともに、ポリシー リポジトリを提供して操作を簡素化します。ポリシー ブラウザを使用できるのは、管理者権限を持つユーザです。

ポリシー ブラウザは、UCS 管理ドメインのポリシー データを管理し、外部の他のノース バウンド API クライアントに向けて表示される基本的な API を使用して、このデータを共有します。ポリシー ブラウザの情報は、これらの API を使用して抽出できます。

Cisco UCS Central は、MIT オブジェクトだけでなく、リソース マネージャ内のポリシーおよびリソースに関する情報も保持します。これらのオブジェクトは、インベントリを介して UCSM MIT オブジェクトを読み取った後、更新されます。統合ツリーは、GUI およびノース バウンド XML API からのクエリー用に Cisco UCS Central で保持され、UCS 管理ドメイン内に存在するリモート ポリシー情報を取得します。

UCS Manager に初めてログインすると、すべてのポリシーのクイック スキャンが実行され、UCS ローカル ポリシー マップが作成され、初期化されます。その後、ポリシー オブジェクトとリソース オブジェクトが作成、更新、および削除されます。

ローカル オブジェクトが作成されると、インベントリ更新メカニズムを使用して Cisco UCS Central に報告されます。これらのオブジェクトを受信すると、policy:Universe オブジェクトが更新され、要素オブジェクトがクラスタおよび送信元オブジェクトに変換されます。これらのオブジェクトは、対応する状態の変更に伴って、UCS ドメイン上で更新および削除されます。

Cisco UCS Central から UCS ドメインを登録解除すると、それらの UCS ドメインのポリシー ソースがクラスタから削除されます。クラスタに送信元オブジェクトが存在しない場合は、そのクラスタが解放されます。

認証方式は、セッションを認証して保持します。次に例を示します。

• aaaLogin：ログインする最初のメソッドです。

• aaaRefresh：現在の認証 Cookie を更新します。

• aaaLogout：現在のセッションを終了し、対応する認証 Cookie を非アクティブ化します。

有効な Cookie を取得する場合は、aaaLogin メソッドを使用します。セッションを保持し、Cookie をアクティブに保つ場合は、aaaRefresh を使用します。セッションを終了（また、Cookie を無効化）する場合は、aaaLogout メソッドを使用します。Cisco UCS に対して一度に最大 256 個のセッションを開くことができます。

クエリー メソッドは、オブジェクトの現在の設定状態情報を取得します。このリリースでは、次のクエリー メソッドがサポートされています。

• configResolveDn：DN によりオブジェクトを取得します。

• configResolveDns：DN のセットによりオブジェクトを取得します。

• configResolveClass：該当するクラスのオブジェクトを取得します。

• configResolveClasses：複数のクラスのオブジェクトを取得します。

• configFindDnsByClassId：指定されたクラスの DN を取得します。

• configResolveChildren：オブジェクトの子オブジェクトを取得します。

• configResolveParent：オブジェクトの親オブジェクトを取得します。

• configScope：管理情報ツリーの DN に対してクラス クエリーを実行します。

ほとんどのクエリー メソッドは、引数 inHierarchical（ブール値 true/yes または false/no）を持ちます。true の場合、inHierarchical 引数はすべての子オブジェクトを返します。

<configResolveDn … inHierarchical="false"></>
<configResolveDn … inHierarchical="true"></>

Cisco UCS から返されるデータ量は非常に大きいことがあるため、inHierarchical 引数は慎重に使用してください。たとえば、クエリー メソッドが、管理情報ツリーの上部にある管理対象オブジェクト（MO）を参照するクラスまたは DN で使われていて、inHierarchical が true に設定されている場合、応答には Cisco UCS の設定全体のほとんどが含まれる可能性があります。Cisco UCS が要求を処理するために必要なリソースが多くなると、Cisco UCS の応答にかかる時間が長くなります。遅延を回避するには、クエリー メソッドを少数の MO に関連する小さな規模で実行する必要があります。

ヒント	クエリー メソッドが応答しない、または応答に時間がかかる場合は、クライアント アプリケーションのタイムアウト期間を長くするか、関連する MO の数を減らすようにクエリー メソッドを調整します。

クエリーの API メソッドには、コールを再帰的にするかどうかを指定するために inRecursive 引数が含まれる場合があります（他のオブジェクトまたは親オブジェクトをポイントし返す場合など）。

この API は、クエリー メソッドの有用性を高めるためにフィルタ セットを提供します。これらのフィルタは、クエリーの一部として渡すことができ、必要な結果セットを特定するために使用されます。

（注）	ホストの電源が少なくとも 1 回投入されるまでに、Cisco UCS はインベントリおよびステータス情報の取得を完了していない場合があります。たとえば、Cisco UCS がリセットされた場合は、ホストの電源が次にオンになるまで、CPU、メモリ、またはアダプタの詳細なインベントリ情報は取得されません。使用できないデータに対応する MO でクエリー メソッドが実行された場合、応答は空白になります。

管理対象オブジェクトの設定を変更するメソッドが複数あります。これらの変更は、ツリー全体、サブツリー、または個々のオブジェクトに適用できます。次に、設定メソッドの例を示します。

• configConfMo：管理情報ツリーの 1 つの管理対象オブジェクト（たとえば、DN）に影響します。

• configConfMos：複数のサブツリー（たとえば、複数の DN）に影響します。

• configConfMoGroup：複数のサブツリー構造（DN）または管理対象オブジェクトに対して同じ設定の変更を加えます。

ほとんどの設定メソッドは、inHierarchical 引数（ブール値 true/yes または false/no）を使用します。子オブジェクトが XML ドキュメントに含まれ、DME が寛容モードで動作するため、設定時にこれらの値は重大な役割を担いません。

アプリケーションは、通常のポーリングまたはイベント サブスクリプションによってステート変更に関する情報を取得します。リソースをより効率的に使うために、イベント サブスクリプションは通知に最適な方法です。ポーリングは非常に限定的な状況にある場合だけ使用してください。

次の例に示すように、イベントに対して登録するために eventSubscribe を使用します。

<eventSubscribe 
    cookie="<real_cookie>">
</eventSubscribe>

通知を受信するには、TCP 上で HTTP または HTTPS セッションを開き、このセッションを開いたままにします。eventSubscribe の受信時に、 は新しいイベントが発生すると、それらすべての送信を開始します。これらのイベントの登録を解除するには、eventUnsubscribe メソッドを使用します。

各イベントには、イベントが生成されたアプリケーションを示す srcDme 属性が含まれています。さらに、各イベントは特定の srcDme に対して一意のイベント ID を持ちます。この srcDme 属性は、イベントのソース アプリケーションを表します。イベント ID はカウンタとして動作し、すべてのメソッドの応答に含まれます。イベントが生成されると、イベント ID カウンタが増加し、新しいイベント ID が割り当てられます。このシーケンス番号により、イベントの追跡が可能になり、イベントを見逃すことがなくなります。

ユーザが開始したイベント チャネル接続は、イベント チャネル セッションの Cookie に関連付けられた非アクティビティが 600 秒経過してから、 によって自動的に切断されます。イベント チャネル接続が によって自動的に閉じられることを防ぐには、ユーザは 600 秒以内に同じイベント チャネル セッション Cookie に対して aaaKeepAlive 要求を送信するか、または同じイベント チャネル セッション Cookie を使用して に他の XML API メソッドを送信する必要があります。

GUI と Cisco UCS Central 間の XML 交換を取得するには、Google Chrome の Web ブラウザ向け開発者ツールにおいて、ショートカット（Ctrl + Shift + I）を使用します。内部セキュリティ要件により、この情報が適用されない場合もあります。ただし、送信された XML を監視するために、市販のパケット アナライザ アプリケーションを使用できます。