Introdução ao Horizon Service Universal Broker

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 inteligentes de intermediação com base na localização geográfica dos usuários e recursos.

Visão geral do Universal Broker

Universal Broker, a tecnologia de intermediação com base na nuvem de primeira geração do Omnissa, 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
• Horizon Cloud em pods do 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 de 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.

Principais Recursos

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 de Universal Broker único, os usuários podem acessar atribuições de qualquer pod participante do em qualquer site em seu ambiente. Não é necessária nenhuma rede interna entre os pods.

  

• Conectividade e conscientização do pod global para desempenho ideal

  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, 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

  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 procura 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 obter a lista de tipos de atribuição disponíveis, por tipo de pod.

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

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

• Uma atribuição de várias nuvens que consiste em áreas de trabalho VDI de um ou mais pods Horizon Cloud. Para obter mais informações, consulte Horizon Cloud pods do no Microsoft Azure: Criar e exibir atribuições de várias nuvens VDI em seu ambiente de primeira geração.
• Uma atribuição de área de trabalho de sessão que consiste em áreas de trabalho baseadas em sessão dos hosts dos Serviços de Área de Trabalho Remota (RDS) da Microsoft em um único pod Horizon Cloud. Para obter mais informações, consulte Horizon Cloud pods do : fornecer sessões da área de trabalho de hosts do RDS a seus usuários finais por meio da criação de uma atribuição de área de trabalho de sessão baseada em RDS.
• Uma atribuição de aplicativos remotos que consiste em aplicativos provisionados por hosts RDS em Horizon Cloud pods. Para obter mais informações, consulte Aplicativos remotos – Criar uma atribuição de aplicativo remoto para aplicativos remotos provisionados por Horizon Cloud pods no Microsoft Azure.
• Uma atribuição de aplicativos App Volumes que consiste em App Volumes aplicativos hospedados em áreas de trabalho VDI em Horizon Cloud pods. Para obter mais informações, consulte Horizon Cloud - Criar uma atribuição de App Volumes.

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

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

• Uma atribuição de várias nuvens que consiste em áreas de trabalho VDI de um ou mais pods do Horizon. Para obter informações gerais sobre como configurar atribuições de várias nuvens com base em recursos dos pods do Horizon conectados à nuvem do tenant do Horizon Cloud, consulte Atribuições de Universal Broker e várias nuvens do Horizon Cloud de primeira geração.
• Uma atribuição de área de trabalho de sessão que consiste em áreas de trabalho baseadas em sessão dos hosts dos Serviços de Área de Trabalho Remota (RDS) da Microsoft em um único pod do Horizon. Para obter mais informações, consulte Pods do Horizon - Configurar áreas de trabalho e aplicativos RDSH para um ambiente Universal Broker.
• Uma atribuição de aplicativos remotos que consiste em aplicativos provisionados por hosts RDS em um único pod do Horizon. Para obter mais informações, consulte Pods do Horizon - Configurar áreas de trabalho e aplicativos RDSH para um ambiente Universal Broker.

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. Universal Broker é o intermediário de conexão recomendado para atribuições de usuário final em implantações do Horizon Cloud de primeira geração.

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

A arquitetura do sistema da solução Universal Broker do difere ligeiramente dependendo do fato de os recursos intermediados residirem em pods do Horizon (com base na tecnologia do Horizon Connection Server) ou em Horizon Cloud pods 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 Universal Broker é um serviço de nuvem multiempresa executado na nuvem 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 Universal Broker.
• O cliente do Universal Broker é executado no Horizon Cloud Connector para cada um dos pods do Horizon conectados à nuvem. A partir da versão 1.5 desse conector, o cliente Universal Broker faz parte desse conector e é instalado automaticamente quando você emparelha o Horizon Cloud Connector com o 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 plug-in do Universal Broker no Servidor de Conexão.

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

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

1. No Horizon Client, o usuário final solicita uma área de trabalho virtual conectando-se ao serviço Universal Broker por meio do FQDN de intermediação. O serviço usa o protocolo XML-API para autenticar o usuário 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 de Universal Broker envia uma mensagem ao cliente Universal Broker, que é executado no Horizon Cloud Connector emparelhado com o Pod 1.
3. O cliente 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 Universal Broker retorna uma resposta para Horizon Client que inclui o FQDN exclusivo do Pod 1 (normalmente o FQDN do balanceador de carga do Pod 1). 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 usuário 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 Universal Broker, consulte Pods do Horizon: requisitos de DNS, portas e protocolo para Universal Broker.

Arquitetura do 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 Universal Broker é um serviço de nuvem multiempresa executado na nuvem 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 Universal Broker.
• O cliente Universal Broker é executado em cada pod Horizon Cloud participante do Microsoft Azure.

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

1. No Horizon Client, o usuário final solicita um recurso virtual conectando-se ao serviço Universal Broker por meio do FQDN de intermediação. O serviço usa o protocolo XML-API para autenticar o usuário 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 de Universal Broker envia uma mensagem para o cliente Universal Broker em execução no 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 Universal Broker retorna uma resposta para Horizon Client que inclui o FQDN exclusivo do Pod 1 (normalmente o FQDN do balanceador de carga Microsoft Azure do Pod 1). 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 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 usuário 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 Universal Broker, consulte a seção "Portas e protocolos exigidos pelo Universal Broker" em Requisitos de portas e protocolos para um pod Horizon Cloud.

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

Esta página de documentação algumas das considerações de recursos relacionadas a Universal Broker e 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 uma atribuição que consiste em áreas de trabalho que abrangem vários pods Horizon Cloud. No entanto, não é possível 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 Universal Broker. Consulte O que há de novo no seu ambiente de tenant após a transição para o 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 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 oferece suporte apenas a 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 Client para Chrome

Os usuários finais podem fazer solicitações de recursos para o serviço do Universal Broker executando o Horizon Web Client em um navegador da Web compatível ou executando o Horizon Client para Chrome 5.4 ou versões posteriores. Se o serviço Universal Broker redirecionar a solicitação para uma instância 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étodo de Autenticação

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

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

Além disso, revise a seção a seguir que descreve a experiência do usuário final ao usar 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.

• Apenas pods do Horizon

  Há suporte para autenticação RADIUS e RSA SecurID.

• Horizon Cloud somente em implantações do 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 autenticação RSA SecurID e RADIUS. Caso contrário, apenas RADIUS tipo terá suporte.

• Combinação de pods do Horizon e Horizon Cloud em implantações do Microsoft Azure

  Em uma frota combinada, os tipos de autenticação compatíveis dependem do fato de seus Horizon Cloud em implantações do Microsoft Azure atenderem às condições para ter a opção de RSA SecurID configurada neles:

  • Se seus Horizon Cloud em implantações do Microsoft Azure não atenderem a essas condições, apenas a autenticação RADIUS será compatível.
  • Se seus Horizon Cloud em implantações do 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 de RSA SecurID e as opções de 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 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.
• Ao usar o fluxo de autenticação de gateway de um pod, os usuários finais serão solicitados a inserir suas credenciais 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 Access e configure a autenticação de dois fatores no 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 Omnissa Access)
• Fazer logon como 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 Horizon Cloud Versões. 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.