Balanceamento do cluster do Service Fabric

O Gerenciador de Recursos de Cluster do Service Fabric oferece suporte a alterações de carga dinâmico, reagindo a inclusões ou remoções de nós ou serviços. Ele também corrige automaticamente as violações de restrição e, proativamente, balanceia novamente o cluster. Mas com que frequência essas ações são executadas, e o que as dispara?

Há três categorias diferentes de trabalho que o Gerenciador de Recursos de Cluster executa:

• Posicionamento – esse estágio lida com o posicionamento de réplicas com estado ou de instâncias sem estado que estejam ausentes. O posicionamento inclui os novos serviços e a manipulação de réplicas com estado ou de instâncias sem estado que falharam. A exclusão e o descarte de réplicas ou de instâncias são tratados aqui.
• Verificações de Restrição – esse estágio verifica e corrige violações das restrições (regras) de posicionamento no sistema. Exemplos de regras são coisas como garantir que os nós não estejam acima da capacidade e que as restrições de posicionamento de um serviço sejam atendidas.
• Balanceamento – esse estágio verifica se o rebalanceamento é necessário com base no nível de equilíbrio desejado configurado para diferentes métricas. Nesse caso, ele tenta localizar uma organização em cluster que é mais equilibrado.

Configuração de temporizadores do Gerenciador de Recursos de Cluster

O primeiro conjunto de controles de balanceamento é um conjunto de temporizadores. Esses temporizadores determinam a frequência com que o Gerenciador de Recursos de Cluster examina o cluster e executa as ações corretivas.

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

• verifica o estado e aplica atualizações (como gravação de um nó estiver inativo) cada 1/10 de segundo
• define o sinalizador de verificação de posicionamento a cada segundo
• define o sinalizador de verificação de restrição a cada segundo
• define o sinalizador de balanceamento a cada cinco segundos

Veja a seguir exemplos de configuração que governam esses 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>

via ClusterConfig.json para implantações Autônomas ou Template.json para clusters hospedados pelo 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 Resource Manager de Cluster executa apenas uma dessas ações ao mesmo tempo, sequencialmente. É por isso que fazemos referência a esses temporizadores como "intervalos mínimos" e as ações realizadas quando os temporizadores desligam como "sinalizadores de configuração". Por exemplo, o Resource Manager de Cluster se encarrega de solicitações pendentes para criar serviços antes do cluster de balanceamento. Como você pode ver, os intervalos de tempo padrão especificados, o Gerenciador de Recursos de Cluster examina se há qualquer coisa que precisa ser feito com frequência. Normalmente, isso significa que o conjunto de alterações feitas durante cada etapa é pequeno. Alterações pequenas e frequentes permitem que o Gerenciador de Recursos de Cluster responda quando coisas acontecem no cluster. Os temporizadores padrão oferecem algum lote, já que muitos dos mesmos tipos de eventos tendem a ocorrer simultaneamente.

Por exemplo, quando os nós falham, eles podem fazer com um domínio de falha inteiro por vez. Todas essas 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 posicionamento, verificação de restrição e balanceamento. Por padrão, o Gerenciador de Recursos de Cluster não está verificando horas de alterações no cluster e tentando resolver todas as alterações de uma só vez. Isso levaria a picos de variação.

O Resource Manager de Cluster também precisa de algumas informações adicionais para determinar se o cluster desequilibrado. Para isso, temos duas outras configurações: Limites de Balanceamento e Limites de Atividade.

Limites de balanceamento

Um Limite de Balanceamento é o controle principal que dispara o rebalanceamento. O Limite de Balanceamento para uma métrica é uma razão. Se a carga de uma métrica no nó mais carregado dividido pela quantidade de carga no nó menos carregado excede o Limite de Balanceamento dessa métrica, o cluster é desequilibrado. Como resultado de balanceamento é disparada na próxima vez que o Resource Manager de Cluster verifica. O temporizador MinLoadBalancingInterval define a frequência com que o Gerenciador de Recursos de Cluster deve verificar se o rebalanceamento é necessário. A verificação não significa que nada acontece.

Os Limites de Balanceamento são definidos baseados em cada métrica, como parte da definição do cluster. Para obter mais informações sobre métricas, confira o artigo métricas.

ClusterManifest.xml

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

via ClusterConfig.json para implantações Autônomas ou Template.json para clusters hospedados pelo Azure:

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

Neste exemplo, cada serviço está consumindo uma unidade de alguma métrica. No exemplo superior, a carga máxima em um nó é cinco e o mínimo é dois. Digamos que o limite de balanceamento para esta métrica seja três. Como a proporção do cluster é 5/2 = 2,5 e é menor do que o especificado balanceamento de limite de três, o cluster é equilibrado. Nenhum balanceamento é disparada quando verifica se o Resource Manager de Cluster.

No exemplo inferior, a carga máxima em um nó é dez, enquanto o mínimo é dois, resultando em uma taxa de cinco. Cinco é maior que o limite de balanceamento designado de três para métrica. Como resultado, uma execução de rebalanceamento será agendada na próxima vez em que o temporizador de balanceamento for acionado. Em uma situação como essa, alguma carga é geralmente distribuída para o Nó 3. Como o Gerenciador de Recursos de Cluster do Service Fabric não usa uma abordagem gananciosa, parte da carga também pode ser distribuída para o Nó 2.

Observação

O "Balanceamento" trata duas estratégias diferentes para gerenciar a carga em seu cluster. É a estratégia padrão que o Gerenciador de Recursos de Cluster usa para distribuir a carga entre os nós no cluster. A outra estratégia é desfragmentação. A desfragmentação é executada durante a mesma execução de balanceamento. As estratégias de balanceamento e desfragmentação podem ser usadas para métricas diferentes dentro do mesmo cluster. Um serviço pode ter métricas de balanceamento e desfragmentação. Para métricas de desfragmentação, a proporção das cargas no cluster aciona o rebalanceamento quando está abaixo do limite de balanceamento.

Ficar abaixo do limite de equilíbrio não é um objetivo explícito. Limites de Balanceamento são apenas um gatilho. Quando balanceamento é executado, o Gerenciador de Recursos de Cluster determina quais melhorias ele pode fazer, se houver alguma. Só porque uma pesquisa de balanceamento é iniciada não significa que nada será movimentado. Às vezes, o cluster é desequilibrado, mas fica muito restrito para corrigir. Como alternativa, os aprimoramentos exigem movimentações muito dispendiosas).

Limites de Atividade

Às vezes, embora os nós estejam relativamente desequilibrados, a quantidade total de carga no cluster é baixa. A falta de carga pode ser um dip transitório, ou porque o cluster é novo e está apenas começando a ser inicializado. Em ambos os casos, talvez não queira gastar tempo o cluster de balanceamento porque não há muito a ser obtido. Se o cluster passou por balanceamento, você gastaria recursos de rede e computação para mover as coisas sem fazer uma diferença absoluta. Para evitar movimentações desnecessárias, há outro controle conhecido como Limites de Atividade. Limites de atividade permite que você especifique algum limite inferior absoluto para a atividade. Se nenhum nó está acima desse limite, balanceamento não é disparado mesmo se o limite de balanceamento é atingido.

Vamos supor que podemos manter nosso Limite de Balanceamento de três para essa métrica. Vamos supor também que temos um Limite de Atividade de 1536. No primeiro caso, embora o cluster esteja desequilibrado pelo Limite de Balanceamento, nenhum nó atende ao Limite de Atividade e, portanto, nada acontece. No exemplo inferior, o Nó 1 está acima do Limite de Atividade. Como o Limite de Balanceamento e o Limite de Atividade para a métrica foram ultrapassados, o balanceamento é agendado. Por exemplo, vamos examinar o diagrama a seguir:

Assim como os Limites de Balanceamento, os Limites de Atividade são definidos por métrica por meio da definição do cluster:

ClusterManifest.xml

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

via ClusterConfig.json para implantações Autônomas ou Template.json para clusters hospedados pelo Azure:

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

Os limites de balanceamento e atividade estão vinculados a uma métrica específica. O balanceamento é disparado somente se o limite de balanceamento e o limite de atividade forem excedidos para a mesma métrica.

Observação

Quando não especificado, o limite de balanceamento para uma métrica é 1 e o limite de atividade é 0. Isso significa que o Gerenciador de Recursos de Cluster tentará manter essa métrica perfeitamente balanceada para qualquer carga fornecida. Se você estiver usando métricas personalizadas, é recomendável definir explicitamente seus próprios limites de balanceamento e atividade para suas métricas.

Balanceamento dos serviços em conjunto

Se o cluster estiver desequilibrado ou não for uma decisão de todo o cluster. No entanto, corrigimos isso movendo réplicas de serviço e instâncias individuais. Isso faz sentido, certo? Se a memória é empilhada em um nó, várias réplicas ou instâncias podem contribuir para ela. Corrigir o desequilíbrio pode exigir a movimentação de qualquer uma das réplicas com monitoração de estado ou instâncias sem monitoração de estado que usam a métrica desequilibrada.

Ocasionalmente, no entanto, um serviço que não estava desequilibrado é movido (lembre-se da discussão sobre pesos local e global anteriormente). Por que um serviço é movido quando todas as métricas desse serviço foram balanceadas? Vejamos um exemplo:

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

Realmente, não há quatro serviços independentes. Temos três serviços relacionados e um que está por conta própria.

Devido a essa cadeia, é possível que um desequilíbrio nas métricas 1 a 4 possa mover as réplicas ou instâncias pertencentes aos serviços 1 a 3. 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, já que mover as réplicas ou instâncias pertencentes ao Serviço 4 não pode fazer absolutamente nada para afetar o equilíbrio das métricas 1-3.

O Gerenciador de Recursos de Cluster descobre automaticamente quais serviços estão relacionados. A adição, remoção ou alteração das métrica para esses serviços pode afetar suas relações. Por exemplo, entre duas execuções de balanceamento o Serviço 2 pode ter sido atualizado para remover a Métrica 2. Isso interrompe a cadeia entre o Serviço 1 e o Serviço 2. Agora, em vez de dois grupos de serviços relacionados, há três:

Balanceamento de um cluster por tipo de nó

Como descrevemos nas seções anteriores, os principais controles de acionamento do rebalanceamento são limiares de atividade, limiares de balanceamento e temporizadores. O Gerenciador de Recursos de Cluster do Service Fabric fornece controle mais granular sobre o acionamento do rebalanceamento com a especificação de parâmetros por tipo de nó e permitindo a movimentação apenas em tipos de nós desbalanceados. O principal benefício do balanceamento por tipo de nó é permitir a melhoria do desempenho em tipos de nó que exigem regras de balanceamento mais rígidas, sem degradação do desempenho em outros tipos de nó. O recurso contém duas partes principais:

• A detecção de desequilíbrio é feita por tipo de nó. O cálculo global do desequilíbrio é calculado anteriormente para cada tipo de nó. Se todos os tipos de nó estiverem balanceados, o CRM não acionará a fase de balanceamento. Caso contrário, se pelo menos um tipo de nó estiver desbalanceado, a fase de balanceamento será necessária.
• O balanceamento move réplicas somente em tipos de nó que estão desbalanceados, outros tipos de nó 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 Gerenciador de Recursos de Cluster do Service Fabric calcula o estado de desequilíbrio para cada tipo de nó. Se pelo menos um tipo de nó estiver desbalanceado, a fase de balanceamento será acionada. A fase de balanceamento não moverá réplicas em tipos de nó que estejam desbalanceados, quando o balanceamento for pausado temporariamente nesses tipos de nó (por exemplo, o intervalo mínimo de balanceamento não passou desde uma fase de balanceamento anterior). A detecção de um estado desbalanceado usa mecanismos comuns já disponíveis para o balanceamento de cluster clássico, mas melhora a granularidade e a flexibilidade da configuração. Os mecanismos usados para balancear por tipo de nó para detectar o desequilíbrio são fornecidos na lista abaixo:

• Os limites de balanceamento métrico por tipo de nó são valores que têm uma função semelhante ao limite de balanceamento definido globalmente usado no balanceamento clássico. A taxa de carga de métrica mínima e máxima é calculada para cada tipo de nó. Se essa proporção de um tipo de nó for maior do que o limite de balanceamento definido do tipo de nó, o tipo de nó será marcado como desbalanceado. Para obter mais detalhes sobre a configuração de limites de atividade métrica por tipo de nó, verifique a seção limites de balanceamento por tipo de nó.
• Os limites de atividade métrica por tipo de nó são valores que têm uma função semelhante ao limite de atividade definido globalmente usado no balanceamento clássico. A carga métrica máxima é calculada para cada tipo de nó. Se a carga máxima de um tipo de nó for maior que o limite de atividade definido para esse tipo de nó, o tipo de nó será marcado como desbalanceado. Para obter mais detalhes sobre a configuração de limites de atividade métrica por tipo de nó, verifique a seção limites de atividade por tipo de nó.
• 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 Gerenciador de Recursos de Cluster preserva o carimbo de data/hora do último balanceamento. Duas fases de balanceamento consecutivas não puderam ser executadas em um tipo de nó dentro do intervalo mínimo de balanceamento definido. Para obter mais detalhes sobre a configuração do intervalo de balanceamento mínimo por tipo de nó, verifique a seção intervalo mínimo de balanceamento por tipo de nó.

Descrever o balanceamento por tipo de nó

Para habilitar o balanceamento por tipo de nó, o parâmetro SeparateBalancingStrategyPerNodeType precisa ser habilitado em um manifesto de cluster. Além disso, o recurso de subclustering também precisa ser habilitado. Exemplo de uma seção PlacementAndLoadBalancing do manifesto do cluster para habilitar o recurso:

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

ClusterConfig.json para implantações autônomas ou Template.json para clusters hospedados do Azure:

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

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

• Limites de balanceamento métrico por tipo de nó
• Limites de atividade métrica por tipo de nó
• Intervalo mínimo de balanceamento por tipo de nó

Limites de balanceamento por tipo de nó

O limite de balanceamento métrico pode ser definido por tipo de nó para aumentar a granularidade da configuração de balanceamento. Os limites de balanceamento têm o tipo de ponto flutuante, uma vez que representam o limite para a razão entre o valor de carga máximo e mínimo dentro de um determinado tipo de nó. Os limites de balanceamento são definidos na seçã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 limite de balanceamento de uma métrica não estiver definido para um tipo de nó, o limite herdará o valor do limite de balanceamento de métrica definido globalmente na seção PlacementAndLoadBalancing. Caso contrário, se o limite de balanceamento para uma métrica não for definido nem para um tipo de nó nem globalmente em uma seção PlacementAndLoadBalancing o limite terá o valor padrão de um.

Limites de atividade por tipo de nó

O limite de atividade métrica pode ser definido por tipo de nó para aumentar a granularidade da configuração de balanceamento. Os limites de atividade têm o tipo inteiro, pois representam o limite para o valor máximo de carga dentro de um determinado tipo de nó. Os limites de atividade são definidos na seçã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 limite de atividade de uma métrica não estiver definido para um tipo de nó, o limite herdará o valor do limite de atividade da métrica definido globalmente na seção PlacementAndLoadBalancing. Caso contrário, se o limite de atividade para uma métrica não for definido nem para um tipo de nó nem globalmente em uma seção PlacementAndLoadBalancing o limite terá o valor padrão de zero.

Intervalo mínimo de balanceamento por tipo de nó

Um intervalo mínimo de balanceamento pode ser definido por tipo de nó para aumentar a granularidade da configuração de balanceamento. O intervalo de balanceamento mínimo tem o tipo inteiro, pois representa a quantidade mínima de tempo que deve passar antes de duas rodadas de balanceamento consecutivas em um mesmo tipo de nó. O intervalo mínimo de balanceamento é definido na seçã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 for definido para um tipo de nó, o intervalo herdará o valor do intervalo de balanceamento mínimo definido globalmente na seção PlacementAndLoadBalancing. Caso contrário, se o intervalo mínimo não for definido nem para um tipo de nó nem globalmente em uma seção PlacementAndLoadBalancing o intervalo mínimo terá o valor padrão de zero o que indica que a pausa entre rodadas de balanceamento consecutivas não é necessária.

Exemplos

Exemplo 1

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

O cliente detectou que cargas de trabalho de dois tipos de nó têm necessidades de balanceamento diferentes e decidiu definir limites de balanceamento e atividade diferentes por tipo de nó. O limite de balanceamento do tipo de nó A é de 2.5 e o limite de atividade é de 50. Para o tipo de nó B, o cliente define o limite de balanceamento como 1.2 e o limite de atividade como 400.

Durante a detecção de desequilíbrio para o cluster neste exemplo, ambos os tipos de nó violam o limite de atividade. A carga máxima do nó tipo A de 300 é superior ao limite de atividade definido de 50. A carga máxima do tipo de nó B de 700 é superior ao limite de atividade definido de 400. O tipo de nó A viola os critérios de limite de balanceamento, uma vez que a relação atual de carga máxima e mínima é de 3 e o limite de balanceamento é de 2.5. Ao contrário, o tipo de nó B não viola os critérios de limite de balanceamento, uma vez que a taxa atual de carga máxima e mínima para esse tipo de nó é de 1.2, mas o limite de balanceamento é de 1.4. O balanceamento é necessário apenas para réplicas no tipo de nó A, e o único conjunto de réplicas que será qualificado 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 relatam uma mesma métrica e são divididos entre esses tipos de nó, portanto, as estatísticas de carga são diferentes para eles. No exemplo, o tipo de nó A tem carga máxima de 600 e mínima de 100, o tipo de nó B tem carga máxima de 900 e carga mínima de 100, e o tipo de nó C tem carga máxima de 600 e carga mínima de 300:

O cliente detectou que as cargas de trabalho desses tipos de nó têm necessidades de balanceamento diferentes e decidiu definir limites de balanceamento e atividade diferentes por tipo de nó. O limite de balanceamento do tipo de nó A é de 5 e o limite de atividade é de 700. Para o tipo de nó B, o cliente define o limite de balanceamento como 10 e o limite de atividade como 200. Para o tipo de nó C, o cliente define o limite de balanceamento como 2 e o limite de atividade como 300.

A carga máxima do tipo de nó A de 600 é menor do que o limite de atividade definido de 700, portanto, o tipo de nó A não será balanceado. A carga máxima do tipo de nó B de 900 é superior ao limite de atividade definido de 200. O tipo de nó B viola os critérios de limite de atividade. A carga máxima do tipo de nó C de 600 é maior do que o limite de atividade definido de 300. O tipo de nó C viola os critérios de limite de atividade. O tipo de nó B não viola os critérios de limite de balanceamento, uma vez que a proporção atual de carga máxima e mínima para esse tipo de nó é de 9, mas o limite de balanceamento é de 10. O tipo de nó C viola os critérios de limite de balanceamento, uma vez que a relação atual de carga máxima e mínima é de 2 e o limite de balanceamento é de 2. O balanceamento é necessário apenas para réplicas no tipo de nó C, e o único conjunto de réplicas que será qualificado para movimentos durante a fase de balanceamento são réplicas colocadas no tipo de nó C.

Próximas etapas

• As métricas são como o Gerenciador de Recursos de Cluster do Service Fabric gerencia o consumo e a capacidade no cluster. Para saber mais sobre métricas e como configurá-las, confira o artigo métricas
• O Custo de Movimento é uma forma de sinalizar para o Gerenciador de Recursos de Cluster que a movimentação de determinados serviços é mais cara do que para outros. Para obter mais informações sobre o custo de movimento, consulte o artigo custo de movimento
• O Resource Manager do Cluster tem várias limitações que você pode configurar para diminuir a variação no cluster. Eles normalmente não são necessários, mas se você precisar deles, você pode aprender sobre eles o artigo limitação avançada
• O Gerenciador de Recursos de Cluster pode reconhecer e manipular subclustering. O subclustering pode surgir quando você usa restrições de posicionamento e balanceamento. Para saber como o subclustering pode afetar o balanceamento e como você pode lidar com ele, consulte o artigo subclustering