Árvore de páginas

Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 34 Próxima »

Descrição

O TOTVS | Broker Agent (agente) é uma ferramenta utilizada em conjunto com o TOTVS | Application Server (server) e com o TOTVS | Broker (broker) para prover escalabilidade horizontal (horizontal scaling) a um ambiente formado por um agente, um broker, e vários servers.

Em palavras mais simples, a funcionalidade de escalabilidade horizontal funciona da seguinte maneira:

  1. o broker monitora o consumo de vários recursos utilizados pelos servers balanceados: conexões, memória, usuários, threads e cpu

  2. à 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

  3. o agente cria uma nova instância de server (cria um novo processo server no sistema) e informa ao broker em qual porta TCP o novo server está aceitando conexões

  4. o broker então incorpora o novo server às suas tabelas de balanceamento, de maneira que novas conexões que chegam no broker são distribuídas também para o server recém iniciad

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.

Premissas

Para que o esquema de escalabilidade horizontal utilizando o agente funcione, várias premissas devem ser atendidas.

  1. o binário do agente esteja na mesma pasta onde se encontra o binário do server
  2. o server esteja configurado para utilizar a porta multi protocolo (este é o modo padrão de funcionamento do server)
  3. o server esteja atendendo apenas , isto é, não estejam configurados outros serviços no server, tais como Smartclient HTML (webapp), HTTP Server, etc.
  4. o server esteja sendo atendido via broker
  5. o broker esteja utilizando monitoramento ativo (que é o modo padrão de funcionamento do broker)

Configuração do Agente

O agente utiliza o mesmo mesmo arquivo de configuração "appserver.ini" utilizado pelo server.

Neste arquivo de configuração deverá haver uma seção específica para o agente, como no exemplo abaixo:

; ------------------------------------------------------------------------------

[BROKER_AGENT]

; habilita ou desabilita a funcionalidade do agente broker
; sem precisar remover os dados de configuração
enable = 1

; ip numérico ou hostname da máquina onde o broker está em execução
; o agente vai se conectar a este broker
BrokerServer = 10.172.16.31

; porta TCP por onde o broker recebe conexões
BrokerPort = 12340

; item de segurança: número máximo de servers que o agente poderá instanciar
MaxServers = 10

; ------------------------------------------------------------------------------

Configuração do Server

A configuração do server não necessita de nada especial, a não os dois pontos abaixo:

  1. deve haver a seção BROKER_AGENT (como descrito acima), porque o agente e o server compartilham o mesmo arquivo de configuração (appserver.ini)
  2. deve apenas a especificação da porta multi protocolo: não pode haver configuração de nenhuma outra seção que implique a utilização de portas TCP em modo server: WEBAPP, HTTP, TELNET, etc

Configuração do Broker

Para o broker funcionar no esquema de escalabilidade horizontal deve ser utilizado um arquivo de configuração parecido com o exemplo abaixo:


; ------------------------------------------------------------------------------

[BALANCE_SMART_CLIENT_DESKTOP]

; porta TCP por onde o broker aceita conexões
LOCAL_SERVER = 12340

; NÃO definir as chaves REMOTE_SERVER_00 etc

; broker vai tratar conexões do agente
WITH_BROKER_AGENT = 1

; planos de escalabilidade que o broker cai tratar
; os nomes abaixo são ilustrativos, podem ser usados quaisquer nomes
SCALING_PLANS = COMERCIAL, NOITE, MADRUGADA, MANHA, FDS

; fator de carga que dispara a ativação de uma nova instância do server pelo agente
; valor padrão: 80%
; SCALING_LOAD_FACTOR = 80

; fator de carga que dispara a desativação de um server pelo agente
; valor padrão: 60%
; SCALING_LOAD_FACTOR_IN = 60

; tempo em segundos para que seja disparada a desativação de um server ocioso
; valor padrão: 300 segundos
; 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

[MADRUGADA]
  FROM = 00:00
  TO = 05:59
  WEEKDAYS = 2 3 4 5 6
  MIN_SERVERS = 1
  MAX_SERVERS = 2
  CONNECTION_LIMIT = 3

[MANHA]
  FROM = 06:00
  TO = 08:59
  WEEKDAYS = 2 3 4 5 6
  MIN_SERVERS = 1
  MAX_SERVERS = 3
  CONNECTION_LIMIT = 5

[FDS]
  FROM = 00:00
  TO = 23:59
  WEEKDAYS = 17
  MIN_SERVERS = 1
  MAX_SERVERS = 3
  CONNECTION_LIMIT = 5
; ------------------------------------------------------------------------------

Descrição do Plano de Escalabilidade

[NOME]: nome do plano, não tem significado especial, server apenas como identificação do plano

FROM: hora do início de validade do plano, especificado em horas e minutos (HH:SS)

TO: hora do final de validade do plano, especificado em horas e minutos (HH:SS)

WEEKDAYS: dias da semana em que o plano é válido, 1= domingo, 2=segunda, ...7=sábado

MIN_SERVERS: número mínimo de servers que o plano vai manter ativo

MAX_SERVERS: número máximo de servers que o plano vai manter ativo

CONNECTION_LIMIT: número máximo de conexões de smartclient que o broker vai direcionar para um server específico

USER_LIMIT: número máximo de usuários (como mostrado na tela de consulta do broker) que um server pode ter para que seja considerado elegível para balanceamento pelo broker

THREAD_LIMIT: número máximo de threads (como mostrado na tela de consulta do broker) que um server pode ter para que seja considerado elegível para balanceamento pelo broker

MEMORY_LIMIT: quantidade máxima de memória (como mostrada na tela de consulta do broker) que um server pode estar utilizando para que seja considerado elegível para balanceamento pelo broker

CPU_LIMIT: porcentagem máxima de cpu (como mostrada na tela de consulta do broker) que um server pode estar utilizando para que seja considerado elegível para balanceamento pelo broker

Detalhes de Funcionamento

Uma vez por minuto o broker faz uma checagem do plano de escalabilidade em operação.

Se especificados, os cinco critérios acima são verificados: CONNECTION_LIMIT, USER_LIMIT, THREAD_LIMIT, MEMORY_LIMIT, CPU_LIMIT.

Caso o valor total agregado de um critério alcance ou ultrapasse 80% do valor total agregado máximo do critério entã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.


Para os exemplos abaixo utilizaremos o seguinte plano de escalabilidade:
[COMERCIAL]
  FROM = 09:00
  TO = 17:59
  WEEKDAYS = 2 3 4 5 6
  MIN_SERVERS = 2
  MAX_SERVERS = 4
  CONNECTION_LIMIT = 10

O número mínimo de servers é 2, 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 para o agente instanciar 2 servers, que é número mínimo configurado.

Com 2 servers, 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 número total máximo de conexões será 30, e aplicando o fato 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 número total máximo de conexões será 40, e aplicando o fato 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. Quando número total de conexões chegar a 32 ... não vai acontecer nada, pois o número de servers ativos vai estar no limite máximo configurado.O broker vai continuar direcionando conexões para os 4 servers de maneira balanceada, até que cada server esteja atendendo 10 conexões, o limite máximo configurado. A partir daí todas as conexões que chegarem no broker serão recusadas.

Desativação de um Server Ocioso

A cada vez que uma conexão é fechada pelo client, o broker verifica se o server chegou a 0 conexões (isto é, o server está ocioso), e neste caso o broker marca a hora que o server se tornou ocioso.A cada ciclo de verificação (1 vez por minuto) que o broker faz do plano de escalabilidade, o broker verifica 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, para verificar se pode pedir a desativação do server.No exemplo 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 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, que é igual a 18. Neste caso, talvez fosse mais adequado 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 processo de ativação e desativação de servers que foi demonstrado considerando o critério CONNECTION_LIMITE também é aplicado para os outros critérios, caso estejam configurados.Para a ativação de um novo server qualquer dos critérios configurados que atinja o fator de carga 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% (após a desativação do server) 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. Se for removido, será recriado na próxima execução do agente.


--//--

  • Sem rótulos