Usar Aplicativo de Orquestração de Patch

Importante

A partir de 30 de abril de 2019, o Aplicativo de Orquestração de Patch versão 1.2* não terá mais suporte. Atualize para a versão mais recente.

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

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

O POA fornece os seguintes recursos:

• Instalação da atualização automática do sistema operacional. Atualizações do sistema operacional são baixadas e instaladas automaticamente. Nós de cluster são reiniciados conforme necessário, sem incorrer em tempo de inatividade do cluster.

• Aplicação de patch com suporte a cluster e integração de integridade. Embora o POA esteja aplicando atualizações, ele monitora a integridade dos nós do cluster. Os nós do cluster são atualizados um nó de cada vez ou um domínio de atualização de cada vez. Se a integridade do cluster falhar devido ao processo de aplicação de patch, a aplicação de patch será interrompida para evitar agravar o problema.

Detalhes internos do POA

O POA é composto pelos seguintes subcomponentes:

• Serviço de Coordenador: este serviço com estado é 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 do Nó: é um serviço sem estado, executado em todos os nós de cluster do Service Fabric. O serviço é responsável por:

  • Inicialização de NTService do Agente do Nó.
  • Monitoramento do NTService do Agente do Nó.

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

  • Desabilitar as atualizações automáticas do Windows no nó.
  • Baixar e instalar as atualizações do Windows de acordo com a política que o usuário forneceu.
  • Reiniciar o computador após a instalação das atualizações do Windows.
  • Carregar os resultados das atualizações do Windows para o Serviço do Coordenador.
  • Entregar relatórios de integridade, no caso de falha na operação após esgotar todas as repetições.

Observação

O POA usa o serviço de Gerenciador de Reparos do Service Fabric para desabilitar ou habilitar o nó e realizar as verificações de integridade. A tarefa de reparo criada pelo POA rastreia o andamento do Windows Update para cada nó.

Pré-requisitos

Observação

A versão mínima necessária do .NET Framework é 4.6.

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

O POA exige que o serviço de Gerenciador de Reparos esteja habilitado no cluster.

Clusters do Azure

Clusters do Azure na camada de durabilidade prata têm o serviço de Gerenciador de Reparos habilitado por padrão. Clusters do Azure na camada de durabilidade ouro podem ou não ter o serviço de Gerenciador de Reparos habilitado, dependendo de quando esses clusters foram criados. Clusters do Azure na camada de durabilidade bronze, por padrão, não têm o serviço de Gerenciador de Reparos habilitado. Se o serviço já está habilitado, você pode vê-lo em execução na seção de 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. Quando você estiver configurando o cluster, selecione a opção Incluir Gerenciador de Reparos em Recursos de complemento.

O modelo de implantação do Azure Resource Manager

Como alternativa, é possível usar o modelo de implantação do Azure Resource Manager para habilitar o serviço de 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 implantação do Azure Resource Manager personalizado.

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

1. Verifique se apiVersion foi definido como 2017-07-01-preview para o recurso Microsoft.ServiceFabric/clusters. Se for diferente, você precisará 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 de Gerenciador de Reparos adicionando a seção addonFeatures a seguir após a seção fabricSettings:

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

3. Depois de atualizar o modelo de cluster com essas alterações, aplique-as e permita a conclusão da atualização. Agora você pode ver o serviço de Gerenciador de Reparos em execução no cluster. É denominado fabric:/System/RepairManagerService na seção de serviços do sistema no Service Fabric Explorer.

Clusters locais autônomos

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

Para habilitar o serviço de Gerenciador de Reparos:

1. Verifique se apiVersion nas configurações gerais do cluster foi definido como 04-2017 ou posterior, conforme mostrado aqui:

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

2. Habilite o serviço de Gerenciador de Reparos adicionando a seção addonFeatures a seguir após a seção fabricSettings, conforme mostrado abaixo:

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

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

   Depois que o cluster estiver em execução com um manifesto de cluster atualizado, será possível ver o serviço de Gerenciador de Reparos em execução no cluster. É denominado fabric:/System/RepairManagerService na seção de serviços do sistema no Service Fabric Explorer.

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

As atualizações automáticas do Windows podem causar a perda de disponibilidade porque vários nós de cluster podem ser reiniciados ao mesmo tempo. Por padrão, o POA tenta desabilitar as atualizações automáticas do Windows em cada nó do cluster. No entanto, se as configurações forem gerenciadas por um administrador ou uma Política de Grupo, é recomendável configurar a política do Windows Update explicitamente como "Notificar antes de Baixar".

Baixar o pacote de aplicativos

Para baixar o pacote de aplicativos, acesse a página de versão do Aplicativo de Orquestração de Patch no GitHub.

Configurar o comportamento do POA

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

Parâmetro	Type	Detalhes
MaxResultsToCache	long	O número máximo de resultados do Windows Update que devem ser armazenados em cache. O valor padrão é 3.000, supondo o seguinte:   - O número de nós é 20.   - O número de atualizações para um nó por mês é 5.   - Número de resultados por operação pode ser 10.   - Resultados dos últimos três meses devem ser armazenados.
TaskApprovalPolicy	Enum { NodeWise, UpgradeDomainWise }	A TaskApprovalPolicy indica a política a ser usada pelo Serviço do Coordinator para instalar atualizações do Windows em todos os nós de cluster do Service Fabric. Os valores permitidos são: NodeWise: as atualizações do Windows são instaladas em um nó de cada vez. UpgradeDomainWise: as atualizações do Windows são instaladas em um domínio de atualização de cada vez. (No máximo, todos os nós que pertencem a um domínio de atualização podem ir para uma atualização do Windows.) Para ajudar a decidir qual política é mais adequada para o cluster, confira a seção perguntas frequentes.
LogsDiskQuotaInMB	long (Padrão: 1024)	O tamanho máximo dos logs do aplicativo de orquestração de patch em MB, que pode ser mantido localmente no nó.
WUQuery	string (Padrão: IsInstalled=0)	Consulta para obter atualizações do Windows. Para obter mais informações, consulte WuQuery.
InstallWindowsOSOnlyUpdates	Booliano (padrão: false)	Use esse sinalizador para controlar quais atualizações devem ser baixadas e instaladas. Os seguintes valores são permitidos true – instala somente as atualizações do sistema operacional Windows. false – instala todas as atualizações disponíveis no computador.
WUOperationTimeOutInMinutes	Int (Padrão: 90)	Especifica o tempo limite para qualquer operação do Windows Update (pesquisar, baixar ou instalar). Se a operação não for concluída dentro do tempo limite especificado, ela será anulada.
WURescheduleCount	Int (Padrão: 5)	O número máximo de vezes que o serviço reagendaria a atualização do Windows, em caso de falha persistente na operação.
WURescheduleTimeInMinutes	Int (Padrão: 30)	O intervalo em que o serviço reagendaria as atualizações do Windows, em caso de falha persistente.
WUFrequency	Cadeia de caracteres separada por vírgula (padrão: Semanalmente, quarta-feira, 7:00:00)	A frequência da instalação das atualizações do Windows. O formato e os valores possíveis são: - Mensal, DD, HH:MM:SS (exemplo: mensal, 5, 12:22:32). Os valores permitidos para o campo DD (dia) são os números de 1 a 28 e last. - Semanal, dia, HH:MM:SS (exemplo: semanal, terça-feira, 12:22:32) - Diário, HH:MM:SS (exemplo: diário, 12:22:32) - MonthlyByWeekAndDay, semana, dia, HH:MM:SS (exemplo: MonthlyByWeekAndDay, 2, sexta-feira, 21:00:00 indica 21:00 UTC na sexta-feira da 2ª semana de cada mês) - Nenhum indica que as atualizações do Windows não devem ser realizadas. As horas estão em UTC.
AcceptWindowsUpdateEula	Boolean (Padrão: true)	Ao definir esse sinalizador, o aplicativo aceita o Contrato de licença do usuário final para o Windows Update em nome do proprietário do computador.

Dica

Se você quiser que as atualizações do Windows ocorram imediatamente, defina WUFrequency em relação ao horário de implantação do aplicativo. Por exemplo, suponha que você tem um cluster de teste de cinco nós e planeja implantar o aplicativo em torno de 5:00 PM UTC. Se você presumir que a atualização ou implantação do aplicativo leva no máximo 30 minutos, defina o WUFrequency como Diário, 17:30:00.

Implantar o POA

1. Conclua todas as etapas necessárias para preparar o cluster.

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

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

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

Observação

Mantenha a pasta de scripts e de aplicativos PatchOrchestrationApplication no mesmo diretório.

Atualizar o POA

Para fazer upgrade da versão do POA usando o PowerShell, siga as instruções em Upgrade do aplicativo do Service Fabric usando o PowerShell.

Remover o POA

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

Para sua comodidade, fornecemos o script Undeploy.ps1 juntamente com o aplicativo. Para usar o script:

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

Observação

Mantenha a pasta de scripts e de aplicativos PatchOrchestrationApplication no mesmo diretório.

Exibir os resultados do Windows Update

O POA expõe as APIs REST para exibir os resultados históricos do usuário. Veja 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:

Campo	Valores	Detalhes
OperationResult	0 - Êxito 1 - Êxito com erros 2 - Falha 3 - Anulado 4 - Anulado com tempo limite	Indica o resultado da operação geral, que normalmente envolve a instalação de uma ou mais atualizações.
ResultCode	O mesmo que OperationResult	Este campo indica o resultado da operação de instalação para uma atualização individual.
OperationType	1 - Instalação 0 - Pesquisar e baixar	Por padrão, a instalação é o único OperationType que é mostrado nos resultados.
WindowsUpdateQuery	O padrão é "IsInstalled=0"	A consulta do Windows Update que foi usada para procurar atualizações. Para obter mais informações, confira WuQuery.
RebootRequired	true - a reinicialização foi necessária false - a reinicialização não foi necessária	Indica se uma reinicialização foi necessária para concluir a instalação das atualizações.
OperationStartTime	Datetime	Indica a hora em que a operação (download/instalação) foi iniciada.
OperationTime	Datetime	Indica a hora em que a operação (download/instalação) foi concluída.
HResult	0 - com sucesso outro – falha	Indica o motivo para a falha da atualização do Windows com updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

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

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

O ponto de extremidade REST para o Serviço do Coordenador tem uma porta dinâmica. Para verificar a URL exata, consulte o 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ê pode acessar a URL de fora do cluster também.

O ponto de extremidade que precisa ser atingido é 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.

Aviso

Depois que o proxy reverso estiver configurado, todos os microsserviços do cluster que exponham um ponto de extremidade HTTP serão endereçáveis de fora do cluster.

Diagnóstico e eventos de integridade

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

Observação

Para obter muitos dos aprimoramentos de autodiagnóstico chamados a seguir, você deve instalar o POA versão 1.4.0 ou posterior.

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

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

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

2. Depois que as atualizações forem baixadas, o NTService do Agente de Nó criará uma tarefa de reparo correspondente para o nó com o nome POS___<id_exclusivo>. Você pode exibir essas tarefas de reparo usando o cmdlet Get-ServiceFabricRepairTask ou usando o SFX na seção de detalhes do nó. Depois que a tarefa de reparo for criada, ela migra rapidamente para o estado Declarado.

3. Periodicamente, o Serviço de Coordenador procura tarefas de reparo no estado Declarado e as atualiza para o estado Em preparação com base na TaskApprovalPolicy. Se a TaskApprovalPolicy foi configurada como NodeWise, uma tarefa de reparo correspondente a um nó será preparada somente se nenhuma outra tarefa de reparo estiver no estado Em preparação, Aprovado, Em execução ou Em restauração no momento.

   Da mesma forma, no caso da UpgradeWise TaskApprovalPolicy, existem tarefas nos estados anteriores somente para os nós que pertencem ao mesmo domínio de atualização. Depois que uma tarefa de reparo é migrada para o estado Em preparação, o nó correspondente do Service Fabric será desabilitado e a intenção definida como Reiniciar.

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

   

4. Depois que o nó é desabilitado, a tarefa de reparo migra para o estado Em execução.

   Observação

   Um nó paralisado no estado Desabilitado pode bloquear uma nova tarefa de reparo, o que interrompe a operação de aplicação de patch no cluster.

5. Quando a tarefa de reparo estiver no estado Em execução, 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 migra para o estado Em restauração, o que reabilita 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-<Nome do Nó>. As seções realçadas 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á realizada quando a tarefa migrar para o estado Em 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 mais problemas ainda forem encontrados, entre na VM (máquina virtual) ou nas VMs e saiba mais sobre elas usando os logs de eventos do Windows. A tarefa de reparo mencionada anteriormente pode existir apenas nos seguintes subestados do executor:

   ExecutorSubState	Descrição
   None=1	Implica que não havia uma operação em andamento no nó. O estado pode ser Em transição.
   DownloadCompleted=2	Implica que a operação de download foi concluída com sucesso, falha parcial ou falha.
   InstallationApproved=3	Implica que a operação de download foi concluída anteriormente e Gerenciador de Reparos aprovou a instalação.
   InstallationInProgress=4	Corresponde ao estado de execução da tarefa de reparo.
   InstallationCompleted=5	Implica que a instalação foi concluída com sucesso, sucesso parcial ou falha.
   RestartRequested=6	Implica que a instalação do patch foi concluída e que 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 sucesso.
   OperationCompleted=9	A operação do Windows Update foi concluída com sucesso.
   OperationAborted=10	Implica que a operação do Windows Update foi anulada.

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

   

Logs de diagnóstico

Os logs do Aplicativo de Orquestração de Patch são coletados como parte dos logs de runtime do Service Fabric.

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

• e39b723c-590c-4090-abb0-11e3e6616346
• fc0028ff-bfdc-499f-80dc-ed922c52c5e9
• 24afa313-0d3b-4c7c-b485-1047fd964b60
• 05dc046c-60e9-4ef7-965e-91660adffa68

Relatórios de integridade

O POA também publica relatórios de integridade em relação ao Serviço do Coordinator ou ao Serviço de Agente do Nó nos seguintes cenários:

• O NTService do Agente do Nó está inativo

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

• O serviço de Gerenciador de Reparos não está habilitado

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

Perguntas 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 desabilita 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 patch ou todo o domínio de atualização pode ficar inativo ao mesmo tempo.

Até o fim da instalação das atualizações do Windows, os nós serão reabilitados 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 patch possa ser iniciada.

Caso o problema persista, consulte a seção de Solução de problemas.

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

R: verifique se um relatório de integridade postado em relação ao aplicativo indica a causa raiz. Geralmente, o aviso contém detalhes do problema. Se o problema for transitório, o aplicativo deve se recuperar automaticamente.

P: o que fazer se o cluster está não íntegro e preciso fazer uma atualização urgente do sistema operacional?

R: o POA não instala as atualizações enquanto o cluster está não íntegro. Tente colocar o cluster em um estado íntegro para desbloquear o fluxo de trabalho do POA.

P: eu devo definir TaskApprovalPolicy como "NodeWise" ou "UpgradeDomainWise" para meu cluster?

R: a configuração "UpgradeDomainWise" acelera o reparo geral do cluster, aplicando patches paralelamente em 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 ficam indisponíveis (no estado Desabilitado).

Por outro lado, a configuração "NodeWise" corrige apenas um nó de cada vez, o que significa que a aplicação geral de patches do cluster pode demorar mais. No entanto, somente um nó no máximo estaria indisponível (no estado Desabilitado) durante o processo de aplicação de patch.

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 patch (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-a como "NodeWise".

P: quanto tempo demora a aplicação de patch em um nó?

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

• O tamanho das atualizações.
• O número de atualizações que precisam ser aplicadas em uma janela de aplicação de patch.
• 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 do computador e as condições da rede.

P: quanto tempo leva a aplicação de patch a um cluster inteiro?

R: o tempo necessário para corrigir um cluster inteiro depende do seguinte:

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

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

  Por exemplo: se um nó leva cerca de 1 hora para ser corrigido, a aplicação de patch em um cluster de 20 nós (do mesmo tipo de nós) com 5 domínios de atualização, cada um contendo 4 nós, requer o seguinte:

  • Para "NodeWise": cerca de 20 horas.
  • Para "UpgradeDomainWise": cerca de 5 horas.

• A carga do cluster. Cada operação de aplicação de patch exige 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 Em desabilitação durante esse tempo. Se o cluster estiver sendo executado perto da carga de pico, o processo de desabilitação levaria mais tempo. Portanto, o processo geral de aplicação de patch pode parecer lento nessas condições sob pressão.

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

P: por que vejo algumas atualizações nos resultados do Windows Update obtidos por meio de API REST, mas não sob o histórico do Windows Update no computador?

R: algumas atualizações do produto são exibidas apenas em seu próprio histórico de atualização ou patch. Por exemplo, 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 o cluster de desenvolvimento (cluster de um nó) do patch?

R: não, o POA não pode ser usado para corrigir um cluster de um nó. Essa limitação é definida por design porque os serviços de sistema do Service Fabric ou outros aplicativos de cliente incorrem em tempo de inatividade. Portanto, os trabalhos de reparo de aplicação de patch nunca seriam aprovados pelo Gerenciador de Reparos.

P: como corrigir os nós de cluster no Linux?

R: para saber mais sobre a orquestração de atualizações no Linux, confira atualizações automáticas de imagem do sistema operacional do conjunto de dimensionamento de máquinas virtuais do Azure.

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

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

Se houver uma janela de tempo grande em que não há atualizações, o cluster pode estar em um estado de erro e, consequentemente, o Gerenciador de Reparos não poderá aprovar as tarefas de reparo do POA. Se a instalação da atualização estiver demorando muito em qualquer nó, talvez esse nó não estejam sendo atualizado há algum tempo. Muitas atualizações podem ter uma instalação pendente, o que pode resultar em atrasos.

Além disso, é possível que a aplicação de patches de nó seja bloqueada porque está paralisada no estado Em desabilitação. Isso geralmente acontece porque a desabilitação do nó pode causar perda de dados ou de quorum.

P: por que o nó deve ser desabilitado durante a aplicação de patch no POA?

R: o POA desabilita o nó com a intenção de reiniciar, o que interrompe ou realoca todos os serviços do Service Fabric em execução no nó. O POA faz isso para garantir que os aplicativos não acabem usando uma combinação de DLLs novas e antigas, portanto, é recomendável não aplicar patches em um nó sem desabilitá-lo.

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

R: o POA usa o Gerenciador de Reparos do Service Fabric para criar tarefas de reparo para atualizações de nós. No entanto, no máximo 250 tarefas de reparo podem estar presentes ao mesmo tempo. Atualmente, o POA cria tarefas de reparo para cada nó ao mesmo tempo. Portanto, o POA pode atualizar no máximo 250 nós em um cluster.

Avisos de Isenção de Responsabilidade

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

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

Solução de problemas

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

O nó não volta para o estado ativo

• O nó pode estar paralisado em um estado Em desabilitação porque:

  • Uma verificação de segurança está pendente. Para corrigir essa situação, verifique se há nós suficientes disponíveis em um estado íntegro.

• O nó pode estar paralisado em um estado Desabilitado porque:

  • Foi desabilitado manualmente.
  • Foi desabilitado devido a um trabalho de infraestrutura em andamento do Azure.
  • Foi desabilitado temporariamente pelo POA para a aplicação de patch no nó.

• O nó pode estar paralisado em um estado inativo porque:

  • Foi colocado em um estado inativo manualmente.
  • Está sendo reiniciado (o que pode ser disparado pelo POA).
  • Tem uma VM ou máquina com defeito 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, será gerado um relatório de integridade no nível de aviso em relação ao Serviço de Agente do Nó. O resultado do Windows Update também contém o possível motivo da falha.

A integridade do cluster apresentou um erro durante a instalação da atualização

Uma atualização do Windows com falha pode reduzir a integridade de um aplicativo ou cluster em um nó ou domínio de atualização específico. O POA interrompe 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 se tornou não íntegro devido ao Windows Update.

Notas de versão do POA

Observação

Para o POA versões 1.4.0 e posteriores, você pode encontrar as notas de versão e as versões na página de versão do Aplicativo de Orquestração de Patch no GitHub.

Version 1.1.0

• Versão pública

Versão 1.1.1

• Correção de bug no SetupEntryPoint de NodeAgentService que impediu a instalação de NodeAgentNTService.

Versão 1.2.0

• Correções de bugs em torno do fluxo de trabalho de reinício do sistema.
• Correção de bug na criação de tarefas RM devido à qual integridade seleção durante a preparação de tarefas de reparo não estava acontecendo conforme o esperado.
• Alteração do modo de inicialização do serviço Windows POANodeSvc de automático para automático com atraso.

Versão 1.2.1

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

Versão 1.2.2

• Diversas correções de bugs.
• Binários agora são assinados.
• Adição do link do sfpkg para o aplicativo.

Versão 1.3.0

• A definição de InstallWindowsOSOnlyUpdates como falso agora instala todas as atualizações disponíveis.
• Alteração da lógica de desabilitação de atualizações automáticas. Isso corrige um bug em que as atualizações Automáticas não são desabilitadas no Server 2016 e posterior.
• Restrição de posicionamento parametrizado para os dois microsserviços do POA para casos de uso avançados.

Versão 1.3.1

• Correção da regressão, em que o POA 1.3.0 não funcionará no Windows Server 2012 R2 ou anterior devido a uma falha ao desabilitar as atualizações automáticas.
• Correção de bug, em que a configuração InstallWindowsOSOnlyUpdates sempre é escolhida como True.
• Alteração do valor padrão de InstallWindowsOSOnlyUpdates para False.

Versão 1.3.2

• Correção de um problema que afeta o ciclo de vida da aplicação de patch 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 aplicação de patch seja ignorada ou que uma reinicialização esteja pendente.