Udostępnij za pośrednictwem

Zarządzanie zużyciem zasobów i obciążeniem w usłudze Service Fabric za pomocą metryk

Metryki to zasoby, które są ważne dla usług 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 na węźle
  • Liczba — liczba wszystkich obiektów usługi (bezstanowych i stanowych) na węźle
Wskaźnik Obciążenie wystąpienia bezstanowego Stanowe obciążenie pomocnicze Stanowe obciążenie podstawowe Ciężar
Podstawowa Liczba 0 0 1 Wysoki
Liczba replik 0 1 1 Średni
Liczba 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 stanowa usługa z trzema partycjami i docelową liczbą trzech replik. Druga usługa jest usługą bezstanową z jedną partycją i liczbą wystąpień wynoszącą trzy.

Oto, co otrzymujesz:

Układ klastra z domyślnymi metrykami

Niektóre kwestie do zapamiętania:

  • Podstawowe repliki usługi stanowej są rozdzielone między kilkoma węzłami.
  • Repliki dla tej samej partycji znajdują się w różnych węzłach
  • Łączna liczba elementów pierwszorzędnych i drugorzędnych jest rozprowadzana 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 pewnego momentu. 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ć 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 zarówno główny, który jest zajęty, jak i taki, który nie jest, każdy przyczynia się "1" do metryki PrimaryCount. W najgorszym przypadku użycie tylko domyślnych metryk może także spowodować nadmiernie obciążone 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 miernika jest unikalnym identyfikatorem miernika w klastrze z perspektywy Resource Manager.

Uwaga / Notatka

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 wersji 9.1 Service Fabric, dla istniejących usług z tymi niestandardowymi nazwami metryk zostanie wyświetlone ostrzeżenie o zdrowiu 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.
  • Obciążenie domyślne: Jest reprezentowane inaczej zależnie 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 usług stanowych definiujesz:
      • PrimaryDefaultLoad: domyślna ilość tej metryki zużywana przez tę usługę, gdy jest główną.
      • SecondaryDefaultLoad: domyślna ilość tej metryki zużywana przez tę usługę, gdy jest drugorzędna

Uwaga / Notatka

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 bardziej dbać o ConnectionCount albo WorkQueueDepth niż o dystrybucję podstawową. 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
  • Wykonałeś kilka pomiarów oraz wiesz, że zwykle replika główna tej usługi zajmuje 20 jednostek "ConnectionCount".
  • Jednostki podrzędne używają 5 jednostek "ConnectionCount".
  • Wiesz, że "ConnectionCount" to najważniejsza metryka pod względem zarządzania wydajnością tej konkretnej usługi
  • Nadal chcesz, aby repliki podstawowe były zrównoważone. Równoważenie replik podstawowych jest ogólnie dobrym pomysłem, niezależnie od okoliczności. Pomaga to zapobiegać sytuacji, w której utrata niektórych węzłów lub domen błędów wpływa na większość replik podstawowych.
  • W przeciwnym razie domyślne metryki są w porządku

Oto kod, który należałoby napisać, aby utworzyć usługę z konfiguracją tego systemu metrycznego.

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);

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 / Notatka

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 związane z metrykami są często przypisywane na poziomie nazwanych wystąpień usługi. Załóżmy na przykład, że tworzysz jedno wystąpienie usługi dla CustomerA, która planuje korzystać z niej tylko w niewielkim stopniu. Załóżmy również, że utworzysz kolejną dla KlientaB, który ma 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 określone w manifestach nie zgadzają się z tymi, z którymi usługa faktycznie działa. 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 przeanalizujmy dokładniej każde z tych ustawień i porozmawiajmy o zachowaniu, na które wpływają.

Ładowanie

Cały punkt definiowania metryk polega na reprezentowaniu pewnego obciążenia. Obciążenie to ilość określonego wskaźnika, która jest wykorzystywana przez jakieś wystąpienie usługi lub replikę w danym węźle. Obciążenie można skonfigurować niemal w dowolnym momencie. Przykład:

  • Obciążenie 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 w trakcie działania. Ta aktualizacja metryki jest nazywana obciążeniem raportowania.
  • Obciążenie replik lub instancji partycji można również zaktualizować poprzez raportowanie wartości obciążenia za pośrednictwem wywołania Fabric API. 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, którą każdy obiekt usługi tego serwisu (wystąpienie bezstanowe lub replika stanowa) zużywa. 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 obciążenie nigdy nie jest aktualizowane i jest używane przez cały okres działania 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 / Notatka

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 posiadającym stan określenie innego domyślnego obciążenia dla instancji podstawowych i pomocniczych. 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 serwery główne zwykle realizują zarówno operacje odczytu, jak i zapisu oraz przyjmują większość obciążeń obliczeniowych, podczas gdy serwery zapasowe tego nie robią. 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 prowadzisz swoją usługę od jakiegoś czasu. Podczas monitorowania zauważyłeś/łaś, że:

  1. Niektóre partycje lub instancje 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ą powiązane z klientami o odmiennych wymaganiach. 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 domyślne obciążenia powodują, że Menedżer Zasobów Klastra albo nadmiernie, albo niewystarczająco przydziela zasoby. W związku z tym masz węzły, które są nadmiernie lub niewystarczająco wykorzystywane, mimo że menedżer zasobów klastra sądzi, że klaster jest zrównoważony. Obciążenia domyślne są nadal dobre, ponieważ zawierają pewne informacje na temat wstępnego rozmieszczenia, ale nie są one kompletną historią dla rzeczywistych obciążeń roboczych. 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.

Raporty dynamicznego obciążenia umożliwiają replikom lub wystąpieniom dostosowanie alokacji lub zgłaszanego obciążenia metryk przez cały okres ich istnienia. Replika usługi lub wystąpienie, które było nieaktywne i nie wykonywało żadnej pracy, zwykle zgłasza, że zużywa mało danej metryki. Zajęta replika lub instancja zgłasza, że zużywa więcej zasobów.

Raportowanie obciążenia na każdą replikę lub instancję pozwala Menedżerowi Zasobów Klastra na reorganizację indywidualnych obiektów usług w klastrze. Reorganizacja usług pomaga zagwarantować, że uzyskają wymagane zasoby. Zajęte usługi skutecznie "odzyskują" zasoby z innych replik lub wystąpień, które są obecnie nieaktywne lub mniej obciążone pracą.

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

Poprzednia sekcja opisuje, jak repliki usług lub instancje same zgłaszają obciążenie. 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 identyczny sposób jak raporty ładowania pochodzące z samych replik lub instancji. Zgłoszone wartości będą ważne aż do momentu, gdy zostaną zgłoszone nowe wartości obciążenia przez replikę, instancję lub poprzez zgłoszenie 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 usługi bezstanowe, jak i stanowe mogą aktualizować obciążenie wszystkich swoich replik pomocniczych lub instancji.
  • Zarówno usługi bezstanowe, jak i stanowe mogą aktualizować obciążenie określonej repliki lub instancji na 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 / Notatka

Przewidywane metryki obciążenia jest obecnie funkcjonalnością testową. 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 wtórna lub instancja nie istnieje na 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 związanej z raportem zawierającym błędy 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 natychmiast zastępują istniejące informacje metryczne dla usługi.

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 korzystne, ponieważ zapewnia menedżerowi zasobów klastra materiał do działania. 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 obciążenia docierają później, początkowe losowe umieszczanie często okazuje się nieprawidłowe i 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 używamy "MemoryInMb" jako przykładową metrykę.

Uwaga / Notatka

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:

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 składnia wygląda następująco: ("MetricName, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad").

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

Zrównoważony klaster z wykorzystaniem zarówno metryk domyślnych, jak i niestandardowych

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 oceniona jako „Wysoka”?

Wagi metryczne

Śledzenie tych samych metryk w różnych usługach jest ważne. Ten globalny widok umożliwia kierownikowi zarządzania zasobami klastra śledzenie zużycia w klastrze, rozłożenie użycia między węzłami oraz zapewnienie, że węzły nie przekroczą pojemności. 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. Miary wartości umożliwiają menedżerowi zasobów klastra także różne równoważenie konkretnych 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 często wykorzystywane do monitorowania zachowań usług oraz 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 temu, jak różne wagi metryk prowadzą do 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 metrycznej wagi i jej wpływ na rozwiązywanie równoważenia

W tym przykładzie istnieją cztery różne usługi, wszystkie raportujące różne wartości dla dwóch różnych wskaźników, MetricA i MetricB. W jednym przypadku wszystkie usługi definiują MetricA jako najważniejszą (Waga = Wysoka) i MetricB jako nieistotną (Waga = Niska). W rezultacie widzimy, że zarządzający zasobami klastra rozmieszcza usługi w taki sposób, aby MetricA był bardziej zrównoważony niż MetricB. "Lepsze zrównoważenie" oznacza, że MetricA ma niższe odchylenie standardowe niż MetricB. W drugim przypadku odwracamy kolejność wag 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 / Notatka

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ę MetricA na niską lub zerową. Jaką rzeczywistą wagę się ostatecznie używa?

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ę głównych i tę samą łączną liczbę replik. Jednak gdy przyjrzysz się rzeczywistemu wpływowi tej alokacji, nie jest to tak dobre: utrata dowolnego węzła wpływa na określone obciążenie w nieproporcjonalny sposób, ponieważ prowadzi do utraty wszystkich jego podstawowych replik. Jeśli na przykład pierwszy węzeł ulegnie awarii, wszystkie trzy główne węzły dla trzech różnych partycji usługi Circle zostaną utracone. Z drugiej strony, w usługach Trójkąt i Sześciokąt partycje tracą replikę. Nie powoduje to zakłóceń, poza koniecznością odzyskania uszkodzonej repliki.

W dolnym przykładzie Menedżer zasobów klastra rozdzielił repliki w oparciu o zarówno globalną, jak i per-service równowagę. Podczas obliczania wyniku rozwiązania, największą wagę przypisuje się rozwiązaniu globalnemu, a konfigurowalną część dla 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 w sobie 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 każdego jest taki sam.

Dalsze 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