Resourcebeheer

Wanneer u meerdere services op hetzelfde knooppunt of cluster uitvoert, is het mogelijk dat één service meer resources verbruikt, waardoor andere services in het proces worden verhongerd. Dit probleem wordt het probleem 'lawaaierige buur' genoemd. Met Azure Service Fabric kan de ontwikkelaar dit gedrag beheren door aanvragen en limieten per service op te geven om het resourcegebruik te beperken.

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

Metrische gegevens over resourcebeheer

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

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

• Geheugen (metrische naamservicefabric:/_MemoryInMB): geheugen wordt uitgedrukt in megabytes en wordt toegewezen aan fysiek geheugen dat beschikbaar is op de computer.

Voor deze twee metrische gegevens houdt Cluster Resource Manager (CRM) de totale clustercapaciteit bij, de belasting op elk knooppunt in het cluster en de resterende resources in het cluster. Deze twee metrische gegevens zijn gelijk aan andere gebruikers- of aangepaste metrische gegevens.

Notitie

Aangepaste namen van metrische gegevens mogen niet een van deze twee metrische namen zijn, omdat dit leidt tot niet-gedefinieerd gedrag.

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.
• Wanneer u een cluster beschrijft, kan buffercapaciteit worden ingesteld voor deze twee metrische gegevens.

Notitie

Dynamische belastingrapportage wordt niet ondersteund voor deze metrische gegevens. De belasting voor deze metrische gegevens wordt tijdens het maken gedefinieerd.

Mechanisme voor resourcebeheer

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

Notitie

Service Fabric-runtimeversies ouder dan 7.2 ondersteunen alleen een model waarbij één waarde zowel als de aanvraag als de limiet voor een bepaalde resource (CPU of geheugen) dient. Dit wordt beschreven als de RequestsOnly-specificatie in dit document.

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

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

Service Fabric staat RequestsOnly, LimitsOnly en zowel RequestsAndLimits-specificaties 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 beschouwd.
• Wanneer de specificatie RequestsAndLimits wordt gebruikt, moeten de limietwaarden groter zijn dan of gelijk zijn aan de aanvraagwaarden.

Laten we eens kijken naar een voorbeeld van een plaatsingsscenario met een RequestsOnly-specificatie voor de CPU-resource (mechanisme voor geheugenbeheer is equivalent) om meer inzicht te krijgen in het mechanisme voor resourcebeheer. 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 alleen een aanvraag van één CPU-kern op. Het tweede servicepakket dat moet worden geplaatst, bestaat uit slechts één op proces gebaseerd codepakket en geeft ook slechts een aanvraag van één CPU-kern op. Omdat beide servicepakketten een RequestsOnly-specificatie hebben, worden hun limietwaarden ingesteld op hun aanvraagwaarden.

1. Eerst wordt het servicepakket op basis van containers 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 servicepakket op basis van processen 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 aanvragen gelijk aan de capaciteit van het knooppunt. CRM plaatst geen containers of serviceprocessen met CPU-aanvragen op dit knooppunt. Op het knooppunt worden een proces en een container uitgevoerd met één kern en hebben ze geen last van elkaar voor CPU.

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

1. Eerst wordt het servicepakket op basis van containers 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 servicepakket op basis van processen 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 CPU-aanvragen van servicepakketten die op het knooppunt worden geplaatst, gelijk aan de CPU-capaciteit van het knooppunt. CRM plaatst geen containers of serviceprocessen met CPU-aanvragen op dit knooppunt. Op het knooppunt overschrijdt de som van de limieten (twee kernen voor de container + één kern voor het proces) de capaciteit van twee kernen. Als de container en het proces tegelijkertijd bursten, is er sprake van conflicten voor de CPU-resource. Dergelijke conflicten worden beheerd 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 niet wordt gegarandeerd.

Notitie

Zoals in het vorige voorbeeld wordt geïllustreerd, leiden de aanvraagwaarden voor CPU en geheugen niet tot reservering van resources op een knooppunt. Deze waarden vertegenwoordigen het resourceverbruik dat de Cluster Resource Manager beschouwt bij het nemen van plaatsingsbeslissingen. Limietwaarden vertegenwoordigen de werkelijke resourcelimieten die worden toegepast wanneer een proces of container op een knooppunt wordt geactiveerd.

Er zijn enkele situaties waarin er sprake kan zijn van conflicten voor CPU. In deze situaties kunnen het proces en de container uit ons voorbeeld het probleem met luidruchtige buren ondervinden:

• Het combineren van beheerde en niet-beheerde services en containers: als een gebruiker een service maakt zonder dat er resourcebeheer is opgegeven, ziet de runtime dat deze geen resources verbruikt en kan deze in het knooppunt in ons voorbeeld worden opgeslagen. In dit geval verbruikt dit nieuwe proces effectief 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 beheerde en niet-beheerde services op hetzelfde cluster niet of gebruik plaatsingsbeperkingen zodat deze twee typen services niet op dezelfde set knooppunten terechtkomen.

• Wanneer een ander proces op het knooppunt wordt gestart, buiten Service Fabric (bijvoorbeeld een besturingssysteemservice): In deze situatie heeft het proces buiten Service Fabric ook te maken met CPU met bestaande services. De oplossing voor dit probleem is het correct instellen van knooppuntcapaciteiten om rekening te houden met 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 meer limieten dan aanvragen op een knooppunt wordt geplaatst, kan deze resources (indien beschikbaar) tot de limieten verbruiken. In dergelijke gevallen kunnen andere services op het knooppunt mogelijk geen resources gebruiken tot hun 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 knooppuntcapaciteiten voor deze twee resources in.

Service Fabric gebruikt slechts 80% van de beschikbare resources op het knooppunt om bufferruimte voor het besturingssysteem te behouden en voor andere processen die op het knooppunt kunnen worden uitgevoerd. Dit percentage kan worden geconfigureerd en kan worden gewijzigd in het clustermanifest.

Hier volgt een voorbeeld van het instrueren van Service Fabric om 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 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 volgt 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 om de capaciteit te ondersteunen die de gebruiker heeft gedefinieerd:

• Als knooppuntcapaciteiten die in het manifest zijn gedefinieerd, 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 zijn gedefinieerd in het manifest groter zijn dan beschikbare resources, gebruikt Service Fabric de beschikbare resources als knooppuntcapaciteiten.

Automatische detectie van beschikbare resources kan worden uitgeschakeld als dit niet vereist is. Als u dit 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>

Belangrijk

Vanaf Service Fabric versie 7.0 hebben we de regel bijgewerkt voor de manier waarop knooppuntresourcecapaciteiten worden berekend in de gevallen waarin de gebruiker handmatig de waarden voor knooppuntresourcecapaciteiten levert. Laten we eens kijken naar het volgende scenario:

• Er zijn in totaal 10 CPU-kernen op het knooppunt
• SF is geconfigureerd voor het gebruik van 80% van de totale resources voor de gebruikersservices (standaardinstelling), die een buffer van 20% overlaat voor de andere services die op het knooppunt worden uitgevoerd (incl. Service Fabric-systeemservices)
• Gebruiker besluit de resourcecapaciteit van het knooppunt handmatig te overschrijven voor de metrische cpu-kernen en stelt deze in op 5 kernen

We hebben de regel gewijzigd voor de manier waarop de beschikbare capaciteit voor Service Fabric-gebruikersservices op de volgende manier wordt berekend:

• Vóór Service Fabric 7.0 wordt de beschikbare capaciteit voor gebruikersservices berekend op 5 kernen (capaciteitsbuffer van 20% wordt genegeerd)
• Vanaf Service Fabric 7.0 wordt de beschikbare capaciteit voor gebruikersservices berekend op 4 kernen (capaciteitsbuffer van 20% wordt niet genegeerd)

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 CpuCores kenmerk gebruikt om een aanvraag van 1 CPU-kern voor ServicePackageA op te geven. Omdat de CPU-limiet (CpuCoresLimit kenmerk) niet is opgegeven, gebruikt Service Fabric ook de opgegeven aanvraagwaarde van 1 kern als de CPU-limiet voor het servicepakket.

ServicePackageA wordt alleen op een knooppunt geplaatst waar de resterende CPU-capaciteit na het aftrekken van de som van DE CPU-aanvragen van alle servicepakketten die op dat knooppunt zijn geplaatst, groter is dan of gelijk is aan 1 kern. Op het knooppunt is het servicepakket beperkt tot één kern. Het servicepakket bevat twee codepakketten (CodeA1 en CodeA2) en beide geven het CpuShares kenmerk 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 zijn opgegeven voor alle codepakketten, verdeelt Service Fabric de CPU-limiet op dezelfde wijze.

Hoewel CpuShares die zijn opgegeven voor codepakketten hun relatieve verhouding vertegenwoordigen van de totale CPU-limiet van het servicepakket, worden geheugenwaarden voor codepakketten in absolute termen opgegeven. In dit voorbeeld wordt het kenmerk gebruikt voor het MemoryInMB opgeven van geheugenaanvragen van 1024 MB voor zowel CodeA1 als CodeA2. Omdat de geheugenlimiet (MemoryInMBLimit kenmerk) niet is opgegeven, gebruikt Service Fabric ook de opgegeven aanvraagwaarden als de 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 wordt de geheugenaanvraag en -limiet berekend als 2048 MB.

ServicePackageA wordt alleen op een knooppunt geplaatst 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 zijn beide codepakketten beperkt tot elk 1024 MB geheugen. Codepakketten (containers of processen) kunnen niet meer geheugen toewijzen dan deze limiet. Als u dit probeert, leidt dit tot onvoldoende geheugenuitzonderingen.

Voorbeeld 2: LimitOnly-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 worden kenmerken CpuCoresLimit gebruikt en MemoryInMBLimit gebruikt, die alleen beschikbaar zijn in SF-versies 7.2 en hoger. Het kenmerk CpuCoresLimit wordt gebruikt om een CPU-limiet van 1 kern voor ServicePackageA op te geven. Omdat de CPU-aanvraag (CpuCores kenmerk) niet is opgegeven, wordt deze beschouwd als 0. MemoryInMBLimit kenmerk wordt gebruikt voor het opgeven van geheugenlimieten van 1024 MB voor CodeA1 en CodeA2 en omdat aanvragen (MemoryInMB kenmerk) niet zijn opgegeven, worden ze beschouwd als 0. De geheugenaanvraag en -limiet voor ServicePackageA worden dus berekend als respectievelijk 0 en 2048. Omdat zowel CPU- als geheugenaanvragen voor ServicePackageA 0 zijn, is er geen belasting voor CRM om rekening mee te houden voor plaatsing, voor de servicefabric:/_CpuCores en servicefabric:/_MemoryInMB metrische gegevens. Daarom kan ServicePackageA vanuit het perspectief van resourcebeheer op elk knooppunt worden geplaatst, ongeacht de resterende capaciteit. Net als in voorbeeld 1 is CodeA1 op het knooppunt beperkt tot twee derde van een kern en 1024 MB geheugen en is CodeA2 beperkt tot een derde van een kern en 1024 MB geheugen.

Voorbeeld 3: RequestsAndLimits-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" CpuCoresLimit="2"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" MemoryInMBLimit="3072" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="2048" MemoryInMBLimit="4096" />
    </Policies>
  </ServiceManifestImport>

Voort op de eerste twee voorbeelden laat dit voorbeeld zien hoe zowel aanvragen als limieten voor CPU en geheugen worden opgegeven. ServicePackageA heeft CPU- en geheugenaanvragen van respectievelijk 1 kern en 3072 (respectievelijk 1024 + 2048) MB. Het kan alleen worden geplaatst op een knooppunt met ten minste 1 kern (en 3072 MB) aan capaciteit 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 het geheugen) van het knooppunt. Op het knooppunt is 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, kunt u toepassingsparameters gebruiken om meerdere app-configuraties te beheren. 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, waar het minder resources krijgt 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>

Belangrijk

Het opgeven van resourcebeheer met toepassingsparameters is beschikbaar vanaf Service Fabric versie 6.1.

Wanneer toepassingsparameters worden gebruikt om resourcebeheer op te geven, kan Service Fabric niet worden gedowngraded naar een versie vóór versie 6.1.

De resourcelimieten voor gebruikersservices afdwingen

Hoewel het toepassen van resourcebeheer op uw Service Fabric-services garandeert dat deze door resources beheerde services hun resourcequotum niet kunnen overschrijden, moeten veel gebruikers nog steeds enkele van hun Service Fabric-services uitvoeren in de modus geforceerd. Wanneer u geforceerd Service Fabric-services gebruikt, is het mogelijk om in situaties te treden waarin 'runaway' niet-overgeslagen services alle beschikbare resources op de Service Fabric-knooppunten verbruiken, wat kan leiden tot ernstige problemen, zoals:

• Resourcehongering van andere services die op de knooppunten worden uitgevoerd (inclusief Service Fabric-systeemservices)
• Knooppunten die een slechte status hebben
• Niet-reagerende Service Fabric-clusterbeheer-API's

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

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

Aanvullende opmerkingen:

• Afdwingen van resourcelimieten is alleen van toepassing op de metrische gegevens van resources servicefabric:/_CpuCores en servicefabric:/_MemoryInMB resources
• Het afdwingen van resourcelimiet werkt alleen als knooppuntcapaciteiten voor de metrische resourcegegevens beschikbaar zijn voor Service Fabric, hetzij via het mechanisme voor automatische detectie, of via gebruikers die handmatig de knooppuntcapaciteiten opgeven (zoals uitgelegd in de sectie Clusterconfiguratie voor het inschakelen van resourcebeheer ). Als knooppuntcapaciteiten niet zijn geconfigureerd, kan de mogelijkheid voor het afdwingen van resourcelimieten niet worden gebruikt, omdat Service Fabric niet kan weten hoeveel resources moeten worden gereserveerd voor gebruikersservices. Service Fabric geeft een statuswaarschuwing uit als 'EnforceUserServiceMetricCapacities' waar is, maar knooppuntcapaciteiten niet zijn 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 taakverdelingen voor deze resources 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 geheugenconflicten worden gedetecteerd op het knooppunt. Moet een positief geheel getal zijn.
• CpuPercent: bruikbaar percentage van 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 IO-gewicht, ten opzichte van andere codepakketten. Moet een positief geheel getal tussen 10 en 1000 zijn.
• DiskQuotaInMB: Schijfquotum voor containers. Moet een positief geheel getal zijn.
• KernelMemoryInMB: Kernelgeheugenlimieten in bytes. Moet een positief geheel getal zijn. Houd er rekening mee dat dit linux-specifiek is en Docker in Windows een foutmelding krijgt als dit is ingesteld.
• ShmSizeInMB: Grootte van /dev/shm in bytes. Als u dit weglaat, gebruikt het systeem 64 MB. Moet een positief geheel getal zijn. Houd er rekening mee dat dit linux-specifiek is, maar Docker negeert (en niet fout) als dit is opgegeven.

Deze resources kunnen worden gecombineerd met CPU en geheugen. Hier volgt 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 Inleiding tot Service Fabric-clusterresourcebeheer voor meer informatie over Cluster Resource Manager.
• Voor meer informatie over het toepassingsmodel, servicepakketten en codepakketten, en hoe replica's aan deze replica's worden toegewezen, leest u een toepassing in Service Fabric.