A VMware atualiza periodicamente os componentes de software do Horizon Cloud para incluir novos recursos, melhorias para a capacidade de suporte e resiliência do serviço, melhorias na experiência do usuário e correções de erros. A VMware geralmente atualiza o ambiente de gerenciamento na nuvem semanalmente e atualiza os componentes de software usados no pod implantado em uma base aproximadamente trimestral. Quando a VMware atualiza os componentes de software usados em um pod implantado, o número do manifesto para o software do pod vai para um número maior. Se houver melhorias consideradas importantes para a manutenção de um pod e para as operações de suporte, a VMware disponibilizará um novo manifesto, mesmo se o tempo estiver dentro de um quarto da versão anterior do manifesto. O processo de atualização normal ocorre sem que haja inatividade do sistema.

Importante: Se o pod já estiver integrado ao Workspace ONE Access hospedado em nuvem usando a versão 2017.12.1.0 antiga do conector do Linux, você deverá atualizar o conector para a versão suportada mais recente antes de atualizar o pod. Para escolher a versão do conector compatível com esta versão do Horizon Cloud, consulte as Matrizes de interoperabilidade entre produtos VMware em https://www.vmware.com/resources/compatibility/sim/interop_matrix.php. Em seguida, atualize o conector existente seguindo as etapas para a sua versão do conector escolhida encontrada na documentação do VMware Workspace ONE Access. Depois de concluir a atualização do seu conector, atualize o pod.

Atualizar seu pod implantado significa mover adequadamente os componentes de infraestrutura atuais do pod para um nível de manifesto de software mais alto. Os componentes de infraestrutura são principalmente as VMs do gerenciador de pod e quaisquer VMs do Unified Access Gateway configuradas para o pod. Por exemplo, uma atualização do pod pode incluir atualizações para o software de gerenciamento do pod, para o software do Unified Access Gateway ou ambos.

Você pode usar a página Capacidade para ver quais pods têm atualizações disponíveis. Navegue até Configurações > Capacidade. A coluna Status do pod mostrará o ícone pendente em vez do ponto verde, o número da versão do pod será um hiperlink em vez de texto estático e, quando o cursor passar sobre esse número de versão, uma dica de ferramenta indicará que uma atualização está disponível. A captura de tela a seguir ilustra o comportamento descrito na frase anterior.


Horizon Cloud on Microsoft Azure: captura de tela da página Capacidade, mostrando um pod com uma atualização disponível e uma seta verde apontando para onde a dica de ferramenta é exibida.

Você pode ver os detalhes de atualização para um pod específico na respectiva página de detalhes do pod. Quando uma atualização está disponível, é exibida uma mensagem na tela descrevendo a atualização.


Horizon Cloud on Microsoft Azure: captura de tela da página de detalhes do pod mostrando mensagens.

Observação: Depois de atualizar um pod de versões anteriores às mais recentes, em seguida, você pode atualizar o software relacionado ao agente em atribuições de área de trabalho VDI, farms e imagens já publicadas do pod no mesmo nível de versão do agente que vem com a versão do pod atualizada. A atualização relacionada ao agente é feita em um processo separado da atualização no pod em si. Para obter as etapas sobre como atualizar o software relacionado ao agente depois que o pod é atualizado, consulte Atualizar o software do agente para imagens RDSH no Horizon Cloud, Atualizar o software do agente para atribuições de área de trabalho VDI dedicadas e Atualizar o software do agente para imagens usadas por atribuições de área de trabalho VDI flutuante.

Esse processo de atualização do pod do Horizon Cloud é padronizado após uma técnica da indústria de software conhecida como implantação azul/verde.


Ilustração conceitual do processo de atualização azul/verde.

Os componentes de pod existentes a serem atualizados são considerados componentes azuis. Logo após a VMware lançar um novo manifesto de pod, a equipe de operações do VMware Horizon Service executa algumas verificações prévias e, em seguida, designa sua conta de cliente do Horizon Cloud conforme disponível para usar a nova versão do manifesto. No point-in-time quando essa nova versão do manifesto é designada na sua conta de cliente, o serviço cria um conjunto verde de componentes para o pod na sua assinatura do Microsoft Azure. Esse conjunto verde é um ambiente paralelo dos componentes azuis existentes.

Observação: Nem todo o processo de atualização do pod adere exatamente a um padrão de implantação de blue-green da indústria de software. Como um exemplo, no processo de atualização do pod, quando as instâncias mais recentes são criadas junto com as existentes, as outras mais recentes são ligadas e permanecerão em execução até que o pod tenha concluído a migração para as novas instâncias. Além disso, após o implantador que valida o pod ser executado com êxito nos componentes mais recentes, as máquinas virtuais mais antigas são excluídas em vez de permanecerem em um estado ocioso.

Processo de ponta-a-ponta

A partir de quando a equipe de operações da VMware designa a sua conta de cliente para usar a nova versão do manifesto, a sequência de ponta-a-ponta é:

  1. O serviço cria um grupo de recursos jumpbox na assinatura do pod e implanta uma VM jumpbox. Essa VM jumpbox orquestra a criação do conjunto verde de componentes.
  2. O conjunto verde de componentes é criado junto com os componentes azuis, nos mesmos grupos de recursos. No grupo de recursos de gerenciamento de pod, o conjunto verde de VMs do gerenciador de pods e seus artefatos associados, como NICs e discos, são criados. Nos grupos de recursos relacionados ao gateway do pod, o conjunto verde de VMs do Unified Access Gateway e seus artefatos associados são criados. Essas VMs verdes são iniciadas e mantidas em execução até que toda a sequência de ponta-a-ponta seja concluída. A VM jumpbox e seu grupo de recursos são excluídos quando os componentes verdes são construídos e executados com êxito.
    Importante: A partir desse ponto da sequência até a última etapa da sequência, há um número duplicado de VMs em execução: as VMs azuis e as VMs verdes. Portanto, é prudente programar que o fluxo de trabalho da atualização mude para o novo software de pod assim que você vir a faixa de notificação de que a atualização está disponível e que a agende para um dia e hora antes, em vez de depois.

    Esse processo não causa nenhum tempo de inatividade, e as VMs paralelas não afetam as operações do pod. A menos que o sistema encontre erros que somente você possa resolver no ambiente do Microsoft Azure, nenhuma ação é necessária nesse momento. Se o serviço encontrar algum problema na implantação dos componentes verdes, ele detectará se a solução para esses problemas está dentro do seu controle. Se o serviço determinar que você pode corrigir os problemas, uma notificação será exibida no console de administração. 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. Para obter detalhes sobre os tipos de problemas que você pode corrigir, consulte Núcleos necessários para atualizar um pod do Horizon Cloud no Microsoft Azure e soluções para erros típicos de atualização de pods. Se o serviço determinar que um problema pode ser resolvido pela equipe de operações da VMware, ele alertará a equipe, que por sua vez resolverá o problema sem que você precise fazer algo.

  3. Na página de detalhes do pod, é exibida uma faixa informando que uma atualização está disponível e que você pode agendar o dia e a hora para fazer a mudança.
    Horizon Cloud on Microsoft Azure: captura de tela da página de detalhes do pod mostrando mensagens atualizadas.

  4. Em seguida, você deverá agendar a atualização para fazer com que o pod deixe de usar seus componentes e VMs azuis atuais e passe a usar os verdes. Agende essa atualização na página de resumo do pod, selecionando Atualizar > Agendar Atualizações. Você define o dia e a hora em que o serviço fará com que o pod comece a usar os novos componentes verdes. O serviço implanta uma VM jumpbox para configurar o programador no pod e, em seguida, exclui a VM jumpbox até o dia e a hora agendados.
    Importante: Antes de a atualização ser executada, remova todos os bloqueios de gerenciamento no Microsoft Azure que você possa ter configurado em máquinas virtuais (VMs) do pod. Pertence ao pod qualquer VM com nomes que incluam vmw-hcs- podID, onde podID é o valor de ID do pod. No Microsoft Azure é possível usar o portal do Microsoft Azure para bloquear recursos a fim evitar alterações neles. Esses bloqueios de gerenciamento podem ser aplicados em um grupo de recursos inteiro ou em recursos individuais. Se você ou sua organização tiver aplicado bloqueios de gerenciamento nas VMs do pod, esses bloqueios deverão ser removidos antes da atualização ser executada. Caso contrário, o processo de atualização não será concluído com êxito. Você pode localizar o valor de ID do pod na página de detalhes do pod, a partir da página Capacidade.

    Determine a hora conveniente para que a atualização seja implantada. Geralmente, a atualização em si, ou a migração da versão existente para a nova versão, demora aproximadamente dez minutos. Como uma prática recomendada, programe a atualização em um momento quando o ambiente estiver menos ocupado. Depois que a atualização for agendada, o console exibirá a hora agendada em uma faixa superior. Você pode reagendar o tempo para a atualização a qualquer momento antes do horário agendado, se exigido pelas necessidades da sua organização.

    Importante: Quando você programa a atualização na página de detalhes do pod, é solicitado a fornecer uma data e hora. Essa hora é local para o seu fuso horário de navegador.

    Horizon Cloud on Microsoft Azure: captura de tela da página Capacidade com a faixa superior mostrando a hora da atualização do pod agendada.

  5. No dia e hora selecionados, o serviço implanta novamente uma VM jumpbox para orquestrar a mudança para o pod usar as VMs e os componentes verdes. Os componentes verdes se tornam os componentes azuis atuais. O processo leva de cinco a quinze minutos para ser concluído, e leva mais tempo para os pods que têm as configurações externa e interna do Unified Access Gateway. O processo migra os dados e as configurações da infraestrutura do pod existente a ser atualizada para a nova.

    Durante a migração, aplicam-se as seguintes limitações:

    • Você não pode realizar tarefas administrativas no pod que está passando pela atualização.
    • Os usuários finais que não têm sessões conectadas às suas áreas de trabalho virtuais ou aplicativos remotos atendidos pelo pod de atualização e que tentam se conectar não podem fazer isso.
    • Os usuários finais que têm sessões conectadas atendidas pelo pod que está atualizando terão estas sessões ativas desconectadas. Após a conclusão da migração, esses usuários podem se reconectar. Nenhuma perda de dados pode ocorrer, a menos que você tenha usado a opção Imediatamente para o gerenciamento de tempo limite em farms e atribuições de área de trabalho VDI.
    Cuidado: Os usuários com sessões conectadas a áreas de trabalho ou aplicativos remotos atendidos por farms e atribuições de área de trabalho VDI com a opção Fazer Logoff das Sessões Desconectadas definida como Imediatamente serão desconectados imediatamente e essas sessões desconectadas também terão o logoff feito imediatamente. Nessas mesmas condições, qualquer usuário em andamento será perdido.

    Para evitar perda de dados do usuário final em andamento para esse cenário, antes de iniciar o processo de migração, ajuste a configuração de Fazer Logoff das Sessões Desconectadas em farms e atribuições de área de trabalho VDI para um valor de tempo que dará a esses usuários tempo para salvar o trabalho deles. Em seguida, após a conclusão da atualização, você pode alterar a configuração de volta para antes.

  6. Depois que tudo é migrado para o novo ambiente, e o pod é executado com êxito nas novas instâncias, o sistema exclui as VMs azuis dos grupos de recursos do pod, bem como do grupo de recursos jumpbox e seu conteúdo. Alguns artefatos, como os NICs para as instâncias do Unified Access Gateway anteriores, permanecem para preservar os valores de configuração necessários para a próxima atualização do pod.

Após a conclusão do processo ponta-a-ponta

Quando a migração para os componentes verdes terminar, você poderá realizar tarefas administrativas no pod. Para ver a versão do software que um pod está executando no momento, selecione Configurações > Capacidade e clique no pod para abrir a página Resumo. A página exibe a versão do software que está sendo executada atualmente. Clique no número da versão do software para ver as informações de versão associadas.

Pós-atualização

Importante: Se o servidor Radius configurado for implantado na mesma VNet, após a migração dos novos elementos de infraestrutura, você deverá atualizar as configurações no seu servidor Radius para aceitar os novos endereços IP privados das novas VMs internas do Unified Access Gateway. Esse é um requisito único para a primeira atualização no pod e não precisa ser repetido para as futuras atualizações do pod.
Importante: A partir da versão de serviço trimestral de setembro de 2019, a arquitetura de pods é atualizada para oferecer suporte à capacidade de ter alta disponibilidade (HA). Mesmo quando o recurso de alta disponibilidade não está habilitado, a nova arquitetura com capacidade de HA inclui um balanceador de carga Microsoft Azure na frente da VM de gerenciador do pod. Depois de atualizar seu pod para o manifesto 1600, se ele tiver sido configurado para conexões diretas, você deverá remapear as configurações de DNS para apontar ao endereço IP do balanceador de carga Azure do gerenciador de pods, que estará visível recentemente na página de detalhes do pod atualizado. Até que você atualize o mapeamento de DNS, mesmo que essas conexões de usuário diretas ainda funcionem, elas não terão o failover de alta disponibilidade para um pod habilitado para HA se a VM do gerenciador do agente ativo ficar inoperante. Nesse caso de uso, você mapeia um FQDN para o endereço IP no campo IP do balanceador de carga do gerenciador de pods, exibido na página de detalhes do pod, conforme descrito em Configurar certificados SSL nas VMs do gerenciador do pod do Horizon Cloud. Antes do manifesto do pod 1600, era esse IP o atribuído ao NIC da VM do gerenciador do pod na sub-rede do tenant. A partir do manifesto do pod 1600 ou posterior, o endereço IP do pod a ser mapeado é o endereço IP privado do balanceador de carga Microsoft Azure usado para as VMs de gerenciador do pod. Para pods existentes atualizados para a versão de manifesto desta versão, se você tiver configurado um nome DNS para apontar para o endereço IP do dispositivo do tenant de um pod com manifesto 1493.1 ou anterior, deverá remapear as configurações de DNS de forma que elas apontem ao endereço IP exibido para o rótulo IP do balanceador de carga do gerenciador de pods na página de detalhes do pod atualizado.