Equilibrar o cluster do Service Fabric

O Cluster do Service Fabric Resource Manager suporta alterações de carga dinâmicas, reagindo a adições ou remoção de nós ou serviços. Também corrige automaticamente as violações de restrição e reequilibrar proativamente o cluster. Mas com que frequência estas ações são executadas e o que as aciona?

Existem três categorias diferentes de trabalho que o Cluster Resource Manager efetua:

• Posicionamento – esta fase aborda a colocação de réplicas com monitorização de estado ou instâncias sem estado em falta. A colocação inclui os novos serviços e o processamento de réplicas com monitorização de estado ou instâncias sem estado que falharam. A eliminação e remoção de réplicas ou instâncias são processadas aqui.
• Verificações de Restrição – esta fase verifica e corrige as violações das diferentes restrições de colocação (regras) no sistema. Exemplos de regras são aspetos como garantir que os nós não estão acima da capacidade e que as restrições de colocação de um serviço são cumpridas.
• Balanceamento – esta fase verifica se o reequilíbrio é necessário com base no nível de equilíbrio pretendido configurado para diferentes métricas. Nesse caso, tenta encontrar uma disposição no cluster mais equilibrada.

Configurar Temporizadores de cluster Resource Manager

O primeiro conjunto de controlos em torno do balanceamento é um conjunto de temporizadores. Estes temporizadores regem a frequência com que o Cluster Resource Manager examina o cluster e efetua ações corretivas.

Cada um destes diferentes tipos de correções que o Cluster Resource Manager pode fazer é controlado por um temporizador diferente que rege a sua frequência. Quando cada temporizador é acionado, a tarefa é agendada. Por predefinição, o Resource Manager:

• analisa o respetivo estado e aplica atualizações (como registar que um nó está inativo) a cada 1/10 de segundo
• define o sinalizador de verificação de colocação a cada segundo
• define o sinalizador de verificação de restrição a cada segundo
• define o sinalizador de balanceamento a cada cinco segundos

Seguem-se alguns exemplos da configuração que rege estes temporizadores:

ClusterManifest.xml:

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PLBRefreshGap" Value="0.1" />
            <Parameter Name="MinPlacementInterval" Value="1.0" />
            <Parameter Name="MinConstraintCheckInterval" Value="1.0" />
            <Parameter Name="MinLoadBalancingInterval" Value="5.0" />
        </Section>

através de ClusterConfig.json para implementações autónomas ou Template.json para clusters alojados no Azure:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PLBRefreshGap",
          "value": "0.10"
      },
      {
          "name": "MinPlacementInterval",
          "value": "1.0"
      },
      {
          "name": "MinConstraintCheckInterval",
          "value": "1.0"
      },
      {
          "name": "MinLoadBalancingInterval",
          "value": "5.0"
      }
    ]
  }
]

Atualmente, o Cluster Resource Manager executa apenas uma destas ações de cada vez, sequencialmente. É por isso que referimos estes temporizadores como "intervalos mínimos" e as ações que são executadas quando os temporizadores são desativados como "sinalizadores de definição". Por exemplo, o Cluster Resource Manager trata de pedidos pendentes para criar serviços antes de equilibrar o cluster. Como pode ver pelos intervalos de tempo predefinidos especificados, o Cluster Resource Manager analisa tudo o que precisa de fazer com frequência. Normalmente, isto significa que o conjunto de alterações efetuadas durante cada passo é pequeno. As alterações pequenas e frequentes permitem que o Cluster Resource Manager responsivo quando acontecem coisas no cluster. Os temporizadores predefinidos fornecem alguma criação de batches, uma vez que muitos dos mesmos tipos de eventos tendem a ocorrer em simultâneo.

Por exemplo, quando os nós falham, podem fazê-lo em domínios de falha inteiros de cada vez. Todas estas falhas são capturadas durante a próxima atualização de estado após o PLBRefreshGap. As correções são determinadas durante as seguintes execuções de colocação, verificação de restrição e balanceamento. Por predefinição, o cluster Resource Manager não está a analisar as horas de alterações no cluster e a tentar resolver todas as alterações ao mesmo tempo. Fazê-lo levaria a explosões de abandono.

O cluster Resource Manager também precisa de algumas informações adicionais para determinar se o cluster desequilibrou. Para isso, temos duas outras partes de configuração: BalancingThresholds e ActivityThresholds.

Limiares de balanceamento

Um Limiar de Balanceamento é o principal controlo para acionar o reequilíbrio. O Limiar de Balanceamento de uma métrica é uma proporção. Se a carga de uma métrica no nó mais carregado dividido pela quantidade de carga no nó menos carregado exceder o BalancingThreshold dessa métrica, o cluster fica desequilibrado. Como resultado, o balanceamento é acionado da próxima vez que o Cluster Resource Manager verifica. O temporizador MinLoadBalancingInterval define a frequência com que o cluster Resource Manager deve verificar se o reequilíbrio é necessário. Verificar não significa que algo aconteça.

Os Limiares de Balanceamento são definidos numa base por métrica como parte da definição do cluster. Para obter mais informações sobre métricas, veja o artigo métricas.

ClusterManifest.xml

    <Section Name="MetricBalancingThresholds">
      <Parameter Name="MetricName1" Value="2"/>
      <Parameter Name="MetricName2" Value="3.5"/>
    </Section>

através de ClusterConfig.json para implementações autónomas ou Template.json para clusters alojados no Azure:

"fabricSettings": [
  {
    "name": "MetricBalancingThresholds",
    "parameters": [
      {
          "name": "MetricName1",
          "value": "2"
      },
      {
          "name": "MetricName2",
          "value": "3.5"
      }
    ]
  }
]

Neste exemplo, cada serviço está a consumir uma unidade de alguma métrica. No exemplo superior, a carga máxima num nó é cinco e o mínimo é dois. Digamos que o limiar de equilíbrio para esta métrica é três. Uma vez que a proporção no cluster é de 5/2 = 2,5 e que é inferior ao limiar de balanceamento especificado de três, o cluster é equilibrado. Não é acionado qualquer balanceamento quando o Cluster Resource Manager verifica.

No exemplo inferior, a carga máxima num nó é 10, enquanto o mínimo é dois, o que resulta numa proporção de cinco. Cinco é maior do que o limiar de equilíbrio designado de três para essa métrica. Como resultado, será agendada uma execução de reequilíbrio da próxima vez que o temporizador de balanceamento for acionado. Numa situação como esta, alguma carga é geralmente distribuída para o Nó 3. Uma vez que o Cluster do Service Fabric Resource Manager não utiliza uma abordagem gananciosa, alguma carga também pode ser distribuída para o Nó 2.

Nota

O "Balanceamento" processa duas estratégias diferentes para gerir a carga no cluster. A estratégia predefinida que o Cluster Resource Manager utiliza é distribuir a carga pelos nós no cluster. A outra estratégia é a desfragmentação. A desfragmentação é realizada durante a mesma execução de balanceamento. As estratégias de balanceamento e desfragmentação podem ser utilizadas para diferentes métricas no mesmo cluster. Um serviço pode ter métricas de balanceamento e desfragmentação. Para as métricas de desfragmentação, a proporção das cargas no cluster aciona o reequilíbrio quando está abaixo do limiar de balanceamento.

Ficar abaixo do limiar de equilíbrio não é um objetivo explícito. Os Limiares de Balanceamento são apenas um acionador. Quando o balanceamento é executado, o cluster Resource Manager determina as melhorias que pode fazer, se existirem. Só porque uma pesquisa de equilíbrio é iniciada não significa que nada se mova. Por vezes, o cluster está desequilibrado, mas demasiado limitado para corrigir. Em alternativa, as melhorias requerem movimentos demasiado dispendiosos).

Limiares de atividade

Por vezes, embora os nós sejam relativamente desequilibrados, a quantidade total de carga no cluster é baixa. A falta de carga pode ser um mergulho transitório ou porque o cluster é novo e está apenas a ser iniciado. Em qualquer um dos casos, poderá não querer perder tempo a equilibrar o cluster porque há pouco a ganhar. Se o cluster fosse submetido a um balanceamento, gastaria recursos de rede e computação para mover itens sem fazer grandes diferenças absolutas . Para evitar movimentações desnecessárias, existe outro controlo conhecido como Limiares de Atividade. Os Limiares de Atividade permitem-lhe especificar um limite inferior absoluto para a atividade. Se nenhum nó estiver acima deste limiar, o balanceamento não será acionado mesmo que o Limiar de Balanceamento seja cumprido.

Digamos que retemos o nosso Limiar de Balanceamento de três para esta métrica. Digamos também que temos um Limiar de Atividade de 1536. No primeiro caso, enquanto o cluster está desequilibrado de acordo com o Limiar de Balanceamento, não existe nenhum nó que cumpra esse Limiar de Atividade, pelo que nada acontece. No exemplo inferior, o Nó 1 está acima do Limiar de Atividade. Uma vez que o Limiar de Balanceamento e o Limiar de Atividade da métrica são excedidos, o balanceamento é agendado. Por exemplo, vamos ver o seguinte diagrama:

Tal como os Limiares de Balanceamento, os Limiares de Atividade são definidos por métrica através da definição do cluster:

ClusterManifest.xml

    <Section Name="MetricActivityThresholds">
      <Parameter Name="Memory" Value="1536"/>
    </Section>

através de ClusterConfig.json para implementações autónomas ou Template.json para clusters alojados no Azure:

"fabricSettings": [
  {
    "name": "MetricActivityThresholds",
    "parameters": [
      {
          "name": "Memory",
          "value": "1536"
      }
    ]
  }
]

Os limiares de balanceamento e atividade estão ambos associados a uma métrica específica . O balanceamento só é acionado se o Limiar de Balanceamento e o Limiar de Atividade forem excedidos para a mesma métrica.

Nota

Quando não especificado, o Limiar de Balanceamento de uma métrica é 1 e o Limiar de Atividade é 0. Isto significa que o cluster Resource Manager tentará manter essa métrica perfeitamente equilibrada para qualquer carga especificada. Se estiver a utilizar métricas personalizadas, recomenda-se que defina explicitamente os seus próprios limiares de balanceamento e atividade para as suas métricas.

Equilibrar serviços em conjunto

Se o cluster está ou não desequilibrado é uma decisão ao nível do cluster. No entanto, corrigimo-lo ao mover réplicas e instâncias de serviço individuais. Isto faz sentido, certo? Se a memória estiver empilhada num nó, várias réplicas ou instâncias poderão estar a contribuir para a mesma. Corrigir o desequilíbrio pode exigir a movimentação de qualquer uma das réplicas com estado ou instâncias sem estado que utilizem a métrica desequilibrada.

Ocasionalmente, porém, um serviço que não estava em si desequilibrado é movido (lembre-se da discussão de pesos locais e globais anteriormente). Por que motivo um serviço seria movido quando todas as métricas desse serviço estavam equilibradas? Vejamos um exemplo:

• Digamos que existem quatro serviços, o Serviço 1, o Serviço 2, o Serviço 3 e o Serviço 4.
• O Serviço 1 comunica as métricas Métrica 1 e Métrica 2.
• O Serviço 2 comunica as métricas Métrica 2 e Métrica 3.
• O Serviço 3 comunica as métricas Métrica 3 e Métrica 4.
• O Serviço 4 comunica a métrica Métrica 99.

Não temos quatro serviços independentes, temos três serviços relacionados e um que está desligado por si só.

Devido a esta cadeia, é possível que um desequilíbrio nas métricas 1 a 4 possa fazer com que réplicas ou instâncias pertencentes aos serviços 1-3 se movam. Também sabemos que um desequilíbrio nas Métricas 1, 2 ou 3 não pode causar movimentos no Serviço 4. Não faria sentido, uma vez que mover as réplicas ou instâncias pertencentes ao Serviço 4 não pode fazer absolutamente nada para afetar o saldo das Métricas 1 a 3.

O Cluster Resource Manager detetar automaticamente que serviços estão relacionados. Adicionar, remover ou alterar as métricas dos serviços pode afetar as respetivas relações. Por exemplo, entre duas execuções de balanceamento, o Serviço 2 pode ter sido atualizado para remover a Métrica 2. Isto interrompe a cadeia entre o Serviço 1 e o Serviço 2. Agora, em vez de dois grupos de serviços relacionados, existem três:

Balanceamento de um cluster por tipo de nó

Conforme descrevemos nas secções anteriores, os principais controlos de acionamento do reequilíbrio são limiares de atividade, limiares de balanceamento e temporizadores. O Cluster do Service Fabric Resource Manager fornece um controlo mais granular sobre como acionar o reequilíbrio com a especificação de parâmetros por tipo de nó e permitir movimento apenas em tipos de nós desequilibrados. O principal benefício do balanceamento por tipo de nó é permitir a melhoria do desempenho em tipos de nós que requerem regras de balanceamento mais rigorosas, sem degradação do desempenho noutros tipos de nós. A funcionalidade contém duas partes principais:

• A deteção de desequilíbrio é efetuada por tipo de nó. Anteriormente, o cálculo global do desequilíbrio é calculado para cada tipo de nó. Se todos os tipos de nós estiverem equilibrados, o CRM não acionará a fase de balanceamento. Caso contrário, se pelo menos um tipo de nó estiver desequilibrado, é necessária a fase de balanceamento.
• O balanceamento move réplicas apenas num tipo de nó que são desequilibrados, outros tipos de nós não são afetados pela fase de balanceamento.

Como o balanceamento por tipo de nó afeta um cluster

Durante o balanceamento de um cluster por tipo de nó, o Cluster do Service Fabric Resource Manager calcula o estado de desequilíbrio para cada tipo de nó. Se, pelo menos, um tipo de nó for desequilibrado, a fase de balanceamento será acionada. A fase de balanceamento não move réplicas em tipos de nós que estão desequilibrados, quando o balanceamento é temporariamente colocado em pausa nestes tipos de nó (por exemplo, o intervalo de balanceamento mínimo não passou desde uma fase de balanceamento anterior). A deteção de um estado desequilibrado utiliza mecanismos comuns já disponíveis para balanceamento de clusters clássicos, mas melhora a granularidade e flexibilidade da configuração. Os mecanismos utilizados para o balanceamento por tipo de nó para detetar o desequilíbrio são fornecidos na lista abaixo:

• Os limiares de balanceamento de métricas por tipo de nó são valores que têm uma função semelhante ao limiar de balanceamento definido globalmente utilizado no balanceamento clássico. A proporção de carga de métricas mínima e máxima é calculada para cada tipo de nó. Se essa proporção de um tipo de nó for superior ao limiar de balanceamento definido do tipo de nó, o tipo de nó será marcado como desequilibrado. Para obter mais detalhes sobre a configuração dos limiares de atividade de métricas por tipo de nó, verifique a secção limiares de balanceamento por tipo de nó.
• Os limiares de atividade de métricas por tipo de nó são valores que têm uma função semelhante ao limiar de atividade definido globalmente utilizado no balanceamento clássico. A carga de métrica máxima é calculada para cada tipo de nó. Se a carga máxima de um tipo de nó for superior ao limiar de atividade definido para esse tipo de nó, o tipo de nó será marcado como desequilibrado. Para obter mais detalhes sobre a configuração dos limiares de atividade de métricas por tipo de nó, verifique a secção activity-thresholds-per-node-type.
• O intervalo de balanceamento mínimo por tipo de nó tem uma função semelhante ao intervalo de balanceamento mínimo definido globalmente. Para cada tipo de nó, o Cluster Resource Manager preserva o carimbo de data/hora do último equilíbrio. Não foi possível executar duas fases de balanceamento consecutivas num tipo de nó no intervalo de balanceamento mínimo definido. Para obter mais detalhes sobre a configuração do intervalo de balanceamento mínimo por tipo de nó, verifique a secção intervalo de balanceamento mínimo por tipo de nó.

Descrever o balanceamento por tipo de nó

Para ativar o balanceamento por tipo de nó, o parâmetro SeparateBalancingStrategyPerNodeType tem de ser ativado num manifesto de cluster. Além disso, a funcionalidade de subclustering também tem de ser ativada. Exemplo de um manifesto de cluster PlacementAndLoadBalancing secção para ativar a funcionalidade:

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="SeparateBalancingStrategyPerNodeType" Value="true" />
    <Parameter Name="SubclusteringEnabled" Value="true" />
    <Parameter Name="SubclusteringReportingPolicy" Value="1" />
</Section>

ClusterConfig.json para implementações autónomas ou Template.json para clusters alojados do Azure:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "SeparateBalancingStrategyPerNodeType",
          "value": "true"
      },
      {
          "name": "SubclusteringEnabled",
          "value": "true"
      },
      {
          "name": "SubclusteringReportingPolicy",
          "value": "1"
      },
    ]
  }
]

Conforme descrevemos na secção anterior, podem ser especificados limiares e intervalos por tipo de nó. Para obter mais detalhes sobre a atualização de parâmetros específicos, verifique as secções seguintes:

• Limiares de balanceamento de métricas por tipo de nó
• Limiares de atividade de métricas por tipo de nó
• Intervalo de balanceamento mínimo por tipo de nó

Limiares de balanceamento por tipo de nó

O limiar de balanceamento de métricas pode ser definido por tipo de nó para aumentar a granularidade da configuração de balanceamento. Os limiares de balanceamento têm o tipo de vírgula flutuante, uma vez que representam um limiar para a proporção de valor de carga máximo e mínimo dentro de um tipo de nó específico. Os limiares de balanceamento são definidos na secção PlacementAndLoadBalancingOverrides para cada tipo de nó:

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MetricBalancingThresholdsPerNodeType>
                <BalancingThreshold Name="Metric1" Value="2.5">
                <BalancingThreshold Name="Metric2" Value="4">
                <BalancingThreshold Name="Metric3" Value="3.25">
            </MetricBalancingThresholdsPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Se o limiar de balanceamento de uma métrica não estiver definido para um tipo de nó, o limiar herda o valor do limiar de balanceamento de métricas definido globalmente na secção PlacementAndLoadBalancing . Caso contrário, se o limiar de balanceamento de uma métrica não estiver definido nem para um tipo de nó nem globalmente numa secção PlacementAndLoadBalancing , o limiar terá o valor predefinido de um.

Limiares de atividade por tipo de nó

O limiar de atividade de métricas pode ser definido por tipo de nó para aumentar a granularidade da configuração de balanceamento. Os limiares de atividade têm um tipo de número inteiro, uma vez que representam um limiar para o valor máximo de carga dentro de um determinado tipo de nó. Os limiares de atividade são definidos na secção PlacementAndLoadBalancingOverrides para cada tipo de nó:

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MetricActivityThresholdsPerNodeType>
                <ActivityThreshold Name="Metric1" Value="500">
                <ActivityThreshold Name="Metric2" Value="40">
                <ActivityThreshold Name="Metric3" Value="1000">
            </MetricActivityThresholdsPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Se o limiar de atividade de uma métrica não estiver definido para um tipo de nó, o limiar herda o valor do limiar de atividade de métrica definido globalmente na secção PlacementAndLoadBalancing . Caso contrário, se o limiar de atividade de uma métrica não estiver definido nem para um tipo de nó nem globalmente numa secção PlacementAndLoadBalancing , o limiar terá o valor predefinido de zero.

Intervalo de balanceamento mínimo por tipo de nó

O intervalo de balanceamento mínimo pode ser definido por tipo de nó para aumentar a granularidade da configuração de balanceamento. O intervalo de balanceamento mínimo tem um tipo de número inteiro, uma vez que representa a quantidade mínima de tempo que tem de passar antes de duas rondas de balanceamento consecutivas num mesmo tipo de nó. O intervalo de balanceamento mínimo é definido na secção PlacementAndLoadBalancingOverrides para cada tipo de nó:

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MinLoadBalancingIntervalPerNodeType>100</MinLoadBalancingIntervalPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Se o intervalo de balanceamento mínimo não estiver definido para um tipo de nó, o intervalo herda o valor do intervalo de balanceamento mínimo definido globalmente na secção PlacementAndLoadBalancing . Caso contrário, se o intervalo mínimo não for definido nem para um tipo de nó nem globalmente numa secção PlacementAndLoadBalancing , o intervalo mínimo terá o valor predefinido de zero , o que indica que não é necessária uma pausa entre as rondas de balanceamento consecutivas.

Exemplos

Exemplo 1

Vamos considerar um caso em que um cluster contém dois tipos de nó, o tipo de nó A e o tipo de nó B. Todos os serviços comunicam uma mesma métrica e estão divididos entre estes tipos de nó, pelo que as estatísticas de carga são diferentes para eles. No exemplo, o tipo de nó A tem uma carga máxima de 300 e um mínimo de 100 e o tipo de nó B tem uma carga máxima de 700 e uma carga mínima de 500:

O cliente detetou que as cargas de trabalho de dois tipos de nós têm necessidades de balanceamento diferentes e decidiu definir diferentes limiares de balanceamento e atividade por tipo de nó. O limiar de balanceamento do tipo de nó A é 2,5 e o limiar de atividade é 50. Para o tipo de nó B, o cliente define o limiar de balanceamento para 1,2 e o limiar de atividade para 400.

Durante a deteção do desequilíbrio para o cluster neste exemplo, ambos os tipos de nós violam o limiar de atividade. A carga máxima do tipo de nó A de 300 é superior ao limiar de atividade definido de 50. A carga máxima do tipo de nó B de 700 é superior ao limiar de atividade definido de 400. O tipo de nó A viola os critérios de limiar de balanceamento, uma vez que a proporção atual de carga máxima e mínima é 3 e o limiar de balanceamento é de 2,5. Em contrário, o tipo de nó B não viola os critérios de limiar de balanceamento, uma vez que a taxa atual de carga máxima e mínima para este tipo de nó é de 1,2, mas o limiar de balanceamento é 1,4. O balanceamento é necessário apenas para réplicas no tipo de nó A e o único conjunto de réplicas que serão elegíveis para movimentos durante a fase de balanceamento são réplicas colocadas no tipo de nó A.

Exemplo 2

Vamos considerar um caso em que um cluster contém três tipos de nó, tipo de nó A, B e C. Todos os serviços comunicam uma mesma métrica e estão divididos entre estes tipos de nó, pelo que as estatísticas de carga são diferentes para eles. No exemplo, o tipo de nó A tem uma carga máxima de 600 e um mínimo de 100, o tipo de nó B tem uma carga máxima de 900 e uma carga mínima de 100 e o tipo de nó C tem uma carga máxima de 600 e uma carga mínima de 300:

O cliente detetou que as cargas de trabalho destes tipos de nó têm necessidades de equilíbrio diferentes e decidiu definir diferentes limiares de balanceamento e atividade por tipo de nó. O limiar de balanceamento do tipo de nó A é 5 e o limiar de atividade é 700. Para o tipo de nó B, o cliente definiu o limiar de balanceamento para 10 e o limiar de atividade para 200. Para o tipo de nó C, o cliente definiu o limiar de balanceamento como 2 e o limiar de atividade para 300.

A carga máxima do tipo de nó A de 600 é inferior ao limiar de atividade definido de 700, pelo que o tipo de nó A não será equilibrado. A carga máxima do tipo de nó B de 900 é superior ao limiar de atividade definido de 200. O tipo de nó B viola os critérios de limiar de atividade. A carga máxima do tipo de nó C de 600 é superior ao limiar de atividade definido de 300. O tipo de nó C viola os critérios de limiar de atividade. O tipo de nó B não viola os critérios de limiar de balanceamento, uma vez que o rácio atual de carga máxima e mínima para este tipo de nó é 9, mas o limiar de balanceamento é 10. O tipo de nó C viola os critérios de limiar de balanceamento, uma vez que a proporção atual de carga máxima e mínima é 2 e o limiar de balanceamento é 2. O equilíbrio é necessário apenas para réplicas no tipo de nó C e o único conjunto de réplicas que serão elegíveis para movimentos durante a fase de balanceamento são as réplicas colocadas no tipo de nó C.

Passos seguintes

• As métricas são como o Resource Manger do Cluster do Service Fabric gere o consumo e a capacidade no cluster. Para saber mais sobre as métricas e como configurá-las, veja o artigo de métricas
• O Custo do Movimento é uma forma de sinalizar para o Cluster Resource Manager que determinados serviços são mais dispendiosos de mover do que outros. Para obter mais informações sobre o custo de movimento, veja o artigo sobre o custo do movimento
• O cluster Resource Manager tem várias limitações que pode configurar para abrandar a taxa de abandono no cluster. Normalmente não são necessários, mas se precisar deles, pode aprender sobre eles o artigo de limitação avançada
• O cluster Resource Manager pode reconhecer e processar subclustering. Pode ocorrer subclustering quando utiliza restrições de colocação e balanceamento. Para saber como o subclustering pode afetar o balanceamento e como pode lidar com o mesmo, veja o artigo de subclustering