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.
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 del tenant 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
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
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.
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.
- 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.
Posizioni autorizzate
- Site-A.example.com e Site-B.example.com sono associati.
- L'utente accede a Site-A come amministratore di sistema.
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>
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.
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.
Stato di un membro dell'associazione
- 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.