In questa sezione viene descritto il modello multi-tenancy e illustrato in che modo è possibile accedere ai tenant tramite i relativi nomi di dominio completo. Viene inoltre spiegato perché è importante abilitare la multi-tenancy insieme al certificato e quali sono i requisiti DNS.
Abilitazione della multi-tenancy
Il tenant master ora viene chiamato tenant primario. Anche se il giorno 0 il componente VMware Identity Manager pronto all'uso dispone già di un tenant primario, questo viene mantenuto in una configurazione minima e non è possibile creare ulteriori tenant inclusi nel tenant primario. Per abilitare la multi-tenancy, occorre eseguire una sequenza di configurazioni e chiamate API su VMware Identity Manager. Per abilitare la multi-tenancy è necessario che sia stato creato un nome alias per il tenant primario. Per ulteriori informazioni sull'abilitazione della multi-tenancy, vedere Abilitazione della multi-tenancy.
Un VMware Identity Manager con nome di dominio completo 'idm1.vmwlab.local' può, ad esempio, disporre già di un tenant primario con nome 'idm1'. Prima di abilitare la multi-tenancy, è obbligatorio creare un alias per il tenant primario, ad esempio impostando "master-tenant" e utilizzando lo stesso nome alias ogni volta che si fa riferimento al tenant primario.
Nomi FQDN dei tenant
Per impostazione predefinita, i tenant creati in VMware Identity Manager sono accessibili tramite URL di tenant, ovvero nomi FQDN mappati al server VMware Identity Manager. Ogni tenant ha il proprio nome di dominio completo. Ad esempio, su un VMware Identity Manager a nodo singolo con nome host idm1.vmwlab.local, con nome tenant primario (idm1) e alias del tenant primario (master-tenant), è necessario accedere al tenant primario tramite il relativo nome di dominio completo master-tenant.vmwlab.local. Se viene creato un nuovo tenant (tenant1), è necessario accedervi solo tramite tenant1.vmwlab.local.
Poiché ogni tenant richiede un nome di dominio completo dedicato, la creazione di tenant su VMware Identity Manager richiede obbligatoriamente che un record DNS di tipo A esegua la mappatura del nome di dominio completo del tenant all'indirizzo IP del server VMware Identity Manager. Per una distribuzione di VMware Identity Manager in cluster, il nome di dominio completo di ogni tenant deve includere una mappatura del record di tipo A all'indirizzo IP del bilanciamento del carico di VMware Identity Manager.
Lo stesso modello è valido anche per vRealize Automation. Quando vRealize Automation è associato a un tenant, è necessario eseguire l'accesso al tenant di vRealize Automation tramite i nomi FQDN del tenant di vRealize Automation. Ad esempio, VMware Identity Manager con nome di dominio completo idm1.vmwlab.local e un tenant "tenant1" accessibile tramite tenant1.vmwlab.local e vRealize Automation 8.1 vra1.vmwlab.local integrato con questo VMware Identity Manager e associato a "tenant1". Come indicato, il tenant di vRealize Automation e il tenant di VMware Identity Manager presentano una mappatura 1:1, pertanto il tenant primario di vRealize Automation è comunque accessibile tramite vra1.vmwlab.local e l'accesso al "tenant 1" di vRealize Automation deve essere eseguito tramite tenant1.vra1.vmwlab.local.
Analogamente a VMware Identity Manager, anche i nomi di dominio completo del tenant di vRealize Automation richiedono la mappatura DNS. Tuttavia, per un vRealize Automation occorre specificare un record di tipo CNAME che mappa i nomi di dominio completo del tenant di vRealize Automation al nome di dominio completo del server vRealize Automation. Per una distribuzione di vRealize Automation in cluster, tutti i nomi di dominio completi del tenant di vRealize Automation devono avere un record DNS di tipo CNAME che punta al nome di dominio completo del bilanciamento del carico di vRealize Automation.
Per il funzionamento della tenancy, oltre alle mappature DNS come prerequisito obbligatorio, sono richiesti anche i certificati. I server VMware Identity Manager e vRealize Automation e i rispettivi bilanciamenti del carico, in base all'architettura di distribuzione, devono includere i certificati corrispondenti con tutti i nomi FQDN dei tenant richiesti.
- VMware Identity Manager Nodo: idm1.vmwlab.local
vRealize Automation Nodo: vra1.vmwlab.local
Nome alias tenant primario: master-tenant
Tenant: tenant-1, tenant-2
| Nomi tenant | Nomi FQDN dei tenant di VMware Identity Manager | Nomi FQDN dei tenant di vRealize Automation |
|---|---|---|
| master-tenant | https://master-tenant.vmwlab.local | https://vra1.vmwlab.local |
| tenant-1 | https://tenant-1.vmwlab.local | https://tenant-1.vra1.vmwlab.local |
| tenant-2 | https://tenant-2.vmwlab.local | https://tenant-2.vra1.vmwlab.local |
- VMware Identity Manager Bilanciamento del carico: idm-lb.vmwlab.local
VMware Identity Manager Nodi: idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local
vRealize Automation Bilanciamento del carico: vra-lb.vmwlab.local
vRealize Automation Nodi: vra1.vmwlab.local, vra2.vmwlab.local, vra3.vmwlab.local
Nome alias del tenant primario: master-tenant
Tenant: tenant-1, tenant-2
| Nomi tenant | Nomi FQDN dei tenant di VMware Identity Manager | Nomi FQDN dei tenant di vRealize Automation |
|---|---|---|
| master-tenant | https://master-tenant.vmwlab.local | https:// vra-lb.vmwlab.local |
| tenant-1 | https://tenant-1.vmwlab.local | https://tenant-1.vra-lb.vmwlab.local |
| tenant-2 | https://tenant-2.vmwlab.local | https://tenant-2.vra-lb.vmwlab.local |
Requisiti di certificato obbligatori
- Quando si modificano i certificati in VMware Identity Manager per abilitare la multi-tenancy o creare i tenant, si verifica un'interruzione o inattività del servizio. Se il certificato di VMware Identity Manager viene modificato, il servizio registra un periodo di inattività. I prodotti o i servizi integrati con VMware Identity Manager a scopo di autenticazione non possono utilizzare il meccanismo di autenticazione AUTH LOGIN di VMware Identity Manager durante il periodo di inattività. Inoltre, la modifica del certificato di VMware Identity Manager richiede un nuovo processo di attendibilità su tutti i prodotti o servizi, il che comporta ancora una volta un tempo di inattività per i prodotti.
- Per ogni nuovo tenant creato e associato a vRealize Automation, è necessario modificare anche i certificati di vRealize Automation e questo genera un tempo di inattività del servizio per vRealize Automation.
- Per evitare tempi di inattività del servizio su vRealize Automation, VMware Identity Manager e altri prodotti o servizi integrati con VMware Identity Manager, in genere è consigliabile utilizzare certificati con caratteri jolly. Per un nuovo tenant, qualsiasi modifica apportata al certificato di VMware Identity Manager o al certificato di vRealize Automation può creare un tempo di inattività in vRealize Automation.
- Se non vengono utilizzati certificati con caratteri jolly, è necessario creare voci SAN specifiche per ciascun nome di dominio completo del tenant in tutti i certificati richiesti.
- Il servizio Locker di vRealize Suite Lifecycle Manager consente di gestire i certificati nei nodi dei server VMware Identity Manager e vRealize Automation. Con vRealize Suite Lifecycle Manager, quando si sostituisce il certificato di VMware Identity Manager, viene automaticamente eseguito il processo di attendibilità di VMware Identity Manager su tutti i prodotti.
- I prodotti o i servizi esterni a vRealize Suite Lifecycle Manager vengono gestiti manualmente. Il servizio Locker non gestisce l'aggiornamento dei certificati del bilanciamento del carico. L'operazione deve essere eseguita manualmente dall'utente. Ogni volta che si modificano i certificati del bilanciamento del carico, occorre sottoporli al processo di attendibilità sui prodotti.
- Per VMware Identity Manager, l'operazione di aggiornamento o sostituzione dei certificati di VMware Identity Manager in vRealize Suite Lifecycle Manager garantisce internamente che il certificato del bilanciamento del carico di VMware Identity Manager sia considerato nuovamente attendibile prima di aggiornare i certificati del server VMware Identity Manager. Pertanto, è consigliabile modificare prima manualmente il certificato del bilanciamento del carico di VMware Identity Manager e quindi creare un certificato VMware Identity Manager da aggiornare o sostituire tramite il servizio Locker di vRealize Suite Lifecycle Manager.
- Per un vRealize Automation 8.x, se SSL viene terminato a livello del bilanciamento del carico di vRealize Automation e il certificato del bilanciamento del carico viene modificato manualmente, è necessario fare clic su "Considera di nuovo attendibile il bilanciamento del carico" nella scheda del prodotto vRealize Automation 8.x per considerare nuovamente attendibile il certificato del bilanciamento del carico in vRealize Automation. Per ulteriori dettagli, vedere Operazioni del giorno 2 con altri prodotti in vRealize Suite Lifecycle Manager.
Requisiti DNS obbligatori
Per un VMware Identity Manager a nodo singolo, è necessario che i record DNS di tipo A contengano i nomi di dominio completo dei tenant nell'indirizzo IP del server VMware Identity Manager. Per un VMware Identity Manager in cluster, sono necessari record DNS di tipo A che indirizzano i nomi di dominio completo dei tenant all'indirizzo IP del bilanciamento del carico di VMware Identity Manager.
Per vRealize Automation a nodo singolo sono necessari record DNS di tipo CNAME che indirizzano i nomi di dominio completo dei tenant di vRealize Automation al nome di dominio completo del server vRealize Automation. Per un vRealize Automation in cluster, sono necessari record DNS di tipo CNAME che indirizzano i nomi di dominio completo dei tenant di vRealize Automation al nome di dominio completo del bilanciamento del carico di vRealize Automation.
Requisiti per la multi-tenancy
 |
|
|
|
