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