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

  • Artigo

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

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

A maioria desses requisitos se alinha ao 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 preferenciais
  4. Desativação de empacotamento de réplica
  5. Permitir várias instâncias sem estado no nó

A maioria dos controles a seguir pode ser configurada por meio das propriedades de nó e de restrições de posicionamento, mas algumas são mais complicadas. Para simplificar, o Cluster Resource Manager do Service Fabric fornece essas políticas de posicionamento adicionais. As políticas de posicionamento são configuradas de acordo com uma instância de serviço nomeada. Elas também podem ser atualizadas 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. Essa política garante que um serviço específico nunca seja executado em uma determinada área, por exemplo, por motivos de política corporativa ou geopolíticos. Vários domínios inválidos podem ser especificados através de diferentes políticas.

Exemplo de domínio inválido

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ário requer que o serviço esteja presente somente no domínio especificado. Vários domínios necessários podem ser especificados através de diferentes políticas.

Exemplo de domínio necessário

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 preferido para as réplicas primárias de um serviço com estado

O Domínio Primário Preferencial especifica o domínio de falha no qual colocar o primário. O primário é encerrado nesse domínio quando tudo está íntegro. Se o domínio ou a réplica primária falhar ou desligar, o primário move-se para algum outro local. De modo ideal, no mesmo domínio. Se essa nova localização não estiver no domínio preferencial, o Cluster Resource Manager vai movê-lo de volta ao domínio preferencial assim que possível. Obviamente, essa configuração só faz sentido para serviços com estado. Essa política é mais útil em clusters que estão distribuídos em regiões do Azure ou em vários datacenters, mas têm serviços que preferem o posicionamento em um determinado local. Manter os primários próximos aos seus usuários ou outros serviços ajudam a fornecer latência menor, especialmente para leituras, que são tratadas pelos primários por padrão.

Domínios primários preferenciais e 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")

Exigindo a distribuição de réplica e desabilitando o empacotamento

As réplicas normalmente são distribuídas entre domínios de falha e upgrade quando o cluster está íntegro. No entanto, há casos em que mais de uma réplica para uma determinada partição podem acabar temporariamente empacotadas em uma ú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 o serviço tem três réplicas. Digamos que os nós que estavam sendo usados para as réplicas em fd:/1 e fd:/2 foram desativados. Normalmente, o Gerenciador de Recursos de Cluster prefere outros nós nos mesmos domínios de falha. Nesse caso, digamos que devido a problemas de capacidade nenhum dos outros nós nesses domínios era válido. Se o Cluster Resource Manager criasse substituições para essas réplicas, ele precisaria 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 as chances de que o conjunto inteiro de réplicas possa ser desativado ou roubado.

Observação

Para obter mais informações sobre restrições e prioridades de restrições em geral, confira este tópico.

Se você já viu uma mensagem de integridade, 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", você atingiu essa condição ou algo parecido. Normalmente, apenas uma ou duas réplicas são empacotadas juntas temporariamente. Enquanto houver menos de um quorum 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, uma vez que os nós voltam. Se os nós permanecem inativos e o Cluster Resource Manager precisa criar substituições, normalmente haverá outros nós disponíveis nos domínios de falha ideais.

Algumas cargas de trabalho sempre preferirão ter o número de destino de réplicas, mesmo se elas forem empacotadas em menos domínios. Essas cargas de trabalho apostam contra falhas de domínio permanentes simultâneas totais e normalmente podem recuperar o estado local. Outras cargas de trabalho preferem passar logo pelo tempo de inatividade do que arriscar a correção ou a 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 balanceamento normal e failover para tratar desses casos extremos, mesmo que isso signifique empacotamento de domínio temporário.

Se desejar desabilitar esse empacotamento para uma determinada carga de trabalho, você poderá especificar a política RequireDomainDistribution no serviço. Quando essa política é definida, o Gerenciador de Recursos de Cluster garante que duas réplicas da mesma partição não seja executadas no mesmo domínio de falha ou upgrade.

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 tenha sido distribuído geograficamente? Seria, mas também não há um bom motivo para isso. As configurações de domínio obrigató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 algum segmento do seu cluster local em vez de outro. Diferentes configurações de hardware devem ser distribuídas entre domínios de falha e manipuladas por propriedades de nó e restrições de posicionamento normais.

Posicionamento de várias instâncias sem estado de uma partição no ú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 integridade, 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", você atingiu essa condição ou algo parecido.

Para aceitar aplicar essa política de posicionamento no serviço, habilite as seguintes configurações:

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

Especificando a política AllowMultipleStatelessInstancesOnNode 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

Observação

Atualmente, a política só tem suporte para serviços sem estado com o modo de ativação do pacote de serviço ExclusiveProcess.

Aviso

Não há suporte para a política quando usada com pontos de extremidade de porta estática. O uso de ambos ao mesmo tempo pode levar a um cluster não íntegro, pois várias instâncias no mesmo nó tentam se vincular à mesma porta e não podem aparecer.

Observação

O uso de um valor alto de MinInstanceCount com essa política de posicionamento pode levar a atualizações de aplicativos travadas. Por exemplo, se você tiver um cluster de cinco nós e definir InstanceCount=10, terá duas instâncias em cada nó. Se você definir MinInstanceCount=9, uma tentativa de atualização de aplicativo poderá ficar travada; com MinInstanceCount=8, isso pode ser evitado.

Próximas etapas