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 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:

  • Os nomes de série que são usados na documentação do Microsoft Azure
  • Os nomes da família de vCPUs que são usadas nas cotas exibidas no portal do Microsoft Azure
  • 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.

VMs jumpbox

As VMs jumpbox são criadas temporariamente nas assinaturas do Microsoft Azure para os fins descritos nas tabelas abaixo.

Tabela 1. 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.
Tabela 2. Quando se tem o gateway externo em uma VNet separada: requisitos de VM jumpbox
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 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.

VMs do gerenciador de pods

Essas VMs geralmente são consideradas o coração do pod. As VMs do gerenciador de pods são responsáveis por realizar a intermediação da conexão dos clientes do usuário final com o software do Horizon Agent executado nas áreas de trabalho virtuais provisionadas pelo pod.

Tabela 3. Requisitos de VM de gerenciamento de pod - Para as VMs principais do pod, sem incluir as configurações de gateway
VM Especificação de VM do Microsoft Azure Quantidade Descrição
Pod sem alta disponibilidade habilitada: instâncias de gerenciamento de pod Linux - Família Dv3 padrão:

Standard_D4_v3 (4 núcleos, 16 GB de memória).

Disco de SO: padrão HDD 30 GiB

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 disponibilidade: instâncias de gerenciamento de pod Linux - Família Dv3 padrão:

Standard_D4_v3 (4 núcleos, 16 GB de memória).

Disco de SO: padrão HDD 30 GiB

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.

O tamanho do seu ambiente deve acomodar as 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, tendo em vista 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.

VMs relacionadas ao gateway

As VMs relacionadas ao gateway são:

  • As instâncias do Unified Access Gateway configuradas para funcionar como gateways seguros para os clientes de usuário final que acessam os recursos provisionados pelo pod.
  • Quando você implanta o gateway externo em uma VNet separada, a VM do conector de gateway que lida com as operações de gerenciamento de nuvem nessa configuração de gateway externo.
Observação: A partir da versão trimestral de julho de 2020, você poderá escolher em uma lista de modelos de VM compatíveis para as instâncias do Unified Access Gateway quando estiver implantando um novo gateway, seja no momento da implantação do pod inteiro, seja ao adicionar um novo gateway. Antes da versão de julho de 2020, as instâncias de gateway eram necessárias para usar o modelo de VM Standard_A4_v2. A lista de modelos de VM compatíveis disponíveis para escolha no assistente na tela dependerá dos modelos de VM disponíveis na região do Microsoft Azure na qual você está implantando as instâncias do gateway. As opções exibidas também dependerão da sua quota de VM na assinatura do Microsoft Azure que você está usando para a implantação do gateway. O menu Modelo de VM do assistente de implantação de pod refletirá dinamicamente os modelos de VM que atendem a esses requisitos.

As atualizações de software manterão os modelos de VM das instâncias de gateway. Qualquer que seja o modelo de VM das instâncias de gateway antes de uma atualização do pod, ele será mantido após a atualização.

Tabela 4. Requisitos de VM do Unified Access Gateway
VM Especificação de VM do Microsoft Azure Quantidade Descrição
Instâncias do Unified Access Gateway A partir desta versão, você pode escolher entre os modelos de VM a seguir para novas implantações de gateway.
  • Família Linux Standard Av2 — Standard_A4_v2 (4 núcleos, 8 GB de memória), disco do SO: HDD padrão de 20 GiB
  • Família Linux Standard FSv2:
    • Standard_F8s_v2 (8 núcleos, 16 GB de memória), disco do SO: SSD de 32 GiB

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:
  • 2 por pod durante as operações em estado estável
  • 4 por pod durante o tempo de ponta-a-ponta para atividades de atualização azul/verde relacionadas a pod.
Para um pod com tanto uma configuração interna quanto uma externa do Unified Access Gateway,
  • 4 por pod durante as operações em estado estável
  • 8 por pod durante o tempo de ponta a ponta para atividades de atualização azul/verde relacionadas ao 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 atualização, 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.

O tamanho do seu ambiente deve acomodar as 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.

Tabela 5. Quando se tem o gateway externo em um VNet separada: requisitos de VM de conector de gateway
VM Especificação de VM do Microsoft Azure Quantidade Descrição
Instância do conector do gateway Família Av2 padrão do Linux:

Standard_A1_v2 (1 núcleo, 2 GB de memória)

Disco de SO: padrão HDD 10 GiB

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.

VMs de imagem mestre

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. Às vezes, essas VMs são chamadas de padrões dourados ou imagens douradas.

Tabela 6. Requisitos da VM de imagem
VM Especificação de VM do Microsoft Azure Quantidade Descrição
Imagens mestres

As imagens mestres são ativadas para GPU ou não, dependendo da sua seleção quando você as cria.

Para imagens mestre habilitadas por GPU, o sistema usa:

  • A NV6 Padrão série NV (das vCPUs da Família NV Padrão)
  • Disco de SO: HDD padrão de 127 GiB

Variado, com base em suas necessidades.

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:

  • Áreas de trabalho RDSH usando o Microsoft Windows 2016 Datacenter, sem GPU
  • Á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 mestra quando ela é publicada (quando você executa a ação Converter para Imagem na imagem mestra do console administrativo). Quando você atualiza uma imagem publicada, o sistema liga a VM novamente.

Observação: Ao duplicar uma imagem usando o console, 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:

  • A Standard_D4_v3 (das vCPUs da família Dv3 padrão)
  • Disco de SO: HDD padrão de 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:

  • A Standard_D2_v3 (das vCPUs da família Dv3 padrão)
  • Disco de SO: HDD padrão de 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.

VMs de farm

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.

Observação: Na versão de manutenção atual, você não poderá oferecer áreas de trabalho baseadas em sessão e aplicativos remotos do mesmo farm.
Tabela 7. Requisitos da VM de farm
VM Especificação de VM do Microsoft Azure Quantidade Descrição
Farm RDSH

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. Estes critérios do Horizon Agent são declarados na documentação do produto Horizon a partir da versão 7.8 (as referências a um mínimo de 2 CPUs começam com esta versão 7.8 de instalação do Horizon Agent em uma máquina virtual).
Variado, com base em suas necessidades e em como você personalizou os tamanhos de VM no seu ambiente do Horizon Cloud.

O estado de energia dessas VMs varia dependendo das definições de configuração do farm e da demanda de usuários finais.

VMs de área de trabalho VDI

As VMs de área de trabalho VDI são as instâncias que fornecem áreas de trabalho VDI aos seus usuários finais.

Observação: Uma nova funcionalidade na versão de manutenção trimestral de julho de 2020 é o uso de App Volumes recursos com pods no Microsoft Azure. Quando você usa o processo de captura do App Volumes do console para adicionar aplicativos nativos ao inventário do Horizon Cloud, o sistema cria uma atribuição de área de trabalho VDI de duas VMs para oferecer suporte ao processo de captura. O tipo de VM usado para essa atribuição gerada pelo sistema é o mesmo modelo usado para a imagem publicada que você selecionou no console para o processo de captura do aplicativo.
Tabela 8. Requisitos de VMs de área de trabalho VDI
VM Especificação de VM do Microsoft Azure Quantidade Descrição
Áreas de trabalho VDI

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 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 nas suas atribuições de área de trabalho VDI, consulte o Guia de administração do Horizon Cloud.

Observação: Um pequeno conjunto de tamanhos de VM do 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.

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 ter no mínimo 2 CPUs para instalar ou atualizar o Horizon Agent da versão 7.x ou posterior. Estes critérios do Horizon Agent são declarados na documentação do produto Horizon a partir da versão 7.8 (as referências a um mínimo de 2 CPUs começam com esta versão 7.8 de instalação do Horizon Agent em uma máquina virtual).
Variado, com base em suas necessidades e em como você personalizou os tamanhos de VM no seu ambiente do Horizon Cloud.

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.