Resursstyrning

När du kör flera tjänster på samma nod eller kluster är det möjligt att en tjänst förbrukar mer resurser, vilket gör att andra tjänster i processen är utsvultna. Det här problemet kallas för problemet med "störande grannar". Azure Service Fabric gör det möjligt för utvecklare att styra det här beteendet genom att ange begäranden och gränser per tjänst för att begränsa resursanvändningen.

Innan du fortsätter med den här artikeln rekommenderar vi att du bekantar dig med Service Fabric-programmodellen och Service Fabric värdmodellen.

Mått för resursstyrning

Resursstyrning stöds i Service Fabric i enlighet med tjänstpaketet. De resurser som är tilldelade till tjänstpaketet kan delas upp ytterligare mellan kodpaket. Service Fabric har stöd för cpu- och minnesstyrning per tjänstpaket, med två inbyggda mått:

• CPU (måttnamn): servicefabric:/_CpuCores En logisk kärna som är tillgänglig på värddatorn. Alla kärnor över alla noder viktas på samma sätt.

• Minne (måttnamn): Minnet uttrycks i megabyte och mappar servicefabric:/_MemoryInMB till det fysiska minne som är tillgängligt på datorn.

För dessa två mått spårar Klusterresurshanteraren (CRM) den totala klusterkapaciteten, belastningen på varje nod i klustret och återstående resurser i klustret. Dessa två mått motsvarar andra användare eller anpassade mått. Alla befintliga funktioner kan användas med dem:

• Klustret kan balanseras enligt dessa två mått (standardbeteende).
• Klustret kan defragmenteras enligt dessa två mått.
• När du beskriver ett klusterkan buffrad kapacitet anges för dessa två mått.

Mekanism för resursstyrning

Från och med version 7.2 Service Fabric körningen specifikation av begäranden och gränser för CPU- och minnesresurser.

• Begäranden: Värden för CPU- och minnesbegäran representerar belastningar som används av Klusterresurshanteraren (CRM) för servicefabric:/_CpuCores servicefabric:/_MemoryInMB måtten och . Med andra ord anser CRM att resursförbrukningen för en tjänst är lika med dess begärandevärden och använder dessa värden när placeringsbeslut fattas.

• Begränsningar: Värden för processor- och minnesgräns representerar de faktiska resursgränser som tillämpas när en process eller en container aktiveras på en nod.

Service Fabric tillåter specifikationerna RequestsOnly, LimitsOnly och både RequestsAndLimits för CPU och minne.

• När RequestsOnly-specifikationen används använder Service Fabric även begärandevärdena som gränser.
• När LimitsOnly-specifikationen används betraktar Service Fabric begärandevärdena som 0.
• När RequestsAndLimits-specifikationen används måste gränsvärdena vara större än eller lika med begärandevärdena.

För att bättre förstå mekanismen för resursstyrning ska vi titta på ett exempel på ett placeringsscenario med en RequestsOnly-specifikation för CPU-resursen (mekanismen för minnesstyrning är likvärdig). Överväg en nod med två processorkärnor och två tjänstpaket som ska placeras på den. Det första tjänstpaketet som ska placeras består av bara ett containerkodpaket och anger endast en begäran om en processorkärna. Det andra tjänstpaketet som ska placeras består av bara ett processbaserat kodpaket och anger också bara en begäran om en processorkärna. Eftersom båda tjänstpaketen har en RequestsOnly-specifikation anges deras gränsvärden till deras begärandevärden.

1. Först placeras det containerbaserade tjänstpaketet som begär en processorkärna på noden. Körningen aktiverar containern och anger CPU-gränsen till en kärna. Containern kan inte använda mer än en kärna.

2. Därefter placeras det processbaserade tjänstpaketet som begär en processorkärna på noden. Körningen aktiverar tjänstprocessen och anger sin CPU-gräns till en kärna.

I det här läget är summan av begäranden lika med nodens kapacitet. CRM placerar inte några fler containrar eller tjänstprocesser med CPU-begäranden på den här noden. På noden körs en process och en container med en kärna vardera och kommer inte att konkurrera med varandra för CPU.

Nu ska vi gå tillbaka till vårt exempel med en RequestsAndLimits-specifikation. Den här gången anger det containerbaserade tjänstpaketet en begäran om en processorkärna och en gräns på två CPU-kärnor. Det processbaserade tjänstpaketet anger både en begäran och en gräns på en processorkärna.

1. Först placeras det containerbaserade tjänstpaketet på noden. Körningen aktiverar containern och anger CPU-gränsen till två kärnor. Containern kan inte använda fler än två kärnor.
2. Därefter placeras det processbaserade tjänstpaketet på noden. Körningen aktiverar tjänstprocessen och anger sin CPU-gräns till en kärna.

I det här läget är summan av CPU-begäranden för tjänstpaket som placeras på noden lika med nodens CPU-kapacitet. CRM placerar inte några fler containrar eller tjänstprocesser med CPU-begäranden på den här noden. På noden överskrider dock summan av gränserna (två kärnor för containern + en kärna för processen) kapaciteten för två kärnor. Om containern och processen burst-bearbetas samtidigt kan det finnas en risk för att CPU-resursen blir det. Den här utvecklingen kommer att ske av plattformens underliggande operativsystem. I det här exemplet kan containern burst-brista upp till två CPU-kärnor, vilket resulterar i att processens begäran om en processorkärna inte garanteras.

Det finns några situationer där det kan uppstå konflikter om CPU. I dessa situationer kan processen och containern från vårt exempel uppleva problemet med den störande grannen:

• Blanda styrda och icke-styrda tjänster och containrar: Om en användare skapar en tjänst utan någon angiven resursstyrning ser körningen att den förbrukar inga resurser och kan placera den på noden i vårt exempel. I det här fallet förbrukar den här nya processen effektivt en del CPU på bekostnad av de tjänster som redan körs på noden. Det finns två lösningar på det här problemet. Blanda antingen inte styrda och icke-styrda tjänster i samma kluster eller använd placeringsbegränsningar så att dessa två typer av tjänster inte hamnar på samma uppsättning noder.

• När en annan process startas på noden, utanför Service Fabric (till exempel en os-tjänst): I det här fallet konkurrerar processen utanför Service Fabric även cpu med befintliga tjänster. Lösningen på det här problemet är att konfigurera nodkapaciteter korrekt för att ta hänsyn till operativsystemets omkostnader, som du ser i nästa avsnitt.

• När begäranden inte är lika med gränser: Enligt beskrivningen i exemplet RequestsAndLimits tidigare leder begäranden inte till reservation av resurser på en nod. När en tjänst med gränser som är större än begäranden placeras på en nod kan den förbruka resurser (om det är tillgängligt) upp till den gränsen. I sådana fall kanske andra tjänster på noden inte kan använda resurser upp till sina begärandevärden.

Klusterkonfiguration för att aktivera resursstyrning

När en nod startar och ansluter till klustret Service Fabric identifierar den tillgängliga mängden minne och det tillgängliga antalet kärnor och anger sedan nodkapaciteten för dessa två resurser.

Om du vill lämna buffertutrymmet för operativsystemet och för andra processer som kan köras på noden använder Service Fabric endast 80 % av de tillgängliga resurserna på noden. Den här procentandelen kan konfigureras och kan ändras i klustermanifestet.

Här är ett exempel på hur du instruerar Service Fabric att använda 50 % av den tillgängliga processorn och 70 % av tillgängligt minne:

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

För de flesta kunder och scenarier är automatisk identifiering av nodkapacitet för CPU och minne den rekommenderade konfigurationen (automatisk identifiering är aktiverat som standard). Men om du behöver fullständig manuell konfiguration av nodkapaciteter kan du konfigurera dem per nodtyp med hjälp av mekanismen för att beskriva noder i klustret. Här är ett exempel på hur du ställer in nodtypen med fyra kärnor och 2 GB minne:

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

När automatisk identifiering av tillgängliga resurser är aktiverat och nodkapaciteter definieras manuellt i klustermanifestet kontrollerar Service Fabric att noden har tillräckligt med resurser för att stödja den kapacitet som användaren har definierat:

• Om nodkapaciteter som definieras i manifestet är mindre än eller lika med de tillgängliga resurserna på noden använder Service Fabric de kapaciteter som anges i manifestet.

• Om nodkapaciteter som definieras i manifestet är större än tillgängliga resurser använder Service Fabric tillgängliga resurserna som nodkapaciteter.

Automatisk identifiering av tillgängliga resurser kan stängas av om det inte behövs. Om du vill inaktivera den ändrar du följande inställning:

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

För optimala prestanda bör följande inställning också aktiveras i klustermanifestet:

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

Ange resursstyrning

Resursstyrningsbegäranden och begränsningar anges i programmanifestet (avsnittet ServiceManifestImport). Låt oss titta på några exempel:

Exempel 1: Specifikation för 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>

I det här exemplet används CpuCores -attributet för att ange en begäran om 1 CPU-kärna för ServicePackageA. Eftersom CPU-gränsen ( attributet) inte anges Service Fabric också det angivna värdet för begäran på 1 kärna som CpuCoresLimit CPU-gräns för tjänstpaketet.

ServicePackageA placeras bara på en nod där den återstående CPU-kapaciteten efter subtrahering av summan av CPU-begäranden för alla tjänstpaket som placerats på noden är större än eller lika med 1 kärna. På noden begränsas tjänstpaketet till en kärna. Tjänstpaketet innehåller två kodpaket (CodeA1 och CodeA2), och båda anger CpuShares attributet . Andelen CpuShares 512:256 används för att beräkna CPU-gränserna för de enskilda kodpaketen. CodeA1 begränsas därför till två tredjedelar av en kärna och CodeA2 begränsas till en tredjedel av en kärna. Om CpuShares inte har angetts för alla kodpaket Service Fabric delar upp CPU-gränsen jämnt mellan dem.

Medan CpuShares som anges för kodpaket representerar deras relativa andel av tjänstpaketets totala CPU-gräns, anges minnesvärden för kodpaket i absoluta termer. I det här exemplet används attributet för att ange minnesbegäranden på MemoryInMB 1 024 MB för både CodeA1 och CodeA2. Eftersom minnesgränsen ( attributet) inte har angetts Service Fabric också de angivna MemoryInMBLimit begärandevärdena som gränser för kodpaketen. Minnesbegäran (och gränsen) för tjänstpaketet beräknas som summan av minnesbegärandevärdena (och gränsen) för dess ingående kodpaket. För ServicePackageA beräknas minnesbegäran och minnesgränsen därför som 2 048 MB.

ServicePackageA placeras bara på en nod där den återstående minneskapaciteten efter subtrahering av summan av minnesbegäranden för alla tjänstpaket som placeras på noden är större än eller lika med 2 048 MB. På noden är båda kodpaketen begränsade till 1 024 MB minne vardera. Kodpaket (containrar eller processer) kan inte allokera mer minne än den här gränsen, och om du försöker göra det resulterar det i minnesundantag.

Exempel 2: LimitsOnly-specifikation

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

I det här CpuCoresLimit exemplet MemoryInMBLimit används attributen och , som endast är tillgängliga i SF-versionerna 7.2 och senare. Attributet CpuCoresLimit används för att ange en CPU-gräns på 1 kärna för ServicePackageA. Eftersom CPU-begäran CpuCores (attribut) inte har angetts anses den vara 0. MemoryInMBLimit attribute används för att ange minnesgränser på 1 024 MB för CodeA1 och CodeA2 och eftersom begäranden (attribut) inte har angetts anses de MemoryInMB vara 0. Minnesbegäran och gränsen för ServicePackageA beräknas därför som 0 respektive 2048. Eftersom både CPU- och minnesbegäranden för ServicePackageA är 0 medför det ingen belastning för CRM att överväga för servicefabric:/_CpuCores servicefabric:/_MemoryInMB placering, för måtten och . Ur ett resursstyrningsperspektiv kan ServicePackageA därför placeras på valfri nod oavsett återstående kapacitet. Precis som i exempel 1 begränsas CodeA1 på noden till två tredjedelar av en kärna och 1 024 MB minne, och CodeA2 begränsas till en tredjedel av en kärna och 1 024 MB minne.

Exempel 3: Specifikation för 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>

Det här exemplet bygger på de två första exemplen och visar hur du anger både begäranden och gränser för CPU och minne. ServicePackageA har CPU- och minnesbegäranden på 1 kärna respektive 3072 (1 024 + 2 048 MB). Den kan bara placeras på en nod som har minst 1 kärna (och 3 072 MB) kapacitet kvar efter att summan av alla CPU-begäranden (och minne) för alla tjänstpaket som placeras på noden har subtraheras från nodens totala CPU-kapacitet (och minne). På noden begränsas CodeA1 till två tredjedelar av 2 kärnor och 3 072 MB minne, medan CodeA2 begränsas till en tredjedel av 2 kärnor och 4 096 MB minne.

Använda programparametrar

När du anger inställningar för resursstyrning är det möjligt att använda programparametrar för att hantera flera appkonfigurationer. I följande exempel visas användningen av programparametrar:

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

I det här exemplet anges standardparametervärden för produktionsmiljön, där varje servicepaket får 4 kärnor och 2 GB minne. Det går att ändra standardvärden med programparameterfiler. I det här exemplet kan en parameterfil användas för att testa programmet lokalt, där det skulle få mindre resurser än i produktion:

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

Framtvinga resursbegränsningar för användartjänster

När resursstyrning tillämpas på dina Service Fabric-tjänster garanterar att dessa resursstyrda tjänster inte kan överskrida sin resurskvot, behöver många användare fortfarande köra vissa av sina Service Fabric-tjänster i överostyrt läge. När du använder överoderade Service Fabric-tjänster är det möjligt att få situationer där "skenande" överansade tjänster förbrukar alla tillgängliga resurser på Service Fabric-noderna, vilket kan leda till allvarliga problem som:

• Resurssvält för andra tjänster som körs på noderna (Service Fabric av systemtjänster)
• Noder som slutar på ett felaktigt tillstånd
• API:er för Service Fabric klusterhantering som inte svarar

För att förhindra att dessa situationer inträffar kan du med Service Fabric framtvinga resursgränserna för alla Service Fabric-användartjänster som körs på noden (både styrda och översked) för att garantera att användartjänsterna aldrig använder mer än den angivna mängden resurser. Detta uppnås genom att ange värdet för EnforceUserServiceMetricCapacities-config i avsnittet PlacementAndLoadBalancing i ClusterManifest till true. Den här inställningen är inaktiverad som standard.

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

Ytterligare kommentarer:

• Tvingande resursbegränsningar gäller endast servicefabric:/_CpuCores för servicefabric:/_MemoryInMB resursmåtten och
• Framtvingande av resursgräns fungerar bara om nodkapaciteter för resursmåtten är tillgängliga för Service Fabric, antingen via automatisk identifiering eller via användare som manuellt anger nodkapaciteten (enligt beskrivningen i avsnittet Klusterkonfiguration för att aktivera resursstyrning). Om nodkapaciteter inte har konfigurerats går det inte att använda funktionen för tvingande resursbegränsning eftersom Service Fabric inte kan veta hur mycket resurser som ska reserveras för användartjänster. Service Fabric en hälsovarning om "EnforceUserServiceMetricCapacities" är sant men nodkapaciteter inte har konfigurerats.

Andra resurser för containrar

Förutom cpu och minne är det möjligt att ange andra resursgränser för containrar. Dessa gränser anges på kodpaketnivå och tillämpas när containern startas. Till skillnad från processor och minne Klusterresurshanteraren inte dessa resurser och kommer inte att göra några kapacitetskontroller eller belastningsutjämning för dem.

• MemorySwapInMB: Den totala mängden växlingsminne som kan användas i MB. Måste vara ett positivt heltal.
• MemoryReservationInMB: Den mjuka gränsen (i MB) för minnesstyrning som tillämpas endast när minnesbegränsning identifieras på noden. Måste vara ett positivt heltal.
• CpuPercent: Användbar procentandel av tillgängliga processorer (endast Windows). Måste vara ett positivt heltal. Kan inte användas med CpuShares, CpuCores eller CpuCoresLimit.
• CpuShares: Relativ CPU-vikt. Måste vara ett positivt heltal. Kan inte användas med CpuPercent, CpuCores eller CpuCoresLimit.
• MaximumIOps: Högsta IO-hastighet (läsning och skrivning) i termer av IOps som kan användas. Måste vara ett positivt heltal.
• MaximumIOBandwidth: Det maximala antalet I/O (byte per sekund) som kan användas (läsning och skrivning). Måste vara ett positivt heltal.
• BlockIOWeight: Blockera I/O-vikt i förhållande till andra kodpaket. Måste vara ett positivt heltal mellan 10 och 1 000.
• DiskQuotaInMB: Diskkvot för containrar. Måste vara ett positivt heltal.
• KernelMemoryInMB: Kernelminnesgränser i byte. Måste vara ett positivt heltal. Observera att detta är Linux-specifikt, och Docker i Windows får ett felmeddelande om detta har angetts.
• ShmSizeInMB: Storleken på /dev/shm i byte. Om detta utelämnas använder systemet 64 MB. Måste vara ett positivt heltal. Observera att detta är Linux-specifikt, men Docker ignorerar bara (och inte fel ut) om det anges.

Dessa resurser kan kombineras med processor och minne. Här är ett exempel på hur du anger ytterligare resurser för containrar:

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

Nästa steg

• Mer information om Klusterresurshanteraren finns i Introduktion till Service Fabric klusterresurshanteraren.
• Mer information om programmodellen, tjänstpaket och kodpaket – och hur repliker mappar till dem – finns i Modellera ett program i Service Fabric.