Integração do gestor de recursos do cluster com a gestão de clusters do Service Fabric

Artigo
06/01/2023

O Cluster do Service Fabric Resource Manager não gera atualizações no Service Fabric, mas está envolvido. A primeira forma de o Cluster Resource Manager ajuda com a gestão é ao controlar o estado pretendido do cluster e os serviços dentro do mesmo. O cluster Resource Manager envia relatórios de estado de funcionamento quando não consegue colocar o cluster na configuração pretendida. Por exemplo, se não existir capacidade suficiente, o Cluster Resource Manager envia avisos de estado de funcionamento e erros que indiquem o problema. Outra parte da integração tem a ver com o funcionamento das atualizações. O Cluster Resource Manager altera ligeiramente o seu comportamento durante as atualizações.

Integração do estado de funcionamento

O Cluster Resource Manager controla constantemente as regras que definiu para colocar os seus serviços. Também controla a capacidade restante para cada métrica nos nós e no cluster e no cluster como um todo. Se não conseguir satisfazer essas regras ou se não existir capacidade suficiente, são emitidos avisos de estado de funcionamento e erros. Por exemplo, se um nó estiver acima da capacidade e o cluster Resource Manager tentará corrigir a situação ao mover os serviços. Se não conseguir corrigir a situação, emite um aviso de estado de funcionamento que indica que nó está acima da capacidade e para que métricas.

Outro exemplo dos avisos de estado de funcionamento do Resource Manager são as violações das restrições de colocação. Por exemplo, se tiver definido uma restrição de colocação (como “NodeColor == Blue”) e o Resource Manager detetar uma violação dessa restrição, emitirá um aviso de estado de funcionamento. Isto aplica-se às restrições personalizadas e às restrições predefinidas (como as restrições Domínio de Falha e Domínio de Atualização).

Eis um exemplo de um desses relatórios de estado de funcionamento. Neste caso, o relatório de estado de funcionamento destina-se a uma das partições do serviço de sistema. A mensagem de estado de funcionamento indica que as réplicas dessa partição são temporariamente embaladas em poucos Domínios de Atualização.

PS C:\Users\User > Get-ServiceFabricPartitionHealth -PartitionId '00000000-0000-0000-0000-000000000001'


PartitionId           : 00000000-0000-0000-0000-000000000001
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='System.PLB', Property='ReplicaConstraintViolation_UpgradeDomain', HealthState='Warning', ConsiderWarningAsError=false.

ReplicaHealthStates   :
                        ReplicaId             : 130766528804733380
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577821
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528854889931
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577822
                        AggregatedHealthState : Ok

                        ReplicaId             : 130837073190680024
                        AggregatedHealthState : Ok

HealthEvents          :
                        SourceId              : System.PLB
                        Property              : ReplicaConstraintViolation_UpgradeDomain
                        HealthState           : Warning
                        SequenceNumber        : 130837100116930204
                        SentAt                : 8/10/2015 7:53:31 PM
                        ReceivedAt            : 8/10/2015 7:53:33 PM
                        TTL                   : 00:01:05
                        Description           : The Load Balancer has detected a Constraint Violation for this Replica: fabric:/System/FailoverManagerService Secondary Partition 00000000-0000-0000-0000-000000000001 is
                        violating the Constraint: UpgradeDomain Details: UpgradeDomain ID -- 4, Replica on NodeName -- Node.8 Currently Upgrading -- false Distribution Policy -- Packing
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : Ok->Warning = 8/10/2015 7:13:02 PM, LastError = 1/1/0001 12:00:00 AM

Eis o que esta mensagem de estado de funcionamento nos está a dizer:

Todas as réplicas estão em bom estado de funcionamento: cada uma tem AggregatedHealthState : Ok
A restrição de distribuição de Domínio de Atualização está a ser violada. Isto significa que um Domínio de Atualização específico tem mais réplicas desta partição do que deveria.
Que nó contém a réplica que causa a violação. Neste caso, é o nó com o nome Node.8
Se está atualmente a ocorrer uma atualização para esta partição ("A atualizar atualmente -- false")
A política de distribuição para este serviço: "Política de Distribuição – Empacotamento". Isto é regido pela RequireDomainDistributionpolítica de colocação. A embalagem indica que, neste caso, a DomainDistribution não era necessária, pelo que sabemos que a política de colocação não foi especificada para este serviço.
Quando o relatório ocorreu - 10/08/2015 19:13:02

Informações como esta permitem alertas. Pode utilizar alertas em produção para saber que algo correu mal. Os alertas também são utilizados para detetar e parar atualizações incorretas. Neste caso, gostaríamos de ver se conseguimos perceber porque é que o Resource Manager teve de empacotar as réplicas para o Domínio de Atualização. Normalmente, a embalagem é transitória porque os nós nos outros Domínios de Atualização estavam inativos, por exemplo.

Digamos que o Cluster Resource Manager está a tentar colocar alguns serviços, mas não existem soluções que funcionem. Quando os serviços não podem ser colocados, normalmente é por um dos seguintes motivos:

Alguma condição transitória impossibilitou a colocação correta desta instância ou réplica de serviço
Os requisitos de colocação do serviço não são insatisfaíveis.

Nestes casos, os relatórios de estado de funcionamento do Cluster Resource Manager ajudá-lo a determinar o motivo pelo qual o serviço não pode ser colocado. Chamamos a este processo a sequência de eliminação de restrições. Durante o mesmo, o sistema percorre as restrições configuradas que afetam o serviço e regista o que eliminam. Desta forma, quando os serviços não podem ser colocados, pode ver quais os nós que foram eliminados e porquê.

Tipos de restrição

Vamos falar sobre cada uma das diferentes restrições nestes relatórios de estado de funcionamento. Verá mensagens de estado de funcionamento relacionadas com estas restrições quando não for possível colocar réplicas.

ReplicaExclusionStatic e ReplicaExclusionDynamic: estas restrições indicam que uma solução foi rejeitada porque dois objetos de serviço da mesma partição teriam de ser colocados no mesmo nó. Isto não é permitido porque, em seguida, a falha desse nó afetaria excessivamente essa partição. ReplicaExclusionStatic e ReplicaExclusionDynamic são quase a mesma regra e as diferenças não importam. Se estiver a ver uma sequência de eliminação de restrições que contém a restrição ReplicaExclusionStatic ou ReplicaExclusionDynamic, o cluster Resource Manager considera que não existem nós suficientes. Isto requer que as soluções restantes utilizem estas colocações inválidas, que não são permitidas. Normalmente, as outras restrições na sequência irão indicar-nos por que motivo os nós estão a ser eliminados.
PlacementConstraint: se vir esta mensagem, significa que eliminámos alguns nós porque não correspondem às restrições de colocação do serviço. Vamos analisar as restrições de colocação atualmente configuradas como parte desta mensagem. Isto é normal se tiver uma restrição de colocação definida. No entanto, se a restrição de colocação estiver a causar incorretamente a eliminação de demasiados nós, é assim que notaria.
NodeCapacity: esta restrição significa que o Cluster Resource Manager não conseguiu colocar as réplicas nos nós indicados porque isso as colocaria acima da capacidade.
Afinidade: esta restrição indica que não conseguimos colocar a réplica nos nós afetados, uma vez que causaria uma violação da restrição de afinidade. Veja este artigo para obter mais informações sobre afinidade
FaultDomain e UpgradeDomain: esta restrição elimina os nós se colocar a réplica nos nós indicados causar a embalagem num determinado domínio de falha ou atualização. Vários exemplos que discutem esta restrição são apresentados no tópico sobre restrições de domínio de falha e atualização e comportamento resultante
PreferredLocation: normalmente, não deverá ver esta restrição a remover nós da solução, uma vez que é executada como uma otimização por predefinição. A restrição de localização preferencial também está presente durante as atualizações. Durante a atualização, é utilizado para mover os serviços de volta para o local onde estavam quando a atualização foi iniciada.

Nós da Lista de Bloqueios

Outra mensagem de estado de funcionamento que o Cluster Resource Manager relatórios é quando os nós são bloqueados na lista de bloqueios. Pode considerar a lista de bloqueios como uma restrição temporária que é aplicada automaticamente. Os nós são bloqueados quando ocorrem falhas repetidas ao iniciar instâncias desse tipo de serviço. Os nós são bloqueados numa base por tipo de serviço. Um nó pode estar bloqueado para um tipo de serviço, mas não para outro.

Verá frequentemente o início da lista de bloqueios durante o desenvolvimento: alguns erros fazem com que o anfitrião do serviço falhe no arranque, o Service Fabric tenta criar o anfitrião do serviço algumas vezes e a falha continua a ocorrer. Após algumas tentativas, o nó é bloqueado e o cluster Resource Manager tentará criar o serviço noutro local. Se essa falha continuar a ocorrer em vários nós, é possível que todos os nós válidos no cluster sejam bloqueados. A lista de bloqueios também pode remover tantos nós que não é suficiente para iniciar o serviço com êxito para satisfazer a escala pretendida. Normalmente, verá erros ou avisos adicionais do Cluster Resource Manager indicando que o serviço está abaixo da contagem de instâncias ou réplicas pretendidas, bem como mensagens de estado de funcionamento que indicam qual é a falha que está a levar à lista de bloqueios.

A lista de bloqueios não é uma condição permanente. Após alguns minutos, o nó é removido da lista de bloqueios e o Service Fabric poderá ativar novamente os serviços nesse nó. Se os serviços continuarem a falhar, o nó será novamente bloqueado para esse tipo de serviço.

Prioridades de restrição

Aviso

A alteração das prioridades de restrição não é recomendada e pode ter efeitos adversos significativos no cluster. As informações abaixo são fornecidas para referência das prioridades de restrição predefinidas e do respetivo comportamento.

Com todas estas restrições, pode ter pensado em "Olá , acho que as restrições de domínio de falha são a coisa mais importante no meu sistema. Para garantir que a restrição de domínio de falha não é violada, estou disposto a violar outras restrições."

As restrições podem ser configuradas com diferentes níveis de prioridade. Esses avisos são:

"hard" (0)
"soft" (1)
"otimização" (2)
"off" (-1).

A maioria das restrições são configuradas como restrições rígidas por predefinição.

A alteração da prioridade das restrições é invulgar. Houve alturas em que as prioridades de restrição precisavam de ser alteradas, normalmente para contornar outro erro ou comportamento que estava a afetar o ambiente. Geralmente, a flexibilidade da infraestrutura de prioridade de restrição tem funcionado muito bem, mas não é necessária com frequência. Na maioria das vezes, tudo está nas suas prioridades predefinidas.

Os níveis de prioridade não significam que uma determinada restrição será violada, nem que será sempre cumprida. As prioridades de restrição definem uma ordem pela qual as restrições são impostas. As prioridades definem as desvantagens quando é impossível satisfazer todas as restrições. Normalmente, todas as restrições podem ser satisfeitas, a menos que haja outra coisa a acontecer no ambiente. Alguns exemplos de cenários que levarão a violações de restrições são restrições conflituosas ou um grande número de falhas simultâneas.

Em situações avançadas, pode alterar as prioridades de restrição. Por exemplo, digamos que queria garantir que a afinidade seria sempre violada quando necessário para resolver problemas de capacidade do nó. Para tal, pode definir a prioridade da restrição de afinidade como "suave" (1) e deixar a restrição de capacidade definida como "dura" (0).

Os valores de prioridade predefinidos para as diferentes restrições são especificados na seguinte configuração:

ClusterManifest.xml

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PlacementConstraintPriority" Value="0" />
            <Parameter Name="CapacityConstraintPriority" Value="0" />
            <Parameter Name="AffinityConstraintPriority" Value="0" />
            <Parameter Name="FaultDomainConstraintPriority" Value="0" />
            <Parameter Name="UpgradeDomainConstraintPriority" Value="1" />
            <Parameter Name="PreferredLocationConstraintPriority" Value="2" />
        </Section>

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

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PlacementConstraintPriority",
          "value": "0"
      },
      {
          "name": "CapacityConstraintPriority",
          "value": "0"
      },
      {
          "name": "AffinityConstraintPriority",
          "value": "0"
      },
      {
          "name": "FaultDomainConstraintPriority",
          "value": "0"
      },
      {
          "name": "UpgradeDomainConstraintPriority",
          "value": "1"
      },
      {
          "name": "PreferredLocationConstraintPriority",
          "value": "2"
      }
    ]
  }
]

Domínio de falha e restrições de domínio de atualização

O cluster Resource Manager quer manter os serviços distribuídos entre domínios de falha e atualização. Modela isto como uma restrição dentro do motor do Cluster Resource Manager. Para obter mais informações sobre como são utilizadas e o respetivo comportamento específico, consulte o artigo sobre a configuração do cluster.

O cluster Resource Manager poderá ter de empacotar algumas réplicas num domínio de atualização para lidar com atualizações, falhas ou outras violações de restrição. Normalmente, a colocação em domínios de falha ou atualização ocorre apenas quando existem várias falhas ou outras alterações no sistema que impedem a colocação correta. Se quiser evitar a embalagem mesmo nestas situações, pode utilizar a RequireDomainDistributionpolítica de colocação. Tenha em atenção que fazê-lo pode afetar a disponibilidade e a fiabilidade do serviço como um efeito secundário, por isso, considere-o cuidadosamente.

Se o ambiente estiver configurado corretamente, todas as restrições são totalmente respeitadas, mesmo durante as atualizações. O mais importante é que o Cluster Resource Manager está atento às suas restrições. Quando deteta uma violação, comunica-a imediatamente e tenta corrigir o problema.

A restrição de localização preferencial

A restrição PreferredLocation é um pouco diferente, uma vez que tem duas utilizações diferentes. Uma utilização desta restrição é durante as atualizações da aplicação. O Cluster Resource Manager gere automaticamente esta restrição durante as atualizações. É utilizado para garantir que, quando as atualizações estiverem concluídas, as réplicas regressam às respetivas localizações iniciais. A outra utilização da restrição PreferredLocation destina-se à PreferredPrimaryDomain política de colocação. Ambas são otimizações e, por conseguinte, a restrição PreferredLocation é a única restrição definida como "Otimização" por predefinição.

Atualizações

O cluster Resource Manager também ajuda durante as atualizações de aplicações e clusters, durante as quais tem duas tarefas:

confirme que as regras do cluster não estão comprometidas
tente ajudar a atualizar sem problemas

Continuar a impor as regras

A principal coisa a ter em conta é que as regras – as restrições estritas, como as restrições de colocação e as capacidades – continuam a ser aplicadas durante as atualizações. As restrições de colocação garantem que as cargas de trabalho só são executadas onde podem fazê-lo, mesmo durante as atualizações. Quando os serviços são altamente restritos, as atualizações podem demorar mais tempo. Quando o serviço ou o respetivo nó for desativado para uma atualização, poderão existir poucas opções para onde pode ir.

Substituições inteligentes

Quando uma atualização é iniciada, o Resource Manager tira um instantâneo da disposição atual do cluster. À medida que cada Domínio de Atualização é concluído, tenta devolver os serviços que estavam nesse Domínio de Atualização para a disposição original. Desta forma, existem, no máximo, duas transições para um serviço durante a atualização. Há uma mudança para fora do nó afetado e outra volta a entrar. Devolver o cluster ou serviço à forma como estava antes da atualização também garante que a atualização não afeta o esquema do cluster.

Redução da taxa de abandono

Durante as atualizações, o cluster Resource Manager também desativa o equilíbrio. A prevenção do equilíbrio impede reações desnecessárias à atualização propriamente dita, como mover serviços para nós que foram esvaziados para a atualização. Se a atualização em questão for uma atualização do Cluster, todo o cluster não será equilibrado durante a atualização. As verificações de restrição permanecem ativas, apenas o movimento com base no balanceamento proativo das métricas está desativado.

Capacidade e atualização em memória intermédia

Geralmente, quer que a atualização seja concluída mesmo que o cluster esteja restrito ou próximo de estar cheio. Gerir a capacidade do cluster é ainda mais importante durante as atualizações do que o habitual. Dependendo do número de domínios de atualização, entre 5 e 20 por cento da capacidade tem de ser migrada à medida que a atualização passa pelo cluster. Esse trabalho tem de ir a algum lado. É aqui que a noção de capacidades em memória intermédia é útil. A capacidade em memória intermédia é respeitada durante o funcionamento normal. O cluster Resource Manager pode preencher nós até à capacidade total (consumindo a memória intermédia) durante as atualizações, se necessário.

Passos seguintes

Comece a partir do início e obtenha uma Introdução ao Cluster do Service Fabric Resource Manager

Share via