Configuration et gestion de déploiements multisite dans votre VMware Cloud Director

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.

Note :

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 du locataire 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

Chaque objet Site est créé avec un attribut de nom sous la forme d'un UUID.

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

Une fois l'association de sites effectuée, les administrateurs d'organisation sur n'importe quel site membre peuvent commencer à associer leurs organisations.

Note : Vous ne pouvez pas associer une organisation System à une organisation de locataire. L'organisation System de tout site peut être associée uniquement à l'organisation System d'un autre site.

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.

Par exemple, lorsque vous effectuez une demande, telle qu'une requête qui récupère des listes de ressources auprès d'une association d'organisations, vous pouvez spécifier la paire de multisite=global dans l'en-tête Accept. En spécifiant la paire multisite=global, vous distribuez la demande auprès de tous les membres de l'association et renvoyez une liste agrégée.

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.

Lorsqu'une demande d'authentification inclut la paire multisite= valeur, la réponse inclut les éléments Link si la demande échoue sur un membre de l'association. La catégorie de la panne est représentée par la valeur rel du lien.

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.

L'URL de demande ayant échoué ou été ignorée est dans href la valeur de Link.

Emplacements autorisés

Lorsque vous vous authentifiez sur un site membre d'une association, la réponse Session inclut un élément AuthorizedLocations qui fournit l'API VMware Cloud Director et les points de terminaison du portail du locataire VMware Cloud Director aux autres membres de l'association. Dans cet exemple :

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.

Demande :

POST https://Site-A.example.com/api/sessions
Authorization: Basic ...
Accept: application/*;version=30.0
...

Réponse :

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.

Note : Vous devez utiliser l'équilibrage de charge global, dans ce cas, https://vcloud.example.com, uniquement pour l'accès à l'interface utilisateur. Si vous développez vos propres scripts ou programmes qui utilisent REST API, ces appels doivent cibler un site particulier.

À 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.

Si vous remplacez un certificat sur un site par un certificat auto-signé, ou s'il existe un autre problème avec le certificat qui empêche l'approbation automatique, les autres sites doivent en être informés. Par exemple, si le certificat expire, vous devez en informer les autres sites. Sur chacun des autres sites, vous devez charger le certificat dans le dossier Certificats approuvés dans le Service Provider Admin Portal. Reportez-vous à Importer des certificats approuvés à l'aide de votre VMware Cloud Director Service Provider Admin Portal. Lorsque vous importez le certificat, le site sur lequel il est téléchargé peut approuver le site obtenant le nouveau certificat.

Note : Vous pouvez importer ces certificats dans les certificats de confiance des autres sites avant de les installer sur le site distant. Cela garantit qu'aucune interruption des communications ne se produit, car l'ancien certificat et le nouveau certificat se trouvent dans le pool Certificats approuvés. Vous n'avez donc pas à réassocier les sites.

État de membre de l'association

Une fois que vous avez créé une association de sites ou d'organisations, le système local récupère périodiquement l'état de chaque membre distant de l'association et met à jour cet état dans la base de données VMware Cloud Director du site local. L'état du membre est visible dans l'élément Status d'un SiteAssociationMember ou d'un OrgAssociationMember. L'élément Status peut prendre l'une des trois valeurs suivantes :

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.