Histórico da Página
Dica | ||||||||
---|---|---|---|---|---|---|---|---|
Feature liberada na versão 20.3.1.0 do
Mais detalhes sobre versão em: Protheus Week em desenvolvimento e sem previsão de liberação. |
O
Agent (agente) é uma ferramenta utilizada em conjunto com o Inclusão de trecho broker broker nopanel true
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Em palavras mais simples, a funcionalidade de escalabilidade horizontal funciona da seguinte maneira:
O broker monitora o consumo de vários recursos utilizados pelos servers balanceados: conexões, memória, usuários, threads e cpu
À medida que o consumo total desses vários recursos alcançam um certo limite, o broker requisita ao agente a criação de uma nova instância de server
O agente cria uma nova instância de server e informa ao broker em qual porta TCP o novo server está aceitando conexões
O broker então incorpora o novo server às suas tabelas de balanceamento, de maneira que as novas conexões sejam distribuídas também para o server recém instanciado
O uso da escalabilidade horizontal para a alocação dinâmica de novos servers possibilita o funcionamento mais estável do sistema, pois evita que haja sobrecarga sobre os servers em operação.
A escalabilidade horizontal também funciona de maneira inversa: à medida que os servers se tornem ociosos por algum tempo, isto é, não estejam atendendo nenhuma conexão, o broker requisita que o agente desative estes servers que estão ociosos, desta maneira economizando recursos computacionais e diminuindo os custos de operação do sistema.
Requisitos
Para que esse esquema de escalabilidade funcione, algumas premissas devem ser atendidas. São elas:
- O binário do agente deve estar na mesma pasta onde se encontra o binário do server
- O server deve estar configurado para utilizar a porta multiprotocolo
- O server deve atender apenas as conexões provenientes do
, isto é, outros modelos de balanceamento não devem estar configurados neste serverInclusão de trecho Smartclient Smartclient nopanel true - O server dever estar sendo atendido via broker
- O broker deve estar configurado para utilizar o modelo de monitoramento ativo (modo padrão do
)Inclusão de trecho broker broker nopanel true
Detalhes de configuração
Informações |
---|
O agente utiliza o mesmo arquivo de configuração utilizado pelo server - appserver.ini |
O arquivo de configuração deverá possuir uma seção específica para o agente, conforme exemplo abaixo:
Detalhes
Chave | Descrição |
---|---|
Enable | Habilita ou desabilita a funcionalidade do agente broker |
BrokerServer | IP ou hostname do servidor onde o broker está em execução (o agente vai se conectar a este broker) |
BrokerPort | Porta TCP por onde o broker recebe conexões |
MaxServers | Número máximo de servers que o agente poderá instanciar (item de segurança) |
Exemplo
Bloco de código | ||
---|---|---|
| ||
[BROKER_AGENT] enable = 1 BrokerServer = 10.172.16.31 BrokerPort = 12340 MaxServers = 10 |
Configuração do Server
A configuração do server depende apenas duas configurações. São elas:
- Deve haver a seção BROKER_AGENT (como descrito acima), pois o agente e o server compartilham o mesmo arquivo de configuração (appserver.ini)
- Deve possuir apenas a especificação da porta multiprotocolo, ou seja, não pode haver configuração de nenhuma outra seção que implique a utilização de portas TCP para outros modelos de serviço (exemplo: webapp, http, telnet)
Configuração do Broker
Para que o broker funcione no esquema de escalabilidade tratado neste material, deve ser utilizado um arquivo de configuração semelhante ao apresentado no exemplo abaixo:
Detalhes
Chave | Descrição |
---|---|
LOCAL_SERVER | Porta TCP por onde o broker aceita conexões |
WITH_BROKER_AGENT | Habilita a configuração que faz o broker tratar as conexões do agente |
SCALING_PLANS | Planos de escalabilidade que o broker vai tratar (podem ser usados quaisquer nomes para definição do plano) |
SCALING_LOAD_FACTOR | Fator de carga que dispara a ativação de uma nova instância do server pelo agente (default: 80%) |
SCALING_LOAD_FACTOR_IN | Fator de carga que dispara a desativação de um server pelo agente (default: 60%) |
SCALING_GRACE_TIME | Tempo em segundos para que seja disparada a desativação de um server ocioso (default: 300 segundos) |
Exemplo
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
[BALANCE_SMART_CLIENT_DESKTOP] LOCAL_SERVER = 12340 WITH_BROKER_AGENT = 1 SCALING_PLANS = COMERCIAL,NOITE ; SCALING_LOAD_FACTOR = 80 ; SCALING_LOAD_FACTOR_IN = 60 ; SCALING_GRACE_TIME = 300 ; especificação dos planos de escalabilidade [COMERCIAL] FROM = 09:00 TO = 17:59 WEEKDAYS = 2 3 4 5 6 MIN_SERVERS = 2 MAX_SERVERS = 4 CONNECTION_LIMIT = 10 [NOITE] FROM = 18:00 TO = 23:59 WEEKDAYS = 2 3 4 5 6 MIN_SERVERS = 1 MAX_SERVERS = 2 CONNECTION_LIMIT = 5 |
* Mais detalhes sobre as chaves para especificação dos planos de escalabilidade na seção Plano de Escalabilidade
Plano de Escalabilidade
Chave / Seção | Descrição | Observação | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
[PLANO] | Essa seção recebe o nome utilizado para identificação do plano de escalabilidade | Não tem significado especial, serve apenas como identificação | ||||||||
FROM | Essa chave indica a hora do início de validade do plano | O valor deve ser especificado em horas e minutos (HH:MM) | ||||||||
TO | Essa chave indica a hora do final de validade do plano | O valor deve ser especificado em horas e minutos (HH:MM) | ||||||||
WEEKDAYS | Essa chave indica os dias da semana em que o plano é válido | Exemplo: 1= domingo, 2=segunda, ... 7=sábado | ||||||||
MIN_SERVERS | Essa chave indica o número mínimo de servers que o plano vai manter ativo | |||||||||
MAX_SERVERS | Essa chave indica o número máximo de servers que o plano vai manter ativo | |||||||||
CONNECTION_LIMIT | Essa chave indica o número máximo de conexões originadas do | |||||||||
USER_LIMIT | Essa chave indica o número máximo de usuários que um server pode ter para que seja considerado elegível para balanceamento pelo broker | |||||||||
THREAD_LIMIT | Essa chave indica o número máximo de threads que um server pode ter para que seja considerado elegível para balanceamento pelo broker | |||||||||
MEMORY_LIMIT | Essa chave indica a quantidade máxima de memória que um server pode estar utilizando para que seja considerado elegível para balanceamento pelo broker | O valor deve ser especificado em Megabytes | ||||||||
CPU_LIMIT | Essa chave indica a porcentagem máxima de CPU que um server pode estar utilizando para que seja considerado elegível para balanceamento pelo broker |
Detalhes de Funcionamento
A cada um minuto o broker faz uma checagem do plano de escalabilidade em operação, levando em consideração os critérios (detalhes na tabela acima) que foram utilizados para a configuração do plano de escalabilidade.
Caso o valor total agregado alcance ou ultrapasse 80% do valor total máximo configurado para o critério em avaliação, o broker vai solicitar ao agente que um um novo server seja instanciado, desde que o número total de servers instanciados ainda esteja abaixo do limite especificado.
Para maior clarificação, utilizaremos o exemplo abaixo como base:
Nessa configuração o número mínimo de servers é 2, o máximo de servers é 4 e o número máximo de conexões por server é 10. | ||
---|---|---|
|
Ativação de Novo Server
- Inicialmente o broker vai solicitar ao agente que instancie 2 servers, pois este foi o número mínimo configurado.
- Com estes 2 servers iniciados, o total máximo de conexões é 20 (2 x 10).
- Aplicando o fator de carga de 80% chegamos a 16 conexões.
- O broker então vai direcionando conexões para os 2 servers de maneira balanceada.
- Quando número total de conexões chegar a 16, o broker solicita ao agente a ativação de um novo server.
- Após o novo server entrar no ar, o novo número total máximo de conexões será 30, e aplicando o fator de carga de 80%, chegamos a 24 conexões.
- O broker agora vai direcionar as conexões para os 3 servers ativos de maneira balanceada.
- Quando número total de conexões chegar a 24, o broker solicita ao agente a ativação de um novo server.
- Após o novo server entrar no ar, o novo número total máximo de conexões será 40, e aplicando o fator de carga de 80%, chegamos a 32 conexões.
- O broker agora vai direcionar as conexões para os 4 servers ativos de maneira balanceada.
- Dessa vez, quando número total de conexões chegar a 32, nenhuma ação de escalabilidade será adotada, pois o número de servers ativos vai estar no limite máximo configurado.
- Assim, o broker vai continuar direcionando conexões para os 4 servers de maneira balanceada, até que cada server esteja atendendo 10 conexões, respeitando o limite máximo configurado.
- A partir desse momento, todas as novas conexões que chegarem no broker serão recusadas.
Desativação de um Server Ocioso
- A cada vez que uma conexão for encerrada pelo client, o broker verifica se o server chegou a 0 (zero) conexões, caracterizando ele como "ocioso", e neste caso o broker marca a hora que o server adotou este estado.
- A cada ciclo de verificação (1 vez por minuto), o broker avalia se existe algum server que está ocioso há 5 minutos (valor padrão) ou mais.
- Se o número de servers ativos está acima do mínimo configurado, o broker faz o cálculo do fator de carga para desativação, a fim de verificar se pode solicitar a desativação do server.
- No cenário acima, supondo 4 servers ativos, o broker vai pedir a desativação de um server ocioso há 5 minutos ou mais caso o número de conexões atuais seja de 18 ou menos, porque o fator de desativação para 4 servers é 60% do número máximo de conexões para 3 servers (60% de 30 conexões, que é igual a 18 conexões).
Dica | ||
---|---|---|
| ||
Neste caso, poderíamos configurar a chave SCALING_LOAD_FACTOR_IN para 70, pois assim um server ocioso poderia ser desativado quando o número atual de conexões fosse 21 (70% de 3 servers x 10 conexões → 70% de 30 → 21 conexões). |
Informações adicionais
- O mesmo fluxo de ativação e desativação de servers que foi demonstrado acima, é considerando para os demais critério caso estes tenham sido configurados.
- Para a ativação de um novo server, qualquer um dos critérios configurados que atinja o fator de carga de 80% dispara a ativação de um novo server.
- Para a desativação de um server ocioso, todos os critérios configurados devem satisfazer o fator de carga de 60% para que o server seja desativado.
- Para cada server ativado, o arquivo de log (normalmente "console.log") terá o nome "worker_AAMMDD_HHMMSS_SS.log", e será gravado na pasta "worker_logs" dentro da pasta onde estão os binários do agente e do server.
- O nome da pasta "worker_logs" pode ser alterado através da chave "ConsolePath".
- O agente cria um log de nome ag_AAMMDD_HHMMSS.txt.
- O agente cria um arquivo de controle AG_CONTROL.TXT na pasta onde estão os binários do agente e do server. Em princípio este arquivo não deve ser removido mas, caso ocorra sua remoção, um novo arquivo será recriado na próxima execução do agente.