Quando o Horizon Cloud encontra erros no processo de atualização do pod que bloqueiam seu progresso e que você pode solucionar, esses erros são exibidos no console de administração, para que você possa tomar as medidas necessárias para solucioná-los. Esses erros bloqueadores de progresso exibidos podem ser controlados por você no seu ambiente do Microsoft Azure. Como a solução está no seu controle e não pode ser resolvida pela VMware, se você vir uma notificação de erros de atualização no console, deverá concluir as ações para resolvê-las e entrar em contato com o suporte da VMware para continuar o processo de atualização do pod.

Atualizando seu pod do Horizon Cloud descreve como o processo de atualização funciona para um pod implantado no Microsoft Azure. Em geral, o processo de atualização segue um padrão azul/verde, em que os recursos de pod existentes a serem atualizados no grupo de recursos principal do pod e nos grupos de recursos relacionados ao gateway são os componentes azuis. A primeira etapa do processo é a criação de um grupo de recursos jumpbox em sua assinatura e a implantação de uma VM jumpbox nesse grupo de recursos. Em seguida, essa VM jumpbox orquestra a criação de um conjunto paralelo de VMs de pod na sua assinatura, dentro dos grupos de recursos existentes do pod. Esse conjunto paralelo são os componentes verdes no padrão azul/verde. Os componentes verdes incluem as VMs paralelas às do grupo de recursos principal e do grupo de recursos relacionados ao gateway do pod, como as VMs do gerenciador de pods e as VMs do Unified Access Gateway. Essas VMs são iniciadas e permanecem em execução juntamente com as VMs do pod a ser atualizado (as VMs do conjunto azul), até que o processo de atualização completo seja concluído. O processo de atualização completo terminará somente depois que você usar o console para agendar a atualização e quando a atividade programada for executada e terminar de fazer com que o pod deixe de usar as VMs azuis e passe a usar as VMs verdes. Quando o pod está usando as VMs verdes, as VMs azuis são interrompidas e removidas, e a VM jumpbox e seus recursos são excluídos.

A criação das VMs verdes não poderá ser concluída com sucesso se o seu ambiente do Microsoft Azure não puder acomodar a criação dessas VMs verdes paralelas junto com as VMs de pod existentes. Um motivo-chave típico pelo qual isso ocorre é quando a assinatura associada do Microsoft Azure do pod não tem quota suficiente para instanciar a VM jumpbox e as VMs verdes. Outro motivo pelo qual compilar as VMs verdes pode causar erros é se o seu pod estiver off-line no momento. No momento em que você agenda a atualização no console, o Horizon Cloud implanta a VM jumpbox para que ela possa rastrear o agendamento e estar pronta para começar a migração do pod para os componentes mais recentes no momento programado. Se a assinatura do Microsoft Azure associada do pod não tiver uma quota suficiente para instanciar a VM jumpbox e mantê-la funcionando pelo período do tempo agendado e quando a mudança para as VMs verdes for concluída, um erro de atualização será sinalizado para notificação no console.

Para obter uma descrição das várias atividades do sistema no processo completo de atualização do pod, consulte Atualizando seu pod do Horizon Cloud.

Erros de bloqueio de atualização que podem ocorrer normalmente

Esses são os erros de bloqueio de atualização que podem ocorrer normalmente e que você pode corrigir no seu ambiente Microsoft Azure.

A assinatura não tem a capacidade disponível para instanciar a VM jumpbox.
O processo de atualização é projetado para instanciar uma VM jumpbox na assinatura do pod quando o sistema criar os componentes verdes, quando você usar o agendador para agendar a atualização e, na hora agendada, para orquestrar a mudança dos componentes azuis para os verdes. Essa VM de caixa de salto orquestra o trabalho para obter os novos componentes prontos e executar o processo de migração real. Juntamente com o uso de quota atual pelas VMs dos pods existentes que estão usando a mesma assinatura, a quota da sua assinatura precisa permitir uma VM adicional da especificação Standard_F2 VM, 2 núcleos (vCPUs). Esse requisito de quota é complementar aos tipos e núcleos de VM necessários para a criação das VMs verdes paralelas.
A assinatura não tem os núcleos apropriados suficientes (vCPUs) ou tamanhos de VM disponíveis para instanciar todas as VMs das VMs verdes paralelas.
Quando os componentes verdes são criados, para cada VM no seu pod atual outra VM é criada. Como resultado, você terá um número duplicado de VMs de gerenciador de pods e VMs do Unified Access Gateway a partir do momento em que os componentes verdes são criados até que a mudança dos componentes azuis para os verdes ocorra no momento agendado no console. Para acomodar a criação dessas VMs verdes, os níveis de quota da sua assinatura para núcleos (vCPUs) das famílias relevantes de VMs da Microsoft devem ser suficientes para englobar as VMs verdes paralelas, juntamente com a quota que você já usou da assinatura para os pods associados existentes. Consulte para os núcleos necessários dos vários tipos e usos de VM.
O pod está offline no momento ou não consegue se comunicar com o Horizon Cloud.
Na página Capacidade, verifique se o pod a ser atualizado está relatando o status online. Faça login no portal do Microsoft Azure e verifique se a VM do gerenciador de pod e suas VMs do Unified Access Gateway (se o seu pod as tiver) estão em execução. Se uma VM não estiver em execução, ligue-a. Para obter detalhes sobre os grupos de recursos nos quais essas VMs estão localizadas, consulte Grupos de recursos criados para um pod implantado no Microsoft Azure.

Quotas e núcleos necessários para o tempo de implantação das VMs verdes quando a alteração para o pod verde é concluída

Se você for notificado sobre um erro de atualização devido à falta de núcleos disponíveis, use a tabela a seguir para ver a cota adicional de que você precisa. Para os vários tipos de VM usados no pod azul atual, a tabela no final deste tópico descreve a quota usada por esses tipos, a quota adicional necessária quando as VMs do pod verde são criadas e a quota total necessária para executar VMs azuis e verdes a partir de quando as VMs verdes são criadas até a alteração para as VMs verdes ser concluída. Para obter detalhes sobre os tipos de família de VM e os núcleos usados por um pod, consulte o tópico da documentação Exigências de VM para um pod no Guia de Implantação.

Tipos de VM e seus núcleos Descrição Quota total para executar VMs azuis e verdes até que a alteração para verde seja concluída
Tipo de VM Standard_D4_v3, quatro núcleos cada
Observação: Se o tipo Standard_D4_v3 não estiver disponível na sua região do Microsoft Azure, seu pod normalmente usará o tipo de VM Standard_D3_v2. Esse tipo também usa quatro núcleos.
Esse tipo de VM é usado para as VMs de gerenciador de pods.
Para um pod com uma única VM de gerenciador
Sua quota deve permitir os 4 núcleos da VM de gerenciador existente (azul), mais 4 núcleos para a VM verde paralela de gerenciador. Oito (8) núcleos para abranger esse uso.
Para um pod com alta disponibilidade habilitada, que tem duas VMs de gerenciador
Sua quota deve permitir os 8 núcleos das VMs de gerenciador existentes (azul) (2 VMs com 4 núcleos cada), mais 8 núcleos para as VMs verdes paralelas de gerenciador. Dezesseis (16) núcleos para abranger esse uso.
Dependendo do que você escolheu ao implantar o pod:
  • Tipo de VM Standard_A4_v2 (tem 4 núcleos)
  • Standard_F8s_v2 (tem 8 núcleos)
Esse tipo de VM é usado para as VMs do Unified Access Gateway nas configurações de gateway do seu pod. O número de núcleos que sua assinatura precisa suportar depende dos tipos de gateway configurados no seu pod.
Para um pod com apenas um gateway externo
Esse gateway externo tem duas VMs do Unified Access Gateway e, portanto, duas VMs vezes o número de núcleos que elas contêm. Para o conjunto verde, sua quota deve permitir que o número total de núcleos das VMs existentes (azuis) do Unified Access Gateway, além de núcleos adicionais de número duplicado para as VMs verdes paralelas do Unified Access Gateway.
  • Por exemplo, se as suas VMs forem Standard_A4_v2 com quatro núcleos cada, você precisará de 2 vezes 4 vezes 2, igual a 16 núcleos, para abranger esse uso.
  • Se as suas VMs tiverem um tamanho de VM com oito núcleos cada, você precisará de 2 vezes 8 vezes 2, igual a 32 núcleos para abranger esse uso.
Para um pod com apenas um gateway interno
Esse gateway tem duas VMs do Unified Access Gateway e, portanto, duas VMs vezes o número de núcleos que elas contêm cada uma. Para o conjunto verde, sua quota deve permitir que o número total de núcleos das VMs existentes (azuis) do Unified Access Gateway, além de núcleos adicionais de número duplicado para as VMs verdes paralelas do Unified Access Gateway.
  • Por exemplo, se as suas VMs forem Standard_A4_v2 com quatro núcleos cada, você precisará de 2 vezes 4 vezes 2, igual a 16 núcleos, para abranger esse uso.
  • Se as suas VMs forem um tamanho de VM com oito núcleos cada, você precisará de 2 vezes 8 vezes 2, igual a 32 núcleos para abranger esse uso.
Para um pod com ambos os tipos de gateways
Esse gateway tem quatro VMs do Unified Access Gateway e, portanto, 4 VMs vezes o número de núcleos que elas contêm cada uma. Para o conjunto verde, sua cota deve permitir quatro vezes os núcleos das VMs existentes do Unified Access Gateway (azul) existentes e duas vezes novamente para as VMs verdes paralelas do Unified Access Gateway.
  • Por exemplo, se as suas VMs forem Standard_A4_v2 com quatro núcleos cada, você precisará de 4 vezes 4 vezes 2, igual a 32 núcleos para abranger esse uso.
  • Se as suas VMs tiverem um tamanho de VM com oito núcleos cada, você precisará de 4 vezes 8 vezes 2, igual a 64 núcleos para abranger esse uso.
VM Standard_F2, dois núcleos Essa VM é usada para a VM jumpbox. Sua quota deve permitir que esses dois núcleos da VM jumpbox sejam implantados e executados durante a criação dos componentes verdes e durante o tempo necessário para orquestrar as atividades de atualização do pod.