PatchIndelingstoepassing gebruiken

Belangrijk

Vanaf 30 april 2019 wordt Patch Orchestration Application versie 1.2.* niet meer ondersteund. Zorg ervoor dat u een upgrade uitvoert naar de nieuwste versie.

Patch Orchestration Application (POA) is een wrapper rond de Service Fabric Repair Manager-service, waarmee op configuratie gebaseerde besturingssysteempatchplanning mogelijk is voor niet-door Azure gehoste clusters. POA is niet vereist voor niet-azure-gehoste clusters, maar het plannen van patch-installatie per updatedomein is vereist om Service Fabric-clusterhosts te patchen zonder downtime.

POA is een Service Fabric-toepassing waarmee patches van besturingssystemen op een Service Fabric-cluster worden geautomatiseerd zonder downtime.

POA biedt de volgende functies:

• Automatische installatie van besturingssysteemupdates. Updates van het besturingssysteem worden automatisch gedownload en geïnstalleerd. Clusterknooppunten worden zo nodig opnieuw opgestart zonder downtime van het cluster.

• Clusterbewuste patching en statusintegratie. Terwijl POA updates toepast, wordt de status van de clusterknooppunten bewaakt. Clusterknooppunten worden per knooppunt of één updatedomein tegelijk bijgewerkt. Als de status van het cluster uitvalt vanwege het patchproces, wordt patching gestopt om te voorkomen dat het probleem wordt verergerd.

Interne details van POA

POA bestaat uit de volgende subonderdelen:

• Coördinatorservice: deze stateful service is verantwoordelijk voor:

  • Het coördineren van de Windows Update taak op het hele cluster.
  • Het resultaat van voltooide Windows Update bewerkingen opslaan.

• Node Agent-service: deze stateless service wordt uitgevoerd op alle Service Fabric-clusterknooppunten. De service is verantwoordelijk voor:

  • Bootstrapping van de NTService van de knooppuntagent.
  • De NTService van de knooppuntagent bewaken.

• Node Agent NTService: deze Windows NT-service wordt uitgevoerd met een hogere bevoegdheid (SYSTEM). De Node Agent-service en de coördinatorservice worden daarentegen uitgevoerd met een bevoegdheid op een lager niveau (NETWORK SERVICE). De service is verantwoordelijk voor het uitvoeren van de volgende Windows Update taken op alle clusterknooppunten:

  • Automatische Windows-updates op het knooppunt uitschakelen.
  • Het downloaden en installeren van Windows-updates volgens het beleid dat de gebruiker heeft opgegeven.
  • De computer opnieuw opstarten na de installatie van Windows-updates.
  • De resultaten van Windows-updates uploaden naar de coördinatorservice.
  • Statusrapporten rapporteren als een bewerking is mislukt nadat alle nieuwe pogingen zijn uitgeput.

Notitie

POA gebruikt de Service Fabric Repair Manager-service om het knooppunt uit te schakelen of in te schakelen en statuscontroles uit te voeren. De hersteltaak die door POA is gemaakt, houdt de Windows Update voortgang voor elk knooppunt bij.

Vereisten

Notitie

De vereiste minimumversie .NET Framework is 4.6.

De Repair Manager-service inschakelen (als deze nog niet wordt uitgevoerd)

PoA vereist dat de Repair Manager-service is ingeschakeld op het cluster.

Azure-clusters

Voor Azure-clusters in de silver-duurzaamheidlaag is de Repair Manager-service standaard ingeschakeld. Voor Azure-clusters in de gold-duurzaamheidlaag is de Repair Manager-service mogelijk al dan niet ingeschakeld, afhankelijk van wanneer deze clusters zijn gemaakt. Voor Azure-clusters in de duurzaamheidslaag brons is de Repair Manager-service standaard niet ingeschakeld. Als de service al is ingeschakeld, ziet u dat deze wordt uitgevoerd in de sectie Systeemservices in Service Fabric Explorer.

Azure Portal

U kunt Repair Manager inschakelen vanuit de Azure Portal wanneer u het cluster instelt. Wanneer u het cluster configureert, selecteert u de optie Reparatiebeheer opnemen onder Invoegtoepassingsfuncties.

Het Azure Resource Manager-implementatiemodel

U kunt ook het Azure Resource Manager-implementatiemodel gebruiken om de Repair Manager-service in te schakelen op nieuwe en bestaande Service Fabric-clusters. Haal de sjabloon op voor het cluster dat u wilt implementeren. U kunt de voorbeeldsjablonen gebruiken of een aangepaste sjabloon voor een Azure Resource Manager-implementatiemodel maken.

Ga als volgt te werk om de Repair Manager-service in te schakelen met behulp van de sjabloon voor het implementatiemodel van Azure Resource Manager:

1. Controleer of apiVersion is ingesteld op 2017-07-01-preview voor de resource Microsoft.ServiceFabric/clusters . Als dit anders is, moet u bijwerken apiVersion naar 2017-07-01-preview of hoger:

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

2. Schakel de Repair Manager-service in door de volgende addonFeatures sectie toe te voegen na de fabricSettings sectie:

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

3. Nadat u uw clustersjabloon met deze wijzigingen hebt bijgewerkt, past u deze toe en laat u de update voltooien. U ziet nu dat de Repair Manager-service wordt uitgevoerd in uw cluster. Dit heet fabric:/System/RepairManagerService in de sectie systeemservices in Service Fabric Explorer.

Zelfstandige on-premises clusters

Als u de Repair Manager-service wilt inschakelen op een nieuw of bestaand Service Fabric-cluster, kunt u de configuratie-instellingen voor een zelfstandig Windows-cluster gebruiken.

De Repair Manager-service inschakelen:

1. apiVersion Controleer of in Algemene clusterconfiguraties is ingesteld op 04-2017 of hoger, zoals hier wordt weergegeven:

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

2. Schakel de Repair Manager-service in door de volgende addonFeatures sectie toe te voegen na de fabricSettings sectie, zoals hier wordt weergegeven:

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

3. Werk uw clustermanifest bij met deze wijzigingen door het bijgewerkte clustermanifest te gebruiken om een nieuw cluster te maken of de clusterconfiguratie bij te werken.

   Nadat het cluster wordt uitgevoerd met een bijgewerkt clustermanifest, ziet u dat de Repair Manager-service wordt uitgevoerd in uw cluster. Het heet fabric:/System/RepairManagerService en bevindt zich in de sectie systeemservices in Service Fabric Explorer.

Windows-updates configureren voor alle knooppunten

Automatische Windows-updates kunnen leiden tot beschikbaarheidsverlies, omdat meerdere clusterknooppunten tegelijkertijd opnieuw kunnen worden opgestart. POA probeert standaard de automatische Windows-updates op elk clusterknooppunt uit te schakelen. Als de instellingen echter worden beheerd door een beheerder of een groepsbeleid, raden we u aan het beleid Windows Update expliciet in te stellen op 'Waarschuwen voor downloaden'.

Het toepassingspakket downloaden

Als u het toepassingspakket wilt downloaden, gaat u naar de pagina Patch Orchestration Application release op GitHub.

POA-gedrag configureren

U kunt POA-gedrag configureren om aan uw behoeften te voldoen. Overschrijf de standaardwaarden door de toepassingsparameter door te geven terwijl u de toepassing maakt of bijwerkt. U kunt toepassingsparameters opgeven door op te geven ApplicationParameter aan de Start-ServiceFabricApplicationUpgrade cmdlets of New-ServiceFabricApplication .

Parameter	Type	Details
MaxResultsToCache	Lange	Het maximum aantal Windows Update resultaten dat in de cache moet worden opgeslagen. De standaardwaarde is 3000, ervan uitgaande dat:   - Het aantal knooppunten is 20.   - Het aantal updates voor een knooppunt per maand is 5.   - Het aantal resultaten per bewerking kan 10 zijn.   - De resultaten van de afgelopen drie maanden moeten worden opgeslagen.
TaskApprovalPolicy	Enum { NodeWise, UpgradeDomainWise }	TaskApprovalPolicy geeft het beleid aan dat door de coördinatorservice moet worden gebruikt om Windows-updates te installeren op de Service Fabric-clusterknooppunten. De toegestane waarden zijn: NodeWise: Windows-updates worden per knooppunt geïnstalleerd. UpgradeDomainWise: Windows-updates worden één updatedomein tegelijk geïnstalleerd. (Maximaal alle knooppunten die deel uitmaken van een updatedomein kunnen worden gebruikt voor een Windows-update.) Als u wilt bepalen welk beleid het meest geschikt is voor uw cluster, raadpleegt u de sectie Veelgestelde vragen .
LogsDiskQuotaInMB	Lange (Standaard: 1024)	De maximale grootte van app-logboeken voor patchindeling in MB, die lokaal op knooppunten kunnen worden bewaard.
WUQuery	tekenreeks (Standaard: IsInstalled=0)	Voer een query uit om Windows-updates op te halen. Zie WuQuery voor meer informatie.
InstallWindowsOSOnlyUpdates	Booleaans (standaard: onwaar)	Gebruik deze vlag om te bepalen welke updates moeten worden gedownload en geïnstalleerd. De volgende waarden zijn toegestaan true: installeert alleen windows-besturingssysteemupdates. false: installeert alle beschikbare updates op de computer.
WUOperationTimeOutInMinutes	Int (Standaard: 90)	Hiermee geeft u de time-out voor een Windows Update bewerking (zoeken of downloaden of installeren). Als de bewerking niet binnen de opgegeven time-out is voltooid, wordt deze afgebroken.
WURescheduleCount	Int (Standaard: 5)	Het maximum aantal keren dat de service de Windows-update opnieuw inplant als een bewerking permanent mislukt.
WURescheduleTimeInMinutes	Int (Standaard: 30)	Het interval waarmee de service de Windows-updates opnieuw inplant als de fout zich blijft voordoen.
WUFrequency	Door komma's gescheiden tekenreeks (standaard: wekelijks, woensdag, 7:00:00)	De frequentie voor het installeren van Windows-updates. De notatie en mogelijke waarden zijn: - Maandelijks, DD, UU:MM:SS (bijvoorbeeld: Maandelijks, 5, 12:22:32). Toegestane waarden voor veld DD (dag) zijn getallen van 1 tot en met 28 en laatste. - Wekelijks, Dag, UU:MM:SS (bijvoorbeeld: Wekelijks, Dinsdag, 12:22:32) - Dagelijks, UU:MM:SS (bijvoorbeeld: Dagelijks, 12:22:32) - MonthlyByWeekAndDay, Week, Day, UU:MM:SS (bijvoorbeeld: MonthlyByWeekAndDay, 2, Vrijdag, 21:00:00 geeft 21:00 uur UTC aan op vrijdag van de tweede week van elke maand) - Geen geeft aan dat Windows-updates niet moeten worden uitgevoerd. Tijden zijn in UTC.
AcceptWindowsUpdateEula	Booleaans (Standaard: true)	Door deze vlag in te stellen, accepteert de toepassing de End-User gebruiksrechtovereenkomst voor Windows Update namens de eigenaar van de machine.

Tip

Als u wilt dat Windows-updates onmiddellijk worden uitgevoerd, stelt u WUFrequency in ten opzichte van de implementatietijd van de toepassing. Stel dat u een testcluster met vijf knooppunten hebt en van plan bent om de app rond 17:00 uur UTC te implementeren. Als u ervan uitgaat dat de upgrade of implementatie van de toepassing maximaal 30 minuten duurt, stelt u WUFrequency in op Dagelijks, 17:30:00.

POA implementeren

1. Voltooi alle vereiste stappen om het cluster voor te bereiden.

2. Implementeer POA zoals elke andere Service Fabric-app. Zie Toepassingen implementeren en verwijderen met Behulp van PowerShell als u deze wilt implementeren met behulp van PowerShell.

3. Als u de toepassing wilt configureren op het moment van implementatie, geeft u de ApplicationParameter door aan de New-ServiceFabricApplication cmdlet. Voor uw gemak hebben we het script Deploy.ps1 samen met de toepassing. Het script gebruiken:

   • Maak verbinding met een Service Fabric-cluster met behulp van Connect-ServiceFabricCluster.
   • Voer het PowerShell-script uit Deploy.ps1 met de juiste ApplicationParameter waarde.

Notitie

Bewaar het script en de toepassingsmap PatchOrchestrationApplication in dezelfde map.

POA upgraden

Als u uw POA-versie wilt upgraden met behulp van PowerShell, volgt u de instructies in Service Fabric-toepassingsupgrade met behulp van PowerShell.

POA verwijderen

Als u de toepassing wilt verwijderen, volgt u de instructies in Toepassingen implementeren en verwijderen met behulp van PowerShell.

Voor uw gemak hebben we het Undeploy.ps1-script samen met de toepassing verstrekt. Het script gebruiken:

• Maak verbinding met een Service Fabric-cluster met behulp van Connect-ServiceFabricCluster.
• Voer het PowerShell-script uit Undeploy.ps1.

Notitie

Bewaar het script en de toepassingsmap PatchOrchestrationApplication in dezelfde map.

De Windows Update resultaten weergeven

POA maakt REST API's beschikbaar om de historische resultaten weer te geven aan gebruikers. Hier volgt een voorbeeld van de resultaat-JSON:

[
  {
    "NodeName": "_stg1vm_1",
    "WindowsUpdateOperationResults": [
      {
        "OperationResult": 0,
        "NodeName": "_stg1vm_1",
        "OperationTime": "2019-05-13T08:44:56.4836889Z",
        "OperationStartTime": "2019-05-13T08:44:33.5285601Z",
        "UpdateDetails": [
          {
            "UpdateId": "7392acaf-6a85-427c-8a8d-058c25beb0d6",
            "Title": "Cumulative Security Update for Internet Explorer 11 for Windows Server 2012 R2 (KB3185319)",
            "Description": "A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "ResultCode": 0,
            "HResult": 0
          }
        ],
        "OperationType": 1,
        "WindowsUpdateQuery": "IsInstalled=0",
        "WindowsUpdateFrequency": "Daily,10:00:00",
        "RebootRequired": false
      }
    ]
  },
  ...
]

De JSON-velden worden beschreven in de volgende tabel:

Veld	Waarden	Details
OperationResult	0 - Geslaagd 1 - Geslaagd met fouten 2 - Mislukt 3 - Afgebroken 4 - Afgebroken met time-out	Geeft het resultaat aan van de algehele bewerking, die gewoonlijk de installatie van een of meer updates omvat.
ResultCode	Hetzelfde als OperationResult	Dit veld geeft het resultaat aan van de installatiebewerking voor een afzonderlijke update.
OperationType	1 - Installatie 0 - Zoeken en downloaden	Installatie is standaard het enige OperationType dat wordt weergegeven in de resultaten.
WindowsUpdateQuery	De standaardwaarde is 'IsInstalled=0'	De Windows Update query die is gebruikt om te zoeken naar updates. Zie WuQuery voor meer informatie.
RebootRequired	true - opnieuw opstarten was vereist false - opnieuw opstarten was niet vereist	Hiermee wordt aangegeven of opnieuw opstarten vereist was om de installatie van updates te voltooien.
OperationStartTime	DateTime	Geeft het tijdstip aan waarop de bewerking (downloaden/installeren) is gestart.
OperationTime	DateTime	Geeft het tijdstip aan waarop de bewerking (downloaden/installeren) is voltooid.
Hresult	0 - Geslaagd overige - fout	Geeft de reden aan voor de fout van de Windows-update met updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

Als er nog geen update is gepland, is de resulterende JSON leeg.

Meld u aan bij het cluster om Windows Update resultaten op te vragen. Zoek het replica-IP-adres voor het primaire adres van de coördinatorservice en open de volgende URL vanuit de browser: http://< REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Het REST-eindpunt voor de coördinatorservice heeft een dynamische poort. Raadpleeg Service Fabric Explorer om de exacte URL te controleren. De resultaten zijn bijvoorbeeld beschikbaar op http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Als de omgekeerde proxy is ingeschakeld op het cluster, hebt u ook toegang tot de URL van buiten het cluster.

Het eindpunt dat u moet bereiken, is http://< SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

Als u de omgekeerde proxy op het cluster wilt inschakelen, volgt u de instructies in Omgekeerde proxy in Azure Service Fabric.

Waarschuwing

Nadat de omgekeerde proxy is geconfigureerd, zijn alle microservices in het cluster die een HTTP-eindpunt beschikbaar maken, adresseerbaar van buiten het cluster.

Diagnostische gegevens en statusgebeurtenissen

In deze sectie wordt beschreven hoe u problemen met patchupdates kunt opsporen of diagnosticeren via POA op Service Fabric-clusters.

Notitie

Als u veel van de volgende verbeteringen voor zelfdiagnose wilt krijgen, moet POA versie 1.4.0 of hoger zijn geïnstalleerd.

De Node Agent NTService maakt hersteltaken voor het installeren van updates op de knooppunten. Elke taak wordt vervolgens voorbereid door de coördinatorservice volgens het taakgoedkeuringsbeleid. Ten slotte worden de voorbereide taken goedgekeurd door Repair Manager, die geen taken goedkeurt als het cluster een slechte status heeft.

Om u te helpen begrijpen hoe updates op een knooppunt verlopen, gaan we stap voor stap aan de slag:

1. NodeAgentNTService, dat op elk knooppunt wordt uitgevoerd, zoekt op het geplande tijdstip naar beschikbare Windows-updates. Als er updates beschikbaar zijn, worden deze gedownload op het knooppunt.

2. Nadat de updates zijn gedownload, maakt de Node Agent NTService een bijbehorende hersteltaak voor het knooppunt met de naam POS___<unique_id>. U kunt deze hersteltaken bekijken met behulp van de cmdlet Get-ServiceFabricRepairTask of met behulp van SFX in de sectie knooppuntdetails. Nadat de hersteltaak is gemaakt, wordt deze snel verplaatst naar de status Geclaimd.

3. De coördinatorservice zoekt regelmatig naar hersteltaken met de status Geclaimd en werkt deze vervolgens bij naar De status Voorbereiden op basis van TaskApprovalPolicy. Als TaskApprovalPolicy is geconfigureerd als NodeWise, wordt een hersteltaak die overeenkomt met een knooppunt alleen voorbereid als er momenteel geen andere hersteltaak is met de status Voorbereiden, Goedgekeurd, Uitvoeren of Herstellen .

   Op dezelfde manier zijn er in het geval van UpgradeWise TaskApprovalPolicy alleen taken in de voorgaande statussen voor knooppunten die tot hetzelfde updatedomein behoren. Nadat een hersteltaak is verplaatst naar de status Voorbereiden , wordt het bijbehorende Service Fabric-knooppunt uitgeschakeld met de intentie ingesteld op Opnieuw opstarten.

   POA-versies 1.4.0 en hoger plaatsen gebeurtenissen met de eigenschap ClusterPatchingStatus op CoordinatorService om de knooppunten weer te geven die worden gepatcht. De updates worden geïnstalleerd op _poanode_0, zoals wordt weergegeven in de volgende afbeelding:

   

4. Nadat het knooppunt is uitgeschakeld, wordt de hersteltaak verplaatst naar de status Uitvoeren .

   Notitie

   Een knooppunt dat vastloopt in de status Uitgeschakeld , kan een nieuwe hersteltaak blokkeren, waardoor de patchbewerking op het cluster wordt gestopt.

5. Wanneer de hersteltaak de status Uitvoeren heeft, wordt de installatie van de patch op dat knooppunt gestart. Nadat de patch is geïnstalleerd, kan het knooppunt al dan niet opnieuw worden opgestart, afhankelijk van de patch. Vervolgens wordt de hersteltaak verplaatst naar de herstelstatus , waardoor het knooppunt opnieuw wordt ingeschakeld. De hersteltaak wordt vervolgens gemarkeerd als voltooid.

   In POA-versies 1.4.0 en hoger kunt u de status van de update vinden door de statusgebeurtenissen op NodeAgentService te bekijken met de eigenschap WUOperationStatus-NodeName<>. In de gemarkeerde secties in de volgende afbeeldingen ziet u de status van Windows-updates op knooppunten poanode_0 en poanode_2:

   

   

   U kunt de details ook ophalen met behulp van PowerShell. Hiervoor maakt u verbinding met het cluster en haalt u de status van de reparatietaak op met behulp van Get-ServiceFabricRepairTask.

   In het volgende voorbeeld heeft de taak 'POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15' de status DownloadComplete . Dit betekent dat updates zijn gedownload op het knooppunt poanode_2 en dat de installatie wordt geprobeerd wanneer de taak de status Uitvoeren krijgt.

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

   Als er nog meer problemen moeten worden gevonden, meldt u zich aan bij uw virtuele machine (VM) of VM's en leert u hier meer over met behulp van Windows-gebeurtenislogboeken. De eerder genoemde hersteltaak kan alleen bestaan in de volgende substatussen van het uitvoerprogramma:

   ExecutorSubState	Description
   Geen=1	Impliceert dat er geen actieve bewerking op het knooppunt is uitgevoerd. De status is mogelijk in overgang.
   DownloadCompleted=2	Impliceert dat de downloadbewerking is voltooid met een geslaagde, gedeeltelijke fout of fout.
   InstallationApproved=3	Impliceert dat de downloadbewerking eerder is voltooid en Repair Manager de installatie heeft goedgekeurd.
   InstallationInProgress=4	Komt overeen met de uitvoeringsstatus van de reparatietaak.
   InstallationCompleted=5	Impliceert dat de installatie is voltooid met succes, gedeeltelijk geslaagd of mislukt.
   RestartRequested=6	Impliceert dat de installatie van de patch is voltooid en dat er een actie voor opnieuw opstarten in behandeling is op het knooppunt.
   RestartNotNeeded=7	Impliceert dat het opnieuw opstarten niet nodig was nadat de installatie van de patch was voltooid.
   RestartCompleted=8	Impliceert dat het opnieuw opstarten is voltooid.
   OperationCompleted=9	De bewerking Windows Update is voltooid.
   OperationAborted=10	Impliceert dat de Windows Update bewerking is afgebroken.

6. Wanneer een knooppuntupdatepoging is voltooid in POA-versies 1.4.0 en hoger, wordt er een gebeurtenis met de eigenschap WUOperationStatus-[NodeName]op NodeAgentService geplaatst om u te informeren wanneer de volgende poging om de Windows-updates te downloaden en installeren wordt gestart. Dit wordt weergegeven in de volgende afbeelding:

   

Logboeken met diagnostische gegevens

Toepassingslogboeken voor patchindeling worden verzameld als onderdeel van de Service Fabric-runtimelogboeken.

U kunt logboeken vastleggen met behulp van het diagnostische hulpprogramma of de pijplijn van uw keuze. POA gebruikt de volgende vaste provider-id's om gebeurtenissen te registreren via de gebeurtenisbron:

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

Statusrapporten

POA publiceert ook statusrapporten voor de Node Agent-service of de coördinatorservice in de volgende scenario's:

• De NTService van de knooppuntagent is niet beschikbaar

  Als de NTService van de knooppuntagent niet beschikbaar is op een knooppunt, wordt er een statusrapport op waarschuwingsniveau gegenereerd voor de Node Agent-service.

• De Repair Manager-service is niet ingeschakeld

  Als de Repair Manager-service niet wordt gevonden in het cluster, wordt er een statusrapport op waarschuwingsniveau gegenereerd voor de coördinatorservice.

Veelgestelde vragen

V: Waarom zie ik mijn cluster in een foutstatus wanneer POA wordt uitgevoerd?

A: Tijdens het installatieproces worden knooppunten door POA uitgeschakeld of opnieuw opgestart, wat tijdelijk kan leiden tot een beschadigd cluster.

Afhankelijk van het beleid van de toepassing kan één knooppunt offline gaan tijdens een patchbewerking of kan een volledig updatedomein in één keer worden uitgeschakeld.

Aan het einde van de installatie van Windows-updates worden de knooppunten opnieuw ingeschakeld na het opnieuw opstarten.

In het volgende voorbeeld heeft het cluster tijdelijk een foutstatus omdat twee knooppunten niet beschikbaar waren en het beleid MaxPercentageUnhealthyNodes is geschonden. De fout is tijdelijk totdat de patchbewerking kan worden gestart.

Als het probleem zich blijft voordoen, raadpleegt u de sectie Probleemoplossing.

V: Wat kan ik doen als POA een waarschuwingsstatus heeft?

A: Controleer of een statusrapport dat is gepost op basis van de toepassing, de hoofdoorzaak aangeeft. Meestal bevat de waarschuwing details van het probleem. Als het probleem tijdelijk is, wordt verwacht dat de toepassing automatisch wordt hersteld.

V: Wat kan ik doen als mijn cluster niet in orde is en ik een urgente update van het besturingssysteem moet uitvoeren?

A: POA installeert geen updates terwijl het cluster niet in orde is. Probeer uw cluster in goede staat te brengen om de blokkering van de POA-werkstroom op te heffen.

V: Moet ik TaskApprovalPolicy instellen als NodeWise of UpgradeDomainWise voor mijn cluster?

A: De instelling UpgradeDomainWise versnelt het algehele clusterherstel door alle knooppunten die deel uitmaken van een updatedomein parallel te patchen. Tijdens het proces zijn knooppunten die deel uitmaken van een volledig updatedomein niet beschikbaar (met de status Uitgeschakeld).

Met de instelling 'NodeWise' wordt daarentegen slechts één knooppunt tegelijk gepatcht, wat betekent dat het uitvoeren van algemene clusterpatches langer kan duren. Maximaal één knooppunt is echter niet beschikbaar (met de status Uitgeschakeld ) tijdens het patchproces.

Als uw cluster het uitvoeren van een N-1 aantal updatedomeinen tijdens de patchcyclus kan tolereren (waarbij N het totale aantal updatedomeinen in uw cluster is), kunt u het beleid instellen op UpgradeDomainWise. Anders stelt u deze in op NodeWise.

V: Hoeveel tijd kost het om een knooppunt te patchen?

A: Het patchen van een knooppunt kan minuten duren (bijvoorbeeld Windows Defender definitie-updates) tot uren (bijvoorbeeld cumulatieve Windows-updates). De tijd die nodig is om een knooppunt te patchen, is voornamelijk afhankelijk van:

• De grootte van de updates.
• Het aantal updates dat moet worden toegepast in een patchvenster.
• De tijd die nodig is om de updates te installeren, het knooppunt opnieuw op te starten (indien nodig) en de installatiestappen na het opnieuw opstarten te voltooien.
• De prestaties van de VM of machine en de netwerkomstandigheden.

V: Hoe lang duurt het om een volledig cluster te patchen?

A: De tijd die nodig is om een volledig cluster te patchen, is afhankelijk van:

• De tijd die nodig is om een knooppunt te patchen.

• Het beleid van de Coördinatordienst. Het standaardbeleid NodeWise resulteert in het patchen van slechts één knooppunt tegelijk, een benadering die langzamer is dan het gebruik van 'UpgradeDomainWise'.

  Bijvoorbeeld: als het ongeveer 1 uur duurt voordat een knooppunt is gepatcht, is voor het patchen van een cluster met 20 knooppunten (hetzelfde type knooppunt) met 5 updatedomeinen, elk met vier knooppunten, vereist:

  • Voor 'NodeWise': ~20 uur.
  • Voor UpgradeDomainWise: ~5 uur.

• De clusterbelasting. Voor elke patchbewerking moet de workload van de klant worden verplaatst naar andere beschikbare knooppunten in het cluster. Een knooppunt dat wordt gepatcht, heeft gedurende deze periode de status Uitschakelen. Als het cluster bijna een piekbelasting heeft, duurt het uitschakelen langer. Daarom kan het algehele patchproces traag lijken te zijn in dergelijke stressomstandigheden.

• Clusterstatusfouten tijdens het patchen. Elke verslechtering van de status van het cluster zou het patchproces onderbreken. Dit probleem zou de totale tijd die nodig is om het hele cluster te patchen, nog verder uitbreiden.

V: Waarom zie ik enkele updates in de Windows Update resultaten die zijn verkregen via REST API, maar niet onder de Windows Update geschiedenis op de computer?

A: Sommige productupdates worden alleen weergegeven in hun eigen update- of patchgeschiedenis. Windows Defender updates worden bijvoorbeeld wel of niet weergegeven in Windows Update geschiedenis op Windows Server 2016.

V: Kan POA worden gebruikt voor het patchen van mijn ontwikkelcluster (cluster met één knooppunt)?

A: Nee, POA kan niet worden gebruikt om een cluster met één knooppunt te patchen. Deze beperking is standaard, omdat Service Fabric-systeemservices of andere klant-apps downtime met zich meebrengt. Daarom zouden reparatietaken voor patches nooit worden goedgekeurd door Repair Manager.

V: Hoe kan ik clusterknooppunten in Linux patchen?

A: Zie Automatische upgrades van azure-installatiekopieën voor virtuele-machineschaalsets voor meer informatie over het organiseren van updates in Linux.

V: Waarom duurt de updatecyclus zo lang?

A: Voer een query uit naar de JSON met het resultaat, voer de updatecyclus voor alle knooppunten in en vervolgens kunt u proberen de tijd te achterhalen die nodig is voor de installatie van de update op elk knooppunt met behulp van OperationStartTime en OperationTime (OperationCompletionTime).

Als er een groot tijdvenster is waarin geen update wordt uitgevoerd, heeft het cluster mogelijk een foutstatus en kan Repair Manager daarom geen POA-hersteltaken goedkeuren. Als de installatie van de update op een knooppunt lang duurt, is dat knooppunt mogelijk al een tijdje niet bijgewerkt. Veel updates wachten mogelijk op installatie, wat kan leiden tot vertragingen.

Het kan ook zijn dat patching van knooppunten is geblokkeerd omdat deze is vastgelopen in de status Uitschakelen . Dit gebeurt meestal omdat het uitschakelen van het knooppunt kan leiden tot situaties met quorum of gegevensverlies.

V: Waarom moet het knooppunt worden uitgeschakeld wanneer poA het patcht?

A: POA schakelt het knooppunt uit met de intentie Opnieuw opstarten , waardoor alle Service Fabric-services die op het knooppunt worden uitgevoerd, worden gestopt of opnieuw worden verplaatst. POA doet dit om ervoor te zorgen dat toepassingen geen combinatie van nieuwe en oude DLL's gebruiken. Daarom raden we u aan een knooppunt niet te patchen zonder het uit te schakelen.

V: Wat is het maximum aantal knooppunten dat kan worden bijgewerkt met behulp van POA?

A: POA maakt gebruik van Service Fabric Repair Manager om reparatietaken te maken voor knooppunten voor updates. Er kunnen echter niet meer dan 250 reparatietaken tegelijk aanwezig zijn. Momenteel maakt POA hersteltaken voor elk knooppunt tegelijk, zodat POA niet meer dan 250 knooppunten in een cluster kan bijwerken.

Disclaimers

• POA accepteert namens de gebruiker de End-User gebruiksrechtovereenkomst voor Windows Update. De instelling kan eventueel worden uitgeschakeld in de configuratie van de toepassing.

• POA verzamelt telemetrie om gebruik en prestaties bij te houden. De telemetrie van de toepassing volgt de instelling van de telemetrie-instelling van de Service Fabric-runtime (deze is standaard ingeschakeld).

Problemen oplossen

Deze sectie bevat mogelijke oplossingen voor problemen met het patchen van knooppunten.

Een knooppunt komt niet terug naar de status Up

• Het knooppunt is mogelijk vastgelopen met de status Uitschakelen , omdat:

  • Er is een veiligheidscontrole in behandeling. Om deze situatie te verhelpen, moet u ervoor zorgen dat er voldoende knooppunten beschikbaar zijn met een goede status.

• Het knooppunt is mogelijk vastgelopen in de status Uitgeschakeld , omdat:

  • Deze is handmatig uitgeschakeld.
  • Deze is uitgeschakeld vanwege een lopende Azure-infrastructuurtaak.
  • Het is tijdelijk uitgeschakeld door POA om het knooppunt te patchen.

• Het knooppunt is mogelijk vastgelopen in een downstatus, omdat:

  • Het is handmatig in een downstatus geplaatst.
  • Deze wordt opnieuw opgestart (die kan worden geactiveerd door POA).
  • Er is sprake van een defecte VM of machine, of er zijn problemen met de netwerkverbinding.

Updates zijn overgeslagen op sommige knooppunten

POA probeert een Windows-update te installeren volgens het beleid voor opnieuw plannen. De service probeert het knooppunt te herstellen en de update over te slaan volgens het toepassingsbeleid.

In een dergelijk geval wordt een statusrapport op waarschuwingsniveau gegenereerd voor de Node Agent-service. Het Windows Update resultaat bevat ook de mogelijke reden voor de fout.

De status van het cluster krijgt een fout terwijl de update wordt geïnstalleerd

Een defecte Windows-update kan de status van een toepassing of cluster op een bepaald knooppunt of updatedomein omlaag brengen. POA stopt alle volgende Windows Update bewerking totdat het cluster weer in orde is.

Een beheerder moet tussenbeide komen en bepalen waarom de toepassing of het cluster beschadigd raakt vanwege Windows Update.

Opmerkingen bij de release van POA

Notitie

Voor POA-versies 1.4.0 en hoger kunt u releaseopmerkingen en -releases vinden op de releasepagina van de Patch Orchestration-toepassing op GitHub.

Versie 1.1.0

• Openbare release

Versie 1.1.1

• Er is een fout opgelost in SetupEntryPoint van NodeAgentService die de installatie van NodeAgentNTService verhinderde.

Versie 1.2.0

• Opgeloste fouten rond de werkstroom voor opnieuw opstarten van het systeem.
• Fout opgelost bij het maken van RM-taken, waardoor de statuscontrole tijdens het voorbereiden van hersteltaken niet is uitgevoerd zoals verwacht.
• De opstartmodus voor Windows-service POANodeSvc is gewijzigd van automatisch in vertraagd automatisch.

Versie 1.2.1

• Fout opgelost in werkstroom voor omlaag schalen van clusters. Logica voor garbagecollection geïntroduceerd voor POA-hersteltaken die behoren tot niet-bestaande knooppunten.

Versie 1.2.2

• Diverse oplossingen voor fouten.
• Binaire bestanden zijn nu ondertekend.
• Sfpkg-koppeling toegevoegd voor de toepassing.

Versie 1.3.0

• Als u InstallWindowsOSOnlyUpdates instelt op false, worden nu alle beschikbare updates geïnstalleerd.
• De logica voor het uitschakelen van automatische updates is gewijzigd. Hiermee wordt een fout opgelost waarbij automatische updates niet werden uitgeschakeld op Server 2016 en hoger.
• Geparameteriseerde plaatsingsbeperking voor beide microservices van POA voor geavanceerde gebruiksvoorbeelden.

Versie 1.3.1

• Regressie herstellen waarbij POA 1.3.0 niet werkt op Windows Server 2012 R2 of eerder vanwege een fout bij het uitschakelen van automatische updates.
• Fout opgelost waarbij de configuratie van InstallWindowsOSOnlyUpdates altijd wordt gekozen als True.
• De standaardwaarde van InstallWindowsOSOnlyUpdates wordt gewijzigd in False.

Versie 1.3.2

• Een probleem oplossen dat van invloed is op de levenscyclus van patches op een knooppunt, als er knooppunten zijn met een naam die een subset is van de naam van het huidige knooppunt. Voor dergelijke knooppunten is het mogelijk dat patching is gemist of dat opnieuw opstarten in behandeling is.