Модель с множественной арендой

В этом разделе описывается модель с множественной арендой (мультитенантность), объясняется, как можно получить доступ к арендаторам с помощью полного доменного имени (FQDN) арендаторов, почему важно включить множественную аренду вместе с сертификатом и каковы требования к службе доменных имен (DNS).

Включение функции множественной аренды

Главный арендатор теперь называется основным арендатором. Хотя готовый к использованию компонент VMware Identity Manager содержит основной арендатор уже на стадии развертывания, он представлен в минимальной конфигурации, и последующее создание арендаторов более низкого уровня невозможно. Чтобы включить функцию множественной аренды, в VMware Identity Manager необходимо выполнить ряд настроек и вызовов API-интерфейса. При включении функции множественной аренды необходимо создать псевдоним основного арендатора. Дополнительные сведения о включении функции множественной аренды см. в разделе Включение функции множественной аренды.

Например, VMware Identity Manager с FQDN «idm1.vmwlab.local» может уже иметь основного арендатора с именем «idm1». Перед включением функции множественной аренды необходимо создать псевдоним основного арендатора. Например, в качестве псевдонима можно указать «master-tenant», а затем всегда использовать это имя для ссылки на основного арендатора.

Полные доменные имена арендаторов

По умолчанию для доступа к арендаторам, созданным в VMware Identity Manager, используются URL-адреса арендаторов, которые представляют собой не что иное, как полные доменные имена (FQDN), сопоставленные с сервером VMware Identity Manager. У каждого арендатора есть собственное полное доменное имя (FQDN). Например, если для VMware Identity Manager с одним узлом указано имя узла idm1.vmwlab.local, имя основного арендатора (idm1) и псевдоним основного арендатора (master-tenant), то доступ к основному арендатору должен осуществляться с помощью его FQDN — master-tenant.vmwlab.local. При создании нового арендатора (tenant1) доступ к нему должен осуществляться только с помощью tenant1.vmwlab.local.

Поскольку для каждого арендатора требуется отдельное полное доменное имя, чтобы создать арендатора в VMware Identity Manager, необходимо наличие DNS-записи типа А, сопоставляющей полное доменное имя арендатора с IP-адресом сервера VMware Identity Manager. При кластерном развертывании VMware Identity Manager необходимо, чтобы у каждого FQDN арендатора имелась запись типа A для сопоставления с IP- адресом подсистемы балансировки нагрузки VMware Identity Manager.

Та же модель применяется и к vRealize Automation. Если компонент vRealize Automation связан с арендатором, то для доступа к арендатору vRealize Automation необходимо использовать FQDN арендатора vRealize Automation. Например, VMware Identity Manager с FQDN idm1.vmwlab.local может иметь арендатора tenant1, доступного с помощью полного доменного имени tenant1.vmwlab.local и, для vRealize Automation 8.1, с помощью vra1.vmwlab.local, интегрированного в VMware Identity Manager и связанного с tenant1. Как отмечалось выше, сопоставление арендатора vRealize Automation и арендатора VMware Identity Manager осуществляется по принципу 1 : 1, поэтому доступ к основному арендатору vRealize Automation по-прежнему можно получить с помощью vra1.vmwlab.local, а доступ к tenant1 vRealize Automation — с помощью tenant1.vra1.vmwlab.local.

Примечание: Существует разница между полным доменным именем арендаторов VMware Identity Manager и vRealize Automation. Для экземпляров VMware Identity Manager форматом полного доменного имени арендатора является имя арендатора (tenant1), за которым следует имя домена VMware Identity Manager (vmwlab.local). Например, tenant1.vmwlab.local. Так как используется сочетание имени арендатора с идущим за ним именем домена, оно остается неизменным даже в кластерных VMware Identity Manager. Для экземпляра vRealize Automation формат FQDN арендатора vRealize Automation представляет собой имя арендатора (tenant1), за которым следует FQDN сервера vRealize Automation (vra1.vmwlab.local) Например, tenant1.vra1.vmwlab.local. Для кластерных vRealize Automation с подсистемой балансировки нагрузки vra-lb.vmwlab.local доступ к арендатору 1 осуществляется с помощью tenant1.vra-lb.vmwlab.local.

Как и в случае с VMware Identity Manager, даже для полного доменного имени арендаторов vRealize Automation требуется сопоставление службы доменных имен (DNS). Однако в случае с vRealize Automation для сопоставления FQDN арендаторов vRealize Automation с FQDN сервера vRealize Automation необходима запись типа CNAME. При кластерном развертывании vRealize Automation все FQDN арендаторов vRealize Automation должны иметь DNS-запись типа CNAME, указывающую на FQDN подсистемы балансировки нагрузки vRealize Automation.

Помимо DNS-сопоставлений, для работы в режиме аренды также обязательно наличие сертификатов. VMware Identity Manager, серверы vRealize Automation и подсистемы балансировки нагрузки в зависимости от архитектуры развертывания должны иметь соответствующие сертификаты, содержащие все необходимые FQDN арендаторов.

Полное доменное имя арендаторов в конфигурации с одним узлом

VMware Identity Manager Узел: idm1.vmwlab.local
vRealize Automation Узел: vra1.vmwlab.local
Псевдоним основного арендатора: master-tenant
Арендаторы: tenant-1, tenant-2

Имена арендаторов	Полные доменные имена арендаторов VMware Identity Manager	Полные доменные имена арендаторов 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 Подсистема балансировки нагрузки: idm-lb.vmwlab.local
VMware Identity Manager Узлы: idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local
vRealize Automation Подсистема балансировки нагрузки: vra-lb.vmwlab.local
vRealize Automation Узлы: vra1.vmwlab.local, vra2.vmwlab.local, vra3.vmwlab.local
Псевдоним основного арендатора: master-tenant
Арендаторы: tenant-1, tenant-2

Имена арендаторов	Полные доменные имена арендаторов VMware Identity Manager	Полные доменные имена арендаторов 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

Примечание: После включения функции множественной аренды доступ к VMware Identity Manager можно будет получить только по полным доменным именам арендаторов. Старые полные доменные имена и имена узлов (idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local и idm-lb.vmwlab.local) становятся недопустимыми.

Обязательные требования к сертификатам

В зависимости от типа развертывания VMware Identity Manager и vRealize Automation, в соответствующих сертификатах серверов должны быть указаны все FQDN арендаторов. Так как каждый арендатор формирует собственное полное доменное имя (FQDN арендатора VMware Identity Manager и FQDN арендатора vRealize Automation), FQDN каждого созданного арендатора должно быть добавлено как в сертификат VMware Identity Manager, так и в сертификат vRealize Automation. Для активации функции множественной аренды в VMware Identity Manager также требуется обновление сертификатов VMware Identity Manager, так как основной арендатор получает новый псевдоним, а его FQDN изменяется.

Примечание:

Если сертификаты в VMware Identity Manager изменяются с целью включения функции множественной аренды или создания арендаторов, служба становится недоступной, что приводит к простою. Если сертификат VMware Identity Manager изменяется, возникает простой службы. Продукты или службы, интегрированные с VMware Identity Manager с целью проверки их подлинности, не могут использовать функцию входа с проверкой в VMware Identity Manager во время простоя. Кроме того, при изменении сертификата VMware Identity Manager требуется повторная проверка надежности всех продуктов и служб, что также приводит к простою в работе продуктов.
Для каждого нового арендатора, созданного и связанного с vRealize Automation, требуется изменение сертификатов vRealize Automation, что приводит к простою vRealize Automation.
Чтобы избежать простоев в работе vRealize Automation, VMware Identity Manager и других продуктов или служб, интегрированных с VMware Identity Manager, обычно рекомендуется использовать сертификаты с поддержкой поддоменов. При создании новых арендаторов любые изменения, вносимые в сертификаты VMware Identity Manager или vRealize Automation, могут привести к простою vRealize Automation.
Если сертификаты с поддержкой поддоменов не используются, для каждого FQDN арендатора во всех требуемых сертификатах необходимо создать отдельную запись SAN.
Служба Locker в vRealize Suite Lifecycle Manager помогает управлять сертификатами на узлах серверов VMware Identity Manager и vRealize Automation. В случае с vRealize Suite Lifecycle Manager, если заменить сертификат VMware Identity Manager, повторная проверка надежности сертификата VMware Identity Manager для всех продуктов выполняется автоматически.
Управление продуктами или службами, внешними по отношению к vRealize Suite Lifecycle Manager, осуществляется вручную. Служба Locker не обновляет сертификаты подсистемы балансировки нагрузки. Пользователь должен сделать это вручную. При любых изменениях сертификатов подсистемы балансировки нагрузки повторная проверка надежности должна быть проведена для всех продуктов.
- VMware Identity Manager. При выполнении операции обновления или замены сертификата VMware Identity Manager внутри vRealize Suite Lifecycle Manager проводится повторная проверка надежности сертификата VMware Identity Manager перед обновлением сертификатов сервера VMware Identity Manager. Поэтому рекомендуется сначала вручную изменить сертификат подсистемы балансировки нагрузки VMware Identity Manager, а затем обновить или заменить сертификат VMware Identity Manager с помощью службы vRealize Suite Lifecycle Manager Locker.
- vRealize Automation 8.x. Если доступ протокола SSL к подсистеме балансировки нагрузки vRealize Automation запрещен, а ее сертификат изменен вручную, нажмите кнопку «Повторная проверка надежности подсистемы балансировки нагрузки» под карточкой продукта vRealize Automation 8.x, чтобы подтвердить надежность сертификата подсистемы балансировки нагрузки в vRealize Automation. Подробнее см. в разделе Операции по регулярному обслуживанию с другими продуктами в vRealize Suite Lifecycle Manager.

Обязательные требования к службе доменных имен (DNS)

Для VMware Identity Manager с одним узлом необходимы DNS-записи типа A, отсылающие FQDN арендаторов к IP-адресу сервера VMware Identity Manager. Для кластерных VMware Identity Manager необходимы DNS-записи типа A, отсылающие FQDN арендаторов к IP-адресу подсистемы балансировки нагрузки VMware Identity Manager.

Для vRealize Automation с одним узлом необходимы DNS-записи типа CNAME, связывающие полные доменные имена арендаторов vRealize Automation с полным доменным именем сервера vRealize Automation. Для кластерных vRealize Automation необходимы DNS-записи типа CNAME, связывающие полные доменные имена арендаторов vRealize Automation с полным доменным именем подсистемы балансировки нагрузки vRealize Automation.

Требования к модели с множественной арендой

Рис. 1. VMware Identity Manager и vRealize Automation с одним узлом	Рис. 2. Кластеры VMware Identity Manager и vRealize Automation
Рис. 3. VMware Identity Manager с одним узлом и кластер vRealize Automation	Рис. 4. Кластер VMware Identity Manager и vRealize Automation с одним узлом