Równoważenie klastra Service Fabric

Menedżer zasobów klastra usługi Service Fabric obsługuje dynamiczne zmiany obciążenia, reagując na dodatki lub usunięcia węzłów lub usług. Powoduje to również automatyczne poprawianie naruszeń ograniczeń i proaktywne ponowne równoważenie klastra. Ale jak często są podejmowane te akcje i jakie wyzwalają je?

Istnieją trzy różne kategorie pracy wykonywanej przez menedżera zasobów klastra:

• Umieszczanie — ten etap dotyczy umieszczania wszystkich replik stanowych lub brakujących wystąpień bezstanowych. Umieszczanie obejmuje zarówno nowe usługi, jak i obsługę replik stanowych lub wystąpień bezstanowych, które zakończyły się niepowodzeniem. Usuwanie i porzucanie replik lub wystąpień jest tutaj obsługiwane.
• Kontrole ograniczeń — ten etap sprawdza i naprawia naruszenia różnych ograniczeń umieszczania (reguł) w systemie. Przykłady reguł to takie rzeczy, jak zapewnienie, że węzły nie są przepełnione i że są spełnione ograniczenia dotyczące rozmieszczania usługi.
• Równoważenie — ten etap sprawdza, czy wymagane jest ponowne równoważenie na podstawie skonfigurowanego żądanego poziomu równowagi dla różnych metryk. Jeśli tak, próbuje znaleźć układ w klastrze, który jest bardziej zrównoważony.

Konfigurowanie czasomierzy usługi Resource Manager klastra

Pierwszy zestaw kontrolek wokół równoważenia to zestaw czasomierzy. Te czasomierze określają, jak często menedżer zasobów klastra sprawdza klaster i podejmuje działania naprawcze.

Każdy z tych różnych typów poprawek, które może wprowadzić menedżer zasobów klastra, jest kontrolowany przez inny czasomierz, który zarządza jego częstotliwością. Po każdym uruchomieniu czasomierza zadanie jest zaplanowane. Domyślnie Resource Manager:

• skanuje jego stan i stosuje aktualizacje (takie jak rejestrowanie, że węzeł jest wyłączony) co 1/10 sekundy
• ustawia flagę sprawdzania umieszczania co sekundę
• ustawia flagę sprawdzania ograniczeń co sekundę
• ustawia flagę równoważenia co pięć sekund

Poniżej przedstawiono przykłady konfiguracji zarządzającej tymi czasomierzami:

ClusterManifest.xml:

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PLBRefreshGap" Value="0.1" />
            <Parameter Name="MinPlacementInterval" Value="1.0" />
            <Parameter Name="MinConstraintCheckInterval" Value="1.0" />
            <Parameter Name="MinLoadBalancingInterval" Value="5.0" />
        </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": "PLBRefreshGap",
          "value": "0.10"
      },
      {
          "name": "MinPlacementInterval",
          "value": "1.0"
      },
      {
          "name": "MinConstraintCheckInterval",
          "value": "1.0"
      },
      {
          "name": "MinLoadBalancingInterval",
          "value": "5.0"
      }
    ]
  }
]

Obecnie menedżer zasobów klastra wykonuje tylko jedną z tych akcji jednocześnie sekwencyjnie. Dlatego nazywamy te czasomierze "minimalnymi interwałami", a akcje podejmowane, gdy czasomierze się zakończą, jako "ustawianie flag". Na przykład menedżer zasobów klastra zajmuje się oczekującymi żądaniami utworzenia usług przed równoważeniem klastra. Jak widać, dzięki domyślnie określonym interwałom czasu, menedżer zasobów klastra skanuje często pod kątem wszystkich działań, które trzeba wykonać. Zwykle oznacza to, że zestaw zmian wprowadzonych w każdym kroku jest mały. Małe, częste zmiany umożliwiają menedżerowi zasobów klastra szybką reakcję na zdarzenia zachodzące w klastrze. Domyślne czasomierze udostępniają pewne partie, ponieważ wiele z tych samych typów zdarzeń zwykle występuje jednocześnie.

Na przykład, gdy węzły ulegają awarii, może to dotyczyć całych domen awarii naraz. Wszystkie te błędy są przechwytywane podczas następnej aktualizacji stanu po plBRefreshGap. Korekty są określane podczas wykonywania następujących operacji umieszczania, sprawdzania ograniczeń i równoważenia. Domyślnie menedżer zasobów klastra nie przeszukuje zmian w klastrze w ciągu wielu godzin i nie próbuje rozwiązać wszystkich zmian jednocześnie. To doprowadziłoby do nagłych zmian.

Menedżer zasobów klastra potrzebuje również pewnych dodatkowych informacji, aby określić, czy klaster jest niezrównoważony. W tym przypadku mamy dwa inne elementy konfiguracji: BalancingThresholds i ActivityThresholds.

Progi równoważenia

Próg równoważenia to główna kontrolka wyzwalania ponownego równoważenia. Próg równoważenia dla metryki jest współczynnikiem. Jeśli stosunek obciążenia metryki na najbardziej obciążonym węźle do obciążenia na najmniej obciążonym węźle przekracza wartość progu równoważenia metryki BalancingThreshold, klaster jest niezrównoważony. W wyniku równoważenia zostanie wyzwolone przy następnym sprawdzeniu przez Menedżera zasobów klastra. Czasomierz MinLoadBalancingInterval definiuje, jak często menedżer zasobów klastra powinien sprawdzić, czy konieczne jest ponowne równoważenie. Sprawdzanie nie oznacza, że coś się dzieje.

Progi równoważenia są definiowane dla poszczególnych metryk w ramach definicji klastra. Aby uzyskać więcej informacji na temat metryk, zapoznaj się z artykułem metryki.

ClusterManifest.xml

    <Section Name="MetricBalancingThresholds">
      <Parameter Name="MetricName1" Value="2"/>
      <Parameter Name="MetricName2" Value="3.5"/>
    </Section>

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

"fabricSettings": [
  {
    "name": "MetricBalancingThresholds",
    "parameters": [
      {
          "name": "MetricName1",
          "value": "2"
      },
      {
          "name": "MetricName2",
          "value": "3.5"
      }
    ]
  }
]

W tym przykładzie każda usługa zużywa jedną jednostkę pewnej metryki. W górnym przykładzie maksymalne obciążenie węzła wynosi pięć, a minimum to dwa. Załóżmy, że próg równoważenia dla tej metryki wynosi trzy. Ponieważ stosunek w klastrze wynosi 5/2 = 2,5 i jest mniejszy niż określony próg równoważenia wynoszący trzy, klaster jest zrównoważony. Podczas sprawdzania przez menedżera zasobów klastra nie jest wyzwalane żadne balansowanie.

W dolnym przykładzie maksymalne obciążenie węzła wynosi 10, a minimum to dwa, co daje stosunek pięciu. Pięć jest większe niż wyznaczony próg równoważenia trzech dla tej metryki. W związku z tym proces ponownego równoważenia zostanie zaplanowany przy następnym uruchomieniu timera równoważenia. W takiej sytuacji obciążenie jest zwykle dystrybuowane do węzła 3. Ponieważ menedżer zasobów klastra usługi Service Fabric nie korzysta z chciwego podejścia, niektóre obciążenia mogą być również dystrybuowane do węzła 2.

Uwaga

"Równoważenie" obsługuje dwie różne strategie zarządzania obciążeniem w klastrze. Domyślną strategią używaną przez menedżera zasobów klastra jest rozłożenie obciążenia między węzłami w klastrze. Druga strategia to defragmentacja. Defragmentacja jest przeprowadzana w trakcie tego samego przebiegu równoważenia. Strategie równoważenia i defragmentacji mogą być używane dla różnych metryk w tym samym klastrze. Usługa może mieć metryki równoważenia i defragmentacji. W przypadku metryk defragmentacji stosunek obciążeń w klastrze wyzwala ponowne równoważenie, gdy jest poniżej progu równoważenia.

Zejście poniżej progu równowagi nie jest wyraźnym celem. Progi równoważenia to tylko wyzwalacz. Gdy wykonywane jest równoważenie, Menedżer Zasobów Klastra określa, jakie ulepszenia może wprowadzić, jeśli w ogóle. Tylko dlatego, że proces równoważenia jest uruchamiany, nie oznacza, że następują jakieś ruchy. Czasami klaster jest niezrównoważony, ale zbyt ograniczony, aby można go było poprawić. Alternatywnie ulepszenia wymagają ruchów, które są zbyt kosztowne).

Progi działań

Czasami, chociaż węzły są stosunkowo niezrównoważone, łączna wielkość obciążenia w klastrze jest niska. Brak obciążenia może być przejściowym spadkiem, albo wynikać z tego, że klaster jest nowy i dopiero uruchamiany. W każdym z przypadków możesz nie chcieć poświęcać czasu na równoważenie klastra, ponieważ niewiele można na tym zyskać. Jeśli klaster przeszedł równoważenie, zużyłbyś zasoby sieciowe i obliczeniowe, aby przemieszczać zasoby bez wprowadzania znaczącej różnicy absolutnej. Aby uniknąć niepotrzebnych ruchów, istnieje inna kontrolka znana jako progi działania. Progi działań umożliwiają określenie pewnej bezwzględnej niższej granicy dla działania. Jeśli żaden węzeł nie przekracza tego progu, równoważenie nie zostanie wyzwolone, nawet jeśli próg równoważenia zostanie osiągnięty.

Załóżmy, że dla tej metryki zachowamy próg równoważenia wynoszące trzy. Załóżmy również, że mamy próg aktywności 1536. W pierwszym przypadku, gdy klaster jest niezrównoważony zgodnie z progiem równoważenia, nie ma węzła spełniającego progu działania, więc nic się nie dzieje. W dolnym przykładzie węzeł 1 przekracza próg działania. Ponieważ zarówno próg równoważenia, jak i próg działania dla metryki są przekraczane, równoważenie jest zaplanowane. Na przykład przyjrzyjmy się następującej ilustracji:

Podobnie jak progi równoważenia obciążeń, progi działania są definiowane dla każdej metryki w ramach definicji klastra.

ClusterManifest.xml

    <Section Name="MetricActivityThresholds">
      <Parameter Name="Memory" Value="1536"/>
    </Section>

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

"fabricSettings": [
  {
    "name": "MetricActivityThresholds",
    "parameters": [
      {
          "name": "Memory",
          "value": "1536"
      }
    ]
  }
]

Zarówno progi równoważenia, jak i działania są powiązane z określoną metryką — równoważenie jest wyzwalane tylko wtedy, gdy zarówno próg równoważenia, jak i próg działania zostaną przekroczone dla tej samej metryki.

Uwaga

Jeśli nie zostanie określony, próg równoważenia dla metryki wynosi 1, a próg działania wynosi 0. Oznacza to, że menedżer zasobów klastra będzie starał się zachować tę metryę idealnie zrównoważoną dla danego obciążenia. Jeśli używasz metryk niestandardowych, zaleca się jawne zdefiniowanie własnych progów równoważenia i aktywności dla metryk.

Równoważące usługi

Decyzja dotycząca tego, czy klaster jest niezrównoważony, jest podejmowana na poziomie całego klastra. Jednak naprawiamy to, przenosząc poszczególne repliki usług i instancje w inne miejsca. To ma sens, prawda? Jeśli pamięć jest nagromadzona na jednym węźle, może przyczyniać się do tego wiele replik lub wystąpień. Naprawienie dysproporcji może wymagać przeniesienia dowolnej repliki stanowej lub instancji bezstanowej, które korzystają z niezrównoważonego wskaźnika.

Czasami jednak usługa, która sama w sobie nie była niezrównoważona, zostaje przeniesiona (pamiętaj o omawianej wcześniej dyskusji na temat lokalnych i globalnych wag). Dlaczego usługa miałaby zostać przeniesiona, skoro wszystkie jej metryki są zrównoważone? Zobaczmy przykład:

• Załóżmy, że istnieją cztery usługi, Service 1, Service 2, Service 3 i Service 4.
• Usługa 1 raportuje metryki Metryki 1 i Metryka 2.
• Usługa 2 raportuje metryki: Metryka 2 i Metryka 3.
• Usługa 3 raportuje metryki Metryki 3 i Metryka 4.
• Usługa 4 raportuje metrykę Metryka 99.

Tak naprawdę nie mamy czterech niezależnych usług, mamy trzy powiązane usługi i jedną, która działa niezależnie.

Z powodu tego łańcucha możliwe jest, że nierównowaga metryk 1–4 może spowodować, że repliki lub wystąpienia należące do usług 1–3 się poruszają. Wiemy również, że brak równowagi we wskaźnikach 1, 2 lub 3 nie może powodować zmian w usłudze 4. Nie byłoby żadnego punktu, ponieważ przeniesienie replik lub wystąpień należących do usługi 4 wokół nie może zrobić absolutnie nic, aby wpłynąć na równowagę metryk 1-3.

Menedżer zasobów klastra automatycznie określa, jakie usługi są powiązane. Dodawanie, usuwanie lub zmienianie metryk dla usług może mieć wpływ na ich relacje. Na przykład między dwoma przebiegami usługi równoważenia 2 mogły zostać zaktualizowane w celu usunięcia metryki 2. Spowoduje to przerwanie łańcucha między usługami Service 1 i Service 2. Teraz zamiast dwóch grup powiązanych usług istnieją trzy:

Równoważenie klastra w zależności od typu węzła

Jak opisano we wcześniejszych sekcjach, głównymi kontrolkami wyzwalania ponownego równoważenia są progi działań, progi równoważenia i czasomierze. Menedżer zasobów klastra usługi Service Fabric zapewnia bardziej szczegółową kontrolę nad wyzwalaniem ponownego równoważenia przy użyciu określania parametrów dla typu węzła i zezwalania na przenoszenie tylko na niezrównoważone typy węzłów. Główną zaletą równoważenia na typ węzła jest umożliwienie poprawy wydajności typów węzłów, które wymagają bardziej rygorystycznych reguł równoważenia, bez obniżenia wydajności w innych typach węzłów. Funkcja zawiera dwie główne części:

• Wykrywanie nierównowagi odbywa się dla każdego typu węzła. Wcześniej globalne obliczenie dysproporcji jest obliczane dla każdego typu węzła. Jeśli wszystkie typy węzłów są zrównoważone, faza równoważenia systemu CRM nie zostanie wyzwolona. W przeciwnym razie, jeśli co najmniej jeden typ węzła jest niezrównoważony, potrzebna jest faza równoważenia.
• Równoważenie przenosi repliki tylko na typy węzłów, które są niezrównoważone; inne typy węzłów nie są wpływane przez fazę równoważenia.

Jak równoważenie dla każdego typu węzła wpływa na klaster

Podczas równoważenia klastra dla każdego typu węzła, Menedżer Zasobów Klastra usługi Service Fabric oblicza stan dysproporcji dla każdego typu węzła. Jeśli co najmniej jeden typ węzła jest niezrównoważony, faza równoważenia zostanie wyzwolona. Proces równoważenia nie przemieszcza replik w typach węzłów, które są niezrównoważone, gdy równoważenie jest tymczasowo wstrzymane w tych typach węzłów (np. minimalny okres równoważenia nie upłynął od poprzedniej fazy równoważenia). Wykrywanie niezrównoważonego stanu korzysta z typowych mechanizmów dostępnych już na potrzeby klasycznego równoważenia klastra, ale zwiększa stopień szczegółowości i elastyczności konfiguracji. Mechanizmy używane do równoważenia dla każdego typu węzła w celu wykrycia nierównowagi są podane na poniższej liście.

• Progi równoważenia metryk na typ węzła to wartości, które mają podobną rolę jak globalnie zdefiniowany próg równoważenia używany w równoważeniu klasycznym. Współczynnik minimalnego i maksymalnego obciążenia metryki jest obliczany dla każdego typu węzła. Jeśli stosunek typu węzła jest wyższy niż zdefiniowany próg równoważenia typu węzła, typ węzła jest oznaczony jako nierównowaga. Aby uzyskać więcej informacji na temat konfiguracji progów dla aktywności metryk dla typu węzła, zapoznaj się z sekcją Progi równoważenia dla typu węzła.
• Progi aktywności metryk dla typu węzła to wartości, które mają podobną rolę do globalnie zdefiniowanego progu aktywności używanego w równoważeniu klasycznym. Maksymalne obciążenie dla metryki jest obliczane dla każdego typu węzła. Jeśli maksymalne obciążenie typu węzła jest wyższe niż zdefiniowany próg działania dla tego typu węzła, typ węzła jest oznaczony jako niezrównoważony. Aby uzyskać więcej informacji na temat konfiguracji progów aktywności metryki według typów węzłów, zapoznaj się z sekcją dotyczącą progów aktywności według typów węzłów.
• Minimalny interwał równoważenia na typ węzła ma rolę podobną do globalnie zdefiniowanego minimalnego interwału równoważenia. Dla każdego typu węzła menedżer zasobów klastra zachowuje znacznik czasu ostatniego równoważenia. Nie można wykonać dwóch kolejnych faz równoważenia w typie węzła w zdefiniowanym minimalnym interwale równoważenia. Aby uzyskać więcej informacji na temat konfiguracji minimalnego interwału równoważenia na typ węzła, zapoznaj się z sekcją Minimalny interwał równoważenia na typ węzła.

Opis równoważenia na typ węzła

Aby włączyć równoważenie dla typu węzła, parametr SeparateBalancingStrategyPerNodeType musi być włączony w manifeście klastra. Ponadto należy również włączyć funkcję podklastrowania. Przykład sekcji manifestu klastra PlacementAndLoadBalancing umożliwiającej włączenie funkcji:

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="SeparateBalancingStrategyPerNodeType" Value="true" />
    <Parameter Name="SubclusteringEnabled" Value="true" />
    <Parameter Name="SubclusteringReportingPolicy" Value="1" />
</Section>

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

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "SeparateBalancingStrategyPerNodeType",
          "value": "true"
      },
      {
          "name": "SubclusteringEnabled",
          "value": "true"
      },
      {
          "name": "SubclusteringReportingPolicy",
          "value": "1"
      },
    ]
  }
]

Jak opisano w poprzedniej sekcji, progi i interwały można określić dla typu węzła. Aby uzyskać więcej informacji na temat aktualizowania określonego parametru, zapoznaj się z następującymi sekcjami:

• Progi równoważenia metryk na typ węzła
• Progi aktywności metryk dla typów węzłów
• Minimalny interwał równoważenia na typ węzła

Progi równoważenia na typ węzła

Próg równoważenia metryk można zdefiniować dla każdego typu węzła, aby zwiększyć szczegółowość konfiguracji równoważenia. Progi równoważenia mają typ zmiennoprzecinkowy, ponieważ reprezentują próg współczynnika maksymalnej i minimalnej wartości obciążenia w określonym typie węzła. Progi równoważenia są definiowane w sekcji PlacementAndLoadBalancingOverrides dla każdego typu węzła:

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MetricBalancingThresholdsPerNodeType>
                <BalancingThreshold Name="Metric1" Value="2.5">
                <BalancingThreshold Name="Metric2" Value="4">
                <BalancingThreshold Name="Metric3" Value="3.25">
            </MetricBalancingThresholdsPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Jeśli dla typu węzła nie zdefiniowano progu równoważenia dla metryki, wtedy próg ten przyjmuje wartość globalnie zdefiniowanego progu równoważenia metryki w sekcji PlacementAndLoadBalancing. W przeciwnym razie, jeśli próg równoważenia dla metryki nie jest zdefiniowany ani dla typu węzła, ani globalnie w sekcji PlacementAndLoadBalancing , próg będzie miał wartość domyślną jednego.

Progi działań na typ węzła

Próg aktywności metryki można zdefiniować dla każdego typu węzła, aby poprawić dokładność konfiguracji równoważenia. Progi działań mają typ całkowity, ponieważ reprezentują próg maksymalnej wartości obciążenia w określonym typie węzła. Progi działań są definiowane w sekcji PlacementAndLoadBalancingOverrides dla każdego typu węzła:

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MetricActivityThresholdsPerNodeType>
                <ActivityThreshold Name="Metric1" Value="500">
                <ActivityThreshold Name="Metric2" Value="40">
                <ActivityThreshold Name="Metric3" Value="1000">
            </MetricActivityThresholdsPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Jeśli próg działania dla metryki nie jest zdefiniowany dla typu węzła, próg dziedziczy wartość z progu działania metryki zdefiniowanego globalnie w sekcji PlacementAndLoadBalancing . W przeciwnym razie, jeśli próg działania dla metryki nie jest zdefiniowany ani dla typu węzła, ani globalnie w sekcji PlacementAndLoadBalancing , próg będzie miał wartość domyślną zero.

Minimalny interwał równoważenia na typ węzła

Minimalny interwał równoważenia można zdefiniować na typ węzła, aby zwiększyć stopień szczegółowości konfiguracji równoważenia. Minimalny interwał równoważenia ma typ całkowity, ponieważ reprezentuje minimalny czas, który musi przejść przed dwoma kolejnymi rundami równoważenia w tym samym typie węzła. Minimalny interwał równoważenia jest zdefiniowany w sekcji PlacementAndLoadBalancingOverrides dla każdego typu węzła:

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MinLoadBalancingIntervalPerNodeType>100</MinLoadBalancingIntervalPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Jeśli minimalny interwał równoważenia nie jest zdefiniowany dla typu węzła, interwał dziedziczy wartość z minimalnego interwału równoważenia zdefiniowanego globalnie w sekcji PlacementAndLoadBalancing . W przeciwnym razie, jeśli minimalny interwał nie jest zdefiniowany ani dla typu węzła, ani globalnie w sekcji PlacementAndLoadBalancing , minimalny interwał będzie miał wartość domyślną zero , co oznacza, że wstrzymanie między kolejnymi rundami równoważenia nie jest wymagane.

Przykłady

Przykład 1

Rozważmy przypadek, w którym klaster zawiera dwa typy węzłów, typ węzła A i typ węzła B. Wszystkie usługi raportują tę samą metrykę i są podzielone między te typy węzłów, dlatego statystyki obciążenia są dla nich różne. W przykładzie typ węzła A ma maksymalne obciążenie 300 i minimum 100, a typ węzła B ma maksymalne obciążenie 700 i minimalne obciążenie 500:

Klient wykrył, że obciążenia dwóch typów węzłów mają różne potrzeby w zakresie równoważenia i postanowił ustawić różne progi równoważenia i aktywności na typ węzła. Próg równoważenia typu węzła A wynosi 2,5, a próg działania wynosi 50. W przypadku typu węzła B klient ustawił próg równoważenia na 1,2, a próg działania na 400.

Podczas wykrywania dysproporcji klastra w tym przykładzie oba typy węzłów naruszają próg działania. Maksymalne obciążenie typu węzła A300 jest wyższe niż zdefiniowany próg działania wynoszący 50. Maksymalne obciążenie typu węzła B700 jest wyższe niż zdefiniowany próg działania wynoszący 400. Typ węzła A narusza kryteria progowe równoważenia, ponieważ bieżący stosunek maksymalnego i minimalnego obciążenia wynosi 3, a próg równoważenia wynosi 2,5. Odwrotnie, typ węzła B nie narusza kryteriów progowych równoważenia, ponieważ bieżący stosunek maksymalnego i minimalnego obciążenia dla tego typu węzła wynosi 1,2, ale próg równoważenia wynosi 1,4. Równoważenie jest wymagane tylko w przypadku replik w węźle typu A, a jedynym zestawem replik, które będą kwalifikować się do przenoszenia podczas fazy równoważenia, są repliki umieszczone w węźle typu A.

Przykład 2

Rozważmy przypadek, w którym klaster zawiera trzy typy węzłów, typ węzła A, B i C. Wszystkie usługi raportują tę samą metrykę i są podzielone między te typy węzłów, dlatego statystyki obciążenia są dla nich różne. W przykładzie typ węzła A ma maksymalne obciążenie 600 i co najmniej 100, typ węzła B ma maksymalne obciążenie 900 i minimalne obciążenie 100, a typ węzła C ma maksymalne obciążenie 600 i minimalne obciążenie 300:

Klient wykrył, że obciążenia tych typów węzłów mają różne potrzeby w zakresie równoważenia i postanowił ustawić różne progi równoważenia i aktywności na typ węzła. Próg równoważenia typu węzła A wynosi 5, a próg działania wynosi 700. W przypadku typu węzła B klient ustawił próg równoważenia na 10, a próg działania na 200. W przypadku typu węzła C klient ustawił próg równoważenia na 2, a próg działania na 300.

Maksymalne obciążenie typu węzła A600 jest niższe niż zdefiniowany próg działania wynoszący 700, dlatego typ węzła A nie będzie zrównoważony. Maksymalne obciążenie typu węzła B900 jest wyższe niż zdefiniowany próg działania wynoszący 200. Typ węzła B narusza kryteria progu działania. Maksymalne obciążenie typu węzła C600 jest wyższe niż zdefiniowany próg działania wynoszący 300. Typ węzła C narusza kryteria progu działania. Typ węzła B nie narusza kryteriów progowych równoważenia, ponieważ bieżący stosunek maksymalnego i minimalnego obciążenia dla tego typu węzła wynosi 9, ale próg równoważenia wynosi 10. Typ węzła C narusza kryteria progowe równoważenia, ponieważ bieżący stosunek maksymalnego i minimalnego obciążenia wynosi 2, a próg równoważenia wynosi 2. Równoważenie jest wymagane tylko w przypadku replik w węźle typu C, a jedynym zestawem replik, które będą kwalifikować się do przenoszenia podczas fazy równoważenia, są repliki umieszczone w typie węzła C.

Następne kroki

• Metryki to sposób, w jaki menedżer zasobów klastra usługi Service Fabric zarządza zużyciem i pojemnością w klastrze. Aby dowiedzieć się więcej o metrykach i sposobie ich konfigurowania, zapoznaj się z artykułem dotyczącym metryk
• Koszt przenoszenia jest jednym ze sposobów sygnalizowania do menedżera zasobów klastra, że niektóre usługi są droższe do przeniesienia niż inne. Aby uzyskać więcej informacji na temat kosztów przenoszenia, zapoznaj się z artykułem Dotyczącym kosztów przenoszenia
• Menedżer zasobów klastra ma kilka ograniczń, które można skonfigurować w celu spowolnienia zmian w klastrze. Nie są one zwykle niezbędne, ale jeśli ich potrzebujesz, możesz dowiedzieć się o nich z artykułu dotyczącego zaawansowanego ograniczania przepustowości.
• Menedżer zasobów klastra może rozpoznawać i obsługiwać podklasteryzację. Gdy używasz ograniczeń umieszczania i balansowania, może wystąpić podklastrowanie. Aby dowiedzieć się, jak podklastryzacja może mieć wpływ na równoważenie i sposób jego obsługi, zobacz artykuł dotyczący podklastryzacji