Równoważenie klastra usługi 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 usuwanie replik lub wystąpień jest obsługiwane tutaj.
• 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ą ponad pojemnością i że są spełnione ograniczenia umieszczania 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 usługa 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" i akcjami, które są wykonywane, gdy czasomierze wyłączają się jako "flagi ustawiania". Na przykład menedżer zasobów klastra zajmuje się oczekującymi żądaniami utworzenia usług przed równoważeniem klastra. Jak widać, domyślnie określone interwały czasu, menedżer zasobów klastra skanuje pod kątem wszystkich elementów, które należy często wykonywać. 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 reagowanie w przypadku wystąpienia w klastrze elementów. 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 kończą się niepowodzeniem, mogą zrobić to całe domeny błędów 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 skanuje godzin zmian w klastrze i próbuje jednocześnie rozwiązać wszystkie zmiany. To doprowadziłoby do pęknięć zmian.

Menedżer zasobów klastra potrzebuje również pewnych dodatkowych informacji, aby określić, czy nierównowaga klastra. 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 obciążenie metryki na najbardziej załadowanym węźle podzielonym przez ilość obciążenia na najmniej załadowanym węźle przekracza wartość RównoważenieThreshold metryki, klaster jest niezrównoważony. W wyniku równoważenia zostanie wyzwolona przy następnym sprawdzeniu usługi Resource Manager 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 menedżera zasobów klastra nie jest wyzwalane żadne równoważenie.

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 uruchomienie ponownego równoważenia zostanie zaplanowane przy następnym uruchomieniu czasomierza 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 wykonywana podczas 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.

Uzyskanie poniżej progu równoważenia nie jest jawnym celem. Progi równoważenia to tylko wyzwalacz. W przypadku uruchamiania równoważenia menedżer zasobów klastra określa, jakie ulepszenia może wprowadzić, jeśli istnieje. Tylko dlatego, że wyszukiwanie równoważenia jest uruchamiane, nie oznacza żadnych ruchów. Czasami klaster jest niezrównoważony, ale zbyt ograniczony do poprawienia. Alternatywnie ulepszenia wymagają ruchów, które są zbyt kosztowne).

Progi działań

Czasami, chociaż węzły są stosunkowo niezrównoważony, łączna ilość obciążenia w klastrze jest niska. Brak obciążenia może być przejściowym spadkiem lub dlatego, że klaster jest nowy i po prostu jest uruchamiany. W obu przypadkach możesz nie chcieć poświęcić czasu na równoważenie klastra, ponieważ nie ma miejsca do zdobycia. Jeśli klaster przeszedł równoważenie, należy wydać zasoby sieciowe i obliczeniowe, aby przenosić elementy bez konieczności dokonywania dużej różnicy bezwzględnej . 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 działania 1536. W pierwszym przypadku, gdy klaster jest niezrównoważony na próg równoważenia, nie ma węzła spełniającego ten próg 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, progi działania są definiowane na metryki za pośrednictwem 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

Niezależnie od tego, czy klaster jest niezrównoważony, czy nie, jest decyzją w całym klastrze. Jednak naprawimy ją, przenosząc poszczególne repliki usług i wystąpienia wokół. To ma sens, prawda? Jeśli pamięć jest stosowana w jednym węźle, współtworzenia wielu replik lub wystąpień. Naprawienie dysproporcji może wymagać przeniesienia dowolnej replik stanowej lub wystąpień bezstanowych korzystających z niezrównoważonych metryk.

Czasami jednak usługa, która nie była sama niezrównoważona, zostaje przeniesiona (pamiętaj o dyskusji na temat lokalnych i globalnych wag wcześniej). Dlaczego usługa zostanie przeniesiona, gdy wszystkie metryki usługi zostały 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 Metryki 2 i Metryka 3.
• Usługa 3 raportuje metryki Metryki 3 i Metryka 4.
• Usługa 4 raportuje metryki metryki 99.

Naprawdę nie mamy czterech niezależnych usług, mamy trzy powiązane usługi i te, które są wyłączone samodzielnie.

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 mogą się poruszać. Wiemy również, że brak równowagi w metrykach 1, 2 lub 3 nie może powodować ruchów 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 na typ 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ę na typ 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 mają wpływu na fazę równoważenia.

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

Podczas równoważenia klastra na typ 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. Faza równoważenia nie przenosi 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 interwał równoważenia nie został przekazany 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 typu węzła do wykrywania nierównowagi są dostępne 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 aktywności metryki na typ węzła, zapoznaj się z sekcją Progi równoważenia na typ węzła.
• Progi działań metryk na typ węzła to wartości, które mają podobną rolę do globalnie zdefiniowanego progu działania używanego w równoważeniu klasycznym. Maksymalne obciążenie 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 na typ węzła, zapoznaj się z sekcją Progi aktywności na węzeł.
• 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 włączyć funkcję podklasowania. Przykład sekcji umieszczania manifestu klastraAndLoadBalancing 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 działań metryk na typ węzła
• 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ć na typ węzła, aby zwiększyć stopień szczegółowości konfiguracji równoważenia. Progi równoważenia mają typ zmiennoprzecinkowa, ponieważ reprezentują one próg dla 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 próg równoważenia dla metryki nie jest zdefiniowany dla typu węzła, próg dziedziczy wartość progu równoważenia metryki zdefiniowanej globalnie 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 działania metryki można zdefiniować na typ węzła, aby zwiększyć stopień szczegółowości 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 A 300 jest wyższe niż zdefiniowany próg działania wynoszący 50. Maksymalne obciążenie typu węzła B 700 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 A 600 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 B 900 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 C 600 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 zaawansowany artykuł dotyczący ograniczania przepustowości
• Menedżer zasobów klastra może rozpoznawać podklasy i obsługiwać podklasy. W przypadku używania ograniczeń umieszczania i równoważenia może wystąpić podklasowanie. Aby dowiedzieć się, jak podklasowanie może mieć wpływ na równoważenie i sposób jego obsługi, zobacz artykuł dotyczący podklasy