Apresentação do gestor de recursos do cluster do Service Fabric
A gestão tradicional de sistemas de TI ou serviços online significava dedicar máquinas físicas ou virtuais específicas a esses serviços ou sistemas específicos. Os serviços foram arquitetados como escalões. Existiria uma camada "Web" e uma camada de "dados" ou "armazenamento". As aplicações teriam um escalão de mensagens onde os pedidos fluíam para dentro e para fora, bem como um conjunto de máquinas dedicadas à colocação em cache. Cada escalão ou tipo de carga de trabalho tinha máquinas específicas dedicadas à mesma: a base de dados tinha algumas máquinas dedicadas à mesma, os servidores Web alguns. Se um determinado tipo de carga de trabalho fez com que as máquinas em que estava a ser executada ficassem demasiado frequentes, adicionou mais máquinas com essa mesma configuração a essa camada. No entanto, nem todas as cargas de trabalho podiam ser aumentadas horizontalmente tão facilmente, especialmente com o escalão de dados que normalmente substituiria máquinas por máquinas maiores. Isso é fácil. Se uma máquina falhou, essa parte da aplicação geral foi executada com menor capacidade até que a máquina possa ser restaurada. Ainda bastante fácil (se não necessariamente divertido).
Agora, no entanto, o mundo da arquitetura de serviço e software mudou. É mais comum que as aplicações tenham adotado um design de escalamento horizontal. A criação de aplicações com contentores ou microsserviços (ou ambos) é comum. Agora, embora ainda possa ter apenas algumas máquinas, estas não estão a executar apenas uma única instância de uma carga de trabalho. Podem até estar a executar várias cargas de trabalho diferentes ao mesmo tempo. Tem agora dezenas de tipos diferentes de serviços (nenhum consome 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 Elevada Disponibilidade (HA). Dependendo dos tamanhos dessas cargas de trabalho e do quão ocupadas estão, poderá encontrar-se com centenas ou milhares de máquinas.
De repente, gerir o seu ambiente não é tão simples como gerir algumas máquinas dedicadas a tipos únicos de cargas de trabalho. Os seus servidores são virtuais e já não têm nomes (afinal, mudou de mentalidade de animais de estimação para gado ). A configuração é menos sobre as máquinas e mais sobre os próprios serviços. 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.
Uma vez que a sua aplicação já não é uma série de monólitos distribuídos por várias camadas, tem agora muitas mais combinações para lidar. Quem decide que tipos de cargas de trabalho podem ser executadas em que hardware ou em quantos? Que cargas de trabalho funcionam bem no mesmo hardware e que conflito? Quando uma máquina fica inativa, como sabe o que estava a ser executado naquele computador? Quem é responsável por se certificar de que a carga de trabalho começa a ser executada novamente? Espera que a máquina (virtual?) regresse ou as cargas de trabalho efetuam a ativação pós-falha automaticamente para outras máquinas e continuam em execução? A intervenção humana é necessária? E as atualizações neste ambiente?
Enquanto programadores e operadores que lidam neste ambiente, vamos querer ajuda para gerir esta complexidade. Uma contratação e tentar esconder a complexidade com as pessoas provavelmente não é a resposta certa, então o que fazemos?
Introdução aos orquestradores
Um "Orchestrator" é o termo geral de um software que ajuda os administradores a gerir estes tipos de ambientes. Os orquestradores são os componentes que recebem pedidos como "Gostaria de ter cinco cópias deste serviço em execução no meu ambiente". Tentam fazer com que o ambiente corresponda ao estado pretendido, aconteça o que acontecer.
Os orquestradores (não humanos) são o que tomam medidas 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. Outras funcionalidades que têm são gerir novas implementações, lidar com atualizações e lidar com o consumo e governação de recursos. Todos os orquestradores têm fundamentalmente a ver com a manutenção de algum estado de configuração pretendido no ambiente. Queres ser capaz de dizer a um orquestrador o que queres e fazê-lo fazer o trabalho pesado. Aurora sobre Mesos, Docker Datacenter/Docker Swarm, Kubernetes e Service Fabric são todos exemplos de orquestradores. Estes orquestradores estão a ser desenvolvidos ativamente para satisfazer as necessidades das cargas de trabalho reais em ambientes de produção.
Orquestração como um serviço
O Cluster Resource Manager é o componente de sistema que processa a orquestração no Service Fabric. A tarefa do cluster Resource Manager está dividida em três partes:
- Impor Regras
- Otimizar o seu ambiente
- Ajudar com Outros Processos
O que não é
Nas aplicações tradicionais de N camadas, há sempre uma Balanceador de Carga. Normalmente, este era um Balanceador de Carga de Rede (NLB) ou um Balanceador de Carga de Aplicações (ALB) consoante o local onde se encontrava na pilha de rede. Alguns balanceadores de carga são baseados em hardware, como a oferta bigIP do F5, outros são baseados em software, como o NLB da Microsoft. Noutros ambientes, poderá ver algo como HAProxy, nginx, Istio ou Enviado nesta função. Nestas arquiteturas, a tarefa de balanceamento de carga é garantir que as cargas de trabalho sem estado recebem (aproximadamente) a mesma quantidade de trabalho. As estratégias para equilibrar a carga variaram. Alguns balanceadores enviariam cada chamada diferente para um servidor diferente. Outros forneceram afixação/persistência da sessão. Os balanceadores mais avançados utilizam a estimativa de carga real ou os relatórios para encaminhar uma chamada com base no custo esperado e na carga atual da máquina.
Os balanceadores de rede ou routers de mensagens tentaram garantir que o escalão Web/de trabalho se mantinha aproximadamente equilibrado. 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 baseava-se na fragmentação de dados, colocação em cache, vistas geridas, procedimentos armazenados e outros mecanismos específicos do arquivo.
Embora algumas destas estratégias sejam interessantes, o Cluster do Service Fabric Resource Manager não é nada como um balanceador de carga de rede ou uma cache. Uma Rede Balanceador de Carga equilibra os front-ends ao espalhar o tráfego pelos front-ends. O Cluster do Service Fabric Resource Manager tem uma estratégia diferente. Fundamentalmente, o Service Fabric move os serviços para onde fazem mais sentido, esperando que o tráfego ou a carga se sigam. Por exemplo, pode mover serviços para nós que estão atualmente frios porque os serviços que existem não estão a fazer muito trabalho. Os nós podem estar frios, uma vez que os serviços presentes foram eliminados ou movidos para outro local. Como outro exemplo, o Cluster Resource Manager também pode mover um serviço para longe de um computador. Talvez a máquina esteja prestes a ser atualizada ou esteja sobrecarregada devido a um aumento do consumo por parte dos serviços em execução no mesmo. Em alternativa, os requisitos de recursos do serviço podem ter aumentado. Como resultado, não existem recursos suficientes neste computador para continuar a executá-lo.
Uma vez que o Cluster Resource Manager é responsável por mover serviços, contém um conjunto de funcionalidades diferente em comparação com o que encontraria num balanceador de carga de rede. Isto deve-se ao facto de os balanceadores de carga de rede fornecerem tráfego de rede para onde os serviços já se encontram, mesmo que essa localização não seja ideal para executar o próprio serviço. O Cluster do Service Fabric Resource Manager utiliza estratégias fundamentalmente diferentes para garantir que os recursos no cluster são utilizados de forma eficiente.
Passos seguintes
- Para obter informações sobre a arquitetura e o fluxo de informações no cluster Resource Manager, consulte este artigo
- O cluster Resource Manager tem muitas opções para descrever o cluster. Para saber mais sobre as métricas, consulte este artigo sobre como descrever um cluster do Service Fabric
- Para obter mais informações sobre como configurar serviços, saiba mais sobre a configuração dos Serviços
- As métricas são a forma como o Service Fabric Cluster Resource Manger gere o consumo e a capacidade no cluster. Para saber mais sobre as métricas e como configurá-las, consulte este artigo
- O cluster Resource Manager funciona com as capacidades de gestão do Service Fabric. Para saber mais sobre essa integração, leia este artigo
- Para saber como o Cluster Resource Manager gere e equilibra a carga no cluster, consulte o artigo sobre balanceamento de carga