Use as seguintes informações e os subtópicos vinculados durante a preparação e o uso do Horizon Cloud. Consulte sempre essas informações no decorrer da sua jornada de uso do Horizon Cloud.

Pré-requisitos de configuração, Downloads de software, Persistência das configurações do usuário, Documentação do produto e recursos úteis adicionais

Pré-requisitos de configuração
Para implantações do Microsoft Azure, revise os pré-requisitos de configuração antes de iniciar a implantação.

Nas conexões com os pods do Horizon, revise os pré-requisitos de configuração antes de começar. Consulte os seguintes documentos:

Downloads de software
Revise os downloads dos softwares que você pode querer para o seu ambiente do My VMware ®. Embora esses downloads possam ser opcionais antes de você começar sua implantação específica, dependendo do cenário do seu caso de uso, convém revê-los antes da implantação. Consulte a página de download do VMware Horizon Cloud Service e navegue até o link de downloads referente a esta versão específica de outubro de 2020. Na mesma página, você verá a linha do Horizon Cloud Connector e poderá clicar em Ir para Downloads para obter as versões mais recentes tanto do Horizon Cloud Connector quanto do instalador do plug-in VMware Universal Broker.
Persistência das configurações do usuário
Para todas as implantações do Microsoft Azure, você pode fornecer persistência de perfis de usuário usando o VMware Dynamic Environment Manager™ com redirecionamento de pastas. Você pode baixar o software Dynamic Environment Manager, que é compatível para uso com esta versão da Página de download do VMware Horizon Cloud Service e acessar o link de downloads para esta versão específica.
Documentação do produto e recursos úteis adicionais

Para acessar a documentação do produto para os diversos modelos de implantação do Horizon Cloud, consulte a página inicial do VMware Horizon Cloud Service.

Visite o site da comunidade para obter dicas úteis e fazer quaisquer perguntas. Há também artigos técnicos disponíveis na seção Recursos da página do produto Horizon Cloud.

Fatos úteis que você precisa saber antes de usar o Horizon Cloud

Antes de fazer qualquer tipo de implantação
  • Quando seu ambiente do Horizon Cloud não está integrado ao seu ambiente do Workspace ONE, a autenticação de login no console administrativo com base na nuvem e na Web depende das credenciais da conta do My VMware. Se o sistema de conta do My VMware estiver passando por uma falha do sistema e não for possível obter as solicitações de autenticação, você não poderá fazer logon no console durante esse período de tempo. Se você encontrar problemas para fazer login na primeira página de login do console, consulte a página de Status do Sistema do Horizon Cloud em https://status.horizon.vmware.com para ver o status mais recente do sistema. Nessa página, você também pode assinar para receber atualizações.
  • Ao implantar um pod usando o assistente do implantador de pod do console e conectar um pod do Horizon usando o Horizon Cloud Connector, os nomes DNS específicos devem ser acessíveis, e as portas e os protocolos específicos devem ser permitidos. Consulte Requisitos de DNS, portas e protocolos ao usar o Horizon Cloud Connector e um pod do Horizon, Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure e Requisitos de portas e protocolos para um pod do Horizon Cloud no manifesto da versão de setembro de 2019 ou posteriores para os requisitos de conectividade.
  • Cada um dos pods emparelhados com a camada de controle do Horizon Cloud e associado à mesma conta de cliente deve ter uma linha de visão para os domínios do Active Directory conectados a esses pods e ter confiança unidirecional ou bidirecional configurada com essa linha de visão. Por exemplo, quando você tem três pods em que um pod está no Microsoft Azure, um pod está no local e um pod no VMware Cloud on AWS, cada um desses pods deve ter linha de visão e confiança unidirecional ou bidirecional configuradas para o mesmo conjunto de domínios do Active Directory.
Antes de fazer implantações do Microsoft Azure
  • Assinaturas e número de pods: lembre-se do número de pods que você implanta em uma única assinatura do Microsoft Azure, principalmente se pretende colocar 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 muitos 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 servidores 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 podem, e muitas vezes preferem, essa abordagem porque 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.
  • O acesso de saída à Internet é necessário na Rede Virtual (VNet) do Microsoft Azure que está conectada à VM de jump box temporária do nó e à VM do gerenciador de pod (ou VMs no plural para o caso em que a alta disponibilidade está habilitada no pod). Há suporte para a autenticação com base em proxy nesta versão. Você deve fornecer os detalhes de proxy no assistente de implantação de pod. Para a implantação de pods, nomes DNS específicos devem ser acessíveis e portas e protocolos específicos devem ser permitidos. Consulte Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure para os requisitos de conectividade.
  • Dimensionamento da sub-rede: a expansão do tamanho das sub-redes do pod após a implantação dele não é suportada no momento. Como resultado, para ambientes de produção, você deve usar tamanhos de sub-rede que sejam grandes o suficiente para acomodar os seguintes requisitos:
    • Sub-rede de gerenciamento: ao implantar um pod, a partir de março de 2019, é necessário que a sub-rede de gerenciamento do pod tenha no mínimo o CIDR /27. Nas versões anteriores, era permitido um mínimo de CIDR inferior de /28. Essa alteração foi feita para reduzir a ocorrência de problemas que podem acontecer durante atualizações do pod devido à falta de endereços IP disponíveis na sub-rede. Um CIDR de /27 fornece para 32 endereços IP.
    • Sub-rede da VM (principal): use um CIDR em um intervalo grande o suficiente para acomodar a conexão de VMs com suas áreas de trabalho VDI antecipadas, as imagens RDS e todas as VMs nos farms RDS do pod. As VMs do Gerenciador de pods e as VMs do Unified Access Gateway também precisam de alguns endereços IP dessa sub-rede (12 endereços no total para acomodar a atualização azul-verde de um pod habilitado para HA com ambos os tipos de gateways). Em geral, o intervalo de /24 a /21 atenderia a casos de uso típicos. Nota: às vezes, a sub-rede da VM é chamada de sub-rede da área de trabalho ou do tenant.
    • A partir do lançamento de serviço de julho de 2020 e o manifesto de pod 2298.0, um novo recurso permite o uso de sub-redes adicionais de tenant para seus áreas de trabalho VDI e VMs de farms RDS. Essas sub-redes adicionais podem estar na mesma VNet que o pod ou em VNets emparelhadas. Para um pod no manifesto 2298.0 ou posterior, você pode editar a configuração desse pod para incluir essas sub-redes adicionais. Em seguida, você pode especificar o uso dessas sub-redes adicionais de tenant nas definições dos seus farms e atribuições de área de trabalho VDI, em vez fazer com que elas usem a sub-rede de VMs primárias. O uso dessas sub-redes secundárias para suas VMs de farm e VMs de áreas de trabalho VDI permite uma administração simplificada, pois você pode especificar quais farms e atribuições de áreas de trabalho VDI estão em qual VNet e sub-rede de tenants.
  • Para usar o recurso para implantar o gateway externo na sua própria VNet, as VNets devem estar emparelhadas. Como resultado, você deve criar as sub-redes manualmente antes de executar o assistente de implantação. Para a VNet do gateway externo, sua sub-rede de gerenciamento e sub-rede de back-end devem seguir o mesmo nível de CIDR/27.
Antes de conectar pods por meio do Horizon Cloud Connector
  • Se a sua conta de tenant do Horizon Cloud foi criada a partir de 17 de março de 2020 em uma destas regiões: US-2, Europe-2, Australia-2 (antes conhecidas como PROD1_NORTHCENTRALUS2_CP1, PROD1_NORTHEUROPE_CP1, PROD1_AUSTRALIAEAST_CP1), você deve usar o Horizon Cloud Connector versão 1.6 ou mais recente para conectar esses pods ao Horizon Cloud. A data em seu e-mail de Boas-vindas ao Horizon Cloud Service é a data a ser usada para determinar se sua conta de tenant foi criada após 17 de março de 2020. O e-mail também informa a região na qual sua conta foi criada. As versões anteriores do Cloud Connector terão problemas de compatibilidade quando usadas com contas de tenant criadas em ou após 17 de março de 2020 nessas regiões.
  • O acesso à Internet de saída é necessário para que o Horizon Cloud Connector se comunique com o plano de nuvem do serviço, especialmente para receber os detalhes de licenciamento. Nomes DNS específicos devem ser acessíveis e portas e protocolos específicos devem ser permitidos. Consulte Requisitos de DNS, portas e protocolos ao usar o Horizon Cloud Connector e um pod do Horizon para os requisitos de conectividade.
  • Antes de conectar um segundo pod Horizon ao Horizon Cloud, você deve fazer login no console administrativo do Horizon Cloud e concluir o processo de registro de domínio do Active Directory depois de conectar seu primeiro pod do Horizon por meio do processo de integração do Horizon Cloud Connector. Quando você emparelha vários pods do Horizon com o Horizon Cloud antes de concluir o registro de domínio do Active Directory, podem ocorrer resultados inesperados ao fazer login no console para tentar o processo de registro de domínio.
  • Devido a um problema conhecido, quando você estiver usando um domínio local do Active Directory para atender a um pod no VMware Cloud on AWS, poderão ocorrer tempos de acesso lentos devido à latência da rede ou ao congestionamento da rede entre esse domínio do Active Directory local e o pod no VMware Cloud on AWS, o que resulta em tempo limite atingido em chamadas para o domínio. Os sintomas dessa latência normalmente incluem a falha da tela de login do Active Directory ao concluir o login antes de o tempo limite ser atingido. Se você tiver esses sintomas, configurar um controlador de domínio gravável em cada centro de dados definido por software (SDDC) na nuvem poderá ajudar.