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. Após a implantação do pod no Microsoft Azure, use o console administrativo, chamado Console administrativo do Horizon Cloud ou console, para criar imagens mestras, farms e áreas de trabalho VDI, atribuir o uso de áreas de trabalho e aplicativos aos seus usuários e realizar outras tarefas administrativas. A partir de um pod localizado no Microsoft Azure, seus usuários finais podem acessar com segurança as áreas de trabalho e aplicativos em qualquer dispositivo. Você pode escolher onde as áreas de trabalho e aplicativos residirão, com base na localização do seu pod implantado.

Para uma introdução geral ao Horizon Cloud, consulte Introdução ao Horizon Cloud e à integração de pods para que se tornem pods conectados à nuvem. Para o fluxo de trabalho sugerido de atividades para um pod no Microsoft Azure, consulte Fluxo de trabalho de alto nível para quando for implantar seu primeiro pod conectado à nuvem do Horizon Cloud e usar o implantador de pod para implantar um pod no Microsoft Azure.

Pod do Horizon Cloud implantado no Microsoft Azure

Conecte a sua assinatura do Microsoft Azure ao Horizon Cloud para gerenciar e oferecer áreas de trabalho VDI e aplicativos e áreas de trabalho fornecidas por RDSH. A configuração do ambiente envolve a implantação automatizada do pod na capacidade do Microsoft Azure.

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 Antes da implantação de pod, crie as sub-redes necessárias do pod do Horizon Cloud na VNet no Microsoft Azure e 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 My VMware, é mais semelhante a um locatário. 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 a instância de gerente do pod (várias VMs para um pod que está ativado para alta disponibilidade)
  • 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 imagens compatíveis com RDSH mestre
  • VMs para as imagens da área de trabalho VDI mestres
  • VMs para as imagens (publicadas) atribuíveis que foram criadas com base em imagens mestre
  • 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 imagens mestre.
  • 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 está ativado para alta disponibilidade e tem os tipos externos e internos de configurações do Unified Access Gateway. Neste diagrama, RG significa grupo de recursos. As instâncias do Unified Access Gateway na configuração externa do Unified Access Gateway têm NICs na rede desmilitarizada (zona desmilitarizada). Quando seu pod tiver a configuração externa de Unified Access Gateway, seus usuários finais localizados na Internet, fora de sua rede corporativa, poderão acessar os aplicativos e áreas de trabalho virtuais provisionadas pelo pod deles por meio desta configuração. Quando o pod tem a configuração interna do Unified Access Gateway, seus usuários finais localizados em sua intranet, dentro de sua rede corporativa, podem fazer conexões confiáveis com os aplicativos e áreas de trabalho virtuais provisionados pelo pod deles por meio deste gateway. O assistente de implantação de pod fornece a opção de implantar o pod com as duas 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 optar por não ativar a opção de alta disponibilidade no assistente de implantação e editar o pod implantado mais tarde para ativar a alta disponibilidade nele. Um novo pod sempre é implantado com o banco de dados Postgres do Azure e com o balanceador de carga de pod, mesmo quando você não ativa a opção de alta disponibilidade no assistente. Ter esses ativos disponíveis permite a fácil habilitação de alta disponibilidade em um pod já implantado. A segunda VM do gerenciador de pod é implantada apenas quando a alta disponibilidade está ativada no pod.

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 da arquitetura dos grupos de recursos, das VMs e das sub-redes de um pod que tem a alta disponibilidade ativada e ambos os tipos de configurações do Unified Access Gateway

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


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ê deveria implantar um único pod por assinatura, acumular essas assinaturas em uma única conta "mestre" e evitar as chances de atingir os limites do Microsoft Azure impostos em uma única assinatura.

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

Conforme descrito em Atualizando seu pod do Horizon Cloud, a VMware atualiza os componentes de software do Horizon Cloud periodicamente para incluir novos recursos e correções de erros. O ambiente de gerenciamento de nuvem é atualizado toda semana e os componentes de software do pod são normalmente atualizados todo trimestre. A página de documentação de Horizon Cloud Service fornece acesso às Notas da versão com controle de versão, nas quais as versões correspondem a essas versões trimestrais, como a versão 2.1 para a versão de setembro de 2019.

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 de fluxos de trabalho nesta versão que agora são diferentes para pods na última versão do manifesto, consulte o documento Notas da versão mais recente em https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/index.html.

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 Windows? Use este artigo para saber mais sobre a área de trabalho virtual do Microsoft Windows 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 Windows, é fornecido suporte ao uso das várias sessões do Windows 10 Enterprise da Microsoft e do Microsoft Windows 7 Enterprise com seus pods implantados no Microsoft Azure.