As atividades de manutenção do sistema incluem uma atualização automatizada dos componentes de software do pod para incluir novos recursos, bem como correções e melhorias para suporte ao serviço e resiliência. A atividade de manutenção que atualiza um pod existente para um manifesto mais recente é iniciada pelo sistema por meio do plano de nuvem em um dia e hora determinados pelo sistema. Para indicar sua preferência de que qualquer atividade de manutenção do sistema deva começar em uma hora e um dia da semana específicos, use o console para especificar a janela de manutenção preferencial de cada pod. Para um pod sem uma janela de manutenção preferencial especificada no console, será considerado que a VMware pode agendar uma manutenção nesse pod a qualquer momento, conforme conveniente para a VMware.

Quando os componentes de software usados em um pod implantado são atualizados para uma nova versão, o número de manifesto do pod aumenta para um número de versão mais alto, como 2632.0. Se houver melhorias consideradas importantes para a manutenção de um pod e para as operações de suporte, a VMware poderá criar um novo manifesto que seja uma versão pontual, como 2632.1. O console exibe o manifesto de um pod na página Capacidade.

O que saber sobre a manutenção do pod

A manutenção dos componentes de software VMware que compõem o pod Horizon Cloud implantado é uma operação necessária e obrigatória para manter a integridade e a estabilidade das áreas de trabalho virtuais e dos aplicativos provisionados por esse pod. Conforme descrito no PDF Descrição de serviço do Horizon, a VMware é responsável pelos componentes de software que residem no pod e que são baixados da camada de controle para esse pod. A Descrição de serviço do Horizon também descreve:

  • As funções e responsabilidades da VMware em torno dos procedimentos de gerenciamento de alterações para manter a integridade dos componentes de software que são baixados para o pod. As atividades de manutenção incluem a atualização dos componentes de software do pod.
  • A função e as responsabilidades do cliente em torno dos procedimentos de gerenciamento de alterações, incluindo a cooperação com a VMware quando uma manutenção agendada ou de emergência é necessária.

A Descrição de serviço do Horizon contém uma definição de manutenção agendada, janelas de manutenção e manutenção de emergência. Consulte esse documento para obter detalhes. No caso de quaisquer discrepâncias entre o conteúdo desta página de documentação e o conteúdo da Descrição de serviço do Horizon, o documento Descrição de serviço do Horizon tem precedência.

Atenção: Antes de o pod ser atualizado, você deve garantir que as VMs de imagem de pod, as VMs de farm e as VMs de área de trabalho VDI tenham o agente mais recente que está disponível para o pod. Se você não as atualizar para o agente mais recente antes da atualização do pod, após a atualização do pod, elas poderão estar executando versões incompatíveis do agente, o que colocará o pod em um estado não compatível. Como saber se precisa atualizar algum dos agentes? No console, veja se há pontos azuis ao lado de uma imagem ou atribuição. Se você vir pontos azuis, o objetivo será fazer com que todos os pontos azuis desapareçam do console antes da atualização do pod. Consulte Atualizações de pods do Horizon Cloud: etapas para compatibilidade e suporte contínuos de agentes

Especificar a janela de manutenção preferencial do pod

Para indicar sua preferência para que qualquer atividade de manutenção no pod comece em uma hora e um dia da semana específicos, use o console para especificar o que é chamado de janela de manutenção preferencial para esse pod. Na página Capacidade, navegue até a guia Manutenção na página de detalhes do pod. Procure o rótulo Hora de manutenção preferencial e siga os controles na tela para escolher um nome e uma hora (UTC) no dia seguinte. Você só pode escolher entre os padrões predefinidos do sistema exibidos.

Especifique a hora de manutenção preferencial para cada pod separadamente na página de detalhes de cada pod no console.

Observação: Para um pod sem uma janela de manutenção preferencial especificada no console, será considerado que você permite que a VMware agende uma manutenção nesse pod a qualquer momento, conforme conveniente para a VMware.

O sistema lerá o dia da semana e a hora que você especificar no console e incorporará esses dados no algoritmo de agendamento. Quando um novo manifesto de pod for definido como padrão no plano de nuvem, o agendador do sistema calculará a atualização real de dia e hora em que determinou que a atualização pode acontecer em cada pod em sua frota de pods. Embora o sistema faça o melhor para acomodar as horas de início de manutenção preferenciais especificadas na guia Manutenção do pod, não há garantias de que o sistema possa acomodar essa hora de início de manutenção preferencial para uma operação de atualização específica.

No momento em que este texto foi redigido, o agendador do sistema aloca quatro (4) horas para a duração da atividade de manutenção. A atualização de pod típica demora menos tempo do que essa duração alocada.

Alertas e notificações de manutenção

O sistema alertará e notificará os administradores do ambiente do tenant quando o sistema tiver agendado uma data e hora específicas para que a manutenção específica de determinado pod ocorra. Esses alertas e notificações incluem o seguinte:

No console
  • Uma faixa persistente na parte superior do console. A hora na faixa é a hora de manutenção local para o fuso horário de seu navegador, quando você exibe o console. A captura de tela a seguir é um exemplo no qual a atualização do pod está agendada para ocorrer às 16h, hora do leste nos Estados Unidos, em 7 de julho de 2020. Use o botão Exibir para clicar na página de detalhes do pod e veja mais informações sobre a manutenção agendada na guia Manutenção do pod.
    Exemplo de captura de tela da faixa no console que fornece informações sobre a manutenção agendada de um pod
  • Na guia Logs de Auditoria do pod e em Atividade > Logs de Auditoria do console, um log de auditoria registrará que um upgrade do pod está agendado pelas Operações da VMware. A linha de log de auditoria incluirá o UUID do pod.
  • Na guia Manutenção do pod, a seção Manutenção Agendada exibirá informações sobre a manutenção agendada.
E-mails
O sistema enviará e-mails sobre a manutenção do pod para os administradores do seu ambiente de tenant, aqueles especificados nas Configurações Gerais > Contas do My VMware do console. Os e-mails incluem um e-mail sobre a data e hora específicas do calendário da manutenção agendada quando o sistema foi definido. Exemplos de tais e-mails incluem lembretes periódicos nos dias e semanas anteriores a essa data e hora agendadas, bem como quando a atividade de manutenção é iniciada e quando ela é concluída.
Observação: Se você quiser reagendar uma data e hora de manutenção agendada, deverá entrar em contato com o Suporte da VMware.

Verificações prévias do sistema antes de realizar a manutenção do pod

Se receber um e-mail de notificação informando que um pod tem erros de atualização do pod ou se vir erros de atualização de pod no relatório do console para o pod, você deverá tomar medidas para corrigir a situação. Se isso acontecer, siga as instruções na tela do console ou as instruções do e-mail. A resolução habitual para esses erros normalmente requer que você tome medidas no Portal do Microsoft Azure, na assinatura do pod contida nele. Para obter informações adicionais sobre as soluções para erros típicos de atualização de pod, consulte Pods do Horizon Cloud: soluções para falhas comuns de verificação prévia.

Qual é a finalidade dessas verificações prévias? A atividade de manutenção para uma atualização do pod ocorre na assinatura do Microsoft Azure e nos grupos de recursos do pod. Pouco tempo antes de o sistema agendar uma data e hora específicas para uma atualização específica em determinado pod, o sistema executa uma operação de verificação prévia para determinar se existem condições que bloqueiam uma atualização bem-sucedida de um pod. Como exemplo de uma dessas verificações prévias, o sistema verifica se sua assinatura do Microsoft Azure tem vCores suficientes da série de VM apropriada para atender aos requisitos da atualização. Se uma das verificações prévias falhar e a condição exigir uma ação de sua parte para repará-la, ocorrerá o seguinte:

  • Um e-mail de notificação será enviado a você para alertá-lo sobre esse fato, com detalhes sobre as ações necessárias para corrigir o erro.
  • O console exibirá um alerta visual de que ações são necessárias, para que você retifique os erros de verificação prévia para esse pod.
Importante: Se você receber notificações sobre erros de upgrade do pod, execute as ações especificadas para corrigir os erros em tempo hábil. O tempo é essencial. Se você não agir para corrigir esses erros no tempo que a VMware requer, o pod entrará em um estado incompatível devido à falha em corrigir o processo de atualização do pod.

Atualizações de pod: visão geral de alto nível

Quando a atividade de manutenção é a atualização de um pod para uma versão mais recente do manifesto, o sistema move adequadamente os componentes de infraestrutura atuais do pod para um nível mais alto de manifesto de software. 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.

O processo de atualização do pod é padronizado após uma técnica da indústria de software conhecida como implantação azul/verde. Os componentes de pod existentes a serem atualizados são considerados componentes azuis.


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

Embora, na maioria das maneiras, a atualização do pod siga um padrão azul-verde da indústria, existem algumas pequenas diferenças em relação a uma atualização azul-verde canônica. A atualização do pod não duplica 100% cada recurso azul único na compilação verde. Alguns dos recursos azuis existentes são reutilizados na nova compilação verde, como as NICs para as instâncias existentes do Unified Access Gateway. Outra diferença é que, 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, depois que o sistema migra o pod para a compilação verde e valida que o pod está em execução com êxito na nova versão do manifesto, as VMs azuis mais antigas são excluídas do grupo de recursos. (Uma atualização canônica azul-verde normalmente manteria os artefatos azuis mais antigos após a mudança para verde, mantendo os mais antigos em um estado ocioso.)

  • Os componentes de pod existentes a serem atualizados, como as VMs de gerenciador de pods e as VMs do Unified Access Gateway, são considerados componentes azuis.
  • O serviço cria automaticamente o conjunto verde necessário de componentes para o pod na sua assinatura do Microsoft Azure: novas VMs verdes do gerenciador de pods, VMs do Unified Access Gateway e a VM do conector do gateway (se o seu gateway externo estiver implantado na própria VNet).
  • Uma VM de jumpbox temporária é criada automaticamente na assinatura do pod para orquestrar essa compilação verde. Essa VM de jumpbox temporária e seu grupo de recursos são excluídos depois que o ambiente paralelo verde é criado com êxito.
  • Os componentes recém-criados na compilação verde são criados junto com os componentes azuis, nos mesmos grupos de recursos.
  • O processo de criação da compilação verde não causa tempo de inatividade ou perda de dados, e as VMs paralelas não afetam as operações do pod.
  • O conjunto verde é um ambiente paralelo, aguardando a atividade de manutenção agendada que fará a mudança de azul para verde. A forma como o sistema agenda a atividade de manutenção em um pod é abordada nas seções anteriores.
  • Essas VMs verdes são iniciadas e mantidas em execução até que a atividade de manutenção agendada seja concluída, a atividade de manutenção que migra de azul para verde.
  • Depois que a atividade de manutenção agendada para migração para a compilação verde for concluída e o pod for executado com êxito nas novas instâncias, o sistema excluirá as VMs azuis dos grupos de recursos do pod. Alguns recursos, como NICs para as instâncias do Unified Access Gateway, permanecem para preservar os valores de configuração que serão necessários na próxima atualização do pod.
Observação: Você deve evitar fazer alterações no Portal do Microsoft Azure e na assinatura do pod que afetem a compilação do sistema dos componentes verdes ou que afetem os processos de atualização e manutenção do pod do sistema.

Sequência de atividades de manutenção

Essa sequência descreve a migração para a compilação verde: a mudança de azul para verde na atualização do pod.

  1. O sistema verifica a janela de manutenção preferencial do pod que você especificou no console para usar essas informações no algoritmo do agendador a fim de agendar a data e a hora reais da atividade de manutenção do pod.
  2. O agendador do sistema escolhe a data e a hora reais da agenda para que a manutenção ocorra. Conforme descrito nas seções anteriores, o console exibe visualmente a data e a hora agendadas, e um e-mail é enviado aos administradores do tenant.
  3. Importante: Antes da manutenção agendada ser executada:
    • Verifique se as VMs de imagem, as VMs do farm e as VMs de área de trabalho VDI do pod têm o agente mais recente disponível para o pod. Se você vir pontos azuis no console, o objetivo será fazer com que todos os pontos azuis desapareçam do console antes que a atualização do pod ocorra. Consulte Atualizações de pods do Horizon Cloud: etapas para compatibilidade e suporte contínuos de agentes
    • 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.

    Se exigido pelas necessidades de sua organização, você pode solicitar uma data agendada diferente para a manutenção contatando o Suporte da VMware a qualquer momento antes da hora de manutenção agendada.

    Importante: A hora agendada que aparece no console é local para o fuso horário de seu navegador.
  4. Na hora de manutenção agendada, o serviço implanta novamente uma VM de jumpbox para orquestrar a atividade de manutenção. Embora o processo geralmente demore até 20 minutos para ser concluído para pods que tenham uma configuração de Unified Access Gateway externa e interna, o sistema aloca quatro (4) horas para a atividade geral de manutenção, a fim de garantir um resultado bem-sucedido.

    Durante a atividade de manutençã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 manutençã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 a atividade de manutenção, ajuste a configuração de Efetuar 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.

  5. Após a conclusão da atividade de manutenção, o sistema excluirá os componentes que não são mais necessários, como o grupo de recursos de jumpbox e seu conteúdo e os componentes azuis que não são reutilizados na compilação verde, como as VMs do gerenciador de pods e as VMs do Unified Access Gateway. Alguns artefatos, como certos NICs para as instâncias do Unified Access Gateway, permanecem para preservar os valores de configuração necessários para a próxima manutenção futura.

Após a atividade de manutenção

Quando a atividade de manutenção 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.

Atenção: Após uma atualização do pod, verifique se os agentes em todas as imagens, farms e atribuições de VDI existentes estão atualizados para a versão mais recente disponível. Se os agentes instalados dessas VMs não foram atualizados, o pod estará em uma configuração incompatível. O processo de manutenção não atualiza automaticamente os agentes instalados. Se você vir pontos azuis no console para suas imagens ou atribuições, isso significará que os agentes precisam de atualização. Atualizações de pods do Horizon Cloud: etapas para compatibilidade e suporte contínuos de agentes.
Importante: Se o servidor Radius configurado for implantado na mesma VNet, após a atividade de manutenção, 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, se a VM do gerenciador de pods ativo ficar inativa, essas conexões não terão o failover de alta disponibilidade que um pod ativado para alta disponibilidade foi projetado para fornecer. 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 diretamente nas VMs do gerenciador de pod, por exemplo, ao integrar o dispositivo Workspace ONE Access Connector ao pod do Horizon Cloud no Microsoft Azure, para que o Connector confie nas conexões com as VMs do gerenciador de pod. 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.