Esta seção descreve o modelo de multilocação, explicando como os tenants podem ser acessados por meio de FQDNs de tenant e a importância de habilitar a multilocação junto com o certificado e os requisitos de DNS.
Ativando a multilocação
O tenant principal agora é chamado de tenant primário. Mesmo que no dia 0 o VMware Identity Manager pronto para uso inclua um tenant primário já disponível, ele é mantido com uma configuração mínima, e a criação adicional de tenants abaixo do tenant primário não é possível. Uma sequência de configurações e chamadas de API deve ser executada no VMware Identity Manager para habilitar a multilocação. Deve haver um nome de alias criado para o tenant primário quando você ativa a multilocação. Para obter mais informações sobre como ativar a multilocação, consulte Ativar o recurso multiempresa.
Por exemplo, um VMware Identity Manager com FQDN “idm1.vmwlab.local” já pode ter um tenant primário com o nome “idm1”. Antes de ativar a multilocação, é obrigatório criar um alias para o tenant primário. Por exemplo, defina “master-tenant” e use o mesmo nome de alias em todos os lugares onde o tenant principal é referenciado.
FQDNs de tenants
Por padrão, os tenants criados no VMware Identity Manager são acessados por meio de URLs de tenant que não passam de FQDNs mapeados para o servidor VMware Identity Manager. Todos os tenants têm seu próprio FQDN de tenant. Por exemplo, em um VMware Identity Manager de nó único com o nome de host idm1.vmwlab.local, o nome de tenant primário (idm1) e o alias de tenant primário (master-tenant), o tenant primário deve ser acessado por meio de seu FQDN master-tenant.vmwlab.local. Se um novo tenant (tenant 1) for criado, ele deverá ser acessado somente por meio de tenant1.vmwlab.local.
Como cada tenant requer um FQDN dedicado, a criação de tenants no VMware Identity Manager requer obrigatoriamente um registro de DNS do tipo A mapeando o FQDN do tenant para o endereço IP do servidor do VMware Identity Manager. Para uma implantação do VMware Identity Manager em cluster, cada FQDN de tenant deve ter um mapeamento de registro do tipo A para o endereço IP do balanceador de carga do VMware Identity Manager.
O mesmo modelo também se aplica ao vRealize Automation. Quando o vRealize Automation está associado a um tenant, o tenant do vRealize Automation deve ser acessado por FQDNs de tenant do vRealize Automation. Por exemplo, o VMware Identity Manager com o FQDN idm1.vmwlab.local e um tenant “tenant 1” acessível via tenant1.vmwlab.local e o vRealize Automation 8.1 vra1.vmwlab.local integrado a esse VMware Identity Manager e associado a “tenant 1”. Como mencionado, o tenant do vRealize Automation e o tenant do VMware Identity Manager têm um mapeamento de 1:1, de modo que o vRealize Automation do tenant primário ainda possa ser acessado por vra1.vmwlab.local e o vRealize Automation “tenant 1”deve ser acessado por tenant1.vra1.vmwlab.local.
Igual ao VMware Identity Manager, até mesmo os FQDNs de tenant do vRealize Automation exigem mapeamento de DNS. Porém, para um vRealize Automation, ele deve ser o registro do tipo CNAME mapeando os FQDNs de tenants do vRealize Automation para o FQDN do servidor do vRealize Automation. Para uma implantação do vRealize Automation em cluster, todos os FQDNs de tenants do vRealize Automation devem ter um registro de DNS do tipo CNAME apontando para o FQDN do balanceador de carga do vRealize Automation.
Além de ter mapeamentos de DNS como pré-requisito obrigatório, certificados também são obrigatórios para que a locação funcione. Ambos os servidores VMware Identity Manager e vRealize Automation e seus balanceadores de carga, dependendo da arquitetura de implantação, devem ter seus certificados correspondentes contendo todos os FQDNs de tenants necessários.
- Nó do VMware Identity Manager: idm1.vmwlab.local
Nó do vRealize Automation: vra1.vmwlab.local
Nome do alias do tenant primário: master-tenant
Tenants: tenant-1, tenant-2
| Nomes dos tenants | FQDNs de tenants do VMware Identity Manager | FQDNs de tenants do 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 |
- Balanceador de carga do VMware Identity Manager: idm-lb.vmwlab.local
Nós do VMware Identity Manager: idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local
Balanceador de carga do vRealize Automation: vra-lb.vmwlab.local
Nós do vRealize Automation: vra1.vmwlab.local, vra2.vmwlab.local, vra3.vmwlab.local
Nome do alias do tenant primário: master-tenant
Tenants: tenant-1, tenant-2
| Nomes dos tenants | FQDNs de tenants do VMware Identity Manager | FQDNs de tenants do 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 |
Requisitos de certificados obrigatórios
- Quando você altera os certificados no VMware Identity Manager para ativar a multilocação ou cria tenants, isso desativa o serviço e resulta em tempo de inatividade. Se o certificado do VMware Identity Manager for alterado, isso resultará em um tempo de inatividade do serviço. Os produtos ou serviços integrados com o VMware Identity Manager para fins de autenticação não podem usar o login de autenticação do VMware Identity Manager durante o tempo de inatividade. Além disso, a alteração do certificado do VMware Identity Manager requer nova confiança em todos os produtos ou serviços, o que novamente resulta em tempo de inatividade para os produtos.
- Para cada novo tenant criado e associado ao vRealize Automation, até mesmo os certificados do vRealize Automation devem ser alterados, e isso resulta em tempo de inatividade de serviço para o vRealize Automation.
- Para evitar tempos de inatividade de serviço no vRealize Automation, no VMware Identity Manager e em outros produtos ou serviços integrados com o VMware Identity Manager, geralmente é recomendável ter certificados curinga. Para um novo tenant, qualquer alteração feita no certificado do VMware Identity Manager ou do vRealize Automation pode criar um tempo de inatividade no vRealize Automation.
- Se certificados curinga não forem usados, entradas específicas de SAN deverão ser criadas para cada FQDN de tenant em todos os certificados necessários.
- O serviço Locker do vRealize Suite Lifecycle Manager ajuda no gerenciamento de certificados nos nós de servidor do VMware Identity Manager e do vRealize Automation. Com o vRealize Suite Lifecycle Manager, quando você substitui o certificado do VMware Identity Manager, a redefinição da confiança do certificado do VMware Identity Manager em todos os produtos é realizada automaticamente.
- Produtos ou serviços externos ao vRealize Suite Lifecycle Manager são tratados manualmente. O serviço Locker não lida com a atualização de certificados de balanceadores de carga. Isso deve ser feito manualmente pelo usuário. Sempre que os certificados de balanceadores de carga forem alterados, sua confiança deverá ser redefinida nos produtos.
- Para o VMware Identity Manager, a operação de atualização ou substituição de certificado do VMware Identity Manager no vRealize Suite Lifecycle Manager garante internamente que o certificado do balanceador de carga do VMware Identity Manager tenha a confiança redefinida antes da atualização dos certificados de servidor do VMware Identity Manager. Portanto, é recomendável primeiro alterar o certificado do balanceador de carga do VMware Identity Manager manualmente e, em seguida, fazer uma operação de atualização ou substituição do certificado do VMware Identity Manager por meio do serviço Locker do vRealize Suite Lifecycle Manager.
- Para o vRealize Automation 8.x, quando SSL é encerrado no balanceador de carga do vRealize Automation e o certificado do balanceador de carga é alterado manualmente, certifique-se de clicar em “Confiar novamente no balanceador de carga” no cartão do produto vRealize Automation 8.x para confiar novamente no certificado do balanceador de carga no vRealize Automation. Para obter mais detalhes, consulte Operações do Dia 2 com outros produtos no vRealize Suite Lifecycle Manager.
Requisitos obrigatórios de DNS
Para o VMware Identity Manager de um único nó, você precisa de registros de DNS do tipo A realçando os FQDNs de tenant para o endereço IP do servidor do VMware Identity Manager. E, para um VMware Identity Manager em cluster, são necessários registros de DNS do tipo A que apontem os FQDNs de tenants para o endereço IP do balanceador de carga do VMware Identity Manager.
Para o vRealize Automation, para um único nó, são necessários registros de DNS do tipo CNAME que apontem FQDNs de tenants do vRealize Automation para o FQDN do servidor do vRealize Automation. E, para um vRealize Automation em cluster, são necessários registros de DNS do tipo CNAME que apontem FQDNs de tenants do vRealize Automation para o FQDN do balanceador de carga do vRealize Automation.
Requisitos para multilocação
 |
|
|
|
