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 uithongeren. Dit probleem wordt aangeduid als het probleem met ruis. 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 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 (metrische naam servicefabric:/_CpuCores): een logische kern die beschikbaar is op de hostcomputer. Alle kernen op alle knooppunten hebben hetzelfde gewicht.

• Geheugen (metrische naam servicefabric:/_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, 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.

Notitie

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

Alle bestaande functies kunnen ermee 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 cluster kan buffercapaciteit worden ingesteld voor deze twee metrische gegevens.

Notitie

Dynamische belastingrapportage wordt niet ondersteund voor deze metrische gegevens; belastingen voor deze metrische gegevens worden gedefinieerd tijdens het maken.

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 en de limiet voor een bepaalde resource (CPU of geheugen) fungeert. Dit wordt beschreven als de specificatie RequestsOnly in dit document.

• Verzoeken: Cpu- en geheugenaanvraagwaarden vertegenwoordigen de belastingen die worden gebruikt door de Cluster Resource Manager (CRM) voor de servicefabric:/_CpuCores metrische gegevens enservicefabric:/_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.

• Grenzen: De limietwaarden voor CPU en geheugen geven de werkelijke resourcelimieten aan die worden toegepast wanneer een proces of een container op een knooppunt wordt geactiveerd.

Service Fabric staat RequestsOnly, LimitsOnly en beide RequestsAndLimits-specificaties toe voor CPU en geheugen.

• Wanneer RequestsOnly-specificatie wordt gebruikt, gebruikt Service Fabric ook de aanvraagwaarden als limieten.
• Wanneer de specificatie LimitsOnly wordt gebruikt, beschouwt Service Fabric de aanvraagwaarden als 0.
• 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 gaan we een voorbeeld van een plaatsingsscenario bekijken 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 proces gebaseerd codepakket en specificeert ook slechts een aanvraag van één CPU-kern. Omdat beide servicepakketten de specificatie RequestsOnly hebben, worden hun limietwaarden ingesteld op hun aanvraagwaarden.

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

We gaan nu terug naar ons voorbeeld met de specificatie RequestsAndLimits . Deze keer geeft het servicepakket op basis van een container 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 een container 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 proces gebaseerde servicepakket op het knooppunt geplaatst. De runtime activeert het serviceproces en stelt de CPU-limiet in op één kern.

Op dit punt is de som van DE CPU-aanvragen van servicepakketten die op het knooppunt worden geplaatst, gelijk aan de CPU-capaciteit van het knooppunt. CRM plaatst geen containers of serviceprocessen meer 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) echter de capaciteit van twee kernen. Als de container en het proces tegelijkertijd bursten, is er mogelijk een conflict 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 door het proces niet wordt gegarandeerd.

Notitie

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

Er zijn een paar situaties waarin er conflicten kunnen zijn met de CPU. In deze situaties kunnen het proces en de container uit ons voorbeeld het probleem met de ruis van de 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 ons voorbeeld op het knooppunt worden weergegeven. In dit geval verbruikt dit nieuwe proces in feite 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 in hetzelfde cluster niet of gebruik plaatsingsbeperkingen , zodat deze twee typen services niet op dezelfde set knooppunten terechtkomen.

• Wanneer een ander proces wordt gestart op het knooppunt, buiten Service Fabric (bijvoorbeeld een besturingssysteemservice): in deze situatie strijdt het proces buiten Service Fabric ook om de CPU met bestaande services. De oplossing voor dit probleem is om knooppuntcapaciteiten correct in te stellen 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 is beschreven in het voorbeeld RequestsAndLimits, leiden aanvragen niet tot het reserveren van resources op een knooppunt. Wanneer een service met limieten groter dan aanvragen op een knooppunt wordt geplaatst, kan deze resources verbruiken (indien beschikbaar) tot aan de limieten. In dergelijke gevallen kunnen andere services op het knooppunt mogelijk geen resources verbruiken 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.

Om bufferruimte over te laten voor het besturingssysteem en voor andere processen die mogelijk op het knooppunt 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 volgt een voorbeeld van hoe u Service Fabric opdracht geeft 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 ter ondersteuning van de capaciteit die de gebruiker heeft gedefinieerd:

• Als de 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 de knooppuntcapaciteiten die in het manifest zijn gedefinieerd, groter zijn dan de 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 berekening van resourcecapaciteiten van knooppunten in gevallen waarin de gebruiker handmatig de waarden voor knooppuntresourcecapaciteiten op geeft. 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), waardoor een buffer van 20% over blijft voor de andere services die op het knooppunt worden uitgevoerd (inclusief Service Fabric-systeemservices)
• Gebruiker besluit de knooppuntresourcecapaciteit voor de metrische gegevens cpu-kernen handmatig te overschrijven 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 werd 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 op te geven voor ServicePackageA. 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 worden 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 voor alle codepakketten zijn opgegeven, verdeelt Service Fabric de CPU-limiet gelijkmatig over deze pakketten.

Hoewel 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 MemoryInMB kenmerk gebruikt om geheugenaanvragen van 1024 MB op te geven 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 waarden voor geheugenaanvragen (en limieten) van de samenstellende codepakketten. Voor ServicePackageA worden 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 de 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 en als u dit probeert te doen, resulteert dit in uitzonderingen voor onvoldoende geheugen.

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 worden CpuCoresLimit kenmerken 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 op te geven voor ServicePackageA. Omdat 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 (MemoryInMB kenmerk) niet worden 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, vormt het geen belasting voor CRM om te overwegen voor plaatsing, voor de servicefabric:/_CpuCores metrische gegevens en servicefabric:/_MemoryInMB . Vanuit het perspectief van resourcebeheer kan ServicePackageA daarom 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: 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>

Voortbouwend op de eerste twee voorbeelden, laat dit voorbeeld zien dat zowel aanvragen als limieten voor CPU en geheugen worden opgegeven. 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) nadat de som van alle CPU-aanvragen (en geheugen) van alle servicepakketten die op het knooppunt worden geplaatst, is afgetrokken van de totale CPU-capaciteit (en geheugen) van het knooppunt. Op het knooppunt is CodeA1 beperkt tot twee derde van 2 kernen en 3072 MB geheugen, terwijl CodeA2 beperkt is tot een derde van de 2 kernen en 4096 MB geheugen.

Toepassingsparameters gebruiken

Bij het opgeven van instellingen voor resourcebeheer is het mogelijk om toepassingsparameters te 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, 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>

Belangrijk

Het opgeven van resourcegovernance 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 eerdere versie dan versie 6.1.

De resourcelimieten voor gebruikersservices afdwingen

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

• Resource-uitstering van andere services die op de knooppunten worden uitgevoerd (inclusief Service Fabric-systeemservices)
• Knooppunten die in een slechte status terechtkomen
• Service Fabric-clusterbeheer-API's reageren niet

Om deze situaties te voorkomen, kunt u met Service Fabric de resourcelimieten afdwingen voor alle Service Fabric-gebruikersservices die op het knooppunt worden uitgevoerd (zowel beheerd als niet-beheerd), om te garanderen 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:

• Afdwingen van resourcelimieten is alleen van toepassing op de metrische gegevens van de servicefabric:/_CpuCores resource en servicefabric:/_MemoryInMB
• Het afdwingen van resourcelimieten werkt alleen als knooppuntcapaciteiten voor de metrische resourcegegevens beschikbaar zijn voor Service Fabric, via automatische detectie of via gebruikers die de knooppuntcapaciteiten handmatig opgeven (zoals uitgelegd in de sectie Cluster instellen 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 weet hoeveel resources moeten worden gereserveerd voor gebruikersservices. Service Fabric geeft een statuswaarschuwing 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 het niveau van het codepakket 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 voert geen capaciteitscontroles of taakverdeling voor deze resources uit.

• 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 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: het maximum aantal IO (bytes per seconde) dat 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 specifiek is voor Linux 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 specifiek is voor Linux, maar Docker negeert alleen (en geen 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 de Service Fabric-clusterresourcebeheer voor meer informatie over Cluster Resource Manager.
• Lees Een toepassing modelleren in Service Fabric voor meer informatie over het toepassingsmodel, servicepakketten en codepakketten en hoe replica's eraan worden toegewezen.