Udostępnij za pośrednictwem

Zarządzanie zużyciem zasobów i ładowaniem w usłudze Service Fabric przy użyciu metryk

  • Artykuł

Metryki to zasoby, o które dbają Usługi i które są udostępniane przez węzły w klastrze. Metryka to wszystko, co chcesz zarządzać w celu poprawy lub monitorowania wydajności usług. Możesz na przykład obserwować użycie pamięci, aby sprawdzić, czy usługa jest przeciążona. Innym zastosowaniem jest ustalenie, czy usługa może przenieść się gdzie indziej, gdzie pamięć jest mniej ograniczona, aby uzyskać lepszą wydajność.

Przykłady metryk, takich jak pamięć, dysk i użycie procesora CPU. Te metryki to metryki fizyczne, zasoby, które odpowiadają zasobom fizycznym w węźle, które muszą być zarządzane. Metryki mogą być również (i często są) metrykami logicznymi. Metryki logiczne to takie elementy jak "MyWorkQueueDepth" lub "MessagesToProcess" lub "TotalRecords". Metryki logiczne są definiowane przez aplikację i pośrednio odpowiadają zużyciu zasobów fizycznych. Metryki logiczne są typowe, ponieważ może być trudne do mierzenia i raportowania zużycia zasobów fizycznych na podstawie poszczególnych usług. Złożoność mierzenia i raportowania własnych metryk fizycznych jest również powodem, dla których usługa Service Fabric udostępnia niektóre domyślne metryki.

Domyślne metryki

Załóżmy, że chcesz rozpocząć pisanie i wdrażanie usługi. W tym momencie nie wiesz, jakie zasoby fizyczne lub logiczne zużywają. To dobrze! Menedżer zasobów klastra usługi Service Fabric używa niektórych domyślnych metryk, jeśli nie określono żadnych innych metryk. Są to:

  • PrimaryCount — liczba replik podstawowych w węźle
  • ReplicaCount — liczba wszystkich replik stanowych w węźle
  • Count — liczba wszystkich obiektów usługi (bezstanowych i stanowych) w węźle
Metric Ładowanie wystąpienia bezstanowego Stanowe obciążenie pomocnicze Stanowe obciążenie podstawowe Weight
PrimaryCount 0 0 1 Wys.
ReplicaCount 0 1 1 Śred.
Licznik 1 1 1 Niski

W przypadku podstawowych obciążeń domyślne metryki zapewniają przyzwoity rozkład pracy w klastrze. W poniższym przykładzie zobaczmy, co się stanie, gdy utworzymy dwie usługi i będziemy polegać na domyślnych metrykach równoważenia. Pierwsza usługa to usługa stanowa z trzema partycjami i docelowym zestawem repliki o rozmiarze trzech. Druga usługa jest usługą bezstanową z jedną partycją i liczbą wystąpień wynoszącą trzy.

Oto co otrzymujemy:

Układ klastra z domyślnymi metrykami

Niektóre kwestie do zapamiętania:

  • Repliki podstawowe dla usługi stanowej są dystrybuowane między kilka węzłów
  • Repliki dla tej samej partycji znajdują się w różnych węzłach
  • Łączna liczba prawyborów i drugich jest dystrybuowana w klastrze
  • Łączna liczba obiektów usługi jest równomiernie przydzielana w każdym węźle

Dobry!

Domyślne metryki działają świetnie jako początek. Jednak domyślne metryki będą prowadzić tylko do tej pory. Na przykład: Jakie jest prawdopodobieństwo, że wybrany schemat partycjonowania daje idealnie równomierne wykorzystanie przez wszystkie partycje? Jakie jest prawdopodobieństwo, że obciążenie danej usługi jest stałe w czasie, a nawet po prostu takie samo w wielu partycjach w tej chwili?

Możesz uruchomić polecenie przy użyciu tylko domyślnych metryk. Jednak zwykle oznacza to, że wykorzystanie klastra jest niższe i bardziej nierówne niż chcesz. Dzieje się tak, ponieważ domyślne metryki nie są adaptacyjne i zakładają, że wszystko jest równoważne. Na przykład element podstawowy, który jest zajęty, i taki, który nie współtworzy "1" do metryki PrimaryCount. W najgorszym przypadku użycie tylko domyślnych metryk może również spowodować nadmierne zaplanowane węzły, co powoduje problemy z wydajnością. Jeśli chcesz jak najlepiej wykorzystać klaster i uniknąć problemów z wydajnością, musisz użyć niestandardowych metryk i dynamicznego raportowania obciążenia.

Metryki niestandardowe

Metryki są konfigurowane dla poszczególnych nazwanych wystąpień usługi podczas tworzenia usługi.

Każda metryka ma pewne właściwości, które ją opisują: nazwę, wagę i domyślne obciążenie.

  • Nazwa metryki: nazwa metryki. Nazwa metryki jest unikatowym identyfikatorem metryki w klastrze z perspektywy usługi Resource Manager.

Uwaga

Nazwa metryki niestandardowej nie powinna być żadną z nazw metryk systemowych, tj. servicefabric:/_CpuCores lub servicefabric:/_MemoryInMB, ponieważ może prowadzić do niezdefiniowanego zachowania. Począwszy od usługi Service Fabric w wersji 9.1, w przypadku istniejących usług z tymi niestandardowymi nazwami metryk zostanie wyświetlone ostrzeżenie o kondycji wskazujące, że nazwa metryki jest niepoprawna.

  • Waga: Waga metryki definiuje, jak ważna jest ta metryka względem innych metryk dla tej usługi.
  • Ładowanie domyślne: domyślne obciążenie jest reprezentowane inaczej w zależności od tego, czy usługa jest bezstanowa, czy stanowa.
    • W przypadku usług bezstanowych każda metryka ma jedną właściwość o nazwie DefaultLoad
    • W przypadku zdefiniowanych usług stanowych:
      • PrimaryDefaultLoad: domyślna ilość tej metryki zużywana przez tę usługę, gdy jest to podstawowa
      • SecondaryDefaultLoad: domyślna ilość tej metryki zużywana przez tę usługę, gdy jest to pomocnicza

Uwaga

Jeśli zdefiniujesz metryki niestandardowe i chcesz również użyć domyślnych metryk, musisz jawnie dodać domyślne metryki z powrotem i zdefiniować dla nich wagi i wartości. Jest to spowodowane tym, że należy zdefiniować relację między domyślnymi metrykami a metrykami niestandardowymi. Na przykład możesz dbać o wartość ConnectionCount lub WorkQueueDepth więcej niż dystrybucja podstawowa. Domyślnie waga metryki PrimaryCount ma wartość Wysoka, więc chcesz zmniejszyć ją do średniej po dodaniu innych metryk, aby upewnić się, że mają pierwszeństwo.

Definiowanie metryk dla usługi — przykład

Załóżmy, że chcesz mieć następującą konfigurację:

  • Twoja usługa zgłasza metrykę o nazwie "ConnectionCount"
  • Chcesz również użyć domyślnych metryk
  • Wykonano kilka pomiarów i wiesz, że zwykle replika podstawowa tej usługi zajmuje 20 jednostek "ConnectionCount"
  • Drugich używa 5 jednostek "ConnectionCount"
  • Wiesz, że "ConnectionCount" to najważniejsza metryka pod względem zarządzania wydajnością tej konkretnej usługi
  • Nadal chcesz zrównoważyć repliki podstawowe. Równoważenie replik podstawowych jest ogólnie dobrym pomysłem niezależnie od tego, co. Pomaga to zapobiec utracie niektórych węzłów lub domeny błędów, które mają wpływ na większość replik podstawowych wraz z nią.
  • W przeciwnym razie domyślne metryki są w porządku

Oto kod, który chcesz napisać, aby utworzyć usługę z konfiguracją tej metryki:

Kod:

StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
StatefulServiceLoadMetricDescription connectionMetric = new StatefulServiceLoadMetricDescription();
connectionMetric.Name = "ConnectionCount";
connectionMetric.PrimaryDefaultLoad = 20;
connectionMetric.SecondaryDefaultLoad = 5;
connectionMetric.Weight = ServiceLoadMetricWeight.High;

StatefulServiceLoadMetricDescription primaryCountMetric = new StatefulServiceLoadMetricDescription();
primaryCountMetric.Name = "PrimaryCount";
primaryCountMetric.PrimaryDefaultLoad = 1;
primaryCountMetric.SecondaryDefaultLoad = 0;
primaryCountMetric.Weight = ServiceLoadMetricWeight.Medium;

StatefulServiceLoadMetricDescription replicaCountMetric = new StatefulServiceLoadMetricDescription();
replicaCountMetric.Name = "ReplicaCount";
replicaCountMetric.PrimaryDefaultLoad = 1;
replicaCountMetric.SecondaryDefaultLoad = 1;
replicaCountMetric.Weight = ServiceLoadMetricWeight.Low;

StatefulServiceLoadMetricDescription totalCountMetric = new StatefulServiceLoadMetricDescription();
totalCountMetric.Name = "Count";
totalCountMetric.PrimaryDefaultLoad = 1;
totalCountMetric.SecondaryDefaultLoad = 1;
totalCountMetric.Weight = ServiceLoadMetricWeight.Low;

serviceDescription.Metrics.Add(connectionMetric);
serviceDescription.Metrics.Add(primaryCountMetric);
serviceDescription.Metrics.Add(replicaCountMetric);
serviceDescription.Metrics.Add(totalCountMetric);

await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Program PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ConnectionCount,High,20,5”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

Uwaga

W powyższych przykładach i w pozostałej części tego dokumentu opisano zarządzanie metrykami dla poszczególnych nazwanych usług. Istnieje również możliwość zdefiniowania metryk dla usług na poziomie typu usługi. Można to osiągnąć, określając je w manifestach usługi. Definiowanie metryk na poziomie typu nie jest zalecane z kilku powodów. Pierwszą przyczyną jest to, że nazwy metryk są często specyficzne dla środowiska. Chyba że istnieje umowa firmowa, nie można mieć pewności, że metryka "Rdzenie" w jednym środowisku nie jest "MiliCores" ani "CoReS" w innych. Jeśli metryki są zdefiniowane w manifeście, musisz utworzyć nowe manifesty dla każdego środowiska. Zwykle prowadzi to do rozprzestrzeniania się różnych manifestów tylko z niewielkimi różnicami, co może prowadzić do trudności z zarządzaniem.

Obciążenia metryki są często przypisywane dla poszczególnych nazwanych wystąpień usługi. Załóżmy na przykład, że utworzysz jedno wystąpienie usługi dla customerA, które planuje używać go tylko lekko. Załóżmy również, że utworzysz kolejną dla klientów, którzy mają większe obciążenie. W takim przypadku prawdopodobnie chcesz dostosować domyślne obciążenia dla tych usług. Jeśli masz metryki i obciążenia zdefiniowane za pośrednictwem manifestów i chcesz obsługiwać ten scenariusz, wymaga różnych typów aplikacji i usług dla każdego klienta. Wartości zdefiniowane w czasie tworzenia usługi zastępują wartości zdefiniowane w manifeście, dzięki czemu można użyć ich do ustawienia określonych wartości domyślnych. Jednak powoduje to, że wartości zadeklarowane w manifestach nie pasują do tych, z którymi usługa rzeczywiście jest uruchamiana. Może to prowadzić do nieporozumień.

Przypomnienie: jeśli chcesz po prostu używać domyślnych metryk, nie musisz w ogóle dotykać kolekcji metryk ani wykonywać żadnych specjalnych czynności podczas tworzenia usługi. Domyślne metryki są używane automatycznie, gdy nie zdefiniowano innych.

Teraz przyjrzyjmy się dokładniej każdemu z tych ustawień i omówimy zachowanie, które ma to wpływ.

Ładowanie

Cały punkt definiowania metryk polega na reprezentowaniu pewnego obciążenia. Obciążenie to ilość danej metryki używanej przez niektóre wystąpienie usługi lub replikę w danym węźle. Obciążenie można skonfigurować niemal w dowolnym momencie. Na przykład:

  • Ładowanie można zdefiniować podczas tworzenia usługi. Ten typ konfiguracji ładowania nosi nazwę ładowania domyślnego.
  • Informacje o metryce, w tym obciążenia domyślne, można zaktualizować dla usługi po utworzeniu usługi. Ta aktualizacja metryki jest wykonywana przez zaktualizowanie usługi.
  • Obciążenia dla danej partycji można zresetować do wartości domyślnych dla tej usługi. Ta aktualizacja metryki jest nazywana resetowaniem obciążenia partycji.
  • Obciążenie można zgłaszać na podstawie poszczególnych obiektów usługi, dynamicznie podczas wykonywania. Ta aktualizacja metryki jest nazywana obciążeniem raportowania.
  • Ładowanie replik lub wystąpień partycji można również zaktualizować przez raportowanie wartości obciążenia za pośrednictwem wywołania interfejsu API sieci szkieletowej. Ta aktualizacja metryki jest nazywana obciążeniem raportowania dla partycji.

Wszystkie te strategie mogą być używane w ramach tej samej usługi w okresie jej istnienia.

Ładowanie domyślne

Domyślne obciążenie to ilość metryki używanej przez każdy obiekt usługi (wystąpienie bezstanowe lub replika stanowa). Menedżer zasobów klastra używa tej liczby do ładowania obiektu usługi, dopóki nie otrzyma innych informacji, takich jak dynamiczny raport ładowania. W przypadku prostszych usług domyślnym obciążeniem jest definicja statyczna. Domyślne ładowanie nigdy nie jest aktualizowane i jest używane przez okres istnienia usługi. Domyślne obciążenia działają świetnie w przypadku prostych scenariuszy planowania pojemności, w których niektóre ilości zasobów są przeznaczone dla różnych obciążeń i nie zmieniają się.

Uwaga

Aby uzyskać więcej informacji na temat zarządzania pojemnością i definiowania pojemności dla węzłów w klastrze, zobacz ten artykuł.

Menedżer zasobów klastra umożliwia usługom stanowym określenie innego domyślnego obciążenia dla prawyborów i drugich. Usługi bezstanowe mogą określać tylko jedną wartość, która ma zastosowanie do wszystkich wystąpień. W przypadku usług stanowych domyślne obciążenie replik podstawowych i pomocniczych jest zwykle różne, ponieważ repliki wykonują różne rodzaje pracy w każdej roli. Na przykład prawybory zwykle obsługują zarówno odczyty, jak i zapisy oraz obsługują większość obciążeń obliczeniowych, podczas gdy drugie nie. Zazwyczaj domyślne obciążenie repliki podstawowej jest wyższe niż domyślne obciążenie replik pomocniczych. Rzeczywiste liczby powinny zależeć od własnych pomiarów.

Ładowanie dynamiczne

Załóżmy, że usługa była uruchomiona od jakiegoś czasu. W przypadku monitorowania zauważyliśmy, że:

  1. Niektóre partycje lub wystąpienia danej usługi zużywają więcej zasobów niż inne
  2. Niektóre usługi mają obciążenie, które różni się w czasie.

Istnieje wiele rzeczy, które mogą powodować te rodzaje wahań obciążenia. Na przykład różne usługi lub partycje są skojarzone z różnymi klientami z różnymi wymaganiami. Obciążenie może również ulec zmianie, ponieważ ilość pracy, jaką usługa wykonuje, różni się w ciągu dnia. Niezależnie od przyczyny zwykle nie ma pojedynczej liczby, której można użyć domyślnie. Jest to szczególnie istotne, jeśli chcesz uzyskać największe wykorzystanie z klastra. Dowolna wartość wybrana dla ładowania domyślnego jest nieprawidłowa w pewnym momencie. Nieprawidłowe ładowanie domyślne powoduje, że menedżer zasobów klastra jest zastępowany lub w ramach przydzielania zasobów. W związku z tym masz węzły, które są ponad lub w pełni wykorzystywane, mimo że menedżer zasobów klastra uważa, że klaster jest zrównoważony. Obciążenia domyślne są nadal dobre, ponieważ zawierają pewne informacje na temat początkowego umieszczania, ale nie są one kompletną historią dla rzeczywistych obciążeń. Aby dokładnie przechwytywać zmieniające się wymagania dotyczące zasobów, menedżer zasobów klastra umożliwia każdemu obiektowi usługi aktualizowanie własnego obciążenia podczas wykonywania. Jest to nazywane dynamicznym raportowaniem obciążenia.

Dynamiczne raporty ładowania umożliwiają replikom lub wystąpieniom dostosowanie alokacji/zgłoszonego obciążenia metryk w okresie ich istnienia. Replika usługi lub wystąpienie, które było zimne i nie wykonuje żadnej pracy, zwykle zgłasza, że używa niskich ilości danej metryki. Zajęta replika lub wystąpienie zgłasza, że używa więcej.

Raportowanie obciążenia na replikę lub wystąpienie umożliwia menedżerowi zasobów klastra reorganizację poszczególnych obiektów usługi w klastrze. Reorganizacja usług pomaga zagwarantować, że uzyskają wymagane zasoby. Zajęte usługi skutecznie uzyskują "odzyskiwanie" zasobów z innych replik lub wystąpień, które są obecnie zimne lub mniej pracy.

W usługach Reliable Services kod do dynamicznego ładowania raportów wygląda następująco:

Kod:

this.Partition.ReportLoad(new List<LoadMetric> { new LoadMetric("CurrentConnectionCount", 1234), new LoadMetric("metric1", 42) });

Usługa może zgłaszać dowolne metryki zdefiniowane dla niej w czasie tworzenia. Jeśli usługa zgłasza obciążenie metryki, która nie jest skonfigurowana do użycia, usługa Service Fabric ignoruje ten raport. Jeśli istnieją inne metryki zgłaszane w tym samym czasie, które są prawidłowe, te raporty są akceptowane. Kod usługi może mierzyć i zgłaszać wszystkie metryki, w których wie, jak to zrobić, a operatory mogą określać konfigurację metryki do użycia bez konieczności zmieniania kodu usługi.

Raportowanie obciążenia partycji

W poprzedniej sekcji opisano sposób ładowania samych replik usług lub wystąpień. Istnieje dodatkowa opcja dynamicznego raportowania obciążenia replik lub wystąpień partycji za pośrednictwem interfejsu API usługi Service Fabric. Podczas raportowania obciążenia partycji można zgłaszać wiele partycji jednocześnie.

Te raporty będą używane w dokładnie taki sam sposób, jak raporty ładowania pochodzące z samych replik lub wystąpień. Zgłoszone wartości będą prawidłowe do momentu zgłoszenia nowych wartości obciążenia przez replikę lub wystąpienie albo raportowanie nowej wartości obciążenia dla partycji.

W przypadku tego interfejsu API istnieje wiele sposobów aktualizowania obciążenia w klastrze:

  • Partycja usługi stanowej może zaktualizować obciążenie repliki podstawowej.
  • Zarówno bezstanowe, jak i stanowe usługi mogą aktualizować obciążenie wszystkich replik pomocniczych lub wystąpień.
  • Zarówno usługi bezstanowe, jak i stanowe mogą aktualizować obciążenie określonej repliki lub wystąpienia w węźle.

Istnieje również możliwość połączenia dowolnej z tych aktualizacji na partycję w tym samym czasie. Kombinacja aktualizacji obciążenia dla określonej partycji powinna być określona za pomocą obiektu PartitionMetricLoadDescription, który może zawierać odpowiednią listę aktualizacji ładowania, jak pokazano w poniższym przykładzie. Aktualizacje obciążenia są reprezentowane za pośrednictwem obiektu MetricLoadDescription, który może zawierać bieżącą lub przewidywaną wartość obciążenia dla metryki określonej za pomocą nazwy metryki.

Uwaga

Przewidywane wartości obciążenia metryki są obecnie funkcją w wersji zapoznawczej. Umożliwia ona raportowanie i używanie przewidywanych wartości obciążenia po stronie usługi Service Fabric, ale ta funkcja nie jest obecnie włączona.

Aktualizowanie obciążeń dla wielu partycji jest możliwe za pomocą jednego wywołania interfejsu API, w tym przypadku dane wyjściowe będą zawierać odpowiedź na partycję. W przypadku, gdy aktualizacja partycji nie zostanie pomyślnie zastosowana z jakiegokolwiek powodu, aktualizacje tej partycji zostaną pominięte, a odpowiedni kod błędu dla partycji docelowej zostanie udostępniony:

  • PartitionNotFound — określony identyfikator partycji nie istnieje.
  • ReconfigurationPending — partycja jest obecnie ponownie konfigurowana.
  • InvalidForStatelessServices — podjęto próbę zmiany obciążenia repliki podstawowej dla partycji należącej do usługi bezstanowej.
  • ReplicaDoesNotExist — replika pomocnicza lub wystąpienie nie istnieje w określonym węźle.
  • InvalidOperation — może się zdarzyć w dwóch przypadkach: aktualizowanie obciążenia partycji należącej do aplikacji systemowej lub aktualizowanie przewidywanego obciążenia nie jest włączone.

Jeśli zostaną zwrócone niektóre z tych błędów, możesz zaktualizować dane wejściowe dla określonej partycji i ponowić próbę aktualizacji.

Kod:

Guid partitionId = Guid.Parse("53df3d7f-5471-403b-b736-bde6ad584f42");
string metricName0 = "CustomMetricName0";
List<MetricLoadDescription> newPrimaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 100)
};

string nodeName0 = "NodeName0";
List<MetricLoadDescription> newSpecificSecondaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 200)
};

OperationResult<UpdatePartitionLoadResultList> updatePartitionLoadResults =
    await this.FabricClient.UpdatePartitionLoadAsync(
        new UpdatePartitionLoadQueryDescription
        {
            PartitionMetricLoadDescriptionList = new List<PartitionMetricLoadDescription>()
            {
                new PartitionMetricLoadDescription(
                    partitionId,
                    newPrimaryReplicaLoads,
                    new List<MetricLoadDescription>(),
                    new List<ReplicaMetricLoadDescription>()
                    {
                        new ReplicaMetricLoadDescription(nodeName0, newSpecificSecondaryReplicaLoads)
                    })
            }
        },
        this.Timeout,
        cancellationToken);

W tym przykładzie wykonasz aktualizację ostatniego zgłoszonego obciążenia partycji 53df3d7f-5471-403b-b736-bde6ad584f42. Obciążenie repliki podstawowej dla metryki CustomMetricName0 zostanie zaktualizowane o wartość 100. Jednocześnie obciążenie tej samej metryki dla określonej repliki pomocniczej znajdującej się w węźle NodeName0 zostanie zaktualizowane o wartość 200.

Aktualizowanie konfiguracji metryki usługi

Lista metryk skojarzonych z usługą oraz właściwości tych metryk można aktualizować dynamicznie, gdy usługa jest aktywna. Umożliwia to eksperymentowanie i elastyczność. Oto kilka przykładów, gdy jest to przydatne:

  • wyłączanie metryki z raportem o błędach dla określonej usługi
  • zmiana konfiguracji wag metryk na podstawie żądanego zachowania
  • włączanie nowej metryki dopiero po wdrożeniu i zweryfikowaniu kodu za pomocą innych mechanizmów
  • zmiana domyślnego obciążenia usługi na podstawie obserwowanego zachowania i zużycia

Główne interfejsy API służące do zmieniania konfiguracji metryki znajdują się FabricClient.ServiceManagementClient.UpdateServiceAsync w języku C# i Update-ServiceFabricService w programie PowerShell. Wszelkie informacje określone za pomocą tych interfejsów API zastępują istniejące informacje o metrykach dla usługi natychmiast.

Mieszanie domyślnych wartości obciążenia i dynamicznych raportów obciążenia

Domyślne ładowanie i obciążenia dynamiczne mogą być używane dla tej samej usługi. Gdy usługa korzysta zarówno z raportów ładowania domyślnego, jak i dynamicznego ładowania, domyślne obciążenie służy jako oszacowanie do momentu wyświetlenia raportów dynamicznych. Domyślne ładowanie jest dobre, ponieważ zapewnia menedżerowi zasobów klastra coś do pracy. Domyślne obciążenie umożliwia menedżerowi zasobów klastra umieszczenie obiektów usługi w dobrych lokalizacjach podczas ich tworzenia. Jeśli nie podano żadnych domyślnych informacji o obciążeniu, umieszczanie usług jest w rzeczywistości losowe. Gdy raporty ładowania docierają później, początkowe losowe umieszczanie jest często nieprawidłowe, a menedżer zasobów klastra musi przenieść usługi.

Przyjrzyjmy się naszemu poprzedniemu przykładowi i zobaczmy, co się stanie po dodaniu niestandardowych metryk i dynamicznego raportowania obciążenia. W tym przykładzie jako przykładowa metryka używamy ciągu "MemoryInMb".

Uwaga

Pamięć jest jedną z metryk systemowych, którymi usługa Service Fabric może zarządzać zasobami, a raportowanie jest zwykle trudne. Nie spodziewamy się raportowania użycia pamięci; Pamięć jest używana tutaj jako pomoc w poznawaniu możliwości usługi Resource Manager klastra.

Załóżmy, że początkowo utworzyliśmy usługę stanową za pomocą następującego polecenia:

Program PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("MemoryInMb,High,21,11”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

Przypominamy, że ta składnia to ("MetricName, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad").

Zobaczmy, jak może wyglądać jeden możliwy układ klastra:

Klaster z równoważeniem zarówno z metrykami domyślnymi, jak i niestandardowymi

Warto zauważyć niektóre kwestie:

  • Repliki pomocnicze w partycji mogą mieć własne obciążenie
  • Ogólnie rzecz biorąc, metryki wyglądają na zrównoważone. W przypadku pamięci stosunek maksymalnego i minimalnego obciążenia wynosi 1,75 (węzeł z największym obciążeniem to N3, najmniej to N2, a 28/16 = 1,75).

Nadal musimy wyjaśnić pewne kwestie:

  • Co ustaliło, czy stosunek 1,75 był rozsądny, czy nie? W jaki sposób menedżer zasobów klastra wie, czy jest to wystarczająco dobre, czy jest więcej pracy do wykonania?
  • Kiedy następuje równoważenie?
  • Co to znaczy, że pamięć została ważona "Wysoka"?

Wagi metryk

Śledzenie tych samych metryk w różnych usługach jest ważne. Ten widok globalny umożliwia menedżerowi zasobów klastra śledzenie użycia w klastrze, równoważenie użycia między węzłami i zapewnienie, że węzły nie przejdą przez pojemność. Jednak usługi mogą mieć różne widoki co do znaczenia tej samej metryki. Ponadto w klastrze z wieloma metrykami i dużą liczbą usług całkowicie zrównoważone rozwiązania mogą nie istnieć dla wszystkich metryk. Jak menedżer zasobów klastra powinien obsługiwać te sytuacje?

Wagi metryk umożliwiają menedżerowi zasobów klastra podjęcie decyzji, jak zrównoważyć klaster, gdy nie ma doskonałej odpowiedzi. Wagi metryk umożliwiają również menedżerowi zasobów klastra równoważenie różnych usług. Metryki mogą mieć cztery różne poziomy wagi: Zero, Niski, Średni i Wysoki. Metryka o wadze Zero nie przyczynia się do niczego, biorąc pod uwagę, czy rzeczy są zrównoważone, czy nie. Jednak jego obciążenie nadal przyczynia się do zarządzania pojemnością. Metryki o zerowej wadze są nadal przydatne i są często używane jako część zachowania usługi i monitorowania wydajności. Ten artykuł zawiera więcej informacji na temat używania metryk do monitorowania i diagnostyki usług.

Rzeczywisty wpływ różnych wag metryk w klastrze polega na tym, że menedżer zasobów klastra generuje różne rozwiązania. Wagi metryk informują menedżera zasobów klastra, że niektóre metryki są ważniejsze niż inne. Jeśli nie ma idealnego rozwiązania, menedżer zasobów klastra może preferować rozwiązania, które lepiej zrównoważą metryki o wyższych wagach. Jeśli usługa uważa, że określona metryka jest nieważna, może okazać się, że ich użycie tej metryki jest niezrównoważony. Dzięki temu inna usługa może uzyskać równomierną dystrybucję niektórych metryk, które są dla niej ważne.

Przyjrzyjmy się przykładowi niektórych raportów obciążenia i sposobie, w jaki różne wagi metryk są wynikiem różnych alokacji w klastrze. W tym przykładzie widzimy, że zmiana względnej wagi metryk powoduje, że menedżer zasobów klastra tworzy różne ustalenia usług.

Przykład wagi metryki i jej wpływ na rozwiązania do równoważenia

W tym przykładzie istnieją cztery różne usługi, wszystkie raportowanie różnych wartości dla dwóch różnych metryk, MetricA i MetricB. W jednym przypadku wszystkie usługi definiują MetricA jest najważniejszym (Waga = Wysoka) i MetricB jako nieistotne (Waga = Niska). W związku z tym widzimy, że menedżer zasobów klastra umieszcza usługi, aby MetricA był lepiej zrównoważony niż MetricB. "Lepsze zrównoważenie" oznacza, że Metryka ma niższe odchylenie standardowe niż MetricB. W drugim przypadku odwracamy wagi metryk. W związku z tym menedżer zasobów klastra zamienia usługi A i B, aby wymyślić alokację, w której Metryka B jest lepiej zrównoważona niż MetricA.

Uwaga

Wagi metryk określają, w jaki sposób menedżer zasobów klastra powinien równoważyć, ale nie wtedy, gdy ma nastąpić równoważenie. Aby uzyskać więcej informacji na temat równoważenia, zapoznaj się z tym artykułem

Globalne wagi metryk

Załóżmy, że usługa ServiceA definiuje MetricA jako wagę Wysoką, a usługa ServiceB ustawia wagę dla wartości MetricA na Low lub Zero. Jaka jest rzeczywista waga, która kończy się coraz używany?

Istnieje wiele wag śledzonych dla każdej metryki. Pierwsza waga to ta zdefiniowana dla metryki podczas tworzenia usługi. Druga waga to waga globalna, która jest obliczana automatycznie. Menedżer zasobów klastra używa obu tych wag podczas oceniania rozwiązań. Uwzględnianie obu wag jest ważne. Dzięki temu menedżer zasobów klastra może równoważyć każdą usługę zgodnie z własnymi priorytetami, a także zapewnić prawidłowe przydzielanie klastra jako całości.

Co by się stało, gdyby menedżer zasobów klastra nie dbał zarówno o równowagę globalną, jak i lokalną? Cóż, łatwo jest konstruować rozwiązania, które są globalnie zrównoważone, ale co skutkuje niską równowagą zasobów dla poszczególnych usług. W poniższym przykładzie przyjrzyjmy się usłudze skonfigurowanej tylko przy użyciu metryk domyślnych i zobaczmy, co się dzieje, gdy uwzględniana jest tylko równowaga globalna:

Wpływ rozwiązania tylko globalnego

W najlepszym przykładzie opartym tylko na równowadze globalnej klaster jako całość jest rzeczywiście zrównoważony. Wszystkie węzły mają tę samą liczbę prawyborów i tę samą liczbę replik całkowitych. Jeśli jednak przyjrzysz się rzeczywistemu wpływowi tej alokacji, nie jest tak dobry: utrata jakiegokolwiek węzła ma wpływ na określone obciążenie nieproporcjonalnie, ponieważ wyjmuje wszystkie prawybory. Jeśli na przykład pierwszy węzeł ulegnie awarii trzech prawyborów dla trzech różnych partycji usługi Circle, wszystkie zostaną utracone. Z drugiej strony usługi Trójkąt i Sześciokąt mają swoje partycje tracą replikę. Powoduje to brak zakłóceń, innych niż konieczność odzyskania repliki w dół.

W dolnej części przykładu menedżer zasobów klastra dystrybuował repliki na podstawie globalnego i poszczególnych usług. Podczas obliczania wyniku rozwiązania daje większość wagi rozwiązaniu globalnemu oraz (konfigurowalną) część do poszczególnych usług. Globalne saldo dla metryki jest obliczane na podstawie średniej wag metryk z każdej usługi. Każda usługa jest zrównoważona zgodnie z własnymi zdefiniowanymi wagami metryk. Gwarantuje to, że usługi są wyważone samodzielnie zgodnie z własnymi potrzebami. W związku z tym, jeśli ten sam pierwszy węzeł ulegnie awarii, awaria zostanie rozproszona we wszystkich partycjach wszystkich usług. Wpływ na poszczególne każdą z nich jest taki sam.

Następne kroki

  • Aby uzyskać więcej informacji na temat konfigurowania usług, dowiedz się więcej o konfigurowaniu usług (service-fabric-cluster-resource-manager-configure-services.md)
  • Definiowanie metryk defragmentacji to jeden ze sposobów konsolidacji obciążenia węzłów zamiast rozkładania go. Aby dowiedzieć się, jak skonfigurować defragmentację, zapoznaj się z tym artykułem
  • Aby dowiedzieć się, jak menedżer zasobów klastra zarządza obciążeniem klastra i równoważy obciążenie w klastrze, zapoznaj się z artykułem dotyczącym równoważenia obciążenia
  • Rozpocznij od początku i uzyskaj wprowadzenie do usługi Service Fabric Cluster Resource Manager
  • 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 dowiedzieć się więcej na temat kosztów przenoszenia, zapoznaj się z tym artykułem