Políticas de colocação para serviços de service fabric

  • Artigo

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

  • O cluster do Service Fabric abrange distâncias geográficas, como vários datacenters no local ou entre regiões do Azure
  • O seu ambiente abrange várias áreas de controlo geopolítico ou legal, ou outro caso em que tem limites de políticas que precisa de impor
  • Existem considerações de desempenho ou latência de comunicação devido a grandes distâncias ou utilização de ligações de rede mais lentas ou menos fiáveis
  • Tem de manter determinadas cargas de trabalho alocadas como um melhor esforço, quer com outras cargas de trabalho, quer nas proximidades dos clientes
  • Precisa de várias instâncias sem estado de uma partição num único nó

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

As políticas de colocação avançadas que ajudam a resolver estes cenários são:

  1. Domínios inválidos
  2. Domínios necessários
  3. Domínios preferenciais
  4. Desativar o empacotamento da réplica
  5. Permitir várias instâncias sem estado no nó

A maioria dos seguintes controlos pode ser configurada através de propriedades de nós e restrições de colocação, mas alguns são mais complicados. Para simplificar as coisas, o Cluster do Service Fabric Resource Manager fornece estas políticas de colocação adicionais. As políticas de colocação são configuradas numa base de instância de serviço por nome. Também podem ser atualizados dinamicamente.

Especificar domínios inválidos

A política de colocação InvalidDomain permite-lhe 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 motivos geopolíticos ou de política empresarial. Podem ser especificados vários domínios inválidos através de políticas separadas.

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

Especificar os domínios necessários

A política de colocação de domínios necessária requer que o serviço esteja presente apenas no domínio especificado. Vários domínios necessários podem ser especificados através de políticas separadas.

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

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

O Domínio Primário Preferencial especifica o domínio de falha para colocar o Principal. O Principal acaba neste domínio quando tudo está em bom estado de funcionamento. Se o domínio ou a réplica Primária falharem ou encerrarem, o Principal muda para outra localização, idealmente no mesmo domínio. Se esta nova localização não estiver no domínio preferencial, o Cluster Resource Manager move-a de volta para o domínio preferencial o mais rapidamente possível. Naturalmente, esta definição só faz sentido para serviços com estado. Esta política é mais útil em clusters que são distribuídos por regiões do Azure ou vários datacenters, mas que têm serviços que preferem a colocação numa determinada localização. Manter as Primárias próximas dos seus utilizadores ou de outros serviços ajuda a fornecer menor latência, especialmente para leituras, que são processadas pelas Primárias por predefinição.

Domínios Primários Preferenciais e Ativação Pós-falha

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

Exigir distribuição de réplica e desativar o empacotamento

Normalmente, as réplicas são distribuídas por domínios de falha e atualização quando o cluster está em bom estado de funcionamento. No entanto, existem casos em que mais de uma réplica para uma determinada partição pode acabar temporariamente embalada num único domínio. Por exemplo, digamos que o cluster tem nove nós em três domínios de falha, fd:/0, fd:/1 e fd:/2. Digamos também que o seu serviço tem três réplicas. Digamos que os nós que estavam a ser utilizados para essas réplicas em fd:/1 e fd:/2 ficaram inativos. Normalmente, o Cluster Resource Manager preferiria 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 Cluster Resource Manager criar substituições para essas réplicas, terá de escolher nós em fd:/0. No entanto, fazê-lo cria uma situação em que a restrição do Domínio de Falha é violada. As réplicas de embalagem aumentam a probabilidade de todo o conjunto de réplicas poder ser desativado ou perdido.

Nota

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

Se alguma vez viu uma mensagem de estado de funcionamento 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 atingiu esta condição ou algo parecido. Normalmente, apenas uma ou duas réplicas são agrupadas temporariamente. Desde que haja menos do que um quórum de réplicas num determinado domínio, está a salvo. A embalagem é rara, mas pode acontecer, e geralmente estas situações são transitórias desde que os nós voltam. Se os nós permanecerem inativos e o Cluster Resource Manager precisar de criar substituições, normalmente existem outros nós disponíveis nos domínios de falha ideais.

Algumas cargas de trabalho preferem ter sempre o número de destino de réplicas, mesmo que estejam embaladas em menos domínios. Estas cargas de trabalho estão a apostar contra falhas de domínio permanentes em simultâneo totais e podem, normalmente, recuperar o estado local. Outras cargas de trabalho preferem ter o tempo de inatividade mais cedo do que a correção do risco 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 predefinição, o comportamento predefinido permite o empacotamento de domínios por predefinição. O comportamento predefinido permite que o balanceamento normal e a ativação pós-falha processem estes casos extremos, mesmo que isso signifique empacotamento temporário de domínios.

Se quiser desativar esse empacotamento para uma determinada carga de trabalho, pode especificar a RequireDomainDistribution política no serviço. Quando esta política está definida, o Cluster Resource Manager garante que não existem duas réplicas da mesma partição executadas 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 utilizar estas configurações para serviços num cluster que não foi geograficamente alargado? Podias, 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 num único rack ou preferir algum segmento do cluster local em vez de outro. As diferentes configurações de hardware devem ser distribuídas por domínios de falha e processadas através de restrições de colocação normais e propriedades de nós.

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

A política de colocação AllowMultipleStatelessInstancesOnNode permite a colocação de várias instâncias sem estado de uma partição num único nó. Por predefinição, não é possível colocar várias instâncias de uma única partição num nó. Mesmo com um serviço -1, não é possível dimensionar o número de instâncias para além do número de nós no cluster, para um determinado serviço nomeado. Esta política de colocação remove esta restrição e permite que a InstanceCount seja especificada acima da contagem de nós.

Se alguma vez viu uma mensagem de estado de funcionamento 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 atingiu esta condição ou algo parecido.

Para optar por aplicar esta política de colocação no 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, a InstanceCount pode ser definida para 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

Nota

Atualmente, a política só é suportada para serviços Sem Estado com o modo de ativação do pacote de serviço ExclusiveProcess.

Aviso

A política não é suportada quando utilizada com pontos finais de porta estática. A utilização de ambos em conjunto pode levar a um cluster em mau estado de funcionamento, uma vez que várias instâncias no mesmo nó tentam vincular-se à mesma porta e não podem surgir.

Nota

Utilizar um valor elevado de MinInstanceCount com esta política de colocação pode levar a Atualizações de Aplicações bloqueadas. Por exemplo, se tiver um cluster de cinco nós e definir InstanceCount=10, terá duas instâncias em cada nó. Se definir MinInstanceCount=9, uma tentativa de atualização da aplicação pode ficar bloqueada; com MinInstanceCount=8, isto pode ser evitado.

Passos seguintes