Criteri di posizionamento per i servizi di Service Fabric

I criteri di posizionamento sono regole aggiuntive che possono essere usate per gestire il posizionamento dei servizi in alcuni scenari specifici e meno comuni. Ecco alcuni esempi di questi scenari:

• Il cluster di Service Fabric si estende su distanze geografiche, ad esempio più data center locali o tra aree di Azure
• L'ambiente si estende su più aree di controllo geopolitico o legale o su altri casi in cui sono presenti limiti di criteri da applicare
• Esistono considerazioni sulle prestazioni o sulla latenza delle comunicazioni dovute a distanze elevate o all'uso di collegamenti di rete più lenti o meno affidabili
• È necessario mantenere determinati carichi di lavoro collocati come miglior sforzo, con altri carichi di lavoro o in prossimità dei clienti
• Sono necessarie più istanze senza stato di una partizione in un singolo nodo

La maggior parte di questi requisiti è allineata al layout fisico del cluster, rappresentato come domini di errore del cluster.

I criteri di posizionamento avanzati che consentono di risolvere questi scenari sono:

1. Domini non validi
2. Domini obbligatori
3. Domini preferiti
4. Non consentire la compressione delle repliche
5. Consenti più istanze senza stato nel nodo

La maggior parte dei controlli seguenti può essere configurata tramite proprietà del nodo e vincoli di posizionamento, ma alcuni sono più complessi. Per semplificare le operazioni, Cluster Resource Manager di Service Fabric fornisce questi criteri di posizionamento aggiuntivi. I criteri di posizionamento vengono configurati per singola istanza di servizio denominata. Possono anche essere aggiornati in modo dinamico.

Specificare domini non validi

Il criterio di posizionamento InvalidDomain consente di specificare che un particolare dominio di errore non è valido per un servizio specifico. Questo criterio garantisce che un particolare servizio non venga mai eseguito in un'area specifica, ad esempio per motivi geopolitici o aziendali. È possibile specificare più domini non validi tramite criteri separati.

Codice:

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

Specifica dei domini obbligatori

Il criterio di posizionamento del dominio richiesto richiede che il servizio sia presente solo nel dominio specificato. È possibile specificare più domini obbligatori tramite criteri separati.

Codice:

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

Specifica di un dominio preferito per le repliche primarie di un servizio con stato

Il dominio primario preferito specifica il dominio di errore in cui posizionare il Primario. Il Primario arriva in questo dominio quando tutto è in salute. Se il dominio o la replica primaria fallisce o si spegne, la replica primaria si sposta in un'altra posizione, idealmente nello stesso dominio. Se questo nuovo percorso non si trova nel dominio preferito, Cluster Resource Manager lo sposta di nuovo nel dominio preferito il prima possibile. Naturalmente questa impostazione ha senso solo per i servizi con stato. Questo criterio è più utile nei cluster che si estendono tra aree di Azure o più data center, ma hanno servizi che preferiscono posizionare in una determinata posizione. Mantenere i primari vicini agli utenti o ad altri servizi consente di garantire una latenza più bassa, soprattutto per le letture, gestite da Primaries per impostazione predefinita.

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

Richiede la distribuzione della replica e impedisce l'imballaggio

Le repliche vengono in genere distribuite tra domini di errore e di aggiornamento quando il cluster è integro. Tuttavia, ci sono casi in cui più repliche di una determinata partizione possono concentrarsi temporaneamente in un singolo dominio. Si supponga, ad esempio, che il cluster abbia nove nodi in tre domini di errore, fd:/0, fd:/1 e fd:/2. Si supponga anche che il servizio abbia tre repliche. Supponiamo che i nodi usati per tali repliche in fd:/1 e fd:/2 siano andati in panne. In genere Cluster Resource Manager preferisce altri nodi negli stessi domini di errore. In questo caso, si supponga che a causa di problemi di capacità nessuno degli altri nodi in tali domini fosse valido. Se il Cluster Resource Manager crea sostituzioni per tali repliche, dovrà scegliere i nodi in fd:/0. Tuttavia , questa operazione crea una situazione in cui viene violato il vincolo Del dominio di errore. La compressione delle repliche aumenta la probabilità che l'intero set di repliche vada inattivo o vada perso.

Se hai mai visto un messaggio di stato di salute, ad esempio "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", hai incontrato questa situazione o qualcosa di simile. In genere solo una o due repliche vengono raggruppate temporaneamente. Finché in un determinato dominio sono presenti meno di un quorum di repliche, si è sicuri. L'accorpamento è raro, ma può verificarsi e in genere queste situazioni sono temporanee poiché i nodi ritornano. Se i nodi rimangono inattivi e il Cluster Resource Manager deve creare sostituzioni, in genere sono disponibili altri nodi nei domini di errore ottimali.

Alcuni carichi di lavoro preferiscono avere sempre il numero di repliche di destinazione, anche se vengono concentrati in un numero minore di domini. Questi carichi di lavoro scommettono contro i totali errori di dominio permanenti simultanei e in genere possono ripristinare lo stato locale. Altri carichi di lavoro preferirebbero accettare un periodo di inattività prima di rischiare errori o perdita di dati. La maggior parte dei carichi di lavoro di produzione viene eseguita con più di tre repliche, più di tre domini di errore e molti nodi validi per ogni dominio di errore. Per questo motivo, il comportamento predefinito consente il raggruppamento di dominio per impostazione predefinita. Il comportamento predefinito consente il bilanciamento normale e il failover per gestire questi casi estremi, anche se questo significa compressione temporanea del dominio.

Se vuoi disabilitare tale impacchettamento per un determinato carico di lavoro, è possibile specificare il RequireDomainDistribution criterio nel servizio. Quando questo criterio è impostato, Cluster Resource Manager non garantisce che due repliche della stessa partizione vengano eseguite nello stesso dominio di errore o aggiornamento.

Codice:

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

A questo punto, sarebbe possibile usare queste configurazioni per i servizi in un cluster che non era geograficamente esteso? Potresti, ma non c'è un ottimo motivo. Le configurazioni di dominio obbligatorie, non valide e preferite devono essere evitate a meno che gli scenari non li richiedano. Non ha senso provare a forzare l'esecuzione di un determinato carico di lavoro in un singolo rack o preferire alcuni segmenti del cluster locale rispetto a un altro. Le diverse configurazioni hardware devono essere distribuite tra domini di errore e gestite tramite normali vincoli di posizionamento e proprietà dei nodi.

Posizionamento di più istanze senza stato di una partizione in un singolo nodo

Il criterio di posizionamento AllowMultipleStatelessInstancesOnNode consente il posizionamento di più istanze senza stato di una partizione in un singolo nodo. Per impostazione predefinita, non è possibile inserire più istanze di una singola partizione in un nodo. Anche con un servizio -1, non è possibile ridimensionare il numero di istanze oltre il numero di nodi nel cluster, per un determinato servizio denominato. Questo criterio di posizionamento rimuove questa restrizione e consente di specificare InstanceCount superiore al numero di nodi.

Se hai mai visto un messaggio di salute, ad esempio "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", hai raggiunto questa condizione o qualcosa del genere.

Per acconsentire esplicitamente all'applicazione di questo criterio di posizionamento nel servizio, abilitare le configurazioni seguenti:

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

Specificando i AllowMultipleStatelessInstancesOnNode criteri nel servizio, InstanceCount può essere impostato oltre il numero di nodi nel cluster.

Codice:

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 

Passaggi successivi

• Per altre informazioni sulla configurazione dei servizi, vedere Informazioni sulla configurazione dei servizi