Histórico da Página
O
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
SORT_METHOD | Descrição | ||||||||
---|---|---|---|---|---|---|---|---|---|
CONNECTION | Balanceamento por número de conexões | ||||||||
ROUND_ROBIN | Balanceamento sequencial (round robin) | ||||||||
SERVER_MEMORY | Balanceamento por consumo de memória reportado pelo
| ||||||||
SERVER_USERS | Balanceamento por número de usuários reportados pelo | ||||||||
SERVER_THREADS | Balanceamento por número de threads reportado pelo
| ||||||||
SERVER_CPU | Balanceamento por consumo de CPU reportado pelo
|
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 | ||||||
---|---|---|---|---|---|---|
|
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).
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
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
São consideradas apenas as conexões que passam pelo Broker. Isto é, se um usuário se conectar sem utilizar o
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Supondo inicialmente que nenhum usuário esteja conectado.
A imagem abaixo mostra as conexões após um usuário entrar 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 conectar irá ou para o servidor 2 ou para o 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 de Cadastro". Portanto, aparecem 2 conexões para o servidor 2 na tela do broker.
Método de balanceamento sequencial (round robin)
Este método redireciona cada nova conexão de Smartclient para um servidor que consta na tabela de servidores do
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
São consideradas apenas as conexões que passam pelo
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Supondo uma configuração com 3 servidores, e inicialmente nenhum usuário conectado, 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, sem usuários conectados.
Tela do
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Tela do
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
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 3.
Tela do
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Para efeito de teste, este último Smartclient aberto, que utiliza o servidor 3, será fechado.
Tela após o fechamento deste Smartclient.
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.
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 conectar ainda não vai se conectar ao servidor 3, e sim ao servidor 2, que é o próximo na sequência.
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
Confirmado, novo Smartclient se conectou no servidor 3.
Método de balanceamento por consumo de memória por servidor
Este método direciona cada nova conexão de Smartclient para o servidor com menor consumo de memória, como informado pelo monitoramento ativo dos servidores.
Mesmo as conexões que não passam pelo
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Tela inicial sem nenhum usuário passando pelo
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
O consumo de memória pelos servidores é bastante parecido, mas o servidor 2 tem o menor consumo: 33.966.
Então a primeira conexão de Smartclient a ser feita vai utilizar o servidor 2.
Tela do Broker após o primeiro usuário se conectar.
Como esperado, esse primeiro usuário se conectou no servidor 2.
O segundo usuário vai se conectar no servidor 3, que agora apresenta o menor consumo de memória entre os 3 servidores configurados.
Tela do Broker após a conexão do segundo usuário.
Correto, o segundo usuário se conectou no servidor 3.
O próximo usuário agora com certeza vai se conectar no servidor 1, que está usando muito menos memória que os outros 2 servidores.
Tela do Broker após a conexão do terceiro usuário.
Certo, o terceiro usuário se conectou no servidor 1.
Como o servidor 1 ainda é o servidor com menor consumo de memória, o próximo usuário a se conectar ainda vai utilizar o servidor 1.
Correto, o quarto usuário se conectou com o o servidor 1, que tinha o menor consumo de memória entre os 3 servidores configurados.
Método de balanceamento por quantidade de usuários no servidor
Este método direciona cada nova conexão de Smartclient para o servidor com menor quantidade de usuários conectados como informado pelo monitoramento ativo dos servidores.
Mesmo as conexões que não passam pelo
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
É importante notar que um mesmo usuário pode participar de várias conexões com os servidores. Por exemplo, um usuário se conecta via módulo SIGAMDI, e depois abre 2 abas para outras módulos. Se as 3 conexões (tala inicial MDI + outros 2 módulos) caírem no mesmo servidor, vai ser contado apenas um usuário neste servidor, embora existam 3 conexões deste usuário. Com o
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Nas telas acima, um usuário se conectou via SIGAMDI com o servidor 1 (pelo
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
A tela do broker no entanto mostra 2 usuários para o servidores 2 e o servidor 3.
Qual a explicação ? Podemos ver os detalhes pelo WebMonitor:
Cada aba MDI utiliza na verdade 2 usuários: o usuário real (jose.santana) e um usuário criado pelo ERP, que é o mesmo que o usuário real, adicionado de um "_" (underline) no final: jose.santana_.
Estes detalhes da criação e gerenciamento de usuários são responsabilidade do ERP, não estão sob controle nem do
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Uma outra consideração a ser levada em conta: quando a chave APP_ENVIRONMENT está habilitada em um servidor, então este servidor, ao iniciar, vai ter automaticamente um usuário LSPULSE ativo, correspondente ao job REST que tratam as rotinas do ERP que utilizam a interface PO-UI. Isso pode ser visto pela tela do WebMonitor:
Agora, quanto aos detalhes do balanceamento por quantidade de usuários em cada
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Inicialmente, 3 servidores sem usuários.
Agora, após um usuário ter se conectado, mas ainda na tela do menu principal.
Agora, após um outro usuário ter se conectando, também ainda na tela do menu principal.
Agora, após o primeiro usuário abrir uma aba MDI.
A conexão foi feita com o servidor 3, que possuía zero usuários ativos. Agora, o servidor 3 possui 2 usuários ativos: o usuário original, que se conectou pelo Smartclient, e o usuário com um "_" (underline) no final, que foi criado pelo ERP.
A tela do WebMonitor mostra os detalhes desses usuários.
Agora, a tela do
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
A conexão vai ser feita ou com o servidor 1, ou com o servidor 2, que possuem apenas 1 usuário, portanto são elegíveis para balanceamento.
O servidor 3 não é elegível para balanceamento, pois não possui o menor número de usuários entre os servidores configurados no
Inclusão de trecho | ||||||
---|---|---|---|---|---|---|
|
Correto. Como esperado, a conexão foi direcionada para um dos servidores com menor número de usuários.