Balanceamento do seu cluster do Service Fabric

O Service Fabric Cluster Resource Manager suporta alterações de carga dinâmica, reagindo a adições ou remoções de nós ou serviços. Ele também corrige automaticamente as violações de restrição e reequilibra proativamente o cluster. Mas com que frequência essas ações são tomadas e o que as desencadeia?

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

• Posicionamento – esta etapa lida com a colocação de réplicas com estado ou instâncias sem estado que estejam ausentes. O posicionamento inclui novos serviços e o tratamento de réplicas com estado ou instâncias sem estado que falharam. A exclusão e a eliminação de réplicas ou instâncias são tratadas aqui.
• Verificações de restrição – esta etapa verifica e corrige violações das diferentes restrições de posicionamento (regras) dentro do 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 – este estágio verifica se o rebalanceamento é necessário com base no nível de equilíbrio desejado configurado para diferentes métricas. Em caso afirmativo, tenta encontrar um arranjo no cluster que seja mais equilibrado.

Configurando temporizadores do Gerenciador de Recursos de Cluster

O primeiro conjunto de controles em torno do balanceamento é um conjunto de temporizadores. Esses temporizadores controlam a frequência com que o Gerenciador de Recursos de Cluster examina o cluster e toma ações corretivas.

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

• verifica seu estado e aplica atualizações (como registrar que um nó está inativo) a 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

Exemplos da configuração que rege esses temporizadores estão abaixo:

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 do 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"
      }
    ]
  }
]

Hoje, o Cluster Resource Manager executa apenas uma dessas ações de cada vez, sequencialmente. É por isso que nos referimos a esses temporizadores como "intervalos mínimos" e as ações que são tomadas quando os temporizadores disparam como "definir sinalizadores". Por exemplo, o Gerenciador de Recursos de Cluster cuida de solicitações pendentes para criar serviços antes de equilibrar o cluster. Como você pode ver pelos intervalos de tempo padrão especificados, o Gerenciador de Recursos de Cluster verifica tudo o que precisa fazer 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 algo acontece no cluster. Os temporizadores padrão fornecem alguns lotes, uma vez que muitos dos mesmos tipos de eventos tendem a ocorrer simultaneamente.

Por exemplo, quando os nós falham, eles podem fazê-lo domínios de falha inteiros de cada 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. Fazer isso levaria a explosões de rotatividade.

O Gerenciador de Recursos de Cluster também precisa de algumas informações adicionais para determinar se o cluster está desequilibrado. Para isso, temos duas outras partes de configuração: BalancingThresholds e ActivityThresholds.

Limiares de equilíbrio

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

Os Limites de Balanceamento são definidos por métrica como parte da definição de cluster. Para obter mais informações sobre métricas, confira o artigo sobre 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 do 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 a mínima é dois. Digamos que o limite de equilíbrio para essa métrica seja três. Como a proporção no cluster é 5/2 = 2,5 e que é menor do que o limiar de balanceamento especificado de três, o cluster é equilibrado. Nenhum balanceamento é acionado quando o Gerenciador de Recursos de Cluster é verificado.

No exemplo inferior, a carga máxima em um nó é 10, enquanto a mínima é duas, resultando em uma proporção de cinco. Cinco é maior do que o limiar de equilíbrio designado de três para essa métrica. Como resultado, uma execução de reequilíbrio será agendada na próxima vez 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, alguma carga também pode ser distribuída para o Nó 2.

Ficar abaixo do limite de equilíbrio não é um objetivo explícito. Os Limiares de Equilíbrio são apenas um gatilho. Quando o balanceamento é executado, o Gerenciador de Recursos de Cluster determina quais melhorias ele pode fazer, se houver. Só porque uma pesquisa de equilíbrio é iniciada não significa que nada se move. Às vezes, o cluster é desequilibrado, mas muito restrito para corrigir. Alternativamente, as melhorias exigem movimentos que são muito caros).

Limiares 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 uma queda transitória, ou porque o cluster é novo e está apenas sendo inicializado. Em ambos os casos, você pode não querer gastar tempo equilibrando o cluster porque há pouco a ser ganho. Se o cluster passasse por balanceamento, você gastaria recursos de rede e computação para mover as coisas sem fazer nenhuma grande diferença absoluta . Para evitar movimentos desnecessários, há outro controle conhecido como Limites de Atividade. Os Limites de Atividade permitem especificar algum limite inferior absoluto para a atividade. Se nenhum nó estiver acima desse limite, o balanceamento não será acionado mesmo se o Limite de Balanceamento for atingido.

Digamos que mantenhamos nosso Limiar de Equilíbrio de três para essa métrica. Digamos também que temos um Limiar de Atividade de 1536. No primeiro caso, enquanto o cluster estiver desequilibrado de acordo com o Limite de Balanceamento, nenhum nó atende a esse Limite de Atividade, 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 da métrica são excedidos, o balanceamento é agendado. Como exemplo, vejamos 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 de 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 do Azure:

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

Os limites de balanceamento e de atividade estão vinculados a uma métrica específica - o balanceamento é acionado somente se o Limite de Balanceamento e o Limite de Atividade forem excedidos para a mesma métrica.

Equilibrar os serviços em conjunto

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

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

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

Nós realmente não temos quatro serviços independentes, temos três serviços que estão relacionados e um que está desligado por conta própria.

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

O Gerenciador de Recursos de Cluster descobre automaticamente quais serviços estão relacionados. Adicionar, remover ou alterar as métricas dos serviços pode afetar seus relacionamentos. Por exemplo, entre duas execuções de balanceamento o Serviço 2 pode ter sido atualizado para remover a Métrica 2. Isso quebra 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ó

Como descrevemos nas seções anteriores, os principais controles para acionar o reequilíbrio são os limites de atividade, os limites de balanceamento e os 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ó desequilibrados. 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 deteção de desequilíbrio é feita por tipo de nó. Anteriormente, o cálculo global do desequilíbrio é calculado para cada tipo de nó. Se todos os tipos de nó estiverem equilibrados, o CRM não acionará a fase de balanceamento. Caso contrário, se pelo menos um tipo de nó estiver desequilibrado, a fase de balanceamento será necessária.
• O balanceamento move réplicas apenas em tipos de nó que estão desequilibrados, 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 desequilibrado, a fase de balanceamento será acionada. A fase de balanceamento não moverá réplicas em tipos de nó desequilibrados, quando o balanceamento estiver temporariamente pausado nesses 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 usa mecanismos comuns já disponíveis para o balanceamento clássico de cluster, mas melhora a granularidade e a flexibilidade da configuração. Os mecanismos usados para balancear por tipo de nó para detetar desequilíbrios são fornecidos na lista abaixo:

• Os limiares de balanceamento métrico por tipo de nó são valores que têm um papel semelhante ao limiar de balanceamento definido globalmente usado no balanceamento clássico. A relação entre carga 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 desequilibrado. Para obter mais detalhes sobre a configuração de limites de atividade métrica por tipo de nó, verifique a seção de limites de balanceamento por tipo de nó.
• Os limiares de atividade métrica por tipo de nó são valores que têm um papel semelhante ao limiar 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 do que o limite de atividade definido para esse tipo de nó, o tipo de nó será marcado como desequilibrado. Para obter mais detalhes sobre a configuração de limites de atividade métrica por tipo de nó, verifique a seçã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 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 de manifesto de 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"
      },
    ]
  }
]

Como descrevemos 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:

• Limiares 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ó

Limiares 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 limiares de balanceamento têm o tipo de ponto flutuante, uma vez que representam o limite para a relação entre o valor de carga máxima e mínima dentro de um tipo de nó específico. 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 para uma métrica não estiver definido para um tipo de nó, o limite herdará o valor do limite de balanceamento métrico definido globalmente na seção PlacementAndLoadBalbalancing . Caso contrário, se o limite de balanceamento para uma métrica não estiver definido nem para um tipo de nó nem globalmente em uma seção PlacementAndLoadBaling , 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 tipo inteiro, uma vez que representam o limite para o valor de carga máxima dentro de um tipo de nó específico. 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 para 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 PlacementAndLoadBalbalancing . Caso contrário, se o limite de atividade para uma métrica não estiver definido nem para um tipo de nó nem globalmente em uma seção PlacementAndLoadBaling , o limite terá valor padrão de zero.

Intervalo mínimo de balanceamento por tipo de nó

O 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 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 PlacementAndLoadBaling . Caso contrário, se o intervalo mínimo não for definido nem para um tipo de nó nem globalmente em uma seção PlacementAndLoadBaling, o intervalo mínimo terá valor padrão 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ós, portanto, as estatísticas de carga são diferentes para eles. No exemplo, o nó tipo A tem carga máxima de 300 e mínima de 100, e o nó tipo B tem carga máxima de 700 e carga mínima de 500:

O cliente detetou 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 limiar de balanceamento do nó tipo A é 2,5 e o limiar de atividade é 50. Para o nó tipo B, o cliente define o limite de balanceamento como 1,2 e o limite de atividade como 400.

Durante a deteçã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 limiar de atividade definido de 50. A carga máxima do nó do tipo B de 700 é superior ao limiar 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 é 3 e o limiar de balanceamento é 2,5. Ao contrário, o tipo de nó B não viola os critérios de limite de balanceamento, uma vez que a relação atual de carga máxima e mínima para esse tipo de nó é 1,2, mas o limite de balanceamento é 1,4. O balanceamento é necessário apenas para réplicas no nó tipo A, e o único conjunto de réplicas que será elegível para movimentos durante a fase de balanceamento são réplicas colocadas no nó tipo 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ós, portanto, as estatísticas de carga são diferentes para eles. No exemplo, o nó tipo A tem carga máxima de 600 e mínima de 100, o nó tipo B tem carga máxima de 900 e carga mínima de 100, e nó tipo C tem carga máxima de 600 e carga mínima de 300:

O cliente detetou 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 limiar de balanceamento do nó tipo A é 5 e o limiar de atividade é 700. Para o nó tipo B, o cliente define o limite de balanceamento como 10 e o limite de atividade como 200. Para o nó tipo C, o cliente define o limite de balanceamento como 2 e o limite de atividade como 300.

A carga máxima do nó tipo A de 600 é inferior ao limite de atividade definido de 700, portanto, o tipo de nó A não será balanceado. A carga máxima do nó do tipo B de 900 é superior ao limiar de atividade definido de 200. O nó tipo B viola os critérios de limite de atividade. A carga máxima do nó tipo C de 600 é superior ao limiar de atividade definido de 300. O nó tipo C viola os critérios de limite de atividade. O nó tipo B não viola os critérios de limite de balanceamento, uma vez que a relação atual de carga máxima e mínima para esse tipo de nó é 9, mas o limite de balanceamento é 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 é 2 e o limite de balanceamento é 2. O balanceamento é necessário apenas para réplicas no nó tipo C, e o único conjunto de réplicas que será elegível para movimentos durante a fase de balanceamento são réplicas colocadas no nó tipo C.

Próximos passos

• 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 sobre métricas
• O Custo de Movimento é uma forma de sinalizar ao Cluster Resource Manager que determinados serviços são mais caros para mover do que outros. Para obter mais informações sobre o custo do movimento, consulte o artigo sobre o custo do movimento
• O Gerenciador de Recursos de Cluster tem vários aceleradores que você pode configurar para diminuir a rotatividade no cluster. Eles normalmente não são necessários, mas se você precisar deles, você pode aprender sobre eles o artigo de limitação avançada
• O Cluster Resource Manager 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 sobre subclustering