Guia de implantação do Horizon Cloud - VMware Horizon Cloud … · 2020-03-31 · Guia de...

Guia de implantação do Horizon CloudPara o nível de serviço a partir de quarta-feira, 17 de março de 2020

VMware Horizon Cloud Service

Você pode encontrar a documentação técnica mais atualizada no site da VMware, em:

https://docs.vmware.com/br/

Caso tenha comentários sobre esta documentação, envie seu feedback para:

[email protected]

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

VMware BrasilRua Surubim, 504 4º andar CEP 04571-050Cidade MonçõesSão PauloSÃO PAULO: 04571-050BrasilTel: +55 11 55097200Fax: + 55. 11. 5509-7224www.vmware.com/br

Copyright © 2017-2020 VMware, Inc. Todos os direitos reservados. Informações sobre direitos autorais e marca registrada.

Guia de implantação do Horizon Cloud

VMware, Inc. 2

https://docs.vmware.com/br/

mailto:[email protected]

http://pubs.vmware.com/copyright-trademark.html

http://pubs.vmware.com/copyright-trademark.html

Conteúdo

Integração ao Horizon Cloud para Microsoft Azure, Horizon 7 no local e Horizon 7 on VMware Cloud on AWS 4

1 Introdução ao Horizon Cloud e à integração de pods para que se tornem pods conectados à nuvem 13Lista de verificação de requisitos do VMware Horizon Cloud Service on Microsoft Azure para novas

implantações do pod — Atualizada para o versão de serviço de 2020 16

VMware Horizon 7 com a lista de verificação de requisitos do Horizon Cloud - Atualizado para a versão de serviço de março de 2020 27

2 Integração do primeiro pod conectado à nuvem ao ambiente do tenant do Horizon Cloud30

Durante a integração de um pod do Horizon 7 para usar licenças de assinatura do Horizon ou serviços hospedados em nuvem com esse pod 32

Fluxo de trabalho de alto nível durante a integração de um pod do Horizon 7 existente implantado manualmente como seu primeiro pod ao seu ambiente de tenant do Horizon Cloud 35

Quando você escolhe a capacidade de nuvem do Microsoft Azure para a implantação do seu primeiro pod 71

Fluxo de trabalho de alto nível para quando o primeiro pod conectado à nuvem estiver sendo implantado no Microsoft Azure 77

3 Agora que seu primeiro pod está completamente implantado e conectado ao Horizon Cloud 223

VMware, Inc. 3

Integração ao Horizon Cloud para Microsoft Azure, Horizon 7 no local e Horizon 7 on VMware Cloud on AWS

Estes tópicos de documentação se aplicam quando você tiver acabado de receber o e-mail Bem-vindo ao serviço do VMware Horizon e estiver pronto para a integração do primeiro pod. Esse conjunto de tópicos de integração descreve a relação entre a licença universal do Horizon, que concede a você o direito ao usar os serviços hospedados na nuvem e à licença de assinatura, bem como a estruturar o processo para a primeira integração de um pod ao Horizon Cloud. Essa primeira integração é a chave que lhe permite explorar suas licenças de assinatura do Horizon, integrar os pods existentes do Horizon 7 aos serviços hospedados na nuvem relevantes para eles, criar novos pods no Microsoft Azure e aproveitar todos os serviços hospedados em nuvem que o VMware Horizon® Cloud Service™ atualmente oferece para pods conectados à nuvem.

Você integra um pod existente do Horizon 7 à nuvem para dois casos de uso primários: para ativar uma licença de assinatura para esse pod e permitir o uso desses serviços hospedados em nuvem que o Horizon Cloud fornece para esse tipo de pod. Você integra um pod no Microsoft Azure usando o Console administrativo do Horizon Cloud para implantar esse pod em sua assinatura de nuvem do Microsoft Azure.

Dica Se você já tiver pelo menos um pod conectado à nuvem, em vez desse conjunto de tópicos de integração, use o conjunto de tópicos de administração complementares para obter informações sobre como integrar outros pods após o primeiro.

n Relacionamento entre a integração do seu primeiro pod com a licença universal do Horizon, a conta My VMware associada a essa licença, seu tenant do Horizon Cloud e o e-mail de boas-vindas

n Listas de verificação de requisitos de integração

n Histórico de revisão para esses tópicos de integração

n Público-alvo

n Sobre as capturas de tela

n Comunidade do Horizon Cloud

n Entrando em contato com o Suporte da VMware

VMware, Inc. 4

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-571F4415-515C-4BED-B02E-8ED2BBD8EF1C.html

Relacionamento entre a integração do seu primeiro pod com a licença universal do Horizon, a conta My VMware associada a essa licença, seu tenant do Horizon Cloud e o e-mail de boas-vindasEm um alto nível, os pontos de conexão entre esses elementos é:

1 Obter uma licença de assinatura. Atualmente, a licença universal do Horizon é a licença a ser obtida. A licença será associada à conta My VMware específica que é usada na solicitação de licença.

2 A VMware configura a nova conta de tenant do Horizon Cloud, associa-a à mesma conta My VMware à qual a licença universal do Horizon está associada e especifica uma das instâncias regionais da camada de controle do Horizon Cloud para a conta. As informações na solicitação de licença são usadas para determinar qual instância da camada de controle regional é apropriada para a conta de tenant. Essas instâncias de camada de controle regional estão relacionadas aos centros de dados que hospedam a camada de controle da nuvem, conforme designado no documento de descrição do serviço disponível na página Descrição do Horizon Cloud Service e Contrato de nível de serviço.

3 A VMware envia o e-mail Bem-vindo ao serviço do VMware Horizon para o endereço de e-mail configurado na conta My VMware na etapa 1 e ao qual a licença está associada. Para obter um exemplo desse e-mail de boas-vindas, consulte a captura de tela abaixo. Entre outras informações, o e-mail declara a conta My VMware e a região associadas à conta de tenant.

Observação Devido a um problema conhecido, a região que aparece no email pode parecer com um nome de cadeia do sistema, como USA, EU_CENTRAL_1, AP_SOUTHEAST_2, PROD1_NORTHCENTRALUS2_CP1, PROD1_NORTHEUROPE_CP1 e PROD1_AUSTRALIAEAST_CP1.


VMware, Inc. 5

https://www.vmware.com/products/horizon-universal-license.html

https://www.vmware.com/download/eula/vmware-horizon-service.html

4 Quando receber o e-mail, leia as informações nele e use os links de hipertexto na seção Como começar para abrir as URLs e ir aos principais destinos, como o portal de ambiente do tenant (denominado console administrativo do Horizon Cloud), o local de download do software Horizon 7 Cloud Connector e a documentação on-line.

Importante Quando o e-mail for recebido pela primeira vez, é prudente fazer logon no portal de ambiente do tenant usando a conta My VMware inicial e adicionar contas My VMware adicionais para as pessoas que você deseja habilitar aos pods integrados e gerenciar os pods integrados. Adicionar essas pessoas mesmo antes de incorporar o primeiro pod impedirá situações e atrasos no acesso à sua conta de tenant, por exemplo, se a pessoa original não estiver mais disponível na sua empresa, e você não tiver outra pessoa na equipe que saiba as credenciais de logon. O acesso à sua conta de tenant é necessário para integrar pods, bem como para executar fluxos de trabalho relacionados, como reconfigurar o Horizon 7 Cloud Connector. Se o acesso à sua conta de tenant for interrompido porque a pessoa principal está deixando a organização, você terá que abrir uma solicitação de suporte para a VMware para atualizar a conta My VMware associada da conta do tenant, o que pode causar um atraso no logon no portais de gerenciamento e integração.

Para ver as etapas para adicionar contas My VMware adicionais para fazer logon na sua conta de tenant, consulte Adicionar administradores para fazer logon no seu ambiente de tenant do Horizon Cloud.

Como obter a licença Você deve obter a licença primeiro, pois é nesse momento que a VMware gera sua conta e ambiente de tenant do Horizon Cloud.

Sua nova conta de tenant do Horizon Cloud na camada de controle de nuvem

Sua conta de tenant do Horizon Cloud é importante para você, mesmo quando só usa uma licença de assinatura com seus pods existentes do Horizon 7, e você não está imaginando o uso de serviços hospedados na nuvem com seus pods. O motivo pelo qual essa conta de tenant é importante é que a mesma conta de tenant é usada para ambas as opções abaixo:

n Efetuar logon no portal de integração e gerenciamento do Horizon 7 Cloud Connector. O portal do Horizon 7 Cloud Connector é usado para a integração de um pod do Horizon 7 à nuvem para usar a licença de assinatura, bem como para ativar serviços hospedados na nuvem. Depois de concluir a integração inicial do pod do Horizon 7, você pode fazer logon no portal do Horizon 7 Cloud Connector a qualquer momento para gerenciar os recursos do próprio conector.

n Fazer logon no portal do ambiente do tenant do Horizon Cloud, denominado console administrativo do Horizon Cloud. O portal de ambiente de tenant do Horizon Cloud é usado para adicionar administradores adicionais para que eles também possam usar o portal de integração e de gerenciamento do Horizon 7 Cloud Connector além da conta My VMware inicial que obteve a licença. Esse portal de ambiente de tenant também é usado para acessar os serviços


VMware, Inc. 6

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-4D46E8D7-2AE4-4DDB-8389-59DE1AF55D84.html

hospedados na nuvem, como os relatórios e o dashboard de monitoramento do Serviço de Monitoramento da Nuvem e o assistente de implantação de pod para a implantação no Microsoft Azure. Esse portal é denominado Console administrativo do Horizon Cloud.

Como essa conta do tenant se refere à conta My VMware associada à licença

Uma conta My VMware deve ser usada para obter a licença universal do Horizon primeiro. Como resultado, essa conta My VMware é a primeira registrada no ambiente e conta de tenant do Horizon Cloud criados recentemente e é usada para as credenciais de logon para a conta de tenant do Horizon Cloud (usada pelos dois portais listados acima). Quando a conta do tenant é criada, o e-mail Bem-vindo ao serviço do VMware Horizon é enviado ao endereço específico configurado na conta My VMware. A captura de tela a seguir é uma ilustração do e-mail de boas-vindas. Garanta que você ou alguém da sua organização possa obter o e-mail de boas-vindas dessa conta de e-mail associada à conta My VMware usada para comprar a licença de assinatura, para que você possa usar os links nesse e-mail para acessar a página de downloads do Horizon 7 Cloud Connector, abrir o portal do tenant do Horizon Cloud etc.

A captura de tela a seguir ilustra um exemplo do e-mail de boas-vindas e indica onde a conta My VMware é referenciada.


VMware, Inc. 7

https://my.vmware.com

Seu novo ambiente de tenant do Horizon Cloud e seu portal

Assim que você receber o e-mail de boas-vindas da VMware, a conta My VMware associada poderá fazer logon no ambiente de tenant do Horizon Cloud recém-criado, mesmo quando você não tiver nenhum pod conectado à nuvem. No entanto, nesse ponto inicial, o portal do ambiente do tenant fornece acesso a uma única tela inicial e um pequeno subconjunto de ações de fluxo de trabalho hospedados na nuvem nessa tela.

A seguinte captura de tela mostra o portal no point-in-time quando a sua conta de tenant é criada. A lista a seguir descreve as principais ações que podem ser tomadas nessa tela antes da integração do primeiro pod.


VMware, Inc. 8

Dica Clique na barra Configuração Geral nessa tela do portal para ver duas das principais ações listadas abaixo.

n Aprendendo a integrar um pod local do Horizon 7, na linha No Local.

n Aprendendo a integrar um pod do Horizon 7 à sua capacidade do SDDC no VMware Cloud on AWS, a partir do botão Adicionar da linha Adicionar Capacidade de Nuvem.

n Implantação de um pod no Microsoft Azure, a partir daquele mesmo botão Adicionar da linha Adicionar Capacidade de Nuvem.

n Adicionar administradores aos quais você deseja dar a capacidade de fazer logon no portal de integração e gerenciamento do Horizon 7 Cloud Connector e no Console administrativo do Horizon Cloud (o portal do seu ambiente de tenant). Por padrão, a conta My VMware


VMware, Inc. 9

usada para configurar o tenant é preenchida ali. Como resultado, você verá essa linha marcada com uma marca de seleção verde. No entanto, isso só acontece porque há sempre a conta inicial My VMware associada à conta do tenant quando o ambiente do tenant é criado.

Dica Para evitar o bloqueio do seu ambiente de tenant e da integração do Horizon 7 Cloud Connector devido ao acesso com uma conta My VMware inicial que ficou inativa por algum motivo, como quando alguém deixa de trabalhar na empresa ou organização, é prudente adicionar outros administradores logo que você receber o e-mail Bem-vindo ao serviço do Horizon, mesmo antes de você integrar um pod pela primeira vez.

n Ativação do Serviço de Monitoramento da Nuvem (CMS). O CMS é habilitado por padrão, portanto você verá essa linha marcada com uma marca de seleção verde. Nesse ponto, você pode optar por desativar esse recurso, mesmo antes de incorporar pods.

Dica Antes de poder acessar outras ações e fluxos de trabalho nesse portal além dos quatro acima, você deve ter um pod integrado, o pod deve estar on-line e em comunicação com o plano de gerenciamento de nuvem e ter um domínio do Active Directory registrado no ambiente do tenant. O portal bloqueia o acesso a outras ações de gerenciamento até que o fluxo de trabalho de registro de domínio do Active Directory seja concluído. Para obter informações sobre esse fluxo de trabalho, consulte Como realizar seu primeiro registro de domínio do Active Directory no ambiente do Horizon Cloud.

Listas de verificação de requisitos de integraçãoSe a sua primeira integração de pod deve explorar sua licença de assinatura do Horizon com um pod existente do Horizon 7 antes de iniciar as etapas descritas neste conjunto de documentações de integração, primeiro leia VMware Horizon 7 com a lista de verificação de requisitos do Horizon Cloud - Atualizado para a versão de serviço de março de 2020. Esse tópico descreve vários elementos de pré-requisito necessários para conectar com êxito um pod do Horizon 7 ao Horizon Cloud. Após o pod do Horizon 7 ser conectado à nuvem, a licença de assinatura do Horizon é enviada da nuvem para o pod, e você pode começar a habilitar os serviços hospedados na nuvem para esse pod no portal do tenant em si.


VMware, Inc. 10

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-CBAA1736-2B10-4875-B19A-64520C63572D.html


Se a sua primeira integração do pod estiver no Microsoft Azure, antes de iniciar as etapas descritas no conjunto de documentações de integração, primeiro leia Lista de verificação de requisitos do VMware Horizon Cloud Service on Microsoft Azure para novas implantações do pod — Atualizada para o versão de serviço de 2020. Esse tópico descreve vários elementos de pré-requisitos necessários para fazer uma implantação bem-sucedida do primeiro pod no Microsoft Azure.

Histórico de revisão para esses tópicos de integraçãoEste conjunto de documentações é atualizado a cada nova versão do produto ou quando necessário.

Essa tabela fornece o histórico de atualizações.

Revisão Descrição

17 DE MAR DE 2020

Versão inicial, quando os recursos descritos foram implantados em tempo real em produção.

Este documento descreve os recursos de serviço mais recentes.

n Para pods usando a capacidade do Microsoft Azure, alguns dos novos recursos não são necessários para a versão do manifest do pod que foi disponibilizada no momento em que esta versão do serviço foi ativada na produção, enquanto alguns dos novos recursos exigem essa nova versão do manifest do pod para que você aproveite esses recursos. Consulte as Notas de Versão da versão 3.0 do serviço para a versão de manifest do pod que corresponde a esta versão do serviço e para a lista de novos recursos que exigem a versão mais recente do manifest do pod.

Para pods do Horizon 7 conectados à nuvem, os recursos mais recentes correspondem aos componentes do Horizon 7 na versão 7.12 e posteriores, conectados à camada de controle de nuvem usando o Horizon 7 Cloud Connector na versão 1.6 e posteriores.

Público-alvoAs informações nesse documento são destinadas a administradores experientes de centros de dados com conhecimento nas seguintes áreas.

n VMware Horizon

n VMware Horizon® 7 Cloud Connector™

n VMware Unified Access Gateway™

n VMware Workspace ONE® Access™

n Tecnologia de virtualização

n Rede

n VMware Cloud™ on AWS (VMware Cloud)

n VMware Horizon® 7 on VMware Cloud™ on AWS

n Microsoft Azure


VMware, Inc. 11

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/rn/horizon-cloud-service-relnotes-30.html

Sobre as capturas de telaEm geral, as capturas de tela:

n Mostram apenas a parte da tela geral da interface de usuário que corresponde ao texto no ponto em que a captura de tela aparece e, não necessariamente, a interface de usuário inteira.

n Tem áreas desfocadas, quando apropriado, para manter o anonimato dos dados.

n No formato PDF, as imagens da captura de tela maiores de seis polegadas são redimensionadas automaticamente. Como resultado, essas imagens podem aparecer desfocadas no formato PDF. Nas páginas HTML paralelas, você pode clicar nessas imagens de captura de tela inteiras para ver a imagem no tamanho máximo.

Observação Algumas capturas de tela são feitas com uma resolução mais alta do que outras e podem parecer granuladas quando o PDF é visualizado em 100%. No entanto, se você aumentar o zoom para 200%, estas imagens ficarão claras e legíveis.

Comunidade do Horizon CloudUse as seguintes comunidades para fazer perguntas, explorar as respostas dadas para perguntas frequentes por outros usuários e acessar links para informações úteis.

n Comunidade do VMware Horizon Cloud Service em https://communities.vmware.com/community/vmtn/horizon-cloud-service

n VMware Horizon Cloud on Microsoft Azure na subcomunidade em https://communities.vmware.com/community/vmtn/horizon-cloud-service/horizon-cloud-on-azure, uma subcomunidade da comunidade do VMware Horizon Cloud Service.

Entrando em contato com o Suporte da VMwareEntre em contato com o Suporte da VMware se precisar de ajuda com o ambiente do Horizon Cloud.

n Você pode enviar uma solicitação de suporte online ao Suporte da VMware usando a sua conta My VMware® ou pelo telefone.

n KB 2144012 As Orientações de Suporte ao Cliente fornece detalhes para obter suporte, dependendo do problema encontrado.

n No Console Administrativo, clicando em > Suporte, exibe o link para esse KB 2144012 também.

Glossário de Publicações Técnicas VMwareAs Publicações Técnicas VMware fornecem um glossário de termos que talvez você não conheça. Para saber as definições de termos como usados na documentação técnica da VMware, acesse http://www.vmware.com/support/pubs.


VMware, Inc. 12

https://communities.vmware.com/community/vmtn/horizon-cloud-service

https://communities.vmware.com/community/vmtn/horizon-cloud-service

https://communities.vmware.com/community/vmtn/horizon-cloud-service/horizon-cloud-on-azure

https://communities.vmware.com/community/vmtn/horizon-cloud-service/horizon-cloud-on-azure

https://kb.vmware.com/s/article/2144012

http://www.vmware.com/support/pubs

http://www.vmware.com/support/pubs

Introdução ao Horizon Cloud e à integração de pods para que se tornem pods conectados à nuvem

1Seu ambiente de tenant do Horizon Cloud geral consiste no serviço de nuvem hospedado pela VMware e nos pods implantados nos ambientes de capacidade correspondentes e conectados ao serviço de nuvem. Quando um pod que consiste no software da VMware implantado em um ambiente de capacidade compatível é integrado adequadamente, ele se torna um pod conectado à nuvem. Quando pelo menos um pod estiver totalmente integrado ao ambiente do tenant, você poderá integrar pods adicionais para fazer uma frota de pods conectados à nuvem. Para trabalhar com a frota de pods conectados à nuvem do seu ambiente de tenant e os recursos de desktop como serviço que o serviço fornece, faça logon no portal do ambiente do tenant e o use. Ele é conhecido como Console Administrativo do Horizon Cloud.

Horizon Cloud Um plano de controle é hospedado na nuvem pela VMware para a orquestração central e o gerenciamento de áreas de trabalho virtuais e de aplicativos.

pod conectado à nuvem

O software VMware foi implantado em um ambiente de capacidade com suporte e integrado à camada de controle da nuvem. Ambientes de capacidade com suporte são aqueles como a nuvem do Microsoft Azure, o VMware Cloud™ on AWS ou a infraestrutura local. Cada um desses ambientes de capacidade fornece um tipo de pod específico:

n Pod na sua assinatura do Microsoft Azure

n Pod local do Horizon 7

n Horizon 7 no VMware Cloud on AWS

Dependendo do tipo de ambiente de capacidade em uso, você pode usar o Console Administrativo do Horizon Cloud para uma implantação automatizada de pods e para conexão com o Horizon Cloud. Para alguns desses tipos de pod, mesmo que eles não possam ser implantados e configurados automaticamente, ainda poderá integrar esses pods ao Horizon Cloud.

Para obter uma visão geral de alto nível do conceito da integração do pod, consulte Integração ao Horizon Cloud para Microsoft Azure, Horizon 7 no local e Horizon 7 on VMware Cloud on AWS.

VMware, Inc. 13

Horizon Cloud Plano de controleA VMware hospeda o plano de controle do Horizon Cloud na nuvem. Esse serviço de nuvem permite a orquestração central e o gerenciamento de áreas de trabalho virtuais, sessões de área de trabalho remotas e aplicativos remotos dos seus usuários. O serviço de nuvem também gerencia seus pods. Os pods estão fisicamente localizados nos ambientes de capacidade que você fornece. Quando você efetua logon no serviço de nuvem, você pode ver todos os pods e executar atividades de gerenciamento entre eles, independentemente de onde estejam fisicamente localizados.

A VMware é responsável por hospedar o serviço e fornecer atualização e aprimoramento de recursos para uma experiência de software como serviço. O Horizon Cloud é um ambiente multiempresa e tem várias instâncias de camada de controle regional. Cada instância de camada de controle regional corresponde ao seu centro de dados geográfico de hospedagem, conforme descrito no documento de descrição do serviço disponível na página Descrição do VMware Horizon Service e Contrato de nível de serviço. A conta do seu tenant está associada a uma instância regional específica no momento em que a conta é criada.

A camada de controle na nuvem também hospeda uma interface de usuário de gerenciamento comum denominada como Console Administrativo do Horizon Cloud ou, resumidamente, como Console Administrativo. O Console Administrativo é executado em navegadores padrão do setor. Ele fornece aos administradores de TI um local único para tarefas de gerenciamento que envolvem as atribuições de usuários e as áreas de trabalho virtuais, as sessões de área de trabalho remota e os aplicativos. O Console de administração pode ser acessado de qualquer lugar, a qualquer momento, oferecendo o máximo de flexibilidade possível.

Importante O Console de Administração é dinâmico e reflete o que está disponível no nível de serviço atual. No entanto, quando você tiver pods conectados à nuvem ainda não atualizados para o nível mais recente do software do pod, o Console Administrativo não exibirá os recursos que variam de acordo com o nível de software mais recente do pod. Além disso, em uma versão específica, o Horizon Cloud pode incluir recursos ou recursos licenciados separadamente que só estão disponíveis para configurações de contas de tenant específicas. O Console administrativo reflete dinamicamente os elementos relacionados a esses recursos somente quando sua licença ou configuração de conta de tenant inclui o uso desses recursos. Para obter exemplos, consulte o Tour do tópico do Console Administrativo do Horizon Cloud em Guia de administração do Horizon Cloud.

Se você espera ver um recurso no Console administrativo, mas ele não está visível, entre em contato com seu representante de contas da VMware para verificar se sua configuração de conta de licença e ou de tenant autoriza seu uso.

Tipos de pod que você pode conectar ao Horizon CloudEsta versão do Horizon Cloud permite os seguintes tipos de implantação.

Observação Para conectar um pod ao Horizon Cloud ou usar o Console Administrativo para uma implantação automatizada, sua conta do cliente deve ter o licenciamento apropriado. Para obter informações de licenciamento, entre em contato com seu representante de contas da VMware.


VMware, Inc. 14



Tabela 1-1. Tipos de implantação de pod

Tipo de implantação Descrição

Pod do VMware Horizon 7 localizado na sua infraestrutura local

Implante o Horizon 7 Cloud Connector em sua infraestrutura local e configure-o para conectar esse pod ao Horizon Cloud.

Pod do VMware Horizon 7 que você instalou e configurou manualmente no seu SDDC do VMware Cloud on AWS

Implante o Horizon 7 Cloud Connector no SDDC do VMware Cloud on AWS e configure-o para conectar esse pod ao Horizon Cloud.

Pod do Horizon Cloud implantado pelo Horizon Cloud em sua capacidade de nuvem do Microsoft Azure

Implante o pod usando o assistente de implantação automatizada do Console Administrativo do Horizon Cloud.

Importante Para ambientes de produção, garanta que os modelos de VM usados para os farms e as atribuições de área de trabalho tenham no mínimo duas (2) CPUs. O teste de dimensionamento da VMware mostrou que usar duas CPUs ou mais evita problemas de conexão do usuário final inesperados. Mesmo que o sistema não impeça você de escolher um modelo de VM com uma única CPU, você deve usar tais modelos de VM para testes ou prova de conceitos somente.

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:

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

n O implantador do pod exige que a sua conta de armazenamento do Azure permita que o implantador use os tipos de conta StorageV1 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 o tipo de conta StorageV1 do Azure.

n Como parte dos processos de implantação de gateway e de pod, 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 implantação do pod falhará se você tentar implantar um pod em uma assinatura do Microsoft Azure que tenha qualquer tipo de requisito de etiqueta de recursos no momento da implantação ou no momento das atualizações de pod ou de adição de uma configuração de gateway a um pod. Você deve 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.

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


VMware, Inc. 15

https://docs.microsoft.com/en-us/azure/governance/policy/

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-9F004F77-5685-400E-8ADC-3ECA96D3CA71.html

Este capítulo inclui os seguintes tópicos:

n Lista de verificação de requisitos do VMware Horizon Cloud Service on Microsoft Azure para novas implantações do pod — Atualizada para o versão de serviço de 2020

n VMware Horizon 7 com a lista de verificação de requisitos do Horizon Cloud - Atualizado para a versão de serviço de março de 2020

Lista de verificação de requisitos do VMware Horizon Cloud Service on Microsoft Azure para novas implantações do pod — Atualizada para o versão de serviço de 2020Esta lista de verificação irá orientá-lo a preparar as suas assinaturas e redes do Microsoft Azure para a implantação de um pod do Horizon Cloud no Microsoft Azure. Garantir que esses requisitos sejam cumpridos, conforme descrito abaixo, fornecerá os dois para concluir uma implantação bem-sucedida de um novo pod e concluir com sucesso essas tarefas principais que são necessárias após a implantação de um pod.

As seções neste tópico da documentação são:

n Requisitos de camada de controle do Horizon Cloud

n Requisitos de assinatura do Microsoft Azure

n Requisitos de rede

n Requisitos de portas e protocolos

n Fluxo de trabalho de implantação do pod

n Requisitos do Active Directory

n Requisitos de registro DNS

n Imagem de base, áreas de trabalho e farms do Horizon Cloud

n Licenciamento para os sistemas operacionais Microsoft Windows

n Arquitetura de referência

n Recursos

Esta lista de verificação destina-se principalmente às contas de cliente do Horizon Cloud que são criadas após a disponibilização do serviço de março de 2020 e que ainda não implantaram seu primeiro pod no Microsoft Azure. Quando essas novas contas são implantadas no primeiro pod, esse pod é implantado usando a versão mais recente do manifest do pod. Os requisitos para uma implantação de pod bem-sucedida são determinados principalmente pela versão do manifesto do pod. A camada de controle de nuvem também pode determinar requisitos para uma implantação bem-sucedida.


VMware, Inc. 16

Alguns dos requisitos listados abaixo são aqueles necessários para a implantação do pod em si. Alguns requisitos são aqueles necessários para as principais tarefas que são realizadas após a implantação do pod para obter um ambiente de tenant produtivo, capaz de fornecer áreas de trabalho e aplicativos provisionados por pod a seus usuários finais.

Requisitos para a própria implantação do pod


n Requisitos de assinatura do Microsoft Azure

n Requisitos de rede


n Fluxo de trabalho de implantação do pod

Requisitos de ambiente produtivo após uma implantação de pod


n Requisitos de registro DNS

n Imagem de base, áreas de trabalho e farms do Horizon Cloud


VMware, Inc. 17

n Licenciamento para os sistemas operacionais Microsoft Windows






Requisitos de camada de controle do Horizon Cloud

☐ Conta ativa do My VMware para fazer logon na camada de controle do Horizon Cloud.

Requisitos de assinatura do Microsoft Azure

☐ Assinatura válida do Microsoft Azure em um ambiente do Microsoft Azure com suporte (Public Azure, Azure China, Azure Germany e Azure Government). Se você for implantar o Unified Access Gateway externo opcional em uma VNet separada usando a própria assinatura, precisará de outra assinatura válida do Microsoft Azure no mesmo ambiente do Microsoft Azure.

☐ Privilégios administrativos válidos do Microsoft Azure na assinatura do Microsoft Azure. Para obter informações adicionais, consulte Introdução ao controle de acesso com base em função no portal do Azure na documentação da Microsoft.


VMware, Inc. 18



https://docs.microsoft.com/en-us/azure/role-based-access-control/overview

☐ Capacidade mínima do Microsoft Azure disponível para a infraestrutura do Horizon Cloud, além da carga de trabalho esperada da área de trabalho e do aplicativo. Observe que, contanto que essa capacidade seja disponibilizada, o Horizon Cloud implantará automaticamente essas VMs, e nenhuma instalação manual será necessária.

n Mecanismo de implantação de pod, também conhecido como jumpbox (transitório) — 1 x Standard_F2

n Pod/Gerenciador de pod com alta disponibilidade habilitada – 2 x Standard_D4_v3 (se não houver nenhum Standard_D4_v3 na região, 2 x Standard_D3_v2)

n Pod/Gerenciador de pod sem alta disponibilidade habilitada – 1 x Standard_D4_v3 (se não houver nenhum Standard_D4_v3 na região, 1 x Standard_D3_v2)

n Base de dados do Microsoft Azure para o PostgreSQL Service — Geração 5, memória otimizada, 2 vCores, armazenamento de 10 GB

n Unified Access Gateway externo (opcional) — 2 x Standard_A4_v2

n Unified Access Gateway interno (opcional) — 2 x Standard_A4_v2

Observação Após a conclusão da implantação do pod, sua capacidade na nuvem do Microsoft Azure terá que também acomodar as imagens base, as áreas de trabalho virtuais e os farms RDSH que você criar nesse pod. Consulte a seção Imagem de base, áreas de trabalho e farms do Horizon Cloud abaixo.

O Unified Access Gateway externo pode ser implantado opcionalmente na própria rede virtual (VNet) do Microsoft Azure, usando a mesma assinatura do pod ou usando uma assinatura diferente. Ao implantar o Unified Access Gateway externo na própria VNet, é necessária a seguinte capacidade na assinatura em que o Unified Access Gateway externo é implantado:

n Mecanismo de implantação externo do Unified Access Gateway, também conhecido como jumpbox de gateway (transitório), 1 x Standard_F2

n Conector de gateway externo — 1 x Standard_A1_v2

n Unified Access Gateway externo — 2 x Standard_A4_v2

☐ Entidade de serviço e chave de autenticação criadas para cada assinatura. Para ver mais detalhes, consulte Usar um portal para criar um aplicativo e uma entidade de serviço do Azure Active Directory que possa acessar recursos.

☐ Cada entidade de serviço deve receber a atribuição da função adequada que possibilita as ações que o Horizon Cloud deve realizar na assinatura. Essa função pode ser a função de Colaborador ou a uma função personalizada com as ações necessárias permitidas no nível da assinatura. Quando você estiver implantando a configuração de gateway externo em um grupo de recursos existente em uma assinatura separada, as permissões mais detalhadas poderão ser definidas para a entidade de serviço dessa assinatura. Para obter detalhes adicionais sobre as ações de função necessárias, consulte Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure.

☐ Provedores de recursos necessários registrados em cada assinatura do Microsoft Azure. Consulte a etapa 8.b em Criar a entidade de serviço exigida pelo implantador de pod do Horizon Cloud através da criação de um registro de aplicativo.

☐ ID de assinatura do Microsoft Azure, ID do diretório, chave e ID do aplicativo identificados.

☐ Se você estiver implantando o Unified Access Gateway externo opcional em uma VNet separada usando sua própria assinatura, e sua organização exigir o uso de um grupo de recursos controlado por você e não criado pelo implantador do pod, use o recurso para implantar o Unified Access Gateway externo no seu próprio grupo de recursos nomeado. O uso desse recurso exige que você crie esse grupo de recursos nessa assinatura antes de executar o implantador do pod. Você também precisa garantir que as permissões necessárias estejam em vigor para o implantador do pod implantar a configuração do Unified Access Gateway nesse grupo de recursos, gerenciar a configuração e atualizar o software do Unified Access Gateway no processo de upgrade do pod padrão. Para obter detalhes sobre as permissões necessárias, consulte Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure.


VMware, Inc. 19

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal?view=azure-cli-latest

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal?view=azure-cli-latest

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.getstarted15/GUID-DC011997-CE9E-4B38-9C4F-57104226218C.html


Requisitos de rede

☐ Rede virtual do Microsoft Azure (VNet) criada na região desejada do Microsoft Azure com espaço de endereço aplicável para cobrir as sub-redes necessárias. Para obter mais detalhes, consulte Rede virtual do Azure.

Ao implantar o Unified Access Gateway externo opcional na própria VNet, separada da do pod, crie essa VNet do Unified Access Gateway na mesma região do Microsoft Azure que a VNet do pod com o espaço de endereço aplicável para cobrir as sub-redes necessárias e emparelhe as duas VNets.

☐ 3 intervalos de endereços não sobrepostos no formato CIDR na VNet do pod, reservados para sub-redes.

n Sub-rede de gerenciamento — No mínimo 27

n Sub-rede de tenants — No mínimo 27, com /24 - /22 de preferência, com base no número de áreas de trabalho e servidores RDS

n Sub-rede de zona desmilitarizada — No mínimo /28 quando o Unified Access Gateway for implantado na VNet do pod (opcional)

As sub-redes podem ser criadas manualmente na VNet ou pelo Horizon Cloud durante a implantação. Se você estiver usando sub-redes criadas manualmente, nenhum outro recurso poderá ser anexado.

☐ Ao implantar o Unified Access Gateway externo opcional na própria VNet separada da do pod, três intervalos de endereços não sobrepostos no formato CIDR na VNet do Unified Access Gateway, reservados para sub-redes.

n Sub-rede de gerenciamento — No mínimo 27

n Sub-rede de back-end — No mínimo 27, com /24-/22 de preferência, com base no número de áreas de trabalho e servidores RDS

n Sub-rede de zona desmilitarizada (front-end) — No mínimo de /28

As sub-redes podem ser criadas manualmente na VNet ou pelo Horizon Cloud durante a implantação. Se você estiver usando sub-redes criadas manualmente, nenhum outro recurso poderá ser anexado. Para esse caso de uso, normalmente as sub-redes são criadas manualmente.

☐ Servidores ou servidor NTP disponíveis e acessíveis a partir do pod do Horizon Cloud e das instâncias do Unified Access Gateway.

☐ Configure o servidor DNS da VNet (rede virtual), apontando para um servidor DNS válido que possa resolver os nomes externos e os nomes de máquinas internos.

☐ Acesso de saída à Internet na VNet para nomes DNS específicos que devem ser resolvidos e acessíveis usando-se portas e protocolos específicos. Isso é necessário para implantação e continuidade das operações. Consulte 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.

☐ Informações do servidor proxy, se necessário, para acesso de saída à Internet na VNet que é usada durante a implantação e a continuidade das operações do ambiente do Horizon Cloud (opcional)

☐ Rota do Microsoft Azure VPN/Express configurada (opcional)

☐ FQDN para acesso de usuário externo e interno (necessário ao implantar um pod com o Unified Access Gateway).

☐ Certificado ou certificados para o Unified Access Gateway no formato PEM correspondente ao FQDN (necessário ao implantar um pod com o Unified Access Gateway).

☐ Autenticação de dois fatores para um servidor de autenticação RADIUS local (opcional)

n Endereços DNS para o Unified Access Gateway para resolver o nome do servidor de autenticação

n Rotas para o Unified Access Gateway para resolver o roteamento de rede para o servidor de autenticação


VMware, Inc. 20

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview

Requisitos de portas e protocolos

☐ Portas e protocolos específicos são necessários para a integração de pods e a continuidade das operações do ambiente do Horizon Cloud. Consulte Requisitos de portas e protocolos para um pod do Horizon Cloud no manifesto da versão de setembro de 2019 ou posteriores.

Fluxo de trabalho de implantação do podOs itens anteriores são aqueles necessários antes de iniciar o assistente de implantação do pod. Depois de garantir que você tenha os itens anteriores, siga as etapas 1 a 4 de implantação do pod em Fluxo de trabalho de alto nível para quando o primeiro pod conectado à nuvem estiver sendo implantado no Microsoft Azure para implantar o pod.

Depois que o pod for implantado com êxito, certifique-se de ter os itens descritos na seção a seguir, para que você possa concluir as etapas de chave restantes nesse fluxo de trabalho de alto nível.

Requisitos do Active Directory

☐ Uma das seguintes configurações do Active Directory com suporte:

n Servidor local do Active Directory conectado via VPN/Express Route

n Servidor do Active Directory localizado no Microsoft Azure

n Serviços de Domínio do Microsoft Azure Active Directory

☐ Níveis funcionais de domínio do Microsoft Windows Active Directory Domain Services (AD DS) compatíveis:

n Microsoft Windows Server 2003

n Microsoft Windows Server 2008 R2



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

☐ Conta de BIND de domínio

n Uma conta de BIND de domínio do Active Directory (um usuário padrão com acesso de leitura) que tem permissão para ler objetos no AD

n Defina a senha da conta como Nunca Expirar

n Para obter mais detalhes e requisitos, consulte Contas de serviço que o Horizon Cloud requer para suas operações

☐ Conta de BIND de domínio auxiliar — não pode usar a mesma conta que a mencionada acima





VMware, Inc. 21

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-5F0B52F6-CD79-447B-B1C6-6ED2AF71BBA7.html




☐ Conta de ingresso no domínio

n Conta de ingresso no domínio do Active Directory que pode ser usada pelo sistema para executar operações de Sysprep e ingressar computadores no domínio, normalmente uma nova conta (conta de usuário de ingresso no domínio)

n É membro do grupo de administradores do Horizon Cloud


n Essa conta requer as seguintes permissões do Active Directory: listar conteúdo, ler todas as propriedades, ler permissões, redefinir a senha, criar objetos de computador, excluir objetos de computador.

n Essa conta também requer a permissão do Active Directory chamada Gravar Todas as Propriedades em todos os objetos descendentes da Unidade Organizacional (UO) de destino que pretende usar para farms e atribuições de área de trabalho VDI.


☐ Conta de ingresso no domínio auxiliar (opcional, não pode usar a mesma conta que a mencionada acima)





n Essa conta também requer a permissão do Active Directory chamada Gravar Todas as Propriedades em todos os objetos descendentes da Unidade Organizacional (UO) de destino que você pretenda usar para farms e áreas de trabalho virtuais VDI.


☐ Grupos do Active Directory

n Administradores do Horizon Cloud — Grupo de segurança do Active Directory para administradores do Horizon Cloud. Contém a conta de ingresso no domínio e usuários administrativos do Horizon Cloud. Esse grupo é adicionado à função de super administrador no Horizon Cloud.

n Usuários do Horizon Cloud — Grupo de segurança do Active Directory para os usuários que terão acesso a áreas de trabalho virtuais e aplicativos publicados e áreas de trabalho baseadas em sessão RDS no Horizon Cloud.

☐ Unidade organizacional (OU) ou unidades organizacionais (UOs) do Active Directory para áreas de trabalho virtuais e áreas de trabalho com base em sessão RDS ou aplicativos publicados ou ambos.

Requisitos de registro DNSDepois que o pod é implantado na nuvem do Microsoft Azure e, dependendo da sua situação de negócios e dos recursos que você deseja aproveitar, é importante configurar os registros no servidor DNS que mapeia nomes de domínio totalmente qualificados (FQDNs) para endereços IP relacionados ao pod.


VMware, Inc. 22





☐ O registro DNS público criado para o acesso externo do usuário final que corresponde ao FQDN, apontando para o balanceador de carga externo do Microsoft Azure na configuração externa do Unified Access Gateway do pod (necessário quando o pod implantado tem essa configuração). Para obter mais detalhes, consulte Como configurar um nome de domínio personalizado para um serviço de nuvem do Azure.

☐ O registro DNS interno criado para o acesso interno do usuário final que corresponde ao FQDN, apontando para o balanceador de carga interno do Microsoft Azure na configuração interna do Unified Access Gateway do pod (necessário quando o pod implantado tem essa configuração).

☐ Registro DNS interno criado para conexões do VMware Workspace ONE Access com o pod que corresponde ao certificado que você carregará para o pod em si, apontando para o balanceador de carga interno do Microsoft Azure do gerenciador de pod. Obrigatório quando você deseja usar o VMware Workspace ONE Access com o pod.

Observação Esse registro DNS interno e um certificado correspondente que é carregado no próprio pod também são usados no caso de uso raro e atípico em que você precisa pedir que os usuários finais internos se conectem diretamente ao pod, em vez de pedir que se conectem a uma configuração interna do Unified Access Gateway no pod. Essas conexões diretas são um caso de uso atípico. Normalmente, é usado um Unified Access Gateway interno.

☐ Cadeia de certificados (certificado de autoridade de certificação, certificado SSL, arquivo de chave SSL) que corresponde ao registro DNS interno criado para conexões do VMware Workspace ONE Access com o pod. Para obter mais detalhes, consulte Carregar certificados SSL em um pod do Horizon Cloud para conexões diretas. (Também necessário se você estiver utilizando o caso de uso atípico de pedir que usuários finais internos se conectem diretamente ao pod. As conexões diretas são um uso raro e atípico. Normalmente, é usado um Unified Access Gateway interno.)

Imagem de base, áreas de trabalho e farms do Horizon CloudSua assinatura do Microsoft Azure deve acomodar os seguintes requisitos, dependendo dos tipos de imagens mestre, das áreas de trabalho VDI e dos farms RDS que você deseja provisionar a partir do pod implantado.

☐ Base para a imagem mestre: uma das configurações de VM do Microsoft Azure com suporte.

n Standard_D4_v3 ou Standard_D2_v2

n Standard_NV6

☐ Seleção de modelo para as VMs de área de trabalho nas atribuições de área de trabalho VDI: qualquer uma das configurações de VM do Microsoft Azure disponíveis na região do Microsoft Azure, exceto aquelas não compatíveis com operações de área de trabalho do Horizon Cloud.

Para ambientes de produção, o teste de dimensionamento da VMware recomenda o uso de modelos que tenham no mínimo 2 CPUs ou mais.

☐ Seleção de modelo para as VMs RDSH em farms: qualquer uma das configurações de VM do Microsoft Azure disponíveis na região do Microsoft Azure, exceto aquelas não compatíveis com operações de farm RDS do Horizon Cloud.

Esse requisito também se aplica a uma VM que executa as várias sessões do Windows 10 Enterprise da Microsoft quando essa VM é usada com o Horizon Cloud. Conforme descrito nas Perguntas frequentes sobre as várias sessões do Windows 10 Enterprise da Microsoft na documentação da área de trabalho virtual do Windows do Microsoft Azure, o com as várias sessões do Windows 10 Enterprise da Microsoft é um tipo de host de sessão de área de trabalho remota (RDSH) que permite várias sessões interativas simultâneas, que anteriormente eram fornecidas apenas pelos sistemas operacionais do Microsoft Windows Server. Os fluxos de trabalho do Horizon Cloud que se aplicam a servidores RDS são aplicáveis às várias sessões do Microsoft Windows 10.

Para ambientes de produção, o teste de dimensionamento da VMware recomenda o uso de modelos que tenham no mínimo 2 CPUs ou mais.


VMware, Inc. 23

https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-custom-domain-name

https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-custom-domain-name

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-23E74933-1441-42A3-AEE9-A95FD1555E03.html

https://docs.microsoft.com/en-us/azure/virtual-desktop/windows-10-multisession-faq

https://docs.microsoft.com/en-us/azure/virtual-desktop/windows-10-multisession-faq

Licenciamento para os sistemas operacionais Microsoft WindowsOs itens estão relacionados aos sistemas operacionais Microsoft Windows nas suas imagens mestre de base, nas VMs de farm compatíveis com RDSH e nas VMs de área de trabalho virtual. Para obter a lista de sistemas operacionais Microsoft Windows compatíveis com o Horizon Cloud, consulte o Artigo 78170 da base de dados de conhecimento da VMware e o Artigo 70965 da base de dados de conhecimento da VMware.

O Horizon Cloud não fornece nenhum licenciamento de sistema operacional convidado necessário para o uso de sistemas operacionais Microsoft Windows que você utiliza durante o uso dos fluxos de trabalho do Horizon Cloud. Você, o cliente, tem a responsabilidade de possuir licenças válidas e elegíveis da Microsoft que lhe autorizem a criar, realizar fluxos de trabalho nas e operar as VMs de área de trabalho baseadas no Windows e as VMs RDSH que você escolhe usar em seu ambiente de tenant do Horizon Cloud. O licenciamento necessário depende do uso pretendido.

Dica Para obter informações sobre o licenciamento da área de trabalho virtual do Microsoft Windows para as várias sessões do Windows 10 Enterprise e para o Windows 7 Enterprise, consulte o tópico da documentação do Microsoft Azure denominado Preços da área de trabalho virtual do Windows.

☐ Licenciamento para um ou mais dos seguintes tipos: Microsoft Windows 7 Enterprise, Microsoft Windows 10 (tipos de cliente)

☐ Licenciamento para as várias sessões do Windows 10 Enterprise da Microsoft

☐ Licenciamento para um ou mais dos seguintes tipos: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019

☐ Servidores de licenciamento Microsoft Windows RDS – para alta disponibilidade, são recomendados servidores de licenciamento redundantes

☐ CAL por usuário ou CAL por dispositivo do Microsoft RDS ou ambas

Arquitetura de referênciaUse os diagramas de arquitetura abaixo como referência.


VMware, Inc. 24





https://azure.microsoft.com/en-us/pricing/details/virtual-desktop/

Figura 1-1. Ilustração da Arquitetura do Cloud Pod do Horizon para um pod com alta disponibilidade habilitada, com configurações de gateway interno ou externo, o gateway externo implantado na mesma VNet que o pod e um IP público habilitado para o balanceador de carga do gateway externo

VM VM VM VM VM VM VM VM

Rede de gerenciamento

AdminPlano de Controledo Horizon Cloud Internet

Usuárioexterno

Usuáriointerno

VPN do gateway ou

ExpressRoute

Balanceador de Carga doMicrosoft Azure

BDPostgres

VM base Imagempublicada

RG: vmw-hcs-<podID>-pool-1001

RG: vmw-hcs-<podID>-pool-100n

RG: vmw-hcs-<podID>-base-vms

RG: vmw-hcs-<podID>-jumpbox

VM: Caixa de salto (temporária)

NIC/IP

RG: vmw-hcs-<podID>

VM: Gerenciador

de Pod 1

VM: Gerenciador

de Pod 2

RedeDMZ

IP público

VM: UnifiedAccess

Gateway 1

VM: UnifiedAccess

Gateway 2

VM: UnifiedAccess

Gateway 1

VM: UnifiedAccess

Gateway 2


RG: vmw-hcs-<podID>-uag

RG: vmw-hcs-<podID>-uag-internal

Rede deLocatário

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

Balanceador de carga interno do

Microsoft Azure

2 Gateway de VPNcom túnel IPsec

Conectado à rede externa

Gateway de VPN(opcional)



VMware, Inc. 25

Figura 1-2. Ilustração dos elementos de arquitetura do gateway externo quando o gateway externo é implantado em sua própria VNet, separado da VNet do pod e em um grupo de recursos criado pelo implantador do pod

Sub-rede de gerenciamento da VNet-2

Admin InternetCamada de controle do

Horizon CloudUsuárioexterno


RG para jumpbox temporária

NIC/IP

VM: Conector

RG para a VM do conectordo gateway

externo

RG para recursos do gateway externo

NIC/IP

Sub-rede (front-end) de zona desmilitarizada da VNet-2

VNet-2

VM: UAG-1


IP do balanceador de carga

Sub-rede de back-end da VNet-2

NIC/IP

NIC/IP

NIC/IP

VM: UAG-2

NIC/IP

NIC/IP

NIC/IP

RecursosConsulte os recursos a seguir para obter informações adicionais.

n Página de documentação do VMware Horizon Cloud Service, para links para os guias do produto e notas de versão

n Página de documentação do VMware Unified Access Gateway

n Tutorial de início rápido para o VMware Horizon Cloud on Microsoft Azure

n Visão geral do Microsoft Azure Resource Manager (cinco minutos)

n Criar a entidade de serviço do Microsoft Azure usando o portal (seis minutos)

n Rede virtual do Microsoft Azure (VNet) (cinco minutos)

n Emparelhamento de rede virtual do Microsoft Azure (seis minutos)


VMware, Inc. 26

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/index.html

https://docs.vmware.com/br/Unified-Access-Gateway/

https://techzone.vmware.com/quick-start-tutorial-vmware-horizon-cloud-service-microsoft-azure

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview

https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal?view=azure-cli-latest


https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

VMware Horizon 7 com a lista de verificação de requisitos do Horizon Cloud - Atualizado para a versão de serviço de março de 2020Conclua as tarefas a seguir para preparar seu ambiente local do Horizon 7 ou no VMware Cloud on AWS para conexão com o Horizon Cloud. Garanta que todas as etapas estejam concluídas, conforme descrito abaixo, para concluir uma implantação exitosa.



n Requisitos do Horizon 7 Cloud Connector e do pod do Horizon 7


n Licenciamento

Requisitos de camada de controle do Horizon Cloud

☐ Conta ativa do My VMware para fazer logon na camada de controle do Horizon Cloud.

☐ Licença universal válida do Horizon. Para obter mais informações, consulte a página Licença Universal do Horizon.

Requisitos do Active Directory

☐ Níveis funcionais de domínio do Microsoft Windows Active Directory Domain Services (AD DS) compatíveis:






☐ 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ê conectar ou implantar esses pods.

☐ Conta de BIND de domínio




☐ Conta de BIND de domínio auxiliar — não pode usar a mesma conta que a mencionada acima





VMware, Inc. 27






☐ Conta de ingresso no domínio





n Essa conta também requer a permissão do Active Directory chamada Gravar Todas as Propriedades nos objetos de OU descendentes da Unidade Organizacional (UO) de destino que pretende usar para farms e atribuições de área de trabalho VDI.


☐ Conta de ingresso no domínio auxiliar (opcional, não pode usar a mesma conta que a mencionada acima)





n Essa conta também requer a permissão do Active Directory chamada Gravar Todas as Propriedades nos objetos de OU descendentes da Unidade Organizacional (UO) de destino que pretende usar para farms e atribuições de área de trabalho VDI.


☐ Grupos do Active Directory

n Administradores do Horizon Cloud — Grupo de segurança do Active Directory para administradores do Horizon Cloud. Contém a conta de ingresso no domínio e usuários administrativos do Horizon Cloud. Esse grupo é adicionado à função de super administrador no Horizon Cloud.

n Usuários do Horizon Cloud — Grupo de segurança do Active Directory para os usuários que terão acesso a áreas de trabalho virtuais e aplicativos publicados e áreas de trabalho baseadas em sessão RDS no Horizon Cloud.

Requisitos do Horizon 7 Cloud Connector e do pod do Horizon 7

☐ Pod do Horizon 7 com no mínimo o Horizon 7 7.10 ou posteriores. Para obter o uso dos serviços e recursos de nuvem mais recentes com o pod conectado à nuvem, ele deve ter a versão mais atual, o Horizon 7 7.12.

☐ Dispositivo virtual do Horizon 7 Cloud Connector, no mínimo a versão 1.5 ou posteriores. Para obter o uso dos serviços e recursos de nuvem mais recentes com o pod conectado à nuvem, ele deve ter a versão mais atual, o Horizon 7 Cloud Connector 1.6.

n IP estático

n Registros de pesquisa direta e inversa de DNS


VMware, Inc. 28





☐ Requisitos de recursos para o dispositivo virtual do Horizon 7 Cloud Connector:

n Para a versão 1.5: 8 vCPUs, 8 GB de memória (RAM), 40 GB de disco rígido

n Para a versão 1.6 (mais recente): 8 vCPUs, 8 GB de memória (RAM), 40 GB de disco rígido

Importante Juntamente com a capacidade de reserva para os componentes de gerenciamento do Horizon 7, como as VMs do Servidor de Conexão, as VMs do Unified Access Gateway e outros componentes, você deve planejar a reserva de capacidade para o componente do Horizon 7 Cloud Connector. O Horizon 7 Cloud Connector é um componente de infraestrutura implantado no ambiente de pod do Horizon 7 para conectar um pod do Horizon 7 ao Horizon Cloud para os casos de uso do uso de licenças de assinatura do Horizon e serviços hospedados na nuvem com esse pod.

☐ Usuário do Active Directory usado no processo de integração do pod ao emparelhar o Horizon 7 Cloud Connector com o Servidor de Conexão do Horizon 7. Este usuário do Active Directory deve ter a função Administradores predefinida do Horizon 7 no grupo de acesso raiz, conforme exibido no Console do Horizon do pod do Horizon 7 em Exibição de Administradores Globais > Permissões de Função > Administradores. Em outras palavras, o usuário do Active Directory especificado para o processo de integração de pod é um superusuário desse pod, conforme descrito na documentação do Horizon 7 Guia de administração do Console do Horizon.

Requisitos de portas e protocolos

☐ Portas e protocolos específicos são necessários para a continuidade das operações do Horizon 7 Cloud Connector e do ambiente de tenant do Horizon Cloud. Consulte Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7.

☐ Licença universal válida do Horizon. Para obter mais informações, consulte a página Licença Universal do Horizon.

LicenciamentoO Horizon Cloud não fornece nenhum licenciamento de sistema operacional convidado necessário para o uso de sistemas operacionais Microsoft Windows que você utiliza durante o uso dos fluxos de trabalho do Horizon Cloud. Você, o cliente, tem a responsabilidade de possuir licenças válidas e elegíveis da Microsoft que lhe autorizem a criar, realizar fluxos de trabalho nas e operar as VMs de área de trabalho baseadas no Windows e as VMs RDSH que você escolhe usar em seu ambiente de tenant do Horizon Cloud. Os requisitos específicos para os itens na tabela abaixo serão determinados por suas escolhas dos tipos que pretende usar no ambiente do seu tenant.

☐ Licenciamento para um ou mais dos seguintes tipos: Microsoft Windows 7, Microsoft Windows 10

☐ Licenciamento para um ou mais dos seguintes tipos: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019

☐ Servidores de licenciamento Microsoft Windows RDS – para alta disponibilidade, são recomendados servidores de licenciamento redundantes

☐ CAL por usuário ou CAL por dispositivo do Microsoft RDS ou ambas


VMware, Inc. 29

https://docs.vmware.com/br/VMware-Horizon-7/7.11/horizon-console-administration/GUID-D1FB63B9-1812-472C-AA06-820018216CFB.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.getstarted15/GUID-2EA5CC20-0452-4BC2-A898-30F493C21DC5.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.getstarted15/GUID-2EA5CC20-0452-4BC2-A898-30F493C21DC5.html


Integração do primeiro pod conectado à nuvem ao ambiente do tenant do Horizon Cloud 2Use os tópicos neste guia quando estiver iniciando sua jornada com o VMware Horizon® Cloud Service™ do começo. No início dessa jornada, seu ambiente de tenant do Horizon Cloud começa como novo, sem nenhum pod conectado à nuvem. A primeira etapa é integrar um pod nesse novo ambiente. Esse pod será o primeiro pod conectado à nuvem. Os tópicos que seguem este tópico descrevem como você obtém esse primeiro pod conectado à nuvem de qualquer um dos tipos de pod atualmente disponíveis para o Horizon Cloud.

Para obter uma descrição de alto nível do processo de obtenção de um ambiente de tenant do Horizon Cloud e como ele se relaciona com a integração de um pod, consulte Integração ao Horizon Cloud para Microsoft Azure, Horizon 7 no local e Horizon 7 on VMware Cloud on AWS.

A seguinte captura de tela é um exemplo representativo da aparência do novo ambiente do Horizon Cloud quando você faz login na sua conta pela primeira vez.

VMware, Inc. 30

Essa tela de primeira vez é orientada em torno da ideia de adicionar capacidade. Você pode pensar em adicionar capacidade aqui como o equivalente a implantar pods em vários ambientes de capacidade e conectar esses pods ao seu ambiente geral do Horizon Cloud.

O que o texto na tela diz Como este texto se refere ao seu primeiro pod conectado à nuvem

Saiba como adicionar capacidade local... Use essa opção quando quiser que seu primeiro pod conectado à nuvem seja um pod do Horizon 7 existente que você tenha no local ou que você tenha configurado manualmente no VMware Cloud on AWS. Clicar no link na interface do usuário o informa para baixar o Horizon Cloud Connector. Em seguida, siga as etapas no tópico Fluxo de trabalho de alto nível durante a integração de um pod do Horizon 7 existente implantado manualmente como seu primeiro pod ao seu ambiente de tenant do Horizon Cloud.

Adicionar Capacidade de Nuvem ... Nuvem do Microsoft Azure

Use essa opção quando quiser que seu primeiro pod conectado à nuvem seja um criado pela implantação automática orientada por assistente de um pod no Microsoft Azure. Quando esse processo é concluído, esse pod é o seu primeiro pod conectado à nuvem. Se você estiver interessado neste tipo para o seu primeiro pod conectado à nuvem, saiba como proceder do tópico Quando você escolhe a capacidade de nuvem do Microsoft Azure para a implantação do seu primeiro pod e de seus subtópicos.

Adicionar Capacidade de Nuvem ... VMware Cloud on AWS

Use essa opção quando quiser que seu primeiro pod conectado à nuvem seja um pod do Horizon 7 localizado no VMware Cloud on AWS. Quando a sua conta de cliente do Horizon Cloud tem a configuração padrão, clicar em Adicionar e na opção VMware Cloud on AWS o informa para baixar o Horizon Cloud Connector. Em seguida, siga as etapas em Fluxo de trabalho de alto nível durante a integração de um pod do Horizon 7 existente implantado manualmente como seu primeiro pod ao seu ambiente de tenant do Horizon Cloud.


VMware, Inc. 31

Depois que o seu primeiro pod estiver integrado ao ambiente de tenant, use a Guia de administração do Horizon Cloud complementar para ler sobre como concluir o fluxo de trabalho de registro de domínio do Active Directory com esse primeiro pod conectado à nuvem. Após a conclusão do registro de domínio, você continua usando o Guia de administração do Horizon Cloud complementar para conhecer todos os fluxos de trabalho que você pode fazer com o Horizon Cloud, incluindo adicionar mais pods. Nesse guia, comece com o tópico Introdução ao Horizon Cloud, a Introdução ao uso do ambiente do Horizon Cloud e seus subtópicos.

Observação n Se você tiver um pod do Horizon 7 criado manualmente no VMware Cloud on AWS que gostaria de

conectar ao Horizon Cloud, poderá usar o fluxo de trabalho adicionar capacidade local para conectar esse pod existente. Se esse fosse o primeiro fluxo de trabalho de adição de capacidade que você concluir, esse pod se tornaria o seu primeiro pod conectado à nuvem. Antes de iniciar as etapas descritas neste documento, consulte também o VMware Horizon 7 com a lista de verificação de requisitos do Horizon Cloud - Atualizado para a versão de serviço de março de 2020. Essa lista de verificação fornece uma boa visão geral dos vários elementos de pré-requisito necessários para ter sucesso com a sua primeira implantação de pod no VMware Cloud on AWS.

n Se estiver adicionando capacidade de nuvem do Microsoft Azure como o primeiro pod conectado à nuvem, antes de iniciar todas as etapas descritas neste documento, consulte também a Lista de verificação de requisitos do VMware Horizon Cloud Service on Microsoft Azure para novas implantações do pod — Atualizada para o versão de serviço de 2020. Essa lista de verificação fornece uma boa visão geral dos vários elementos de pré-requisito necessários para ter sucesso com a sua primeira implantação de pod no Microsoft Azure.

Este capítulo inclui os seguintes tópicos:

n Durante a integração de um pod do Horizon 7 para usar licenças de assinatura do Horizon ou serviços hospedados em nuvem com esse pod

n Quando você escolhe a capacidade de nuvem do Microsoft Azure para a implantação do seu primeiro pod

Durante a integração de um pod do Horizon 7 para usar licenças de assinatura do Horizon ou serviços hospedados em nuvem com esse podQuando a interface do usuário do Horizon Cloud refere-se à capacidade local ou à capacidade de nuvem do VMware Cloud on AWS, isso significa que seus pods do VMware Horizon 7 que você instalou e configurou manualmente em sua infraestrutura local ou no VMware Cloud on AWS SDDC. Você integra tais pods do Horizon 7 ao ambiente do tenant do Horizon Cloud para dois casos de uso principais: para aplicar uma licença de assinatura com o pod do Horizon 7 e para usar serviços hospedados na nuvem com ele. Quando a licença de assinatura é ativada nesse pod, essa ativação também oferece a capacidade de aproveitar esses serviços hospedados na nuvem. Tais serviços incluem recursos e fluxos de trabalho para os pods conectados à nuvem. Ambos os casos de uso exigem o uso do VMware Horizon® 7 Cloud Connector™, o componente que conecta sua implantação do Horizon 7 com o plano


VMware, Inc. 32

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-3E17DDDC-807B-4952-A1D3-F37364925AA3.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-A4FA2F8E-6AF5-4F4A-9437-01107591337F.html

de gerenciamento com base na nuvem do Horizon Cloud. Essa conexão provê tanto para aplicar a licença de assinatura à implantação do Horizon 7 quanto para habilitar serviços hospedados na nuvem, como o Serviço de Monitoramento da Nuvem (CMS).

Para obter uma descrição de alto nível do processo de primeira integração de qualquer um dos tipos de pod com suporte à camada de controle da nuvem, consulte Integração ao Horizon Cloud para Microsoft Azure, Horizon 7 no local e Horizon 7 on VMware Cloud on AWS.

VMs CS

Serviço degerenciamento

Integridade dosistema

Cloud Connector

Pod do Horizon 7

Serviço deMonitoramento da

Nuvem (CMS)

Serviço delicença

AD

Plano de gerenciamento do Horizon Cloud

API do Horizon

Importante Seu ambiente de Horizon Cloud pode consistir em pods no VMware Cloud on AWS e nos pods locais do Microsoft Azure e do Horizon 7. Como resultado, todos esses pods conectados à nuvem devem ter linha de visão para o mesmo conjunto de domínios do Active Directory. Se o seu ambiente já tiver pods no Microsoft Azure e você estiver conectando seu primeiro pod do Horizon 7, deverá garantir que o pod do Horizon 7 tenha uma linha de visão para os domínios do Active Directory que já estão registrados no seu ambiente do Horizon Cloud quando você conecta o pod do Horizon 7. Para obter detalhes sobre o fluxo de trabalho de registro de domínio do Active Directory, consulte Como realizar seu primeiro registro de domínio do Active Directory no ambiente do Horizon Cloud.

Como ativar licenças de assinatura e habilitar serviços hospedados na nuvem para pods do Horizon 7 usando o Horizon 7 Cloud ConnectorO Horizon 7 Cloud Connector é um dispositivo virtual que conecta o pod de um Horizon 7 ao Horizon Cloud. O Horizon 7 Cloud Connector é necessário para usar serviços hospedados na nuvem com seu pod do Horizon 7, incluindo as licenças de assinatura do Horizon 7, o dashboard de status de integridade e a ferramenta de suporte técnico do Horizon.

licenças de assinatura do Horizon 7

As licenças de assinatura do Horizon 7 estão disponíveis com o pacote do Horizon 7 autônomo e como parte do pacote empresarial do Workspace


VMware, Inc. 33



ONE. A licença de assinatura do Horizon 7 fornece o mesmo produto com mais opções de implantação flexível. As licenças de assinatura do Horizon 7 permitem a implantação do Horizon 7 no centro de dados, na nuvem privada e no VMware Cloud on AWS. Quando você tiver concluído as etapas usando o Horizon 7 Cloud Connector para integrar seu pod ao Horizon Cloud, a VMware ativará sua licença de assinatura. Dentro de 48 horas, o serviço de licença aplica a licença a esse pod conectado à nuvem, e uma mensagem é exibida na tela de licenciamento do Horizon 7 Administration:

Você deve ter uma conta ativa do My VMware para comprar uma licença do Horizon 7 em https://my.vmware.com. Em seguida, você receberá um e-mail de boas-vindas com o link para baixar o Horizon 7 Cloud Connector como um arquivo OVA.

Ao implantar o dispositivo virtual do Horizon 7 Cloud Connector do vSphere Web Client, você emparelhará o Cloud Connector com o Servidor de conexão do pod que deseja conectar ao Horizon Cloud para usar licenças de assinatura ou serviços hospedados na nuvem. Como parte do processo de emparelhamento, o dispositivo virtual do Horizon 7 Cloud Connector conecta o Servidor de conexão ao Horizon Cloud para gerenciar a licença de assinatura do Horizon 7 e outros serviços. Com uma licença de assinatura do Horizon 7, você não precisa inserir manualmente uma chave de licença do Horizon 7 para a ativação do produto VMware Horizon 7. No entanto, você precisa usar as chaves de licença para ativar os componentes de suporte, como vSphere, o App Volumes e outros.

Serviços hospedados na nuvem para pods do Horizon 7

Quando você concluir as etapas usando o Horizon 7 Cloud Connector para conectar seu pod ao Horizon Cloud, além de aplicar uma licença de assinatura, você poderá aproveitar esses serviços, recursos e fluxos de trabalho hospedados na nuvem fornecidos pelo Horizon Cloud e que estão disponíveis para você de acordo com essa licença de assinatura, como o Serviço de Monitoramento da Nuvem (CMS). Consulte Introdução aos recursos de suporte técnico, monitoramento de integridade e visibilidade unificada do Serviço de Monitoramento da Nuvem fornecidos no Horizon Cloud.


VMware, Inc. 34


https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-9815E322-A13F-4E0A-B4F7-98B34A054D8F.html




Fluxo de trabalho de alto nível durante a integração de um pod do Horizon 7 existente implantado manualmente como seu primeiro pod ao seu ambiente de tenant do Horizon CloudEsta lista é um alto nível das etapas durante a integração do primeiro pod ao ambiente de tenant do Horizon Cloud, e esse pod é um pod do Horizon existente implantado manualmente. Um pod manualmente implantado é um que você instalou e configurou manualmente usando capacidade local ou usando a capacidade do VMware Cloud on AWS. Após a conclusão dessas etapas de integração do primeiro pod conectado à nuvem, a licença de assinatura é aplicada ao pod do Horizon 7, e você pode começar a usar os serviços hospedados na nuvem que o Horizon Cloud fornece para esse tipo de pod, que inclui o Serviço de Monitoramento da Nuvem (CMS). Nesse ponto, você também pode integrar pods adicionais.

O diagrama a seguir ilustra o fluxo geral.

VM

vAPP

Obter licença de assinatura/universal do Horizon

Baixar e implantar o Horizon 7 Cloud Connector OVA no pod do Horizon 7 usando um IP estático

Registrar o domínio do AD do pod no Horizon Cloud

Emparelhar o pod e o Horizon 7 Cloud Connector implantado com o Horizon Cloud

Antes de começar esse fluxo de trabalho, você deve ter instalado e configurado o pod do Horizon 7. Para obter informações sobre como instalar manualmente um pod do Horizon 7 que você pode usar com esta versão do Horizon Cloud:

n Para a instalação manual de pods usando a capacidade local, consulte as informações de instalação relevantes para a versão mais recente do Horizon 7 na página de documentação do Horizon 7.

n Para a instalação manual de pods usando a capacidade do VMware Cloud on AWS, confira o guia de práticas recomendadas para implantar o Horizon 7 no VMware Cloud on AWS, disponível na página de produto do Horizon 7 no VMware Cloud on AWS.

Você integra um pod existente do Horizon 7 à nuvem para dois casos de uso primários: para ativar uma licença de assinatura para esse pod e permitir o uso desses serviços hospedados em nuvem que o Horizon Cloud fornece para esse tipo de pod, como o Serviço de Monitoramento da Nuvem (CMS). O CMS é um dos serviços centrais fornecidos no Horizon Cloud. O CMS fornece visibilidade,


VMware, Inc. 35

https://docs.vmware.com/br/VMware-Horizon-7/index.html

https://www.vmware.com/products/horizon/horizon-on-vmc-aws.html

https://www.vmware.com/products/horizon/horizon-on-vmc-aws.html

monitoramento de integridade e serviços de suporte técnico com pods conectados à nuvem. Para obter uma descrição de alto nível do processo de integração de um pod à camada de controle da nuvem, consulte Integração ao Horizon Cloud para Microsoft Azure, Horizon 7 no local e Horizon 7 on VMware Cloud on AWS.

Cuidado Conclua todas as etapas abaixo para conectar totalmente seu primeiro pod ao Horizon Cloud antes de começar a implantar o Horizon 7 Cloud Connector com todos os pods instalados manualmente subsequentes que você deseja conectar. Devido a um problema conhecido nesta versão, se você concluir a conexão de mais de um pod à nuvem usando o Horizon 7 Cloud Connector antes de concluir a etapa de registro de domínio do Active Directory e atribuição da função de Super Administrador pelo menos uma vez, a etapa de registro de domínios do Active Directory falhara. Nesse ponto, você terá que desconectar todos os pods do Horizon 7 conectados à número, com exceção de um, para poder concluir com êxito a etapa de registro de domínio do Active Directory e atribuição da função de Super Administrador.

1 Atenda aos pré-requisitos, que incluem a obtenção de uma licença de assinatura do Horizon, como a licença do Horizon Universal. Consulte VMware Horizon 7 com a lista de verificação de requisitos do Horizon Cloud - Atualizado para a versão de serviço de março de 2020, bem como a seção de pré-requisitos no Conecte o Horizon Cloud Service com um pod existente do Horizon 7 para usar licenças de assinatura ou serviços hospedados na nuvem do Horizon ou ambos.

2 Verifique se você atende aos requisitos de DNS, de portas e de protocolo para conectar um pod do Horizon 7 ao Horizon Cloud. Consulte Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7.

3 Se o ambiente exigir o uso de um servidor proxy para o dispositivo virtual do Horizon 7 Cloud Connector acessar a Internet, obtenha as configurações de proxy necessárias para que você possa especificá-las ao implantar o modelo OVF do dispositivo.

Importante Se você planeja usar o Agente Universal do Horizon com o Horizon 7 Cloud Connector 1.5 e precisa usar configurações de proxy, deverá definir essas configurações de proxy ao implantar o modelo OVF. Devido a uma limitação conhecida, o Agente Universal do Horizon não vai captar as alterações nas configurações de proxy feitas no dispositivo do Horizon 7 Cloud Connector após o processo de implantação inicial.

Devido a um problema conhecido, o sistema não está respeitando nenhuma configuração de host sem proxy que você especificou na implantação inicial do modelo OVF. Para usar uma configuração de host sem proxy com o dispositivo do Horizon 7 Cloud Connector, você deve configurá-lo após o processo de implantação inicial. Consulte Como modificar as configurações de proxy para o Horizon 7 Cloud Connector 1.5 ou anterior para ver mais detalhes.


VMware, Inc. 36


4 Opcionalmente, faça logon no portal de tenant do Horizon Cloud e configure administradores adicionais para o ambiente de tenant.

Dica Mesmo que você possa concluir as próximas etapas para incorporar o pod usando apenas a conta My VMware que é a primeira associada ao seu ambiente de tenant, é prudente configurar administradores adicionais no início desse processo. Se apenas uma única conta My VMware estiver associada à sua conta de tenant, e você perder o acesso às credenciais, poderão ocorrer atrasos porque você terá que abrir uma solicitação de serviço junto à VMware para associar uma nova conta My VMware à conta de tenant. Para evitar esses atrasos, faça logon no portal de tenant em cloud.horizon.vmware.com com a conta My VMware inicialmente associada e siga as etapas descritas em Adicionar administradores para fazer logon no seu ambiente de tenant do Horizon Cloud usando a linha na seção Configuração Geral da tela.

5 Implante o dispositivo virtual do Horizon 7 Cloud Connector no ambiente do pod. Siga as etapas de implantação OVA descritas em Baixar e implantar o Cloud Connector no ambiente do vSphere do pod.

6 Depois que o dispositivo virtual é ligado, ative o acesso SSH ao dispositivo virtual para executar comandos remotamente no sistema operacional do dispositivo. Você deve usar seu ambiente do vSphere para inicializar o console do dispositivo do, fazer login no sistema operacional do dispositivo usando o usuário raiz que você definiu durante a implantação do dispositivo e executar os comandos apropriados para ativar o SSH. Siga as etapas em Habilitar o acesso do SSH ao Horizon 7 Cloud Connector antes de emparelhá-lo com o Servidor de Conexão do Horizon 7.

Observação Essas etapas para ativar o SSH são usadas para o momento em que o pod ainda não é emparelhado com o Horizon Cloud. Depois que o pod for emparelhado com sucesso com o Horizon Cloud, você poderá usar o portal de configuração do Horizon 7 Cloud Connector baseado em navegador para ativar e desativar o acesso do SSH ao dispositivo virtual.

7 Se o seu ambiente exigir o uso de um proxy e você não tiver especificado as configurações relacionadas ao proxy no assistente de implantação do OVF, defina as configurações relacionadas ao proxy para o dispositivo virtual. Consulte Como modificar as configurações de proxy para o Horizon 7 Cloud Connector 1.5 ou anterior para ver mais detalhes.

8 Se você quiser acessar o portal de configuração do Horizon 7 Cloud Connector baseado em navegador usando um nome de domínio totalmente qualificado (FQDN) em vez de usar o endereço IP do dispositivo virtual do Horizon 7 Cloud Connector, crie um registro de pesquisa direta e inversa no seu servidor DNS que mapeie um FQDN para o endereço IP do dispositivo virtual.


VMware, Inc. 37

https://cloud.horizon.vmware.com



9 Verifique a integridade dos componentes e serviços do sistema do pod abrindo uma sessão do SSH no dispositivo virtual do Horizon 7 Cloud Connector e executando o script de diagnóstico precheck.sh. Consulte Verifique se o pod do Horizon 7 e o Horizon 7 Cloud Connector estão prontos para serem emparelhados para ver mais detalhes.

10 Usando um FQDN mapeado ou o endereço IP do dispositivo virtual, faça login no portal de configuração do Horizon 7 Cloud Connector baseado em navegador e conclua as etapas de integração que emparelham o conector com o Servidor de Conexão do pod. Siga as etapas descritas em Concluir o emparelhamento do pod do Horizon 7 com o Horizon Cloud usando o portal de configuração do Horizon 7 Cloud Connector.

Dica Quando o conector e o Servidor de Conexão forem emparelhados com êxito, o portal de configuração do Horizon 7 Cloud Connector exibirá uma mensagem de Parabéns. Neste momento, a VMware ativará sua licença de assinatura. A ativação pode levar até 48 horas. Quando a licença estiver ativada, você verá a mensagem Conectado ao Serviço de Licença na tela padrão Horizon 7 Uso e Licenciamento de Produto.

11 Dependendo das suas práticas e do ambiente padrão da sua equipe, configure opcionalmente o dispositivo virtual do Horizon 7 Cloud Connector em áreas, como configurar um certificado assinado pela CA e definir uma expiração de senha para o usuário raiz do dispositivo. Consulte o tópico .

12 Preencha o fluxo de trabalho de registro de domínio do Active Directory no portal de tenant do Horizon Cloud, conhecido como Console Administrativo. Consulte o tópico Tarefas de administração e manutenção típicas que você executa no Horizon 7 Cloud Connector depois que o pod do Horizon 7 é emparelhado com o Horizon Cloud no Guia de administração.

Dica Concluir o fluxo de trabalho de registro de domínio do Active Directory permite que você aproveite todos os serviços hospedados na nuvem, como o Serviço de Monitoramento da Nuvem (CMS). Até que o domínio do Active Directory do pod seja registrado com seu ambiente de tenant, o portal do bloqueia o acesso às telas do Console Administrativo em que os dados de monitoramento do CMS são exibidos.

13 Conceda a função de Superadministradores do Horizon Cloud a um grupo do Active Directory que inclua essa conta de ingresso no domínio como um membro. Consulte o tópico Atribuir funções administrativas do Horizon Cloud a grupos do Active Directory no Guia de administração.


VMware, Inc. 38

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-6835A0B9-06F4-4A38-93BD-E139DAC4BF66.html



https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-1DD4F3A7-E3CB-4786-A2D4-C356C0EDA9CE.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-1DD4F3A7-E3CB-4786-A2D4-C356C0EDA9CE.html

Você pode encontrar mais detalhes sobre como concluir cada etapa do fluxo de trabalho nos tópicos vinculados de cada etapa acima ou no guia complementar. Consulte o Guia de administração do Horizon Cloud.

Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7Quando você estiver usando o componente do Horizon 7 Cloud Connector com seu pod do Horizon 7, deverá configurar seus firewalls para permitir que o Cloud Connector acesse os endereços de serviço de nomes de domínio (DNS) necessários. Além disso, as configurações de proxy exigem portas e protocolos configurados, e o DNS deve resolver nomes específicos conforme descrito neste tópico. Em seguida, após a implantação do componente do Cloud Connector, e depois de você concluir as etapas para conectar com êxito o pod ao Horizon Cloud, serão necessários portas e protocolos específicos para operações contínuas entre o Horizon Cloud e o Cloud Connector.

Conforme descrito em Durante a integração de um pod do Horizon 7 para usar licenças de assinatura do Horizon ou serviços hospedados em nuvem com esse pod, o componente do Cloud Connector é usado com implantações do Horizon 7 para ativar as licenças de assinatura no Horizon 7 e habilitar o uso de serviços hospedados em nuvem com suas implantações do Horizon 7.

Requisitos de conectividade e DNS

As Conecte o Horizon Cloud Service com um pod existente do Horizon 7 para usar licenças de assinatura ou serviços hospedados na nuvem do Horizon ou ambos incluem a etapa para usar um navegador para navegar até o endereço IP do dispositivo do Cloud Connector, e uma tela de login será exibida. Ver essa tela de login requer conectividade de Internet entre o dispositivo do Cloud Connector e a camada de controle de nuvem do Horizon Cloud. O dispositivo estabelece uma conexão com a camada de controle de nuvem do Horizon Cloud inicialmente usando HTTPS e, em seguida, abre um soquete da Web usando a porta 443 de saída da Internet. Para operações em andamento, a conexão entre o dispositivo do Cloud Connector e o Horizon Cloud requer que a conexão de saída da Internet usando a porta 443 abra o tempo todo. Você deve garantir que os seguintes nomes DNS possam ser resolvidos e acessados usando-se as portas e os protocolos específicos, conforme listado na tabela a seguir.


VMware, Inc. 39



Origem Destino (nome DNS) Porta Protocolo Finalidade

Horizon 7 Cloud Connector

Um dos seguintes nomes, dependendo de qual instância regional da camada de controle do Horizon Cloud está especificada na sua conta de tenant do Horizon Cloud. A instância regional é definida quando a conta é criada, conforme descrito em Como fazer a integração ao Horizon Cloud for Microsoft Azure, ao Horizon 7 No Local e ao Horizon 7 on VMware Cloud on AWS.

n cloud.horizon.vmware.com

n cloud-us-2.horizon.vmware.com

n cloud-eu-central-1.horizon.vmware.com

n cloud-eu-2.horizon.vmware.com

n cloud-ap-southeast-2.horizon.vmware.com

n cloud-ap-2.horizon.vmware.com

443 TCP Instância da camada de controle regional do Horizon Cloud

n Estados Unidos: cloud.horizon.vmware.com, cloud-us-2.horizon.vmware.com

n Europa: cloud-eu-central-1.horizon.vmware.com, cloud-eu-2.horizon.vmware.com

n Ásia-Pacífico: cloud-ap-southeast-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com


Dependendo da camada de controle do Horizon Cloud regional especificada na sua conta do Horizon Cloud:

América do Norte:

n kinesis.us-east-1.amazonaws.com

n query-prod-us-east-1.cms.vmware.com

Europa:

n kinesis.eu-central-1.amazonaws.com

n query-prod-eu-central-1.cms.vmware.com

Austrália:

n kinesis.ap-southeast-2.amazonaws.com

n query-prod-ap-southeast-2.cms.vmware.com

443 TCP Serviço de Monitoramento da Nuvem (CMS)

Portas e protocolos necessários para o dispositivo do Horizon 7 Cloud Connector

Para operações em andamento entre o Horizon 7 Cloud Connector e o Horizon Cloud, são necessárias as portas e os protocolos na tabela a seguir.


VMware, Inc. 40

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.getstarted15/GUID-6E460805-C323-4200-9A45-45E7BFB31730.html




Tabela 2-1. Portas do Horizon 7 Cloud Connector

Origem Destino Porta Protocolo Descrição


Horizon Cloud 443 HTTPS Usado para emparelhar o Horizon 7 Cloud Connector com o Horizon Cloud e transferir dados.


Servidor de conexão 443 HTTPS Chamadas de interface de programação de aplicativos para o servidor de conexão.


Servidor de conexão 4002 TCP Comunicação do Java Message Service (JMS) entre o Cloud Connector e o Servidor de conexão

Nova versão do dispositivo do Horizon 7 Cloud Connector

Versão existente do dispositivo do Horizon 7 Cloud Connector

22 SSH Ouça as solicitações para iniciar o processo de atualização.

Navegador da Web Horizon 7 Cloud Connector

443 HTTPS Ouça a inicialização do processo de emparelhamento.


Autoridade de Certificação

* HTTP, HTTPS Consultas CRL ou OCSP

Agente do Serviço de Monitoramento da Nuvem nas VMs de área de trabalho ou de servidor que são do Horizon 7 conectado à nuvem em sua rede

Dispositivo do Horizon 7 Cloud Connector

11002 TCP Para o agente do Serviço de Monitoramento de Nuvem em uma VM de servidor ou de área de trabalho para enviar dados ao Cloud Connector

Preparação para executar o assistente de integração para emparelhar um pod do Horizon 7 com o Horizon Cloud usando o Horizon 7 Cloud ConnectorPara conectar um pod existente do Horizon 7 ao nível da versão de serviço atual com a finalidade de usar licenças de assinatura do Horizon ou serviços hospedados na nuvem com esse pod, certifique-se de ter os seguintes itens instalados antes de implantar o dispositivo Horizon 7 Cloud Connector e executar o assistente de integração.

n Verifique se você cumpriu com os pré-requisitos descritos em VMware Horizon 7 com a lista de verificação de requisitos do Horizon Cloud - Atualizado para a versão de serviço de março de 2020.

n Você determinou quais das instâncias do Servidor de Conexão do pod serão emparelhadas com o dispositivo virtual do Horizon 7 Cloud Connector e que você tem o FQDN dessa instância do Servidor de Conexão. Você só pode emparelhar o dispositivo virtual do Horizon 7 Cloud Connector com uma das instâncias do Servidor de Conexão instaladas do pod a qualquer momento.

n Você determinou qual conta de administrador do Horizon 7 será especificada quando emparelhar o Servidor de Conexão com o Horizon 7 Cloud Connector e essa conta de administrador atender aos requisitos necessários para emparelhamento. Este usuário do Active Directory deve ter a função


VMware, Inc. 41

Administradores predefinida do Horizon 7 no grupo de acesso raiz, conforme exibido no Console do Horizon do pod do Horizon 7 em Exibição de Administradores Globais > Permissões de Função > Administradores. Em outras palavras, o usuário do Active Directory especificado para o processo de integração de pod é um superusuário desse pod, conforme descrito na documentação do Horizon 7 Guia de administração do Console do Horizon.

n Você tem uma conta My VMware válida no https://my.vmware.com. Essa conta é necessária para comprar uma licença de assinatura do Horizon 7, para executar o fluxo de trabalho de integração do Horizon 7 Cloud Connector para emparelhar o pod com o serviço de nuvem e para fazer logon no Console administrativo do Horizon Cloud para usar os serviços hospedados na nuvem com esse pod.

n Uma licença de assinatura do Horizon 7 é associada a essa conta My VMware.

n Você tem as informações no e-mail de boas-vindas enviado ao endereço associado da conta My VMware, incluindo o link para baixar o Horizon 7 Cloud Connector OVA. Se você não tiver as informações do e-mail, poderá baixar o OVA fazendo logon em my.vmware.com usando essa conta My VMware e navegando até os downloads de produto listados para essa conta.

n Se você estiver usando o navegador Microsoft Internet Explorer, verifique se o modo de compatibilidade está desativado. Essa configuração permite a visualização da interface de usuário de integração do dispositivo do Horizon 7 Cloud Connector no navegador da Web.

n Verifique se você atendeu aos Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7.

n Determine o endereço IP estático que será usado para o dispositivo virtual do Horizon 7 Cloud Connector. Você precisará desse endereço IP ao implantar o Horizon 7 Cloud Connector OVA no vSphere.

Observação Não use IPv6 com o appliance virtual do Horizon 7 Cloud Connector. IPv6 não é compatível.


VMware, Inc. 42

https://docs.vmware.com/br/VMware-Horizon-7/7.11/horizon-console-administration/GUID-D1FB63B9-1812-472C-AA06-820018216CFB.html


n Verifique se tem as informações de rede típicas adequadas para seu ambiente a serem usadas quando você implantar o Horizon 7 Cloud Connector OVA no ambiente vSphere, como o domínio de pesquisa DNS, o endereço IP do servidor DNS, o endereço de gateway padrão e a máscara de sub-rede.

Observação Não há suporte para a configuração SSL do proxy para o certificado autoassinado para o dispositivo virtual do Horizon 7 Cloud Connector.

Importante Se você estiver implantando o Horizon 7 Cloud Connector 1.5 ou anterior, e o ambiente exigir o uso de um servidor proxy com o dispositivo, confira as informações descritas em Como modificar as configurações de proxy para o Horizon 7 Cloud Connector 1.5 ou anterior antes de implantar o dispositivo. Além disso, tenha em mente as seguintes limitações conhecidas. Essas limitações não se aplicam ao Horizon 7 Cloud Connector 1.6 ou posterior.

n Devido a uma limitação conhecida, qualquer configuração de host sem proxy que você especificar ao implantar o modelo OVF não será respeitada pelo sistema. Para definir uma configuração de host sem proxy para o Horizon 7 Cloud Connector 1.5 ou anterior, você deve alterar um arquivo de configuração no dispositivo após implantá-lo. Para obter detalhes, consulte o Artigo 76663 da base de dados de conhecimento da VMware.

n Se você planeja usar o pod com o Agente Universal do Horizon e o Horizon 7 Cloud Connector 1.5, e o ambiente exigir o uso de configurações de proxy, deverá definir essas configurações de proxy ao implantar o modelo OVF. Devido a uma limitação conhecida do Horizon 7 Cloud Connector 1.5, o Agente Universal do Horizon não respeitará as modificações feitas nas configurações de proxy após a implantação. Como você só pode configurar hosts sem proxy após a implantação, essa limitação significa que o Agente Universal do Horizon não oferece suporte ao uso de hosts sem proxy com o Horizon 7 Cloud Connector 1.5.

n Verifique se você tem uma senha raiz forte para o dispositivo virtual do Horizon 7 Cloud Connector que contenha pelo menos oito caracteres com uma letra maiúscula, um número e um caractere especial.

Importante Ao implantar o modelo OVF, você deve especificar uma senha raiz que atenda aos padrões de segurança de uma senha forte. No entanto, devido a uma limitação conhecida, o assistente de implantação OVF continua a implantar o dispositivo virtual, mesmo que você especifique uma senha raiz que não contenha um caractere especial. Nesse caso, a implantação será bem-sucedida, mas você será impedido(a) de fazer login no sistema operacional do dispositivo virtual após a implantação.

Para garantir seu acesso ao dispositivo virtual após sua implantação, sempre especifique uma senha raiz forte contendo pelo menos um caractere especial, conforme solicitado pelo assistente de implantação OVF.


VMware, Inc. 43


n Para o caso de uso mínimo de utilização de licenças de assinatura do Horizon com o pod do Horizon 7, verifique se você atende a estes pré-requisitos, além dos listados acima:

n A instância do Servidor de Conexão com a qual você vai emparelhar o Horizon 7 Cloud Connector deve ter a versão 7.6 ou posteriores do Horizon 7. A versão 7.6 é a versão mínima que pode ser emparelhada com o serviço de nuvem.

Dica Embora tecnicamente você possa emparelhar um pod do Horizon 7 com versões anteriores à versão mais recente do Horizon 7, para obter os recursos hospedados em nuvem mais atualizados com esse pod, o melhor é que os Servidores de conexão do pod do Horizon 7 tenham a versão mais recente do Horizon 7. Somente usando a combinação mais atual das versões do Horizon 7 e do Horizon 7 Cloud Connector, você terá acesso aos recursos mais atualizados dos recursos hospedados na nuvem, além de simplesmente usar uma licença de assinatura com esse pod.

Considerações conhecidas do Horizon 7 Cloud Connector

Lembre-se dessas considerações quando você estiver usando o Horizon 7 Cloud Connector.

n Não há suporte para o uso do IPv6 com o appliance virtual do Horizon 7 Cloud Connector.

n Não há suporte para a configuração SSL do proxy durante a implantação do dispositivo virtual do Horizon 7 Cloud Connector.

n Devido a uma limitação conhecida, qualquer configuração de host sem proxy que você especificar ao implantar o modelo OVF não será respeitada pelo Horizon 7 Cloud Connector 1.5 ou anterior. Para definir uma configuração de host sem proxy, você deve alterar um arquivo de configuração no dispositivo após implantá-lo. Para obter detalhes, consulte o Artigo 76663 da base de dados de conhecimento da VMware. Essa limitação não se aplica ao Horizon 7 Cloud Connector 1.6 ou posterior.

n : se você planejar usar o pod com o Agente Universal do Horizon e o Horizon 7 Cloud Connector 1.5 e o ambiente exigir o uso de configurações de proxy, deverá definir essas configurações de proxy ao implantar o modelo OVF. Devido a uma limitação conhecida, o Agente Universal do Horizon não respeitará as modificações feitas nas configurações de proxy após a implantação. Como você só pode configurar hosts sem proxy após a implantação, essa limitação significa que o uso de hosts sem proxy com o Agente Universal do Horizon não é compatível com o Horizon 7 Cloud Connector 1.5. Essa limitação não se aplica quando se usa o Agente Universal do Horizon com o Horizon 7 Cloud Connector 1.6 ou posterior.

n As informações sobre as configurações de proxy e de IP estático para o dispositivo virtual implantado do Horizon 7 Cloud Connector são salvas em determinados arquivos de contêiner. Quando você quiser alterar essas configurações no dispositivo virtual, precisará se conectar a ele e editar esses arquivos de contêiner. Se você alterar o endereço IP estático para o dispositivo virtual implantado no seu ambiente do vSphere, deverá editar o arquivo de contêiner apropriado no sistema operacional do dispositivo virtual e executar um comando para garantir que o novo endereço IP seja compartilhado com todos os componentes do pod que dependem do dispositivo virtual. Consulte Atualizar o IP estático para o dispositivo virtual do Horizon 7 Cloud Connector.


VMware, Inc. 44



https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-22AAAFCA-E658-4DE3-806B-9929C5E60318.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-22AAAFCA-E658-4DE3-806B-9929C5E60318.html

n Antes de excluir o appliance virtual do Horizon 7 Cloud Connector do seu ambiente do vCenter, aponte seu navegador para o endereço IP do appliance do Horizon 7 Cloud Connector e use a ação Desconectar para remover a conexão entre o pod e o Horizon Cloud.

n Usar uma conta separada do vdadmin para o Horizon 7 Cloud Connector emparelhado com o pod do Horizon 7 é uma boa prática. Usar uma conta separada do vdmadmin evita que configurações sejam substituídas entre o gerenciamento local e o na nuvem. Usar contas separadas também permite uma auditoria mais fácil para as operações baseadas na nuvem.

n A conexão entre o Horizon 7 Cloud Connector e o Horizon Cloud usa a porta de Internet de saída 443. Para todos os protocolos, portas e DNS necessários do conector, consulte Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7.

n Você define a senha para o usuário root do appliance virtual do Horizon 7 Cloud Connector durante a implantação. Por padrão, essa senha não expira. No entanto, com base na política de segurança da organização, você pode querer atualizar periodicamente essa senha root definindo uma política de expiração para esse usuário root. Para obter as etapas, consulte Definir uma política de expiração de senha para o usuário raiz do Horizon 7 Cloud Connector.

n Se o seu Servidor de Conexão estiver usando certificados autoassinados, e você substituir esses certificados autoassinados depois de emparelhar o pod com o Horizon Cloud, deverá fazer login na interface do Horizon 7 Cloud Connector e usar o fluxo de trabalho Reconfigurar para realizar as etapas de validação do certificado novamente com o novo certificado autoassinado. Ao fazer login na interface do Horizon 7 Cloud Connector, você pode clicar em Reconfigurar e concluir as etapas do assistente para verificar a comunicação usando o novo certificado autoassinado do Servidor de Conexão.

n Se você tiver adicionado uma entrada ao arquivo /etc/hosts para resolver o endereço IP do Servidor de Conexão, deverá reiniciar o hze-core e os serviços do csms. Use os seguintes comandos:

systemctl restart hze-core

systemctl restart csms

n Para garantir que o dispositivo virtual do Horizon 7 Cloud Connector seja autenticado corretamente no Horizon Cloud e nas instâncias necessárias do Servidor de Conexão, você deve sincronizar o relógio do dispositivo virtual com um servidor NTP. Para obter mais informações, consulte Sincronizar o dispositivo virtual do Horizon 7 Cloud Connector com um servidor NTP .

Conecte o Horizon Cloud Service com um pod existente do Horizon 7 para usar licenças de assinatura ou serviços hospedados na nuvem do Horizon ou ambosA conexão de seu pod existente do Horizon 7 com o Horizon Cloud Service é um processo de várias etapas. Após comprar uma licença de assinatura do VMware Horizon, a VMware enviará a você um e-mail de assinatura de licença, que inclui o link para baixar o dispositivo virtual do Horizon 7 Cloud Connector. Em seguida, instale o dispositivo virtual e ligue-o. Quando o dispositivo virtual estiver ligado e você verificar a integridade dos componentes e serviços necessários do pod, use o fluxo de trabalho de integração do conector para emparelhá-lo com um Servidor de Conexão no pod com o qual você deseja


VMware, Inc. 45

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-202C4522-26A4-40CA-A85F-535CF22197E2.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-202C4522-26A4-40CA-A85F-535CF22197E2.html

usar essa licença de assinatura. Como parte de um processo de emparelhamento bem-sucedido, o dispositivo virtual do Horizon 7 Cloud Connector liga o Servidor de Conexão ao Horizon Cloud Service, para que o plano de gerenciamento de nuvem possa gerenciar a licença de assinatura do Horizon e outros serviços hospedados na nuvem para esse pod conectado na nuvem.

VMs CS

Serviço degerenciamento

Integridade dosistema

Cloud Connector

Pod do Horizon 7

Serviço deMonitoramento da

Nuvem (CMS)

Serviço delicença

AD

Plano de gerenciamento do Horizon Cloud

API do Horizon

Dica Para obter uma introdução ao processo de integração geral do Horizon Cloud, consulte Integração ao Horizon Cloud para Microsoft Azure, Horizon 7 no local e Horizon 7 on VMware Cloud on AWS.

Use as etapas aqui para conectar ambientes do Horizon 7 existentes, instalados no local ou no VMware Cloud™ on AWS ao plano de gerenciamento de nuvem. Conectar um pod ao Horizon Cloud Service permite que você use licenças de assinatura do Horizon com esse pod, mesmo se você não utilizar nenhum serviço hospedado na nuvem com esse pod. Com uma licença de assinatura do Horizon, você não precisa inserir manualmente uma chave de licença do Horizon 7 para a ativação do produto do Horizon 7. Após a conclusão do emparelhamento, a VMware ativará a licença de assinatura, normalmente dentro de 48 horas depois de emparelhar o pod com a camada de controle de nuvem. Quando a VMware ativar a licença de assinatura, aparecerá uma mensagem no console do Horizon 7 dizendo que o ambiente do Horizon 7 está usando a licença.


VMware, Inc. 46

Conforme descrito na Integração ao Horizon Cloud para Microsoft Azure, Horizon 7 no local e Horizon 7 on VMware Cloud on AWS, o processo para integrar um pod do Horizon 7 ao Horizon Cloud envolve estes conceitos básicos:

n As licenças de assinatura do Horizon são gerenciadas a partir do plano de gerenciamento de nuvem, que é Horizon Cloud.

n Portanto, se você quiser usar licenças de assinatura do Horizon com um pod do Horizon 7, deverá conectar o pod com esse plano de gerenciamento de nuvem. Se você quiser evitar a conexão do pod do Horizon 7 com o plano de gerenciamento de nuvem, não poderá usar as licenças de assinatura do Horizon com esse pod.

n Conectar esse pod existente do Horizon 7 com o plano de gerenciamento de nuvem requer um conector, denominado Horizon 7 Cloud Connector. O plano de gerenciamento de nuvem conversa com o conector, que, por sua vez, conversa com uma das instâncias do Servidor de Conexão do pod. O conector é emparelhado com apenas uma das instâncias do Servidor de Conexão instaladas do pod a qualquer momento.

n Como o Horizon 7 Cloud Connector precisa alcançar tanto o plano de gerenciamento de nuvem quanto a instância do Servidor de Conexão do pod com a qual você o está emparelhando, Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7 devem ser atendidos para ter um bem-sucedido resultado de emparelhamento do Horizon 7 Cloud Connector com o pod e para a continuidade das operações. Até mesmo o caso de uso mínimo de usar uma licença de assinatura com o pod exige que se atenda a esses requisitos de DNS, portas e protocolos.

n Uma conta My VMware é necessária para obter uma licença de assinatura do Horizon e para se autenticar no plano de gerenciamento de nuvem a fim de configurar o conector e estabelecer a conexão para usar essa licença de assinatura com o pod.

n Você pode querer usar somente as licenças de assinatura do Horizon com o pod do Horizon 7 ou pode querer também usar serviços hospedados na nuvem com esse pod. Ambos os casos de uso exigem uma licença de assinatura do Horizon.

n Para obter os recursos e as correções de segurança e de erro mais recentes, o melhor é usar a combinação da versão mais atual do Horizon 7 com a versão mais atual do Horizon 7 Cloud Connector. Embora a versão 7.6 seja a primeira versão do Horizon 7 que forneceu a capacidade de usar uma licença de assinatura do Horizon gerenciada do plano de gerenciamento de nuvem usando o Horizon 7 Cloud Connector, essa versão já tem mais de um ano, e nenhum dos serviços de gerenciamento de nuvem atuais além do uso simples da licença de assinatura está disponível para a versão 7.6 do Horizon 7. Para a combinação recomendada de versões do Horizon 7 e versões do Horizon 7 Cloud Connector, consulte as notas de versão do Horizon Cloud vinculadas na página de documentação do Horizon Cloud Service.

As etapas de alto nível desse processo são:

1 Obtenha sua conta My VMware.

2 Use essa conta para se inscrever em uma licença de assinatura do Horizon.


VMware, Inc. 47



3 Quando você se inscreve na licença, um e-mail de boas-vindas é enviado para o endereço associado a essa conta My VMware. Esse e-mail de boas-vindas conterá um link para baixar o Horizon 7 Cloud Connector OVA da área de downloads my.vmware.com adequada.

4 Baixe o Horizon 7 Cloud Connector OVA usando o link no e-mail de boas-vindas.

5 Implante esse OVA no ambiente vSphere do pod do Horizon 7 usando um endereço IP estático. Quando o processo de implantação do dispositivo virtual estiver concluído, ligue-o.

6 Quando ligado, a tela azul do console do dispositivo exibirá um endereço de URL a ser usado para iniciar o fluxo de trabalho de emparelhamento para emparelhar o Horizon 7 Cloud Connector com uma instância do Servidor de Conexão no pod e concluir a conexão entre a instância do Servidor de Conexão, o Horizon 7 Cloud Connector e o plano de gerenciamento de nuvem.

7 Antes de iniciar o fluxo de trabalho de emparelhamento, execute o script precheck.sh para verificar a integridade dos componentes e serviços do sistema do pod.

8 Use o endereço da URL exibido na tela azul do console do dispositivo em um navegador para iniciar o fluxo de trabalho de emparelhamento. A tela de logon do Horizon Cloud será exibida, e você fará logon usando as credenciais da conta My VMware. Nesse ponto, a interface de usuário do fluxo de trabalho aparece no navegador, e você conclui as etapas conforme detalhado no tópico abaixo.

Importante Se você já tiver pods conectados à nuvem no seu ambiente do Horizon Cloud ao qual está conectando este pod do Horizon 7, todos esses pods conectados à nuvem deverão ter uma linha de visão para o mesmo conjunto de domínios do Active Directory. Ao executar as etapas para conectar o pod do Horizon 7, você deve garantir que o pod do Horizon 7 terá uma linha de visão para os domínios do Active Directory que já estão registrados no seu ambiente do Horizon Cloud.

Por exemplo, se o seu ambiente já tiver pods no Microsoft Azure e você estiver conectando um pod do Horizon 7, verifique se:n O pod do Horizon 7 que você está conectando usando as etapas a seguir tem uma linha de visão

para os domínios do Active Directory usados pelos pods existentes no Microsoft Azure, pois esses domínios já estão registrados no plano de nuvem do seu ambiente.

n Seus pods existentes conectados à nuvem no Microsoft Azure têm uma linha de visão para o domínio do Active Directory do pod do Horizon 7, o domínio que você está usando nas etapas a seguir para parear o appliance virtual do Horizon 7 Cloud Connector com o servidor de conexão do pod do Horizon 7.

Pré-requisitos

Verifique se você cumpriu todos os itens descritos em Preparação para executar o assistente de integração para emparelhar um pod do Horizon 7 com o Horizon Cloud usando o Horizon 7 Cloud Connector.

Verifique se você atendeu aos Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7 ao usar o Horizon 7 Cloud Connector para emparelhar um pod do Horizon 7 ao Horizon Cloud.


VMware, Inc. 48

http://www.vmware.com/go/download-horizon-subscription

Verifique se a sua configuração de DNS na Topologia de Rede fornecerá para o Horizon 7 Cloud Connector implantado para resolver o FQDN do Servidor de Conexão do pod. Se o Horizon 7 Cloud Connector implantado não puder resolver o Servidor de Conexão usando o DNS, o assistente de integração encontrará um erro inesperado na etapa em que você inserir as credenciais do domínio do Horizon 7.

Confira Considerações conhecidas do Horizon 7 Cloud Connector para garantir que você esteja ciente desses itens.

O dispositivo virtual do Horizon 7 Cloud Connector deve acessar a Internet para conversar com o plano de controle do Horizon Cloud. Se o ambiente exigir o uso de um servidor proxy e uma configuração de proxy para os dispositivos virtuais acessarem a Internet, verifique se você analisou as informações relacionadas ao proxy, as limitações e os problemas conhecidos ao usar as configurações de proxy com o dispositivo do Horizon 7 Cloud Connector. Consulte as informações relacionadas ao proxy em Preparação para executar o assistente de integração para emparelhar um pod do Horizon 7 com o Horizon Cloud usando o Horizon 7 Cloud Connector, Considerações conhecidas do Horizon 7 Cloud Connector e Como modificar as configurações de proxy para o Horizon 7 Cloud Connector 1.5 ou anterior.

Importante Se você planeja usar o pod com o Agente Universal do Horizon e o Horizon 7 Cloud Connector 1.5, e o ambiente exigir o uso de configurações de proxy, deverá definir essas configurações de proxy ao implantar o modelo OVF. Devido a uma limitação conhecida do Horizon 7 Cloud Connector 1.5, o Agente Universal do Horizon aceitará somente as configurações de proxy especificadas na implantação do modelo OVF. Como resultado, devido a outro problema conhecido no Horizon 7 Cloud Connector 1.5, onde qualquer configuração de host sem proxy especificada na implantação do modelo OVF não é respeitada pelo dispositivo e deve ser configurada após a implantação, essa limitação conhecida que a combinação de Agente Universal do Horizon com Horizon 7 Cloud Connector 1.5 requer ao definir as configurações de proxy durante a implantação do modelo OVF significa que não há suporte atualmente para o uso de hosts sem proxy com o Agente Universal do Horizon.

Procedimentos

1 Baixar e implantar o Cloud Connector no ambiente do vSphere do pod

Nesta etapa no fluxo de trabalho de integração de um pod do Horizon 7 para Horizon Cloud, baixe e implante o Horizon 7 Cloud Connector no seu ambiente do vSphere. O resultado dessas etapas é que o dispositivo virtual do Horizon 7 Cloud Connector é implantado e executado no seu ambiente do vSphere.

2 Verifique se o pod do Horizon 7 e o Horizon 7 Cloud Connector estão prontos para serem emparelhados

Nesta etapa no fluxo de trabalho de integração de um pod do Horizon 7 ao Horizon Cloud, você executa a ferramenta de diagnóstico precheck.sh para validar que o pod e o Horizon 7 Cloud Connector estão prontos para o processo de emparelhamento. Ao executar primeiro os diagnósticos e corrigir quaisquer problemas de bloqueio encontrados em componentes e configurações do sistema, você pode maximizar as chances de sucesso ao emparelhar o pod com o Horizon Cloud.


VMware, Inc. 49

3 Concluir o emparelhamento do pod do Horizon 7 com o Horizon Cloud usando o portal de configuração do Horizon 7 Cloud Connector

Nesta etapa no fluxo de trabalho de integração de um pod do Horizon 7 ao Horizon Cloud, use o portal de configuração do Horizon 7 Cloud Connector para especificar os detalhes que o Horizon 7 Cloud Connector usa para emparelhar com o Servidor de Conexão do pod do Horizon 7. Concluir essas etapas resulta com sucesso no pod do Horizon 7 conectado ao ambiente do tenant do Horizon Cloud.

Resultados

Quando o pod do Horizon 7 é conectado com êxito ao Horizon Cloud, o portal de configuração do Horizon 7 Cloud Connector exibe uma mensagem de Parabéns. A partir desse ponto, você usa esse mesmo portal de configuração para realizar tarefas administrativas, como revisar o status de integridade dos componentes do Horizon 7 Cloud Connector, ativar ou desativar o acesso do SSH ao dispositivo virtual do Horizon 7 Cloud Connector e tarefas semelhantes. Para obter detalhes, consulte o tópico Tarefas de administração e manutenção típicas que você executa no Horizon 7 Cloud Connector depois que o pod do Horizon 7 é emparelhado com o Horizon Cloud.

Próximo passo

Se o seu único objetivo é usar sua licença de assinatura do Horizon com o pod conectado à nuvem agora, não há etapas adicionais a serem tomadas, exceto para garantir que seja possível continuar atendendo aos requisitos de DNS, portas e protocolos para manter a conexão entre o Horizon 7 Cloud Connector e a camada de controle da nuvem. Como as licenças de assinatura são gerenciadas pela camada de controle de nuvem, o Horizon 7 Cloud Connector deve continuar a acessar o plano de controle de nuvem para que o pod receba suas informações de licença de assinatura.

Importante Quando o Horizon 7 Cloud Connector estiver instalado, a conexão é estabelecida com a camada de controle da nuvem pela porta 443 de Internet de saída. Essa conexão fica aberta o tempo todo. Se essa conexão entre o Cloud Connector e a camada de controle da nuvem cair, haverá um período de cortesia de 10 dias por padrão, que podem passar antes que o emparelhamento entre esse pod e o Horizon Cloud seja marcado como expirado. Se isso acontecer, entre em contato com o suporte da VMware para obter assistência.

Se você quiser aproveitar qualquer um dos serviços hospedados na nuvem com o pod conectado à nuvem, deverá fazer logon no Console administrativo do Horizon Cloud e concluir o fluxo de trabalho de registro do Active Directory que registra o domínio do Active Directory do pod no Horizon Cloud. Para obter detalhes sobre esse fluxo de trabalho, consulte Como realizar seu primeiro registro de domínio do Active Directory no ambiente do Horizon Cloud no Guia de Administração do Horizon Cloud.

Baixar e implantar o Cloud Connector no ambiente do vSphere do pod

Nesta etapa no fluxo de trabalho de integração de um pod do Horizon 7 para Horizon Cloud, baixe e implante o Horizon 7 Cloud Connector no seu ambiente do vSphere. O resultado dessas etapas é que o dispositivo virtual do Horizon 7 Cloud Connector é implantado e executado no seu ambiente do vSphere.


VMware, Inc. 50





Pré-requisitos

n Verifique se você cumpriu com os pré-requisitos relacionados ao conector descritos em Preparação para executar o assistente de integração para emparelhar um pod do Horizon 7 com o Horizon Cloud usando o Horizon 7 Cloud Connector.

n Verifique se você atendeu aos Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7 ao usar o Horizon 7 Cloud Connector para emparelhar um pod do Horizon 7 ao Horizon Cloud.

n O dispositivo virtual do Horizon 7 Cloud Connector deve acessar a Internet para conversar com o plano de controle do Horizon Cloud. Se o ambiente exigir o uso de um servidor proxy e uma configuração de proxy para os dispositivos implantados acessarem a Internet, verifique se você analisou as informações relacionadas ao proxy, as limitações e os problemas conhecidos ao usar as configurações de proxy com o dispositivo do Horizon 7 Cloud Connector. Consulte as informações relacionadas ao proxy em Preparação para executar o assistente de integração para emparelhar um pod do Horizon 7 com o Horizon Cloud usando o Horizon 7 Cloud Connector, Considerações conhecidas do Horizon 7 Cloud Connector e Como modificar as configurações de proxy para o Horizon 7 Cloud Connector 1.5 ou anterior.

Procedimentos

1 Conforme descrito na lista de pré-requisitos, baixe o dispositivo do Horizon 7 Cloud Connector usando o link fornecido no e-mail de assinatura.

O dispositivo do Horizon 7 Cloud Connector está disponível como um arquivo OVA e tem sua localização inicial no my.vmware.com após fazer logon no my.vmware.com usando as credenciais da sua conta My VMware.

Importante Certifique-se de que a versão baixada seja a versão mais recente (a versão 1.6 ou posteriores) para habilitar os recursos mais atualizados. Se você já tiver baixado um Horizon 7 Cloud Connector OVA com uma versão anterior à 1.6, deverá fazer logon no my.vmware.com e obter a versão mais recente a ser usada para emparelhar o pod.

2 Use o vSphere Web Client para implantar o appliance do Horizon 7 Cloud Connector como um modelo OVF para o pod do Horizon.

Para obter informações gerais sobre a implantação de modelos OVF, consulte o guia Administração da máquina virtual do vSphere na página Documentação do VMware vSphere.


VMware, Inc. 51

http://www.vmware.com/go/download-horizon-subscription

http://my.vmware.com

https://docs.vmware.com/br/VMware-vSphere/index.html

O assistente de implantação do OVF tem várias etapas, em que você faz opções típicas de implantação do OVF, como qual host, repositório de dados, rede etc. A etapa Personalizar modelo é onde você fornece detalhes que são específicos para o dispositivo do Horizon 7 Cloud Connector.

Importante Você pode ter melhores resultados ao implantar o appliance no seu pod quando usa o VMware vSphere® Web Client, que é uma interface de usuário baseada em Flex. Se você implantar usando o VMware vSphere® Client™, que é a interface de usuário baseada em HTML5 mais recente, poderá encontrar uma mensagem de erro sobre um valor inválido. Esse problema é causado por um problema conhecido no vSphere Client e não é um problema com o pacote de appliances do Horizon 7 Cloud Connector. Se você encontrar esse erro, implante o dispositivo usando a interface de usuário baseada em Flex.


VMware, Inc. 52

3 Na etapa do assistente para Personalizar modelo, forneça a entrada para os campos necessários e para os itens que são apropriados para o seu ambiente.

A entrada nessa etapa é usada para configurar o dispositivo virtual.

a Especifique uma senha raiz para o dispositivo que atenda aos padrões de segurança de uma senha forte. Verifique se a senha contém um mínimo de oito caracteres com pelo menos uma letra maiúscula, um número e um caractere especial.

Importante Devido a uma limitação conhecida, o assistente de implantação OVF continua a implantar o dispositivo virtual, mesmo que você especifique uma senha raiz que não contenha um caractere especial. Nesse caso, a implantação será bem-sucedida, mas você será impedido(a) de fazer login no sistema operacional do dispositivo virtual após a implantação. Para garantir seu acesso ao dispositivo virtual após sua implantação, verifique se a sua senha raiz contém pelo menos um caractere especial.

b Especifique um endereço IP estático para o dispositivo virtual.

Não use IPv6 com o appliance virtual do Horizon 7 Cloud Connector. IPv6 não é compatível.

c Se o seu ambiente exigir o uso de um servidor proxy HTTP para seus dispositivos virtuais acessarem a Internet, defina as configurações relacionadas ao proxy.

Importante Tenha em mente as seguintes considerações:

n Não há suporte para a configuração SSL do proxy para o certificado autoassinado para o dispositivo virtual do Horizon 7 Cloud Connector.

n (Horizon 7 Cloud Connector 1.6 ou posterior) Para garantir que somente as solicitações de saída para a internet sejam roteadas pelo proxy HTTP, configure os hosts sem proxy que ignoram o servidor proxy ao receber solicitações internas do dispositivo. No mínimo, para Nenhum Proxy Para, digite o subdomínio DNS das instâncias do Servidor de Conexão e do vCenter Server associadas ao pod que será emparelhado com o Horizon 7 Cloud Connector. Você também pode especificar hosts sem proxy inserindo um intervalo de IP, usando um separador de vírgula entre as entradas, conforme mostrado no seguinte exemplo:

.ad-domain.example.com, 10.109.*

n (Horizon 7 Cloud Connector 1.6 ou posterior) Se você deixar em branco a configuração Nenhum Proxy Para, o dispositivo virtual buscará os nomes de host do Servidor de Conexão fornecidos pelo administrador ou descobertos por meio da consulta do pod e configurará esses hosts como hosts sem proxy implícitos.

n (Horizon 7 Cloud Connector 1.5 ou anterior) Devido a uma limitação conhecida, qualquer configuração de host sem proxy que você especificar ao implantar o modelo OVF não será respeitada pelo sistema. Para definir uma configuração de host sem proxy, você deve alterar um arquivo de configuração no dispositivo após implantá-lo, conforme descrito no Artigo 76663 da base de dados de conhecimento da VMware. Essa limitação não se aplica ao Horizon 7 Cloud Connector 1.6 ou posterior.

n (Horizon 7 Cloud Connector 1.5) Se você planejar usar o pod com o Agente Universal do Horizon e o Horizon 7 Cloud Connector 1.5, deverá definir todas as configurações de proxy necessárias ao implantar o modelo OVF. Devido a uma limitação conhecida do Horizon 7 Cloud Connector 1.5, o Agente Universal do Horizon não respeitará as modificações feitas nas configurações de proxy após a implantação. Como você só pode configurar hosts sem proxy após a implantação, o uso de hosts sem proxy com o Agente Universal do Horizon não é compatível com o Horizon 7 Cloud Connector 1.5. Essas limitações não se aplicam ao Agente Universal do Horizon quando ele é usado com o Horizon 7 Cloud Connector 1.6 ou posterior.


VMware, Inc. 53



4 Ligue o dispositivo do Horizon 7 Cloud Connector.

5 Quando o dispositivo estiver totalmente ligado, use a opção do vSphere Web Client para inicializar o console do dispositivo do Horizon 7 Cloud Connector.

A tela azul do console do dispositivo do Horizon 7 Cloud Connector é exibida. Essa tela azul do console exibe o endereço da URL a ser carregado no navegador para o fluxo de trabalho de integração. A seguinte captura de tela é um exemplo para um dispositivo implantado que tem o endereço https://10.92.245.255/.

6 Conclua as etapas em Habilitar o acesso do SSH ao Horizon 7 Cloud Connector antes de emparelhá-lo com o Servidor de Conexão do Horizon 7.

7 Se você quiser usar um nome de domínio completo (FQDN) para o dispositivo virtual do Horizon 7 Cloud Connector e resolver o nome do host, crie um registro de pesquisa direta e inversa no seu servidor DNS que mapeia esse FQDN para o IP estático do dispositivo virtual do Horizon 7 Cloud Connector.

8 Continue com o fluxo de trabalho de integração do pod seguindo as etapas em Verifique se o pod do Horizon 7 e o Horizon 7 Cloud Connector estão prontos para serem emparelhados.

Habilitar o acesso do SSH ao Horizon 7 Cloud Connector antes de emparelhá-lo com o Servidor de Conexão do Horizon 7Use estas etapas se você quiser poder usar o SSH com o dispositivo do Horizon 7 Cloud Connector implantado antes de executar o assistente de integração para emparelhar o Horizon 7 Cloud Connector com o pod.

Pré-requisitos

Verifique se o dispositivo do Horizon 7 Cloud Connector foi implantado com êxito no seu ambiente do vSphere, conforme descrito em Conecte o Horizon Cloud Service com um pod existente do Horizon 7 para usar licenças de assinatura ou serviços hospedados na nuvem do Horizon ou ambos, mas ainda não foi emparelhado com o Servidor de Conexão.

Procedimentos

1 Use o vSphere Web Client para iniciar o console do dispositivo implantado e fazer login no dispositivo usando a conta root e a senha que você definiu quando implantou o OVA no vSphere.

2 No sistema operacional do dispositivo, habilite o SSH executando o seguinte comando.

/opt/vmware/bin/configure-adapter.py --sshEnable


VMware, Inc. 54

Resultados

O acesso do SSH ao dispositivo está ativado.

Para desativar o acesso do SSH, use o seguinte comando:

/opt/vmware/bin/configure-adapter.py --sshDisable

Próximo passo

Execute as etapas do assistente de integração para concluir o emparelhamento do Horizon 7 Cloud Connector com o pod. Quando o emparelhamento é concluído com êxito, a interface de usuário do portal do Horizon 7 Cloud Connector fornece uma opção que você pode usar para desativar o acesso do SSH ao dispositivo ou reativar o SSH se ele tiver sido desativado anteriormente.

Como modificar configurações de proxy para o Horizon 7 Cloud Connector 1.6 ou versão posteriorVocê pode definir as configurações de proxy HTTP durante a implantação do modelo OVF do Horizon 7 Cloud Connector. Se você quiser modificar essas configurações de proxy após a implantação, deverá criar um script usando o comando configure-webproxy.py. O comando configure-webproxy.py está localizado no diretório /opt/vmware/bin do dispositivo implantado do Horizon 7 Cloud Connector.

Observação Observe as seguintes diretrizes com relação às configurações de proxy e atualizações de dispositivo:

n Se você atualizar o Horizon 7 Cloud Connector 1.6 manualmente para uma versão posterior, deverá redefinir as configurações do seu proxy. Sua configuração original com proxy não migra com a atualização manual do dispositivo.

n Se o Horizon 7 Cloud Connector 1.6 for atualizado automaticamente para uma versão posterior, as configurações do seu proxy migrarão com a atualização automática. Você não precisa redefinir as configurações de proxy.

Sintaxe para o uso do configure-webproxy.py

Use a seguinte sintaxe para criar um script com o configure-webproxy.py:

configure-webproxy.py [argument1 [value1]] [argument2 [value2]] ...

Para exibir o uso do comando e a lista de argumentos disponíveis, execute o configure-webproxy.py -h ou o configure-webproxy.py --help.

Argumentos para o configure-webproxy.py

Todos os argumentos são opcionais para o script do configure-webproxy.py.

Argumento Descrição

--proxyHost Nome de host ou endereço IP do servidor proxy HTTP

--proxyPort Número da porta para a conexão proxy

--noProxyFor Hosts ou intervalo de rede configurado para ignorar o proxy HTTP. Use espaços para separar diferentes valores.


VMware, Inc. 55

Argumento Descrição

--proxySsl= Especifica se o SSL deve ser usado para a conexão proxy. Os valores permitidos são TRUE ou FALSE.

--proxyUsername Nome de usuário para o proxy HTTP

--proxyPassword Senha para o proxy HTTP

--implicitNonProxyHosts= Especifica se você deseja adicionar o vCenter Server e o Servidor de Conexão do pod emparelhado implicitamente à lista de hosts que ignoram o proxy HTTP. Os valores permitidos são TRUE ou FALSE. O padrão é TRUE.

Se o seu ambiente exigir solicitações internas para o Servidor de Conexão e o vCenter Server para rotear pelo proxy, defina esse argumento como FALSE. Nesse caso, somente os hosts especificados explicitamente por --noProxyFor ignoram o proxy.

Exemplo de script

configure-webproxy.py --proxyHost PROXYEXAMPLE --proxyPort 80 --proxySsl=TRUE

--noProxyFor .AD-DOMAIN.EXAMPLE.COM 10.109.* --implicitNonProxyHosts=TRUE

Este exemplo de script define as seguintes configurações de proxy:

n PROXYEXAMPLE é o servidor proxy.

n A conexão proxy usa a porta 80.

n A conexão proxy usa o SSL.

n Hosts que se enquadram em .AD-DOMAIN.EXAMPLE.COM e 10.109.* ignorar o proxy.

n Além disso, o Servidor de Conexão do pod emparelhado e o vCenter Server ignoram o proxy.

Como modificar as configurações de proxy para o Horizon 7 Cloud Connector 1.5 ou anteriorVocê pode definir as configurações de proxy HTTP durante a implantação do modelo OVF do Horizon 7 Cloud Connector. Se você quiser alterar as configurações de proxy após a implantação ou configurar hosts sem proxy, deverá modificar determinados arquivos de configuração. Devido a uma limitação conhecida, o Horizon 7 Cloud Connector 1.5 ou anterior não respeita a configuração do host sem proxy especificada durante a implantação. Para configurar hosts sem proxy, você deve modificar um determinado arquivo de configuração após a implantação.

Importante Devido a uma limitação conhecida, se você planeja usar o Agente Universal do Horizon com o Horizon 7 Cloud Connector 1.5, e o ambiente exigir o uso de configurações de proxy, deverá definir essas configurações de proxy ao implantar o modelo OVF. O Agente Universal do Horizon não reconhece as configurações de proxy definidas após a implantação. Como você só poderá configurar hosts sem proxy após a implantação, essa limitação significa que o uso de hosts sem proxy com o Agente Universal do Horizon não é compatível com o Horizon 7 Cloud Connector 1.5.

Como configurar hosts sem proxy para o Horizon 7 Cloud Connector 1.5 ou anterior


VMware, Inc. 56

Durante a implantação do modelo OVF do Horizon 7 Cloud Connector, o assistente de implantação fornece avisos para a configuração de hosts sem proxy. No entanto, devido a um problema conhecido, o Horizon 7 Cloud Connector 1.5 ou anterior não respeita a configuração do host sem proxy especificada durante a implantação. Em vez disso, você deve modificar um determinado arquivo de configuração após a implantação para configurar hosts sem proxy.

Para garantir que somente as solicitações de saída para a internet sejam roteadas pelo proxy HTTP, configure os hosts sem proxy que ignoram o servidor proxy ao receber solicitações internas do dispositivo. No mínimo, configure as instâncias do Servidor de Conexão e do vCenter Server do pod emparelhado de modo que sejam hosts sem proxy.

Observação Se você atualizar o Horizon 7 Cloud Connector 1.5 ou anterior para uma versão posterior, deverá reconfigurar seus hosts sem proxy. Sua configuração original de host sem proxy não executa a atualização do dispositivo.

Para obter informações detalhadas sobre como configurar hosts sem proxy após a implantação do dispositivo virtual, consulte o artigo 76663 da Base de Conhecimento (KB) da VMware: Problemas de configuração de proxy e correções para o Horizon Cloud Connector.

Como modificar as configurações de proxy para o Horizon 7 Cloud Connector 1.5 ou 1.4

Use as seguintes etapas para modificar as configurações de proxy HTTP para o Horizon 7 Cloud Connector 1.5 ou 1.4 depois de implantar o dispositivo.

1 Abra uma sessão Secure Shell (SSH) para o dispositivo virtual implantado do Horizon 7 Cloud Connector.

2 Altere os detalhes do proxy conforme necessário nos seguintes arquivos:

n /opt/container-data/cc-settings/proxy.conf

n /opt/container-data/data/hze-core/properties/hydra.properties

n /opt/container-data/data/hze-ccc/config/ccc-core/sn.config

3 Reinicie os serviços necessários.

systemctl restart hze-core

systemctl restart hze-ccc

systemctl restart csms

Como modificar as configurações de proxy para o Horizon 7 Cloud Connector 1.3 ou anterior

Use as seguintes etapas para modificar as configurações de proxy HTTP para o Horizon 7 Cloud Connector 1.3 ou anterior depois de implantar o dispositivo.

1 Abra uma sessão Secure Shell (SSH) para o dispositivo virtual implantado do Horizon 7 Cloud Connector.

2 Altere os detalhes do proxy conforme necessário nos seguintes arquivos:

n /opt/vmware/var/lib/tomcat8/properties/hydra.properties

n /opt/vmware/var/lib/tomcat8/properties/sn.config


VMware, Inc. 57



3 Reinicie os serviços necessários.

systemctl restart tomcat8

systemctl restart cccService

Configurar um certificado assinado pela autoridade de certificação para o appliance virtual do Horizon 7 Cloud ConnectorPara ter mais segurança, você pode configurar um certificado personalizado assinado pela autoridade de certificação para o appliance virtual do Horizon 7 Cloud Connector.

Pré-requisitos

n Verifique se a cadeia de certificados inteira está disponível no formato PEM.

n Verifique se a chave privada está disponível no formato PEM.

n Verifique se o FQDN e o nome alt da entidade está incluído no certificado emitido.

Procedimentos

1 Abra uma sessão SSH para o dispositivo virtual implantado do Horizon 7 Cloud Connector.

2 Copie o certificado assinado pela autoridade de certificação no diretório /root/server.crt.

3 Copie a chave assinada pela autoridade de certificação no diretório /root/server.key.

4 Faça backup do certificado existente.

n Para a versão 1.4 ou posterior do Horizon 7 Cloud Connector, use o seguinte comando:

cp /opt/container-data/certs/hze-nginx/server.crt /opt/container-data/certs/hze-nginx/

server.crt.orig

n Para a versão 1.3 ou anterior do Horizon 7 Cloud Connector, use o seguinte comando:

cp /etc/nginx/ssl/server.crt /etc/nginx/ssl/server.crt.orig

5 Faça backup da chave existente.


cp /opt/container-data/certs/hze-nginx/server.key /opt/container-data/certs/hze-nginx/

server.key.orig


cp /etc/nginx/ssl/server.key /etc/nginx/ssl/server.key.orig

6 Copie o arquivo nginx conf existente.


cp /opt/container-data/conf/hze-nginx/nginx.conf /opt/container-data/conf/hze-nginx/

nginx.conf.orig


VMware, Inc. 58


cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig

7 Copie o certificado da autoridade de certificação no diretório apropriado para a sua versão do dispositivo virtual.


cp /root/server.crt /opt/container-data/certs/hze-nginx/server.crt


cp /root/server.crt /etc/nginx/ssl/server.crt

8 Copie o arquivo de chave de certificado da autoridade de certificação no diretório apropriado para a sua versão do dispositivo virtual.


cp /root/server.key /opt/container-data/certs/hze-nginx/server.key


cp /root/server.key /etc/nginx/ssl/server.key

9 Verifique o proprietário e as permissões para o arquivo de chave e certificado.

n Para a versão 1.4 ou posterior do Horizon 7 Cloud Connector, use os seguintes comandos:

chown -R hze-nginx:hze-nginx /opt/container-data/certs/hze-nginx

chmod 644 /opt/container-data/certs/hze-nginx/server.crt

chmod 600 /opt/container-data/certs/hze-nginx/server.key

n Para a versão 1.3 ou anterior do Horizon 7 Cloud Connector, use os seguintes comandos:

chown -R root:root /etc/nginx/ssl

chmod -R 600 /etc/nginx/ssl

10 Verifique se o FQDN emitido no certificado corresponde à diretiva de nome de servidor no bloco 443 de escuta do servidor no arquivo de configuração nginx.

n Para a versão 1.4 ou posterior do Horizon 7 Cloud Connector, o arquivo de configuração nginx está localizado em /opt/container-data/conf/hze-Nginx/nginx.conf.

n Para a versão 1.3 ou posterior do Horizon 7 Cloud Connector, o arquivo de configuração nginx está localizado em /etc/nginx/nginx.conf.


VMware, Inc. 59

11 Verifique e reinicie nginx.


docker exec -i hze-nginx sudo nginx -t

systemctl restart hze-nginx


nginx -t

systemctl restart nginx

12 Para a versão 1.4 ou posterior do Horizon 7 Cloud Connector, atualize as impressões digitais SSL na tela de boas-vindas.

Use os seguintes comandos:

docker exec -i hze-core sudo /opt/vmware/bin/configure-welcome-screen.py

/usr/bin/killall --quiet vami_login

13 Teste o novo certificado recarregando a URL da interface de usuário do Horizon 7 Cloud Connector em um navegador da Web.

14 (Opcional) Se o certificado funcionar corretamente, remova os arquivos em backup.


rm /opt/container-data/certs/hze-nginx/server.crt.orig

rm /opt/container-data/certs/hze-nginx/server.key.orig

rm /opt/container-data/conf/hze-nginx/nginx.conf.orig


rm /etc/nginx/ssl/server.crt.orig

rm /etc/nginx/ssl/server.key.orig

rm /etc/nginx/nginx.conf.orig

15 Remova os certificados de autoridade de certificação copiados e os arquivos de chave no diretório raiz.

Use os seguintes comandos:

rm /root/server.crt

rm /root/server.key

Sincronizar o dispositivo virtual do Horizon 7 Cloud Connector com um servidor NTPPara garantir que o dispositivo virtual do Horizon 7 Cloud Connector seja autenticado corretamente no Horizon Cloud e nas instâncias necessárias do Servidor de Conexão, você deve sincronizar o relógio do dispositivo virtual com um servidor Network Time Protocol (NTP). Depois de ter garantido que o host esteja sincronizado com um servidor NTP, você poderá sincronizar o relógio no dispositivo virtual do Horizon 7 Cloud Connector com o relógio no host físico do ESXi no qual o dispositivo virtual reside.


VMware, Inc. 60

Como alternativa, você pode sincronizar o relógio do dispositivo virtual diretamente com um servidor NTP.

Procedimentos

u Sincronize o dispositivo virtual do Horizon 7 Cloud Connector com o host físico do ESXi no qual o dispositivo virtual reside.

a Verifique se o relógio do host do ESXi está sincronizado com um servidor NTP.

Para obter mais informações, consulte a Documentação do VMware vSphere.

b Use o vSphere Client para abrir a janela Editar Configurações do dispositivo virtual do Horizon 7 Cloud Connector e habilitar a opção Sincronizar a Hora com o Host.

Para obter instruções detalhadas, consulte a Documentação do VMware vSphere.

u Sincronize o dispositivo virtual do Horizon 7 Cloud Connector diretamente com um servidor NTP.

a Abra uma conexão SSH com o dispositivo virtual do Horizon 7 Cloud Connector e faça login como o usuário root.

b Usando um editor de texto como vi, abra o arquivo timesyncd.conf para editá-lo.

vi /etc/systemd/timesyncd.conf

c Edite a seção [Time] para que ela seja semelhante ao exemplo a seguir. Substitua ntpAddress pelo nome de domínio do servidor NTP que você deseja usar.

[Time]

#FallbackNTP=time1.google.com time2.google.com time3.google.com time4.google.com

NTP=ntpAddress

Salve as alterações no arquivo timesyncd. conf e saia do editor de texto.

d Reinicie o serviço de rede do dispositivo virtual.

systemctl restart systemd-networkd

e Reinicie o serviço do timesync do dispositivo virtual.

systemctl restart systemd-timesyncd

f Verifique se o relógio no dispositivo virtual já está sincronizado com o servidor NTP especificado.

Verifique se o pod do Horizon 7 e o Horizon 7 Cloud Connector estão prontos para serem emparelhados

Nesta etapa no fluxo de trabalho de integração de um pod do Horizon 7 ao Horizon Cloud, você executa a ferramenta de diagnóstico precheck.sh para validar que o pod e o Horizon 7 Cloud Connector estão prontos para o processo de emparelhamento. Ao executar primeiro os diagnósticos e corrigir quaisquer problemas de bloqueio encontrados em componentes e configurações do sistema, você pode maximizar as chances de sucesso ao emparelhar o pod com o Horizon Cloud.


VMware, Inc. 61



A ferramenta de diagnóstico precheck.sh valida a integridade dos serviços e componentes necessários para emparelhar com êxito o pod do Horizon 7 com o Horizon Cloud. Além disso, a ferramenta verifica se:

n As configurações relacionadas a certificados e configurações de proxy estão corretas.

n A conectividade com o Horizon Cloud e o Servidor de Conexão pode ser estabelecida.

n Existem alguns problemas relacionados ao SSL para o Horizon 7 Cloud Connector.

Pré-requisitos

Verifique o seguinte:

n Você concluiu as etapas em Baixar e implantar o Cloud Connector no ambiente do vSphere do pod, incluindo as etapas para Habilitar o acesso do SSH ao Horizon 7 Cloud Connector antes de emparelhá-lo com o Servidor de Conexão do Horizon 7.

n O dispositivo virtual do Horizon 7 Cloud Connector está ligado.

Procedimentos

1 Abra uma sessão SSH para o dispositivo virtual implantado do Horizon 7 Cloud Connector.

2 Execute a ferramenta de diagnóstico usando o seguinte comando. Substitua CS-FQDN pelo nome de domínio completo (FQDN) do Servidor de Conexão do pod.

/opt/vmware/bin/precheck.sh CS-FQDN

Se a ferramenta de diagnóstico descobrir um problema que vai impedir o emparelhamento do seu pod do Horizon 7 com o Horizon Cloud, ela relatará as seguintes informações:

n Nome do componente ou serviço do problema

n Status do componente ou serviço do problema

n Detalhes e mensagem de erro associados


VMware, Inc. 62

n Etapas de correção recomendadas, se houver, para restaurar o componente ou o serviço para um estado íntegro e pronto

Observação A ferramenta de diagnóstico sempre relata uma ou ambas as condições esperadas a seguir como parte de sua saída. Ambas as condições são normais e esperadas neste estágio do fluxo de trabalho de integração, e nenhuma delas bloqueia o emparelhamento do pod do Horizon 7 com o Horizon Cloud.

n Component/Service Name: "Cloud Broker Client Service"

Status: "NOT_INITIALIZED"

Message: Service is not initialized.

Essa condição pertence ao serviço opcional do Agente Universal do Horizon, que permanece no estado NOT_INITIALIZED até que seja habilitado conforme descrito em Como configurar o Agente Universal do Horizon para atribuições de várias nuvens. Você ainda poderá emparelhar com sucesso o pod do Horizon 7 com o Horizon Cloud quando o Agente Universal do Horizon estiver no estado NOT_INITIALIZED. Portanto, essa condição não representa um problema de bloqueio, e você pode ignorá-la.

n Component/Service Name: "Connector Client Service"

Status: "FAIL"

Message: Connector service is initialized post on-boarding.

O serviço do cliente do Horizon 7 Cloud Connector é inicializado após a conclusão do procedimento de emparelhamento, pois o processo de inicialização requer conectividade com o Horizon Cloud. Portanto, a condição FAIL é esperada neste estágio do fluxo de trabalho de integração. Depois de emparelhar o pod do Horizon 7 com o Horizon Cloud, o serviço do cliente do Horizon 7 Cloud Connector é inicializado, e a condição FAIL é desmarcada.

3 Se a ferramenta de diagnóstico relatar um problema que interfira no processo de emparelhamento, investigue o componente ou o serviço afetado e realize as etapas de correção sugeridas. Conforme observado anteriormente, você pode ignorar condições de erro para o "Serviço do Cliente do Agente do Cloud" e o "Serviço do Cliente do Connector", pois elas não são problemas de bloqueio.

Dependendo da necessidade, repita as etapas 2 e 3 para executar a ferramenta de diagnóstico novamente e solucionar problemas até que a ferramenta não relate quaisquer problemas de bloqueio que impeçam o processo de emparelhamento. O pod do Horizon 7 e o Horizon 7 Cloud Connector agora estão prontos para o processo de emparelhamento.

Observação Se você tentar realizar o processo de emparelhamento sem primeiro limpar quaisquer problemas de bloqueio relatados pela ferramenta de diagnóstico, o processo de emparelhamento poderá falhar.


VMware, Inc. 63

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-6086C3C0-EFE2-4205-9EDB-47E112256528.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-6086C3C0-EFE2-4205-9EDB-47E112256528.html

4 Continue com o fluxo de trabalho de integração do pod seguindo as etapas em Concluir o emparelhamento do pod do Horizon 7 com o Horizon Cloud usando o portal de configuração do Horizon 7 Cloud Connector.

Depois que o procedimento de emparelhamento tiver sido concluído, você poderá continuar a monitorar a integridade do seu pod conectado à nuvem usando a página Painel no Console Administrativo do Horizon Cloud. Para obter mais informações, consulte Visibilidade de integridade e informações sobre seus pods conectados à nuvem fornecidos pelo serviço de monitoramento de nuvem no Horizon Cloud.

Concluir o emparelhamento do pod do Horizon 7 com o Horizon Cloud usando o portal de configuração do Horizon 7 Cloud Connector

Nesta etapa no fluxo de trabalho de integração de um pod do Horizon 7 ao Horizon Cloud, use o portal de configuração do Horizon 7 Cloud Connector para especificar os detalhes que o Horizon 7 Cloud Connector usa para emparelhar com o Servidor de Conexão do pod do Horizon 7. Concluir essas etapas resulta com sucesso no pod do Horizon 7 conectado ao ambiente do tenant do Horizon Cloud.

Pré-requisitos

Verifique se você concluiu as etapas em Baixar e implantar o Cloud Connector no ambiente do vSphere do pod e Verifique se o pod do Horizon 7 e o Horizon 7 Cloud Connector estão prontos para serem emparelhados. Além disso, verifique se:

n O dispositivo virtual do Horizon 7 Cloud Connector está ligado

n Você tem a URL para exibir o portal de configuração do Horizon 7 Cloud Connector baseado em navegador. Essa URL é normalmente exibida na tela do console azul do dispositivo e é baseada no endereço IP do dispositivo virtual, como https://IP-address/, em que IP-address é o endereço IP do dispositivo. Como alternativa, se você tiver mapeado um nome de domínio totalmente qualificado (FQDN) para o endereço IP do dispositivo virtual do Horizon 7 Cloud Connector no servidor DNS, a URL do portal de configuração será esse FQDN.

Verifique se o dispositivo virtual do Horizon 7 Cloud Connector está ligado e se você pode obter a URL para iniciar o assistente de integração na tela do console azul do dispositivo.

Verifique se você cumpriu todos os itens descritos em Preparação para executar o assistente de integração para emparelhar um pod do Horizon 7 com o Horizon Cloud usando o Horizon 7 Cloud Connector, especificamente:

n Você atendeu aos Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7 ao usar o Horizon 7 Cloud Connector para emparelhar um pod do Horizon 7 ao Horizon Cloud.

n Sua configuração de DNS na Topologia de Rede fornecerá para o Horizon 7 Cloud Connector implantado para resolver o FQDN do Servidor de Conexão do pod. Se o Horizon 7 Cloud Connector implantado não puder resolver o Servidor de Conexão usando o DNS, o assistente de integração encontrará um erro inesperado na etapa em que você inserir as credenciais do domínio do Horizon 7.


VMware, Inc. 64

https://docs.vmware.com/br/draft/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-6086C3C0-EFE2-4205-9EDB-47E112256528.html



n O dispositivo virtual do Horizon 7 Cloud Connector deve acessar a Internet para conversar com o plano de controle do Horizon Cloud e exibir o portal de configuração baseado em navegador. Se o seu ambiente exigir o uso de um servidor proxy e uma configuração de proxy com dispositivos implantados, verifique se você configurou o dispositivo do Horizon 7 Cloud Connector com as configurações de proxy necessárias para o seu ambiente. Consulte as informações relacionadas ao proxy em Preparação para executar o assistente de integração para emparelhar um pod do Horizon 7 com o Horizon Cloud usando o Horizon 7 Cloud Connector, Considerações conhecidas do Horizon 7 Cloud Connector e Como modificar as configurações de proxy para o Horizon 7 Cloud Connector 1.5 ou anterior.

n Você tem as credenciais de uma conta do My VMware associada à conta de cliente do Horizon Cloud à qual está emparelhando o pod. Conforme descrito em Conecte o Horizon Cloud Service com um pod existente do Horizon 7 para usar licenças de assinatura ou serviços hospedados na nuvem do Horizon ou ambos, é necessária uma conta do My VMware para se autenticar no plano de gerenciamento de nuvem para configurar o conector e estabelecer a conexão para usar essa licença para as ofertas de assinatura do Horizon.

Procedimentos

1 Obtenha a URL para iniciar o assistente de integração na tela do console azul do dispositivo.

2 Usando um navegador, navegue até o endereço exibido na tela azul do console do dispositivo.

Importante Nesta etapa, o Horizon 7 Cloud Connector faz uma conexão com o Horizon Cloud para exibir a tela de logon, que será usada para autenticar as credenciais da sua conta My VMware na camada de controle de nuvem. Esta conexão é HTTPS de saída usando a porta 443. Se você não vir uma tela de logon, verifique se você atendeu aos Requisitos de DNS, portas e protocolos ao usar o Horizon 7 Cloud Connector e um pod do Horizon 7.

É exibida a tela de login para fazer login no portal de configuração do Horizon 7 Cloud Connector.

3 Na tela de logon, insira as credenciais da conta My VMware e clique em Logon.

A seguinte captura de tela é um exemplo da tela de logon com as credenciais inseridas antes de clicar em Logon.


VMware, Inc. 65

Se a mensagem de Termos de Serviço for exibida, clique em Aceitar para continuar.

O portal de configuração exibe a primeira etapa do assistente de integração do pod. A captura de tela a seguir ilustra essa etapa antes que os campos sejam preenchidos.

4 No campo Conexão com o Servidor de Conexão do Horizon 7, insira o FQDN da instância do Servidor de Conexão do pod ao qual você está emparelhando o Horizon 7 Cloud Connector.

À medida que você digita no campo, o botão Conectar é exibido.

5 Após digitar o FQDN, clique em Conectar.


VMware, Inc. 66

O Horizon 7 Cloud Connector tenta se comunicar com o Servidor de Conexão especificado e recuperar as informações de certificado dele. Esse processo leva alguns minutos. Quando a comunicação for estabelecida, a página exibirá as informações de certificado recuperadas.

Se o Servidor de Conexão não tiver um certificado da CA raiz válido, uma mensagem de aviso será exibida informando que o certificado não pode ser validado automaticamente, e você deverá confirmar sua validade clicando na caixa de seleção. A captura de tela a seguir é um exemplo da situação.

Se você vir essa mensagem, verifique se as informações do certificado exibidas são precisas e clique na caixa de seleção para passar para a próxima etapa.

Observação Se o servidor de conexão tiver um certificado da autoridade de certificação raiz válido, o assistente validará as informações automaticamente, e você poderá prosseguir para a próxima etapa.

A captura de tela a seguir ilustra a tela que aparece após clicar na caixa de seleção.


VMware, Inc. 67

6 Na seção Credenciais do Horizon 7, digite o nome de domínio e as credenciais de administrador usadas pelo Servidor de Conexão e clique em Conectar.

Essa conta de administrador deve atender aos requisitos, conforme descrito em Preparação para executar o assistente de integração para emparelhar um pod do Horizon 7 com o Horizon Cloud usando o Horizon 7 Cloud Connector. A conta deve ter a função Administradores predefinida do Horizon 7 no grupo de acesso raiz para o pod do Horizon 7.

A captura de tela a seguir ilustra essa área da tela.

Observação Nesse ponto, o sistema detecta se a instância especificada do servidor de conexão já está emparelhada com outra instância do Horizon 7 Cloud Connector. Nesse caso, a página exibe uma mensagem e pergunta se você deseja excluir o emparelhamento existente e emparelhar esse Servidor de Conexão com a instância do Horizon 7 Cloud Connector que você especificou na etapa 4. Para continuar emparelhando o pod com as seguintes etapas, escolha o botão de ação exibido que corresponde ao guia na tela.

A etapa 2 do assistente aparece.

7 Nessa etapa do assistente, forneça detalhes sobre o pod.

A seguinte captura de tela é um exemplo dessa etapa concluída.


VMware, Inc. 68

Esses detalhes são usados no plano de gerenciamento de nuvem para associar ao ambiente do tenant do Horizon Cloud o Horizon 7 Cloud Connector e a instância do Servidor de Conexão emparelhados. Por exemplo, o nome especificado, a localização e a descrição serão visíveis no Console administrativo do Horizon Cloud para que você possa identificar o pod a partir de seus outros pods que estão conectados à camada de controle.

Opção Descrição

Nome Digite um nome fácil para identificar esse pod no ambiente do tenant do Horizon Cloud.

Local do centro de dados Selecione um local existente ou clique em Novo para especificar um novo local a ser usado para o pod. No Console de Administração do Horizon Cloud, seus pods são agrupados e exibidos de acordo com os locais especificados.

Na caixa de texto Nome da Cidade, comece a digitar o nome de uma cidade. O sistema exibe automaticamente nomes de cidades do mundo em sua tabela de pesquisa de geografia de back-end que corresponde aos caracteres inseridos, e você pode escolher uma cidade nessa lista.

Observação Você deve selecionar uma cidade na lista de preenchimento automático do sistema.

Descrição Opcional: insira uma descrição para esse pod.

Pod implantado no VMware Cloud on AWS

Marque essa caixa de seleção se o pod for implantado em um centro de dados definido por software (SDDC) do VMware Cloud on AWS.

8 Vá para a próxima etapa do assistente clicando em Salvar.

A etapa de configuração do assistente é exibida. O sistema verifica a conexão à instância do Servidor de Conexão especificada e conclui as etapas de configuração finais. A captura de tela a seguir é um exemplo dessa etapa.


VMware, Inc. 69

Quando o sistema determina que o pod foi conectado com êxito à camada de controle do Horizon Cloud, uma tela de parabéns aparece com alguns botões de ação e texto de orientação para tarefas de gerenciamento pós-configuração. A captura de tela a seguir é um exemplo dessa tela.

Observação O botão Configurar Atualizações Automáticas do Cloud Connector será exibido apenas se a sua conta de tenant do Horizon Cloud estiver configurada para atualizações automáticas do Horizon 7 Cloud Connector. Para obter detalhes sobre esse recurso, consulte o tópico Upgrade automatizado do dispositivo virtual do Horizon 7 Cloud Connector no Guia de administração.

Resultados

Quando você atinge esse ponto, o fluxo de trabalho de emparelhamento é concluído. Nessa altura, a VMware ativará a licença de assinatura, normalmente dentro de 48 horas depois de emparelhar o pod com a camada de controle de nuvem. Quando a VMware ativar a licença de assinatura, aparecerá uma mensagem no console do administrador do Horizon 7 dizendo que o ambiente do Horizon 7 está usando o tipo de licença de assinatura. A seguinte captura de tela é um exemplo de entrada.

Atenção Se se passarem 48 horas, e você não vir a mensagem Conectado ao Serviço de Licença na área de licenciamento do console do Horizon, entre em contato com seu representante da VMware.


VMware, Inc. 70

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-A060CCC8-8F33-4CE3-A0DF-272D186E6863.html

Próximo passo

A partir desse ponto, o pod é emparelhado com sucesso com o Horizon Cloud . Para obter detalhes sobre as tarefas administrativas e de manutenção do Horizon 7 Cloud Connector que normalmente são realizadas a partir desse ponto em diante, consulte o tópico Tarefas de administração e de manutenção típicas que você executa no Horizon 7 Cloud Connector após o pod do Horizon 7 ser emparelhado com o Horizon Cloud no Guia de administração.

Quando você escolhe a capacidade de nuvem do Microsoft Azure para a implantação do seu primeiro podConecte o Horizon Cloud à sua assinatura do Microsoft Azure para gerenciar e fornecer áreas de trabalho VDI do Microsoft Windows 10 e VMs Windows RDSH virtual para áreas de trabalho e aplicativos remotos baseados em sessão. A configuração do ambiente envolve a implementação do software VMware necessário em sua capacidade do Microsoft Azure. O software implementado da VMware cria uma entidade configurada adequadamente, chamada de um pod, que é combinado com a camada de controle. Depois que o pod tiver sido implantado, use a camada de controle para provisionar áreas de trabalho VDI e RDSHs e autorize o acesso a áreas de trabalho e aplicativos remotos para seus usuários finais.


VMware, Inc. 71




Implantação do Pod no Microsoft AzureO 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.

Você pode implantar mais de um pod no Microsoft Azure e gerenciar todos eles a partir do Console Administrativo do Horizon Cloud. Os pods que você implanta após o primeiro podem reutilizar a mesma VNet do seu primeiro pod ou usar VNets diferentes. Além disso, cada pod pode estar em uma região diferente do Microsoft Azure e usar uma VNet em cada região.

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.


VMware, Inc. 72

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:

n VMs para a instância de gerente do pod (várias VMs para um pod que está ativado para alta disponibilidade)

n VMs para as instâncias do Unified Access Gateway e seus balanceadores de carga

n 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

n VMs para as imagens compatíveis com RDSH mestre

n VMs para as imagens da área de trabalho VDI mestres

n VMs para as imagens (publicadas) atribuíveis que foram criadas com base em imagens mestre

n VMs para os farms RDSH que fornecem as áreas de trabalho e os aplicativos RDSH

n VMs para as áreas de trabalho VDI

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

O diagrama a seguir ilustra um pod implantado e ativado para alta disponibilidade, tem ambos os tipos de configurações de gateway externa e interna, e onde o gateway externo reside na mesma VNet que o pod. 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 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. A partir desta versão, um novo pod sempre é implantado com um recurso de servidor do Banco de Dados do Microsoft Azure para PostgreSQL e um balanceador de carga de pod, mesmo quando você não ativa a opção de alta disponibilidade no assistente. Ter esses recursos disponíveis permite a ativação da alta disponibilidade em um pod já implantado. A segunda VM do gerenciador de pod é implantada apenas quando a alta disponibilidade está ativada no pod. Para obter mais informações, consulte o tópico de documentação intitulado Alta disponibilidade e seu pod do Horizon Cloud on Microsoft Azure no Guia de Administração.


VMware, Inc. 73

https://docs.microsoft.com/en-us/azure/postgresql/overview

https://docs.microsoft.com/en-us/azure/postgresql/overview

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-1DAA5671-5928-47C0-BDAE-E3353A90115D.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-1DAA5671-5928-47C0-BDAE-E3353A90115D.html

Figura 2-1. Ilustração da Arquitetura do Cloud Pod do Horizon para um pod com alta disponibilidade habilitada, com configurações de gateway interno ou externo, o gateway externo implantado na mesma VNet que o pod e um IP público habilitado para o balanceador de carga do gateway externo

VM VM VM VM VM VM VM VM

Rede de gerenciamento

AdminPlano de Controledo Horizon Cloud Internet

Usuárioexterno

Usuáriointerno

VPN do gateway ou

ExpressRoute


BDPostgres

VM base Imagempublicada

RG: vmw-hcs-<podID>-pool-1001

RG: vmw-hcs-<podID>-pool-100n

RG: vmw-hcs-<podID>-base-vms

RG: vmw-hcs-<podID>-jumpbox


NIC/IP

RG: vmw-hcs-<podID>

VM: Gerenciador

de Pod 1

VM: Gerenciador

de Pod 2

RedeDMZ

IP público

VM: UnifiedAccess

Gateway 1

VM: UnifiedAccess

Gateway 2

VM: UnifiedAccess

Gateway 1

VM: UnifiedAccess

Gateway 2


RG: vmw-hcs-<podID>-uag

RG: vmw-hcs-<podID>-uag-internal

Rede deLocatário

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

NIC/IP

Balanceador de carga interno do

Microsoft Azure

2 Gateway de VPNcom túnel IPsec

Conectado à rede externa




VMware, Inc. 74

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-2. Ilustração dos elementos de arquitetura do gateway externo quando o gateway externo é implantado na própria VNet, separado da do pod

Sub-rede de gerenciamento da VNet-2

Admin InternetCamada de controle do

Horizon CloudUsuárioexterno


RG para jumpbox temporária

NIC/IP

VM: Conector

RG para a VM do conectordo gateway

externo

RG para recursos do gateway externo

NIC/IP

Sub-rede (front-end) de zona desmilitarizada da VNet-2

VNet-2

VM: UAG-1


IP do balanceador de carga

Sub-rede de back-end da VNet-2

NIC/IP

NIC/IP

NIC/IP

VM: UAG-2

NIC/IP

NIC/IP

NIC/IP

Referências e terminologia do Microsoft AzureA 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.


VMware, Inc. 75

https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

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.


VMware, Inc. 76

https://docs.microsoft.com/en-us/azure/azure-glossary-cloud-terminology



https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal







https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview


https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction

https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-plan-design

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-plan-design

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-site-to-site-resource-manager-portal

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-site-to-site-resource-manager-portal

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview


https://docs.microsoft.com/en-us/azure/postgresql/


https://docs.microsoft.com/en-us/azure/virtual-desktop/overview

https://docs.microsoft.com/en-us/azure/virtual-desktop/overview

Recursos da VMware adicionaisOs seguintes recursos fornecem detalhes técnicos sobre o serviço.

Recursos técnicos adicionais da VMware Descrição

Lista de verificação de requisitos Use esta lista de verificação para saber mais sobre os recursos necessários a serem obtidos e configurados antes de iniciar o processo de implantação do pod.

Considerações de rede e do Active Directory no Microsoft Azure com o VMware Horizon Cloud

Leia este artigo para saber mais sobre as várias opções e práticas recomendadas para as conexões de rede e o uso do Microsoft Active Directory com os pods do Horizon Cloud no Microsoft Azure.

Considerações de segurança do Horizon Cloud Service on Microsoft Azure

Use este artigo para obter informações sobre os detalhes de segurança de um ambiente e os tipos de dados armazenados.

Horizon Cloud on Microsoft Azure: área de trabalho RDS e dimensionamento de aplicativo (download do artigo técnico)

Use este artigo para obter informações de análises de dimensionamento da área de trabalho RDS e do aplicativo remoto e as densidades ideais de usuários, bem como considerações de custo relacionadas às configurações de gerenciamento de energia e de implantação de farm.

Fluxo de trabalho de alto nível para quando o primeiro pod conectado à nuvem estiver sendo implantado no Microsoft AzureEsta é uma lista de alto nível das etapas para usar o assistente no Horizon Cloud para criar seu primeiro pod conectado à nuvem implantando um pod na sua capacidade do Microsoft Azure. Após esse primeiro pod conectado à nuvem ser totalmente implantado e você tiver concluído as etapas para registrar o Horizon Cloud com o domínio do Active Directory pretendido do pod, você poderá usar todos os recursos fornecidos do Horizon Cloud, especialmente para o provisionamento de áreas de trabalho VDI, áreas de trabalhos baseadas em sessão RDSH ou aplicativos remotos baseados em RDSH para os seus usuários finais a partir desse pod.

Execute as seguintes etapas quando estiver implantando seu primeiro pod conectado à nuvem e usando o assistente para implantá-lo no Microsoft Azure.

1 Atenda aos pré-requisitos. Consulte Lista de verificação de requisitos do VMware Horizon Cloud Service on Microsoft Azure para novas implantações do pod — Atualizada para o versão de serviço de 2020.

2 Execute as tarefas preparatórias fora do Horizon Cloud. Consulte Preparar para implementar um pod do Horizon Cloud no Microsoft Azure.

3 Verifique se você atende aos requisitos de DNS, de portas e de protocolo para a implantação do pod. Consulte 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.

4 Implante o pod. Consulte Implantar um pod do Horizon Cloud no Microsoft Azure.

5 Registre seu domínio do Active Directory com o pod implantado, o que inclui fornecer o nome de uma conta de ingresso no domínio. Consulte o Guia de administração do Horizon Cloud.


VMware, Inc. 77

http://www.vmware.com/info?id=1434

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/horizon/vmw-wp-networking-ad-horizon-cloud-azure-uslet-20171201.pdf



https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/horizon/vmw-wp-horizon-cloud-microsoft-azure-uslet-white-paper.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/horizon/vmw-wp-horizon-cloud-microsoft-azure-uslet-white-paper.pdf

https://secure.vmware.com/44435_REG



6 Conceda a função de Superadministradores do Horizon Cloud a um grupo do Active Directory que inclua essa conta de ingresso no domínio como um membro.

Importante Você deve garantir que a conta de ingresso no domínio inserida ao registrar o domínio também esteja em um dos grupos do Active Directory ao qual você atribuiu a função de Superadministradores do Horizon Cloud. As operações de ingresso no domínio do sistema dependem se a conta de ingresso no domínio tem a função de Superadministradores do Horizon Cloud. Consulte o Guia de administração do VMware Horizon Cloud Service on Microsoft Azure.

7 Se você planeja usar o Workspace ONE Access com o pod ou pretende ter o Horizon Clients conectado diretamente ao pod (não por meio de uma configuração de gateway de pod), execute estas etapas:

n No seu servidor DNS, mapeie um nome de domínio completo (FQDN) para o endereço IP do dispositivo do tenant do pod.

n Obter um certificado SSL com base nesse FQDN mapeado

Você carregará um certificado SSL para o pod que é baseado no FQDN que você mapeou para o endereço IP do dispositivo do tenant do pod em seu DNS para que as conexões que vão para o pod façam conexões confiáveis. Essas conexões incluem Horizon Clients, para seus usuários aos quais você concede esse FQDN mapeado, e o Conector do Workspace ONE Access que é usado quando você integra o Workspace ONE Access ao pod. O Conector do Workspace ONE Access deve se conectar ao pod usando um FQDN mapeado para o endereço IP do dispositivo do tenant do pod.

Atenção Quando você estiver integrando o Workspace ONE Access ao pod, deverá carregar um certificado SSL para o pod e configurar o Workspace ONE Access para apontar para o pod, não para as configurações do Unified Gateway Access do pod.

No entanto, tenha em mente que, após carregar um certificado SSL com base no FQDN mapeado para DNS, se você tentar se conectar digitando diretamente esse FQDN em um navegador — sem passar por um Workspace ONE Access corretamente configurado — esse uso de FQDN puro aparecerá como conexões não confiáveis com o navegador. A razão é porque apenas carregar esse FQDN em um navegador é uma conexão usando o HTML Access (Blast) e é assim que o HTML Access (Blast) se comporta. Como resultado, quando você carrega esse FQDN em um navegador, ele exibe o erro de certificado não confiável típico.

Na ausência do Workspace ONE Access, para ter conexões usando o HTML Access (Blast) — usando basicamente um navegador — evite o erro de certificado não confiável exibido. Você deve colocar uma configuração de gateway no pod e fazer com que essas conexões usem o balanceador de carga e as instâncias do Unified Access Gateway dessa configuração de gateway. Se você não deseja expor seu FQDN à Internet, poderá implantar uma configuração interna do Unified Access Gateway. Essa configuração interna do Unified Access Gateway usa um balanceador de carga interno da Microsoft com o qual os usuários finais, que são internos à sua rede corporativa, podem realizar suas conexões.


VMware, Inc. 78

8 Carregue um certificado SSL para o pod diretamente, usando a página de resumo do pod no Console Administrativo, se você pretender ter um ou ambos os casos de uso descritos na etapa anterior.Consulte o Guia de administração do Horizon Cloud.

Dica Se o único caso de uso de acesso que você deseja suportar é onde as conexões irão para as instâncias do Unified Access Gateway do pod por meio do balanceador de carga conectado a essas instâncias, então carregar o certificado SSL diretamente para o pod será supérfluo. Ainda assim, realizar a etapa 6 acima e esta etapa 7 é uma prática recomendada, pois garante que, se você um dia informar esse FQDN para que os usuários insiram em seus Horizon Clients, esses clientes poderão ter conexões confiáveis. Realizar a etapa 6 e esta etapa 7 também oferece a capacidade de integrar mais rapidamente o pod ao Workspace ONE Access, pois você teria o FQDN mapeado e o certificado SSL já implantado no pod.

9 Importe uma imagem mestre. Na página VMs Importadas, use a ação Redefinir Emparelhamento de Agente para emparelhar a nova imagem mestre com o Horizon Cloud. Consulte o Guia de administração do Horizon Cloud.

10 Dependendo se a sua imagem mestre é para provisionamento de áreas de trabalho VDI ou para áreas de trabalho de sessão baseadas em RDSH e aplicativos remotos baseados em RDSH, execute uma ou mais das seguintes etapas conforme apropriado: Para saber quais são as etapas detalhadas, consulte o Guia de administração do Horizon Cloud. n Em uma imagem mestre para áreas de trabalho VDI, instale os aplicativos de terceiros que você

deseja que seus usuários finais usem em suas áreas de trabalho VDI e configure outras personalizações aplicáveis, como a configuração de papel de parede da área de trabalho, a instalação dos drivers de GPU NVIDIA (para imagens ativadas por GPU) e assim por diante. Otimize também a imagem das práticas recomendadas do Sysprep da Microsoft, caso isso não seja feito como parte do processo de importação de imagens. Consulte o Guia de administração do Horizon Cloud.

n Na imagem compatível com RDS mestre para provisionamento de aplicativos remotos e áreas de trabalho de sessão baseadas em RDSH, instale os aplicativos de terceiros que você deseja fornecer aos seus usuários finais a partir dessa imagem RDS e configure outras personalizações aplicáveis, como configuração de papel de parede da área de trabalho, instalação dos drivers de GPU NVIDIA (para imagens ativadas por GPU) e assim por diante. Otimize também a imagem das práticas recomendadas do Sysprep da Microsoft, caso isso não seja feito como parte do processo de importação de imagens. Se a VM importada estiver executando um dos sistemas de várias sessões do Windows 10 Enterprise da Microsoft que inclui o Office 365 ProPlus por padrão, você deverá verificar se a VM está configurada para a ativação do computador compartilhado para o Office 365 ProPlus, conforme descrito no tópico da documentação da Microsoft denominado Visão geral da ativação do computador compartilhado para o Office 365 ProPlus. Se o Office 365 ProPlus não estiver configurado para a ativação do computador compartilhado na VM importada, use o método descrito no documento da Microsoft apropriado para a sua situação. Consulte o Guia de administração do Horizon Cloud.

11 Converta essa imagem mestre em uma imagem atribuível, também conhecido como selamento ou publicação da imagem. Consulte o Guia de administração do Horizon Cloud.


VMware, Inc. 79

https://docs.microsoft.com/en-us/deployoffice/overview-of-shared-computer-activation-for-office-365-proplus

https://docs.microsoft.com/en-us/deployoffice/overview-of-shared-computer-activation-for-office-365-proplus

12 Para provisionar áreas de trabalho RDSH baseadas em sessão RDSH e aplicativos remotos a partir de uma imagem de servidor mestre publicada:

a Crie um farm RDSH de áreas de trabalho para fornecer áreas de trabalho de sessão e crie atribuições autorizar os usuários finais a usarem essas áreas de trabalho. Consulte o Guia de administração do Horizon Cloud.

b Crie um farm RDSH de aplicativos para fornecer aplicativos remotos, adicionar os aplicativos ao seu inventário de aplicativos e criar atribuições para autorizar os usuários a usarem esses aplicativos remotos. Consulte o Guia de administração do Horizon Cloud.

13 Para provisionar as áreas de trabalho VDI a partir de uma imagem da área de trabalho VDI mestre publicada, crie uma atribuição de área de trabalho VDI dedicada ou flutuante. Consulte o Guia de administração do Horizon Cloud.

14 Quando um pod é implantado com uma configuração de gateway, você deve criar um registro CNAME no servidor DNS que mapeie o nome de domínio completo (FQDN) inserido no assistente de implantação para o recurso apropriado do balanceador de carga do Azure configurado no pod para esse gateway.

n Para um gateway externo habilitado com um endereço IP público, mapeie o FQDN que você inseriu no assistente de implantação para o FQDN público gerado automaticamente do recurso do balanceador de carga do Azure do gateway. Seu registro do servidor DNS mapeia esse FQDN público gerado automaticamente do balanceador de carga com o FQDN que os usuários finais usarão e que é usado no certificado enviado. A linha de código a seguir mostra um exemplo. Você localiza a ID a ser usada na página de detalhes do pod no Console Administrativo, após ter registrado o domínio do Active Directory. Se o gateway externo tiver sido implantado na própria VNet, use a ID exibida no campo ID de Implantação.

ourApps.ourOrg.example.com vwm-hcs-ID-uag.região.cloudapp.azure.com

n Para um gateway interno ou externo sem um endereço IP público, mapeie o FQDN que você inseriu no assistente de implantação para o endereço IP privado do recurso do balanceador de carga do Azure do gateway. Seu registro do servidor DNS mapeia esse endereço IP do balanceador de carga com o FQDN que os usuários finais usarão e que é usado no certificado carregado. A linha de código a seguir mostra um exemplo.

ourApps.ourOrg.example.com Azure-load-balancer-private-IP

Quando o pod estiver integrado, e você puder acessar a página Capacidade no Console Administrativo, navegue até a página Capacidade para ver o valor vmw-hcs-ID-uag.region.cloudapp.azure.com necessário para mapear o FQDN no DNS.

Para obter detalhes sobre como localizar o FQDN do balanceador de carga no Console Administrativo, consulte o Guia de administração do Horizon Cloud.


VMware, Inc. 80

15 Quando um pod é implantado para ter a autenticação de dois fatores RADIUS para os gateways do pod, você deve concluir as seguintes tarefas:

n Se você tiver configurado um gateway externo com configurações RADIUS, e esse servidor RADIUS não estiver acessível na mesma VNet usada pelo pod, ou na topologia VNet emparelhada se você tiver implantando o gateway externo na própria VNet, configure o servidor RADIUS a permitir conexões de cliente a partir do endereço IP do balanceador de carga do gateway externo. Em uma configuração gateway externo, as instâncias do Unified Access Gateway tentam entrar em contato com o servidor RADIUS usando esse endereço do balanceador de carga. Para permitir as conexões, verifique se o endereço IP do recurso do balanceador de carga que está no grupo de recursos do gateway externo está especificado como um cliente na configuração do seu servidor RADIUS.

n Se você tiver configurado um gateway interno ou externo e seu servidor RADIUS estiver acessível na mesma VNet usada pelo pod, configure o servidor RADIUS para permitir conexões dos NICs apropriados que foram criados no grupo de recursos do gateway no Microsoft Azure que deve se comunicar com o servidor RADIUS. O administrador de rede determina a visibilidade da rede do servidor RADIUS para as sub-redes e a rede virtual do Azure do pod. Seu servidor RADIUS deve permitir conexões de cliente a partir dos endereços IP desses NICs de gateway que correspondem à sub-rede para a qual o administrador de rede forneceu visibilidade de rede ao servidor RADIUS. O grupo de recursos do gateway no Microsoft Azure tem quatro NICs que correspondem a essa sub-rede, duas que estão ativas atualmente para as duas instâncias do Unified Access Gateway e duas que estão ociosas e se tornarão as ativas após o pod passar por uma atualização. Para oferecer suporte à conectividade entre o gateway e o servidor RADIUS tanto para operações de pod contínuo quanto após cada atualização de pod, certifique-se de que os endereços IP dessas quatro NICs sejam especificados como clientes na configuração do servidor RADIUS.

Para obter informações sobre como obter esses endereços IP, consulte o Guia de Administração.

Após a conclusão das etapas do fluxo de trabalho acima, seus usuários finais podem iniciar as áreas de trabalho e os aplicativos remotos aos quais têm direito utilizando seu FQDN no Horizon Client ou por meio do HTML Access.

Você pode encontrar mais detalhes sobre como concluir cada etapa do fluxo de trabalho nos tópicos vinculados de cada etapa acima ou no guia complementar. Consulte o Guia de administração do Horizon Cloud.


VMware, Inc. 81

Preparar para implementar um pod do Horizon Cloud no Microsoft AzureAntes de fazer login no Console Administrativo do Horizon Cloud e executar o assistente de implantação do pod pela primeira vez, é necessário executar estas tarefas preparatórias.

1 Cumpra os pré-requisitos descritos na Lista de verificação de requisitos do VMware Horizon Cloud Service on Microsoft Azure para novas implantações do pod — Atualizada para o versão de serviço de 2020, especialmente:

n Garanta que sua conta e assinatura do Microsoft Azure abrangem o número e os tamanhos de máquinas virtuais necessários do pod, incluindo as configurações opcionais do Unified Access Gateway se você planeja implantá-las. Consulte Requisitos de máquina virtual do Microsoft Azure para um pod do Horizon Cloud no Microsoft Azure.

Se você planeja implantar o pod com uma configuração de gateway externo que usa a própria assinatura, separada da do pod, garanta que a outra assinatura abrange o número e os tamanhos de máquinas virtuais necessários do gateway externo. Para esse caso de uso, essa assinatura separada precisará da própria VNet, pois as VNets não abrangem as assinaturas. Além disso, essa assinatura deve estar na mesma região que a assinatura do pod, pois a topologia da VNet com suporte está conectando VNets na mesma região do Microsoft Azure.

n Conforme descrito na Lista de verificação de requisitos do VMware Horizon Cloud Service on Microsoft Azure para novas implantações do pod — Atualizada para o versão de serviço de 2020, certifique-se de que sua assinatura não restrinja o uso do tipo de conta StorageV1 do Azure, não restrinja a criação de grupos de recursos não marcados ou não exija etiquetas específicas em seus grupos de recursos e não tenha nenhuma política do Azure que poderiam bloquear, negar ou restringir a criação dos componentes do pod nessa assinatura.

Cuidado O processo de implantação de pod falhará no início se a sua assinatura restringir esses itens, pois a primeira etapa de criação do grupo de recursos da jumpbox temporária e de implantação da jumpbox não será concluída. Portanto, se o processo de implantação de seu pod expirar após duas horas, primeiro verifique se a sua assinatura tem políticas do Azure ativas que poderiam bloquear, negar ou restringir a criação de grupos de recursos com base em critérios específicos.

n Certifique-se de que haja uma rede virtual (VNet) na região em que o pod será implantado e que essa rede virtual atenda aos requisitos para um pod do Horizon Cloud. Se você não tiver uma VNet existente, crie uma que atenda aos requisitos. Consulte Configurar a rede virtual necessária no Microsoft Azure.


VMware, Inc. 82

Se você planeja implantar o pod com uma configuração de gateway externo que usa a própria VNet, separada da do pod — ou que usa a própria assinatura separada da assinatura do pod, verifique se a VNet existe na mesma região que a VNet do pod e se ela atende aos Configurar a rede virtual necessária no Microsoft Azure. Para esse caso de uso, essas duas VNets devem ser emparelhadas.

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.

n Se quiser criar manualmente as sub-redes para o pod na sua VNet antes de implantá-lo, certifique-se de que o número necessário de sub-redes seja criado na sua VNet, que seus espaços de endereço atendam aos Configurar a rede virtual necessária no Microsoft Azure e que elas estejam sem recursos. Antes da implantação de pod, crie as sub-redes necessárias do pod do Horizon Cloud na VNet no Microsoft Azure.

Cuidado Essas sub-redes criadas na sua VNet para a implantação do pod devem estar vazias. Você pode criar as sub-redes antes de implantar o pod, mas não coloque recursos nelas nem use qualquer um dos endereços IP. Se um endereço IP já estiver em uso nas sub-redes, a implantação do pod poderá falhar.

Se você não quiser criar as sub-redes com antecedência, o processo de implantação do pod as criará usando as informações de CIDR inseridas no assistente na tela.

n Verifique se rede virtual está configurada para apontar para um servidor DNS (Serviços de Nome de Domínio) válido que esteja resolvendo os nomes externos. Consulte Defina as configurações do servidor DNS necessárias pela topologia de VNet que você usará para os pods do Horizon Cloud no Microsoft Azure.

Importante O processo de implantação do pod requer a resolução de nome interno e externo. Se a VNet apontar para um servidor DNS que não possa resolver nomes externos, o processo de implantação falhará.

n Se você planeja implantar o pod com uma configuração de gateway externo em um grupo de recursos existente que você cria em uma assinatura separada da assinatura do pod — em vez de fazer com que o implantador crie automaticamente esse grupo de recursos — garanta que o grupo de recursos exista nessa assinatura antes de iniciar o assistente de implantação de pod. Decida se deseja definir as permissões que o Horizon Cloud precisa no nível do grupo de recursos ou no nível da assinatura. Consulte Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure.

n Verifique se você tem uma configuração do Active Directory com suporte ao uso com esta versão, se a sua rede virtual pode acessá-la e se o servidor DNS pode resolver o seu nome. Consulte Configurações de domínio do Active Directory.


VMware, Inc. 83

https://azure.microsoft.com/en-us/regions/services/


2 Crie o número necessário de entidades de serviço, de acordo com as opções de implantação planejadas. Se você estiver implantando a configuração de gateway externo do pod na própria assinatura, precisará de uma entidade de serviço para essa assinatura, bem como para a assinatura usada para o pod em si. Para ver as etapas detalhadas, consulte Crie a entidade de serviço necessária para o implantador do pod do Horizon Cloud através da criação de um registro de aplicativo.

Importante Cada entidade de serviço que você configura para o uso do Horizon Cloud deve receber uma função apropriada na assinatura associada da entidade de serviço. A função para uma entidade de serviço deve permitir que as ações de que o Horizon Cloud precisa para operar nos recursos gerenciados do Horizon Cloud na assinatura associada do Microsoft Azure dessa entidade de serviço. A entidade de serviço para a assinatura do pod precisa de uma função que permita que as ações implantem o pod com êxito, operem no pod e nos recursos gerenciados por pod a fim de atender aos fluxos de trabalho de administrador iniciados usando o Console administrativo do Horizon Cloud e preservem o pod com o tempo. Ao usar uma assinatura separada para a configuração externa do Unified Access Gateway do pod, a entidade de serviço para essa assinatura precisa de uma função que permita que as ações implantem os recursos necessários para essa configuração de gateway, operem nesses recursos gerenciados pelo Horizon Cloud a fim de atender aos fluxos de trabalho do administrador e preservem os recursos relacionados ao gateway ao longo do tempo.

Conforme descrito em Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure, a entidade de serviço deve receber acesso usando um dos seguintes métodos:n No nível da assinatura, atribua a função de Colaborador. A função de Colaborador é uma das

funções internas do Microsoft Azure. A função de Colaborador está descrita em Funções internas para recursos do Azure na documentação do Microsoft Azure.

n No nível da assinatura, atribua uma função personalizada que você tenha configurado para fornecer à entidade de serviço Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure de que o Horizon Cloud precisa para a implantação dos recursos relacionados ao pod e para fluxos de trabalho contínuos iniciados pelo administrador e operações de manutenção de pod.

n Ao usar uma assinatura separada para a configuração externa do Unified Access Gateway e implantar em um grupo de recursos existente, uma combinação válida é conceder acesso à entidade de serviço para acessar o grupo de recursos e a VNet associada usando uma função que fornece permissões de escopo estreito, além de conceder acesso à entidade de serviço para acessar a assinatura usando a função integrada de Leitor.

3 No portal do Microsoft Azure, para a assinatura do pod e a assinatura de seu gateway externo (se estiver usando essa opção de implantação), obtenha os valores para o ID de assinatura do Microsoft Azure, o ID de aplicativo, a chave de autenticação de aplicativo e o ID de diretório do Microsoft Azure AD do portal do Microsoft Azure. Esses recursos são usados pelo Horizon Cloud para realizar as operações na sua assinatura do Microsoft Azure. Consulte Informações relacionadas à assinatura para o assistente de implantação de pod do Horizon Cloud.


VMware, Inc. 84

https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles


4 Se estiver implantando o pod com uma configuração do Unified Access Gateway, obtenha o certificado de servidor TLS/SSL assinado, que pode permitir que os clientes dos seus usuários finais confiem em conexões com as áreas de trabalho e os aplicativos remotos. Esse certificado deve corresponder ao FQDN que seus usuários finais usarão nos clientes e ser assinado por uma Autoridade de Certificação (CA) confiável. Além disso, todos os certificados na cadeia de certificados devem ter períodos de tempo válidos, incluindo quaisquer certificados intermediários. Se qualquer certificado da cadeia tiver expirado, falhas inesperadas poderão ocorrer mais tarde no processo de integração de pod.

O Unified Access Gateway apresenta seu certificado assinado pela CA, para que os clientes dos usuários finais possam confiar nas conexões. Para oferecer suporte ao acesso confiável da Internet, implante uma configuração externa do Unified Access Gateway para o pod. Para oferecer suporte ao acesso confiável na sua rede corporativa, use uma configuração interna do Unified Access Gateway. Ambos os tipos de configuração podem ser implantados durante o processo de implantação de pod inicial ou a implantação após o pod usando o fluxo de trabalho Editar Pod.

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.

5 Se o certificado de servidor SSL assinado que você usará com a configuração do Unified Access Gateway não estiver no formato PEM ou não for um único arquivo PEM contendo a cadeia de certificados completa com a chave privada, converta as informações do certificado no formato PEM necessário. Consulte as etapas em Converter um arquivo de certificado para o formato PEM necessário para a implantação do pod.

6 Obtenha uma conta do My VMware e registre-se no Horizon Cloud, se ainda não estiver registrado.

Após concluir estas tarefas preparatórias, efetue login no Console de administração do Horizon Cloud em cloud.horizon.vmware.com utilizando a sua conta do My VMware. Após fazer login, você verá a área Adicionar Capacidade de Nuvem na tela e poderá clicar em Adicionar para iniciar o assistente de implantação do pod. Conclua o assistente inserindo as informações necessárias em cada tela. Para ver as etapas detalhadas, consulte Implantar um pod do Horizon Cloud no Microsoft Azure.

Observação A autenticação de logon no Console Administrativo do Horizon Cloud baseia-se nas credenciais de conta do My VMware. Se o sistema de conta do My VMware estiver passando por uma falha do sistema e não puder obter as solicitações de autenticação, você não poderá fazer logon no Console Administrativo durante esse período de tempo. Se você encontrar problemas para fazer logon na primeira página de logon do Console Administrativo, 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.

Requisitos de máquina virtual do Microsoft Azure para um pod do Horizon Cloud no Microsoft Azure

Implantações de pod, implantações das configurações de gateway do pod e operações padrão exigem tipos e tamanhos específicos de máquinas virtuais (VMs) em sua capacidade de nuvem do Microsoft Azure. Sua assinatura precisa ter as cotas e a configuração apropriadas para ter compatibilidade com essas VMs. Quando você estiver usando a opção de implantar o gateway externo do pod em uma


VMware, Inc. 85


https://status.horizon.vmware.com

assinatura separada, essa assinatura precisará da quota e da configuração para suportar a configuração do gateway externo.

Importante O assistente de implantação do pod valida que seu ambiente do Microsoft Azure possui uma quota suficiente de núcleos para criar o pod e a configuração do gateway que você especificou, se houver. Se o assistente determinar que não há quota suficiente dadas as informações de assinatura especificadas no assistente, uma mensagem na tela será exibida, e o assistente não prosseguirá para a próxima etapa.

Começando com a versão de manifesto do pod de setembro de 2019, tanto para os pods implantados recentemente nessa versão quanto para os pods atualizados para essa versão, cada pod tem um balanceador de carga do Microsoft Azure e uma base de dados do Microsoft Azure para o servidor PostgreSQL. Quando um pod é atualizado para o manifesto de setembro de 2019 ou para versões posteriores, o pod atualizado inclui um balanceador de carga do Microsoft Azure e uma base de dados do Microsoft Azure para o servidor PostgreSQL. O servidor do Banco de Dados do Microsoft Azure para PostgreSQL é implantado usando-se a implantação de servidor único.

Observação VMs habilitadas por GPU estão disponíveis somente em algumas regiões do Microsoft Azure. Para obter mais detalhes, consulte Produtos do Microsoft Azure por região.

Nas tabelas abaixo, a coluna de especificação de VM fornece:

n Os nomes de série que são usados na documentação do Microsoft Azure

n Os nomes da família de vCPUs que são usadas nas cotas exibidas no portal do Microsoft Azure

n O nome específico do tipo de VM dessa família

Para ver as quotas atuais de uma assinatura no portal do Microsoft Azure, vá para Todos os serviços > Assinaturas, clique na assinatura e em Uso + Quotas. Para obter mais informações sobre os tamanhos das máquinas virtuais do Microsoft Windows no Microsoft Azure, consulte este tópico e seus subtópicos na documentação do Microsoft Azure: https://docs.microsoft.com/pt-br/azure/virtual-machines/windows/sizes.

Tabela 2-2. Requisitos de VM jumpbox do pod

VM Especificação de VM do Microsoft Azure

Quantidade

Descrição

Jumpbox Família F padrão do Linux:

Standard_F2 (2 núcleos, 4 GB de

memória)

Disco de SO: padrão HDD 30 GiB

1 por pod Uma VM criada no ambiente do Microsoft Azure e utilizada durante a criação do

pod inicial e durante as atualizações de software subsequentes no ambiente.

Uma VM jumpbox para cada pod implantado. Essa VM jumpbox é excluída

automaticamente quando o processo de criação ou atualização do pod é

concluído e a VM não é mais necessário.

Observação Uma VM jumpbox é recém-implantada para criar um pod, para

compilar os componentes verdes de uma atualização quando a próxima versão

do software do pod estiver disponível, para orquestrar o processo de atualização

azul/verde no pod e para o processo de adicionar uma configuração de gateway

a um pod existente.


VMware, Inc. 86


https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes


Tabela 2-3. Quando se tem o gateway externo em uma VNet separada: requisitos de VM jumpbox


Quantidade

Descrição

Jumpbox Família F padrão do Linux:

Standard_F2 (2 núcleos, 4 GB de

memória)


1 por pod Ao implantar opcionalmente o gateway externo na própria assinatura ou VNet,

ele precisa de uma VM jumpbox separada da usada para os próprios recursos

principais do pod. Essa VM jumpbox é criada no ambiente do Microsoft Azure em

um grupo de recursos separado da VM jumpbox do pod e é usada durante a

implantação inicial da configuração do gateway externo e durante as atualizações

de software subsequentes nesse gateway externo. Uma VM jumpbox para cada

gateway externo em sua própria VNet ou assinatura que você implanta. Essa VM

jumpbox é excluída automaticamente quando o processo de implantação ou de

atualização do gateway externo é concluído, e a VM não é mais necessária.

Observação Uma VM jumpbox é recém-implantada para criar um desses

gateways externos na própria VNet ou assinatura (durante a criação de pod ou

ao usar o fluxo de trabalho Editar Pod para adicionar o gateway externo a um

pod existente), para compilar os componentes verdes de uma atualização para

esse gateway externo quando a próxima versão do software do pod ou gateway

externo for disponibilizada para você, para orquestrar o processo de atualização

azul/verde nesse gateway externo.


VMware, Inc. 87

Tabela 2-4. Requisitos de VM de gerenciamento de pod - Para as VMs principais do pod, sem incluir as configurações de gateway


Quantidade Descrição

Pod sem

alta

disponibilid

ade

habilitada:

instâncias

de

gerenciam

ento de

pod

Linux - Família Dv3 padrão:

Standard_D4_v3 (4 núcleos, 16 GB

de memória).


Observação Se o tipo

Standard_D4_v3 não estiver

disponível na sua região do

Microsoft Azure, o implantador

usará Standard_D3_v2 (4 núcleos,

14 GB de memória) da família Dv2

padrão.

1 por pod durante as operações em

estado estável

2 por pod durante o tempo de ponta-a-

ponta para o processo de atualização

azul/verde do pod.

Para um pod sem alta disponibilidade habilitada,

durante as operações em estado estável, há uma

VM, que é ligada e que executa o pod. Quando um

novo manifesto de pod é disponibilizado a você

pelas Operações da VMware, e o sistema começa

a criar os componentes verdes para o processo de

atualização azul/verde do pod, e uma segunda

instância é criada e ligada. Como parte do

processo de atualização de ponta-a-ponta, você

agenda a hora em que o sistema passará a usar os

componentes verdes. Após a conclusão dessa

mudança, o pod usará a VM recém-criada para

operações em estado estável, e aquela usada

anteriormente no conjunto de componentes azuis é

interrompida e excluída.

O tamanho do seu ambiente deve acomodar as

duas instâncias do gerenciador de pods em

execução lado a lado para o período de atualização

de ponta-a-ponta a partir do momento em que o

sistema começa a criar os componentes verdes do

pod para o processo de atualização azul/verde,

para quando as atividades de atualização forem

concluídas e o pod passar a usar os novos

componentes verdes. Consulte o Guia de

Administração para obter uma descrição do

processo de atualização azul/verde do pod.

Pod

habilitado

à alta

disponibilid

ade:

instâncias

de

gerenciam

ento de

pod

Linux - Família Dv3 padrão:

Standard_D4_v3 (4 núcleos, 16 GB

de memória).


Observação Se o tipo

Standard_D4_v3 não estiver

disponível na sua região do

Microsoft Azure, o implantador do

pod usará Standard_D3_v2 (4

núcleos, 14 GB de memória) da

família Dv2 padrão.

2 por pod durante as operações em

estado estável

4 por pod durante o tempo de ponta-a-

ponta para o processo de atualização

azul/verde do pod.

Para um pod habilitado à alta disponibilidade,

durante as operações em estado estável, há duas

VMs ligadas, que são ligadas e que executam o

pod. Quando um novo manifesto de pod é

disponibilizado a você pelas operações da VMware,

e o sistema começa a criar os componentes verdes

para o processo de atualização azul/verde do pod,

uma segunda instância por VM de gerenciador de

pods é criada e ligada. Nesse momento, o total de

VMs do gerenciador de pods em execução é de

quatro (4). Como parte do processo de atualização

de ponta-a-ponta, você agenda a hora em que o

sistema passará a usar os componentes verdes.

Após a conclusão dessa mudança, o pod usará as

duas VMs recém-criadas para operações em

estado estável, e as duas usadas anteriormente no

conjunto de componentes azuis são interrompidas

e excluídas.


quatro instâncias do gerenciador de pods em

execução lado a lado para o período de atualização

de ponta-a-ponta a partir do momento em que o

sistema começa a criar os componentes verdes do

pod para o processo de atualização azul/verde,


VMware, Inc. 88

Tabela 2-4. Requisitos de VM de gerenciamento de pod - Para as VMs principais do pod, sem incluir as configurações de gateway

(continuação)



para quando as atividades de atualização forem

concluídas e o pod passar a usar os novos

componentes verdes. Consulte o Guia de

Administração para obter uma descrição do

processo de atualização azul/verde do pod.


VMware, Inc. 89

Tabela 2-5. Requisitos de VM do Unified Access Gateway



Instâncias

do Unified

Access

Gateway

Família Av2 padrão do Linux:

Standard_A4_v2 Standard (4

núcleos, 8 GB de memória)


Varia com base em se você escolher

uma configuração externa ou interna

para o Unified Access Gateway ou

ambos os tipos no mesmo pod.

Para uma configuração somente

externa ou somente interna:

n 2 por pod durante as operações

em estado estável

n 4 por pod durante o tempo de

ponta-a-ponta para atividades de

atualização azul/verde

relacionadas ao pod.

Para um pod com tanto uma

configuração interna quanto uma

externa do Unified Access Gateway,

n 4 por pod durante as operações

em estado estável

n 8 por pod durante o tempo de

ponta-a-ponta para atividades de

atualização azul/verde

relacionadas a pod.

O Unified Access Gateway é um recurso opcional

implantado para seu pod quando você define as

configurações de gateway no assistente de

implantação. Se você optar por ter instâncias do

Unified Access Gateway para o pod, seu ambiente

deverá acomodar essas instâncias em execução

durante o processo de atualização azul/verde

ponta-a-ponta do pod. O número de instâncias de

estado estável depende de você optar por ter

ambas as configurações externa e interna do

Unified Access Gateway.

Quando você tem apenas uma configuração

externa ou apenas uma configuração interna do

Unified Access Gateway, durante operações de

estado estável, existem duas instâncias ligadas que

fornecem os recursos do Unified Access Gateway.

Durante um processo de atualização, duas

instâncias adicionais são criadas e ligadas para

executar as atualizações de software no Unified

Access Gateway. Após a conclusão da atualização,

o pod migra para o uso das VMs recém-criadas, e

as usadas anteriormente no conjunto de

componentes azuis são interrompidas e excluídas.

Quando você tem ambas as configurações interna

e externa do Unified Access Gateway, durante

operações de estado estável, existem quatro

instâncias ligadas que fornecem os recursos do

Unified Access Gateway. Duas instâncias fornecem

os recursos da configuração externa e duas

fornecem os recursos da configuração interna.

Durante um processo de upgrade, duas instâncias

adicionais por configuração são criadas e ligadas

para executar as atualizações de software no

Unified Access Gateway. Após a conclusão da

atualização, o pod migra para o uso das VMs

recém-criadas, e as usadas anteriormente no

conjunto de componentes azuis são interrompidas

e excluídas.


instâncias do Unified Access Gateway indicadas

em execução lado a lado para o período de

atualização de ponta-a-ponta a partir do momento

em que o sistema começa a compilar os

componentes verdes do pod para o processo de

atualização azul/verde, de modo que as atividades

de atualização sejam concluídas e o pod passe a

usar os novos componentes verdes. Consulte o

Guia de Administração para obter uma descrição

do processo de atualização azul/verde do pod.


VMware, Inc. 90

Tabela 2-6. Quando se tem o gateway externo em um VNet separada: requisitos de VM de conector de gateway



Instância

do

conector

do

gateway

Família Av2 padrão do Linux:

Padrão Standard_A1_v2 (1 núcleo,

2 GB de memória)


1 por este tipo de gateway externo

durante operações de estado estável

2 por esse tipo de gateway externo

durante o tempo de ponta-a-ponta para

atividades de atualização azul/verde

relacionadas ao pod.

Quando o gateway externo é implantado em uma

VNet separada, essa VM é criada e usada para as

operações de gerenciamento de nuvem nessa

configuração de gateway externo. Durante um

processo de atualização, uma instância adicional é

criada e ligada para executar as atualizações de

software no Unified Access Gateway na

configuração de gateway externo. Após a

conclusão da atualização, ocorre a migração para a

VM recém-criada, e a usada anteriormente é

interrompida e excluída. Se você decidir usar essa

configuração opcional, seu ambiente deverá

acomodar essas instâncias em execução ponta-a-

ponta durante as atividades de atualização azul/

verde relacionadas ao pod.


VMware, Inc. 91

Tabela 2-7. Requisitos da VM de imagem


Quantidade

Descrição

Imagens

mestres

As

imagens

mestres

são

ativadas

para GPU

ou não,

dependend

o da sua

seleção

quando

você as

cria.

Para imagens mestre habilitadas

por GPU, o sistema usa:

n A NV6 Padrão série NV (das

vCPUs da Família NV Padrão)

n Disco de SO: HDD padrão de

127 GiB

Variado,

com base

em suas

necessida

des.

Uma imagem mestre é uma VM do sistema operacional Microsoft Windows que

está configurada para que o Horizon Cloud pode convertê-la em uma imagem

publicada. Uma VM de sistema operacional Windows compatível com RDSH

fornece a base usada para criar os RDSHs nos farms que fornecem áreas de

trabalho e aplicativos remotos com base em sessão para os seus usuários finais.

Uma VM de sistema operacional Windows Client fornece a base usada para criar

as áreas de trabalho VDI. Cada imagem mestre é uma combinação de sistema

operacional Microsoft Windows e se ela está ativada para GPU ou não. Portanto,

se você desejar que o seu pod forneça:

n Áreas de trabalho RDSH usando o Microsoft Windows 2016 Datacenter,

sem GPU

n Áreas de trabalho RDSH usando o Microsoft Windows 2016 Datacenter,

com GPU

Você precisará de pelo menos 2 VMs de imagem mestre.

O processo de conversão de uma imagem mestre em uma imagem publicada é,

às vezes, chamado de publicação da imagem, ou também chamado de

selamento da imagem. A imagem publicada resultante é às vezes chamada de

imagem selada ou imagem atribuível, pois está em um estado finalizado para

uso em atribuições.

O sistema desliga automaticamente a imagem mestre quando ela é publicada

(quando você executa a ação Converter em Imagem na imagem mestre do

Console Administrativo). Quando você atualiza uma imagem publicada, o

sistema liga a VM novamente.

Observação Ao duplicar uma imagem usando o Console Administrativo, o

sistema liga temporariamente a VM da imagem mestre para obter sua

configuração para a duplicata e, em seguida, a desliga novamente.

Para obter informações sobre como criar uma imagem mestre, consulte o tópico

Criando imagens de área de trabalho para um Pod do Horizon Cloud on

Microsoft Azure no Guia de administração.

Para imagens mestre não

habilitadas para GPU e sistemas

operacionais Microsoft Windows

Client, o sistema usa o seguinte:

n A Standard_D4_v3 (das

vCPUs da família Dv3 padrão)


127 GiB

Se a Microsoft não fornecer a

Família Dv3 Padrão na região do

Microsoft Azure em que você

implantou o pod, o sistema usará a

Standard_D3_v2 em vez da família

Dv2 padrão.

Para imagens mestre não

habilitadas para GPU e sistemas

operacionais compatíveis com

RDSH do Microsoft Windows, o

sistema usa o seguinte:

n A Standard_D2_v3 (das

vCPUs da família Dv3 padrão)


127 GiB

Se a Microsoft não fornecer a Dv3-

series na região do Microsoft Azure

em que você implantou o pod, o

sistema usará a Standard_D2_v2

em vez da família Dv2 padrão.


VMware, Inc. 92


Tabela 2-8. Requisitos da VM de farm


Quantidade

Descrição

Farm

RDSH

A partir desta versão, você pode

personalizar o conjunto de tipos de

VM do Microsoft Azure que deseja

disponibilizar para seleção ao criar

farms no seu pod. Você pode

personalizar sua própria lista do

conjunto de tamanhos de VM do

Microsoft Azure que normalmente

estão disponíveis nas regiões

padrão do Microsoft Azure. Para

obter mais informações sobre

como personalizar o conjunto de

tipos de VM disponíveis para uso

nos farms, consulte o Guia de

administração do Horizon Cloud.

Ao criar ou editar um farm, você

pode personalizar o tamanho do

disco do SO das instâncias de

RDSH do farm para alterá-lo a

partir do valor padrão do sistema.

Para obter detalhes específicos

sobre os tamanhos de VM do

Windows que normalmente estão

nas regiões padrão do Microsoft

Azure, consulte a documentação

da Microsoft em https://

docs.microsoft.com/en-us/azure/

virtual-machines/windows/sizes.

Observação Para ambientes de

produção, garanta que os tipos de

VM que você usa para seus farms

tenham no mínimo duas (2) CPUs.

Atender a esse critério evita

problemas de conexão

inesperados do usuário final. Esse

critério é resultado das

recomendações do Horizon Agent

para se ter no mínimo 2 CPUs para

instalar ou atualizar o Horizon

Agent da versão 7.x ou posteriores.

Esses critérios do Horizon Agent

estão descritos no tópico da

documentação do Horizon 7

Instalar o Horizon Agent em uma

máquina virtual da versão 7.7 em

diante.

Variado,

com base

em suas

necessida

des e em

como

você

personaliz

ou os

tamanhos

de VM no

seu

ambiente

do

Horizon

Cloud.

VMs RDSH do farm são instâncias compatíveis com RDS que fornecem áreas de

trabalho e aplicativos remotos baseados em sessão para os usuários finais. Você

precisa de pelo menos um farm RDSH para fornecer áreas de trabalho de

sessão e um farm RDSH para fornecer aplicativos remotos. Para atender às

necessidades do administrador ou dos usuários finais, você pode decidir

implantar farms adicionais.

O estado de energia dessas VMs varia dependendo das definições de

configuração do farm e da demanda de usuários finais.

Observação Nesta versão, você não poderá oferecer áreas de trabalho

baseadas em sessão e aplicativos remotos do mesmo farm.


VMware, Inc. 93




https://docs.vmware.com/br/VMware-Horizon-7/7.8/horizon-virtual-desktops/GUID-1F2D0C6E-6379-4B52-A7EA-C1EF09CE2F9B.html



Tabela 2-9. Requisitos de VMs de área de trabalho VDI


Quantidade

Descrição

Áreas de

trabalho

VDI

A partir desta versão, você pode

personalizar o conjunto de tipos de

VM do Microsoft Azure que deseja

disponibilizar para seleção ao criar

atribuições de área de trabalho VDI

no seu pod. Você pode

personalizar sua própria lista do


Microsoft Azure que normalmente

estão disponíveis nas regiões

padrão do Microsoft Azure. Para

obter mais informações sobre

como personalizar o conjunto de

tipos de VM disponíveis para uso

nas suas atribuições de área de

trabalho VDI, consulte o Guia de

administração do Horizon Cloud.

Observação Um pequeno


Microsoft Azure que a Microsoft

determinou não é apropriado para

casos de uso de VDI omitidos

automaticamente do uso, como

Standard_B2ls e Standard_B1s.

Ao criar ou editar uma atribuição de

área de trabalho VDI, você pode

personalizar o tamanho do disco

do SO das instâncias de área de

trabalho VDI para alterá-lo do

padrão do sistema.

Variado,

com base

em suas

necessida

des e em

como

você

personaliz

ou os

tamanhos

de VM no

seu

ambiente

do

Horizon

Cloud.

As VMs de área de trabalho VDI são as instâncias que fornecem áreas de

trabalho VDI aos seus usuários finais.

O estado de energia dessas VMs varia dependendo das configurações de

atribuição de área de trabalho VDI e da demanda de usuários finais.


VMware, Inc. 94

Tabela 2-9. Requisitos de VMs de área de trabalho VDI


Quantidade

Descrição

Para obter detalhes específicos

sobre esses tamanhos de VM do

Windows, consulte a

documentação da Microsoft em

https://docs.microsoft.com/en-us/

azure/virtual-machines/windows/

sizes.

Observação Para ambientes de

produção, garanta que os tipos de

VM que você usa para as

atribuições de área de trabalho VDI

tenham no mínimo duas (2) CPUs.

Atender a esse critério evita

problemas de conexão

inesperados do usuário final. Esse

critério é resultado das

recomendações do Horizon Agent

para se ter no mínimo 2 CPUs para

instalar ou atualizar o Horizon

Agent da versão 7.x ou posteriores.

Esses critérios do Horizon Agent

estão descritos no tópico da

documentação do Horizon 7

Instalar o Horizon Agent em uma

máquina virtual da versão 7.7 em

diante.

Limites de serviço do VMware Horizon Cloud Service on Microsoft Azure

Este tópico descreve alguns dos limites comuns do VMware Horizon Cloud Service on Microsoft Azure que também são chamados de máximos suportados. Este tópico descreve atualmente os máximos suportados tanto no número de VMs de área de trabalho e RDSH de farm que você pode implantar em uma única assinatura quanto no número total de sessões simultâneas conectadas que você pode ter por pod. Ao longo do tempo, este tópico será atualizado para listar mais limites conhecidos.

O serviço é testado até certo número de VMs implantadas em uma única assinatura e o número de conexões simultâneas que um pod pode acomodar.

Máximo de 2.000 VMs de área de trabalho e VMs RDSH de farm por assinatura

Esse limite é baseado nos limites de API do Microsoft Azure dados em uma única assinatura. Para funcionar bem dentro desses limites da interface de programação de aplicativos durante as operações normais, o Horizon Cloud suporta um máximo de 2.000 VMs de área de trabalho e VMs RDSH de farm por assinatura.


VMware, Inc. 95







O número de 2.000 por assinatura inclui VMs de área de trabalho VDI e VMs RDSH de farm e aplica-se a todos os pods na assinatura única. Por exemplo, se você tiver um pod na sua assinatura, poderá ter até 2.000 áreas de trabalho VDI nesse pod ou 1.950 áreas de trabalho VDI e mais 50 VMs RDSH de farm. Se você tiver mais de um pod em sua assinatura, o número de áreas de trabalho VDI e VMs RDSH de farm em todos os pods não deverá ser maior que o total de 2.000.

Máximo de 2.000 sessões por pod

O Horizon Cloud suporta até 2.000 sessões simultâneas conectadas por pod. Esse número de 2.000 inclui conexões a áreas de trabalho VDI, áreas de trabalho RDS e aplicativos de RDS servidos pelo pod. Os recursos de manipulação de sessão do pod determinam esse máximo.

Configurar a rede virtual necessária no Microsoft Azure

Seu ambiente do Microsoft Azure deve ter uma rede virtual existente antes de você poder implantar o pod do Horizon Cloud no ambiente. Se você não tiver uma rede virtual (VNet) na região na qual você está implantando, deverá criar a rede virtual. Se você quiser que o gateway externo do pod seja implantado na própria VNet — separado da do pod, deverá criar essa VNet e, em seguida, emparelhar as duas. Se você quiser que o gateway externo do pod use a própria assinatura, separada da do pod, deverá criar uma VNet separada para esse gateway externo nessa assinatura e emparelhar as duas. Como uma VNet única não abrange assinaturas, optar por implantar um gateway externo na própria assinatura também exigirá que o gateway externo use uma VNet separada da VNet do pod e emparelhado com ela.

Cuidado As sub-redes criadas manualmente na sua VNet com antecedência para a implantação do pod devem permanecer vazias. Não coloque recursos nessas sub-redes nem use qualquer um dos endereços IP. Se um endereço IP já estiver em uso nas sub-redes, a implantação do pod poderá falhar.

Ao implantar um pod com o gateway externo usando a VNet do pod

Para essa configuração, você pode criar sub-redes com antecedência na VNet e especificá-las no assistente de implantação de pod, ou digitar diretamente no assistente os espaços de endereço para as sub-redes necessárias, e o implantador do pod criará as sub-redes na VNet.

Importante Se sua VNet existente for emparelhada, o implantador não poderá atualizar automaticamente o espaço de endereço da VNet. Se a VNet for emparelhada, a prática recomendada será criar as sub-redes com antecedência, conforme descrito em Antes da implantação de pod, crie as sub-redes necessárias do pod do Horizon Cloud na VNet no Microsoft Azure. Se você não quiser criar as sub-redes com antecedência e digitar CIDRs de sub-rede no assistente de implementação que não estão no espaço de endereço existente da VNet, o assistente exibirá uma mensagem de erro, e você precisará especificar espaços de endereço de sub-rede válidos para continuar ou usar uma rede virtual não emparelhada.


VMware, Inc. 96

Essa configuração conta com as seguintes sub-redes:

n Sub-rede de gerenciamento para endereços IP usados pelas VMs envolvidas em atividades de gerenciamento do pod em si

n Sub-rede de área de trabalho, para endereços IP usados para as VMs do servidor RDSH e as VMs de área de trabalho VDI nessa sub-rede. Quando a configuração interna do Unified Access Gateway é especificada no assistente de implantação, as VMs do Unified Access Gateway também usam endereços IP dessa sub-rede.

Importante As VMs para suas áreas de trabalho VDI, as imagens compatíveis com RDS e todas as VMs RDSH nos farms do pod consomem esses endereços IP. Como essa sub-rede da área de trabalho não pode ser estendida depois que o pod é implantado, verifique se você definiu esse intervalo como grande o suficiente para acomodar o número de áreas de trabalho que você espera que este pod forneça. Por exemplo, se você esperar que esse pod deva fornecer mais de 1000 áreas de trabalho no futuro, verifique se esse intervalo fornece mais que essa quantidade de endereços IP.

n Sub-rede DMZ, para endereços IP usados pela configuração externa opcional do Unified Access Gateway.

Quando o implantador cria as sub-redes automaticamente, a criação sempre ocorre na VNet correspondente. Em termos de espaço de endereço da VNet, o implantador lida com os espaços de endereço de sub-rede inseridos no assistente da seguinte maneira:

n Se você especificar espaços de endereço no assistente que já não estejam no espaço de endereço da VNet, o implantador atualizará automaticamente a configuração da VNet para adicionar esses espaços de endereço. Em seguida, ele cria novas sub-redes na VNet.

n Se os espaços de endereço especificados no assistente já estiverem contidos no espaço de endereço existente da VNet, o implantador simplesmente criará novas sub-redes na VNet usando os espaços de endereço especificados.

Ao implantar um pod com a opção de gateway externo usando a própria VNet ou assinatura, separe-o da VNet ou assinatura do pod

Para essa configuração, como há duas VNets envolvidas, e essas VNets devem ser emparelhadas, a boa prática é criar as sub-redes com antecedência na VNet e especificá-las no assistente de implantação de pod. Crie as sub-redes com antecedência, conforme descrito em Antes da implantação de pod, crie as sub-redes necessárias do pod do Horizon Cloud na VNet no Microsoft Azure. Mesmo que o assistente de implantação ofereça a opção de digitar diretamente no assistente os


VMware, Inc. 97

espaços de endereço das sub-redes necessárias para que o implantador crie as sub-redes para você, se você especificar espaços de endereço que ainda não estão no espaço de endereço da VNet, o implantador não poderá adicioná-los à VNet porque se trata de uma VNet emparelhada.

Nesse caso, uma VNet terá as sub-redes para o pod, e uma VNet terá as sub-redes para o gateway externo. As duas VNets devem ser emparelhadas. Vamos chamar a VNet do pod de VNet-1 e a VNet do gateway externo de VNet-2. Para cada uma dessas VNets, você pode especificar os espaços de endereço para as sub-redes que o implantador do pod criará automaticamente ou especificar as sub-redes que você criou com antecedência.

Nesse tipo de implantação, a VNet do pod (VNet-1) obtém uma sub-rede de gerenciamento e uma sub-rede da área de trabalho, usadas para as mesmas finalidades descritas para quando o gateway externo está na própria VNet do pod. No entanto, a VNet do pod não obtém uma sub-rede de zona desmilitarizada nessa configuração, pois tal sub-rede seria usada pela configuração externa do Unified Access Gateway, que está na outra VNet (VNet-2) dessa configuração. Nessa configuração de implantação, a VNet do gateway externo obtém as seguintes sub-redes:

n Sub-rede de gerenciamento, para endereços IP usados pelas VMs envolvidas em atividades de gerenciamento do próprio gateway externo (a jumpbox temporária, a VM do conector do gateway e as instâncias do Unified Access Gateway do gateway externo)

n Sub-rede de back-end usada pelas instâncias do Unified Access Gateway do gateway externo

n Sub-rede de zona desmilitarizada usada pelas instâncias do Unified Access Gateway do gateway externo

Você executa estas etapas usando o portal do Microsoft Azure apropriado para sua conta registrada. Por exemplo, há endpoints de portal específicos para essas nuvens do Microsoft Azure.

n Microsoft Azure (global padrão)

n Microsoft Azure na Alemanha

n Microsoft Azure na China

n Microsoft Azure Governo dos EUA

Faça logon no portal do usando a URL apropriada para sua conta.


VMware, Inc. 98

Procedimentos

1 Na barra de navegação à esquerda do portal do Microsoft Azure, clique no (Redes virtuais) e clique em Adicionar.

O assistente Criar rede virtual aparece, exibindo a etapa Noções básicas.

2 Siga as etapas na tela do assistente para especificar as seguintes informações.

Opção Descrição

Assinatura Selecione a mesma assinatura que você planeja usar quando você implantar o pod.

Grupo de Recursos Você pode escolher um grupo de recursos existente ou criar um novo quando a rede virtual é criada.

Nome Especifique um nome para a VNet.

Região Selecione a mesma região do Microsoft Azure na qual você planeja implantar o pod.

Espaço de endereço Especifique o espaço de endereço da VNet.

Intervalo de Sub-Redes e Endereços O Microsoft Azure requer a criação de uma sub-rede ao criar uma VNet. Você pode manter os valores padrão ou personalizar o nome e o intervalo. Se quiser usar essa sub-rede para uma das sub-redes necessárias do pod, especifique o intervalo de endereços apropriado de acordo com os requisitos do implantador do pod. Por exemplo, se quiser usar essa sub-rede para a sub-rede de tenant do pod, verifique se ela tem um intervalo de endereços IP que corresponda ao mínimo de /27 exigido pelo assistente de implantação. Consulte Antes da implantação de pod, crie as sub-redes necessárias do pod do Horizon Cloud na VNet no Microsoft Azure.

Importante Se você usar essa sub-rede para uma das sub-redes necessárias do pod, não poderá usá-la também para outros recursos.

Mantenha os valores padrão para todas as configurações opcionais.

3 Vá para a etapa de revisão e clique em Criar.

Resultados

A rede virtual (VNet) é criada na sua conta do Microsoft Azure.

Próximo passo

Se você estiver criando manualmente as sub-redes necessárias em vez de fazer com que elas sejam criadas pelo processo de implantação do pod, configure a VNet recém-criada com as sub-redes que você usará para o pod. 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 e Ao usar sub-redes existentes para um pod do Horizon Cloud no Microsoft Azure.

Configure a VNet recém-criada com um serviço DNS em funcionamento e a conectividade ao serviço do Active Directory que você usará com o pod. Consulte as etapas em Defina as configurações do servidor DNS necessárias pela topologia de VNet que você usará para os pods do Horizon Cloud no Microsoft Azure.


VMware, Inc. 99

Certifique-se de que a sua configuração de VNet, em termos de firewalls e outros comportamentos de rede, atenda aos requisitos de DNS, portas e protocolos para implantação de pods descritos 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.

Importante A VM jumpbox temporária do pod e a VM do gerenciador de pods exigem acesso de saída à Internet na sua VNet do Microsoft Azure. Se você estiver implantando um gateway externo na própria VNet, essa VNet deverá oferecer suporte à VM do conector do gateway e jumpbox temporária do gateway externo com acesso de saída à Internet. Se você tiver exigido acesso de saída à Internet com base em proxy, deverá especificar as informações do servidor proxy enquanto preenche os campos no assistente de implantação de pod.

Antes da implantação de pod, crie as sub-redes necessárias do pod do Horizon Cloud na VNet no Microsoft Azure

Se você estiver usando uma VNet emparelhada, uma boa prática é criar as sub-redes necessárias antes de implantar o pod, para garantir que você tenha considerado os espaços de endereço de que suas sub-redes precisam na VNet antes de executar o assistente de implantação. Mesmo quando sua VNet não está emparelhada, em vez de fazer com que o processo de implantação do pod crie as sub-redes necessárias, você pode criá-las com antecedência na sua VNet.

Importante A partir da versão de manifesto de pod da de setembro de 2019, tanto para pods recém-implantados nessa versão de manifesto ou posterior quanto para pods atualizados para essa versão ou versões posteriores, a sub-rede de gerenciamento do pod também deve oferecer suporte à comunicação de rede com o recurso do servidor do Banco de Dados do Microsoft Azure para PostgreSQL. Antes de implantar um novo pod ou atualizar um pod existente, a sub-rede de gerenciamento de pod que você cria deve ter o serviço Microsoft.Sql listado como um endpoint de serviço. O processo de implantação ou atualização verificará se a sub-rede tem o endpoint e não continuará se o endpoint não estiver ativado na sub-rede. Para obter detalhes, consulte Ao usar sub-redes existentes para um pod do Horizon Cloud no Microsoft Azure.

Ao criar as sub-redes com antecedência, você deve garantir que os seus intervalos de endereços, na notação CIDR (roteamento entre domínios sem classes), estejam de acordo com os requisitos mínimos do assistente de implantação de pod:

n Para a sub-rede de gerenciamento, é necessário um CIDR de /27 ou mais. Essa sub-rede é para endereços IP usados pelas VMs envolvidas em atividades de gerenciamento do pod propriamente dito.

n Para a sub-rede de tenant da área de trabalho, é necessário um CIDR de pelo menos /27. Para ambientes de produção, um CIDR de /24 a /21 é recomendado (256 endereços para 2048 endereços). Essa sub-rede é para endereços IP usados para as VMs do servidor RDSH e as VMs de área de trabalho VDI nessa sub-rede. A VM de gerenciador do pod usa um endereço IP dessa sub-


VMware, Inc. 100

rede. Se o pod terá uma configuração interna do Unified Access Gateway, as VMs do Unified Access Gateway também usarão endereços IP a partir dessa sub-rede. Se o pod terá uma configuração de gateway externo implantada usando a VNet do pod, as VMs do Unified Access Gateway do gateway externo também usarão endereços IP dessa sub-rede.

Importante As VMs para suas áreas de trabalho VDI, as imagens compatíveis com RDS e todas as VMs RDSH nos farms do pod consomem esses endereços IP. Como essa sub-rede da área de trabalho não pode ser estendida depois que o pod é implantado, verifique se você definiu esse intervalo como grande o suficiente para acomodar o número de áreas de trabalho que você espera que este pod forneça. Por exemplo, se você esperar que esse pod deva fornecer mais de 1000 áreas de trabalho no futuro, verifique se esse intervalo fornece mais que essa quantidade de endereços IP.

n Se você pretende ter uma configuração externa do Unified Access Gateway implantada na VNet do pod, precisará de uma sub-rede DMZ, com um CIDR de /28 ou mais. Essa sub-rede é para endereços IP usados pelas NICs das VMs do Unified Access Gateway para se comunicar com o balanceador de carga da configuração desse gateway externo. 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.

n Se você pretende ter a configuração externa do Unified Access Gateway implantada na própria VNet, separada da do pod, essa VNet precisará de três sub-redes:

n É necessária uma sub-rede de gerenciamento com um CIDR de /27 ou mais. Essa sub-rede é para endereços IP usados pelas VMs envolvidas em atividades de gerenciamento do gateway externo geral, como a VM do conector do gateway.

n É necessária uma sub-rede de back-end com um CIDR de /27 ou mais. Essa sub-rede destina-se a endereços IP usados pelas NICs das VMs do Unified Access Gateway para se comunicar pela VNet emparelhada com a VNet do pod.

n Uma sub-rede de front-end (zona desmilitarizada), de um CIDR de /28 ou mais. Essa sub-rede é para endereços IP usados pelas NICs das VMs do Unified Access Gateway para se comunicar com o balanceador de carga do gateway externo. Se você quiser manter os intervalos de sub-rede de gerenciamento e de front-end posicionados nessa VNet, 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 de front-end correspondente seria 192.168.8.32/27.

Importante Para cada CIDR, certifique-se de que cada combinação de prefixo e máscara de bits resulte em um intervalo de endereços IP que tenha o prefixo especificado 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.


VMware, Inc. 101

Pré-requisitos

Verifique se a sua região da Microsoft tem a VNet que você pretende usar para o seu pod. Consulte Configurar a rede virtual necessária no Microsoft Azure.

Certifique-se de que os intervalos de endereços que você planeja usar para as sub-redes não estejam sobrepostos. O assistente de implantação de pod exibirá um erro se os intervalos de sub-redes estiverem sobrepostos.

Procedimentos

1 No portal do Microsoft Azure, navegue até a VNet para a qual você precisa criar as sub-redes descritas.

2 Clique em Sub-redes.

3 Clique em + Sub-rede.

A tela Adicionar sub-rede é exibida.

4 Forneça as informações para os campos obrigatórios.

Opção Descrição

Nome Especifique um nome para a sub-rede.

Intervalo de endereços (bloco CIDR) Digite um CIDR para a sub-rede.

5 Se essa sub-rede for a sub-rede de gerenciamento, na seção Endpoints de serviço, selecione o serviço Microsoft.Sql.

6 Clique em OK.

A sub-rede é adicionada à VNet.

7 Repita as etapas de 3 a 5 para adicionar as sub-redes necessárias restantes.

8 Se você pretende implantar o gateway externo na própria VNet, repita as etapas para as sub-redes dessa VNet.

Resultados


Próximo passo

Para todas as sub-redes de gerenciamento criadas, não deixe de habilitar o serviço Microsoft.Sql como um endpoint de serviço. Consulte Ao usar sub-redes existentes para um pod do Horizon Cloud no Microsoft Azure. Esse serviço deve ser habilitado na sub-rede de gerenciamento do pod e, se você estiver implantando o gateway externo a própria VNet, o serviço deverá ser habilitado também na sub-rede de gerenciamento desse gateway.


VMware, Inc. 102

Ao usar sub-redes existentes para um pod do Horizon Cloud no Microsoft AzureA partir da release de setembro de 2019, tanto para pods recém-implantados usando a versão de manifesto dessa release ou posteriores quanto pods atualizados para a versão ou versões posteriores de manifesto dessa release, a sub-rede de gerenciamento de um pod também deve ser compatível com a comunicação de rede com o endpoint de serviço do Microsoft Azure Database for PostgreSQL. Antes de implantar um novo pod ou atualizar um pod existente, a sub-rede de gerenciamento de pod que você cria deve ter o serviço Microsoft.Sql ativado como um endpoint de serviço. O processo de implantação ou atualização verificará se a sub-rede tem o endpoint e não continuará se o endpoint não estiver ativado na sub-rede de gerenciamento. Além de habilitar esse endpoint de serviço, se você tiver regras de grupo de segurança de rede (NSG) ou de firewall na sua sub-rede de gerenciamento, deverá configurá-lo para permitir o tráfego para o serviço do Banco de Dados do Azure para PostgreSQL antes de implantar um novo pod ou atualizar um pod existente.

Importante A versão de dezembro de 2019 introduziu o recurso de implantar a configuração externa do Unified Access Gateway do pod na própria VNet, separada da VNet do pod. Ao usar esse recurso, a sub-rede de gerenciamento na VNet do gateway externo também deve aderir a esse requisito para ter o serviço Microsoft.Sql habilitado como um endpoint de serviço nessa sub-rede.

A versão de setembro de 2019 introduziu o uso do serviço do Banco de Dados do Microsoft Azure para PostgreSQL como elemento necessário de um pod do Horizon Cloud no Microsoft Azure. Conforme descrito na documentação da Microsoft, o Banco de Dados do Microsoft Azure para PostgreSQL é uma oferta do banco de dados como serviço totalmente gerenciado. Em uma implantação ou atualização de pod, um recurso de servidor do Banco de Dados do Microsoft Azure para PostgreSQL é implantado no grupo de recursos do pod, usando o tipo de implantação de servidor único. Os processos de implantação e atualização também adicionam automaticamente uma regra de VNet à VNet do pod. Essa regra de VNet restringe o tráfego do servidor do Banco de Dados do Microsoft Azure para PostgreSQL para a sub-rede de gerenciamento do pod. A comunicação entre o pod e esse servidor do Banco de Dados do Microsoft Azure para PostgreSQL usam a sub-rede de gerenciamento, que coloca alguns requisitos na sub-rede de gerenciamento do pod.

Na sub-rede de gerenciamento, habilite o serviço Microsoft.Sql como um endpoint de serviço

A regra de VNet para restringir o tráfego do servidor implantado do Banco de Dados do Microsoft Azure para PostgreSQL para a sub-rede de gerenciamento requer que a sub-rede tenha o endpoint de serviço Microsoft.Sql habilitado. No cenário em que você faz o implantador do pod criar as sub-redes, o implantador garante que a sub-rede de gerenciamento do pod tenha o endpoint de serviço Microsoft.Sql ativado na sub-rede de gerenciamento que ele cria. No entanto, quando você mesmo cria a sub-rede de gerenciamento, deve garantir que ela atenda a esses requisitos antes de implantar um novo pod ou atualizar um pod existente. A seguinte captura de tela é um exemplo para ilustrar onde você ativa o serviço Microsoft.Sql como um endpoint de serviço em uma sub-rede usando o portal do Microsoft Azure. Após clicar na sub-rede no portal, na seção Endpoints de serviço, use a lista suspensa Serviços para selecionar Microsoft.Sql e depois salve.


VMware, Inc. 103



Você pode usar o portal do Microsoft Azure para navegar até a sub-rede de gerenciamento e selecionar Microsoft.Sql na lista suspensa Serviços.

Certifique-se de que seus firewalls ou NSGs permitam a comunicação do pod com o serviço do Banco de Dados do Azure para PostgreSQL

Conforme listado em Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure, na sub-rede de gerenciamento, você deve configurar suas regras de rede para a sub-rede de gerenciamento para permitir a comunicação do pod com o serviço do Banco de Dados do Azure para PostgreSQL. Você deve garantir que suas sub-redes de gerenciamento atendam a esse requisito antes de implantar um novo pod ou atualizar um pod existente.

Se os seus firewalls ou NSGs forem compatíveis com o uso de tags de serviço para especificar o acesso, permita a comunicação do pod com um dos seguintes:

n Etiqueta de serviço global do SQL do Azure: Sql

n Etiqueta de serviço SQL específica à região para a região do Azure onde o pod é implantado: Sql.região, por exemplo, Sql.WestUS.


VMware, Inc. 104

Se os seus firewalls ou NSGs não oferecerem suporte ao uso de tags de serviço para especificar o acesso, você poderá usar o nome do host do recurso do servidor do banco de dados que é criado no grupo de recursos do pod. O nome do recurso do servidor segue o padrão *.postgres.database.azure.com.

Para obter informações sobre as tags de serviço em grupos de segurança, consulte o tópico de documentação do Microsoft Azure em Tags de Serviço.

Defina as configurações do servidor DNS necessárias pela topologia de VNet que você usará para os pods do Horizon Cloud no Microsoft Azure

As VNets nas quais os pods do Horizon Cloud são implantados devem ter a capacidade de resolver nomes externos e nomes de máquinas internos. Durante o processo de implantação do pod, o implantador baixa com segurança o software do pod para o seu ambiente do Microsoft Azure a partir de endereços externos na camada de controle do Horizon Cloud. A capacidade de resolver os nomes de máquina virtual (VM) internos é necessária para operações de ingresso no domínio do Active Directory no Horizon Cloud do pod com as VMs que são implantadas em seu ambiente do Microsoft Azure.

Importante Por fim, o principal requisito é que as VMs relacionadas ao pod que precisam acessar nomes DNS específicos possam fazer isso. Se você tiver sua topologia de VNet configurada para que os nomes de máquinas internos e os nomes externos possam ser resolvidos pelas VMs relacionadas ao pod que precisam fazer isso. É preciso garantir que qualquer topologia de VNet que você esteja usando no Microsoft Azure na qual deseja implantar o pod permita que as VMs de pod implantadas nas sub-redes necessárias relevantes possa obter essa resolução de nome DNS. Para ver especificações sobre os requisitos de resolução DNS, consulte Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure.

Se você pretende usar o recurso para que o gateway externo seja implantado na própria VNet separada da do pod, essas VNets devem estar emparelhadas, e você e sua equipe de rede devem garantir que a topologia de VNets emparelhadas forneça as configurações de DNS dessa topologia para atender aos principais requisitos de DNS do pod, conforme descrito no parágrafo anterior. O conjunto de documentações do Horizon Cloud não abrange detalhes de topologias de VNet avançadas que sua equipe de rede pode ter personalizado para uso.

Em uma assinatura do Microsoft Azure, a conectividade da rede interna não está configurada por padrão. Em ambientes de produção, você ou sua equipe de rede normalmente definiria as configurações de DNS da rede virtual para apontar para um servidor DNS válido que possa resolver nomes externos, bem como funcionar no Microsoft Azure para suas máquinas corporativas. Por exemplo, você pode desejar implantar uma máquina virtual do Microsoft Windows Server 2016 nessa rede virtual para agir como o servidor DNS e definir a configuração de DNS da rede virtual para apontar para o endereço IP do servidor DNS implantado.


VMware, Inc. 105

https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#service-tags

Para ambientes de prova de conceito, se as políticas de segurança e privacidade da sua organização permitirem, você poderá configurar um DNS interno para delegar para um DNS público externo a resolução de nomes externos. Algumas organizações e ISPs fornecem servidores de nome públicos e recursivos para serem usados para esses fins, como OpenDNS em 208.67.222.222 ou Google Public DNS em 8.8.8.8. Para obter uma lista de amostra de servidores de nome públicos e recursivos, consulte o artigo na Wikipédia Servidor de nome recursivo público.

Pré-requisitos

Certifique-se de que sua região do Microsoft Azure tenha a topologia de VNet que você planeja especificar no assistente do implantador do pod. Consulte Configurar a rede virtual necessária no Microsoft Azure.

Certifique-se de que as configurações do servidor DNS que você ou sua equipe de rede vão configurar para essa topologia de VNet possam alcançar e resolver os nomes externos específicos necessários para uma implantação de pod bem-sucedida. Para obter detalhes, consulte Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure.

Procedimentos

1 Na barra de navegação à esquerda do portal do Microsoft Azure, clique no (Redes virtuais) e clique na rede virtual que você pretende usar para o pod.

2 Exiba as configurações do servidor DNS da rede virtual clicando em Servidores DNS.

3 Usando a opção Personalizado, adicione o endereço do servidor DNS que você deseja utilizar para a resolução de nomes e clique em Salvar.

Próximo passo

Certifique-se de que os requisitos de acesso do implantador do pod para DNS, portas e protocolos sejam cumpridos na topologia de VNet. Consulte 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.


VMware, Inc. 106

https://en.wikipedia.org/wiki/Public_recursive_name_server

Configurações de domínio do Active Directory

Um ambiente do Horizon Cloud requer o registro de pelo menos um domínio do Active Directory (AD) com o pod do Horizon Cloud. Este tópico descreve as configurações permitidas para utilização com seus pods do Horizon Cloud no Microsoft Azure.

As configurações permitidas são:

n O servidor AD local e conectar este AD local com seu ambiente do Microsoft Azure usando o VPN/MPLS ou o Microsoft Azure Express Route.

n Servidor do AD em execução no seu ambiente do Microsoft Azure.

n Usando o Microsoft Azure Active Directory Domain Services. Para obter uma visão geral destes serviços que o Microsoft Azure oferece, consulte este artigo do Azure AD Domain Services na documentação da Microsoft.

Para obter uma descrição técnica detalhada de cada configuração com suporte, algumas opções para cada e as vantagens e desvantagens de cada uma delas, consulte o white paper da VMware Networking and Active Directory Considerations on Microsoft Azure with VMware Horizon Cloud.

Importante Seu ambiente do Horizon Cloud pode ser formado pelos pods do Microsoft Azure e do Horizon 7 no local e no VMware Cloud on AWS. Como resultado, todos esses pods conectados à nuvem devem ter linha de visão para o mesmo conjunto de domínios do Active Directory. Se o ambiente já tiver pods do Horizon 7 conectados à nuvem e você estiver implantando o primeiro pod no Microsoft Azure, será necessário garantir que o pod será capaz de ter linha de visão para os domínios do Active Directory que já estão registrados no seu ambiente do Horizon Cloud. Veja os tópicos relacionados ao Active Directory no Guia de administração do Horizon Cloud para obter mais detalhes.

Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure

Para o processo de implantação do pod implantar o pod com êxito no Microsoft Azure, você deve configurar seus firewalls para permitir que o Horizon Cloud acesse os endereços do Serviço de Nome de Domínio (DNS), que ele precisa. Além disso, o DNS deve resolver nomes específicos, conforme descrito neste tópico. Além da implantação principal do pod, quando você estiver implantando o gateway externo


VMware, Inc. 107

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/



na própria VNet, a sub-rede da VNet deverá atender aos mesmos requisitos de DNS que a sub-rede de gerenciamento da VNet de pod separada, conforme descrito neste tópico.

Importante O processo de implantação de pod usa uma VM jumpbox. Essa VM jumpbox tem requisitos de protocolo e porta para o processo de implantação de pod, bem como para definir as configurações das VMs do Unified Access Gateway do pod ao implantar uma configuração do Unified Access Gateway para o pod. Consulte Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods.

Implantar o gateway externo na própria VNet também usa a própria VM jumpbox, separada da do pod. Essa VM jumpbox tem os próprios requisitos de protocolo e portas para o processo de implantação de gateway. Consulte Quando o gateway externo é implantado na própria VNet: portas e protocolos exigidos pela jumpbox da configuração do gateway externo durante implantações e atualizações de gateway.

Depois que o pod for implantado com êxito, portas e protocolos específicos serão necessários para operações contínuas do Horizon Cloud. As portas e os protocolos específicos necessários dependem do fato de o pod estar na versão de manifesto para a versão de setembro de 2019 ou em uma versão anterior do manifesto.n Para um pod criado após a versão de setembro de 2019 ou atualizado para a versão de manifesto

dessa versão ou posterior, consulte Requisitos de portas e protocolos para um pod do Horizon Cloud no manifesto da versão de setembro de 2019 ou posteriores. Esses pods têm versões de manifesto de 1593 ou posteriores.

n Para um pod criado antes da versão de setembro de 2019 e ainda não atualizado para a versão de manifesto dessa versão, consulte Requisitos de portas e protocolos para um pod do Horizon Cloud implantado antes da versão de setembro de 2019. Esses pods têm versões de manifesto de 1493.1 ou anteriores.

n Requisitos do DNS para o processo de implantação de pod principal, atualizações de pod e operações em andamento

n Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods

n Quando o gateway externo é implantado na própria VNet: portas e protocolos exigidos pela jumpbox da configuração do gateway externo durante implantações e atualizações de gateway


VMware, Inc. 108

Requisitos do DNS para o processo de implantação de pod principal, atualizações de pod e operações em andamento

Você deve garantir que os seguintes nomes DNS sejam resolvidos e acessíveis pela sub-redes do tenant e de gerenciamento usando as portas e os protocolos específicos, conforme indicado na tabela a seguir. O Horizon Cloud usa as portas de saída específicas para baixar com segurança o software do pod para o seu ambiente do Microsoft Azure e para que o pod possa se conectar de volta à camada de controle do Horizon Cloud. Você deve configurar seu firewall de rede, de tal forma que o Horizon Cloud tenha a capacidade de entrar em contato com os endereços DNS nas portas que ele exige. Caso contrário, o processo de implantação do pod falhará.

Importante Quando você estiver usando o recurso para implantar o gateway externo na própria VNet, a sub-rede de gerenciamento nessa VNet deverá atender aos mesmos requisitos de DNS conforme indicado na tabela abaixo para a sub-rede de gerenciamento na VNet do pod. A sub-rede de back-end da VNet e a sub-rede de zona desmilitarizada do gateway externo não têm requisitos de DNS específicos.

O email Bem-vindo(a) ao Horizon Service indicará a instância da camada de controle regional na qual sua conta de tenant foi criada. Devido a um problema conhecido, o e-mail de boas-vindas pode exibir os nomes das cadeias de caracteres do sistema usados para as regiões em vez de nomes amigáveis. Se você vir um nome de cadeia de caracteres do sistema no seu email de boas-vindas, poderá usar a tabela a seguir para relacionar o que é mostrado no seu email com os nomes DNS da camada de controle regional.

Tabela 2-10. Regiões no seu e-mail de boas-vindas mapeadas para nomes DNS da camada de controle regional

Seu email de boas-vindas diz Nome DNS regional

USA cloud.horizon.vmware.com

EU_CENTRAL_1 cloud-eu-central-1.horizon.vmware.com

AP_SOUTHEAST_2 cloud-ap-southeast-2.horizon.vmware.com

PROD1_NORTHCENTRALUS2_CP1 cloud-us-2.horizon.vmware.com

PROD1_NORTHEUROPE_CP1 cloud-eu-2.horizon.vmware.com

PROD1_AUSTRALIAEAST_CP1 cloud-ap-2.horizon.vmware.com


VMware, Inc. 109

Tabela 2-11. Requisitos de DNS de operações e de implantação do pod

Origem da sub-rede Destino (nome DNS) Porta Protocolo Finalidade

Gerenciamento Um dos seguintes nomes, dependendo de qual instância regional da camada de controle do Horizon Cloud está especificada na sua conta de tenant do Horizon Cloud. A instância regional é definida quando a conta é criada, conforme descrito em Como fazer a integração ao Horizon Cloud for Microsoft Azure, ao Horizon 7 No Local e ao Horizon 7 on VMware Cloud on AWS.

n cloud.horizon.vmware.com

n cloud-us-2.horizon.vmware.com

n cloud-eu-central-1.horizon.vmware.com

n cloud-eu-2.horizon.vmware.com

n cloud-ap-southeast-2.horizon.vmware.com

n cloud-ap-2.horizon.vmware.com

443 TCP Instância da camada de controle regional do Horizon Cloud

n Estados Unidos: cloud.horizon.vmware.com, cloud-us-2.horizon.vmware.com

n Europa: cloud-eu-central-1.horizon.vmware.com, cloud-eu-2.horizon.vmware.com

n Ásia-Pacífico: cloud-ap-southeast-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com

Gerenciamento softwareupdate.vmware.com 443 TCP Servidor de pacote de software da VMware. Usado para baixar atualizações do software relacionadas ao agente usado em operações relacionadas à imagem do sistema.


VMware, Inc. 110





Tabela 2-11. Requisitos de DNS de operações e de implantação do pod (continuação)


Gerenciamento Um dos seguintes nomes, dependendo de qual dos nomes DNS regionais se aplica à sua conta.

n d1mes20qfad06k.cloudfront.net

n hydra-softwarelib-cdn.azureedge.net

443 TCP Servidor de distribuição de conteúdo do Horizon Cloud. Na sub-rede gerenciamento, este site é usado para baixar os VHDs (discos virtuais) para as VMs do gerenciador de pod e do Unified Access Gateway. Também usado para o VHD da VM do conector de gateway, no caso em que o gateway externo está na própria VNet.)

d1mes20qfad06k.cloudfront.net corresponde a instâncias regionais para cloud.horizon.vmware.com, cloud-eu-central-1.horizon.vmware.com, cloud-ap-southeast-2.horizon.vmware.com.

hydra-softwarelib-cdn.azureedge.net corresponde a instâncias regionais para cloud-us-2.horizon.vmware.com, cloud-eu-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com

Gerenciamento packages.microsoft.com 443 e 11371

TCP Servidor de pacote de software da Microsoft. Usado para baixar com segurança o software Interface de Linha de Comando (CLI) do Microsoft Azure.


VMware, Inc. 111



Gerenciamento azure.archive.ubuntu.com 80 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas em Linux relacionadas ao pod para atualizações do sistema operacional Ubuntu.

Gerenciamento api.snapcraft.io 443 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas no Linux do pod para atualizações do sistema operacional Ubuntu.

Gerenciamento archive.ubuntu.com 80 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas no Linux do pod para atualizações do sistema operacional Ubuntu.

Gerenciamento changelogs.ubuntu.com 80 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas no Linux do pod para rastreamento das atualizações do sistema operacional Ubuntu.

Gerenciamento security.ubuntu.com 80 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas no Linux do pod para rastreamento das atualizações do sistema operacional Ubuntu relacionadas à segurança.


VMware, Inc. 112



Gerenciamento Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você está implantando seu pod:

n Microsoft Azure (global): login.microsoftonline.com

n Microsoft Azure Alemanha: login.microsoftonline.de

n Microsoft Azure China: login.chinacloudapi.cn

n Governo dos EUA do Microsoft Azure: login.microsoftonline.us

443 TCP Esse endereço da Web é geralmente usado pelos aplicativos para autenticação em serviços do Microsoft Azure. Para obter algumas descrições na documentação do Microsoft Azure, consulte Fluxo do código de autorização OAuth 2.0 , Azure Active Directory v2.0 e o protocolo OpenID Connect e Nuvens nacionais . O tópico Nuvens nacionais descreve como existem diferentes endpoints de autenticação do Azure AD para cada nuvem nacional do Microsoft Azure.


n Microsoft Azure (global): management.azure.com

n Microsoft Azure Alemanha: management.microsoftazure.de

n Microsoft Azure China: management.chinacloudapi.cn

n Microsoft Azure Governo dos EUA: management.usgovcloudapi.net

443 TCP Usado para solicitações de API de pod aos endpoints do Gerenciador de Recurso do Microsoft Azure para usar os serviços do Gerenciador de Recurso do Microsoft Azure. O Microsoft Azure Resource Manager fornece uma camada de gerenciamento consistente para realizar tarefas por meio do Azure PowerShell, da CLI do Azure, do portal do Azure, da REST API e dos SDKs de cliente.


VMware, Inc. 113

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow




https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc




https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-national-cloud






n Microsoft Azure (global): graph.windows.net

n Microsoft Azure Alemanha: graph.cloudapi.de

n Microsoft Azure China: graph.chinacloudapi.cn

n Microsoft Azure Governo dos EUA: graph.windows.net

443 TCP Acesso à API do Graph do Azure Active Directory (Azure AD), que é usada para acesso programático do pod ao Azure Active Directory (Azure AD) por meio de endpoints da REST API OData.

Gerenciamento Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você implantou seu pod:

n Microsoft Azure (global): *.blob.core.windows.net

n Microsoft Azure Alemanha: *.blob.core.cloudapi.de

n Microsoft Azure China: *.blob.core.chinacloudapi.cn

n Microsoft Azure Governo dos EUA: *.blob.core.usgovcloudapi.net

443 TCP Usado para acesso programático do pod ao Armazenamento de Blobs do Azure. O Armazenamento de Blobs do Azure é um serviço para armazenar grandes quantidades de dados de objetos não estruturados, como texto ou dados binários.

Gerenciamento Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você implantou seu pod:

n Microsoft Azure (global): *.vault.azure.net

n Microsoft Azure Alemanha: *.vault.microsoftazure.de

n Microsoft Azure China: *.vault.azure.cn

n Microsoft Azure Governo dos EUA: *.vault.usgovcloudapi.net

443 TCP Usado para a capacidade do pod de trabalhar programaticamente com o serviço de nuvem Cofre de Chaves do Azure. O Cofre de Chaves do Azure é um serviço de nuvem que fornece um armazenamento seguro para segredos.


VMware, Inc. 114



Gerenciamento Se o seu firewall ou grupo de segurança de rede (NSG) oferecer suporte ao uso de tags de serviço, será uma das seguintes:

n Etiqueta de serviço global do SQL do Azure: Sql

n Etiqueta de serviço SQL específica à região para a região do Azure onde o pod é implantado: Sql.região, por exemplo, Sql.WestUS.

Se o seu firewall ou grupo de segurança de rede (NSG) não oferecer suporte ao uso de tags de serviço, você poderá usar o nome do host da base de dados. Esse nome segue o padrão *.postgres.database.azure.com.

5432 TCP Usado para comunicação do pod com o servidor do Banco de Dados do Microsoft Azure para PostgreSQL. A partir da versão de setembro de 2019, os pods recém-implantados após essa data de lançamento e os pods atualizados para a versão de manifesto dessa versão são configurados com um servidor do Banco de Dados do Microsoft Azure para PostgreSQL.

Para obter informações sobre as tags de serviço em grupos de segurança, consulte o tópico de documentação do Microsoft Azure em Tags de Serviço.


VMware, Inc. 115

https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#service-tags



Locatário Um dos seguintes nomes, dependendo de qual dos nomes DNS regionais se aplica à sua conta.

n d1mes20qfad06k.cloudfront.net

n hydra-softwarelib-cdn.azureedge.net

443 TCP Servidor de distribuição de conteúdo do Horizon Cloud. Na sub-rede do locatário, este site é usado pelo processo de Importação de Imagem automatizado do sistema para baixar o instalador para o software relacionado ao agente.

d1mes20qfad06k.cloudfront.net corresponde a instâncias regionais para cloud.horizon.vmware.com, cloud-eu-central-1.horizon.vmware.com, cloud-ap-southeast-2.horizon.vmware.com.

hydra-softwarelib-cdn.azureedge.net corresponde a instâncias regionais para cloud-us-2.horizon.vmware.com, cloud-eu-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com

Locatário Dependendo da camada de controle do Horizon Cloud regional especificada na sua conta do Horizon Cloud:

América do Norte:

n kinesis.us-east-1.amazonaws.com

n query-prod-us-east-1.cms.vmware.com

Europa:

n kinesis.eu-central-1.amazonaws.com

n query-prod-eu-central-1.cms.vmware.com

Austrália:

n kinesis.ap-southeast-2.amazonaws.com

n query-prod-ap-southeast-2.cms.vmware.com

443 TCP Serviço de Monitoramento da Nuvem (CMS)


VMware, Inc. 116

Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods

Conforme descrito em Requisitos de máquina virtual do Microsoft Azure para um pod do Horizon Cloud no Microsoft Azure, a VM jumpbox é usada na criação inicial de um pod e durante atualizações de software subsequentes no ambiente do pod. Depois que um pod é criado, a VM jumpbox é excluída. Em seguida, quando um pod estiver sendo atualizado, a VM jumpbox é recriada para executar esse processo de atualização e é excluída quando a atualização é concluída. Essas atualizações incluem quando um pod é editado para adicionar uma configuração do Unified Access Gateway.

Observação Um pod já implantado no Microsoft Azure na versão de setembro de 2019 ou que é atualizado para ela e tem alta disponibilidade habilitada terá duas VMs de gerenciador. Os parágrafos a seguir usam a palavra VMs no plural para indicar que a VM jumpbox deve se comunicar com todas as VMs de gerenciador do pod, tenha o pod apenas uma ou duas.

Durante esses processos, essa VM jumpbox se comunica com:

n As VMs de gerenciador do pod usando SSH para a porta 22 das VMs de gerenciador. Como resultado, durante o processo de implantação do pod e o processo de atualização do pod, o requisito de comunicação entre a VM jumpbox e a porta 22 das VMs do gerenciador deve ser atendido. A porta 22 das VMs do gerenciador de pods deve ser permitida entre a VM jumpbox como uma origem e as VMs do gerenciador de pods como um destino.

n As VMs do Unified Access Gateway usando HTTPS para a porta 9443 dessas VMs, no caso em que um pod é implantado com uma configuração do Unified Access Gateway ou editado para adicionar uma. Como resultado, durante o processo de implantação do pod e o processo de atualização do pod, quando a configuração do pod inclui Unified Access Gateway, o requisito de comunicação entre a VM jumpbox e a porta 9443 das VMs do Unified Access Gateway deve ser atendido. A porta 9443 das VMs do Unified Access Gateway deve ser permitida entre a VM jumpbox como uma origem e as VMs do Unified Access Gateway como um destino.

Como são atribuídos endereços IP dinamicamente a essas VMs, as regras de rede para permitir essa comunicação devem usar:

n O CIDR de sub-rede de gerenciamento como a origem e o destino, com a porta de destino 22, a porta de origem qualquer uma e o TCP de protocolo.

n O CIDR de sub-rede de gerenciamento como a origem e o destino, com a porta de destino 9443, a porta de origem qualquer uma e o TCP de protocolo, quando uma configuração do Unified Access Gateway está envolvida.

Observação As operações do pod em andamento não exigem disponibilidade da porta 22 nas VMs de gerenciador do pod. No entanto, se você fizer uma solicitação de suporte à VMware e à equipe de suporte determinar que a maneira de depurar essa solicitação é implantar uma VM jumpbox para comunicação SSH com as VMs do gerenciador do seu pod, será necessário atender a esse requisito de porta durante o tempo em que a equipe de suporte da VMware precisar da porta para depurar seu problema. A equipe de suporte da VMware informará sobre quaisquer requisitos, conforme apropriado para qualquer situação de suporte.


VMware, Inc. 117

Quando o gateway externo é implantado na própria VNet: portas e protocolos exigidos pela jumpbox da configuração do gateway externo durante implantações e atualizações de gateway

Conforme descrito em Requisitos de máquina virtual do Microsoft Azure para um pod do Horizon Cloud no Microsoft Azure, uma VM jumpbox é usada na criação inicial do gateway externo na própria VNet e durante atualizações de software subsequentes nesse gateway. Quando o gateway externo for criado na própria VNet, a VM jumpbox será excluída. Em seguida, quando um gateway externo estiver sendo atualizado, a VM jumpbox será recriada para executar esse processo de atualização e será excluída quando a atualização for concluída. Essas atualizações incluem quando um pod é editado para adicionar um gateway externo na própria VNet.

Durante esses processos, essa VM jumpbox se comunica com:

n Durante esses processos, essa VM jumpbox se comunica com a VM do conector do gateway usando o SSH para a porta 22 da VM do conector. Como resultado, durante o processo de implantação do gateway e o processo de atualização, o requisito de comunicação entre a VM jumpbox e a porta 22 das VMs do conector deve ser atendido. A porta 22 das VMs do conector deve ser permitida entre a VM jumpbox como uma origem e as VMs do conector como um destino.

n As VMs do Unified Access Gateway usando HTTPS para a porta 9443 dessas VMs. Como resultado, durante o processo de implantação do pod e o processo de atualização do pod, quando a configuração do pod inclui Unified Access Gateway, o requisito de comunicação entre a VM jumpbox e a porta 9443 das VMs do Unified Access Gateway deve ser atendido. A porta 9443 das VMs do Unified Access Gateway deve ser permitida entre a VM jumpbox como uma origem e as VMs do Unified Access Gateway como um destino.

Como são atribuídos endereços IP dinamicamente a essas VMs, as regras de rede para permitir essa comunicação devem usar:



Observação As operações do pod em andamento não exigem disponibilidade da porta 22 na VM do conector do gateway. No entanto, se você fizer uma solicitação de suporte à VMware e à equipe de suporte determinar que a maneira de depurar essa solicitação é implantar uma VM jumpbox para comunicação SSH com a VM do conector desse gateway, será necessário atender a esse requisito de porta durante o tempo em que a equipe de suporte da VMware precisar da porta para depurar seu problema. A equipe de suporte da VMware informará sobre quaisquer requisitos, conforme apropriado para qualquer situação de suporte.

Requisitos de portas e protocolos para um pod do Horizon Cloud no manifesto da versão de setembro de 2019 ou posteriores

Para as operações do Horizon Cloud em andamento, um pod implantado no Microsoft Azure já na versão de setembro de 2019 e posteriores ou que é atualizado para ela tem requisitos específicos de porta e


VMware, Inc. 118

protocolo que são diferentes de um pod que foi implantado anteriormente. Os pods já implantados na versão de setembro de 2019 ou atualizados para ela têm versões de manifesto 1600 ou posteriores.

Importante Além das portas e protocolos descritos aqui, você deve atender aos requisitos de DNS. Para obter detalhes, consulte Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure.

Portas e protocolos exigidos pelos principais componentes do pod para operações contínuas

Além dos requisitos de DNS, as portas e os protocolos nas tabelas a seguir são necessários para que o pod funcione adequadamente para operações em andamento após a implantação.

Nas tabelas abaixo, a VM do gerenciador de termos refere-se à VM do gerenciador do pod. No portal do Microsoft Azure, parte do nome dessa VM é vmw-hcs-podID, em que podID é o UUID do pod, e a outra parte é node.

Importante Um pod ativado para alta disponibilidade tem duas VMs de gerenciador. Um pod com alta disponibilidade desabilitada tem apenas uma VM de gerenciador. Nas tabelas abaixo, onde quer que você veja a VM de gerenciador de termos, ela se aplica a todas as VMs de gerenciador em seu pod habilitado à alta disponibilidade, a menos que seja indicada de outra forma.

Todos os pods na versão de manifesto da versão de setembro de 2019 ou posteriores têm um balanceador de carga do Microsoft Azure do pod. As linhas de tabela que envolvem o balanceador de carga do pod se aplicam a todos os pods no nível de manifesto 1600 ou posterior.

Tabela 2-12. Portas e Protocolos das Operações do Pod

Origem Destino Portas

Protocolo Finalidade

VM do Gerenciador

Outra VM do gerenciador do pod

4101

TCP Para um pod ativado com alta disponibilidade, esse tráfego é roteamento JMS entre as VMs do gerenciador.

VM do Gerenciador

VMs do Unified Access Gateway

9443

HTTPS Essa porta é usada pela VM do gerenciador de pod na sub-rede de gerenciamento para definir as configurações na configuração do Unified Access Gateway do pod. Esse requisito de porta é aplicável quando se implanta inicialmente um pod com uma configuração do Unified Access Gateway e quando se edita um pod para adicionar uma configuração do Unified Access Gateway ou atualizar as definições para essa configuração do Unified Access Gateway.

Balanceador de carga do Microsoft Azure do pod

VM do Gerenciador

8080

HTTP Verificações de integridade das VMs no pool de back-ends do balanceador de carga. Quando um pod na versão de manifesto dessa versão não está habilitado com alta disponibilidade, o balanceador de carga tem uma VM de gerenciador, e seu pool de back-end a verificar.

VM do Gerenciador

Controlador de domínio

389 TCP

UDP

Serviços LDAP. Servidor que contém uma função de controlador de domínio em uma configuração do Active Directory. Registrar o pod com um Active Directory é um requisito.


VMware, Inc. 119

Tabela 2-12. Portas e Protocolos das Operações do Pod (continuação)



VM do Gerenciador

Catálogo global

3268

TCP Serviços LDAP. Servidor que contém a função de catálogo global em uma configuração do Active Directory. Registrar o pod com um Active Directory é um requisito.

VM do Gerenciador


88 TCP

UDP

Serviços do Kerberos. Servidor que contém uma função de controlador de domínio em uma configuração do Active Directory. Registrar o pod com um Active Directory é um requisito.

VM do Gerenciador

Servidor DNS

53 TCP

UDP

Serviços DNS.

VM do Gerenciador

Servidor NTP

123 UDP Serviços NTP. Servidor que fornece a sincronização de horário do NTP.

VM do Gerenciador

Servidor de Registro do True SSO

32111

TCP Servidor de Registro do True SSO. Opcional se você não estiver usando recursos do Servidor de Inscrição da True SSO com os pods.

VM do Gerenciador

Serviço Workspace ONE Access

443 HTTPS Opcional se você não estiver usando o Workspace ONE Access com o pod. Usado para criar um relacionamento de confiança entre o pod e o serviço do Workspace ONE Access. Certifique-se de que o pod possa acessar o ambiente do Workspace ONE Access que você estiver usando, no local ou no serviço de nuvem, na porta 443. Se você estiver usando o serviço de nuvem do Workspace ONE Access, consulte também a lista de endereços IP do Workspace ONE Access para o qual o Conector do Workspace ONE Access e o pod devem ter acesso no artigo 2149884 da Base de Dados de Conhecimento da VMware.

VM jumpbox transitória

VM do Gerenciador

22 TCP Conforme descrito acima em Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods, uma jumpbox transitória é usada durante a implantação de pod e os processos de atualização de pod. Embora processos contínuos não exijam essas portas, durante os processos de implantação de pod e de atualização de pod, essa VM jumpbox deve se comunicar com as VMs do gerenciador usando o SSH para a porta 22 das VMs do gerenciador. Para obter detalhes sobre os casos para os quais a VM jumpbox precisa dessa comunicação, consulte Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods.

Observação Um pod que está na versão de manifesto 1600 ou posterior e tem o recurso de alta disponibilidade habilitado terá duas VMs de gerenciador. O parágrafo anterior usa as VMs de palavra plural para indicar que a VM jumpbox deve se comunicar com todas as VMs de gerenciador do pod, tenha o pod apenas uma ou duas.


VMs do Unified Access Gateway

9443

HTTPS Essa porta é usada pela VM jumpbox na sub-rede de gerenciamento para definir as configurações na configuração do Unified Access Gateway do pod. Esse requisito de porta é aplicável quando se implanta inicialmente um pod com uma configuração do Unified Access Gateway e quando se edita um pod para adicionar uma configuração do Unified Access Gateway ao pod.


VMware, Inc. 120

Requisitos de protocolos e portas da VM do conector do gateway

Esta tabela se aplica à VM do conector do gateway usada quando você implantou o gateway externo em uma VNet separada. Além dos requisitos de DNS, as portas e os protocolos na tabela a seguir são necessários para que o gateway externo funcione adequadamente para operações em andamento após a implantação.

Na tabela abaixo, o termo VM do conector refere-se à VM do conector do gateway que gerencia a conexão entre o plano de gerenciamento de nuvem e o gateway externo. No portal do Microsoft Azure, parte do nome dessa VM é vmw-hcs-ID, em que ID é a ID do implantador do gateway, e outra parte é node.




VM do conector

Servidor DNS

53 TCP

UDP

Serviços DNS.

VM do conector

Servidor NTP



VM do conector

22 TCP Conforme descrito acima em Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods, uma jumpbox transitória é usada durante a implantação do gateway externo e durante processos de atualização. Embora processos contínuos não exijam essas portas, durante os processos de implantação e de atualização, essa VM jumpbox deve se comunicar com a VM do conector usando o SSH para a porta 22 das VMs do conector.

Requisitos de portas e protocolos da VM do Unified Access Gateway

Além dos requisitos de protocolos e portas principais acima e do DNS, as portas e os protocolos nas tabelas a seguir se relacionam aos gateways que você configurou no pod para funcionar corretamente para operações contínuas após a implantação.

Para conexões que usam um pod habilitado à alta disponibilidade configurado com as instâncias do Unified Access Gateway, o tráfego deve ser permitido nas instâncias do Unified Access Gateway do pod para destinos, conforme listado na tabela abaixo. Durante a implantação do pod, um Grupo de Segurança de Rede (NSG) é criado no ambiente do Microsoft Azure para uso pelo software do Unified Access Gateway do pod.


VMware, Inc. 121

Tabela 2-14. Requisitos de porta para o tráfego proveniente das instâncias do Unified Access Gateway do pod

Origem Destino Porta Protocolo Finalidade

Unified Access Gateway


8443 TCP Tráfego de autenticação de login. O tráfego das instâncias do Unified Access Gateway chega à VM de gerenciador do pod por meio do balanceador de carga do pod.


Horizon Agent nas VMs RDSH de farm ou área de trabalho

4172 TCP

UDP

PCoIP



22443 TCP

UDP

Blast Extreme

Por padrão, quando Blast Extreme é usado, o tráfego de redirecionamento de unidade do cliente (CDR) e o tráfego USB são encapsulados por lado nesta porta. Se você preferir, o tráfego de CDR pode ser separado na porta TCP 9427 e o tráfego de redirecionamento USB pode ser separado na porta TCP 32111.



9427 TCP Opcional para o tráfego de redirecionamento de unidade do cliente (CDR) e de redirecionamento de multimídia (MMR).



32111 TCP Opcional para o tráfego de redirecionamento USB.


Sua instância do RADIUS

1812 UDP Ao usar a autenticação de dois fatores RADIUS com essa configuração do Unified Access Gateway. O valor padrão para RADIUS é mostrado aqui.

Requisitos de protocolos e portas de tráfego de conexão do usuário final

Para obter informações detalhadas sobre os vários Horizon Clients que os usuários finais podem usar com o seu pod do Horizon Cloud, consulte a página de documentação do Horizon Client em https://docs.vmware.com/br/VMware-Horizon-Client/index.html. As portas que devem ser abertas para o tráfego proveniente de conexões dos usuários finais para acessar suas áreas de trabalho virtuais e aplicativos remotos provisionadas pelo pod dependem da escolha feita em como os usuários se conectarão:

Quando você escolhe a opção de implantador de ter uma configuração de gateway externo na própria VNet do pod

O implantador implanta instâncias do Unified Access Gateway no ambiente do Microsoft Azure, juntamente com um recurso do balanceador de carga do Microsoft Azure para essas instâncias nesse pool de backend do balanceador de carga. Esse balanceador de carga se comunica com os NICs dessas instâncias na sub-rede DMZ e está configurado como um balanceador de carga público no Microsoft Azure. O diagrama Figura 2-1. Ilustração da Arquitetura do Cloud Pod do Horizon para um pod com alta disponibilidade habilitada, com configurações de gateway interno ou externo, o gateway externo implantado na mesma VNet que o pod e um IP público habilitado para o balanceador de carga do gateway externo


VMware, Inc. 122

https://docs.vmware.com/br/VMware-Horizon-Client/index.html




https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#publicloadbalancer

descreve o local desse balanceador de carga público e das instâncias do Unified Access Gateway.Quando seu pod tem essa configuração, o tráfego dos seus usuários finais na Internet vai para esse balanceador de carga, que distribui as solicitações para as instâncias do Unified Access Gateway. Para essa configuração, você deve garantir que essas conexões de usuários finais possam chegar ao balanceador de carga usando as portas e os protocolos listados abaixo. Após a implantação, o balanceador de carga do gateway externo estará localizado no grupo de recursos denominado vmw-hcs-podID-uag, em que podID é o UUID do pod.

Quando você escolhe a opção do implantador de configuração interna do Unified Access Gateway

Uma configuração de gateway interno é implantada na própria VNet do pod por padrão. O implantador implanta instâncias do Unified Access Gateway no ambiente do Microsoft Azure, juntamente com um recurso do balanceador de carga do Microsoft Azure para essas instâncias nesse pool de backend. Esse balanceador de carga se comunica com as NICs dessas instâncias na sub-rede do tenant e está configurado como um balanceador de carga interno no Microsoft Azure. O diagrama Figura 2-1. Ilustração da Arquitetura do Cloud Pod do Horizon para um pod com alta disponibilidade habilitada, com configurações de gateway interno ou externo, o gateway externo implantado na mesma VNet que o pod e um IP público habilitado para o balanceador de carga do gateway externo descreve o local desse balanceador de carga interno e das instâncias do Unified Access Gateway. Quando seu pod tem essa configuração, o tráfego dos seus usuários finais em sua rede corporativa vai para esse balanceador de carga, que distribui as solicitações para as instâncias do Unified Access Gateway. Para essa configuração, você deve garantir que essas conexões de usuários finais possam chegar ao balanceador de carga usando as portas e os protocolos listados abaixo. Após a implantação, o balanceador de carga do gateway interno estará localizado no grupo de recursos denominado vmw-hcs-podID-uag-internal, em que podID é o UUID do pod.

Quando você escolhe as opções do implantador de configuração de gateway externo na própria VNet e não nos pods, ou a opção de usar a própria assinatura (que é um subcaso especial de uso da própria VNet, pois as VNets não abrangem as assinaturas)

O implantador implanta instâncias do Unified Access Gateway no ambiente do Microsoft Azure, juntamente com um recurso do balanceador de carga do Microsoft Azure para essas instâncias nesse pool de backend do balanceador de carga. Esse balanceador de carga se comunica com os NICs dessas instâncias na sub-rede DMZ e está configurado como um balanceador de carga público no Microsoft Azure. O diagrama Figura 2-2. Ilustração dos elementos de arquitetura do gateway externo quando o gateway externo é implantado na própria VNet, separado da do pod descreve o local desse balanceador de carga público e das instâncias do Unified Access Gateway na própria VNet do gateway.Quando seu pod tem essa configuração, o tráfego dos seus usuários finais na Internet vai para esse balanceador de carga, que distribui as solicitações para as instâncias do Unified Access Gateway. Para essa configuração, você deve garantir que essas conexões de usuários finais possam chegar ao balanceador de


VMware, Inc. 123



https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#internalloadbalancer





carga usando as portas e os protocolos listados abaixo. Após a implantação, o balanceador de carga do gateway externo estará localizado no grupo de recursos chamado vmw-hcs-ID-uag, em que ID é o valor exibido no campo ID do Implantador da página de detalhes do pod. Conforme descrito no Guia de Administração, você acessa a página de detalhes do pod pela página Capacidade do Console Administrativo.

Quando você opta por ter zero configurações do Unified Access Gateway no pod, como quando está integrando o Workspace ONE Access ao pod ou permitindo que os usuários internos se conectem diretamente via VPN

Atenção Em sistemas de produção, para acesso de usuário interno, a boa prática é usar uma configuração interna de gateway do Unified Access Gateway no pod e não conexões diretas com o pod.

Quando o Workspace ONE Access está integrado ao pod, você normalmente faz com que seus usuários finais se conectem por meio do Workspace ONE Access. Quando o Workspace ONE Access estiver integrado a um pod do Horizon Cloud no Microsoft Azure, você deverá configurá-lo apontando diretamente para o pod. Nenhuma configuração do Unified Access Gateway será necessária no pod quando os usuários finais estiverem se conectando aos recursos provisionados por pod usando o Workspace ONE Access. Para essa configuração, você carrega um certificado SSL para as VMs do gerenciador do pod usando a página de resumo do pod no Console Administrativo, conforme descrito no Guia de administração do VMware Horizon Cloud Service. Depois, conclua as etapas para integrar o Workspace ONE Access ao pod.

Tabela 2-15. Portas e protocolos de conexões externas de usuários finais quando a configuração do pod tem instâncias externas do Unified Access Gateway

Origem Destino Porta


Horizon Client

Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway

443 TCP Tráfego de autenticação de login. Também pode executar o tráfego de redirecionamento de unidade do cliente (CDR), redirecionamento USB, de redirecionamento de multimídia (MMR) e de RDP encapsulado.

O SSL (acesso HTTPS) está ativado por padrão para conexões de clientes. A porta 80 (acesso HTTP) pode ser usada em alguns casos. Consulte o tópico Entendendo o que é o redirecionamento de conteúdo da URL no Guia de administração do VMware Horizon Cloud Service.

Horizon Client


4172 TCP

UDP

PCoIP por meio do Gateway Seguro PCoIP no Unified Access Gateway


VMware, Inc. 124

Tabela 2-15. Portas e protocolos de conexões externas de usuários finais quando a configuração do pod tem instâncias externas do Unified Access Gateway (continuação)



Horizon Client


443 TCP Blast Extreme por meio do Gateway Seguro Blast no Unified Access Gateway para o tráfego de dados.

Horizon Client


443 UDP Blast Extreme por meio do Unified Access Gateway para tráfego de dados.

Horizon Client


8443 UDP Blast Extreme por meio do Gateway do Blast Secure no Unified Access Gateway para tráfego de dados (transporte adaptativo).

Navegador Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway

443 TCP HTML Access


VMware, Inc. 125

Tabela 2-16. Portas e protocolos de conexões internas de usuários finais quando a configuração do pod tem instâncias internas do Unified Access Gateway



Horizon Client




Horizon Client


4172 TCP

UDP


Horizon Client



Horizon Client



Horizon Client




443 TCP HTML Access


VMware, Inc. 126

Tabela 2-17. Portas e protocolos de conexões de usuário final interno ao usar conexões diretas de pod, como sobre VPN

Origem Destino Porta Protocolo

Finalidade

Horizon Client


443 TCP Tráfego de autenticação de login. O tráfego dos clientes chega às VMs de gerenciador do pod por meio do balanceador de carga do pod.

Horizon Client


4172 TCP

UDP

PCoIP

Horizon Client


22443 TCP

UDP

Blast Extreme

Horizon Client


32111 TCP Redirecionamento USB

Horizon Client


9427 TCP Redirecionamento de unidade do cliente (CDR) e redirecionamento de multimídia (MMR)

Navegador


443 TCP HTML Access

Portas e protocolos exigidos pelos farms e Horizon Agent a áreas de trabalho VDI

As seguintes portas devem permitir o tráfego do software relacionado ao Horizon Agent que é instalado nas VMs de área de trabalho e nas VMs RDSH de farm para as VMs do gerenciador do pod de alta disponibilidade.



VM do Gerenciador

4002 TCP Java Message Service (JMS) durante o uso da segurança avançada (padrão)


VM do Gerenciador

4001 TCP Java Message Service (JMS), herdado


VMware, Inc. 127



VM do Gerenciador

3099 TCP Servidor de mensagens da área de trabalho

Agente do FlexEngine (o agente do VMware Dynamic Environment Manager) nas VMs de área de trabalho ou RDSH de farm

Esses compartilhamentos de arquivos que você configura para uso pelo agente do FlexEngine que é executado nas VMs de área de trabalho ou RDSH de farm

445 TCP O acesso do agente do FlexEngine a seus compartilhamentos de arquivos SMB, se você estiver usando recursos do VMware Dynamic Environment Manager.

Como parte do processo de implantação de pod, o implantador cria grupos de segurança de rede (NSGs) nas interfaces de rede (NICs) em todas as VMs implantadas. Para obter detalhes sobre as regras definidas nesses NSGs, consulte o Guia de administração do Horizon Cloud.

Observação Em vez de listar nomes DNS, endereços IP, portas e protocolos em um artigo da Base de Dados de Conhecimento (KB) do Horizon Cloud, nós os fornecemos aqui como parte da documentação principal do Horizon Cloud.

Requisitos de portas e protocolos para um pod do Horizon Cloud implantado antes da versão de setembro de 2019

Para as operações do Horizon Cloud em andamento, um pod que foi implantado no Microsoft Azure antes da versão de setembro de 2019 tem requisitos específicos de porta e protocolo que são diferentes de um pod implantado na versão de manifesto da versão de setembro de 2019 ou que é atualizado para a versão de manifesto da versão de setembro de 2019. Um pod que foi implantado antes da versão de setembro de 2019 tem uma versão de manifesto 1493.1 ou anterior.

Importante Além das portas e protocolos descritos aqui, você deve atender aos requisitos de DNS. Para obter detalhes, consulte Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure.

Portas e protocolos necessários para operações contínuas para um pod da versão do manifesto

Além dos requisitos de DNS, as portas e os protocolos nas tabelas a seguir são necessários para que o pod funcione adequadamente para operações em andamento após a implantação.

Observação Nas tabelas desta seção, a VM do gerenciador de termos refere-se à VM do gerenciador do pod. No portal do Microsoft Azure, parte do nome dessa VM é vmw-hcs-podID, em que podID é o UUID do pod, e a outra parte é node.


VMware, Inc. 128





VM do Gerenciador


389 TCP

UDP

Serviços LDAP. Servidor que contém uma função de controlador de domínio em uma configuração do Active Directory. Registrar o pod com um Active Directory é um requisito.

VM do Gerenciador

Catálogo global

3268

TCP Serviços LDAP. Servidor que contém a função de catálogo global em uma configuração do Active Directory. Registrar o pod com um Active Directory é um requisito.

VM do Gerenciador


88 TCP

UDP

Serviços do Kerberos. Servidor que contém uma função de controlador de domínio em uma configuração do Active Directory. Registrar o pod com um Active Directory é um requisito.

VM do Gerenciador

Servidor DNS

53 TCP

UDP

Serviços DNS.

VM do Gerenciador

Servidor NTP


VM do Gerenciador

Servidor de Registro do True SSO

32111

TCP Servidor de Registro do True SSO. Opcional se você não estiver usando recursos do Servidor de Inscrição da True SSO com os pods.

VM do Gerenciador

Serviço Workspace ONE Access

443 HTTPS Opcional se você não estiver usando o Workspace ONE Access com o pod. Usado para criar um relacionamento de confiança entre o pod e o serviço do Workspace ONE Access. Certifique-se de que o pod possa acessar o ambiente do Workspace ONE Access que você estiver usando, no local ou no serviço de nuvem, na porta 443. Se você estiver usando o serviço de nuvem do Workspace ONE Access, consulte também a lista de endereços IP do Workspace ONE Access para o qual o Conector do Workspace ONE Access e o pod devem ter acesso no artigo 2149884 da Base de Dados de Conhecimento da VMware.


VM do Gerenciador

22 TCP Conforme descrito em Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods, uma jumpbox transitória é usada durante a implantação de pod e os processos de atualização de pod. Embora processos contínuos não exijam essas portas, durante os processos de implantação de pod e de atualização de pod, essa VM jumpbox deve se comunicar com a VM do gerenciador do pod usando o SSH para a porta 22 da VM do gerenciador. Para obter detalhes sobre os casos para os quais a VM jumpbox precisa dessa comunicação, consulte Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods.

As portas que devem ser abertas para o tráfego proveniente de conexões dos usuários finais para acessar suas áreas de trabalho virtuais e aplicativos remotos provisionadas pelo pod dependem da escolha feita em como os usuários se conectarão:

n Quando você escolhe a opção para ter uma configuração de gateway externo, as instâncias do Unified Access Gateway são implantadas automaticamente no seu ambiente do Microsoft Azure, junto com um recurso de balanceador de carga do Microsoft Azure para essas instâncias em seu


VMware, Inc. 129


pool de back-ends. Esse balanceador de carga se comunica com os NICs dessas instâncias na sub-rede DMZ e está configurado como um balanceador de carga público no Microsoft Azure. O diagrama Figura 2-1. Ilustração da Arquitetura do Cloud Pod do Horizon para um pod com alta disponibilidade habilitada, com configurações de gateway interno ou externo, o gateway externo implantado na mesma VNet que o pod e um IP público habilitado para o balanceador de carga do gateway externo descreve o local desse balanceador de carga público e das instâncias do Unified Access Gateway.Quando seu pod tem essa configuração, o tráfego dos seus usuários finais na Internet vai para esse balanceador de carga, que distribui as solicitações para as instâncias do Unified Access Gateway. Para essa configuração, você deve garantir que essas conexões de usuários finais possam chegar ao balanceador de carga usando as portas e os protocolos listados abaixo. Para o pod implantado, o balanceador de carga do gateway externo está localizado no grupo de recursos denominado vmw-hcs-podID-uag, em que podID é o UUID do pod.

n Quando você escolhe a opção para ter uma configuração do Unified Access Gateway externo, as instâncias do Unified Access Gateway são implantadas automaticamente no seu ambiente do Microsoft Azure, junto com um recurso de balanceador de carga do Microsoft Azure para essas instâncias em seu pool de back-ends. Esse balanceador de carga se comunica com as NICs dessas instâncias na sub-rede do tenant e está configurado como um balanceador de carga interno no Microsoft Azure. O diagrama Figura 2-1. Ilustração da Arquitetura do Cloud Pod do Horizon para um pod com alta disponibilidade habilitada, com configurações de gateway interno ou externo, o gateway externo implantado na mesma VNet que o pod e um IP público habilitado para o balanceador de carga do gateway externo descreve o local desse balanceador de carga interno e das instâncias do Unified Access Gateway. Quando seu pod tem essa configuração, o tráfego dos seus usuários finais em sua rede corporativa vai para esse balanceador de carga, que distribui as solicitações para as instâncias do Unified Access Gateway. Para essa configuração, você deve garantir que essas conexões de usuários finais possam chegar ao balanceador de carga usando as portas e os protocolos listados abaixo. Para o pod implantado, o balanceador de carga do gateway interno está localizado no grupo de recursos denominado vmw-hcs-podID-uag-internal, em que podID é o UUID do pod.

n Quando você não escolhe nenhuma das configurações do Unified Access Gateway, pode fazer com que os usuários finais se conectem diretamente ao pod, por exemplo, usando uma VPN. Para essa configuração, você carrega um certificado SSL para a VM do gerenciador do pod usando a página de resumo do pod no Console Administrativo, conforme descrito no Guia de administração do VMware Horizon Cloud Service.

Para obter informações detalhadas sobre os vários Horizon Clients que os usuários finais podem usar com o seu pod do Horizon Cloud, consulte a página de documentação do Horizon Client em https://docs.vmware.com/br/VMware-Horizon-Client/index.html.


VMware, Inc. 130







Tabela 2-19. Portas e protocolos de conexões externas de usuários finais quando a configuração do pod tem instâncias externas do Unified Access Gateway



Horizon Client




Horizon Client


4172 TCP

UDP


Horizon Client



Horizon Client



Horizon Client




443 TCP HTML Access


VMware, Inc. 131

Tabela 2-20. Portas e protocolos de conexões internas de usuários finais quando a configuração do pod tem instâncias internas do Unified Access Gateway



Horizon Client




Horizon Client


4172 TCP

UDP


Horizon Client



Horizon Client



Horizon Client




443 TCP HTML Access


VMware, Inc. 132

Tabela 2-21. Portas e protocolos de conexões de usuário final interno ao usar conexões diretas de pod, como sobre VPN

Origem Destino Porta Protocolo

Finalidade

Horizon Client

VM do Gerenciador

443 TCP Tráfego de autenticação de logon

Horizon Client

Horizon Agent nas VMS de área de trabalho ou de servidor de farms

4172 TCP

UDP

PCoIP

Horizon Client


22443 TCP

UDP

Blast Extreme

Horizon Client


32111 TCP Redirecionamento USB

Horizon Client


9427 TCP Redirecionamento de unidade do cliente (CDR) e redirecionamento de multimídia (MMR)

Navegador


443 TCP HTML Access

Para conexões que usam um pod configurado com as instâncias do Unified Access Gateway, o tráfego deve ser permitido nas instâncias do Unified Access Gateway do pod para destinos, conforme listado na tabela abaixo. Durante a implantação do pod, um Grupo de Segurança de Rede (NSG) é criado no ambiente do Microsoft Azure para uso pelo software do Unified Access Gateway do pod.

Tabela 2-22. Requisitos de porta para o tráfego proveniente das instâncias do Unified Access Gateway do pod



VM do Gerenciador

443 TCP Tráfego de autenticação de logon



4172 TCP

UDP

PCoIP


VMware, Inc. 133

Tabela 2-22. Requisitos de porta para o tráfego proveniente das instâncias do Unified Access Gateway do pod (continuação)




22443 TCP

UDP

Blast Extreme

Por padrão, quando Blast Extreme é usado, o tráfego de redirecionamento de unidade do cliente (CDR) e o tráfego USB são encapsulados por lado nesta porta. Se você preferir, o tráfego de CDR pode ser separado na porta TCP 9427 e o tráfego de redirecionamento USB pode ser separado na porta TCP 32111.



9427 TCP Opcional para o tráfego de redirecionamento de unidade do cliente (CDR) e de redirecionamento de multimídia (MMR).



32111 TCP Opcional para o tráfego de redirecionamento USB.


Sua instância do RADIUS

1812 UDP Ao usar a autenticação de dois fatores RADIUS com essa configuração do Unified Access Gateway. O valor padrão para RADIUS é mostrado aqui.

As seguintes portas devem permitir o tráfego por meio do software relacionado ao agente Horizon que é instalado nas VMs de área de trabalho e VMs de servidor de farms.



VM do Gerenciador

4002 TCP Java Message Service (JMS) durante o uso da segurança avançada (padrão)


VM do Gerenciador

4001 TCP Java Message Service (JMS), herdado


VMware, Inc. 134



VM do Gerenciador

3099 TCP Servidor de mensagens da área de trabalho

Agente do FlexEngine (o agente do VMware Dynamic Environment Manager) nas VMs de área de trabalho ou de servidor de farms

Esses compartilhamentos de arquivos que você configura para uso pelo agente do FlexEngine que é executado nas VMs de área de trabalho ou de servidor de farms

445 TCP O acesso do agente do FlexEngine a seus compartilhamentos de arquivos SMB, se você estiver usando recursos do VMware Dynamic Environment Manager.

Como parte do processo de implantação de pod, o implantador cria grupos de segurança de rede (NSGs) nas interfaces de rede (NICs) em todas as VMs implantadas. Para obter detalhes sobre as regras definidas nesses NSGs, consulte o Guia de administração do Horizon Cloud.

Observação Em vez de listar nomes DNS, endereços IP, portas e protocolos em um artigo da Base de Dados de Conhecimento (KB) do Horizon Cloud, nós os fornecemos aqui como parte da documentação principal do Horizon Cloud.

Crie a entidade de serviço necessária para o implantador do pod do Horizon Cloud através da criação de um registro de aplicativo

O implantador do pod do Horizon Cloud precisa de uma entidade de serviço para acessar e utilizar sua capacidade da assinatura do Microsoft Azure para seus pods do Horizon Cloud. Quando você registra um aplicativo do AD do Microsoft Azure, a entidade de serviço também é criada. Além disso, você deve gerar uma chave de autenticação e atribuir a função à entidade de serviço no nível da assinatura. Se pretende usar o recurso para que o gateway externo use sua própria assinatura, separada da do pod, você também deve executar etapas semelhantes para uma entidade de serviço associada a essa assinatura.


VMware, Inc. 135


Para obter capturas de tela e informações detalhadas e atualizadas para a criação de uma entidade de serviço, consulte o tópico da documentação do Microsoft Azure Como: usar o portal para criar um aplicativo e uma entidade de serviço do Azure AD que possam acessar recursos.

Importante Cada entidade de serviço que você configura para o uso do Horizon Cloud deve receber uma função apropriada na assinatura associada da entidade de serviço. A função para uma entidade de serviço deve permitir que as ações de que o Horizon Cloud precisa para operar nos recursos gerenciados do Horizon Cloud na assinatura associada do Microsoft Azure dessa entidade de serviço. A entidade de serviço para a assinatura do pod precisa de uma função que permita que as ações implantem o pod com êxito, operem no pod e nos recursos gerenciados por pod a fim de atender aos fluxos de trabalho de administrador iniciados usando o Console administrativo do Horizon Cloud e preservem o pod com o tempo. Ao usar uma assinatura separada para a configuração externa do Unified Access Gateway do pod, a entidade de serviço para essa assinatura precisa de uma função que permita que as ações implantem os recursos necessários para essa configuração de gateway, operem nesses recursos gerenciados pelo Horizon Cloud a fim de atender aos fluxos de trabalho do administrador e preservem os recursos relacionados ao gateway ao longo do tempo.

Conforme descrito em Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure, a entidade de serviço deve receber acesso usando um dos seguintes métodos:n No nível da assinatura, atribua a função de Colaborador. A função de Colaborador é uma das

funções internas do Microsoft Azure. A função de Colaborador está descrita em Funções internas para recursos do Azure na documentação do Microsoft Azure.

n No nível da assinatura, atribua uma função personalizada que você tenha configurado para fornecer à entidade de serviço Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure de que o Horizon Cloud precisa para a implantação dos recursos relacionados ao pod e para fluxos de trabalho contínuos iniciados pelo administrador e operações de manutenção de pod.

n Ao usar uma assinatura separada para a configuração externa do Unified Access Gateway e implantar em um grupo de recursos existente, uma combinação válida é conceder acesso à entidade de serviço para acessar o grupo de recursos e a VNet associada usando uma função que fornece permissões de escopo estreito, além de conceder acesso à entidade de serviço para acessar a assinatura usando a função integrada de Leitor.

Você executa estas etapas usando o portal do Microsoft Azure apropriado para sua conta registrada. Por exemplo, há endpoints de portal específicos para essas nuvens do Microsoft Azure.

n Microsoft Azure (global padrão)

n Microsoft Azure na Alemanha

n Microsoft Azure na China


VMware, Inc. 136

https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal

https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal



n Microsoft Azure Governo dos EUA

Observação Ao executar estas etapas, você pode coletar alguns dos valores que serão necessários para o assistente de implementação, como descrito no Informações relacionadas à assinatura para o assistente de implantação de pod do Horizon Cloud, especificamente:

n ID de aplicativo

n Chave de autenticação

Cuidado Embora seja possível definir a duração da expiração da chave secreta para um período de tempo específico, se você fizer isso, lembre-se de atualizar a chave antes da expiração ou o pod associado do Horizon Cloud parará de funcionar. O Horizon Cloud não pode detectar ou saber a duração definida. Para o bom funcionamento, defina a expiração da chave como Nunca.

Se você preferir não definir a expiração como Nunca e preferir atualizar a chave antes dela expirar, precisará se lembrar de fazer login no Console Administrativo do Horizon Cloud antes da data de expiração e inserir o novo valor de chave nas informações de assinatura do pod associado. Para obter as etapas detalhadas, consulte o tópico Atualizar as informações de assinatura associadas aos pods implantados no Guia de administração do VMware Horizon Cloud Service on Microsoft Azure.

Dentre as etapas abaixo, a etapa 7.a mostra a entidade de serviço que está recebendo acesso no nível da assinatura.

Pré-requisitos

Se você quiser atribuir uma função personalizada à entidade de serviço em vez da função interna de colaborador, verifique se a função personalizada existe na sua assinatura. Verifique se a função personalizada permite as operações de gerenciamento exigidas pelo Horizon Cloud, conforme descrito em Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure.

Procedimentos

1 A partir da barra de navegação esquerda do portal do Microsoft Azure, clique no

(Azure Active Directory), em seguida, clique no (Registros de aplicativo).

2 Clique em Novo registro de aplicativo.

3 Digite um nome descritivo e selecione um tipo de conta com suporte.


VMware, Inc. 137


4 Na seção URI de Redirecionamento, selecione Web, digite http://localhost:8000 e clique em Registrar.

Opção Descrição

Nome O nome fica a seu critério. O nome é uma maneira de diferenciar esta entidade de serviço utilizada pelo Horizon Cloud de quaisquer outras entidades de serviço que possam existir nesta mesma assinatura.

URI de Redirecionamento Garanta que a opção Web esteja selecionada.

Digite http://localhost:8000 conforme mostrado. O Microsoft Azure marca isso como um campo obrigatório. Como o Horizon Cloud não precisa de uma URL de entrada para a entidade de serviço, http://localhost:8000 é usado para satisfazer o requisito do Microsoft Azure.

O registro do aplicativo recém-criado aparece na tela.

5 Copie o ID do aplicativo e o ID do diretório (tenant) e salve-os em um local onde possa recuperá-los mais tarde ao executar o assistente de implantação.

6 Na tela de detalhes da entidade de serviço, crie a chave secreta de autenticação da entidade de serviço.

a Clique no (Certificados e segredos).

b Clique em Novo segredo do cliente.


VMware, Inc. 138

c Digite uma descrição, selecione uma duração da expiração e clique em Adicionar.

A descrição da chave deve ter 16 caracteres ou menos, por exemplo, Hzn-Cloud-Key1.

Cuidado Você pode definir a duração da expiração para Nunca ou para um período de tempo específico. No entanto, se você definir uma duração específica, precisará se lembrar de atualizar a chave antes que ela expire e inserir a nova chave nas informações de assinatura do pod no Console Administrativo do Horizon Cloud. Caso contrário, o pod associado parará de funcionar. O Horizon Cloud não pode detectar ou saber a duração definida.

Importante Mantenha essa tela aberta até copiar o valor secreto e colá-lo em um local onde poderá recuperá-lo mais tarde. Não feche a tela até ter copiado o valor secreto.

d Copie o valor secreto para um novo local onde possa recuperá-lo mais tarde ao executar o assistente de implementação.


VMware, Inc. 139

7 Atribua a função à entidade de serviço no nível da assinatura.

Cuidado Se a função atribuída da entidade de serviço não permitir as operações exigidas pelo implantador do pod, de acordo com as opções selecionadas no assistente de implantação, o assistente impedirá que você conclua as etapas do assistente. Para saber as permissões que a função atribuída deve fornecer, consulte Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure.

a Navegue até a tela de configurações de sua assinatura clicando em Todos os serviços na barra de navegação principal do portal do Microsoft Azure, clicando em Assinaturas e, em seguida, clicando no nome da assinatura que será utilizada com o pod.

Observação Nesse momento, na tela, você pode copiar a ID de assinatura, que será necessária mais tarde no assistente de implementação.

b Clique no (Controle de acesso (IAM)) e clique em Adicionar > Adicionar atribuição de função para abrir a tela Adicionar atribuição de função.

c Na tela Adicionar atribuição de função, para Função, selecione a função que você está atribuindo, de acordo com as regras descritas em Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure.


VMware, Inc. 140

d Use a caixa Selecionar para procurar sua entidade de serviço pelo nome dado.

A captura de tela a seguir ilustra essa etapa em que a função de Colaborador está selecionada para a entidade de serviço.

Observação Verifique se a lista suspensa Atribuir acesso a está definida como Usuário, grupo ou aplicativo do Azure AD.

e Clique em sua entidade de serviço para torná-la um membro selecionado e, em seguida, clique em Salvar.


VMware, Inc. 141

8 Verifique se a sua assinatura possui os provedores de recursos registrados dos quais o pod necessita.

a Na tela Controle de acesso (IAM) em que você se encontra devido à etapa anterior, navegue até

a lista de provedores de recursos da assinatura clicando em (Provedores de recursos) no menu da assinatura.

b Verifique se os seguintes provedores de recursos têm um status (Registrado) e, caso contrário, registre-os.

n Microsoft.Compute

n microsoft.insights

n Microsoft.Network

n Microsoft.Storage

n Microsoft.KeyVault

n Microsoft.Authorization

n Microsoft.Resources

n Microsoft.ResourceHealth

n Microsoft.DBforPostgreSQL

n Microsoft.Sql

Resultados

Nesse momento, você já criou e configurou o Provedor de Serviços para o pod e tem os valores relacionados à assinatura necessários na primeira etapa do assistente de implantação do pod. Os quatro valores relacionados à assinatura são:

n ID da assinatura


VMware, Inc. 142

n ID do Azure Active Directory

n ID de aplicativo

n Valor da chave do aplicativo

Próximo passo

Verifique se você obteve todas as informações relacionadas à assinatura que serão inseridas no assistente de implantação. Consulte Informações relacionadas à assinatura para o assistente de implantação de pod do Horizon Cloud.

Se você pretende usar uma assinatura separada para implantar a configuração externa do Unified Access Gateway em um grupo de recursos existente e quiser conceder permissões detalhadas e de escopo estreito em vez de acesso no nível da assinatura, consulte Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure para obter detalhes. Certifique-se de que o acesso apropriado seja concedido à entidade de serviço de modo a atender aos requisitos do implantador do Horizon Cloud.

Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft AzureA entidade de serviço usada pelo Horizon Cloud para realizar operações tanto na assinatura quanto nos grupos de recursos do Microsoft Azure precisa de uma função atribuída que especifique quais operações são permitidas à entidade de serviço realizar nessa assinatura e em seus grupos de recursos. Mesmo que o uso da função integrada Colaborador do Microsoft Azure forneça todas as operações necessárias ao Horizon Cloud, ele faz isso concedendo o maior número possível de permissões. Em vez de usar essa função interna Colaborador do Microsoft Azure no nível da assinatura, você pode criar uma função personalizada com o conjunto mínimo de permissões, com escopo para o conjunto mínimo de operações que o Horizon Cloud exige na assinatura associada, e atribuir essa função personalizada à entidade de serviço no nível da assinatura. Se você adotar essa abordagem com o objetivo de ter uma assinatura separada para a configuração externa do Unified Access Gateway do pod e selecionar a implantação dos recursos de gateway em um grupo de recursos que você criar e manter, terá a opção de atribuir à entidade de serviço mais permissões detalhadas e de escopo estreito nessa assinatura separada.

O conceito abrangente é o de que o Horizon Cloud precisa realizar determinadas operações em sua assinatura e nos grupos de recursos dele para criar e manter com êxito os recursos necessários para ter um pod e suas configurações de gateway. Como um exemplo simples, como o pod e a arquitetura de gateway exigem máquinas virtuais com NICs, o Horizon Cloud precisa da capacidade de criar máquinas virtuais e NICs na sua assinatura e anexar esses NICs a sub-redes na VNet da assinatura. Algumas das opções que você escolher para as implantações do pod e do gateway determinarão o conjunto específico de operações que o Horizon Cloud precisará realizar. É possível restringir as habilidades do Horizon Cloud em sua assinatura às operações mínimas necessárias, seguindo as regras descritas abaixo, de acordo com as opções que você estiver adotando para implantar um pod e para sua configuração externa de gateway.

Para obter detalhes sobre as funções personalizadas no Microsoft Azure e as etapas necessárias para a criação de uma função personalizada, consulte o tópico de documentação do Microsoft Azure Funções personalizadas para recursos do Azure. Para obter detalhes sobre como uma função funciona, sua estrutura e a estrutura das operações de gerenciamento, consulte Compreender as definições de função dos recursos do Azure na documentação do Microsoft Azure. Conforme descrito no tópico da


VMware, Inc. 143

https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles


https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions

https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions

documentação, uma definição de função é um conjunto de permissões. Essa definição de função é chamada de função. A função lista as operações de gerenciamento que podem ser realizadas, bem como as operações que não podem ser realizadas, pela entidade de serviço à qual essa função está atribuída. Uma operação de gerenciamento é uma combinação do recurso e da ação executada nesse recurso.

Este tópico inclui as seguintes seções.

n Visão geral dos casos de uso disponíveis

n Ao usar uma única assinatura para o pod e suas configurações de gateway ou usar uma assinatura separada para a configuração externo do Unified Access Gateway com permissões definidas no nível da assinatura

n Ao usar uma assinatura separada para a configuração externa do Unified Access Gateway, implantá-la em um grupo de recursos personalizado, com a função de leitor no nível da assinatura e permissões adicionais necessárias atribuídas em níveis granulares

Visão geral dos casos de uso disponíveis

Ao discutir as operações necessárias para o Horizon Cloud em suas assinaturas e grupos de recursos do Microsoft Azure, existem esses casos de uso.

Observação A função da entidade de serviço criada para a assinatura especificada relativa ao restante dos recursos de pod no caso de uso de duas assinaturas deve seguir as mesmas regras necessárias para o caso de uso de assinatura única.


VMware, Inc. 144

Caso de uso Descrição

Uma única assinatura usada pelo Horizon Cloud relativa aos pods e suas configurações externas do Unified Access Gateway.

Nesse caso, o acesso deve ser concedido à entidade de serviço no nível da assinatura. A função atribuída à entidade de serviço nesse nível deve permitir as ações que o Horizon Cloud precisa realizar na sua assinatura para criar, com êxito, nessa assinatura, os recursos necessários e trabalhar com esses recursos ao longo do tempo. Por exemplo, nesse caso, a função deve fornecer a capacidade de criar os grupos de recursos padrão, os grupos de segurança de rede, as máquinas virtuais e assim por diante.

Duas assinaturas, e você deseja que o Horizon Cloud crie automaticamente os grupos de recursos e os recursos necessários ao gateway na assinatura especificada do gateway externo, tal qual se passa com a assinatura para o restante dos recursos de pod.

n Uma assinatura especificada para uso com os recursos de configuração externa do Unified Access Gateway

n Uma assinatura para o restante dos recursos do pod

Ao usar essa opção, a entidade de serviço de cada assinatura deve receber acesso no nível da assinatura, com permissões que viabilizem as ações iguais às do caso de uso de assinatura única descrito acima.

Duas assinaturas conforme descrito acima, mas em vez de o Horizon Cloud criar automaticamente os grupos de recursos e os recursos necessários do gateway externo, você cria um grupo de recursos com antecedência na assinatura especificada do gateway externo e deseja que o Horizon Cloud implante os recursos do gateway nesse grupo de recursos existente.

Duas opções para conceder acesso à entidade de serviço usada para implantar o gateway externo:

n Conceda acesso no nível da assinatura, como no caso acima.

n Use a seguinte combinação:

n No nível da assinatura, conceda acesso usando a função de Leitor integrada.

n No nível do grupo de recursos nomeados, conceda acesso usando as permissões definidas em uma função personalizada. As permissões concedidas no nível do grupo de recursos devem ser fornecidas às operações que o Horizon Cloud precisa realizar no grupo de recursos para implantar e configurar os recursos do gateway externo ali.

Além das permissões no grupo de recursos, o Horizon Cloud precisa das permissões para realizar as seguintes ações, dependendo dos seus planos de implantação:

n Se esta implantação usar sub-redes criadas com antecedência na VNet dessa assinatura, o Horizon Cloud precisará da capacidade de criar NICs e grupos de segurança de rede (NSGs) nessas sub-redes. As permissões necessárias para a VNet às quais a sub-rede pertence são Microsoft.Network/virtualNetworks/subnets/* e Microsoft.Network/networkSecurityGroups/*

n Se essa implantação fizer com que o Horizon Cloud gere as sub-redes, além das permissões Microsoft.Network/virtualNetworks/subnets/* e


VMware, Inc. 145

Caso de uso Descrição

Microsoft.Network/networkSecurityGroups/*

acima, o Horizon Cloud precisará da capacidade de criar as sub-redes. A permissão necessária para a VNet é Microsoft.Network/virtualNetworks/write

n Se a implantação do seu gateway externo especificar o uso de um endereço IP público, o Horizon Cloud precisará da capacidade de criar endereços IP públicos no grupo de recursos nomeado. A permissão necessária no grupo de recursos nomeado é Microsoft.Network/publicIPAddresses

Ao usar uma única assinatura para o pod e suas configurações de gateway ou usar uma assinatura separada para a configuração externo do Unified Access Gateway com permissões definidas no nível da assinatura

Para esses casos de uso, as permissões são atribuídas no nível da assinatura. Para a função personalizada definida na entidade de serviço que você especificar na etapa de assinatura dos fluxos de trabalho do Horizon Cloud, as seguintes ações são necessárias para a definição de função personalizada. O * (caractere curinga) concede acesso a todas as operações que correspondem à string na operação do provedor de recursos listada. Para obter as descrições das operações, consulte a documentação do Microsoft Azure nos links listados abaixo.

Tabela 2-23. As operações de recursos do Microsoft Azure que devem ser permitidas na função personalizada ao atribuir permissões no nível da assinatura

Operação Descrição na documentação do Microsoft Azure

Microsoft.Authorization/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftauthorization

Microsoft.Compute/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute


VMware, Inc. 146

https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftauthorization








https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute








Tabela 2-23. As operações de recursos do Microsoft Azure que devem ser permitidas na função personalizada ao atribuir permissões no nível da assinatura (continuação)


Microsoft.Compute/availabilitySets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/disks/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/images/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/locations/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/snapshots/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute


VMware, Inc. 147











































Microsoft.Compute/virtualMachines/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/virtualMachineScaleSets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.DBforPostgreSQL/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftdbforpostgresql

Microsoft.KeyVault/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault

Microsoft.KeyVault/vaults/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault


VMware, Inc. 148

















https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftdbforpostgresql








https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault


















Microsoft.KeyVault/vaults/secrets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault

Microsoft.Network/loadBalancers/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/networkInterfaces/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/networkSecurityGroups/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/publicIPAddresses/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork


VMware, Inc. 149









https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork


































Microsoft.Network/virtualNetworks/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/virtualNetworks/write https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/virtualNetworks/subnets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork


VMware, Inc. 150











































Microsoft.ResourceHealth/availabilityStatuses/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresourcehealth

Microsoft.Resources/subscriptions/resourceGroups/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresources

Microsoft.Resources/deployments/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresources

Microsoft.Storage/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftstorage

Microsoft.Storage/storageAccounts/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftstorage

O seguinte bloco de códigos JSON é um exemplo que ilustra a possível aparência de uma definição de função personalizada chamada Pod do Horizon Cloud quando tem o conjunto de operações exigidas pelo implantador do pod. Para ver uma descrição das propriedades e das informações de uso, consulte a seção Propriedades da função personalizada no tópico de documentação do Microsoft Azure intitulado


VMware, Inc. 151

https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresourcehealth








https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresources
















https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftstorage
















https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles#custom-role-properties

Funções personalizadas para recursos do Azure. A ID é a ID exclusiva da função personalizada. Quando você cria a função personalizada usando o Azure PowerShell ou a interface de linha de comando do Azure, essa ID é gerada automaticamente quando você cria uma nova função. Conforme descrito no tutorial: Criar uma função personalizada para os recursos do Azure usando a interface de linha de comando do Azure, mysubscriptionId1 é a ID da sua própria assinatura.

{"Name": "Horizon Cloud Pod","Id": "uuid","IsCustom": true,"Description": "Minimum set of Horizon Cloud pod required operations","Actions": [ "Microsoft.Authorization/*/read" "Microsoft.Compute/*/read" "Microsoft.Compute/availabilitySets/*" "Microsoft.Compute/disks/*" "Microsoft.Compute/images/*" "Microsoft.Compute/locations/*" "Microsoft.Compute/virtualMachines/*" "Microsoft.Compute/virtualMachineScaleSets/*" "Microsoft.Compute/snapshots/*" "Microsoft.DBforPostgreSQL/*" "Microsoft.KeyVault/*/read" "Microsoft.KeyVault/vaults/*" "Microsoft.KeyVault/vaults/secrets/*" "Microsoft.Network/loadBalancers/*" "Microsoft.Network/networkInterfaces/*" "Microsoft.Network/networkSecurityGroups/*" "Microsoft.Network/publicIPAddresses/*" "Microsoft.Network/virtualNetworks/read" "Microsoft.Network/virtualNetworks/write" "Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read" "Microsoft.Network/virtualNetworks/subnets/*" "Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read" "Microsoft.Resources/subscriptions/resourceGroups/*" "Microsoft.ResourceHealth/availabilityStatuses/read" "Microsoft.Resources/deployments/*" "Microsoft.Storage/*/read" "Microsoft.Storage/storageAccounts/*" ],"NotActions": [],"DataActions": [],"NotDataActions": [],"AssignableScopes": [ "/subscriptions/mysubscriptionId1" ]}

Ao usar uma assinatura separada para a configuração externa do Unified Access Gateway, implantá-la em um grupo de recursos personalizado, com a função de leitor no nível da assinatura e permissões adicionais necessárias atribuídas em níveis granulares


VMware, Inc. 152


https://docs.microsoft.com/en-us/azure/role-based-access-control/tutorial-custom-role-cli



Para esse caso de uso, você pode atribuir a função Leitor integrada à entidade de serviço no nível da assinatura e, em seguida, conceder acesso no nível do grupo de recursos nomeado usando uma função personalizada que especifica as permissões na tabela a seguir. Algumas permissões adicionais em sub-redes e na VNet serão necessárias, dependendo das suas opções de implantação planejadas:

n Se essa implantação externa de gateway usar sub-redes que você cria com antecedência, o Horizon Cloud precisará da capacidade de criar NICs e grupos de segurança de rede (NSGs) nessas sub-redes. As permissões necessárias para a VNet às quais a sub-rede pertence são Microsoft.Network/virtualNetworks/subnets/* e Microsoft.Network/networkSecurityGroups/*

n Se essa implantação externa de gateway fizer com que o Horizon Cloud gere as sub-redes, além das permissões Microsoft.Network/virtualNetworks/subnets/* e Microsoft.Network/networkSecurityGroups/* acima, o Horizon Cloud precisará da capacidade de criar as sub-redes. A permissão necessária para a VNet da assinatura é Microsoft.Network/virtualNetworks/write

n Se a sua implantação especificar o uso de um endereço IP público para a configuração externa de gateway, o Horizon Cloud precisará da capacidade de criar endereços IP públicos no grupo de recursos nomeado. A permissão necessária no grupo de recursos nomeado é Microsoft.Network/publicIPAddresses

As seguintes operações permitidas são necessárias para o grupo de recursos nomeado. O * (caractere curinga) concede acesso a todas as operações que correspondem à string na operação do provedor de recursos listada. Para obter as descrições das operações, consulte a documentação do Microsoft Azure nos links listados abaixo.

Tabela 2-25. Operações de recurso do Microsoft Azure que devem ser permitidas no grupo de recursos especificado


Microsoft.Authorization/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftauthorization

Microsoft.Compute/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute


VMware, Inc. 153

















Tabela 2-25. Operações de recurso do Microsoft Azure que devem ser permitidas no grupo de recursos especificado (continuação)


Microsoft.Compute/availabilitySets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/disks/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/images/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/locations/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/snapshots/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute


VMware, Inc. 154











































Microsoft.Compute/virtualMachines/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/virtualMachineScaleSets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.DBforPostgreSQL/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftdbforpostgresql

Microsoft.KeyVault/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault

Microsoft.KeyVault/vaults/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault


VMware, Inc. 155











































Microsoft.KeyVault/vaults/secrets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault

Microsoft.Network/loadBalancers/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/networkInterfaces/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/publicIPAddresses/*, se a sua implantação especificar o uso de um endereço IP público para a implantação externa de gateway.


Microsoft.Network/virtualNetworks/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork


VMware, Inc. 156











































Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.ResourceHealth/availabilityStatuses/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresourcehealth

Microsoft.Resources/subscriptions/resourceGroups/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresources

Microsoft.Resources/deployments/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresources


VMware, Inc. 157











































Microsoft.Storage/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftstorage

Microsoft.Storage/storageAccounts/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftstorage

Informações relacionadas à assinatura para o assistente de implantação de pod do Horizon Cloud

O assistente de implantação de pod do Horizon Cloud requer que você forneça as seguintes partes de informações da sua assinatura do Microsoft Azure. Se você estiver implantando o gateway externo na própria assinatura, separada da do pod, o implantador exigirá essas informações para as duas assinaturas.

Importante Você deve obter a chave de aplicativo no momento em que você a gera no portal do Microsoft Azure. Para obter mais informações, consulte Crie a entidade de serviço necessária para o implantador do pod do Horizon Cloud através da criação de um registro de aplicativo. Você pode obter outras partes de informações a qualquer momento fazendo login no seu portal do Microsoft Azure usando suas credenciais de conta do Microsoft Azure.

Os IDs são UUIDs, no formato 8-4-4-4-12. Esses IDs e a chave descritos na tabela a seguir são usados na primeira etapa do assistente de implantação do pod.


VMware, Inc. 158

















Valor Obrigatório Como coletar Seus valores

Ambiente Determine o ambiente de nuvem do Microsoft Azure ao se inscrever na assinatura do Microsoft Azure. Nesse momento, sua conta e assinatura são criadas no ambiente específico do Microsoft Azure.

ID da assinatura No portal do Microsoft Azure, navegue até a tela de configurações de sua assinatura clicando em Todos os serviços na barra de navegação principal do portal do Microsoft Azure, clicando em Assinaturas e, em seguida, clicando no nome da assinatura que será utilizada com o pod. Localize o ID de assinatura exibida.

ID do diretório No portal do Microsoft Azure, clique no

> (em Gerenciar).

ID de aplicativo No portal do Microsoft Azure, clique no

>

e, em seguida, clique no registro de aplicativo que você criou para o Horizon Cloud usando as etapas em Crie a entidade de serviço necessária para o implantador do pod do Horizon Cloud através da criação de um registro de aplicativo.

Chave do aplicativo Obtenha a chave quando gerá-la no portal do Microsoft Azure. Consulte Crie a entidade de serviço necessária para o implantador do pod do Horizon Cloud através da criação de um registro de aplicativo.

Converter um arquivo de certificado para o formato PEM necessário para a implantação do pod

O recurso do Unified Access Gateway no seu pod requer SSL para conexões de clientes. Quando você deseja que o pod tenha uma configuração do Unified Access Gateway, o assistente de implantação de pod requer um arquivo no formato PEM para fornecer a cadeia de certificados do servidor SSL para a configuração do Unified Access Gateway do pod. O arquivo PEM único deve conter a cadeia de certificados inteira, incluindo a chave privada: o certificado do servidor SSL, quaisquer certificados de CA intermediários necessários, o certificado da CA raiz e a chave privada.

Para obter mais detalhes sobre os tipos de certificado usados em Unified Access Gateway, consulte o tópico chamado Selecionando o tipo de certificado correto na documentação do produto do Unified Access Gateway.


VMware, Inc. 159

https://docs.vmware.com/br/Unified-Access-Gateway/index.html

https://docs.vmware.com/br/Unified-Access-Gateway/index.html

Na etapa do assistente de implantação de pod das configurações do gateway, carregue um arquivo de certificado. Durante o processo de implantação, esse arquivo é enviado para a configuração das instâncias do Unified Access Gateway implantadas. Quando você realiza a etapa de carregamento na interface do assistente, o assistente verifica se o arquivo que você carregou atende a estes requisitos:

n O arquivo pode ser analisado como formato PEM.

n Ele contém uma cadeia de certificados válida e uma chave privada.

n Essa chave privada correspondente à chave pública do certificado do servidor.

Se você não tiver um arquivo no formato PEM para suas informações de certificado, deverá converter suas informações de certificado em um arquivo que atenda os requisitos acima. Você deve converter o arquivo no formato não PEM no formato PEM e criar um único arquivo PEM que contenha a cadeia de certificados inteira mais a chave privada. Você também precisa editá-lo para remover informações adicionais, se houver, para que o assistente não tenha quaisquer problemas ao analisar o arquivo. As etapas de alto nível são:

1 Converta suas informações de certificado para o formato PEM e crie um único arquivo PEM que contenha a cadeia de certificados e a chave privada.

2 Edite o arquivo para remover as informações de certificado extras, se houver alguma, que estejam fora das informações do certificado entre cada conjunto de marcadores ----BEGIN CERTIFICATE---- e -----END CERTIFICATE-----.

Os exemplos de código nas etapas a seguir consideram que você está começando com um arquivo chamado mycaservercert.pfx que contém o certificado da CA raiz, as informações de certificado de CA intermediária e a chave privada.

Pré-requisitos

n Verifique se possui o arquivo do certificado. O arquivo pode estar no formato PKCS#12 (.p12 ou .pfx) ou no formato Java JKS ou JCEKS.

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.

n Familiarize-se com a ferramenta de linha de comando openssl que você pode usar para converter o certificado. Consulte https://www.openssl.org/docs/apps/openssl.html.

n Se o certificado estiver no formato Java JKS ou JCEKS, familiarize-se com a ferramenta de linha de comando keytool do Java para converter o certificado primeiramente para o formato .p12 ou .pks antes de convertê-lo em arquivos .pem.


VMware, Inc. 160

https://www.openssl.org/docs/apps/openssl.html

Procedimentos

1 Se seu certificado estiver no formato Java JKS ou JCEKS, utilize o keytool para converter o certificado para o formato .p12 ou .pks.

Importante Utilize a mesma senha de origem e destino durante essa conversão.

2 Se seu certificado estiver no formato PKCS#12 (.p12 ou .pfx) ou após o certificado ser convertido para o formato PKCS#12, utilize o openssl para converter o certificado para um arquivo .pem.

Por exemplo, se o nome do certificado é mycaservercert.pfx, você poderá usar os seguintes comandos para converter o certificado:

openssl pkcs12 -in mycaservercert.pfx -nokeys -out mycaservercertchain.pem

openssl pkcs12 -in mycaservercert.pfx -nodes -nocerts -out mycaservercertkey.pem

A primeira linha acima obtém os certificados no mycaservercert.pfx e os grava no formato PEM como mycaservercertchain.pem. A segunda linha acima obtém a chave privada do mycaservercert.pfx e a grava no formato PEM como mycaservercertkey.pem

3 (Opcional) Se a chave privada não estiver no formato RSA, converta a chave privada no formato de chave privada RSA.

As instâncias do Unified Access Gateway requerem o formato da chave privada RSA. Para verificar se você precisa executar essa etapa, examine o arquivo PEM e veja se as informações da chave privada começam com

-----BEGIN PRIVATE KEY-----

Se a chave privada começar com essa linha, você deverá converter a chave privada no formato RSA. Se a chave privada começar com -----BEGIN RSA PRIVATE KEY-----, você não precisará executar essa etapa para converter a chave privada.

Para converter a chave privada no formato RSA, execute este comando.

openssl rsa -in mycaservercertkey.pem -check -out mycaservercertkeyrsa.pem

A chave privada no arquivo PEM agora está no formato RSA (-----BEGIN RSA PRIVATE KEY----- e -----END RSA PRIVATE KEY-----).

4 Combine as informações no arquivo PEM da cadeia de certificados e no arquivo PEM da chave privada para criar um único arquivo PEM.

O exemplo abaixo mostra um exemplo de onde o conteúdo do mycaservercertkeyrsa.pem é exibido primeiro (a chave privada no formato RSA), seguido pelo conteúdo do mycaservercertchain.pem, que é o seu certificado SSL primário, seguido por um certificado intermediário, seguido pelo certificado raiz.

-----BEGIN CERTIFICATE-----

.... (your primary SSL certificate)


VMware, Inc. 161

-----END CERTIFICATE-----


.... (the intermediate CA certificate)



.... (the trusted root certificate)


-----BEGIN RSA PRIVATE KEY-----

.... (your server key from mycaservercertkeyrsa.pem)

----- END RSA PRIVATE KEY-----

Observação O certificado do servidor deve ser exibido primeiro, seguido por quaisquer outros intermediários e, em seguida, pelo certificado raiz confiável.

5 Se houver entradas de certificado desnecessárias ou informações externas entre os marcadores BEGIN e END, edite o arquivo para removê-las.

Resultados

O arquivo PEM resultante atende aos requisitos do assistente de implantação de pod.

Implantar um pod do Horizon Cloud no Microsoft AzureVocê executa o assistente de implantação de pod para implantar os componentes que juntos compõem um pod e suas configurações de gateway. O componente do conector do pod é combinado com o Horizon Cloud para que você possa utilizar a capacidade do Microsoft Azure com o Horizon Cloud.

O implantador usa as informações fornecidas em cada etapa do assistente para determinar como configurar o pod. Depois de fornecer as informações solicitadas em uma etapa específica, prossiga para a próxima etapa clicando em Avançar.

Cuidado Os endereços IP mencionados nessas etapas são exemplos. Você deve utilizar os intervalos de endereços que atendam às necessidades de sua organização. Para cada etapa que menciona um intervalo de endereço IP, substitua os que são aplicáveis para a sua organização.

Pré-requisitos

Antes de executar o assistente de implantação de pod, certifique-se de que o seu ambiente atenda a esses pré-requisitos. Os itens que você precisa fornecer no assistente variam de acordo com as opções de configuração de pod desejadas. Para conhecer os pré-requisitos, consulte Pré-requisitos para executar o assistente de implantação de pod.

As opções de configuração de pod incluem:

n Selecionar sub-redes existentes que você cria com antecedência ou fazer que essas sub-redes sejam criadas automaticamente pelo implantador de pod

n Selecionar se deseja ativar a alta disponibilidade para o pod. Se você implantar o pod sem a alta disponibilidade habilitada, poderá editar o pod posteriormente para habilitá-la.

n Fazer com que o processo de implantação crie um locatário do VMware Workspace ONE® Access™.


VMware, Inc. 162

n Implantar com uma configuração externa ou interna do Unified Access Gateway ou implantar com ambas. Se você implantar com apenas um tipo de configuração de gateway, poderá editar o pod mais tarde para adicionar o outro tipo não configurado.

Se você implantar com a configuração do Unified Access Gateway como... Mais tarde, você pode editar o pod para adicionar...

Externo Interno

Interno Externo

Nenhum Um ou o outro ou ambos ao mesmo tempo

n Implantação com uma configuração externa do Unified Access Gateway na própria VNet, separada da VNet do pod.

n Implantação com uma configuração externa do Unified Access Gateway na própria assinatura, separada da assinatura do pod. Como as VNets não abrangem as assinaturas, essa opção é um cenário especial do caso da VNet separada — quando o gateway externo é implantado usando-se a própria assinatura, isso também significa que está na própria VNet.

n Qual código SKU usar para o balanceador de carga do Microsoft Azure para as configurações de gateway interno e externo. As opções são o código SKU do balanceador de carga padrão do Azure ou o código SKU do balanceador de carga básico do Azure. Para uma comparação dos dois códigos SKU, consulte o tópico de documentação do Microsoft Azure Comparação de SKU do Balanceador de Carga.

n Implantar com a opção de autenticação de dois fatores RADIUS definida nas configurações de gateway do pod. Se você implantar sem as configurações RADIUS definidas nas configurações de gateway do pod, poderá editar o pod mais tarde para adicionar o outro tipo não configurado.

n Para uma configuração de Unified Access Gateway externo, você pode optar por não ter um endereço IP público no balanceador de carga da configuração. Se você selecionar a opção do assistente de não ter um endereço IP público no balanceador de carga, deverá especificar no assistente um valor de IP mapeado para um FQDN no seu servidor DNS. Esse FQDN é aquele que será usado nos clientes Horizon dos usuários finais para conexões PCoIP a esse gateway. No processo de implantação, o implantador configurará esse endereço IP nas definições de configuração do Horizon do Unified Access Gateway. Na documentação do Unified Access Gateway, esse valor de IP é chamado de URL externa do PCoIP. Embora a documentação do Unified Access


VMware, Inc. 163

http://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#skus


Gateway se refira a ele como uma URL, o valor inserido deve ser um endereço IP. Você mapeia esse endereço IP para um FQDN no DNS, que é o FQDN usado nos clientes Horizon dos usuários finais para estabelecer as sessões do PCoIP deles com a configuração externa do Unified Access Gateway do pod.

Cuidado Posteriormente, você não poderá editar o pod implantado para alterar a configuração desse endereço IP para o balanceador de carga do gateway externo. Portanto, certifique-se de inserir o endereço IP público no assistente de implantação que corresponde ao seu mapeamento DNS com o FQDN, e que o FQDN corresponde ao do certificado carregado no assistente de implantação.

Procedimentos

1 Pré-requisitos para executar o assistente de implantação de pod

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.

2 Iniciar o assistente de implantação de pod

Ao implantar o primeiro pod no Microsoft Azure, você inicia o assistente de implantação do pod usando o recurso Adicionar Capacidade de Nuvem da página Introdução do Console Administrativo do Horizon Cloud.

3 Especificar as informações de assinatura do Microsoft Azure para o novo pod

Nesta etapa do assistente de implantação de pod, você deve fornecer as informações de assinatura do Microsoft Azure que deseja usar para este pod.

4 Especificar as informações de configuração do pod

Na etapa de Configuração do Pod do assistente de implantação do pod, você deve especificar os detalhes, como nome do pod, e as informações de rede. Nessa etapa, você também pode optar por fazer com que o processo de implantação crie um locatário do Workspace ONE Access.

5 Especificar a configuração de gateway do pod do Horizon Cloud

Nessa etapa do assistente, especifique as informações necessárias para implantar o pod com um configurado. Unified Access Gateway fornece o ambiente de gateway para um pod implantado no Microsoft Azure. Ao implantar o novo pod, você pode optar por ter uma configuração gateway interno ou externo ou ambos os tipos no mesmo pod. Você também pode implantar o pod sem qualquer configuração de gateway e decidir adicionar uma mais tarde após a implantação do pod. Por padrão, quando essa etapa do assistente é exibida, a configuração gateway externo é selecionada.

6 Validar e Avançar, e iniciar o processo de implantação do pod

Depois de clicar em Validar e Avançar, o sistema verifica seus valores especificados. Se tudo for validado, o assistente exibirá um resumo das informações para análise. Em seguida, você pode iniciar o processo de implantação.


VMware, Inc. 164

Pré-requisitos para executar o assistente de implantação de pod

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.






Pré-requisitos para todas as implantações

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

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


VMware, Inc. 165



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


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

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

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

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

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


n 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


VMware, Inc. 166



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.

n 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 ao criar um tenant da nuvem do Workspace ONE Access durante a implantação do pod

O assistente de implantação de pod tem uma opção para criar um tenant do Workspace ONE Access no serviço da nuvem do Workspace ONE Access como parte da implantação do pod. Com essa opção selecionada, o processo de implantação do pod cria e configura um tenant no serviço de nuvem do Workspace ONE Access. Depois de algumas etapas de configuração após a criação do tenant, você poderá usar esse tenant do Workspace ONE Access com os pods que implantar no Microsoft Azure usando a mesma conta do Horizon Cloud.

Se você planeja usar essa opção no assistente, certifique-se de saber o seguinte:

n O nome da região do centro de dados do Workspace ONE Access na qual você deseja que o locatário do Workspace ONE Access seja criado. No assistente de implantação de pod, você selecionará essa região do centro de dados em um menu suspenso.

n O nome que você deseja usar para o seu tenant do Workspace ONE Access.

n Um nome de usuário que deseja usar para a conta de administrador do tenant.

n Endereço de e-mail. O endereço de e-mail que você digita no assistente será associado à conta de administrador do tenant. O e-mail de boas-vindas é enviado para esse endereço de e-mail quando o sistema criou o tenant do Workspace ONE Access.


VMware, Inc. 167

Uma prática recomendada é usar o mesmo e-mail refletido na conta do My VMware associada a seu registro de conta do cliente do VMware Horizon Cloud Service on Microsoft Azure. Essa prática recomendada trata do e-mail de boas-vindas sobre o novo tenant indo para o mesmo endereço de e-mail aonde os e-mails do Horizon Cloud são enviados. Ou seja, ao fazer login no Console Administrativo para implantar seu primeiro pod, você faz login com um nome da My VMware na forma de [email protected], conforme descrito em Iniciar o assistente de implantação de pod. Usar o mesmo nome que o endereço de e-mail para o tenant do Workspace ONE Access pode facilitar a experiência inicial.

Pré-requisitos ao implantar com uma configuração do Unified Access Gateway

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

n O nome de domínio totalmente qualificado (FQDN) que seus usuários finais utilizarão para acessar o serviço. Se você pretende implantar o pod com tanto a configuração externa quanto a interna do Unified Access Gateway e deseja usar o mesmo FQDN para ambas, deverá determinar como rotear o tráfego do cliente do usuário final de entrada para o balanceador de carga adequado. Nesse cenário, você precisa configurar o roteamento de modo que o tráfego de cliente da Internet seja encaminhado para o balanceador de carga pública da Microsoft, e o tráfego de cliente da intranet seja roteado para o balanceador de carga interno da Microsoft.


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

n 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:

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


VMware, Inc. 168

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

n Se você estiver implantando com uma configuração do Unified Access Gateway externa e quiser desativar 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.

n A VNet para o gateway deve ser emparelhada com a VNet do pod.

n Verifique se as sub-redes necessárias foram criadas com antecedência e existem na VNet ou se os espaços de endereço CIDR que você planeja inserir no assistente já estão no espaço de endereço da VNet. Como as VNets são emparelhadas, o implantador não poderá expandir a VNet automaticamente se você inserir no CIDR do assistente espaços de endereço que ainda não estejam no espaço de endereço da VNet. Se isso acontecer, o processo de implantação apresentará falha.

Dica A boa prática é criar as sub-redes com antecedência. 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.

n Se estiver usando uma assinatura separada para o gateway externo, 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.


VMware, Inc. 169

n Se você estiver usando uma assinatura separada para o gateway externo e estiver planejando implantar o gateway em um grupo de recursos nomeado que você cria em vez de fazer com que o implantador crie automaticamente o grupo de recursos, verifique se criou esse grupo de recursos nessa assinatura. Você selecionará esse grupo de recursos por nome no assistente. Verifique também se você concedeu o acesso necessário a esse grupo de recursos para que o implantador opere nele, conforme descrito em Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure

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.

n Endereço IP ou nome DNS do servidor de autenticação

n O segredo compartilhado que é usado para criptografia e descriptografia em mensagens do protocolo do servidor de autenticação

n Números de porta de autenticação, geralmente a porta UDP 1812.

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


VMware, Inc. 170

Iniciar o assistente de implantação de pod

Ao implantar o primeiro pod no Microsoft Azure, você inicia o assistente de implantação do pod usando o recurso Adicionar Capacidade de Nuvem da página Introdução do Console Administrativo do Horizon Cloud.

Observação A autenticação de logon no Console Administrativo do Horizon Cloud baseia-se nas credenciais de conta do My VMware. Se o sistema de conta do My VMware estiver passando por uma falha do sistema e não puder obter as solicitações de autenticação, você não poderá fazer logon no Console Administrativo durante esse período de tempo. Se você encontrar problemas para fazer logon na primeira página de logon do Console Administrativo, 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.

Pré-requisitos

Verifique se você cumpriu com os pré-requisitos descritos em Pré-requisitos para executar o assistente de implantação de pod.

Procedimentos

1 Faça logon no Console Administrativo do Horizon Cloud em https://cloud.horizon.vmware.com usando as credenciais da sua conta do My VMware.

As credenciais de conta são o endereço de e-mail principal, como [email protected], e a senha definidos no perfil da conta.

Se você ainda não aceitou os termos de serviço do Horizon Cloud usando as credenciais do My VMware, uma caixa de notificação dos termos de serviço é exibida depois que você clica no botão Fazer logon. Aceite os termos de serviço para continuar.


VMware, Inc. 171

https://status.horizon.vmware.com


Após entrar, o Console de administração do Horizon Cloud é exibido. Quando não há pods existentes, o assistente de Introdução é exibido por padrão com a seção Capacidade expandida e a linha Adicionar Capacidade de Nuvem.

2 Na linha Adicionar Capacidade de Nuvem, clique em Adicionar.

Uma janela de seleção aparece, em que você pode selecionar a nuvem na qual deseja implantar o pod.

3 Clique em Selecionar para a nuvem do Microsoft Azure.

O assistente para Adicionar Capacidade de Nuvem é exibido em sua primeira etapa.


VMware, Inc. 172

4 Especifique a assinatura a ser usada para este pod seguindo as etapas em Especificar as informações de assinatura do Microsoft Azure para o novo pod.

Especificar as informações de assinatura do Microsoft Azure para o novo pod

Nesta etapa do assistente de implantação de pod, você deve fornecer as informações de assinatura do Microsoft Azure que deseja usar para este pod.

Pré-requisitos

n Verifique se você cumpriu com os pré-requisitos descritos em Implantar um pod do Horizon Cloud no Microsoft Azure.

n Para esta etapa do assistente, verifique se você tem as informações relacionadas à assinatura, conforme descrito em Informações relacionadas à assinatura para o assistente de implantação de pod do Horizon Cloud.

n Conclua as etapas no Iniciar o assistente de implantação de pod.


VMware, Inc. 173

Procedimentos

1 Na primeira etapa do assistente, especifique a assinatura a ser usada para este pod selecionando o nome de uma assinatura inserida anteriormente ou insira novas informações de assinatura.


VMware, Inc. 174

Se você selecionar uma assinatura existente, a etapa será preenchida com as informações da assinatura que foram inseridas no sistema.

Observação Você pode imaginar por que haveria informações de assinatura inseridas anteriormente, quando você está implantando um pod da página Introdução inicial. As informações de assinatura inseridas anteriormente são possíveis em situações, como os exemplos a seguir:

n Você inicia o assistente, insere as informações de assinatura nesta primeira etapa do assistente e clica em Adicionar para enviar as informações de assinatura para o sistema e continuar no assistente. Em seguida, na próxima etapa, você sai do assistente antes de concluir todas as etapas. Nessa situação, o sistema salvou as informações de assinatura que você inseriu nessa primeira etapa do assistente depois que clicou em Adicionar. Mesmo que você saia do assistente na próxima etapa, o sistema mantém essas informações de assinatura inseridas anteriormente.

n Você usou este registro de conta do cliente do Horizon Cloud antes, implantou os primeiros pods e os subsequentes para esse registro de conta e, em seguida, em algum momento, excluído esses pods. Quando você faz login novamente com as credenciais que estão associadas a seu registro de conta do cliente do Horizon Cloud, as informações de assinatura que foram inseridas anteriormente ainda estão associadas a esse registro do cliente e os nomes de assinatura anteriores são exibidos na lista suspensa.

Opção Descrição

Aplicar assinatura

Selecione o nome de uma assinatura inserida anteriormente ou selecione Adicionar nova para inserir as informações de uma nova assinatura.

Nome da assinatura

Ao fornecer informações de uma nova assinatura, digite um nome conhecido para que você possa identificar esta assinatura de outras assinaturas inseridas anteriormente.

O nome deve começar com uma letra e conter apenas letras, traços e números.

Ambiente Selecione o ambiente de nuvem associado à sua assinatura, por exemplo:

n Azure, para a nuvem padrão global do Microsoft Azure

n Azure - China, para o Microsoft Azure na nuvem da China

n Azure - Alemanha, para a nuvem do Microsoft Azure na Alemanha

n Azure - Governo dos EUA, para a nuvem do Governo dos EUA do Microsoft Azure

ID da assinatura Insira sua ID da assinatura da capacidade de nuvem (no formato UUID). Esta ID da assinatura deve ser válida para o ambiente selecionado. Para o Microsoft Azure, você pode obter este UUID na área de Assinaturas do portal do Microsoft Azure.

ID do diretório Digite sua ID do diretório do AD do Microsoft Azure (no formato UUID). Para o Microsoft Azure, é possível obter este UUID nas propriedades do Active Directory do Microsoft Azure no portal do Microsoft Azure.

ID de aplicativo Digite a ID do aplicativo (na forma de UUID) associada à entidade de serviço que você criou no portal Microsoft Azure. Criar um registro de aplicativo e sua entidade de serviço associada em seu Active Directory do Microsoft Active Directory é um pré-requisito.


VMware, Inc. 175

Opção Descrição

Chave do aplicativo

Digite o valor da chave para a chave de autenticação da entidade de serviço que você criou no Portal do Microsoft Azure. Criar esta chave é um pré-requisito.

Use uma assinatura diferente para o gateway externo

Ative essa alternância quando você quiser implantar uma configuração externa do Unified Access Gateway na própria assinatura, separada da assinatura do pod. O uso de assinaturas separadas para o gateway externo dá à sua organização a flexibilidade de atribuir a equipes separadas controle sobre essas assinaturas, dependendo da área de experiência delas. Isso permite um controle de acesso mais detalhado para o qual as pessoas da organização podem acessar os ativos do pod nos grupos de recursos de sua assinatura e para o qual as pessoas podem acessar os ativos do gateway.

Quando essa alternância está ativada, os campos para inserir as informações de assinatura do gateway são exibidos. Especifique as informações nesses campos como fez para a assinatura do pod.

Importante Nesta tela, você não pode excluir os valores de assinatura inseridos anteriormente associados a um determinado Nome da Assinatura. Mesmo que essa ocorrência seja rara, você pode imaginar uma situação onde você:

a Configure as partes relacionadas à assinatura no Microsoft Azure.

b Inicie o assistente para Adicionar Capacidade na Nuvem, insira os valores de assinatura na primeira etapa e o andamento ativado na próxima etapa do assistente.

c No entanto, após a leitura dos valores de rede solicitados na próxima etapa do assistente, saia desse assistente e abra uma nova guia do navegador para entrar no portal do Microsoft Azure e ajustar suas configurações de rede para atender aos pré-requisitos.

d Enquanto estiver no portal do Microsoft Azure, também opte por fazer um novo registro de aplicativo para ter um provedor de serviços com um nome diferente.

e Retorne para o navegador que tenha a página Como começar e reinicie o assistente para Adicionar Capacidade na Nuvem.

Nesse ponto, o nome da assinatura inserido anteriormente ainda está na lista suspensa Aplicar Assinatura. No entanto, se você selecionar esse nome, todos os campos serão pré-preenchidos com os valores anteriores, incluindo o ID do aplicativo antigo, e não haverá uma maneira de alterar os valores na tela, ou editar ou excluir esse nome da assinatura para começar com ele. Se isso acontecer para você, saia do assistente, reinicie o assistente e nesta primeira etapa, crie um novo nome de assinatura selecionando Adicionar Novo, insira os valores atuais que você deseja usar e siga em frente.

A seguinte captura de tela é um exemplo com essa etapa concluída.


VMware, Inc. 176

2 Prossiga para a próxima etapa do assistente.

Quando você clica no botão para prosseguir para a próxima etapa, o sistema verifica a validade de todos os valores especificados e se eles estão adequadamente relacionados entre si, como:

n O ID da assinatura especificado é válido no ambiente selecionado.

n O ID do diretório, o ID do aplicativo e a chave do aplicativo especificados são válidos nessa assinatura.

n A entidade de serviço do aplicativo para o ID de aplicativo especificado recebe a atribuição de uma função que permite todas as operações que o processo de implantação exige para o tipo de implantação que você está fazendo? Para obter uma descrição da entidade de serviço e seus requisitos de função, consulte o tópico Criar a entidade de serviço exigida por meio da criação de um registro de aplicativo e Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure.

Se você ver uma mensagem de erro sobre a correção de valores, pelo menos um dos valores será inválido por não existir em sua assinatura ou não ter um relacionamento confiável válido com outro valor. Esta é uma lista de algumas, embora não necessariamente todas, das situações que podem resultar nesta mensagem de erro:

n Se você tiver especificado um ID do Diretório que esteja em sua assinatura, mas tiver especificado um valor de ID do Aplicativo que esteja em um diretório diferente.

n Se a função atribuída da entidade de serviço especificada não permitir as operações exigidas pelo implantador do pod.

Importante Mais de uma parte pode ser inválida quando essa mensagem de erro é exibida. Se você ver essa mensagem de erro, verifique as informações relacionadas à assinatura obtidas e a configuração da entidade de serviço.


VMware, Inc. 177



3 Especifique os detalhes do pod e as informações de rede seguindo as etapas em Especificar as informações de configuração do pod.

Especificar as informações de configuração do pod

Na etapa de Configuração do Pod do assistente de implantação do pod, você deve especificar os detalhes, como nome do pod, e as informações de rede. Nessa etapa, você também pode optar por fazer com que o processo de implantação crie um locatário do Workspace ONE Access.

Cuidado Os endereços IP mencionados nessas etapas são exemplos. Você deve utilizar os intervalos de endereços que atendam às necessidades de sua organização. Para cada etapa que menciona um intervalo de endereço IP, substitua os que são aplicáveis para a sua organização.

Pré-requisitos


Se o processo de implantação for criar automaticamente as sub-redes necessárias, verifique se os intervalos de endereços CIDR que você planeja especificar nos campos do assistente para elas já não estão em uso por sub-redes existentes na sua VNet do Microsoft Azure.

Se você tiver criado sub-redes com antecedência para uso com esse pod, verifique se essas sub-redes não têm recursos anexados e se a sub-rede criada para uso com a sub-rede de gerenciamento tem o serviço Microsoft.SQL configurado como um endpoint de serviço para essa sub-rede. O assistente de implantação de pod validará que o serviço Microsoft.SQL está configurado como um endpoint de serviço na sub-rede de gerenciamento.

Cuidado Essas sub-redes criadas na sua VNet para a implantação do pod devem estar vazias. Você pode criar as sub-redes antes de implantar o pod, mas não coloque recursos nelas nem use qualquer um dos endereços IP. Se um endereço IP já estiver em uso nas sub-redes, a implantação do pod poderá falhar.

Procedimentos

1 Nesta etapa do assistente, forneça detalhes sobre o pod e as informações de rede necessárias.

A seguinte captura de tela é um exemplo da etapa quando é exibida inicialmente.


VMware, Inc. 178

Opção Descrição

Nome do Pod Insira um nome conhecido para esse pod. Este nome é utilizado no Console Administrativo para identificar este pod entre seus outros pods.

Localização Selecione um nome de cidade existente ou clique em Adicionar para especificar uma nova cidade.

O sistema agrupa seus pods de acordo com o nome da cidade e os exibe no mapa Área de Cobertura Global do Horizon da página Painel do Console Administrativo.

Quando você clicar em Adicionar, comece digitando o nome de uma cidade. O sistema exibe automaticamente nomes de cidades do mundo em sua tabela de pesquisa de geografia de back-end que corresponde aos caracteres inseridos, e você pode escolher uma cidade nessa lista.

Observação Você deve selecionar uma cidade na lista de preenchimento automático do sistema.


VMware, Inc. 179

Opção Descrição

Região do Microsoft Azure

Selecione a região geográfica física do Microsoft Azure na qual você deseja que o pod seja implantado. As regiões disponíveis são determinadas pelo ambiente do Microsoft Azure selecionado anteriormente.

Considere escolher a região com base na proximidade aos usuários finais que você pretende atender com esse pod. Uma maior proximidade forneceria a menor latência.


Descrição Opcional: insira uma descrição para esse pod.

Alta Disponibilidade

Habilite essa alternância para implantar um pod que esteja configurado com alta disponibilidade. Para obter detalhes sobre alta disponibilidade e o pod, consulte o Guia de Administração.Se você desativar essa alternância, o pod será implantado sem alta disponibilidade.

Rede virtual Selecione uma rede virtual na lista.

Apenas as redes virtuais (VNets) que existem na região selecionada no campo Região do Microsoft Azure são mostradas aqui. Você já deve ter criado a VNet que deseja usar nessa região na sua assinatura do Microsoft Azure.

Usar Sub-rede Existente

Ative essa alternância se você tiver criado sub-redes com antecedência para atender aos requisitos de sub-redes do pod. Quando essa opção está definida como Sim, os campos do assistente para especificar sub-redes se transformam em menus de seleção suspensos.

Importante O assistente não oferece suporte ao uso de uma sub-rede existente para uma das sub-redes necessárias e à especificação de endereços CIDR para as outras sub-redes necessárias. Quando essa opção está definida como Sim, você deve selecionar entre as sub-redes existentes para todas as sub-redes necessárias do pod.

Sub-rede de GerenciamentoSub-rede de gerenciamento (CIDR)

Quando a opção Usar Sub-Rede Existente está ativada, a Sub-Rede de Gerenciamento lista as sub-redes disponíveis na VNet selecionada para Rede Virtual. Selecione a sub-rede existente que você deseja usar para a sub-rede de gerenciamento do pod.

Importante n Selecione uma sub-rede que tenha o serviço Microsoft.SQL configurado como um endpoint de

serviço para essa sub-rede. Esse endpoint de serviço é compatível com a comunicação necessária entre as VMs de gerenciador de pods e o Banco de Dados do Microsoft Azure para PostgreSQL do pod pela sub-rede de gerenciamento.

Selecione uma sub-rede vazia que não tenha outros recursos anexados a ela. Se a sub-rede não estiver vazia, poderão ocorrer resultados inesperados durante o processo de implantação ou as operações do pod.

Quando a opção Usar Sub-rede Existente estiver desativada, em Sub-rede de Gerenciamento (CIDR), insira um intervalo de endereços de sub-rede (na notação CIDR) para o implantador criar uma sub-rede à qual as instâncias do pod e do Unified Access Gateway serão conectadas, como 192.168.8.0/27. Para a sub-rede de gerenciamento, é necessário um CIDR de pelo menos /27.

Cuidado Quando você não selecionar a opção do assistente para usar sub-redes existentes, a sub-rede ainda não deve existir no seu ambiente do Microsoft Azure. Se ela já existir, você receberá um erro ao tentar prosseguir para a próxima etapa do assistente.


VMware, Inc. 180


Opção Descrição

Sub-rede de Área de TrabalhoSub-rede da área de trabalho (CIDR)

Quando a opção Usar Sub-Rede Existente está ativada, a Sub-Rede de Área de Trabalho lista as sub-redes disponíveis na VNet selecionada para Rede Virtual. Selecione a sub-rede existente que você deseja usar para a sub-rede de tenant de área de trabalho do pod.

Importante Selecione uma sub-rede vazia que não tenha outros recursos anexados a ela. Se a sub-rede não estiver vazia, poderão ocorrer resultados inesperados durante o processo de implantação ou as operações do pod.

Quando a opção Usar a Sub-Rede Existente estiver desativada, na Sub-Rede da Área de Trabalho (CIDR), digite um intervalo de endereços de sub-rede (na notação CIDR) para o implantador criar uma sub-rede à qual todas as áreas de trabalho VDI e VMs RDSH de farm desse pod para aplicativos e áreas de trabalho remotas dos usuários finais serão conectadas, como 192.168.12.0/22. Para a sub-rede de área de trabalho, um CIDR de pelo menos /27 é necessário, e um CIDR de /22 é recomendado.

Importante Certifique-se de que o intervalo que você inserir seja grande o suficiente para permitir a acomodação do número de áreas de trabalho que você pretende que esse pod forneça. Essa sub-rede de área de trabalho não poderá ser estendida depois que o pod for implantado.

Cuidado Quando você não selecionar a opção do assistente para usar sub-redes existentes, a sub-rede ainda não deve existir no seu ambiente do Microsoft Azure. Se ela já existir, você receberá um erro ao tentar prosseguir para a próxima etapa do assistente.


VMware, Inc. 181

Opção Descrição

Servidores NTP Insira a lista de servidores NTP que você deseja usar para a sincronização de horário, separada por vírgula.

Um servidor NTP inserido aqui pode ser um servidor NTP público ou seu próprio servidor NTP que você configurou para fornecer a sincronização de horário. Os servidores NTP especificados aqui devem ser acessíveis pela rede virtual que você selecionou no campo Rede Virtual para o pod a ser usado. Nesse campo, você pode especificar cada servidor NTP por meio de seu endereço IP numérico ou seu nome de domínio. Quando você fornece um nome de domínio nesse campo em vez de um endereço IP numérico, deve garantir que o DNS configurado para sua rede virtual possa resolver o nome especificado.

Exemplos de nomes de domínio do servidor NTP públicos incluem time.windows.com, us.pool.ntp.org, time.google.com.

Usar Proxy Se você precisar de um proxy para conectividade de saída à Internet, ative essa alternância e preencha os campos exibidos associados.

O implantador de pod exige acesso de saída à Internet para baixar o software para o ambiente de nuvem do Microsoft Azure e conectar-se novamente à camada de controle de nuvem do Horizon Cloud de forma segura. Para ativar o pod a ser usado na sua configuração de proxy, você deve fornecer as seguintes informações depois de ativar a alternância.

n Proxy (obrigatório): digite o nome do host ou endereço IP para o servidor proxy.

n Porta (obrigatória): digite o número da porta especificado na configuração do servidor proxy.

Se sua configuração do servidor proxy exigir um nome de usuário e senha para autenticação, também forneça essas credenciais.

A captura de tela a seguir é um exemplo com essa etapa concluída quando o processo de implantação cria automaticamente as sub-redes e com a Alta Disponibilidade ativada. Neste exemplo, um proxy não era necessário para atender ao requisito de conectividade de Internet de saída.


VMware, Inc. 182

2 Na seção Workspace ONE Access, se quiser que o processo de implantação do pod crie um tenant de nuvem do Workspace ONE Access, ative a opção Tenant do Workspace ONE Access e preencha os campos exibidos associados.

Importante O sistema pode criar o tenant do Workspace ONE Access nesse fluxo de trabalho de criação do pod. Nessa versão, você não pode editar um pod existente para que o sistema crie o tenant do Workspace ONE Access para você mais tarde. Se você criar o pod com a opção de seção ativada e, em seguida, quiser usar um tenant do Workspace ONE Access com os pods do Horizon Cloud nesta conta do cliente, deverá obter seu tenant assinando o ambiente hospedado em nuvem do Workspace ONE Access.

Opção Descrição

Região do Centro de Dados

Selecione a região do Workspace ONE Access para o novo locatário.

Nome do Locatário

Digite um nome para o locatário.


VMware, Inc. 183

Opção Descrição

Nome do usuário Digite um nome a ser usado para a conta de administrador do locatário do Workspace ONE Access.

E-mail Digite o endereço de e-mail a ser usado para a conta de administrador em Nome de usuário. O e-mail de boas-vindas é enviado para esse endereço de e-mail quando o sistema criou o tenant do Workspace ONE Access.

Uma prática recomendada é usar o mesmo e-mail que é um dos endereços de e-mail de conta do My VMware listados como Administrador do Cliente na área Contas do My VMware da tela Introdução, o registro de conta de cliente do Horizon Cloud como proprietário deste ambiente de tenant do Horizon Cloud. Essa prática recomendada trata do e-mail de boas-vindas sobre o novo tenant indo para o mesmo endereço de e-mail aonde os e-mails do Horizon Cloud são enviados. Ou seja, ao fazer login no Console Administrativo para implantar seu primeiro pod, você faz login com um nome da My VMware na forma de [email protected], conforme descrito em Iniciar o assistente de implantação de pod. Usar o mesmo nome que o endereço de e-mail para o tenant do Workspace ONE Access pode facilitar a experiência inicial.

A captura de tela a seguir mostra a seção com os campos preenchidos.

Observação Depois que o pod for implantado, outras etapas serão necessárias para integrar o novo tenant do Workspace ONE Access ao seu pod. Para conhecer essas etapas subsequentes, consulte o Guia de administração do Horizon Cloud e seus tópicos e subtópicos sobre como Integrar um pod do Horizon Cloud com um ambiente do Workspace ONE Access. O implantador do pod não implanta o appliance do conector do Workspace ONE Access que é necessário para o pod se integrar ao serviço do Workspace ONE Access.

3 Vá para a próxima etapa clicando em Avançar.

4 Especifique detalhes para o pod ter uma configuração do Unified Access Gateway, seguindo as etapas em Especificar a configuração de gateway do pod do Horizon Cloud. Para que os usuários finais possam acessar suas áreas de trabalho e aplicativos remotos pela Internet, uma configuração externa do Unified Access Gateway é necessária.

Especificar a configuração de gateway do pod do Horizon Cloud

Nessa etapa do assistente, especifique as informações necessárias para implantar o pod com um configurado. Unified Access Gateway fornece o ambiente de gateway para um pod implantado no Microsoft Azure. Ao implantar o novo pod, você pode optar por ter uma configuração gateway interno ou externo ou ambos os tipos no mesmo pod. Você também pode implantar o pod sem qualquer


VMware, Inc. 184

configuração de gateway e decidir adicionar uma mais tarde após a implantação do pod. Por padrão, quando essa etapa do assistente é exibida, a configuração gateway externo é selecionada.

Configuração de gateway externo

A configuração externa do Unified Access Gateway oferece a capacidade de fornecer acesso a áreas de trabalho e aplicativos para usuários finais localizados fora da sua rede corporativa. Quando o pod tem a configuração gateway externo, o pod inclui um recurso de balanceador de carga do Azure e as instâncias do Unified Access Gateway para fornecer esse acesso. Nesse caso, as instâncias têm três NICs cada: uma NIC na sub-rede de gerenciamento, uma NIC na sub-rede de área de trabalho e uma NIC na sub-rede DMZ. No assistente de implantação, você tem a opção de especificar o tipo de balanceamento de carga como privado ou público, dependendo se deseja um endereço IP privado ou um endereço IP público para o balanceador de carga. Se você desativar a alternância de IP público, deverá especificar o endereço IP mapeado no servidor DNS para o FQDN que os clientes do Horizon dos usuários finais usarão para conexões PCoIP com o gateway.

Para uma configuração de gateway externo, você também tem a opção de implantar a configuração em uma VNet separada da do pod. O VNets deve ser emparelhado. Esse tipo de configuração oferece a capacidade de implantar o pod em topologias de rede mais complexas no Microsoft Azure, como uma Topologia de Rede hub-spoke.

Observação Se você ativou a alternância que determina que o gateway externo use a própria assinatura na primeira etapa do assistente, deverá implantar o gateway externo na VNet dele, a VNet associada a essa assinatura. Se você ativou essa alternância, poderá, opcionalmente, selecionar um grupo de recursos existente nessa assinatura para os recursos do gateway externo. Você deve ter preparado esse grupo de recursos com antecedência para que possa selecioná-lo nessa etapa do assistente.

Configuração de gateway interno

A configuração interna do Unified Access Gateway permite que os usuários finais localizados na sua rede corporativa tenham conexões confiáveis via HTML Access (Blast) com suas áreas de trabalho e aplicativos. Se o pod não estiver definido com essa configuração gateway interno, os usuários finais na sua rede corporativa verão o erro de certificado não confiável padrão do navegador quando usarem seus navegadores para estabelecerem conexões via HTML Access (Blast) às suas áreas de trabalho e aos seus aplicativos. Quando o pod tem essa configuração de gateway interno, o pod inclui um recurso de balanceador de carga do


VMware, Inc. 185





Azure e as instâncias do Unified Access Gateway para fornecer esse acesso. Nesse caso, as instâncias têm duas NICs cada: uma NIC na sub-rede de gerenciamento e uma NIC na sub-rede de área de trabalho. Por padrão, o tipo de balanceamento de carga desse gateway é privado.

A seguinte captura de tela é um exemplo da etapa quando é exibida inicialmente. Alguns controles são exibidos somente quando você seleciona na primeira etapa do assistente o uso de uma assinatura diferente para a configuração externa de gateway do Unified Access Gateway.


VMware, Inc. 186



VMware, Inc. 187

Pré-requisitos


Importante Para concluir esta etapa, você deve ter o nome de domínio totalmente qualificado (FQDN) necessário que os usuários finais usarão para acessar o serviço e ter um certificado SSL assinado (no formato PEM) baseado neste FQDN. O certificado deve ser assinado por uma autoridade de certificação confiável. Um único arquivo PEM deve conter a cadeia de certificados inteira e a chave privada: certificado SSL, certificados intermediários, certificado da CA raiz, chave privada. Para obter detalhes, consulte Converter um arquivo de certificado para o formato PEM necessário para a implantação do pod.

Confirme que todos os certificados na cadeia de certificados têm intervalos de tempo válidos. Se qualquer certificado na cadeia tiver expirado. falhas inesperadas poderão ocorrer mais tarde no processo de integração de pod.

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.

Procedimentos

1 Se quiser a configuração gateway externo, preencha os campos na seção UAG Externo.

Opção Descrição

Ativar UAG Externo?

Controla se o pod tem uma configuração de gateway externo. A configuração externa fornece acesso a áreas de trabalho e aplicativos para usuários localizados fora da sua rede corporativa. O pod inclui um recurso do balanceador de carga do Azure e instâncias do Unified Access Gateway para fornecer esse acesso.

Observação É recomendável manter a configuração que vem ativada por padrão.

Quando essa alternância é desativada, os clientes devem se conectar por meio do Workspace ONE Access integrado ao pod ou diretamente ao balanceador de carga dos gerenciadores de pod ou se conectar por meio de uma configuração de gateway interno. No caso dos clientes que se conectam pelo Workspace ONE Access integrado ao pod ou diretamente, algumas etapas pós-implantação são necessárias. Nesse caso, após a implantação do pod, consulte as informações em Guia de administração do Horizon Cloud sobre o upload de certificados SSL para o pod.

FQDN Digite seu nome de domínio completo (FQDN), como ourOrg.example.com, que seus usuários finais utilizarão para acessar o serviço. Você deve ser o proprietário desse nome de domínio e ter um certificado no formato PEM que possa validar esse FQDN.


Endereços DNS

Opcionalmente, insira endereços para servidores DNS adicionais que o Unified Access Gateway pode usar para a resolução de nomes, separados por vírgulas. Ao definir essa configuração externa do Unified Access Gateway para usar a autenticação de dois fatores com o servidor RADIUS local, você deve especificar o endereço de um servidor DNS que possa resolver o nome do seu servidor RADIUS local.

Como descrito nos Pré-requisitos para todas as implantações, um servidor DNS deve ser configurado internamente em sua assinatura e configurado para fornecer uma resolução de nome externa. As instâncias do Unified Access Gateway usam esse servidor DNS por padrão. Se você especificar endereços nesse campo, as instâncias do Unified Access Gateway implantadas usarão os endereços, além do servidor DNS de pré-requisito que você configurou na rede virtual da sua assinatura.


VMware, Inc. 188

Opção Descrição

Rotas Opcionalmente, especifique as rotas personalizadas para gateways adicionais que você deseja que as instâncias implantadas do Unified Access Gateway usem para resolver o roteamento de rede para o acesso do usuário final. As rotas especificadas são usadas para permitir que o Unified Access Gateway resolva o roteamento de rede, como servidores RADIUS para autenticação de dois fatores.

Ao configurar esse pod para usar a autenticação de dois fatores com um servidor RADIUS local, você deve inserir a rota correta que as instâncias do Unified Access Gateway podem usar para acessar o servidor RADIUS. Por exemplo, se o servidor RADIUS local usar 10.10.60.20 como endereço IP, você deverá inserir 10.10.60.0/24 e seu endereço de gateway de rota padrão como uma rota personalizada. Você obtém seu endereço de gateway de rota padrão na configuração de Express Route ou de VPN que está usando para esse ambiente.

Especifique as rotas personalizadas como uma lista separada por vírgulas no formato ipv4-network-address/bits ipv4-gateway-address. Por exemplo: 192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2.

Certificado Carregue o certificado no formato PEM que o Unified Access Gateway usará para permitir que os clientes confiem nas conexões com as instâncias do Unified Access Gateway que estão sendo executadas no Microsoft Azure. O certificado deve ser baseado no FQDN inserido e ser assinado por uma autoridade de certificação confiável. O arquivo PEM deve conter a cadeia de certificados inteira e a chave privada: certificado SSL, certificados intermediários, certificado da CA raiz, chave privada.

Especifique as configurações para o balanceador de carga da Microsoft desse gateway.

Opção Descrição

Habilitar IP público?

Controla se o tipo de balanceamento de carga desse gateway é configurado como privado ou público. Se a opção estiver ativada, o recurso do balanceador de carga do Microsoft Azure implantado será configurado com um endereço IP público. Se a opção estiver desativada, o recurso do balanceador de carga do Microsoft Azure será configurado com um endereço IP privado.

Importante Nesta versão, você não poderá alterar posteriormente o tipo de balanceamento de carga do gateway externo de público para privado, ou de privado para público. A única maneira de fazer essa alteração seria excluir toda a configuração do gateway do pod implantado e editar o pod para adicioná-lo de volta com a configuração oposta.

Se você desativar essa alternância, o campo IP Público do FQDN do Horizon será exibido.

IP Público do FQDN do Horizon

Se optar por não configurar o balanceador de carga implantado do Microsoft Azure com um IP público, deverá fornecer o endereço IP que você está mapeando no seu DNS para o FQDN que os clientes do Horizon dos usuários finais usarão para conexões PCoIP com o gateway. O implantador vai configurar esse endereço IP nas definições de configuração do Unified Access Gateway.

Tipo Selecione o código SKU a ser usado para o balanceador de carga do Microsoft Azure que o implantador usará para essa configuração de gateway externo. As opções são Padrão ou Básico. Para uma comparação dos dois códigos SKU, consulte o tópico de documentação do Microsoft Azure Comparação de SKU do Balanceador de Carga.

Especifique as configurações de rede do gateway externo.


VMware, Inc. 189



Opção Descrição

Usar uma Rede Virtual Diferente

Essa alternância controla se o gateway externo será implantado na própria VNet, separada da do pod.

As seguintes linhas descrevem os diferentes casos.

Observação Quando você especifica a utilização de uma assinatura diferente para o gateway externo na primeira etapa do assistente, essa alternância é ativada por padrão. Você deve escolher uma VNet para o gateway nessa situação.

Usar uma Rede Virtual Diferente — Desativada

Quando a alternância estiver desativada, o gateway externo será implantado na VNet do pod. Nesse caso, você deve especificar a sub-rede da zona desmilitarizada.

n Sub-Rede da Zona Desmilitarizada Quando a opção Usar a Sub-Rede Existente estiver ativada na etapa do assistente de configuração de pod, a Sub-Rede da Zona Desmilitarizada lista as sub-redes disponíveis na VNet selecionada para Rede Virtual. Selecione a sub-rede existente que você deseja usar para a sub-rede DMZ do pod.

Importante Selecione uma sub-rede vazia que não tenha outros recursos anexados a ela. Se a sub-rede não estiver vazia, poderão ocorrer resultados inesperados durante o processo de implantação ou as operações do pod.

n Sub-rede da Zona Desmilitarizada (CIDR) - Quando a opção Usar a Sub-Rede Existente estiver desativada na etapa anterior do assistente, insira a sub-rede (na notação CIDR) da rede DMZ (zona desmilitarizada) que será configurada para conectar as instâncias do Unified Access Gateway ao balanceador de carga público do Microsoft Azure do gateway.

Usar uma Rede Virtual Diferente — Ativada

Quando a alternância estiver ativada, o gateway externo será implantado na própria VNet. Nesse caso, você deve selecionar a VNet a ser usada e, em seguida, especificar as três sub-redes necessárias. Ative a alternância Usar a Sub-Rede Existente para selecionar dentre as sub-redes que você criou com antecedência na VNet especificada. Caso contrário, especifique as sub-redes na notação CIDR.

Importante Selecione sub-redes vazias que não tenham outros recursos anexados a elas. Se as sub-redes não estiverem vazias, poderão ocorrer resultados inesperados durante o processo de implantação ou as operações do pod.

Nesse caso, a VNet do gateway e a VNet do pod são emparelhadas. A boa prática é criar as sub-redes com antecedência e não usar as entradas CIDR aqui. Consulte 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.

n Sub-rede de gerenciamento - Especifique a sub-rede a ser usada para a sub-rede de gerenciamento do gateway. É necessário um CIDR de pelo menos /27. Essa sub-rede deve ter o serviço Microsoft.SQL configurado como um endpoint de serviço.

n Sub-rede de back-end - Especifique a sub-rede a ser usada para a sub-rede de back-end do gateway. É necessário um CIDR de pelo menos /27.

n Sub-rede de front-end - Especifique a sub-rede para a sub-rede de front-end que será configurada para conectar as instâncias do Unified Access Gateway ao balanceador de carga público do Microsoft Azure do gateway.

2 (Opcional) Na seção UAG Externo, configure opcionalmente a autenticação de dois fatores para o Unified Access Gateway externo.

Conclua as etapas no Especificar o recurso de autenticação de dois fatores para o novo pod.


VMware, Inc. 190

3 (Opcional) Na seção Implantação, use a alternância para selecionar opcionalmente um grupo de recursos existente no qual você deseja que o implantador implante os recursos para a configuração externa do Unified Access Gateway.

Essa alternância é exibida quando você especifica a utilização de uma assinatura diferente para o gateway externo na primeira etapa do assistente. Quando você habilita a alternância, é exibido um campo no qual você pode procurar e selecionar o grupo de recursos.

4 Na seção UAG Interno, se quiser a configuração interna do Unified Access Gateway, ative a opção Ativar UAG Interno? ative a alternância e preencha os campos exibidos.

Opção Descrição

Ativar UAG Interno?

Controla se o pod tem uma configuração de gateway interno. A configuração interna fornece acesso confiável a áreas de trabalho e aplicativos para conexões via HTML Access (Blast) para usuários localizados na sua rede corporativa. O pod inclui um recurso do balanceador de carga do Azure e instâncias do Unified Access Gateway para fornecer esse acesso. Por padrão, o tipo de balanceamento de carga desse gateway é privado. O balanceador de carga é configurado com um endereço IP privado.

FQDN Digite seu nome de domínio completo (FQDN), como ourOrg.example.com, que seus usuários finais utilizarão para acessar o serviço. Você deve ser o proprietário desse nome de domínio e ter um certificado no formato PEM que possa validar esse FQDN.


Endereços DNS

Opcionalmente, insira endereços para servidores DNS adicionais que o Unified Access Gateway pode usar para a resolução de nomes, separados por vírgulas. Ao definir essa configuração interna do Unified Access Gateway para usar a autenticação de dois fatores com o servidor RADIUS local, você deve especificar o endereço de um servidor DNS que possa resolver o nome do seu servidor RADIUS local.

Como descrito nos Pré-requisitos para todas as implantações, um servidor DNS deve ser configurado internamente na sua assinatura e configurado para fornecer uma resolução de nome. As instâncias do Unified Access Gateway usam esse servidor DNS por padrão. Se você especificar endereços nesse campo, as instâncias do Unified Access Gateway implantadas usarão os endereços, além do servidor DNS de pré-requisito que você configurou na rede virtual da sua assinatura.

Rotas Opcionalmente, especifique as rotas personalizadas para gateways adicionais que você deseja que as instâncias implantadas do Unified Access Gateway usem para resolver o roteamento de rede para o acesso do usuário final. As rotas especificadas são usadas para permitir que o Unified Access Gateway resolva o roteamento de rede, como servidores RADIUS para autenticação de dois fatores.

Ao configurar esse pod para usar a autenticação de dois fatores com um servidor RADIUS local, você deve inserir a rota correta que as instâncias do Unified Access Gateway podem usar para acessar o servidor RADIUS. Por exemplo, se o servidor RADIUS local usar 10.10.60.20 como endereço IP, você deverá inserir 10.10.60.0/24 e seu endereço de gateway de rota padrão como uma rota personalizada. Você obtém seu endereço de gateway de rota padrão na configuração de Express Route ou de VPN que está usando para esse ambiente.



VMware, Inc. 191

Opção Descrição

Certificado Carregue o certificado no formato PEM que o Unified Access Gateway usará para permitir que os clientes confiem nas conexões com as instâncias do Unified Access Gateway que estão sendo executadas no Microsoft Azure. O certificado deve ser baseado no FQDN inserido e ser assinado por uma autoridade de certificação confiável. O arquivo PEM deve conter a cadeia de certificados inteira e a chave privada: certificado SSL, certificados intermediários, certificado da CA raiz, chave privada.

Tipo de Balanceador de Carga

Selecione o código SKU a ser usado para o balanceador de carga do Microsoft Azure que o implantador usará para essa configuração de gateway externo. As opções são Padrão ou Básico. Para uma comparação dos dois códigos SKU, consulte o tópico de documentação do Microsoft Azure Comparação de SKU do Balanceador de Carga.

5 (Opcional) Na seção UAG Interno, configure opcionalmente a autenticação de dois fatores para o Unified Access Gateway interno.

Conclua as etapas no Especificar o recurso de autenticação de dois fatores para o novo pod.

Resultados

Quando você tiver fornecido as informações necessárias associadas às opções selecionadas, poderá clicar em Validar e Avançar para continuar até a etapa final do assistente. Consulte Validar e Avançar, e iniciar o processo de implantação do pod. Especificar o recurso de autenticação de dois fatores para o novo podNa etapa do assistente de implantação do pod para especificar suas configurações do Unified Access Gateway, você também pode especificar o uso da autenticação de dois fatores para o acesso de seus usuários finais a suas áreas de trabalho e aplicativos por meio dessas configurações de gateway. Você pode especificar esses detalhes de autenticação de dois fatores depois de fornecer os detalhes da configuração do Unified Access Gateway.

Pré-requisitos


Para a configuração do Unified Access Gateway interna ou externa para a qual você estiver inserindo os detalhes da autenticação de dois fatores, verifique se você concluiu os campos para a configuração do Unified Access Gateway no assistente, conforme descrito em Especificar a configuração de gateway do pod do Horizon Cloud. Ao configurar a autenticação de dois fatores para um servidor de autenticação local, você também fornece informações nos seguintes campos para que as instâncias do Unified Access Gateway possam resolver o roteamento para esse servidor local.


VMware, Inc. 192



Opção Descrição

Endereços DNS

Especifique um ou mais endereços de servidores DNS que podem resolver o nome do seu servidor de autenticação local.

Rotas Especifique uma ou mais rotas personalizadas que permitem que as instâncias do Unified Access Gateway do pod resolvam o roteamento de rede para seu servidor de autenticação local.

Por exemplo, se você tiver um servidor RADIUS local que usa 10.10.60.20 como endereço IP, deverá usar 10.10.60.0/24 e seu endereço de gateway de rota padrão como uma rota personalizada. Você obtém seu endereço de gateway de rota padrão na configuração de Express Route ou de VPN que está usando para esse ambiente.


Verifique se você tem as seguintes informações usadas na configuração do seu servidor de autenticação, para que possa fornecê-las nos campos apropriados do assistente de implantação do pod. Se você tiver um servidor primário e um secundário, obtenha as informações para cada um deles.

n Endereço IP ou nome DNS do servidor de autenticação

n O segredo compartilhado que é usado para criptografia e descriptografia em mensagens do protocolo do servidor de autenticação

n Números de porta de autenticação, geralmente a porta UDP 1812.

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

Procedimentos

1 Alterne para a opção Ativar a Autenticação de 2 Fatores.

Quando a opção de alternância está ativada, o assistente exibe os campos de configuração adicionais. Use a barra de rolagem para acessar todos os campos.

A seguinte captura de tela é um exemplo do que aparecerá após você ativar o botão de alternância na seção UAG Externo.


VMware, Inc. 193

2 Selecione o método de autenticação de dois fatores na lista suspensa.

Nesta versão, há suporte para autenticação RADIUS.

3 No campo Nome, digite um nome de identificação para esta configuração.

4 Na seção Propriedades, especifique os detalhes relacionados à interação dos usuários finais com a tela de logon, que eles usarão para autenticar para obter acesso.

Opção Descrição

Nome de Exibição

Você pode deixar este campo em branco. Embora esse campo seja visível no assistente, ele define apenas um nome interno no Unified Access Gateway. Esse nome não é usado pelos clientes do Horizon.

Dica de Exibição

Opcionalmente, insira uma cadeia de texto que será exibida para os usuários finais na mensagem na tela de login do cliente final quando solicitar ao usuário o código de acesso e a senha RADIUS. A dica especificada aparece para o usuário final como Enter your DisplayHint user name and passcode, em que DisplayHint é o texto que você especifica neste campo.

Essa dica pode ajudar a orientar os usuários a inserir o código de acesso correto do RADIUS. Como exemplo, especificando uma frase como Exemplo de nome de usuário e senha de domínio da empresa abaixo resultaria em um aviso para o usuário final que diz Enter your Example Company user name and domain password below for user name and passcode.

Sufixo da ID do Nome

Essa configuração é usada em cenários SAML, onde seu pod está configurado para usar o TrueSSO para Single Sign-on. Opcionalmente, forneça uma cadeia de caracteres que o sistema anexará ao nome de usuário da declaração SAML enviado ao agente. Por exemplo, se o nome de usuário for inserido como user1 na tela de logon e um sufixo de ID de nome de @example.com for especificado aqui, o sistema enviará um nome de usuário de declaração SAML de [email protected] ao agente.


VMware, Inc. 194

Opção Descrição

Número de Iterações

Insira o número máximo de tentativas de autenticação com falha que um usuário tem permissão ao tentar fazer logon usando o sistema do RADIUS.

Manter o nome de usuário

Ative a opção de alternância para manter o nome de usuário do RADIUS durante a autenticação no Horizon Cloud. Quando ativado:

n O usuário deve ter as mesmas credenciais de nome de usuário para o RADIUS que para a autenticação do Active Directory no Horizon Cloud.

n O usuário não pode alterar o nome de usuário na tela de logon.

Se esse botão de alternância estiver desativado, o usuário poderá digitar outro nome de usuário na tela de logon.

Observação Para o relacionamento entre a habilitação de Manter Nome de Usuário e as configurações de segurança do domínio em Horizon Cloud, consulte o tópico Configurações de segurança do domínio na página Configurações Gerais no Guia de administração do Horizon Cloud.

5 Na seção Servidor Primário, especifique os detalhes sobre o servidor de autenticação.

Opção Descrição

Nome do host/Endereço IP

Insira o nome DNS ou o endereço IP do servidor de autenticação.

Segredo compartilhado

Insira o segredo da comunicação com o servidor de autenticação. O valor deve ser idêntico ao valor configurado do servidor.

Porta de autenticação Especifique a porta UDP configurada no servidor de autenticação para enviar ou receber tráfego de autenticação. O padrão é 1812.

Porta de contabilização

Opcionalmente, especifique a porta UDP configurada no servidor de autenticação para enviar ou receber tráfego contábil. O padrão é 1813.

Mecanismo Selecione o protocolo de autenticação que é compatível com o servidor de autenticação especificado e que você deseja que seja usado pelo pod implantado.

Tempo limite do servidor

Especifique o número de segundos durante os quais o pod deverá esperar por uma resposta do servidor de autenticação. Após esse número de segundos, uma nova tentativa será enviada se o servidor não responder.

Número Máximo de Novas Tentativas

Especifique o número máximo de vezes que o pod deve enviar novamente as solicitações com falha para o servidor de autenticação.

Prefixo do território Opcionalmente, forneça uma cadeia de caracteres que o sistema colocará no começo do nome do usuário quando o nome for enviado ao servidor de autenticação. A localização da conta do usuário é chamada território.

Por exemplo, se o nome de usuário for inserido como user1 na tela de logon e um prefixo de território de DOMAIN-A\ for especificado aqui, o sistema enviará DOMAIN-A\user1 ao servidor de autenticação. Se você não especificar um prefixo de território, somente o nome de usuário inserido será enviado.

Sufixo do território Opcionalmente, forneça uma cadeia de caracteres que o sistema anexará ao nome de usuário quando o nome for enviado ao servidor de autenticação. Por exemplo, se o nome de usuário for inserido como user1 na tela de logon e um sufixo de território de @example.com for especificado aqui, o sistema enviará [email protected] ao servidor de autenticação.


VMware, Inc. 195

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-FE87529D-CF7F-464D-B74F-A21F19A22F54.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-FE87529D-CF7F-464D-B74F-A21F19A22F54.html

6 (Opcional) Na seção Servidor Secundário, opcionalmente, especifique detalhes sobre um servidor de autenticação auxiliar.

Você pode configurar um servidor de autenticação secundário para oferecer alta disponibilidade. Ative a opção de alternância Servidor Auxiliar e preencha os campos conforme descrito na Etapa seção Servidor Primário.

Validar e Avançar, e iniciar o processo de implantação do pod

Depois de clicar em Validar e Avançar, o sistema verifica seus valores especificados. Se tudo for validado, o assistente exibirá um resumo das informações para análise. Em seguida, você pode iniciar o processo de implantação.

Procedimentos

1 Clique em Validar e Avançar.

O sistema valida os valores especificados, como:

n Os intervalos de endereços especificados para as sub-redes a serem criadas são válidos e não sobrepõem outros endereços na região selecionada dentro de sua assinatura.

n Há máquina virtual (VM) e núcleos suficientes na quota da sua assinatura para compilar o pod.

n São quaisquer arquivos de certificado carregado no formato PEM correto.

n Se você optou por usar uma sub-rede de gerenciamento existente, ela tem o endpoint de serviço Microsoft.SQL ativado nessa sub-rede?

Importante A partir da versão de serviço de setembro de 2019, novas implantações de pod exigem o endpoint de serviço Microsoft.SQL ativado na sub-rede de gerenciamento para oferecer suporte ao uso do banco de dados PostgreSQL do Microsoft Azure do pod. Se você vir um erro de validação semelhante à seguinte captura de tela que lista sua sub-rede selecionada, significa que a sub-rede de gerenciamento pré-existente que você selecionou no assistente não contém o endpoint de serviço Microsoft.SQL configurado nela. Nesse ponto, você pode fazer login no portal do Microsoft Azure e ativar o endpoint de serviço Microsoft.SQL na sub-rede. Em seguida, você pode reenviar o assistente para implantar o pod. Para obter alguns detalhes sobre como ativar esse endpoint, consulte Antes da implantação de pod, crie as sub-redes necessárias do pod do Horizon Cloud na VNet no Microsoft Azure.

Se tudo estiver validado, a página de resumo será exibida.


VMware, Inc. 196

Se você vir uma mensagem de erro sobre endereços de rede sobrepostos, verifique se há sub-redes existentes que usam os mesmos valores que já estão em sua assinatura.

2 Na etapa final do assistente, revise as informações resumidas e clique em Enviar.

O sistema começa a implementação do pod em seu ambiente do Microsoft Azure.

Resultados

Implantar seu primeiro pod pode levar até uma hora. Até que esse pod seja implantado com êxito, um ícone de progresso será exibido na tela Introdução do Console Administrativo. Pode ser necessário atualizar a tela em seu navegador para ver o andamento. A interface de usuário baseada em navegador pode atingir o tempo limite após aproximadamente 30 minutos e solicitar que você faça login novamente.

Importante Normalmente, o estágio de pendente do pod dura até dez minutos. No entanto, ao implantar um pod na nuvem do Microsoft Azure China, o processo de implantação geral pode levar até sete (7) horas para ser concluído. O processo está sujeito a problemas de rede geográfica que podem fazer com que a velocidade de download fique lenta à medida que os binários são baixados da camada de controle da nuvem.

Se o estado do pod não tiver mudado de Pendente para Baixando após 20 minutos, e você não estiver implantando no Microsoft Azure China, o sistema colocará automaticamente o pod no estado Erro e exibirá uma mensagem informando que o pod não pode se conectar aos serviços de nuvem e pedindo para você verificar a conectividade de rede no ambiente do Microsoft Azure.

Se a tela mostra que o pod está em estado de Erro porque a VM jumpbox implantada não pôde baixar os binários necessários, provavelmente há um problema com a configuração de rede do seu ambiente. Por exemplo, o DNS configurado do VNet não pode estar resolvendo os nomes internos ou externos, ou as portas de saída necessárias não estão abertas ou estão bloqueadas pelo seu firewall. Às vezes, há uma perda temporária de conectividade com o site packages.microsoft.com usado para baixar o software de Interface de linha de comando do Microsoft Azure. Você pode executar alguns testes para verificar se a rede do seu ambiente está configurada corretamente para os requisitos do pod. Consulte Solução de problemas na implantação de pods ou no BIND de domínio pela primeira vez.

Durante o processo de implantação do pod, a seção Capacidade da página Introdução indica as várias etapas do processo (pendente, baixando, criando e conectando, etc.).


VMware, Inc. 197

A tabela a seguir fornece alguns exemplos de durações aproximadas para os estágios de criação do pod.

Importante As durações reais que você aguardará no andamento da sua implantação variarão dependendo das latências de rede que existem no momento.

Estágio Exemplo de duração

Pendente 10 minutos

Baixando 10 minutos

Criando 15 minutos

Conectando 10 minutos

Quando o pod é implantado com êxito:

n O Horizon Cloud envia um e-mail de notificação para o proprietário da conta que é identificado no registro de conta de cliente do Horizon Cloud correspondente. O e-mail informa que a integração do pod está concluída.

n Uma marca de seleção verde é exibida na tela Introdução ao lado de uma mensagem que informa que o pod foi adicionado e sobre a conclusão do processo de ingresso no domínio.

Observação Nesse momento, como seu domínio do Active Directory ainda não está registrado no pod, um botão Excluir aparecerá na página. Se o processo de implantação falhar por algum motivo ou se você não gostar dos valores usados e quiser recomeçar antes de registrar seu domínio do Active Directory, poderá clicar no botão Excluir para excluir os artefatos que foram implantados. Quando a tela indica que o pod foi excluído com êxito, você pode iniciar o processo clicando em Adicionar novamente.

Se você optar por excluir o pod a partir desse momento, devido à latência da rede, a página Introdução poderá indicar que o pod está totalmente excluído antes que todos os artefatos relacionados ao pod estejam completamente excluídos do seu ambiente do Microsoft Azure. Antes de executar o assistente de implantação de pod novamente após a exclusão do novo pod, siga as seguintes etapas:

1 Faça logout da interface do usuário do Horizon Cloud.

2 Faça login no portal do Microsoft Azure.

3 Navegue até a sua VNet.

4 Se o implantador tiver criado automaticamente as sub-redes do pod, certifique-se de que não existam sub-redes criadas por pod e de que os intervalos de endereços especificados para essas sub-redes tenham sido removidos do espaço de endereço da VNet.

Em seguida, você pode fazer login novamente no Horizon Cloud para executar o assistente de implantação do pod novamente.


VMware, Inc. 198

Próximo passo

Expanda a seção Configurações Gerais do assistente de Introdução do Console administrativo do Horizon Cloud e conclua a tarefa necessária de registro de um domínio do Active Directory. Registrar o Active Directory é a próxima etapa necessária. Após registrar o domínio, continue o gerenciamento deste pod no Console Administrativo. Veja o capítulo Introdução do Guia de administração do Horizon Cloud. Após registrar o domínio do Active Directory, siga o assistente de Como começar para ver qual tarefa deve ser concluída em seguida.

Se você tiver especificado uma configuração de gateway no pod, antes que os usuários finais acessem suas áreas de trabalho ou aplicativos remotos, deverá configurar os registros CNAME adequados no seu servidor DNS, de acordo com o tipo de gateway especificado.

n Para um gateway externo habilitado com um endereço IP público, mapeie o FQDN que você inseriu no assistente de implantação para o FQDN público gerado automaticamente do recurso do balanceador de carga do Azure do gateway. Seu registro do servidor DNS mapeia esse FQDN público gerado automaticamente do balanceador de carga com o FQDN que os usuários finais usarão e que é usado no certificado enviado. A linha de código a seguir mostra um exemplo. Você localiza a ID a ser usada na página de detalhes do pod no Console Administrativo, após ter registrado o domínio do Active Directory. Se o gateway externo tiver sido implantado na própria VNet, use a ID exibida no campo ID de Implantação.

ourApps.ourOrg.example.com vwm-hcs-ID-uag.região.cloudapp.azure.com

n Para um gateway interno ou externo sem um endereço IP público, mapeie o FQDN que você inseriu no assistente de implantação para o endereço IP privado do recurso do balanceador de carga do Azure do gateway. Seu registro do servidor DNS mapeia esse endereço IP do balanceador de carga com o FQDN que os usuários finais usarão e que é usado no certificado carregado. A linha de código a seguir mostra um exemplo.

ourApps.ourOrg.example.com Azure-load-balancer-private-IP

Se você tiver especificado ambas as configurações gateway interno ou externo e usado o mesmo FQDN para ambas, deverá configurar o roteamento o tráfego de cliente de usuário final de entrada para o recurso do balanceador de carga apropriado nos grupos de recursos dos gateways. Nesse cenário, você precisa configurar o roteamento de modo que o tráfego de cliente da Internet seja roteado para o recurso do balanceador de carga do Azure do gateway externo, e o tráfego de cliente da sua intranet seja roteado para o recurso do balanceador de carga interno do Azure do gateway interno.

Veja em Guia de administração do Horizon Cloud as etapas para localizar as informações do balanceador de carga na página de detalhes do pod.

Se você tiver especificado a autenticação de dois fatores RADIUS para as configurações de gateway do pod, deverá concluir as seguintes tarefas.

n Se você tiver configurado um gateway externo com configurações RADIUS, e esse servidor RADIUS não estiver acessível na mesma VNet usada pelo pod, ou na topologia VNet emparelhada se você tiver implantando o gateway externo na própria VNet, configure o servidor RADIUS a permitir conexões de cliente a partir do endereço IP do balanceador de carga do gateway externo. Em uma


VMware, Inc. 199


configuração gateway externo, as instâncias do Unified Access Gateway tentam entrar em contato com o servidor RADIUS usando esse endereço do balanceador de carga. Para permitir as conexões, verifique se o endereço IP do recurso do balanceador de carga que está no grupo de recursos do gateway externo está especificado como um cliente na configuração do seu servidor RADIUS.

n Se você tiver configurado um gateway interno ou externo e seu servidor RADIUS estiver acessível na mesma VNet usada pelo pod, configure o servidor RADIUS para permitir conexões dos NICs apropriados que foram criados no grupo de recursos do gateway no Microsoft Azure que deve se comunicar com o servidor RADIUS. O administrador de rede determina a visibilidade da rede do servidor RADIUS para as sub-redes e a rede virtual do Azure do pod. Seu servidor RADIUS deve permitir conexões de cliente a partir dos endereços IP desses NICs de gateway que correspondem à sub-rede para a qual o administrador de rede forneceu visibilidade de rede ao servidor RADIUS. O grupo de recursos do gateway no Microsoft Azure tem quatro NICs que correspondem a essa sub-rede, duas que estão ativas atualmente para as duas instâncias do Unified Access Gateway e duas que estão ociosas e se tornarão as ativas após o pod passar por uma atualização. Para oferecer suporte à conectividade entre o gateway e o servidor RADIUS tanto para operações de pod contínuo quanto após cada atualização de pod, certifique-se de que os endereços IP dessas quatro NICs sejam especificados como clientes na configuração do servidor RADIUS.

Para obter informações sobre como obter esses endereços IP, consulte o tópico Atualizar o seu sistema RADIUS com as informações necessárias do gateway do pod do Horizon Cloud no Guia de administração do Horizon Cloud.

Se você tiver especificado que o processo de implantação do pod crie um tenant do Workspace ONE Access, etapas adicionais serão necessárias para concluir a integração do seu pod a esse tenant. Depois de concluir a tarefa necessária de registrar um domínio do Active Directory, consulte as informações no tópico Integrar um pod do Horizon Cloud a um ambiente do Workspace ONE Access no Guia de administração do Horizon Cloud.

Solução de problemas na implantação de pods ou no BIND de domínio pela primeira vezSe a rede do seu ambiente não estiver configurada corretamente para uso com o pod do Horizon Cloud no Microsoft Azure, o processo para compilar o pod poderá ficar congelado em um estado PENDENTE ou a ação de pós-implantação para realizar o BIND de domínio em seu ambiente do Active Directory poderá falhar. As duas causas mais comuns relacionadas à rede são falha ao abrir as portas de saída necessárias e falha ao ativar o DNS para resolver os endereços internos e externos. Seguindo as etapas de solução de problemas aqui, você pode executar alguns testes para verificar se as portas de saída necessárias estão abertas e se o DNS pode resolver os endereços internos e externos.

Os requisitos gerais de rede para implantar com êxito um pod estão descritos no documento de lista de verificação de pré-requisitos, localizado neste link para PDF, e descritos em Defina as configurações do servidor DNS necessárias pela topologia de VNet que você usará para os pods do Horizon Cloud no Microsoft Azure e em Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure. Se a rede do seu ambiente não atender a esses requisitos, você encontrará um ou estes dois problemas:


VMware, Inc. 200

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-830C2506-0B55-44B5-904C-E25218DE2926.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-830C2506-0B55-44B5-904C-E25218DE2926.html

https://docs.vmware.com/br/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-6F252F50-0304-47EF-A207-5D36FDF40FAC.html


Problemas Causas comuns

n A página Introdução mostra o pod no estado pendente e que nunca muda para o estado conectando. Geralmente um pod fica no estado pendente por cerca de 10 minutos (exceto ao implantar um pod na nuvem do Microsoft Azure China, o que leva mais tempo).

n Até mesmo quando o pod tiver sido implantado com êxito, quando você tentar registrar seu Active Directory, haverá falha na etapa de BIND de domínio com o erro Unable to register Active Directory

n As portas de saída necessárias não estão abertas ou estão bloqueadas pelo seu ambiente de firewall. Se as portas de saída necessárias não estiverem abertas ou estiverem bloqueadas por um firewall, isso impedirá que o software de pod baixe para o ambiente de nuvem do Microsoft Azure e se conecte novamente à camada de controle de nuvem do Horizon Cloud de forma segura. Como resultado, ocorre o problema de estado pendente.

n O servidor DNS do VNet não está configurado corretamente para apontar para um servidor DNS válido que possa resolver os dois nomes de máquina interno e externo.

n Embora o servidor DNS do VNet esteja apontando corretamente para um servidor DNS, esse servidor DNS não pode resolver os dois nomes de máquina interno e externo.

Se nenhuma resolução DNS para nomes de máquina externos for fornecida para o VNet, poderá ocorrer o problema de estado pendente e de BIND de domínio. Por exemplo, se o DNS não puder ser resolvido no Active Directory nos Controladores de Domínio, a etapa de BIND de domínio falhará. Para obter detalhes sobre a configuração de DNS do VNet, consulte Defina as configurações do servidor DNS necessárias pela topologia de VNet que você usará para os pods do Horizon Cloud no Microsoft Azure.

Para executar alguns testes que verificarão se a configuração de DNS pode resolver os nomes internos e externos e verificarão se as portas de saída necessárias estão abertas, você pode implantar uma pequena máquina virtual (VM) de teste em sua assinatura do Microsoft Azure e usar essa VM para executar esses testes de rede. Veja a sequência de alto nível das etapas de solução de problemas:

1 Crie um par de chaves SSH.

2 Crie a VM de teste na sua assinatura do Microsoft Azure.

3 Conecte-se a essa VM de teste.

4 Execute os testes de rede.

5 Quando o teste é feito, exclua a VM de teste e todos os artefatos relacionados ao teste que foram criados no seu ambiente do Microsoft Azure durante esta solução de problemas.

Observação Se você não excluir os artefatos relacionados ao teste e usar posteriormente a ação Excluir do Console Administrativo para excluir o pod, poderão ocorrer resultados inesperados. Ao excluir um pod, o sistema verifica as sub-redes do pod para verificar se tudo o que estiver conectado às sub-redes pertence ao pod (de acordo com o ID do pod). Se o sistema determinar que VMs adicionais, discos de VM, IPs ou outros artefatos estão conectados às sub-redes do pod, o sistema não poderá excluir o pod de forma clara.


VMware, Inc. 201

Para obter detalhes sobre como executar os testes de solução de problemas, consulte as seções a seguir.

Importante Se você estiver direcionando todo o tráfego para fora por meio de sua rede local e permitir apenas a passagem do tráfego autenticado, mas não tiver fornecido valores para o uso de um proxy no assistente de implantação de pod, embora todos esses testes manuais sejam bem-sucedidos, o tráfego enviado por uma origem não autenticada, o jumpbox, falhará. O sintoma dessa situação é que a implantação do pod fica presa no estado pendente. Se você estiver nessa situação, deverá excluir o pod da página Introdução, executar novamente o assistente de implantação de pod e especificar as informações de proxy necessárias.

Procedimentos

1 Criar um par de chaves SSH

Você precisa de um par de chaves SSH para autenticar a VM de teste do Linux que você implantará em sua assinatura do Microsoft Azure. Crie o par de chaves no sistema que você usará para o SSH se conectar à VM de teste. Essa etapa será opcional se você já tiver um par de chaves nesse sistema.

2 Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure

Você usará uma máquina virtual (VM) do Linux de teste no seu ambiente do Microsoft Azure para executar os testes que verificam a conectividade de rede configurada para o seu pod do Horizon Cloud.

3 Usar SSH para se conectar à VM de teste

Faça uma conexão SSH (Secure Shell) com a VM de teste para que você possa executar os testes de conectividade de rede em seu ambiente do Microsoft Azure.

4 Executar os testes para verificar a rede no seu ambiente do Microsoft Azure

Executar estes testes para verificar se estas duas áreas relacionadas à rede estão configuradas corretamente: se o DNS pode resolver os endereços interno e externo e se as portas de saída necessárias estão abertas. Execute esses testes usando sua VM de teste.

5 Excluir a VM de teste depois de concluir os testes

Quando você tiver concluído os testes para verificar a sua configuração de rede do Microsoft Azure e não precisar mais da VM de teste, deverá excluir a VM e todos os seus artefatos relacionados do seu ambiente do Microsoft Azure.

Criar um par de chaves SSH

Você precisa de um par de chaves SSH para autenticar a VM de teste do Linux que você implantará em sua assinatura do Microsoft Azure. Crie o par de chaves no sistema que você usará para o SSH se conectar à VM de teste. Essa etapa será opcional se você já tiver um par de chaves nesse sistema.

Você pode usar um sistema do Microsoft Windows ou do Linux para criar esse par de chaves SSH. As etapas para os dois tipos de sistemas estão descritas aqui. Escolha as etapas mais apropriadas para sua situação.


VMware, Inc. 202

Criar um par de chaves SSH em um sistema do Microsoft WindowsUse estas etapas quando você estiver usando um sistema do Microsoft Windows para o SSH se conectar à VM de teste do Linux sendo implantada em sua assinatura do Microsoft Azure.

Quando você criar a VM de teste no Microsoft Azure, usará o conteúdo do arquivo de chave pública gerado. Se você já tiver um par de chaves SSH existente no sistema do Microsoft Windows que será usado para se conectar com a VM de teste, poderá ignorar essa etapa e prosseguir com a criação da VM de teste, conforme descrito em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure.

Ao seguir essas etapas, você gera o par de chaves SSH, copia o conteúdo do arquivo de chave pública para que possa usá-lo ao criar a VM de teste e carrega a chave privada para a ferramenta PuTTY Pageant. Pageant é um agente de autenticação de SSH que pode conter as chaves privadas na memória. Ao manter a chave privada na memória, a chave privada é aplicada automaticamente em qualquer sessão de SSH do sistema do Microsoft Windows, tornando-a mais fácil de ser usada.

Pré-requisitos

Um sistema do Microsoft Windows não tem o software de par de chaves SSH instalado por padrão. Verifique se o software de geração de par de chaves SSH está instalado no sistema que você está planejando usar. Você pode usar qualquer software de geração de par de chaves SSH. As etapas abaixo descrevem como usar o software PuTTY no Microsoft Windows para criar o par de chaves SSH. Você pode obter o software PuTTY em www.putty.org. Após a instalação, o conjunto de ferramentas PuTTY está disponível. A seguinte captura de tela mostra um exemplo das ferramentas PuTTY no menu Iniciar.

Procedimentos

1 No seu sistema do Microsoft Windows, inicie PuTTYgen (o gerador de chaves do PuTTY).

No Microsoft Windows 10, a opção PuTTYgen no menu Iniciar se parece com .

A janela PuTTY Key Generator é exibida. Como destacado na seguinte captura de tela, o objetivo é gerar um par de chaves públicas-privadas, do tipo RSA SSH-2 e ter 2048 bits.


VMware, Inc. 203

https://www.putty.org

2 Verifique se a opção SSH-2RSA está selecionada, se 2048 está definido como o número de bits e clique em Gerar. A janela muda para a janela Chave que exibe uma barra de progresso.

3 Mova o cursor ao redor aleatoriamente na área em branco abaixo da barra de progresso. Mover o cursor na área adiciona a aleatoriedade necessária para o processo.


VMware, Inc. 204

4 Salve a chave privada no sistema inserindo uma senha da chave e clique em Salvar chave privada.

Observação Usar uma senha da chave é uma prática recomendada opcional. No entanto, se você clicar em Salvar chave privada sem inserir uma senha da chave, uma janela pop-up perguntará se você deseja salvar a chave privada sem uma senha da chave.

A chave privada é salva como um arquivo PPK. Depois de clicar em Salvar chave privada, você pode navegar para um diretório no sistema local, digitar um nome de arquivo e salvar o arquivo.

5 Use o botão Salvar chave pública para salvar a chave pública em uma localização da qual você pode copiar quando você cria a VM de teste.

6 Inicie o Pageant, o agente de autenticação de SSH do PuTTY.

No Microsoft Windows 10, a opção Pageant no menu Iniciar se parece com a . Quando você clica nele, o ícone do Pageant de um computador usando um chapéu é carregado na bandeja do sistema.


VMware, Inc. 205

A seguinte captura de tela mostra o ícone do Pageant carregado em uma bandeja do sistema do Microsoft Windows 10.

7 Adicione a chave privada ao Pageant clicando com o botão direito do mouse nesse ícone de bandeja do sistema, clicando em Adicionar Chave e usando a janela de seleção de arquivo para navegar e selecione o arquivo de chave privada (PPK) salvo.

Observação Se você tiver especificado uma senha da chave quando salvou o arquivo de chave privada anteriormente, uma caixa será exibida para você digitar essa senha.

Resultados

Nesse ponto, a chave privada é carregada no Pageant. Você pode usar a opção Exibir Chaves no menu de ação para ver a chave na lista de chaves carregadas. Quando você inicia uma sessão de SSH usando PuTTY, o PuTTY irá recuperar a chave automaticamente do Pageant e usará a chave para autenticar sem a necessidade de digitar sua senha. Mais tarde, quando você terminar as sessões SSH em execução e desejar desligar o Pageant, use a opção Sair do menu clique de clique direito do mouse do ícone da bandeja do Pageant.

Próximo passo

Crie a VM de teste seguindo as etapas em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure.

Criar um par de chaves SSH em um sistema LinuxSiga estas etapas ao usar um sistema Linux para se conectar por SSH à VM de teste Linux que você estiver implantando na sua assinatura do Microsoft Azure.

Nas etapas para a criação da VM de teste no Microsoft Azure, você usará o conteúdo do arquivo de chave pública gerada. Se você já tiver um par de chaves SSH existente no sistema do Linux que você usará para se conectar à VM de teste, você poderá ignorar essa etapa e prosseguir com a criação da VM de teste, conforme descrito em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure.


VMware, Inc. 206

Pré-requisitos

Antes de executar estas etapas, garanta que não vai substituir um par de chaves de SSH existente que você deseja manter para outros fins. Em um sistema Linux, os arquivos de chaves SSH públicas e privadas são criados, via de regra, no diretório ~/.ssh/id_rsa do Linux. Se houver um par de chaves SSH no diretório e você usar o mesmo nome de arquivo ao executar esse comando, ou se você especificar um local diferente no comando e um par de chaves SSH já existir no local, o par existente será substituído.

Procedimentos

1 No sistema Linux, abra um shell bash.

2 No shell bash, digite o seguinte comando:

ssh-keygen -t rsa -b 2048

3 Siga as instruções na tela sobre como inserir um arquivo no qual salvar a chave, inserir um código de acesso e confirmá-lo.

Vejamos um exemplo das instruções na tela, no qual mykey foi inserido como o arquivo para salvar a chave.

-bash-4.1$ ssh-keygen -t rsa -b 2048

Generating public/private rsa key pair.

Enter file in which to save the key (/mts-cm/home/user1/.ssh/id_rsa): mykey

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Observação Usar um código de acesso de chave é uma prática recomendada opcional.

A chave privada é salva no arquivo que você especificar e a chave pública é salva em um arquivo com o mesmo nome e uma extensão .pub. Usando-se o exemplo acima de inserir mykey como o arquivo, o exemplo de saída seria:

Your identification has been saved in mykey.

Your public key has been saved in mykey.pub.

Próximo passo

Crie a VM de teste seguindo as etapas em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure.

Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure

Você usará uma máquina virtual (VM) do Linux de teste no seu ambiente do Microsoft Azure para executar os testes que verificam a conectividade de rede configurada para o seu pod do Horizon Cloud.


VMware, Inc. 207

Pré-requisitos

Verifique se você tem a chave pública SSH que criou conforme descrito em Criar um par de chaves SSH. Você fornecerá essa chave pública no assistente de criação de VM para que a máquina virtual confie nas conexões SSH provenientes do sistema que tem a chave privada correspondente.

Verifique se você tem o nome da rede virtual (VNet) que é o mesmo que está usando para implantar seu pod, conforme descrito em Configurar a rede virtual necessária no Microsoft Azure.

Se você tentar implantar um pod e o processo de implantação falhar em algum momento, o processo poderá já ter criado a sub-rede de gerenciamento do pod na VNet.

n Em caso afirmativo, recomenda-se que você implante a VM de teste nessa sub-rede. Para identificar se a sub-rede de gerenciamento do pod existe na VNet, faça login no portal do Microsoft Azure, navegue até essa VNet e examine a lista de sub-redes que ele tem. Você pode navegar para o VNet

usando as Redes virtuais ( ) na barra de navegação esquerda. A sub-rede de gerenciamento do pod terá um nome no padrão vmw-hcs-podID-net-management, em que podID é o UUID do pod.

n Se o processo de implantação do pod não tiver criado a sub-rede de gerenciamento do pod na VNet, você poderá escolher qualquer sub-rede disponível na VNet ou criar uma nova sub-rede para a VM de teste usar.

Procedimentos


2 Na barra de navegação esquerda do portal, clique em Máquinas virtuais ( ) e clique em + Adicionar.

3 Procure por Ubuntu Server 16.04 LTS e selecione-o.

4 Selecione Gerenciador de Recursos como o modelo de implantação e clique em Criar.

O assistente de Criar Máquina Virtual indica as etapas para definir as configurações básicas.


VMware, Inc. 208

5 Forneça as configurações básicas da VM e clique em OK para continuar na próxima etapa do assistente.

Opção Descrição

Nome Digite um nome para a VM.

Tipo de disco da VM Mantenha a configuração SSD padrão.

Nome de usuário Insira um nome de usuário que satisfaça os requisitos de nome de usuário do Microsoft Azure, conforme descrito na documentação da Microsoft aqui.

Importante Anote esse nome porque você precisará usá-lo mais tarde.

Tipo de Autenticação Selecione Chave pública SSH.

Chave pública SSH Nesse campo, cole a chave pública SSH que você criou quando criou o par de chaves SSH. O conteúdo colado deve começar com a linha ---- BEGIN SSH2 PUBLIC KEY ---- e terminar com a linha ---- END SSH2 PUBLIC KEY ---- da sua chave pública.

Inscrição Selecione a mesma assinatura que você está usando para o pod.

Grupo de recursos A opção recomendada é criar um novo grupo de recursos para a VM de teste e seus artefatos relacionados como seu disco. Selecione Criar novo e digite um nome para o novo grupo de recursos. Embora você possa usar um grupo de recursos existente com essa VM de teste, recomenda-se usar um grupo de recursos específico para a VM de teste porque é mais fácil excluir a VM e seus artefatos relacionados excluindo o grupo de recursos inteiro ao terminar de executar os testes.

Localização Selecione a mesma região geográfica física que você está usando para o pod.


VMware, Inc. 209

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/faq#what-are-the-username-requirements-when-creating-a-vm

6 Na etapa de tamanho do assistente, clique em um tamanho de VM e em Selecionar para continuar na próxima etapa do assistente.

Como essa deve ser uma VM de curta duração, usada apenas para concluir os testes de verificação, você pode escolher qualquer tamanho. No entanto, como tamanhos menores geralmente têm custos menores associados no Microsoft Azure, é comum escolher um tamanho pequeno para a VM de teste. A captura de tela a seguir ilustra o exemplo de escolher o tamanho Padrão D2S_V3.


VMware, Inc. 210

7 Na etapa de configurações do assistente, especifique as opções de rede principais para a VM de teste.

Você pode fazer três escolhas importantes nesta etapa do assistente. A captura de tela a seguir ilustra estes três itens de chave. Depois de definir as três opções de rede de chave, é possível manter todos os outros valores padrão.

.


VMware, Inc. 211

Opção Descrição

Rede virtual Você deve selecionar a mesma VNet que está usando para implantar o pod. Esse VNet deve ser aquele que você configurou de acordo com os detalhes na lista de verificação de pré-requisitos e conforme descrito em Configurar a rede virtual necessária no Microsoft Azure.

Sub-rede Se você já tentou implantar o pod e o processo falhou, a sub-rede de gerenciamento do pod pode ter sido criada na rede virtual. Se a sub-rede estiver lá, recomenda-se selecionar essa sub-rede para esta VM de teste. Clique na opção Sub-rede para navegar até as sub-redes que existem na rede virtual selecionada. Talvez você precise passar o mouse sobre a sub-rede para ver seu nome completo na dica de ferramenta. Esta captura de tela ilustra a ação de passar o cursor sobre uma sub-rede para ver o padrão de nomenclatura de uma sub-rede de gerenciamento do pod, no padrão vmw-hcs-podID-net-management.

Se o processo de implantação do pod não tiver criado a sub-rede de gerenciamento do pod na VNet, selecione a sub-rede na sua VNet que você identificou para usar para a VM de teste (conforme descrito nos pré-requisitos acima).

Observação Se o pod tiver sido implantado com êxito, mas você não conseguir solucionar os problemas de ingresso no domínio, talvez você queira selecionar a sub-rede de área de trabalho do pod para a VM de teste, em vez da sub-rede de gerenciamento, pois as operações de ingresso no domínio são usadas com as imagens da área de trabalho que se conectam à essa sub-rede de área de trabalho.

Endereço IP público Selecione essa opção para que a VM de teste criada tenha um endereço IP público atribuído a ela. Ter um endereço IP público permite que você se conecte a ela por meio da rede de longa distância (WAN).

Observação Usar um IP público pode não ser tecnicamente viável em sua configuração de rede. Se você não puder criar a VM de teste com um IP público, precisará ter conectividade de rede do seu sistema local para a sub-rede que selecionou no campo Sub-rede ou precisará se conectar a algumas outras máquinas na sua rede e, em seguida, estabelecer uma conexão de entrada com a VM de teste.

8 Clique em OK para mover para a etapa de resumo do assistente.

9 Na etapa de resumo, verifique se as principais partes de informação (assinatura, localização, rede virtual e sub-rede) correspondem àquelas que você está usando para seu pod e, em seguida, clique em Criar.


VMware, Inc. 212

Resultados

A criação da VM de teste começa a ser executada. Normalmente, você pode ver o processo em execução no seu painel do Microsoft Azure, conforme ilustrado na captura de tela a seguir.

A implantação da VM normalmente leva cerca de cinco a dez minutos. Quando a VM é totalmente implantada, ela fica no estado Em execução. A captura de tela a seguir ilustra os detalhes de uma VM de teste de amostra.

Quando você vir a VM de teste que está ativa e em execução, conecte-se a ela. Siga as etapas em Usar SSH para se conectar à VM de teste.

Usar SSH para se conectar à VM de teste

Faça uma conexão SSH (Secure Shell) com a VM de teste para que você possa executar os testes de conectividade de rede em seu ambiente do Microsoft Azure.Conexão por SSH à VM de teste a partir de um sistema Microsoft WindowsVocê faz essa conexão a partir do sistema Microsoft Windows que tem a chave privada que corresponde à chave pública especificada por você ao criar a VM de teste.

Pré-requisitos

Verifique se você tem o endereço IP da VM de teste e o nome de usuário que especificou ao criar a VM.


VMware, Inc. 213

Em um sistema Microsoft Windows, normalmente se usa o PuTTY. Para que o PuTTY carregue a sua chave privada com facilidade quando você iniciar a sessão SSH, antes de iniciar o PuTTY, inicie o Pageant conforme descrito em Criar um par de chaves SSH em um sistema do Microsoft Windows e adicione a chave privada SSH à lista de chaves Pageant. A chave privada SSH deve coincidir com a chave pública que você especificou ao criar a VM de teste. Quando a chave privada é carregada no Pageant, a sessão SSH do PuTTY usará essa chave privada automaticamente.

Procedimentos

1 Inicie o PuTTY ( ).

A janela Configuração do PuTTY abre.

2 Na janela Configuração do PuTTY, especifique o nome do host, selecione SSH e, em seguida, clique em Abrir.

No campo Nome de Host da janela Configuração do PuTTY, digite uma cadeia de caracteres no padrão

vmdeteste_nomedeusuário@ipvmdeteste

substituindo o nome de usuário e o endereço IP da VM de teste por vmdeteste_nomedeusuário e ipvmdeteste na cadeia de caracteres.

Importante Depois de clicar em Abrir, na primeira vez que você se conectar à VM de teste, serão exibidas uma mensagem de segurança PuTTY informando que a chave do host do servidor não está armazenada em cache e a impressão digital da chave rsa2 do servidor. Você pode continuar a fazer a conexão clicando em Sim para adicionar a chave do host do servidor à cache do PuTTY ou em Não para se conectar sem adicionar a chave à cache do PuTTY. Se você achar que a conexão não está sendo feita com a VM de teste, clique em Cancelar para abandonar a conexão e volte para a janela de configuração do PuTTY para verificar a entrada do seu nome de host.

A seguinte captura de tela é uma ilustração da janela usando o exemplo

[email protected]


VMware, Inc. 214

.

Resultados

Quando é estabelecida a conexão SSH, aparece uma janela de linha de comando parecida com a seguinte captura de tela.


VMware, Inc. 215

Próximo passo

Agora que você está conectado à VM de teste, já pode executar os testes para verificar a conectividade de rede em seu ambiente do Microsoft Azure. Siga as etapas descritas em Executar os testes para verificar a rede no seu ambiente do Microsoft Azure.

Conexão por SSH à VM de teste a partir de um sistema LinuxVocê faz essa conexão a partir do sistema Linux que tem a chave privada que corresponde à chave pública especificada por você quando criou a VM de teste.

Pré-requisitos

Verifique se você tem o endereço IP da VM de teste e o nome de usuário que especificou ao criar a VM.

Procedimentos

1 Abra um shell bash.

2 No prompt do shell bash $, insira o comando ssh como se vê abaixo, substituindo o endereço IP da VM de teste e o nome de usuário por ipvmdeteste e vmdeteste_nomedeusuário no comando:

ssh vmdeteste_nomedeusuário@ipvmdeteste

Por exemplo, usando os detalhes da VM de teste dos exemplos em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure, o exemplo de comando se pareceria com o seguinte:

ssh [email protected]

Resultados

Quando é estabelecida a conexão SSH, aparece uma janela de linha de comando parecida com a seguinte captura de tela.


VMware, Inc. 216

Próximo passo

Agora que você está conectado à VM de teste, já pode executar os testes para verificar a conectividade de rede em seu ambiente do Microsoft Azure. Siga as etapas descritas em Executar os testes para verificar a rede no seu ambiente do Microsoft Azure.

Executar os testes para verificar a rede no seu ambiente do Microsoft Azure

Executar estes testes para verificar se estas duas áreas relacionadas à rede estão configuradas corretamente: se o DNS pode resolver os endereços interno e externo e se as portas de saída necessárias estão abertas. Execute esses testes usando sua VM de teste.

O pod depende de o DNS resolver os endereços interno e externo. Os dois primeiros teste aqui verificam se o DNS configurado no seu ambiente de rede pode resolver os FQDNs conhecidos para os endereços interno e externo.

Importante Se você estiver direcionando todo o tráfego para fora por meio de sua rede local e permitir apenas a passagem do tráfego autenticado, mas não tiver fornecido valores para o uso de um proxy no assistente de implantação de pod, embora todos esses testes manuais sejam bem-sucedidos, o tráfego enviado por uma origem não autenticada, o jumpbox, falhará. O sintoma dessa situação é que a implantação do pod fica presa no estado pendente. Se você estiver nessa situação, deverá excluir o pod da página Introdução, executar novamente o assistente de implantação de pod e especificar as informações de proxy necessárias.

Pré-requisitos

Antes de executar esses testes, verifique se você criou uma VM de teste na sua assinatura do Microsoft Azure e tem uma conexão SSH com ela, conforme descrito em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure e Usar SSH para se conectar à VM de teste.

Obtenha os endereços IP e nomes de domínio totalmente qualificados (FQDNs) para servidores internos à sua rede e que você espera que sejam acessíveis pelo VNet, como seu Controlador de Domínio do Active Directory. Você usará essas informações no teste de verificação de DNS.

Procedimentos

1 Verifique se o DNS está funcionando em seu ambiente para resolver os FQDNs internos usando o comando dlg para consultar um nome de domínio conhecido que é interno para seu VNet no Microsoft Azure.

Na janela de conexão SSH, emita o comando dig para consultar o nome de domínio de um servidor que você sabe que é interno à sua rede, como seu Controlador de Domínio do Active Directory.

dig internal-domain-name

Onde internal-domain-name é o nome de domínio completo de um servidor que você sabe é interno à sua rede.


VMware, Inc. 217

dig (Domain Information Groper) é uma ferramenta de linha de comando para solução de problemas de rede. Ao executar este comando usando um nome de host interno, o resultado verifica se a sua configuração de DNS pode resolver os endereços internos corretamente. Se a sua configuração de DNS puder resolver o internal-domain-name usado no comando, a saída do comando retornará o endereço IP correto associado a esse nome de domínio.

Por exemplo, suponha que o VNet esteja configurado com um servidor interno do Active Directory que possui um Controlador de Domínio do Active Directory com a entrada DNS skylo.local e o endereço IP 192.168.0.15. Emitir dig skylo.local deveria verificar se a configuração de DNS do VNet pode resolver esse nome de servidor interno skylo.local:

testvmadmin@HCS-testingVM:~$ dig skylo.local

; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4000

;; QUESTION SECTION:

;skylo.local. IN A

;; ANSWER SECTION: skylo.local. 600 IN A 192.168.0.15

;; Query time: 1 msec

;; SERVER: 192.168.0.15#53(192.168.0.15)

;; WHEN: Mon Mar 26 20:58:01 UTC 2018

;; MSG SIZE rcvd: 56

testvmadmin@HCS-testingVM:~$

O teste é bem-sucedido quando a ANSWER SECTION indica que o nome do host fornecido foi resolvido para o endereço IP que você espera para esse nome de host.

Observação Às vezes, o DNS não é 100% confiável, e algumas solicitações são resolvidas corretamente, enquanto outras falham. Se a emissão do comando falhar na primeira vez, execute o comando para dez a vinte iterações e consulte se você obteve respostas confiáveis a cada vez.

2 Verifique se o DNS está funcionando em seu ambiente para resolver FQDNs externos usando o comando dlg para consultar um nome de domínio externo conhecido.

Na janela de conexão SSH, emita o comando dig para consultar um nome de domínio externo padrão do setor, como vmware.com ou microsoft.com.

dig external-domain-name


VMware, Inc. 218

Onde external-domain-name é um nome de domínio totalmente qualificado que é externo ao seu VNet. Por exemplo, emitir dig vmware.com verificaria se a configuração de DNS do VNet pôde possível resolver o nome externo:

testvmadmin@HCS-testingVM:~$ dig vmware.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4000

;; QUESTION SECTION:

;vmware.com. IN A

;; ANSWER SECTION: vmware.com. 150 IN A 107.154.105.19 vmware.com. 150 IN A 107.154.106.19

;; Query time: 28 msec

;; SERVER: 192.168.0.15#53(192.168.0.15)

;; WHEN: Mon Mar 26 21:14:29 UTC 2018

;; MSG SIZE rcvd: 71

testvmadmin@HCS-testingVM:~

No exemplo acima, a ANSWER SECTION indica que o nome de domínio externo vmware.com foi resolvido corretamente para dois endereços IP.

Observação Você pode repetir esse teste usando vários nomes de domínio externos, como azure.com ou microsoft.com, para verificar se o DNS pode resolver nomes externos diferentes.

Se os testes de DNS não funcionarem, verifique as suas configurações de rede e o servidor DNS. Verifique que você adicionou seu servidor DNS ao seu VNet.

Importante Se você achar que precisará adicionar o seu servidor DNS ao seu VNet ou que precisará alterar a configuração do servidor DNS do VNet, deverá reiniciar todas as VMs que estão conectadas a esse VNet para que elas detectem a alteração. Se você alterar a configuração do servidor DNS do VNet e não reiniciar que todas as VMs conectadas a esse VNet, as alterações não serão propagadas corretamente no VNet.

3 Verifique se as portas de saída necessárias estão disponíveis usando o comando netcat.

O Horizon Cloud requer que algumas portas de saída sejam abertas, para que o software do pod possa ser baixado com segurança para o seu ambiente do Microsoft Azure e para que o pod possa conectar de volta com a camada de controle do Horizon Cloud. Conforme descrito em Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure, as seguintes portas TCP de saída precisam ser abertas da sub-rede de gerenciamento do pod: portas 80, 443 e 11371. Ao executar o comando netcat, conforme indicado no comando a seguir, você pode verificar se essas portas de saída estão abertas conforme necessário.


VMware, Inc. 219

Na janela de conexão SSH, execute os comandos a seguir (um por porta).

Observação O comando a seguir para testar a porta 11371 especifica packages.microsoft.com para testar essa conexão, enquanto as duas outras linhas testam a conexão de saída com a camada de controle do Horizon Cloud.

testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80

Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!

testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443

Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!

testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371

Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!

Quando uma porta é aberta corretamente, o comando netcat retorna a linha succeeded! para seu teste.

Se os comandos netcat retornarem falhas, verifique suas conexões de rede do Microsoft Azure, seus Grupos de Segurança de Rede na sua assinatura e todos os firewalls que você possa ter em funcionamento. Verifique se a sua configuração de rede atende aos requisitos de DNS, portas e protocolo que o pod precisa para a implantação, conforme descrito em Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure.

Resultados

Se os testes acima forem bem-sucedidos, você será capaz de implantar com êxito o seu pod.

Observação Se você estiver configurando recursos opcionais para uso com o seu pod, como a autenticação de dois fatores Radius ou True SSO, portas adicionais poderão ser necessárias para as finalidades acima. Você pode usar as técnicas de teste acima da porta de saída para verificar se essas portas estão abertas corretamente.

Próximo passo

Quando você concluir o teste, deverá excluir a VM de teste e todos os seus artefatos relacionados, como seu disco de VM, endereço IP, NIC, do seu ambiente do Microsoft Azure. Idealmente, você deveria ter criado um grupo de recursos para a VM de teste e poderá simplesmente excluir esse grupo de recursos para excluir todos os artefatos da VM. Siga as etapas em Excluir a VM de teste depois de concluir os testes.

Importante Se você não excluir todos os artefatos da VM de teste do seu ambiente do Microsoft Azure e tiver conectado a VM a uma das sub-redes do pod, se tentar excluir o pod usando o Console Administrativo mais tarde, o sistema poderá não ser capaz de excluir totalmente o pod devido a esses artefatos conectados restantes. Por padrão, quando você usa a ação Excluir para excluir um pod, o Horizon Cloud exclui esses grupos de recursos e sub-redes que ele criou para o pod. O Microsoft Azure impedirá a exclusão de sub-redes que ainda estão em uso. Se os artefatos da sua VM de teste estiverem conectados às sub-redes do pod, essas sub-redes não podem ser excluídas e a exclusão de pod ficará incompleta. Para evitar essa situação, certifique-se de que todos os artefatos da VM de teste sejam excluídos depois de você implantar o pod com êxito.


VMware, Inc. 220

Excluir a VM de teste depois de concluir os testes

Quando você tiver concluído os testes para verificar a sua configuração de rede do Microsoft Azure e não precisar mais da VM de teste, deverá excluir a VM e todos os seus artefatos relacionados do seu ambiente do Microsoft Azure.

Importante Se você não excluir todos os artefatos da VM de teste do seu ambiente do Microsoft Azure e tiver conectado a VM a uma das sub-redes do pod, se tentar excluir o pod usando o Console Administrativo mais tarde, o sistema poderá não ser capaz de excluir totalmente o pod devido a esses artefatos conectados restantes. Por padrão, quando você usa a ação Excluir para excluir um pod, o Horizon Cloud exclui esses grupos de recursos e sub-redes que ele criou para o pod. O Microsoft Azure impedirá a exclusão de sub-redes que ainda estão em uso. Se os artefatos da sua VM de teste estiverem conectados às sub-redes do pod, essas sub-redes não podem ser excluídas e a exclusão de pod ficará incompleta. Para evitar essa situação, certifique-se de que todos os artefatos da VM de teste sejam excluídos depois de você implantar o pod com êxito.

Procedimentos


2 Use um dos seguintes métodos para excluir a VM de teste, dependendo de como você a implantou.

n Se você tiver implantado a VM de teste em seu próprio grupo de recursos e você não estiver usando esse grupo para outros fins, poderá excluir o grupo de recursos inteiro.

Cuidado Para evitar a exclusão indesejada de outros itens, certifique-se de que o grupo de recursos contenha apenas a VM de teste e seus objetos associados, como seus adaptadores de rede e disco, antes de excluir o grupo de recursos.

a Na navegação esquerda do portal, clique em Grupos de recursos e procure pelo grupo de recursos da VM de teste.

b Clique no nome do grupo de recursos para ver os itens nesse grupo de recursos.


VMware, Inc. 221

c Clique em Excluir grupo de recursos. Na mensagem de confirmação, digite no nome do grupo de recursos e, em seguida, clique em Excluir.

n Se você precisar excluir a VM de teste sem excluir um grupo de recursos inteiro, poderá usar a caixa de pesquisa do portal para procurar o nome da VM de teste. Os resultados dessa pesquisa listarão a VM e todos os seus objetos associados (disco, interfaces de rede, endereço IP público etc.). Exclua cada objeto individualmente.


VMware, Inc. 222

Agora que seu primeiro pod está completamente implantado e conectado ao Horizon Cloud 3Parabéns por implantar seu primeiro pod do Horizon Cloud!

A página Introdução do Console Administrativo indica quando você criou com êxito um pod conectado à nuvem.

A seguinte captura de tela ilustra a aparência da página quando seu primeiro pod é um implantado no Microsoft Azure.

Neste ponto, você deve realizar as etapas para registrar o Horizon Cloud com o domínio do Active Directory que deseja usar com esse pod. O Guia de administração do Horizon Cloud fornece essas etapas detalhadas. Consulte o tópico Introdução ao uso do ambiente do Horizon Cloud e seus subtópicos.

VMware, Inc. 223


Guia de implantação do Horizon Cloud - VMware Horizon Cloud … · 2020-03-31 · Guia de...

Documents

Transcript of Guia de implantação do Horizon Cloud - VMware Horizon Cloud … · 2020-03-31 · Guia de...