Plaatsingsbeleid voor Service Fabric-services

Plaatsingsbeleid is aanvullende regels die kunnen worden gebruikt voor het beheren van serviceplaatsing in bepaalde specifieke, minder voorkomende scenario's. 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 in de buurt houden van bepaalde werkbelastingen, hetzij met andere werkbelastingen of in de nabijheid van klanten
  • U hebt meerdere staatloze exemplaren van een partitie nodig op één knooppunt

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

De geavanceerde plaatsingsbeleidsregels 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 staatloze 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 het Service Fabric-cluster Resource Manager 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 om 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 het plaatsen van domeinen vereist dat de service alleen aanwezig is in het opgegeven domein. Er kunnen meerdere vereiste domeinen 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 specificeert het foutdomein waarin de primaire locatie moet worden opgenomen. 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 het 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 de toewijzing van pakketten ongedaan maken

Replica's worden normaal gesproken verdeeld over fout- en upgradedomeinen wanneer het cluster in orde is. Er zijn echter gevallen waarin meerdere replica's voor een bepaalde partitie tijdelijk in één domein 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 deze replica's in fd:/1 en fd:/2 zijn uitgekomen. Normaal gesproken geeft het cluster Resource Manager de voorkeur aan andere knooppunten in dezelfde foutdomeinen. In dit geval kunnen we zeggen dat vanwege capaciteitsproblemen geen van de andere knooppunten in die domeinen geldig waren. Als het cluster Resource Manager vervangingen voor deze replica's bouwt, moet het 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 vergroot de kans dat de hele replicaset uitvalt of verloren kan gaan.

Notitie

Raadpleeg dit onderwerp voor meer informatie over beperkingen en 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. Verpakking 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 altijd het doelaantal replica's, zelfs als ze in minder domeinen zijn verpakt. Deze workloads wedden op totale gelijktijdige permanente domeinfouten en kunnen meestal de lokale status herstellen. Andere workloads nemen liever de downtime eerder dan risicovolheid 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 standaard het standaardgedrag het inpakken van domeinen toe. Het standaardgedrag maakt normale taakverdeling en failover mogelijk om deze extreme gevallen af te handelen, 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 het 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")

Zou het nu mogelijk zijn om deze configuraties te gebruiken voor services in een cluster dat niet geografisch is verspreid? Dat kan, maar er is ook geen goede reden. De vereiste, ongeldige en voorkeursdomeinconfiguraties moeten worden vermeden, tenzij de scenario's deze vereisen. Het is niet logisch om een bepaalde workload te dwingen om in één rek te worden uitgevoerd of om een bepaald segment van uw lokale cluster te prefereren boven een ander. 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 staatloze 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 te schalen buiten het aantal knooppunten in het cluster, 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 boven 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 verbinden met dezelfde poort en niet kunnen 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 geprobeerde app-upgrade vastlopen; met MinInstanceCount=8 kan dit worden vermeden.

Volgende stappen