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

Pokud ve stejném uzlu nebo clusteru používáte více služeb, je možné, že jedna služba spotřebuje více prostředků a ostatní služby v procesu budou hladovět. 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 limitů pro jednotlivé služby, aby se omezilo využití prostředků.

Než budete pokračovat v tomto článku, doporučujeme, abyste se seznámili 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 v Service Fabric podporují v souladu s balíčkem služby. Prostředky, které jsou přiřazeny k balíčku služby, lze dále rozdělit mezi balíčky kódu. Service Fabric podporuje zásady správného řízení procesoru a paměti pro jednotlivé balíčky 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 mají stejnou váhu.

• 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 clusteru Resource Manager (CRM) sleduje celkovou kapacitu clusteru, zatížení jednotlivých uzlů v clusteru a zbývající prostředky v clusteru. Tyto dvě metriky jsou ekvivalentní libovolnému 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ím.

Můžete s nimi používat všechny existující funkce:

• Cluster je možné vyvážit na základě 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 ve vyrovnávací paměti.

Poznámka

Pro tyto metriky se nepodporuje dynamické generování sestav zatížení. Zatížení pro tyto metriky jsou definována v době vytvoření.

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

Počínaje verzí 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ěť). To je popsáno jako specifikace RequestsOnly v tomto dokumentu.

• Požadavky: Hodnoty požadavků procesoru a paměti představují zatížení používaná clusterovou Resource Manager (CRM) pro metriky servicefabric:/_CpuCores aservicefabric:/_MemoryInMB. Jinými slovy, CRM považuje spotřebu prostředků služby za rovnou hodnotám požadavků a používá tyto hodnoty při rozhodování o umístění.

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

Service Fabric umožňuje specifikace RequestsOnly, LimitsOnly a obou požadavků ALimits pro procesor a paměť.

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

Abychom lépe porozuměli mechanismu zásad správného řízení prostředků, podívejme se na příklad scénáře umístění se specifikací RequestsOnly pro prostředek procesoru (mechanismus zásad správného řízení paměti je ekvivalentní). Zvažte uzel se dvěma jádry procesoru a dvěma balíčky služeb, které na něj budou umístěny. 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, jsou jejich limitní hodnoty nastaveny na hodnoty požadavků.

1. Nejprve se na uzel 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 uzel 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 na tento uzel neumisťuje žá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 limit dvou jader procesoru. Balíček služeb založený na procesu určuje požadavek i limit jednoho jádra procesoru.

1. Nejprve se na uzel umístí balíček služby založený na kontejneru. Modul runtime aktivuje kontejner a nastaví limit procesoru na dvě jádra. Kontejner nebude moct používat více než dvě jádra.
2. Dále se na uzel umístí balíček služby založený na procesu. 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 na tento uzel neumisťuje žádné další kontejnery ani procesy služeb s požadavky procesoru. Na uzlu však součet limitů (dvě jádra pro kontejner a jedno jádro pro proces) překračuje kapacitu dvou jader. Pokud kontejner a proces propukají současně, existuje možnost kolize pro prostředek procesoru. Takové kolize bude spravovat základní operační systém platformy. V tomto příkladu by kontejner mohl navýšit kapacitu na dvě jádra procesoru, což vede k tomu, že požadavek procesu na jedno jádro procesoru není zaručen.

Poznámka

Jak je znázorněno v předchozím příkladu, hodnoty požadavků pro procesor a paměť nevedou k rezervaci prostředků na uzlu. Tyto hodnoty představují spotřebu prostředků, kterou cluster Resource Manager při rozhodování o umístění zvažuje. Hodnoty limitů představují skutečná omezení prostředků použitá při aktivaci procesu nebo kontejneru na uzlu.

V několika situacích může docházet ke kolizím procesoru. V těchto situacích může u procesu a kontejneru z našeho příkladu docházet k problému s hlučnou sousedou:

• Kombinování řídicích a neříděných služeb a kontejnerů: Pokud uživatel vytvoří službu bez zadaných zásad správného řízení prostředků, modul runtime ji uvidí jako bez prostředků a v našem příkladu ji může umístit na uzel. V tomto případě tento nový proces efektivně spotřebovává část procesoru na úkor služeb, které už jsou na uzlu spuštěné. Tento problém má dvě řešení. 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 neskončily na stejné sadě uzlů.

• Při spuštění jiného procesu na uzlu mimo Service Fabric (například služba operačního systému): V této situaci proces mimo Service Fabric také bojuje o procesor s existujícími službami. Řešením tohoto problému je správné nastavení kapacit uzlů tak, aby odpovídaly režii operačního systému, jak je znázorněno v další části.

• Pokud se požadavky nerovnají limitům: Jak bylo popsáno v příkladu RequestsAndLimits výše, požadavky nevedou k rezervaci prostředků v uzlu. Pokud je na uzlu umístěna služba s limity většími než požadavky, může využívat prostředky (pokud jsou k dispozici) až do limitů. V takových případech nemusí být jiné služby v uzlu schopné využí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 uzlů pro tyto dva prostředky.

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

Tady je příklad, jak dát Service Fabric pokyn, aby využí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>

Pro většinu zákazníků a scénářů se doporučuje automatická detekce kapacit uzlů pro procesor a paměť (automatická detekce je ve výchozím nastavení 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ů jsou ručně definovány v manifestu clusteru, Service Fabric zkontroluje, jestli má uzel dostatek prostředků pro podporu kapacity definované uživatelem:

• Pokud jsou kapacity uzlů definované v manifestu menší nebo se rovnají dostupným prostředkům v uzlu, pak Service Fabric použije kapacity, které jsou zadané 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ů uzlů v případech, kdy uživatel ručně zadá hodnoty pro kapacity prostředků uzlů. Podívejme se na následující scénář:

• Na uzlu je celkem 10 procesorových jader.
• SF je nakonfigurovaný tak, aby využíval 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 jádra procesoru a nastaví ji na 5 jader.

Změnili jsme pravidlo pro výpočet dostupné kapacity pro uživatelské služby Service Fabric následujícím způsobem:

• Před verzí Service Fabric 7.0 by se dostupná kapacita uživatelských služeb počítal na 5 jader (vyrovnávací paměť kapacity 20 % se ignoruje).
• Od verze Service Fabric 7.0 se dostupná kapacita pro uživatelské služby počítá na 4 jádra (vyrovnávací paměť kapacity 20 % se neignoruje).

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

Požadavky a limity zásad správného řízení prostředků se zadává v manifestu aplikace (část 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 určení požadavku s 1 jádrem procesoru pro ServicePackageA. Vzhledem k tomu, že limit procesoru (CpuCoresLimit atribut) není zadaný, Service Fabric jako limit procesoru pro balíček služby používá také zadanou hodnotu požadavku 1 jádro.

ServicePackageA se umístí jenom na uzel, kde je zbývající kapacita procesoru po odečtení součtu požadavků procesoru všech balíčků služeb umístěných na daném uzlu větší než 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. Proto bude CodeA1 omezený na dvě třetiny jádra a CodeA2 bude omezený na jednu třetinu jádra. Pokud cpuShares nejsou zadané pro všechny balíčky kódu, Service Fabric rozdělí limit procesoru rovnoměrně mezi ně.

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

ServicePackageA se umístí jenom na uzel, kde je 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 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 pokud se o to pokusíte, dojde k výjimkám kvůli nedostatku paměti.

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>

V tomto příkladu se používají CpuCoresLimit atributy a MemoryInMBLimit , které jsou k dispozici pouze ve verzích SF 7.2 a novějších. Atribut CpuCoresLimit slouží k určení limitu procesoru 1 jádra pro ServicePackageA. Vzhledem k tomu, že požadavek procesoru (CpuCores atribut) není zadaný, považuje se za 0. MemoryInMBLimit Atribut slouží k určení limitů paměti 1024 MB pro CodeA1 a CodeA2, a protože požadavky (MemoryInMB atribut) nejsou zadané, považují se za 0. Požadavek na paměť a limit pro ServicePackageA se proto počítají jako 0 a 2048. Vzhledem k tomu, že požadavky na procesor i paměť pro ServicePackageA jsou 0, představuje to pro CRM žádné zatížení, které by mohlo zvážit při umístění, pro metriky servicefabric:/_CpuCores a servicefabric:/_MemoryInMB . Z hlediska zásad správného řízení prostředků je proto možné ServicePackageA umístit na libovolný uzel bez ohledu na zbývající kapacitu. Podobně jako v příkladu 1 bude codeA1 na uzlu omezený na dvě třetiny jádra a 1 024 MB paměti a CodeA2 bude omezený na jednu třetinu jádra a 1 024 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>

V návaznosti na první dva příklady tento příklad ukazuje určení požadavků i omezení procesoru a paměti. ServicePackageA má požadavky na procesor a paměť s 1 jádrem a 3072 (1024 + 2048) MB v uvedeném pořadí. Může být umístěn pouze na uzel, který má alespoň 1 jádro (a 3072 MB) kapacity po odečtení součtu všech požadavků procesoru (a paměti) všech balíčků služeb, které jsou umístěny na uzlu, od celkové kapacity procesoru (a paměti) uzlu. Na uzlu bude CodeA1 omezený na dvě třetiny 2 jader a 3072 MB paměti, zatímco CodeA2 bude omezený 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 by každý balíček služby získal 4 jádra a 2 GB paměti. Pomocí souborů parametrů aplikace je možné změnit výchozí hodnoty. V tomto příkladu lze jeden soubor parametrů použít k místnímu testování aplikace, kde by získala 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 k určení zásad správného řízení prostředků použijí parametry aplikace, není možné Service Fabric downgradovat na verzi starší než 6.1.

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

Použití zásad správného řízení prostředků u služeb Service Fabric zaručuje, že tyto služby řízené prostředky nemůžou překročit kvótu prostředků, ale mnoho uživatelů stále musí některé služby Service Fabric spouštět v neschválovaném režimu. Při používání neschovaných služeb Service Fabric je možné narazit na situace, kdy neběžené 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:

• Nedostatek prostředků u 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 umožňuje vynucovat limity prostředků pro všechny uživatelské služby Service Fabric spuštěné na uzlu (řízené i neschválené), aby se zajistilo, že uživatelské služby nebudou nikdy využívat více prostředků, než je zadané množství prostředků. Toho dosáhnete nastavením hodnoty pro konfiguraci EnforceUserServiceMetricCapacities v části PlacementAndLoadBalancing clusterManifest na 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 .
• Vynucování limitu prostředků funguje pouze v případě, že service Fabric má k dispozici kapacity uzlů pro metriky prostředků, a to buď prostřednictvím mechanismu automatického zjišťování, nebo prostřednictvím ručního určení kapacit uzlů (jak je vysvětleno v části Nastavení clusteru pro povolení zásad správného řízení prostředků ). Pokud kapacity uzlů nejsou nakonfigurované, možnost vynucování limitu prostředků se nedá použít, protože Service Fabric nemůže vědět, kolik prostředků má být rezervováno pro uživatelské služby. Service Fabric vydá upozornění na stav, pokud hodnota EnforceUserServiceMetricCapacities má hodnotu true, ale kapacity uzlů nejsou nakonfigurované.

Další prostředky pro kontejnery

Kromě procesoru a paměti je možné pro kontejnery určit i další limity prostředků. Tato omezení se zadává na úrovni balíčku kódu a použijí se při spuštění kontejneru. Na rozdíl od procesoru a paměti cluster Resource Manager o těchto prostředcích neví a neprovádí za ně žádné kontroly kapacity ani vyrovnávání zatížení.

• MemorySwapInMB: Celková velikost odkládací paměti, kterou je možné použít, v MB. Musí být kladné celé číslo.
• MemoryReservationInMB: Měkký limit (v MB) pro zásady správného řízení paměti, který se vynucuje pouze v případě, že se na uzlu zjistí kolize paměti. Musí být kladné celé číslo.
• CpuPercent: Využitelné procento dostupných procesorů (jenom Windows). Musí být kladné celé číslo. Nelze použít s cpushares, CpuCores nebo CpuCoresLimit.
• CpuShares: Relativní váha procesoru. Musí být kladné celé číslo. Nelze použít s procesory CpuPercent, CpuCores nebo CpuCoresLimit.
• MaximumIOps: Maximální rychlost vstupně-výstupních operací (čtení a zápisu) z hlediska IOps, které je možné použít. Musí být kladné celé číslo.
• MaximumIOBandwidth: Maximální počet vstupně-výstupních operací (v bajtech za sekundu), které je možné použít (čtení a zápis). Musí být kladné celé číslo.
• BlockIOWeight: Váha vstupně-výstupních operací bloku vzhledem k jiným balíčkům kódu. Musí to být kladné celé číslo mezi 10 a 1 000.
• DiskQuotaInMB: Kvóta disků pro kontejnery. Musí být kladné celé číslo.
• KernelMemoryInMB: Omezení paměti jádra v bajtech. Musí být kladné celé číslo. Všimněte si, že se jedná o specifickou verzi Linuxu, a pokud je toto nastavení nastavené, Dojde k chybě Dockeru ve Windows.
• ShmSizeInMB: Velikost /dev/shm v bajtech. Pokud ho vynecháte, systém použije 64 MB. Musí být kladné celé číslo. Všimněte si, že se jedná o specifickou verzi Linuxu, ale Docker bude ignorovat (a nevyřešil chybu), pouze pokud je zadána.

Tyto prostředky je možné kombinovat s procesorem a pamětí. Tady je příklad určení dalších prostředků 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 Manager clusteru najdete v tématu Představujeme Správce prostředků clusteru Service Fabric.
• Další informace o modelu aplikace, balíčcích služeb a balíčcích kódu a o tom, jak se na ně repliky mapují, najdete v tématu Modelování aplikace v Service Fabric.