Integracja menedżera zasobów klastra z zarządzaniem klastrem usługi Service Fabric

Menedżer zasobów klastra usługi Service Fabric nie obsługuje uaktualnień w usłudze Service Fabric, ale jest zaangażowany. Pierwszym sposobem, w jaki menedżer zasobów klastra pomaga w zarządzaniu, jest śledzenie żądanego stanu klastra i usług w nim. Menedżer zasobów klastra wysyła raporty o kondycji, gdy nie może umieścić klastra w żądanej konfiguracji. Jeśli na przykład nie ma wystarczającej pojemności, menedżer zasobów klastra wysyła ostrzeżenia o kondycji i błędy wskazujące problem. Kolejna integracja musi mieć związek ze sposobem działania uaktualnień. Menedżer zasobów klastra nieco zmienia swoje zachowanie podczas uaktualniania.

Integracja kondycji

Menedżer zasobów klastra stale śledzi reguły zdefiniowane do umieszczania usług. Śledzi również pozostałą pojemność dla każdej metryki w węzłach i w klastrze oraz w klastrze jako całości. Jeśli nie można spełnić tych reguł lub jeśli nie ma wystarczającej pojemności, ostrzeżenia dotyczące kondycji i błędy są emitowane. Jeśli na przykład węzeł jest za dużo pojemności, a menedżer zasobów klastra spróbuje rozwiązać tę sytuację, przenosząc usługi. Jeśli nie może poprawić sytuacji, emituje ostrzeżenie o kondycji wskazujące, który węzeł znajduje się w pojemności i dla których metryk.

Innym przykładem ostrzeżeń dotyczących kondycji usługi Resource Manager są naruszenia ograniczeń umieszczania. Jeśli na przykład zdefiniowano ograniczenie umieszczania (na “NodeColor == Blue”przykład ) i usługa Resource Manager wykryje naruszenie tego ograniczenia, emituje ostrzeżenie o kondycji. Dotyczy to ograniczeń niestandardowych i ograniczeń domyślnych (takich jak ograniczenia domeny błędów i uaktualniania domeny).

Oto przykład jednego z takich raportów dotyczących kondycji. W takim przypadku raport kondycji dotyczy jednej z partycji usługi systemowej. Komunikat o kondycji wskazuje, że repliki tej partycji są tymczasowo pakowane w zbyt mało domen uaktualnienia.

PS C:\Users\User > Get-ServiceFabricPartitionHealth -PartitionId '00000000-0000-0000-0000-000000000001'


PartitionId           : 00000000-0000-0000-0000-000000000001
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='System.PLB', Property='ReplicaConstraintViolation_UpgradeDomain', HealthState='Warning', ConsiderWarningAsError=false.

ReplicaHealthStates   :
                        ReplicaId             : 130766528804733380
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577821
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528854889931
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577822
                        AggregatedHealthState : Ok

                        ReplicaId             : 130837073190680024
                        AggregatedHealthState : Ok

HealthEvents          :
                        SourceId              : System.PLB
                        Property              : ReplicaConstraintViolation_UpgradeDomain
                        HealthState           : Warning
                        SequenceNumber        : 130837100116930204
                        SentAt                : 8/10/2015 7:53:31 PM
                        ReceivedAt            : 8/10/2015 7:53:33 PM
                        TTL                   : 00:01:05
                        Description           : The Load Balancer has detected a Constraint Violation for this Replica: fabric:/System/FailoverManagerService Secondary Partition 00000000-0000-0000-0000-000000000001 is
                        violating the Constraint: UpgradeDomain Details: UpgradeDomain ID -- 4, Replica on NodeName -- Node.8 Currently Upgrading -- false Distribution Policy -- Packing
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : Ok->Warning = 8/10/2015 7:13:02 PM, LastError = 1/1/0001 12:00:00 AM

Oto, co mówi nam ten komunikat o kondycji:

1. Wszystkie same repliki są w dobrej kondycji: każdy z nich ma AggregatedHealthState : Ok
2. Ograniczenie dystrybucji domeny uaktualnienia jest obecnie naruszane. Oznacza to, że określona domena uaktualnienia ma więcej replik z tej partycji niż powinna.
3. Który węzeł zawiera replikę powodującą naruszenie. W takim przypadku jest to węzeł o nazwie Node.8
4. Czy uaktualnienie jest obecnie wykonywane dla tej partycji ("Obecnie uaktualnianie -- false")
5. Zasady dystrybucji dla tej usługi: "Zasady dystrybucji - Pakowanie". Podlega to zasadom umieszczania.RequireDomainDistribution Pakowanie wskazuje, że w tym przypadku atrybut DomainDistribution nie był wymagany, więc wiemy, że zasady umieszczania nie zostały określone dla tej usługi.
6. Kiedy raport miał miejsce — 10.08.2015 17:13:02

Informacje takie jak te zasilają alerty. Możesz użyć alertów w środowisku produkcyjnym, aby poinformować, że coś poszło nie tak. Alerty są również używane do wykrywania i zatrzymywania nieprawidłowych uaktualnień. W takim przypadku chcemy sprawdzić, czy możemy dowiedzieć się, dlaczego usługa Resource Manager musiała spakować repliki do domeny uaktualnienia. Zazwyczaj pakowanie jest przejściowe, ponieważ węzły w innych domenach uaktualniania były wyłączone, na przykład.

Załóżmy, że menedżer zasobów klastra próbuje umieścić niektóre usługi, ale nie ma żadnych rozwiązań, które działają. Gdy nie można umieścić usług, zwykle jest to z jednego z następujących powodów:

1. Niektóre przejściowe warunki uniemożliwiły poprawne umieszczenie tego wystąpienia usługi lub repliki
2. Wymagania dotyczące umieszczania usługi są niezadowalalne.

W takich przypadkach raporty o kondycji z usługi Resource Manager klastra ułatwiają określenie, dlaczego nie można umieścić usługi. Nazywamy ten proces sekwencją eliminacji ograniczeń. W trakcie tego procesu system przechodzi przez skonfigurowane ograniczenia wpływające na usługę i rejestruje, co eliminują. W ten sposób, gdy nie można umieścić usług, można zobaczyć, które węzły zostały wyeliminowane i dlaczego.

Typy ograniczeń

Porozmawiajmy o poszczególnych ograniczeniach w tych raportach dotyczących kondycji. Zobaczysz komunikaty o kondycji związane z tymi ograniczeniami, gdy nie można umieścić replik.

• ReplicaExclusionStatic i ReplicaExclusionDynamic: te ograniczenia wskazują, że rozwiązanie zostało odrzucone, ponieważ dwa obiekty usługi z tej samej partycji musiałyby zostać umieszczone w tym samym węźle. Nie jest to dozwolone, ponieważ awaria tego węzła będzie miała nadmierny wpływ na tę partycję. ReplicaExclusionStatic i ReplicaExclusionDynamic są prawie tą samą regułą, a różnice nie mają znaczenia. Jeśli widzisz sekwencję eliminacji ograniczeń zawierającą ograniczenie ReplicaExclusionStatic lub ReplicaExclusionDynamic, menedżer zasobów klastra uważa, że nie ma wystarczającej liczby węzłów. Wymaga to użycia tych nieprawidłowych umieszczania, które są niedozwolone w pozostałych rozwiązaniach. Inne ograniczenia w sekwencji zwykle informują nas, dlaczego węzły są usuwane w pierwszej kolejności.
• PlacementConstraint: jeśli widzisz ten komunikat, oznacza to, że wyeliminowaliśmy niektóre węzły, ponieważ nie były zgodne z ograniczeniami umieszczania usługi. Śledzimy obecnie skonfigurowane ograniczenia umieszczania w ramach tego komunikatu. Jest to normalne, jeśli masz zdefiniowane ograniczenie umieszczania. Jeśli jednak ograniczenie umieszczania jest niepoprawnie przyczyną wyeliminowania zbyt wielu węzłów, jest to jak można zauważyć.
• NodeCapacity: to ograniczenie oznacza, że menedżer zasobów klastra nie może umieścić replik na wskazanych węzłach, ponieważ spowoduje to umieszczenie ich w pojemności.
• Koligacja: to ograniczenie wskazuje, że nie można umieścić repliki w węzłach, których dotyczy problem, ponieważ spowodowałoby to naruszenie ograniczenia koligacji. Więcej informacji na temat koligacji znajduje się w tym artykule
• FaultDomain i UpgradeDomain: to ograniczenie eliminuje węzły, jeśli umieszczenie repliki w wskazanych węzłach spowoduje spakowanie w określonej domenie błędu lub uaktualnieniu. Kilka przykładów omawiających to ograniczenie przedstawiono w temacie na temat ograniczeń dotyczących błędów i uaktualniania domeny oraz wynikowych zachowań
• PreferredLocation: zwykle nie powinno być widoczne to ograniczenie usuwające węzły z rozwiązania, ponieważ jest ono domyślnie uruchamiane jako optymalizacja. Podczas uaktualniania występuje również ograniczenie preferowanej lokalizacji. Podczas uaktualniania jest on używany do przenoszenia usług z powrotem do lokalizacji, w której były, gdy uaktualnienie zostało uruchomione.

Blokowanie węzłów

Innym komunikatem o kondycji raportów usługi Resource Manager klastra jest to, że węzły są blokowane. Możesz traktować blokowanie jako tymczasowe ograniczenie, które jest automatycznie stosowane. Węzły są blokowane, gdy występują powtarzające się błędy podczas uruchamiania wystąpień tego typu usługi. Węzły są blokowane według typu usługi. Węzeł może być zablokowany dla jednego typu usługi, ale nie inny.

Podczas programowania często pojawia się rzut blokowy: Podczas opracowywania pojawia się błąd: niektóre błędy powodują awarię hosta usługi podczas uruchamiania, usługa Service Fabric próbuje utworzyć hosta usługi kilka razy, a awaria nadal występuje. Po kilku próbach węzeł zostanie zablokowany, a menedżer zasobów klastra spróbuje utworzyć usługę w innym miejscu. Jeśli ten błąd będzie nadal występuje w wielu węzłach, możliwe, że wszystkie prawidłowe węzły w klastrze zakończą się zablokowane. Blokowanie może również usuwać tak wiele węzłów, że nie wystarczy, aby można było uruchomić usługę, aby spełnić żądaną skalę. Zazwyczaj zobaczysz dodatkowe błędy lub ostrzeżenia z usługi Resource Manager klastra wskazujące, że usługa jest poniżej żądanej liczby replik lub wystąpień, a także komunikatów o kondycji wskazujących, jaka jest awaria prowadząca do blokowania w pierwszej kolejności.

Blokowanie nie jest warunkiem trwałym. Po kilku minutach węzeł zostanie usunięty z listy zablokowanych, a usługa Service Fabric może ponownie aktywować usługi w tym węźle. Jeśli usługi nadal kończą się niepowodzeniem, węzeł zostanie ponownie zablokowany dla tego typu usługi.

Priorytety ograniczeń

Ostrzeżenie

Zmiana priorytetów ograniczeń nie jest zalecana i może mieć znaczący negatywny wpływ na klaster. Poniższe informacje znajdują się w dokumentacji domyślnych priorytetów ograniczeń i ich zachowania.

Ze wszystkimi tymi ograniczeniami można pomyśleć:"Hej – myślę, że ograniczenia domeny błędów są najważniejszą rzeczą w moim systemie. Aby zapewnić, że ograniczenie domeny błędów nie zostanie naruszone, chcę naruszyć inne ograniczenia.

Ograniczenia można skonfigurować przy użyciu różnych poziomów priorytetu. Są to:

• "hard" (0)
• "miękkie" (1)
• "optymalizacja" (2)
• "off" (-1).

Większość ograniczeń jest domyślnie konfigurowana jako twarde ograniczenia.

Zmiana priorytetu ograniczeń jest rzadkością. Były czasy, w których konieczne było ograniczenie priorytetów, które trzeba zmienić, zwykle w celu obejścia innego błędu lub zachowania, które miało wpływ na środowisko. Ogólnie rzecz biorąc, elastyczność infrastruktury priorytetowej ograniczeń działała bardzo dobrze, ale często nie jest potrzebna. Przez większość czasu wszystko znajduje się w ich domyślnych priorytetach.

Poziomy priorytetów nie oznaczają, że określone ograniczenie zostanie naruszone ani nie zostanie spełnione. Priorytety ograniczeń definiują kolejność wymuszania ograniczeń. Priorytety definiują kompromisy, gdy nie można spełnić wszystkich ograniczeń. Zwykle wszystkie ograniczenia mogą być spełnione, chyba że w środowisku dzieje się coś innego. Niektóre przykłady scenariuszy, które spowodują naruszenie ograniczeń, to ograniczenia powodujące konflikt lub duża liczba współbieżnych awarii.

W zaawansowanych sytuacjach można zmienić priorytety ograniczeń. Załóżmy na przykład, że chcesz upewnić się, że koligacja będzie zawsze naruszana w razie potrzeby w celu rozwiązania problemów z pojemnością węzła. Aby to osiągnąć, można ustawić priorytet ograniczenia koligacji na wartość "soft" (1) i pozostawić ograniczenie pojemności ustawione na wartość "hard" (0).

Domyślne wartości priorytetów dla różnych ograniczeń są określone w następującej konfiguracji:

ClusterManifest.xml

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PlacementConstraintPriority" Value="0" />
            <Parameter Name="CapacityConstraintPriority" Value="0" />
            <Parameter Name="AffinityConstraintPriority" Value="0" />
            <Parameter Name="FaultDomainConstraintPriority" Value="0" />
            <Parameter Name="UpgradeDomainConstraintPriority" Value="1" />
            <Parameter Name="PreferredLocationConstraintPriority" Value="2" />
        </Section>

za pośrednictwem ClusterConfig.json dla wdrożeń autonomicznych lub Template.json dla klastrów hostowanych na platformie Azure:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PlacementConstraintPriority",
          "value": "0"
      },
      {
          "name": "CapacityConstraintPriority",
          "value": "0"
      },
      {
          "name": "AffinityConstraintPriority",
          "value": "0"
      },
      {
          "name": "FaultDomainConstraintPriority",
          "value": "0"
      },
      {
          "name": "UpgradeDomainConstraintPriority",
          "value": "1"
      },
      {
          "name": "PreferredLocationConstraintPriority",
          "value": "2"
      }
    ]
  }
]

Ograniczenia domeny błędów i uaktualniania domeny

Menedżer zasobów klastra chce zachować rozproszenie usług między domenami błędów i uaktualniania. Modeluje to jako ograniczenie wewnątrz aparatu usługi Resource Manager klastra. Aby uzyskać więcej informacji na temat sposobu ich użycia i ich konkretnego zachowania, zapoznaj się z artykułem dotyczącym konfiguracji klastra.

Menedżer zasobów klastra może wymagać spakowania kilku replik do domeny uaktualnienia, aby poradzić sobie z uaktualnieniami, awariami lub innymi naruszeniami ograniczeń. Pakowanie w domeny błędów lub uaktualniania zwykle odbywa się tylko wtedy, gdy w systemie występuje kilka awarii lub innych zmian uniemożliwiających prawidłowe umieszczanie. Jeśli chcesz zapobiec pakowaniu nawet w tych sytuacjach, możesz skorzystać z zasad umieszczania.RequireDomainDistribution Należy pamiętać, że może to mieć wpływ na dostępność i niezawodność usługi jako efekt uboczny, dlatego należy je dokładnie rozważyć.

Jeśli środowisko jest poprawnie skonfigurowane, wszystkie ograniczenia są w pełni przestrzegane, nawet podczas uaktualniania. Kluczową rzeczą jest to, że menedżer zasobów klastra obserwuje ograniczenia. Gdy wykryje naruszenie, natychmiast zgłosi go i spróbuje rozwiązać problem.

Ograniczenie preferowanej lokalizacji

Ograniczenie PreferredLocation jest nieco inne, ponieważ ma dwa różne zastosowania. Jednym z zastosowań tego ograniczenia jest uaktualnienie aplikacji. Menedżer zasobów klastra automatycznie zarządza tym ograniczeniem podczas uaktualniania. Służy do zapewnienia, że po zakończeniu uaktualnień repliki wracają do ich lokalizacji początkowych. Inne zastosowanie ograniczenia PreferredLocation dotyczy zasad umieszczania.PreferredPrimaryDomain Oba są optymalizacjami, dlatego ograniczenie PreferredLocation jest jedynym ograniczeniem ustawionym na wartość "Optymalizacja" domyślnie.

Uaktualnienia

Menedżer zasobów klastra pomaga również podczas uaktualniania aplikacji i klastra, podczas których ma dwa zadania:

• upewnij się, że reguły klastra nie zostały naruszone
• spróbuj pomóc bezproblemowo uaktualnić

Wymuszanie reguł

Główną rzeczą, o której należy pamiętać, jest to, że reguły — ścisłe ograniczenia, takie jak ograniczenia umieszczania i pojemności — są nadal wymuszane podczas uaktualniania. Ograniczenia umieszczania zapewniają, że obciążenia działają tylko tam, gdzie są dozwolone, nawet podczas uaktualniania. Gdy usługi są wysoce ograniczone, uaktualnienia mogą trwać dłużej. Gdy usługa lub jej węzeł zostanie wyłączony dla aktualizacji, może istnieć kilka opcji, w których można przejść.

Inteligentne zamiany

Po uruchomieniu uaktualnienia usługa Resource Manager tworzy migawkę bieżącego układu klastra. Po zakończeniu każdego uaktualnienia domeny próbuje zwrócić usługi, które znajdowały się w tej domenie uaktualnienia do ich oryginalnego układu. W ten sposób podczas uaktualniania istnieją co najwyżej dwa przejścia dla usługi. Istnieje jedno wyjście z węzła, którego dotyczy problem, i jedno przejście z powrotem. Powrót klastra lub usługi do sposobu, w jaki był przed uaktualnieniem, zapewnia również, że uaktualnienie nie ma wpływu na układ klastra.

Zmniejszony współczynnik zmian

Podczas uaktualniania menedżer zasobów klastra wyłącza również równoważenie. Zapobieganie równoważeniu uniemożliwia niepotrzebne reakcje na samo uaktualnienie, takie jak przenoszenie usług do węzłów, które zostały opróżnione w celu uaktualnienia. Jeśli uaktualnienie jest uaktualnieniem klastra, cały klaster nie jest zrównoważony podczas uaktualniania. Kontrole ograniczeń pozostają aktywne, a ruch tylko na podstawie proaktywnego równoważenia metryk jest wyłączony.

Pojemność buforowana i uaktualnianie

Ogólnie rzecz biorąc, uaktualnienie ma zostać ukończone, nawet jeśli klaster jest ograniczony lub zbliżony do pełnego. Zarządzanie pojemnością klastra jest jeszcze ważniejsze podczas uaktualniania niż zwykle. W zależności od liczby domen uaktualnienia należy przeprowadzić migrację między 5 a 20% pojemności, ponieważ uaktualnienie jest przenoszone przez klaster. Ta praca musi gdzieś iść. Jest to miejsce, w którym przydatne jest pojęcie buforowanych pojemności . Pojemność buforowana jest uwzględniana podczas normalnego działania. Menedżer zasobów klastra może wypełnić węzły do całkowitej pojemności (zużywając bufor) podczas uaktualniania w razie potrzeby.

Następne kroki

• Rozpocznij od początku i uzyskaj wprowadzenie do usługi Service Fabric Cluster Resource Manager