Placeringsprinciper för Service Fabric-tjänster

Placeringsprinciper är ytterligare regler som kan användas för att styra tjänstplacering i vissa specifika, mindre vanliga scenarier. Några exempel på dessa scenarier är:

• Service Fabric-klustret sträcker sig över geografiska avstånd, till exempel flera lokala datacenter eller mellan Azure-regioner
• Din miljö omfattar flera områden med geopolitisk eller juridisk kontroll, eller något annat fall där du har principgränser som du behöver tillämpa
• Det finns kommunikationsprestanda- eller svarstidsöverväganden på grund av stora avstånd eller användning av långsammare eller mindre tillförlitliga nätverkslänkar
• Du måste hålla vissa arbetsbelastningar samlade som ett bästa arbete, antingen med andra arbetsbelastningar eller i närheten av kunder
• Du behöver flera tillståndslösa instanser av en partition på en enda nod

De flesta av dessa krav överensstämmer med klustrets fysiska layout, som representeras av klustrets feldomäner.

De avancerade placeringsprinciperna som hjälper dig att hantera dessa scenarier är:

1. Ogiltiga domäner
2. Obligatoriska domäner
3. Prioriterade domäner
4. Tillåter inte replikpackning
5. Tillåt flera tillståndslösa instanser på noden

De flesta av följande kontroller kan konfigureras via nodegenskaper och placeringsbegränsningar, men vissa är mer komplicerade. För att göra det enklare tillhandahåller Service Fabric-klustret Resource Manager dessa ytterligare placeringsprinciper. Placeringsprinciper konfigureras per namngiven tjänstinstans. De kan också uppdateras dynamiskt.

Ange ogiltiga domäner

Med placeringsprincipen InvalidDomain kan du ange att en viss feldomän är ogiltig för en viss tjänst. Den här principen säkerställer att en viss tjänst aldrig körs inom ett visst område, till exempel av geopolitiska eller företagspolitiska skäl. Flera ogiltiga domäner kan anges via separata principer.

Kod:

ServicePlacementInvalidDomainPolicyDescription invalidDomain = new ServicePlacementInvalidDomainPolicyDescription();
invalidDomain.DomainName = "fd:/DCEast"; //regulations prohibit this workload here
serviceDescription.PlacementPolicies.Add(invalidDomain);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("InvalidDomain,fd:/DCEast”)

Ange nödvändiga domäner

Den obligatoriska principen för domänplacering kräver att tjänsten endast finns i den angivna domänen. Flera obligatoriska domäner kan anges via separata principer.

Kod:

ServicePlacementRequiredDomainPolicyDescription requiredDomain = new ServicePlacementRequiredDomainPolicyDescription();
requiredDomain.DomainName = "fd:/DC01/RK03/BL2";
serviceDescription.PlacementPolicies.Add(requiredDomain);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("RequiredDomain,fd:/DC01/RK03/BL2")

Ange en önskad domän för de primära replikerna av en tillståndskänslig tjänst

Den primära primära domänen anger feldomänen som den primära ska placeras i. Den primära hamnar i den här domänen när allt är felfritt. Om domänen eller den primära repliken misslyckas eller stängs av flyttas den primära till någon annan plats, helst i samma domän. Om den här nya platsen inte finns i önskad domän flyttar kluster Resource Manager tillbaka den till önskad domän så snart som möjligt. Naturligtvis är den här inställningen bara lämplig för tillståndskänsliga tjänster. Den här principen är mest användbar i kluster som sträcker sig över Azure-regioner eller flera datacenter, men som har tjänster som föredrar placering på en viss plats. Att hålla primärvården nära sina användare eller andra tjänster ger kortare svarstider, särskilt för läsningar, som hanteras av primärenheter som standard.

ServicePlacementPreferPrimaryDomainPolicyDescription primaryDomain = new ServicePlacementPreferPrimaryDomainPolicyDescription();
primaryDomain.DomainName = "fd:/EastUS/";
serviceDescription.PlacementPolicies.Add(primaryDomain);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("PreferredPrimaryDomain,fd:/EastUS")

Krav på replikdistribution och otillåten förpackning

Repliker distribueras normalt över fel- och uppgraderingsdomäner när klustret är felfritt. Det finns dock fall där mer än en replik för en viss partition tillfälligt kan packas i en enda domän. Anta till exempel att klustret har nio noder i tre feldomäner, fd:/0, fd:/1 och fd:/2. Anta också att tjänsten har tre repliker. Anta att noderna som användes för dessa repliker i fd:/1 och fd:/2 gick ned. Vanligtvis föredrar kluster Resource Manager andra noder i samma feldomäner. I det här fallet kan vi säga att på grund av kapacitetsproblem var ingen av de andra noderna i dessa domäner giltiga. Om klustret Resource Manager skapar ersättningar för dessa repliker måste det välja noder i fd:/0. Om du gör det skapas dock en situation där begränsningen för feldomänen överträds. Om du packar repliker ökar risken för att hela replikuppsättningen kan gå förlorad eller gå förlorad.

Anteckning

Mer information om begränsningar och villkorsprioriteringar finns i det här avsnittet.

Om du någonsin har sett ett hälsomeddelande som "The Load Balancer has detected a Constraint Violation for this Replica:fabric:/<some service name> Secondary Partition <some partition ID> is violating the Constraint: FaultDomain" har du nått det här villkoret eller något liknande. Vanligtvis packas bara en eller två repliker ihop tillfälligt. Så länge det finns färre än ett kvorum med repliker i en viss domän är du säker. Packning är sällsynt, men det kan hända, och vanligtvis är dessa situationer tillfälliga eftersom noderna kommer tillbaka. Om noderna ligger nere och klustret Resource Manager behöver skapa ersättningar, finns det vanligtvis andra noder tillgängliga i de idealiska feldomänerna.

Vissa arbetsbelastningar föredrar att alltid ha målantalet repliker, även om de är packade i färre domäner. Dessa arbetsbelastningar satsar på totalt antal samtidiga permanenta domänfel och kan vanligtvis återställa lokalt tillstånd. Andra arbetsbelastningar tar hellre driftstopp tidigare än risk för korrekthet eller dataförlust. De flesta produktionsarbetsbelastningar körs med fler än tre repliker, fler än tre feldomäner och många giltiga noder per feldomän. Därför tillåter standardbeteendet domänpackning som standard. Standardbeteendet tillåter normal utjämning och redundans för att hantera dessa extrema fall, även om det innebär tillfällig domänpackning.

Om du vill inaktivera sådan packning för en viss arbetsbelastning kan du ange RequireDomainDistribution principen för tjänsten. När den här principen har angetts ser kluster Resource Manager till att inga två repliker från samma partition körs i samma fel- eller uppgraderingsdomän.

Kod:

ServicePlacementRequireDomainDistributionPolicyDescription distributeDomain = new ServicePlacementRequireDomainDistributionPolicyDescription();
serviceDescription.PlacementPolicies.Add(distributeDomain);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("RequiredDomainDistribution")

Skulle det nu vara möjligt att använda dessa konfigurationer för tjänster i ett kluster som inte var geografiskt utspädd? Det kan du, men det finns ingen stor anledning också. Nödvändiga, ogiltiga och önskade domänkonfigurationer bör undvikas om inte scenarierna kräver dem. Det är inte meningsfullt att försöka tvinga en viss arbetsbelastning att köras i ett enda rack, eller att föredra något segment av det lokala klustret framför ett annat. Olika maskinvarukonfigurationer bör spridas över feldomäner och hanteras via normala placeringsbegränsningar och nodegenskaper.

Placering av flera tillståndslösa instanser av en partition på en enda nod

Placeringsprincipen AllowMultipleStatelessInstancesOnNode tillåter placering av flera tillståndslösa instanser av en partition på en enda nod. Som standard kan flera instanser av en enda partition inte placeras på en nod. Även med en -1-tjänst går det inte att skala antalet instanser utöver antalet noder i klustret för en viss namngiven tjänst. Den här placeringsprincipen tar bort den här begränsningen och tillåter att InstanceCount anges högre än antalet noder.

Om du någonsin har sett ett hälsomeddelande som "The Load Balancer has detected a Constraint Violation for this Replica:fabric:/<some service name> Secondary Partition <some partition ID> is violating the Constraint: ReplicaExclusion" har du nått det här villkoret eller något liknande.

Om du vill välja att tillämpa den här placeringsprincipen på din tjänst aktiverar du följande konfigurationer:

<Section Name="Common">
  <Parameter Name="AllowCreateUpdateMultiInstancePerNodeServices" Value="True" />
  <Parameter Name="HostReuseModeForExclusiveStateless" Value="1" />
</Section>

Genom att AllowMultipleStatelessInstancesOnNode ange principen för tjänsten kan InstanceCount anges utöver antalet noder i klustret.

Kod:

ServicePlacementAllowMultipleStatelessInstancesOnNodePolicyDescription allowMultipleInstances = new ServicePlacementAllowMultipleStatelessInstancesOnNodePolicyDescription();
serviceDescription.PlacementPolicies.Add(allowMultipleInstances);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless –PartitionSchemeSingleton –PlacementPolicy @(“AllowMultipleStatelessInstancesOnNode”) -InstanceCount 10 -ServicePackageActivationMode ExclusiveProcess 

Anteckning

För närvarande stöds principen endast för tillståndslösa tjänster med exclusiveprocess-tjänstpaketets aktiveringsläge.

Varning

Principen stöds inte när den används med statiska portslutpunkter. Att använda båda tillsammans kan leda till ett kluster med feltillstånd eftersom flera instanser på samma nod försöker binda till samma port och inte kan komma upp.

Anteckning

Om du använder ett högt värde för MinInstanceCount med den här placeringsprincipen kan det leda till fastnade programuppgraderingar. Om du till exempel har ett kluster med fem noder och anger InstanceCount=10 har du två instanser på varje nod. Om du anger MinInstanceCount=9 kan ett försök till appuppgradering fastna. med MinInstanceCount=8 kan du undvika detta.

Nästa steg

• Mer information om hur du konfigurerar tjänster finns i Mer information om hur du konfigurerar tjänster