In diesem Abschnitt wird das Modell zur Mehrmandantenfähigkeit beschrieben. Es wird erläutert, wie auf Mandanten über Mandanten-FQDNs zugegriffen werden kann und wie wichtig es ist, die Mehrmandantenfähigkeit zusammen mit dem Zertifikat und den DNS-Anforderungen zu aktivieren.
Aktivieren der Mehrmandantenfähigkeit
Der Master-Mandant wird jetzt als primärer Mandant bezeichnet. Obwohl der einsatzbereite VMware Identity Manager an Tag 0 bereits einen verfügbaren primären Mandanten enthält, bleibt dieser minimal konfiguriert, und eine weitere Erstellung von Mandanten unterhalb des primären Mandanten ist nicht möglich. Bei VMware Identity Manager muss zur Aktivierung der Mehrmandantenfähigkeit eine Abfolge von Konfigurationen und API-Aufrufen durchgeführt werden. Für den primären Mandanten muss ein Aliasname erstellt sein, wenn Sie die Mehrmandantenfähigkeit aktivieren. Weitere Informationen zur Aktivierung der Mehrmandantenfähigkeit finden Sie unter Aktivieren der Mehrmandantenfähigkeit.
Beispielsweise kann ein VMware Identity Manager mit dem FQDN „idm1.vmwlab.local“ bereits einen primären Mandanten namens „idm1“ haben. Vor der Aktivierung der Mehrmandantenfähigkeit ist es erforderlich, einen Alias für den primären Mandanten zu erstellen. Legen Sie beispielsweise „master-tenant“ fest und verwenden Sie denselben Aliasnamen überall dort, wo auf den primären Mandanten verwiesen wird.
Mandanten-FQDNs
Standardmäßig wird auf Mandanten, die in VMware Identity Manager erstellt wurden, über Mandanten-URLs zugegriffen, bei denen es sich eigentlich nur um FQDNs handelt, die dem VMware Identity Manager-Server zugeordnet sind. Jeder Mandant verfügt über einen eigenen Mandanten-FQDN. Beispielsweise sollte auf VMware Identity Manager mit einem Einzelknoten und Hostnamen idm1.vmwlab.local, mit dem Namen des primären Mandanten (idm1) und dem primären Mandantenalias (master-tenant) über den FQDN-Namen master-tenant.vmwlab.local auf den primären Mandanten zugegriffen werden. Wenn ein neuer Mandant (tenant1) erstellt wird, darf auf ihn nur über tenant1.vmwlab.local zugegriffen werden.
Da jeder Mandant einen dedizierten FQDN benötigt, erfordert das Erstellen von Mandanten im VMware Identity Manager verpflichtend einen DNS-Datensatz vom Typ „A“, der den Mandanten-FQDN der IP-Adresse des VMware Identity Manager-Servers zuordnet. Für eine geclusterte VMware Identity Manager-Bereitstellung muss jeder Mandanten-FQDN über einen Datensatz vom Typ „A“ verfügen, der auf die IP-Adresse des Lastausgleichsdiensts für VMware Identity Manager verweist.
Dasselbe Modell gilt auch für vRealize Automation. Wenn vRealize Automation einem Mandanten zugeordnet ist, muss ein Zugriff auf den vRealize Automation-Mandanten durch Mandanten-FQDNs von vRealize Automation erfolgen. Beispiel: VMware Identity Manager mit FQDN idm1.vmwlab.local, der über einen Mandanten „tenant1“ verfügt, auf den über tenant1.vmwlab.local zugegriffen werden kann, und in den vRealize Automation 8.1 vra1.vmwlab.local in diesen VMware Identity Manager integriert und mit „tenant1“ verknüpft ist. Wie bereits erwähnt, wird der Mandant von vRealize Automation 1:1 auf den Mandanten von VMware Identity Manager abgebildet, sodass auf den primären Mandanten vRealize Automation weiterhin über vra1.vmwlab.local zugegriffen werden kann und auf vRealize Automation „tenant 1“ über tenant1.vra1.vmwlab.local zugegriffen werden muss.
Analog zu VMware Identity Manager erfordern auch Mandanten-FQDNs von vRealize Automation eine DNS-Zuordnung. Für vRealize Automation sollte es sich jedoch um einen Datensatz vom Typ CNAME handeln, der die Mandanten-FQDNs von vRealize Automation dem FQDN des vRealize Automation-Servers zuordnet. Für eine geclusterte vRealize Automation-Bereitstellung müssen alle Mandanten-FQDNs von vRealize Automation einen DNS-Datensatz vom Typ CNAME haben, der auf den FQDN des Lastausgleichsdiensts von vRealize Automation verweist.
Abgesehen davon, dass DNS-Zuordnungen obligatorisch sind, gilt dies auch für Zertifikate, damit die Mandantenfähigkeit funktioniert. Sowohl VMware Identity Manager- als auch vRealize Automation-Server sowie deren Lastausgleichsdienste, die von der Bereitstellungsarchitektur abhängen, sollten entsprechende Zertifikate haben, die mit allen erforderlichen Mandanten-FQDNs versehen sind.
- VMware Identity Manager-Knoten: idm1.vmwlab.local
vRealize Automation-Knoten: vra1.vmwlab.local
Aliasname des primären Mandanten: master-tenant
Mandanten: tenant-1, tenant-2
| Mandantennamen | Mandanten-FQDNs von VMware Identity Manager | Mandanten-FQDNs von 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 |
- Lastausgleichsdienst von VMware Identity Manager: idm-lb.vmwlab.local
VMware Identity Manager-Knoten: idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local
Lastausgleichsdienst von vRealize Automation: vra-lb.vmwlab.local
vRealize Automation-Knoten: vra1.vmwlab.local, vra2.vmwlab.local, vra3.vmwlab.local
Aliasname des primären Mandanten: master-tenant
Mandanten: tenant-1, tenant-2
| Mandantennamen | Mandanten-FQDNs von VMware Identity Manager | Mandanten-FQDNs von 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 |
Obligatorische Anforderungen an Zertifikate
- Wenn Sie die Zertifikate für VMware Identity Manager ändern, um Mandantenfähigkeit zu aktivieren oder Mandanten zu erstellen, wird der Dienst heruntergefahren und es kommt zu einem Ausfall. Wenn ein VMware Identity Manager-Zertifikat geändert wird, kommt es zu einem Dienstausfall. Die Produkte oder Dienste, die zu Authentifizierungszwecken in VMware Identity Manager integriert sind, können während des Ausfalls die Authentifizierungsanmeldung von VMware Identity Manager nicht nutzen. Darüber hinaus erfordert die Änderung des VMware Identity Manager-Zertifikats eine erneute Vertrauensstellung auf alle Produkte oder Dienste, was wiederum zu Ausfällen für die Produkte führt.
- Für jeden neuen Mandanten, der erstellt und mit vRealize Automation verknüpft ist, müssen selbst vRealize Automation-Zertifikate geändert werden. Dies führt zu Dienstausfällen für vRealize Automation.
- Um Dienstausfälle für vRealize Automation, VMware Identity Manager und andere Produkte oder Dienste zu vermeiden, die in VMware Identity Manager integriert sind, wird in der Regel empfohlen, Platzhalterzertifikate bereitzuhalten. Bei einem neuen Mandanten kann jede Änderung am VMware Identity Manager- oder vRealize Automation-Zertifikat zu Ausfällen bei vRealize Automation führen.
- Wenn keine Platzhalterzertifikate verwendet werden, müssen für jeden Mandanten-FQDN spezifische SAN-Einträge für alle erforderlichen Zertifikate erstellt werden.
- Der vRealize Suite Lifecycle Manager-Locker-Dienst hilft bei der Verwaltung von Zertifikaten auf den VMware Identity Manager- und vRealize Automation-Serverknoten. Wenn Sie bei vRealize Suite Lifecycle Manager das VMware Identity Manager-Zertifikat ersetzen, wird die erneute Vertrauensstellung des VMware Identity Manager-Zertifikats für alle Produkte automatisch durchgeführt.
- Produkte oder Dienste außerhalb von vRealize Suite Lifecycle Manager werden manuell verarbeitet. Der Locker-Dienst verarbeitet nicht das Aktualisieren von Zertifikaten des Lastausgleichsdiensts. Sie müssen vom Benutzer manuell durchgeführt werden. Immer dann, wenn Zertifikate des Lastausgleichsdiensts geändert werden, mussten die Vertrauensstellung der Zertifikate für die Produkte erneut hergestellt werden.
- Für VMware Identity Manager stellt der Zertifikataktualisierungs- oder -austauschvorgang von VMware Identity Manager in vRealize Suite Lifecycle Manager intern sicher, dass das Lastausgleichsdienstzertifikat von VMware Identity Manager erneut als vertrauenswürdig eingestuft wird, bevor die Zertifikate des VMware Identity Manager-Servers aktualisiert werden. Daher wird empfohlen, zuerst das Lastausgleichsdienstzertifikat für VMware Identity Manager manuell zu ändern und dann ein VMware Identity Manager-Zertifikat zu erstellen, das über den vRealize Suite Lifecycle Manager-Locker-Dienst aktualisiert oder ersetzt werden soll.
- Wenn im Fall von vRealize Automation 8.x SSL am Lastausgleichsdienst von vRealize Automation endet und das Lastausgleichsdienstzertifikat manuell geändert wird, stellen Sie sicher, dass Sie auf der vRealize Automation 8.x-Produktkarte auf „Lastausgleichsdienst erneut vertrauen“ klicken, um dem Lastausgleichsdienstzertifikat in vRealize Automation erneut zu vertrauen. Weitere Informationen finden Sie unter Tag-2-Vorgänge bei anderen Produkten in vRealize Suite Lifecycle Manager.
Obligatorische DNS-Anforderungen
Für VMware Identity Manager mit einem Einzelknoten benötigen Sie DNS-Datensätze vom Typ „A“, die die Mandanten-FQDNs für die IP-Adresse des VMware Identity Manager-Servers hervorheben. Für einen geclusterten VMware Identity Manager sind DNS-Datensätze vom Typ „A“ erforderlich, die die Mandanten-FQDNs auf die IP-Adresse des Lastausgleichsdiensts von VMware Identity Manager verweisen.
Für vRealize Automation sind für einen einzelnen Knoten DNS-Datensätze vom Typ CNAME erforderlich, die Mandanten-FQDNs von vRealize Automation auf den FQDN des vRealize Automation-Servers verweisen. Und für clusterbasierte vRealize Automation DNS-Datensätze vom Typ CNAME, die Mandanten-FQDNs von vRealize Automation auf den FQDN des Lastausgleichsdiensts von vRealize Automation verweisen.
Anforderungen für Mehrmandantenfähigkeit
 |
|
|
|
