Cette section décrit le modèle de mutualisation. Elle explique comment les locataires sont accessibles via les noms de domaine complets des locataires et pourquoi il est important d'activer la mutualisation en même temps que le certificat et les conditions requises pour le DNS.
Activation d'une architecture mutualisée
Le locataire master est désormais appelé locataire principal. Même si, le jour 0, VMware Identity Manager prêt à l'emploi inclut un locataire principal déjà disponible, cette configuration est minimale et il n'est pas possible de créer de locataires sous le locataire principal. Une séquence de configurations et d'appels d'API doit être effectuée sur VMware Identity Manager pour activer la mutualisation. Un nom d'alias doit être créé pour le locataire principal lorsque vous activez la mutualisation. Pour plus d'informations sur l'activation de la mutualisation, reportez-vous à la section Activer une architecture mutualisée.
Par exemple, une instance de VMware Identity Manager avec le nom de domaine complet « idm1.vmwlab.local » peut déjà disposer d'un locataire principal nommé « idm1 ». Avant d'activer la mutualisation, vous devez obligatoirement créer un alias pour le locataire principal. Par exemple, choisissez « master-tenant » et utilisez le même nom d'alias partout où il est fait référence au locataire principal.
Noms de domaine complets de locataires
Par défaut, les locataires créés dans VMware Identity Manager sont accessibles via des URL de locataires qui ne sont rien d'autre que des noms de domaine complets mappés au serveur VMware Identity Manager. Chaque locataire dispose de son propre nom de domaine complet de locataire. Par exemple, dans une instance de VMware Identity Manager à nœud unique ayant idm1.vmwlab.local comme nom d'hôte, idm1 comme alias de locataire principal et master-tenant comme alias de locataire principal, le locataire principal est accessible via son nom de domaine complet master-tenant.vmwlab.local. Si un nouveau locataire (tenant1) est créé, il est alors uniquement accessible via tenant1.vmwlab.local.
Étant donné que chaque locataire nécessite un nom de domaine complet dédié, la création de locataires dans VMware Identity Manager nécessite obligatoirement un enregistrement DNS de type A mappant le nom de domaine complet du locataire à l'adresse IP du serveur VMware Identity Manager. Pour un déploiement de VMware Identity Manager en cluster, chaque nom de domaine complet de locataire doit disposer d'un mappage d'enregistrement de type A à l'adresse IP de l'équilibrage de charge de VMware Identity Manager.
Le même modèle s'applique aussi à vRealize Automation. Lorsque vRealize Automation est associé à un locataire, l'accès au locataire vRealize Automation doit s'effectuer par le biais du nom de domaine complet du locataire vRealize Automation. Par exemple, VMware Identity Manager avec idm1.vmwlab.local comme nom de domaine complet et un locataire « tenant1 » accessible par le biais de tenant1.vmwlab.local et vRealize Automation 8.1 vra1.vmwlab.local intégré à cette instance de VMware Identity Manager et associé à « tenant1 ». Comme indiqué, le locataire vRealize Automation et le locataire VMware Identity Manager sont mappés l'un à l'autre, de sorte que le locataire principal vRealize Automation est toujours accessible par vra1.vmwlab.local et que le « tenant 1 » vRealize Automation doit être accessible par le biais de tenant1.vra1.vmwlab.local.
Comme pour VMware Identity Manager, même les noms de domaine complets de locataire vRealize Automation nécessitent un mappage DNS. Toutefois, pour vRealize Automation, il doit s'agir d'un enregistrement de type CNAME mappant des noms de domaine complets de locataires vRealize Automation au nom de domaine complet du serveur vRealize Automation. Pour un déploiement de vRealize Automation en cluster, tous les noms de domaine complets de locataires vRealize Automation doivent disposer d'un enregistrement DNS de type CNAME pointant vers le nom de domaine complet de l'équilibrage de charge de vRealize Automation.
Outre la condition préalable obligatoire des mappages DNS, les certificats sont également obligatoires pour que la mutualité fonctionne. Les serveurs VMware Identity Manager, vRealize Automation et leurs équilibrages de charge dépendant de l'architecture du déploiement doivent avoir des certificats correspondants contenant tous les noms de domaine complets de locataires requis.
- Nœud VMware Identity Manager : idm1.vmwlab.local
Nœud vRealize Automation : vra1.vmwlab.local
Nom d'alias du locataire principal : master-tenant
Locataires : tenant-1, tenant-2
Noms des locataires | Noms de domaine complets de locataires VMware Identity Manager | Noms de domaine complets de locataires 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 |
- Équilibreur de charge VMware Identity Manager : idm-lb.vmwlab.local
Nœuds VMware Identity Manager : idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local
Équilibreur de charge vRealize Automation : vra-lb.vmwlab.local
Nœuds vRealize Automation : vra1.vmwlab.local, vra2.vmwlab.local, vra3.vmwlab.local
Nom d'alias du locataire principal : master-tenant
Locataires : tenant-1, tenant-2
Noms des locataires | Noms de domaine complets de locataires VMware Identity Manager | Noms de domaine complets de locataires 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 |
Conditions requises obligatoires pour les certificats
- Lorsque vous modifiez les certificats dans VMware Identity Manager pour activer la mutualisation ou que vous créez des locataires, cela entraîne la mise à l'arrêt du service et un temps d'arrêt. Si le certificat de VMware Identity Manager est modifié, il en découle une interruption de service. Les produits ou les services intégrés à VMware Identity Manager à des fins d'authentification ne peuvent pas utiliser la connexion authentifiée de VMware Identity Manager pendant l'interruption de service. En outre, la modification du certificat de VMware Identity Manager impose d'approuver à nouveau tous les produits ou services, ce qui entraîne à nouveau une interruption de service pour les produits.
- Pour chaque nouveau locataire créé et associé à vRealize Automation, même les certificats de vRealize Automation doivent être modifiés, ce qui entraîne une interruption de service pour vRealize Automation.
- Pour éviter les interruptions de service dans vRealize Automation, VMware Identity Manager et d'autres produits ou services intégrés à VMware Identity Manager, il est généralement recommandé d'avoir des certificats génériques. Pour un nouveau locataire, toute modification du certificat de VMware Identity Manager ou du certificat de vRealize Automation peut entraîner une interruption de service dans vRealize Automation.
- Si des certificats génériques ne sont pas utilisés, des entrées SAN spécifiques doivent être créées pour chaque nom de domaine complet de locataire sur tous les certificats requis.
- Le service Locker de vRealize Suite Lifecycle Manager vous aide à gérer les certificats sur les nœuds de serveur VMware Identity Manager et vRealize Automation. Avec vRealize Suite Lifecycle Manager, lorsque vous remplacez un certificat de VMware Identity Manager, la réapprobation du certificat de VMware Identity Manager sur tous les produits s'effectue automatiquement.
- Les produits ou services externes à vRealize Suite Lifecycle Manager sont gérés manuellement. Le service Locker ne gère pas la mise à jour des certificats d’équilibrage de charge. L'utilisateur doit l'effectuer manuellement. Chaque fois qu'un certificat d'équilibrage de charge est modifié, il doit être approuvé à nouveau sur les produits.
- Pour VMware Identity Manager, l'opération de mise à jour ou de remplacement du certificat de VMware Identity Manager dans vRealize Suite Lifecycle Manager vérifie en interne que le certificat de l'équilibrage de charge VMware Identity Manager est à nouveau approuvé avant de mettre à jour les certificats de serveur VMware Identity Manager. Par conséquent, il est recommandé de commencer par modifier manuellement le certificat d'équilibrage de charge VMware Identity Manager, puis de créer un certificat VMware Identity Manager pour une mise à jour ou un remplacement par le biais du service Locker de vRealize Suite Lifecycle Manager.
- Pour vRealize Automation 8.x, lorsque SSL est arrêté au niveau de l'équilibrage de charge vRealize Automation et que le certificat de l'équilibrage de charge est modifié manuellement, cliquez sur « Approuver à nouveau l'équilibrage de charge » sous la carte de produit de vRealize Automation 8.x pour approuver à nouveau le certificat d'équilibrage de charge dans vRealize Automation. Pour plus de détails, reportez-vous à Opérations du jour 2 avec d'autres produits dans vRealize Suite Lifecycle Manager.
Conditions requises obligatoires pour le DNS
Pour VMware Identity Manager à nœud unique, vous avez besoin d'enregistrements DNS de type A mettant en évidence les noms de domaine complets de locataires à l'adresse IP du serveur VMware Identity Manager. Pour VMware Identity Manager mis en cluster, il faut des enregistrements DNS de type A faisant pointer les noms de domaine complets de locataires vers l'adresse IP de l'équilibrage de charge VMware Identity Manager.
Pour vRealize Automation, pour un nœud unique, il faut des enregistrements DNS de type CNAME faisant pointer les noms de domaine complets de locataires vRealize Automation vers le nom de domaine complet du serveur vRealize Automation. Pour vRealize Automation en cluster, il faut des enregistrements DNS de type CNAME faisant pointer les noms de domaine complets de locataires vRealize Automation vers le nom de domaine complet de l'équilibrage de charge vRealize Automation.