Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

O

Inclusão de trecho
broker
broker
nopaneltrue
 suporta os métodos descritos abaixo para balancear as conexões oriundas de um
Inclusão de trecho
SmartClient
SmartClient
nopaneltrue
:

SORT_METHODDescrição
CONNECTIONBalanceamento por número de conexões
ROUND_ROBINBalanceamento Round Robin (RR)
SERVER_MEMORY

Balanceamento por consumo de memória reportado pelo 

Inclusão de trecho
application server
application server
nopaneltrue

SERVER_USERS

Balanceamento por número de usuários reportados pelo 

Inclusão de trecho
application server
application server
nopaneltrue

SERVER_THREADS

Balanceamento por número de threads reportado pelo 

Inclusão de trecho
application server
application server
nopaneltrue

SERVER_CPU

Balanceamento por consumo de CPU reportado pelo 

Inclusão de trecho
application server
application server
nopaneltrue

Obs.: o método SERVER_MEMORY  é o padrão e não precisa ser especificado.

A especificação do método de balanceamento é feita pelo uso da chave SORT_METHOD na seção BALANCE_SMART_CLIENT_DESKTOP no arquivo de configuração do

Inclusão de trecho
broker
broker
nopaneltrue
(appserver.ini).

Os métodos SERVER_MEMORY, SERVER_USERS, SERVER_THREADS e SERVER_CPU são efetivos apenas quando usados em conjunto com a opção de monitoramento ativo (SMARTCLIENT_ACTIVE ou SMARTCLIENT_SSL_ACTIVE).


Exemplo

Este exemplo utiliza o método de balanceamento pelo consumo de memória nos servidores.


Sem Formato
[BALANCE_SMART_CLIENT_DESKTOP]
...
...
SORT_METHOD=SERVER_MEMORY
...
...

Detalhes dos métodos de balanceamento


Método de balanceamento por conexões

Este método utiliza como métrica o número de conexões de Smartclient para cada servidor que consta na tabela de servidores do Broker.

São consideradas apenas as conexões que passam pelo Broker. Isto é, se um usuário se conectar sem utilizar o Broker, está conexão não será levada em consideração pelo algoritmo de balanceamento.

Exemplo.

Supondo inicialmente que nenhum usuário está logado.

Agora, após um usuário se logar no sistema. Como o balanceamento está sendo feito pelo número de conexões, então o servidor que tiver o menor número de conexões será o escolhido. Como os 3 servidores possuem o mesmo número de conexões (zero), qualquer um deles poderá ser escolhido.

O servidor 1 foi o escolhido, porque era um dos que possuía menor quantidade de conexões.

O próximo usuário a se logar irá para o servidor 2 ou servidor 3.

Foi escolhido o servidor 2.

Agora, o próximo usuário a se conectar será obrigatoriamente direcionado ao servidor 3.

Confirmado, o terceiro usuário foi direcionado para o servidor 3.

Agora, para efeito de teste, o segundo usuário (servidor 2) fecha sua sessão com o sistema.

Certo, o servidor 2 agora aparece com zero conexões.

Portanto, o próximo usuário que se conectar irá ser direcionado ao servidor 2, que é o servidor com o menor número de conexões.

Certo, o novo usuário foi direcionado ao servidor 2.

Agora, um detalhe: a cada aba que acessa uma rotina específica de um módulo, uma nova conexão com o servidor será aberta. Assim, a tela inicial do módulo (p.ex. SIGAADV, SIGAMDI) conta com uma conexão, e qualquer rotina escolhida que crie uma nova aba MDI criará uma nova conexão com um servidor.

Na tela abaixo, o usuário se conectou no servidor 2 no módulo SIGAADV, e abriu uma rotina de "Consulta Genérica". Portanto, aparecem 2 conexões para o servidor 2 na tela do broker.

Método de balanceamento por round robin

Este método redireciona cada nova conexão de Smartclient para cada servidor que consta na tabela de servidores do Broker em ordem sequencial.

São consideradas apenas as conexões que passam pelo Broker. Isto é, se um usuário se conectar sem utilizar o Broker, está conexão não será levada em consideração pelo algoritmo de balanceamento.

Supondo uma configuração com 3 servidores, e inicialmente nenhum usuário logado.

A primeira conexão irá para o servidor 1, a segunda para para o servidor 2, a terceira para o servidor 3, a quarta volta para o servidor 1, a quinta para o servidor 2, e assim por diante


Tela inicial, com nenhuma usuário conectado.

Image Added


Tela do Broker com o primeiro usuário conectado, ainda  na tela de menu do Smartclient, após conexão no módulo SIGMDI.

Image Added


Tela do Broker após o usuário executar uma Consulta Genérica de Cadastro. A nova aba MDI abera consumiu uma nova conexão. Como o balanceamento é round robin, esta nova conexão foi para o servidor 2, que era o próximo na sequência na tabela de servidores do Broker.

Image Added


O próximo servidor na sequência é o servidor 3. Então uma nova aba MDI aberta, ou um novo Smartclient iniciado vai abrir uma conexão com o servidor.

Tela do Broker após a abertura de um novo Smartclient. Usando o servidor 3, como previsto.

Image Added


Para efeito de teste, este último Smartclient aberto, que utiliza o servidor 3, será fechado.

Tela após o fechamento deste Smartclient.

Image Added


O servidor 3 agora está com zero conexões. Mesmo assim o próximo Smartclient a ser iniciado irá se conectar ao servidor 1, que é o próximo na sequência.

Image Added

Como esperado, o novo Smartclient se conectou ao servidor 1, apesar do servidor 3 não estar sendo usado por nenhum Smartclient (está com zero conexões).


O próximo Smartclient a se conertar ainda não vai se conectar ao servidor 3, e sim ao servidor 2, que é o próximo na sequência.

Image Added

Como esperado, o novo Smartclient se conectou ao servidor 2.


Agora, o próximo Smartclient a se conectar irá usar o servidor 3, que é o próximo na sequência

Image Added

Confirmado, novo Smartclient se conectou no servidor 3.