Zásady správného řízení prostředků

Pokud používáte více služeb na stejném uzlu nebo clusteru, je možné, že jedna služba může využívat více prostředků a v procesu hladovět jiné služby. Tento problém se označuje jako problém "hlučný soused". Azure Service Fabric umožňuje vývojáři řídit toto chování zadáním požadavků a omezení pro každou službu, aby omezil využití prostředků.

Než budete pokračovat v tomto článku, doporučujeme seznámit se s aplikačním modelem Service Fabric a modelem hostování Service Fabric.

Metriky zásad správného řízení prostředků

Zásady správného řízení prostředků se podporují v Service Fabric v souladu s balíčkem služeb. Prostředky přiřazené k balíčku služby je možné dále rozdělit mezi balíčky kódu. Service Fabric podporuje zásady správného řízení procesoru a paměti na balíček služby se dvěma integrovanými metrikami:

• CPU (název servicefabric:/_CpuCoresmetriky): Logické jádro, které je k dispozici na hostitelském počítači. Všechna jádra ve všech uzlech jsou vážená stejně.

• Paměť (název servicefabric:/_MemoryInMBmetriky): Paměť se vyjadřuje v megabajtech a mapuje se na fyzickou paměť dostupnou na počítači.

U těchto dvou metrik sleduje Správce prostředků clusteru (CRM) celkovou kapacitu clusteru, zatížení každého uzlu v clusteru a zbývající prostředky v clusteru. Tyto dvě metriky jsou ekvivalentní jakémukoli jinému uživateli nebo vlastní metrice.

Poznámka:

Vlastní názvy metrik by neměly být jedním z těchto dvou názvů metrik, protože by to vedlo k nedefinovaným chování.

Všechny stávající funkce je možné s nimi používat:

• Cluster je možné vyvážit podle těchto dvou metrik (výchozí chování).
• Cluster je možné defragmentovat podle těchto dvou metrik.
• Při popisu clusteru je možné pro tyto dvě metriky nastavit kapacitu s vyrovnávací pamětí.

Poznámka:

Dynamické generování sestav zatížení se pro tyto metriky nepodporuje. Načítání těchto metrik se definuje při vytváření.

Mechanismus zásad správného řízení prostředků

Od verze 7.2 podporuje modul runtime Service Fabric specifikaci požadavků a omezení pro prostředky procesoru a paměti.

Poznámka:

Verze modulu runtime Service Fabric starší než 7.2 podporují pouze model, ve kterém jedna hodnota slouží jako požadavek i limit pro konkrétní prostředek (procesor nebo paměť). Toto je popsáno jako specifikace RequestsOnly v tomto dokumentu.

• Požadavky: Hodnoty požadavků na procesor a paměť představují zatížení používaná správcem prostředků clusteru (CRM) pro metriky servicefabric:/_CpuCores a servicefabric:/_MemoryInMB metriky. Jinými slovy, CRM bere v úvahu spotřebu prostředků služby, aby byla rovna hodnotám žádosti a používá tyto hodnoty při rozhodování o umístění.

• Omezení: Hodnoty limitu procesoru a paměti představují skutečné limity prostředků použité při aktivaci procesu nebo kontejneru na uzlu.

Service Fabric umožňuje požadavkyOnly, LimitsOnly a specifikace RequestsAndLimits pro procesor a paměť.

• Při použití specifikace RequestsOnly používá Service Fabric také hodnoty požadavků jako omezení.
• Při použití specifikace LimitsOnly služba Service Fabric považuje hodnoty požadavku za 0.
• Při použití specifikace RequestsAndLimits musí být mezní hodnoty větší nebo rovny hodnotám požadavku.

Abychom lépe porozuměli mechanismu zásad správného řízení prostředků, podívejme se na ukázkový scénář umístění se specifikací RequestsOnly pro prostředek procesoru (mechanismus zásad správného řízení paměti je ekvivalentní). Představte si uzel se dvěma jádry procesoru a dvěma balíčky služeb, které se na něj umístí. První balíček služby, který se má umístit, se skládá pouze z jednoho balíčku kódu kontejneru a určuje pouze požadavek jednoho jádra procesoru. Druhý balíček služby, který se má umístit, se skládá pouze z jednoho balíčku kódu založeného na procesu a také určuje pouze požadavek jednoho jádra procesoru. Vzhledem k tomu, že oba balíčky služeb mají specifikaci RequestsOnly, jejich mezní hodnoty jsou nastaveny na hodnoty požadavků.

1. Nejprve se na uzlu umístí balíček služby založený na kontejneru, který požaduje jedno jádro procesoru. Modul runtime aktivuje kontejner a nastaví limit procesoru na jedno jádro. Kontejner nebude moct používat více než jedno jádro.

2. Dále se na uzlu umístí balíček služby založený na procesu, který požaduje jedno jádro procesoru. Modul runtime aktivuje proces služby a nastaví limit procesoru na jedno jádro.

V tomto okamžiku se součet požadavků rovná kapacitě uzlu. CRM nebude na tomto uzlu umisťovat žádné další kontejnery ani procesy služeb s požadavky procesoru. Na uzlu běží proces a kontejner s jedním jádrem a nebudou se vzájemně soupeřit o procesor.

Pojďme se teď znovu vrátit k našemu příkladu se specifikací RequestsAndLimits . Tentokrát balíček služby založené na kontejneru určuje požadavek na jedno jádro procesoru a omezení dvou jader procesoru. Balíček procesní služby určuje požadavek i limit jednoho jádra procesoru.

1. Nejprve se balíček služby založené na kontejneru umístí do uzlu. Modul runtime aktivuje kontejner a nastaví limit procesoru na dvě jádra. Kontejner nebude moct používat více než dvě jádra.
2. V dalším kroku se balíček služby založené na procesu umístí do uzlu. Modul runtime aktivuje proces služby a nastaví limit procesoru na jedno jádro.

V tomto okamžiku se součet požadavků procesoru balíčků služeb umístěných na uzlu rovná kapacitě procesoru uzlu. CRM nebude na tomto uzlu umisťovat žádné další kontejnery ani procesy služeb s požadavky procesoru. Na uzlu ale součet limitů (dvě jádra pro kontejner + jedno jádro pro proces) překročí kapacitu dvou jader. Pokud kontejner a proces najednou praskne, existuje možnost kolizí pro prostředek procesoru. Takové kolize bude spravovat základní operační systém pro platformu. V tomto příkladu by kontejner mohl navýšit až dvě jádra procesoru, což vede k tomu, že požadavek jednoho jádra procesoru není zaručený.

Poznámka:

Jak je znázorněno v předchozím příkladu, hodnoty požadavků pro procesor a paměť vedou k rezervaci prostředků na uzlu. Tyto hodnoty představují spotřebu prostředků, kterou Správce prostředků clusteru při rozhodování o umístění bere v úvahu. Mezní hodnoty představují skutečné limity prostředků použité při aktivaci procesu nebo kontejneru na uzlu.

Existuje několik situací, kdy může dojít k kolizí procesoru. V těchto situacích může proces a kontejner z našeho příkladu zaznamenat problém hlučného souseda:

• Kombinování řízení a neřídících služeb a kontejnerů: Pokud uživatel vytvoří službu bez zadaných zásad správného řízení prostředků, modul runtime ho uvidí jako využívání žádných prostředků a může ho umístit do uzlu v našem příkladu. V tomto případě tento nový proces efektivně spotřebovává některé procesory na úkor služeb, které už běží na uzlu. Existují dvě řešení tohoto problému. Buď nekombinujte řízené a neřídící služby ve stejném clusteru, nebo použijte omezení umístění, aby tyto dva typy služeb nekončily na stejné sadě uzlů.

• Když se na uzlu spustí jiný proces mimo Service Fabric (například služba operačního systému):V této situaci se proces mimo Service Fabric také hádá o využití procesoru se stávajícími službami. Řešením tohoto problému je správně nastavit kapacity uzlů tak, aby zohlednily režijní náklady na operační systém, jak je znázorněno v další části.

• Pokud se požadavky nerovnají limitům: Jak je popsáno v předchozím příkladu RequestsAndLimits, požadavky nevedou k rezervaci prostředků na uzlu. Když je služba s limity většími než požadavky umístěná na uzlu, může spotřebovávat prostředky (pokud jsou k dispozici) až do jeho limitů. V takových případech nemusí být ostatní služby v uzlu schopny spotřebovávat prostředky až do hodnot požadavků.

Nastavení clusteru pro povolení zásad správného řízení prostředků

Když se uzel spustí a připojí ke clusteru, Service Fabric zjistí dostupné množství paměti a dostupný počet jader a pak nastaví kapacity uzlu pro tyto dva prostředky.

Pro ponechání prostoru vyrovnávací paměti pro operační systém a pro další procesy, které můžou běžet na uzlu, Service Fabric používá pouze 80 % dostupných prostředků na uzlu. Toto procento je konfigurovatelné a dá se změnit v manifestu clusteru.

Tady je příklad, jak instruovat Service Fabric, aby používal 50 % dostupného procesoru a 70 % dostupné paměti:

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

U většiny zákazníků a scénářů je doporučená konfigurace automatické detekce kapacit uzlů pro procesor a paměť (ve výchozím nastavení je automatická detekce zapnutá). Pokud ale potřebujete úplné ruční nastavení kapacit uzlů, můžete je nakonfigurovat podle typu uzlu pomocí mechanismu pro popis uzlů v clusteru. Tady je příklad nastavení typu uzlu se čtyřmi jádry a 2 GB paměti:

    <NodeType Name="MyNodeType">
      <Capacities>
        <Capacity Name="servicefabric:/_CpuCores" Value="4"/>
        <Capacity Name="servicefabric:/_MemoryInMB" Value="2048"/>
      </Capacities>
    </NodeType>

Pokud je povolené automatické zjišťování dostupných prostředků a kapacity uzlů se v manifestu clusteru definují ručně, Service Fabric zkontroluje, jestli má uzel dostatek prostředků pro podporu kapacity, kterou uživatel definoval:

• Pokud jsou kapacity uzlů definované v manifestu menší nebo rovny dostupným prostředkům na uzlu, service Fabric použije kapacity, které jsou uvedené v manifestu.

• Pokud jsou kapacity uzlů definované v manifestu větší než dostupné prostředky, Service Fabric použije dostupné prostředky jako kapacity uzlů.

Automatické zjišťování dostupných prostředků je možné vypnout, pokud není potřeba. Pokud ho chcete vypnout, změňte následující nastavení:

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="AutoDetectAvailableResources" Value="false" />
</Section>

Pro zajištění optimálního výkonu by se v manifestu clusteru mělo zapnout také následující nastavení:

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="PreventTransientOvercommit" Value="true" />
    <Parameter Name="AllowConstraintCheckFixesDuringApplicationUpgrade" Value="true" />
</Section>

Důležité

Počínaje Service Fabric verze 7.0 jsme aktualizovali pravidlo pro výpočet kapacit prostředků uzlu v případech, kdy uživatel ručně poskytuje hodnoty pro kapacity prostředků uzlu. Zvažme následující scénář:

• Na uzlu je celkem 10 jader procesoru.
• SF je nakonfigurované tak, aby používalo 80 % celkových prostředků pro uživatelské služby (výchozí nastavení), což ponechá vyrovnávací paměť 20 % pro ostatní služby spuštěné na uzlu (včetně systémových služeb Service Fabric).
• Uživatel se rozhodne ručně přepsat kapacitu prostředků uzlu pro metriku jader procesoru a nastaví ji na 5 jader.

Změnili jsme pravidlo, jak se vypočítá dostupná kapacita uživatelských služeb Service Fabric následujícím způsobem:

• Před verzí Service Fabric 7.0 by se dostupná kapacita uživatelských služeb vypočítala na 5 jader (vyrovnávací paměť kapacity 20 % se ignoruje).
• Počínaje Service Fabric 7.0 by se dostupná kapacita uživatelských služeb vypočítala na 4 jádra (vyrovnávací paměť kapacity 20 % není ignorována).

Určení zásad správného řízení prostředků

Požadavky a omezení zásad správného řízení prostředků se zadají v manifestu aplikace (oddíl ServiceManifestImport). Podívejme se na několik příkladů:

Příklad 1: Specifikace RequestsOnly

<?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>

V tomto příkladu CpuCores se atribut používá k zadání požadavku na 1 jádro procesoru pro ServicePackageA. Vzhledem k tomu, že limit procesoru (CpuCoresLimit atribut) není zadaný, Service Fabric také používá zadanou hodnotu požadavku 1 jádro jako limit procesoru pro balíček služby.

ServicePackageA se umístí pouze na uzel, kde zbývající kapacita procesoru po odečtení součtu žádostí o procesor všech balíčků služeb umístěných na daném uzlu je větší nebo rovna 1 jádru. Na uzlu bude balíček služby omezen na jedno jádro. Balíček služby obsahuje dva balíčky kódu (CodeA1 a CodeA2) a oba určují CpuShares atribut. Podíl cpuShares 512:256 se používá k výpočtu limitů procesoru pro jednotlivé balíčky kódu. CodeA1 tedy bude omezen na dvě třetiny jádra a CodeA2 bude omezena na jednu třetinu jádra. Pokud nejsou pro všechny balíčky kódu zadány funkce CpuShares, Service Fabric rozdělí limit procesoru rovnoměrně mezi ně.

Zatímco CpuShares zadané pro balíčky kódu představují relativní podíl celkového limitu procesoru balíčku služby, hodnoty paměti pro balíčky kódu jsou zadány v absolutních termínech. V tomto příkladu MemoryInMB se atribut používá k určení požadavků na paměť 1024 MB pro CodeA1 i CodeA2. Vzhledem k tomu, že limit paměti (MemoryInMBLimit atribut) není zadán, Service Fabric také používá zadané hodnoty požadavku jako omezení balíčků kódu. Požadavek na paměť (a limit) balíčku služby se vypočítá jako součet hodnot požadavků na paměť (a limit) základních balíčků kódu. Proto pro ServicePackageA se požadavek na paměť a limit vypočítá jako 2048 MB.

Balíček ServicePackageA bude umístěn pouze na uzlu, kde zbývající kapacita paměti po odečtení součtu požadavků na paměť všech balíčků služeb umístěných na daném uzlu je větší nebo rovna 2048 MB. Na uzlu budou oba balíčky kódu omezeny na 1024 MB paměti. Balíčky kódu (kontejnery nebo procesy) nebudou moct přidělit více paměti, než je tento limit, a při pokusu o to dojde k výjimkám mimo paměť.

Příklad 2: Specifikace LimitsOnly

<?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>

Tento příklad používá CpuCoresLimit a MemoryInMBLimit atributy, které jsou k dispozici pouze v SF verze 7.2 a novější. Atribut CpuCoresLimit slouží k určení limitu procesoru 1 jádra pro ServicePackageA. Vzhledem k tomu, že není zadán požadavek procesoru (CpuCores atribut), považuje se za 0. MemoryInMBLimit atribut se používá k určení limitů paměti 1024 MB pro CodeA1 a CodeA2 a vzhledem k tomu, že požadavky (MemoryInMB atribut) nejsou zadány, považují se za 0. Požadavek na paměť a limit pro ServicePackageA se proto vypočítá jako 0 a 2048. Vzhledem k tomu, že požadavky na procesor i paměť pro ServicePackageA jsou 0, představuje pro CRM žádné zatížení, které by bylo potřeba zvážit při umísťování a servicefabric:/_CpuCores servicefabric:/_MemoryInMB metrikách. Z hlediska zásad správného řízení prostředků je proto možné Balíček ServicePackageA umístit na libovolný uzel bez ohledu na zbývající kapacitu. Podobně jako v příkladu 1 bude codeA1 omezena na dvě třetiny jádra a 1024 MB paměti a CodeA2 bude omezena na jednu třetinu jádra a 1024 MB paměti.

Příklad 3: Specifikace RequestsAndLimits

<?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>

Tento příklad vychází z prvních dvou příkladů a ukazuje určení požadavků i omezení procesoru a paměti. ServicePackageA má požadavky na procesor a paměť 1 jádra a 3072 (1024 + 2048) MB v uvedeném pořadí. Dá se umístit pouze na uzel, který má alespoň 1 jádro (a 3072 MB) kapacity po odečtení součtu všech požadavků na procesor (a paměť) všech balíčků služeb umístěných na uzlu z celkové kapacity procesoru (a paměti) uzlu. Na uzlu bude CodeA1 omezena na dvě třetiny 2 jádra a 3072 MB paměti, zatímco CodeA2 bude omezena na jednu třetinu 2 jader a 4096 MB paměti.

Použití parametrů aplikace

Při zadávání nastavení zásad správného řízení prostředků je možné použít parametry aplikace ke správě více konfigurací aplikací. Následující příklad ukazuje použití parametrů aplikace:

<?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>

V tomto příkladu jsou výchozí hodnoty parametrů nastavené pro produkční prostředí, kde každý balíček služby získá 4 jádra a 2 GB paměti. U souborů parametrů aplikace je možné změnit výchozí hodnoty. V tomto příkladu se dá použít jeden soubor parametrů pro místní testování aplikace, kde by získal méně prostředků než v produkčním prostředí:

<!-- 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>

Důležité

Určení zásad správného řízení prostředků pomocí parametrů aplikace je k dispozici od Service Fabric verze 6.1.

Pokud se parametry aplikace používají k určení zásad správného řízení prostředků, Service Fabric se nedá downgradovat na verzi starší než verze 6.1.

Vynucení limitů prostředků pro uživatelské služby

Při aplikování zásad správného řízení prostředků na služby Service Fabric zaručuje, že tyto služby řízené prostředky nesmí překročit kvótu prostředků, mnoho uživatelů stále potřebuje spustit některé služby Service Fabric v nepřístupném režimu. Při používání služeb Service Fabric bez převzetí služeb je možné narazit na situace, kdy "neběžné" nepřístupné služby spotřebovávají všechny dostupné prostředky na uzlech Service Fabric, což může vést k vážným problémům, jako jsou:

• Hladovění prostředků jiných služeb spuštěných na uzlech (včetně systémových služeb Service Fabric)
• Uzly končí ve špatném stavu
• Nereagující rozhraní API pro správu clusteru Service Fabric

Aby k těmto situacím nedocházelo, Service Fabric vám umožňuje vynutit omezení prostředků pro všechny uživatelské služby Service Fabric spuštěné na uzlu (jak řízené, tak i nepřístupné), aby se zajistilo, že uživatelské služby nikdy nebudou používat více než zadané množství prostředků. Toho dosáhnete nastavením hodnoty pro konfiguraci EnforceUserServiceMetricCapacities v části PlacementAndLoadBalancing clusterManifest na hodnotu true. Toto nastavení je ve výchozím nastavení vypnuté.

<SectionName="PlacementAndLoadBalancing">
    <ParameterName="EnforceUserServiceMetricCapacities" Value="false"/>
</Section>

Další poznámky:

• Vynucení limitu prostředků se vztahuje pouze na metriky servicefabric:/_CpuCores prostředků a servicefabric:/_MemoryInMB prostředky.
• Vynucení limitu prostředků funguje jenom v případě, že jsou kapacity uzlů pro metriky prostředků dostupné pro Service Fabric, a to buď prostřednictvím mechanismu automatického zjišťování, nebo ručním zadáním kapacit uzlů (jak je vysvětleno v nastavení clusteru pro povolení zásad správného řízení prostředků). Pokud kapacity uzlů nejsou nakonfigurované, nelze použít funkci vynucení limitu prostředků, protože Service Fabric nedokáže zjistit, kolik prostředků je potřeba rezervovat pro uživatelské služby. Service Fabric vydá upozornění na stav, pokud je true "EnforceUserServiceMetricCapacities", ale kapacity uzlů nejsou nakonfigurované.

Další prostředky pro kontejnery

Kromě procesoru a paměti je možné zadat další limity prostředků pro kontejnery. Tato omezení se zadají na úrovni balíčku kódu a použijí se při spuštění kontejneru. Na rozdíl od procesoru a paměti správce prostředků clusteru tyto prostředky nezná a nebude pro ně provádět žádné kontroly kapacity ani vyrovnávání zatížení.

• MemorySwapInMB: Celková velikost prohození paměti, kterou lze použít, v MB. Musí to být kladné celé číslo.
• MemoryReservationInMB: Soft limit (v MB) pro zásady správného řízení paměti, který se vynucuje pouze v případě, že je na uzlu zjištěn kolize paměti. Musí to být kladné celé číslo.
• CpuPercent: Využitelné procento dostupných procesorů (jenom Windows). Musí to být kladné celé číslo. Nelze použít se službou CpuShares, CpuCores nebo CpuCoresLimit.
• CpuShares: Relativní váha procesoru. Musí to být kladné celé číslo. Nelze použít s procesorem CpuPercent, CpuCores nebo CpuCoresLimit.
• MaximumIOps: Maximální rychlost vstupně-výstupních operací (čtení a zápis) z hlediska IOps, které lze použít. Musí to být kladné celé číslo.
• MaximumIOBandwidth: Maximální vstupně-výstupní operace (bajty za sekundu), které lze použít (čtení a zápis). Musí to být kladné celé číslo.
• BlockIOWeight: Bloková hmotnost vstupně-výstupních operací vzhledem k jiným balíčkům kódu. Musí být kladné celé číslo mezi 10 a 1000.
• DiskQuotaInMB: Kvóta disku pro kontejnery. Musí to být kladné celé číslo.
• KernelMemoryInMB: Omezení paměti jádra v bajtech. Musí to být kladné celé číslo. Všimněte si, že je to specifické pro Linux a Docker ve Windows se zobrazí chyba, pokud je tato hodnota nastavená.
• ShmSizeInMB: Velikost /dev/shm v bajtech. Pokud tento parametr vynecháte, systém používá 64 MB. Musí to být kladné celé číslo. Všimněte si, že je to specifické pro Linux, ale Docker bude ignorovat (a nebude se zobrazovat chyba) pouze v případě, že je zadán.

Tyto prostředky je možné kombinovat s procesorem a pamětí. Tady je příklad, jak zadat další prostředky pro kontejnery:

    <ServiceManifestImport>
        <ServiceManifestRef ServiceManifestName="FrontendServicePackage" ServiceManifestVersion="1.0"/>
        <Policies>
            <ResourceGovernancePolicy CodePackageRef="FrontendService.Code" CpuPercent="5"
            MemorySwapInMB="4084" MemoryReservationInMB="1024" MaximumIOPS="20" />
        </Policies>
    </ServiceManifestImport>

Další kroky

• Další informace o Resource Manageru clusteru najdete v tématu Úvod do Správce prostředků clusteru Service Fabric.
• Další informace o aplikačním modelu, balíčcích služeb a balíčcích kódu a o tom, jak se repliky mapují na model pro čtení aplikace v Service Fabric.