Równoważenie klastra usługi Service Fabric

Klaster usługi Service Fabric Resource Manager obsługuje dynamiczne zmiany obciążenia, reagując na dodatki lub usuwanie węzłów lub usług. Automatycznie poprawia również naruszenia ograniczeń i proaktywnie ponownie równoważy klaster. Ale jak często są podejmowane te akcje i jakie wyzwalają je?

Istnieją trzy różne kategorie pracy wykonywanej przez Resource Manager 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 poprawia naruszenia różnych ograniczeń umieszczania (reguł) w systemie. Przykłady reguł są takie jak zapewnienie, że węzły nie są nadmiernie pojemności i że ograniczenia umieszczania usługi są spełnione.
• Równoważenie — ten etap sprawdza, czy ponowne równoważenie jest wymagane 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 Resource Manager klastra

Pierwszy zestaw kontrolek wokół równoważenia to zestaw czasomierzy. Te czasomierze określają, jak często klaster Resource Manager bada klaster i podejmuje działania naprawcze.

Każdy z tych różnych typów poprawek, które można wprowadzić w Resource Manager 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 pliku 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 klaster Resource Manager wykonuje tylko jedną z tych akcji jednocześnie, sekwencyjnie. Dlatego nazywamy te czasomierze "minimalnymi interwałami" i akcjami, które są podejmowane po wyłączeniu czasomierzy jako "flagi ustawiania". Na przykład klaster Resource Manager zajmuje się oczekującymi żądaniami tworzenia usług przed równoważeniem klastra. Jak widać według domyślnych interwałów czasu określonych, klaster Resource Manager skanuje pod kątem wszystkich elementów, które należy wykonać często. Zwykle oznacza to, że zestaw zmian wprowadzonych w każdym kroku jest mały. Małe, częste zmiany pozwalają klastrowi Resource Manager reagować, gdy coś się stanie w klastrze. Domyślne czasomierze zapewniają 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ą to zrobić jednocześnie całe domeny błędów. Wszystkie te błędy są przechwytywane podczas następnej aktualizacji stanu po plBRefreshGap. Poprawki są określane podczas wykonywania następujących operacji umieszczania, sprawdzania ograniczeń i równoważenia. Domyślnie Resource Manager klastra nie skanuje godzin zmian w klastrze i próbuje jednocześnie rozwiązać wszystkie zmiany. W ten sposób doprowadziłoby to do wybuchów zmian.

Klaster Resource Manager również potrzebuje dodatkowych informacji, aby ustalić, czy nierównowaga klastra. W tym celu mamy dwie 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 tę metrykę BalancingThreshold, klaster jest nierównowagowany. W wyniku równoważenia jest wyzwalane przy następnym sprawdzaniu Resource Manager klastra. Czasomierz MinLoadBalancingInterval określa, jak często Resource Manager klaster powinien sprawdzić, czy konieczne jest ponowne równoważenie. Sprawdzanie nie oznacza, że coś się dzieje.

Progi równoważenia są definiowane w oparciu o metrykę jako część definicji klastra. Aby uzyskać więcej informacji na temat metryk, zapoznaj się z artykułem metryk.

ClusterManifest.xml

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

za pośrednictwem pliku 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 pierwszym przykładzie maksymalny 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 trzech, klaster jest zrównoważony. Podczas sprawdzania Resource Manager klastra nie jest wyzwalane żadne równoważenie.

W dolnej części przykładu maksymalne obciążenie węzła wynosi 10, a minimum to dwa, co skutkuje współczynnikiem 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ż klaster usługi Service Fabric Resource Manager nie używa 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 klaster Resource Manager jest rozłożenie obciążenia między węzłami w klastrze. Drugą strategią jest defragmentacja. Defragmentacja jest wykonywana podczas tego samego uruchomienia 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 współczynnik obciążeń w klastrze wyzwala ponowne równoważenie, gdy jest on niższy od progu równoważenia.

Uzyskanie poniżej progu równoważenia nie jest wyraźnym celem. Progi równoważenia to tylko wyzwalacz. Po uruchomieniu równoważenia klaster Resource Manager 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, aby poprawić. Alternatywnie ulepszenia wymagają ruchów, które są zbyt kosztowne).

Progi działań

Czasami, chociaż węzły są stosunkowo nierównowagowane, łą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ż niewiele trzeba zdobyć. 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 aktywności. Progi działań umożliwiają określenie 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 zostanie osiągnięty próg równoważenia.

Załóżmy, że zachowamy nasz próg równoważenia trzech dla tej metryki. Załóżmy również, że mamy próg aktywności 1536. W pierwszym przypadku, gdy klaster jest nierównowagowany na próg równoważenia, nie ma żadnego węzła spełnia 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, zaplanowano równoważenie. Na przykład przyjrzyjmy się następującej ilustracji:

Podobnie jak w przypadku progów równoważenia progi działań są definiowane na metryki za pośrednictwem definicji klastra:

ClusterManifest.xml

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

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

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

Progi równoważenia 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 Resource Manager klaster 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. Naprawimy ją jednak, przenosząc poszczególne repliki usług i wystąpienia. To ma sens, prawda? Jeśli pamięć jest skumulowana w jednym węźle, wiele replik lub wystąpień może być współtworzenia. Naprawienie dysproporcji może wymagać przeniesienia dowolnej replik stanowej lub wystąpień bezstanowych, które używają metryki nierównowagowanej.

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 zostałaby 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 zgłasza metryki Metryki 2 i Metryki 3.
• Usługa 3 raportuje metryki Metryki 3 i Metryka 4.
• Usługa 4 zgłasza metryki metryki 99.

Nie mamy naprawdę czterech niezależnych usług, mamy trzy usługi, które są powiązane i jeden, który jest wyłączony samodzielnie.

Ze względu na ten łańcuch istnieje możliwość, że nierównowaga metryk 1–4 może spowodować przenoszenie replik lub wystąpień należących do usług 1–3. Wiemy również, że nierównowaga metryk 1, 2 lub 3 nie może powodować ruchów w usłudze 4. Nie byłoby sensu, 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.

Klaster Resource Manager 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 uruchomieniami usługi równoważenia 2 mogły zostać zaktualizowane w celu usunięcia metryki 2. Spowoduje to przerwanie łańcucha między usługą 1 a usługą 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. Klaster usługi Service Fabric Resource Manager zapewnia bardziej szczegółową kontrolę nad wyzwalaniem ponownego równoważenia przy użyciu określania parametrów na typ węzła i zezwalania na przenoszenie tylko w przypadku niezrównoważonych typów 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 nierównowagi jest obliczane dla każdego typu węzła. Jeśli wszystkie typy węzłów są zrównoważone, moduł CRM nie wyzwoli fazy równoważenia. W przeciwnym razie, jeśli co najmniej jeden typ węzła jest niezrównoważony, wymagana jest faza równoważenia.
• Równoważenie przenosi repliki tylko w typach węzłów, które są nierównowagowane, 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 klaster usługi Service Fabric Resource Manager oblicza stan nierównowagi 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ą nierównowagowane, 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 stanu nierównowagi używa typowych mechanizmów dostępnych już na potrzeby klasycznego równoważenia klastra, ale poprawia stopień szczegółowości i elastyczności konfiguracji. Mechanizmy używane do równoważenia typu węzła do wykrywania nierównowagi znajdują się 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 ten 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 metryk 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 globalnego 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 nierównowaga. Aby uzyskać więcej informacji na temat konfiguracji progów aktywności metryk 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 klaster Resource Manager 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 szczegółów dotyczących 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.

Opisywanie 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 służącej do włączania 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ć na typ 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

Równoważenie progów 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 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 zostać przekazany 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 zgłaszają tę samą metrykę i są one 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 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 nierównowagi dla 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 dla 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 typie węzła 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 zgłaszają tę samą metrykę i są one 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 minimum 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 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 typu C węzła, 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 zasób 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 metryk
• Koszt przenoszenia jest jednym ze sposobów sygnalizowania klastra Resource Manager, ż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
• Klaster Resource Manager 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
• Klaster Resource Manager może rozpoznawać i obsługiwać podklasy. Podklasowanie może wystąpić, gdy używasz ograniczeń umieszczania i równoważenia. Aby dowiedzieć się, jak podklasowanie może wpływać na równoważenie i jak można go obsłużyć, zobacz artykuł dotyczący podklasowania