A arquitetura do SmartERP é diferente da disponibilizada no cloud padrão ou em uma nuvem privada. Utilizamos o conceito de deploy em contêineres.

Abaixo, explicamos melhor o conceito e todos os componentes da arquitetura SmartERP Protheus.

Contêineres

Contêineres são um conjunto de processos isolados do resto do sistema.  Eles criam um ambiente completo de execução, incluindo um aplicativo e todas as suas dependências, bibliotecas e outros binários e arquivos de configuração que são necessários para executá-lo, tudo isso agrupado em um pacote. Com a criação desse contêiner isolado para a aplicação, diferenças nas distribuições de sistema operacional e na infraestrutura utilizada são abstraídas.

É importante não confundir contêineres com virtualização. Na execução das aplicações em contêineres, há um único sistema operacional, e cada contêiner compartilha o kernel do sistema operacional com os demais, mesmo permanecendo individualmente isolados. O que isso significa em termos práticos? Bem, enquanto um contêiner pode ter apenas pouco mais de 10 megabytes de tamanho, um servidor virtual – que obrigatoriamente inclui todo um sistema operacional – normalmente, ocupará vários gigabytes.

Esse tipo de arquitetura é conhecida como microsserviços (microservices), e aplicações que são desenvolvidas nesse modelo são bem mais simples de gerenciar, por exemplo, é possível já que cada módulo é relativamente simples e conta com interfaces e operações bem definidas, é perfeitamente possível realizar atualizações individuais em cada módulo sem ter que reconstruir a aplicação como um todo.

Colocando em termos bem simples, os contêineres são algo extremamente prático e que, cada vez mais, estão sendo adotados por organizações que querem ter mais agilidade ou mesmo adotar uma abordagem baseada em DevOps. Essa facilidade de uso cria uma tendência bem simples: uma vez que você começa a utilizar, contêineres podem crescer em número muito rapidamente, se multiplicando em uma velocidade assombrosa!

Para orquestrar todos os contêineres, utilizamos o Kubernetes, que organiza os contêineres em grupos chamados pods, isso permite solucionar boa parte dos problemas relacionados a sua proliferação. Os pods criam uma camada extra de abstração. Desta forma, fica bem mais fácil controlar a carga de trabalho e fornecer serviços necessários ao funcionamento dos contêineres, como rede e armazenamento.

Dentre outras funcionalidades, o Kubernetes permite:

• Orquestrar contêineres em múltiplos hosts, em clouds públicas, privadas ou híbridas.
• Otimizar o uso do hardware, maximizando a disponibilidade de recursos para execução dos aplicativos.
• Maior agilidade para escalar aplicativos em contêineres e recursos relacionados.
• Gerenciar e automatizar a maior parte das implantações e atualizações de aplicativos.
• Garantir a integridade e autorrecuperação dos aplicativos em contêineres, com posicionamento, reinício, replicação e escalonamento automáticos.

Componentes dentro da arquitetura

Cada componente em execução do Protheus é separado dentro de um pod, onde temos:

• License Server
• DbAccess
• LockServer
• AppServer
  • Execução do ERP
  • Execução do Configurador
  • Execução do Portal
  • Execução do REST
  • Execução do WebService
• FileSystem (protheus_data)
• Banco de dados
• Serviço de customização

Diagramaticamente, temos o seguinte modelo disponibilizado:

Importante: Todas as topologias contém todos os artefatos listados acima, porém em alguns casos, é necessário um licenciamento especifico de uso. Para este caso, solicitamos que consultem o contrato de uso antes de utilizar o componente.

O ambiente utiliza um sistema operacional Linux e todos os componentes do ERP estão homologados para esta arquitetura. O banco de dados é gerenciado pela própria nuvem publica, com diversas camadas de proteção, cujo somente a topologia consegue enxergá-la.

Também, disponibilizamos no ambiente de produção, a exclusividade de execução do Appserver do ERP por usuário, ou seja, cada usuário terá um Appserver exclusivo para o seu uso, não havendo concorrência de recursos computacionais do Appserver.

Cabe salientar que a topologia trabalha em uma nuvem pública de baixa latência (localizada em São Paulo).

Prevenção de desastres

Com a disponibilização no modelo de contêiner, os componentes sempre irão utilizar uma imagem base para execução, Caso haja uma queda ou perda de conexão em um dos componentes, a arquitetura irá restabelecer-se ao estado anterior da queda. Isto diminui em muito as ações manuais dentro do ambiente, tornando-o mais confiável e estável ao uso.

A única exceção neste modelo são os artefatos exclusivos de uso do cliente, como o banco de dados e volume (FileSystem). Estes dois componentes variam de acordo com o uso do cliente e devido a isto criamos agentes de monitoramento que executam verificações e backups diários destas informações. Caso haja algum problema com este componentes, o agente avisará o operador/administrador do sistema, cujo irá realizar a manutenção manual nos mesmos.

Cabe salientar que além da execução diária dos backups destes componentes, também executamos o backup caso haja uma intervenção manual e/ou atualização. Isto previne que haja perda de informações recentes.

Modelo de Uso do ambiente

O SmartERP utiliza o modelo SERVERLESS em sua estrutura, pois o SmartERP tem como sua essência a otimização dos recursos do cliente e da nuvem . O serverless é diferente de outros modelos de cloud computing em que o provedor de nuvem é responsável por gerenciar a infraestrutura da nuvem e por escalar as aplicações. As aplicações serverless são implantadas em containers que são iniciados sob demanda e automaticamente quando chamados.

Em um modelo padrão de cloud computing baseado em infraestrutura como serviço (IaaS), os usuários compram unidades de capacidade. Ou seja, o provedor de nuvem pública fornece componentes de servidor "sempre ativos" para a execução das aplicações. Os usuários precisam aumentar a capacidade do servidor nos momentos de alta demanda e diminuí-la quando a capacidade alta não é mais necessária. Mesmo quando as aplicações não são usadas, a infraestrutura de nuvem necessária para executá-las continua ativa.

Em comparação, com a arquitetura serverless, as aplicações são iniciadas apenas quando necessárias. Quando um evento aciona a execução do código da aplicação, o provedor de nuvem pública aloca os recursos relacionados dinamicamente. Os usuários deixam de ser cobrados quando essa execução termina. Além do aumento da eficiência e da economia, o modelo serverless livra os desenvolvedores das tarefas rotineiras e manuais associadas ao provisionamento do servidor e à escala da aplicação.

Com o modelo serverless, todas as tarefas rotineiras são realizadas pelo provedor de serviços de nuvem. Elas incluem, por exemplo, o gerenciamento do sistema operacional e de arquivos, a aplicação de patches de segurança, o balanceamento de carga, a administração da capacidade, a escala, a geração de registros e o monitoramento. Desta forma, todos os serviços do ambiente são executados somente quando há a requisição do serviço. Quanto não há, o ambiente se auto-gerencia para otimizar os recursos disponíveis dentro dos ambientes.

Consulta de Logs do ambiente

Mesmo com todos os agentes de prevenção de desastres do ambiente, ainda há algumas ações dentro do ERP que são de exclusividade do Protheus e devido à isto, disponibilizamos dentro do FileSystem do cliente, os logs de execução de todos os componentes da arquitetura. Estes logs encontram-se na pasta /volume/logs e podem ser acessados via sftp. Para maiores informações sobre como acessar estes artefatos, acesse: 7. SmartERP Protheus - Arquivos de instalação do ERP