Este artigo é uma breve introdução ao Universal Broker, um dos serviços da Camada de controle do Horizon. O Universal Broker é um serviço com base na nuvem que permite a intermediação de recursos que abrangem várias implantações de pod, independentemente da infraestrutura em que estão sendo executados. O serviço também toma decisões de intermediação inteligentes com base nos locais geográficos de usuários e pods.

Visão geral do Universal Broker

O Universal Broker, a mais recente tecnologia de intermediação com base na nuvem da VMware, está disponível para uso quando o tenant tem uma ou mais das seguintes opções:

  • Pods do Horizon: pods baseados na tecnologia do Horizon Connection Server
  • Pods do Horizon Cloud on Microsoft Azure e todos os pods que estão executando o manifesto de pod 2298.0 ou posterior.

Para obter informações detalhadas sobre como os componentes do sistema da solução do Universal Broker funcionam juntos para gerenciar as solicitações de conexão dos usuários às atribuições, consulte Arquitetura do sistema e componentes do Universal Broker.


Diagrama abrangente da arquitetura do sistema do Universal Broker

Principais Recursos

O Universal Broker oferece os seguintes recursos principais:

  • FQDN de conexão única para todos os recursos remotos

    Os usuários finais podem acessar atribuições de várias nuvens no seu ambiente através da conexão de um único nome de domínio totalmente qualificado (FQDN) que você define nas definições de configuração do Universal Broker. Por meio do FQDN único do Universal Broker, os usuários podem acessar atribuições de qualquer pod participante em qualquer site em seu ambiente. Não é necessária nenhuma rede interna entre os pods.


    Diagrama de conexão de FQDN único para o Universal Broker
  • Conectividade e conscientização do pod global para desempenho ideal

    O Universal Broker mantém a conectividade direta com cada pod participante de atribuições de várias nuvens e permanece ciente do status de disponibilidade de cada pod. Como resultado, o Universal Broker pode gerenciar as solicitações de conexão dos usuários finais e encaminhá-las para os recursos virtuais diretamente desses pods. Não há necessidade de GSLB (balanceamento de carga de servidor global) ou de qualquer comunicação de rede entre pods que possa resultar em problemas de desempenho e latência reduzidos.

  • Intermediação inteligente

    O Universal Broker pode intermediar recursos de atribuições para usuários finais pela rota de rede mais curta, com base no reconhecimento de seus locais geográficos e topologia de pod.

Pools de áreas de trabalho e aplicativos remotos de usuários finais e de intermediação

Atribuições são entidades conceituais no Horizon Universal Console. Usando o console, as atribuições são a maneira como você define pools de áreas de trabalho virtuais do usuário final e aplicativos remotos e concede aos usuários finais o direito a eles. Por exemplo, no console, você cria atribuições de áreas de trabalho VDI ou atribuições de recursos RDSH e, em seguida, autoriza essas atribuições aos seus usuários finais.

O Universal Broker gerencia a solicitação de conexão de um usuário cliente para uma atribuição autorizada e negocia a sessão de conexão com um recurso apropriado que atende a essa solicitação. O Universal Broker está ciente da localidade geográfica e da topologia do pod. Usando essas informações, o Universal Broker pesquisa os melhores recursos para atender às solicitações de conexão dos usuários com base na configuração do site e na disponibilidade de recursos.

Consulte as seções a seguir para a lista de tipos de atribuição disponíveis, por tipo de pod.

Atribuições de usuário final usando recursos dos pods do Horizon Cloud implantados no Microsoft Azure

Com a configuração do Universal Broker concluída para os pods do Horizon Cloudem sua frota de pods, estes tipos de atribuição são possíveis:

Atribuições de usuário final usando recursos de pods do Horizon conectados à nuvem

Com a configuração do Universal Broker concluída para os pods do Horizonem sua frota de pods, estes tipos de atribuição são possíveis:

Notas

Assim como ocorre com quase todos os softwares, a versão atual tem algumas considerações de recursos e limitações conhecidas. Para obter mais informações, consulte Universal Broker - Considerações sobre recursos e limitações conhecidas.

Arquitetura do sistema e componentes do Universal Broker

Este artigo fornece uma ilustração detalhada dos componentes do sistema do Universal Broker que são executados nos pods participantes e na camada de controle do Horizon Cloud. O Universal Broker representa a mais recente tecnologia de intermediação com base na nuvem da VMware e é o intermediário de conexão recomendado para atribuições de usuário final em novas implantações.

Para obter uma visão geral dos principais recursos do Universal Broker, consulte Introdução ao VMware Horizon Service Universal Broker.

A arquitetura do sistema da solução do Universal Broker difere ligeiramente dependendo do fato de os recursos intermediados residirem em pods do Horizon (com base na tecnologia do Horizon Connection Server) ou em pods do Horizon Cloud no Microsoft Azure.

Arquitetura do sistema do Universal Broker para pods do Horizon

Os seguintes componentes compreendem a solução Universal Broker para a intermediação baseada em nuvem de atribuições de várias nuvens de pods do Horizon (com base na tecnologia do Horizon Connection Server).

  • O serviço do Universal Broker é um serviço de nuvem multiempresa executado na nuvem do Universal Broker, que está conectada ao Horizon Cloud. Cada cliente se conecta ao serviço do Universal Broker usando um FQDN exclusivo e dedicado que está configurado conforme descrito em Definir Configurações do Universal Broker.
  • O cliente do Universal Broker é executado dentro do Horizon Cloud Connector para cada um dos pods do Horizon conectados à nuvem. A partir da versão 1.5 desse conector, o cliente do Universal Broker faz parte desse conector e é instalado automaticamente quando você emparelha o Horizon Cloud Connector com o seu pod.
  • O plug-in do Universal Broker é executado no Horizon Connection Server para cada pod conectado à nuvem que participa de atribuições de várias nuvens. Você deve baixar e instalar o plug-in em cada instância do Servidor de Conexão dentro de um pod participante, conforme descrito em Pods do Horizon: Instalar o Universal Broker plug-in no Servidor de Conexão.

O diagrama a seguir ilustra como o Universal Broker trabalha com os componentes no ambiente de pod do Horizon para gerenciar as solicitações de conexão dos usuários finais externos para os recursos remotos em uma atribuição.

Observação: O cenário descrito envolve o Horizon Client localizado em uma rede externa, fora da sua rede corporativa, com um Unified Access Gateway externo configurado no pod.

Arquitetura do sistema do Universal Broker para pods do Horizon

  1. No Horizon Client, o usuário final solicita uma área de trabalho virtual conectando-se ao serviço do Universal Broker por meio do FQDN de intermediação. O serviço usa o protocolo XML-API para autenticar o usuário do Horizon Client e gerenciar a sessão de conexão.
  2. Depois de determinar que o Pod 1 no Site 1 é a melhor fonte disponível para a área de trabalho, o serviço do Universal Broker envia uma mensagem para o cliente do Universal Broker, que é executado no Horizon Cloud Connector emparelhado com o Pod 1.
  3. O cliente do Universal Broker encaminha a mensagem para o plug-in do Universal Broker, que é executado em cada uma das instâncias do Servidor de Conexão no Pod 1.
  4. O plug-in do Universal Broker identifica a melhor área de trabalho disponível que atende à solicitação do usuário final.
  5. O serviço do Universal Broker retorna uma resposta ao Horizon Client que inclui o FQDN exclusivo do Pod 1 (normalmente o FQDN do balanceador de carga do Pod 1). O Horizon Client estabelece uma conexão com o balanceador de carga para solicitar uma sessão de protocolo à área de trabalho.
  6. Depois de passar pelo balanceador de carga local, a solicitação vai para o Unified Access Gateway do Pod 1. O Unified Access Gateway valida que a solicitação é confiável e prepara o Blast Secure Gateway, o PCoIP Secure Gateway e o servidor de túnel.
  7. O Horizon Client recebe a área de trabalho especificada e estabelece uma sessão com base no protocolo secundário configurado (Blast Extreme, PCoIP ou RDP).

Para obter mais informações sobre as portas usadas para comunicações do Universal Broker, consulte Pods do Horizon: requisitos de DNS, portas e protocolo para o Universal Broker.

Arquitetura de sistema do Universal Broker para pods do Horizon Cloud no Microsoft Azure

Os seguintes componentes compreendem a solução Universal Broker para a intermediação baseada em nuvem de atribuições VDI e RDSH de pods do Horizon Cloud no Microsoft Azure.

  • O serviço do Universal Broker é um serviço de nuvem multiempresa executado na nuvem do Universal Broker, que está conectada ao Horizon Cloud. Cada cliente se conecta ao serviço do Universal Broker usando um FQDN exclusivo e dedicado que está configurado conforme descrito em Definir Configurações do Universal Broker.
  • O cliente Universal Broker é executado em cada pod do Horizon Cloud participante do Microsoft Azure.
Observação: O cenário descrito envolve o Horizon Client localizado em uma rede externa, fora da sua rede corporativa, com um Unified Access Gateway externo configurado no pod.

Arquitetura do sistema do Universal Broker para pods do Horizon Cloud no Microsoft Azure

  1. No Horizon Client, o usuário final solicita um recurso virtual conectando-se ao serviço do Universal Broker por meio do FQDN de intermediação. O serviço usa o protocolo XML-API para autenticar o usuário do Horizon Client e gerenciar a sessão de conexão.
  2. Depois de determinar que o Pod 1 no Site 1 tem o melhor recurso disponível para solicitação do usuário, o serviço Universal Broker enviará uma mensagem ao cliente Universal Broker em execução dentro do Pod 1.
  3. O cliente Universal Broker encaminha a mensagem ao gerenciador de pods ativo no Pod 1.
  4. O gerenciador de pods ativo identifica o melhor recurso disponível que atende à solicitação do usuário final.
  5. O serviço do Universal Broker retorna uma resposta ao Horizon Client que inclui o FQDN exclusivo do Pod 1 (normalmente o FQDN do balanceador de carga Microsoft Azure do Pod 1). O Horizon Client estabelece uma conexão com o balanceador de carga para solicitar uma sessão de protocolo ao recurso.
  6. Depois de passar pelo balanceador de carga Microsoft Azure, a solicitação irá para o Unified Access Gateway do Pod 1. O Unified Access Gateway valida que a solicitação é confiável e prepara o Blast Secure Gateway, o PCoIP Secure Gateway e o servidor de túnel.
  7. O Horizon Client recebe os recursos especificados e estabelece uma sessão com base no protocolo secundário configurado (Blast Extreme, PCoIP ou RDP).

Para obter mais informações sobre as portas usadas para comunicações do Universal Broker, consulte a seção "Portas e protocolos exigidos pelo Universal Broker", em Requisitos de portas e protocolos para um pod do Horizon Cloud no manifesto da versão de setembro de 2019 ou posterior.

Universal Broker - Considerações sobre recursos e limitações conhecidas

Esta página de documentação algumas das considerações de recursos relacionadas ao Universal Broker, bem como uma lista dos recursos do Horizon que têm suporte limitado ou não têm suporte.

Considerações sobre o recurso

  • Em uma frota de pods que contenha pods do Horizon e pods do Horizon Cloud, cada atribuição de usuário final que você criar deverá consistir em áreas de trabalho VDI de apenas um tipo de pod. Por exemplo, você pode criar uma atribuição que consiste em áreas de trabalho que abrangem vários pods do Horizon ou vários pods do Horizon Cloud. No entanto, você não pode criar uma atribuição que consiste em áreas de trabalho que abrangem uma combinação de pods do Horizon e pods do Horizon Cloud.
  • Considerações adicionais serão aplicadas se você tiver feito a transição do tenant de uma configuração do agente de pod único para o Universal Broker. Consulte Novidades no seu ambiente de tenant após a transição para Universal Broker.

Número máximo de pods por limite de atribuição de várias nuvens VDI

O número máximo com suporte de pods em uma atribuição de várias nuvens VDI é cinco (5). Esse limite se aplica tanto aos pods do tipo do Horizon Connection Server quanto aos pods do tipo Horizon Cloud on Microsoft Azure. Usar mais de cinco aumenta a carga simultânea em Universal Broker. Aumentar essa carga simultânea pode levar os usuários finais a encontrar falhas quando clicam no bloco exibido da atribuição no cliente e o serviço tenta fazer login do usuário na área de trabalho virtual.

Recursos virtuais

Para a intermediação de recursos virtuais, esta versão do Universal Broker só é compatível com os sistemas operacionais Windows. Não há suporte para áreas de trabalho baseadas em Linux.

Essa versão não oferece suporte a atalhos criados pelo administrador para áreas de trabalho e aplicativos.

Observação: Um usuário específico pode receber no máximo uma área de trabalho atribuída de uma atribuição dedicada intermediada pelo Universal Broker, mesmo se a atribuição incluir áreas de trabalho de vários pods.

Horizon HTML Access e Horizon Client para Chrome

Os usuários finais podem fazer solicitações de recursos para o serviço Universal Broker executando o Horizon HTML Access em um navegador da Web compatível ou executando o Horizon Client para Chrome 5.4 ou versões posteriores. Se o serviço do Universal Broker redirecionar a solicitação para uma instância do Unified Access Gateway que usa um certificado autoassinado, o aplicativo cliente exibirá uma mensagem de erro indicando que a autoridade de certificação é inválida.

Esse comportamento é de acordo com o design. Para se conectar ao recurso solicitado, o usuário pode aceitar o certificado autoassinado seguindo os prompts na mensagem de erro do certificado.

Métodos de autenticação

Esta versão do Universal Broker oferece suporte à autenticação de usuário do cliente por meio de nome de usuário e senha do Windows, nos formatos UPN e NETBIOS.

Também há suporte para a autenticação de dois fatores por meio de RADIUS ou RSA, dependendo do estado atual da frota de pods do tenant, como na lista a seguir.

Em seguida, revise a seção a seguir que descreve a experiência do usuário final ao usar o Universal Broker em seus clientes, e a autenticação de dois fatores está configurada. O comportamento atual é diferente do comportamento ao usar diretamente os FQDNs do gateway de um pod.

Somente pods do Horizon
Há suporte para a autenticação RADIUS e RSA SecurID.
Somente implantações do Horizon Cloud on Microsoft Azure
Se todos os pods forem manifesto 3139.x ou posterior e as opções RSA SecurID e RADIUS estiverem visíveis para seleção quando você executar o assistente Editar pod nos pods, haverá suporte para a autenticação RSA SecurID e RADIUS. Caso contrário, apenas o tipo RADIUS terá suporte.
Combinação de pods do Horizon e implantações do Horizon Cloud on Microsoft Azure
Em uma frota combinada, os tipos de autenticação com suporte dependem de suas implantações do Horizon Cloud on Microsoft Azure atenderem às condições para ter a opção RSA SecurID configurada nelas:
  • Se suas implantações do Horizon Cloud on Microsoft Azure não atenderem a essas condições, apenas a autenticação RADIUS será compatível.
  • Se suas implantações do Horizon Cloud on Microsoft Azure atenderem a essas condições, a autenticação RADIUS e RSA SecurID será compatível.

As condições a serem atendidas são: os pods estão executando o manifesto 3139.x ou posterior e, quando você abre o assistente para Editar Pod nos pods, a opção RSA SecurID e as opções RADIUS ficam visíveis para seleção.

Quando a autenticação de dois fatores está configurada

Quando a autenticação de dois fatores estiver envolvida, seus usuários finais terão um fluxo de autenticação ao usar o FQDN do Universal Broker que é ligeiramente diferente do fluxo ao usar o FQDN do gateway de um pod diretamente.

  • No fluxo de autenticação do Universal Broker, os usuários finais serão solicitados a inserir suas credenciais do Windows Active Directory (AD) duas vezes: uma vez, quando se conectam pela primeira vez ao FQDN do Universal Broker e, em seguida, novamente após a conclusão bem-sucedida da autenticação de dois fatores com o sistema RADIUS ou RSA SecurID configurado.
  • Usando o fluxo de autenticação de gateway de um pod, os usuários finais serão solicitados a inserir suas credenciais do Windows Active Directory (AD) uma vez quando se conectarem pela primeira vez ao FQDN do gateway do pod.
Observação: Para eliminar a exibição de dois prompts do AD ao usar o Universal Broker, considere a integração com o VMware Workspace ONE Access e configure a autenticação de dois fatores no VMware Workspace ONE Access.

Métodos de acesso e autenticação de usuário atualmente não compatíveis

Os métodos de acesso e autenticação de usuário a seguir não são suportados atualmente.

  • Cartão inteligente
  • Certificado
  • Autenticação SAML (fora da integração com o VMware Workspace ONE)
  • Fazer login como o usuário atual
  • Acesso anônimo

Quando um dos itens sem suporte qualificado para suporte, sua entrada será removida da lista anterior e o anúncio do suporte será indicado na página intitulada Para Clientes Atuais com Pods Conectados à Nuvem Existentes: Sobre os lançamentos do Horizon Cloud Service. Nessa página, a instrução será listada na seção que corresponde à versão na qual o suporte foi adicionado.

Recursos da área de trabalho remota

Não há suporte para os seguintes recursos nesta versão do Universal Broker:

  • Redirecionamento de conteúdo de URL
  • Colaboração em sessão

Outros recursos

Também não há suporte para os seguintes recursos nesta versão do Universal Broker:

  • Modo quiosque
  • Perfil de temporização (para solucionar problemas nas sessões de usuário).
  • Verificações de conformidade do endpoint com base em OPSWAT.