Korzystanie z aplikacji orkiestracji poprawek

Ważne

Od 30 kwietnia 2019 r. aplikacja Patch Orchestration Application w wersji 1.2.* nie jest już obsługiwana. Pamiętaj o uaktualnieniu do najnowszej wersji.

Patch Orchestration Application (POA) to otoka usługi Azure Service Fabric Repair Manager, która umożliwia planowanie poprawek systemu operacyjnego opartych na konfiguracji dla klastrów hostowanych na platformie Azure. Weryfikacja koncepcji nie jest wymagana w przypadku klastrów hostowanych poza platformą Azure, ale planowanie instalacji poprawek przez domenę aktualizacji jest wymagane do stosowania poprawek hostów klastra usługi Service Fabric bez ponoszenia przestojów.

PoA to aplikacja usługi Service Fabric, która automatyzuje stosowanie poprawek systemu operacyjnego w klastrze usługi Service Fabric bez ponoszenia przestojów.

Funkcja weryfikacji koncepcji zapewnia następujące funkcje:

• Automatyczna instalacja aktualizacji systemu operacyjnego. Aktualizacje systemu operacyjnego są automatycznie pobierane i instalowane. Węzły klastra są uruchamiane ponownie w razie potrzeby bez ponoszenia przestojów klastra.

• Integracja poprawek i kondycji z obsługą klastra. Podczas stosowania aktualizacji poA monitoruje kondycję węzłów klastra. Węzły klastra są aktualizowane jeden węzeł jednocześnie lub jedna domena aktualizacji jednocześnie. Jeśli kondycja klastra ulegnie awarii z powodu procesu stosowania poprawek, stosowanie poprawek zostanie zatrzymane, aby zapobiec pogorszeniu problemu.

Wewnętrzne szczegóły weryfikacji koncepcji

PoA składa się z następujących podskładników:

• Usługa koordynatora: Ta usługa stanowa jest odpowiedzialna za:

  • Koordynowanie zadania usługi Windows Update w całym klastrze.
  • Przechowywanie wyniku zakończonych operacji usługi Windows Update.

• Usługa agenta węzła: ta bezstanowa usługa jest uruchamiana we wszystkich węzłach klastra usługi Service Fabric. Usługa jest odpowiedzialna za:

  • Bootstrapping the Node Agent NTService.
  • Monitorowanie usługi NTService agenta węzła.

• Node Agent NTService: ta usługa Systemu Windows NT działa na wyższym poziomie uprawnień (SYSTEM). Z kolei usługa agenta węzła i usługa koordynatora działają z uprawnieniami niższego poziomu (USŁUGA SIECIOWA). Usługa jest odpowiedzialna za wykonywanie następujących zadań usługi Windows Update na wszystkich węzłach klastra:

  • Wyłączanie automatycznych aktualizacji systemu Windows w węźle.
  • Pobieranie i instalowanie aktualizacji systemu Windows zgodnie z zasadami podanymi przez użytkownika.
  • Ponowne uruchomienie komputera po instalacji aktualizacji systemu Windows.
  • Przekazywanie wyników aktualizacji systemu Windows do usługi koordynatora.
  • Raportowanie raportów dotyczących kondycji, jeśli operacja nie powiodła się po wyczerpaniu wszystkich ponownych prób.

Uwaga

PoA używa usługi Service Fabric Repair Manager do wyłączenia lub włączenia węzła i przeprowadzania kontroli kondycji. Zadanie naprawy utworzone przez poA śledzi postęp usługi Windows Update dla każdego węzła.

Wymagania wstępne

Uwaga

Wymagana minimalna wersja programu .NET Framework to 4.6.

Włącz usługę Repair Manager (jeśli nie jest jeszcze uruchomiona)

PoA wymaga włączenia usługi Menedżer naprawy w klastrze.

Klastry platformy Azure

Klastry platformy Azure w warstwie trwałości srebra mają domyślnie włączoną usługę Repair Manager. Klastry platformy Azure w warstwie trwałości złota mogą lub nie mają włączonej usługi Menedżer naprawy, w zależności od tego, kiedy te klastry zostały utworzone. Klastry platformy Azure w warstwie trwałości z brązu domyślnie nie mają włączonej usługi Repair Manager. Jeśli usługa jest już włączona, możesz ją wyświetlić w sekcji usług systemowych w narzędziu Service Fabric Explorer.

Azure Portal

Menedżer naprawy można włączyć w witrynie Azure Portal podczas konfigurowania klastra. Podczas konfigurowania klastra wybierz opcję Uwzględnij menedżera naprawy w obszarze Funkcje dodatku.

Model wdrażania usługi Azure Resource Manager

Alternatywnie możesz użyć modelu wdrażania usługi Azure Resource Manager, aby włączyć usługę Repair Manager w nowych i istniejących klastrach usługi Service Fabric. Pobierz szablon klastra, który chcesz wdrożyć. Możesz użyć przykładowych szablonów lub utworzyć niestandardowy szablon modelu wdrażania usługi Azure Resource Manager.

Aby włączyć usługę Repair Manager przy użyciu szablonu modelu wdrażania usługi Azure Resource Manager, wykonaj następujące czynności:

1. Upewnij się, że apiVersion dla zasobu Microsoft.ServiceFabric/clusters ustawiono wartość 2017-07-01-preview. Jeśli jest inaczej, musisz zaktualizować apiVersion do wersji 2017-07-01-preview lub nowszej:

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

2. Włącz usługę Repair Manager, dodając następującą addonFeatures sekcję fabricSettings po sekcji:

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

3. Po zaktualizowaniu szablonu klastra za pomocą tych zmian zastosuj je i pozwól na zakończenie aktualizacji. Teraz możesz wyświetlić usługę Repair Manager uruchomioną w klastrze. Jest ona nazywana fabric:/System/RepairManagerService w sekcji usług systemowych w narzędziu Service Fabric Explorer.

Autonomiczne klastry lokalne

Aby włączyć usługę Repair Manager w nowym lub istniejącym klastrze usługi Service Fabric, możesz użyć ustawień konfiguracji dla autonomicznego klastra systemu Windows.

Aby włączyć usługę Repair Manager:

1. Upewnij się, że apiVersion w obszarze Ogólne konfiguracje klastra ustawiono wartość 04-2017 lub nowszą, jak pokazano poniżej:

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

2. Włącz usługę Repair Manager, dodając następującą addonFeatures sekcję po fabricSettings sekcji, jak pokazano poniżej:

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

3. Zaktualizuj manifest klastra za pomocą tych zmian, używając zaktualizowanego manifestu klastra, utwórz nowy klaster lub uaktualnij konfigurację klastra.

   Po uruchomieniu klastra ze zaktualizowanym manifestem klastra możesz zobaczyć usługę Repair Manager uruchomioną w klastrze. Jest ona nazywana fabric:/System/RepairManagerService i znajduje się w sekcji usług systemowych w narzędziu Service Fabric Explorer.

Konfigurowanie aktualizacji systemu Windows dla wszystkich węzłów

Automatyczne aktualizacje systemu Windows mogą prowadzić do utraty dostępności, ponieważ wiele węzłów klastra może zostać uruchomionych ponownie w tym samym czasie. Domyślnie poA próbuje wyłączyć automatyczne aktualizacje systemu Windows w każdym węźle klastra. Jeśli jednak ustawienia są zarządzane przez administratora lub zasady grupy, zalecamy jawne ustawienie zasad usługi Windows Update na "Powiadom przed pobraniem".

Pobieranie pakietu aplikacji

Aby pobrać pakiet aplikacji, przejdź do strony wydania aplikacji Patch Orchestration Application w witrynie GitHub.

Konfigurowanie zachowania weryfikacji koncepcji

Zachowanie weryfikacji koncepcji można skonfigurować w celu spełnienia Twoich potrzeb. Zastąpij wartości domyślne, przekazując parametr aplikacji podczas tworzenia lub aktualizowania aplikacji. Parametry aplikacji można podać, określając ApplicationParameter polecenia Start-ServiceFabricApplicationUpgrade cmdlet lub New-ServiceFabricApplication .

Parametr	Type	Szczegóły
MaxResultsToCache	Długi	Maksymalna liczba wyników usługi Windows Update, które powinny być buforowane. Wartość domyślna to 3000, przy założeniu, że:   — Liczba węzłów wynosi 20.   — Liczba aktualizacji węzła miesięcznie wynosi 5.   - Liczba wyników na operację może wynosić 10.   - Wyniki z ostatnich trzech miesięcy powinny być przechowywane.
TaskApprovalPolicy	Wyliczenie { NodeWise, UpgradeDomainWise }	TaskApprovalPolicy wskazuje zasady, które mają być używane przez usługę koordynatora do instalowania aktualizacji systemu Windows w węzłach klastra usługi Service Fabric. Dozwolone wartości to: NodeWise: aktualizacje systemu Windows są instalowane po jednym węźle naraz. UpgradeDomainWise: aktualizacje systemu Windows są instalowane w jednej domenie aktualizacji naraz. (W większości wszystkie węzły należące do domeny aktualizacji mogą przejść do aktualizacji systemu Windows). Aby ułatwić podjęcie decyzji, które zasady najlepiej nadają się do klastra, zobacz sekcję Często zadawane pytania .
LogsDiskQuotaInMB	Długi (Ustawienie domyślne: 1024)	Maksymalny rozmiar dzienników aplikacji orkiestracji poprawek w MB, który można utrwalać lokalnie w węzłach.
WUQuery	string (Ustawienie domyślne: IsInstalled=0)	Zapytanie dotyczące pobierania aktualizacji systemu Windows. Aby uzyskać więcej informacji, zobacz WuQuery.
InstallWindowsOSOnlyUpdates	Wartość logiczna (wartość domyślna: false)	Ta flaga służy do kontrolowania, które aktualizacje mają być pobierane i instalowane. Dozwolone są następujące wartości true — instaluje tylko aktualizacje systemu operacyjnego Windows. false — instaluje wszystkie dostępne aktualizacje na maszynie.
WUOperationTimeOutInMinutes	Int (Wartość domyślna: 90)	Określa limit czasu dla dowolnej operacji usługi Windows Update (wyszukiwanie lub pobieranie lub instalowanie). Jeśli operacja nie zostanie ukończona w określonym przedziale czasu, zostanie przerwana.
WURescheduleCount	Int (Wartość domyślna: 5)	Maksymalna liczba ponownych prób ponownego uruchomienia usługi aktualizacji systemu Windows w przypadku trwałej awarii operacji.
WURescheduleTimeInMinutes	Int (Wartość domyślna: 30)	Interwał, w którym usługa zmienia harmonogram aktualizacji systemu Windows, jeśli awaria będzie się powtarzać.
WUFrequency	Ciąg rozdzielony przecinkami (wartość domyślna: Co tydzień, środa, 7:00:00)	Częstotliwość instalowania aktualizacji systemu Windows. Format i możliwe wartości to: - Monthly, DD, HH:MM:SS (przykład: Monthly, 5, 12:22:32). Dozwolone wartości dla pola DD (dzień) to liczby z zakresu od 1 do 28 i ostatnich. - Co tydzień, Dzień, HH:MM:SS (przykład: Co tydzień, wtorek, 12:22:32) - Codziennie, HH:MM:SS (przykład: Codziennie, 12:22:32) - MonthlyByWeekAndDay, Week, Day, HH:MM:SS (przykład: MonthlyByWeekAndDay, 2, piątek, 21:00:00 wskazuje 19:00 UTC w piątek drugiego tygodnia każdego miesiąca) - Brak wskazuje, że nie należy wykonywać aktualizacji systemu Windows. Czasy są w formacie UTC.
AcceptWindowsUpdateEula	Boolowski (Wartość domyślna: true)	Ustawiając tę flagę, aplikacja akceptuje umowę licencyjną użytkownika końcowego dla usługi Windows Update w imieniu właściciela maszyny.

Napiwek

Jeśli chcesz, aby aktualizacje systemu Windows były wykonywane natychmiast, ustaw wartość WUFrequency względem czasu wdrożenia aplikacji. Załóżmy na przykład, że masz klaster testowy z pięcioma węzłami i planujesz wdrożyć aplikację o około 17:00 czasu UTC. Jeśli zakładasz, że uaktualnienie lub wdrożenie aplikacji trwa co najwyżej 30 minut, ustaw wartość WUFrequency jako Codziennie, 17:30:00.

Wdrażanie weryfikacji koncepcji

1. Zakończ wszystkie kroki wymagań wstępnych, aby przygotować klaster.

2. Wdróż weryfikację koncepcji, podobnie jak dowolną inną aplikację usługi Service Fabric. Aby wdrożyć ją przy użyciu programu PowerShell, zobacz Wdrażanie i usuwanie aplikacji przy użyciu programu PowerShell.

3. Aby skonfigurować aplikację w czasie wdrażania, przekaż element ApplicationParameter do New-ServiceFabricApplication polecenia cmdlet . Dla Wygody udostępniliśmy skrypt Deploy.ps1 wraz z aplikacją. Aby użyć skryptu:

   • Nawiąż połączenie z klastrem usługi Service Fabric przy użyciu polecenia Connect-ServiceFabricCluster.
   • Wykonaj skrypt programu PowerShell Deploy.ps1 z odpowiednią ApplicationParameter wartością.

Uwaga

Zachowaj skrypt i folder aplikacji PatchOrchestrationApplication w tym samym katalogu.

Uaktualnianie weryfikacji koncepcji

Aby uaktualnić wersję weryfikacji koncepcji przy użyciu programu PowerShell, postępuj zgodnie z instrukcjami w temacie Uaktualnianie aplikacji usługi Service Fabric przy użyciu programu PowerShell.

Usuwanie weryfikacji koncepcji

Aby usunąć aplikację, postępuj zgodnie z instrukcjami w temacie Wdrażanie i usuwanie aplikacji przy użyciu programu PowerShell.

Dla Twojej wygody udostępniliśmy skrypt Undeploy.ps1 wraz z aplikacją. Aby użyć skryptu:

• Nawiąż połączenie z klastrem usługi Service Fabric przy użyciu polecenia Connect-ServiceFabricCluster.
• Wykonaj skrypt programu PowerShell Undeploy.ps1.

Uwaga

Zachowaj skrypt i folder aplikacji PatchOrchestrationApplication w tym samym katalogu.

Wyświetlanie wyników usługi Windows Update

PoA uwidacznia interfejsy API REST w celu wyświetlenia wyników historycznych dla użytkowników. Oto przykładowy kod JSON wyniku:

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

Pola JSON zostały opisane w poniższej tabeli:

Pole	Wartości	Szczegóły
OperationResult	0 — Powodzenie 1 — Powodzenie z błędami 2 — Niepowodzenie 3 — Przerwane 4 — Przerwane z przekroczeniem limitu czasu	Wskazuje wynik ogólnej operacji, która zwykle obejmuje instalację co najmniej jednej aktualizacji.
Kod wyniku	Tak samo jak OperacjaResult	To pole wskazuje wynik operacji instalacji dla pojedynczej aktualizacji.
OperationType	1 — Instalacja 0 — Wyszukiwanie i pobieranie	Domyślnie instalacja jest jedyną wartością OperationType wyświetlaną w wynikach.
WindowsUpdateQuery	Wartość domyślna to "IsInstalled=0"	Kwerenda usługi Windows Update, która została użyta do wyszukiwania aktualizacji. Aby uzyskać więcej informacji, zobacz WuQuery.
RebootRequired	true — wymagany był ponowny rozruch false — ponowne uruchomienie nie było wymagane	Wskazuje, czy ponowne uruchomienie było wymagane do ukończenia instalacji aktualizacji.
OperationStartTime	DateTime	Wskazuje czas rozpoczęcia operacji (Pobieranie/instalacja).
OperationTime	DateTime	Wskazuje czas, w którym operacja (Pobieranie/instalacja) została ukończona.
HResult	0 — Powodzenie inne — niepowodzenie	Wskazuje przyczynę niepowodzenia aktualizacji systemu Windows z identyfikatorem updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

Jeśli nie zaplanowano jeszcze żadnej aktualizacji, wynik JSON jest pusty.

Zaloguj się do klastra, aby wysłać zapytanie do wyników usługi Windows Update. Znajdź adres IP repliki dla adresu podstawowego usługi koordynatora i otwórz następujący adres URL w przeglądarce: http://< REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Punkt końcowy REST dla usługi koordynatora ma port dynamiczny. Aby sprawdzić dokładny adres URL, zapoznaj się z tematem Service Fabric Explorer. Na przykład wyniki są dostępne pod adresem http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Jeśli zwrotny serwer proxy jest włączony w klastrze, możesz również uzyskać dostęp do adresu URL spoza klastra.

Punkt końcowy, który należy trafić, to http://< SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

Aby włączyć zwrotny serwer proxy w klastrze, postępuj zgodnie z instrukcjami w temacie Zwrotny serwer proxy w usłudze Azure Service Fabric.

Ostrzeżenie

Po skonfigurowaniu zwrotnego serwera proxy wszystkie mikrousługi w klastrze, które uwidaczniają punkt końcowy HTTP, są adresowane spoza klastra.

Zdarzenia diagnostyki i kondycji

W tej sekcji omówiono sposób debugowania lub diagnozowania problemów z aktualizacjami poprawek za pośrednictwem weryfikacji koncepcji w klastrach usługi Service Fabric.

Uwaga

Aby uzyskać wiele z następujących wywołań, samodzielnych ulepszeń diagnostycznych, należy mieć zainstalowaną wersję POA w wersji 1.4.0 lub nowszej.

Agent węzła NTService tworzy zadania naprawy do instalowania aktualizacji w węzłach. Każde zadanie jest następnie przygotowywane przez usługę koordynatora zgodnie z zasadami zatwierdzania zadań. Na koniec przygotowane zadania są zatwierdzane przez Menedżera naprawy, co nie zatwierdza żadnego zadania, jeśli klaster jest w złej kondycji.

Aby zrozumieć, jak aktualizacje są kontynuowane w węźle, przejdźmy krok po kroku:

1. NodeAgentNTService, uruchomiona w każdym węźle, szuka dostępnych aktualizacji systemu Windows w zaplanowanym czasie. Jeśli aktualizacje są dostępne, pobiera je w węźle.

2. Po pobraniu aktualizacji agent NTService węzła tworzy odpowiednie zadanie naprawy dla węzła o nazwie POS___<unique_id>. Te zadania naprawy można wyświetlić przy użyciu polecenia cmdlet Get-ServiceFabricRepairTask lub narzędzia SFX w sekcji szczegółów węzła. Po utworzeniu zadania naprawy szybko przechodzi do stanu Oświadczenia.

3. Usługa koordynatora okresowo wyszukuje zadania naprawy w stanie Oświadczenia, a następnie aktualizuje je do przygotowania stanu na podstawie taskApprovalPolicy. Jeśli zadanie TaskApprovalPolicy jest skonfigurowane jako NodeWise, zadanie naprawy odpowiadające węzłowi jest przygotowane tylko wtedy, gdy żadne inne zadanie naprawy nie jest obecnie w stanie Przygotowywanie, Zatwierdzanie, Wykonywanie lub Przywracanie .

   Podobnie w przypadku elementu UpgradeWise TaskApprovalPolicy istnieją zadania w poprzednich stanach tylko dla węzłów należących do tej samej domeny aktualizacji. Po przeniesieniu zadania naprawy do stanu Przygotowywanie odpowiedni węzeł usługi Service Fabric zostanie wyłączony z intencją ustawioną na Uruchom ponownie.

   PoA w wersji 1.4.0 lub nowszej publikuje zdarzenia z właściwością ClusterPatchingStatus w usłudze CoordinatorService, aby wyświetlić węzły, które są poprawiane. Aktualizacje są instalowane na _poanode_0, jak pokazano na poniższej ilustracji:

   

4. Po wyłączeniu węzła zadanie naprawy zostanie przeniesione do stanu Wykonywanie .

   Uwaga

   Węzeł, który jest zablokowany w stanie Wyłączone , może zablokować nowe zadanie naprawy, które zatrzymuje operację stosowania poprawek w klastrze.

5. Gdy zadanie naprawy jest w stanie Wykonywania , rozpoczyna się instalacja poprawek w tym węźle. Po zainstalowaniu poprawki węzeł może lub nie zostanie ponownie uruchomiony, w zależności od poprawki. Następnie zadanie naprawy zostanie przeniesione do stanu Przywracania , co umożliwia ponowne włączanie węzła. Zadanie naprawy jest następnie oznaczone jako ukończone.

   W programie POA w wersji 1.4.0 lub nowszej można znaleźć stan aktualizacji, wyświetlając zdarzenia kondycji w usłudze NodeAgentService za pomocą właściwości WUOperationStatus-NodeName<>. Wyróżnione sekcje na poniższych obrazach przedstawiają stan aktualizacji systemu Windows w węzłach poanode_0 i poanode_2:

   

   

   Szczegółowe informacje można również uzyskać przy użyciu programu PowerShell. W tym celu należy nawiązać połączenie z klastrem i pobrać stan zadania naprawy przy użyciu polecenia Get-ServiceFabricRepairTask.

   W poniższym przykładzie zadanie "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" jest w stanie DownloadComplete . Oznacza to, że aktualizacje zostały pobrane w węźle poanode_2 , a instalacja zostanie podjęta, gdy zadanie przejdzie do stanu Wykonywanie .

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

   Jeśli nie zostaną znalezione więcej problemów, zaloguj się do maszyny wirtualnej lub maszyn wirtualnych i dowiedz się więcej o nich przy użyciu dzienników zdarzeń systemu Windows. Wymienione wcześniej zadanie naprawy może istnieć tylko w następujących podstanach funkcji wykonawczej:

   Funkcja wykonawczaSubState	opis
   Brak =1	Sugeruje, że w węźle nie było trwającej operacji. Stan może być w stanie przejściowym.
   DownloadCompleted=2	Oznacza to, że operacja pobierania została ukończona z powodzeniem, częściowym niepowodzeniem lub niepowodzeniem.
   InstallationApproved=3	Oznacza to, że operacja pobierania została ukończona wcześniej, a Menedżer naprawy zatwierdził instalację.
   InstallationInProgress=4	Odpowiada stanowi wykonania zadania naprawy.
   InstalacjaCompleted=5	Oznacza to, że instalacja została ukończona z powodzeniem, częściowym powodzeniem lub niepowodzeniem.
   RestartRequested=6	Oznacza to, że instalacja poprawek została ukończona i w węźle istnieje oczekująca akcja ponownego uruchomienia.
   RestartNotNeeded=7	Oznacza to, że ponowne uruchomienie nie było potrzebne po zakończeniu instalacji poprawek.
   RestartCompleted=8	Oznacza to, że ponowne uruchomienie zostało ukończone pomyślnie.
   OperationCompleted=9	Operacja usługi Windows Update została ukończona pomyślnie.
   OperationAborted=10	Oznacza to, że operacja usługi Windows Update została przerwana.

6. W wersji 1.4.0 lub nowszej po zakończeniu próby aktualizacji węzła zdarzenie o właściwości "WUOperationStatus-[NodeName]" zostanie opublikowane w usłudze NodeAgentService, aby powiadomić Użytkownika o następnej próbie pobrania i zainstalowania aktualizacji systemu Windows. Zostanie to wyświetlone na poniższej ilustracji:

   

Dzienniki diagnostyczne

Dzienniki aplikacji orkiestracji poprawek są zbierane w ramach dzienników środowiska uruchomieniowego usługi Service Fabric.

Dzienniki można przechwytywać przy użyciu wybranego narzędzia diagnostycznego lub potoku. PoA używa następujących stałych identyfikatorów dostawców do rejestrowania zdarzeń za pośrednictwem źródła zdarzeń:

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

Raporty o kondycji

PoA publikuje również raporty o kondycji względem usługi agenta węzła lub usługi koordynatora w następujących scenariuszach:

• Agent węzła NTService nie działa

  Jeśli agent węzła NTService nie działa w węźle, zostanie wygenerowany raport kondycji na poziomie ostrzeżenia względem usługi agenta węzła.

• Usługa Menedżer naprawy nie jest włączona

  Jeśli usługa Menedżera naprawy nie zostanie znaleziona w klastrze, zostanie wygenerowany raport kondycji na poziomie ostrzeżenia dla usługi koordynatora.

Często zadawane pytania

.: Dlaczego mój klaster jest wyświetlany w stanie błędu, gdy jest uruchomiona usługa POA?

1: Podczas procesu instalacji agent weryfikacji klienta wyłącza lub uruchamia ponownie węzły, co może spowodować tymczasowe wystąpienie klastra w złej kondycji.

W zależności od zasad aplikacji jeden węzeł może spaść podczas operacji stosowania poprawek lub cała domena aktualizacji może spaść jednocześnie.

Po zakończeniu instalacji aktualizacji systemu Windows węzły są ponownie uruchamiane po ponownym uruchomieniu.

W poniższym przykładzie klaster tymczasowo przeszedł do stanu błędu, ponieważ dwa węzły zostały wyłączone, a zasady MaxPercentageUnhealthyNodes zostały naruszone. Błąd jest tymczasowy do momentu rozpoczęcia operacji stosowania poprawek.

Jeśli problem będzie się powtarzać, zapoznaj się z sekcją Rozwiązywanie problemów.

.: Co mogę zrobić, jeśli poa jest w stanie ostrzeżenia?

1: Sprawdź, czy raport kondycji opublikowany względem aplikacji wskazuje główną przyczynę. Zazwyczaj ostrzeżenie zawiera szczegóły problemu. Jeśli problem jest przejściowy, aplikacja ma zostać odzyskana automatycznie.

.: Co mogę zrobić, jeśli mój klaster jest w złej kondycji i muszę przeprowadzić pilną aktualizację systemu operacyjnego?

1: PoA nie instaluje aktualizacji, gdy klaster jest w złej kondycji. Spróbuj przenieść klaster do stanu w dobrej kondycji, aby odblokować przepływ pracy weryfikacji koncepcji.

.: Czy należy ustawić właściwość TaskApprovalPolicy jako "NodeWise" lub "UpgradeDomainWise" dla mojego klastra?

1: Ustawienie "UpgradeDomainWise" przyspiesza ogólną naprawę klastra przez stosowanie poprawek do wszystkich węzłów należących do domeny aktualizacji. Podczas procesu węzły należące do całej domeny aktualizacji są niedostępne (w stanie Wyłączone).

Natomiast ustawienie "NodeWise" poprawia tylko jeden węzeł jednocześnie, co oznaczałoby, że ogólne stosowanie poprawek klastra może trwać dłużej. Jednak tylko jeden węzeł w większości będzie niedostępny (w stanie Wyłączone ) podczas procesu stosowania poprawek.

Jeśli klaster może tolerować działanie na N-1 liczbie domen aktualizacji podczas cyklu stosowania poprawek (gdzie N to całkowita liczba domen aktualizacji w klastrze), można ustawić zasady jako "UpgradeDomainWise". W przeciwnym razie ustaw go na wartość "NodeWise".

.: Ile czasu zajmuje stosowanie poprawek węzła?

1: Stosowanie poprawek węzła może potrwać od minut (na przykład aktualizacji definicji usługi Windows Defender) do godzin (na przykład aktualizacji zbiorczych systemu Windows). Czas wymagany do stosowania poprawek węzła zależy głównie od:

• Rozmiar aktualizacji.
• Liczba aktualizacji, które należy zastosować w oknie stosowania poprawek.
• Czas potrzebny na zainstalowanie aktualizacji, ponowne uruchomienie węzła (jeśli jest to wymagane) i zakończenie kroków instalacji po ponownym uruchomieniu.
• Wydajność maszyny wirtualnej lub maszyny oraz warunków sieciowych.

.: Jak długo trwa stosowanie poprawek całego klastra?

1: Czas wymagany do stosowania poprawek całego klastra zależy od:

• Czas potrzebny do stosowania poprawek węzła.

• Zasady usługi koordynatora. Domyślne zasady "NodeWise" skutkują stosowaniem poprawek tylko jednego węzła w danym momencie, czyli podejściem wolniejszym niż użycie polecenia "UpgradeDomainWise".

  Na przykład: Jeśli stosowanie poprawek węzła trwa około 1 godziny, stosowanie poprawek do klastra 20 węzłów (tego samego typu węzłów) z 5 domenami aktualizacji, z których każdy zawiera 4 węzły, wymaga:

  • W przypadku elementu "NodeWise": ~20 godzin.
  • W przypadku elementu "UpgradeDomainWise": ~5 godzin.

• Obciążenie klastra. Każda operacja stosowania poprawek wymaga przeniesienia obciążenia klienta do innych dostępnych węzłów w klastrze. W tym czasie węzeł, który jest poprawiany, będzie w stanie Wyłączanie. Jeśli klaster jest uruchomiony w pobliżu szczytowego obciążenia, proces wyłączania będzie trwać dłużej. W związku z tym ogólny proces stosowania poprawek może wydawać się powolny w takich warunkach zestresowany.

• Błędy kondycji klastra podczas stosowania poprawek. Każde obniżenie kondycji klastra spowoduje przerwanie procesu stosowania poprawek. Ten problem zostanie dodany do ogólnego czasu wymaganego do stosowania poprawek całego klastra.

.: Dlaczego widzę niektóre aktualizacje w wynikach usługi Windows Update uzyskanych za pośrednictwem interfejsu API REST, ale nie w historii usługi Windows Update na maszynie?

1: Niektóre aktualizacje produktów są wyświetlane tylko w ich własnej historii aktualizacji lub poprawek. Na przykład aktualizacje usługi Windows Defender mogą być wyświetlane lub nie są wyświetlane w historii usługi Windows Update w systemie Windows Server 2016.

.: Czy usługa POA może służyć do stosowania poprawek klastra deweloperskiego (klastra z jednym węzłem)?

1: Nie, nie można użyć weryfikacji koncepcji do stosowania poprawek do klastra z jednym węzłem. To ograniczenie jest zgodnie z projektem, ponieważ usługi systemowe usługi Service Fabric lub inne aplikacje klienckie spowodują przestoje. W związku z tym zadania naprawy poprawek nigdy nie zostaną zatwierdzone przez Menedżera naprawy.

Pytanie: Jak mogę poprawki węzłów klastra w systemie Linux?

1: Aby dowiedzieć się więcej o organizowaniu aktualizacji w systemie Linux, zobacz Automatyczne uaktualnienia obrazów systemu operacyjnego zestawu skalowania maszyn wirtualnych platformy Azure.

.: Dlaczego cykl aktualizacji trwa tak długo?

Odp.: Zapytanie dotyczące wyniku JSON, wprowadź cykl aktualizacji dla wszystkich węzłów, a następnie możesz spróbować sprawdzić czas potrzebny na instalację aktualizacji w każdym węźle przy użyciu operationStartTime i OperationTime (OperationCompletionTime).

Jeśli istnieje duże okno czasowe, w którym nie ma żadnej aktualizacji, klaster może być w stanie błędu, a w związku z tym menedżer naprawy nie może zatwierdzić żadnych zadań naprawy poA. Jeśli instalacja aktualizacji trwa długo w dowolnym węźle, ten węzeł może nie zostać zaktualizowany na chwilę. Wiele aktualizacji może być oczekujących na instalację, co może spowodować opóźnienia.

Może być również możliwe, że stosowanie poprawek węzłów jest zablokowane, ponieważ jest zablokowane w stanie Wyłączanie . Zwykle dzieje się tak, ponieważ wyłączenie węzła może prowadzić do sytuacji kworum lub utraty danych.

.: Dlaczego węzeł musi być wyłączony, gdy narzędzie POA go poprawia?

1: PoA wyłącza węzeł z intencją Ponowne uruchomienie , która zatrzymuje lub ponownie przydziela wszystkie usługi Service Fabric uruchomione w węźle. W celu zapewnienia, że aplikacje nie korzystają z kombinacji nowych i starych bibliotek DLL, dlatego nie zalecamy stosowania poprawek węzła bez wyłączania go.

.: Jaka jest maksymalna liczba węzłów, które można zaktualizować przy użyciu weryfikacji koncepcji?

1: PoA używa programu Service Fabric Repair Manager do tworzenia zadań naprawy węzłów na potrzeby aktualizacji. Jednak nie więcej niż 250 zadań naprawy może być obecnych w tym samym czasie. Obecnie agent weryfikacji koncepcji tworzy zadania naprawy dla każdego węzła w tym samym czasie, dzięki czemu poA może aktualizować nie więcej niż 250 węzłów w klastrze.

Zastrzeżenia

• PoA akceptuje umowę licencyjną użytkownika końcowego dla usługi Windows Update w imieniu użytkownika. Opcjonalnie ustawienie można wyłączyć w konfiguracji aplikacji.

• PoA zbiera dane telemetryczne w celu śledzenia użycia i wydajności. Dane telemetryczne aplikacji są zgodne z ustawieniem ustawienia telemetrii środowiska uruchomieniowego usługi Service Fabric (które jest domyślnie włączone).

Rozwiązywanie problemów

Ta sekcja zawiera możliwe rozwiązania rozwiązywania problemów z węzłami stosowania poprawek.

Węzeł nie wraca do stanu

• Węzeł może zostać zablokowany w stanie wyłączenia , ponieważ:

  • Trwa sprawdzanie bezpieczeństwa. Aby rozwiązać ten problem, upewnij się, że w dobrej kondycji są dostępne wystarczające węzły.

• Węzeł może być zablokowany w stanie Wyłączone , ponieważ:

  • Został wyłączony ręcznie.
  • Została ona wyłączona z powodu trwającego zadania infrastruktury platformy Azure.
  • Funkcja weryfikacji klienta została tymczasowo wyłączona w celu stosowania poprawek węzła.

• Węzeł może być zablokowany w stanie w dół, ponieważ:

  • Został on umieszczony ręcznie w stanie w dół.
  • Następuje ponowne uruchomienie (które może zostać wyzwolone przez weryfikację koncepcji).
  • Ma on wadliwą maszynę wirtualną lub maszynę albo ma problemy z łącznością sieciową.

Aktualizacje zostały pominięte w niektórych węzłach

PoA próbuje zainstalować aktualizację systemu Windows zgodnie z zasadami ponownego opracowywania. Usługa próbuje odzyskać węzeł i pominąć aktualizację zgodnie z zasadami aplikacji.

W takim przypadku raport kondycji na poziomie ostrzeżenia jest generowany względem usługi agenta węzła. Wynik usługi Windows Update zawiera również możliwą przyczynę błędu.

Kondycja klastra jest błędna podczas instalowania aktualizacji

Wadliwa aktualizacja systemu Windows może obniżyć kondycję aplikacji lub klastra w określonym węźle lub w domenie aktualizacji. PoA zaprzestanie kolejnej operacji usługi Windows Update, dopóki klaster nie zostanie ponownie w dobrej kondycji.

Administrator musi interweniować i określić, dlaczego aplikacja lub klaster stały się w złej kondycji z powodu usługi Windows Update.

Informacje o wersji poA

Uwaga

W przypadku wersji POA w wersji 1.4.0 lub nowszej można znaleźć informacje o wersji i wydania na stronie wydania aplikacji Patch Orchestration Application w witrynie GitHub.

Wersja 1.1.0

• Publiczne wydanie

Wersja 1.1.1

• Usunięto usterkę w elem. SetupEntryPoint of NodeAgentService, która uniemożliwiała instalację obiektu NodeAgentNTService.

Wersja 1.2.0

• Poprawki błędów dotyczące przepływu pracy ponownego uruchamiania systemu.
• Poprawka usterek podczas tworzenia zadań zarządzania zabezpieczeniami z powodu sprawdzania kondycji podczas przygotowywania zadań naprawy nie była zgodna z oczekiwaniami.
• Zmieniono tryb uruchamiania usługi POANodeSvc systemu Windows z automatycznego na opóźniony automatycznie.

Wersja 1.2.1

• Poprawka usterek w przepływie pracy skalowania klastra w dół. Wprowadzono logikę odzyskiwania pamięci dla zadań naprawy poA należących do nieistniejących węzłów.

Wersja 1.2.2

• Różne poprawki błędów.
• Pliki binarne są teraz podpisane.
• Dodano link sfpkg dla aplikacji.

Wersja 1.3.0

• Ustawienie ustawienia InstallWindowsOSOnlyUpdates na wartość false powoduje teraz zainstalowanie wszystkich dostępnych aktualizacji.
• Zmieniono logikę wyłączania aktualizacji automatycznych. To naprawia usterkę polegającą na tym, że aktualizacje automatyczne nie były wyłączone na serwerze 2016 lub nowszym.
• Ograniczenie umieszczania sparametryzowanego dla obu mikrousług poA dla zaawansowanych przypadków użycia.

Wersja 1.3.1

• Naprawianie regresji, w której poA 1.3.0 nie będzie działać w systemie Windows Server 2012 R2 lub starszym z powodu awarii wyłączania aktualizacji automatycznych.
• Naprawiono usterkę polegającą na tym, że konfiguracja InstallWindowsOSOnlyUpdates jest zawsze wybierana jako prawda.
• Zmiana domyślnej wartości InstallWindowsOSOnlyUpdates na False.

Wersja 1.3.2

• Rozwiązanie problemu, który ma wpływ na cykl życia stosowania poprawek w węźle, jeśli istnieją węzły o nazwie będącej podzbiorem nazwy bieżącego węzła. W przypadku takich węzłów możliwe jest, że nieodebrane stosowanie poprawek lub oczekiwanie na ponowne uruchomienie.