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

Pokud spouštíte více služeb na stejném uzlu nebo clusteru, může se stát, že jedna služba bude spotřebovávat více prostředků, omezují se v procesu další služby. Tento problém se označuje jako problém s "vysokou úrovní souseda". Azure Service Fabric umožňuje vývojářům řídit toto chování zadáním požadavků a omezení pro službu, aby se omezilo využití prostředků.

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

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

Zásady správného řízení prostředků jsou podporované v Service Fabric v souladu s balíčkem služby. Prostředky, které jsou přiřazeny k balíčku služby, mohou být dále rozděleny mezi balíčky kódu. Service Fabric podporuje zásady správného řízení procesoru a paměti na jeden balíček služby se dvěma integrovanými metrikami:

• CPU (název metriky servicefabric:/_CpuCores ): logický jádro, které je k dispozici na hostitelském počítači. Všechny jádra ve všech uzlech jsou vážená na stejnou.

• Paměť (název metriky servicefabric:/_MemoryInMB ): paměť je vyjádřena v megabajtech a je namapována na fyzickou paměť, která je k dispozici v počítači.

Pro tyto dvě metriky cluster správce prostředků (CRM) sleduje celkovou kapacitu clusteru, zatížení každého uzlu v clusteru a zbývající prostředky v clusteru. Tyto dvě metriky jsou ekvivalentní libovolné jiné uživateli nebo vlastní metriky. U těchto funkcí se dají použít všechny existující funkce:

• Cluster může být vyvážený podle těchto dvou metrik (výchozí chování).
• Cluster se dá defragmentovat podle těchto dvou metrik.
• Při popisu clusteruje možné nastavit kapacitu vyrovnávací paměti pro tyto dvě metriky.

Mechanismus řízení prostředků

Počínaje verzí 7,2 Service Fabric runtime podporuje určení požadavků a omezení pro prostředky procesoru a paměti.

• Požadavky: Hodnoty požadavků na procesor a paměť reprezentují zatížení používané clusterem Správce prostředků (CRM) pro servicefabric:/_CpuCores servicefabric:/_MemoryInMB metriky a. Jinými slovy CRM zvažuje spotřebu prostředků služby, která se má rovnat hodnotám požadavků, a při rozhodování o umístění používá tyto hodnoty.

• Omezení: Hodnoty limitu procesoru a paměti reprezentují skutečné limity prostředků, které se uplatní při aktivaci procesu nebo kontejneru na uzlu.

Service Fabric umožňuje RequestsOnly, LimitsOnly a RequestsAndLimits specifikace procesoru a paměti.

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

Pro lepší pochopení mechanismu řízení prostředků se podívejme na ukázkový scénář umístění se specifikací RequestsOnly pro prostředek procesoru (mechanismus řízení paměti je ekvivalentní). Vezměte v úvahu 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á jenom z jednoho balíčku kódu kontejneru a určuje jenom požadavek jednoho jádra procesoru. Druhý balíček služby, který se má umístit, se skládá jenom z jednoho balíčku kódu založeného na procesu a zároveň určuje jenom požadavek jednoho jádra procesoru. Vzhledem k tomu, že oba balíčky služby mají specifikaci RequestsOnly, jejich mezní hodnoty jsou nastaveny na jejich hodnoty požadavků.

1. Nejprve se v uzlu umístí balíček služby na bázi kontejneru požadující jeden procesor. Modul runtime aktivuje kontejner a nastaví limit procesoru na jeden Core. Kontejner nebude moci používat více než jedno jádro.

2. V dalším kroku se na uzel umístí balíček služby na základě procesu požadujícího jeden PROCESORový jader. Modul runtime aktivuje proces služby a nastaví jeho limit pro procesor na jednu jádro.

V tomto okamžiku je součet požadavků roven kapacitě uzlu. CRM nebude v tomto uzlu umísťovat žádné další kontejnery ani procesy služeb s požadavky na procesor. V uzlu je proces a kontejner spuštěný s jedním jádrem a nesoupeří se mezi sebou pro procesor.

Pojďme teď přejít na náš příklad se specifikací RequestsAndLimits . Tentokrát balíček služby založený na kontejneru určí požadavek na jádro procesoru a omezení dvou jader procesoru. Balíček služby na základě procesu určuje jak požadavek, tak i limit jednoho jádra procesoru.

1. Nejprve se balíček služby na bázi kontejneru umístí na uzel. Modul runtime aktivuje kontejner a nastaví limit procesoru na dvě jádra. Kontejner nebude moci používat více než dvě jádra.
2. V dalším kroku se balíček služby na základě procesu umístí na uzel. Modul runtime aktivuje proces služby a nastaví jeho limit pro procesor na jednu jádro.

V tomto okamžiku se součet požadavků na procesor balíčků služeb, které jsou umístěné na uzlu, rovná kapacitě procesoru uzlu. CRM nebude v tomto uzlu umísťovat žádné další kontejnery ani procesy služeb s požadavky na procesor. V uzlu ale součet omezení (dvě jádra pro kontejner a jeden jádro pro proces) překračuje kapacitu dvou jader. Pokud kontejner a proces se současně rozchází, existuje možnost kolizí prostředků procesoru. Takové spory budou spravovaných podkladovým operačním systémem pro danou platformu. V tomto příkladu může kontejner zvýšit kapacitu až na dvě jádra procesoru, což vede k tomu, že požadavek na procesor se nezaručuje.

Existuje několik situací, kdy může dojít ke sporům pro procesor. V takových situacích se může stát, že proces a kontejner z našeho příkladu nastanou problém s okolním sousedem:

• Kombinování řízených a neřízených služeb a kontejnerů: Pokud uživatel vytvoří službu bez zadaného zásad správného řízení prostředků, modul runtime ji uvidí, že nespotřebovává žádné prostředky, a může je umístit na uzel v našem příkladu. V tomto případě tento nový proces efektivně spotřebovává určitý procesor na úkor služeb, které jsou již spuštěny na uzlu. Existují dvě řešení tohoto problému. Buď nemíchejte řízení a neřídící služby ve stejném clusteru, nebo použijte omezení umístění , aby tyto dva typy služeb neukončily stejnou sadu uzlů.

• Když je na uzlu spuštěný jiný proces, mimo Service Fabric (například pro službu operačního systému): v této situaci se proces mimo Service Fabric taky zamýšlí pro procesor s existujícími službami. Řešením tohoto problému je správné nastavení kapacity uzlů pro účet pro režijní náklady na operační systém, jak je znázorněno v další části.

• Pokud požadavky nejsou rovnocenné omezení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 omezením větší než požadavky umístěná na uzlu, může spotřebovávat prostředky (pokud jsou dostupné) až do omezení IT. V takových případech nemusí být další služby na uzlu schopné spotřebovávat prostředky až do jejich 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.

Pro opuštění prostoru vyrovnávací paměti pro operační systém a pro jiné procesy, které mohou být spuštěny na uzlu, Service Fabric používá pouze 80% dostupných prostředků na uzlu. Toto procento je konfigurovatelné a v manifestu clusteru je možné ho změnit.

Tady je příklad, jak dát Service Fabric k použití 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é zjišťování kapacit uzlů pro procesor a paměť, což je doporučená konfigurace (automatické zjišťování je ve výchozím nastavení zapnuté). Pokud ale potřebujete úplnou ruční instalaci kapacit uzlů, můžete je nakonfigurovat podle typu uzlu pomocí mechanismu pro popis uzlů v clusteru. Tady je příklad, jak nastavit typ 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>

Když je povolená Automatická detekce 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ů, které jsou definovány v manifestu, menší nebo rovny dostupným prostředkům v uzlu, Service Fabric používá kapacity, které jsou uvedeny v manifestu.

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

Automatické zjišťování dostupných prostředků může být vypnuto, pokud není vyžadováno. 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 byste měli v manifestu clusteru zapnout taky následující nastavení:

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

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

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

Balíček ServicePackageA se umístí pouze do uzlu, kde je zbývající kapacita procesoru po odečtení součtu požadavků na procesor všech balíčků služeb umístěných na tomto uzlu 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 bude tedy omezen na dvě třetiny jádra a CodeA2 bude omezen na jednu třetinu jádra. Pokud se pro všechny balíčky kódu nezadá cpushares, Service Fabric limit procesoru rovnoměrně rozdělí 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 určeny absolutními termíny. V tomto příkladu se atribut používá k určení požadavků na paměť MemoryInMB 1 024 MB pro CodeA1 i CodeA2. Vzhledem k tomu, že limit paměti ( atribut) není zadaný, Service Fabric používá jako limity pro MemoryInMBLimit balíčky kódu také zadané hodnoty požadavků. Požadavek na paměť (a limit) pro balíček služby se počí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čítají jako 2048 MB.

ServicePackageA se umístí pouze do 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 tomto uzlu je větší nebo rovna 2048 MB. V 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 pokus o to bude mít za následek výjimky, které jsou 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 MemoryInMBLimit atributy a , 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í zadaný 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 (atribut) nejsou zadané, považují se za MemoryInMB 0. Požadavek na paměť a omezení pro ServicePackageA se proto počítají jako 0 a 2048 v uvedeném pořadí. Vzhledem k tomu, že požadavky na procesor i paměť pro ServicePackageA jsou 0, crm pro metriky a nemá žádné zatížení, které by bylo třeba servicefabric:/_CpuCores zvážit při servicefabric:/_MemoryInMB umísťování. Z hlediska zásad správného řízení prostředků je tedy možné ServicePackageA umístit na libovolný uzel bez ohledu na zbývající kapacitu. Podobně jako v příkladu 1 bude kód CodeA1 omezen na dvě třetiny jádra a 1024 MB paměti a CodeA2 bude omezen 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>

Na základě prvních dvou příkladů tento příklad ukazuje určení požadavků a omezení procesoru a paměti. ServicePackageA má požadavky na procesor a paměť 1 jádro a 3072 (1024 + 2048) MB. 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ů na procesor (a paměť) všech balíčků služeb umístěných na uzlu od celkové kapacity procesoru (a paměti) uzlu. V uzlu bude CodeA1 omezen na dvě třetiny 2 jader a 3072 MB paměti, zatímco CodeA2 bude omezen na jednu třetinu ze 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 se nastaví výchozí hodnoty parametrů pro produkční prostředí, kde každý balíček služby dostane 4 jádra a 2 GB paměti. Výchozí hodnoty je možné změnit pomocí souborů parametrů aplikace. V tomto příkladu je možné jeden soubor parametrů použít k místnímu testování aplikace, kde bude mít 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>

Vynucování limitů prostředků pro uživatelské služby

Přestože použití zásad správného řízení prostředků na služby Service Fabric zaručuje, že tyto služby spravované prostředky nemohou překročit kvótu svých prostředků, mnoho uživatelů stále musí spouštět některé své Service Fabric služby v nespravovaném režimu. Při použití nespravovaných Service Fabric služeb je možné na dochází k situacím, kdy "běžící" nespravované 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:

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

Aby k těmto situacím nedosahoval, umožňuje Service Fabric vynucovat limity prostředků pro všechny uživatelské služby spuštěné v uzlu (řízených Service Fabric přecházených), abyste zaručili, že uživatelské služby nikdy nebudou využívat více než zadané množství prostředků. Toho se dosáhne nastavením hodnoty pro konfiguraci EnforceUserServiceMetricCapacities v části PlacementAndLoadBalancing souboru ClusterManifest na true. Toto nastavení je ve výchozím nastavení vypnuté.

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

Další poznámky:

• Vynucování limitu prostředků se vztahuje jenom na servicefabric:/_CpuCores servicefabric:/_MemoryInMB metriky prostředků a .
• Vynucování 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 prostřednictvím uživatelů, kteří ručně určí kapacity uzlů (jak je vysvětleno v části Nastavení clusteru pro povolení zásad správného řízení prostředků). Pokud nejsou kapacity uzlů nakonfigurované, není možné použít funkci vynucení limitu prostředků, protože Service Fabric nemůže vědět, kolik prostředků je třeba rezervovat pro uživatelské služby. Service Fabric stav zobrazí upozornění, pokud má hodnota EnforceUserServiceMetricCapacities hodnotu true, ale kapacity uzlů nejsou nakonfigurované.

Další prostředky pro kontejnery

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

• MemorySwapInMB: Celková velikost využité paměti pro prohození 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ěno škádnutí paměti. Musí to být kladné celé číslo.
• CpuPercent: Použitelné procento dostupných procesorů (jenom Windows). Musí to být kladné celé číslo. Nelze použít s CpuShares, CpuCores ani CpuCoresLimit.
• CpuShares: Relativní váha procesoru. Musí to být kladné celé číslo. Nelze použít s 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í to být kladné celé číslo.
• MaximumIOBandwidth: Maximální počet V/V (bajtů za sekundu), které lze použít (čtení a zápis). Musí to být kladné celé číslo.
• BlockIOWeight: Zablokuje V/V váhu vzhledem k jiným balíčkům kódu. Musí to být kladné celé číslo v rozmezí od 10 do 1000.
• DiskQuotaInMB: Kvóta disku pro kontejnery. Musí to být kladné celé číslo.
• KernelMemoryInMB: Limity paměti jádra v bajtech. Musí to být kladné celé číslo. Všimněte si, že se jedná o konkrétní Linux a Pokud je tato možnost nastavená, Docker ve Windows se zobrazí chybou.
• ShmSizeInMB: Velikost /dev/shm v bajtech. Pokud je tento název vynechán, systém použije 64 MB. Musí to být kladné celé číslo. Všimněte si, že se jedná o specifické pro Linux, Ale Docker bude ignorovat (a ne chybu) 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 Správce prostředků clusteru najdete v úvodu ke správci prostředků Service Fabric clusteru.
• Další informace o aplikačním modelu, balíčcích služeb a balíčcích kódu a o tom, jak se na ně mapují repliky, najdete v tématu Modelování aplikace v Service Fabric.