Para obter sucesso do dia 0 em diante nas implantações do Horizon Cloud on Microsoft Azure de primeira geração, você deve garantir que os nomes de host descritos nessa página de documentação possam ser resolvidos e acessados nas sub-redes de gerenciamento e tenant usando as portas e os protocolos específicos identificados nessa página.
Sobre esta página
Conforme descrito em Artigo 93762 da base de dados de conhecimento da VMware, o recurso Monitoramento de Infraestrutura do Horizon foi preterido. A partir de outubro de 2023, as informações de portas e protocolos relacionadas a esse recurso preterido foram removidas desta página.
Uma indicação de qual ambiente você tem, next-gen ou primeira geração, é o padrão que aparece no campo de URL do navegador depois que você faz login em seu ambiente e vê o rótulo Horizon Universal Console. Para um ambiente next-gen, o endereço de URL do console contém uma parte como /hcsadmin/. A URL do console de primeira geração tem uma seção diferente (/horizonadmin/).
Breve introdução
O motivo pelo qual essa página inclui a frase nome do DNS junto com a frase nome do host é porque o DNS é um padrão de rede para resolver nomes de host para que ocorra a comunicação entre esses nomes de host.
Um nome de host é um nome exclusivo atribuído a uma instância de máquina em uma determinada rede. Conforme descrito no setor de rede de software, os sistemas usam o Sistema de Nomes de Domínio (DNS) para resolver nomes de host em seus endereços IP para fins de comunicação.
O processo de implantação do pod requer que as instâncias do implantadas tenham comunicação de rede por meio da VNet selecionada da implantação para os nomes de host (nomes DNS) descritos nesta página.
Depois que o pod é implantado com êxito na sua assinatura, várias operações de serviço diárias exigem acesso à rede a nomes de host específicos, assim como o processo de atualização do pod para atualizar o software do pod quando um novo software é disponibilizado.
Esta página descreve os requisitos. Às vezes, essa página usa as frases nome do DNS e nome do host de forma intercambiável.
Alguns pontos principais
- Sobre esses nomes DNS necessários
-
Implantar e executar um pod do
Horizon Cloud requer acesso à rede a endereços DNS específicos por meio das VNets do Microsoft Azure. Para que o implantador do pod funcione, você deve configurar seus firewalls para permitir que a rede acesse esses endereços. O objetivo de cada endereço DNS é indicado nas tabelas a seguir.
Além de permitir a comunicação de rede com esses endereços DNS, a configuração de DNS no seu VNet deve resolver os nomes conforme descrito neste artigo.
Quando você seleciona a opção de implantar o gateway externo na própria VNet separada da VNet do gerenciador de pods, essa sub-rede da VNet deve atender aos mesmos requisitos de DNS que a sub-rede de gerenciamento da VNet do gerenciador de pods.
Além do implantador de pod e seus fluxos de trabalho, vários recursos de serviço exigem acesso a endereços DNS específicos para esses recursos funcionarem de ponta a ponta. Esses nomes DNS também são fornecidos nas tabelas a seguir.
Alguns desses nomes DNS têm um elemento regional para eles.
Conforme descrito em Integração Restrita no Ecossistema VMware, você pode usar o Horizon Cloud com outros produtos disponíveis no ecossistema mais amplo da VMware. Esses outros produtos podem ter requisitos de DNS adicionais. Esses requisitos de DNS adicionais não são detalhados aqui. Para esses requisitos de DNS, consulte a documentação definida para os produtos específicos que você integrará ao seu pod.
- Sobre portas e protocolos após a implantação de um pod, para operações contínuas relacionadas ao serviço
- 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. Consulte Tenants de primeira geração: pod do Horizon Cloud: requisitos de portas e protocolos para obter mais detalhes.
Tenants de primeira geração: nomes de DNS da camada de controle regional
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 que existia quando o e-mail de boas-vindas foi enviado para você, o e-mail que você recebeu 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.
| Seu email de boas-vindas diz | Nome DNS regional |
|---|---|
USA |
cloud.horizon.vmware.com |
EU_CENTRAL_1 ou Europe |
cloud-eu-central-1.horizon.vmware.com |
AP_SOUTHEAST_2 ou Australia |
cloud-ap-southeast-2.horizon.vmware.com |
PROD1_NORTHCENTRALUS2_CP1 ou USA-2 |
cloud-us-2.horizon.vmware.com |
PROD1_NORTHEUROPE_CP1 ou Europe-2 |
cloud-eu-2.horizon.vmware.com |
PROD1_AUSTRALIAEAST_CP1 ou Australia-2 |
cloud-ap-2.horizon.vmware.com |
Japan |
cloud-jp.horizon.vmware.com |
UK |
cloud-uk.horizon.vmware.com |
Europe-3 |
cloud-de.horizon.vmware.com |
Nomes de host, requisitos de DNS para o processo de implantação de pod principal, atualizações de pod, ativação de vários recursos de serviço e operações em andamento
Para o uso de ponta a ponta bem-sucedido dos recursos do serviço, você deve garantir que os nomes de host a seguir possam ser resolvidos e acessados pelas sub-redes de gerenciamento e tenant usando as portas e os protocolos específicos, conforme indicado nas tabelas a seguir. Alguns dos recursos de serviço que exigem a capacidade de acessar nomes de host específicos são:
- O implantador de pod que implanta automaticamente um pod baseado em gerenciador de pod em sua assinatura do Microsoft Azure
- O recurso de atualização do pod, que atualiza o software do pod para uma versão de software mais recente
- O processo de importação de imagem que usa o assistente Importar do Marketplace
- Os recursos relacionados ao agente, como a atualização automatizada do agente (AAU)
- Universal Broker
- Recursos relacionados ao Cloud Monitoring Service (CMS)
- Principalmente para implantação de pod e atualizações de pod
-
Você deve garantir que os nomes de host a seguir possam ser resolvidos e acessados pelas sub-redes de gerenciamento e tenant usando as portas e os protocolos específicos, conforme indicado nas tabelas a seguir. Os dispositivos usados nesses fluxos de trabalho usam portas de saída específicas para baixar com segurança o software de que esses processos precisam para o seu ambiente do Microsoft Azure. Esses nomes DNS também são usados para que os dispositivos relacionados ao fluxo de trabalho apropriados possam se comunicar com a camada de controle de nuvem.
Para novas implantações de pod, você deve configurar as regras do firewall de rede, do grupo de segurança de rede (NSG) e os servidores proxy, de forma que os principais dispositivos relacionados à implantação tenham a capacidade de entrar em contato com os endereços DNS nas portas necessárias. Caso contrário, o processo de implantação do pod falhará.
- Quando você estiver usando o recurso para implantar o gateway externo na própria VNet
- A sub-rede de gerenciamento nessa VNet deve 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.
- Quando você está implantando o pod com um gateway externo, um gateway interno ou ambos
- Você deve carregar um certificado que o implantador de pod configurará nessas configurações de gateway. Se o certificado ou os certificados que você fornecer para essa finalidade usarem as CRLs (listas de certificados revogados) ou as configurações de OCSP (protocolo de status de certificados on-line) que se referem a nomes DNS específicos, você deverá garantir que o acesso à internet de saída na VNet para esses nomes DNS seja resolvível e acessível. Durante a configuração do certificado fornecido na configuração do gateway do Unified Access Gateway, o software do Unified Access Gateway consultará esses nomes DNS para verificar o status de revogação do certificado. Se esses nomes DNS não estiverem acessíveis, a implantação do pod falhará durante a fase de Conexão. Esses nomes são altamente dependentes da autoridade de certificação que você usou para obter os certificados e, portanto, não estão no controle da VMware.
- Quando você planeja usar os recursos do App Volumes on Azure
- O implantador de pod provisiona uma conta de armazenamento do Azure para uso pelos recursos do App Volumes on Azure do pod, no grupo de recursos dos gerenciadores de pods. Quando provisionada, a Azure Cloud atribui um nome de domínio completo (FQDN) a essa conta de armazenamento que tem o padrão *.file.core.windows.net, em que * é o nome da conta de armazenamento gerado pelo Azure. Esse FQDN deve ser resolvido pelo seu servidor DNS para que o App Volumes possa acessar e montar os compartilhamentos de arquivos subjacentes a essa conta de armazenamento e fornecer a funcionalidade do App Volumes. Você deve garantir que o seu servidor DNS resolva esse FQDN em todos os momentos para os processos do App Volumes Manager que são executados dentro das instâncias do gerenciador de pods e para o App Volumes Agent que é executado nos desktops do VDI. Esse é um endpoint do Microsoft Azure em seu ambiente de nuvem do Microsoft Azure, e a conexão é direta no espaço em nuvem do Microsoft Azure.
Requisitos de DNS para implantação de novo pod, atualizações de pod e operações de serviço que se aplicam em todo o tenant
A tabela a seguir descreve os requisitos de DNS para uma nova implantação de pod, atualizações de pod e operações de serviço aplicáveis em todo o tenant.
A partir do início de 2021, como resultado de um upgrade das instâncias regionais da camada de controle do serviço, o nome DNS d1mes20qfad06k.cloudfront.net não é mais necessário para nenhuma das instâncias regionais da camada de controle. Todas as instâncias da camada de controle regional agora usam o nome DNS hydra-softwarelib-cdn.azureedge.net. O conteúdo da tabela a seguir está alinhado com essa realidade atual.
| Origem da sub-rede | Destino (nome DNS) | Porta | Protocolo | Tráfego de Proxy (se configurado na implantação) | Finalidade |
|---|---|---|---|---|---|
| Gerenciamento | Um dos seguintes nomes, dependendo de qual instância da camada de controle regional está especificada em sua conta de tenant do Horizon Cloud. A instância regional é definida quando a conta é criada, conforme descrito em Implantações e integração ao Horizon Cloud para pods do Horizon e Microsoft Azure.
|
443 | TCP | Sim | Instância da camada de controle regional
|
| Gerenciamento | softwareupdate.vmware.com | 443 | TCP | Sim | 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. |
| Gerenciamento | hydra-softwarelib-cdn.azureedge.net | 443 | TCP | Não O gerenciador de pods e manifestos binários do Unified Access Gateway são armazenados aqui e servidos daqui. Esses manifestos são usados exclusivamente durante períodos de implantações e upgrades de gateways e pods. Essa conexão com esse endpoint está configurada para ser direta e não por meio de um proxy. |
Servidor de distribuição de conteúdo do Horizon Cloud. Na sub-rede de gerenciamento, este site é usado pelo serviço para baixar os binários necessários usados pela infraestrutura do pod. |
| Gerenciamento | packages.microsoft.com | 443 e 11371 | TCP | Não Esse site está fora do aplicativo e do serviço. Portanto, a conexão não usa o proxy configurado. Esse é um endpoint do Microsoft Azure em seu ambiente de nuvem do Microsoft Azure, e a conexão é direta no espaço em nuvem do Microsoft Azure. |
Servidor de pacote de software da Microsoft. Usado para baixar com segurança o software Interface de Linha de Comando (CLI) do Microsoft Azure. |
| Gerenciamento | azure.archive.ubuntu.com | 80 | TCP | Não Esse site está fora do aplicativo e do serviço. Portanto, a conexão não usa o proxy configurado. Esse é um endpoint do Microsoft Azure em seu ambiente de nuvem do Microsoft Azure, e a conexão é direta no espaço em nuvem do Microsoft Azure. |
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 | Não Esse endpoint está fora do aplicativo e do serviço. A conexão não usa o proxy configurado. |
Servidor de pacote de software do Ubuntu. O gerenciador de pods e as instâncias do Unified Access Gateway executam sistemas operacionais Ubuntu. Esses sistemas operacionais Ubuntu estão configurados para obter atualizações desses sistemas operacionais Ubuntu deste site do Ubuntu. |
| Gerenciamento | archive.ubuntu.com | 80 | TCP | Não Esse endpoint está fora do aplicativo e do serviço. A conexão não usa o proxy configurado. |
Servidor de pacote de software do Ubuntu. O gerenciador de pods e as instâncias do Unified Access Gateway executam sistemas operacionais Ubuntu. Esses sistemas operacionais Ubuntu estão configurados para obter atualizações desses sistemas operacionais Ubuntu deste site do Ubuntu. |
| Gerenciamento | changelogs.ubuntu.com | 80 | TCP | Não Esse site está fora do aplicativo e do serviço. Portanto, a conexão não usa o proxy configurado. |
Servidor de pacote de software do Ubuntu. O gerenciador de pods e as instâncias do Unified Access Gateway executam sistemas operacionais Ubuntu. Esses sistemas operacionais Ubuntu estão configurados para usar este site do Ubuntu para rastrear as atualizações do sistema operacional Ubuntu. |
| Gerenciamento | security.ubuntu.com | 80 | TCP | Não Esse endpoint está fora do aplicativo e do serviço. A conexão não usa o proxy configurado. |
Servidor de pacote de software do Ubuntu. O gerenciador de pods e as instâncias do Unified Access Gateway executam sistemas operacionais Ubuntu. Esses sistemas operacionais Ubuntu estão configurados para usar este site do Ubuntu para atualizações do sistema operacional Ubuntu relacionadas à segurança. |
| Gerenciamento | esm.ubuntu.com | 80 e 443 | TCP | Não Esse endpoint está fora do aplicativo e do serviço. A conexão não usa o proxy configurado. |
Servidor de pacote de software do Ubuntu. O gerenciador de pods e as instâncias do Unified Access Gateway executam sistemas operacionais Ubuntu. Esses sistemas operacionais Ubuntu são configurados para usar este site do Ubuntu para rastrear atualizações de segurança para CVEs (Vulnerabilidades e Exposições Comuns) altos e críticos no sistema operacional base Ubuntu e na infraestrutura de dimensionamento horizontal. |
| Gerenciamento | Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você está implantando seu pod:
|
443 | TCP | Sim | 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. |
| Gerenciamento | Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você está implantando seu pod:
|
443 | TCP | Sim | 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. |
| Gerenciamento | Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você está implantando seu pod:
|
443 | TCP | Sim | 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 | 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:
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 do banco de dados. Esse nome segue o padrão *.postgres.database.azure.com. |
5432 | TCP | Não Esse endpoint é o serviço do banco de dados Microsoft Azure PostgreSQL em seu ambiente de nuvem do Microsoft Azure. A conexão é direta dentro do espaço de nuvem do Microsoft Azure. |
Usado para comunicação de pod com o serviço do banco de dados PostgreSQL do Microsoft Azure que está configurado para essa implantação do Horizon Cloud on Microsoft Azure. 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. |
| Gerenciamento | Um dos seguintes nomes, dependendo de qual instância da camada de controle regional está especificada em sua conta de tenant do Horizon Cloud. A instância regional é definida quando a conta é criada, conforme descrito em Implantações e integração ao Horizon Cloud para pods do Horizon e Microsoft Azure.
|
443 | TCP | Sim | Instância regional do serviço Universal Broker
|
| Gerenciamento | Dependendo de qual camada de controle regional se aplica à sua conta do Horizon Cloud:
|
443 | TCP | Sim | Cloud Monitoring Service (CMS) |
| Gerenciamento |
|
443 | TCP | Não | O endpoint *.blob.core.windows.net é usado para acesso programático ao Azure Blob Storage. Esse endpoint é um endpoint do Microsoft Azure no seu ambiente de nuvem do Microsoft Azure e a comunicação com esse endpoint vai direto para o espaço de nuvem do Microsoft Azure. O endpoint sauron-jp.horizon.vmware.com permite que o sistema de monitoramento da VMware detecte eventos de segurança nas instâncias gerenciadas pela VMware. Ativa a responsabilidade de gerenciamento da VMware pelas instâncias implantadas, que exige o monitoramento obrigatório do sistema VMware dessas instâncias. |
| Locatário | hydra-softwarelib-cdn.azureedge.net | 443 | TCP | Não | Servidor de distribuição de conteúdo do Horizon Cloud. Na sub-rede do tenant, esse site é usado por vários processos relacionados à imagem do sistema, incluindo processos envolvidos no fluxo de trabalho de Importação de Imagem do Marketplace automatizado do sistema e no fluxo de trabalho de emparelhamento do agente. |
| Locatário | scapi.vmware.com | 443 | TCP | Não | VMware Cloud Services, usado para o programa VMware Service Usage Data. Na saída da sub-rede do tenant, o Horizon Agent nas instâncias de área de trabalho provisionadas pelo pod e as instâncias do servidor de farm enviam informações de configuração relacionadas ao agente. |
| Locatário | *.file.core.windows.net | 445 | TCP | Não Esse endpoint é o serviço de Armazenamento de Arquivos do Microsoft Azure em seu ambiente de nuvem do Microsoft Azure. A conexão é direta dentro do espaço de nuvem do Microsoft Azure. |
Usado para a funcionalidade do App Volumes on Azure. Usado para acesso programático ao compartilhamento de arquivos SMB no grupo de recursos do gerenciador de pods para acessar os AppStacks do App Volumes que estão armazenados nesse compartilhamento. |
Requisito obrigatório de monitoramento do sistema VMware: monitor.horizon.vmware.com
O requisito obrigatório descrito nesta seção permite que o sistema de monitoramento da VMware detecte eventos de segurança nas instâncias gerenciadas da VMware que são implantadas nas sub-redes de gerenciamento, tenant e DMZ da implantação do Horizon Cloud on Microsoft Azure.
Para uma implantação do Horizon Cloud on Microsoft Azure, a VMware controla e gerencia esses recursos na implantação: instâncias de gerenciador de pods, instâncias do Unified Access Gateway, arquivos do Azure relacionados a App Volumes, serviço Azure PostgreSQL e, quando necessário para situações de solução de problemas, a instância de jumpbox relacionada ao suporte.
A responsabilidade de gerenciamento da VMware pelas instâncias implantadas requer o monitoramento obrigatório do sistema VMware dessas instâncias.
O monitoramento do sistema VMware exige que você atenda aos requisitos descritos abaixo.
Em termos de uma descrição de alto nível, as instâncias da implantação devem alcançar na saída o nome de host monitor.horizon.vmware.com na porta 1514 (TCP e UDP) e na porta 1515 (TCP e UDP).
- Requisito aplicável quando sua rede tem a inspeção SSL ativada
- Quando a inspeção SSL está ativada na rede, você deve especificar para excluir o host monitor.horizon.vmware.com.
- Requisito aplicável quando a implantação tem uma configuração de gateway interno
-
Você deve estabelecer a comunicação de saída para a configuração de gateway interno seguindo todas as etapas e informações no
artigo 90145 da Base de conhecimento. Siga o artigo da Base de conhecimento conforme descrito, incluindo as notas finais no final do artigo da Base de conhecimento.
Em seguida, se você estiver usando o proxy ou firewall adicionalmente para comunicação de saída, deverá atender ao seguinte requisito aplicável ao usar o proxy ou o firewall para comunicação de saída.
- Requisito aplicável quando você estiver usando um proxy ou firewall para comunicação de saída
-
Ao usar o proxy ou firewall para a comunicação de saída, você deve permitir a comunicação no proxy ou firewall da seguinte maneira:
- Ambientes comerciais: permita a configuração de nome de host monitor.horizon.vmware.com em 1514 (TCP e UDP) e 1515 (TCP e UDP)
- Ambientes federais dos EUA: abra um caso com o suporte federal da VMware para solicitar o nome do host do sistema de monitoramento.
Nesses ambientes, você deve permitir essa comunicação mencionada anteriormente para estas fontes:
- Gerenciamento: as instâncias do gerenciador de pods
- DMZ: as instâncias do Unified Access Gateway da configuração de gateway externo
- Tenant: as instâncias do Unified Access Gateway da configuração do gateway interno
Observação: Quando a implantação tem uma configuração do gateway interno, você deve atender ao requisito descrito anteriormente que é aplicável à configuração do gateway interno, às etapas no artigo 90145 da Base de conhecimento.
Se necessário para uma solicitação de suporte ativo, portas e protocolos de jumpbox temporários
Se você fizer uma solicitação de suporte à VMware e a equipe de suporte determinar que a maneira de se usar essa solicitação é implantar uma VM de jumpbox temporária para comunicação SSH com os dispositivos gerenciados pela VMware, essa jumpbox exigirá as portas e os protocolos descritos aqui.
Uma permissão será solicitada a você para uma implantação de jumpbox relacionada ao suporte. A equipe de suporte da VMware informará sobre quaisquer requisitos, conforme apropriado para qualquer situação de suporte.
Essa VM de jumpbox relacionada ao suporte foi projetada para se comunicar como origem para os seguintes destinos:
- A porta 22 das VMs do gerenciador de pods do pod usando SSH e a porta 22.
- A porta 9443 das VMs do Unified Access Gateway usando HTTPS.
- A porta 22 da VM do conector do gateway usando SSH em uma implantação em que o gateway externo é implantado na própria VNet.
Como essas VMs recebem endereços IP dinamicamente, as seguintes regras de rede podem fornecer as comunicações descritas. Todas as atividades de solicitação de suporte, sempre procure orientação e supervisão do Suporte da VMware para requisitos para a implementação de jumpbox relacionada ao suporte.
- 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.
- 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.
