Instâncias Recomendadas
Foram testadas diversas instâncias e a que apresentou melhor performance para o uso do Protheus foi a família EC2 M7, que pode ser visualizada no site da AWS ou na planilha abaixo.
Configuração de cenário
Cenários que necessitam de disponibilidade 24x7 podem:
- definir uma instância das pré-desenhadas, que não será desligada quando seu consumo for inferior a 10% do total de CPU;
- trabalhar com máquinas menores, em horários de menor consumo, podendo utilizar RDS com o seu principal SGBD ou uma Instância EC2 com um banco de dados homologado.
- Instância Primária: Possui a função de Gateway, direcionando as conexões para as instâncias Secundárias. Se conecta nas instâncias Secundárias, Secundárias VIP, WF/WB/SCH/JOB, e Database.
- Instância Secundária: De 1 a N, recebe as requisições da Primária para processamento. Não é recomendado instalar outros serviços. Elas podem ser escalonadas horizontalmente conforme a necessidade.
- Instância Secundária VIP: Para cenários que necessitam de alta disponibilidade, pode ser definido uma instância das pré-desenhadas que não será desligada quando o consumo estiver abaixo de 10%. Neste cenário, é importante a configuração de um broker (balanceamento de carga), exclusivo após a escolha do blueprint.
- Instância WF/WB/SCH/JOB/Rest: Este servidor vale para Work Flow, WebService, Scheduler, Rest ou Jobs.
- Database: É possível utilizar um Database (dentre os bancos homologados, tais como PostgreSQL, Oracle ou SQL Server) em RDS ou instalado em uma instância EC2.
- Instância TSS (SPED): Recomendamos que uma instância específica seja dedicada ao TSS.
- Volumes EBS para o uso da Protheus_data no servidor Primário: O volume para o sistema operacional pode ser do tipo General Purpose SSD (gp2). Porém, para o diretório Protheus_data, quando se usa o CtreeServer para a gestão do dicionário no modelo ISAM, pode-se utilizar opção de General Purpose SSD (gp2). Lembrando que é necessário um disco maior, para ter a quantidade de IOPS necessária para o seu consumo (proporção distribuída no valor de 3 IOPS para cada GiB), ou optar por um modelo de Provisioned IOPS SSD (io1 ou io2).
- Volumes de Finalidade geral (SSD) (gp2):
Tamanho do volume: 1 GiB – 16 TiB
IOPS máxima por volume = 16,000
IOPS máxima por instância = 160,000
Taxa de transferência máxima por volume = 250 MiB/s - Volumes de Finalidade geral (SSD) (io1 e io2):
Tamanho do volume: 4 GiB – 16 TiB
IOPS máxima por volume = 64,000
IOPS máxima por instância = 160,000
Taxa de transferência máxima por volume = 1,000 MiB/s
Para ambientes com Dicionário no banco é recomendado, além do disco estar em high performance, as seguintes instâncias (lembrando que, quanto maior o tamanho do disco, mais performático será o throughput):
- Instância Primária: Instância m7, App Broker, App Broker VIP, App Compilação, App Balance (monitor), License Server, DBAccess SPOFless, DBAccess secundário; Utilizando o EBS é recomendado o volume de 120GB no C:/ em cenários Windows e no / em cenários Linux.
- Instância(s) Secundária(s): Instância m7, com AppServer Secundárias e DBAccess secundário. Utilizando o EBS é recomendado o volume de 120GB no C:/ em cenários Windows e no / em cenários Linux.
- Instância WebService/Job/Workflow: Instância m7, com Protheus WEBRest, Protheus WEBService, Protheus Workflow, Protheus JOB, Protheus Schedule, Protheus Mobile, e um DBAccess em modo secundário. Utilizando o EBS é recomendado o volume de 120GB no C:/ em cenários Windows e no / em cenários Linux.
- Instância TSS: Instância m5, com Broker (balance), Appserver Secundários e DBAccess (Single). Utilizando o EBS é recomendamos o volume de 512GB no C:/ em cenários Windows e no / em cenários Linux.
É recomendado que todas as instâncias com Protheus utilizem a feature placement group. Ao utilizá-la, o posicionamento de um grupo de instâncias interdependentes será influenciado, dependendo da opção escolhida, minimizando riscos de erros ocasionados por falhas relacionadas à distribuição de carga de trabalho.
As três opções disponibilizadas pela AWS são:
Cluster
Partition
Spread
Foram realizado testes nestas três opções, porém a que apresentou melhor perfomance para a utilização do ERP Protheus foi a Cluster, que agrupa instâncias em uma zona de disponibilidade. “Essa estratégia permite que as cargas de trabalho atinjam o desempenho de rede de baixa latência necessário para a comunicação de nó a nó, totalmente acoplada que é típica dos aplicativos HPC”, conforme documentado no site da fabricante.
A opção homologada para o uso do Protheus é o Placement Group com a estratégia de Cluster.
Consulte o site da fabricante para mais informações sobre a feature Placement Groups.
Atenção: Região escolhida
Para minimizar a latência, escolha a região mais próxima à sua localização.
Os Security Groups (Grupos de segurança) agem como um firewall virtual para controlar o tráfego de entrada e saída das instâncias EC2. Por padrão, o tráfego de saída (ou seja, da instância para a internet) é livre. Não podem ser criadas regras que neguem o acesso a algo; as regras sempre serão permissivas, pois na ausência destas, o acesso é bloqueado.
Desenho sugerido:
Utilize esta alternativa com três objetivos:
- Agrupar melhor os recursos na AWS;
- Ter melhor controle de custos;
- Ter melhor organização das permissões de segurança.
Sugestão de compartimentos:
Produção Aplicação Database | Homologação Aplicação Database | Desenvolvimento Aplicação Database |
Desenho sugerido:
Atenção
Esta seção não atende às últimas atualizações de release do Protheus, e deve ser utilizada apenas para consulta em cenários com ambientes legados.
Blueprints recomendadas, de acordo com a quantidade de usuários simultâneos
Atenção
Estas estimativas são referentes ao uso do produto Protheus padrão. Caso alterações sejam necessárias, o cliente pode fazer o scale-up/down (escalonamento vertical, adicionando recursos de processador e memória) ou o scale in/out (escalonamento horizontal, adicionando instâncias secundárias).
Nota
As quantidades de usuários são referentes a usuários simultâneos acessando a aplicação. Threads em execução pelo Scheduler ou Jobs também são consideradas como usuários.
Nos cenários onde uma máquina não pode ser desligada, é possível utilizar uma máquina secundária VIP, que ficará disponível em períodos de baixo consumo de recursos.
É possível utilizar diferentes instâncias para atender à quantidades de usuários mais específicas. Neste caso, será necessário apenas ajustar no Broker a quantidade de usuários para cada Appserver.
No exemplo abaixo, são definidas quatro instâncias, com dois Appserver cada, e o exemplo para a configuração do Broker. Na seção [BALANCE_SMART_CLIENT_DESKTOP], as chaves REMOTE_SERVER_XX são referentes aos IPs de cada instância; estes endereços, portas e quantidades de usuários exibidos são meramente ilustrativos.
Atenção
Verifique também as recomendações ou restrições sobre banco de dados.