Správa spotřeby prostředků a zatížení v Service Fabric s využitím metrik

Metriky jsou prostředky, o které vaše služby pečují a které jsou poskytovány uzly v clusteru. Metrika je cokoli, co chcete spravovat, aby se zlepšil nebo monitoruje výkon vašich služeb. Můžete například sledovat spotřebu paměti, abyste věděli, jestli je vaše služba přetížená. Dalším využitím je zjistit, jestli se služba může přesunout jinam, kde je paměť méně omezená, aby se zlepšil výkon.

Příkladem metrik jsou například využití paměti, disku a procesoru. Tyto metriky jsou fyzické metriky, prostředky, které odpovídají fyzickým prostředkům v uzlu, který je potřeba spravovat. Metriky můžou být také (a běžně to jsou) logické metriky. Logické metriky jsou například MyWorkQueueDepth nebo MessagesToProcess nebo TotalRecords. Logické metriky jsou definované aplikací a nepřímo odpovídají určité spotřebě fyzických prostředků. Logické metriky jsou běžné, protože může být obtížné měřit a hlásit spotřebu fyzických prostředků na základě jednotlivých služeb. Složitost měření a generování sestav vlastních fyzických metrik je také důvodem, proč Service Fabric poskytuje některé výchozí metriky.

Výchozí metriky

Řekněme, že chcete začít psát a nasazovat službu. V tomto okamžiku nevíte, jaké fyzické nebo logické prostředky využívá. To je v pořádku! Resource Manager clusteru Service Fabric používá některé výchozí metriky, pokud nejsou zadány žádné jiné metriky. Mezi ně patří:

• PrimaryCount – počet primárních replik na uzlu
• ReplicaCount – počet celkových stavových replik na uzlu
• Count – počet všech objektů služby (bezstavové a stavové) na uzlu

Pro základní úlohy poskytují výchozí metriky slušnou distribuci práce v clusteru. V následujícím příkladu se podíváme, co se stane, když vytvoříme dvě služby a spoléháme na výchozí metriky pro vyrovnávání. První služba je stavová služba se třemi oddíly a sadou cílových replik velikostí tří. Druhá služba je bezstavová služba s jedním oddílem a počtem instancí tří.

Získáme:

Několik věcí, které si poznamenejte:

• Primární repliky stavové služby se distribuují napříč několika uzly.
• Repliky pro stejný oddíl jsou na různých uzlech.
• Celkový počet primárních a sekundárních souborů se distribuuje v clusteru.
• Celkový počet objektů služby se rovnoměrně přiděluje na každém uzlu.

Dobré!

Výchozí metriky fungují skvěle jako začátek. Výchozí metriky vás ale budou obsahovat jenom doposud. Například: Jaká je pravděpodobnost, že schéma dělení, které jste vybrali, vede k dokonalému rovnoměrného využití u všech oddílů? Jaká je šance, že je zatížení dané služby v průběhu času konstantní, nebo dokonce stejné v několika oddílech právě teď?

Můžete spustit pouze s výchozími metrikami. Obvykle to ale znamená, že využití clusteru je nižší a nerovnoměrnější, než byste chtěli. Důvodem je to, že výchozí metriky nejsou adaptivní a předpokládá se, že vše je ekvivalentní. Například primární, který je zaneprázdněný, a jeden, který oba nepřispívají "1" do metriky PrimaryCount. V nejhorším případě může použití pouze výchozích metrik vést také k přeplánovaným uzlům, které vedou k problémům s výkonem. Pokud vás zajímá, jak využít cluster co nejvíce a vyhnout se problémům s výkonem, musíte použít vlastní metriky a dynamické generování sestav zatížení.

Vlastní metrika

Při vytváření služby se metriky konfigurují podle pojmenované instance.

Každá metrika má některé vlastnosti, které ji popisují: název, váha a výchozí zatížení.

• Název metriky: Název metriky. Název metriky je jedinečný identifikátor metriky v rámci clusteru z pohledu Resource Manageru.

• Váha: Váha metriky definuje, jak důležitá je tato metrika vzhledem k ostatním metrikám pro tuto službu.
• Výchozí načtení: Výchozí zatížení je reprezentováno odlišně v závislosti na tom, jestli je služba bezstavová nebo stavová.
  • Pro bezstavové služby má každá metrika jednu vlastnost s názvem DefaultLoad.
  • Pro stavové služby, které definujete:
    • PrimaryDefaultLoad: Výchozí množství této metriky, kterou tato služba spotřebovává, když je primární
    • SecondaryDefaultLoad: Výchozí množství této metriky, kterou tato služba spotřebovává, když je sekundární

Definování metrik pro vaši službu – příklad

Řekněme, že chcete mít následující konfiguraci:

• Vaše služba hlásí metriku s názvem ConnectionCount.
• Chcete také použít výchozí metriky.
• Provedli jste některá měření a víte, že obvykle primární replika této služby zabírá 20 jednotek "ConnectionCount".
• Secondaries use 5 units of "ConnectionCount"
• Víte, že "ConnectionCount" je nejdůležitější metrika z hlediska správy výkonu této konkrétní služby.
• Stále chcete vyvážit primární repliky. Vyrovnávání primárních replik je obecně dobrou myšlenkou bez ohledu na to, co. To pomáhá zabránit ztrátě některého uzlu nebo domény selhání, aby spolu s ní ovlivnila většinu primárních replik.
• Jinak jsou výchozí metriky v pořádku.

Tady je kód, který byste napsali pro vytvoření služby s danou konfigurací metriky:

Kód:

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

Připomínáme: Pokud chcete použít jenom výchozí metriky, nemusíte se vůbec dotýkat shromažďování metrik ani při vytváření služby nic zvláštního. Výchozí metriky se použijí automaticky, když nejsou definovány žádné jiné.

Teď si pojďme projít každé z těchto nastavení podrobněji a probrat chování, které ovlivňuje.

Načítání

Celý bod definování metrik představuje určité zatížení. Zatížení určuje, kolik dané metriky spotřebuje nějaká instance služby nebo replika na daném uzlu. Zatížení lze nakonfigurovat téměř v libovolném bodě. Příklad:

• Načtení lze definovat při vytvoření služby. Tento typ konfigurace zatížení se nazývá výchozí načtení.
• Informace o metrikách, včetně výchozích načtení, pro službu je možné po vytvoření služby aktualizovat. Tato aktualizace metrik se provádí aktualizací služby.
• Načtení pro daný oddíl je možné resetovat na výchozí hodnoty dané služby. Tato aktualizace metrik se nazývá resetování zatížení oddílu.
• Zatížení může být hlášeno na základě jednotlivých objektů služby dynamicky během běhu. Tato aktualizace metrik se nazývá načítání sestav.
• Načtení replik nebo instancí oddílu je také možné aktualizovat generováním sestav hodnot načítání prostřednictvím volání rozhraní API infrastruktury. Tato aktualizace metrik se označuje jako načítání sestav pro oddíl.

Všechny tyto strategie se dají používat ve stejné službě po celou dobu jeho života.

Výchozí načtení

Výchozí zatížení určuje, kolik metriky spotřebuje každý objekt služby (bezstavová instance nebo stavová replika) této služby. Správce prostředků clusteru používá toto číslo pro načtení objektu služby, dokud neobdrží další informace, jako je například dynamická sestava zatížení. Pro jednodušší služby je výchozí načtení statickou definicí. Výchozí načtení se nikdy neaktualizuje a používá se po celou dobu životnosti služby. Výchozí zatížení funguje skvěle pro jednoduché scénáře plánování kapacity, ve kterých jsou určité množství prostředků vyhrazené pro různé úlohy a nemění se.

Správce prostředků clusteru umožňuje stavovým službám určit jiné výchozí zatížení pro jejich primarie a sekundární. Bezstavové služby mohou zadat pouze jednu hodnotu, která se vztahuje na všechny instance. U stavových služeb se výchozí zatížení primárních a sekundárních replik obvykle liší, protože repliky provádějí různé druhy práce v každé roli. Například Primaries obvykle obsluhují čtení i zápisy a zpracovávají většinu výpočetní zátěže, zatímco sekundární ne. Výchozí zatížení primární repliky je obvykle vyšší než výchozí zatížení sekundárních replik. Skutečná čísla by měla záviset na vašich vlastních měřeních.

Dynamické načítání

Řekněme, že už nějakou dobu používáte službu. U některých monitorování jste si všimli, že:

1. Některé oddíly nebo instance dané služby spotřebovávají více prostředků než jiné.
2. Některé služby mají zatížení, které se v průběhu času liší.

Existuje spousta věcí, které by mohly způsobit tyto typy kolísání zatížení. Různé služby nebo oddíly jsou například přidružené k různým zákazníkům s různými požadavky. Zatížení se může také změnit, protože množství práce, kterou služba v průběhu dne mění. Bez ohledu na důvod není obvykle k dispozici žádné číslo, které můžete použít pro výchozí nastavení. To platí hlavně v případě, že chcete z clusteru dosáhnout největšího využití. Jakákoli hodnota, kterou vyberete pro výchozí načtení, je v některých časových obdobích chybná. Nesprávné výchozí načtení vede k tomu, že Správce prostředků clusteru je nad nebo pod přidělením prostředků. V důsledku toho máte uzly, které se využívají, i když správce prostředků clusteru považuje cluster za vyvážené. Výchozí načtení je stále dobré, protože poskytují určité informace pro počáteční umístění, ale nejsou úplným scénářem pro skutečné úlohy. Aby bylo potřeba přesně zachytit měnící se požadavky na prostředky, Správce prostředků clusteru umožňuje každému objektu služby aktualizovat vlastní zatížení během běhu. Tomu se říká dynamické generování sestav zatížení.

Dynamické sestavy zatížení umožňují replikám nebo instancím upravit jejich přidělení nebo nahlášené zatížení metrik v průběhu jejich životnosti. Replika služby nebo instance, která byla studená a neprovádí žádnou práci, by obvykle hlásila, že používala nízké množství dané metriky. Zaneprázdněná replika nebo instance by hlásila, že používají více.

Načtení sestav na repliku nebo instanci umožňuje Správci prostředků clusteru změnit uspořádání jednotlivých objektů služby v clusteru. Změna uspořádání služeb pomáhá zajistit, aby získaly požadované prostředky. Zaneprázdněné služby se efektivně dostanou k uvolnění prostředků z jiných replik nebo instancí, které jsou aktuálně studené nebo méně práce.

V rámci Reliable Services kód, který bude načítat sestavy dynamicky, vypadá takto:

Kód:

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

Služba může hlásit jakoukoli z metrik definovaných pro ni při vytváření. Pokud se sestava služby načte pro metriku, kterou není nakonfigurovaná pro použití, Service Fabric tuto sestavu ignoruje. Pokud jsou ve stejnou dobu hlášené další metriky, jsou tyto sestavy přijímány. Kód služby může měřit a hlásit všechny metriky, které zná, a operátory mohou určit konfiguraci metriky, která se má použít, aniž by museli měnit kód služby.

Načítání sestav pro oddíl

Předchozí část popisuje, jak se repliky služeb nebo instance sestavy načítají. Existuje další možnost dynamického načítání sestav pro repliky nebo instance oddílu prostřednictvím rozhraní Service Fabric API. Při vytváření sestav pro oddíl můžete najednou hlásit více oddílů.

Tyto sestavy se použijí úplně stejným způsobem jako sestavy načítání, které pocházejí z replik nebo samotných instancí. Ohlášené hodnoty budou platné, dokud nebudou hlášeny nové hodnoty načtení, a to buď replikou, nebo instancí nebo generováním sestav nové hodnoty zatížení pro oddíl.

S tímto rozhraním API existuje několik způsobů, jak aktualizovat zatížení v clusteru:

• Oddíl stavové služby může aktualizovat zatížení primární repliky.
• Bezstavové i stavové služby můžou aktualizovat zatížení všech jeho sekundárních replik nebo instancí.
• Bezstavové i stavové služby můžou aktualizovat zatížení konkrétní repliky nebo instance na uzlu.

Je také možné kombinovat všechny tyto aktualizace na oddíl současně. Kombinace aktualizací zatížení pro konkrétní oddíl by měla být zadána prostřednictvím objektu PartitionMetricLoadDescription, který může obsahovat odpovídající seznam aktualizací načtení, jak je znázorněno v následujícím příkladu. Aktualizace zatížení jsou reprezentovány prostřednictvím objektu MetricLoadDescription, který může obsahovat aktuální nebo předpovězenou hodnotu zatížení pro metriku zadanou názvem metriky.

Aktualizace zatížení pro více oddílů je možná jedním voláním rozhraní API, v takovém případě bude výstup obsahovat odpověď na oddíl. V případě, že se aktualizace oddílu z nějakého důvodu úspěšně nepoužije, aktualizace pro tento oddíl se přeskočí a zobrazí se odpovídající kód chyby pro cílový oddíl:

• PartitionNotFound – Zadané ID oddílu neexistuje.
• RekonfiguracePending – Oddíl je aktuálně překonfigurován.
• InvalidForStatelessServices – Došlo k pokusu o změnu zatížení primární repliky pro oddíl patřící do bezstavové služby.
• ReplicaDoesNotExist – Sekundární replika nebo instance na zadaném uzlu neexistuje.
• InvalidOperation – Může k tomu dojít ve dvou případech: aktualizace zatížení oddílu, který patří do systémové aplikace nebo aktualizace předpovězené zátěže, není povolená.

Pokud se některé z těchto chyb vrátí, můžete aktualizovat vstup pro určitý oddíl a zkusit aktualizaci zopakovat.

Kód:

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

V tomto příkladu provedete aktualizaci posledního nahlášeného zatížení oddílu 53df3d7f-5471-403b-b736-bde6ad584f42. Zatížení primární repliky pro metriku CustomMetricName0 se aktualizuje hodnotou 100. Zároveň se načte stejná metrika pro konkrétní sekundární repliku umístěnou v node NodeName0 a aktualizuje se hodnotou 200.

Aktualizace konfigurace metrik služby

Seznam metrik přidružených ke službě a vlastnosti těchto metrik je možné dynamicky aktualizovat, když je služba aktivní. To umožňuje experimentování a flexibilitu. Tady je několik příkladů, kdy je to užitečné:

• zakázání metriky se sestavou chyb pro konkrétní službu
• změna konfigurace váhy metrik na základě požadovaného chování
• povolení nové metriky až po nasazení a ověření kódu prostřednictvím jiných mechanismů
• změna výchozího zatížení služby na základě zjištěného chování a spotřeby

Hlavní rozhraní API pro změnu konfigurace metrik jsou FabricClient.ServiceManagementClient.UpdateServiceAsync v jazyce C# a Update-ServiceFabricService v PowerShellu. Jakékoli informace, které zadáte pomocí těchto rozhraní API, nahradí stávající informace metriky pro službu okamžitě.

Kombinování výchozích hodnot zatížení a sestav dynamického načítání

Pro stejnou službu je možné použít výchozí načtení a dynamické načítání. Když služba využívá výchozí sestavy načítání i dynamického zatížení, slouží výchozí zatížení jako odhad, dokud se dynamické sestavy nezobrazí. Výchozí zatížení je dobré, protože dává Správci prostředků clusteru něco, se kterým může pracovat. Výchozí zatížení umožňuje Správci prostředků clusteru umístit objekty služby do vhodných umístění při jejich vytvoření. Pokud nejsou k dispozici žádné výchozí informace o načtení, umístění služeb je efektivně náhodné. Když sestavy načítání dorazí později, počáteční náhodné umístění je často chybné a Cluster Resource Manager musí přesunout služby.

Podívejme se na náš předchozí příklad a podívejme se, co se stane, když přidáme nějaké vlastní metriky a dynamické generování sestav zatížení. V tomto příkladu jako ukázkovou metriku používáme "MemoryInMb".

Předpokládejme, že jsme původně vytvořili stavovou službu pomocí následujícího příkazu:

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

Připomínáme, že tato syntaxe je (MetricName, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad).

Podívejme se, jak by mohlo vypadat jedno možné rozložení clusteru:

Některé věci, které stojí za zmínku:

• Sekundární repliky v rámci oddílu můžou mít vlastní zatížení.
• Celkově vypadají metriky vyváženě. Pro paměť je poměr mezi maximálním a minimálním zatížením 1,75 (uzel s největším zatížením je N3, nejmenší je N2 a 28/16 = 1,75).

Stále potřebujeme vysvětlit některé věci:

• Co určilo, jestli byl poměr 1,75 přiměřený nebo ne? Jak Správce prostředků clusteru zjistí, jestli je to dost dobré nebo jestli je k dispozici více práce?
• Kdy dojde k vyrovnávání?
• Co znamená, že paměť byla vážená "Vysoká"?

Váhy metrik

Sledování stejných metrik napříč různými službami je důležité. Toto globální zobrazení umožňuje Správci prostředků clusteru sledovat spotřebu v clusteru, vyrovnávat spotřebu napříč uzly a zajistit, aby uzly nepřecházely přes kapacitu. Služby ale můžou mít různá zobrazení důležitosti stejné metriky. Také v clusteru s mnoha metrikami a spoustou služeb nemusí dokonale vyvážená řešení existovat pro všechny metriky. Jak by měl Správce prostředků clusteru tyto situace zvládnout?

Váhy metrik umožňují Správci prostředků clusteru rozhodnout, jak vyrovnávat cluster, když neexistuje žádná dokonalá odpověď. Váhy metrik také umožňují Resource Manageru clusteru vyrovnávat konkrétní služby jinak. Metriky můžou mít čtyři různé úrovně hmotnosti: nula, nízká, střední a vysoká. Metrika s váhu nula nic přispívá při zvažování, zda jsou věci vyváženy, nebo ne. Jeho zatížení ale stále přispívá ke správě kapacity. Metriky s nulovou hmotností jsou stále užitečné a často se používají jako součást chování služby a monitorování výkonu. Tento článek obsahuje další informace o využití metrik pro monitorování a diagnostiku vašich služeb.

Skutečný dopad různých váhy metrik v clusteru spočívá v tom, že Správce prostředků clusteru generuje různá řešení. Váhy metrik říkají Správci prostředků clusteru, že určité metriky jsou důležitější než jiné. Pokud neexistuje žádné dokonalé řešení, může Správce prostředků clusteru upřednostňovat řešení, která vyvážou vyšší vážené metriky lépe. Pokud si služba myslí, že konkrétní metrika je nedůležitá, může zjistit, že je tato metrika nevyrovnaná. To umožňuje jiné službě získat rovnoměrnou distribuci určité metriky, která je pro ni důležitá.

Podívejme se na příklad některých sestav zatížení a na to, jak různé váhy metrik mají za následek různé přidělení v clusteru. V tomto příkladu vidíme, že přepnutí relativní váhy metrik způsobí, že Správce prostředků clusteru vytvoří různé uspořádání služeb.

V tomto příkladu existují čtyři různé služby, všechny hlásí různé hodnoty pro dvě různé metriky, metriky A a metrikyB. V jednom případě všechny služby definují metriku MetricA je nejdůležitější (váha = vysoká) a metrikaB jako nedůležitá (váha = nízká). V důsledku toho vidíme, že Správce prostředků clusteru umístí služby tak, aby metrika byla lépe vyvážená než metrikaB. "Lepší vyvážení" znamená, že metrika má nižší směrodatnou odchylku než MetricB. V druhém případě obrátíme váhy metrik. V důsledku toho Správce prostředků clusteru prohodí služby A a B a vytvoří přidělení, ve kterém je metrikaB lépe vyvážená než metrika.

Globální váhy metrik

Řekněme, že ServiceA definuje metriku MetricA jako váhu Vysoká a ServiceB nastaví váhu metriky na Nízkou nebo nulu. Jaká je skutečná váha, která se nakonec používá?

Pro každou metriku se sleduje více váhy. První váha je ta, která je definovaná pro metriku při vytvoření služby. Druhá váha je globální váha, která se vypočítá automaticky. Správce prostředků clusteru při vyhodnocování řešení používá obě tyto váhy. Je důležité vzít v úvahu obě váhy. To umožňuje Správci prostředků clusteru vyrovnávat každou službu podle svých vlastních priorit a také zajistit správné přidělení clusteru jako celku.

Co by se stalo, když správce prostředků clusteru nezajímá globální i místní zůstatek? Dobře, je snadné vytvářet řešení, která jsou globálně vyvážená, ale což vede k špatnému zůstatku prostředků pro jednotlivé služby. V následujícím příkladu se podíváme na službu nakonfigurovanou pouze s výchozími metrikami a podívejme se, co se stane, když se považuje pouze globální zůstatek:

V horním příkladu založeném pouze na globálním zůstatku je cluster jako celek skutečně vyvážen. Všechny uzly mají stejný počet primárek a stejný počet celkových replik. Pokud se ale podíváte na skutečný dopad tohoto přidělení, není to tak dobré: ztráta jakéhokoli uzlu má nepřiměřený dopad na konkrétní úlohu, protože vytáhne všechny její primarie. Pokud například první uzel selže, dojde ke ztrátě tří primárních oddílů pro tři různé oddíly služby Circle. Naopak služby Trojúhelník a Hexagon mají své oddíly ztraceny repliku. To způsobí žádné přerušení, jiné než obnovení repliky mimo provoz.

V dolním příkladu správce prostředků clusteru distribuoval repliky na základě globálního zůstatku i zůstatku jednotlivých služeb. Při výpočtu skóre řešení dává největší váhu globálnímu řešení a část (konfigurovatelnou) jednotlivým službám. Globální zůstatek metriky se počítá na základě průměru váhy metriky z každé služby. Každá služba je vyvážená podle vlastních definovaných hmotností metrik. To zajišťuje, že služby jsou v sobě vyváženy podle vlastních potřeb. Pokud tedy selže stejný první uzel, selhání se distribuuje napříč všemi oddíly všech služeb. Dopad na každý z nich je stejný.

Další kroky

• Další informace o konfiguraci služeb najdete v tématu Konfigurace služeb (service-fabric-cluster-resource-manager-configure-services.md)
• Definování defragmentačních metrik je jedním ze způsobů, jak konsolidovat zatížení uzlů místo jejich rozložení. Informace o konfiguraci defragmentace najdete v tomto článku.
• Pokud chcete zjistit, jak Resource Manager clusteru spravuje a vyrovnává zatížení v clusteru, přečtěte si článek o vyrovnávání zatížení.
• Začněte od začátku a získejte úvod do Resource Manageru clusteru Service Fabric.
• Náklady na přesun jsou jedním ze způsobů, jak signalizovat Správce prostředků clusteru, že některé služby jsou dražší než jiné. Další informace o nákladech na pohyb najdete v tomto článku.