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 sorterade 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 som klustrets feldomäner.

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

1. Ogiltiga domäner
2. Obligatoriska domäner
3. Prioriterade domäner
4. Tillåt inte replikförpackning
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 Cluster 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 domänplaceringsprincipen 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 primärdomänen 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 den önskade domänen flyttar Klusterresurshanteraren tillbaka den till önskad domän så snart som möjligt. Naturligtvis är den här inställningen endast 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. Genom att hålla primärvalen nära sina användare eller andra tjänster får du 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 packning

Repliker distribueras normalt över fel- och uppgraderingsdomäner när klustret är felfritt. Det finns dock fall där fler än en replik för en viss partition tillfälligt kan packas till 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. Normalt föredrar Klusterresurshanteraren andra noder i samma feldomäner. I det här fallet ska vi säga att på grund av kapacitetsproblem var ingen av de andra noderna i dessa domäner giltiga. Om Klusterresurshanteraren skapar ersättningar för dessa repliker måste den 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å ned eller gå förlorad.

Kommentar

Mer information om begränsningar och begränsningsprioriteringar 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", så 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. Förpackning är sällsynt, men det kan hända, och vanligtvis är dessa situationer tillfälliga eftersom noderna kommer tillbaka. Om noderna håller sig nere och Klusterresurshanteraren 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 mot totala samtidiga permanenta domänfel och kan vanligtvis återställa lokalt tillstånd. Andra arbetsbelastningar tar hellre stilleståndstiden 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. På grund av detta tillåter standardbeteendet domänpackning som standard. Standardbeteendet tillåter normal balansering och redundans för att hantera dessa extrema fall, även om det innebär tillfällig domänförpackning.

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 Klusterresurshanteraren 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ädt? 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 enskild 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", så 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 

Kommentar

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.

Kommentar

Om du använder ett högt värde för MinInstanceCount med den här placeringsprincipen kan det leda till att programuppgraderingar fastnar. 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 detta undvikas.

Nästa steg

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