Plaatsingsbeleid voor Service Fabric-services

  • Artikel

Plaatsingsbeleid zijn aanvullende regels die kunnen worden gebruikt voor het beheren van serviceplaatsing in enkele specifieke, minder algemene scenario's. Enkele voorbeelden van deze scenario's zijn:

  • Uw Service Fabric-cluster overspant geografische afstanden, zoals meerdere on-premises datacenters of tussen Azure-regio's
  • Uw omgeving omvat meerdere gebieden van geopolitieke of juridische controle, of een ander geval waarin u beleidsgrenzen moet afdwingen
  • Er zijn overwegingen voor communicatieprestaties of latentie vanwege grote afstanden of het gebruik van tragere of minder betrouwbare netwerkkoppelingen
  • U moet bepaalde werkbelastingen zo goed mogelijk op dezelfde locatie houden, hetzij met andere workloads of in de buurt van klanten
  • U hebt meerdere staatloze exemplaren van een partitie op één knooppunt nodig

De meeste van deze vereisten zijn afgestemd op de fysieke indeling van het cluster, weergegeven als de foutdomeinen van het cluster.

Het geavanceerde plaatsingsbeleid waarmee deze scenario's kunnen worden aangepakt, zijn:

  1. Ongeldige domeinen
  2. Vereiste domeinen
  3. Voorkeursdomeinen
  4. Toewijzing van replicaverpakking ongedaan maken
  5. Meerdere staatloze exemplaren op het knooppunt toestaan

De meeste van de volgende besturingselementen kunnen worden geconfigureerd via knooppunteigenschappen en plaatsingsbeperkingen, maar sommige zijn ingewikkelder. Om het eenvoudiger te maken, biedt het Service Fabric-cluster Resource Manager deze aanvullende plaatsingsbeleidsregels. Plaatsingsbeleid wordt per benoemd service-exemplaar geconfigureerd. Ze kunnen ook dynamisch worden bijgewerkt.

Ongeldige domeinen opgeven

Met het plaatsingsbeleid InvalidDomain kunt u opgeven dat een bepaald foutdomein ongeldig is voor een specifieke service. Dit beleid zorgt ervoor dat een bepaalde service nooit wordt uitgevoerd op een bepaald gebied, bijvoorbeeld vanwege geopolitieke of zakelijke beleidsredenen. Er kunnen meerdere ongeldige domeinen worden opgegeven via afzonderlijke beleidsregels.

Voorbeeld van ongeldig domein

Code:

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

Vereiste domeinen opgeven

Het vereiste domeinplaatsingsbeleid vereist dat de service alleen aanwezig is in het opgegeven domein. Meerdere vereiste domeinen kunnen worden opgegeven via afzonderlijke beleidsregels.

Voorbeeld van vereist domein

Code:

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

Een voorkeursdomein opgeven voor de primaire replica's van een stateful service

Het primaire voorkeursdomein geeft het foutdomein op waarin het primaire domein moet worden opgeslagen. De primaire komt in dit domein terecht wanneer alles in orde is. Als het domein of de primaire replica uitvalt of wordt afgesloten, wordt de primaire locatie verplaatst naar een andere locatie, idealiter in hetzelfde domein. Als deze nieuwe locatie zich niet in het voorkeursdomein bevindt, verplaatst de cluster-Resource Manager deze zo snel mogelijk terug naar het voorkeursdomein. Deze instelling is natuurlijk alleen zinvol voor stateful services. Dit beleid is het meest nuttig in clusters die zijn verspreid over Azure-regio's of meerdere datacenters, maar services hebben die de voorkeur geven aan plaatsing op een bepaalde locatie. Door primaries dicht bij hun gebruikers of andere services te houden, kunt u een lagere latentie bieden, met name voor leesbewerkingen, die standaard worden verwerkt door Primaries.

Voorkeurs primaire domeinen en failover

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

Replicadistributie vereisen en de toewijzing van verpakking ongedaan maken

Replica's worden normaal gesproken verdeeld over fout- en upgradedomeinen wanneer het cluster in orde is. Er zijn echter gevallen waarin meer dan één replica voor een bepaalde partitie tijdelijk in één domein wordt verpakt. Stel dat het cluster negen knooppunten heeft in drie foutdomeinen, fd:/0, fd:/1 en fd:/2. Stel dat uw service drie replica's heeft. Stel dat de knooppunten die werden gebruikt voor deze replica's in fd:/1 en fd:/2 uitgevallen zijn. Normaal gesproken geeft de cluster-Resource Manager de voorkeur aan andere knooppunten in dezelfde foutdomeinen. In dit geval zijn vanwege capaciteitsproblemen geen van de andere knooppunten in deze domeinen geldig. Als het cluster Resource Manager vervangingen voor deze replica's bouwt, moet het knooppunten kiezen in fd:/0. Als u dit doet, ontstaat er echter een situatie waarin de beperking van het foutdomein wordt geschonden. Het verpakken van replica's vergroot de kans dat de hele replicaset uitvalt of verloren gaat.

Notitie

Raadpleeg dit onderwerp voor meer informatie over beperkingen en beperkingsprioriteiten in het algemeen.

Als u ooit een statusbericht zoals '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' hebt gezien, hebt u deze voorwaarde of iets dergelijks bereikt. Meestal worden slechts een of twee replica's tijdelijk samengepakt. Zolang er minder dan een quorum aan replica's in een bepaald domein is, bent u veilig. Verpakken is zeldzaam, maar het kan gebeuren en deze situaties zijn meestal tijdelijk sinds de knooppunten terugkomen. Als de knooppunten niet beschikbaar blijven en de cluster-Resource Manager vervangingen moet bouwen, zijn er meestal andere knooppunten beschikbaar in de ideale foutdomeinen.

Sommige workloads hebben liever altijd het doelaantal replica's, zelfs als ze in minder domeinen zijn verpakt. Deze workloads zijn gebaseerd op totale gelijktijdige permanente domeinfouten en kunnen meestal de lokale status herstellen. Andere workloads nemen de downtime liever eerder dan het risico op correctheid of verlies van gegevens. De meeste productieworkloads worden uitgevoerd met meer dan drie replica's, meer dan drie foutdomeinen en veel geldige knooppunten per foutdomein. Daarom staat het standaardgedrag domeinverpakking toe. Het standaardgedrag maakt normale verdeling en failover mogelijk om deze extreme gevallen af te handelen, zelfs als dat tijdelijke domeinverpakking betekent.

Als u dergelijke pakketten voor een bepaalde workload wilt uitschakelen, kunt u het RequireDomainDistribution beleid voor de service opgeven. Wanneer dit beleid is ingesteld, zorgt de cluster-Resource Manager ervoor dat er geen twee replica's van dezelfde partitie worden uitgevoerd in hetzelfde fout- of upgradedomein.

Code:

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

Is het nu mogelijk om deze configuraties te gebruiken voor services in een cluster dat niet geografisch overspannen is? Dat kan, maar er is ook geen goede reden. De vereiste, ongeldige en voorkeursdomeinconfiguraties moeten worden vermeden, tenzij de scenario's deze vereisen. Het heeft geen zin om te proberen een bepaalde workload uit te voeren in één rek of om een bepaald segment van uw lokale cluster te verkiezen boven een ander segment. Verschillende hardwareconfiguraties moeten worden verdeeld over foutdomeinen en worden afgehandeld via normale plaatsingsbeperkingen en knooppunteigenschappen.

Plaatsing van meerdere stateless exemplaren van een partitie op één knooppunt

Het plaatsingsbeleid AllowMultipleStatelessInstancesOnNode staat de plaatsing van meerdere stateless exemplaren van een partitie op één knooppunt toe. Standaard kunnen niet meerdere exemplaren van één partitie op een knooppunt worden geplaatst. Zelfs met een -1-service is het niet mogelijk om het aantal exemplaren buiten het aantal knooppunten in het cluster te schalen voor een bepaalde benoemde service. Met dit plaatsingsbeleid wordt deze beperking verwijderd en kan InstanceCount hoger worden opgegeven dan het aantal knooppunten.

Als u ooit een statusbericht zoals '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' hebt gezien, hebt u deze voorwaarde of iets dergelijks bereikt.

Als u zich wilt aanmelden om dit plaatsingsbeleid toe te passen op uw service, schakelt u de volgende configuraties in:

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

Door het AllowMultipleStatelessInstancesOnNode beleid voor de service op te geven, kan InstanceCount worden ingesteld buiten het aantal knooppunten in het cluster.

Code:

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

Notitie

Momenteel wordt het beleid alleen ondersteund voor stateless services met de activeringsmodus ExclusiveProcess-servicepakketten.

Waarschuwing

Het beleid wordt niet ondersteund wanneer het wordt gebruikt met statische poorteindpunten. Als u beide in combinatie gebruikt, kan dit leiden tot een beschadigd cluster, omdat meerdere exemplaren op hetzelfde knooppunt proberen verbinding te maken met dezelfde poort en dit niet kan worden weergegeven.

Notitie

Het gebruik van een hoge waarde van MinInstanceCount met dit plaatsingsbeleid kan leiden tot vastgelopen toepassingsupgrades. Als u bijvoorbeeld een cluster met vijf knooppunten hebt en InstanceCount=10 instelt, hebt u twee exemplaren op elk knooppunt. Als u MinInstanceCount=9 instelt, kan een app-upgrade vastlopen; met MinInstanceCount=8 kan dit worden vermeden.

Volgende stappen