Apresentando o gerenciador de recursos de cluster do Service Fabric

Tradicionalmente, gerenciar sistemas de TI ou serviços on-line significava dedicar máquinas físicas ou virtuais específicas a esses serviços ou sistemas específicos. Os serviços foram arquitetados como níveis. Haveria uma camada "web" e uma camada "dados" ou "armazenamento". Os aplicativos teriam uma camada de mensagens onde as solicitações fluíam para dentro e para fora, bem como um conjunto de máquinas dedicadas ao cache. Cada camada ou tipo de carga de trabalho tinha máquinas específicas dedicadas a ele: o banco de dados tinha algumas máquinas dedicadas a ele, os servidores web alguns. Se um determinado tipo de carga de trabalho fez com que as máquinas em que estava funcionassem muito quentes, você adicionou mais máquinas com essa mesma configuração a essa camada. No entanto, nem todas as cargas de trabalho poderiam ser dimensionadas tão facilmente - especialmente com a camada de dados que você normalmente substituiria máquinas por máquinas maiores. Fácil. Se uma máquina falhasse, essa parte do aplicativo geral era executada em menor capacidade até que a máquina pudesse ser restaurada. Ainda bastante fácil (se não necessariamente divertido).

Agora, no entanto, o mundo dos serviços e da arquitetura de software mudou. É mais comum que os aplicativos tenham adotado um design de expansão. A criação de aplicativos com contêineres ou microsserviços (ou ambos) é comum. Agora, embora você ainda possa ter apenas algumas máquinas, elas não estão executando apenas uma única instância de uma carga de trabalho. Eles podem até mesmo estar executando várias cargas de trabalho diferentes ao mesmo tempo. Agora você tem dezenas de tipos diferentes de serviços (nenhum consumindo recursos de uma máquina completa), talvez centenas de instâncias diferentes desses serviços. Cada instância nomeada tem uma ou mais instâncias ou réplicas para Alta Disponibilidade (HA). Dependendo do tamanho dessas cargas de trabalho e de quão ocupadas elas estão, você pode se encontrar com centenas ou milhares de máquinas.

De repente, gerenciar seu ambiente não é tão simples quanto gerenciar algumas máquinas dedicadas a tipos únicos de cargas de trabalho. Seus servidores são virtuais e não têm mais nomes (você mudou a mentalidade de animais de estimação para gado , afinal). A configuração é menos sobre as máquinas e mais sobre os serviços em si. O hardware dedicado a uma única instância de uma carga de trabalho é, em grande parte, uma coisa do passado. Os próprios serviços tornaram-se pequenos sistemas distribuídos que abrangem várias peças menores de hardware de mercadoria.

Como seu aplicativo não é mais uma série de monólitos espalhados por várias camadas, agora você tem muito mais combinações para lidar. Quem decide que tipos de cargas de trabalho podem ser executadas em que hardware ou quantas? Quais cargas de trabalho funcionam bem no mesmo hardware e quais conflitos? Quando uma máquina cai, como você sabe o que estava rodando lá naquela máquina? Quem é responsável por garantir que a carga de trabalho comece a funcionar novamente? Você espera que a máquina (virtual?) volte ou suas cargas de trabalho fazem failover automático para outras máquinas e continuam funcionando? É necessária intervenção humana? E as atualizações neste ambiente?

Como desenvolvedores e operadores que lidam com esse ambiente, vamos querer ajuda para gerenciar essa complexidade. Uma farra de contratações e tentar esconder a complexidade com as pessoas provavelmente não é a resposta certa, então o que fazemos?

Apresentando orquestradores

Um "Orchestrator" é o termo geral para um software que ajuda os administradores a gerenciar esses tipos de ambientes. Os orquestradores são os componentes que recebem solicitações como "Gostaria que cinco cópias deste serviço fossem executadas no meu ambiente". Eles tentam fazer com que o ambiente corresponda ao estado desejado, não importa o que aconteça.

Orquestradores (não humanos) são aqueles que agem quando uma máquina falha ou uma carga de trabalho termina por algum motivo inesperado. A maioria dos orquestradores faz mais do que apenas lidar com o fracasso. Outros recursos que eles têm são gerenciar novas implantações, lidar com atualizações e lidar com o consumo de recursos e governança. Todos os orquestradores são fundamentalmente sobre a manutenção de algum estado desejado de configuração no ambiente. Você quer ser capaz de dizer a um orquestrador o que você quer e fazê-lo fazer o trabalho pesado. O Aurora no topo do Mesos, o Docker Datacenter/Docker Swarm, o Kubernetes e o Service Fabric são exemplos de orquestradores. Esses orquestradores estão sendo ativamente desenvolvidos para atender às necessidades de cargas de trabalho reais em ambientes de produção.

Orquestração como serviço

O Gerenciador de Recursos de Cluster é o componente do sistema que lida com a orquestração no Service Fabric. O trabalho do Gerenciador de Recursos de Cluster é dividido em três partes:

  1. Aplicação das regras
  2. Otimizando seu ambiente
  3. Ajudar com outros processos

Consulte esta página para obter um vídeo de formação para compreender como funciona o Gestor de Recursos de Cluster:

O que não é

Em aplicativos tradicionais de camada N, há sempre um Load Balancer. Normalmente, este era um Network Load Balancer (NLB) ou um Application Load Balancer (ALB), dependendo de onde ele estava na pilha de rede. Alguns balanceadores de carga são baseados em hardware, como a oferta BigIP da F5, outros são baseados em software, como o NLB da Microsoft. Em outros ambientes, você pode ver algo como HAProxy, nginx, Istio ou Envoy nessa função. Nessas arquiteturas, o trabalho de balanceamento de carga é garantir que cargas de trabalho sem estado recebam (aproximadamente) a mesma quantidade de trabalho. Estratégias para balancear a carga variadas. Alguns balanceadores enviariam cada chamada diferente para um servidor diferente. Outros forneceram fixação/aderência da sessão. Os balanceadores mais avançados usam estimativa de carga real ou relatórios para rotear uma chamada com base no custo esperado e na carga atual da máquina.

Balanceadores de rede ou roteadores de mensagens tentaram garantir que a camada web/trabalhador permanecesse aproximadamente equilibrada. As estratégias para equilibrar a camada de dados eram diferentes e dependiam do mecanismo de armazenamento de dados. O balanceamento da camada de dados dependia de fragmentação de dados, cache, exibições gerenciadas, procedimentos armazenados e outros mecanismos específicos do armazenamento.

Embora algumas dessas estratégias sejam interessantes, o Gerenciador de Recursos de Cluster do Service Fabric não é nada parecido com um balanceador de carga de rede ou um cache. Um Network Load Balancer equilibra frontends distribuindo o tráfego entre frontends. O Gerenciador de Recursos de Cluster do Service Fabric tem uma estratégia diferente. Fundamentalmente, o Service Fabric move os serviços para onde eles fazem mais sentido, esperando que o tráfego ou a carga sejam seguidos. Por exemplo, ele pode mover serviços para nós que estão atualmente frios porque os serviços que estão lá não estão fazendo muito trabalho. Os nós podem estar frios, uma vez que os serviços que estavam presentes foram excluídos ou movidos para outro lugar. Como outro exemplo, o Gerenciador de Recursos de Cluster também pode mover um serviço para longe de uma máquina. Talvez a máquina esteja prestes a ser atualizada, ou esteja sobrecarregada devido a um pico no consumo pelos serviços em execução nela. Alternativamente, os requisitos de recursos do serviço podem ter aumentado. Como resultado, não há recursos suficientes nesta máquina para continuar a executá-la.

Como o Gerenciador de Recursos de Cluster é responsável por mover serviços, ele contém um conjunto de recursos diferente em comparação com o que você encontraria em um balanceador de carga de rede. Isso ocorre porque os balanceadores de carga de rede fornecem tráfego de rede para onde os serviços já estão, mesmo que esse local não seja ideal para executar o serviço em si. O Gerenciador de Recursos de Cluster do Service Fabric emprega estratégias fundamentalmente diferentes para garantir que os recursos no cluster sejam utilizados de forma eficiente.

Próximos passos

  • Para obter informações sobre a arquitetura e o fluxo de informações no Gerenciador de Recursos de Cluster, confira este artigo
  • O Gerenciador de Recursos de Cluster tem muitas opções para descrever o cluster. Para saber mais sobre métricas, confira este artigo sobre como descrever um cluster do Service Fabric
  • Para obter mais informações sobre como configurar serviços, Saiba mais sobre como configurar serviços
  • 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 este artigo
  • O Cluster Resource Manager funciona com os recursos de gerenciamento do Service Fabric. Para saber mais sobre essa integração, leia este artigo
  • Para saber como o Gerenciador de Recursos de Cluster gerencia e equilibra a carga no cluster, confira o artigo sobre balanceamento de carga