Share via


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:

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 a servicefabric:/_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.

  1. 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.

  2. 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.

  1. 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.
  2. 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 az servicefabric:/_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