Delen via

Plaatsingsbeleid voor Service Fabric-services

  • Artikel

Plaatsingsbeleid is aanvullende regels die kunnen worden gebruikt om de plaatsing van services in bepaalde specifieke, minder gangbare scenario's te beheren. Enkele voorbeelden van deze scenario's zijn:

  • Uw Service Fabric-cluster omvat 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 hebt die u 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 als best effort houden, hetzij met andere workloads of in nabijheid van klanten
  • U hebt meerdere stateless exemplaren van een partitie op één knooppunt nodig

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

De geavanceerde beleidsregels voor plaatsing die u helpen bij het oplossen van deze scenario's zijn:

  1. Ongeldige domeinen
  2. Vereiste domeinen
  3. Voorkeursdomeinen
  4. Toewijzing van replicaverpakking ongedaan maken
  5. Meerdere stateless exemplaren op knooppunten toestaan

De meeste van de volgende besturingselementen kunnen worden geconfigureerd via knooppunteigenschappen en plaatsingsbeperkingen, maar sommige zijn ingewikkelder. Om het eenvoudiger te maken, biedt Service Fabric-clusterbronbeheer deze aanvullende plaatsingsbeleidsregels. Plaatsingsbeleid wordt geconfigureerd op basis van een service-exemplaar per naam. 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.

Ongeldig domeinvoorbeeld

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 beleid voor domeinplaatsing vereist dat de service alleen aanwezig is in het opgegeven domein. Meerdere vereiste domeinen kunnen worden opgegeven via afzonderlijke beleidsregels.

Vereist domeinvoorbeeld

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 domein van voorkeur geeft het foutdomein op waarin de primaire moet worden ingevoerd. De primaire komt in dit domein terecht wanneer alles in orde is. Als het domein of de primaire replica mislukt 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 Cluster Resource Manager deze zo snel mogelijk terug naar het voorkeursdomein. Deze instelling is natuurlijk alleen zinvol voor stateful services. Dit beleid is het handigst 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. Primaries dicht bij hun gebruikers of andere services houden, zorgt voor lagere latentie, 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 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 kan worden verpakt. Stel dat het cluster negen knooppunten heeft in drie foutdomeinen, fd:/0, fd:/1 en fd:/2. Stel ook dat uw service drie replica's heeft. Stel dat de knooppunten die werden gebruikt voor die replica's in fd:/1 en fd:/2 omlaag zijn gegaan. Normaal gesproken geeft Cluster Resource Manager de voorkeur aan andere knooppunten in dezelfde foutdomeinen. In dit geval kunnen we zeggen dat er geen van de andere knooppunten in deze domeinen geldig zijn vanwege capaciteitsproblemen. Als de Cluster Resource Manager vervangingen voor deze replica's bouwt, moet deze knooppunten kiezen in fd:/0. Als u dat doet, ontstaat er echter een situatie waarin de beperking foutdomein wordt geschonden. Het inpakken van replica's verhoogt de kans dat de hele replicaset uitvalt of verloren kan gaan.

Notitie

Raadpleeg dit onderwerp voor meer informatie over beperkingen en prioriteiten voor beperkingen.

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 bereikt of iets dergelijks. Meestal worden slechts één of twee replica's tijdelijk samengepakt. Zolang er minder dan een quorum van replica's in een bepaald domein is, bent u veilig. Verpakken is zeldzaam, maar het kan gebeuren, en meestal zijn deze situaties tijdelijk omdat de knooppunten terugkomen. Als de knooppunten niet actief 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 wedden tegen totale gelijktijdige permanente domeinfouten en kunnen meestal de lokale status herstellen. Andere workloads nemen liever de downtime eerder dan risico-juistheid 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. Hierdoor staat standaard het standaardgedrag toe dat domeinverpakkingen zijn toegestaan. Het standaardgedrag zorgt ervoor dat normale taakverdeling en failover deze extreme gevallen kunnen verwerken, zelfs als dat tijdelijke domeinverpakking betekent.

Als u een dergelijke verpakking voor een bepaalde workload wilt uitschakelen, kunt u het RequireDomainDistribution beleid voor de service opgeven. Wanneer dit beleid is ingesteld, zorgt 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 is verspreid? Je kunt, maar er is ook geen goede reden. De vereiste, ongeldige en voorkeursdomeinconfiguraties moeten worden vermeden, tenzij de scenario's deze vereisen. Het is niet zinvol om een bepaalde werkbelasting af te dwingen om in één rek te worden uitgevoerd of om een bepaald segment van uw lokale cluster te prefereren boven een ander cluster. Verschillende hardwareconfiguraties moeten worden verdeeld over foutdomeinen en worden verwerkt via normale plaatsingsbeperkingen en knooppunteigenschappen.

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

Met het plaatsingsbeleid AllowMultipleStatelessInstancesOnNode kunnen meerdere stateless exemplaren van een partitie op één knooppunt worden geplaatst. Standaard kunnen meerdere exemplaren van één partitie niet 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 bereikt of iets dergelijks.

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 bij gebruik met statische poorteindpunten. Als u beide in combinatie gebruikt, kan dit leiden tot een beschadigd cluster omdat meerdere exemplaren op hetzelfde knooppunt proberen te binden aan dezelfde poort en niet kunnen worden opgehaald.

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 geprobeerde app-upgrade vastlopen; met MinInstanceCount=8 kan dit worden vermeden.

Volgende stappen