Você deve ter uma assinatura da capacidade na nuvem no Microsoft Azure e depois trazer essas informações de assinatura para emparelhar essa capacidade de nuvem com o Horizon Cloud. Você usa o Horizon Universal Console para manter a implantação nessa assinatura e criar golden images. Por meio dessas imagens, você provisiona aplicativos remotos e áreas de trabalho de sessão única e de várias sessões para que seus usuários finais acessem com segurança por meio de qualquer dispositivo.

A implantação cria o que é chamado de pod do Horizon Cloud. Os aplicativos remotos e as áreas de trabalho de sessão única e de várias sessões são provisionados por meio desse pod usando a capacidade da sua assinatura do Microsoft Azure. Você escolhe onde as áreas de trabalho e os aplicativos residem, com base na localização do pod implantado.

Para obter uma introdução geral ao Horizon Cloud, consulte Introdução ao serviço. Para o fluxo de trabalho sugerido de atividades para a sua primeira implantação de pod do Horizon Cloud, consulte Pod do Horizon Cloud, Integração do primeiro pod, Fluxo de trabalho de alto nível.

O pod implantado do Horizon Cloud

O pod implantado por Horizon Cloud no Microsoft Azure possui um local regional físico em uma nuvem do Microsoft Azure. No assistente de implantação do pod, selecione onde o pod será posicionado, de acordo com as regiões disponíveis para sua assinatura específica do Microsoft Azure. Selecione também uma rede virtual existente (VNet) que o pod utilizará em sua região selecionada. Você tem a opção de implantar uma configuração de gateway externo com o pod, com os recursos do gateway externo implantados na mesma VNet que o pod ou em uma VNet separada emparelhada com a VNet do pod.
Observação: Você pré-configura seu ambiente do Microsoft Azure com a VNet do pod (e com a VNet do gateway externo se estiver usando essa opção de configuração). Você pode criar com antecedência essas sub-redes que o pod e a configuração do gateway externo exigem, ou permitir que o implantador do pod crie as sub-redes durante a implantação. Se você não criar as sub-redes com antecedência, o implantador do pod as criará à medida que implantar as VMs e recursos necessários no ambiente. Se você escolher que o implantador do pod crie as sub-redes necessárias, precisará saber quais espaços de endereço IP você deseja usar para elas antes de iniciar o assistente de implantação. Se você optar por criar as sub-redes com antecedência, deverá garantir que elas atendam a determinados requisitos antes de iniciar o processo de implantação. Para obter detalhes sobre os requisitos ao criar as sub-redes com antecedência, consulte Tenants de primeira geração: antes da implantação de pod, crie as sub-redes necessárias do pod do Horizon Cloud na VNet no Microsoft Azure e Tenants de primeira geração: ao usar sub-redes existentes para um pod do Horizon Cloud no Microsoft Azure.
Importante: Esse pod no Microsoft Azure não é um tenant. Esse pod não adere ao exato mesmo conjunto de características que define um tenant e que seria de esperar de um tenant. Por exemplo, mesmo se um tenant tivesse um mapeamento de um para um para um domínio do Active Directory e fosse isolado dos outros tenants, todos os pods do Horizon Cloud no Microsoft Azure que são implantados usando o mesmo registro de conta de cliente do Horizon Cloud precisarão ser capazes de acessar os mesmos servidores do Active Directory e a configuração de DNS precisará resolver todos esses domínios do Active Directory.

Para ter vários locatários, você pode configurar diversos registros de conta de cliente do Horizon Cloud. O registro de conta de cliente do Horizon Cloud, que é criado quando você se registra na VMware para usar o Horizon Cloud Service e está associado às suas credenciais do VMware Customer Connect, é mais semelhante a um tenant. Um registro de conta de cliente do Horizon Cloud é isolado de outros registros de conta de cliente do Horizon Cloud. Um único registro de conta de cliente é mapeado para vários pods, e quando alguém utilizar qualquer uma das credenciais de conta associadas a esse registro de conta de cliente para fazer login no console administrativo, o console refletirá todos os pods que são mapeados para esse registro de conta de cliente.

O processo de implementação do pod cria automaticamente um conjunto de grupos de recursos em sua capacidade do Microsoft Azure. Grupos de recursos são utilizados para organizar os ativos que o ambiente precisa e cria, como:

  • VMs para as instâncias do gerenciador de pods.
  • VMs para as instâncias do Unified Access Gateway e seus balanceadores de carga
  • VM para a VM do conector na configuração de gateway externo quando você implanta essa configuração em uma VNet separada da VNet do pod
  • VMs para as golden images compatíveis com RDSH
  • VMs para as golden images de área de trabalho VDI
  • VMs para as imagens atribuíveis (publicadas, seladas) criadas com base nas golden images
  • VMs para os farms RDSH que fornecem as áreas de trabalho e os aplicativos RDSH
  • VMs para as áreas de trabalho VDI
  • Ativos adicionais exigidos pelas VMs e pelo ambiente para operações com suporte, como interfaces de rede, endereços IP, discos, repositórios de chaves, recurso do servidor do Banco de Dados do Azure para PostgreSQL e vários itens desses tipos. O processo de implantação do pod também pode criar as sub-redes virtuais necessárias, usando os valores especificados no assistente de implantação.

Todos os grupos de recursos criados pelo Horizon Cloud em seu ambiente do Microsoft Azure são nomeados utilizando o prefixo vmw-hcs.

Cuidado: Não modifique ou exclua manualmente os recursos relacionados ao pod usando o portal do Microsoft Azure, exceto para:
  • Criação manual de golden images.
  • Modificar os grupos de segurança de rede da atribuição de área de trabalho VDI e de farm, conforme necessário para configurar portas para sua situação de negócios.

O Horizon Cloud configura automaticamente os recursos relacionados ao pod para garantir que o pod opere como projetado. Nunca altere manualmente as configurações dos recursos que o Horizon Cloud cria e implanta automaticamente durante fluxos de trabalho, nomes ou endereços IP atribuídos etc. Nunca desligue manualmente as instâncias de VM nem as exclua diretamente usando o portal do Microsoft Azure. Nunca exclua manualmente a VM do gerenciador ou as VMs do Unified Access Gateway. Nunca exclua manualmente as NICs dos grupos de recursos, especialmente dos grupos de recursos do Unified Access Gateway. Se você alterar as configurações geradas, desligar manualmente as VMs ou excluir manualmente as VMs ou NICs que foram criadas pelo implantador do pod, poderão ocorrer resultados imprevisíveis. Além disso, as operações de pod, as atualizações de pod e as operações de exclusão de pod poderão falhar.

O diagrama a seguir ilustra um pod implantado que tem os tipos externos e internos de configurações de gateway e onde o gateway externo reside na mesma VNet que o pod em si. Neste diagrama, RG significa grupo de recursos.

As instâncias do Unified Access Gateway na configuração de gateway externo têm NICs na rede desmilitarizada (zona desmilitarizada). Com uma configuração de gateway externo, você pode ter seus usuários finais localizados na Internet, fora de sua rede corporativa, acessando os aplicativos e áreas de trabalho virtuais provisionadas pelo pod deles por meio dessa configuração. Com uma configuração de gateway interno, você pode ter seus usuários finais na sua intranet, dentro de sua rede corporativa, fazendo conexões confiáveis com os aplicativos e áreas de trabalho virtuais provisionados pelo pod deles por meio desse gateway.

O implantador do pod fornece a opção de implantar o pod com ambas as configurações antecipadamente. Como alternativa, você pode implantar o pod com apenas uma configuração de gateway ou sem nenhuma e editar o pod implantado para adicionar a configuração de gateway não escolhida mais tarde. Você também pode implantar o pod inicialmente sem nenhum tipo e adicionar posteriormente.

O sistema implanta o pod com alta disponibilidade, tendo duas VMs de gerenciador de pods por padrão.

Figura 1. Ilustração da arquitetura do Horizon Cloud Pod para um pod com alta disponibilidade ativado e definido com as configurações externa e interna do Unified Access Gateway

Ilustração de arquitetura dos grupos de recursos, VMs e sub-redes do pod para um pod que tem os dois tipos de configurações do Unified Access Gateway, com o gateway externo residindo na mesma VNet que o pod.

O diagrama a seguir ilustra os recursos implantados quando você escolhe a opção para que o gateway externo resida na própria VNet, separado da VNet do pod. As duas VNets devem ser emparelhadas. Esse diagrama também se aplica quando você escolhe a opção de implantar os recursos do gateway externo usando uma assinatura do Microsoft Azure diferente daquela usada para o pod. Como as VNets não podem cruzar assinaturas, escolher implantar o gateway externo em sua própria assinatura é um subconjunto de escolher que o gateway externo resida na própria VNet.

Dica: A implantação da configuração do gateway externo em sua própria VNet oferece a capacidade de implantar esses pods do Horizon Cloud em ambientes complexos do Microsoft Azure que usam Topologia de Rede hub-spoke no Microsoft Azure.
Figura 2. Ilustração dos elementos de arquitetura do gateway externo quando o gateway externo é implantado na própria VNet, separado da do pod

Ilustração de arquitetura dos elementos de um gateway externo quando o gateway externo é implantado em sua própria VNet. Nesse caso, há uma VM do Conector com uma NIC para a sub-rede de gerenciamento da VNet, juntamente com os elementos padrão do próprio gateway externo.

Assinaturas e número de pods

Lembre-se do número de pods que você implanta em uma única assinatura, especialmente se você pretende ter cada pod em execução em grande escala. Apesar de ser possível implantar vários pods em uma única assinatura do Microsoft Azure, seja tudo em uma região ou espalhado por várias regiões, o Microsoft Azure impõe certos limites dentro de uma assinatura única. Devido a esses limites do Microsoft Azure, a implantação de um grande número de pods em uma única assinatura aumenta a probabilidade de atingir esses limites. Inúmeras variáveis, e combinações dessas variáveis, estão envolvidas em atingir esses limites, como o número de pods, o número de farms e atribuições em cada pod, o número de VMs RDSH de farm em cada pod, o número de áreas de trabalho em cada atribuição etc.

Se você pretende ter pods em execução em grande escala, considere adotar a abordagem de ter várias assinaturas com essas várias assinaturas em uma conta do Microsoft Azure. Os clientes do Microsoft Azure usam essa abordagem, e muitas vezes a preferem, pois ela fornece alguns benefícios para um gerenciamento contínuo das assinaturas. Com essa abordagem, você implanta somente um pod por assinatura, reúne essas assinaturas em apenas uma conta principal e evita as chances de atingir os limites do Microsoft Azure impostos a uma única assinatura.

Quando você tiver pods existentes que foram implantados antes desta versão atual do Horizon Cloud

Conforme descrito em Pods do Horizon Cloud: manutenção e atualizações, a VMware atualiza os componentes de software do Horizon Cloud periodicamente para incluir novos recursos e correções de erros. O ambiente de gerenciamento na nuvem é atualizado toda semana, e os binários que são a base dos componentes de software do pod costumam ser atualizados a cada trimestre, aproximadamente. A página de documentação do Horizon Cloud Service fornece acesso à página Notas da Versão, que inclui as listas de Novidades referentes a cada ponto de tempo do calendário em que foram lançados os recursos importantes visíveis aos clientes.

Quando você implanta um novo pod, esse pod é sempre criado na versão de manifesto mais recente do ambiente de serviço atual em produção. Por exemplo, se você tivesse criado um novo pod em agosto de 2019, esse pod seria implantado com componentes de software que eram atuais para o Horizon Cloud nessa data. Dependendo de quanto tempo você está usando o seu ambiente do Horizon Cloud, em uma determinada data do calendário, o seu ambiente geral do Horizon Cloud pode incluir alguns pods que estão na última versão lançada e alguns que estão em uma versão anterior que ainda não foi atualizada para o manifesto mais recente.

Importante: Em geral, o conteúdo neste Guia de Administração descreve recursos, fluxos de trabalho e comportamentos que estão disponíveis na versão em produção atual e que são aplicáveis quando seu pod está na última versão do manifesto do pod que foi disponibilizada nesta versão atual. O console com base na nuvem no qual você executa as tarefas administrativas e de gerenciamento é dinâmico. A interface baseada na Web do console normalmente exibirá mensagens quando uma área ou ação na interface do usuário exigir a atualização do pod para usar esse recurso. Para um pod que existia antes desta versão, alguns fluxos de trabalho podem exigir etapas diferentes das descritas neste Guia de Administração. Para obter uma lista dos fluxos de trabalho desta versão que agora são diferentes em relação aos pods da última versão do manifesto, se houver, consulte o tópico da documentação Para clientes atuais com pods conectados à nuvem existentes: sobre as versões do Horizon Cloud e as seções incluídas.

Referências e terminologia do Microsoft Azure

A documentação do produto VMware Horizon Cloud Service on Microsoft Azure usa a terminologia do Microsoft Azure aplicável. conforme apropriado nas descrições e nas etapas de tarefas dos fluxos de trabalho do VMware Horizon Cloud Service on Microsoft Azure. Se você não conhecer a terminologia do Microsoft Azure, use as seguintes referências aplicáveis na documentação do produto Microsoft Azure para saber mais.

Observação: Todas as letras maiúsculas e minúsculas e ortografia nas citações abaixo seguem as mesmas letras maiúsculas e minúsculas e ortografia encontradas no artigos vinculados na documentação do Microsoft Azure em si.
Referências úteis do Microsoft Azure Descrição
Glossário do Microsoft Azure: um dicionário de terminologia de nuvem na plataforma do Azure Use esse glossário para saber o significado dos termos usados no contexto de nuvem do Microsoft Azure, como balanceador de carga, região, grupo de recursos, assinatura, máquina virtual e rede virtual (vnet).
Observação: O glossário do Microsoft Azure não inclui o termo entidade de serviço, pois a entidade de serviço é um recurso criado automaticamente no Microsoft Azure quando um registro de aplicativo é criado no Microsoft Azure. O motivo de se criar um registro de aplicativo na sua assinatura do Microsoft Azure é porque essa é a forma de você autorizar Horizon Cloud como um aplicativo usa sua capacidade do Microsoft Azure. O registro do aplicativo e sua entidade de serviço complementar permitem que o Horizon Cloud Cloud Service atue como um aplicativo para acessar os recursos na sua assinatura do Microsoft Azure. Use a próxima referência abaixo para saber mais sobre os aplicativos e as entidades de serviço que podem acessar os recursos no Microsoft Azure.
Usar o portal para criar um aplicativo e uma entidade de serviço do Azure Active Directory que possa acessar recursos

Use este artigo para saber mais sobre o relacionamento entre um aplicativo e uma entidade de serviço em uma nuvem do Microsoft Azure.

Visão geral do Azure Resource Manager

Use este artigo para saber mais sobre os relacionamentos entre recursos, grupos de recursos e o Resource Manager no Microsoft Azure.

Rede Virtual do Azure

Use este artigo para saber mais sobre o serviço Rede Virtual (VNet) do Azure no Microsoft Azure. Consulte também Perguntas frequentes sobre a rede virtual do Azure (FAQ).

Emparelhamento de rede virtual

Use este artigo para saber mais sobre emparelhamento de rede virtual no Microsoft Azure.

Topologia de rede hub-spoke no Azure

Use este artigo para saber mais sobre topologia de rede hub-spoke no Microsoft Azure.

Visão geral do Microsoft Azure ExpressRoute

Use este artigo para saber mais sobre o Microsoft Azure ExpressRoute e como você pode usá-lo para estabelecer conexões entre suas redes locais, o Microsoft Azure e seus pods do Horizon Cloud.

Sobre o Gateway de VPN

Planejando e projetando para o Gateway de VPN

Criar uma conexão de site a site no portal do Azure

Use os seguintes artigos para saber mais sobre como configurar VPNs no Microsoft Azure.

O que é o Balanceador de Carga do Azure?

Use este artigo para saber mais sobre os balanceadores de carga do Azure implantados para um pod: o balanceador de carga das VMs de gerenciador de pods e os balanceadores de carga para as configurações do gateway.

O que é o Banco de Dados do Azure para PostgreSQL? Use este artigo para saber mais sobre o serviço do Banco de Dados do Azure para PostgreSQL.
O que é a área de trabalho virtual do Azure? Use este artigo para saber mais sobre a área de trabalho virtual do Microsoft Azure e como ela está relacionada às várias sessões do Windows 10 Enterprise da Microsoft e ao Microsoft Windows 7 Enterprise com atualizações de segurança estendidas. Quando a sua conta de tenant do Horizon Cloud tem a configuração para o Horizon Cloud Service on Microsoft Azure estendendo a área de trabalho virtual do Microsoft Azure, é fornecido suporte ao uso das várias sessões do Microsoft Windows 10 Enterprise e do Microsoft Windows 7 Enterprise com seus pods implantados no Microsoft Azure.