Antes de executar o assistente de implantação do pod de primeira geração, certifique-se de que o seu ambiente atenda a estes pré-requisitos. Você deve ter os seguintes itens para poder fornecer os valores solicitados no assistente de implantação de pod e continuar com o assistente.

Importante: Essas informações aplicam-se apenas quando você tem acesso a um ambiente de tenant de primeira geração na camada de controle de primeira geração. Conforme descrito em KB-92424, a camada de controle de primeira geração atingiu o fim da disponibilidade (EOA). Consulte esse artigo para obter detalhes.
Importante: Antes de iniciar o assistente de implantação de pod e começar a implantá-lo, além dos requisitos abaixo, você deve estar ciente dos seguintes pontos-chave:
  • Uma implantação de pod bem-sucedida requer que nenhuma das políticas do Microsoft Azure que você ou sua equipe de TI tenha no ambiente do Microsoft Azure bloqueie, negue ou restrinja a criação dos componentes do pod. Além disso, você deve garantir que as definições de política interna das políticas do Microsoft Azure não bloqueiem, neguem nem restrinjam a criação dos componentes do pod. Como dois exemplos de itens que devem ser permitidos, você e sua equipe de TI devem verificar se nenhuma das suas políticas do Microsoft Azure bloqueia, nega ou restringe a criação de componentes na conta de armazenamento do Azure e deve verificar se as suas políticas do Microsoft Azure permitem resourceType de Microsoft.MarketplaceOrdering/*. O processo de implantação do pod depende da aceitação de ofertas do Azure Marketplace do vmware-inc publisherID da VMware. Para obter informações sobre políticas do Azure, consulte a documentação Política do Azure. Para obter informações sobre como o serviço usa o tipo de recurso Microsoft.MarketplaceOrdering/*, consulte Quando sua organização de TI ou segurança tiver restrições sobre o uso de ofertas do Azure Marketplace ou pedidos do Marketplace.
  • O implantador do pod requer que sua conta de armazenamento do Azure permita que o implantador crie o tipo de conta StorageV2 do Azure no grupo de recursos do pod na assinatura. Essa conta de armazenamento é usada para os recursos do App Volumes do pod. Durante o processo de implantação do pod, certifique-se de que suas Políticas do Microsoft Azure não restrinjam ou neguem a criação de conteúdo que exija o tipo de conta StorageV2 do Azure.
  • Todos os pods conectados à nuvem devem ter linha de visão para o mesmo conjunto de domínios do Active Directory no momento em que você implantar esses pods.

Pré-requisitos para todas as implantações

  • Quando você adiciona outro pod, pode usar a mesma assinatura que usou para seus pods anteriores ou pode usar uma assinatura diferente, caso isso seja exigido pela sua organização. Se você pretende usar assinaturas diferentes, deverá realizar as etapas descritas no Guia de Implantação para obter o ID de assinatura, o ID do diretório, o ID do aplicativo e a chave do aplicativo. Você deve garantir que a assinatura usada atenda aos requisitos descritos nesse guia, especialmente que a entidade de serviço tenha as permissões de função apropriadas concedidas nos níveis relevantes da sua assinatura. Na página Documentação do Horizon Cloud, você pode navegar on-line até o documento de introdução.
  • Quando o tenant está configurado para usar o Universal Broker para os pods no Microsoft Azure, ao executar o assistente de implantação de pod para adicionar um novo pod, você deve especificar um site. Você pode selecionar um site existente ou especificar um novo.
  • Verifique se você tem uma VNet na região na qual você deseja implantar o pod e se a VNet atende aos requisitos, conforme descrito em Configurar a rede virtual necessária no Microsoft Azure.
    Importante: Nem todas as regiões do Microsoft Azure oferecem suporte a máquinas virtuais ativadas para GPU. Se você quiser usar o pod para áreas de trabalho compatíveis com GPU ou aplicativos remotos, verifique se a região do Microsoft Azure selecionada para o pod fornece os tipos de VM das séries NV, NVv4 e NCv2 que você deseja usar e que têm suporte nesta versão do Horizon Cloud. Consulte a documentação da Microsoft em https://azure.microsoft.com/pt-br/regions/services/ para obter detalhes.
  • Verifique se sua VNet está configurada para apontar para um DNS que possa resolver endereços externos. O implantador do pod deve poder acessar endereços externos na camada de controle do Horizon Cloud com segurança para baixar o software do pod para o seu ambiente do Microsoft Azure.
  • Verifique se os requisitos de protocolos, portas e DNS do implantador do pod foram cumpridos, conforme descrito em Tenants de primeira geração: Implantações do Horizon Cloud on Microsoft Azure: requisitos de resolução de nomes de host e nomes DNS e Tenants de primeira geração: pod do Horizon Cloud: requisitos de portas e protocolos.
  • Se você precisar usar um proxy para acesso de saída à Internet, verifique se que você possui as informações de rede para a sua configuração de proxy e as credenciais de autenticação que necessita, se houver. O processo de implantação do pod exige acesso de saída à Internet.
    Importante: Atualmente, não há suporte para a edição ou atualização das configurações de proxy em um pod depois que o pod é implantado no Microsoft Azure. Além disso, não há suporte para a adição de uma configuração de proxy a um pod implantado sem configurações de proxy.
  • Verifique se você tem as informações para pelo menos um servidor NTP que deseja que as instâncias de gerenciador de pods e as instâncias do Unified Access Gateway sejam usadas para sincronização de horário. O servidor NTP pode ser um servidor NTP público ou seu próprio servidor NTP que configurou para essa finalidade. O servidor NTP especificado deve ser acessível a partir das redes virtuais nas quais você planeja implantar as instâncias do gerenciador de pods e as instâncias do Unified Access Gateway. Quando você planejar usar um servidor NTP usando seu nome de domínio em vez de um endereço IP numérico, certifique-se também de que o DNS configurado para a rede virtual possa resolver o nome do servidor NTP.
    Observação: Usar o mesmo servidor NTP para as instâncias do gerenciador de pods, as instâncias do Unified Access Gateway e seus servidores do Active Directory é uma boa prática. Podem ocorrer distorções de tempo quando essas instâncias usam servidores NTP diferentes. Essas distorções de tempo podem resultar em falhas mais tarde quando o gateway tenta autenticar sessões de usuário final em suas áreas de trabalho e aplicativos.
  • Se você não quiser que o implantador crie automaticamente as sub-redes de que precisa, verifique se as sub-redes necessárias foram criadas com antecedência e se elas existem na VNet. Para conhecer as etapas de criação das sub-redes necessárias 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.
    Cuidado: As sub-redes criadas manualmente na sua VNet com antecedência para a implantação do pod devem permanecer vazias. Não reutilize sub-redes existentes que já tenham itens que estejam usando endereços IP nessas sub-redes. Se um endereço IP já estiver em uso nas sub-redes, problemas como falha na implantação do pod e outros problemas de conflito de IP downstream terão uma alta probabilidade de ocorrer. Não coloque recursos nessas sub-redes nem use qualquer um dos endereços IP. Esse aviso de cuidado inclui pods implantados do Horizon Cloud: Não reutilize sub-redes em que você já tenha um pod implantado.
    Importante: Ao implantar pods adicionais após o primeiro, não reutilize uma sub-rede existente que já está em uso por um pod existente. Não tente compartilhar uma sub-rede que já está em uso por um pod. A seleção de uma sub-rede já em uso por outro pod interromperá as operações para o pod existente e para aquele que você implantar com sua sub-rede.

    A prática recomendada é usar uma VNet separada para cada pod. Essa recomendação decorre da orientação de se manter atento ao número de pods que você implanta em uma única assinatura, descrita em O que saber antes e durante o uso do Horizon Cloud. Para evitar os limites do Microsoft Azure em uma assinatura única, quando você tiver um único pod por assinatura, evite as chances de atingir esses limites. Como o Microsoft Azure exige que cada assinatura tenha sua própria VNet, ao aderir à prática recomendada de ter um único pod por assinatura, você automaticamente adere à prática recomendada de usar uma VNet separada para cada pod.

  • Se o implantador for criar as sub-redes necessárias, certifique-se de conhecer os intervalos de endereços que serão inseridos no assistente para a sub-rede de gerenciamento, a sub-rede de área de trabalho e a sub-rede DMZ. A sub-rede DMZ é necessária quando você quer a configuração externa do Unified Access Gateway. Também garanta que esses intervalos não se sobreponham. Digite os intervalos de endereços usando a notação CIDR (notação de roteamento inter-domínio sem classes). O assistente exibirá um erro se os intervalos de sub-redes digitados estiverem sobrepostos. Para o intervalo de sub-rede de gerenciamento, é necessário um CIDR de pelo menos /27. Para o intervalo de sub-rede DMZ, é necessário um CIDR de pelo menos /28. Se você quiser manter os intervalos de sub-rede de gerenciamento e de DMZ posicionados, poderá especificar um intervalo de sub-redes DMZ semelhante à sub-rede de gerenciamento com um IP especificado. Por exemplo, se a sub-rede de gerenciamento for 192.168.8.0/27, uma sub-rede DMZ correspondente seria 192.168.8.32/27.
    Importante: Os CIDRs que você inserir nos campos do assistente deverão ser definidos para que cada combinação de prefixo e bitmask resulte em um intervalo de endereços IP que tem o prefixo como o endereço IP inicial. O Microsoft Azure exige que o prefixo CIDR seja o início do intervalo. Por exemplo, um CIDR correto de 192.168.182.48/28 resultaria em um intervalo de IP de 192.168.182.48 a 192.168.182.63, e o prefixo seria o mesmo que o endereço IP inicial (192.168.182.48). No entanto, um CIDR incorreto de 192.168.182.60/28 resultaria em um intervalo de IP de 192.168.182.48 a 192.168.182.63, no qual o endereço IP inicial não é o mesmo que o prefixo de 192.168.182.60. Verifique se os CIDRs resultam em intervalos de endereços IP em que o endereço IP inicial corresponda ao prefixo do CIDR.
  • Se o implantador for criar as sub-redes necessárias, verifique se sub-redes com esses intervalos de endereços já não existem na VNet. Nesse cenário, o próprio implantador criará automaticamente as sub-redes usando os intervalos de endereços fornecidos no assistente. Se o assistente detectar que já existem sub-redes com esses intervalos, o assistente exibirá um erro sobre a sobreposição de endereços e não continuará mais. Se sua VNet for emparelhada, garanta também que os espaços de endereços CIDR que você planeja digitar no assistente já estão contidos no espaço de endereço da VNet.

Pré-requisitos para as configurações do Unified Access Gateway

Se você estiver planejando fazer o pod usar uma configuração do Unified Access Gateway, deverá fornecer:

  • O nome de domínio totalmente qualificado (FQDN) que seus usuários finais utilizarão para acessar o serviço. Se estiver planejando usar o mesmo FQDN para as configurações de gateway interno e externo, depois que o pod for implantado, você deverá configurar o tráfego de cliente de usuário final de entrada para rotear para o balanceador de carga do gateway apropriado. O objetivo é configurar o roteamento de modo que o tráfego de cliente da Internet seja encaminhado para o balanceador de carga público do Microsoft Azure do gateway externo, e o tráfego de cliente da intranet seja encaminhado para o balanceador de carga interno do Microsoft Azure do gateway interno. Nesse cenário, em que ambos os gateways terão o mesmo FQDN, configure o DNS dividido (Sistema de nome de domínio dividido) para resolver o endereço do gateway como o gateway externo ou o gateway interno, dependendo da rede de origem da consulta de DNS do cliente do usuário final. Em seguida, o mesmo FQDN usado no cliente do usuário final poderá rotear para o gateway externo quando o cliente estiver na Internet e rotear para o gateway interno quando o cliente estiver na sua rede interna.
    Importante: Este FQDN não pode conter sublinhados. Nesta versão, as conexões com as instâncias do Unified Access Gateway falharão quando o FQDN contiver sublinhados.
  • Um certificado de servidor SSL assinado (no formato PEM) com base no FQDN. Os recursos do Unified Access Gateway exigem SSL para conexões de cliente, conforme descrito na documentação do produto Unified Access Gateway. O certificado deve ser assinado por uma Autoridade de Certificação (CA) confiável. O arquivo PEM único deve conter a cadeia de certificados inteira completa com a chave privada. Por exemplo, o arquivo PEM único deve conter o certificado de servidor SSL, quaisquer certificados de autoridade de certificação intermediários necessários, o certificado da CA raiz e a chave privada. OpenSSL é uma ferramenta que você pode usar para criar o arquivo PEM.
    Importante: Todos os certificados na cadeia de certificados devem ter períodos de tempo válidos. As VMs do Unified Access Gateway exigem que todos os certificados na cadeia, incluindo quaisquer certificados intermediários, tenham períodos de tempo válidos. Se qualquer certificado da cadeia tiver expirado, falhas inesperadas podem ocorrer mais tarde, como o certificado é carregado para a configuração de Unified Access Gateway.
  • Se você estiver implantando com uma configuração externa do Unified Access Gateway, deverá especificar uma sub-rede de DMZ (zona desmilitarizada). Você pode fornecer essa sub-rede DMZ de uma destas maneiras:
    • Criando a sub-rede DMZ com antecedência na VNet. Com esse método, você também precisa criar as sub-redes de gerenciamento e de locatário de área de trabalho com antecedência. Consulte as etapas em 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.
    • Fazendo com que o implantador crie automaticamente a sub-rede DMZ durante a implantação. Com esse método, você deve ter o intervalo de endereços que pretende inserir no assistente para a sub-rede DMZ e verificar se esse intervalo não está sobreposto aos intervalos das sub-redes de gerenciamento e de locatário de área de trabalho. Digite os intervalos de endereços usando a notação CIDR (notação de roteamento inter-domínio sem classes). O assistente exibirá um erro se os intervalos de sub-redes digitados estiverem sobrepostos. Para o intervalo de sub-rede DMZ, é necessário um CIDR de pelo menos /28. Se você quiser manter os intervalos de sub-rede de gerenciamento e de DMZ posicionados, poderá especificar o mesmo intervalo de sub-redes DMZ à sub-rede de gerenciamento com um IP especificado. Por exemplo, se a sub-rede de gerenciamento for 192.168.8.0/27, uma sub-rede DMZ correspondente seria 192.168.8.32/27. Além disso, consulte a observação importante em Pré-requisitos para todas as implantações sobre garantir que o intervalo de endereços IP tenha uma combinação de prefixo e máscara de bits de modo que esse intervalo tenha o prefixo especificado como o endereço IP inicial.
  • Se estiver implantando com uma configuração do Unified Access Gateway externa e não desejar ter um endereço IP público para o balanceador de carga da configuração, deverá especificar um endereço IP que você mapeou nas configurações DNS para o FQDN que os usuários finais usarão para conexões PCoIP nos clientes Horizon deles.

Para obter mais informações sobre as considerações de arquivo PEM exigidas pelo Unified Access Gateway, consulte Tenants de primeira geração: converter um arquivo de certificado no formato PEM necessário para implantações de pod de primeira geração do Horizon Cloud.

Pré-requisitos ao implantar com uma configuração de Unified Access Gateway externa usando a própria VNet ou assinatura separada da VNet ou da assinatura do pod

Observação: A implantação de um gateway externo usando a própria VNet implantará uma VM do conector do gateway. Em Requisitos de portas e protocolos para um pod do Horizon Cloud, a seção que descreve as portas e os protocolos da VM do conector do gateway também inclui uma descrição dessa VM do conector do gateway, que informa que essa VM do conector de gateway tem um nome com uma parte como vmw-hcs-ID, em que ID é a ID do implantador do gateway, e uma parte de node.

Junto com os pré-requisitos acima durante a implantação com uma configuração do Unified Access Gateway, esses pré-requisitos são específicos ao caso de uso da implantação do gateway externo na própria VNet ou assinatura. Usar a assinatura própria é um caso especial de uso da própria VNet, pois a assinatura separada deve ter a própria VNet, pois as VNets têm o escopo de uma assinatura.

Pré-requisitos ao implantar com uma configuração de autenticação de dois fatores

Se você planeja usar o recurso de autenticação de dois fatores, ou usá-lo com um servidor de autenticação de dois fatores local, verifique se você tem as seguintes informações da configuração do seu servidor de autenticação, para que você possa fornecê-lo nos campos apropriados no assistente para Adicionar Pod.

Obtenha as seguintes informações listadas de acordo com o tipo que você possui.

RADIUS

"Se você estiver definindo configurações para um servidor RADIUS primário e auxiliar, obtenha as informações para cada um deles."

  • Endereço IP ou nome DNS do servidor de autenticação
  • O segredo compartilhado que é usado para criptografia e descriptografia em mensagens do protocolo do servidor de autenticação
  • Números de porta de autenticação, normalmente 1812/UDP para RADIUS.
  • Tipo de protocolo de autenticação. Os tipos de autenticação incluem PAP (Password Authentication Protocol, Protocolo de autenticação de senha), CHAP (Challenge Handshake Authentication Protocol, Protocolo de autenticação por desafios de identidade), MSCHAP1, MSCHAP2 (Microsoft Challenge Handshake Authentication Protocol, Protocolo de autenticação por desafios de identidade, versões 1 e 2).
    Observação: Verifique a documentação do seu fornecedor RADIUS para o protocolo de autenticação recomendado e siga o tipo de protocolo indicado. A capacidade do pod de oferecer suporte à autenticação de dois fatores com o RADIUS é fornecida pelas instâncias do Unified Access Gateway, e o Unified Access Gateway é compatível com PAP, CHAP, MSCHAP1 e MSCHAP2. Em geral, o PAP é menos seguro que o MSCHAP2. O PAP também é um protocolo mais simples que o MSCHAP2. Como resultado, embora a maioria dos fornecedores RADIUS seja compatível com o protocolo PAP mais simples, alguns não são tão compatíveis com o MSCHAP2 mais seguro.
RSA SecurID
Observação: O tipo RSA SecurID é compatível com implantações do Horizon Cloud on Microsoft Azure que estão executando o manifesto 3139.x ou posterior. A opção de interface do usuário para especificar o tipo de RSA SecurID nos assistentes Adicionar Pod e Editar Pod se tornará visível para seleção nos assistentes a partir de meados de março de 2022.
  • Chave de acesso do servidor do gerenciador de autenticação RSA SecurID.
  • Número da porta de comunicação RSA SecurID. Normalmente. 5555, conforme definido nas configurações do sistema RSA Authentication Manager para a API de autenticação RSA SecurID.
  • Nome do host do servidor do gerenciador de autenticação RSA SecurID.
  • Endereço IP desse servidor do gerenciador de autenticação RSA SecurID.
  • Se o servidor do gerenciador de autenticação RSA SecurID ou seu servidor do balanceador de carga tiver um certificado autoassinado, você precisará do certificado de autoridade de certificação para fornecer no assistente para Adicionar Pod. O certificado deve estar no formato PEM (tipos de arquivo .cer ou .cert ou .pem)