Índice

Conceito

Quando um único servidor (hardware) não possui uma configuração que comporte a carga gerada por um grande processamento, é possível configurar uma nova instância da aplicação em um outro servidor disponível e balancear a carga de processamento, de forma que o recurso computacional seja elevado com a adoção de um novo hardware. A configuração de balanceamento de carga visa a escalabilidade da aplicação para permitir a utilização do TSS mesmo em cenários de operação crítica ou que demandem alto volume de transações diárias.
Ainda que o hardware utilizado comporte um volume expressivo de carga, as características de limite máximo de consumo de memória da aplicação devem ser respeitadas, logo, podem ser adotadas novas instâncias em um mesmo hardware, desde que este comporte.
A seguir, apresentamos algumas premissas básicas e requisitos mínimos para adoção do recurso de balanceamento:

  • Um mesmo tipo de sistema operacional deve ser utilizado em todos os serviços criados;
  • Uma cópia do build deve ser utilizada para cada novo serviço criado;
  • Uma atualização de build, quando realizada, deve ser replicada a todos os demais serviços.
  • Um mesmo usuário Microsoft ® Windows deve ter direitos na pasta compartilhada (RootPath) e deverá pertencer ao grupo “Administrador”, para que possa ser associado ao serviço de cada servidor.
  • O nome do ambiente, convencionalmente definido como [SPED] deve ser idêntico para todos os servidores.
  • Separe em um servidor dedicado, o ambiente de homologação: homologação é uma operação de menor relevância, que não deve ser executada no mesmo serviço que atende as conexões do ambiente de produção para que não haja concorrências desvantajosas ao processo.
  • O valor de RootPath=\\SERVER1\protheus_data\ deve ser o mesmo para todas as instâncias, para os ambientes Environment de mesmo nome e não devem compreender unidades de letra “mapeadas”.
  • Reserve 2 GB de memória RAM para cada instância do servidor de aplicação, que pode ser na mesma máquina desde que tenha capacidade para isso.
  • Nos ambientes balanceados deve haver um único repositório (RPO). Não compartilhe RPO em rede, pois os servidores de aplicação fazem leitura intensiva do RPO quando executam os JOBS, visto que neles estão compiladas todas as regras de negócio. Se o RPO é compartilhado em rede, tem como resultado:
      • Degradação na performance de execução dos servidores de aplicação que utilizam o RPO compartilhado (tráfego de RPO em rede).
      • O aumento do consumo de recursos de rede nos servidores que compartilham RPO, tipicamente, saturam o uso das interfaces de rede, criando uma concorrência de transmissão de dados.
         

Nota

O repositório de funções do TSS (Apo) é do tipo Small Application e contempla apenas as funções relativas às regras de negócio do TSS, além da LIB de Framework. Os demais recursos do ERP não estão presentes neste arquivo.

Alguns pontos são imprescindíveis no balanceamento e bom funcionamento do TSS. Os pontos referentes à recursos físicos de máquina, são válidos para qualquer distribuição do TSS, quanto aos parâmetros de configuração, à partir do release 12.1.3, O TSS segue o modelo de Balanceamento por Demanda(escalabilidade), despresando alguns critérios de configuração encontradas nos releases anteriores como range de entidades. 

  • É recomendado que um servidor do TSS seja configurado para atuar apenas como WebService.
  • A quantidade de Jobs configurados em um servidor impacta no consumo de recursos da máquina, assim como, na agilidade que cada JOB e cada procedimento tem, portanto, como recomendação, balanceie os Jobs e os procedimentos pelo tamanho de carga.
  • Caso um JOB (exemplo o de NFe) seja muito utilizado por possuir grande quantidade de notas a serem transmitidas, monitoradas, isole este JOB em um servidor separado dos demais JOBs em concorrência.
  • Caso algum procedimento de algum JOB seja muito utilizado ou apresente tempo de espera acima do esperado a ser executado, isole-o em um servidor, separado dos demais Jobs e procedimentos.
  • Observe a quantidade de entidades ativas e configuradas para serem processadas nos Jobs. Quaisquer entidades que não requeiram o processamento, ou que não são utilizadas, devem ser desativadas no TSS ou configurados os Jobs para que não sejam processadas.
  • Entidades que possuem um volume grande de documentos a serem processados, ou demandam maior prioridade na agilidade dos processos, devem ser isoladas em servidores dedicados a elas, garantindo que o processamento seja prioritário distante das demais entidades.
  • Acompanhe a utilização dos recursos físicos da máquina como memória e processador, se a utilização está acima do esperado, balanceie os Jobs e, se necessário, as entidades em máquinas diferentes, para não ocasionar lentidão no processo do TSS.

Modelos de Balanceamento

A maior parcela do processamento do TSS se resume às tarefas de construção dos lotes, assinatura digital do documento, transmissão ao fisco e verificação dos possíveis retornos do processamento fiscal. Por esta razão, o balanceamento tem como foco estas tarefas. Para atender as diferentes necessidades encontradas, o TSS compreende quatro modelos de balanceamento no que diz respeito ao processamento destas tarefas, abaixo listados:

  • Balanceamento por Entidade ou Filial;
  • Balanceamento por Tipo de Documento;
  • Balanceamento por Tipo de Atividade;
  • Balanceamento Misto.
  • Balanceamento por Demanda

Nota

Independentemente do modelo de balanceamento adotado, recomenda-se que o WebServices de recepção de documentos do ERP sempre esteja isolado em um serviço exclusivo para este propósito, para que não ocorram concorrências de performance.

Conteúdos Relacionados