Utilizar a Aplicação de Orquestração de Patches

Importante

A partir de 30 de abril de 2019, a versão 1.2.* da Aplicação Patch Orchestration já não é suportada. Certifique-se de que atualiza para a versão mais recente.

A Aplicação de Orquestração de Patches (POA) é um wrapper em torno do serviço Azure Service Fabric Repair Manager, que permite o agendamento de patches do SO baseado na configuração para clusters não alojados no Azure. A POA não é necessária para clusters não alojados do Azure, mas a instalação de patches de agendamento por domínio de atualização é necessária para corrigir anfitriões de clusters do Service Fabric sem incorrer em tempo de inatividade.

A POA é uma aplicação do Service Fabric que automatiza a aplicação de patches do sistema operativo num cluster do Service Fabric sem incorrer em períodos de inatividade.

A POA fornece as seguintes funcionalidades:

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

• Aplicação de patches com suporte para clusters e integração do estado de funcionamento. Enquanto a POA está a aplicar atualizações, monitoriza o estado de funcionamento 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 o estado de funcionamento do cluster ficar inativo devido ao processo de aplicação de patches, a aplicação de patches será interrompida para evitar agravar o problema.

Detalhes internos da POA

A POA é composta pelos seguintes subcomponentes:

• Serviço de Coordenador: este serviço com estado é responsável por:

  • Coordenar a tarefa de Windows Update em todo o cluster.
  • Armazenar o resultado de operações de Windows Update concluídas.

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

  • Bootstrapping the Node Agent NTService.
  • Monitorizar o Agente do Nó NTService.

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

  • Desativar as atualizações automáticas do Windows no nó.
  • Transferir e instalar atualizações do Windows de acordo com a política fornecida pelo utilizador.
  • Reiniciar a instalação de atualizações pós-Windows do computador.
  • Carregar os resultados das atualizações do Windows para o Serviço de Coordenador.
  • Comunicar relatórios de estado de funcionamento se uma operação tiver falhado depois de esgotar todas as tentativas.

Nota

A POA utiliza o serviço Service Fabric Repair Manager para desativar ou ativar o nó e efetuar verificações de estado de funcionamento. A tarefa de reparação criada pela POA controla o progresso Windows Update para cada nó.

Pré-requisitos

Nota

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

Ativar o serviço Gestor de Reparação (se ainda não estiver em execução)

A POA requer que o serviço Gestor de Reparação seja ativado no cluster.

Clusters do Azure

Os clusters do Azure no escalão de durabilidade silver têm o serviço Gestor de Reparação ativado por predefinição. Os clusters do Azure na camada de durabilidade dourada podem ou não ter o serviço Do Gestor de Reparação ativado, dependendo do momento em que esses clusters foram criados. Por predefinição, os clusters do Azure na camada de durabilidade de bronze não têm o serviço Gestor de Reparação ativado. Se o serviço já estiver ativado, pode vê-lo em execução na secção serviços do sistema no Service Fabric Explorer.

O portal do Azure

Pode ativar o Gestor de Reparação a partir do portal do Azure quando configurar o cluster. Quando estiver a configurar o cluster, selecione a opção Incluir Gestor de Reparaçãoem Funcionalidades de suplementos.

O modelo de implementação do Azure Resource Manager

Em alternativa, pode utilizar o modelo de implementação do Azure Resource Manager para ativar o serviço Repair Manager em clusters do Service Fabric novos e existentes. Obtenha o modelo para o cluster que pretende implementar. Pode utilizar os modelos de exemplo ou criar um modelo de implementação do Azure Resource Manager personalizado.

Para ativar o serviço Gestor de Reparação com o modelo de modelo de implementaçã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, terá de 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. Ative o serviço Gestor de Reparação ao adicionar a secção seguinte addonFeatures após a fabricSettings secção:

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

3. Depois de atualizar o modelo de cluster com estas alterações, aplique-as e deixe a atualização ser concluída. Agora, pode ver o serviço Gestor de Reparação em execução no cluster. Chama-se fabric:/System/RepairManagerService na secção serviços de sistema no Service Fabric Explorer.

Clusters no local autónomos

Para ativar o serviço Repair Manager num cluster novo ou existente do Service Fabric, pode utilizar as Definições de configuração para um cluster autónomo do Windows.

Para ativar o serviço Gestor de Reparação:

1. Verifique se apiVersion , em Geral, as configurações do cluster estão definidas como 04-2017 ou posterior, conforme mostrado aqui:

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

2. Ative o serviço Gestor de Reparação ao adicionar a secção seguinte addonFeatures após a fabricSettings secção, conforme mostrado aqui:

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

3. Atualize o manifesto do cluster com estas alterações ao utilizar o manifesto de cluster atualizado para criar um novo cluster ou atualizar a configuração do cluster.

   Depois de o cluster estar em execução com um manifesto de cluster atualizado, pode ver o serviço Gestor de Reparação em execução no cluster. Chama-se fabric:/System/RepairManagerService e está na secção serviços de 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, uma vez que vários nós de cluster podem ser reiniciados ao mesmo tempo. A POA, por predefinição, tenta desativar as atualizações automáticas do Windows em cada nó de cluster. No entanto, se as definições forem geridas por um administrador ou um Política de Grupo, recomendamos que defina a política de Windows Update para "Notificar antes de Transferir" explicitamente.

Transferir o pacote de aplicação

Para transferir o pacote de aplicações, aceda à página de lançamento da Aplicação de Orquestração de Patches no GitHub.

Configurar o comportamento da POA

Pode configurar o comportamento da POA para satisfazer as suas necessidades. Substitua os valores predefinidos ao transmitir o parâmetro da aplicação enquanto cria ou atualiza a aplicação. Pode fornecer parâmetros de aplicação ao especificar ApplicationParameter para os Start-ServiceFabricApplicationUpgrade cmdlets ou New-ServiceFabricApplication .

Parâmetro	Tipo	Detalhes
MaxResultsToCache	Longo	O número máximo de Windows Update resultados que devem ser colocados em cache. O valor predefinido é 3000, partindo do princípio de que:   - O número de nós é 20.   - O número de atualizações para um nó por mês é 5.   - O número de resultados por operação pode ser 10.   - Os resultados dos últimos três meses devem ser armazenados.
TaskApprovalPolicy	Enumeração { NodeWise, UpgradeDomainWise }	TaskApprovalPolicy indica a política que deve ser utilizada pelo Serviço de Coordenação para instalar atualizações do Windows nos nós de cluster do Service Fabric. Os valores permitidos são: NodeWise: as atualizações do Windows são instaladas num nó de cada vez. UpgradeDomainWise: as atualizações do Windows são instaladas um domínio de atualização de cada vez. (No máximo, todos os nós pertencentes a um domínio de atualização podem optar por uma atualização do Windows.) Para ajudar a decidir qual a política mais adequada para o cluster, consulte a secção FAQ .
LogsDiskQuotaInMB	Longo (Predefinição: 1024)	O tamanho máximo dos registos de aplicações de orquestração de patches em MB, que podem ser mantidos localmente nos nós.
WUQuery	string (Predefinição: IsInstalled=0)	Consultar para obter atualizações do Windows. Para obter mais informações, veja WuQuery.
InstallWindowsOSOnlyUpdates	Booleano (predefinição: falso)	Utilize este sinalizador para controlar as atualizações que devem ser transferidas e instaladas. Os seguintes valores são permitidos true - Instala apenas atualizações do sistema operativo Windows. false - instala todas as atualizações disponíveis no computador.
WUOperationTimeOutInMinutes	int (Predefinição: 90)	Especifica o tempo limite para qualquer operação de Windows Update (pesquisa, transferência ou instalação). Se a operação não estiver concluída dentro do tempo limite especificado, esta será abortada.
WURescheduleCount	int (Predefinição: 5)	O número máximo de vezes que o serviço reagenda a atualização do Windows se uma operação falhar persistentemente.
WURescheduleTimeInMinutes	int (Predefinição: 30)	O intervalo no qual o serviço reagenda as atualizações do Windows se a falha persistir.
WUFrequency	Cadeia separada por vírgulas (Predefinição: Semanalmente, Quarta-feira, 7:00:00)	A frequência de instalação de 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 números de 1 a 28 e último. - Semanalmente, Dia, HH:MM:SS (exemplo: Semanalmente, Terça-feira, 12:22:32) - Diariamente, HH:MM:SS (exemplo: Diariamente, 12:22:32) - MonthlyByWeekAndDay, Week, Day, HH:MM:SS (exemplo: MonthlyByWeekAndDay, 2, Friday, 21:00:00 indica 21 :00 UTC na sexta-feira da 2ª semana de cada mês) - Nenhuma indica que as atualizações do Windows não devem ser feitas. As horas estão em UTC.
AcceptWindowsUpdateEula	Booleano (Predefinição: verdadeiro)	Ao definir este sinalizador, a aplicação aceita o Contrato de Licença End-User para Windows Update em nome do proprietário do computador.

Dica

Se quiser que as atualizações do Windows ocorram imediatamente, defina WUFrequency em relação ao tempo de implementação da aplicação. Por exemplo, suponha que tem um cluster de teste de cinco nós e planeia implementar a aplicação por volta das 17:00 UTC. Se assumir que a atualização ou implementação da aplicação demora, no máximo, 30 minutos, defina WUFrequency como Diário, 17:30:00.

Implementar POA

1. Conclua todos os passos de pré-requisitos para preparar o cluster.

2. Implemente a POA como qualquer outra aplicação do Service Fabric. Para implementá-lo com o PowerShell, veja Implementar e remover aplicações com o PowerShell.

3. Para configurar a aplicação no momento da implementação, passe o ApplicationParameter para o New-ServiceFabricApplication cmdlet. Para sua comodidade, fornecemos o script Deploy.ps1 juntamente com a aplicação. Para utilizar o script:

   • Ligue-se a um cluster do Service Fabric com Connect-ServiceFabricCluster.
   • Execute o script do PowerShell Deploy.ps1 com o valor adequado ApplicationParameter .

Nota

Mantenha o script e a pasta da aplicação PatchOrchestrationApplication no mesmo diretório.

Atualizar POA

Para atualizar a sua versão de POA com o PowerShell, siga as instruções em Atualização da aplicação do Service Fabric com o PowerShell.

Remover POA

Para remover a aplicação, siga as instruções em Implementar e remover aplicações com o PowerShell.

Para sua comodidade, fornecemos o script Undeploy.ps1 juntamente com a aplicação. Para utilizar o script:

• Ligue-se a um cluster do Service Fabric com Connect-ServiceFabricCluster.
• Execute o script do PowerShell Undeploy.ps1.

Nota

Mantenha o script e a pasta da aplicação PatchOrchestrationApplication no mesmo diretório.

Ver os resultados do Windows Update

A POA expõe as APIs REST para apresentar os resultados históricos aos utilizadores. Eis um exemplo do JSON do resultado:

[
  {
    "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 estão descritos na seguinte tabela:

Campo	Valores	Detalhes
OperationResult	0 - Com êxito 1 - Com êxito com erros 2 - Falha 3 - Abortado 4 - Abortado com tempo limite	Indica o resultado da operação geral, que normalmente envolve a instalação de uma ou mais atualizações.
Código de Resultado	O mesmo que OperationResult	Este campo indica o resultado da operação de instalação de uma atualização individual.
Tipo de Operação	1 - Instalação 0 - Procurar e Transferir	Por predefinição, a Instalação é o único OperationType apresentado nos resultados.
WindowsUpdateQuery	A predefinição é "IsInstalled=0"	A consulta Windows Update utilizada para procurar atualizações. Para obter mais informações, veja WuQuery.
RebootRequired	true - foi necessário reiniciar false - o reinício não foi necessário	Indica se foi necessário reiniciar para concluir a instalação de atualizações.
OperationStartTime	DateTime	Indica o momento em que a operação (Transferência/Instalação) foi iniciada.
OperationTime	DateTime	Indica o momento em que a operação (Transferência/Instalação) foi concluída.
HResult	0 - Êxito outra - falha	Indica o motivo da falha da atualização do Windows com updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

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

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

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

Se o proxy inverso estiver ativado no cluster, também pode aceder ao URL a partir de fora do cluster.

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

Para ativar o proxy inverso no cluster, siga as instruções em Inverter proxy no Azure Service Fabric.

Aviso

Após a configuração do proxy inverso, todos os microsserviços no cluster que expõem um ponto final HTTP são endereçáveis fora do cluster.

Diagnósticos e eventos de estado de funcionamento

Esta secção aborda como depurar ou diagnosticar problemas com atualizações de patches através de POA em clusters do Service Fabric.

Nota

Para obter muitos dos seguintes melhoramentos de autodiagnóstruos chamados, deve ter a versão 1.4.0 ou posterior da POA instalada.

O Agente do Nó NTService cria tarefas de reparação para instalar atualizações nos nós. Cada tarefa é então preparada pelo Serviço de Coordenação de acordo com a política de aprovação de tarefas. Por fim, as tarefas preparadas são aprovadas pelo Gestor de Reparação, que não aprova nenhuma tarefa se o cluster estiver num estado de mau estado de funcionamento.

Para o ajudar a compreender como as atualizações prosseguem num nó, vamos passo a passo:

1. NodeAgentNTService, em execução em todos os nós, procura atualizações do Windows disponíveis na hora agendada. Se estiverem disponíveis atualizações, transfere-as no nó.

2. Após a transferência das atualizações, o Agente do Nó NTService cria uma tarefa de reparação correspondente para o nó com o nome POS___<unique_id>. Pode ver estas tarefas de reparação com o cmdlet Get-ServiceFabricRepairTask ou com o SFX na secção de detalhes do nó. Após a criação da tarefa de reparação, esta muda rapidamente para o estado Afirmação.

3. O Serviço de Coordenador procura periodicamente tarefas de reparação no estado Reclamado e, em seguida, atualiza-as para o estado Preparação com base em TaskApprovalPolicy. Se TaskApprovalPolicy estiver configurado para ser NodeWise, uma tarefa de reparação que corresponda a um nó só será preparada se nenhuma outra tarefa de reparação estiver atualmente no estado Preparação, Aprovação, Execução ou Restauro .

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

   As versões de POA 1.4.0 e posteriores publicam eventos com a propriedade ClusterPatchingStatus no CoordinatorService para apresentar os nós que estão a ser corrigidos. As atualizações são instaladas no _poanode_0, conforme mostrado na imagem seguinte:

   

4. Após a desativação do nó, a tarefa de reparação é movida para o estado de Execução .

   Nota

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

5. Quando a tarefa de reparação estiver no estado execução , a instalação do patch nesse nó começa. Após a instalação do patch, o nó poderá ou não ser reiniciado, dependendo do patch. Em seguida, a tarefa de reparação é movida para o estado de Restauro , o que reativa o nó. A tarefa de reparação é então marcada como concluída.

   Nas versões 1.4.0 e posteriores da POA, pode encontrar o estado da atualização ao ver os eventos de estado de funcionamento no NodeAgentService com a propriedade WUOperationStatus-NodeName<>. As secções realçadas nas seguintes imagens mostram o estado das atualizações do Windows nos nós poanode_0 e poanode_2:

   

   

   Também pode obter os detalhes com o PowerShell. Para tal, ligue-se ao cluster e obtenha o estado da tarefa de reparação com Get-ServiceFabricRepairTask.

   No exemplo seguinte, a tarefa "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" está no estado DownloadComplete . Significa que as atualizações foram transferidas no nó poanode_2 e a instalação será tentada quando a tarefa mudar 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 os mesmos com os registos de eventos do Windows. A tarefa de reparação mencionada anteriormente só pode existir nos seguintes subestados do executor:

   ExecutorSubState	Descrição
   Nenhum=1	Implica que não houve uma operação em curso no nó. O estado pode estar em transição.
   DownloadCompleted=2	Implica que a operação de transferência foi concluída com êxito, falha parcial ou falha.
   InstallationApproved=3	Implica que a operação de transferência foi concluída anteriormente e o Gestor de Reparação aprovou a instalação.
   InstallationInProgress=4	Corresponde ao estado de execução da tarefa de reparação.
   InstallationCompleted=5	Implica que a instalação foi concluída com êxito, êxito parcial ou falha.
   ReiniciarRequested=6	Implica que a instalação do patch foi concluída e que existe uma ação de reinício pendente no nó.
   RestartNotNeeded=7	Implica que o reinício não foi necessário após a conclusão da instalação do patch.
   RestartCompleted=8	Implica que o reinício foi concluído com êxito.
   OperationCompleted=9	A operação Windows Update foi concluída com êxito.
   OperationAborted=10	Implica que a operação de Windows Update foi abortada.

6. Nas versões 1.4.0 e posteriores da POA, quando uma tentativa de atualização de nó é concluída, é publicado um evento com a propriedade "WUOperationStatus-[NodeName]" no NodeAgentService para notificá-lo quando a próxima tentativa de transferir e instalar as atualizações do Windows será iniciada. Esta ação é apresentada na imagem seguinte:

   

Registos de diagnósticos

Os registos de aplicações de orquestração de patches são recolhidos como parte dos registos de runtime do Service Fabric.

Pode capturar registos com a ferramenta de diagnóstico ou o pipeline à sua escolha. A POA utiliza os seguintes IDs de fornecedor fixos para registar eventos através da origem 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 estado de funcionamento

A POA também publica relatórios de estado de funcionamento no Serviço do Agente de Nó ou no Serviço de Coordenador nos seguintes cenários:

• O NTService do Agente do Nó está inativo

  Se o NTService do Agente do Nó estiver inativo num nó, é gerado um relatório de estado de funcionamento ao nível do aviso no Serviço do Agente do Nó.

• O serviço Gestor de Reparação não está ativado

  Se o serviço Gestor de Reparação não for encontrado no cluster, é gerado um relatório de estado de funcionamento ao nível do aviso para o Serviço de Coordenador.

Perguntas mais frequentes

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

R: Durante o processo de instalação, a POA desativa ou reinicia os nós, o que pode resultar temporariamente num cluster em mau estado de funcionamento.

Dependendo da política da aplicação, um nó pode ficar inativo durante uma operação de aplicação de patches ou um domínio de atualização completo 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 o reinício.

No exemplo seguinte, o cluster passou temporariamente para um estado de erro 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, veja a secção Resolução de problemas.

P: O que posso fazer se a POA estiver num estado de aviso?

R: Verifique se um relatório de estado de funcionamento publicado na aplicação indica a causa raiz. Normalmente, o aviso contém detalhes do problema. Se o problema for transitório, espera-se que a aplicação recupere automaticamente.

P: O que posso fazer se o meu cluster estiver em mau estado de funcionamento e precisar de fazer uma atualização urgente do sistema operativo?

R: A POA não instala atualizações enquanto o cluster estiver em mau estado de funcionamento. Tente colocar o cluster num bom estado de funcionamento para desbloquear o fluxo de trabalho da POA.

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

R: A definição "UpgradeDomainWise" acelera a reparação geral do cluster ao aplicar patches em paralelo a 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 completo estão indisponíveis (no estado Desativado).

Por outro lado, a definição "NodeWise" corrige apenas um nó de cada vez, o que implicaria que a aplicação de patches de cluster geral poderia demorar 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 conseguir tolerar a execução num 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), pode definir a política como "UpgradeDomainWise". Caso contrário, defina-o como "NodeWise".

P: Quanto tempo demora a corrigir um nó?

R: A aplicação de patches a um nó pode demorar de minutos (por exemplo, Windows Defender atualizações de definição) 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 têm de ser aplicadas numa janela de aplicação de patches.
• O tempo necessário para instalar as atualizações, reiniciar o nó (se necessário) e concluir os passos de instalação pós-reinício.
• O desempenho da VM ou do computador e as condições de rede.

P: Quanto tempo demora a corrigir um cluster inteiro?

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

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

• A política do Serviço de Coordenação. A política predefinida, "NodeWise", resulta na aplicação de patches apenas a um nó de cada vez, uma abordagem mais lenta do que a utilização de "UpgradeDomainWise".

  Por exemplo: se um nó demorar cerca de 1 hora a ser corrigido, a aplicação de patches a um cluster de 20 nós (mesmo tipo de nós) com 5 domínios de atualização, cada um com 4 nós, requer:

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

• A carga do cluster. Cada operação de aplicação de patches requer a relocalização da carga de trabalho do cliente para outros nós disponíveis no cluster. Um nó que está a ser corrigido estaria no estado Desativar durante este período de tempo. Se o cluster estiver a ser executado perto do pico de carga, o processo de desativação demorará mais tempo. Por conseguinte, o processo geral de aplicação de patches pode parecer lento em condições tão stressadas.

• Falhas de estado de funcionamento do cluster durante a aplicação de patches. Qualquer degradação no estado de funcionamento do cluster interromperia o processo de aplicação de patches. Este problema iria aumentar o tempo global necessário para corrigir todo o cluster.

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

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

P: A POA pode ser utilizada para corrigir o meu cluster de desenvolvimento (cluster de um nó)?

R: Não, a POA não pode ser utilizada para corrigir um cluster de um nó. Esta limitação é por predefinição, porque os serviços de sistema do Service Fabric ou outras aplicações de cliente incorreriam em tempo de inatividade. Por conseguinte, as tarefas de reparação de patches nunca seriam aprovadas pelo Gestor de Reparação.

P: Como devo proceder para nós de cluster de patch no Linux?

R: Para saber mais sobre como orquestrar atualizações no Linux, veja Atualizações automáticas da imagem do SO do conjunto de dimensionamento de máquinas virtuais do Azure.

P: Porque é que o ciclo de atualização está a demorar tanto tempo?

R: Consulte o JSON do resultado, introduza o ciclo de atualização para todos os nós e, em seguida, pode tentar descobrir o tempo decorrido pela instalação da atualização em cada nó com OperationStartTime e OperationTime (OperationCompletionTime).

Se existir um período de tempo grande no qual não está a ocorrer nenhuma atualização, o cluster pode estar num estado de erro e, consequentemente, o Gestor de Reparação não consegue aprovar nenhuma tarefa de reparação poa. Se a instalação da atualização estiver a demorar muito tempo em qualquer nó, esse nó poderá não ter sido atualizado durante algum tempo. Muitas atualizações podem estar pendentes de instalação, o que pode resultar em atrasos.

Também pode ser possível que a aplicação de patches de nós esteja bloqueada porque está bloqueada no estado A desativar . Normalmente, isto acontece porque a desativação do nó pode levar a situações de quórum ou perda de dados.

P: Por que motivo o nó tem de ser desativado quando a POA está a aplicação de patches?

R: A POA desativa o nó com uma intenção Reiniciar , que para ou realoca todos os serviços do Service Fabric que estão em execução no nó. A POA faz isto para garantir que as aplicações não acabam por utilizar uma mistura de DLLs novas e antigas, pelo que recomendamos que não aplicação de patches a um nó sem a desativar.

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

R: A POA utiliza o Service Fabric Repair Manager para criar tarefas de reparação para nós para atualizações. No entanto, não podem estar presentes mais de 250 tarefas de reparação ao mesmo tempo. Atualmente, a POA cria tarefas de reparação para cada nó ao mesmo tempo, pelo que a POA não pode atualizar mais de 250 nós num cluster.

Exclusões de Responsabilidade

• A POA aceita o Contrato de Licença do End-User para Windows Update em nome do utilizador. Opcionalmente, a definição pode ser desativada na configuração da aplicação.

• A POA recolhe telemetria para controlar a utilização e o desempenho. A telemetria da aplicação segue a definição da definição de telemetria do runtime do Service Fabric (que está ativada por predefinição).

Resolução de problemas

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

Um nó não está a voltar ao estado de funcionamento

• O nó pode estar bloqueado no estado Desativar porque:

  • Está pendente uma verificação de segurança. Para remediar esta situação, certifique-se de que existem nós suficientes disponíveis num bom estado de funcionamento.

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

  • Foi desativado manualmente.
  • Foi desativada devido a uma tarefa de infraestrutura do Azure em curso.
  • Foi desativado temporariamente pela POA para corrigir o nó.

• O nó pode estar bloqueado num estado de inatividade porque:

  • Foi colocado manualmente num estado de inatividade.
  • Está a ser reiniciado (que pode ser acionado pela POA).
  • Tem uma VM ou máquina com falhas ou está a ter problemas de conectividade de rede.

Atualizações foram ignoradas em alguns nós

A 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 da aplicação.

Nesse caso, é gerado um relatório de estado de funcionamento ao nível do aviso no Serviço do Agente do Nó. O resultado Windows Update também contém o motivo possível para a falha.

O estado de funcionamento do cluster entra em erro enquanto a atualização está a ser instalada

Uma atualização do Windows com falhas pode reduzir o estado de funcionamento de uma aplicação ou cluster num determinado nó ou domínio de atualização. A POA descontinua qualquer operação de Windows Update subsequente até que o cluster esteja novamente em bom estado de funcionamento.

Um administrador tem de intervir e determinar por que motivo a aplicação ou cluster ficou em mau estado de funcionamento devido a Windows Update.

Notas de versão da POA

Nota

Para as versões 1.4.0 e posteriores da POA, pode encontrar notas de versão e versões na página de lançamento da Aplicação de Orquestração de Patches no GitHub.

Versão 1.1.0

• Lançamento público

Versão 1.1.1

• Foi corrigido um erro em SetupEntryPoint do NodeAgentService que impedia a instalação do NodeAgentNTService.

Versão 1.2.0

• Correções de erros em torno do fluxo de trabalho de reinício do sistema.
• Correção de erros na criação de tarefas RM devido ao qual a verificação do estado de funcionamento durante a preparação das tarefas de reparação não estava a ocorrer conforme esperado.
• O modo de arranque do serviço Windows POANodeSvc foi alterado de automático para automático atrasado.

Versão 1.2.1

• Correção de erros no fluxo de trabalho de redução vertical do cluster. Introduziu a lógica de libertação da memória para tarefas de reparação de POA pertencentes a nós inexistentes.

Versão 1.2.2

• Correções de erros diversas.
• Os binários estão agora assinados.
• Ligação sfpkg adicionada para a aplicação.

Versão 1.3.0

• Definir InstallWindowsOSOnlyUpdates como falso agora instala todas as atualizações disponíveis.
• Alterou a lógica da desativação das atualizações automáticas. Esta ação corrige um erro em que as Atualizações automáticas não estavam a ser desativadas no Server 2016 e superior.
• Restrição de colocação parametrizada para ambos os microsserviços da POA para casos de utilização avançados.

Versão 1.3.1

• Corrigir a regressão em que a 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.
• Corrigir o erro em que a configuração InstallWindowsOSOnlyUpdates é sempre escolhida como Verdadeiro.
• Alterar o valor predefinido de InstallWindowsOSOnlyUpdates para Falso.

Versão 1.3.2

• Corrigir um problema que afeta o ciclo de vida de aplicação de patches num nó, se existirem nós com um nome que seja um subconjunto do nome do nó atual. Para esses nós, é possível que tenha falhado a aplicação de patches ou que esteja pendente um reinício.