Partilhar via

Integração do gerenciador de recursos de cluster com o gerenciamento de cluster do Service Fabric

  • Artigo

O Gerenciador de Recursos de Cluster do Service Fabric não gera atualizações no Service Fabric, mas está envolvido. A primeira maneira que o Gerenciador de Recursos de Cluster ajuda com o gerenciamento é rastreando o estado desejado do cluster e os serviços dentro dele. O Gerenciador de Recursos de Cluster envia relatórios de integridade quando não pode colocar o cluster na configuração desejada. Por exemplo, se não houver capacidade suficiente, o Gerenciador de Recursos de Cluster enviará avisos de integridade e erros indicando o problema. Outra parte da integração tem a ver com a forma como as atualizações funcionam. O Gerenciador de Recursos de Cluster altera ligeiramente seu comportamento durante as atualizações.

Integração na saúde

O Cluster Resource Manager rastreia constantemente as regras que você definiu para colocar seus serviços. Ele também rastreia a capacidade restante para cada métrica nos nós e no cluster e no cluster como um todo. Se não conseguir cumprir essas regras ou se não houver capacidade suficiente, são emitidos avisos de saúde e erros. Por exemplo, se um nó estiver acima da capacidade e o Gerenciador de Recursos de Cluster tentará corrigir a situação movendo serviços. Se não conseguir corrigir a situação, emite um aviso de saúde indicando qual nó está acima da capacidade e para quais métricas.

Outro exemplo dos avisos de integridade do Gerenciador de Recursos são as violações das restrições de posicionamento. Por exemplo, se você definiu uma restrição de posicionamento (como “NodeColor == Blue”) e o Gerenciador de Recursos deteta uma violação dessa restrição, ele emite um aviso de integridade. Isso é verdadeiro para restrições personalizadas e as restrições padrão (como as restrições Domínio de Falha e Domínio de Atualização).

Aqui está um exemplo de um desses relatórios de saúde. Nesse caso, o relatório de integridade é para uma das partições do serviço do sistema. A mensagem de integridade indica que as réplicas dessa partição estão temporariamente compactadas 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

Aqui está o que esta mensagem de saúde está nos dizendo é:

  1. Todas as réplicas em si são saudáveis: cada uma tem AggregatedHealthState : Ok
  2. A restrição de distribuição Atualizar domínio está sendo violada no momento. Isso significa que um determinado Domínio de Atualização tem mais réplicas dessa partição do que deveria.
  3. Qual nó contém a réplica que causa a violação. Neste caso, é o nó com o nome Node.8
  4. Se uma atualização está acontecendo atualmente para esta partição ("Atualmente atualizando -- false")
  5. A política de distribuição para este serviço: "Política de Distribuição -- Embalagem". Isso é regido RequireDomainDistribution pela política de colocação. A embalagem indica que, neste caso, DomainDistribution não era necessário, portanto, sabemos que a política de posicionamento não foi especificada para este serviço.
  6. Quando a reportagem aconteceu - 10/08/2015 19:13:02

Informações como esta permitem alertar. Você pode usar alertas na produção para informar que algo deu errado. Os alertas também são usados para detetar e interromper atualizações incorretas. Nesse caso, gostaríamos de ver se conseguimos descobrir por que o Gerenciador de Recursos teve que empacotar as réplicas no 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á tentando colocar alguns serviços, mas não há soluções que funcionem. Quando os serviços não podem ser colocados, geralmente é por um dos seguintes motivos:

  1. Algumas condições transitórias impossibilitaram a colocação correta dessa instância de serviço ou réplica
  2. Os requisitos de colocação do serviço são insatisfatórios.

Nesses casos, os relatórios de integridade do Gerenciador de Recursos de Cluster ajudam a determinar por que o serviço não pode ser colocado. Chamamos esse processo de sequência de eliminação de restrições. Durante ele, o sistema percorre as restrições configuradas que afetam o serviço e registra o que elas eliminam. Dessa forma, quando os serviços não puderem ser colocados, você poderá ver quais nós foram eliminados e por quê.

Tipos de restrição

Vamos falar sobre cada uma das diferentes restrições nesses relatórios de saúde. Você verá mensagens de integridade relacionadas a essas restrições quando as réplicas não puderem ser colocadas.

  • ReplicaExclusionStatic e ReplicaExclusionDynamic: essas restrições indicam que uma solução foi rejeitada porque dois objetos de serviço da mesma partição teriam que ser colocados no mesmo nó. Isso não é permitido porque, então, a falha desse nó afetaria excessivamente essa partição. ReplicaExclusionStatic e ReplicaExclusionDynamic são quase a mesma regra e as diferenças realmente não importam. Se você estiver vendo uma sequência de eliminação de restrição contendo a restrição ReplicaExclusionStatic ou ReplicaExclusionDynamic, o Gerenciador de Recursos de Cluster achará que não há nós suficientes. Isso requer soluções restantes para usar esses posicionamentos inválidos, que não são permitidos. As outras restrições na sequência geralmente nos dirão por que os nós estão sendo eliminados em primeiro lugar.
  • PlacementConstraint: Se você vir essa mensagem, isso significa que eliminamos alguns nós porque eles não correspondiam às restrições de posicionamento do serviço. Rastreamos as restrições de posicionamento configuradas atualmente como parte desta mensagem. Isso é normal se você tiver uma restrição de posicionamento definida. No entanto, se a restrição de posicionamento estiver fazendo com que muitos nós sejam eliminados incorretamente, é assim que você notaria.
  • NodeCapacity: essa restrição significa que o Gerenciador de Recursos de Cluster não pôde colocar as réplicas nos nós indicados porque isso as colocaria acima da capacidade.
  • Afinidade: essa restrição indica que não foi possível colocar a réplica nos nós afetados, pois isso causaria uma violação da restrição de afinidade. Mais informações sobre afinidade estão neste artigo
  • FaultDomain e UpgradeDomain: essa restrição elimina nós se colocar a réplica nos nós indicados causar empacotamento em uma falha específica ou domínio de atualização. Vários exemplos discutindo essa restrição são apresentados no tópico sobre restrições de domínio de falha e atualização e comportamento resultante
  • PreferredLocation: Normalmente, você não deve ver essa restrição removendo nós da solução, pois ela é executada como uma otimização por padrão. A restrição de local preferencial também está presente durante as atualizações. Durante a atualização, ele é usado para mover os serviços de volta para onde estavam quando a atualização foi iniciada.

Nós de lista de bloqueio

Outra mensagem de integridade que o Gerenciador de Recursos de Cluster relata é quando os nós estão bloqueados. Você pode pensar na lista de bloqueio como uma restrição temporária que é aplicada automaticamente para você. Os nós são bloqueados quando enfrentam falhas repetidas ao executar instâncias desse tipo de serviço. Os nós são bloqueados por tipo de serviço. Um nó pode ser bloqueado para um tipo de serviço, mas não para outro.

Você verá a lista de bloqueio entrar em ação com frequência durante o desenvolvimento: algum bug faz com que seu host de serviço falhe na inicialização, o Service Fabric tenta criar o host de serviço algumas vezes e a falha continua ocorrendo. Após algumas tentativas, o nó é bloqueado e o Gerenciador de Recursos de Cluster tentará criar o serviço em outro lugar. Se essa falha continuar acontecendo em vários nós, é possível que todos os nós válidos no cluster acabem bloqueados. Blocklisting também pode remover tantos nós que não o suficiente pode iniciar com êxito o serviço para atender à escala desejada. Normalmente, você verá erros ou avisos adicionais do Gerenciador de Recursos de Cluster indicando que o serviço está abaixo da réplica ou contagem de instâncias desejada, bem como mensagens de integridade indicando qual é a falha que está levando à lista de bloqueios em primeiro lugar.

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

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 padrão e seu comportamento.

Com todas essas restrições, você pode estar pensando "Ei, 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 seja violada, estou disposto a violar outras restrições."

As restrições podem ser configuradas com diferentes níveis de prioridade. São as seguintes:

  • "difícil" (0)
  • "macio" (1)
  • "Otimização" (2)
  • "desligado" (-1).

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

Alterar a prioridade das restrições é incomum. Houve momentos em que as prioridades de restrição precisaram mudar, geralmente para contornar algum outro bug ou comportamento que estava afetando o ambiente. Geralmente, a flexibilidade da infraestrutura prioritária de restrição tem funcionado muito bem, mas não é necessária com frequência. Na maioria das vezes, tudo está em suas prioridades padrão.

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

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

Os valores de prioridade padrão 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>

via ClusterConfig.json para implantações autônomas ou Template.json para clusters hospedados do 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 Gerenciador de Recursos de Cluster deseja manter os serviços distribuídos entre domínios de falha e atualização. Ele modela isso como uma restrição dentro do mecanismo do Gerenciador de Recursos de Cluster. Para obter mais informações sobre como eles são usados e seu comportamento específico, confira o artigo sobre configuração de cluster.

O Gerenciador de Recursos de Cluster pode precisar empacotar algumas réplicas em um domínio de atualização para lidar com atualizações, falhas ou outras violações de restrição. Empacotar em domínios de falha ou atualização normalmente acontece apenas quando há várias falhas ou outra rotatividade no sistema impedindo o posicionamento correto. Se você deseja evitar a embalagem, mesmo durante essas situações, você pode utilizar a RequireDomainDistribution política de colocação. Observe que isso pode afetar a disponibilidade e a confiabilidade do serviço como um efeito colateral, portanto, considere-o cuidadosamente.

Se o ambiente estiver configurado corretamente, todas as restrições serã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, reporta-a imediatamente e tenta corrigir o problema.

A restrição de local preferencial

A restrição PreferredLocation é um pouco diferente, pois tem dois usos diferentes. Um uso dessa restrição é durante as atualizações de aplicativos. O Gerenciador de Recursos de Cluster gerencia automaticamente essa restrição durante as atualizações. Ele é usado para garantir que, quando as atualizações forem concluídas, as réplicas retornem aos seus locais iniciais. O outro uso da restrição PreferredLocation é para a PreferredPrimaryDomain política de posicionamento. Ambas são otimizações e, portanto, a restrição PreferredLocation é a única restrição definida como "Otimização" por padrão.

Atualizações

O Gerenciador de Recursos de Cluster também ajuda durante atualizações de aplicativos e clusters, durante as quais ele tem dois trabalhos:

  • garantir que as regras do cluster não sejam comprometidas
  • Tente ajudar a atualização a decorrer sem problemas

Continuar a aplicar as regras

A principal coisa a ter em conta é que as regras – as restrições rigorosas, como restrições de colocação e capacidades – ainda são aplicadas durante as atualizações. As restrições de posicionamento garantem que suas cargas de trabalho sejam executadas apenas onde são permitidas, mesmo durante as atualizações. Quando os serviços são altamente restritos, as atualizações podem levar mais tempo. Quando o serviço ou seu nó é derrubado para uma atualização, pode haver poucas opções para onde ele pode ir.

Substituições inteligentes

Quando uma atualização é iniciada, o Gerenciador de Recursos tira um instantâneo da organização atual do cluster. À medida que cada Domínio de Atualização é concluído, ele tenta retornar os serviços que estavam nesse Domínio de Atualização à sua disposição original. Dessa forma, há no máximo duas transições para um serviço durante a atualização. Há um movimento para fora do nó afetado e um movimento de volta para dentro. Retornar o cluster ou serviço para como era antes da atualização também garante que a atualização não afete o layout do cluster.

Redução da rotatividade

Durante as atualizações, o Gerenciador de Recursos de Cluster também desativa o balanceamento. Impedir o balanceamento evita reações desnecessárias à atualização em si, 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 de cluster, todo o cluster não será balanceado durante a atualização. As verificações de restrições permanecem ativas, apenas o movimento baseado no equilíbrio proativo de métricas é desativado.

Capacidade em buffer e upgrade

Geralmente, você deseja que a atualização seja concluída mesmo se o cluster estiver restrito ou próximo da totalidade. Gerenciar a capacidade do cluster é ainda mais importante durante as atualizações do que o normal. Dependendo do número de domínios de atualização, entre 5% e 20% da capacidade deve ser migrada à medida que a atualização passa pelo cluster. Esse trabalho tem de ir para algum lado. É aqui que a noção de capacidades em buffer é útil. A capacidade em buffer é respeitada durante a operação normal. O Gerenciador de Recursos de Cluster pode preencher nós até sua capacidade total (consumindo o buffer) durante as atualizações, se necessário.

Próximos passos