Balanceamento de carga entre servios (LoadBalance)

Quando existe uma grande quantidade de usurios que utilizam o sistema e o servidor no possui uma configurao ideal para comportar todos, mas h mais de um servidor disponvel, pode-se configurar balanceamento de carga para que nenhum servidor fique sobrecarregado e comprometa assim o desempenho da rede e do servidor.
Para que isto seja possvel, "nomeamos" um servidor intitulado de "servidor Master" que ser o responsvel por administrar o balanceamento.

Configurando o servidor Master

O nico arquivo de configurao (xxxsrv.ini) que ser alterado com as configuraes abaixo o do servidor Master, pois ele quem administrar o balanceamento de carga. Todos os usurios se conectaro inicialmente ao servidor Master, e este quem efetuar o balanceamento de carga para os outros servidores. Nos arquivos de configurao (*.ini) dos outros servidores ser alterado apenas a chave "RootPath", para que eles peguem a mesma base de dados do servidor Master.

[ServerNetwork] Servers=SERVER2, SERVER3 MasterConnection=0 --> NO INFORME O NOME DO SERVIDOR MASTER --> O SERVIDOR MASTER NO RECEBE CONEXO

[SERVER2] Type=TCPIP Server=172.16.77.42 Port=1234 Connections=1

[SERVER3] Type=TCPIP Server=172.16.75.62 Port=1235

Connections=1

Configurao dos outros servidores

Conforme citado acima, nos demais servidores a nica coisa que ser alterada a chave " RootPath" do arquivo de configurao do TOTVS Application Server. Para isso, o diretrio raiz (P10), do servidor Master, deve ser compartilhado com direitos apenas para um usurio que ser usado por todos os servios. Assim, os outros usurios no conseguiro acesso a este diretrio. Isto necessrio para que todos os servidores exerguem a mesma base de dados. Supondo que a base de dados esteja no servidor Master, os arquivos de configurao (*.ini) ficariam assim:

[Environment] SourcePath=C:\XXX\APO RootPath=\\SIGAMASTER\XXX\AP_DATA\ Master. StartPath=\SIGAADV\ ou \SYSTEM\ (as demais configuraes continuam iguais) --> Veja que a raiz est sendo apontada para o servidor

Observaes
Cada servidor dever ter o seu build e repositrio, sendo que a base de dados fica centralizada no servidor Master ou no servidor de banco de dados. O balanceamento de carga monoplataforma para o TOTVS Application Server. Isso significa que o MASTER e todos os SLAVES devem rodar no mesmo sistema operacional. Quando for realizada qualquer atualizao de build e o repositrio no servidor Master, a mesma alterao dever ser feita nos outros servidores. Um mesmo usurio Windows deve ter direitos na pasta compartilhada (RootPath) e dever ser um usurio Administrador, para que possa ser associado ao servio de cada servidor. Para verificar onde os usurios esto conectados, basta utilizar a aplicativo TOTVS Monitor em cada servidor. Crie sees [TCP] no arquivo de configurao, do TOTVS Smart Client, para receber conexo dos slaves (TCP1, TCP2, TCP3 e TCPN).

[TCP1] Server=Slave1 Port=1237

[TCP2] Server=Slave2 Port=1239

[TCP3] Server=Slave3 Port=1241

Ao abrir o TOTVS Monitor, informe qual comunicao [TCP] que deseja verificar as conexes. O nome do ambiente e portas de comunicao deve ser idntico para todos os servidores.

Separe em um servidor dedicado, um TOTVS Application Server para o ambiente de compilao: compilao uma operao crtica, exclusiva, que no deve ser executada no mesmo servio do TOTVS Application Server que est atendendo conexes de usurios do TOTVS Smart Client e ambiente de produo. No caso de balanceamento de carga em schedule, deve-se escolher um slave para receber a conexo. Lembre-se que o servidor Master NO recebe conexes. O valor da chave Connections determina a distribuio entre os slaves usando RAZO MATEMTICA (Exemplo: 1:2:1) O valor de RootPath=\\SIGAMASTER\XXX\AP_DATA\ deve ser a mesma para todas as instncias para os ambientes [Environment] de mesmo nome. Para mais informaes, consulte a documentao da seo [ServerNetwork]. Reserve 2 GB para cada TOTVS Application Server criado que pode ser na mesma mquina (desde que tenha capacidade para isso). No ambiente de balance cada ambiente deve ter seu RPO (todos iguais). NO compartilhe RPO em rede, pelos seguintes motivos: o Em casos conhecidos os logs mostram que o sistema operacional est causando os erros de comunicao nos servidores de aplicao e no nas estaes. o As mensagens que as estaes enviam no momento de uma nova conexo mostram que foi a parte servidora da operao que cortou a conexo de rede. o Os servidores de aplicao fazem leitura intensiva dos RPOs quando executam o ERP, pois neles esto compiladas todas as regras de negcio, se o RPO compartilhado em rede, tem como resultado: 1. Degradao na performance de execuo dos servidores de aplicao que utilizam o RPO compartilhado (trfego de RPO em rede). 2. O aumento do consumo de recursos de rede nos servidores que compartilham RPO, tipicamente, saturam o uso das interfaces de rede, criando uma concorrncia de transmisso de dados com as estaes que utilizam o TOTVS Smart Client.