Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

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

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

Índice

...

Contêineres

Contêineres são um conjunto de processos isolados do resto do sistema, eles .  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 containercontê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 container 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 container contêiner pode ter apenas pouco mais de 10 megabytes de tamanho, um servidor virtual – que obrigatoriamente inclui todo um sistema operacional – normalmente estará ocupando , 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 modulo 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 conteinerscontêineres, utilizamos o Kubernetes, que organiza os contêineres em grupos chamados “pods” pods, isso permite solucionar boa parte dos problemas relacionados a sua proliferação. Os pods criam uma camada extra de abstração. Desta forma, dessa 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.

...

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:

Image Modified

Importante: Todas as topologias contém todos os artefatos listados acima, porem 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 enxergaenxergá-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).

Aviso

É impreterível que a latência da sua rede local e internet estejam abaixo de 70ms. Caso esteja acima disto, poderá ocorrer perda de pacotes e o sintoma de lentidão ao navegar no ambiente.

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). Este 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 alem 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.

Informações

Por motivos de segurança e normalização, não será possível executar ações como:

  • Alteração de dicionário de dados;
  • Execução de Upddistr;
  • Execução de Rup´s;
  • Aplicar pacotes (.ptms);
  • Compilar fontes diretamente no RPO;
  • Acesso ao monitor do Dbaccess;
  • Acesso ao monitor do Protheus;
  • Acesso direto ao banco de dados;
  • Parar serviços/componentes do ambiente;.

Isto deve-se ao modelo de disponibilização do SmartERP Protheus

Todas as ações listadas exigem uma parada no ambiente e execução exclusiva e devido aos agentes de monitoramento do ambiente, estas ações não poderão ser executadas sem que haja a interrupção do mesmo.

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