Histórico da Página

Conforme estudo realizado em conjunto com o time de arquitetura da Oracle (responsável pela OCI - Oracle Cloud Infrastructure), estudamos cenários computacionais gerando melhores insights dentro de sua arquitetura computacional. Primeiro, abordamos os termos e conceitos que serão utilizados nos próximos passos: 

Escalonar horizontalmente - scale out/in: Adicionamos mais VMs ou serviços para a distribuição da carga dos serviços do Protheus. Podemos, por exemplo, necessitar de uma nova VM com 6 serviços slaves e um DBAccess que utiliza modo distribuído ou SPOFLess. Como os recursos computacionais estão mais acessíveis e o desempenho continua a crescer, aplicações de computação de alto desempenho - como análise sísmica e cargas de trabalho - tem uma mudança muito rápida no volume de dados para tarefas que antes exigiam melhor desempenho.  Com o escalonamento horizontal, podemos liberar recursos, diminuindo a bilhetagem, e obter poder de computação agregada (que geralmente excede ao de computadores baseados em um único processador tradicional).

O desenvolvimento de interconexões de alto desempenho, como Ethernet Gigabit, entre os servidores respeitando o tráfego de dados de no mínimo 1 Gigabit por segundo, aliado ao nível de processamento com clock mínimo de 2.0GHz, demonstra desempenho conforme estudo já realizado com este clock. Também é importante ressaltar que quanto maior o clock, mais poder de processamento; temos, consequentemente, melhores tempos para o processamento de relatórios. O crescimento constatado  direcionou para demanda por  arquitetura scale out/in, já que esta possibilita o gerenciamento e manutenção mais eficientes de vários nodes, com o mínimo de recurso operacional.

A imagem abaixo demonstra um exemplo de máquinas slave em cenários com crescimento pela horizontal:

Image Removed

Escalonar verticalmente - scale up/down: Adicionamos ao servidor (master ou slaves) recursos para o melhor gerenciamento dos serviços que estão sendo executados. Este procedimento dificilmente ocorrerá nos slaves, já que quando estes estão com consumo elevado, pode ser feito o escalonamento horizontal. Estes recursos são referentes apenas à máquina, como CPU, memória ou disco, por exemplo.

BoundServer: O c-tree BoundServer (c-tree Server DLL) é, basicamente, um servidor c-tree que sobe junto (embarcado) com o TOTVS | Application Server. É recomendado seu uso em ambientes onde é utilizado apenas um TOTVS | Application Server, onde os dicionários não têm seu acesso compartilhado com outras instâncias do TOTVS | Application Server. 

Para habilitar este modo de funcionamento, altere o valor da chave ctreeMode na seção General do arquivo de configuração do TOTVS | Application Server (appserver.ini) para BoundServer.

Dicionário em Memória RAM: Pensando em um cenário de escalabilidade horizontal para o Application Server (onde distribuímos vários serviços "Slave" do Application Server em vários equipamentos), foi desenvolvido um mecanismo de cache dos dicionários de dados (SXS) do ERP em memória, com sincronismo automático, em parceria com a Faircom® para retirar o overhead de rede na leitura dos metadados. Para isso, a partir da Build 7.00.121227P, o pacote de arquivos do Application Server passa a ser distribuído com uma versão do c-Tree Server compilada em DLL, conhecida por BoundServer. Utilizando um c-Tree Server com a licença Faircom c-Tree Server Enterprise, podemos configurar um ou mais Application Servers do ambiente para replicarem os dicionários do ERP desejados entre estas instâncias, onde cada Application Server com esta configuração vai acessar os dados dos arquivos do cache para operações de leitura, e um mecanismo de sincronismo entre o c-Tree Server e os Application Server(s) trabalhando com o cache (mecanismo ou thread de notificação) mantém os caches dos dados atualizados caso alguma das tabelas em memória seja alterada. 

Abaixo, o desenho da arquitetura BoundServer:

Image Removed