Resourcebeheer

Wanneer u meerdere services op hetzelfde knooppunt of cluster hebt uitgevoerd, is het mogelijk dat de ene service meer resources verbruikt, zodat andere services in het proces worden uit bedrijf genomen. Dit probleem wordt het 'ruisprobleem' genoemd. Met Azure Service Fabric de ontwikkelaar dit gedrag bepalen door aanvragen en limieten per service op te geven om het resourcegebruik te beperken.

Voordat u verdergaat met dit artikel, raden we u aan om vertrouwd te raken met het Service Fabric-toepassingsmodel en het Service Fabric hostingmodel.

Metrische gegevens voor resourcebeheer

Resourcebeheer wordt ondersteund in Service Fabric in overeenstemming met het servicepakket. De resources die aan het servicepakket zijn toegewezen, kunnen verder worden verdeeld over codepakketten. Service Fabric ondersteunt CPU- en geheugenbeheer per servicepakket, met twee ingebouwde metrische gegevens:

• CPU (naam van metrische servicefabric:/_CpuCores gegevens): een logische kern die beschikbaar is op de hostmachine. Alle kernen op alle knooppunten worden hetzelfde gewogen.

• Geheugen (naam van metrische gegevens): het geheugen wordt uitgedrukt in megabytes en wordt aan het fysieke geheugen dat servicefabric:/_MemoryInMB beschikbaar is op de computer, toe te kennen.

Voor deze twee metrische gegevens houdt Cluster Resource Manager (CRM) de totale clustercapaciteit, de belasting van elk knooppunt in het cluster en de resterende resources in het cluster bij. Deze twee metrische gegevens zijn gelijk aan andere gebruikers- of aangepaste metrische gegevens. Alle bestaande functies kunnen met deze functies worden gebruikt:

• Het cluster kan worden verdeeld op basis van deze twee metrische gegevens (standaardgedrag).
• Het cluster kan worden gedefragmenteerd op basis van deze twee metrische gegevens.
• Bij het beschrijven van een clusterkan buffercapaciteit worden ingesteld voor deze twee metrische gegevens.

Mechanisme voor resourcebeheer

Vanaf versie 7.2 ondersteunt Service Fabric specificatie van aanvragen en limieten voor CPU- en geheugenresources.

• Aanvragen: Aanvraagwaarden voor CPU en geheugen vertegenwoordigen de belastingen die door de Cluster Resource Manager (CRM) worden gebruikt voor de metrische gegevens en servicefabric:/_CpuCores servicefabric:/_MemoryInMB . Met andere woorden, CRM beschouwt het resourceverbruik van een service als gelijk aan de aanvraagwaarden en gebruikt deze waarden bij het nemen van plaatsingsbeslissingen.

• Limieten: Waarden voor de CPU- en geheugenlimiet vertegenwoordigen de werkelijke resourcelimieten die worden toegepast wanneer een proces of container wordt geactiveerd op een knooppunt.

Service Fabric staat de specificaties RequestsOnly, LimitsOnly en requestsAndLimits voor CPU en geheugen toe.

• Wanneer RequestsOnly-specificatie wordt gebruikt, gebruikt Service Fabric ook de aanvraagwaarden als limieten.
• Wanneer LimitsOnly-specificatie wordt gebruikt, worden de aanvraagwaarden door Service Fabric als 0 gezien.
• Wanneer de specificatie RequestsAndLimits wordt gebruikt, moeten de limietwaarden groter zijn dan of gelijk zijn aan de aanvraagwaarden.

Voor een beter begrip van het mechanisme voor resourcebeheer bekijken we een voorbeeld van een plaatsingsscenario met een RequestsOnly-specificatie voor de CPU-resource (mechanisme voor geheugenbeheer is gelijkwaardig). Overweeg een knooppunt met twee CPU-kernen en twee servicepakketten die erop worden geplaatst. Het eerste servicepakket dat moet worden geplaatst, bestaat uit slechts één containercodepakket en geeft slechts een aanvraag van één CPU-kern op. Het tweede servicepakket dat moet worden geplaatst, bestaat uit slechts één op processen gebaseerd codepakket en geeft ook slechts een aanvraag van één CPU-kern op. Omdat beide servicepakketten een RequestsOnly-specificatie hebben, worden de limietwaarden ingesteld op de aanvraagwaarden.

1. Eerst wordt het op containers gebaseerde servicepakket dat één CPU-kern aanvraagt, op het knooppunt geplaatst. De runtime activeert de container en stelt de CPU-limiet in op één kern. De container kan niet meer dan één kern gebruiken.

2. Vervolgens wordt het op processen gebaseerde servicepakket dat één CPU-kern aanvraagt, op het knooppunt geplaatst. De runtime activeert het serviceproces en stelt de CPU-limiet in op één kern.

Op dit moment is de som van de aanvragen gelijk aan de capaciteit van het knooppunt. CRM zal geen containers of serviceprocessen meer plaatsen met CPU-aanvragen op dit knooppunt. Op het knooppunt worden een proces en een container uitgevoerd met elk één kern en zullen ze niet met elkaar in strijd zijn voor CPU.

We gaan nu terug naar ons voorbeeld met de specificatie RequestsAndLimits. Deze keer geeft het servicepakket op basis van een container een aanvraag van één CPU-kern en een limiet van twee CPU-kernen op. Het servicepakket op basis van processen specificeert zowel een aanvraag als een limiet van één CPU-kern.

1. Eerst wordt het op containers gebaseerde servicepakket op het knooppunt geplaatst. De runtime activeert de container en stelt de CPU-limiet in op twee kernen. De container kan niet meer dan twee kernen gebruiken.
2. Vervolgens wordt het op processen gebaseerde servicepakket op het knooppunt geplaatst. De runtime activeert het serviceproces en stelt de CPU-limiet in op één kern.

Op dit moment is de som van de CPU-aanvragen van servicepakketten die op het knooppunt worden geplaatst gelijk aan de CPU-capaciteit van het knooppunt. CRM zal geen containers of serviceprocessen meer plaatsen met CPU-aanvragen op dit knooppunt. Op het knooppunt overschrijdt de som van limieten (twee kernen voor de container + één kern voor het proces) echter de capaciteit van twee kernen. Als de container en het proces tegelijkertijd bursten, is er kans op een probleem met de CPU-resource. Dergelijke problemen worden veroorzaakt door het onderliggende besturingssysteem voor het platform. In dit voorbeeld kan de container maximaal twee CPU-kernen bursten, waardoor de aanvraag van één CPU-kern van het proces niet kan worden gegarandeerd.

Er zijn enkele situaties waarin er mogelijk sprake is van een cpu-ing. In deze situaties kunnen het proces en de container uit ons voorbeeld het probleem met ruis ervaren:

• Beheerde en niet-beheerde services en containers combineren: als een gebruiker een service maakt zonder dat er resourcebeheer is opgegeven, ziet de runtime dat deze geen resources verbruikt en kan deze in ons voorbeeld op het knooppunt worden geplaatst. In dit geval verbruikt dit nieuwe proces een deel van de CPU ten koste van de services die al op het knooppunt worden uitgevoerd. Er zijn twee oplossingen voor dit probleem. Combineer geen beheerde en niet-beheerde services in hetzelfde cluster of gebruik plaatsingsbeperkingen zodat deze twee typen services niet op dezelfde set knooppunten eindigen.

• Wanneer een ander proces wordt gestart op het knooppunt, buiten Service Fabric (bijvoorbeeld een besturingssysteemservice) : In dit geval wordt het proces buiten Service Fabric ook gebruikt voor CPU met bestaande services. De oplossing voor dit probleem is om knooppuntcapaciteiten correct in te stellen om rekening te houden met de overhead van het besturingssysteem, zoals wordt weergegeven in de volgende sectie.

• Wanneer aanvragen niet gelijk zijn aan limieten: zoals eerder beschreven in het voorbeeld RequestsAndLimits, leiden aanvragen niet tot reservering van resources op een knooppunt. Wanneer een service met limieten groter is dan aanvragen op een knooppunt wordt geplaatst, kan deze resources gebruiken (indien beschikbaar) tot aan deze limieten. In dergelijke gevallen kunnen andere services op het knooppunt mogelijk geen resources gebruiken tot aan de aanvraagwaarden.

Clusterinstallatie voor het inschakelen van resourcebeheer

Wanneer een knooppunt wordt gestart en lid wordt van het cluster, detecteert Service Fabric de beschikbare hoeveelheid geheugen en het beschikbare aantal kernen en stelt vervolgens de knooppuntcapaciteit voor deze twee resources in.

Als u bufferruimte wilt laten voor het besturingssysteem en voor andere processen die op het knooppunt kunnen worden uitgevoerd, gebruikt Service Fabric slechts 80% van de beschikbare resources op het knooppunt. Dit percentage kan worden geconfigureerd en kan worden gewijzigd in het clustermanifest.

Hier is een voorbeeld van het instrueren Service Fabric 50% van de beschikbare CPU en 70% van het beschikbare geheugen te gebruiken:

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

Voor de meeste klanten en scenario's is automatische detectie van knooppuntcapaciteiten voor CPU en geheugen de aanbevolen configuratie (automatische detectie is standaard ingeschakeld). Als u echter een volledige handmatige installatie van knooppuntcapaciteiten nodig hebt, kunt u deze per knooppunttype configureren met behulp van het mechanisme voor het beschrijven van knooppunten in het cluster. Hier is een voorbeeld van het instellen van het knooppunttype met vier kernen en 2 GB geheugen:

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

Wanneer automatische detectie van beschikbare resources is ingeschakeld en knooppuntcapaciteiten handmatig worden gedefinieerd in het clustermanifest, controleert Service Fabric of het knooppunt voldoende resources heeft ter ondersteuning van de capaciteit die de gebruiker heeft gedefinieerd:

• Als knooppuntcapaciteiten die zijn gedefinieerd in het manifest kleiner zijn dan of gelijk zijn aan de beschikbare resources op het knooppunt, gebruikt Service Fabric de capaciteiten die zijn opgegeven in het manifest.

• Als knooppuntcapaciteiten die in het manifest zijn gedefinieerd groter zijn dan de beschikbare resources, Service Fabric de beschikbare resources als knooppuntcapaciteit gebruikt.

Automatische detectie van beschikbare resources kan worden uitgeschakeld als dit niet vereist is. Als u deze wilt uitschakelen, wijzigt u de volgende instelling:

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

Voor optimale prestaties moet de volgende instelling ook worden ingeschakeld in het clustermanifest:

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

Resourcebeheer opgeven

Aanvragen en limieten voor resourcebeheer worden opgegeven in het toepassingsmanifest (sectie ServiceManifestImport). Hier volgen enkele voorbeelden:

Voorbeeld 1: RequestsOnly-specificatie

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

In dit voorbeeld wordt het kenmerk gebruikt om een aanvraag van CpuCores 1 CPU-kern voor ServicePackageA op te geven. Omdat de CPU-limiet (kenmerk) niet is opgegeven, gebruikt Service Fabric ook de opgegeven aanvraagwaarde van 1 kern als de CpuCoresLimit CPU-limiet voor het servicepakket.

ServicePackageA wordt alleen geplaatst op een knooppunt waar de resterende CPU-capaciteit na het aftrekken van de som van CPU-aanvragen van alle servicepakketten die op dat knooppunt zijn geplaatst, groter is dan of gelijk is aan 1 kern. Op het knooppunt wordt het servicepakket beperkt tot één kern. Het servicepakket bevat twee codepakketten (CodeA1 en CodeA2) en geven beide het kenmerk CpuShares op. Het aandeel cpushares 512:256 wordt gebruikt om de CPU-limieten voor de afzonderlijke codepakketten te berekenen. CodeA1 wordt dus beperkt tot twee derde van een kern en CodeA2 wordt beperkt tot een derde van een kern. Als CpuShares niet voor alle codepakketten zijn opgegeven, Service Fabric de CPU-limiet er gelijkmatig over verdeeld.

Terwijl CpuShares die zijn opgegeven voor codepakketten hun relatieve aandeel van de totale CPU-limiet van het servicepakket vertegenwoordigen, worden geheugenwaarden voor codepakketten in absolute termen opgegeven. In dit voorbeeld wordt het kenmerk gebruikt om geheugenaanvragen van 1024 MB op te geven voor MemoryInMB zowel CodeA1 als CodeA2. Omdat de geheugenlimiet ( kenmerk) niet is opgegeven, gebruikt Service Fabric ook de opgegeven aanvraagwaarden als de MemoryInMBLimit limieten voor de codepakketten. De geheugenaanvraag (en limiet) voor het servicepakket wordt berekend als de som van de geheugenaanvraagwaarden (en limietwaarden) van de samenstellende codepakketten. Voor ServicePackageA worden de geheugenaanvraag en -limiet dus berekend als 2048 MB.

ServicePackageA wordt alleen geplaatst op een knooppunt waar de resterende geheugencapaciteit na het aftrekken van de som van geheugenaanvragen van alle servicepakketten die op dat knooppunt zijn geplaatst, groter is dan of gelijk is aan 2048 MB. Op het knooppunt worden beide codepakketten beperkt tot elk 1024 MB geheugen. Codepakketten (containers of processen) kunnen niet meer geheugen toewijzen dan deze limiet. Als u dit probeert te doen, leidt dit tot out-of-memory-uitzonderingen.

Voorbeeld 2: LimietenOnly-specificatie

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

In dit voorbeeld CpuCoresLimit worden de kenmerken en MemoryInMBLimit gebruikt, die alleen beschikbaar zijn in SF-versie 7.2 en hoger. Het kenmerk CpuCoresLimit wordt gebruikt om een CPU-limiet van 1 kern op te geven voor ServicePackageA. Omdat de CPU-aanvraag ( CpuCores kenmerk) niet is opgegeven, wordt deze beschouwd als 0. MemoryInMBLimit Kenmerk wordt gebruikt om geheugenlimieten van 1024 MB op te geven voor CodeA1 en CodeA2 en omdat aanvragen (kenmerk) niet worden opgegeven, worden ze beschouwd als MemoryInMB 0. De geheugenaanvraag en limiet voor ServicePackageA worden dus berekend als respectievelijk 0 en 2048. Omdat zowel CPU- als geheugenaanvragen voor ServicePackageA 0 zijn, geeft het CRM geen belasting om te overwegen voor plaatsing, voor de metrische gegevens servicefabric:/_CpuCores en servicefabric:/_MemoryInMB . Daarom kan ServicePackageA vanuit het perspectief van resourcebeheer op elk knooppunt worden geplaatst, ongeacht de resterende capaciteit. Net als in voorbeeld 1 wordt CodeA1 op het knooppunt beperkt tot twee derde van een kerngeheugen en 1024 MB aan geheugen. CodeA2 wordt beperkt tot een derde van een kerngeheugen en 1024 MB geheugen.

Voorbeeld 3: Specificatie 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>

Op basis van de eerste twee voorbeelden laat dit voorbeeld zien hoe u zowel aanvragen als limieten voor CPU en geheugen opgeeft. ServicePackageA heeft cpu- en geheugenaanvragen van respectievelijk 1 kern en 3072 (1024 + 2048) MB. Het kan alleen worden geplaatst op een knooppunt met ten minste 1 kerncapaciteit (en 3072 MB) na het aftrekken van de som van alle CPU-aanvragen (en geheugen) van alle servicepakketten die op het knooppunt worden geplaatst van de totale CPU-capaciteit (en geheugencapaciteit) van het knooppunt. Op het knooppunt wordt CodeA1 beperkt tot twee derde van 2 kernen en 3072 MB geheugen, terwijl CodeA2 wordt beperkt tot een derde van 2 kernen en 4096 MB geheugen.

Toepassingsparameters gebruiken

Wanneer u instellingen voor resourcebeheer opgeeft, is het mogelijk om toepassingsparameters te gebruiken voor het beheren van meerdere app-configuraties. In het volgende voorbeeld ziet u het gebruik van toepassingsparameters:

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

In dit voorbeeld worden standaardparameterwaarden ingesteld voor de productieomgeving, waarbij elk servicepakket 4 kernen en 2 GB geheugen krijgt. Het is mogelijk om standaardwaarden te wijzigen met toepassingsparameterbestanden. In dit voorbeeld kan één parameterbestand worden gebruikt voor het lokaal testen van de toepassing, waarbij er minder resources worden gebruikt dan in productie:

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

De resourcelimieten voor gebruikersservices afdwingen

Hoewel het toepassen van resourcebeheer op uw Service Fabric-services ervoor zorgt dat deze resourcebeheerde services hun quotum voor resources niet kunnen overschrijden, moeten veel gebruikers nog steeds een deel van hun Service Fabric-services uitvoeren in de modus 'niet-beheerd'. Wanneer u Service Fabric-services gebruikt, is het mogelijk om in situaties te komen waarin 'runaway' ungoverned services alle beschikbare resources op de Service Fabric-knooppunten verbruiken, wat kan leiden tot ernstige problemen zoals:

• Resource starvation of other services running on the nodes (including Service Fabric system services)
• Knooppunten die een slechte status krijgen
• Niet responsief Service Fabric voor clusterbeheer-API's

Om te voorkomen dat deze situaties zich voordoen, kunt u met Service Fabric de resourcelimieten afdwingen voor alle Service Fabric-gebruikersservices die worden uitgevoerd op het knooppunt (zowel beheerd als niet-beheerd) om ervoor te zorgen dat gebruikersservices nooit meer dan de opgegeven hoeveelheid resources gebruiken. Dit wordt bereikt door de waarde voor de configuratie EnforceUserServiceMetricCapacities in de sectie PlacementAndLoadBalancing van het ClusterManifest in te stellen op true. Deze instelling is standaard uitgeschakeld.

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

Aanvullende opmerkingen:

• Het afdwingen van resourcelimieten is alleen van toepassing op de servicefabric:/_CpuCores metrische gegevens van servicefabric:/_MemoryInMB de resource en
• Het afdwingen van resourcelimieten werkt alleen als knooppuntcapaciteiten voor de metrische resourcegegevens beschikbaar zijn voor Service Fabric, via een mechanisme voor automatische detectie of via gebruikers die handmatig de knooppuntcapaciteiten opgeven (zoals uitgelegd in de sectie Clusterinstallatie voor het inschakelen van resourcebeheer). Als er geen knooppuntcapaciteit is geconfigureerd, kan de mogelijkheid voor het afdwingen van resourcelimieten niet worden gebruikt omdat Service Fabric niet weet hoeveel resources er moeten worden reserveren voor gebruikersservices. Service Fabric wordt een statuswaarschuwing gegeven als EnforceUserServiceMetricCapacities waar is, maar er geen knooppuntcapaciteit is geconfigureerd.

Andere resources voor containers

Naast CPU en geheugen is het mogelijk om andere resourcelimieten voor containers op te geven. Deze limieten worden opgegeven op codepakketniveau en worden toegepast wanneer de container wordt gestart. In tegenstelling tot cpu en geheugen is Cluster Resource Manager niet op de hoogte van deze resources en worden er geen capaciteitscontroles of taakverdeling voor uitgevoerd.

• MemorySwapInMB: de totale hoeveelheid wisselgeheugen die kan worden gebruikt, in MB. Moet een positief geheel getal zijn.
• MemoryReservationInMB: de zachte limiet (in MB) voor geheugenbeheer die alleen wordt afgedwongen wanneer er een geheugenbeperking op het knooppunt wordt gedetecteerd. Moet een positief geheel getal zijn.
• CpuPercent: bruikbaar percentage beschikbare CPU's (alleen Windows). Moet een positief geheel getal zijn. Kan niet worden gebruikt met CpuShares, CpuCores of CpuCoresLimit.
• CpuShares: relatief CPU-gewicht. Moet een positief geheel getal zijn. Kan niet worden gebruikt met CpuPercent, CpuCores of CpuCoresLimit.
• MaximumIOps: maximale IO-snelheid (lezen en schrijven) in termen van IOps die kunnen worden gebruikt. Moet een positief geheel getal zijn.
• MaximumIOBandwidth: de maximale IO (bytes per seconde) die kan worden gebruikt (lezen en schrijven). Moet een positief geheel getal zijn.
• BlockIOWeight: blok-I/O-gewicht ten opzichte van andere codepakketten. Moet een positief geheel getal tussen 10 en 1000 zijn.
• DiskQuotaInMB: schijfquota voor containers. Moet een positief geheel getal zijn.
• KernelMemoryInMB: geheugenlimieten voor kernel in bytes. Moet een positief geheel getal zijn. Houd er rekening mee dat dit Linux-specifiek is en dat Docker in Windows een foutmelding krijgt als deze is ingesteld.
• ShmSizeInMB: grootte van /dev/shm in bytes. Als u dit weggelaten, gebruikt het systeem 64 MB. Moet een positief geheel getal zijn. Houd er rekening mee dat dit Linux-specifiek is, maar Docker negeert alleen (en geen foutmelding) als dit is opgegeven.

Deze resources kunnen worden gecombineerd met CPU en geheugen. Hier is een voorbeeld van het opgeven van aanvullende resources voor containers:

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

Volgende stappen

• Lees Introducing the Cluster Resource Manager Service Fabric cluster resource manager (Introductie tot Service Fabric clusterbronbeheer) voor meerinformatie over deze informatie.
• Lees Een toepassing modelleren in Service Fabric voor meer informatie over het toepassingsmodel, servicepakketten en codepakketten,en hoe replica's er aan worden Service Fabric.