地理的に分散された複数の VMware Cloud Director インストール環境またはサーバ グループとその組織を単一のエンティティとして管理および監視するには、VMware Cloud Director マルチサイト機能を使用します。

マルチサイトの効果的な実装

2 つの VMware Cloud Director サイトを関連付けると、これらのサイトを単一のエンティティとして管理できます。これらのサイトにある複数の組織を相互に関連付けることもできます。VMware Cloud Director でのサイトの関連付けの作成を参照してください。組織が関連付けのメンバーである場合、組織ユーザーは VMware Cloud Director Tenant Portal を使用して、任意のメンバーのサイトにある組織の資産にアクセスできます。ただし、各メンバー組織とその資産は使用するサイトにローカルに配置されます。

注：

サイトの VMware Cloud Director API バージョンは同じであるか、メジャー バージョンの差が 1 である必要があります。たとえば、VMware Cloud Director 10.1（API バージョン 34.0）のサイトを VMware Cloud Director サイト バージョン 10.0、10.1、10.2、または 10.2.2（それぞれ API バージョンは 33.0、34.0、35.0、または 35.2）に関連付けることができます。

2 つのサイトを関連付けた後、VMware Cloud Director API または VMware Cloud Director Tenant Portal を使用して、それらのサイトを使用する組織を関連付けることができます。『VMware Cloud Director API プログラミング ガイド』または『VMware Cloud Director テナント ガイド』のマルチサイト展開の構成と管理トピックを参照してください。

サイトまたは組織がピアと作成できる関連付けの数には上限がありませんが、各関連付けには必ず 2 つのメンバーを含めます。各サイトまたは組織には、独自のプライベート キーを設定する必要があります。関連付けの各メンバーはパブリック キーを交換して信頼関係を確立します。パブリック キーはメンバー間の署名要求を確認するために使用されます。

関連付けられた各サイトは、VMware Cloud Director サーバ グループ（VMware Cloud Director データベースを共有するサーバのグループ）の範囲によって定義されます。関連付けられた各組織は、1 つのサイトを使用します。組織管理者は、各メンバー サイトにある資産への組織ユーザーおよびグループによるアクセスを制御します。

サイトのオブジェクトとサイトの関連付け

インストールまたはアップグレード プロセスでは、ローカルの VMware Cloud Director サーバ グループを表す Site オブジェクトが作成されます。複数の VMware Cloud Director サーバ グループで管理権限を持つシステム管理者は、VMware Cloud Director サイトの関連付けとして、これらのサーバ グループを構成できます。

サイト名

各 Site オブジェクトは、UUID である名前属性を使用して作成されます。 
GET https://Site-B.example.com/api/site
...
<Site name="b5920690-fe13-4c31-8e23-9e86005e7a7b" ...>
   ...
   <RestEndpoint>https://Site-A.example.com/api/org/Org-A</RestEndpoint>
   <RestEndpointCertificate>-----BEGIN CERTIFICATE-----
      MIIDDTCCAfWgAwIBAgI...Ix0eSE= -----END CERTIFICATE-----
   </RestEndpointCertificate>
   ...
</Site>
サイト名が API エンドポイントのホスト名と一致する必要はありませんが、システム管理者は、 VMware Cloud Director API ユーザーの管理上の便宜のためにサイト名を次のような要求で更新できます。 
PUT https://Site-B.example.com/api/site
content-type: application/vnd.vmware.vcloud.site+xml
...
<Site name="Site-B" ...>
   ...
   <RestEndpoint>https://Site-A.example.com/api/org/Org-A</RestEndpoint>
   <RestEndpointCertificate>-----BEGIN CERTIFICATE-----
      MIIDDTCCAfWgAwIBAgI...Ix0eSE= -----END CERTIFICATE-----
   </RestEndpointCertificate>
   ...
</Site>
要求の本文内の Site 要素は、 GET .../site 要求によって返された形式を保持する必要があります。証明書の前後に追加の文字、特にキャリッジリターン、ラインフィード、またはスペースがあると、システムは不正な要求の例外を返す可能性があります。

組織の関連付け

サイトの関連付けが完了したら、メンバー サイトの 組織管理者は組織の関連付けを開始できます。
注： テナントの組織に System 組織を関連付けることはできません。任意のサイトにある System 組織は、別のサイトにある System 組織にのみ関連付けることができます。

承認ヘッダーと要求のファンアウト

成功したログイン要求に対する Session 応答には、X-VMWARE-VCLOUD-ACCESS-TOKEN ヘッダーが含まれ、その値はエンコードされたキーになります。この値は X-VMWARE-VCLOUD-TOKEN-TYPE ヘッダーの値とともに、関連付けメンバーへの認証ができない廃止された x-vcloud-authorization ヘッダーの代わりに、以降の要求に含められる JWT Authorization ヘッダーを作成するために使用できます。VMware Cloud Director API へのログインの詳細については、「VMware Cloud Director API セッションの作成」を参照してください。

Accept ヘッダーで multisite=value ペアを指定することにより、複数の関連付けメンバーをファンアウトする要求の作成が可能です。要求をファンアウトする場合、value は global またはコロン区切りのリスト形式のロケーション ID となります。ロケーション ID の取得方法については、承認済みの場所 を参照してください。value を local に設定すると、要求はファンアウトしませんが、ファンアウトで含まれるマルチサイト メタデータが含まれます。

たとえば、組織の関連付けからリソースのリストを取得するクエリなどの要求を作成するときに、 Accept ヘッダーに multisite=global ペアを指定できます。 multisite=global ペアを指定することで、要求をすべての関連メンバーにファンアウトし、集約されたリストを返します。 
Accept: application/*;version=30.0;multisite=global

ロケーション ID を multisite=ID-a:ID-b:ID-x のようなコロン区切りのリスト形式で指定できます。Accept ヘッダーにこの値を指定する場合を除き、要求に対して、要求の対象である組織が所有するリソースのみが返されます。認証した組織への要求をする場合を除き、要求に対応する組織の名前を指定した X-VMWARE-VCLOUD-AUTH-CONTEXT ヘッダーを追加する必要もあります。

認証要求に multisite= value ペアが含まれていると、要求がいずれかの関連付けメンバーで失敗した場合、応答には Link 要素が含まれます。エラーのカテゴリは、リンクの rel の値で表されます。
rel="fanout:failed"
メンバーのステータスは ACTIVE ですが、何らかの理由でメンバーでの認証が失敗しました。
rel="fanout:skipped"
関連付けのステータスが ASYMMETRIC または UNREACHABLE であったため、メンバーでの認証がスキップされました。
失敗またはスキップされた要求の URL は Link の href 値にあります。

承認済みの場所

関連付けのメンバー サイトに対して認証する場合、 Session の応答には、他の関連付けメンバーの VMware Cloud Director API および VMware Cloud Director テナント ポータル エンドポイントを提供する AuthorizedLocations 要素が含まれます。この例では、次のようになります。
  • Site-A.example.com と Site-B.example.com が関連付けられています。
  • ユーザーはシステム管理者としてサイト A にログインします。
要求： 
POST https://Site-A.example.com/api/sessions
Authorization: Basic ...
Accept: application/*;version=30.0
...
応答： 
200 OK
...
X-VMWARE-VCLOUD-ACCESS-TOKEN: eyJhbGciOiJSUzI1NiJ9....Rn4Xw
X-VMWARE-VCLOUD-TOKEN-TYPE: Bearer
Content-Type: application/vnd.vmware.vcloud.session+xml;version=30.0;multisite=global
...
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Session ...
   ...  
   <AuthorizedLocations>
      <Location>
         <LocationId>a93c9db9-7471-3192-8d09-a8f7eeda85f9@9a41...
         </LocationId>
         <SiteName>Site-A</SiteName>
         <OrgName>System</OrgName>
         <RestApiEndpoint>https://site-a.example.com
         </RestApiEndpoint>
         <UIEndpoint>https://site-a.example.com
         </UIEndpoint>
         <AuthContext>System</AuthContext>
      </Location>
      <Location>
         <LocationId>a93c9db9-7471-3192-8d09-a8f7eeda85f9@4f56...
         </LocationId>
         <SiteName>Site-B</SiteName>
         <OrgName>System</OrgName>
         <RestApiEndpoint>https://site-b.example.com
         </RestApiEndpoint>
         <UIEndpoint>https://site-b.example.com
         </UIEndpoint>
         <AuthContext>System</AuthContext>
      </Location>
   </AuthorizedLocations>
</Session>

ユーザーおよびグループの ID

サイトおよび組織の関連付けでは、同じ ID プロバイダ (IDP) を使用することに同意する必要があります。関連付けられたすべての組織のユーザーおよびグループの ID は、この IDP が管理する必要があります。

関連付けでは、最適な IDP を自由に選択できます。VMware Cloud Director での ID プロバイダの管理を参照してください。

VMware Cloud Director 10.4.1 以降では、サービス アカウントはマルチサイト機能を使用して、地理的に分散された複数の VMware Cloud Director インストール環境またはサーバ グループとその組織を単一エンティティとして管理および監視できます。サービス アカウントが、認証の対象となる組織とは異なる組織に要求を行う場合は、サービス アカウントが関連付けられた組織に存在し、同じ名前とソフトウェア ID を保持していることを確認します。VMware Cloud Director でのサービス アカウントの管理を参照してください。

組織のユーザーおよびグループのサイト アクセス コントロール

組織管理者は、各自の IDP を設定して、ユーザーまたはグループのアクセス トークンを生成できます。このアクセス トークンはすべてのメンバー サイトで有効にすることも、一部のメンバー サイトのみで有効にすることもできます。ユーザーおよびグループの ID は、すべてのメンバー組織で同じにする必要がありますが、ユーザーおよびグループの権限は、各メンバー組織内でユーザーおよびグループが割り当てられているロールによって制約されます。ユーザーまたはグループへのロールは、作成したカスタム ロールと同様に、メンバー組織にローカルで割り当てられます。

ロード バランサの要件

マルチサイト展開を効果的に実装するには、ロード バランサを設定して、組織のエンドポイント（https://vcloud.example.com など）に送信される要求を、サイト関連付けの各メンバーのエンドポイント（https://us.vcloud.example.com や https://uk.vcloud.example.com など）に分散する必要があります。サイトに複数のセルがある場合は、受信する要求をすべてのセルで分散するロード バランサも設定する必要があります。これにより、https://us.vcloud.example.com への要求を、https://cell1.us.vcloud.example.com、https://cell2.us.vcloud.example.com などで処理できます。

注： グローバル ロード バランサ（この場合は https://vcloud.example.com）は、ユーザー インターフェイスへのアクセス専用にする必要があります。REST API を使用する独自のスクリプトまたはプログラムを開発する場合、この呼び出しは特定のサイトをターゲットにする必要があります。

VMware Cloud Director 10.3 以降では、マルチサイト展開のロードバランシング エンドポイントに送信されたすべてのクライアント要求がリダイレクトされます。要求がロード バランシング エンドポイントに送信されると、要求が送信されたサイトが正しいサイトである場合もリダイレクトが実行され、ユーザーに表示される URL に反映されるため、要求が正しい場所に転送されたことがわかります。

たとえば、グローバル ロードバランシング エンドポイント https://us.vcloud.example.com の背後に、https://site1.vcloud.example.com と https://site2.vcloud.example.com の 2 つのサイトで構成された展開を配置できます。VMware Cloud Director 10.3 以降では、サイト 1 (https://us.vcloud.example.com/org1) にある組織のロード バランシング エンドポイントに要求が送信された場合、サイトは要求がサイト 1 に到着した時点で要求を https://site1.vcloud.example.com/org1 に転送して、自身へのリダイレクトを実行します。VMware Cloud Director 10.2.x 以前のバージョンでは、ロード バランサが同じ場所にある組織の要求を受信して、この要求がパブリック エンドポイントの URL (https://us.vcloud.example.com/org1) を介して処理される場合、リダイレクトは実行されません。

ネットワーク接続の要件

マルチサイト機能を使用する場合は、各サイトの各セルが、すべてのサイトの REST API エンドポイントに REST API 要求を実行できる必要があります。「ロード バランサの要件」セクションの例を使用する場合は、cell1.us.vcloud.example.com および cell2.us.vcloud.example.com から uk.example.com の REST API エンドポイントにアクセスできる必要があります。その逆は、uk.example.com のすべてのセルで成立します。つまり、セルは自身の REST API エンドポイントに REST API 呼び出しを実行できる必要があるため、cell1.us.vcloud.example.com から https://us.vcloud.example.com への REST API 呼び出しが可能である必要があります。

REST API のファンアウトを行うには、すべてのサイトの REST API エンドポイントに対して REST API 要求を行う必要があります。たとえば、ユーザー インターフェイスまたは API クライアントがマルチサイト要求を行い、すべてのサイトから組織のページを取得して、cell1.us.vcloud.example.com で要求を処理する場合を考えます。セル cell1 は REST API 呼び出しを行って、各サイトに構成された REST API エンドポイントを使用してサイトから組織のページを取得する必要があります。すべてのサイトから組織のページが返されたら、cell1 は結果を照合し、他のすべてのサイトのデータを含む結果を 1 ページにまとめて返します。

サイトと証明書

サイトが他のサイトに関連付けられている場合に、証明書を更新する場合、他のサイトへの変更の通知が必要になることがあります。他のサイトに証明書の変更を知らせない場合、マルチサイトのファンアウトが影響を受ける可能性があります。

サイトの証明書を適切に署名された有効な証明書に置き換える場合は、他のサイトに通知する必要はありません。証明書は有効で、適切に署名されているため、他のサイトのセルは中断することなく、安全な方法で接続し続けることができます。

サイトの証明書を自己署名証明書に置き換える場合、または自動信頼の妨げとなる他の問題が証明書にある場合は、他のサイトに通知する必要があります。たとえば、証明書が期限切れの場合は、他のサイトに通知する必要があります。他の各サイトで、 Service Provider Admin Portal の [信頼されている証明書] に証明書をアップロードする必要があります。 VMware Cloud Director Service Provider Admin Portal を使用した信頼されている証明書のインポートを参照してください。証明書をインポートすると、証明書がアップロードされたサイトは新しい証明書を取得してサイトを信頼できます。
注： これらの証明書は、リモート サイトにインストールする前に、他のサイトの [信頼されている証明書] にインポートできます。これにより、古い証明書と新しい証明書の両方が信頼されている証明書プールに配置されるため、通信が中断されなくなります。サイトを再び関連付ける必要はありません。

関連付けメンバーのステータス

サイトまたは組織の関連付けを作成した後、ローカル システムは各リモート関連付けメンバーのステータスを定期的に取得し、ローカル サイトの VMware Cloud Director データベースの該当するステータスを更新します。メンバーのステータスは、 SiteAssociationMember または OrgAssociationMember の Status 要素に表示されます。 Status 要素には、以下の 3 つの値のいずれかが含まれます。
ACTIVE
両者の間で関連付けが確立され、リモート側との通信が正常に行われました。
ASYMMETRIC
ローカル サイトでの関連付けが確立されましたが、リモート サイトからの応答がありません。
UNREACHABLE
両者の間で関連付けが確立されましたが、現在リモート サイトがネットワーク上でアクセスできません。

Service Provider Admin Portal および Tenant Portal では、ステータスは Connected、Partially Connected、Unreachable と表示されます。

メンバー ステータスの「ハートビート」は、マルチサイト システムのユーザー ID、つまり VMware Cloud Director のインストール中にシステム組織で作成したローカルの VMware Cloud Director ユーザー アカウントを使用して実行されます。このアカウントはシステム組織のメンバーですが、システム管理者の権限はありません。このアカウントには、Multisite: System Operations という権限のみが付与されています。これにより、サイト関連付けのリモート メンバーのステータスを取得する VMware Cloud Director API 要求を行うことができます。