Políticas de posicionamento para serviços do Service Fabric

As políticas de posicionamento são regras adicionais que podem ser usadas para controlar o posicionamento do serviço em alguns cenários específicos e menos comuns. Alguns exemplos desses cenários são:

• Seu cluster do Service Fabric abrange distâncias geográficas, como vários datacenters locais ou entre regiões do Azure
• Seu ambiente abrange várias áreas de controle geopolítico ou legal, ou algum outro caso em que você tenha limites de política que precisa impor
• Existem considerações de desempenho ou latência de comunicação devido a grandes distâncias ou ao uso de links de rede mais lentos ou menos confiáveis
• Você precisa manter certas cargas de trabalho colocadas como um melhor esforço, seja com outras cargas de trabalho ou na proximidade com os clientes
• Você precisa de várias instâncias sem estado de uma partição em um único nó

A maioria desses requisitos está alinhada com o layout físico do cluster, representado como os domínios de falha do cluster.

As políticas de posicionamento avançado que ajudam a resolver esses cenários são:

1. Domínios inválidos
2. Domínios necessários
3. Domínios preferidos
4. Não permitindo o empacotamento de réplicas
5. Permitir várias instâncias sem estado no nó

A maioria dos controles a seguir pode ser configurada por meio de propriedades de nó e restrições de posicionamento, mas alguns são mais complicados. Para simplificar as coisas, o Gerenciador de Recursos de Cluster do Service Fabric fornece essas políticas de posicionamento adicionais. As políticas de posicionamento são configuradas por instância de serviço nomeada. Eles também podem ser atualizados dinamicamente.

Especificando domínios inválidos

A política de posicionamento InvalidDomain permite especificar que um determinado Domínio de Falha é inválido para um serviço específico. Esta política garante que um determinado serviço nunca é executado numa determinada área, por exemplo, por razões geopolíticas ou de política empresarial. Vários domínios inválidos podem ser especificados por meio de políticas separadas.

Código:

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

Especificando domínios necessários

A política de posicionamento de domínio necessária requer que o serviço esteja presente apenas no domínio especificado. Vários domínios necessários podem ser especificados por meio de políticas separadas.

Código:

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

Especificando um domínio preferencial para as réplicas primárias de um serviço com monitoração de estado

O Domínio Primário Preferencial especifica o domínio de falha no qual colocar o Primário. A Primária acaba neste domínio quando tudo está saudável. Se o domínio ou a réplica Primária falhar ou for encerrada, a Primária será movida para outro local, idealmente no mesmo domínio. Se esse novo local não estiver no domínio preferencial, o Gerenciador de Recursos de Cluster o moverá de volta para o domínio preferencial o mais rápido possível. Naturalmente, essa configuração só faz sentido para serviços com monitoração de estado. Essa política é mais útil em clusters que se estendem por regiões do Azure ou vários datacenters, mas têm serviços que preferem o posicionamento em um determinado local. Manter as Primárias próximas de seus usuários ou outros serviços ajuda a fornecer menor latência, especialmente para leituras, que são tratadas por Primárias por padrão.

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

Exigindo distribuição de réplica e não permitindo o empacotamento

As réplicas normalmente são distribuídas entre domínios de falha e atualização quando o cluster está íntegro. No entanto, há casos em que mais de uma réplica para uma determinada partição pode acabar temporariamente compactada em um único domínio. Por exemplo, digamos que o cluster tenha nove nós em três domínios de falha, fd:/0, fd:/1 e fd:/2. Digamos também que seu serviço tenha três réplicas. Digamos que os nós que estavam sendo usados para essas réplicas em fd:/1 e fd:/2 caíram. Normalmente, o Cluster Resource Manager prefere outros nós nesses mesmos domínios de falha. Neste caso, digamos que, devido a problemas de capacidade, nenhum dos outros nós nesses domínios era válido. Se o Gerenciador de Recursos de Cluster criar substituições para essas réplicas, ele terá que escolher nós em fd:/0. No entanto, fazer isso cria uma situação em que a restrição de domínio de falha é violada. Empacotar réplicas aumenta a chance de todo o conjunto de réplicas cair ou ser perdido.

Se você já viu uma mensagem de saúde como "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", então você atingiu esta condição ou algo parecido. Normalmente, apenas uma ou duas réplicas são agrupadas temporariamente. Desde que haja menos de um quórum de réplicas em um determinado domínio, você estará seguro. O empacotamento é raro, mas pode acontecer, e geralmente essas situações são transitórias, já que os nós voltam. Se os nós permanecerem inativos e o Gerenciador de Recursos de Cluster precisar criar substituições, geralmente há outros nós disponíveis nos domínios de falha ideais.

Algumas cargas de trabalho preferem ter sempre o número de réplicas de destino, mesmo que estejam agrupadas em menos domínios. Essas cargas de trabalho estão apostando contra falhas de domínio permanentes simultâneas totais e geralmente podem recuperar o estado local. Outras cargas de trabalho preferem aproveitar o tempo de inatividade mais cedo do que correr o risco de correção ou perda de dados. A maioria das cargas de trabalho de produção é executada com mais de três réplicas, mais de três domínios de falha e muitos nós válidos por domínio de falha. Por isso, o comportamento padrão permite o empacotamento de domínio por padrão. O comportamento padrão permite o balanceamento normal e o failover para lidar com esses casos extremos, mesmo que isso signifique empacotamento de domínio temporário.

Se quiser desativar esse empacotamento para uma determinada carga de trabalho, você pode especificar a RequireDomainDistribution política no serviço. Quando essa política é definida, o Gerenciador de Recursos de Cluster garante que nenhuma réplica da mesma partição seja executada no mesmo domínio de falha ou atualização.

Código:

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

Agora, seria possível usar essas configurações para serviços em um cluster que não fosse geograficamente estendido? Você poderia, mas não há uma grande razão também. As configurações de domínio necessárias, inválidas e preferenciais devem ser evitadas, a menos que os cenários as exijam. Não faz sentido tentar forçar uma determinada carga de trabalho a ser executada em um único rack ou preferir um segmento do cluster local em detrimento de outro. Diferentes configurações de hardware devem ser distribuídas entre domínios de falha e tratadas por meio de restrições de posicionamento normais e propriedades de nó.

Colocação de várias instâncias sem estado de uma partição em um único nó

A política de posicionamento AllowMultipleStatelessInstancesOnNode permite o posicionamento de várias instâncias sem estado de uma partição em um único nó. Por padrão, várias instâncias de uma única partição não podem ser colocadas em um nó. Mesmo com um serviço -1, não é possível dimensionar o número de instâncias além do número de nós no cluster, para um determinado serviço nomeado. Essa política de posicionamento remove essa restrição e permite que InstanceCount seja especificado acima da contagem de nós.

Se você já viu uma mensagem de saúde como "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", então você atingiu esta condição ou algo parecido.

Para optar por aplicar esta política de posicionamento ao seu serviço, ative as seguintes configurações:

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

Ao especificar a AllowMultipleStatelessInstancesOnNode política no serviço, InstanceCount pode ser definido além do número de nós no cluster.

Código:

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 

Próximos passos

• Para obter mais informações sobre como configurar serviços, Saiba mais sobre como configurar serviços