Patchindelingstoepassing gebruiken
Belangrijk
Vanaf 30 april 2019 wordt patchindelingstoepassing 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 Azure Service Fabric Repair Manager-service, waarmee op configuratie gebaseerde patchplanning voor niet-Door Azure gehoste clusters mogelijk is. POA is niet vereist voor niet-Azure-gehoste clusters, maar het plannen van patchinstallatie per updatedomein is vereist voor het patchen van Service Fabric-clusterhosts zonder uitvaltijd.
POA is een Service Fabric-toepassing die het patchen van besturingssystemen op een Service Fabric-cluster automatiseert zonder uitvaltijd.
POA biedt de volgende functies:
Automatische installatie van besturingssysteemupdates. Updates van besturingssystemen worden automatisch gedownload en geïnstalleerd. Clusterknooppunten worden indien nodig opnieuw opgestart zonder dat er downtime van het cluster is opgetreden.
Clusterbewuste patching en statusintegratie. Terwijl POA updates toepast, wordt de status van de clusterknooppunten bewaakt. Clusterknooppunten worden één knooppunt tegelijk bijgewerkt of één updatedomein tegelijk. Als de status van het cluster uitvalt vanwege het patchproces, wordt patching gestopt om te voorkomen dat het probleem verergert.
Interne details van POA
POA bestaat uit de volgende subonderdelen:
Coördinatorservice: Deze stateful service is verantwoordelijk voor:
- De Windows Update-taak in het hele cluster coördineren.
- Het resultaat van voltooide Windows Update-bewerkingen opslaan.
Knooppuntagentservice: deze stateless service wordt uitgevoerd op alle Service Fabric-clusterknooppunten. De service is verantwoordelijk voor:
- Bootstrapping van de Node Agent NTService.
- De NTService van de Node Agent bewaken.
Node Agent NTService: deze Windows NT-service wordt uitgevoerd op 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.
- Windows-updates downloaden en installeren op basis van het beleid dat de gebruiker heeft opgegeven.
- Start de installatie van de computer na windows-updates opnieuw op.
- Upload de resultaten van Windows-updates naar de coördinatorservice.
- Statusrapporten rapporteren als een bewerking is mislukt nadat alle nieuwe pogingen zijn uitgeput.
Notitie
POA maakt gebruik van de Service Fabric Repair Manager-service om het knooppunt uit te schakelen of in te schakelen en statuscontroles uit te voeren. Met de hersteltaak die door POA is gemaakt, wordt de voortgang van Windows Update voor elk knooppunt bijgehouden.
Vereisten
Notitie
De vereiste minimale .NET Framework-versie is 4.6.
De Repair Manager-service inschakelen (als deze nog niet wordt uitgevoerd)
Voor POA moet de Repair Manager-service zijn ingeschakeld op het cluster.
Azure-clusters
Voor Azure-clusters in de silver-duurzaamheidslaag is de Repair Manager-service standaard ingeschakeld. Azure-clusters in de gold-duurzaamheidslaag kunnen de Repair Manager-service al dan niet hebben ingeschakeld, afhankelijk van wanneer deze clusters zijn gemaakt. Azure-clusters in de bronzen duurzaamheidslaag hebben standaard niet de Repair Manager-service 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 Azure Portal wanneer u het cluster instelt. Wanneer u het cluster configureert, selecteert u de optie Herstelbeheer 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 Azure Resource Manager-implementatiemodelsjabloon maken.
Ga als volgt te werk om de Repair Manager-service in te schakelen met behulp van de azure Resource Manager-implementatiemodelsjabloon:
Controleer of
apiVersion
deze is ingesteld op 2017-07-01-preview voor de resource Microsoft.ServiceFabric/clusters . Als dit anders is, moet u bijwerkenapiVersion
naar 2017-07-01-preview of hoger:{ "apiVersion": "2017-07-01-preview", "type": "Microsoft.ServiceFabric/clusters", "name": "[parameters('clusterName')]", "location": "[parameters('clusterLocation')]", ... }
Schakel de Repair Manager-service in door de volgende
addonFeatures
sectie na defabricSettings
sectie toe te voegen:"fabricSettings": [ ... ], "addonFeatures": [ "RepairManager" ],
Nadat u de clustersjabloon met deze wijzigingen hebt bijgewerkt, past u deze toe en laat u de update voltooien. U kunt nu de Repair Manager-service zien die in uw cluster wordt uitgevoerd. Het 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:
Controleer of
apiVersion
in algemene clusterconfiguraties is ingesteld op 04-2017 of hoger, zoals hier wordt weergegeven:{ "name": "SampleCluster", "clusterConfigurationVersion": "1.0.0", "apiVersion": "04-2017", ... }
Schakel de Repair Manager-service in door de volgende
addonFeatures
sectie na defabricSettings
sectie toe te voegen, zoals hier wordt weergegeven:"fabricSettings": [ ... ], "addonFeatures": [ "RepairManager" ],
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 voor alle knooppunten configureren
Automatische Windows-updates kunnen leiden tot verlies van beschikbaarheid, 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 groepsbeleid, raden we u aan om het Windows Update-beleid expliciet in te stellen op Waarschuwen voordat downloaden.
Het toepassingspakket downloaden
Als u het toepassingspakket wilt downloaden, gaat u naar de releasepagina van de Patch Orchestration-toepassing 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 deze op te geven ApplicationParameter
aan de Start-ServiceFabricApplicationUpgrade
of New-ServiceFabricApplication
cmdlets.
Parameter | Type | DETAILS |
---|---|---|
MaxResultsToCache | Lang | 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 voor de afgelopen drie maanden moeten worden opgeslagen. |
TaskApprovalPolicy | Opsomming { NodeWise, UpgradeDomainWise } |
TaskApprovalPolicy geeft het beleid aan dat door de coördinatorservice moet worden gebruikt voor het installeren van Windows-updates op de Service Fabric-clusterknooppunten. De toegestane waarden zijn: NodeWise: Windows-updates worden één knooppunt tegelijk geïnstalleerd. UpgradeDomainWise: Windows-updates worden één updatedomein tegelijk geïnstalleerd. (Alle knooppunten die deel uitmaken van een updatedomein kunnen maximaal worden gebruikt voor een Windows-update.) Zie de sectie Veelgestelde vragen om te bepalen welk beleid het meest geschikt is voor uw cluster. |
LogsDiskQuotaInMB | Lang (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 | Booleaanse waarde (standaard: onwaar) |
Gebruik deze vlag om te bepalen welke updates moeten worden gedownload en geïnstalleerd. De volgende waarden zijn toegestaan true: hiermee worden alleen updates van het Windows-besturingssysteem geïnstalleerd. 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 tussen 1 en 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, HH:MM:SS (bijvoorbeeld: MonthlyByWeekAndDay, 2, Friday, 21:00:00 geeft 19:00 UUR UTC aan op vrijdag van de 2e 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 gebruiksrechtovereenkomst voor Windows Update namens de eigenaar van de computer. |
Tip
Als u wilt dat Windows-updates onmiddellijk worden uitgevoerd, stelt u WUFrequency
deze in ten opzichte van de implementatietijd van de toepassing. Stel dat u een testcluster met vijf knooppunten hebt en de app rond 17:00 uur UTC wilt 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
Voltooi alle vereiste stappen om het cluster voor te bereiden.
Implementeer POA zoals elke andere Service Fabric-app. Zie Toepassingen implementeren en verwijderen met behulp van PowerShell om deze te implementeren met behulp van PowerShell.
Als u de toepassing wilt configureren op het moment van de implementatie, geeft u de
ApplicationParameter
New-ServiceFabricApplication
cmdlet door. Voor uw gemak hebben we het script Deploy.ps1 samen met de toepassing opgegeven. Het script gebruiken:- Maak verbinding met een Service Fabric-cluster met behulp van
Connect-ServiceFabricCluster
. - Voer het PowerShell-script Deploy.ps1 uit met de juiste
ApplicationParameter
waarde.
- Maak verbinding met een Service Fabric-cluster met behulp van
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 de 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 script Undeploy.ps1 samen met de toepassing opgegeven. Het script gebruiken:
- Maak verbinding met een Service Fabric-cluster met behulp van
Connect-ServiceFabricCluster
. - Voer het PowerShell-script Undeploy.ps1 uit.
Notitie
Bewaar het script en de toepassingsmap PatchOrchestrationApplication in dezelfde map.
De Resultaten van Windows Update weergeven
POA maakt REST API's beschikbaar om de historische resultaten voor gebruikers weer te geven. 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 van de installatiebewerking voor een afzonderlijke update aan. |
OperationType | 1 - Installatie 0 - Zoeken en downloaden |
Installatie is standaard het enige OperationType dat in de resultaten wordt weergegeven. |
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 is vereist false - opnieuw opstarten is niet vereist |
Geeft aan of opnieuw opstarten is vereist om de installatie van updates te voltooien. |
OperationStartTime | Datum en tijd | Geeft het tijdstip aan waarop de bewerking (Download/Installatie) is gestart. |
OperationTime | Datum en tijd | Geeft het tijdstip aan waarop de bewerking (Downloaden/installatie) 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 JSON leeg.
Meld u aan bij het cluster om query's uit te voeren op windows Update-resultaten. Zoek het replica-IP-adres voor het primaire adres van de coördinatorservice uit 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.
Volg de instructies in Reverse Proxy in Azure Service Fabric om de omgekeerde proxy in te schakelen op het cluster.
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 en status-gebeurtenissen
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 gemarkeerde, zelfdiagnose verbeteringen wilt krijgen, moet POA-versie 1.4.0 of hoger zijn geïnstalleerd.
De Node Agent NTService maakt reparatietaken voor het installeren van updates op de knooppunten. Elke taak wordt vervolgens voorbereid door de coördinatorservice volgens het goedkeuringsbeleid voor taken. Ten slotte worden de voorbereide taken goedgekeurd door Repair Manager, die geen taak goedkeurt als het cluster een slechte status heeft.
Als u wilt weten hoe updates verdergaan op een knooppunt, gaan we stapsgewijs aan de slag:
NodeAgentNTService, uitgevoerd op elk knooppunt, zoekt op het geplande tijdstip naar beschikbare Windows-updates. Als er updates beschikbaar zijn, worden deze gedownload op het knooppunt.
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 weergeven met behulp van de get-ServiceFabricRepairTask-cmdlet of met behulp van SFX in de sectie met knooppuntdetails. Nadat de reparatietaak is gemaakt, wordt deze snel verplaatst naar de status Geclaimd.
De coördinatorservice zoekt periodiek naar reparatietaken in 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 reparatietaak is in de status Voorbereiden, Goedgekeurd, Uitvoeren of Herstellen .
In het geval van UpgradeWise TaskApprovalPolicy zijn er ook taken in de voorgaande statussen alleen voor knooppunten die deel uitmaken van hetzelfde updatedomein. 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 posten 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:
Nadat het knooppunt is uitgeschakeld, wordt de hersteltaak verplaatst naar de uitvoeringsstatus .
Notitie
Een knooppunt dat is vastgelopen in de status Uitgeschakeld , kan een nieuwe hersteltaak blokkeren, waardoor de patchbewerking op het cluster wordt gestopt.
Wanneer de hersteltaak de uitvoeringsstatus heeft, wordt de patchinstallatie 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 kan worden uitgevoerd. De reparatietaak 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 poanode_2-knooppunt en dat de installatie wordt uitgevoerd wanneer de taak wordt verplaatst naar de uitvoeringsstatus .
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 zijn gevonden, meldt u zich aan bij uw virtuele machine (VM) of VM's en leert u er meer over met behulp van Windows-gebeurtenislogboeken. De eerder genoemde hersteltaak kan alleen bestaan in de volgende substates van de uitvoerder:
ExecutorSubState Beschrijving Geen=1 Impliceert dat er geen doorlopende bewerking op het knooppunt is uitgevoerd. De status is mogelijk in overgang. DownloadCompleted=2 Impliceert dat de downloadbewerking is voltooid met succes, 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 status van de uitvoering van de reparatietaak. InstallationCompleted=5 Impliceert dat de installatie is voltooid met succes, gedeeltelijk succes 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 is voltooid. RestartCompleted=8 Impliceert dat het opnieuw opstarten is voltooid. OperationCompleted=9 De Windows Update-bewerking is voltooid. OperationAborted=10 Impliceert dat de Windows Update-bewerking is afgebroken. In POA-versies 1.4.0 en hoger wordt een gebeurtenis met de eigenschap WUOperationStatus-[NodeName] geplaatst op NodeAgentService wanneer de volgende poging tot het downloaden en installeren van de Windows-updates 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 maakt gebruik van de volgende vaste provider-id's voor het vastleggen van gebeurtenissen via gebeurtenisbron:
- e39b723c-590c-4090-abb0-11e3e6616346
- fc0028ff-bfdc-499f-80dc-ed922c52c5e9
- 24afa313-0d3b-4c7c-b485-1047fd964b60
- 05dc046c-60e9-4ef7-965e-91660adffa68
Statusrapporten
POA publiceert in de volgende scenario's ook statusrapporten op basis van de knooppuntagentservice of de coördinatorservice:
De NTService van de knooppuntagent is offline
Als de NTService van de knooppuntagent niet beschikbaar is op een knooppunt, wordt er een statusrapport op waarschuwingsniveau gegenereerd op basis van de knooppuntagentservice.
De Repair Manager-service is niet ingeschakeld
Als de Repair Manager-service niet op het cluster wordt gevonden, 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 schakelt POA knooppunten uit of start deze opnieuw op, wat tijdelijk kan leiden tot een beschadigd cluster.
Afhankelijk van het beleid van de toepassing kan één knooppunt omlaag gaan tijdens een patchbewerking of kan een volledig updatedomein in één keer omlaag gaan.
Na het einde van de installatie van Windows-updates worden de knooppunten opnieuw opgestart.
In het volgende voorbeeld is het cluster tijdelijk naar een foutstatus gegaan omdat er twee knooppunten zijn uitgevallen 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 dringende update van het besturingssysteem moet uitvoeren?
A: POA installeert geen updates terwijl het cluster niet in orde is. Probeer uw cluster in orde te brengen om de POA-werkstroom te deblokkeren.
V: Moet ik TaskApprovalPolicy instellen als NodeWise of UpgradeDomainWise voor mijn cluster?
A: De instelling UpgradeDomainWise versnelt het algehele clusterherstel door parallel alle knooppunten die deel uitmaken van een updatedomein te patchen. Tijdens het proces zijn knooppunten die deel uitmaken van een volledig updatedomein niet beschikbaar (met de status Uitgeschakeld).
Daarentegen wordt met de instelling NodeWise slechts één knooppunt tegelijk gepatcht, wat betekent dat het algemene patchen van clusters langer kan duren. Tijdens het patchproces is echter slechts één knooppunt maximaal niet beschikbaar (in uitgeschakelde status).
Als uw cluster het uitvoeren op een N-1-aantal updatedomeinen tijdens de patchcyclus tolereert (waarbij N het totale aantal updatedomeinen op uw cluster is), kunt u het beleid instellen als '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 enkele 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 netwerkvoorwaarden.
V: Hoe lang duurt het om een hele cluster te patchen?
A: De tijd die nodig is om een hele 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 'UpgradeDomainWise'.
Als een knooppunt bijvoorbeeld ongeveer 1 uur moet worden gepatcht, moet u een cluster met 20 knooppunten (hetzelfde type knooppunt) met 5 updatedomeinen patchen, elk met 4 knooppunten:
- 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 de status Uitschakelen gedurende deze periode. Als het cluster bijna piekbelasting heeft, duurt het uitschakelen langer. Daarom lijkt het algehele patchproces in dergelijke gestrest omstandigheden traag te zijn.
Clusterstatusfouten tijdens het patchen. Elke verslechtering van de status van het cluster zou het patchproces onderbreken. Dit probleem wordt toegevoegd aan de totale tijd die nodig is om het hele cluster te patchen.
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 de geschiedenis van Windows Update op Windows Server 2016.
V: Kan POA worden gebruikt om mijn ontwikkelcluster (cluster met één knooppunt) te patchen?
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 zouden veroorzaken. Daarom worden patchtaken nooit goedgekeurd door Repair Manager.
V: Hoe kan ik patchclusterknooppunten in Linux?
A: Voor meer informatie over het organiseren van updates in Linux, raadpleegt u de automatische upgrades van installatiekopieën van het besturingssysteem van azure virtuele-machineschaalsets.
V: Waarom duurt de updatecyclus zo lang?
A: Voer een query uit voor 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 plaatsvindt, heeft het cluster mogelijk een foutstatus en kan Repair Manager dus geen POA-hersteltaken goedkeuren. Als de installatie van de update lang duurt op een knooppunt, is dat knooppunt mogelijk al een tijdje niet bijgewerkt. Veel updates zijn mogelijk in behandeling bij de installatie, wat kan leiden tot vertragingen.
Het kan ook zijn dat knooppuntpatching wordt geblokkeerd omdat het vastloopt in de status Uitschakelen. Dit gebeurt meestal omdat het uitschakelen van het knooppunt kan leiden tot quorum- of gegevensverliessituaties.
V: Waarom moet het knooppunt worden uitgeschakeld wanneer POA deze 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, dus we raden 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. Op dit moment maakt POA reparatietaken voor elk knooppunt tegelijk, zodat POA niet meer dan 250 knooppunten in een cluster kan bijwerken.
Disclaimers
POA accepteert de gebruiksrechtovereenkomst voor Windows Update namens de gebruiker. De instelling kan eventueel worden uitgeschakeld in de configuratie van de toepassing.
POA verzamelt telemetrie om het gebruik en de prestaties bij te houden. De telemetrie van de toepassing volgt de instelling van de telemetrie-instelling van de Service Fabric-runtime (die standaard is ingeschakeld).
Probleemoplossing
Deze sectie bevat mogelijke oplossingen voor het oplossen van problemen met patching-knooppunten.
Een knooppunt komt niet terug naar de status
Het knooppunt is mogelijk vastgelopen in 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 in een goede status.
Het knooppunt is mogelijk vastgelopen in de status Uitgeschakeld omdat:
- Het 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 werd handmatig in een downstatus geplaatst.
- Het wordt opnieuw opgestart (die mogelijk wordt geactiveerd door POA).
- Er is een defecte VM of computer, 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 slaat de update over volgens het toepassingsbeleid.
In dat geval wordt een statusrapport op waarschuwingsniveau gegenereerd op basis van de Node Agent-service. Het Windows Update-resultaat bevat ook de mogelijke reden voor de fout.
De status van het cluster treedt op 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-bewerkingen totdat het cluster weer in orde is.
Een beheerder moet ingrijpen en bepalen waarom de toepassing of het cluster niet in orde is geworden vanwege Windows Update.
Opmerkingen bij de release van POA
Notitie
Voor POA-versies 1.4.0 en hoger vindt u releaseopmerkingen en releases 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 of NodeAgentService die de installatie van NodeAgentNTService verhinderde.
Versie 1.2.0
- Opgeloste problemen met betrekking tot de werkstroom voor opnieuw opstarten van het systeem.
- Er is een fout opgelost bij het maken van RM-taken omdat de statuscontrole tijdens het voorbereiden van reparatietaken niet werd uitgevoerd zoals verwacht.
- De opstartmodus voor de Windows-service POANodeSvc is gewijzigd van automatisch naar vertraagd auto.
Versie 1.2.1
- Probleem opgelost in werkstroom voor omlaag schalen van clusters. Er is garbagecollectionlogica geïntroduceerd voor POA-hersteltaken die behoren tot niet-bestaande knooppunten.
Versie 1.2.2
- Diverse bugfixes.
- Binaire bestanden zijn nu ondertekend.
- Er is een 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.
- Beperking voor geparameteriseerde plaatsing voor zowel de 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.
- Er is een fout opgelost waarbij de configuratie van InstallWindowsOSOnlyUpdates altijd als Waar wordt gekozen.
- 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 van de huidige knooppuntnaam is. Voor dergelijke knooppunten is het mogelijk dat patching is gemist of dat opnieuw opstarten in behandeling is.