Esta página de documentação descreve os principais aspectos para saber sobre a manutenção dos componentes de software da VMware que compõem o pod implantado do Horizon Cloud.

Breve introdução

As atividades de manutenção do sistema incluem uma atualização automatizada dos componentes de software do pod para incluir novos recursos, correções e melhorias para suporte ao serviço e resiliência.

Para concluir uma atualização dos dispositivos de pod e de gateway com tempo de inatividade próximo a zero, o sistema usa contagens das sessões de usuário final. O sistema usa as contagens de sessão para determinar o tempo ideal para concluir a atualização quando há um número baixo de usuários conectados ao ambiente com sessões ativas.

A atividade de manutenção que atualiza um pod existente para um manifesto mais recente é iniciada pelo sistema a partir 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.

Observação: Conforme descrito nesta página de documentação, a partir do início do ano oficial de 2022, o serviço aprimorou o código de upgrade para usar programaticamente as ofertas da VMware que a VMware fornece no Azure Marketplace. Quando as verificações prévias de upgrade determinam que o uso programático dessas ofertas da VMware é evitado na assinatura, você deve concluir as ações conforme descrito nessa página de documentação para resolver os erros de bloqueio de atualização.

Por exemplo, se a entidade de serviço do Horizon Cloud associada às assinaturas usadas para o pod e suas configurações de gateway estiverem usando uma função personalizada (atípica), certifique-se de que a função personalizada inclua essas duas permissões. O código de API de upgrade aprimorado depende dessas permissões para recuperar a lista de ofertas do Marketplace e obter as ofertas da VMware. Se a função personalizada ainda não incluir essas duas permissões, adicione-as à função personalizada antes que o processo de upgrade do pod e do gateway ocorra.

Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read
Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write

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.

Informações importantes sobre a atualização de um pod de manifestos anteriores a 3328

"A partir de fevereiro de 2021, as NICs para as VMs do gerenciador de pods seguem o mesmo padrão de design de infraestrutura que as NICs para as VMs do Unified Access Gateway."

Em novas implantações de pod a partir desse momento e nas atualizações de pod a partir de manifestos anteriores ao 3328, o implantador instancia toda a rede necessária para oferecer suporte à execução do pod e às atualizações subsequentes ao longo do tempo. O grupo de recursos do pod agora terá 8 NICs:

  • 4 NICs que reservam 4 endereços IP da sub-rede de gerenciamento do pod
  • 4 NICs que reservam 4 endereços IP da sub-rede de VM primária do pod (historicamente chamada de sub-rede do tenant).

Essas NICs de pod do 8 persistirão e continuarão a reservar seus endereços IP atribuídos para a vida útil do pod.

Esse design oferece suporte a atualizações de pod mais rápidas e resilientes. Antes desse design, uma atualização de pod era necessária para a criação de novas NICs como parte da compilação do pod verde e a obtenção de endereços IP para essas NICs a partir das sub-redes do pod no momento da atualização. Com esse design, podem ocorrer tempos limite no Azure e interromper o processo de atualização.

Nesse design, onde o implantador instancia toda a rede necessária com antecedência, os NICs e seus endereços IP a partir das sub-redes de gerenciamento e de VM (tenant) são preservados para serem usados em atualizações de pod subsequentes. Este design se alinha com o padrão usado para as instâncias do Unified Access Gateway.

Quando o seu pod ainda não tiver as 8 NICs no grupo de recursos do pod e o pod estiver agendado para ser atualizado para o manifesto 3328 ou posterior, você deverá executar essas ações.

Antes de atualizar esse pod, verifique se os endereços IP da sub-rede de gerenciamento do pod e os endereços IP da sub-rede de VM primária (tenant) são obtidos apenas por itens que o Horizon Cloud on Microsoft Azure cria e configura
  • Sub-rede de gerenciamento - Somente as NICs específicas da implantação do Horizon Cloud on Microsoft Azure que o implantador do pod criou e configurou devem usar endereços IP da sub-rede de gerenciamento do pod. Essas NICs são as NICs dos gerenciadores de pods e as NICs da instância do Unified Access Gateway do pod. A sub-rede de gerenciamento do pod não deve ter recursos ou itens não implantados por pod anexados a ela ou obter endereços IP dela.
  • Sub-rede de tenant - Somente as NICs e os balanceadores de carga específicos da implantação do Horizon Cloud on Microsoft Azure que o implantador do pod cria e configura devem estar usando endereços IP da sub-rede do tenant do pod. A sub-rede do tenant do pod não deve ter nenhum recurso ou item que não seja de implantação anexado a ela ou tirar endereços IP dela.

O Guia de Implantação informa que as sub-redes usadas pelo pod devem ter zero recurso adicional anexado a eles além dos recursos da implantação do pod. Se você tiver criado manualmente os recursos e atribuído endereços IP da sub-rede do tenant ou gerenciamento do pod a esses recursos adicionais, deverá remover esses endereços IP desses recursos antes que a atualização do pod seja executada. Caso contrário, a atualização do pod falhará e exigirá suporte da VMware.

Depois de atualizar o pod, certifique-se de adicionar todos os endereços IP reservados pelas NICs criadas pelo implantador no grupo de recursos do pod às regras de firewall que você tem em vigor antes da atualização
Você pode ter regras de firewall existentes que governam o tráfego dos endereços IP das NICs das VMs do gerenciador de pods. Para que a comunicação de tráfego funcione após a atualização do pod como funcionou antes da atualização, você deve garantir que todos os 8 endereços IP reservados pelas NICs no grupo de recursos do pod sejam refletidos nas suas regras de firewall após a atualização.

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 em VMware Horizon Cloud Service: detalhes adicionais do serviço (87894) KB, a VMware é responsável pelos componentes de software que residem no pod e que são baixados da camada de controle para esse pod. O PDF VMware Horizon Cloud Service - : detalhes adicionais do serviço anexado a esse artigo da KB 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.

O documento VMware Horizon Cloud Service: detalhes adicionais do serviço 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 do documento VMware Horizon Cloud Service: detalhes adicionais do serviço, o documento VMware Horizon Cloud Service: detalhes adicionais do serviço 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).
  • 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 inicia a atividade de atualização. O processo completo normalmente leva entre 20 e 30 minutos do início ao fim para os pods que têm uma configuração externa e interna do Unified Access Gateway.
    Observação: Durante o tempo de 20 a 30 minutos para que o processo seja concluído, o console impede que você realize tarefas administrativas no pod que está passando pela atualização. Por exemplo, até que os dispositivos do gerenciador de pods notifiquem o plano de nuvem de que a atualização foi concluída, a ação Editar na página de detalhes do pod não estará disponível para clicar para alterar as características desse pod.
    Sobre as sessões de usuário final e a atividade de atualização nos dispositivos do Unified Access Gateway
    Para obter um tempo de inatividade próximo a zero para as sessões de usuário final, dentro do tempo de atividade de manutenção geral, o sistema usa as contagens das sessões de usuário final nos dispositivos para determinar o intervalo ideal para concluir a atualização desses dispositivos.

    O tempo de conclusão é otimizado para ocorrer no momento em que há um número baixo de usuários conectados ao ambiente com sessões ativas.

    Nessa janela de tempo quase zero, os usuários finais com sessões ativas terão essas sessões desconectadas. Em seguida, em alguns minutos, esses usuários podem se reconectar.

    Não ocorre perda de dados, exceto no cenário em que você definiu a opção Imediatamente para o tratamento de tempo limite nos farms e atribuições de área de trabalho VDI. Esse cenário, os usuários com sessões ativas nas quais você usou a opção Imediatamente para o tratamento de tempo limite serão desconectados imediatamente, e essas sessões também serão desconectadas imediatamente, de acordo com essa configuração. Nessas mesmas condições, qualquer usuário em andamento será perdido. Para evitar perda de dados do usuário final em processo 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.

    Além disso, durante essa janela de tempo quase zero, se um usuário final que ainda não tiver uma sessão conectada à área de trabalho virtual ou ao aplicativo remoto a partir do pod e que tentar se conectar, não poderá se conectar até que o processo seja concluído.

  5. "Ao concluir a atividade de manutenção, o sistema excluirá os componentes que não são mais necessários, como 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 gerenciador de pods e 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.

  • 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.
  • Se essa atualização tiver sido de um manifesto anterior ao 3328, após a atualização do pod, certifique-se de adicionar às suas regras de firewall todos os endereços IP das NICs criadas pelo implantador que estão no grupo de recursos do pod. Você pode ter regras de firewall existentes que governam o tráfego dos endereços IP das NICs das VMs do gerenciador de pods. Para que a comunicação de tráfego funcione após essa atualização do pod e as atualizações subsequentes, pois ela funcionou antes dessa atualização, você deve garantir que todos os 8 endereços IP reservados pelas NICs no grupo de recursos do pod sejam refletidos nas suas regras de firewall após essa atualização.
  • Se o servidor de autenticação de dois fatores configurado for implantado na mesma VNet, após a atividade de manutenção, você deverá atualizar as configurações no servidor de autenticação de dois fatores para aceitar os novos endereços IP privados para as 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 atualizações futuras desse pod. Consulte Atualizar seu sistema de autenticação de dois fatores com as informações de gateway necessárias.
  • 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.
  • No manifesto 2474.x, o sistema não verificava seus servidores Active Directory registrados para ver se havia desvio do relógio. Com a 2474.x, uma verificação de desvio do relógio foi introduzida. Se seus servidores Active Directory registrados tiverem algum problema de sincronização de horário (clockSkew > 4 minutes) agora, quando o pod for atualizado para 2474.x ou posterior, essa validação do sistema será iniciada nesse pod. Como resultado, a detecção do servidor Active Directory pode começar a falhar até que você resolva o problema de desalinhamento do relógio, e a detecção com falha afetará as solicitações de conexão da área de trabalho do usuário final para esse pod.