Usare Patch Orchestration Application

Patch Orchestration Application (POA) è un wrapper per il servizio Gestione ripristini di Azure Service Fabric, che consente la pianificazione dell’applicazione di patch al sistema operativo basata sulla configurazione per i cluster non ospitati in Azure. Patch Orchestration Application non è obbligatorio per i cluster non ospitati in Azure, ma la pianificazione dell'installazione delle patch dai domini di aggiornamento è necessaria per applicare le patch agli host dei cluster senza tempi di inattività.

Patch Orchestration Application è un'applicazione di Service Fabric che automatizza l'applicazione di patch ai sistemi operativi in un cluster di Service Fabric senza tempi di inattività.

Offre le funzionalità seguenti:

• Installazione automatica dell'aggiornamento del sistema operativo. Gli aggiornamenti del sistema operativo vengono scaricati e installati automaticamente. I nodi del cluster vengono riavviati in base alle esigenze senza tempi di inattività del cluster.

• Integrazione dell'integrità e l'applicazione di patch compatibile con il cluster. Durante l'applicazione degli aggiornamenti, viene monitorata l'analisi dell'integrità dei nodi del cluster. I nodi del cluster vengono aggiornati un nodo alla volta o un dominio di aggiornamento alla volta. Se l'integrità del cluster diminuisce a causa del processo di applicazione di patch, l'applicazione di patch viene interrotta per evitare che il problema si aggravi.

Dettagli interni di Patch Orchestration Application

Patch Orchestration Application è costituita dai sottocomponenti seguenti:

• Coordinator Service: il servizio con stato è responsabile per:

  • Il coordinamento del processo di Windows Update nell'intero cluster.
  • L'archiviazione del risultato delle operazioni completate di Windows Update.

• Node Agent Service: è un servizio senza stato che viene eseguito in tutti i nodi di cluster di Service Fabric. Il servizio è responsabile per:

  • Il bootstrap del Node Agent NTService.
  • Il monitoraggio di Node Agent NTService

• Node agent NTService: questo servizio di Windows NT viene eseguito con un privilegio di livello superiore (SYSTEM). Il Node Agent Service e il Coordinator Service vengono invece eseguiti con un privilegio di livello inferiore (NETWORK SERVICE). Il servizio è responsabile dell'esecuzione dei seguenti processi di Windows Update in tutti i nodi del cluster:

  • Disabilitazione degli aggiornamenti di Windows automatici nel nodo.
  • Download e installazione degli aggiornamenti di Windows in base ai criteri forniti dall'utente.
  • Riavvio del computer dopo l'installazione degli aggiornamenti di Windows.
  • Caricamento dei risultati di Windows Update nel Coordinator Service.
  • naSegnalazione dei report sull'integrità nell’eventualità di operazione non riuscita e dopo l'esaurimento di tutti i tentativi.

Prerequisiti

Abilitare il servizio Gestione ripristini (se non è già in esecuzione)

Patch Orchestration Application richiede che il servizio Gestione ripristini sia abilitato nel cluster.

Cluster di Azure

Per impostazione predefinita, il servizio Gestione ripristini è abilitato nei cluster di Azure al livello di durabilità silver. Il servizio Gestione ripristini può essere abilitato o meno nei cluster di Azure al livello di durabilità gold, a seconda della loro data di creazione. Per impostazione predefinita, il servizio Gestione ripristini non è abilitato nei cluster di Azure al livello di durabilità bronze. Se il servizio è già abilitato, è possibile vederlo in esecuzione nella sezione relativa ai servizi del sistema in Service Fabric Explorer.

Il portale di Azure

È possibile abilitare Gestione ripristini dal portale di Azure al momento della configurazione del cluster. Al momento della configurazione del cluster, selezionare l'opzione Includi Gestione ripristini in Funzionalità aggiuntive.

Modello di distribuzione di Azure Resource Manager:

In alternativa, è possibile usare il modello di distribuzione di Azure Resource Manager per abilitare il servizio Gestione ripristini nei cluster nuovi ed esistenti di Service Fabric. Ottenere il modello per il cluster che si vuole distribuire. È possibile usare i modelli di esempio o creare un modello di distribuzione Azure Resource Manager personalizzato.

Per abilitare il servizio Gestione ripristini con il modello del modello di distribuzione di Azure Resource Manager, eseguire le operazioni seguenti:

1. Verificare che apiVersion sia impostato su 2017-07-01-preview per la risorsa Microsoft.ServiceFabric/clusters. Se l’impostazione non corrisponde, è necessario eseguire l'aggiornamento di apiVersion alla versione 2017-07-01-preview o a una versione successiva:

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

2. A questo punto, abilitare il servizio Gestione ripristini aggiungendo la sezione addonFeatures seguente dopo la sezione fabricSettings:

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

3. Dopo aver aggiornato il modello del cluster con queste modifiche, applicarle e attendere il completamento dell'aggiornamento. È ora possibile vedere il servizio Gestione ripristini in esecuzione nel cluster. È denominato fabric:/System/RepairManagerService nella sezione dei servizi di sistema in Service Fabric Explorer.

Cluster locali autonomi

È possibile usare le impostazioni di configurazione per un cluster Windows autonomo per abilitare il servizio Gestione ripristini nei cluster di Service Fabric nuovi ed esistenti.

Per abilitare il servizio Gestione ripristini:

1. Verificare che apiVersion nelle configurazioni generali del cluster sia impostato su 04-2017 o una versione successiva, come illustrato di seguito:

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

2. A questo punto abilitare il servizio Gestione ripristini aggiungendo la sezione addonFeatures seguente dopo la sezione fabricSettings, come illustrato di seguito:

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

3. Aggiornare il manifesto del cluster con queste modifiche usando il manifesto del cluster aggiornato Creare un nuovo cluster o Aggiornare la configurazione del cluster.

   Dopo l'esecuzione del cluster con un manifesto del cluster aggiornato, è possibile visualizzare il servizio Gestione ripristini in esecuzione nel cluster. È denominato fabric:/System/RepairManagerServiceed è presente nella sezione servizi di sistema in Service Fabric Explorer.

Configurare gli aggiornamenti di Windows per tutti i nodi

Gli aggiornamenti automatici di Windows potrebbero causare la perdita di disponibilità perché più nodi del cluster possono riavviarsi contemporaneamente. Per impostazione predefinita, Patch Orchestration Application tenta di disabilitare gli aggiornamenti automatici di Windows in ogni nodo del cluster. Tuttavia, se le impostazioni sono gestite da un amministratore o dai Criteri di gruppo, è consigliabile impostare esplicitamente i criteri di Windows Update su “Notifica prima del download”.

Scaricare il pacchetto dell'applicazione

Per scaricare il pacchetto dell'applicazione, passare alla pagina Versione di Patch Orchestration Application in GitHub.

Configurare il comportamento di Patch Orchestration Application

È possibile configurare il comportamento di Patch Orchetration Application in base alle proprie esigenze. Eseguire l'override dei valori predefiniti passando il parametro dell'applicazione durante la creazione o l'aggiornamento dell'applicazione. È possibile indicare i parametri dell'applicazione specificando ApplicationParameter per i cmdlet Start-ServiceFabricApplicationUpgrade o New-ServiceFabricApplication.

Distribuire Patch Orchestration Application

1. Completare tutti i passaggi preliminari per preparare il cluster.

2. Distribuire Patch Orchestration Application come qualsiasi altra app di Service Fabric. Per distribuirla con PowerShell, vedere Distribuire e rimuovere applicazioni con PowerShell.

3. Per configurare l'applicazione al momento della distribuzione, passare ApplicationParameter al cmdlet New-ServiceFabricApplication. Per praticità, è stato fornito lo script Deploy.ps1 insieme all'applicazione. Per usare lo script:

   • Connettersi a un cluster di Service Fabric tramite Connect-ServiceFabricCluster.
   • Eseguire lo script Deploy.ps1 di PowerShell con il valore ApplicationParameter appropriato.

Aggiornare Patch Orchestration Application

Per aggiornare la versione di Patch Orchestration Application con PowerShell, seguire le istruzioni riportate in Aggiornamento dell'applicazione di Service Fabric con PowerShell.

Rimuovere Patch Orchestration Application

Per rimuovere l'applicazione, seguire la procedura descritta in Distribuire e rimuovere applicazioni con PowerShell.

Per praticità, è stato fornito lo script Undeploy.ps1 insieme all'applicazione. Per usare lo script:

• Connettersi a un cluster di Service Fabric tramite Connect-ServiceFabricCluster.
• Eseguire lo script Undeploy.ps1 di PowerShell.

Visualizzare i risultati di Windows Update

Patch Orchestration Application espone le API REST per consentire agli utenti di visualizzare i risultati cronologici. Di seguito è riportato un esempio del risultato 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
      }
    ]
  },
  ...
]

I campi JSON sono descritti nella tabella seguente:

Se non è stato ancora pianificato alcun aggiornamento, il file JSON dei risultati è vuoto.

Accedere al cluster per eseguire la query sui risultati di Windows Update. Trovare l’indirizzo IP della replica per l’indirizzo primario del servizio Coordinatore e aprire il seguente URL dal browser: http://<REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

L'endpoint REST per Coordinator Service dispone di una porta dinamica. Per controllare l'URL esatto, fare riferimento a Service Fabric Explorer. Ad esempio, i risultati sono disponibili in http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Se il proxy inverso è abilitato nel cluster, l'utente può accedere all'URL anche dall'esterno del cluster.

L’endpoint da scegliere è http://<SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

Per abilitare il proxy inverso nel cluster, seguire la procedura descritta in Proxy inverso in Azure Service Fabric.

Eventi di diagnostica e integrità

Questa sezione illustra come eseguire il debug o diagnosticare i problemi relativi agli aggiornamenti delle patch effettuati tramite Patch Orchestration Application nei cluster di Service Fabric.

Node Agent NTService crea attività di ripristino per l'installazione degli aggiornamenti nei nodi. Ogni attività viene quindi preparata dal servizio Coordinatore in base ai criteri di approvazione delle attività. Infine, le attività preparate vengono approvate da Gestione ripristini, che non approva alcuna attività se il cluster si trova in uno stato non integro.

Per comprendere in che modo gli aggiornamenti procedono in un nodo, è possibile procedere in modo dettagliato:

1. NodeAgentNTService, in esecuzione in ogni nodo, cerca gli aggiornamenti di Windows disponibili all'ora pianificata. Se gli aggiornamenti sono disponibili, li scarica nel nodo.

2. Dopo il download degli aggiornamenti, Node Agent NTService crea un'attività di ripristino corrispondente per il nodo con il nome POS___<unique_id>. È possibile visualizzare queste attività di ripristino usando il cmdletGet-ServiceFabricRepairTask o SFX nella sezione dei dettagli del nodo. Dopo la creazione, l'attività di ripristino passa rapidamente allo stato Richiesto.

3. Il servizio Coordinatore cerca periodicamente le attività di ripristino con lo stato Richiesto e quindi le aggiorna impostandole nello stato Preparazione in base al valore di TaskApprovalPolicy. Se TaskApprovalPolicy è configurato come NodeWise, viene preparata un'attività di ripristino corrispondente a un nodo solo se lo stato di nessun'altra attività di ripristino è attualmente Preparazione, Approvato, In esecuzione o Ripristino.

   Analogamente, nel caso di UpgradeWise TaskApprovalPolicy, sono presenti attività negli stati precedenti solo per i nodi che appartengono allo stesso dominio di aggiornamento. Dopo lo spostamento di un'attività di ripristino nello stato Preparazione , il nodo di Service Fabric corrispondente viene disabilitato con la finalità impostata su Riavvia.

   Le versioni 1.4.0 e successive di Patch Orchestration Application pubblicano eventi con la proprietà ClusterPatchingStatus in CoordinatorService per consentire la visualizzazione dei nodi a cui vengono applicate le patch. Gli aggiornamenti vengono installati in _poanode_0, come illustrato nell'immagine seguente:

   

4. Dopo la disabilitazione del nodo, l'attività di ripristino viene spostata nello stato In esecuzione.

   Nota

   Un nodo bloccato nello stato Disabilitato può bloccare una nuova attività di ripristino, che interrompe l'operazione di applicazione di patch nel cluster.

5. Quando l'attività di ripristino è nello stato In esecuzione , viene avviata l'installazione della patch in tale nodo. Dopo l'installazione della patch, è possibile che il nodo venga o meno riavviato, a seconda della patch. Successivamente, l'attività di ripristino viene spostata nello stato Ripristino, che riabilita il nodo. L'attività di ripristino viene quindi contrassegnata come completata.

   Nelle versioni 1.4.0 e successive di Patch Orchestration Application è possibile trovare lo stato dell'aggiornamento visualizzando gli eventi di integrità in NodeAgentService con la proprietà WUOperationStatus-<NodeName>. Le sezioni evidenziate nelle immagini seguenti mostrano lo stato degli aggiornamenti di Windows nei nodi poanode_0 e poanode_2:

   

   

   È anche possibile ottenere i dettagli usando PowerShell. A tale scopo, connettersi al cluster e recuperare lo stato dell'attività di ripristino usando Get-ServiceFabricRepairTask.

   Nell'esempio seguente lo stato dell'attività "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" è DownloadComplete. Significa che gli aggiornamenti sono stati scaricati nel nodo poanode_2 e che l'installazione verrà tentata quando lo stato dell'attività passa a In esecuzione.

    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 permangono altri problemi, accedere alla macchina virtuale o alle macchine virtuali e ottenere informazioni su tali problemi usando i registri eventi di Windows. L'attività di ripristino menzionata in precedenza può essere presente solo nei sottostati dell'executor seguenti:

   ExecutorSubState	Descrizione
   None = 1	Implica che non c’era un'operazione in corso sul nodo. Lo stato potrebbe essere in transizione.
   DownloadCompleted=2	Implica che l'operazione di download è stata completata con un esito positivo, un errore parziale o un errore.
   InstallationApproved=3	Implica che l'operazione di download è stata completata in precedenza e che Gestione ripristini ha approvato l'installazione.
   InstallationInProgress=4	Corrisponde allo stato di esecuzione dell'attività di ripristino.
   InstallationCompleted=5	Implica che l'installazione è stata completata con un esito positivo, parziale o negativo.
   RestartRequested=6	Implica che l'installazione della patch è stata completata e che è presente un'azione di riavvio in sospeso nel nodo.
   RestartNotNeeded=7	Implica che non è stato necessario il riavvio dopo il completamento dell'installazione della patch.
   RestartCompleted=8	Implica che il riavvio è stato completato correttamente.
   OperationCompleted=9	L'operazione di Windows Update è stata completata correttamente.
   OperationAborted=10	Implica che l'operazione di Windows Update è stata interrotta.

6. Nelle versioni 1.4.0 e successive di Patch Orchestration Application, al termine di un tentativo di aggiornamento del nodo, viene pubblicato un evento con la proprietà "WUOperationStatus-[NodeName]" in NodeAgentService che notifica quando inizierà il successivo tentativo di download e installazione degli aggiornamenti di Windows. Questa opzione viene visualizzata nell'immagine seguente:

   

Log di diagnostica

Vengono raccolti i log dell'app di orchestrazione delle patch come parte dei log di runtime di Service Fabric.

È possibile acquisire i log usando lo strumento di diagnostica o la pipeline desiderata. Patch Orchestration Application usa gli ID provider fissi seguenti per registrare gli eventi tramite l’origine evento:

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

Report sull'integrità

Patch Orchestration Application pubblica anche i report sull'integrità per Node Agent Service e il servizio Coordinatore nei casi seguenti:

• Il Node Agent NTService è inattivo

  Se il Node Agent NTService è inattivo in un nodo, viene generato un report sull'integrità dei livelli di avviso per il Node Agent Service.

• Il servizio Gestione ripristini non è abilitato

  Se il servizio Gestione ripristini non viene individuato nel cluster, viene generato un report sull'integrità con livello di avviso per il servizio Coordinatore.

Domande frequenti

D. Perché il cluster viene visualizzato con uno stato di errore quando è in esecuzione Patch Orchestration Application?

R. Durante il processo di installazione, Patch Orchestration Application disabilita o riavvia i nodi, condizione che può temporaneamente influire sull’integrità di un cluster.

A seconda dei criteri dell'applicazione, un nodo può diventare inattivo durante un'operazione di applicazione di patch oppure può diventare contemporaneamente inattivo un intero dominio di aggiornamento.

Al termine dell'installazione degli aggiornamenti di Windows, i nodi vengono abilitati di nuovo dopo il riavvio.

Nell'esempio seguente il cluster è passato temporaneamente a uno stato di errore perché due nodi erano inattivi e il criterio MaxPercentageUnhealthNodes è stato violato. L'errore è temporaneo fino all’inizio dell’operazione di aggiornamento.

Se il problema persiste, fare riferimento alla sezione relativa alla risoluzione dei problemi.

D. Cosa è possibile fare se Patch Orchestration Application è in uno stato di avviso?

R. Verificare se è stato pubblicato un report sull'integrità relativo all'applicazione che indica la causa radice. L'avviso in genere contiene i dettagli del problema. Se il problema è temporaneo, il ripristino dell'applicazione è generalmente automatico.

D. Che cosa è possibile fare se il cluster non è integro ed è necessario eseguire un aggiornamento urgente del sistema operativo?

R. Patch Orchestration Application non installa gli aggiornamenti mentre il cluster non è integro. Provare a portare il cluster in uno stato integro per sbloccare il flusso di lavoro di Patch Orchestration Application.

D. Devo impostare TaskApprovalPolicy su 'NodeWise' o 'UpgradeDomainWise' per il cluster?

R. L'impostazione "UpgradeDomainWise" accelera il ripristino complessivo del cluster applicando patch in parallelo a tutti i nodi appartenenti a un dominio di aggiornamento. Durante il processo, i nodi che appartengono a un intero dominio di aggiornamento non sono disponibili (in stato Disabilitato).

Al contrario, l'impostazione "NodeWise" applica patch a un solo nodo alla volta, il che implica che l'applicazione di patch complessiva al cluster potrebbe richiedere più tempo. Tuttavia, al massimo un solo nodo può non essere disponibile (nello stato Disabilitato) durante il processo dell'applicazione di patch.

Se il cluster può essere eseguito in un numero N-1 di domini di aggiornamento durante il ciclo di applicazione di patch (dove N è il numero totale di domini di aggiornamento nel cluster), è possibile impostare il criterio su "UpgradeDomainWise". In caso contrario, impostarlo su "NodeWise".

D. Quanto tempo è necessario per applicare una patch a un nodo?

L'applicazione di patch a un nodo può richiedere da alcuni minuti (ad esempio: gli aggiornamenti delle definizioni di Windows Defender) a ore (ad esempio: gli aggiornamenti cumulativi di Windows). Il tempo necessario per applicare le patch a un nodo dipende principalmente da:

• Dimensioni degli aggiornamenti.
• Numero degli aggiornamenti da applicare in una finestra di gestione delle patch.
• Il tempo impiegato per installare gli aggiornamenti, riavviare il nodo (se richiesto) e completare i passaggi di installazione post-riavvio.
• Prestazioni della macchina virtuale o del computer e delle condizioni di rete.

D. Quanto tempo occorre per applicare patch a un intero cluster?

R. Il tempo necessario per applicare patch a un intero cluster dipende da:

• Tempo necessario per applicare le patch a un nodo.

• I criteri del Coordinator Service. Il criterio predefinito "NodeWise" implica l'applicazione di patch a un solo nodo alla volta, un approccio più lento rispetto all'uso di "UpgradeDomainWise".

  Ad esempio: se l'applicazione di patch a un nodo richiede circa 1 ora, l’applicazione di patch a un cluster di 20 nodi (con lo stesso tipo di nodi) e con 5 domini di aggiornamento, ognuno dei quali contenente 4 nodi, richiede:

  • Per "NodeWise": ~20 ore.
  • Per "UpgradeDomainWise": ~5 ore.

• Carico del cluster. Ogni operazione di applicazione di patch richiede la rilocazione del carico di lavoro dei clienti ad altri nodi disponibili nel cluster. In questo intervallo di tempo, il nodo a cui vengono applicate patch sarà nello stato Disabilitato. Se il cluster è in prossimità di picchi di carico, il processo di disabilitazione richiederà più tempo. Di conseguenza il processo complessivo dell'applicazione di patch in tali condizioni potrebbe risultare lento.

• Errori di integrità del cluster durante l'applicazione di patch. Qualsiasi riduzione dell'integrità del cluster interrompe il processo di applicazione di patch. Questo tempo si somma al tempo necessario per applicare le patch all'intero cluster.

D. Per quale motivo alcuni aggiornamenti vengono visualizzati nei risultati di Windows Update ottenuti tramite l'API REST, ma non nella cronologia di Windows Update sul computer?

R. Alcuni aggiornamenti del prodotto vengono visualizzati solo nella cronologia degli aggiornamenti o delle patch. Ad esempio, è possibile che gli aggiornamenti di Windows Defender vengano visualizzati o meno nella cronologia di Windows Update in Windows Server 2016.

D. È possibile usare Patch Orchestration Application per applicare patch al cluster di sviluppo (cluster a un nodo)?

R. No, Patch Orchestration Application non può essere usato per applicare patch a un cluster a un nodo. Questa limitazione è progettuale, perché i servizi di sistema di Service Fabric o altre app dei clienti potrebbero comportare tempi di inattività. Di conseguenza, i processi di ripristino relativi all'applicazione di patch non verranno mai approvati da Gestione ripristini.

D. Come si applicano patch ai nodi del cluster in Linux?

R. Per informazioni sull'orchestrazione degli aggiornamenti in Linux, vedere Aggiornamenti automatici delle immagini del sistema operativo del set di scalabilità di macchine virtuali di Azure.

D. Perché il ciclo di aggiornamento richiede così tanto tempo?

R. Eseguire una query sul risultato JSON, immettere il ciclo di aggiornamento per tutti i nodi e quindi provare a individuare quando tempo richiede l’installazione dell’aggiornamento in ogni nodo usando OperationStartTime e OperationTime (OperationCompletionTime).

Se non viene eseguito alcun aggiornamento in un intervallo di tempo elevato, il cluster potrebbe risultare in uno stato di errore e, di conseguenza, Gestione ripristini non può approvare alcuna attività di ripristino di Patch Orchestration Application. Se l'installazione dell'aggiornamento richiede molto tempo in qualsiasi nodo, è possibile che il nodo non sia stato aggiornato per diverso tempo. È possibile che ci siano diversi aggiornamenti in attesa che stanno causando ritardi.

È anche possibile che l'applicazione di patch ai nodi sia bloccata perché è bloccata nello stato Disabilitazione. Questo problema si verifica in genere perché la disabilitazione del nodo potrebbe causare situazioni di perdita di dati o quorum.

D: Perché il nodo deve essere disabilitato quando Patch Orchestration Application applica patch al nodo?

R. Patch Orchestration Application disabilita il nodo con una finalità Riavvio, che arresta o rialloca tutti i servizi di Service Fabric in esecuzione nel nodo. Patch Orchestration Application esegue questa operazione per assicurarsi che le applicazioni non usino una combinazione di DLL nuove e vecchie. Pertanto, è consigliabile non applicare patch a un nodo senza disabilitarlo.

D. Qual è il numero massimo di nodi che è possibile aggiornare con Patch Orchestration Application?

R. Patch Orchestration Application usa Gestione ripristini di Service Fabric per creare attività di ripristino per l’aggiornamento dei nodi. Tuttavia, non possono essere presenti più di 250 attività di riparazione contemporaneamente. Attualmente, Patch Orchestration Application crea attività di ripristino per ogni nodo contemporaneamente, quindi non può aggiornare più di 250 nodi in un cluster.

Dichiarazioni di non responsabilità

• Patch Orchestration Application accetta il Contratto di licenza con l'utente finale per Windows Update per conto dell'utente. Facoltativamente, l'impostazione può essere disattivata nella configurazione dell'applicazione.

• Patch Orchestration Application raccoglie i dati di telemetria per tenere traccia dell'utilizzo e delle prestazioni. I dati di telemetria dell'applicazione seguono l'impostazione dei dati di telemetria del runtime di Service Fabric (attiva per impostazione predefinita).

Risoluzione dei problemi

Questa sezione fornisce le possibili soluzioni per la risoluzione dei problemi relativi all'applicazione di patch ai nodi.

Un nodo non torna allo stato attivo

• È possibile che il nodo sia bloccato nello stato Disabilitazione perché:

  • Un controllo di sicurezza è in sospeso. Per risolvere questo problema, assicurarsi che siano disponibili sufficienti nodi in uno stato di integrità.

• È possibile che il nodo sia bloccato nello stato Disabilitato perché:

  • È stato disabilitato manualmente.
  • È stato disabilitato a causa di un processo di infrastruttura di Azure in corso.
  • È stato disabilitato temporaneamente da Patch Orchestration Application per consentire l’applicazione di patch al nodo.

• Il nodo potrebbe essere bloccato in uno stato inattivo perché:

  • È stato impostato manualmente in uno stato inattivo.
  • È in fase di riavvio (che potrebbe essere stato attivato da Patch Orchestration Application).
  • Include una macchina virtuale o un computer difettosi o presenta problemi di connettività di rete.

Gli aggiornamenti sono stati ignorati in alcuni nodi

Patch Orchestration Application tenta di installare un aggiornamento di Windows in base ai criteri di riprogrammazione. Il servizio tenta di recuperare il nodo e di ignorare l'aggiornamento in base ai criteri dell'applicazione.

In questo caso, viene generato un report sull'integrità dei livelli di avviso per Node Agent Service. Il risultato di Windows Update contiene anche la possibile causa dell'errore.

L'integrità del cluster passa nello stato di errore durante l'installazione dell'aggiornamento

Un aggiornamento difettoso di Windows può compromettere l'integrità di un'applicazione o di un cluster in un nodo specifico o in un dominio di aggiornamento. Patch Orchestration Application interrompe qualsiasi successiva operazione di aggiornamento di Windows fino a quando il cluster è di nuovo integro.

Un amministratore deve intervenire e stabilire perché l'applicazione o il cluster è diventato non integro a causa di Windows Update.

Note sulla versione di Patch Orchestration Application

Versione 1.1.0

• Versione pubblica

Versione 1.1.1

• Correzione di un bug in SetupEntryPoint di NodeAgentService che ha impedito l'installazione di NodeAgentNTService.

Versione 1.2.0

• Correzioni di bug nel flusso di lavoro di riavvio del sistema.
• Correzione di bug nella creazione di attività RM a causa delle quali il controllo dell'integrità durante la preparazione delle attività di ripristino non ha avuto luogo come previsto.
• La modalità di avvio per il servizio di Windows POANodeSvc è stata modificata da automatico ad automatico posticipato.

Versione 1.2.1

• Correzione di bug nel flusso di lavoro di riduzione delle prestazioni del cluster. È stata introdotta la logica di Garbage Collection per le attività di riparazione di Patch Orchestration Application relative a nodi inesistenti.

Versione 1.2.2

• Varie correzioni di bug.
• I file binari sono ora firmati.
• Aggiunta del collegamento a sfpkg per l'applicazione.

Versione 1.3.0

• L'impostazione di InstallWindowsOSOnlyUpdates su false consente di installare tutti gli aggiornamenti disponibili.
• Modifica della logica per disabilitare gli aggiornamenti automatici. Questa correzione risolve un bug che impediva la disabilitazione degli aggiornamenti automatici nei sistemi Server 2016 e versioni successive.
• Il vincolo di posizionamento per entrambi i microservizi di Patch Orchestration Application è stato parametrizzato per casi d'uso avanzati.

Versione 1.3.1

• È stata corretta la regressione per cui Patch Orchestration Application 1.3.0 non funzionava in Windows Server 2012 R2 o nelle versioni precedenti a causa di un errore durante la disabilitazione degli aggiornamenti automatici.
• Correzione di un bug per cui la configurazione di InstallWindowsOSOnlyUpdates risulta sempre true.
• Modifica del valore predefinito di InstallWindowsOSOnlyUpdates su False.

Versione 1.3.2

• È stato corretto un problema che influisce sul ciclo di vita delle patch in un nodo, se sono presenti nodi con un nome che rappresenta un subset del nome del nodo corrente. Per questi nodi, è possibile che l'applicazione di patch non sia stata eseguita o che il riavvio sia in sospeso.