Descrição geral da arquitetura do gestor de recursos do cluster

O Cluster do Service Fabric Resource Manager é um serviço central que é executado no cluster. Gere o estado pretendido dos serviços no cluster, especialmente no que diz respeito ao consumo de recursos e a quaisquer regras de colocação.

Para gerir os recursos no cluster, o Cluster do Service Fabric Resource Manager tem de ter várias informações:

• Que serviços existem atualmente
• Consumo de recursos atual (ou predefinido) de cada serviço
• A capacidade de cluster restante
• A capacidade dos nós no cluster
• A quantidade de recursos consumidos em cada nó

O consumo de recursos de um determinado serviço pode mudar ao longo do tempo e os serviços normalmente preocupam-se com mais do que um tipo de recurso. Em diferentes serviços, podem existir recursos físicos e físicos reais a serem medidos. Os serviços podem controlar métricas físicas, como a memória e o consumo de discos. Normalmente, os serviços podem preocupar-se com métricas lógicas, como "WorkQueueDepth" ou "TotalRequests". As métricas lógicas e físicas podem ser utilizadas no mesmo cluster. As métricas podem ser partilhadas em vários serviços ou ser específicas de um determinado serviço.

Outras considerações

Os proprietários e operadores do cluster podem ser diferentes dos autores de serviços e aplicações ou, no mínimo, são as mesmas pessoas que usam chapéus diferentes. Quando desenvolve a sua aplicação, sabe algumas coisas sobre o que é necessário. Tem uma estimativa dos recursos que irá consumir e de que forma devem ser implementados diferentes serviços. Por exemplo, a camada Web tem de ser executada em nós expostos à Internet, enquanto os serviços de base de dados não devem. Como outro exemplo, os serviços Web são provavelmente restringidos pela CPU e pela rede, enquanto os serviços de camada de dados se preocupam mais com o consumo de memória e disco. No entanto, a pessoa que está a lidar com um incidente de site em direto para esse serviço em produção ou que está a gerir uma atualização para o serviço tem um trabalho diferente para fazer e requer ferramentas diferentes.

Tanto o cluster como os serviços são dinâmicos:

• O número de nós no cluster pode aumentar e diminuir
• Nós de diferentes tamanhos e tipos podem ir e vir
• Os serviços podem ser criados, removidos e alterar as alocações de recursos e regras de colocação pretendidas
• As atualizações ou outras operações de gestão podem passar pelo cluster na aplicação ao nível da infraestrutura
• As falhas podem ocorrer em qualquer altura.

Componentes e fluxo de dados do gestor de recursos do cluster

O cluster Resource Manager tem de controlar os requisitos de cada serviço e o consumo de recursos por cada objeto de serviço nesses serviços. O cluster Resource Manager tem duas partes conceptuais: agentes que são executados em cada nó e um serviço tolerante a falhas. Os agentes em cada nó monitorizam os relatórios de carga dos serviços, agregam-nos e reportam-nos periodicamente. O cluster Resource Manager serviço agrega todas as informações dos agentes locais e reage com base na configuração atual.

Vejamos o seguinte diagrama:

Durante o runtime, existem muitas alterações que podem ocorrer. Por exemplo, digamos que a quantidade de recursos que alguns serviços consomem alterações, alguns serviços falham e alguns nós se associam e saem do cluster. Todas as alterações num nó são agregadas e enviadas periodicamente para o serviço cluster Resource Manager (1,2) onde são agregadas novamente, analisadas e armazenadas. A cada poucos segundos, o serviço analisa as alterações e determina se são necessárias ações (3). Por exemplo, pode notar que alguns nós vazios foram adicionados ao cluster. Como resultado, decide mover alguns serviços para esses nós. O cluster Resource Manager também pode notar que um determinado nó está sobrecarregado ou que determinados serviços falharam ou foram eliminados, libertando recursos noutro local.

Vamos ver o diagrama seguinte e ver o que acontece a seguir. Digamos que o cluster Resource Manager determina que as alterações são necessárias. Coordena-se com outros serviços do sistema (em particular o Gestor de Ativação Pós-falha) para fazer as alterações necessárias. Em seguida, os comandos necessários são enviados para os nós adequados (4). Por exemplo, digamos que o Resource Manager notado que o Node5 estava sobrecarregado e, por isso, decidiu mover o serviço B do Node5 para o Node4. No final da reconfiguração (5), o cluster tem o seguinte aspeto:

Passos seguintes

• O cluster Resource Manager tem muitas opções para descrever o cluster. Para saber mais sobre os mesmos, veja este artigo sobre como descrever um cluster do Service Fabric
• Os principais deveres do cluster Resource Manager estão a reequilibrar o cluster e a impor regras de colocação. Para obter mais informações sobre como configurar estes comportamentos, veja Balancear o cluster do Service Fabric