Configurar e gerenciar implantações multissite no seu VMware Cloud Director

Para gerenciar e monitorar várias instalações do VMware Cloud Director geograficamente distribuídas ou grupos de servidores e suas organizações como entidades individuais, você pode usar o recurso multissite do VMware Cloud Director.

Implementação efetiva de um multissite

Ao associar dois sites do VMware Cloud Director, você ativa a administração dos sites como uma entidade única. Você também permite que as organizações nesses sites formem associações entre si. Consulte Criar uma associação de site no VMware Cloud Director. Quando uma organização é um membro de uma associação, os usuários da organização podem usar o do VMware Cloud Director Tenant Portal para acessar os ativos da organização em qualquer site membro, embora cada organização membro e seus recursos sejam locais para o site que ela ocupa.

Observação:

Os sites devem ter a mesma versão da API do VMware Cloud Director ou uma versão principal separada. Por exemplo, você pode associar um site do VMware Cloud Director 10.1 (API versão 34.0) com um site do VMware Cloud Director versão 10.0, 10.1, 10.2 ou 10.2.2, respectivamente, as versões de API 33.0, 34.0, 35.0 ou 35.2.

Depois de associar dois sites, você poderá usar a API do VMware Cloud Director ou o VMware Cloud Director Tenant Portal para associar organizações que ocupam esses sites. Consulte o Guia de programação da API do VMware Cloud Director ou o tópico Configurar e gerenciar implantações multissite no Guia de subprovedor e tenant do VMware Cloud Director.

Um site ou organização pode formar um número ilimitado de associações com um par, mas cada associação inclui exatamente dois membros. Cada site ou organização deve ter sua própria chave privada. Os membros da associação estabelecem uma relação de confiança trocando chaves públicas, que são usadas para verificar solicitações assinadas de um membro para outro.

Cada site em uma associação é definida pelo escopo de um grupo de servidores do VMware Cloud Director (um grupo de servidores que compartilham um banco de dados do VMware Cloud Director). Cada organização em uma associação ocupa um único site. O administrador da organização controla o acesso por usuários e grupos da organização aos recursos em cada site membro.

Objetos e Associações de Site

O processo de instalação ou atualização cria um objeto do Site que representa o grupo local de servidores do VMware Cloud Director. Um administrador de sistema cuja autoridade estende a mais de um grupo de servidores do VMware Cloud Director pode configurar esses grupos de servidores como uma associação de sites do VMware Cloud Director.

Nomes do Site

Cada objeto do Site é criado com um atributo de nome que é um 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>

Embora não exista um requisito de que o nome do site corresponda ao nome do host no endpoint da API, um administrador do sistema pode atualizar o nome do site como uma conveniência administrativa para os usuários da API do VMware Cloud Director, com uma solicitação como esta:

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>

O elemento do Site no corpo da solicitação deve manter a formatação na qual ela foi retornada pela solicitação do GET .../site. Caracteres adicionais, especialmente retornos de carro, alimentações de linha ou espaços, antes ou depois dos certificados, podem fazer com que o sistema retorne uma exceção de solicitação inválida.

Associações de Organizações

Após a conclusão da associação de sites, os administradores da organização em qualquer site de membro podem começar a associação de suas organizações.

Observação: Você não pode associar uma organização do System a uma organização de tenant. A organização do System em qualquer site pode ser associada somente à organização do System em outro site.

Cabeçalhos de Autorização e Fanout de Solicitação

A resposta do Session a uma solicitação de login bem-sucedida inclui um cabeçalho do X-VMWARE-VCLOUD-ACCESS-TOKEN cujo valor é uma chave codificada que você pode usar e também o valor do cabeçalho do X-VMWARE-VCLOUD-TOKEN-TYPE, para construir um cabeçalho JWT do Authorization para incluir em solicitações subsequentes no lugar do cabeçalho do x-vcloud-authorization obsoleto, que não autentica você para os membros da associação. Consulte Criar uma Sessão de API do VMware Cloud Director para obter mais informações sobre como fazer login na API do VMware Cloud Director.

Você pode fazer solicitações que fazem o fanout em vários membros de associação, especificando o par de multisite=valor no cabeçalho do Accept. Se você quiser realizar fan-out da solicitação, o valor poderá ser global ou uma lista separada por vírgula de IDs de localização. Para obter informações sobre como obter as IDs de localização, consulte Localizações Autorizadas. Quando você definir o valor como local, a solicitação não fará fan out, mas incluirá metadados multissite incluídos no fan-out.

Por exemplo, quando você faz uma solicitação como uma consulta que recupera listas de recursos de uma associação de organizações, é possível especificar o par de multisite=global no cabeçalho Accept. Especificando o par multisite=global, você desconecta a solicitação a todos os membros da associação e retorna uma lista agregada.

Accept: application/*;version=30.0;multisite=global

Você pode especificar uma lista separada por vírgula de IDs de localização, por exemplo, multisite=ID-a:ID-b:ID-x. A menos que você incluir esse valor no cabeçalho do Accept, a solicitação retorna apenas os recursos pertencentes à organização que é o destino da solicitação. A menos que você esteja fazendo uma solicitação para a mesma organização à qual se autenticou, inclua também um cabeçalho do X-VMWARE-VCLOUD-AUTH-CONTEXT que especifica o nome da organização que atenderá à sua solicitação.

Quando uma solicitação de autenticação inclui o par de multisite= value, a resposta inclui elementos do Link se a solicitação falhou em qualquer membro da associação. A categoria da falha é representada pelo valor rel do link.

rel="fanout:failed": O status do membro era ACTIVE, mas a autenticação no membro falhou por algum outro motivo.
rel="fanout:skipped": A autenticação no membro foi ignorada porque o status de associação era ASYMMETRIC ou UNREACHABLE.

A URL de solicitação com falha ou ignorada está no valor href do Link.

Localizações Autorizadas

Quando você autentica em um site que é membro de uma associação, a resposta do Session inclui um elemento do AuthorizedLocations que fornece a API do VMware Cloud Director e os endpoints do Portal de Tenant do VMware Cloud Director para outros membros da associação. Neste exemplo:

Site-A.example.com e Site-B.example.com são associados.
O usuário faz login no Site-A como administrador de sistema.

Solicitação:

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

Resposta:

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>

Identidades de Usuário e Grupo

As associações de sites e organizações devem concordar em usar o mesmo provedor de identidade (IDP). As identidades de usuário e grupo para todas as organizações na associação devem ser gerenciadas por meio desse IDP.

As associações têm a liberdade de escolher o IDP que funciona melhor para elas. Consulte Gerenciando provedores de identidade no VMware Cloud Director.

A partir do VMware Cloud Director 10.4.1, as contas de serviço podem gerenciar e monitorar várias instalações do VMware Cloud Director geograficamente distribuídas ou grupos de servidores e suas organizações como entidades únicas usando o recurso multissite. Se uma conta de serviço estiver fazendo uma solicitação a uma organização diferente da qual ela está autenticada, verifique se a conta de serviço existe na organização associada e se ela tem o mesmo nome e ID de software. Consulte Gerenciamento de contas de serviço no VMware Cloud Director.

Controle de Acesso do Site para Usuários e Grupos da Organização

Os administradores de organização podem configurar seu IDP para gerar tokens de acesso de usuários ou grupos que sejam válidos em todos os sites de membro ou válidos apenas em um subconjunto de sites de membro. Embora as identidades de usuário e grupo devam ser as mesmas em todas as organizações membros, os direitos de usuário e grupo são limitados pelas funções a que esses usuários e grupos são atribuídos em cada organização membro. A atribuição de uma função a um usuário ou grupo é local para uma organização membro, assim como qualquer função personalizada criada por você.

Requisitos do Balanceador de Carga

A implementação efetiva de uma implantação multissite exige a configuração de um balanceador de carga que distribui solicitações que chegam a um endpoint institucional, como https://vcloud.exemplo.com para os endpoints para cada membro da associação do site (por exemplo, https://us.vcloud.exemplo.com e https://uk.vcloud.exemplo.com). Se um site tiver mais de uma célula, você também deverá configurar um balanceador de carga que distribua as solicitações de entrada em todas as células, de modo que uma solicitação para https://us.vcloud.exemplo.com possa ser tratada por https://cell1.us.vcloud.exemplo.com , https://cell2.us.vcloud.exemplo.com e assim por diante.

Observação: Você deve usar o balanceador de carga global, neste caso https://vcloud.exemplo.com, apenas para acesso à interface do usuário. Se você desenvolve seus próprios scripts ou programas que usam a REST API, essas chamadas deverão ser destinadas a um site específico.

A partir do VMware Cloud Director 10.3, todas as solicitações de cliente que chegam ao endpoint de balanceamento de carga para uma implantação multissite são redirecionadas. Quando uma solicitação chega ao endpoint de balanceamento de carga, mesmo que o site de destino seja o correto, um redirecionamento é emitido e refletido na URL visível pelo usuário para especificar que a solicitação foi direcionada ao local correto.

Por exemplo, você pode ter uma implantação que consiste em dois sites: https://site1.vcloud.exemplo.com e https://site2.vcloud.exemplo.com - atrás de um endpoint de balanceamento de carga global https://us.vcloud.exemplo.com. A partir do VMware Cloud Director 10.3, quando uma solicitação chega ao endpoint de balanceamento de carga de uma organização localizada no site 1, https://us.vcloud.exemplo.com/org1, se essa solicitação chegar no site 1, este site emitirá um redirecionamento para si mesmo encaminhando a solicitação para https://site1.vcloud.exemplo.com/org1. O VMware Cloud Director 10.2.x e versões anteriores não emitem redirecionamentos quando um balanceador de carga recebe uma solicitação para uma organização que está localizada no mesmo local, e a solicitação é atendida por meio da URL do endpoint público https://us.vcloud.exemplo.com/org1.

Requisitos de conectividade de rede

Se você quiser usar o recurso multissite, cada célula em cada site deverá ser capaz de fazer solicitações de REST API aos endpoints de REST API de todos os sites. Se você usar os exemplos da seção Requisitos do Balanceador de Carga, cell1.us.vcloud.exemplo.com e cell2.us.vcloud.exemplo.com deverão ser capazes de acessar o endpoint de REST API para uk.exemplo.com. O contrário é válido para todas as células em uk.exemplo.com. Isso significa que uma célula também deve ser capaz de fazer chamadas de REST API para seu próprio endpoint de REST API, ou seja, cell1.us.vcloud.exemplo.com deve ser capaz de fazer uma chamada de REST API para https://us.vcloud.exemplo.com.

Fazer solicitações de REST API para os endpoints de REST API de todos os sites é necessário para o fan-out da REST API. Por exemplo, se a UI ou um cliente de API fizer uma solicitação multissite para obter uma página de organizações de todos os sites e cell1.us.vcloud.exemplo.com lidar com a solicitação. A célula cell1 deve fazer uma chamada de REST API para obter uma página de organizações de cada site usando o endpoint de REST API configurado para esse site. Quando todos os sites retornarem sua página de organizações, cell1 agrupará os resultados e retornará uma única página de resultados que contêm os dados de todos os outros sites.

Sites e certificados

Quando um site estiver associado a outros sites, se você atualizar o certificado dele, poderá ser preciso permitir que os outros sites saibam sobre essa alteração. Se você não permitir que os outros sites saibam sobre a alteração do certificado, o fan-out do multissite poderá ser afetado.

Se estiver substituindo um certificado em um site por um certificado válido e assinado, não será necessário informar os outros sites. Como o certificado é válido e está bem assinado, as células em outros sites podem continuar se conectando a ele de maneira segura, sem interrupção.

Se estiver substituindo um certificado em um site por um certificado autoassinado ou se houver algum outro problema com o certificado que impeça a confiança automática, outros sites precisarão saber sobre isso. Por exemplo, se o certificado expirar, você deverá informar os outros sites. Em cada um dos outros sites, você deve carregar o certificado em Certificados Confiáveis no Service Provider Admin Portal. Consulte Importar certificados confiáveis usando seu VMware Cloud Director Service Provider Admin Portal. Quando você importa o certificado, o site para o qual ele é carregado pode confiar no site para obter o novo certificado.

Observação: Você pode importar esses certificados para os Certificados Confiáveis dos outros sites antes de instalá-los no site remoto. Isso não garante interrupções na comunicação, pois o certificado antigo e o novo estão no pool de Certificados Confiáveis. Você não precisa reassociar os sites.

Status do Membro de Associação

Depois que você criar uma associação de sites ou organizações, o sistema local recuperará periodicamente o status de cada membro remoto da associação e atualizará esse status no banco de dados do VMware Cloud Director do site local. O status do membro ficará visível no elemento Status de um SiteAssociationMember ou OrgAssociationMember. O elemento Status pode ter um dos três valores:

ACTIVE: A associação foi estabelecida por ambas as partes, e a comunicação com a parte remota foi bem-sucedida.
ASYMMETRIC: A associação foi estabelecida no local, mas o local remoto ainda não retribuiu.
UNREACHABLE: Uma associação foi criada por ambas as partes, mas o site remoto não está atualmente acessível na rede.

Na tela Service Provider Admin Portal e Tenant Portal, os status aparecem como Connected, Partially Connected e Unreachable.

O processo de "heartbeat" de status de membro é executado com a identidade do usuário do sistema multissite, uma conta de usuário local do VMware Cloud Director criada na organização do Sistema durante a instalação do VMware Cloud Director. Embora essa conta seja membro da organização do Sistema, ela não possui direitos de administrador do sistema. Ele tem apenas um único direito, Multisite: System Operations, que concede permissão para fazer uma solicitação da API do VMware Cloud Director que recupera o status do membro remoto de uma associação de site.