Share 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 det 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 NTService för Node Agent.
    • Ö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.
    • Rapportering av hälsorapporter om en åtgärd har misslyckats när den har tömt alla återförsök.

Anteckning

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

Förutsättningar

Anteckning

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å guldhå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 Portal

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

Bild av aktivering av Repair Manager från Azure Portal

Distributionsmodellen för Azure Resource Manager

Du kan också använda Azure Resource Manager-distributionsmodellen för att aktivera Repair Manager-tjänsten i 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.

Gör följande för att aktivera Repair Manager-tjänsten med hjälp av mallen Azure Resource Manager distributionsmodell:

  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 tillämpar du dem och låter uppdateringen slutföras. Nu kan du se att Repair Manager-tjänsten 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 genom att använda det uppdaterade klustermanifestet för att 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 automatiska Windows-uppdateringar på varje klusternod. Men om inställningarna hanteras av en administratör eller en grupprincip rekommenderar vi att du uttryckligen anger Windows Update princip 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 Typ Information
MaxResultsToCache Lång 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 Enum
{ 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. (Högst 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: falskt)		 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 som 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:
– Varje månad, 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)
- Varje dag, HH:MM:SS (exempel: Varje dag, 12:22:32)
– MonthlyByWeekAndDay, Week, Day, HH:MM:SS (exempel: MonthlyByWeekAndDay, 2, fredag, 21:00:00 anger 21:00 UTC-tid på fredag den andra veckan i varje månad)
- Ingen anger att Windows-uppdateringar inte ska göras.

Tiderna anges i UTC.
AcceptWindowsUpdateEula Boolesk
(Standard: sant)		 Genom att ange den här flaggan godkänner programmet End-User-licensavtalet för Windows Update åt datorns ägare.

Tips

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 vid 17:00 UTC-tid. Om du antar att programuppgraderingen eller distributionen tar högst 30 minuter anger du WUFrequency som Dagligen, 17:30:00.

Distribuera POA

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

  2. Distribuera POA precis som andra Service Fabric-appar. Information om hur du distribuerar den 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 att underlätta för dig 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.

Anteckning

Behåll skriptet och programmappen PatchOrchestrationApplication i samma katalog.

Uppgradera POA

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

Ta bort POA

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

För att underlätta för dig har vi tillhandahållit Undeploy.ps1-skriptet 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.

Anteckning

Behåll skriptet och programmappen PatchOrchestrationApplication i samma katalog.

Visa Windows Update resultat

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 Information
OperationResult 0 – Lyckades
1 – Lyckades med fel
2 – Misslyckades
3 – Avbruten
4 – Avbröts med timeout		 Anger resultatet av den övergripande åtgärden, vilket normalt innebär 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.
Åtgärdstyp 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" Den Windows Update fråga som användes för att söka efter uppdateringar. Mer information finns i WuQuery.
RebootRequired true – omstart krävdes
false – omstart krävdes inte		 Anger om en omstart krävdes för att slutföra installationen av uppdateringar.
OperationStartTime DateTime Anger den tidpunkt då åtgärden (Nedladdning/installation) startades.
OperationTime DateTime 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 fråga 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. Om du vill kontrollera den exakta URL:en läser du Service Fabric Explorer. Resultatet är till exempel tillgängligt på http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Bild av REST-slutpunkten

Om omvänd proxy är aktiverad i klustret kan du även 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 omvänd proxy 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.

Anteckning

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 aktivitet om klustret är i ett feltillstånd.

Vi hjälper dig att förstå hur uppdateringarna fortsätter på en nod genom att gå 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 statusen Begärd och uppdaterar dem sedan till Förberedelsetillstånd baserat på TaskApprovalPolicy. Om TaskApprovalPolicy har konfigurerats att vara NodeWise förbereds en reparationsaktivitet som motsvarar en nod endast om ingen annan reparationsaktivitet för närvarande är i tillståndet Förbereder, Godkänd, Körs eller Återställer .

    När det gäller UpgradeWise TaskApprovalPolicy finns det uppgifter i föregående tillstånd endast för noder som tillhör samma uppdateringsdomän. När en reparationsaktivitet har flyttats till tillståndet Förberederinaktiveras 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 reparationsåtgärden till körningstillstånd .

    Anteckning

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

  5. När reparationsåtgärden är i körningstillstånd börjar korrigeringsinstallationen på noden. När korrigeringen har installerats kanske noden startas om, beroende på korrigeringen. Därefter flyttas reparationsuppgiften till Återställningstillstånd , som återaktiverar 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. Det gör du genom att ansluta till klustret och hämta tillståndet för reparationsuppgiften med hjälp av Get-ServiceFabricRepairTask.

    I följande exempel är aktiviteten "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" i tillståndet DownloadComplete . Det innebär att uppdateringar har laddats ned på noden poanode_2 och att installationen görs när uppgiften övergår 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 kvarstår 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 executor-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 lyckat, partiellt 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 lyckad, delvis lyckad eller misslyckad installation.
    RestartRequested=6 Innebär att korrigeringsinstallationen slutfördes och att det finns en väntande omstartsåtgärd på noden.
    RestartNotNeeded=7 Innebär att omstarten inte behövdes efter att korrigeringsinstallationen slutfördes.
    RestartCompleted=8 Innebär att omstarten har slutförts.
    OperationCompleted=9 Åtgärden Windows Update har slutförts.
    OperationAborted=10 Innebär att den 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ällan:

  • 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-tjänsten eller koordinatortjänsten i följande scenarier:

  • Node Agent NTService är inte tillgänglig

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

  • 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 bröts. 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 publiceras 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 felaktigt och jag behöver göra en brådskande uppdatering av operativsystemet?

S: POA installerar inte uppdateringar när klustret är felaktigt. 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 inte tillgä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 högst en nod skulle vara otillgänglig (i inaktiverat tillstånd) under korrigeringsprocessen.

Om klustret kan tolerera körning 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: Uppdatering av en nod kan ta från minuter (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 kluster med 20 noder (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 tar inaktiveringsprocessen längre tid. Därför kan den övergripande korrigeringsprocessen verka vara långsam under sådana stressade förhållanden.

  • Fel vid klusterhälsa under korrigering. Eventuell försämringav 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 några uppdateringar i Windows Update resultat som hämtas via REST API, men inte under Windows Update-historiken på datorn?

S: Vissa produktuppdateringar visas bara i sin egen uppdaterings- eller korrigeringshistorik. Till exempel kan Windows Defender uppdateringar visas i Windows Update historik på Windows Server 2016.

F: Kan POA användas för att korrigera mitt utvecklingskluster (kluster med en nod)?

S: Nej, POA kan inte användas för att korrigera ett kluster med en nod. Den här begränsningen är avsiktlig eftersom 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 gör jag för att korrigera klusternoder i Linux?

S: Information om hur du dirigerar uppdateringar i Linux finns i Automatisk uppgradering av avbildningar av os-avbildningar för virtuella Azure-datorer.

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

S: Fråga efter resultat-JSON, ange uppdateringscykeln för alla noder och sedan kan du försöka ta reda på hur lång tid det tar vid 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örseningar.

Det kan också vara möjligt att nodkorrigering blockeras eftersom den har fastnat i inaktiverat tillstånd. Detta inträffar vanligtvis eftersom 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 använder 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 End-User licensavtalet 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 på 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ånd

  • Noden kan ha fastnat i inaktiveringstillstånd eftersom:

    • En säkerhetskontroll väntar. Å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å fall genereras en hälsorapport på varningsnivå mot Node Agent Service. Det 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 efterföljande Windows Update åtgärd 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

Anteckning

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örberedelse av reparationsuppgifter inte skedde som förväntat.
  • Startläget för Windows-tjänsten POANodeSvc har ändrats från automatiskt till fördröjt automatiskt.

Version 1.2.1

  • Felkorrigering i arbetsflöde 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 poa-mikrotjänsterna 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ärda fel där InstallWindowsOSOnlyUpdates-konfigurationen alltid väljs som True.
  • Ä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.