Pour gérer et surveiller plusieurs installations ou groupes de serveurs VMware Cloud Director distribués géographiquement et leurs organisations en tant qu'entités uniques, vous pouvez utiliser la fonctionnalité multisite de VMware Cloud Director.
Implémentation multisite efficace
Lorsque vous associez deux sites VMware Cloud Director, vous activez l'administration des sites en tant qu'entité unique. Vous permettez également aux organisations sur ces sites de former des associations entre elles. Reportez-vous à Créer une association de sites dans votre VMware Cloud Director. Lorsqu'une organisation est membre d'une association, les utilisateurs de l'organisation peuvent utiliser le VMware Cloud Director Tenant Portal pour accéder aux ressources de l'organisation de n'importe quel site membre, bien que chaque organisation membre et ses ressources soient locales sur le site qu'elles occupent.
Les sites doivent avoir la même version de VMware Cloud Director API ou une version majeure de différence. Par exemple, vous pouvez associer un site VMware Cloud Director 10.1 (API version 34.0) à un site VMware Cloud Director version 10.0, 10.1, 10.2 ou 10.2.2, correspondant à la version de l'API version 33.0, 34.0, 35.0 ou 35.2 respectivement.
Lorsque vous associez deux sites, vous pouvez utiliser l'API VMware Cloud Director ou le portail VMware Cloud Director Tenant Portal pour associer les organisations qui occupent ces sites. Reportez-vous à la section Guide de programmation de VMware Cloud Director API ou à la section Configurer et gérer des déploiements multisite du Guide des sous-fournisseurs et des locataires de VMware Cloud Director.
Un site ou une organisation peut former un nombre illimité d'associations avec un homologue, mais chaque association inclut exactement deux membres. Chaque site ou organisation doit détenir sa propre clé privée. Les membres d'une association établissent une relation de confiance en échangeant des clés publiques, qui sont utilisées pour vérifier les demandes signées d'un membre à un autre.
Chaque site d'une association est défini par l'étendue d'un groupe de serveurs VMware Cloud Director (un groupe de serveurs qui partagent une base de données VMware Cloud Director). Chaque organisation dans une association occupe un site unique. L'administrateur d'organisation contrôle l'accès aux ressources par les utilisateurs et les groupes de l'organisation sur chaque site membre.
Objets site et associations de sites
Le processus d'installation ou de mise à niveau crée un objet Site qui représente le groupe de serveurs VMware Cloud Director local. Un administrateur système dont l'autorité s'étend à plusieurs groupes de serveurs VMware Cloud Director peut configurer ces groupes de serveurs comme une association de sites VMware Cloud Director.
Noms de site
GET https://Site-B.example.com/api/site ... <Site name="b5920690-fe13-4c31-8e23-9e86005e7a7b" ...> ... <RestEndpoint>https://Site-A.example.com/api/org/Org-A</RestEndpoint> <RestEndpointCertificate>-----BEGIN CERTIFICATE----- MIIDDTCCAfWgAwIBAgI...Ix0eSE= -----END CERTIFICATE----- </RestEndpointCertificate> ... </Site>Comme il n'est pas nécessaire que le nom du site corresponde au nom d'hôte dans le point de terminaison de l'API, un administrateur système peut mettre à jour le nom du site par commodité administrative pour les utilisateurs de l'API VMware Cloud Director, avec une demande semblable à celle-ci :
PUT https://Site-B.example.com/api/site content-type: application/vnd.vmware.vcloud.site+xml ... <Site name="Site-B" ...> ... <RestEndpoint>https://Site-A.example.com/api/org/Org-A</RestEndpoint> <RestEndpointCertificate>-----BEGIN CERTIFICATE----- MIIDDTCCAfWgAwIBAgI...Ix0eSE= -----END CERTIFICATE----- </RestEndpointCertificate> ... </Site>L'élément Site présent dans le corps de la demande doit conserver le formatage dans lequel il a été renvoyé par la demande
GET .../site
. Les caractères supplémentaires, notamment les retours chariot, les sauts de ligne ou les espaces, avant ou après les certificats peuvent provoquer le renvoi de système d'une exception de demande incorrecte.
Associations d'organisations
En-têtes d'autorisation et distribution ramifiée de demande
La réponse Session à une demande de connexion réussie inclut un en-tête X-VMWARE-VCLOUD-ACCESS-TOKEN dont la valeur est une clé codée que vous pouvez utiliser et la valeur de l'en-tête X-VMWARE-VCLOUD-TOKEN-TYPE, pour construire un en-tête JWT Authorization à inclure dans les demandes ultérieures à la place de l'en-tête x-vcloud-authorization obsolète, qui ne vous authentifie pas auprès des membres de l'association. Reportez-vous à la section Créer une session d'API VMware Cloud Director pour plus d'informations sur la connexion à l'API VMware Cloud Director.
Vous pouvez effectuer des demandes qui sont réparties auprès de plusieurs membres de l'association en spécifiant la paire multisite=valeur dans l'en-tête Accept. Si vous souhaitez que la demande soit répartie, value peut être global ou une liste d'ID d'emplacement séparés par des deux-points. Pour plus d'informations sur l'obtention des ID d'emplacement, reportez-vous à la section Emplacements autorisés. Lorsque vous définissez value sur local, la demande n'est pas répartie, mais comprend des métadonnées multisites incluses dans la répartition.
Accept: application/*;version=30.0;multisite=global
Vous pouvez spécifier une liste d'ID d'emplacement séparés par des deux-points. Par exemple, multisite=ID-a:ID-b:ID-x. Si vous n'incluez pas cette valeur dans l'en-tête Accept, la demande renvoie uniquement ces ressources appartenant à l'organisation cible de la demande. À moins que vous ne présentiez une demande à l'organisation auprès de laquelle vous avez été authentifié, vous devez également inclure un en-tête X-VMWARE-VCLOUD-AUTH-CONTEXT qui spécifie le nom de l'organisation qui répondra à votre demande.
- rel="fanout:failed"
- L'état du membre était ACTIVE mais l'authentification du membre a échoué pour une autre raison.
- rel="fanout:skipped"
- L'authentification du membre a été ignorée, car l'état de l'association était ASYMMETRIC ou UNREACHABLE.
Emplacements autorisés
- Site-A.example.com et Site-B.example.com sont associés.
- L'utilisateur se connecte au Site-A en tant qu'administrateur système.
POST https://Site-A.example.com/api/sessions Authorization: Basic ... Accept: application/*;version=30.0 ...
200 OK ... X-VMWARE-VCLOUD-ACCESS-TOKEN: eyJhbGciOiJSUzI1NiJ9....Rn4Xw X-VMWARE-VCLOUD-TOKEN-TYPE: Bearer Content-Type: application/vnd.vmware.vcloud.session+xml;version=30.0;multisite=global ... <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Session ... ... <AuthorizedLocations> <Location> <LocationId>a93c9db9-7471-3192-8d09-a8f7eeda85f9@9a41... </LocationId> <SiteName>Site-A</SiteName> <OrgName>System</OrgName> <RestApiEndpoint>https://site-a.example.com </RestApiEndpoint> <UIEndpoint>https://site-a.example.com </UIEndpoint> <AuthContext>System</AuthContext> </Location> <Location> <LocationId>a93c9db9-7471-3192-8d09-a8f7eeda85f9@4f56... </LocationId> <SiteName>Site-B</SiteName> <OrgName>System</OrgName> <RestApiEndpoint>https://site-b.example.com </RestApiEndpoint> <UIEndpoint>https://site-b.example.com </UIEndpoint> <AuthContext>System</AuthContext> </Location> </AuthorizedLocations> </Session>
Identités d'utilisateurs et de groupes
Les associations de sites et d'organisations doivent convenir d'utiliser le même fournisseur d'identité (IDP). Les identités d'utilisateurs et de groupes pour toutes les organisations dans l'association doivent être gérées au moyen de ce fournisseur d'identité.
Les associations sont libres de choisir le fournisseur d'identité qui leur convient le mieux. Reportez-vous à la section Gestion des fournisseurs d'identité dans VMware Cloud Director.
À partir de VMware Cloud Director 10.4.1, les comptes de service peuvent gérer et surveiller plusieurs installations ou groupes de serveurs VMware Cloud Director distribués géographiquement et leurs organisations en tant qu'entités uniques à l'aide de la fonctionnalité multisite. Si un compte de service fait une demande à une organisation différente de celle sur laquelle il est authentifié, vérifiez que le compte de service existe dans l'organisation associée et qu'il a le même nom et le même ID logiciel. Reportez-vous à la section Gestion des comptes de service dans VMware Cloud Director.
Contrôle d'accès aux sites pour les utilisateurs et les groupes d'organisation
Les administrateurs d'organisation peuvent configurer leur fournisseur d'identité pour générer des jetons d'accès d'utilisateur ou de groupe qui sont valides sur tous les sites membres ou seulement sur un sous-ensemble des sites membres. Alors que les identités d'utilisateurs et de groupes doivent être les mêmes dans toutes les organisations membres, les droits des utilisateurs et des groupes sont limités par les rôles attribués à ces utilisateurs et groupes dans chaque organisation membre. L'attribution d'un rôle à un utilisateur ou un groupe se fait de manière locale à l'organisation membre, tout comme les rôles personnalisés que vous créez.
Conditions d'équilibrage de charge
Pour implémenter efficacement un déploiement multisite, vous devez configurer un équilibrage de charge qui répartit les demandes arrivant sur un point de terminaison institutionnel comme https://vcloud.example.com sur les points de terminaison de chaque membre de l'association de sites (par exemple, https://us.vcloud.example.com et https://uk.vcloud.example.com). Si un site dispose d'une seule cellule, vous devez également configurer un équilibrage de charge qui répartit les demandes entrantes dans l'ensemble de ses cellules, afin qu'une demande à https://us.vcloud.example.com puisse être traitée par https://cell1.us.vcloud.example.com, https://cell2.us.vcloud.example.com, etc.
À partir de VMware Cloud Director 10.3, toutes les demandes des clients qui arrivent au point de terminaison d'équilibrage de charge pour un déploiement multisite sont redirigées. Lorsqu'une demande arrive au point de terminaison d'équilibrage de charge, même si le site sur lequel la demande arrive est la bonne, une redirection est émise et reflétée dans l'URL visible par l'utilisateur pour indiquer que la demande a été dirigée vers l'emplacement correct.
Par exemple, vous pouvez avoir un déploiement composé de deux sites (https://site1.vcloud.example.com et https://site2.vcloud.example.com) derrière un point de terminaison d'équilibrage de charge https://us.vcloud.example.com. À partir de VMware Cloud Director 10.3, lorsqu'une demande arrive au point de terminaison d'équilibrage de charge d'une organisation située sur le site 1 (https://us.vcloud.example.com/org1), si la demande est renvoyée sur le site 1, le site émettra une redirection vers lui-même en faisant suivre la demande au site https://site1.vcloud.example.com/org1. VMware Cloud Director 10.2.x ou version antérieure n'émet aucune redirection lorsqu'un équilibrage de charge reçoit une demande pour une organisation qui se trouve au même emplacement et que la demande est traitée via l'URL du point de terminaison public https://us.vcloud.example.com/org1.
Configuration requise pour la connexion réseau
Si vous souhaitez utiliser la fonctionnalité multisite, chaque cellule de chaque site doit pouvoir effectuer des demandes REST API auprès des points de terminaison REST API de tous les sites. Si vous utilisez les exemples de la section Conditions d'équilibrage de charge, cell1.us.vcloud.example.com et cell2.us.vcloud.example.com doivent pouvoir accéder au point de terminaison REST API pour uk.example.com. L'inverse est vrai pour toutes les cellules sous uk.example.com. Cela signifie qu'une cellule doit également pouvoir effectuer des appels REST API à son propre point de terminaison REST API, de sorte que cell1.us.vcloud.example.com doit pouvoir effectuer un appel REST API à https://us.vcloud.example.com.
Les demandes REST API effectuées auprès des points de terminaison REST API de tous les sites sont nécessaires pour la répartition des demandes REST API. Par exemple, lorsque l'interface utilisateur ou un client d'API effectue une demande multisite pour obtenir les pages d'organisations de tous les sites et cell1.us.vcloud.example.com traite la demande. La cellule cell1
effectue un appel REST API pour obtenir les pages d'organisations à partir de chaque site à l'aide du point de terminaison REST API configuré pour ce site. Lorsque tous les sites renvoient les pages d'organisations, cell1
rassemble les résultats et renvoie une seule page de résultats contenant les données de tous les autres sites.
Sites et certificats
Lorsqu'un site est associé à d'autres sites, si vous mettez à jour son certificat, vous devrez peut-être informer les autres sites de la modification. Dans le cas contraire, la répartition multisite peut être affectée.
Si vous remplacez un certificat sur un site par un certificat valide et signé, vous n'avez pas besoin d'en informer les autres sites. Comme le certificat est valide et signé, les cellules des autres sites peuvent continuer à s'y connecter de manière sécurisée sans interruption.
État de membre de l'association
- ACTIVE
- L'association a été établie par les deux parties et la communication avec la partie distante a réussi.
- ASYMMETRIC
- L'association a été établie sur le site local, mais le site distant n'a pas encore répondu.
- UNREACHABLE
- Une association a été créée par les deux parties, mais le site distant est actuellement inaccessible sur le réseau.
Dans le Service Provider Admin Portal et le Tenant Portal, les états s'affichent sous la forme Connected
, Partially Connected
et Unreachable
.
Le processus du « signal de pulsation » de l'état de membre s'exécute avec l'identité de l'utilisateur système multisite, un compte d'utilisateur local de VMware Cloud Director créé dans l'organisation système pendant l'installation de VMware Cloud Director. Bien que ce compte soit membre de l'organisation système, il ne dispose pas de droits d'administrateur système. Il n'a qu'un seul droit, Multisite: System Operations
, qui lui donne l'autorisation d'effectuer une demande d'API VMware Cloud Director qui récupère l'état du membre distant d'une association de sites.