Per gestire e monitorare più installazioni o gruppi di server di VMware Cloud Director distribuiti geograficamente e le relative organizzazioni come singole entità, è possibile utilizzare la funzionalità multisito di VMware Cloud Director.

Implementazione efficace di un multisito

Quando si associano due siti di VMware Cloud Director, si abilita l'amministrazione dei siti come singola entità. Si abilita inoltre l'associazione delle organizzazioni di tali siti. Vedere Creazione di un'associazione di siti nel VMware Cloud Director. Quando un'organizzazione fa parte di un'associazione, gli utenti dell'organizzazione possono utilizzare il VMware Cloud Director Tenant Portal per accedere alle risorse dell'organizzazione che si trovano in qualsiasi sito membro, anche se ciascuna organizzazione membro e le relative risorse si trovano in locale nel sito che occupano.

Nota:

I siti devono avere la stessa versione dell'API di VMware Cloud Director oppure la versione principale immediatamente precedente o successiva. Ad esempio, è possibile associare un sito VMware Cloud Director 10.1 (API versione 34.0) a un sito VMware Cloud Director versione 10.0, 10.1, 10.2 o 10.2.2, rispettivamente con le versioni API 33.0, 34.0, 35.0 o 35.2.

Dopo aver associato due siti, è possibile utilizzare l'API di VMware Cloud Director o VMware Cloud Director Tenant Portal per associare le organizzazioni che occupano tali siti. Consultare l'argomento Guida alla programmazione dell'API di VMware Cloud Director o l'argomento Configurazione e gestione di distribuzioni multisito in Guida ai tenant e ai provider secondari di VMware Cloud Director.

Un sito o un'organizzazione può creare un numero illimitato di associazioni con un peer, ma ciascuna associazione include esattamente due membri. Ciascun sito od organizzazione deve disporre della propria chiave privata. I membri di un'associazione stabiliscono una relazione di attendibilità attraverso lo scambio di chiavi pubbliche che vengono utilizzate per verificare le richieste firmate inviate da un membro all'altro.

Ciascun sito di un'associazione viene definito dall'ambito di un gruppo di server VMware Cloud Director (un gruppo di server che condivide un database di VMware Cloud Director). Ciascuna organizzazione di un'associazione occupa un singolo sito. L'amministratore dell'organizzazione controlla l'accesso agli asset di ogni sito membro da parte di utenti e gruppi dell'organizzazione.

Oggetti Site e associazioni di siti

Il processo di installazione o aggiornamento crea un oggetto Site che rappresenta il gruppo di server VMware Cloud Director locale. Un amministratore di sistema la cui autorità si estende a più gruppi di server VMware Cloud Director può configurare tali gruppi di server come un'associazione di siti di VMware Cloud Director.

Nomi dei siti

Ciascun oggetto Site viene creato con un attributo nome che è un 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>
Nonostante il nome del sito non debba necessariamente corrispondere al nome host nell'endpoint dell'API, l'amministratore di sistema può aggiornare il nome del sito per agevolare gli utenti dell'API di VMware Cloud Director, con una richiesta simile a questa: 
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>
L'elemento Site nel corpo della richiesta deve mantenere la formattazione con cui è stato restituito dalla richiesta GET .../site. Caratteri aggiuntivi, in particolare ritorni a capo, avanzamenti riga o spazi, prima o dopo i certificati, possono determinare la restituzione di un'eccezione di richiesta non valida da parte del sistema.

Associazioni di organizzazioni

Una volta completata l'associazione del sito, gli amministratori dell'organizzazione di qualsiasi sito membro possono iniziare ad associare le rispettive organizzazioni.
Nota: Non è possibile associare un'organizzazione System a un'organizzazione tenant. L'organizzazione System in qualsiasi sito può essere associata solo all'organizzazione System in un altro sito.

Intestazioni delle autorizzazioni e fan-out della richiesta

La risposta Session a una richiesta di accesso riuscita include un'intestazione X-VMWARE-VCLOUD-ACCESS-TOKEN il cui valore è una chiave codificata che è possibile utilizzare, insieme al valore dell'intestazione X-VMWARE-VCLOUD-TOKEN-TYPE, per creare un'intestazione JWT Authorization da includere nelle richieste successive al posto dell'intestazione x-vcloud-authorization obsoleta, che non consente di eseguire l'autenticazione nei membri dell'associazione. Vedere Creazione di una sessione dell'API di VMware Cloud Director per ulteriori informazioni sull'accesso all'API di VMware Cloud Director.

È possibile creare richieste ed estenderle a più membri dell'associazione specificando la coppia multisite=value nell'intestazione Accept. Se si desidera che venga effettuato il fan-out della richiesta, value può essere global o un elenco di ID posizione separati da due punti. Per informazioni su come ottenere gli ID posizione, vedere Posizioni autorizzate. Quando si imposta value su local, non viene effettuato il fan-out della richiesta che però include metadati multisito inclusi nel fan-out.

Quando si effettua una richiesta, ad esempio una query che recupera elenchi di risorse da un'associazione di organizzazioni, è possibile specificare la coppia multisite=global nell'intestazione Accept. Se si specifica la coppia multisite=global, la richiesta viene estesa a tutti i membri dell'associazione e viene restituito un elenco aggregato. 
Accept: application/*;version=30.0;multisite=global

È possibile specificare un elenco di ID posizione separati da due punti, ad esempio multisite=ID-a:ID-b:ID-x. A meno che questo valore non venga incluso nell'intestazione Accept, la richiesta restituisce solo le risorse di proprietà dell'organizzazione di destinazione della richiesta. A meno che non si stia effettuando una richiesta alla stessa organizzazione in cui è stata eseguita l'autenticazione, è inoltre necessario includere un'intestazione X-VMWARE-VCLOUD-AUTH-CONTEXT che specifichi il nome dell'organizzazione che soddisferà la richiesta.

Quando una richiesta di autenticazione include la coppia multisite= value, la risposta include elementi Link se la richiesta non riesce in qualche membro dell'associazione. La categoria dell'errore è rappresentata dal valore rel del collegamento.
rel="fanout:failed"
Lo stato del membro era ACTIVE, ma l'autenticazione nel membro non è riuscita per un altro motivo.
rel="fanout:skipped"
L'autenticazione nel membro è stata ignorata perché lo stato dell'associazione era ASYMMETRIC o UNREACHABLE.
L'URL della richiesta non riuscita o ignorata si trova in href, ovvero il valore di Link.

Posizioni autorizzate

Quando esegue l'autenticazione in un sito che è un membro di un'associazione, la risposta di Session include un elemento AuthorizedLocations che fornisce le API di VMware Cloud Director e gli endpoint del portale tenant di VMware Cloud Director per altri membri dell'associazione. Nell'esempio seguente:
  • Site-A.example.com e Site-B.example.com sono associati.
  • L'utente accede a Site-A come amministratore di sistema.
Richiesta: 
POST https://Site-A.example.com/api/sessions
Authorization: Basic ...
Accept: application/*;version=30.0
...
Risposta: 
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>

Identità di utenti e gruppi

Le associazioni di siti e organizzazioni devono accettare di utilizzare lo stesso provider di identità. Le identità di utenti e gruppi per tutte le organizzazioni nell'associazione devono essere gestite tramite questo provider di identità.

Le associazioni sono libere di scegliere il provider di identità che funziona meglio per loro. Vedere Gestione dei provider di identità in VMware Cloud Director.

A partire da VMware Cloud Director 10.4.1, gli account di servizio possono gestire e monitorare più installazioni o gruppi di server di VMware Cloud Director distribuiti geograficamente e le relative organizzazioni come singole entità utilizzando la funzionalità multisito. Se un account di servizio effettua una richiesta a un'organizzazione diversa da quella in cui è autenticato, verificare che l'account di servizio esista nell'organizzazione associata e che disponga dello stesso nome e ID software. Vedere Gestione degli account di servizio in VMware Cloud Director.

Controllo dell'accesso al sito per utenti e gruppi dell'organizzazione

Gli amministratori dell'organizzazione possono configurare il proprio provider di identità in modo che generi token di accesso di utenti o gruppi che siano validi in tutti i siti membri oppure solo in un sottoinsieme di siti membri. Mentre le identità di utenti e gruppi devono essere le stesse in tutte le organizzazioni membro, i diritti di utenti e gruppi sono limitati dai ruoli assegnati a tali utenti e gruppi in ogni organizzazione membro. L'assegnazione di un ruolo a un utente o un gruppo è locale rispetto all'organizzazione membro, così come gli eventuali ruoli personalizzati che vengono creati.

Requisiti di bilanciamento del carico

L'implementazione efficace di una distribuzione multisito richiede la configurazione di un bilanciamento del carico che distribuisca le richieste in arrivo in un endpoint istituzionale, come https://vcloud.example.com, agli endpoint per ciascun membro dell'associazione dei siti (ad esempio, https://us.vcloud.example.com e https://uk.vcloud.example.com). Se un sito dispone di più celle, è inoltre necessario configurare un bilanciamento del carico che distribuisca le richieste in arrivo a tutte le celle, in modo che una richiesta a https://us.vcloud.example.com possa essere gestita da https://cell1.us.vcloud.example.com, https://cell2.us.vcloud.example.com e così via.

Nota: È necessario utilizzare il bilanciamento del carico globale, in questo caso https://vcloud.example.com solo per l'accesso all'interfaccia utente. Se si sviluppano script o programmi personalizzati che utilizzano la REST API, queste chiamate devono avere come destinazione un determinato sito.

A partire da VMware Cloud Director 10.3, tutte le richieste del client che arrivano all'endpoint del bilanciamento del carico per una distribuzione multisito vengono reindirizzate. Quando una richiesta arriva all'endpoint di bilanciamento del carico, anche se il sito in cui arriva la richiesta è quello corretto, viene emesso un reindirizzamento che viene indicato nell'URL visibile dall'utente per specificare che la richiesta è stata indirizzata alla posizione corretta.

Ad esempio, è possibile che sia presente una distribuzione composta da due siti, https://site1.vcloud.example.com e https://site2.vcloud.example.com, dietro un endpoint di bilanciamento del carico globale https://us.vcloud.example.com. A partire da VMware Cloud Director 10.3, quando una richiesta arriva all'endpoint del bilanciamento del carico per un'organizzazione che si trova nel sito 1, https://us.vcloud.example.com/org1, se la richiesta arriva al sito 1, il sito emette un reindirizzamento a se stesso inoltrando la richiesta a https://site1.vcloud.example.com/org1. VMware Cloud Director 10.2.x e versioni precedenti non emettono reindirizzamenti quando un bilanciamento del carico riceve una richiesta per un'organizzazione che si trova nella stessa posizione e la richiesta viene inviata tramite l'URL dell'endpoint pubblico https://us.vcloud.example.com/org1.

Requisiti di connettività di rete

Se si desidera utilizzare la funzionalità multisito, ogni cella di ciascun sito deve essere in grado di effettuare le richieste della REST API agli endpoint della REST API di tutti i siti. Se si utilizzano gli esempi della sezione Requisiti di bilanciamento del carico, cell1.us.vcloud.example.com e cell2.us.vcloud.example.com devono essere in grado di raggiungere l'endpoint della REST API per uk.example.com. Vale il contrario per tutte le celle in uk.example.com. Ciò significa che una cella deve anche poter effettuare chiamate REST API all'endpoint della propria REST API. Pertanto cell1.us.vcloud.example.com deve essere in grado di effettuare una chiamata REST API a https://us.vcloud.example.com.

La capacità di effettuare richieste della REST API agli endpoint della REST API di tutti i siti è necessaria per il fan-out della REST API. Ad esempio, se l'interfaccia utente o un client API effettua una richiesta multisito per ottenere una pagina delle organizzazioni da tutti i siti e cell1.us.vcloud.example.com gestisce la richiesta, la cella cell1 deve effettuare una chiamata REST API per ottenere una pagina delle organizzazioni da ciascun sito utilizzando l'endpoint della REST API configurato per tale sito. Quando tutti i siti restituiscono la loro pagina di organizzazioni, cell1 raccoglie i risultati e restituisce una singola pagina di risultati contenente i dati di tutti gli altri siti.

Siti e certificati

Quando un sito è associato ad altri siti, se si aggiorna il suo certificato, potrebbe essere necessario segnalare la modifica agli altri siti. La mancata segnalazione della modifica del certificato agli altri siti potrebbe influire sul fan-out multisito.

Se si sostituisce un certificato in un sito con un certificato valido e firmato correttamente, non è necessario segnalarlo agli altri siti. Poiché il certificato è valido e firmato correttamente, le celle negli altri siti possono continuare a connettersi a tale certificato in modo sicuro, senza interruzioni.

Se si sostituisce un certificato in un sito con un certificato autofirmato o se esiste un altro problema relativo al certificato che impedisce l'attendibilità automatica, è necessario segnalarlo agli altri siti. Ad esempio, se il certificato scade, è necessario segnalarlo agli altri siti. In ciascuno degli altri siti, è necessario caricare il certificato in Certificati attendibili in Service Provider Admin Portal. Vedere Importazione di certificati attendibili tramite il VMware Cloud Director Service Provider Admin Portal. Quando si importa il certificato, il sito in cui viene caricato può considerare attendibile il sito che riceve il nuovo certificato.
Nota: È possibile importare questi certificati in Certificati attendibili negli altri siti prima di installarli nel sito remoto. In questo modo, non si verificherà alcuna interruzione della comunicazione, perché sia il certificato precedente sia quello nuovo si trovano entrambi nel pool di certificati attendibili. Non è necessario associare nuovamente i siti.

Stato di un membro dell'associazione

Dopo aver creato un'associazione di siti o organizzazioni, il sistema locale recupera periodicamente lo stato di ciascun membro dell'associazione remota e aggiorna tale stato nel database VMware Cloud Director del sito locale. Lo stato del membro è visibile nell'elemento Status di un SiteAssociationMember o OrgAssociationMember. L'elemento Status può avere uno dei tre valori seguenti:
ACTIVE
L'associazione è stata stabilita da entrambe le parti e la comunicazione con la parte remota è riuscita.
ASYMMETRIC
L'associazione è stata stabilita nel sito locale, ma il sito remoto non ha ancora risposto con un'azione corrispondente.
UNREACHABLE
È stata creata un'associazione da entrambe le parti, ma il sito remoto non è al momento raggiungibile in rete.

Nel Service Provider Admin Portal e nel Tenant Portal gli stati vengono visualizzati come Connected, Partially Connected e Unreachable.

Il processo "heartbeat" dello stato del membro viene eseguito con l'identità dell'utente del sistema multisito, un account utente VMware Cloud Director locale creato nell'organizzazione System durante l'installazione di VMware Cloud Director. Nonostante questo account sia membro dell'organizzazione System, non dispone di diritti di amministratore di sistema, ma di un diritto singolo, ovvero Multisite: System Operations, che fornisce le autorizzazioni per creare una richiesta dell'API di VMware Cloud Director che recuperi lo stato del membro remoto di un'associazione di siti.