Správa spotřeby a zatížení prostředků v Service Fabric s metrikami

Metriky jsou prostředky, o které se vaše služby starají a které poskytují uzly v clusteru. Metrika je cokoli, co chcete spravovat za účelem zlepšení nebo monitorování výkonu 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 použitím je zjistit, jestli se služba může přesunout jinam, kde je paměť méně constrained, aby se mohl zlepšit výkon.

Příkladem metrik je 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 mohou být také (a obvykle to jsou) logické metriky. Logické metriky jsou například "MyWorkQueueDepth" nebo "MessagesToProcess" nebo "TotalRecords". Logické metriky jsou definované aplikací a nepřímo odpovídají využití některých 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ů pro každou službu. Složitost měření a generování sestav vlastních fyzických metrik je také důvod, proč Service Fabric některé výchozí metriky.

Výchozí metriky

Řekněme, že chcete začít psát a nasazovat službu. V tuto chvíli nevíte, jaké fyzické nebo logické prostředky spotřebovává. To je v pořádku! Pokud Service Fabric Správce prostředků clusteru žádné jiné metriky, aplikace použije některé výchozí metriky. Jsou to tyto:

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

U základních úloh poskytují výchozí metriky dobrou distribuci práce v clusteru. V následujícím příkladu se podívejme, 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 cílovou velikostí sady replik tří. Druhou službou je bezvýcová služba s jedním oddílem a třemi instancemi.

Získáme:

Všimněte si:

• Primární repliky stavové služby se distribuují mezi několik uzlů.
• Repliky pro stejný oddíl jsou na různých uzlech.
• Celkový početries and secondaries is distributed in the cluster
• Celkový počet objektů služby je rovnoměrně přidělen na každém uzlu.

Dobré!

Výchozí metriky fungují jako první. Výchozí metriky vás ale doposud donesou. Příklad: Jaká je pravděpodobnost, že výsledkem schématu dělení, které jste vybrali, je dokonale even využití všemi oddíly? Jaká je šance, že zatížení pro danou službu je v průběhu času konstantní, nebo dokonce v několika oddílech právě teď stejné?

Můžete spustit pouze s výchozími metrikami. Obvykle to ale znamená, že využití clusteru je nižší a nerovnoměrné, než byste chtěli. Je to proto, že výchozí metriky nejsou adaptivní a předpokládá se, že je všechno ekvivalentní. Například primární, která je zaneprázdněná, a ta, která není obě, přispívá 1 k metrikě PrimaryCount. V nejhorším případě může použití jenom výchozích metrik vést k přeplánovaných uzlům, což vede k problémům s výkonem. Pokud vás zajímá, jak využít cluster napl prostředky a vyhnout se problémům s výkonem, musíte použít vlastní metriky a dynamické generování sestav zatížení.

Vlastní metriky

Metriky se při vytváření služby konfiguruje pro každou instanci pojmenované služby.

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 Resource Manager perspektivy.
• Váha: Váha metriky definuje, jak důležitá je tato metrika relativní vzhledem k ostatním metrikám pro tuto službu.
• Výchozí načtení: Výchozí zatížení se reprezentuje různě v závislosti na tom, jestli je služba bez stavu nebo stavová.
  • U bez stavových služeb má každá metrika jednu vlastnost s názvem DefaultLoad.
  • Pro stavové služby definujete:
    • PrimaryDefaultLoad: Výchozí množství této metriky, kterou tato služba spotřebuje, když se jedná o primární metriku
    • SecondaryDefaultLoad: Výchozí množství této metriky, kterou tato služba spotřebuje, když se jedná o sekundární metriku.

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

Řekněme, že chcete 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ěkolik měření a víte, že za normálních okolností primární replika této služby zabírá 20 jednotek hodnoty ConnectionCount.
• Druhé kategorie používají 5 jednotek ConnectionCount.
• Víte, že "ConnectionCount" je nejdůležitější metrikou z hlediska správy výkonu této konkrétní služby.
• Stále chcete mít vyvážené primární repliky. Vyrovnávání primárních replik je obecně dobrou myšlenkou bez ohledu na to, co je. To pomáhá zabránit ztrátě některých uzlů 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 konfigurací této 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, že pokud chcete jenom použít výchozí metriky, nemusíte se vůbec vůbec potýkat s kolekcí metrik nebo při vytváření služby dělat nic zvláštního. Výchozí metriky se automaticky používají, když nejsou definované žádné jiné.

Teď si podrobněji projdeme každé z těchto nastavení a promluvme si o chování, které ovlivňuje.

Načítání

Celým bodem definování metrik je reprezentovat určité zatížení. Zatížení je množství dané metriky spotřebované nějakou instancí služby nebo replikou na daném uzlu. Zatížení je možné nakonfigurovat téměř v jakémkoli bodě. Příklad:

• Při vytváření služby je možné definovat načtení. Tento typ konfigurace načítání se nazývá výchozí načtení.
• Informace o metrikách, včetně výchozích načtení, pro službu je možné aktualizovat po vytvoření služby. Tato aktualizace metriky se provádí aktualizací služby.
• Načtení pro daný oddíl je možné obnovit na výchozí hodnoty pro danou službu. Tato aktualizace metriky se nazývá resetování zatížení oddílů.
• Zatížení se může hlásit dynamicky za běhu pro každý objekt služby. Tato aktualizace metriky se nazývá generování sestav o zatížení.
• Zatížení replik nebo instancí oddílů je také možné aktualizovat generováním sestav hodnot zatížení prostřednictvím volání rozhraní API infrastruktury. Tato aktualizace metriky se nazývá generování sestav zatížení pro oddíl.

Všechny tyto strategie je možné během své životnosti použít v rámci stejné služby.

Výchozí načtení

Výchozí zatížení je, kolik metrik každý objekt služby (bez stavu instance nebo stavová replika) této služby spotřebuje. Aplikace Správce prostředků clusteru toto číslo používá pro načtení objektu služby, dokud nebude do něj dokončovat další informace, jako je například sestava dynamického načtení. U jednodušších služeb je výchozí načtení statickou definicí. Výchozí načtení není nikdy aktualizováno 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, kdy jsou určité objemy prostředků vyhrazené pro různé úlohy a nemění se.

Funkce Správce prostředků clusteru stavové služby zadat jiné výchozí zatížení pro své dešimy a sekundáry. Bezvýcové 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í a sekundární repliky obvykle liší, protože repliky v každé roli pracují různými druhy práce. Napříkladries obvykle slouží ke čtení i zápisu a zvládá většinu výpočetní zátěže, zatímco sekundy 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čtení

Řekněme, že službu už chvíli používáte. Při 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 mění.

Existuje spousta věcí, které by mohly způsobit tyto typy kolísání zatížení. Například různé služby nebo oddíly jsou 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 dělá, se liší. Bez ohledu na důvod obvykle neexistuje žádné jedno číslo, které byste mohli použít jako výchozí. To platí zejména v případě, že chcete využít cluster na maximální využití. Jakákoli hodnota, kterou vyberete pro výchozí načtení, je v některých případech chybná. Nesprávné výchozí načtení má za následek Správce prostředků clusteru přes nebo pod přidělováním prostředků. V důsledku toho máte více nebo méně využívovaných uzlů, i když se Správce prostředků clusteru cluster vyvažuje. Výchozí načítání je stále dobré, protože poskytují určité informace pro počáteční umístění, ale nejsou kompletním scénářem pro skutečné úlohy. K přesnému zachycení měnících se požadavků na Správce prostředků clusteru umožňuje každý objekt služby aktualizovat vlastní zatížení za běhu. Tomu se říká generování sestav dynamického zatížení.

Sestavy dynamického zatížení umožňují replikám nebo instancím upravovat přidělování nebo hlášené zatížení metrik v průběhu jejich životnosti. Replika nebo instance služby, která byla studená a nedělá žádnou práci, obvykle hlásí, že používá nízké objemy dané metriky. Zaneprázdněná replika nebo instance by nahlásit, že používají více.

Vytváření sestav zatížení na repliku nebo instanci umožňuje Správce prostředků clusteru reorganizovat jednotlivé objekty služby v clusteru. Reorganizace služeb pomáhá zajistit, aby měly prostředky, které potřebují. Zaneprázdněné služby se efektivně daří "uvolnit" prostředky z jiných replik nebo instancí, které jsou momentálně studené nebo pracují méně.

Uvnitř Reliable Services bude kód pro dynamické načítání vypadat podobně jako tento:

Kód:

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

Služba může při vytváření hlásit jakoukoli metriku, která je pro něj definovaná. Pokud služba hlásí načtení metriky, která není nakonfigurovaná k použití, Service Fabric sestavu ignoruje. Pokud jsou ve stejnou dobu hlášené další metriky, které jsou platné, budou tyto sestavy přijaty. Kód služby může měřit a hlásit všechny metriky, které umí, a operátory mohou určit konfiguraci metriky, která se má použít, aniž by museli měnit kód služby.

Vytváření sestav zatížení pro oddíl

Předchozí část popisuje, jak se repliky nebo instance služby samy načítají. Existuje další možnost dynamického hlášení zatížení replik nebo instancí oddílu prostřednictvím Service Fabric API. Při vytváření sestav zatížení pro oddíl můžete vytvořit sestavu pro více oddílů najednou.

Tyto sestavy se budou používat úplně stejným způsobem jako sestavy načítání, které přicházejí ze samotných replik nebo instancí. Ohlášené hodnoty budou platné, dokud nebudou hlášeny nové hodnoty zatížení, a to buď replikou nebo instancí, nebo hlášením 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.
• Bez stavové i stavové služby mohou aktualizovat zatížení všech sekundárních replik nebo instancí.
• Bez stavové i stavové služby mohou aktualizovat zatížení konkrétní repliky nebo instance na uzlu.

Je také možné kombinovat všechny tyto aktualizace na oddíl současně. Kombinaci aktualizací zatížení pro konkrétní oddíl je třeba zadat prostřednictvím objektu PartitionMetricLoadDescription, který může obsahovat odpovídající seznam aktualizací zatížení, jak je znázorněno v následujícím příkladu. Aktualizace zatížení se reprezentují 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ě nenasa by se použila, aktualizace pro tento oddíl se přeskočí a bude k dispozici odpovídající kód chyby pro cílový oddíl:

• PartitionNotFound – Zadané ID oddílu neexistuje.
• ReconfigurationPending – Oddíl v současné době překonfiguruje.
• 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 – K tomu může dojít ve dvou případech: aktualizace zatížení pro oddíl, který patří do systémové aplikace, nebo aktualizace předpovězené zátěže není povolená.

Pokud se vrátí některé z těchto chyb, můžete aktualizovat vstup pro konkrétní oddíl a opakovat aktualizaci pro něj.

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í hlášené zátěže pro oddíl 53df3d7f-5471-403b-b736-bde6ad584f42. Zatížení primární repliky pro metriku CustomMetricName0 se aktualizuje s hodnotou 100. Zároveň se zatížení pro stejnou metriku pro konkrétní sekundární repliku umístěnou v uzlu NodeName0 aktualizuje s 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. Některé příklady, kdy je to užitečné:

• Zakázání metriky pomocí sestavy ladění pro určitou službu
• Změna konfigurace vah metrik na základě požadovaného chování
• povolení nové metriky až poté, co byl kód již nasazen a ověřen prostřednictvím jiných mechanismů
• Změna výchozího zatížení služby na základě pozorovaného chování a spotřeby

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

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

Pro stejnou službu lze použít výchozí zatížení a dynamické načtení. Když služba využívá výchozí zatížení a dynamické sestavy zatížení, slouží jako odhad výchozí zatížení, dokud se nezobrazují dynamické sestavy. Výchozí zatížení je dobré, protože zajišťuje, aby cluster Správce prostředků něco. Výchozí zatížení umožňuje, aby cluster Správce prostředků umístit objekty služby do dobrý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ž budou načteny sestavy později, počáteční náhodné umístění je často chybné a cluster Správce prostředků musí přesunout služby.

Pojďme si vyzkoušet náš předchozí příklad a podívat se, co se stane, když přidáme některé vlastní metriky a generování sestav dynamického načtení. V tomto příkladu používáme jako ukázkovou metriku "MemoryInMb".

Řekněme, že jsme původně vytvořili stavovou službu pomocí následujícího příkazu:

Prostředí

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

Tato syntaxe je jako připomenutí ("metric, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad").

Pojďme se podívat, jak může vypadat možné rozložení clusteru:

Zde jsou některé věci, které se zaznamenaly:

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

K dispozici jsou některé věci, které ještě potřebujeme vysvětlit:

• Jak bylo zjištěno, zda byl poměr 1,75 rozumný nebo ne? Jak cluster Správce prostředků ví, jestli je dostatečně dobrý, nebo pokud je to tak více práce?
• Kdy dojde k vyvážení?
• Co to znamená, že paměť byla vážená "vysoká"?

Váhy metriky

Sledování stejných metrik v různých službách je důležité. Toto globální zobrazení umožňuje Správce prostředků clusteru sledovat spotřebu v clusteru, vyrovnávat spotřebu napříč uzly a zajistit, aby uzly nepřešly do kapacity. Nicméně služby mohou mít různá zobrazení, která mají význam stejné metriky. Také v clusteru s mnoha metrikami a velkým množstvím služeb nemusí pro všechny metriky existovat dokonale vyvážená řešení. Jak by měl cluster Správce prostředků zvládnout tyto situace?

Váhy metriky umožňují, aby se cluster Správce prostředků rozhodl, jak vyrovnávat cluster, pokud neexistuje žádná dokonalý odpověď. Váhy metriky také umožňují, aby cluster Správce prostředků různým způsobem vyrovnávat konkrétní služby. Metriky můžou mít čtyři různé úrovně důležitosti: 0, nízká, střední a vysoká. Metrika s váhou nula nepřispívá k tomu, když zvažujete, jestli jsou věci vyvážené. Jeho zatížení ale pořád přispívá k řízení kapacity. Metriky s nulovou váhou jsou stále užitečné a často se používají jako součást chování služby a sledování výkonu. V tomto článku najdete další informace o použití metrik pro monitorování a diagnostiku vašich služeb.

Skutečný dopad různých vah v clusteru je, že cluster Správce prostředků generuje různá řešení. Váhy metriky oznamují clusteru Správce prostředků, že některé metriky jsou důležitější než jiné. Pokud není k dispozici žádné dokonalé řešení, může cluster Správce prostředků preferovat řešení, která lépe vyrovnávají vyšší vážené metriky. Pokud se služba domnívá, že určitá metrika je neimportovaná, může najít jejich použití v nevyrovnaném měřítku. To umožňuje, aby jiná služba získala ještě rozmístění některé metriky, které jsou pro ni důležité.

Pojďme se podívat na příklad některých sestav zatížení a na to, jak různé váhy metriky mají za následek různá přidělení v clusteru. V tomto příkladu vidíte, že přepínání relativní váhy metrik způsobí, že cluster Správce prostředků vytvoří různé mechanismy služeb.

V tomto příkladu jsou k dispozici čtyři různé služby, které vytvářejí sestavy různých hodnot pro dvě různé metriky, metriky a MetricB. V jednom případě jsou všechny služby, které definuje metrika, nejdůležitější (váha = vysoká) a MetricB jako neimportované (váha = nízká). V důsledku toho uvidí, že cluster Správce prostředků umístí služby, aby byla metrika lépe vyvážená, než MetricB. "Lépe vyvážené" znamená, že metrika má nižší směrodatnou odchylku než MetricB. V druhém případě vrátíme váhy metriky. V důsledku toho cluster Správce prostředků prohodí služby A a B, aby se přizpůsobilo přidělení, kde je MetricB lépe vyvážené, než je metrika.

Hmotnosti globálních metrik

Řekněme, že služba Service definuje metriku jako vysokou váhu a ServiceB nastaví váhu metriky na nízká nebo nula. Jaká je skutečná váha, která končí použití?

Pro každou metriku je sledováno více vah. První tloušťka je ta, která je definována pro metriku při vytvoření služby. Druhá váha je globální váha, která je automaticky vypočítána. Správce prostředků clusteru používá tyto váhy při bodování řešení. Je důležité brát v úvahu oba váhy. To umožňuje, aby cluster Správce prostředků vyrovnávat každou službu podle svých priorit a také zajistil, že se cluster jako celek přidělí správně.

Co se stane, když se cluster Správce prostředků nestará o globální i místní zůstatek? Dobře je snadné vytvořit řešení, která jsou globálně vyvážená, ale výsledkem je špatné vyvážení 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 zjistíte, co se stane, když se bude brát pouze globální zůstatek:

V horním příkladu, který je založený jenom na globálním zůstatku, cluster jako celek je skutečně vyvážený. Všechny uzly mají stejný počet primárních prvků a stejné číslo jako celkový počet replik. Nicméně pokud se podíváte na skutečný dopad tohoto přidělení, není tak dobrý: ztráta jakéhokoli uzlu má dopad na určitou úlohu, protože zabírá všechny primární údaje. Například pokud první uzel neprojde tři primárními verzemi pro tři různé oddíly služby Circle, ztratí se všechny tři. Naopak, trojúhelník a šestiúhelníkové služby mají své oddíly ke ztrátě repliky. To nezpůsobuje žádné přerušení, kromě nutnosti obnovení repliky.

V dolním příkladu cluster Správce prostředků distribuuje repliky založené na globálním zůstatku i na úrovni služby. Při výpočtu skóre řešení poskytuje většina váhy globálnímu řešení a (konfigurovatelná) část k jednotlivým službám. Globální zůstatek pro metriku se vypočítá na základě průměru vah metriky od jednotlivých služeb. Každá služba je vyvážená podle vlastní definované váhy metriky. Tím se zajistí, že se služby rovnoměrně vyrovnávají podle svých potřeb. V důsledku toho dojde při selhání jednoho prvního uzlu k distribuci selhání napříč všemi oddíly všech služeb. Dopad na každý je stejný.

Další kroky

• Další informace o konfiguraci služeb najdete v informacích o konfiguraci služeb(Service-Fabric-cluster-Resource-Manager-Configure-Services.MD).
• Definování metrik defragmentace je jedním ze způsobů, jak konsolidovat zatížení uzlů místo jejich rozprostření. Informace o tom, jak nakonfigurovat defragmentaci, najdete v tomto článku .
• Informace o tom, jak cluster Správce prostředků spravuje a vyrovnává zatížení v clusteru, najdete v článku o Vyrovnávání zatížení .
• začněte od začátku a získejte úvod do clusteru Service Fabric Správce prostředků
• Náklady na pohyb jsou jedním ze způsobů signalizace clusteru Správce prostředků, že některé služby jsou dražší než ostatní. Další informace o nákladech na přesun najdete v tomto článku .