Dela via

Använda patchorkestreringsprogram

  • Artikel

Viktigt!

Från och med den 30 april 2019 stöds inte längre Patch Orchestration Application version 1.2.*. Se till att uppgradera till den senaste versionen.

Patch Orchestration Application (POA) är en omslutning runt Azure Service Fabric Repair Manager-tjänsten, som möjliggör konfigurationsbaserad schemaläggning av os-korrigeringar för icke-Azure-värdbaserade kluster. POA krävs inte för icke-Azure-värdbaserade kluster, men schemaläggning av korrigeringsinstallation efter uppdateringsdomän krävs för att korrigera Service Fabric-klustervärdar utan att orsaka driftstopp.

POA är ett Service Fabric-program som automatiserar operativsystemets korrigering på ett Service Fabric-kluster utan att orsaka driftstopp.

POA innehåller följande funktioner:

  • Automatisk installation av operativsystemuppdatering. Uppdateringar av operativsystemet laddas ned och installeras automatiskt. Klusternoder startas om efter behov utan att orsaka klusteravbrott.

  • Klustermedveten korrigering och hälsointegrering. När POA tillämpar uppdateringar övervakar det hälsotillståndet för klusternoderna. Klusternoder uppdateras en nod i taget eller en uppdateringsdomän i taget. Om hälsotillståndet för klustret går ned på grund av korrigeringsprocessen stoppas korrigeringen för att förhindra att problemet förvärras.

Intern information om POA

POA består av följande underkomponenter:

  • Koordinatortjänst: Den här tillståndskänsliga tjänsten ansvarar för:

    • Samordna Windows Update-jobbet i hela klustret.
    • Lagra resultatet av slutförda Windows Update-åtgärder.

  • Node Agent Service: Den här tillståndslösa tjänsten körs på alla Service Fabric-klusternoder. Tjänsten ansvarar för:

    • Startar nodagentens NTService.
    • Övervaka Node Agent NTService.

  • Node Agent NTService: Den här Windows NT-tjänsten körs med en högre behörighet (SYSTEM). Nodagenttjänsten och koordinatortjänsten körs däremot med lägre behörighet (NETWORK SERVICE). Tjänsten ansvarar för att utföra följande Windows Update-jobb på alla klusternoder:

    • Inaktivera automatiska Windows-uppdateringar på noden.
    • Ladda ned och installera Windows-uppdateringar enligt principen som användaren har angett.
    • Starta om installationen av datorn efter Windows-uppdateringar.
    • Ladda upp resultatet av Windows-uppdateringar till koordinatortjänsten.
    • Rapportera hälsorapporter om en åtgärd har misslyckats när den har tömt alla återförsök.

Kommentar

POA använder Service Fabric Repair Manager-tjänsten för att inaktivera eller aktivera noden och utföra hälsokontroller. Reparationsaktiviteten som skapas av POA spårar Windows Update-förloppet för varje nod.

Förutsättningar

Kommentar

Den lägsta .NET Framework-version som krävs är 4.6.

Aktivera Repair Manager-tjänsten (om den inte redan körs)

POA kräver att Repair Manager-tjänsten är aktiverad i klustret.

Azure-kluster

Azure-kluster på silverhållbarhetsnivån har Repair Manager-tjänsten aktiverad som standard. Azure-kluster på den guldfärgade hållbarhetsnivån kanske eller kanske inte har Repair Manager-tjänsten aktiverad, beroende på när dessa kluster skapades. Azure-kluster på bronshållbarhetsnivån har som standard inte Repair Manager-tjänsten aktiverad. Om tjänsten redan är aktiverad kan du se att den körs i avsnittet systemtjänster i Service Fabric Explorer.

Azure-portalen

Du kan aktivera Repair Manager från Azure-portalen när du konfigurerar klustret. När du konfigurerar klustret väljer du alternativet Inkludera Reparationshanteraren under Tilläggsfunktioner.

Bild av hur du aktiverar Repair Manager från Azure-portalen

Azure Resource Manager-distributionsmodellen

Du kan också använda Azure Resource Manager-distributionsmodellen för att aktivera Repair Manager-tjänsten på nya och befintliga Service Fabric-kluster. Hämta mallen för klustret som du vill distribuera. Du kan antingen använda exempelmallarna eller skapa en anpassad Mall för Azure Resource Manager-distributionsmodell.

Om du vill aktivera Repair Manager-tjänsten med hjälp av mallen för Azure Resource Manager-distributionsmodellen gör du följande:

  1. Kontrollera att apiVersion är inställt på 2017-07-01-preview för resursen Microsoft.ServiceFabric/clusters . Om det är annorlunda måste du uppdatera apiVersion till 2017-07-01-preview eller senare:

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

  2. Aktivera Repair Manager-tjänsten genom att lägga till följande addonFeatures avsnitt efter avsnittet fabricSettings :

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

  3. När du har uppdaterat klustermallen med dessa ändringar använder du dem och låter uppdateringen slutföras. Nu kan du se reparationshanterarens tjänst som körs i klustret. Den kallas fabric:/System/RepairManagerService i avsnittet systemtjänster i Service Fabric Explorer.

Fristående lokala kluster

Om du vill aktivera Repair Manager-tjänsten i ett nytt eller befintligt Service Fabric-kluster kan du använda konfigurationsinställningarna för fristående Windows-kluster.

Så här aktiverar du Repair Manager-tjänsten:

  1. Kontrollera att apiVersion i Allmänna klusterkonfigurationer är inställt på 04–2017 eller senare, som du ser här:

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

  2. Aktivera Repair Manager-tjänsten genom att lägga till följande addonFeatures avsnitt efter fabricSettings avsnittet, som du ser här:

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

  3. Uppdatera klustermanifestet med dessa ändringar med hjälp av det uppdaterade klustermanifestet , skapa ett nytt kluster eller uppgradera klusterkonfigurationen.

    När klustret körs med ett uppdaterat klustermanifest kan du se repair manager-tjänsten som körs i klustret. Den kallas fabric:/System/RepairManagerService och finns i avsnittet systemtjänster i Service Fabric Explorer.

Konfigurera Windows-uppdateringar för alla noder

Automatiska Windows-uppdateringar kan leda till tillgänglighetsförlust eftersom flera klusternoder kan startas om samtidigt. POA försöker som standard inaktivera de automatiska Windows-uppdateringarna på varje klusternod. Men om inställningarna hanteras av en administratör eller en grupprincip rekommenderar vi att du uttryckligen anger Windows Update-principen till "Meddela före nedladdning".

Ladda ned programpaketet

Om du vill ladda ned programpaketet går du till versionssidan för Patch Orchestration-programmet på GitHub.

Konfigurera POA-beteende

Du kan konfigurera POA-beteende för att uppfylla dina behov. Åsidosätt standardvärdena genom att skicka in programparametern när du skapar eller uppdaterar programmet. Du kan ange programparametrar genom att ange ApplicationParameter till Start-ServiceFabricApplicationUpgrade cmdletarna eller New-ServiceFabricApplication .

Parameter Type Details
MaxResultsToCache Long Det maximala antalet Windows Update-resultat som ska cachelagras.

Standardvärdet är 3 000, förutsatt att:
  – Antalet noder är 20.
  – Antalet uppdateringar av en nod per månad är 5.
  – Antalet resultat per åtgärd kan vara 10.
  - Resultaten för de senaste tre månaderna bör lagras.
TaskApprovalPolicy Räkna upp
{ NodeWise, UpgradeDomainWise }		 TaskApprovalPolicy anger den princip som ska användas av koordinatortjänsten för att installera Windows-uppdateringar över Service Fabric-klusternoderna.

De tillåtna värdena är:
NodeWise: Windows-uppdateringar installeras en nod i taget.
UpgradeDomainWise: Windows-uppdateringar installeras en uppdateringsdomän i taget. (Som mest kan alla noder som tillhör en uppdateringsdomän gå till en Windows-uppdatering.)

Information om vilken princip som passar bäst för klustret finns i avsnittet Vanliga frågor och svar .
LogsDiskQuotaInMB Lång
(Standard: 1024)		 Den maximala storleken på loggarna för korrigeringsorkestreringsappen i MB, som kan sparas lokalt på noder.
WUQuery sträng
(Standard: IsInstalled=0)		 Fråga för att hämta Windows-uppdateringar. Mer information finns i WuQuery.
InstalleraWindowsOSOnlyUpdates Boolesk
(standard: false)		 Använd den här flaggan för att styra vilka uppdateringar som ska laddas ned och installeras. Följande värden tillåts
true – Installerar endast Uppdateringar av Windows-operativsystemet.
false – Installerar alla tillgängliga uppdateringar på datorn.
WUOperationTimeOutInMinutes Int
(Standard: 90)		 Anger tidsgränsen för alla Windows Update-åtgärder (sök eller ladda ned eller installera). Om åtgärden inte har slutförts inom den angivna tidsgränsen avbryts den.
WURescheduleCount Int
(Standard: 5)		 Det maximala antalet gånger tjänsten schemaläggs om Windows-uppdateringen om en åtgärd misslyckas beständigt.
WURescheduleTimeInMinutes Int
(Standard: 30)		 Intervallet då tjänsten schemaläggs om Windows-uppdateringarna om felet kvarstår.
WUFrequency Kommaavgränsad sträng (standard: Varje vecka, onsdag, 7:00:00) Frekvensen för att installera Windows-uppdateringar. Formatet och möjliga värden är:
– Månatlig, DD, HH:MM:SS (exempel: Varje månad, 5, 12:22:32). Tillåtna värden för fält-DD (dag) är tal från 1 till 28 och sista.
- Varje vecka, Dag, HH:MM:SS (exempel: Varje vecka, tisdag, 12:22:32)
- Dagligen, HH:MM:SS (exempel: Dagligen, 12:22:32)
- MonthlyByWeekAndDay, Week, Day, HH:MM:SS (exempel: MonthlyByWeekAndDay, 2, Fredag, 21:00:00 anger 21:00 UTC-tid på fredag den 2:a veckan i varje månad)
- Ingen anger att Windows-uppdateringar inte ska göras.

Tiderna finns i UTC.
AccepteraWindowsUpdateEula Boolesk
(Standard: sant)		 Genom att ange den här flaggan godkänner programmet licensavtalet för slutanvändare för Windows Update för datorns ägares räkning.

Dricks

Om du vill att Windows-uppdateringar ska ske omedelbart anger du WUFrequency i förhållande till programdistributionstiden. Anta till exempel att du har ett testkluster med fem noder och planerar att distribuera appen runt 17:00 UTC. Om du antar att programuppgraderingen eller distributionen tar högst 30 minuter anger du WUFrequency som Daily, 17:30:00.

Distribuera POA

  1. Slutför alla nödvändiga steg för att förbereda klustret.

  2. Distribuera POA som alla andra Service Fabric-appar. Information om hur du distribuerar det med hjälp av PowerShell finns i Distribuera och ta bort program med Hjälp av PowerShell.

  3. Om du vill konfigurera programmet vid tidpunkten för distributionen ApplicationParameter skickar du till cmdleten New-ServiceFabricApplication . För din bekvämlighet har vi tillhandahållit skriptet Deploy.ps1 tillsammans med programmet. Så här använder du skriptet:

    • Anslut till ett Service Fabric-kluster med hjälp Connect-ServiceFabricClusterav .
    • Kör PowerShell-skriptet Deploy.ps1 med lämpligt ApplicationParameter värde.

Kommentar

Behåll skriptet och programmappen PatchOrchestrationApplication i samma katalog.

Uppgradera POA

Om du vill uppgradera DIN POA-version med hjälp av PowerShell följer du anvisningarna i Service Fabric-programuppgradering med hjälp av PowerShell.

Ta bort POA

Om du vill ta bort programmet följer du anvisningarna i Distribuera och ta bort program med PowerShell.

För din bekvämlighet har vi angett Skriptet Undeploy.ps1 tillsammans med programmet. Så här använder du skriptet:

  • Anslut till ett Service Fabric-kluster med hjälp Connect-ServiceFabricClusterav .
  • Kör PowerShell-skriptet Undeploy.ps1.

Kommentar

Behåll skriptet och programmappen PatchOrchestrationApplication i samma katalog.

Visa Windows Update-resultaten

POA exponerar REST-API:er för att visa historiska resultat för användare. Här är ett exempel på JSON-resultatet:

[
  {
    "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
      }
    ]
  },
  ...
]

JSON-fälten beskrivs i följande tabell:

Fält Värden Details
OperationResult 0 – Lyckades
1 – Lyckades med fel
2 – Det gick inte
3 – Avbröts
4 – Avbröts med timeout		 Anger resultatet av den övergripande åtgärden, som vanligtvis omfattar installation av en eller flera uppdateringar.
ResultCode Samma som OperationResult Det här fältet anger resultatet av installationsåtgärden för en enskild uppdatering.
OperationType 1 – Installation
0 – Sök och ladda ned		 Som standard är Installation den enda OperationType som visas i resultatet.
WindowsUpdateQuery Standardvärdet är "IsInstalled=0" Windows Update-frågan som användes för att söka efter uppdateringar. Mer information finns i WuQuery.
RebootRequired sant – omstart krävdes
false – omstart krävdes inte		 Anger om en omstart krävdes för att slutföra installationen av uppdateringar.
OperationStartTime Datum/tid Anger den tidpunkt då åtgärden (Download/Installation) startades.
OperationTime Datum/tid Anger den tidpunkt då åtgärden (nedladdning/installation) slutfördes.
HResult 0 – Lyckades
other – fel		 Anger orsaken till felet för Windows-uppdateringen med updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

Om ingen uppdatering har schemalagts ännu är JSON-resultatet tomt.

Logga in på klustret för att köra frågor mot Windows Update-resultat. Ta reda på replikens IP-adress för den primära adressen för koordinatortjänsten och öppna följande URL från webbläsaren: http://< REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

REST-slutpunkten för koordinatortjänsten har en dynamisk port. Information om hur du kontrollerar den exakta URL:en finns i Service Fabric Explorer. Resultaten är till exempel tillgängliga på http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Bild av REST-slutpunkten

Om den omvända proxyn är aktiverad i klustret kan du också komma åt URL:en utanför klustret.

Slutpunkten som du behöver träffa är http://< SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

Om du vill aktivera omvänd proxy i klustret följer du anvisningarna i Omvänd proxy i Azure Service Fabric.

Varning

När den omvända proxyn har konfigurerats kan alla mikrotjänster i klustret som exponerar en HTTP-slutpunkt adresseras utanför klustret.

Diagnostik- och hälsohändelser

I det här avsnittet beskrivs hur du felsöker eller diagnostiserar problem med korrigeringsuppdateringar via POA i Service Fabric-kluster.

Kommentar

För att få många av följande utkallade självdiagnostikförbättringar bör du ha POA version 1.4.0 eller senare installerat.

Node Agent NTService skapar reparationsuppgifter för att installera uppdateringar på noderna. Varje uppgift förbereds sedan av koordinatortjänsten enligt principen för uppgiftsgodkännande. Slutligen godkänns de förberedda uppgifterna av Repair Manager, som inte godkänner någon uppgift om klustret är i ett feltillstånd.

För att hjälpa dig att förstå hur uppdateringarna fortsätter på en nod går vi steg för steg:

  1. NodeAgentNTService, som körs på varje nod, söker efter tillgängliga Windows-uppdateringar vid den schemalagda tiden. Om uppdateringar är tillgängliga laddas de ned på noden.

  2. När uppdateringarna har laddats ned skapar Node Agent NTService en motsvarande reparationsuppgift för noden med namnet POS___<unique_id>. Du kan visa dessa reparationsuppgifter med hjälp av cmdleten Get-ServiceFabricRepairTask eller med hjälp av SFX i avsnittet med nodinformation. När reparationsuppgiften har skapats flyttas den snabbt till tillståndet Fordrat.

  3. Koordinatortjänsten söker regelbundet efter reparationsuppgifter i anspråkstillstånd och uppdaterar dem sedan till Förberedelsetillstånd baserat på TaskApprovalPolicy. Om TaskApprovalPolicy har konfigurerats till NodeWise förbereds endast en reparationsuppgift som motsvarar en nod om ingen annan reparationsuppgift för närvarande är i tillståndet Förbered, Godkänd, Kör eller Återställa.

    När det gäller UpgradeWise TaskApprovalPolicy finns det på samma sätt uppgifter i föregående tillstånd endast för noder som tillhör samma uppdateringsdomän. När en reparationsaktivitet har flyttats till Förberedelsetillstånd inaktiveras motsvarande Service Fabric-nod med avsikten Inställd på Starta om.

    POA-versionerna 1.4.0 och senare publicerar händelser med egenskapen ClusterPatchingStatus på CoordinatorService för att visa de noder som korrigeras. Uppdateringarna installeras på _poanode_0, enligt följande bild:

    Bild av status för klusterkorrigering

  4. När noden har inaktiverats flyttas reparationsuppgiften till Körningstillstånd .

    Kommentar

    En nod som har fastnat i inaktiverat tillstånd kan blockera en ny reparationsuppgift, vilket stoppar korrigeringsåtgärden i klustret.

  5. När reparationsuppgiften är i körningstillstånd börjar korrigeringsinstallationen på noden. När korrigeringen har installerats kanske noden eller kanske inte startas om, beroende på korrigeringen. Därefter flyttas reparationsaktiviteten till Återställningstillstånd , som kan återanvända noden. Reparationsuppgiften markeras sedan som slutförd.

    I POA-versionerna 1.4.0 och senare kan du hitta status för uppdateringen genom att visa hälsohändelserna på NodeAgentService med egenskapen WUOperationStatus-NodeName<>. De markerade avsnitten i följande bilder visar status för Windows-uppdateringar på noder poanode_0 och poanode_2:

    Skärmbild som visar konsolfönstret med Windows Update-åtgärdsstatus med poanode_0 markerat.

    Skärmbild som visar konsolfönstret med Windows Update-åtgärdsstatus med poanode_1 markerat.

    Du kan också hämta informationen med hjälp av PowerShell. För att göra det ansluter du till klustret och hämtar reparationsaktivitetens tillstånd med hjälp av Get-ServiceFabricRepairTask.

    I följande exempel är aktiviteten "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" i DownloadComplete-tillstånd . Det innebär att uppdateringar har laddats ned på den poanode_2 noden, och installationen kommer att försökas när uppgiften flyttas till Körningstillstånd .

     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"}

    Om fler problem återstår att hitta loggar du in på den virtuella datorn eller de virtuella datorerna och lär dig mer om dem med hjälp av Windows-händelseloggar. Den tidigare nämnda reparationsuppgiften kan bara finnas i följande kör-undertillstånd:

    ExecutorSubState beskrivning
    Ingen=1 Innebär att det inte fanns någon pågående åtgärd på noden. Tillståndet kan vara i övergång.
    DownloadCompleted=2 Innebär att nedladdningsåtgärden slutfördes med lyckade, partiella fel eller fel.
    InstallationApproved=3 Innebär att nedladdningsåtgärden slutfördes tidigare och Repair Manager har godkänt installationen.
    InstallationInProgress=4 Motsvarar körningstillståndet för reparationsuppgiften.
    InstallationCompleted=5 Innebär att installationen slutfördes med framgång, partiell framgång eller fel.
    RestartRequested=6 Innebär att korrigeringsinstallationen har slutförts och att det finns en väntande omstartsåtgärd på noden.
    RestartNotNeeded=7 Innebär att omstarten inte behövdes när korrigeringsinstallationen slutfördes.
    RestartCompleted=8 Innebär att omstarten har slutförts.
    OperationCompleted=9 Windows Update-åtgärden har slutförts.
    OperationAborted=10 Innebär att Windows Update-åtgärden avbröts.

  6. I POA-versionerna 1.4.0 och senare, när ett noduppdateringsförsök har slutförts, publiceras en händelse med egenskapen "WUOperationStatus-[NodeName]" på NodeAgentService för att meddela dig när nästa försök att ladda ned och installera Windows-uppdateringarna börjar. Detta visas i följande bild:

    Skärmbild som visar konsolfönstret med Windows Update-åtgärdsstatus med NodeAgentService.

Diagnostikloggar

Programloggar för korrigeringsorkestrering samlas in som en del av Service Fabric-körningsloggarna.

Du kan samla in loggar med hjälp av diagnostikverktyget eller valfri pipeline. POA använder följande fasta provider-ID:t för att logga händelser via händelsekälla:

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

Hälsorapporter

POA publicerar även hälsorapporter mot Node Agent Service eller koordinatortjänsten i följande scenarier:

  • Node Agent NTService är nere

    Om Node Agent NTService är nere på en nod genereras en hälsorapport på varningsnivå mot Node Agent Service.

  • Repair Manager-tjänsten är inte aktiverad

    Om Repair Manager-tjänsten inte hittas i klustret genereras en hälsorapport på varningsnivå för koordinatortjänsten.

Vanliga frågor och svar

F: Varför ser jag mitt kluster i ett feltillstånd när POA körs?

S: Under installationsprocessen inaktiverar eller startar POA om noder, vilket tillfälligt kan resultera i ett kluster med feltillstånd.

Beroende på programmets princip kan antingen en nod gå ned under en korrigeringsåtgärd eller så kan en hel uppdateringsdomän gå ned samtidigt.

I slutet av installationen av Windows-uppdateringar kan noderna återanvändas efter omstart.

I följande exempel gick klustret tillfälligt till ett feltillstånd eftersom två noder var nere och principen MaxPercentageUnhealthyNodes överträddes. Felet är tillfälligt tills korrigeringsåtgärden kan påbörjas.

Bild av kluster med feltillstånd

Om problemet kvarstår läser du avsnittet Felsökning.

F: Vad kan jag göra om POA är i ett varningstillstånd?

S: Kontrollera om en hälsorapport som publicerats mot programmet anger rotorsaken. Varningen innehåller vanligtvis information om problemet. Om problemet är tillfälligt förväntas programmet återställas automatiskt.

F: Vad kan jag göra om mitt kluster är felfritt och jag behöver göra en brådskande uppdatering av operativsystemet?

S: POA installerar inte uppdateringar när klustret inte är felfritt. Försök att få klustret i ett felfritt tillstånd för att avblockera POA-arbetsflödet.

F: Ska jag ange TaskApprovalPolicy som "NodeWise" eller "UpgradeDomainWise" för mitt kluster?

S: Inställningen "UpgradeDomainWise" påskyndar den övergripande klusterreparationen genom att parallellt korrigera alla noder som tillhör en uppdateringsdomän. Under processen är noder som tillhör en hel uppdateringsdomän otillgängliga (i inaktiverat tillstånd).

Inställningen "NodeWise" korrigerar däremot bara en nod i taget, vilket innebär att den övergripande klusterkorrigeringen kan ta längre tid. Men endast en nod som mest skulle vara otillgänglig (i inaktiverat tillstånd) under korrigeringsprocessen.

Om klustret kan tolerera att köras på ett N-1-antal uppdateringsdomäner under korrigeringscykeln (där N är det totala antalet uppdateringsdomäner i klustret) kan du ange principen som "UpgradeDomainWise". Annars ställer du in den på "NodeWise".

F: Hur lång tid tar det att korrigera en nod?

S: Det kan ta från minuter att korrigera en nod (till exempel windows Defender-definitionsuppdateringar) till timmar (till exempel kumulativa Windows-uppdateringar). Den tid som krävs för att korrigera en nod beror främst på:

  • Storleken på uppdateringarna.
  • Antalet uppdateringar som måste tillämpas i ett uppdateringsfönster.
  • Den tid det tar att installera uppdateringarna startar du om noden (om det behövs) och slutför installationsstegen efter omstarten.
  • Prestanda för den virtuella datorn eller datorn och nätverksvillkoren.

F: Hur lång tid tar det att korrigera ett helt kluster?

S: Den tid som krävs för att korrigera ett helt kluster beror på:

  • Den tid som krävs för att korrigera en nod.

  • Koordinatortjänstens princip. Standardprincipen"NodeWise" resulterar i att endast en nod i taget korrigeras, en metod som är långsammare än att använda "UpgradeDomainWise".

    Exempel: Om det tar ~1 timme att korrigera en nod måste du korrigera ett 20-nodkluster (samma typ av noder) med 5 uppdateringsdomäner som var och en innehåller 4 noder:

    • För "NodeWise": ~20 timmar.
    • För "UpgradeDomainWise": ~5 timmar.

  • Klusterbelastningen. Varje korrigeringsåtgärd kräver att kundens arbetsbelastning flyttas till andra tillgängliga noder i klustret. En nod som korrigeras skulle vara i inaktiverat tillstånd under den här tiden. Om klustret körs nära hög belastning skulle inaktiveringsprocessen ta längre tid. Därför kan den övergripande korrigeringsprocessen verka långsam under sådana stressade förhållanden.

  • Fel vid klusterhälsa under korrigeringen. Eventuell försämring av klustrets hälsotillstånd skulle avbryta korrigeringsprocessen. Det här problemet skulle öka den totala tid som krävs för att korrigera hela klustret.

F: Varför ser jag vissa uppdateringar i Windows Update-resultaten som hämtas via REST API, men inte under Windows Update-historiken på datorn?

S: Vissa produktuppdateringar visas endast i sin egen uppdaterings- eller korrigeringshistorik. Windows Defender-uppdateringar kanske eller kanske inte visas i Windows Update-historiken på Windows Server 2016.

F: Kan POA användas för att korrigera mitt dev-kluster (ett nodkluster)?

S: Nej, POA kan inte användas för att korrigera ett kluster med en nod. Den här begränsningen beror avsiktligt på att Service Fabric-systemtjänster eller andra kundappar skulle medföra stilleståndstid. Därför skulle reparationsjobb aldrig godkännas av Repair Manager.

F: Hur korrigerar jag klusternoder i Linux?

S: Mer information om hur du samordnar uppdateringar på Linux finns i Automatisk uppgradering av os-avbildningar för vm-skalningsuppsättningar för virtuella datorer.

F: Varför tar uppdateringscykeln så lång tid?

S: Fråga efter JSON-resultatet, ange uppdateringscykeln för alla noder och försök sedan ta reda på den tid det tar för uppdateringsinstallationen på varje nod med hjälp av OperationStartTime och OperationTime (OperationCompletionTime).

Om det finns ett stort tidsfönster där ingen uppdatering sker kan klustret ha ett feltillstånd och reparationshanteraren kan därför inte godkänna några POA-reparationsuppgifter. Om uppdateringsinstallationen tar lång tid på en nod kanske noden inte har uppdaterats på ett tag. Många uppdateringar kan vänta på installationen, vilket kan leda till fördröjningar.

Det kan också vara möjligt att nodkorrigering blockeras eftersom den har fastnat i inaktiverande tillstånd. Detta beror vanligtvis på att inaktivering av noden kan leda till kvorum- eller dataförlustsituationer.

F: Varför måste noden inaktiveras när POA korrigerar den?

S: POA inaktiverar noden med avsikten Starta om , vilket stoppar eller omallokerar alla Service Fabric-tjänster som körs på noden. POA gör detta för att säkerställa att program inte slutar använda en blandning av nya och gamla DLL:er, så vi rekommenderar att du inte korrigerar en nod utan att inaktivera den.

F: Vad är det maximala antalet noder som kan uppdateras med poa?

S: POA använder Service Fabric Repair Manager för att skapa reparationsuppgifter för noder för uppdateringar. Det går dock inte att utföra fler än 250 reparationsuppgifter samtidigt. För närvarande skapar POA reparationsuppgifter för varje nod samtidigt, så POA kan inte uppdatera fler än 250 noder i ett kluster.

Ansvarsfriskrivningar

  • POA godkänner licensavtalet för slutanvändare för Windows Update för användarens räkning. Du kan också inaktivera inställningen i programmets konfiguration.

  • POA samlar in telemetri för att spåra användning och prestanda. Programmets telemetri följer inställningen för Service Fabric-körningens telemetriinställning (som är aktiverad som standard).

Felsökning

Det här avsnittet innehåller möjliga felsökningslösningar för problem med korrigering av noder.

En nod återgår inte till up-tillståndet

  • Noden kan ha fastnat i inaktiverande tillstånd eftersom:

    • En säkerhetskontroll väntar. Du kan åtgärda den här situationen genom att se till att tillräckligt många noder är tillgängliga i ett felfritt tillstånd.

  • Noden kan ha fastnat i inaktiverat tillstånd eftersom:

    • Den inaktiverades manuellt.
    • Det inaktiverades på grund av ett pågående Azure-infrastrukturjobb.
    • Den inaktiverades tillfälligt av POA för att korrigera noden.

  • Noden kan ha fastnat i ett nedläge eftersom:

    • Den placerades i ett nedläge manuellt.
    • Den genomgår en omstart (som kan utlösas av POA).
    • Den har en felaktig virtuell dator eller dator, eller så har den problem med nätverksanslutningen.

Uppdateringar hoppades över på vissa noder

POA försöker installera en Windows-uppdatering enligt omplaneringsprincipen. Tjänsten försöker återställa noden och hoppa över uppdateringen enligt programprincipen.

I sådana fall genereras en hälsorapport på varningsnivå mot Node Agent Service. Windows Update-resultatet innehåller också den möjliga orsaken till felet.

Hälsotillståndet för klustret går till fel när uppdateringen installeras

En felaktig Windows-uppdatering kan sänka hälsotillståndet för ett program eller kluster på en viss nod eller uppdateringsdomän. POA avbryter alla efterföljande Windows Update-åtgärder tills klustret är felfritt igen.

En administratör måste ingripa och avgöra varför programmet eller klustret blev felfritt på grund av Windows Update.

Viktig information om POA

Kommentar

För POA-versionerna 1.4.0 och senare hittar du viktig information och versioner på sidan patchorkestreringsprogram på GitHub.

Version 1.1.0

  • Offentlig version

Version 1.1.1

  • En bugg har åtgärdats i SetupEntryPoint för NodeAgentService som förhindrade installationen av NodeAgentNTService.

Version 1.2.0

  • Felkorrigeringar runt arbetsflödet för omstart av systemet.
  • Felkorrigering vid skapande av RM-uppgifter på grund av vilken hälsokontroll under förberedelsen av reparationsuppgifter inte skedde som förväntat.
  • Ändrade startläget för Windows-tjänsten POANodeSvc från automatisk till fördröjd auto.

Version 1.2.1

  • Felkorrigering i arbetsflödet för nedskalning av kluster. Introducerade skräpinsamlingslogik för POA-reparationsuppgifter som tillhör noder som inte finns.

Version 1.2.2

  • Diverse felkorrigeringar.
  • Binärfiler är nu signerade.
  • Sfpkg-länken har lagts till för programmet.

Version 1.3.0

  • Om du anger InstallWindowsOSOnlyUpdates till false installeras nu alla tillgängliga uppdateringar.
  • Ändrade logiken för att inaktivera automatiska uppdateringar. Detta åtgärdar ett fel där automatiska uppdateringar inte inaktiverades på Server 2016 och senare.
  • Parametriserad placeringsbegränsning för båda mikrotjänsterna i POA för avancerade användningsfall.

Version 1.3.1

  • Åtgärda regression där POA 1.3.0 inte fungerar på Windows Server 2012 R2 eller tidigare på grund av ett fel vid inaktivering av automatiska uppdateringar.
  • Åtgärdar bugg där InstallationWindowsOSOnlyUpdates-konfiguration alltid väljs som Sant.
  • Ändra standardvärdet för InstallWindowsOSOnlyUpdates till False.

Version 1.3.2

  • Åtgärda ett problem som påverkar uppdateringslivscykeln på en nod, om det finns noder med ett namn som är en delmängd av det aktuella nodnamnet. För sådana noder är det möjligt att korrigeringen missades eller att en omstart väntar.