Usar o aplicativo Patch Orchestration

O Aplicativo de Orquestração de Patches (POA) é um wrapper em torno do serviço Gerenciador de Reparo do Azure Service Fabric, que permite o agendamento de patches do sistema operacional baseado em configuração para clusters hospedados que não sejam do Azure. O POA não é necessário para clusters hospedados que não sejam do Azure, mas o agendamento da instalação do patch por domínio de atualização é necessário para corrigir hosts de cluster do Service Fabric sem incorrer em tempo de inatividade.

O POA é um aplicativo do Service Fabric que automatiza a aplicação de patches do sistema operacional em um cluster do Service Fabric sem incorrer em tempo de inatividade.

O POA oferece os seguintes recursos:

• Instalação automática de atualização do sistema operacional. As atualizações do sistema operacional são baixadas e instaladas automaticamente. Os nós de cluster são reinicializados conforme necessário sem incorrer em tempo de inatividade do cluster.

• Aplicação de patches com reconhecimento de cluster e integração de integridade. Enquanto o POA está aplicando atualizações, ele monitora a integridade dos nós do cluster. Os nós de cluster são atualizados um nó de cada vez ou um domínio de atualização de cada vez. Se a integridade do cluster diminuir devido ao processo de aplicação de patches, a aplicação de patches será interrompida para evitar o agravamento do problema.

Detalhes internos do POA

O POA é composto pelos seguintes subcomponentes:

• Serviço de Coordenador: Este serviço stateful é responsável por:

  • Coordenar o trabalho do Windows Update em todo o cluster.
  • Armazenar o resultado das operações concluídas do Windows Update.

• Serviço de Agente de Nó: esse serviço sem monitoração de estado é executado em todos os nós de cluster do Service Fabric. O serviço é responsável por:

  • Inicializando o agente de nó NTService.
  • Monitorando o agente de nó NTService.

• Node Agent NTService: Este serviço do Windows NT é executado em um privilégio de nível superior (SYSTEM). Por outro lado, o Serviço de Agente de Nó e o Serviço de Coordenador são executados em um privilégio de nível inferior (SERVIÇO DE REDE). O serviço é responsável por executar os seguintes trabalhos do Windows Update em todos os nós do cluster:

  • Desativando as atualizações automáticas do Windows no nó.
  • Baixar e instalar atualizações do Windows de acordo com a política fornecida pelo usuário.
  • Reiniciar a máquina após a instalação de atualizações do Windows.
  • Carregar os resultados das atualizações do Windows para o Serviço Coordenador.
  • Relatar relatórios de integridade se uma operação falhou depois de esgotar todas as tentativas.

Pré-requisitos

Habilite o serviço Gerenciador de reparos (se ainda não estiver em execução)

O POA requer que o serviço Repair Manager esteja habilitado no cluster.

Clusters do Azure

Os clusters do Azure na camada de durabilidade prata têm o serviço Gerenciador de Reparos habilitado por padrão. Os clusters do Azure na camada de durabilidade ouro podem ou não ter o serviço Gerenciador de Reparos habilitado, dependendo de quando esses clusters foram criados. Os clusters do Azure na camada de durabilidade bronze, por padrão, não têm o serviço Gerenciador de Reparos habilitado. Se o serviço já estiver habilitado, você poderá vê-lo em execução na seção serviços do sistema no Service Fabric Explorer.

O portal do Azure

Você pode habilitar o Gerenciador de Reparos no portal do Azure ao configurar o cluster. Ao configurar o cluster, selecione a opção Incluir Gerenciador de Reparo em Recursos complementares.

O modelo de implantação do Azure Resource Manager

Como alternativa, você pode usar o modelo de implantação do Azure Resource Manager para habilitar o serviço Gerenciador de Reparos em clusters do Service Fabric novos e existentes. Obtenha o modelo para o cluster que você deseja implantar. Você pode usar os modelos de exemplo ou criar um modelo de modelo de implantação personalizado do Azure Resource Manager.

Para habilitar o serviço Gerenciador de Reparos usando o modelo de modelo de implantação do Azure Resource Manager, faça o seguinte:

1. Verifique se apiVersion está definido como 2017-07-01-preview para o recurso Microsoft.ServiceFabric/clusters . Se for diferente, você precisa atualizar apiVersion para 2017-07-01-preview ou posterior:

   {
       "apiVersion": "2017-07-01-preview",
       "type": "Microsoft.ServiceFabric/clusters",
       "name": "[parameters('clusterName')]",
       "location": "[parameters('clusterLocation')]",
       ...
   }
   

2. Habilite o serviço Gerenciador de reparos adicionando a seguinte addonFeatures seção após a fabricSettings seção:

   "fabricSettings": [
       ...      
   ],
   "addonFeatures": [
       "RepairManager"
   ],
   

3. Depois de atualizar seu modelo de cluster com essas alterações, aplique-as e deixe a atualização ser concluída. Agora você pode ver o serviço Gerenciador de reparos em execução no cluster. Ele é chamado de fabric:/System/RepairManagerService na seção de serviços do sistema no Service Fabric Explorer.

Clusters locais autônomos

Para habilitar o serviço Gerenciador de Reparos em um cluster do Service Fabric novo ou existente, você pode usar as definições de configuração para cluster autônomo do Windows.

Para ativar o serviço Repair Manager:

1. Verifique se apiVersion em Configurações gerais de cluster está definido como 04-2017 ou posterior, conforme mostrado aqui:

   {
       "name": "SampleCluster",
       "clusterConfigurationVersion": "1.0.0",
       "apiVersion": "04-2017",
       ...
   }
   

2. Habilite o serviço Repair Manager adicionando a seguinte addonFeatures seção após a fabricSettings seção, conforme mostrado aqui:

   "fabricSettings": [
       ...      
   ],
   "addonFeatures": [
       "RepairManager"
   ],
   

3. Atualize o manifesto do cluster com essas alterações usando o manifesto de cluster atualizado, crie um novo cluster ou atualize a configuração do cluster.

   Depois que o cluster estiver sendo executado com um manifesto de cluster atualizado, você poderá ver o serviço Gerenciador de Reparos em execução no cluster. Chama-se fabric:/System/RepairManagerService e encontra-se na secção de serviços do sistema no Service Fabric Explorer.

Configurar atualizações do Windows para todos os nós

As atualizações automáticas do Windows podem levar à perda de disponibilidade, porque vários nós de cluster podem reiniciar ao mesmo tempo. POA, por padrão, tenta desabilitar as atualizações automáticas do Windows em cada nó de cluster. No entanto, se as configurações forem gerenciadas por um administrador ou uma Diretiva de Grupo, recomendamos definir a política do Windows Update como "Notificar antes de Baixar" explicitamente.

Transferir o pacote de candidaturas

Para baixar o pacote do aplicativo, vá para a página de lançamento do aplicativo Patch Orchestration no GitHub.

Configurar o comportamento do POA

Você pode configurar o comportamento POA para atender às suas necessidades. Substitua os valores padrão passando o parâmetro do aplicativo enquanto você está criando ou atualizando o aplicativo. Você pode fornecer parâmetros de aplicativo especificando ApplicationParameter para os Start-ServiceFabricApplicationUpgrade cmdlets ou New-ServiceFabricApplication .

Implantar POA

1. Conclua todas as etapas de pré-requisito para preparar o cluster.

2. Implante o POA como qualquer outro aplicativo do Service Fabric. Para implantá-lo usando o PowerShell, consulte Implantar e remover aplicativos usando o PowerShell.

3. Para configurar o aplicativo no momento da implantação, passe o ApplicationParameter para o New-ServiceFabricApplication cmdlet. Para sua conveniência, fornecemos o script Deploy.ps1 junto com o aplicativo. Para usar o script:

   • Conectar-se a um cluster do Service Fabric usando Connect-ServiceFabricClustero .
   • Execute o script do PowerShell Deploy.ps1 com o valor apropriado ApplicationParameter .

Atualizar POA

Para atualizar sua versão POA usando o PowerShell, siga as instruções em Atualização do aplicativo Service Fabric usando o PowerShell.

Remover POA

Para remover o aplicativo, siga as instruções em Implantar e remover aplicativos usando o PowerShell.

Para sua conveniência, fornecemos o script Undeploy.ps1 junto com o aplicativo. Para usar o script:

• Conectar-se a um cluster do Service Fabric usando Connect-ServiceFabricClustero .
• Execute o script do PowerShell Undeploy.ps1.

Ver os resultados do Windows Update

POA expõe APIs REST para exibir os resultados históricos para os usuários. Aqui está um exemplo do resultado JSON:

[
  {
    "NodeName": "_stg1vm_1",
    "WindowsUpdateOperationResults": [
      {
        "OperationResult": 0,
        "NodeName": "_stg1vm_1",
        "OperationTime": "2019-05-13T08:44:56.4836889Z",
        "OperationStartTime": "2019-05-13T08:44:33.5285601Z",
        "UpdateDetails": [
          {
            "UpdateId": "7392acaf-6a85-427c-8a8d-058c25beb0d6",
            "Title": "Cumulative Security Update for Internet Explorer 11 for Windows Server 2012 R2 (KB3185319)",
            "Description": "A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "ResultCode": 0,
            "HResult": 0
          }
        ],
        "OperationType": 1,
        "WindowsUpdateQuery": "IsInstalled=0",
        "WindowsUpdateFrequency": "Daily,10:00:00",
        "RebootRequired": false
      }
    ]
  },
  ...
]

Os campos JSON são descritos na tabela a seguir:

Se nenhuma atualização estiver agendada ainda, o JSON resultante estará vazio.

Entre no cluster para consultar os resultados do Windows Update. Descubra o endereço IP da réplica para o endereço principal do Serviço Coordenador e abra a seguinte URL no navegador: http://< REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

O ponto de extremidade REST para o Serviço de Coordenador tem uma porta dinâmica. Para verificar a URL exata, consulte Service Fabric Explorer. Por exemplo, os resultados estão disponíveis em http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Se o proxy reverso estiver habilitado no cluster, você também poderá acessar a URL de fora do cluster.

O ponto de extremidade que você precisa atingir é http://< SERVERURL>:<REVERSEPROXYPORT/>PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

Para habilitar o proxy reverso no cluster, siga as instruções em Proxy reverso no Azure Service Fabric.

Diagnósticos e eventos de saúde

Esta seção discute como depurar ou diagnosticar problemas com atualizações de patch por meio de POA em clusters do Service Fabric.

O Node Agent NTService cria tarefas de reparo para instalar atualizações nos nós. Cada tarefa é então preparada pelo Serviço Coordenador de acordo com a política de aprovação da tarefa. Finalmente, as tarefas preparadas são aprovadas pelo Gerenciador de Reparos, que não aprova nenhuma tarefa se o cluster estiver em um estado não íntegro.

Para ajudá-lo a entender como as atualizações procedem em um nó, vamos passo a passo:

1. O NodeAgentNTService, em execução em cada nó, procura atualizações disponíveis do Windows no horário agendado. Se houver atualizações disponíveis, ele as baixará no nó.

2. Depois que as atualizações são baixadas, o Node Agent NTService cria uma tarefa de reparo correspondente para o nó com o nome POS___<unique_id>. Você pode exibir essas tarefas de reparo usando o cmdlet Get-ServiceFabricRepairTask ou SFX na seção de detalhes do nó. Depois que a tarefa de reparo é criada, ela se move rapidamente para o estado Reivindicado.

3. O Serviço de Coordenador procura periodicamente tarefas de reparo no estado Reivindicado e, em seguida, atualiza-as para o estado Preparando com base em TaskApprovalPolicy. Se TaskApprovalPolicy estiver configurado para ser NodeWise, uma tarefa de reparo que corresponda a um nó será preparada somente se nenhuma outra tarefa de reparo estiver atualmente no estado Preparando, Aprovado, Executando ou Restaurando.

   Da mesma forma, no caso de UpgradeWise TaskApprovalPolicy, há tarefas nos estados anteriores apenas para nós que pertencem ao mesmo domínio de atualização. Depois que uma tarefa de reparo é movida para o estado Preparando , o nó correspondente do Service Fabric é desabilitado com a intenção definida como Reiniciar.

   As versões 1.4.0 e posteriores do POA postam eventos com a propriedade ClusterPatchingStatus em CoordinatorService para exibir os nós que estão sendo corrigidos. As atualizações são instaladas no _poanode_0, conforme mostrado na imagem a seguir:

   

4. Depois que o nó é desativado, a tarefa de reparo é movida para o estado de execução .

   Nota

   Um nó preso no estado Desativado pode bloquear uma nova tarefa de reparo, o que interrompe a operação de aplicação de patches no cluster.

5. Quando a tarefa de reparo estiver no estado Executante , a instalação do patch nesse nó será iniciada. Depois que o patch é instalado, o nó pode ou não ser reiniciado, dependendo do patch. Em seguida, a tarefa de reparo é movida para o estado de restauração , que reativa o nó. A tarefa de reparo é marcada como concluída.

   No POA versões 1.4.0 e posteriores, você pode encontrar o status da atualização exibindo os eventos de integridade em NodeAgentService com a propriedade WUOperationStatus-NodeName<>. As seções destacadas nas imagens a seguir mostram o status das atualizações do Windows nos nós poanode_0 e poanode_2:

   

   

   Você também pode obter os detalhes usando o PowerShell. Para fazer isso, conecte-se ao cluster e busque o estado da tarefa de reparo usando Get-ServiceFabricRepairTask.

   No exemplo a seguir, a tarefa "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" está no estado DownloadComplete . Isso significa que as atualizações foram baixadas no nó poanode_2 e a instalação será tentada quando a tarefa for movida para o estado de execução .

    D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k = Get-ServiceFabricRepairTask -TaskId "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15"
   
    D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k.ExecutorData
    {"ExecutorSubState":2,"ExecutorTimeoutInMinutes":90,"RestartRequestedTime":"0001-01-01T00:00:00"}
   

   Se ainda não forem encontrados mais problemas, inicie sessão na sua máquina virtual (VM) ou VMs e saiba mais sobre eles utilizando os registos de eventos do Windows. A tarefa de reparo mencionada anteriormente pode existir apenas nos seguintes subestados do executor:

   ExecutorSubstate	Description
   Nenhum=1	Implica que não havia uma operação em curso no nó. O Estado pode estar em transição.
   DownloadCompleted=2	Implica que a operação de download foi concluída com êxito, falha parcial ou falha.
   InstalaçãoApproved=3	Implica que a operação de descarregamento foi concluída anteriormente e que o Repair Manager aprovou a instalação.
   InstallationInProgress=4	Corresponde ao estado de execução da tarefa de reparação.
   InstalaçãoCompleted=5	Implica que a instalação foi concluída com êxito, sucesso parcial ou falha.
   RestartRequested=6	Implica que a instalação do patch foi concluída e há uma ação de reinicialização pendente no nó.
   RestartNotNeeded=7	Implica que a reinicialização não foi necessária após a conclusão da instalação do patch.
   RestartCompleted=8	Implica que a reinicialização foi concluída com êxito.
   OperaçãoCompleted=9	A operação do Windows Update foi concluída com êxito.
   OperaçãoAborted=10	Implica que a operação do Windows Update foi anulada.

6. No POA versões 1.4.0 e posteriores, quando uma tentativa de atualização de nó é concluída, um evento com a propriedade "WUOperationStatus-[NodeName]" é publicado no NodeAgentService para notificá-lo quando a próxima tentativa de baixar e instalar as atualizações do Windows começar. Isso é exibido na imagem a seguir:

   

Registos de diagnósticos

Os logs de aplicativos de orquestração de patches são coletados como parte dos logs de tempo de execução do Service Fabric.

Você pode capturar logs usando a ferramenta de diagnóstico ou pipeline de sua escolha. O POA usa as seguintes IDs de provedor fixo para registrar eventos por meio da fonte de eventos:

• E39B723C-590C-4090-ABB0-11E3E6616346
• FC0028FF-BFDC-499F-80DC-ED922C52C5E9
• 24AFA313-0D3B-4C7C-B485-1047FD964B60
• 05DC046C-60E9-4EF7-965E-91660ADFFA68

Relatórios de saúde

O POA também publica relatórios de integridade no Serviço de Agente de Nó ou no Serviço de Coordenador nos seguintes cenários:

• O agente de nó NTService está inativo

  Se o Agente de Nó NTService estiver inativo em um nó, um relatório de integridade de nível de aviso será gerado em relação ao Serviço de Agente de Nó.

• O serviço Repair Manager não está ativado

  Se o serviço Gerenciador de Reparos não for encontrado no cluster, um relatório de integridade em nível de aviso será gerado para o Serviço Coordenador.

Perguntas mais frequentes

P: Por que vejo meu cluster em um estado de erro quando o POA está em execução?

R: Durante o processo de instalação, o POA desativa ou reinicia os nós, o que pode resultar temporariamente em um cluster não íntegro.

Dependendo da política do aplicativo, um nó pode ficar inativo durante uma operação de aplicação de patches ou um domínio de atualização inteiro pode ficar inativo de uma só vez.

No final da instalação das atualizações do Windows, os nós são reativados após a reinicialização.

No exemplo a seguir, o cluster foi para um estado de erro temporariamente porque dois nós estavam inativos e a política MaxPercentageUnhealthyNodes foi violada. O erro é temporário até que a operação de aplicação de patches possa começar.

Se o problema persistir, consulte a seção Solução de problemas.

P: O que posso fazer se o POA estiver em estado de aviso?

R: Verifique se um relatório de integridade publicado no aplicativo indica a causa raiz. Normalmente, o aviso contém detalhes do problema. Se o problema for transitório, espera-se que o aplicativo se recupere automaticamente.

P: O que posso fazer se meu cluster não estiver íntegro e eu precisar fazer uma atualização urgente do sistema operacional?

R: O POA não instala atualizações enquanto o cluster não estiver íntegro. Tente trazer seu cluster para um estado íntegro para desbloquear o fluxo de trabalho POA.

P: Devo definir TaskApprovalPolicy como "NodeWise" ou "UpgradeDomainWise" para o meu cluster?

R: A configuração "UpgradeDomainWise" acelera o reparo geral do cluster corrigindo em paralelo todos os nós que pertencem a um domínio de atualização. Durante o processo, os nós que pertencem a um domínio de atualização inteiro não estão disponíveis (no estado Desativado).

Por outro lado, a configuração "NodeWise" corrige apenas um nó de cada vez, o que implicaria que a aplicação geral de patches de cluster poderia levar mais tempo. No entanto, apenas um nó no máximo estaria indisponível (no estado desativado ) durante o processo de aplicação de patches.

Se o cluster puder tolerar a execução em um número N-1 de domínios de atualização durante o ciclo de aplicação de patches (em que N é o número total de domínios de atualização no cluster), você poderá definir a política como "UpgradeDomainWise". Caso contrário, defina-o como "NodeWise".

P: Quanto tempo leva para corrigir um nó?

R: A aplicação de patches em um nó pode levar de minutos (por exemplo, atualizações de definição do Windows Defender) a horas (por exemplo, atualizações cumulativas do Windows). O tempo necessário para corrigir um nó depende principalmente de:

• O tamanho das atualizações.
• O número de atualizações, que devem ser aplicadas em uma janela de patching.
• O tempo necessário para instalar as atualizações, reinicializar o nó (se necessário) e concluir as etapas de instalação pós-reinicialização.
• O desempenho da VM ou máquina e as condições de rede.

P: Quanto tempo leva para corrigir um cluster inteiro?

R: O tempo necessário para corrigir um cluster inteiro depende:

• O tempo necessário para corrigir um nó.

• A política do Serviço Coordenador. A política padrão, "NodeWise", resulta na aplicação de patches em apenas um nó de cada vez, uma abordagem mais lenta do que usar "UpgradeDomainWise".

  Por exemplo: Se um nó demorar ~1 hora para ser corrigido, a aplicação de patches em um cluster de 20 nós (mesmo tipo de nós) com 5 domínios de atualização, cada um contendo 4 nós, exigirá:

  • Para "NodeWise": ~20 horas.
  • Para "UpgradeDomainWise": ~5 horas.

• A carga do cluster. Cada operação de aplicação de patches requer a realocação da carga de trabalho do cliente para outros nós disponíveis no cluster. Um nó que está sendo corrigido estaria no estado de desativação durante esse tempo. Se o cluster estiver sendo executado perto do pico de carga, o processo de desativação levará mais tempo. Portanto, o processo geral de aplicação de patches pode parecer lento em tais condições de estresse.

• Falhas de integridade do cluster durante a aplicação de patches. Qualquer degradação na integridade do cluster interromperia o processo de aplicação de patches. Esse problema aumentaria o tempo total necessário para corrigir todo o cluster.

P: Por que motivo vejo algumas atualizações nos resultados do Windows Update obtidas através da API REST, mas não no histórico do Windows Update no computador?

R: Algumas atualizações de produtos aparecem apenas no seu próprio histórico de atualizações ou patches. Por exemplo, as atualizações do Windows Defender podem ou não ser exibidas no histórico do Windows Update no Windows Server 2016.

P: O POA pode ser usado para corrigir meu cluster de desenvolvimento (cluster de um nó)?

R: Não, o POA não pode ser usado para corrigir um cluster de um nó. Essa limitação ocorre por design, porque os serviços do sistema Service Fabric ou outros aplicativos do cliente incorreriam em tempo de inatividade. Portanto, os trabalhos de reparo de patches nunca seriam aprovados pelo Repair Manager.

P: Como faço para corrigir nós de cluster no Linux?

R: Para saber mais sobre como orquestrar atualizações no Linux, consulte Azure virtual machine scale set automatic OS image upgrades.

P: Por que o ciclo de atualização está demorando tanto?

R: Consulte o resultado JSON, insira o ciclo de atualização para todos os nós e, em seguida, você pode tentar descobrir o tempo necessário para a instalação da atualização em cada nó usando OperationStartTime e OperationTime (OperationCompletionTime).

Se houver uma grande janela de tempo na qual nenhuma atualização está ocorrendo, o cluster pode estar em um estado de erro e, consequentemente, o Gerenciador de Reparos não pode aprovar nenhuma tarefa de reparo de POA. Se a instalação da atualização estiver demorando muito tempo em qualquer nó, esse nó pode não ter sido atualizado há algum tempo. Muitas atualizações podem estar pendentes de instalação, o que pode resultar em atrasos.

Também pode ser possível que o patch de nó esteja bloqueado porque está preso no estado de desativação . Isso geralmente acontece porque desativar o nó pode levar a situações de quórum ou perda de dados.

P: Por que o nó deve ser desativado quando o POA está corrigindo-o?

R: O POA desativa o nó com uma intenção Reiniciar , que interrompe ou realoca todos os serviços do Service Fabric que estão sendo executados no nó. O POA faz isso para garantir que os aplicativos não acabem usando uma mistura de DLLs novas e antigas, por isso recomendamos não aplicar patches em um nó sem desativá-lo.

P: Qual é o número máximo de nós que podem ser atualizados usando POA?

R: O POA usa o Service Fabric Repair Manager para criar tarefas de reparo para nós para atualizações. No entanto, não podem estar presentes mais de 250 tarefas de reparação ao mesmo tempo. Atualmente, o POA cria tarefas de reparo para cada nó ao mesmo tempo, para que o POA não possa atualizar mais de 250 nós em um cluster.

Exclusões de Responsabilidade

• O POA aceita o Contrato de Licença de Usuário Final para o Windows Update em nome do usuário. Opcionalmente, a configuração pode ser desativada na configuração do aplicativo.

• O POA coleta telemetria para acompanhar o uso e o desempenho. A telemetria do aplicativo segue a configuração da configuração de telemetria do tempo de execução do Service Fabric (que está ativada por padrão).

Resolução de Problemas

Esta seção fornece possíveis soluções de solução de problemas para problemas com a aplicação de patches em nós.

Um nó não está voltando ao estado ascendente

• O nó pode estar preso no estado de desativação porque:

  • Está pendente uma verificação de segurança. Para corrigir essa situação, certifique-se de que nós suficientes estejam disponíveis em um estado íntegro.

• O nó pode estar preso no estado Desativado porque:

  • Foi desativado manualmente.
  • Ele foi desabilitado devido a um trabalho de infraestrutura do Azure em andamento.
  • Ele foi desativado temporariamente pelo POA para corrigir o nó.

• O nó pode estar preso em um estado descendente porque:

  • Ele foi colocado em um estado descendente manualmente.
  • Ele está passando por uma reinicialização (que pode ser desencadeada pelo POA).
  • Ele tem uma VM ou máquina defeituosa ou está tendo problemas de conectividade de rede.

As atualizações foram ignoradas em alguns nós

O POA tenta instalar uma atualização do Windows de acordo com a política de reagendamento. O serviço tenta recuperar o nó e ignorar a atualização de acordo com a política do aplicativo.

Nesse caso, um relatório de integridade de nível de aviso é gerado em relação ao Serviço de Agente de Nó. O resultado do Windows Update também contém o possível motivo da falha.

A integridade do cluster vai para erro enquanto a atualização está sendo instalada

Uma atualização defeituosa do Windows pode reduzir a integridade de um aplicativo ou cluster em um nó ou domínio de atualização específico. O POA descontinua qualquer operação subsequente do Windows Update até que o cluster esteja íntegro novamente.

Um administrador deve intervir e determinar por que o aplicativo ou cluster ficou não íntegro devido ao Windows Update.

Notas de versão do POA

Versão 1.1.0

• Divulgação pública

Versão 1.1.1

• Corrigido um bug no SetupEntryPoint do NodeAgentService que impedia a instalação do NodeAgentNTService.

Versão 1.2.0

• Correções de bugs em torno do fluxo de trabalho de reinicialização do sistema.
• Correção de bug na criação de tarefas de RM devido ao qual a verificação de integridade durante a preparação de tarefas de reparo não estava acontecendo como esperado.
• Alterado o modo de inicialização do serviço do Windows POANodeSvc de auto para delayed-auto.

Versão 1.2.1

• Correção de bugs no fluxo de trabalho de redução de escala do cluster. Introdução da lógica de coleta de lixo para tarefas de reparo de POA pertencentes a nós inexistentes.

Versão 1.2.2

• Correções de bugs diversos.
• Os binários agora estão assinados.
• Adicionado link sfpkg para o aplicativo.

Versão 1.3.0

• Definir InstallWindowsOSOnlyUpdates como false agora instala todas as atualizações disponíveis.
• Alterada a lógica de desativação das atualizações automáticas. Isso corrige um bug em que as atualizações automáticas não estavam sendo desabilitadas no Server 2016 e superior.
• Restrição de posicionamento parametrizada para ambos os microsserviços de POA para casos de uso avançados.

Versão 1.3.1

• Corrigindo a regressão em que o POA 1.3.0 não funcionará no Windows Server 2012 R2 ou anterior devido a uma falha na desativação das atualizações automáticas.
• Corrigindo bug onde a configuração InstallWindowsOSOnlyUpdates é sempre escolhida como True.
• Alterando o valor padrão de InstallWindowsOSOnlyUpdates para False.

Versão 1.3.2

• Corrigir um problema que afeta o ciclo de vida de aplicação de patches em um nó, se houver nós com um nome que seja um subconjunto do nome do nó atual. Para esses nós, é possível que o patch tenha sido perdido ou uma reinicialização esteja pendente.