En esta sección se describe el modelo de varios tenants, y se explica cómo acceder a los tenants a través de FQDN de tenant y la importancia de habilitar varios tenants junto con el certificado y los requisitos de DNS.

Habilitar varios tenants

El principal maestro ahora se conoce como tenant principal. A pesar de que el día 0, la instancia de VMware Identity Manager inmediata incluye un tenant principal que ya está disponible, esta configuración se mantiene al mínimo y no es posible crear más tenants por debajo del tenant principal. Se debe realizar una secuencia de configuraciones y llamadas a la API en VMware Identity Manager para habilitar varios tenants. Se debe haber creado un nombre de alias para el tenant principal al habilitar varios tenants. Para obtener más información sobre cómo habilitar varios tenants, consulte Habilitar varios tenants.

Por ejemplo, un VMware Identity Manager con el FQDN 'idm1.vmwlab.local' ya puede tener un tenant principal con el nombre 'idm1'. Antes de habilitar la estructura de varios tenants, es obligatorio crear un alias para el tenant principal. Por ejemplo, establezca "master-tenant" y utilice el mismo nombre de alias en cualquier lugar en que se haga referencia al tenant principal.

FQDN de tenant

De forma predeterminada, el acceso a los tenants creados en VMware Identity Manager es a través de las URL de tenant, que no son más que FQDN asignados al servidor de VMware Identity Manager. Cada tenant tiene su propio FQDN de tenant. Por ejemplo, en VMware Identity Manager de nodo único con el nombre de host idm1.vmwlab.local, el nombre de tenant principal (idm1) y el alias de tenant principal (master-tenant), se debe acceder al tenant principal a través de su FQDN master-tenant.vmwlab.local. Si se crea un nuevo tenant (tenant1), solo se debe acceder a él a través de tenant1.vmwlab.local.

Dado que cada tenant requiere un FQDN dedicado, la creación de tenants en VMware Identity Manager requiere de forma obligatoria un registro DNS de tipo A que asigna el FQDN del tenant a la dirección IP del servidor de VMware Identity Manager. Para una implementación de VMware Identity Manager en clúster, cada FQDN de tenant debe tener una asignación de registro de tipo A para la dirección IP del equilibrador de carga de VMware Identity Manager.

También se aplica el mismo modelo a vRealize Automation. Cuando vRealize Automation está asociado a un tenant, se debe acceder al tenant de vRealize Automation a través de los FQDN de tenant de vRealize Automation. Por ejemplo, VMware Identity Manager con el FQDN idm1.vmwlab.local que tiene un tenant 'tenant1’ accesible a través de tenant1.vmwlab.local, y vra1.vmwlab.local de vRealize Automation 8.1 integrado con este VMware Identity Manager y asociado con 'tenant1'. Como se mencionó anteriormente, el tenant de vRealize Automation y el de VMware Identity Manager se asignan 1 a 1, por lo que aún puede acceder al tenant principal de vRealize Automation a través de vra1.vmwlab.local y se debe acceder a 'tenant 1' de vRealize Automation a través de tenant1.vra1.vmwlab.local.

Nota: Existe una diferencia entre los FQDN de tenant de VMware Identity Manager y de vRealize Automation. Para una instancia de VMware Identity Manager, el formato de FQDN de tenant es el nombre del tenant (tenant1) seguido del nombre del dominio de VMware Identity Manager (vmwlab.local). Por ejemplo, tenant1.vmwlab.local. Dado que es el nombre del tenant seguido por el dominio, sigue siendo igual incluso para VMware Identity Manager en clúster. Para vRealize Automation, el formato de FQDN de tenant de vRealize Automation es el nombre del tenant (tenant1) seguido del FQDN del servidor de vRealize Automation (vra1.vmwlab.local). Por ejemplo, tenant1.vra1.vmwlab.local. Para vRealize Automation en clúster detrás de un equilibrador de carga vra-lb.vmwlab.local, se debe acceder a tenant 1 a través de tenant1.vra-lb.vmwlab.local.

De forma similar que en VMware Identity Manager, incluso los FQDN de tenant de vRealize Automation requieren una asignación de DNS. Sin embargo, para vRealize Automation debe ser un registro de tipo CNAME que asigna los FQDN de tenant de vRealize Automation al servidor de vRealize Automation. Para una implementación de vRealize Automation en clúster, todos los FQDN de tenant de vRealize Automation deben tener un registro DNS de tipo CNAME que apunte al FQDN del equilibrador de carga de vRealize Automation.

Además de tener asignaciones de DNS como requisito previo obligatorio, los certificados también son obligatorios para que funcionen los tenants. Los servidores de VMware Identity Manager y de vRealize Automation, así como sus equilibradores de carga, según la arquitectura de implementación, deben tener sus correspondientes certificados que contengan todos los FQDN de tenant necesarios.

FQDN de tenant en una configuración de nodo único
  • Nodo de VMware Identity Manager: idm1.vmwlab.local

    Nodo de vRealize Automation: vra1.vmwlab.local

    Nombre de alias de tenant principal: master-tenant

    Tenants: tenant-1, tenant-2

Nombres de tenant FQDN de tenant de VMware Identity Manager FQDN de tenant de 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
FQDN de tenant en una configuración en clúster
  • Equilibrador de carga de VMware Identity Manager: idm-lb.vmwlab.local

    Nodos de VMware Identity Manager: idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local

    Equilibrador de carga de vRealize Automation: vra-lb.vmwlab.local

    Nodos de vRealize Automation: vra1.vmwlab.local, vra2.vmwlab.local, vra3.vmwlab.local

    Nombre de alias del tenant principal: master-tenant

    Tenants: tenant-1, tenant-2

Nombres de tenant FQDN de tenant de VMware Identity Manager FQDN de tenant de 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
Nota: Después de habilitar varios tenants, solo se debe acceder a VMware Identity Manager a través de sus FQDN de tenant. Los FQDN y los nombres de host antiguos (idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local e idm-lb.vmwlab.local) no son válidos.

Requisitos de certificados obligatorios

Según el tipo de implementación de VMware Identity Manager y vRealize Automation, los certificados de servidor correspondientes deben tener todos los FQDN de tenant en ellos. Dado que cada tenant forma su propio FQDN de tenant (tanto el FQDN de tenant de VMware Identity Manager como el FQDN de tenant de vRealize Automation), cada tenant creado requiere que su FQDN de tenant se agregue como parte de los certificados de VMware Identity Manager y vRealize Automation. Para habilitar varios tenants en VMware Identity Manager también es necesario actualizar los certificados de VMware Identity Manager, ya que el tenant principal obtiene un nuevo nombre de alias y se cambia el FQDN del tenant principal.
Nota:
  • Cuando se cambian los certificados en VMware Identity Manager para habilitar varios tenants o crear tenants, el servicio se vuelve inactivo por un tiempo. Si se cambia el certificado de VMware Identity Manager, se produce un periodo de inactividad del servicio. Los productos o los servicios integrados con VMware Identity Manager no pueden autenticarse a través del inicio de sesión de autenticación de VMware Identity Managerdurante el tiempo de inactividad. Además, para cambiar el certificado de VMware Identity Manager, es necesario volver a confiar en todos los productos o servicios, lo que de nuevo provocará un tiempo de inactividad de los productos.
  • Por cada tenant nuevo que se cree y se asocie con vRealize Automation, se deben cambiar incluso los certificados de vRealize Automation, lo que provoca un tiempo de inactividad del servicio para vRealize Automation.
  • Para evitar tiempos de inactividad del servicio en vRealize Automation, VMware Identity Manager y otros productos o servicios integrados con VMware Identity Manager, por lo general, se recomienda tener certificados comodín. Para un nuevo tenant, cualquier cambio realizado en el certificado de VMware Identity Manager o de vRealize Automation, puede crear un tiempo de inactividad en vRealize Automation.
  • Si no se utilizan certificados comodín, se deben crear entradas de SAN específicas para cada FQDN de tenant en todos los certificados requeridos.
  • El servicio de almacén de vRealize Suite Lifecycle Manager ayuda a administrar certificados en los nodos de servidor de VMware Identity Manager y vRealize Automation. Con vRealize Suite Lifecycle Manager, al reemplazar el certificado de VMware Identity Manager, se vuelve a confiar automáticamente en el certificado de VMware Identity Manager en todos los productos.
  • Los productos o servicios externos a vRealize Suite Lifecycle Manager se gestionan manualmente. El servicio de almacén no controla la actualización de los certificados del equilibrador de carga. El usuario la debe realizar manualmente. Cada vez que se cambian los certificados del equilibrador de carga, es necesario volver a confiar en ellos en los productos.
    • Para VMware Identity Manager, la operación de actualización o reemplazo del certificado de VMware Identity Manager en vRealize Suite Lifecycle Manager se asegura internamente de que se vuelva a confiar en el certificado del equilibrador de carga de VMware Identity Manager antes de actualizar los certificados del servidor de VMware Identity Manager. Por lo tanto, se recomienda cambiar primero el certificado del equilibrador de carga de VMware Identity Manager manualmente y, a continuación, realizar un certificado de VMware Identity Manager para actualizarlo o reemplazarlo a través del servicio de almacén de vRealize Suite Lifecycle Manager.
    • Para vRealize Automation 8.x, cuando SSL se cancela en el equilibrador de carga de vRealize Automation, y el certificado del equilibrador de carga cambia manualmente, asegúrese de hacer clic en "Volver a confiar en el equilibrador de carga" en la tarjeta del producto vRealize Automation 8.x para volver a confiar en el certificado del equilibrador de carga en vRealize Automation. Para obtener más detalles, consulte Operaciones del día 2 con otros productos en vRealize Suite Lifecycle Manager.

Requisitos de DNS obligatorios

Para VMware Identity Manager de nodo único, se requieren registros de DNS de tipo A que apunten los FQDN del tenant a la dirección IP del servidor de VMware Identity Manager; y para VMware Identity Manager en clúster, se requieren registros de DNS de tipo A que apunten los FQDN de tenant a la dirección IP del equilibrador de carga de VMware Identity Manager.

Para vRealize Automation de nodo único, se requieren registros DNS de tipo CNAME que apunten los FQDN de tenant de vRealize Automation al FQDN del servidor de vRealize Automation; y para vRealize Automation en clúster, se requieren registros DNS de tipo CNAME que apunten los FQDN de tenant de vRealize Automation al FQDN del equilibrador de carga de vRealize Automation.

Requisitos para varios tenants

Figura 1. VMware Identity Manager y vRealize Automation de nodo único
Figura 2. Clúster de VMware Identity Manager y de vRealize Automation
Figura 3. vIDM único y vRA en clúster
Figura 4. Clúster de VMware Identity Manager y vRealize Automation único