はじめに
このドキュメントでは、Intersightでの組織とリソースグループの使用率のシナリオ、および一般的なトラブルシューティングについて説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
使用するコンポーネント
- 管理者権限を持つIntersightアカウント
- Intersightで管理されるCisco UCS 6454ファブリックインターコネクト
- Cisco UCS B200 M5サーバ
- Cisco UCS C240 M6統合サーバ
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
リソースグループとは
リソースグループは、サーバなどのハードウェアリソースの集まりで、管理のためにグループ化されています。これらのグループを使用すると、グループをまとめて管理できるため、設定の制御と処理が容易になります。
組織とは
組織は、Intersightアカウントの異なるリソースを分離および管理し、複数のユーザが同じシステムで独立して作業できるように支援する論理エンティティです。
組織を使用すると、リソースグループを管理して、特定のリソースに構成を適用できます。
設定
リソースグループの作成
サーバを特定のリソースグループに割り当てると、サーバレベルで詳細なアクセス制御を有効にすることができます。ターゲットを1つまたは複数のリソースグループに割り当てることもできます。
- System > Organizations > Create Organizationの順に移動します。
- リソースグループを編集して名前を付け、「カスタムメンバーシップ」を選択して、目的のターゲットまたはサブターゲットのみをリソースグループに割り当てます。



組織の作成
リソースグループを1つまたは複数の組織に割り当てます。
- System > Organizations > Create Organizationの順に移動します。
- 組織を編集して名前を付け、目的のリソースグループを追加します。



「リソースを他の組織と共有」をオンにした場合、表示されるリストは「組織」になります。
これらは、これから作成される他の組織に関連付けられたリソースを共有することを目的としているため、次のように表示されます。


シナリオ
このドキュメントでは、3つのリソースグループと3つの組織を使用してシナリオを説明します。
警告:このドキュメントのシナリオは、説明のみを目的としているため、ベストプラクティスと見なしてはなりません。この機能の利点を最大限に活用するには、ユーザ固有のニーズに応じて、リソースとオブジェクトの編成を計画することをお勧めします。
ヒント:使用するシナリオに関係なく、少なくとも1つの組織が、ドメインによって管理されるすべてのリソースに関連付けられていることを確認する必要があります。これにより、ファブリックインターコネクトが少なくとも1つの組織に属していることが保証され、ドメインプロファイルをデバイスに関連付けることができます。
シナリオ 1.デフォルトのすべてのデバイス
シナリオ1のダイアグラム
シナリオ1の設定の結果
- これはデフォルト設定です。すべてのリソースと設定は、自動的にデフォルトのリソースグループ(default-RG)と組織(default-ORG)に配置されます。
シナリオ 2.他のすべての組織との既定の共有
シナリオ2のダイアグラム
シナリオ2の設定の結果
- デフォルトの組織(default-ORG)で作成されたすべてのオブジェクト(ポリシー、プール、およびプロファイル)は、開発、運用、および品質管理組織(DEV-ORG、OPS-ORG、およびQA-ORG)でそれぞれ使用できますが、その逆はできません。
- ある組織のオブジェクト(default-ORGで作成されたオブジェクトを除く)を他の組織で使用することはできません。たとえば、開発組織(DEV-ORG)は、OPS組織(OPS-ORG)でもQA組織(QA-ORG)でも使用できません。
- デフォルトのリソースグループ(default-RG)は、デフォルトの組織(default-ORG)に属していません。 default-RGに属するサーバは、別の組織に割り当てられていない限り使用できません。
シナリオ 3.QA-ORGがDEV-ORGおよびOPS-ORGと共有
シナリオ3のダイアグラム
シナリオ3の設定の結果
- DEV、OPSまたはQA組織(それぞれDEV-ORG、OPS-ORGおよびQA-ORG)で作成されたオブジェクトをデフォルトの組織(default-ORG)で使用することはできません。逆も同様です。
- QA組織(QA-ORG)で作成されたオブジェクトは、開発/運用組織(DEV-ORGおよびOPS-ORG)で使用できます。
- DEV、OPSおよびデフォルトの組織(それぞれDEV-ORG、OPS-ORGおよびdefault-ORG)で作成されたオブジェクトは、QA組織(QA-ORG)で使用できません。
- QAリソースグループ(QA-RG)がQA組織(QA-ORG)に属していません。QA-RGに属するサーバは、別の組織に割り当てられていない限り使用できません。
このシナリオの最も直感的なソリューションは、QA-RGがDEV-ORGおよびOPS-ORGに関連付けられていることです。
シナリオ3のソリューション案のダイアグラム
これは、シナリオ3の直感的なソリューションとして提案する構成の結果です。DEVおよびOPS組織(DEV-ORGおよびOPS-ORG)がQAリソースグループ(QA-RG)に関連付けられていることがわかります。
シナリオ 4.QA-ORGとのデフォルト共有、OPS-ORGとのDEV-ORG共有
シナリオ4のダイアグラム
シナリオ4の設定の結果
- DEVおよびOPS組織(DEV-ORGおよびOPS-ORG)で作成されたオブジェクトは、QAおよびデフォルトの組織(QA-ORGおよびdefault-ORG)やその逆の組織では使用できません。
- DEV Organization(DEV-ORG)で作成されたオブジェクトはOPS Organization(OPS-ORG)で使用できますが、その逆はできません。
- 同じことが、デフォルトおよびQA組織(default-ORGおよびQA-ORG)にも当てはまります。 default-ORGで作成されたオブジェクトはQA-ORG組織で使用できますが、その逆はできません。
- デフォルトのリソースグループ(default-RG)は、デフォルトの組織(default-ORG)に属していません。 DEVリソースグループ(DEV-RG)と同じですが、DEV組織(DEV-ORG)に属さなくなりました。両方のリソースグループは、他の組織によって管理されていない限り使用できません。
このシナリオの場合、最も直感的なソリューションはORG-RGとDEV-RGに関連付けられているOPS-ORGです。default-RGに対する同一のソリューションで、QA-ORGに適用可能:
シナリオ4のソリューション案のダイアグラム
これは、シナリオ4の直感的なソリューションとして提案する構成の結果です。OPS組織(OPS-ORG)がOPSとDEVのリソースグループ(OPS-RGとDEV-RG)に関連付けられていることは明らかです。 一方、QA組織は、デフォルトおよびQAリソースグループ(デフォルトRGおよびQA-RG)に関連付けられています。
確認
このセクションでは、シナリオ4を参照として使用します。
サーバプロファイルの作成と割り当て
目的の組織でサーバプロファイルを作成します。
- Configure > Profiles > UCS Server Profiles > Create UCS Server Profileの順に選択します。

組織に関連付けられているサーバーが、属しているリソースグループ別に一覧表示されます。

2. ポリシーが属する組織に応じて、ポリシーをプロファイルに関連付けます。
この図は、OPSおよびDEV組織のプロファイルのポリシーを示しています。これは、DEV-ORGがOPS-ORGと共有されているためです。

Intersight API要求による
ヒント:クエリパラメータでは、エラーを回避するために、キーと値の例に同じ正確な文字を使用してください。
Intersight API Referenceに移動し、アカウントでログインします。
- /api/v1/organization/Organizationsリクエストを探します。
- 最初のGETコールを選択し、必要なクエリーパラメータを入力します。
この例では、次のパラメータを使用します。
キー |
値 |
用途 |
選択($s) |
名前、MOID |
そのオブジェクトから表示する値を選択します。 |
応答には、Intersightアカウントで作成された組織が一覧表示されます。将来の参照用に、目的の組織のMOIDをコピーします。
OPS-ORGに関連するMOIDは678acbb76972653201ddedf8です
/api/v1/server/Profiles を検索し、クエリパラメータを入力します。
この例では、次のパラメータを使用します。
キー |
値 |
用途 |
フィルタ($f) |
名前Eq 'OPS-SERVER-1' |
入力した名前を持つサーバプロファイルに出力をフィルタリングします。 |
選択($s) |
名前、MOID、組織 |
そのオブジェクトから表示する値を選択します。表示される値は、プロファイル名、プロファイルMOID、および組織MOIDです。 |
プロファイルが組織に属していることを確認します。MOIDを照合します。
プロファイル「OPS-SERVER-1」に関連付けられている組織MOIDは、OPS-ORGに対応する678acbb76972653201ddedf8です。
ポリシーについても同じことができます。この場合、/api/v1/boot/PrecisionPoliciesが使用されます。これは、ブート順序ポリシーが、そのポリシーが属する組織を確認するために求められるためです。
この例では、次のパラメータを使用します。
キー |
値 |
用途 |
フィルタ($f) |
名前Eq 'OPS-BOOT-ORDER' |
入力した名前を持つサーバプロファイルに出力をフィルタリングします。 |
選択($s) |
名前、MOID、組織 |
そのオブジェクトから表示する値を選択します。表示される値は、ポリシー名、ポリシーMOID、および組織MOIDです。 |
ポリシーOPS-BOOT-ORDERに関連付けられている組織MOIDは、678acbb76972653201ddedf8で、OPS-ORGに対応します。
トラブルシュート
問題 1.特定の組織でサーバプロファイルを作成した後にサーバがリストされない
この問題では、シナリオ4を参照として使用します。
デフォルトの組織(default-ORG)で作成されたサーバプロファイル
サーバプロファイルを割り当てようとしたときにサーバが表示されない
組織がサーバのリソースグループに直接関連付けられていることを確認します。共有組織はプール、ポリシー、プロファイルなどのオブジェクトを共有し、サーバなどのリソースを共有しないため、共有組織からはできません。
デフォルト組織(default-ORG)は、リソースグループに直接関連付けられていません。サーバー・プロファイルがQA組織(QA-ORG)ではなくQA組織を使用して作成される場合、サーバーは「サーバー割当」セクションにリストされます。
問題 2:リソースグループを削除できない
- リソースグループが組織に関連付けられていないことを確認します。その場合は、リソースグループを使用しないように組織を編集します。
問題 3:組織を削除できない
- プロファイル、プール、またはポリシーが関連付けられているかどうかを確認します。その場合は、オブジェクトを削除します。
- 「組織」テーブルを参照し、他の組織と共有されていないことを確認します。
注意:組織は、リソースグループに関連付けられている場合でも削除できます。
組織へのリソースグループの添付を検討してください。これは、プロファイル割り当てが必要であるためです。
問題 4:ファブリックインターコネクトはどの組織にも属さず、ドメインプロファイルを関連付けることができない
すべてのドメインサーバが共通のリソースグループに属していることを確認します。このリソースグループは、ドメインプロファイルを所有する組織に関連付ける必要があります。
注:シャーシ組織の動作は、ドメイン組織の動作とほとんど同じです。
問題 5:サーバがリソースグループに追加されたが、ファブリックインターコネクトに組織が表示されない
- リソースグループを編集し、変更を加えます。そのリソースグループからサーバーを選択解除します。変更を保存します。
- リソースグループを編集し、選択されていないサーバーを追加して再度追加します。変更を保存して確認します。必要に応じて2 ~ 3回繰り返します。
- Fabric Interconnectに属するすべてのサーバが、必要な組織に関連付けられているリソースグループのメンバーであることを確認します。
代替:
- リソースグループを編集し、すべてのデバイスを追加して保存します。もう1回編集し、リソースグループに属させたい特定のサーバだけを残します。(これはほとんどの場合は機能しますが、複雑さはアカウントで管理されるサーバの数に直接依存します)。
関連情報