Antes de executar o assistente de implantação de pod, 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: 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:
  • A partir da versão de manutenção de julho de 2020, em ambientes totalmente novos, novos pods devem ser implantados com pelo menos uma configuração de gateway. Se a sua conta de cliente foi criada antes da versão de 2020 de julho, mas você ainda não tiver implantado o primeiro pod, a implantação desse primeiro pod exigirá a configuração de pelo menos uma configuração de gateway no momento da implantação do pod.
  • 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. Por exemplo, você e sua equipe de TI devem garantir que nenhuma das políticas do Microsoft Azure bloqueie, negue ou restrinja a criação de componentes na conta de armazenamento do Azure. Para obter informações sobre as políticas do Azure, consulte a documentação da política do Azure.
  • O implantador do pod exige que a sua conta de armazenamento do Azure permita que o implantador use os tipos de conta StorageV1 e StorageV2 do Azure. Certifique-se de que suas políticas do Microsoft Azure não restrinjam nem neguem a criação de conteúdo que requer os tipos de conta StorageV1 e StorageV2 do Azure.
  • Como parte dos processos de implantação de gateway e de pod, a menos que você especifique tags de recursos personalizados no assistente de implantação, o Horizon Cloud cria grupos de recursos (RGs) na sua assinatura do Microsoft Azure que não têm etiquetas, incluindo o grupo de recursos inicial criado para a jumpbox temporária que orquestra esses processos de implantação. A partir da atualização do plano de nuvem de 8 de outubro de 2020, o assistente de implantação passou a ter um recurso no qual você pode especificar tags de recursos personalizadas que deseja aplicar aos grupos de recursos criados pelo implantador. Se você não especificar tags de recursos personalizadas e sua assinatura do Microsoft Azure tiver algum tipo de requisito de tag de recurso, a implantação do pod falhará se você tentar implantar um pod nessa assinatura, ou ela falhará durante a atualização do pod ou a adição de uma configuração de gateway a um pod. Se você não estiver planejando usar o recurso de tags de recursos personalizadas do assistente de implantação, deverá verificar se as suas políticas do Microsoft Azure permitem a criação dos grupos de recursos não marcados do pod na assinatura de destino. Para a lista de RGs que o implantador cria, consulte o tópico Grupos de recursos criados para um pod implantado no Microsoft Azure do Guia de administração.
  • 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

  • Verifique se todas as tarefas preparatórias estão concluídas, conforme descrito em Preparar para implementar um pod do Horizon Cloud no Microsoft Azure.
  • Verifique se você tem as informações de assinatura, conforme descrito em Informações relacionadas à assinatura para o assistente de implantação de pod do Horizon Cloud.
  • Verifique se você possui uma rede virtual existente em sua assinatura do Microsoft Azure e na região na qual está implementando o pod, 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 ou aplicativos remotos ativados para GPU, certifique-se de esta região do Microsoft Azure selecionada para o pod forneça para esses tipos de VM da série NV 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 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.
  • 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.
  • Verifique se você tem as informações para pelo menos um servidor NTP que deseja que o pod seja usado 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 que você especificar deverá ser acessível pela rede virtual configurada. 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.
  • 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 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.
    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.
  • 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. A partir do novo manifesto de pod disponibilizado na versão de manutenção trimestral de julho de 2020, ao implantar ambas as configurações de gateway em um pod, você é solicitado a especificar o mesmo FQDN para ambas as configurações de gateway. Depois que o pod for implantado com a configuração de gateway interno e externo, você deverá configurar que o tráfego de cliente de usuário final de entrada seja roteado para o balanceador de carga 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. Como os dois 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 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 Converter um arquivo de certificado para o formato PEM necessário para a implantação do pod.

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

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 usadas na configuração do seu servidor de autenticação, para que você possa fornecê-lo nos campos apropriados no assistente de implantação de pod. Se você tiver um servidor primário e um secundário, 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, geralmente a porta UDP 1812.
  • 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.