In deze sectie wordt een multitenancymodel beschreven waarbij wordt uitgelegd hoe tenants via de tenant-FQDN's kunnen worden gebruikt en hoe belangrijk het is om multitenancy in te stellen, naast het certificaat en de DNS-vereisten.
Multitenancy inschakelen
Naar de hoofdtenant wordt nu verwezen als primaire tenant. Hoewel op dag 0, de out-of-the-box VMware Identity Manager al een beschikbare primaire tenant bevat, wordt deze met een minimale configuratie bewaard en is verdere aanmaak van tenants onder de primaire tenant niet mogelijk. Er moet een reeks configuraties en API-aanroepen worden uitgevoerd op de VMware Identity Manager om multitenancy in te schakelen. Er moet een aliasnaam voor de primaire tenant zijn gemaakt wanneer u multitenancy inschakelt. Zie Multitenancy inschakelen voor meer informatie over het inschakelen van multitenancy.
Bijvoorbeeld: een VMware Identity Manager met FQDN 'idm1.vmwlab.local' kan al een primaire tenant met de naam 'idm1' hebben. Voordat u multitenancy inschakelt, is het verplicht om een alias voor de primaire tenant te maken. Stel bijvoorbeeld 'master-tenant' in en gebruik dezelfde aliasnaam overal waar naar de primaire tenant wordt verwezen.
FQDN's van tenant
Standaard zijn tenants die zijn gemaakt op VMware Identity Manager, toegankelijk via URL's van de tenant. Deze zijn FQDN's die aan de VMware Identity Manager-server zijn toegewezen. Elke tenant heeft een eigen tenant-FQDN. Bijvoorbeeld: op een VMware Identity Manager met één knooppunt en de hostnaam idm1.vmwlab.local, met de naam van de primaire tenant (idm1) en de alias van de primaire tenant (master-tenant), moet de primaire tenant toegankelijk zijn via de FQDN master-tenant.vmwlab.local. Als een nieuwe tenant (tenant1) wordt gemaakt, mag deze alleen worden gebruikt via tenant1.vmwlab.local.
Aangezien elke tenant een toegewezen FQDN vereist, vereist het maken van tenants in VMware Identity Manager een DNS-record van type A die de FQDN van de tenant toewijst aan het IP-adres van de VMware Identity Manager-server. Voor een geclusterde VMware Identity Manager-implementatie moet elke tenant-FQDN een record van A-type hebben die wordt toegewezen aan het IP-adres van de VMware Identity Manager-load-balancer.
Hetzelfde model is ook op vRealize Automation van toepassing. Wanneer vRealize Automation is gekoppeld aan een tenant, moet toegang tot de vRealize Automation-tenant worden gekregen via de vRealize Automation-tenant-FQDN's. Bijvoorbeeld: VMware Identity Manager met FQDN idm1.vmwlab.local die een tenant 'tenant1' heeft die toegankelijk is via tenant1.vmwlab.local en vRealize Automation 8.1 vra1.vmwlab.local geïntegreerd met deze VMware Identity Manager en gekoppeld aan 'tenant1'. Zoals aangegeven worden de vRealize Automation-tenant en VMware Identity Manager-tenant 1:1 toegewezen, zodat de primaire vRealize Automation-tenant nog steeds toegankelijk is via vra1.vmwlab.local en vRealize Automation 'tenant 1' toegankelijk is via tenant1.vra1.vmwlab.local.
Net zoals bij VMware Identity Manager vereisen ook vRealize Automation-tenant-FQDN's DNS-toewijzing. Maar voor een vRealize Automation moet dit een record van het CNAME-type zijn die de vRealize Automation-tenant-FQDN's aan de FQDN van de vRealize Automation-server toewijst. Voor een geclusterde vRealize Automation-implementatie moeten alle vRealize Automation-tenants-FQDN's een DNS-record van het CNAME-type hebben die verwijst naar de FQDN van de vRealize Automation-load-balancer.
Afgezien van de vereiste om DNS-toewijzingen te hebben, zijn certificaten ook verplicht voor de werking van de tenancy. Zowel VMware Identity Manager- als vRealize Automation-servers en de load balancers die afhankelijk zijn van de implementatie-architectuur, moeten in hun bijbehorende certificaten alle vereiste tenant-FQDN's hebben.
- VMware Identity Manager-knooppunt: idm1.vmwlab.local
vRealize Automation-knooppunt: vra1.vmwlab.local
Aliasnaam van primaire tenant: master-tenant
Tenants: tenant-1, tenant-2
| Tenantnamen | VMware Identity Manager-tenant-FQDN's | vRealize Automation-tenant-FQDN's |
|---|---|---|
| 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-load-balancer: idm-lb.vmwlab.local
VMware Identity Manager-knooppunten: idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local
vRealize Automation-load-balancer: vra-lb.vmwlab.local
vRealize Automation-knooppunten: vra1.vmwlab.local, vra2.vmwlab.local, vra3.vmwlab.local
Aliasnaam van primaire tenant: master-tenant
Tenants: tenant-1, tenant-2
| Tenantnamen | VMware Identity Manager-tenant-FQDN's | vRealize Automation-tenant-FQDN's |
|---|---|---|
| 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 |
Vereisten voor verplichte certificaten
- Wanneer u de certificaten in VMware Identity Manager wijzigt om multitenancy in te schakelen of tenants te maken, wordt de service hierdoor afgesloten, wat zorgt voor uitvaltijd. Als een VMware Identity Manager-certificaat wordt gewijzigd, veroorzaakt dit een uitvaltijd van de service. De producten of services die zijn geïntegreerd met VMware Identity Manager voor verificatiedoeleinden, kunnen tijdens de uitvaltijd geen gebruikmaken van aanmelding via VMware Identity Manager-verificatie. Als u het VMware Identity Manager-certificaat wijzigt, moet u het in alle producten of services opnieuw vertrouwen, wat opnieuw uitvaltijd veroorzaakt.
- Voor elke nieuwe tenant die wordt gemaakt en gekoppeld aan vRealize Automation, moeten ook vRealize Automation-certificaten worden gewijzigd, wat uitvaltijd van de service voor vRealize Automation veroorzaakt.
- Om uitvaltijd van de service te vermijden in vRealize Automation, VMware Identity Manager en andere producten of services die zijn geïntegreerd met VMware Identity Manager, wordt het over het algemeen aanbevolen om certificaten met jokertekens te gebruiken. Voor een nieuwe tenant kan elke wijziging in het VMware Identity Manager-certificaat of het vRealize Automation-certificaat uitvaltijd in vRealize Automation veroorzaken.
- Als er geen certificaten met jokertekens worden gebruikt, moeten voor elke tenant-FQDN specifieke SAN-vermeldingen worden gemaakt in alle vereiste certificaten.
- De vRealize Suite Lifecycle Manager Locker-service helpt bij het beheren van certificaten op de knooppunten van de VMware Identity Manager- en vRealize Automation-server. Wanneer u voor vRealize Suite Lifecycle Manager een VMware Identity Manager-certificaat vervangt, wordt het VMware Identity Manager-certificaat op alle producten automatisch opnieuw vertrouwd.
- Producten of services die extern zijn voor vRealize Suite Lifecycle Manager worden handmatig afgehandeld. Locker-service verwerkt het bijwerken van load-balancercertificaten niet. Dit moet handmatig door de gebruiker worden gedaan. Wanneer load-balancercertificaten worden gewijzigd, moesten deze opnieuw worden vertrouwd in de producten.
- Voor VMware Identity Manager wordt de update- of vervangingsbewerking voor het VMware Identity Manager-certificaat in vRealize Suite Lifecycle Manager intern uitgevoerd om ervoor te zorgen dat het certificaat van de VMware Identity Manager-load-balancer opnieuw wordt vertrouwd voordat de certificaten van de VMware Identity Manager-server worden bijgewerkt. U wordt daarom aanbevolen het certificaat van de VMware Identity Manager-load-balancer handmatig te wijzigen en vervolgens een update- of vervangingsbewerking van het VMware Identity Manager-certificaat uit te voeren via een vRealize Suite Lifecycle Manager Locker-service.
- Als voor een vRealize Automation 8.x SSL bij de vRealize Automation-load-balancer wordt beëindigd en het load-balancercertificaat handmatig wordt gewijzigd, klikt u op 'Load balancer opnieuw vertrouwen' onder de productkaart van vRealize Automation 8.x om het certificaat van de load balancer opnieuw te vertrouwen in vRealize Automation. Raadpleeg Dag 2-bewerkingen met andere producten in vRealize Suite Lifecycle Manager voor meer informatie.
Verplichte DNS-vereisten
Voor een VMware Identity Manager met één knooppunt heeft u DNS-records van het type A nodig die de tenant-FQDN's markeren voor het IP-adres van de VMware Identity Manager-server. En voor een geclusterde VMware Identity Manager zijn DNS-records van het A-type vereist, die de tenant-FQDN's verwijzen naar het IP-adres van de VMware Identity Manager-load-balancer.
Voor vRealize Automation zijn voor één knooppunt DNS-records van het CNAME-type vereist die vRealize Automation-tenant-FQDN's verwijzen naar de vRealize Automation-server-FQDN. En voor een geclusterde vRealize Automation verwijzen DNS-records van het CNAME-type vRealize Automation-tenant-FQDN's naar de FQDN van de vRealize Automation-load-balancer.
Vereisten voor multitenancy
 |
|
|
|
