Usare Patch Orchestration Application

Importante

A partire dal 30 aprile 2019, Patch Orchestration Application versione 1.2.* non è più supportato. Assicurarsi di eseguire l'aggiornamento alla versione più recente.

Patch Orchestration Application (POA) è un wrapper intorno al servizio Di ripristino di Azure Service Fabric, che consente la pianificazione delle patch del sistema operativo basata sulla configurazione per i cluster non ospitati in Azure. L'autenticazione poA non è necessaria per i cluster non ospitati in Azure, ma la pianificazione dell'installazione delle patch per dominio di aggiornamento è necessaria per applicare patch agli host del cluster di Service Fabric senza incorrere in tempi di inattività.

PoA è un'applicazione di Service Fabric che automatizza l'applicazione di patch al sistema operativo in un cluster di Service Fabric senza incorrere in tempi di inattività.

PoA 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 incorrere in tempi di inattività del cluster.

• Integrazione dell'integrità e l'applicazione di patch compatibile con il cluster. Durante l'applicazione degli aggiornamenti, l'aggiornamento poA monitora l'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 si arresta a causa del processo di applicazione di patch, l'applicazione di patch viene arrestata per evitare l'aggravamento del problema.

Dettagli interni dell'ordine di acquisto

L'ordine di acquisto è costituito 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 automatici di Windows 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.
  • La segnalazione dell'integrità segnala se un'operazione non è riuscita dopo l'esaurimento di tutti i tentativi.

Nota

PoA usa il servizio Service Fabric Repair Manager per disabilitare o abilitare il nodo ed eseguire i controlli di integrità. L'attività di ripristino creata da POA tiene traccia dello stato di avanzamento Windows Update per ogni nodo.

Prerequisiti

Nota

La versione minima richiesta di .NET Framework è la 4.6.

Abilitare il servizio Repair Manager (se non è già in esecuzione)

PoA richiede che il servizio Repair Manager sia abilitato nel cluster.

Cluster di Azure

I cluster di Azure nel livello di durabilità silver hanno il servizio Repair Manager abilitato per impostazione predefinita. I cluster di Azure nel livello di durabilità Gold potrebbero avere o meno abilitato il servizio Repair Manager, a seconda della creazione di tali cluster. I cluster di Azure nel livello di durabilità bronze, per impostazione predefinita, non hanno il servizio Repair Manager abilitato. Se il servizio è già abilitato, è possibile visualizzarlo in esecuzione nella sezione servizi di sistema in Service Fabric Explorer.

Portale di Azure

È possibile abilitare Repair Manager dal portale di Azure durante la configurazione del cluster. Quando si configura il cluster, selezionare l'opzione Includi Repair Manager in Funzionalità del componente aggiuntivo.

Modello di distribuzione di Azure Resource Manager

In alternativa, è possibile usare il modello di distribuzione di Azure Resource Manager per abilitare il servizio Repair Manager in cluster di Service Fabric nuovi ed esistenti. 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 Repair Manager usando il modello di 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 . In caso contrario, è necessario eseguire l'aggiornamento apiVersion alla versione 2017-07-01-preview o successiva:

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

2. Abilitare il servizio Repair Manager aggiungendo la sezione seguente addonFeatures dopo la fabricSettings sezione :

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

3. Dopo aver aggiornato il modello di cluster con queste modifiche, applicarli e lasciare che l'aggiornamento venga completato. È ora possibile visualizzare il servizio Repair Manager in esecuzione nel cluster. Viene chiamato fabric:/System/RepairManagerService nella sezione dei servizi di sistema in Service Fabric Explorer.

Cluster locali autonomi

Per abilitare il servizio Repair Manager in un cluster di Service Fabric nuovo o esistente, è possibile usare le impostazioni di configurazione per il cluster Windows autonomo.

Per abilitare il servizio Repair Manager:

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

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

2. Abilitare il servizio Repair Manager aggiungendo la sezione seguente addonFeatures dopo la fabricSettings sezione , come illustrato di seguito:

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

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

   Dopo aver eseguito il cluster con un manifesto del cluster aggiornato, è possibile visualizzare il servizio Repair Manager in esecuzione nel cluster. Si chiama fabric:/System/RepairManagerService ed è presente nella sezione dei servizi di sistema in Service Fabric Explorer.

Configurare gli aggiornamenti di Windows per tutti i nodi

Gli aggiornamenti automatici di Windows possono causare una perdita di disponibilità, perché più nodi del cluster possono essere riavviati contemporaneamente. PoA, per impostazione predefinita, tenta di disabilitare gli aggiornamenti automatici di Windows in ogni nodo del cluster. Tuttavia, se le impostazioni sono gestite da un amministratore o da un Criteri di gruppo, è consigliabile impostare il criterio di Windows Update su "Notifica prima del download" in modo esplicito.

Scaricare il pacchetto dell'applicazione

Per scaricare il pacchetto dell'applicazione, passare alla pagina Patch Orchestration Application release (Versione dell'applicazione patch orchestrazione ) in GitHub.

Configurare il comportamento poA

È possibile configurare il comportamento poA per soddisfare le proprie esigenze. Eseguire l'override dei valori predefiniti passando il parametro dell'applicazione durante la creazione o l'aggiornamento dell'applicazione. È possibile specificare i parametri dell'applicazione specificando ApplicationParameter i Start-ServiceFabricApplicationUpgrade cmdlet o New-ServiceFabricApplication .

Parametro	Tipo	Dettagli
MaxResultsToCache	long	Numero massimo di Windows Update risultati che devono essere memorizzati nella cache. Il valore predefinito è 3000, presupponendo che:   - Il numero di nodi è 20.   - Il numero di aggiornamenti a un nodo al mese è 5.   - Il numero di risultati per operazione può essere 10.   - I risultati degli ultimi tre mesi devono essere archiviati.
TaskApprovalPolicy	Enumerazione {NodeWise, UpgradeDomainWise}	TaskApprovalPolicy indica i criteri che devono essere usati dal Coordinator Service per installare gli aggiornamenti di Windows Update nei nodi del cluster di Service Fabric. Di seguito sono elencati i valori consentiti: NodeWise: gli aggiornamenti di Windows vengono installati un nodo alla volta. UpgradeDomainWise: gli aggiornamenti di Windows vengono installati un dominio di aggiornamento alla volta. Al massimo, tutti i nodi appartenenti a un dominio di aggiornamento possono essere utilizzati per un aggiornamento di Windows. Per decidere quali criteri sono più adatti per il cluster, vedere la sezione Domande frequenti .
LogsDiskQuotaInMB	long (Impostazione predefinita: 1024)	Dimensioni massime dei log delle app di orchestrazione patch in MB, che possono essere mantenute localmente nei nodi.
WUQuery	string (Impostazione predefinita: IsInstalled=0)	Eseguire una query per ottenere gli aggiornamenti di Windows. Per altre informazioni, vedere WuQuery.
InstallWindowsOSOnlyUpdates	Boolean (impostazione predefinita: false)	Usare questo flag per controllare quali aggiornamenti devono essere scaricati e installati. Sono consentiti i valori seguenti: true: installa solo gli aggiornamenti del sistema operativo Windows. false: installa tutti gli aggiornamenti disponibili nel computer.
WUOperationTimeOutInMinutes	Int (Impostazione predefinita: 90)	Specifica il timeout per qualsiasi operazione di Windows Update (ricerca, download o installazione). L'operazione viene interrotta se non viene completata entro il timeout specificato.
WURescheduleCount	Int (Impostazione predefinita: 5)	Numero massimo di volte in cui il servizio riprogramma l'aggiornamento di Windows se un'operazione ha esito negativo in modo permanente.
WURescheduleTimeInMinutes	Int (Impostazione predefinita: 30)	Intervallo in cui il servizio riprogramma gli aggiornamenti di Windows se l'errore persiste.
WUFrequency	Stringa delimitata da virgole (impostazione predefinita: settimanale, mercoledì, 7:00:00)	Frequenza per l'installazione degli aggiornamenti di Windows. Il formato e i valori possibili sono: - Mensile, DD, HH:MM:SS (esempio: mensile, 5, 12:22:32). I valori consentiti per il campo DD (giorno) sono numeri compresi tra 1 e 28 e ultimo. - Settimanale, Giorno, HH:MM:SS (esempio: Settimanale, Martedì, 12:22:32) - Giornaliero, HH:MM:SS (esempio: Daily, 12:22:32) - MonthlyByWeekAndDay, Week, Day, HH:MM:SS (esempio: MonthlyByWeekAndDay, 2, Venerdì, 21 :00:00 indica 9:00 UTC il venerdì della seconda settimana di ogni mese) - Nessuno indica che gli aggiornamenti di Windows non devono essere eseguiti. I tempi sono in formato UTC.
AcceptWindowsUpdateEula	Boolean (Impostazione predefinita: true)	Impostando questo flag, l'applicazione accetta il contratto di licenza dell'utente finale per Windows Update per conto del proprietario della macchina.

Suggerimento

Se si desidera che gli aggiornamenti di Windows vengano eseguiti immediatamente, impostare WUFrequency in relazione all'ora di distribuzione dell'applicazione. Ad esempio, si supponga di disporre di un cluster di test a cinque nodi e si prevede di distribuire l'app all'incirca alle 17:00:00 UTC. Se si presuppone che l'aggiornamento o la distribuzione dell'applicazione richiede almeno 30 minuti, impostare WUFrequency come Daily, 17:30:00.

Distribuire l'oggetto POA

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

2. Distribuire poA come qualsiasi altra app di Service Fabric. Per distribuirlo usando 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.

Nota

Mantenere lo script e la cartella dell'applicazione PatchOrchestrationApplication nella stessa directory.

Aggiornare il poA

Per aggiornare la versione poA usando PowerShell, seguire le istruzioni riportate nell'aggiornamento dell'applicazione Service Fabric usando PowerShell.

Rimuovere l'oggetto POA

Per rimuovere l'applicazione, seguire le istruzioni riportate in Distribuire e rimuovere applicazioni con PowerShell.

Per comodità, abbiamo fornito lo script di 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.

Nota

Mantenere lo script e la cartella dell'applicazione PatchOrchestrationApplication nella stessa directory.

Visualizzare i risultati di Windows Update

POA espone le API REST per visualizzare i risultati cronologici agli utenti. Ecco un esempio del codice JSON dei risultati:

[
  {
    "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:

Campo	Valori	Dettagli
OperationResult	0 - Completata 1 - Completata con errori 2 - Non riuscita 3 - Interrotta 4 - Interrotta con timeout	Indica il risultato dell'operazione complessiva, che prevede normalmente l'installazione di uno o più aggiornamenti.
ResultCode	Stesso di OperationResult	Questo campo indica il risultato dell'operazione di installazione per un singolo aggiornamento.
Tipo operazione	1 - Installazione 0 - Ricerca e download	Per impostazione predefinita, l'installazione è l'unico OperationType visualizzato nei risultati.
WindowsUpdateQuery	Impostazione predefinita: "IsInstalled = 0"	Query Windows Update usata per cercare gli aggiornamenti. Per altre informazioni, vedere WuQuery.
RebootRequired	true: il riavvio è necessario false: il riavvio non è necessario	Indica se è stato necessario un riavvio per completare l'installazione degli aggiornamenti.
OperationStartTime	Datetime	Indica l'ora di avvio dell'operazione (download/installazione).
OperationTime	Datetime	Indica l'ora in cui è stata completata l'operazione (download/installazione).
HResult	0 - Operazione riuscita other : errore	Indica il motivo dell'errore di Windows Update con updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

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

Accedere al cluster per eseguire query Windows Update risultati. Individuare l'indirizzo IP di replica per l'indirizzo primario del Servizio Coordinatore e aprire l'URL seguente 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, è anche possibile accedere all'URL dall'esterno del cluster.

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

Per abilitare il proxy inverso nel cluster, seguire le istruzioni in Proxy inverso in Azure Service Fabric.

Avviso

Dopo aver configurato il proxy inverso, tutti i microservizi nel cluster che espongono un endpoint HTTP sono indirizzabili dall'esterno del cluster.

Diagnostica ed eventi di integrità

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

Nota

Per ottenere molti dei miglioramenti di diagnostica automatica indicati di seguito, è necessario che sia installata la versione POA 1.4.0 o successiva.

L'agente node NTService crea attività di ripristino per l'installazione degli aggiornamenti nei nodi. Ogni attività viene quindi preparata dal Coordinator Service in base ai criteri di approvazione delle attività. Infine, le attività preparate vengono approvate da Repair Manager, che non approva alcuna attività se il cluster si trova in uno stato non integro.

Per comprendere in che modo gli aggiornamenti proseguono in un nodo, è possibile procedere passo dopo passo:

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 aver scaricato gli aggiornamenti, l'agente node NTService crea un'attività di ripristino corrispondente per il nodo con il nome POS___<unique_id>. È possibile visualizzare queste attività di ripristino usando il cmdlet Get-ServiceFabricRepairTask o SFX nella sezione dei dettagli del nodo. Dopo aver creato l'attività di ripristino, passa rapidamente allo stato Attestazione.

3. Il Coordinator Service cerca periodicamente le attività di ripristino nello stato Richiesto e quindi le aggiorna allo stato Preparazione dello stato in base ad TaskApprovalPolicy. Se TaskApprovalPolicy è configurato come NodeWise, un'attività di ripristino corrispondente a un nodo viene preparata solo se nessun'altra attività di ripristino è attualmente in Fase di preparazione, approvazione, esecuzione o ripristino .

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

   Le versioni POA 1.4.0 e successive pubblicano eventi con la proprietà ClusterPatchingStatus in CoordinatorService per visualizzare i nodi a cui vengono applicate le patch. Gli aggiornamenti vengono installati in _poanode_0, come illustrato nell'immagine seguente:

   

4. Dopo aver disabilitato il nodo, l'attività di ripristino viene spostata in Stato di esecuzione .

   Nota

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

5. Quando l'attività di ripristino è in stato In esecuzione , viene avviata l'installazione della patch in tale nodo. Dopo aver installato la patch, il nodo potrebbe essere riavviato o meno, a seconda della patch. Successivamente, l'attività di ripristino viene spostata in Stato di ripristino, che consente di riabilitare il nodo. L'attività di ripristino viene quindi contrassegnata come completata.

   Nelle versioni POA 1.4.0 e successive è 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 l'attività "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" è in stato DownloadComplete . Significa che gli aggiornamenti sono stati scaricati nel nodo poanode_2 e l'installazione verrà tentata quando l'attività passa allo stato 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 si verificano altri problemi, accedere alla macchina virtuale (VM) o alle macchine virtuali e ottenere informazioni su di essi usando i registri eventi di Windows. L'attività di ripristino menzionata in precedenza può esistere solo nelle seguenti sottostate dell'executor:

   ExecutorSubState	Descrizione
   Nessuno=1	Implica che non è stata eseguita un'operazione in corso nel nodo. Lo stato potrebbe essere in transizione.
   DownloadCompleted=2	Implica che l'operazione di download è stata completata con esito positivo, errore parziale o errore.
   InstallationApproved=3	Implica che l'operazione di download è stata completata in precedenza e Repair Manager ha approvato l'installazione.
   InstallationInProgress=4	Corrisponde allo stato di esecuzione dell'attività di ripristino.
   InstallationCompleted=5	Implica che l'installazione è stata completata con esito positivo, esito positivo parziale o negativo.
   RestartRequested=6	Implica che l'installazione della patch è stata completata ed è presente un'azione di riavvio in sospeso nel nodo.
   RestartNotNeeded=7	Implica che il riavvio non era necessario 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. In POA versioni 1.4.0 e successive, al termine di un tentativo di aggiornamento del nodo, viene pubblicato un evento con la proprietà "WUOperationStatus-[NodeName]" in NodeAgentService per notificare quando inizierà il successivo tentativo di download e installazione degli aggiornamenti di Windows. Questa opzione viene visualizzata nell'immagine seguente:

   

Log di diagnostica

I log delle applicazioni di orchestrazione delle patch vengono raccolti come parte dei log di runtime di Service Fabric.

È possibile acquisire i log usando lo strumento di diagnostica o la pipeline di propria scelta. PoA 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à

PoA pubblica anche i report sull'integrità sul servizio agente del nodo o sul servizio Coordinatore negli scenari 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 Repair Manager non è abilitato

  Se il servizio Repair Manager non viene trovato nel cluster, viene generato un report di integrità a livello di avviso per il Servizio coordinatore.

Domande frequenti

D: Perché viene visualizzato il cluster in uno stato di errore quando è in esecuzione un poA?

R: Durante il processo di installazione, poA disabilita o riavvia i nodi, che possono causare temporaneamente un cluster non integro.

A seconda dei criteri dell'applicazione, un nodo può andare inattivo durante un'operazione di applicazione di patch o un intero dominio di aggiornamento può essere disattivato contemporaneamente.

Al termine dell'installazione degli aggiornamenti di Windows, i nodi vengono riabilitabili 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 applicazione di patch.

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

D: Cosa è possibile fare se poA è in uno stato di avviso?

R: Verificare se un report sull'integrità pubblicato sull'applicazione indica la causa radice. L'avviso in genere contiene i dettagli del problema. Se il problema è temporaneo, l'applicazione dovrebbe essere ripristinata automaticamente.

D: Cosa è possibile fare se il cluster non è integro ed è necessario eseguire un aggiornamento urgente del sistema operativo?

R: POA non installa gli aggiornamenti mentre il cluster non è integro. Provare a portare il cluster a uno stato integro per sbloccare il flusso di lavoro POA.

D: È necessario impostare TaskApprovalPolicy come "NodeWise" o "UpgradeDomainWise" per il cluster?

R: L'impostazione "UpgradeDomainWise" accelera il ripristino complessivo del cluster eseguendo l'applicazione di 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 del cluster complessivo potrebbe richiedere più tempo. Tuttavia, durante il processo di applicazione di patch, solo un nodo al massimo non sarà disponibile (in stato Disabilitato ).

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

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

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

• Dimensioni degli aggiornamenti.
• Numero di aggiornamenti che devono essere applicati in una finestra di applicazione di patch.
• Il tempo necessario per installare gli aggiornamenti, riavviare il nodo (se necessario) e completare i passaggi di installazione dopo il riavvio.
• Prestazioni della macchina virtuale o del computer e delle condizioni di rete.

D: Quanto tempo è necessario per applicare patch a un intero cluster?

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

• Tempo necessario per applicare patch a un nodo.

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

  Ad esempio: se per applicare patch a un nodo sono necessarie circa 1 ora, è necessario applicare patch a un cluster di 20 nodi (stesso tipo di nodi) con 5 domini di aggiornamento, ognuno contenente 4 nodi:

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

• Caricamento del cluster. Ogni operazione di applicazione di patch richiede lo spostamento del carico di lavoro del cliente in altri nodi disponibili nel cluster. Un nodo a cui viene applicata l'applicazione di patch è in stato Disabilitazione durante questo periodo. Se il cluster è in esecuzione vicino al picco di carico, il processo di disabilitazione richiederebbe più tempo. Pertanto, il processo complessivo di applicazione di patch potrebbe sembrare lento in tali condizioni stressate.

• Errori di integrità del cluster durante l'applicazione di patch. Qualsiasi riduzionedell'integrità del cluster interrompe il processo di applicazione di patch. Questo problema verrebbe aggiunto al tempo complessivo necessario per applicare patch all'intero cluster.

D: Perché vengono visualizzati alcuni aggiornamenti nei risultati Windows Update ottenuti tramite l'API REST, ma non nella cronologia Windows Update nel computer?

R: Alcuni aggiornamenti del prodotto vengono visualizzati solo nella cronologia degli aggiornamenti o delle patch. Ad esempio, Windows Defender gli aggiornamenti potrebbero o non essere visualizzati nella cronologia di Windows Update in Windows Server 2016.

D: È possibile usare POA per applicare patch al cluster di sviluppo (cluster a un nodo)?

R: No, l'applicazione poA non può essere usata per applicare patch a un cluster a un nodo. Questa limitazione è per impostazione predefinita, perché i servizi di sistema di Service Fabric o altre app dei clienti potrebbero comportare tempi di inattività. Pertanto, l'applicazione di patch ai processi di riparazione non verrebbe mai approvata da Repair Manager.

D: Ricerca per categorie applicare 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 per il risultato JSON, immettere il ciclo di aggiornamento per tutti i nodi e quindi provare a individuare il tempo impiegato dall'installazione dell'aggiornamento in ogni nodo usando OperationStartTime e OperationTime (OperationCompletionTime).

Se si verifica un intervallo di tempo elevato in cui non viene eseguito alcun aggiornamento, il cluster potrebbe trovarsi in uno stato di errore e, di conseguenza, Repair Manager non può approvare alcuna attività di ripristino poA. Se l'installazione dell'aggiornamento richiede molto tempo in qualsiasi nodo, il nodo potrebbe non essere stato aggiornato in un periodo di tempo. Un sacco di aggiornamenti potrebbero essere in attesa di installazione, il che può causare ritardi.

Potrebbe anche essere possibile che l'applicazione di patch ai nodi sia bloccata perché è bloccata nello stato Disabilitazione . Ciò 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 viene applicata l'applicazione di patch al nodo?

R: POA disabilita il nodo con una finalità Di riavvio , che arresta o rialloca tutti i servizi di Service Fabric in esecuzione nel nodo. PoA esegue questa operazione per assicurarsi che le applicazioni non usino una combinazione di DLL nuove e precedenti, quindi è consigliabile non applicare patch a un nodo senza disabilitarlo.

D: Qual è il numero massimo di nodi che è possibile aggiornare tramite poA?

R: POA usa Service Fabric Repair Manager per creare attività di ripristino per i nodi per gli aggiornamenti. Tuttavia, non più di 250 attività di riparazione possono essere presenti contemporaneamente. Attualmente, poa crea attività di ripristino per ogni nodo contemporaneamente, quindi POA può aggiornare non più di 250 nodi in un cluster.

Dichiarazioni di non responsabilità

• POA accetta il contratto di licenza End-User per Windows Update per conto dell'utente. Facoltativamente, l'impostazione può essere disattivata nella configurazione dell'applicazione.

• PoA 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

In questa sezione vengono fornite le possibili soluzioni per la risoluzione dei problemi relativi all'applicazione di patch ai nodi.

Un nodo non torna allo stato attivo

• Il nodo potrebbe essere 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à.

• Il nodo potrebbe essere bloccato in stato Disabilitato perché:

  • È stato disabilitato manualmente.
  • È stato disabilitato a causa di un processo di infrastruttura di Azure in corso.
  • È stato disabilitato temporaneamente da POA per applicare patch al nodo.

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

  • È stato inserito manualmente in uno stato inattivo.
  • È in fase di riavvio (che potrebbe essere attivato da POA).
  • Ha una macchina virtuale o un computer difettoso o presenta problemi di connettività di rete.

Gli aggiornamenti sono stati ignorati in alcuni nodi

PoA 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 Windows Update contiene anche il possibile motivo dell'errore.

L'integrità del cluster va in errore durante l'installazione dell'aggiornamento

Un aggiornamento di Windows difettoso può causare l'integrità di un'applicazione o di un cluster in un determinato nodo o dominio di aggiornamento. PoA interrompe tutte le operazioni di Windows Update successive fino a quando il cluster non è di nuovo integro.

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

Note sulla versione poA

Nota

Per le versioni POA 1.4.0 e successive, è possibile trovare le note sulla versione e le versioni nella pagina Patch Orchestration Application release (Versione dell'applicazione patch orchestrazione ) in GitHub.

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.
• Modificata la modalità di avvio per il servizio Windows POANodeSvc da auto a auto ritardata.

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.
• Vincolo di posizionamento con parametri per entrambi i microservizi di POA per i casi d'uso avanzati.

Versione 1.3.1

• Correzione della regressione in cui POA 1.3.0 non funzionerà in Windows Server 2012 R2 o versioni precedenti a causa di un errore nella 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

• Correzione di un problema che influisce sul ciclo di vita dell'applicazione di 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.