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 opartego na konfiguracji dla klastrów hostowanych na platformie Azure. Usługa POA nie jest wymagana dla klastrów hostowanych na platformie Azure, ale planowanie instalacji poprawek według domeny aktualizacji jest wymagane do stosowania poprawek hostów klastra usługi Service Fabric bez 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.

Usługa POA udostępnia 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 obsługujących klastry. Podczas gdy poA stosuje aktualizacje, 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 spadnie z powodu procesu stosowania poprawek, stosowanie poprawek zostanie zatrzymane, aby zapobiec pogorszeniu problemu.

Wewnętrzne szczegóły umowy zakupu

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

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

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

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

  • Uruchamianie agenta węzła NTService.
  • Monitorowanie usługi NTService agenta węzła.

• Node Agent NTService: ta usługa Windows NT działa na wyższym poziomie uprawnień (SYSTEM). Z kolei usługa agenta węzła i usługa koordynatora działają na niższym poziomie uprawnień (USŁUGA SIECIOWA). Usługa jest odpowiedzialna za wykonywanie następujących zadań Windows Update we 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 instalacji po aktualizacji systemu Windows na maszynie.
  • 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łączania lub włączania węzła i przeprowadzania kontroli kondycji. Zadanie naprawy utworzone przez program POA śledzi postęp Windows Update dla każdego węzła.

Wymagania wstępne

Uwaga

Wymagana minimalna wersja .NET Framework to 4.6.

Włącz usługę Menedżer naprawy (jeśli jeszcze nie jest uruchomiona)

Usługa POA wymaga włączenia usługi Menedżer naprawy w klastrze.

Klastry platformy Azure

Klastry platformy Azure w warstwie trwałości srebrnej mają domyślnie włączoną usługę Menedżer naprawy. 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 brązu domyślnie nie mają włączonej usługi Menedżer napraw. Jeśli usługa jest już włączona, można ją wyświetlić w sekcji usług systemowych w Service Fabric Explorer.

Witryna Azure Portal

Menedżer napraw można włączyć z poziomu 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 dla 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ć program 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ę po fabricSettings 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 zobaczyć usługę Repair Manager uruchomioną w klastrze. Jest to nazywane fabric:/System/RepairManagerService w sekcji usług systemowych w 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 mają wartość 04-2017 lub nowszą, jak pokazano poniżej:

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

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

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

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

   Po uruchomieniu klastra ze zaktualizowanym manifestem klastra można zobaczyć usługę Repair Manager uruchomioną w klastrze. Jest ona nazywana fabric:/System/RepairManagerService i znajduje się w sekcji usług systemowych w 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 Windows Update na "Powiadom przed pobraniem".

Pobieranie pakietu aplikacji

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

Konfigurowanie zachowania poa

Zachowanie 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 ApplicationParameterStart-ServiceFabricApplicationUpgrade polecenia cmdlet lub New-ServiceFabricApplication .

Parametr	Typ	Szczegóły
MaxResultsToCache	Długi	Maksymalna liczba Windows Update wyników, które powinny być buforowane. Wartość domyślna to 3000, przy założeniu, że:   - Liczba węzłów to 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 pojedynczo w jednej domenie aktualizacji. (Co najwyżej 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.
Kolejka WU	ciąg (Ustawienie domyślne: IsInstalled=0)	Wykonaj zapytanie w celu pobrania aktualizacji systemu Windows. Aby uzyskać więcej informacji, zobacz WuQuery.
InstallWindowsOSOnlyUpdates	Wartość logiczna (ustawienie domyślne: 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 (Ustawienie domyślne: 90)	Określa limit czasu dla dowolnej operacji Windows Update (wyszukiwanie lub pobieranie lub instalowanie). Jeśli operacja nie zostanie ukończona w ramach określonego limitu czasu, zostanie przerwana.
WURescheduleCount	int (Ustawienie domyślne: 5)	Maksymalna liczba ponownych prób ponownego wykonania aktualizacji systemu Windows w przypadku trwałej awarii operacji.
WURescheduleTimeInMinutes	int (Ustawienie domyślne: 30)	Interwał, w którym usługa zmienia harmonogram aktualizacji systemu Windows, jeśli awaria będzie się powtarzać.
WUFrequency	Ciąg rozdzielony przecinkami (domyślnie: 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 (na 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	Wartość logiczna (Wartość domyślna: true)	Ustawiając tę flagę, aplikacja akceptuje umowę licencyjną End-User dla Windows Update w imieniu właściciela maszyny.

Porada

Jeśli chcesz, aby aktualizacje systemu Windows były wykonywane natychmiast, ustaw WUFrequency wartość 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 przyjęto założenie, że uaktualnienie lub wdrożenie aplikacji trwa co najwyżej 30 minut, ustaw wartość WUFrequency na wartość Codziennie, 17:30:00.

Wdrażanie weryfikacji koncepcji

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

2. Wdróż aplikację POA tak jak każda inna aplikacja 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ż polecenie ApplicationParameter cmdlet do polecenia New-ServiceFabricApplication cmdlet . Dla Wygody udostępniliśmy skrypt Deploy.ps1 wraz z aplikacją. Aby użyć skryptu:

   • Połącz się 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 Wygody udostępniliśmy skrypt Undeploy.ps1 wraz z aplikacją. Aby użyć skryptu:

• Połącz się 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 Windows Update

Funkcja POA uwidacznia interfejsy API REST w celu wyświetlania wyników historycznych użytkownikom. 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"	Zapytanie Windows Update używane do wyszukiwania aktualizacji. Aby uzyskać więcej informacji, zobacz WuQuery.
RebootRequired	true — wymagane było ponowne uruchomienie false — ponowny rozruch nie był wymagany	Wskazuje, czy ponowne uruchomienie było wymagane do ukończenia instalacji aktualizacji.
OperationStartTime	DateTime	Wskazuje godzinę rozpoczęcia operacji (pobieranie/instalacja).
OperationTime	DateTime	Wskazuje godzinę ukończenia operacji (pobieranie/instalacja).
Hresult	0 — Powodzenie other — failure	Wskazuje przyczynę niepowodzenia aktualizacji systemu Windows z identyfikatorem updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

Jeśli aktualizacja nie jest jeszcze zaplanowana, wynik JSON jest pusty.

Zaloguj się do klastra, aby wysłać zapytanie Windows Update wyników. Znajdź adres IP repliki dla podstawowego adresu 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 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ą adresowalne spoza klastra.

Diagnostyka i zdarzenia kondycji

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

Uwaga

Aby uzyskać wiele z następujących wywołań, samodzielnych ulepszeń diagnostycznych, powinno być zainstalowane rozwiązanie POA w wersji 1.4.0 lub nowszej.

Agent węzła NTService tworzy zadania naprawy na potrzeby instalowania aktualizacji w węzłach. Każde zadanie jest następnie przygotowane 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 węzła NTService tworzy odpowiednie zadanie naprawy dla węzła o nazwie POS___<unique_id>. Te zadania naprawy można wyświetlić za pomocą polecenia cmdlet Get-ServiceFabricRepairTask lub narzędzia SFX w sekcji szczegółów węzła. Po utworzeniu zadania naprawy szybko przejdzie 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 zadaniaApprovalPolicy. Jeśli zadanieApprovalPolicy 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 jest 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 Wykonywania .

   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 uruchomiony ponownie, w zależności od poprawki. Następnie zadanie naprawy zostanie przeniesione do stanu przywracania , który można ponownie przywrócić węzeł. 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 pokazują stan aktualizacji systemu Windows w węzłach poanode_0 i poanode_2:

   

   

   Szczegółowe informacje można również uzyskać za pomocą 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 po przejściu zadania do stanu Wykonywania .

    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 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:

   ExecutorSubState	Opis
   Brak =1	Oznacza to, że nie było trwającej operacji w węźle. Stan może być w stanie przejściowym.
   DownloadCompleted=2	Oznacza, że operacja pobierania została ukończona z powodzeniem, częściowym niepowodzeniem lub niepowodzeniem.
   InstalacjaApproved=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.
   InstallationCompleted=5	Sugeruje, że instalacja została ukończona z powodzeniem, częściowym powodzeniem lub niepowodzeniem.
   RestartRequested=6	Sugeruje, że instalacja poprawki została ukończona i istnieje oczekująca akcja ponownego uruchomienia w węźle.
   RestartNotNeeded=7	Sugeruje, że ponowne uruchomienie nie było potrzebne po zakończeniu instalacji poprawki.
   RestartCompleted=8	Oznacza, że ponowne uruchomienie zostało ukończone pomyślnie.
   OperationCompleted=9	Operacja Windows Update została ukończona pomyślnie.
   OperationAborted=10	Sugeruje, że operacja Windows Update została przerwana.

6. W wersji 1.4.0 i nowszej po zakończeniu próby aktualizacji węzła zdarzenie z właściwością "WUOperationStatus-[NodeName]" zostanie opublikowane w usłudze NodeAgentService, aby powiadomić o następnej próbie pobrania i zainstalowania aktualizacji systemu Windows. Zostanie ona wyświetlona 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 przechwycić 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 dotyczące 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:

• Usługa NTService agenta węzła nie działa

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

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

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

Często zadawane pytania

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

1: Podczas procesu instalacji usługa POA 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 przechodzić w dół 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 nie działały, 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.

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

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

Pyt.: 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.

Pytanie: Czy dla klastra należy ustawić wartość TaskApprovalPolicy jako wartość "NodeWise" lub "UpgradeDomainWise"?

O: Ustawienie "UpgradeDomainWise" przyspiesza ogólną naprawę klastra przez stosowanie poprawek równolegle 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).

Z kolei ustawienie "NodeWise" poprawia tylko jeden węzeł naraz, 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 liczba 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 ją na wartość "NodeWise".

Pyt.: Ile czasu zajmuje poprawianie węzła?

Elementy: Stosowanie poprawek węzła może potrwać od minut (na przykład Windows Defender aktualizacji definicji) 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 rozruchu.
• Wydajność maszyny wirtualnej lub maszyny i warunków sieciowych.

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

O: 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 do jednego węzła naraz, czyli podejściem wolniejszym niż użycie polecenia "UpgradeDomainWise".

  Na przykład: Jeśli poprawianie 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:

  • Dla "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 może 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żeniekondycji klastra spowoduje przerwanie procesu stosowania poprawek. Ten problem spowoduje dodanie do ogólnego czasu wymaganego do stosowania poprawek całego klastra.

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

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

Pyt.: Czy można użyć weryfikacji koncepcji do stosowania poprawek do klastra deweloperskiego (klaster 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 klienta powodują przestoje. W związku z tym poprawianie zadań naprawy nigdy nie zostanie zatwierdzone przez Menedżera naprawy.

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

Elementy: Aby dowiedzieć się więcej na temat organizowania aktualizacji w systemie Linux, zobacz Automatyczne uaktualnienia obrazów systemu operacyjnego zestawu skalowania maszyn wirtualnych platformy Azure.

Pyt.: Dlaczego cykl aktualizacji trwa tak długo?

Odp.: Wykonaj zapytanie o wynikowy kod 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 opcji OperationStartTime i OperationTime (OperationCompletionTime).

Jeśli istnieje duży przedział czasu, 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ł mógł nie zostać zaktualizowany w pewnym momencie. 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.

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

Elementy: PoA wyłącza węzeł z intencją Ponowne uruchomienie , która zatrzymuje lub przenosi wszystkie usługi 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.

Pyt.: 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 agent weryfikacji koncepcji może zaktualizować nie więcej niż 250 węzłów w klastrze.

Zastrzeżenia

• PoA akceptuje umowę licencyjną End-User dla 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 problemów z węzłami stosowania poprawek.

Węzeł nie wraca do stanu

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

  • Kontrola bezpieczeństwa jest w toku. Aby rozwiązać ten problem, upewnij się, że wystarczająca liczba węzłów jest dostępna w dobrej kondycji.

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

  • Została ona wyłączona ręcznie.
  • Została ona wyłączona z powodu trwającego zadania infrastruktury platformy Azure.
  • Funkcja weryfikacji koncepcji 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 instalowania. 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 Windows Update zawiera również możliwą przyczynę błędu.

Kondycja klastra ulega błędowi 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 zaprzestaje każdej kolejnej operacji 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 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 wersji aplikacji Patch Orchestration Application w usłudze GitHub.

Wersja 1.1.0

• Publiczne wydanie

Wersja 1.1.1

• Usunięto usterkę w elemecie 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 usterki podczas tworzenia zadań zarządzania maszynami wirtualnymi z powodu sprawdzania kondycji podczas przygotowywania zadań naprawy nie była zgodna z oczekiwaniami.
• Zmieniono tryb uruchamiania usługi SYSTEMU Windows POANodeSvc z automatycznego na opóźniony auto.

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. Rozwiązano problem polegający na tym, że aktualizacje automatyczne nie były wyłączone na serwerze 2016 i nowszym.
• Sparametryzowane ograniczenie umieszczania dla obu mikrousług poA dla zaawansowanych przypadków użycia.

Wersja 1.3.1

• Naprawianie regresji, w której program POA 1.3.0 nie będzie działać na Windows Server 2012 R2 lub starszym z powodu awarii podczas wyłączania aktualizacji automatycznych.
• Usunięto usterkę polegającą na tym, że konfiguracja InstallWindowsOSOnlyUpdates jest zawsze wybierana jako true.
• 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, która jest podzbiorem bieżącego węzła. W przypadku takich węzłów istnieje możliwość, że nieodebrane stosowanie poprawek lub ponowne uruchomienie oczekuje.