Erőforrás-felhasználás és -terhelés kezelése a Service Fabricben metrikákkal

A metrikák azok az erőforrások, amelyekkel a szolgáltatások törődnek, és amelyeket a fürt csomópontjai biztosítanak. A metrika minden, amit kezelni szeretne a szolgáltatások teljesítményének javítása vagy monitorozása érdekében. Figyelheti például a memóriahasználatot, hogy megtudja, a szolgáltatás túlterhelt-e. Egy másik lehetőség annak kiderítése, hogy a szolgáltatás áthelyezhető-e olyan helyre, ahol a memória kevésbé korlátozott a jobb teljesítmény érdekében.

A metrikák közé tartoznak például a memória, a lemez és a CPU-használat. Ezek a metrikák fizikai metrikák, amelyek a kezelni kívánt csomópont fizikai erőforrásainak felelnek meg. A metrikák lehetnek (és általában) logikai metrikák is. A logikai metrikák a következők: "MyWorkQueueDepth" vagy "MessagesToProcess" vagy "TotalRecords". A logikai metrikák alkalmazásalapúak, és közvetetten megfelelnek bizonyos fizikai erőforrás-felhasználásnak. A logikai metrikák gyakoriak, mert a fizikai erőforrások szolgáltatásonkénti használatának mérése és jelentése nehézkes lehet. A saját fizikai metrikák mérésének és jelentésének összetettsége miatt a Service Fabric is biztosít néhány alapértelmezett metrikát.

Alapértelmezett metrikák

Tegyük fel, hogy szeretné elkezdeni a szolgáltatás írását és üzembe helyezését. Ezen a ponton nem tudja, hogy milyen fizikai vagy logikai erőforrásokat használ fel. Ez rendben van! A Service Fabric-fürt Resource Manager használ néhány alapértelmezett metrikát, ha más metrikák nincsenek megadva. Ezek a következők:

• PrimaryCount – A csomópont elsődleges replikáinak száma
• ReplicaCount – a csomópont összes állapotalapú replikájának száma
• Darabszám – a csomópont összes szolgáltatásobjektumának száma (állapot nélküli és állapotalapú)

Metrika	Állapot nélküli példány betöltése	Állapotalapú másodlagos terhelés	Állapotalapú elsődleges terhelés	Tömeg
PrimaryCount	0	0	1	Magas
ReplicaCount	0	1	1	Közepes
Darabszám	1	1	1	Alacsony

Az alapszintű számítási feladatokhoz az alapértelmezett metrikák megfelelő eloszlást biztosítanak a fürtön belüli munka számára. Az alábbi példában lássuk, mi történik, ha két szolgáltatást hozunk létre, és az alapértelmezett metrikákra támaszkodunk a kiegyensúlyozáshoz. Az első szolgáltatás egy állapotalapú szolgáltatás három partícióval és három célreplikakészlet-mérettel. A második szolgáltatás egy állapot nélküli szolgáltatás egy partícióval és három példányszámmal.

A következő eredményt kapjuk:

Ügyeljen a következőkre:

• Az állapotalapú szolgáltatás elsődleges replikái több csomópont között vannak elosztva
• Ugyanazon partíció replikái különböző csomópontokon találhatók
• Az előválasztások és a másodlagosak teljes száma el van osztva a fürtön
• A szolgáltatásobjektumok teljes száma egyenletesen van lefoglalva az egyes csomópontokon

Jó!

Az alapértelmezett metrikák első lépésként remekül működnek. Az alapértelmezett metrikák azonban csak az eddigieket fogják szállítani. Például: Mekkora annak a valószínűsége, hogy a kiválasztott particionálási séma tökéletesen egyenletes kihasználtságot eredményez az összes partíció esetében? Mi az esélye annak, hogy egy adott szolgáltatás terhelése állandó az idő múlásával, vagy akár egyszerre több partíción is ugyanaz?

Futtathat csak az alapértelmezett metrikákkal. Ez azonban általában azt jelenti, hogy a fürt kihasználtsága alacsonyabb és egyenlőtlenebb a kívántnál. Ennek az az oka, hogy az alapértelmezett metrikák nem adaptívak, és feltételezik, hogy minden egyenértékű. Például egy foglalt elsődleges és egy olyan, amely nem is járul hozzá az "1" elemhez a PrimaryCount metrikához. A legrosszabb esetben, ha csak az alapértelmezett metrikákat használja, az is okozhat túlütemezett csomópontokat, amelyek teljesítményproblémákat okozhatnak. Ha a lehető legtöbbet szeretné kihozni a fürtből, és el szeretné kerülni a teljesítményproblémákat, egyéni metrikákat és dinamikus terhelésjelentéseket kell használnia.

Egyéni metrikák

A metrikák nevesített szolgáltatáspéldányonként vannak konfigurálva a szolgáltatás létrehozásakor.

Minden metrika rendelkezik néhány olyan tulajdonsággal, amely leírja: egy név, egy súly és egy alapértelmezett terhelés.

• Metrika neve: A metrika neve. A metrikanév a fürtben lévő metrika egyedi azonosítója a Resource Manager szempontjából.

Megjegyzés

Az egyéni metrika neve nem lehet a rendszermetrikanevek egyike sem, például servicefabric:/_CpuCores vagy servicefabric:/_MemoryInMB, mivel nem definiált viselkedéshez vezethet. A Service Fabric 9.1-es verziójától kezdődően az ilyen egyéni metrikanevekkel rendelkező meglévő szolgáltatások esetében a rendszer állapotriasztást ad ki, amely jelzi, hogy a metrikanév helytelen.

• Súly: A metrika súlya határozza meg, hogy mennyire fontos ez a metrika a szolgáltatás többi metrikáihoz képest.
• Alapértelmezett terhelés: Az alapértelmezett terhelés eltérően jelenik meg attól függően, hogy a szolgáltatás állapot nélküli vagy állapotalapú.
  • Állapot nélküli szolgáltatások esetén minden metrika egyetlen DefaultLoad nevű tulajdonságot tartalmaz
  • Állapotalapú szolgáltatások esetében a következőket kell meghatározni:
    • PrimaryDefaultLoad: A szolgáltatás által elsődlegesként használt metrika alapértelmezett mennyisége
    • SecondaryDefaultLoad: A szolgáltatás által használt metrika alapértelmezett mennyisége másodlagosként

Megjegyzés

Ha egyéni metrikákat definiál, és az alapértelmezett metrikákat is használni szeretné, explicit módon hozzá kell adnia az alapértelmezett metrikákat, és meg kell határoznia a súlyokat és értékeket. Ennek az az oka, hogy meg kell határoznia az alapértelmezett metrikák és az egyéni metrikák közötti kapcsolatot. Előfordulhat például, hogy a ConnectionCount vagy a WorkQueueDepth érték jobban érdekli, mint az elsődleges disztribúció. Alapértelmezés szerint a PrimaryCount metrika súlya Magas, ezért a többi metrika hozzáadásakor közepesre szeretné csökkenteni, hogy azok elsőbbséget élvezhessenek.

Metrikák meghatározása a szolgáltatáshoz – példa

Tegyük fel, hogy a következő konfigurációt szeretné használni:

• A szolgáltatás egy "ConnectionCount" nevű metrikát jelent
• Az alapértelmezett metrikákat is használni szeretné
• Elvégzett néhány mérést, és tudja, hogy a szolgáltatás elsődleges replikája általában 20 egység "ConnectionCount" értéket vesz igénybe.
• A másodfokok 5 egységnyi "ConnectionCount" értéket használnak
• Tudja, hogy a "ConnectionCount" a legfontosabb metrika az adott szolgáltatás teljesítményének kezelése szempontjából
• Továbbra is kiegyensúlyozott elsődleges replikákat szeretne. Az elsődleges replikák kiegyensúlyozása általában jó ötlet, függetlenül attól, hogy mi történik. Ez segít megakadályozni, hogy egy csomópont vagy tartalék tartomány elvesztése hatással legyen az elsődleges replikák többségére.
• Ellenkező esetben az alapértelmezett metrikák rendben vannak

A metrikakonfigurációval rendelkező szolgáltatás létrehozásához a következő kódot kell írnia:

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

Megjegyzés

A fenti példák és a dokumentum többi része a metrikák elnevezett szolgáltatásonkénti kezelését ismerteti. A szolgáltatásokhoz tartozó metrikákat a szolgáltatástípus szintjén is meg lehet határozni. Ezt úgy érheti el, hogy megadja őket a szolgáltatásjegyzékekben. A típusszintű metrikák definiálása több okból sem ajánlott. Az első ok az, hogy a metrikanevek gyakran környezetspecifikusak. Ha nincs érvényben határozott szerződés, nem lehet biztos abban, hogy az egyik környezetben a "Cores" metrika nem "MiliCores" vagy "CoReS" más környezetben. Ha a metrikák definiálva vannak a jegyzékben, környezetenként új jegyzékfájlokat kell létrehoznia. Ez általában a különböző jegyzékek elterjedéséhez vezet, amelyek csak kisebb különbségeket mutatnak, ami felügyeleti nehézségekhez vezethet.

A metrikabetöltések általában névvel ellátott szolgáltatáspéldányonként vannak hozzárendelve. Tegyük fel például, hogy a szolgáltatás egy példányát hozza létre a CustomerA számára, aki csak könnyedén szeretné használni. Tegyük fel azt is, hogy egy másikat hoz létre a CustomerB számára, amely nagyobb számítási feladattal rendelkezik. Ebben az esetben valószínűleg módosítani szeretné a szolgáltatások alapértelmezett terhelését. Ha jegyzékfájlokkal definiált metrikákkal és terhelésekkel rendelkezik, és támogatni szeretné ezt a forgatókönyvet, akkor az egyes ügyfelek különböző alkalmazás- és szolgáltatástípusokat igényelnek. A szolgáltatás létrehozásakor definiált értékek felülbírálják a jegyzékben definiált értékeket, így ezzel beállíthatja az adott alapértelmezett értékeket. Ez azonban azt eredményezi, hogy a jegyzékekben deklarált értékek nem egyeznek meg a szolgáltatás által ténylegesen futtatott értékekkel. Ez zavart okozhat.

Emlékeztetőül: ha csak az alapértelmezett metrikákat szeretné használni, a szolgáltatás létrehozásakor egyáltalán nem kell megérintenie a metrikák gyűjteményét, és semmi különlegeset sem kell tennie. Az alapértelmezett metrikák automatikusan használatosak lesznek, ha nincs más definiálva.

Most tekintsük át ezeket a beállításokat részletesebben, és beszéljünk az általa befolyásolt viselkedésről.

Betöltés

A metrikák definiálásának lényege, hogy egy bizonyos terhelést képviseljen. A terhelés az, hogy egy adott metrika mekkora részét használja fel egy adott csomópont egyes szolgáltatáspéldánya vagy replikája. A terhelés szinte bármely ponton konfigurálható. Például:

• A terhelés definiálható egy szolgáltatás létrehozásakor. Az ilyen típusú terhelés-konfigurációt alapértelmezett terhelésnek nevezzük.
• A szolgáltatás metrikaadatai, beleértve az alapértelmezett betöltéseket is, frissíthetők a szolgáltatás létrehozása után. Ez a metrikafrissítés egy szolgáltatás frissítésével történik.
• Az adott partíció terhelése visszaállítható az adott szolgáltatás alapértelmezett értékeire. Ezt a metrikafrissítést partícióterhelés alaphelyzetbe állításának nevezzük.
• A terhelés szolgáltatásobjektumonként, futásidőben dinamikusan jelenthető. Ezt a metrikafrissítést jelentési terhelésnek nevezzük.
• A partíció replikáinak vagy példányainak terhelése is frissíthető a terhelési értékek Fabric API-híváson keresztüli jelentésével. Ezt a metrikafrissítést egy partíció jelentési terhelésének nevezzük.

Mindezek a stratégiák ugyanazon a szolgáltatáson belül használhatók az élettartama során.

Alapértelmezett terhelés

Az alapértelmezett terhelés az, hogy a szolgáltatás egyes szolgáltatásobjektumai (állapot nélküli példánya vagy állapotalapú replikája) mennyi metrikát használnak fel. A fürt Resource Manager ezt a számot használja a szolgáltatásobjektum terheléséhez, amíg más információt nem kap, például egy dinamikus terhelési jelentést. Az egyszerűbb szolgáltatások esetében az alapértelmezett terhelés egy statikus definíció. Az alapértelmezett terhelés soha nem frissül, és a szolgáltatás teljes élettartama alatt használatos. Az alapértelmezett terhelések nagyszerűen működnek az egyszerű kapacitástervezési forgatókönyvekben, ahol bizonyos mennyiségű erőforrás különböző számítási feladatokhoz van dedikáltan, és nem változnak.

Megjegyzés

A fürt csomópontjaihoz tartozó kapacitáskezelésről és kapacitások meghatározásáról ebben a cikkben talál további információt.

A fürt Resource Manager lehetővé teszi, hogy az állapotalapú szolgáltatások eltérő alapértelmezett terhelést adjanak meg az elsődleges és a másodsorban. Az állapot nélküli szolgáltatások csak egy értéket adhatnak meg, amely az összes példányra vonatkozik. Az állapotalapú szolgáltatások esetében az elsődleges és másodlagos replikák alapértelmezett terhelése általában eltérő, mivel a replikák különböző típusú feladatokat végeznek az egyes szerepkörökben. Az előválasztások például általában olvasást és írást is szolgálnak, és kezelik a számítási terhek nagy részét, míg a másodjegyzők nem. Az elsődleges replikák alapértelmezett terhelése általában magasabb, mint a másodlagos replikák alapértelmezett terhelése. A valós számoknak a saját méréseiktől kell függenie.

Dinamikus terhelés

Tegyük fel, hogy már egy ideje futtatja a szolgáltatást. Némi figyeléssel a következőt észlelte:

1. Egy adott szolgáltatás egyes partíciói vagy példányai több erőforrást használnak fel, mint mások
2. Egyes szolgáltatások terhelése idővel változik.

Sok minden okozhat ilyen típusú terhelés-ingadozásokat. A különböző szolgáltatások vagy partíciók például különböző követelményekkel rendelkező ügyfelekhez vannak társítva. A terhelés is változhat, mert a szolgáltatás által végzett munka mennyisége a nap folyamán változik. Az októl függetlenül általában nincs egyetlen szám, amelyet alapértelmezés szerint használhat. Ez különösen akkor igaz, ha a lehető legtöbb kihasználtságot szeretné kihozni a fürtből. Az alapértelmezett betöltéshez választott értékek némelyike hibás. A helytelen alapértelmezett betöltési eredmények azt eredményezik, hogy a fürt Resource Manager az erőforrások kiosztása alatt vagy felett. Ennek eredményeképpen vannak olyan csomópontjai, amelyek túl vannak használva vagy kihasználatlanok, annak ellenére, hogy a fürt Resource Manager úgy véli, hogy a fürt kiegyensúlyozott. Az alapértelmezett terhelések továbbra is jóak, mivel a kezdeti elhelyezéshez nyújtanak némi információt, de nem teljes körűek a valós számítási feladatokhoz. A változó erőforráskövetelmények pontos rögzítéséhez a fürt Resource Manager lehetővé teszi, hogy minden szolgáltatásobjektum frissítse a saját terhelését futásidőben. Ezt dinamikus terhelésjelentésnek nevezzük.

A dinamikus terhelési jelentések lehetővé teszik a replikák vagy példányok számára, hogy az élettartamuk során módosítsák a metrikák foglalási/jelentett terhelését. Ha egy szolgáltatásreplika vagy -példány hideg volt, és nem végzett semmilyen munkát, általában azt jelenti, hogy alacsony mennyiségű metrikát használ. Az elfoglalt replikák vagy példányok azt jelentik, hogy többet használnak.

A replikán vagy példányonkénti terhelés jelentésével a Fürt Resource Manager átrendezheti a fürt egyes szolgáltatásobjektumait. A szolgáltatások átrendezése segít biztosítani, hogy megkapják a szükséges erőforrásokat. Az elfoglalt szolgáltatások hatékonyan kapják meg a más replikákból vagy példányokból származó erőforrásokat, amelyek jelenleg hidegek, vagy kevesebb munkát végeznek.

A Reliable Servicesben a betöltést dinamikusan betöltő kód a következőképpen néz ki:

Kód:

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

A szolgáltatások a létrehozáskor a számára meghatározott metrikák bármelyikéről jelentést készíthetnek. Ha egy szolgáltatás olyan metrikához töltődik be, amelyet nincs konfigurálva, a Service Fabric figyelmen kívül hagyja ezt a jelentést. Ha más, egyidejűleg jelentett metrikák is érvényesek, akkor a rendszer elfogadja ezeket a jelentéseket. A szolgáltatáskód képes mérni és jelenteni az összes metrikát, amelyet tud, és az operátorok a szolgáltatáskód módosítása nélkül is megadhatja a használni kívánt metrika-konfigurációt.

Partíció terhelésének jelentéskészítése

Az előző szakasz bemutatja, hogyan töltik be magukat a szolgáltatásreplikák vagy -példányok. További lehetőség a partíció replikáinak vagy példányainak terhelésének dinamikus jelentésére a Service Fabric API-val. Ha egy partíció terhelését jelenti, egyszerre több partícióról is jelentést készíthet.

Ezek a jelentések ugyanúgy lesznek használatban, mint a replikákból vagy példányokból származó jelentések betöltése. A jelentett értékek mindaddig érvényesek lesznek, amíg az új terhelési értékeket nem jelenti a replika vagy a példány, vagy egy partíció új terhelési értékének jelentésével.

Ezzel az API-val többféleképpen frissítheti a fürt terhelését:

• Az állapotalapú szolgáltatáspartíciók frissíthetik az elsődleges replikabetöltést.
• Az állapot nélküli és az állapotalapú szolgáltatások is frissíthetik az összes másodlagos replika vagy példány terhelését.
• Az állapot nélküli és az állapotalapú szolgáltatások is frissíthetik egy adott replika vagy -példány terhelését egy csomóponton.

A frissítések partíciónkénti kombinálása is lehetséges egyszerre. Egy adott partíció terhelésfrissítéseinek kombinációját a PartitionMetricLoadDescription objektumon keresztül kell megadni, amely a terhelésfrissítések megfelelő listáját is tartalmazhatja az alábbi példában látható módon. A terhelésfrissítések a MetricLoadDescription objektumon keresztül jelennek meg, amely egy metrikanévvel megadott metrika aktuális vagy előrejelzett terhelési értékét tartalmazhatja.

Megjegyzés

Az előrejelzett metrikabetöltési értékek jelenleg előzetes verziójú funkciók. Lehetővé teszi az előrejelzett terhelési értékek jelentését és használatát a Service Fabric oldalán, de ez a funkció jelenleg nincs engedélyezve.

Több partíció terhelésének frissítése egyetlen API-hívással lehetséges, amely esetben a kimenet partíciónkénti választ fog tartalmazni. Ha a partíciófrissítés valamilyen okból nem lesz sikeresen alkalmazva, a rendszer kihagyja a partíció frissítéseit, és megadja a célpartíció megfelelő hibakódját:

• PartitionNotFound – A megadott partícióazonosító nem létezik.
• ReconfigurationPending – A partíció jelenleg újrakonfigurálva van.
• InvalidForStatelessServices – Kísérlet történt az állapot nélküli szolgáltatáshoz tartozó partíció elsődleges replikájának terhelésének módosítására.
• ReplicaDoesNotExist – A másodlagos replika vagy példány nem létezik egy megadott csomóponton.
• InvalidOperation – Két esetben fordulhat elő: a rendszeralkalmazáshoz tartozó partíció terhelésének frissítése vagy az előrejelzett terhelés frissítése nincs engedélyezve.

Ha ezek közül néhány hibát ad vissza, frissítheti egy adott partíció bemenetét, és újrapróbálhatja annak frissítését.

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

Ebben a példában az 53df3d7f-5471-403b-b736-bde6ad584f42 partíció utolsó jelentett terhelését fogja frissíteni. A CustomMetricName0 metrika elsődleges replikabetöltése 100 értékkel frissül. Ugyanakkor a NodeName0 csomóponton található adott másodlagos replika ugyanazon metrikájára vonatkozó terhelés 200 értékkel frissül.

Szolgáltatás metrikakonfigurációjának frissítése

A szolgáltatáshoz társított metrikák listája és a metrikák tulajdonságai dinamikusan frissíthetők a szolgáltatás élő állapotában. Ez lehetővé teszi a kísérletezést és a rugalmasságot. Néhány példa arra, hogy ez mikor hasznos:

• metrika letiltása egy adott szolgáltatás hibás jelentésével
• a metrikák súlyainak a kívánt viselkedés alapján történő újrakonfigurálása
• új metrikák engedélyezése csak akkor, ha a kód már üzembe lett helyezve és más mechanizmusokon keresztül lett érvényesítve
• a szolgáltatás alapértelmezett terhelésének módosítása a megfigyelt viselkedés és a használat alapján

A metrikakonfiguráció módosítására szolgáló fő API-k a C# és Update-ServiceFabricService a PowerShell használatával érhetők FabricClient.ServiceManagementClient.UpdateServiceAsync el. Az ezekkel az API-kkal megadott információk azonnal lecserélik a szolgáltatás meglévő metrikaadatait.

Alapértelmezett terhelési értékek és dinamikus terhelési jelentések keverése

Az alapértelmezett terhelés és a dinamikus terhelések ugyanahhoz a szolgáltatáshoz használhatók. Ha egy szolgáltatás az alapértelmezett terhelési és a dinamikus terhelési jelentéseket is használja, az alapértelmezett terhelés becslésként szolgál mindaddig, amíg a dinamikus jelentések meg nem jelennek. Az alapértelmezett terhelés jó, mert a fürtnek Resource Manager valamit, amellyel dolgoznia kell. Az alapértelmezett terhelés lehetővé teszi, hogy a fürt Resource Manager a szolgáltatásobjektumokat a létrehozásukkor jó helyekre helyezze. Ha nincs megadva alapértelmezett terhelési információ, a szolgáltatások elhelyezése gyakorlatilag véletlenszerű. Amikor a terhelési jelentések később érkeznek, a kezdeti véletlenszerű elhelyezés gyakran helytelen, és a fürt Resource Manager át kell helyeznie a szolgáltatásokat.

Vegyük az előző példánkat, és nézzük meg, mi történik, ha hozzáadunk néhány egyéni metrikát és dinamikus terhelésjelentést. Ebben a példában a "MemoryInMb" metrikát használjuk példaként.

Megjegyzés

A memória az egyik olyan rendszermetrika, amelyet a Service Fabric képes szabályozni, és általában nehéz saját maga jelenteni. Valójában nem számítunk arra, hogy jelentést készít a memóriahasználatról; A memória a fürt Resource Manager képességeinek megismeréséhez nyújt segítséget.

Tegyük fel, hogy eredetileg a következő paranccsal hoztuk létre az állapotalapú szolgáltatást:

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

Emlékeztetőül: ez a szintaxis ("MetricName, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad").

Nézzük meg, hogyan nézhet ki egy lehetséges fürtelrendezés:

Néhány dolog, amit érdemes megjegyezni:

• A partíción belüli másodlagos replikák mindegyike saját terheléssel rendelkezhet
• A metrikák összességében kiegyensúlyozottnak tűnnek. Memória esetén a maximális és minimális terhelés aránya 1,75 (a legnagyobb terhelésű csomópont az N3, a legkisebb N2, a 28/16 = 1,75).

Néhány dolgot még meg kell magyaráznunk:

• Mi határozza meg, hogy az 1,75 arány ésszerű volt-e vagy sem? Honnan tudja a fürt Resource Manager, hogy ez elég jó-e, vagy hogy van-e még tennivaló?
• Mikor történik a kiegyensúlyozás?
• Mit jelent az, hogy a memória "Magas" súlyú volt?

Metrikasúlyok

Fontos, hogy ugyanazokat a metrikákat nyomon követve különböző szolgáltatásokban is. Ez a globális nézet teszi lehetővé, hogy a fürt Resource Manager nyomon kövesse a fürtben lévő felhasználást, kiegyensúlyozhassa a használatot a csomópontok között, és győződjön meg arról, hogy a csomópontok nem lépik át a kapacitást. Előfordulhat azonban, hogy a szolgáltatások eltérő nézetekkel rendelkeznek ugyanannak a metrikának a fontosságáról. Emellett a sok metrikát és sok szolgáltatást tartalmazó fürtökben nem feltétlenül léteznek tökéletesen kiegyensúlyozott megoldások az összes metrika esetében. Hogyan kezelje a fürt ezeket a helyzeteket Resource Manager?

A metrikavastagságok lehetővé teszik, hogy a fürt Resource Manager eldöntse, hogyan kell egyensúlyozni a fürtöt, ha nincs tökéletes válasz. A metrikasúlyok lehetővé teszik, hogy a fürt Resource Manager különbözőképpen egyensúlyba hozhassa az egyes szolgáltatásokat. A metrikáknak négy különböző súlyszintjük lehet: Nulla, Alacsony, Közepes és Magas. A Nulla súlyú metrikák semmit sem adnak hozzá, ha mérlegelik, hogy a dolgok kiegyensúlyozottak-e vagy sem. Terhelése azonban továbbra is hozzájárul a kapacitáskezeléshez. A nulla súlyú metrikák továbbra is hasznosak, és gyakran használják a szolgáltatás viselkedésének és teljesítményének monitorozása részeként. Ez a cikk további információkat nyújt a metrikák használatáról a szolgáltatások monitorozásához és diagnosztikáihoz.

A fürt különböző metrikasúlyainak valós hatása az, hogy a fürt Resource Manager különböző megoldásokat hoz létre. A metrikák súlyozása azt jelzi a fürtnek Resource Manager, hogy bizonyos metrikák fontosabbak másoknál. Ha nincs tökéletes megoldás, a fürt Resource Manager előnyben részesítheti azokat a megoldásokat, amelyek jobb egyensúlyt biztosítanak a nagyobb súlyozású metrikák között. Ha egy szolgáltatás úgy véli, hogy egy adott metrika nem lényeges, előfordulhat, hogy a metrika használata kiegyensúlyozatlan. Ez lehetővé teszi, hogy egy másik szolgáltatás egyenletes eloszlást kapjon a számára fontos metrikákról.

Tekintsünk meg egy példát néhány terhelési jelentésre, és arra, hogy a különböző metrikasúlyok hogyan eredményeznek különböző foglalásokat a fürtben. Ebben a példában azt látjuk, hogy a metrikák relatív súlyának váltása miatt a fürt Resource Manager különböző szolgáltatási elrendezéseket hoz létre.

Ebben a példában négy különböző szolgáltatás létezik, amelyek mindegyike két különböző metrika, a MetricA és a MetricB különböző értékeit jelenti. Egy esetben a MetricA-t definiáló összes szolgáltatás a legfontosabb (Súly = Magas), a MetricB pedig nem lényeges (Súly = Alacsony). Ennek eredményeként azt látjuk, hogy a fürt Resource Manager helyezi el a szolgáltatásokat, hogy a MetricA kiegyensúlyozottabb legyen, mint a MetricB. A "kiegyensúlyozottabb" azt jelenti, hogy a MetricA alacsonyabb szórással rendelkezik, mint a MetricB. A második esetben megfordítjuk a metrikasúlyokat. Ennek eredményeképpen a fürt Resource Manager felcseréli az A és A szolgáltatásokat, hogy olyan foglalást hozzon létre, amelyben a MetricB kiegyensúlyozottabb, mint a MetricA.

Megjegyzés

A metrikasúlyok határozzák meg, hogy a fürt Resource Manager hogyan kell kiegyensúlyozni, de a kiegyensúlyozáskor nem. A kiegyensúlyozással kapcsolatos további információkért tekintse meg ezt a cikket

Globális metrikasúlyok

Tegyük fel, hogy a ServiceA a MetricA-t magas súlyként határozza meg, a ServiceB pedig a MetricA súlyát Alacsony vagy Nulla értékre állítja. Mi a tényleges súly, ami végül használatba kerül?

Minden metrika több súlyt is nyomon követ. Az első súly a szolgáltatás létrehozásakor definiált metrika. A másik súly egy globális súly, amely automatikusan lesz kiszámítva. A fürt Resource Manager mindkét súlyt használja a pontozási megoldásoknál. Mindkét súly figyelembe vétele fontos. Ez lehetővé teszi a fürt Resource Manager, hogy az egyes szolgáltatásokat a saját prioritásainak megfelelően egyensúlyba hozhassa, és hogy a fürt egésze megfelelően legyen lefoglalva.

Mi történne, ha a fürt Resource Manager nem törődne a globális és a helyi egyensúlygal? Könnyű globálisan kiegyensúlyozott megoldásokat létrehozni, amelyek azonban az egyes szolgáltatások erőforrás-egyensúlyának romlásához vezetnek. Az alábbi példában vizsgáljuk meg a csak az alapértelmezett metrikákkal konfigurált szolgáltatást, és nézzük meg, mi történik, ha csak a globális egyenleget vesszük figyelembe:

A legfelső példában, amely csak a globális egyensúlyon alapul, a fürt egésze valóban kiegyensúlyozott. Minden csomópont azonos számú előválasztási és azonos számú replikával rendelkezik. Ha azonban a foglalás tényleges hatását vizsgáljuk, az nem olyan jó: a csomópontok elvesztése aránytalanul érinti egy adott számítási feladatot, mert az az összes előválasztást kiveszi. Ha például az első csomópont meghibásodik, a Circle szolgáltatás három különböző partíciójának három előválasztása elveszne. Ezzel szemben a Háromszög és a Hatszög szolgáltatások partíciói elveszítik a replikát. Ez nem okoz fennakadást, csak a leállási replikát kell helyreállítani.

Az alsó példában a fürt Resource Manager a replikákat a globális és a szolgáltatásonkénti egyenleg alapján is elosztotta. A megoldás pontszámának kiszámításakor a legnagyobb súlyt a globális megoldás kapja, és egy (konfigurálható) részt az egyes szolgáltatásokhoz. A metrikák globális egyenlegének kiszámítása az egyes szolgáltatások metrikasúlyainak átlaga alapján történik. Minden szolgáltatás a saját meghatározott metrikasúlyai szerint van kiegyensúlyozott. Ez biztosítja, hogy a szolgáltatások saját igényeiknek megfelelően kiegyensúlyozottak legyenek. Ennek eredményeképpen, ha ugyanaz az első csomópont meghibásodik, a hiba az összes szolgáltatás összes partíciójára el lesz osztva. A hatás mindegyikre ugyanaz.

Következő lépések

• A szolgáltatások konfigurálásával kapcsolatos további információkért tekintse meg a Szolgáltatások (service-fabric-cluster-resource-manager-configure-services.md) konfigurálását ismertető cikket.
• A töredezettségmentesítési metrikák meghatározása az egyik módszer a csomópontok terhelésének konszolidálására ahelyett, hogy szétosztanák. A töredezettségmentesítés konfigurálásáról ebben a cikkben olvashat.
• Ha tudni szeretné, hogy a fürt Resource Manager hogyan kezeli és egyensúlyozza a fürt terhelését, tekintse meg a terheléselosztásról szóló cikket.
• Kezdje az elejétől, és szerezzen be egy bevezetést a Service Fabric-fürt Resource Manager
• Az áthelyezési költség a fürt Resource Manager jelzi, hogy bizonyos szolgáltatások áthelyezése drágább, mint mások. Ha többet szeretne megtudni a mozgási költségekről, tekintse meg ezt a cikket