Pour gérer et surveiller plusieurs installations de VMware Cloud Director ou groupes de serveurs distribués géographiquement et leurs organisations en tant qu'entités simples, les fournisseurs de services et les locataires peuvent 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. 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 l'API VMware Cloud Director ou à la section Configurer et gérer des déploiements multisite du Guide du portail de 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.

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.

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.

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 à Importation de certificats approuvés. 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.