Beskriva ett Service Fabric kluster med hjälp av Klusterresurshanteraren

Funktionen Klusterresurshanteraren Azure Service Fabric innehåller flera mekanismer för att beskriva ett kluster:

• Feldomäner
• Uppgradera domäner
• Nodegenskaper
• Nodkapaciteter

Under körningen Klusterresurshanteraren den här informationen för att säkerställa hög tillgänglighet för de tjänster som körs i klustret. När dessa viktiga regler tillämpas försöker den även optimera resursförbrukningen i klustret.

Feldomäner

En feldomän är alla områden med koordinerade fel. En enskild dator är en feldomän. Den kan misslyckas på egen hand av olika orsaker, från strömförsörjningsfel till fel på grund av felaktig inbyggd NIC-programvara.

Datorer som är anslutna till samma Ethernet-växel finns i samma feldomän. Det gäller även datorer som delar en enda strömkälla eller på en enda plats.

Eftersom det är naturligt att maskinvarufel överlappar varandra är feldomäner i sig hierarkiska. De representeras som URI:er i Service Fabric.

Det är viktigt att feldomäner konfigureras korrekt eftersom Service Fabric använder den här informationen för att placera tjänster på ett säkert sätt. Service Fabric vill inte placera tjänster så att förlust av en feldomän (som orsakas av fel på en komponent) gör att en tjänst går förlorad.

I Azure-miljön använder Service Fabric feldomäninformation som tillhandahålls av miljön för att konfigurera noderna i klustret på rätt sätt åt dig. För fristående instanser Service Fabric definieras feldomäner vid den tidpunkt då klustret konfigureras.

I följande bild färgar vi alla entiteter som bidrar till feldomäner och visar en lista över alla olika feldomäner som resulterar i detta. I det här exemplet har vi datacenter ("DC"), rack ("R") och blad ("B"). Om varje blad innehåller mer än en virtuell dator kan det finnas ett annat lager i feldomänhierarkin.

Under körningen tar Service Fabric Klusterresurshanteraren hänsyn till feldomänerna i klustret och planers layouter. Tillståndslösa repliker eller tillståndslösa instanser för en tjänst distribueras så att de finns i separata feldomäner. Genom att distribuera tjänsten mellan feldomäner säkerställer du att tjänstens tillgänglighet inte komprometteras när en feldomän misslyckas på någon nivå i hierarkin.

Klusterresurshanteraren bryr sig inte om hur många lager det finns i feldomänhierarkin. Den försöker se till att förlust av någon del av hierarkin inte påverkar tjänster som körs i den.

Det är bäst om samma antal noder finns på varje djupnivå i feldomänhierarkin. Om "trädet" för feldomäner är obalanserat i klustret är det svårare för Klusterresurshanteraren att ta reda på den bästa allokeringen av tjänster. Obalanserade feldomänlayouter innebär att förlusten av vissa domäner påverkar tillgängligheten för tjänster mer än andra domäner. Därför är Klusterresurshanteraren två mål:

• De vill använda datorerna i den "tunga" domänen genom att placera tjänster på dem.
• De vill placera tjänster i andra domäner så att förlust av en domän inte orsakar problem.

Hur ser obalanserade domäner ut? Följande diagram visar två olika klusterlayouter. I det första exemplet fördelas noderna jämnt över feldomänerna. I det andra exemplet har en feldomän många fler noder än de andra feldomänerna.

I Azure hanteras valet av vilken feldomän som innehåller en nod åt dig. Men beroende på antalet noder som du etablerar kan du fortfarande få feldomäner som har fler noder i sig än i andra.

Säg till exempel att du har fem feldomäner i klustret men etablerar sju noder för en nodtyp (NodeType). I det här fallet får de två första feldomänerna fler noder. Om du fortsätter att distribuera fler NodeType-instanser med bara ett par instanser blir problemet värre. Därför rekommenderar vi att antalet noder i varje nodtyp är en multipel av antalet feldomäner.

Uppgradera domäner

Uppgraderingsdomäner är en annan funktion Service Fabric Klusterresurshanteraren att förstå klustrets layout. Uppgraderingsdomäner definierar uppsättningar noder som uppgraderas samtidigt. Uppgraderingsdomäner hjälper Klusterresurshanteraren att förstå och samordna hanteringsåtgärder som uppgraderingar.

Uppgraderingsdomäner liknar feldomäner, men med några viktiga skillnader. För det första definierar områden med koordinerade maskinvarufel feldomäner. Uppgraderingsdomäner definieras å andra sidan av en princip. Du får bestämma hur många du vill, i stället för att låta miljön styra talet. Du kan ha lika många uppgraderingsdomäner som noder. En annan skillnad mellan feldomäner och uppgraderingsdomäner är att uppgraderingsdomäner inte är hierarkiska. I stället är de mer som en enkel tagg.

I följande diagram visas tre uppgraderingsdomäner som är stripe-över tre feldomäner. Den visar också en möjlig placering för tre olika repliker av en tillståndsfull tjänst, där var och en hamnar i olika fel- och uppgraderingsdomäner. Den här placeringen gör att du kan förlora en feldomän mitt i en tjänstuppgradering och fortfarande ha en kopia av koden och data.

Det finns för- och nackdelar med att ha ett stort antal uppgraderingsdomäner. Fler uppgraderingsdomäner innebär att varje steg i uppgraderingen är mer detaljerad och påverkar ett mindre antal noder eller tjänster. Färre tjänster måste flyttas åt gången, vilket ger mindre omsättning i systemet. Detta tenderar att förbättra tillförlitligheten eftersom mindre av tjänsten påverkas av eventuella problem som uppstår under uppgraderingen. Fler uppgraderingsdomäner innebär också att du behöver mindre tillgänglig buffert på andra noder för att hantera effekten av uppgraderingen.

Om du till exempel har fem uppgraderingsdomäner hanterar noderna i var och en ungefär 20 procent av trafiken. Om du behöver ta ned uppgraderingsdomänen för en uppgradering måste den belastningen vanligtvis gå någonstans. Eftersom du har fyra återstående uppgraderingsdomäner måste var och en ha utrymme för cirka 25 procent av den totala trafiken. Fler uppgraderingsdomäner innebär att du behöver mindre buffert på noderna i klustret.

Överväg om du har 10 uppgraderingsdomäner i stället. I så fall skulle varje uppgraderingsdomän endast hantera cirka 10 procent av den totala trafiken. När en uppgradering går igenom klustret måste varje domän ha utrymme för endast cirka 11 procent av den totala trafiken. Fler uppgraderingsdomäner gör vanligtvis att du kan köra noder med högre användning eftersom du behöver mindre reserverad kapacitet. Samma sak gäller för feldomäner.

Nackdelen med att ha många uppgraderingsdomäner är att uppgraderingar tenderar att ta längre tid. Service Fabric en kort stund efter att en uppgraderingsdomän har slutförts och utför kontroller innan du börjar uppgradera nästa. Dessa fördröjningar gör det möjligt att identifiera problem som introduceras av uppgraderingen innan uppgraderingen fortsätter. Kompromissen är acceptabel eftersom den förhindrar att dåliga ändringar påverkar för mycket av tjänsten i taget.

Förekomsten av för få uppgraderingsdomäner har många negativa sidoeffekter. Varje uppgraderingsdomän är ur funktion och uppgraderas, men en stor del av den totala kapaciteten är inte tillgänglig. Om du till exempel bara har tre uppgraderingsdomäner tar du ned ungefär en tredjedel av din totala tjänst- eller klusterkapacitet i taget. Det är inte önskvärt att ha så mycket av din tjänst nere samtidigt eftersom du behöver tillräckligt med kapacitet i resten av klustret för att hantera arbetsbelastningen. Att underhålla bufferten innebär att noderna under normal drift är mindre inlästa än annars. Detta ökar kostnaden för att köra tjänsten.

Det finns ingen verklig gräns för det totala antalet fel- eller uppgraderingsdomäner i en miljö eller begränsningar för hur de överlappar. Men det finns vanliga mönster:

• Feldomäner och uppgraderingsdomäner mappade 1:1
• En uppgraderingsdomän per nod (fysisk eller virtuell OS-instans)
• En "stripe"- eller "matris"-modell där feldomänerna och uppgraderingsdomänerna bildar en matris med datorer som vanligtvis körs längs diagonalerna

Det finns inget bra svar på vilken layout du ska välja. Var och en har för- och nackdelar. Till exempel är 1FD:1UD-modellen enkel att konfigurera. Modellen för en uppgraderingsdomän per nodmodell är som de flesta är vana vid. Under uppgraderingar uppdateras varje nod oberoende av varandra. Detta liknar hur små uppsättningar datorer har uppgraderats manuellt tidigare.

Den vanligaste modellen är FD/UD-matrisen, där feldomäner och uppgraderingsdomäner bildar en tabell och noder placeras med början längs diagonalen. Det här är den modell som används som standard Service Fabric kluster i Azure. För kluster med många noder ser allt ut som ett kompakt matrismönster.

Fel- och uppgraderingsdomänbegränsningar och resulterande beteende

Standardinställning

Som standard ser Klusterresurshanteraren tjänster balanserade över fel- och uppgraderingsdomäner. Detta modelleras som en begränsning. Begränsningen för fel- och uppgraderingsdomäntillstånd: "För en viss tjänstpartition bör det aldrig finnas någon skillnad större än en i antalet tjänstobjekt (tillståndslösa tjänstinstanser eller tillståndslösa tjänstrepliker) mellan två domäner på samma hierarkinivå."

Anta att den här begränsningen ger en "maximal skillnad"-garanti. Begränsningen för fel- och uppgraderingsdomäner förhindrar vissa förflyttningar eller arrangemang som strider mot regeln.

Anta till exempel att vi har ett kluster med sex noder, konfigurerade med fem feldomäner och fem uppgraderingsdomäner.

Anta nu att vi skapar en tjänst med värdet TargetReplicaSetSize (eller fem för en tillståndslös tjänst, InstanceCount). Replikerna hamnar på N1–N5. I själva verket används aldrig N6 oavsett hur många tjänster som du skapar. Men varför? Nu ska vi titta på skillnaden mellan den aktuella layouten och vad som skulle hända om N6 väljs.

Här är layouten vi har och det totala antalet repliker per fel- och uppgraderingsdomän:

Den här layouten balanseras när det gäller noder per feldomän och uppgraderingsdomän. Det är också balanserat vad gäller antalet repliker per feldomän och uppgraderingsdomän. Varje domän har samma antal noder och samma antal repliker.

Nu ska vi titta på vad som skulle hända om vi hade använt N6 i stället för N2. Hur skulle replikerna distribueras då?

Den här layouten bryter mot vår definition av "maximal skillnad" för begränsningen av feldomänen. FD0 har två repliker, medan FD1 har noll. Skillnaden mellan FD0 och FD1 är totalt två, vilket är större än den maximala skillnaden för en. Eftersom begränsningen överträds, Klusterresurshanteraren inte det här arrangemanget.

På samma sätt skulle vi få följande om vi valde N2 och N6 (i stället för N1 och N2):

Den här layouten är balanserad när det gäller feldomäner. Men nu bryter den mot begränsningen för uppgraderingsdomänen eftersom UD0 har noll repliker och UD1 har två. Den här layouten är också ogiltig och kommer inte att väljas av Klusterresurshanteraren.

Den här metoden för distribution av tillståndsfulla repliker eller tillståndslösa instanser ger bästa möjliga feltolerans. Om en domän går ned går det minimala antalet repliker/instanser förlorade.

Å andra sidan kan den här metoden vara för strikt och inte tillåta att klustret använder alla resurser. Vissa noder kan inte användas för vissa klusterkonfigurationer. Detta kan göra Service Fabric inte placerar dina tjänster, vilket resulterar i varningsmeddelanden. I föregående exempel kan vissa klusternoder inte användas (N6 i exemplet). Även om du har lagt till noder i klustret (N7-N10), placeras repliker/instanser endast på N1–N5 på grund av begränsningar i fel- och uppgraderingsdomäner.

Alternativ metod

Klusterresurshanteraren en annan version av begränsningen för fel- och uppgraderingsdomäner. Den tillåter placering samtidigt som den garanterar en lägsta säkerhetsnivå. Den alternativa begränsningen kan anges på följande sätt: "För en viss tjänstpartition bör replikdistributionen mellan domäner säkerställa att partitionen inte drabbas av en kvorumförlust." Anta att den här begränsningen ger en "kvorumsäker" garanti.

Vi går tillbaka till föregående exempel. Med den "kvorumsäkra" versionen av begränsningen skulle alla tre layouterna vara giltiga. Även om FD0 misslyckades i den andra layouten eller UD1 misslyckades i den tredje layouten, skulle partitionen fortfarande ha kvorum. (En majoritet av replikerna skulle fortfarande vara upp.) Med den här versionen av begränsningen kan N6 nästan alltid användas.

Metoden "kvorumsäker" ger mer flexibilitet än metoden "maximal skillnad". Anledningen är att det är enklare att hitta replikdistributioner som är giltiga i nästan vilken klustertopologi som helst. Den här metoden kan dock inte garantera de bästa feltoleransegenskaperna eftersom vissa fel är sämre än andra.

I värsta fall kan en majoritet av replikerna gå förlorade på grund av ett fel i en domän och en ytterligare replik. I stället för tre fel som krävs för att förlora kvorum med fem repliker eller instanser kan du nu förlora en majoritet med bara två fel.

Anpassningsbar metod

Eftersom båda metoderna har styrkor och svagheter har vi infört en anpassningsbar metod som kombinerar dessa två strategier.

Vi går tillbaka till föregående exempel och antar att ett kluster nu har åtta noder. Klustret är fortfarande konfigurerat med fem feldomäner och fem uppgraderingsdomäner, och targetReplicaSetSize-värdet för en tjänst som finns i det klustret förblir fem.

Eftersom alla nödvändiga villkor uppfylls använder Klusterresurshanteraren "kvorumbaserad" logik för att distribuera tjänsten. Detta möjliggör användning av N6-N8. En möjlig tjänstdistribution i det här fallet kan se ut så här:

Om tjänstens TargetReplicaSetSize-värde minskas till fyra (till exempel) Klusterresurshanteraren märker den ändringen. Den återupptas med hjälp av logiken "maximal skillnad" eftersom TargetReplicaSetSize inte längre kan delas upp av antalet feldomäner och uppgraderingsdomäner. Därför sker vissa replikförflyttningar för att distribuera de återstående fyra replikerna på noderna N1-N5. På så sätt överträds inte den "högsta skillnaden" versionen av feldomänen och uppgraderingsdomänlogiken.

Om värdet TargetReplicaSetSize är fem och N1 tas bort från klustret i den föregående layouten blir antalet uppgraderingsdomäner lika med fyra. Återigen Klusterresurshanteraren börjar använda logik för "maximal skillnad" eftersom antalet uppgraderingsdomäner inte delar upp tjänstens TargetReplicaSetSize-värde jämnt längre. Därför måste repliken R1, när den skapats igen, landa på N4 så att begränsningen för felet och uppgraderingsdomänen inte överträds.

Konfigurera fel- och uppgraderingsdomäner

I Azure-värdbaserade Service Fabric definieras feldomäner och uppgraderingsdomäner automatiskt. Service Fabric hämtar upp och använder miljöinformationen från Azure.

Om du skapar ett eget kluster (eller vill köra en viss topologi under utveckling) kan du ange feldomänen och uppgradera domäninformation själv. I det här exemplet definierar vi ett lokalt utvecklingskluster med nio noder som omfattar tre datacenter (vart och ett med tre rack). Det här klustret har också tre uppgraderingsdomäner som är stripe-över dessa tre datacenter. Här är ett exempel på konfigurationen i ClusterManifest.xml:

  <Infrastructure>
    <!-- IsScaleMin indicates that this cluster runs on one box/one single server -->
    <WindowsServer IsScaleMin="true">
      <NodeList>
        <Node NodeName="Node01" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType01" FaultDomain="fd:/DC01/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node02" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType02" FaultDomain="fd:/DC01/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node03" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType03" FaultDomain="fd:/DC01/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
        <Node NodeName="Node04" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType04" FaultDomain="fd:/DC02/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node05" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType05" FaultDomain="fd:/DC02/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node06" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType06" FaultDomain="fd:/DC02/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
        <Node NodeName="Node07" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType07" FaultDomain="fd:/DC03/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node08" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType08" FaultDomain="fd:/DC03/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node09" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType09" FaultDomain="fd:/DC03/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
      </NodeList>
    </WindowsServer>
  </Infrastructure>

I det här ClusterConfig.jspå för fristående distributioner:

"nodes": [
  {
    "nodeName": "vm1",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm2",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm3",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD3"
  },
  {
    "nodeName": "vm4",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm5",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm6",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD3"
  },
  {
    "nodeName": "vm7",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm8",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm9",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD3"
  }
],

Nodegenskaper och placeringsbegränsningar

Ibland (i de flesta fall) vill du se till att vissa arbetsbelastningar endast körs på vissa typer av noder i klustret. Vissa arbetsbelastningar kan till exempel kräva GPU:er eller SD:er, och andra kanske inte gör det.

Ett bra exempel på att rikta maskinvara mot specifika arbetsbelastningar är nästan alla n-nivåarkitekturer. Vissa datorer fungerar som klientsidan eller API-betjänande sidan av programmet och exponeras för klienterna eller Internet. Olika datorer, ofta med olika maskinvaruresurser, hanterar beräknings- eller lagringslagers arbete. Dessa exponeras vanligtvis inte direkt för klienter eller Internet.

Service Fabric förväntar sig att vissa arbetsbelastningar i vissa fall kan behöva köras på vissa maskinvarukonfigurationer. Exempel:

• Ett befintligt n-nivåprogram har "lyfts och flyttats" till en Service Fabric miljö.
• En arbetsbelastning måste köras på specifik maskinvara av prestanda-, skalnings- eller säkerhetsisoleringsskäl.
• En arbetsbelastning bör isoleras från andra arbetsbelastningar av princip- eller resursförbrukningsskäl.

För att stödja den här typen av konfigurationer Service Fabric du taggar som du kan använda för noder. De här taggarna kallas nodegenskaper. Placeringsbegränsningar är de instruktioner som är kopplade till enskilda tjänster som du väljer för en eller flera nodegenskaper. Placeringsbegränsningar definierar var tjänsterna ska köras. Uppsättningen begränsningar är utökningsbar. Alla nyckel/värde-par kan fungera. Från och Service Fabric 8.1 kan nodegenskaper uppdateras dynamiskt utan avbrott i arbetsbelastningar som körs.

Inbyggda nodegenskaper

Service Fabric definierar vissa standardnodegenskaper som kan användas automatiskt så att du inte behöver definiera dem. Standardegenskaperna som definieras vid varje nod är NodeType och NodeName.

Du kan till exempel skriva en placeringsbegränsning som "(NodeType == NodeType03)" . NodeType är en egenskap som används ofta. Det är användbart eftersom det motsvarar 1:1 med en typ av dator. Varje typ av dator motsvarar en typ av arbetsbelastning i ett traditionellt n-nivåprogram.

Placeringsbegränsningar och syntax för nodegenskap

Värdet som anges i nodegenskapen kan vara en sträng, boolesk eller signerad lång. Instruktionen i tjänsten kallas för en placeringsbegränsning eftersom den begränsar var tjänsten kan köras i klustret. Begränsningen kan vara en boolesk instruktion som fungerar på nodegenskaperna i klustret. Giltiga väljare i dessa booleska instruktioner är:

• Villkorsstyrda kontroller för att skapa särskilda instruktioner:

  Uttryck	Syntax
  "lika med"	"=="
  "inte lika med"	"!="
  "större än"	">"
  "större än eller lika med"	">="
  "mindre än"	"<"
  "mindre än eller lika med"	"<="

• Booleska instruktioner för gruppering och logiska åtgärder:

  Uttryck	Syntax
  "and"	"&&"
  "or"	"||"
  "inte"	"!"
  "gruppera som enskild instruktion"	"()"

Här följer några exempel på grundläggande begränsningssatser:

• "Value >= 5"
• "NodeColor != green"
• "((OneProperty < 100) || ((AnotherProperty == false) && (OneProperty >= 100)))"

Endast noder där den övergripande placeringsbegränsningssatsen utvärderas till "True" kan ha tjänsten placerad på den. Noder som inte har en definierad egenskap matchar inte någon placeringsbegränsning som innehåller egenskapen .

Anta att följande nodegenskaper har definierats för en nodtyp i ClusterManifest.xml:

    <NodeType Name="NodeType01">
      <PlacementProperties>
        <Property Name="HasSSD" Value="true"/>
        <Property Name="NodeColor" Value="green"/>
        <Property Name="SomeProperty" Value="5"/>
      </PlacementProperties>
    </NodeType>

I följande exempel visas nodegenskaper som definierats via ClusterConfig.jspå för fristående distributioner eller Template.jspå för Azure-värdbaserade kluster.

"nodeTypes": [
    {
        "name": "NodeType01",
        "placementProperties": {
            "HasSSD": "true",
            "NodeColor": "green",
            "SomeProperty": "5"
        },
    }
],

Du kan skapa begränsningar för tjänstplacering för en tjänst på följande sätt:

FabricClient fabricClient = new FabricClient();
StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
serviceDescription.PlacementConstraints = "(HasSSD == true && SomeProperty >= 4)";
// Add other required ServiceDescription fields
//...
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceType -Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementConstraint "HasSSD == true && SomeProperty >= 4"

Om alla noder i NodeType01 är giltiga kan du också välja den nodtypen med begränsningen "(NodeType == NodeType01)" .

Placeringsbegränsningar för en tjänst kan uppdateras dynamiskt under körning. Om du behöver kan du flytta runt en tjänst i klustret, lägga till och ta bort krav och så vidare. Service Fabric ser till att tjänsten förblir tillgänglig även när dessa typer av ändringar görs.

StatefulServiceUpdateDescription updateDescription = new StatefulServiceUpdateDescription();
updateDescription.PlacementConstraints = "NodeType == NodeType01";
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

Update-ServiceFabricService -Stateful -ServiceName $serviceName -PlacementConstraints "NodeType == NodeType01"

Placeringsbegränsningar anges för varje namngiven tjänstinstans. Uppdateringar tar alltid i stället för (skriver över) det som angavs tidigare.

Klusterdefinitionen definierar egenskaperna på en nod. Om du vill ändra en nods egenskaper måste klusterkonfigurationen uppgraderas. Uppgradering av en nods egenskaper kräver att varje berörd nod startas om för att rapportera sina nya egenskaper. Service Fabric hanterar dessa löpande uppgraderingar.

Beskriva och hantera klusterresurser

Ett av de viktigaste jobben i en orkestrerare är att hjälpa till att hantera resursförbrukningen i klustret. Hantering av klusterresurser kan innebära några olika saker.

Först ser du till att datorerna inte överbelastas. Det innebär att se till att datorer inte kör fler tjänster än de kan hantera.

För det andra finns det balansering och optimering, vilket är viktigt för att köra tjänster effektivt. Kostnadseffektiva eller prestandakänsliga tjänsterbjudanden kan inte tillåta att vissa noder är heta medan andra är kalla. Heta noder leder till resursförseningar och dåliga prestanda. Kalla noder representerar slöseri med resurser och ökade kostnader.

Service Fabric representerar resurser som mått. Mått är en logisk eller fysisk resurs som du vill beskriva för att Service Fabric. Exempel på mått är "WorkQueueDepth" eller "MemoryInMb". Information om de fysiska resurser som Service Fabric kan styra på noder finns i Resursstyrning. Information om de standardmått som används av Klusterresurshanteraren och hur du konfigurerar anpassade mått finns i den här artikeln.

Mått skiljer sig från placeringsbegränsningar och nodegenskaper. Nodegenskaper är statiska beskrivningar av själva noderna. Mått beskriver resurser som noder har och som tjänster använder när de körs på en nod. En nodegenskap kan vara HasSSD och kan vara inställd på sant eller falskt. Mängden tillgängligt utrymme på SSD:n och hur mycket som förbrukas av tjänster skulle vara ett mått som "DriveSpaceInMb".

Precis som för placeringsbegränsningar och nodegenskaper förstår Service Fabric Klusterresurshanteraren inte vad namnen på måtten innebär. Måttnamn är bara strängar. Det är en bra idé att deklarera enheter som en del av de måttnamn som du skapar när de kan vara tvetydiga.

Kapacitet

Om du inaktiverade all resursbalansering Service Fabric Klusterresurshanteraren fortfarande se till att ingen nod går över dess kapacitet. Det går att hantera kapacitetsöverskridningar om inte klustret är för fullt eller om arbetsbelastningen är större än någon nod. Kapacitet är en annan begränsning som Klusterresurshanteraren använder för att förstå hur mycket av en resurs en nod har. Återstående kapacitet spåras också för klustret som helhet. Från och Service Fabric 8.1 kan nodkapacitet uppdateras dynamiskt utan avbrott i arbetsbelastningar som körs.

Både kapaciteten och förbrukningen på tjänstnivå uttrycks i mått. Måttet kan till exempel vara "ClientConnections" och en nod kan ha en kapacitet för "ClientConnections" på 32 768. Andra noder kan ha andra gränser. En tjänst som körs på noden kan säga att den för närvarande förbrukar 32 256 av måttet "ClientConnections".

Under körningen spårar Klusterresurshanteraren återstående kapacitet i klustret och på noderna. För att spåra Klusterresurshanteraren subtraherar användningen av varje tjänst från en nods kapacitet där tjänsten körs. Med den här Klusterresurshanteraren du ta reda på var repliker ska placera ut eller flytta så att noderna inte går över kapaciteten.

StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
ServiceLoadMetricDescription metric = new ServiceLoadMetricDescription();
metric.Name = "ClientConnections";
metric.PrimaryDefaultLoad = 1024;
metric.SecondaryDefaultLoad = 0;
metric.Weight = ServiceLoadMetricWeight.High;
serviceDescription.Metrics.Add(metric);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ClientConnections,High,1024,0)

Du kan se de kapaciteter som definierats i klustermanifestet. Här är ett exempel på ClusterManifest.xml:

    <NodeType Name="NodeType03">
      <Capacities>
        <Capacity Name="ClientConnections" Value="65536"/>
      </Capacities>
    </NodeType>

Här är ett exempel på kapaciteter som definierats via ClusterConfig.jspå för fristående distributioner eller Template.jspå för Azure-värdbaserade kluster:

"nodeTypes": [
    {
        "name": "NodeType03",
        "capacities": {
            "ClientConnections": "65536",
        }
    }
],

En tjänsts belastning ändras ofta dynamiskt. Säg att en repliks belastning på "ClientConnections" ändrades från 1 024 till 2 048. Noden som den kördes på hade sedan en kapacitet på endast 512 kvar för det måttet. Nu är replikens eller instansens placering ogiltig eftersom det inte finns tillräckligt med utrymme på noden. Klusterresurshanteraren måste hämta noden under kapaciteten igen. Det minskar belastningen på noden som är över kapacitet genom att flytta en eller flera repliker eller instanser från noden till andra noder.

Klusterresurshanteraren försöker minimera kostnaden för att flytta repliker. Du kan lära dig mer om rörelsekostnader och om ombalanseringsstrategier och regler.

Klusterkapacitet

Hur ser Service Fabric Klusterresurshanteraren hela klustret från att vara för fullt? Med dynamisk belastning kan den inte göra så mycket. Tjänster kan ha en topp i belastningen oberoende av åtgärder som Klusterresurshanteraren vidtar. Därför kan ditt kluster med mycket utrymme i dag vara underpowered om det blir en topp i morgon.

Kontroller i Klusterresurshanteraren att förhindra problem. Det första du kan göra är att förhindra att nya arbetsbelastningar skapas som gör att klustret blir fullt.

Anta att du skapar en tillståndslös tjänst och att den har en viss belastning kopplad till den. Tjänsten bryr sig om måttet "DiskSpaceInMb". Tjänsten förbrukar fem enheter av "DiskSpaceInMb" för varje instans av tjänsten. Du vill skapa tre instanser av tjänsten. Det innebär att du behöver 15 enheter av "DiskSpaceInMb" som ska finnas i klustret för att du även ska kunna skapa dessa tjänstinstanser.

Klusterresurshanteraren beräknar kontinuerligt kapaciteten och förbrukningen för varje mått så att den kan fastställa återstående kapacitet i klustret. Om det inte finns tillräckligt med utrymme Klusterresurshanteraren av anropet för att skapa en tjänst.

Eftersom kravet bara är att 15 enheter ska vara tillgängliga kan du allokera det här utrymmet på många olika sätt. Det kan till exempel finnas en återstående kapacitetsenhet på 15 olika noder eller tre återstående kapacitetsenheter på fem olika noder. Om Klusterresurshanteraren kan ordna om saker så att det finns fem enheter tillgängliga på tre noder placeras tjänsten. Det går vanligtvis att ordna om klustret såvida inte klustret är nästan fullt eller om de befintliga tjänsterna inte kan konsolideras av någon anledning.

Nodbuffert och överbokingskapacitet

Om en nodkapacitet för ett mått anges kommer Klusterresurshanteraren aldrig att placera eller flytta repliker till en nod om den totala belastningen skulle gå över den angivna nodkapaciteten. Detta kan ibland förhindra placering av nya repliker eller ersätta misslyckade repliker om klustret är nära full kapacitet och en replik med stor belastning måste placeras, ersättas eller flyttas.

För att ge mer flexibilitet kan du ange antingen nodbuffert eller överbokingskapacitet. När nodbufferten eller överbokingskapaciteten har angetts för ett mått försöker Klusterresurshanteraren placera eller flytta repliker på ett sådant sätt att buffert- eller överbokingskapaciteten förblir oanvänd, men tillåter att buffert- eller överbokingskapaciteten används vid behov för åtgärder som ökar tjänstens tillgänglighet, till exempel:

• Ny replikplacering eller ersätta misslyckade repliker
• Placering under uppgraderingar
• Åtgärda mjuka och hårda begränsningsöverträdelser
• Defragmentering

Nodbuffertkapacitet representerar en reserverad del av kapaciteten under angiven nodkapacitet och överbokingskapacitet representerar en del av extra kapacitet över angiven nodkapacitet. I båda fallen försöker Klusterresurshanteraren att hålla den här kapaciteten kostnadsfri.

Om en nod till exempel har en angiven kapacitet för måttet CpuUtilization på 100 och nodbuffertprocenten för det måttet är inställt på 20 %, blir total och obuffrad kapacitet 100 respektive 80, och Klusterresurshanteraren placerar inte mer än 80 enheter av belastning på noden under normala omständigheter.

Nodbufferten ska användas när du vill reservera en del av nodkapaciteten som endast ska användas för åtgärder som ökar tjänstens tillgänglighet som nämns ovan.

Å andra sidan gäller att om procentandelen för överboking av noder används och anges till 20 % blir total och obufferterad kapacitet 120 respektive 100.

Överbokningskapacitet ska användas när du vill tillåta Klusterresurshanteraren att placera repliker på en nod även om den totala resursanvändningen skulle överskrida kapaciteten. Detta kan användas för att ge ytterligare tillgänglighet för tjänster på bekostnad av prestanda. Om överboking används måste användarprogramlogiken kunna fungera med färre fysiska resurser än den kan kräva.

Om nodbufferten eller överbokingskapaciteten anges flyttas Klusterresurshanteraren inte eller placerar repliker om den totala belastningen på målnoden skulle gå över total kapacitet (nodkapacitet vid nodbuffert och nodkapacitet + överbokingskapacitet vid överbokning).

Överbokingskapacitet kan också anges som oändlig. I det här Klusterresurshanteraren försöker behålla den totala belastningen på noden under den angivna nodkapaciteten, men kan potentiellt placera en mycket större belastning på noden, vilket kan leda till allvarlig prestandaförsämring.

Ett mått kan inte ha både nodbuffert och överbokingskapacitet angivna samtidigt.

Här är ett exempel på hur du anger nodbuffert eller överbokingskapacitet i ClusterManifest.xml:

<Section Name="NodeBufferPercentage">
    <Parameter Name="SomeMetric" Value="0.15" />
</Section>
<Section Name="NodeOverbookingPercentage">
    <Parameter Name="SomeOtherMetric" Value="0.2" />
    <Parameter Name=”MetricWithInfiniteOverbooking” Value=”-1.0” />
</Section>

Här är ett exempel på hur du anger nodbuffert eller överbokingskapacitet via ClusterConfig.jspå för fristående distributioner ellerTemplate.jspå för Azure-värdbaserade kluster:

"fabricSettings": [
  {
    "name": "NodeBufferPercentage",
    "parameters": [
      {
          "name": "SomeMetric",
          "value": "0.15"
      }
    ]
  },
  {
    "name": "NodeOverbookingPercentage",
    "parameters": [
      {
          "name": "SomeOtherMetric",
          "value": "0.20"
      },
      {
          "name": "MetricWithInfiniteOverbooking",
          "value": "-1.0"
      }
    ]
  }
]

Nästa steg

• Information om arkitekturen och informationsflödet i Klusterresurshanteraren finns i Klusterresurshanteraren översikt över arkitektur.
• Att definiera defragmenteringsmått är ett sätt att konsolidera belastningen på noder i stället för att sprida ut den. Information om hur du konfigurerar defragmentering finns i Defragmenteringav mått och inläsning i Service Fabric .
• Börja från början och få en introduktion till Service Fabric Klusterresurshanteraren.
• Information om hur Klusterresurshanteraren hanterar och balanserar belastningen i klustret finns i Balansera Service Fabric kluster.