Erőforrások szabályozása
Ha több szolgáltatást futtat ugyanazon a csomóponton vagy fürtön, lehetséges, hogy egy szolgáltatás több erőforrást használ fel, és a folyamat más szolgáltatásait éhezteti. Ezt a problémát "zajos szomszédnak" nevezik. Az Azure Service Fabric lehetővé teszi, hogy a fejlesztő szabályozhassa ezt a viselkedést úgy, hogy szolgáltatásonként kéréseket és korlátokat ad meg az erőforrás-használat korlátozásához.
A cikk folytatása előtt javasoljuk, hogy ismerkedjen meg a Service Fabric alkalmazásmodellel és a Service Fabric üzemeltetési modelljével.
Erőforrás-szabályozási metrikák
Az erőforrás-szabályozás a Service Fabricben a szolgáltatáscsomagnak megfelelően támogatott. A szolgáltatáscsomaghoz rendelt erőforrások tovább oszthatók a kódcsomagok között. A Service Fabric szolgáltatáscsomagonként két beépített metrikával támogatja a processzor- és memóriaszabályozást:
CPU (metrika neve
servicefabric:/_CpuCores
): A gazdagépen elérhető logikai mag. Az összes csomópont összes magja azonos súlyozású.Memória (metrika neve
servicefabric:/_MemoryInMB
): A memória megabájtban van kifejezve, és leképezi a gépen elérhető fizikai memóriát.
E két metrika esetében a Fürt Resource Manager (CRM) nyomon követi a fürt teljes kapacitását, a fürt minden csomópontjának terhelését és a fürt többi erőforrását. Ez a két metrika egyenértékű bármely más felhasználóval vagy egyéni metrikákkal.
Megjegyzés
Az egyéni metrikanevek nem tartozhatnak a két metrikanév közé, mivel nem definiált működéshez vezetnek.
Minden meglévő funkció használható velük:
- A fürt a két metrika (alapértelmezett viselkedés) szerint kiegyensúlyozott lehet.
- A fürt töredezettségmentesítése e két metrika alapján végezhető el.
- A fürtök leírásakor a pufferelt kapacitás e két metrika esetében állítható be.
Megjegyzés
Ezek a metrikák nem támogatják a dinamikus terhelésjelentést; ezekhez a metrikákhoz a betöltések a létrehozáskor vannak meghatározva.
Erőforrás-szabályozási mechanizmus
A 7.2-es verziótól kezdve a Service Fabric-futtatókörnyezet támogatja a processzor- és memóriaerőforrásokra vonatkozó kérések és korlátozások specifikációját.
Megjegyzés
A Service Fabric 7.2-nél régebbi futtatókörnyezeti verziói csak olyan modelleket támogatnak, ahol egyetlen érték szolgál egy adott erőforrás (CPU vagy memória) kéréseként és korlátjaként is. Ezt a jelen dokumentumban a RequestsOnly specifikációként ismertetjük.
Kérelmek: A processzor- és memóriakérelmek értékei a fürt Resource Manager (CRM) által a és
servicefabric:/_MemoryInMB
aservicefabric:/_CpuCores
metrikákhoz használt terheléseket jelölik. Más szóval a CRM úgy véli, hogy egy szolgáltatás erőforrás-felhasználása megegyezik a kérésértékeivel, és ezeket az értékeket használja az elhelyezési döntések meghozatalakor.Határok: A processzor- és memóriakorlátok azokat a tényleges erőforráskorlátokat jelölik, amelyek akkor lépnek érvénybe, amikor egy folyamat vagy egy tároló aktiválódik egy csomóponton.
A Service Fabric lehetővé teszi a RequestsOnly, a LimitsOnly és a RequestsAndLimits specifikációkat a cpu-hoz és a memóriához.
- A RequestsOnly specifikáció használata esetén a Service Fabric a kérelemértékeket is korlátokként használja.
- Ha a LimitsOnly specifikációt használja, a Service Fabric a kérelemértékeket 0-nak tekinti.
- A RequestsAndLimits specifikáció használata esetén a korlátértékeknek a kérelem értékénél nagyobbnak vagy egyenlőnek kell lenniük.
Az erőforrás-szabályozási mechanizmus jobb megértéséhez lássunk egy példa elhelyezési forgatókönyvet a CPU-erőforrás RequestsOnly specifikációjával (a memóriaszabályozási mechanizmus egyenértékű). Fontolja meg a két processzormaggal és két szolgáltatáscsomaggal rendelkező csomópontot, amelyek a csomópontra kerülnek. Az első helyezendő szolgáltatáscsomag csak egy tárolókódcsomagból áll, és csak egy processzormag kérését adja meg. A második helyezendő szolgáltatáscsomag csak egy folyamatalapú kódcsomagból áll, és csak egy processzormag kérését adja meg. Mivel mindkét szolgáltatáscsomag requestsOnly specifikációval rendelkezik, a korlátértékek a kérelemértékekre vannak állítva.
Először az egy processzormagot kérő tárolóalapú szolgáltatáscsomag kerül a csomópontra. A futtatókörnyezet aktiválja a tárolót, és beállítja a processzorkorlátot egy magra. A tároló nem fog tudni egynél több magot használni.
Ezután a folyamatalapú szolgáltatáscsomag, amely egy processzormagot kér le, a csomóponton lesz elhelyezve. A futtatókörnyezet aktiválja a szolgáltatásfolyamatot, és egy magra állítja a processzorkorlátot.
Ezen a ponton a kérelmek összege megegyezik a csomópont kapacitásával. A CRM nem helyez el több tárolót vagy szolgáltatásfolyamatot cpu-kérésekkel ezen a csomóponton. A csomóponton egy folyamat és egy tároló fut egy maggal, és nem fog egymással versengeni a processzorért.
Most tekintsük meg újra a példánkat egy RequestsAndLimits specifikációval. Ezúttal a tárolóalapú szolgáltatáscsomag egy processzormag kérését és két processzormag korlátját adja meg. A folyamatalapú szolgáltatáscsomag egy kérést és egy processzormag korlátját is meghatározza.
- Először a tárolóalapú szolgáltatáscsomag kerül a csomópontra. A futtatókörnyezet aktiválja a tárolót, és két magra állítja a processzorkorlátot. A tároló nem fog tudni két magnál több magot használni.
- Ezután a folyamatalapú szolgáltatáscsomag a csomópontra kerül. A futtatókörnyezet aktiválja a szolgáltatásfolyamatot, és egy magra állítja a processzorkorlátot.
Ezen a ponton a csomóponton elhelyezett szolgáltatáscsomagok CPU-kéréseinek összege megegyezik a csomópont cpu-kapacitásával. A CRM nem helyez el több tárolót vagy szolgáltatásfolyamatot cpu-kérésekkel ezen a csomóponton. A csomóponton azonban a korlátok összege (a tároló két magja + a folyamat egy magja) meghaladja a két mag kapacitását. Ha a tároló és a folyamat egyszerre szakad meg, lehetséges, hogy versengés történik a CPU-erőforrással. Az ilyen versengést a platform mögöttes operációs rendszere kezeli. Ebben a példában a tároló két cpu-magra is felszakadhat, ami azt eredményezi, hogy a folyamat egy processzormag kérése nem garantált.
Megjegyzés
Ahogy az előző példában is látható, a processzor és a memória kérésértékei nem vezetnek erőforrás-foglaláshoz egy csomóponton. Ezek az értékek azt az erőforrás-felhasználást jelölik, amelyet a fürt Resource Manager figyelembe venni az elhelyezési döntések meghozatalakor. A korlátértékek azokat a tényleges erőforráskorlátokat jelölik, amelyek akkor lépnek érvénybe, amikor egy folyamat vagy tároló aktiválódik egy csomóponton.
Van néhány olyan helyzet, amikor versengés lehet a CPU-val. Ilyen helyzetekben a példánkban szereplő folyamat és tároló zajos szomszédproblémát tapasztalhat:
Szabályozott és nem szabályozott szolgáltatások és tárolók keverése: Ha egy felhasználó erőforrás-szabályozás nélkül hoz létre egy szolgáltatást, a futtatókörnyezet úgy látja, hogy nem használ erőforrásokat, és a példánkban elhelyezheti a csomóponton. Ebben az esetben ez az új folyamat hatékonyan használ fel processzorhasználatot a csomóponton már futó szolgáltatások rovására. Erre a problémára két megoldás létezik. Ne keverje össze a szabályozott és a nem szabályozott szolgáltatásokat ugyanazon a fürtön, vagy használjon elhelyezési korlátozásokat , hogy ez a két szolgáltatástípus ne ugyanazon a csomópontkészleten végződjön.
Amikor egy másik folyamat indul el a csomóponton, a Service Fabricen (például egy operációsrendszer-szolgáltatáson) kívül: Ebben az esetben a Service Fabricen kívüli folyamat a cpu-t is a meglévő szolgáltatásokkal szemben állítja. Erre a problémára az a megoldás, hogy helyesen állítja be a csomópontkapacitásokat, hogy figyelembe vegyék az operációs rendszer többletterhelését, amint az a következő szakaszban látható.
Ha a kérések nem egyenlők a korlátokkal: A KérésekAndLimits példában korábban leírtak szerint a kérések nem eredményeznek erőforrások foglalását egy csomóponton. Ha egy csomóponton a kérelmeknél nagyobb korlátokkal rendelkező szolgáltatás van elhelyezve, az erőforrásokat (ha vannak) a korlátaiig felhasználhatja. Ilyen esetekben előfordulhat, hogy a csomópont többi szolgáltatása nem tudja a kérésértékekig felhasználni az erőforrásokat.
Fürtbeállítás az erőforrás-szabályozás engedélyezéséhez
Amikor egy csomópont elindul és csatlakozik a fürthöz, a Service Fabric észleli a rendelkezésre álló memóriamennyiséget és a rendelkezésre álló magszámot, majd beállítja a csomópontkapacitásokat a két erőforráshoz.
Ha pufferterületet szeretne hagyni az operációs rendszer és a csomóponton esetleg futó egyéb folyamatok számára, a Service Fabric csak a csomópont rendelkezésre álló erőforrásainak 80%-át használja. Ez a százalék konfigurálható, és módosítható a fürtjegyzékben.
Íme egy példa arra, hogyan utasíthatja a Service Fabricet, hogy az elérhető processzor 50%-át és a rendelkezésre álló memória 70%-át használja:
<Section Name="PlacementAndLoadBalancing">
<!-- 0.0 means 0%, and 1.0 means 100%-->
<Parameter Name="CpuPercentageNodeCapacity" Value="0.5" />
<Parameter Name="MemoryPercentageNodeCapacity" Value="0.7" />
</Section>
A legtöbb ügyfél és forgatókönyv esetében a csomópontkapacitások automatikus észlelése a cpu-hoz és a memóriához az ajánlott konfiguráció (az automatikus észlelés alapértelmezés szerint be van kapcsolva). Ha azonban a csomópontkapacitások teljes manuális beállítására van szüksége, csomóponttípusonként konfigurálhatja őket a fürt csomópontjainak leírására szolgáló mechanizmus használatával. Íme egy példa arra, hogyan állíthatja be a csomóponttípust négy maggal és 2 GB memóriával:
<NodeType Name="MyNodeType">
<Capacities>
<Capacity Name="servicefabric:/_CpuCores" Value="4"/>
<Capacity Name="servicefabric:/_MemoryInMB" Value="2048"/>
</Capacities>
</NodeType>
Ha az elérhető erőforrások automatikus észlelése engedélyezve van, és a csomóponti kapacitások manuálisan vannak definiálva a fürtjegyzékben, a Service Fabric ellenőrzi, hogy a csomópont rendelkezik-e elegendő erőforrással a felhasználó által definiált kapacitás támogatásához:
Ha a jegyzékben definiált csomóponti kapacitások kisebbek vagy egyenlők a csomóponton elérhető erőforrásokkal, akkor a Service Fabric a jegyzékben megadott kapacitásokat használja.
Ha a jegyzékben definiált csomópontkapacitások nagyobbak a rendelkezésre álló erőforrásoknál, a Service Fabric az elérhető erőforrásokat csomóponti kapacitásként használja.
Az elérhető erőforrások automatikus észlelése kikapcsolható, ha nincs rá szükség. A kikapcsolásához módosítsa a következő beállítást:
<Section Name="PlacementAndLoadBalancing">
<Parameter Name="AutoDetectAvailableResources" Value="false" />
</Section>
Az optimális teljesítmény érdekében a fürtjegyzékben a következő beállítást is be kell kapcsolni:
<Section Name="PlacementAndLoadBalancing">
<Parameter Name="PreventTransientOvercommit" Value="true" />
<Parameter Name="AllowConstraintCheckFixesDuringApplicationUpgrade" Value="true" />
</Section>
Fontos
A Service Fabric 7.0-s verziójától kezdve frissítettük a csomóponterőforrás-kapacitások kiszámításának szabályát azokban az esetekben, amikor a felhasználó manuálisan adja meg a csomóponterőforrás-kapacitások értékeit. Tekintsük át a következő forgatókönyvet:
- A csomóponton összesen 10 processzormag található
- Az SF úgy van konfigurálva, hogy az összes erőforrás 80%-át használja a felhasználói szolgáltatásokhoz (alapértelmezett beállítás), ami 20%-os puffert hagy a csomóponton futó többi szolgáltatás számára (beleértve a Service Fabric rendszerszolgáltatásokat is)
- A felhasználó úgy dönt, hogy manuálisan felülbírálja a cpu-magok metrikájának csomóponterőforrás-kapacitását, és 5 magra állítja
Módosítottuk a Service Fabric felhasználói szolgáltatásainak rendelkezésre álló kapacitásának kiszámítására vonatkozó szabályt a következő módon:
- A Service Fabric 7.0 előtt a felhasználói szolgáltatások rendelkezésre álló kapacitása 5 magra lesz kiszámítva (a rendszer figyelmen kívül hagyja a 20%-os kapacitáspuffert)
- A Service Fabric 7.0-tól kezdve a felhasználói szolgáltatások rendelkezésre álló kapacitása 4 magra lesz kiszámítva (a 20%-os kapacitáspuffert nem hagyja figyelmen kívül)
Erőforrás-szabályozás megadása
Az erőforrás-szabályozási kérelmek és -korlátok az alkalmazásjegyzékben (ServiceManifestImport) vannak megadva. Íme, néhány példa:
1. példa: RequestsOnly specifikáció
<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="1"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="1024" />
</Policies>
</ServiceManifestImport>
Ebben a példában az CpuCores
attribútum egy 1 processzormagos kérés megadására szolgál a ServicePackageA-hoz. Mivel a cpu-korlát (CpuCoresLimit
attribútum) nincs megadva, a Service Fabric az 1 magos kérelemértéket is használja a szolgáltatáscsomag cpu-korlátjaként.
A ServicePackageA csak olyan csomóponton lesz elhelyezve, ahol a csomóponton elhelyezett összes szolgáltatáscsomag CPU-kéréseinek összegének kivonása után a fennmaradó processzorkapacitás nagyobb vagy egyenlő 1 magnál. A csomóponton a szolgáltatáscsomag egy magra lesz korlátozva. A szolgáltatáscsomag két kódcsomagot (CodeA1 és CodeA2) tartalmaz, és mindkettő megadja az CpuShares
attribútumot. A CpuShares 512:256 aránya az egyes kódcsomagok CPU-korlátainak kiszámítására szolgál. Így a CodeA1 egy mag kétharmadára lesz korlátozva, a CodeA2 pedig a mag egyharmadára lesz korlátozva. Ha a CpuShares nincs megadva az összes kódcsomaghoz, a Service Fabric egyenlően osztja el a cpu-korlátot közöttük.
Míg a kódcsomagokhoz megadott CpuShares a szolgáltatáscsomag teljes processzorkorlátjának relatív arányát jelenti, a kódcsomagok memóriaértékeit abszolút értékben adja meg a rendszer. Ebben a példában az MemoryInMB
attribútum 1024 MB memóriakérelmek megadására szolgál a CodeA1 és a CodeA2 esetében is. Mivel a memóriakorlát (MemoryInMBLimit
attribútum) nincs megadva, a Service Fabric a megadott kérésértékeket is használja a kódcsomagok korlátaiként. A szolgáltatáscsomag memóriakérelmét (és korlátját) a rendszer az alkotó kódcsomagok memóriakérelmének (és korlátjának) összegeként számítja ki. Így a ServicePackageA esetében a memóriakérelmet és a korlátot 2048 MB-ként számítjuk ki.
A ServicePackageA csak olyan csomóponton lesz elhelyezve, ahol a csomóponton elhelyezett összes szolgáltatáscsomag memóriakérelmének kivonása után a fennmaradó memóriakapacitás nagyobb vagy egyenlő 2048 MB-nál. A csomóponton mindkét kódcsomag 1024 MB memóriára lesz korlátozva. A kódcsomagok (tárolók vagy folyamatok) nem tudnak több memóriát lefoglalni ennél a korlátnál, és ennek megkísérlése memóriakivételeket eredményez.
2. példa: LimitsOnly specification
<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCoresLimit="1"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMBLimit="1024" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMBLimit="1024" />
</Policies>
</ServiceManifestImport>
Ez a példa olyan MemoryInMBLimit
és attribútumokat használCpuCoresLimit
, amelyek csak az SF 7.2-s és újabb verzióiban érhetők el. A CpuCoresLimit attribútum a ServicePackageA 1 magos processzorkorlátjának megadására szolgál. Mivel a CPU-kérelem (CpuCores
attribútum) nincs megadva, a rendszer 0-nak tekinti.
MemoryInMBLimit
az attribútum 1024 MB memóriakorlátok megadására szolgál a CodeA1 és a CodeA2 esetében, és mivel a kérések (MemoryInMB
attribútum) nincsenek megadva, 0-nak minősülnek. A ServicePackageA memóriakérelmének és korlátjának kiszámítása tehát 0 és 2048. Mivel a ServicePackageA processzor- és memóriakérelmeinek száma 0, nem jelent terhelést a CRM számára az elhelyezéshez, a és servicefabric:/_MemoryInMB
a servicefabric:/_CpuCores
metrikákhoz. Ezért erőforrás-szabályozási szempontból a ServicePackageA bármely csomóponton elhelyezhető a fennmaradó kapacitástól függetlenül. Az 1. példához hasonlóan a csomóponton a CodeA1 egy mag kétharmadára és 1024 MB memóriára lesz korlátozva, a CodeA2 pedig a mag egyharmadára és 1024 MB memóriára lesz korlátozva.
3. példa: RequestsAndLimits specifikáció
<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="1" CpuCoresLimit="2"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" MemoryInMBLimit="3072" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="2048" MemoryInMBLimit="4096" />
</Policies>
</ServiceManifestImport>
Az első két példa alapján ez a példa bemutatja a processzorra és a memóriára vonatkozó kéréseket és korlátokat is. A ServicePackageA 1 magos és 3072 (1024 + 2048) MB processzor- és memóriaigényekkel rendelkezik. Csak olyan csomóponton helyezhető el, amely legalább 1 maggal (és 3072 MB-tal) rendelkezik, miután kivonta a csomópontra helyezett összes szolgáltatáscsomag cpu- (és memória-) kérésének összegét a csomópont teljes PROCESSZOR- (és memória-) kapacitásából. A csomóponton a CodeA1 2 mag és 3072 MB memória kétharmadára lesz korlátozva, míg a CodeA2 a 2 mag egyharmadára és 4096 MB memóriára lesz korlátozva.
Alkalmazásparaméterek használata
Az erőforrás-szabályozási beállítások megadásakor alkalmazásparaméterek használatával több alkalmazáskonfigurációt is kezelhet. Az alábbi példa az alkalmazásparaméterek használatát mutatja be:
<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<Parameters>
<Parameter Name="CpuCores" DefaultValue="4" />
<Parameter Name="CpuSharesA" DefaultValue="512" />
<Parameter Name="CpuSharesB" DefaultValue="512" />
<Parameter Name="MemoryA" DefaultValue="2048" />
<Parameter Name="MemoryB" DefaultValue="2048" />
</Parameters>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="[CpuCores]"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="[CpuSharesA]" MemoryInMB="[MemoryA]" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="[CpuSharesB]" MemoryInMB="[MemoryB]" />
</Policies>
</ServiceManifestImport>
Ebben a példában az alapértelmezett paraméterértékek az éles környezethez vannak beállítva, ahol minden szolgáltatáscsomag 4 magot és 2 GB memóriát kap. Az alapértelmezett értékek módosíthatók alkalmazásparaméter-fájlokkal. Ebben a példában egy paraméterfájl használható az alkalmazás helyi teszteléséhez, ahol kevesebb erőforrást kapna, mint az éles környezetben:
<!-- ApplicationParameters\Local.xml -->
<Application Name="fabric:/TestApplication1" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="CpuCores" DefaultValue="2" />
<Parameter Name="CpuSharesA" DefaultValue="512" />
<Parameter Name="CpuSharesB" DefaultValue="512" />
<Parameter Name="MemoryA" DefaultValue="1024" />
<Parameter Name="MemoryB" DefaultValue="1024" />
</Parameters>
</Application>
Fontos
Az erőforrás-szabályozás alkalmazásparaméterekkel való megadása a Service Fabric 6.1-es verziójától kezdve érhető el.
Ha az erőforrás-szabályozás megadásához alkalmazásparamétereket használ, a Service Fabric nem állítható vissza a 6.1-es verzió előtti verzióra.
A felhasználói szolgáltatások erőforráskorlátainak kényszerítése
Miközben az erőforrás-szabályozást a Service Fabric-szolgáltatásokra alkalmazza, garantálja, hogy ezek az erőforrás-vezérlésű szolgáltatások nem léphetik túl az erőforráskvótát, sok felhasználónak továbbra is felügyelt módban kell futtatnia néhány Service Fabric-szolgáltatását. Az átvezetett Service Fabric-szolgáltatások használatakor olyan helyzetekbe ütközhet, amikor a "szökött" ungoverned szolgáltatások a Service Fabric-csomópontok összes rendelkezésre álló erőforrását felhasználják, ami súlyos problémákhoz vezethet, például:
- A csomópontokon futó egyéb szolgáltatások erőforrás-éhezése (beleértve a Service Fabric rendszerszolgáltatásait is)
- Nem kifogástalan állapotú csomópontok
- Nem válaszoló Service Fabric-fürtkezelési API-k
Ezen helyzetek megelőzése érdekében a Service Fabric lehetővé teszi , hogy a csomóponton futó (szabályozott és felügyelt) összes Service Fabric-felhasználói szolgáltatásra érvényesítse az erőforráskorlátokat , így garantálhatja, hogy a felhasználói szolgáltatások soha nem fognak többet használni a megadott mennyiségű erőforrásnál. Ezt úgy érheti el, hogy a ClusterManifest PlacementAndLoadBalancing szakaszában található EnforceUserServiceMetricCapacities konfiguráció értékét true (igaz) értékre állítja. Ez a beállítás alapértelmezés szerint ki van kapcsolva.
<SectionName="PlacementAndLoadBalancing">
<ParameterName="EnforceUserServiceMetricCapacities" Value="false"/>
</Section>
További megjegyzések:
- Az erőforráskorlát kikényszerítése csak a és
servicefabric:/_MemoryInMB
azservicefabric:/_CpuCores
erőforrásmetrikára vonatkozik - Az erőforráskorlát kényszerítése csak akkor működik, ha az erőforrás-metrikák csomópontkapacitásai elérhetők a Service Fabric számára az automatikus észlelési mechanizmuson keresztül, vagy a felhasználók által manuálisan megadott csomóponti kapacitásokon keresztül (az erőforrás-szabályozás engedélyezésére szolgáló fürtbeállítás című szakaszban leírtak szerint). Ha a csomóponti kapacitások nincsenek konfigurálva, az erőforráskorlát kényszerítési képessége nem használható, mivel a Service Fabric nem tudja, mennyi erőforrást kell lefoglalni a felhasználói szolgáltatásokhoz. A Service Fabric állapotjelzést ad ki, ha a "EnforceUserServiceMetricCapacities" igaz, de a csomópontkapacitások nincsenek konfigurálva.
Tárolók egyéb erőforrásai
A processzor és a memória mellett más erőforráskorlátokat is megadhat a tárolókhoz. Ezek a korlátozások a kódcsomag szintjén vannak megadva, és a tároló indításakor lesznek alkalmazva. A processzorral és a memóriával ellentétben a fürt Resource Manager nem ismeri ezeket az erőforrásokat, és nem végez kapacitás-ellenőrzést vagy terheléselosztást.
- MemorySwapInMB: A felcserélhető memória teljes mennyisége MB-ban. Pozitív egész számnak kell lennie.
- MemoryReservationInMB: A memóriaszabályozás helyreállítható korlátja (MB-ban), amely csak akkor érvényes, ha a rendszer memória versengést észlel a csomóponton. Pozitív egész számnak kell lennie.
- CpuPercent: Az elérhető CPU-k használható százaléka (csak Windows esetén). Pozitív egész számnak kell lennie. A CpuShares, a CpuCores vagy a CpuCoresLimit nem használható.
- CpuShares: Relatív cpu-súly. Pozitív egész számnak kell lennie. A CpuPercent, a CpuCores vagy a CpuCoresLimit nem használható.
- MaximumIOps: Maximális I/O-sebesség (olvasás és írás) a használható IOps tekintetében. Pozitív egész számnak kell lennie.
- MaximumIOBandwidth: A maximális I/O (másodpercenkénti bájt) használható (olvasási és írási). Pozitív egész számnak kell lennie.
- BlockIOWeight: Az I/O-súly blokkolása más kódcsomagokhoz képest. 10 és 1000 közötti pozitív egész számnak kell lennie.
- DiskQuotaInMB: Tárolók lemezkvótája. Pozitív egész számnak kell lennie.
- KernelMemoryInMB: A kernel memóriakorlátja bájtban. Pozitív egész számnak kell lennie. Vegye figyelembe, hogy ez Linux-specifikus, és a Windowson futó Docker hibát jelez, ha ez be van állítva.
- ShmSizeInMB: A /dev/shm mérete bájtban. Ha nincs megadva, a rendszer 64 MB-ot használ. Pozitív egész számnak kell lennie. Vegye figyelembe, hogy ez Linux-specifikus, de a Docker csak akkor hagyja figyelmen kívül (és nem hagyja ki a hibát), ha meg van adva.
Ezek az erőforrások processzorral és memóriával kombinálhatók. Íme egy példa arra, hogyan adhat meg további erőforrásokat a tárolókhoz:
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="FrontendServicePackage" ServiceManifestVersion="1.0"/>
<Policies>
<ResourceGovernancePolicy CodePackageRef="FrontendService.Code" CpuPercent="5"
MemorySwapInMB="4084" MemoryReservationInMB="1024" MaximumIOPS="20" />
</Policies>
</ServiceManifestImport>
Következő lépések
- A fürt Resource Manager további információért olvassa el a Service Fabric-fürt erőforrás-kezelőjének bemutatása című témakört.
- Ha többet szeretne megtudni az alkalmazásmodellről, a szolgáltatáscsomagokról és a kódcsomagokról, és arról, hogy a replikák hogyan képezhetik le őket, olvassa el az Alkalmazás modellezése a Service Fabricben című cikket.
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: