SIZING Protheus MaqCampo

Relatório de Dimensionamento
de Ambiente (SIZING)
Cliente Maqcampo
Relatório de Dimensionamento de Ambiente
Sumário
1. Objetivo .............................................................................................................................................................................................. 3
2. Escopo ................................................................................................................................................................................................. 3
3. Ambiente Solicitado - Produção .................................................................................................................................................... 3
4. Analise do cenário atual ................................................................................................................................................................ 11
5. Diagrama do Protheus ................................................................................................................................................................... 12
6. Sistema Operacional Homologado AppServer Protheus....................................................................................................... 13
7. Banco de Dados Homologados Protheus ................................................................................................................................. 14
8. Meios de Comunicação ................................................................................................................................................................. 15
9. Ambiente com Latência (Protheus)............................................................................................................................................. 16
10. Cenários do SIZING ........................................................................................................................................................................ 17
11. Sizing de Aplicação VmWare ....................................................................................................................................................... 18
11.1 Cenário Recomendado – ERP em Plataforma VmWare ........................................................................................................ 18
11.2 Volumetria VM’s ............................................................................................................................................................................. 22
11.3 Sugestão de Host Fisico para Aplicação VmWare .................................................................................................................. 23
11.4 Softwares .......................................................................................................................................................................................... 24
11.5 Considerações ................................................................................................................................................................................. 24
12. Banco de Dados .............................................................................................................................................................................. 25
12.1 Hardware Fisico .............................................................................................................................................................................. 25
12.2 Considerações ................................................................................................................................................................................. 27
12.3 Softwares .......................................................................................................................................................................................... 28
13. Observações do Cenário Recomendado ................................................................................................................................... 28
14. Ambiente DEV e QA ...................................................................................................................................................................... 31
14.1 Aplicação - PL .................................................................................................................................................................................. 31
14.2 Servidor Fisico ................................................................................................................................................................................. 32
14.3 Softwares .......................................................................................................................................................................................... 33
14.4 Observações .................................................................................................................................................................................... 33
15. Requisitos de Software e Parâmetros do Sistema .................................................................................................................. 34
15.1 Balanceamento Utilizando Broker .............................................................................................................................................. 34
16. Informações Adicionais ................................................................................................................................................................. 34
17. Pontos de Atenção VmWare ....................................................................................................................................................... 35
18. Advertências Vm’s .......................................................................................................................................................................... 36
19. Considerações ................................................................................................................................................................................. 36
20. Requisitos de Ambiente ................................................................................................................................................................ 38
21. Histórico de Revisões .................................................................................................................................................................... 38
2
1. Objetivo
Orientar o cliente Maqcampo na concepção de cenários de infraestrutura, de forma a atender as necessidades da
companhia na utilização das soluções TOTVS Protheus 12.1.27, considerando a situação atual e perspectivas de
crescimento, com foco na operação e disponibilidade do ambiente dentro do padrão de mercado.
O trabalho de sizing de ambiente ERP verifica se os recursos de hardware atual (se houver) estão adequados para
executar a nova versão do ERP. Contudo o tempo de execução das rotinas pode variar, devido a novas
implementações e alterações nas rotinas.
2. Escopo
Dimensionamento de hardware, software complementar e conectividade necessária para suportar a solução de ERP
TOTVS Protheus 12.1.27.
3. Ambiente Solicitado - Produção

Cliente solicitou um SIZING do ambiente Protheus para a release 12.1.27.
Em conversa com o cliente, não se sabe ao certo o total de threads que o ambiente deve ser dimensionado.
O cliente informa que ao tentar se aproximar do pico de conexões (durante o fechamento), ocorre queda dos
servidores, interrompendo as conexões.
Essa queda ocorre devido a sobrecarga de operação em uma infra reduzida. Foi criado uma única VM de aplicação
para suportar toda a demanda de produção.
Cientes que existem 400 usuários com acesso a aplicação, e que no dia 06/10 foi observado que o total de conexões
no ambiente (período da manhã) possuia quase 1.200 threads, foi acordado a realização do sizing de forma urgente,
para que fosse possível aproveitar o cenário proposto e implanta-lo antes do fechamento de outubro.
Isso somente é possível devido o cliente estar com o ambiente instalado em um cloud (privado).
Para a aplicação, o sizing deve ser destinado para atender 850 conexões simultâneas, mais as threads de dicionário de
dados, totalizando 1.700 threads simultâneas no DBAccess.
Considerar desse total 100 threads referentes aos Jobs, já com as threads de dicionário contabilizadas.
Com esse cenário, estamos considerando que se todos os 400 usuários estiverem executando alguma operação,
apesar de estar ciente que podem operar diversas telas, o sistema teria uma capacidade de processamento para
sustentar 02 processamentos simultâneos para cada usuário.
O cliente não sabe ao certo o total de conexões durante o fechamento, mas com esse cenário pretendemos aliviar o
consumo, criando um cenário mais estável para produção, podendo o cliente ampliar a infra (escalabilidade) ou
diminuir, caso limite a quantidade de conexões por usuário.
Todo o ambiente deve ser considerado em plataforma virtualizada (VmWare), considerando que está hospedado
em um cloud.
Deve ser considerado o cenário recomendado, fornecendo opções de escalabilidade.
Cenário Recomendado: Aplicação em plataforma virtualizada VmWare e o banco de dados em plataforma física.
O banco de dados será entregue em plataforma física, de forma que a Cloud escolhida possa avaliar qual cenário
de sua infra atende a necessidade proposta em sizing.
Para o banco de dados, foi solicitado que seja utilizado o SQL Server 2017 Standard Edition.
3
O cliente solicitou considerar um acréscimo de 30% a mais de volume nas base de dados, sem considerar a
compressão para o banco de dados ERP, dimensionando para os próximos três anos.
Considerando que esse é um ambiente inicial, consideramos 200GB de dados para o ERP, podendo ser iniciado
com um volume menor.
Lembrando que bases de dados com volume próximo a 1TB, recomendamos que seja realizada a compressão.
Esse volume é uma estimativa. Em alguns casos, dependendo do tamanho de tabelas, a compressão pode ajudar
na performance do sistema.
Quando estiverem com mais de 500GB de volume de dados, recomendo uma avaliação do ambiente.
No sizing será estimado também um volume de 300 GB para a base de dados do Audit Trail (Auditoria), podendo
ser usado de forma opcional.
Além da base do ERP e Auditoria, segue abaixo as bases de dados que devem ser consideradas, e suas volumetrias:
NomeDoBanco DataFileSize
TMPRD 200GB
TSSPRD 100GB
Audit 300GB
Esse documento possui todos os dados que serão utilizados como base, para geração desse sizing.
Segue abaixo algumas informações uteis para conhecimento do cliente:
Alta Disponibilidade a nível de aplicação:

Para alta disponibilidade a nível de aplicação, recomendamos que o ambiente seja instalado em plataforma física.
Dessa forma a aplicação pode ser instalada em um cluster Microsoft (Failover Microsoft), de forma a atender a
solicitação de alta disponibilidade a nível de aplicação.
Em plataforma virtualizada, a alta disponibilidade é a nível físico.
O próprio Hypervisor possui funcionalidades para prever disponibilidade, sem uso do Failover Microsoft, e nesse caso,
podendo a aplicação estar em Linux ou Windows, seguindo as plataformas homologadas.
DMZ:
O Ambiente do cliente possui serviços que podem ficar em uma DMZ, como o TSS e WebServices (caso venha a possuir).
Esses serviços podem ser colocados em VM’s dedicadas para atender a DMZ, ou em LUNS dedicadas no Failover, com
um IP dedicado.
Banco de Dados em plataforma virtualizada:

A TOTVS segue sempre as recomendações dos fabricantes, e procura não colocar os clientes em risco.
Seguindo essas premissas, a TOTVS não recomenda banco de dados em plataforma virtualizada em cenários On
Premise, recomendando sempre em plataforma física.
Para clientes que procuram sizing em cloud homologadas como OCI (Oracle), AWS (Amazon), Azure (Microsoft) e GCP
(Google), a TOTVS realiza as indicações para banco de dados, considerando a infraestrutura dessas Cloud.
Para as outras cloud, a TOTVS apresenta o dimensionamento do banco de dados em plataforma física, de forma que
o cliente, junto a cloud escolhida, possam avaliar qual o ambiente da cloud melhor atende o cenário.
O cliente deve sempre seguir as plataformas homologadas do fabricante do banco de dados, além de seguir as
orientações do Hypervisor e cloud escolhido (Caso optado por uma cloud).
4
Com base nas informações levantadas, segue abaixo os fatores relevantes para o desenvolvimento do sizing:
Protheus
CENARIO ATUAL:
Ø Poderá ser dimensionado novos servidores no SIZING, sem a necessidade de reutilizar (se possível) os
servidores atuais, no caso desses servidores não estarem aptos?
Sim.
Ø Possui alta disponibilidade (Cluster/AlwaysOn/Rac) no cenário atual?

Sim. Ambiente em cloud Privado com HA a nível físico.
Ø Favor responder o questionário de infra atual:
Segue abaixo os servidores presentes na Maqcampo:
- Servidor (banco de dados)

- Windows Server 2019 Standard
- 4 Vcpu´s
- 64 Gb de memória
- Disco 1 = 200 GB (SAS)
- Disco 2 = 200 GB (SSD)
- Servidor (Aplicação)
- Windows Server 2019 Standard
- 8 Vcpu´s
- 72 GB de memória
- Disco = 260 GB (SAS)
Os servidores acima estão em nosso sistema de virtualização Vmware, onde possuímos HA em nosso
ambiente.
A nossa estrutura se baseia em servidores HPE DL 360 GEN 10 com dois processadores conectados à
storages da linha HPE também.
Ø Versão da aplicação atual? 12.1.027 – Out 2020
Ø Dicionário em disco com CtreeServer ou no banco de dados? Banco de dados.
Ø Qual a Build do:
o Binário: 7.00.191205P-20210114 – 64 bits

o DBAccess: 20200606 – 20200110 on WinNT (x64)
Ø Numero de usuários simultâneos na aplicação no momento de pico:
§ DbAccess: Dia 06/10 as 10:45 = 1.074 conexões simultâneas (considerando thread de dicionário).
§ Monitor: Não informado, mas possível média de 500 conexões fora do fechamento. No fechamento
o numero pode aumentar.
Ø Qual o sistema operacional da:
§ Aplicação: Windows Server 2019 Standard

§ Banco de Dados: Windows Server 2019 Standard
5
Ø Possui virtualização? Se sim, da aplicação e/ou Banco de Dados? Hyper-V ou VmWare? Qual versão?
Sim. VmWare em cloud Privado.
1 VM de Banco de dados e 1 VM de Aplicação produção.
Ø Versão do Banco de Dados (Oracle, SQL, DB2, etc.). Standard ou Enterprise?

SQL. Microsoft SQL Server 2017 (RTM-CU22) (KB4577467) - 14.0.3356.20 (X64)
Aug 20 2020 22:33:27 Copyright (C) 2017 Microsoft Corporation Standard Edition (64-bit)
on Windows Server 2019 Standard 10.0 <X64> (Build 17763: ) (Hypervisor)
Ø Tamanho do Banco de Dados de produção (Banco Principal, TSS, TAF e Audit Trail):
Segue os tamanhos de banco de dados:
NomeDoBanco DataFileSizeMB LogFileSizeMB

TMDEV 1GB 448MB
TSSDEV 256MB 128MB
TSSHML 1GB 448MB
TMHML 23.296GB 43.776GB
DW 264MB 328MB
TMPRD 32.896GB 43.8GB
TSSPRD 1.3GB 896MB
LinxMaq 776MB 1.2GB
ReportServerMaqcampo 72MB 72MB
ReportServerMaqcampoTempDB 8MB 72MB
ReportServer 72MB 72MB
ReportServerTempDB 8MB 72MB
Ø A base de dados está comprimida? Não.
Ø Utiliza Features como In-Memory ( Tabela na Memoria Ram – Somente na versão Enterprise do Banco de
Dados) Não.
Ø Possui tabela ou índice particionado no banco de dados? Não.
Ø Possui tabelas no Banco de Dados Protheus, que não são lidas pelo ERP (Integração com outros softwares)?
Não.
Ø Utiliza Storage para armazenamento da base de dados? Se sim, responder:

Ambiente em cloud Privada. Sem informação.
§ Modelo do Storage:
§ Modelo e quantidade de discos (SAS, SATA, SSD, etc):
§ Qual RAID?
§ Além do Banco de Dados, utiliza o Storage para aplicação?
Ø Rede entre os servidores é GB? Sim.
Ø Qual o modelo do switch utilizado pelos servidores de aplicação
§ Se possível, informe o Layer do switch: Não informado.

§ Switch GB? Não informado.
Ø Quais os módulos utilizados? Sem informação.
Ø Qual o Thoughput de consumo dos servidores (leitura e escrita)? O cenário atual atende sem gerar alta fila em
disco? Sem informação.
6
Ø Qual o pico de IOPS do servidor de banco de dados?

Se o dicionário se encontra em disco com ctreeserver, qual o pico de IOPS do servidor onde se encontra a
Protheus_Data? Sem informação
Ø Caso possua serviços Protheus instalados no cenário atual (Balance, Slaves, License, CtreeServer, TSS,
WebService, Schedule, Job, etc.), favor informar a quantidade de serviços que possui, e em quais servidores se
encontra.
Exemplo: Servidor 1 – 1 Balance, 1 License, 1 CtreeServer e 7 slaves

Servidor 2 – 10 TSS, 1 Job e 1 WS.
7
CENARIO FUTURO:
Ø Devera ser considerado alta disponibilidade no SIZING (cluster) para os servidores fisicos? Para banco e
aplicação? Sim para os servidores fisicos.
Ø Deve ser considerado Site de Contingência (DR) /Backup? Não.
Ø Qual o Sistema Operacional que deve ser considerado para os servidores de aplicação? E para o Banco de
dados?
o Aplicação: Windows Server 2019
o Banco de Dados: Windows Server 2019
Ø Qual o Release da Aplicação que o Ambiente deve atender?

Protheus 12.1.27
Ø Considerar Dicionário no Banco de Dados? (Se você já possui o ERP Protheus, e não está com o dicionário no
banco de dados, é possível optar. Para cenário novos, o dicionário no banco de dados é obrigatório).
Dicionário no BD.
Ø Qual a versão do Banco de dados que deseja utilizar? Favor especificar se Standard ou Enterprise (Feature de
compressão, In-Memory, etc.)
SQL 2017 Std. (Pode ser o SQL 2019 já homologado pela TOTVS).
Ø Dimensionar aplicação para quantas conexões simultâneas?
TOTVS: Em reunião com o cliente, foi entendido que o cenário atual não suporta o total de conexões
simultâneas.
O cliente relatou diversos problemas de performance, chegando a travar toda a operação, principalmente em
períodos de fechamento.
Diante do cenário, e considerando os dados fornecidos pelo cliente, eu propus considerar um ambiente para
800 conexões simultâneas, adicionando no cenário as threads de dicionário de dados, totalizando 1.600
conexões no DBAccess.
Considerando as threads de Jobs, será considerado 1700 threads totais simultâneas.
Devido ao cliente não conseguir afirmar hoje qual a quantidade real de conexões simultâneas quando em
período de fechamento, esse cenário proposto irá reduzir os problemas, tornando mais estável as conexões e
proporcionando que o ambiente seja monitorado, de forma que possam obter esse total de conexões.
O ambiente também vai permitir uma escalabilidade, para que possa aumenta-lo conforme necessidade,
podendo inclusive ser maior durante o período de fechamento, reduzindo após o período, diminuindo assim a
quantidade de servidores disponíveis em cloud, reduzindo o seu investimento.
Cliente: Ciente das opções, foi acordado com o Rafael a execução do sizing considerando o plano acima.
Ø No SIZING deve ser considerado para a aplicação servidores virtuais? Se sim, Hyper ou VmWare?
Sim. VmWare.
Ø Para o total acima, está considerando o acesso via SIGAMDI ou SIGAADV ? Caso não saiba, verificar com o
responsável pelo sistema. Se for a primeira instalação TOTVS, verificar com o responsável pela implantação.
SIGAMDI
Ø Para o banco de dados, considerar qual a quantidade de volume (Legado + pós go live considerando 3 anos)?
(Favor responder em GB).
TMPRD 200GB
TSSPRD 100GB
Audit 300GB
8
Ø Considerar Audit Trail?

Não.
TOTVS: Colocado para uso de forma opcional.
Ø Considerar ambiente de desenvolvimento e homologação (Dev/QA)?

Sim.
Ø Caso optado por realizarmos um sizing com alta disponibilidade, além da produção deve ser considerado no sizing
HA para mais algum ambiente (Dev/QA)?
Não.
Ø Quais são os módulos que serão utilizados pelo cliente? Caso já possua o Protheus, quais serão adicionados?
Não informado.
Ø Os servidores novos serão hospedados onde? (Nuvem pública, nuvem privada, On Premises)
Cloud Privado.
Ø Gera notas fiscais eletrônicas? Se sim, responder:

1 serviço de TSS atende o ambiente.
§ Faturamento Atual:
Emissão de quantas Notas Fiscais mês? (Quantidade, não valor).
§ Futuro:
Para quantas notas fiscais mês deve ser dimensionado?
Ø O Modulo Gestão Pessoal será utilizado? Se sim, responder:

Não.
Ø Será utilizado Portal? Se sim, responder:

Não.
Ø Será utilizado WebServices para integração do Protheus com outros sistemas?

Não.
Ø Caso não possua Jobs no cenário atual (ou não possua Protheus no cenário atual), podemos considerar os serviços
dedicados a Jobs (rotinas agendadas para execução) no cenário futuro?
Sim
o Sem projeção, consideramos pelo menos 3 serviços para Jobs. Se quiser um numero maior de serviços,
favor informar.
Cenário atual possui dois serviços de JOB. Mantê-los.
Ø Deve ser considerado no Sizing (se houver) o ambiente Histórico?

Não.
9
Segue resumo do cenário Produção que o sizing deve atender:
PROTHEUS Banco de Dados
Cenário recomendado.
SQL Server 2017 Standard Edition 64 Bits
ERP em VmWare e BD físico – 12.1.27
Sistema Operacional Microsoft Windows Server Sistema Operacional Microsoft Windows Server 2019
2019 Standard ou DataCenter 64 Bits Standard ou DataCenter 64 Bits
Protheus com 200 GB de dados para 3 anos, sendo:
Datafiles de dados ERP: 75 GB;
12.1.27 – 1700 conexões simultâneas:
Datafiles de Índices ERP: 75 GB;
(considerando as threads de dicionário de dados);
Datafiles de Log ERP: 50 GB.
Backoffice para 800 conexões simultâneas;
SPEDNFE com 100 GB:
Datafiles de dados + índices: 50 GB.
Considerar TSS para até 50 mil NF/mês;
Datafiles de Log: 50 GB.
Banco de dados Audit Trail: 300 GB (Opcional);

Backup do banco de dados: 500 GB de volume;
Considerar 50 Threads adicionais, para:
Binário SQL:
• Jobs; Considerar volume para System DB = 100 GB
Considerar volume para Temp DB = 100 GB
O sizing está considerando 3 anos de uso.
Nesse documento, os cenários devem ser dimensionados considerando apenas o cenário recomendado.
Para o banco de dados, os volumes podem ser iniciados com um volume menor, e crescer conforme a demanda.
O Volume de Backup, Auditoria e Binário SQL é uma sugestão.
O DBA do cliente pode aumentar ou diminuir conforme sua decisão.
OBS 1:
Para o banco de dados, a TOTVS sempre recomenda que o banco seja instalado em plataforma física, não sendo
em plataformas virtualizadas. Com exceção de ambientes para Cloud.
O uso do banco de dados em plataforma virtualizada é uma opção do cliente, e sua performance/homologação
deve ser garantida pelo fabricante do banco, Cloud (Caso seja escolhido) e do Hypervisor.
OBS 2:
A TOTVS realiza à homologação do ERP para o banco de dados, independente da plataforma em que o banco de
dados se encontra.
A plataforma de banco de dados, deve atender as plataformas homologadas do fabricante do banco de dados.
10
4. Analise do cenário atual

Em reunião, o cliente informou que o cenário atual apresenta travamento, principalmente durante o período de
fechamento.
O cliente realizou um acesso no ambiente e compartilhou a tela durante a reunião. Foi possível observar pico de
até 1.200 threads no DBAccess, com o servidor de aplicação batendo 100% de consumo de memória RAM.
Nesse momento existiam 160 licenças consumidas, com quase 600 threads provenientes de conexões de usuários
e 600 threads de dicionário de dados.
Sem uso de InactiveTimeOut, e com algumas conexões presas, aparentemente existiam 200 threads em
operações Real-time, fazendo consumo no ambiente.
Como o cliente não soube informar o total de conexões simultâneas que o ambiente deve atender, até pelo fato
de o servidor travar durante os picos em período de fechamento, foi levado em conta os 400 usuários que podem
usar o ambiente e considerado o total de 800 conexões simultâneas para backoffice.
Considerando threads de jobs (50 Threads), teremos o total de 850 conexões simultâneas no ambiente, mais o
TSS.
Adicionando as threads de dicionário de dados, o ambiente deve atender 1700 threads.
O ideal seria realizarmos uma analise do ambiente, e acompanhar o fechamento, de forma que possamos ajustar
o ambiente, para em seguida prover o sizing.
Considerando que o estado nesse momento é critico, foi acordado com o cliente de seguirmos com o sizing
considerando as 1700 threads, e caso necessário, será realizado ajustes (para mais ou para menos), já que o
ambiente apresentado possui escalabilidade.
Sendo esse um ambiente em Cloud, essa solução é possível.
Esse plano fará com que já para o fechamento de outubro, o cliente possa ter um cenário mais estável, podendo
realizar o fechamento, avaliar seus consumos e ajustar qualquer necessidade de infraestrutura.
11
5. Diagrama do Protheus
Arquitetura com balanceamento de Carga e dicionário em disco:
Arquitetura com balanceamento de Carga e dicionário no banco de dados:
12
6. Sistema Operacional Homologado AppServer Protheus

Ø Protheus 12:
Sistemas Operacionais Homologados:
13
Maiores informações:
Plataformas Homologadas:
https://tdn.totvs.com/pages/viewpage.action?pageId=452690307
7. Banco de Dados Homologados Protheus
Status EOL = End Of Life
14
Maiores informações:
Plataformas Homologada:
https://tdn.totvs.com/display/tec/DBAccess+-+Banco+de+dados
https://tdn.totvs.com/display/tec/DBAccess+-+Sistemas+operacionais
8. Meios de Comunicação
• Linha privada (LP) de dados 48 kbps para uma sessão;
• Linha privada (LP) de dados 18 kbps por sessão (utilize um Frame Relay puro), desde que esteja com mais de 5
usuários;
• O tempo de resposta, do site remoto, deve ser inferior a 100 ms (tempo de resposta do comando Ping) em pacotes
de 32 KB;
• Utilize o WTS (Windows Terminal Server) com meta frame, caso o trecho seja realizado por meio de satélite ou
tenha um tempo de latência muito elevado na comunicação remota;
• Outros tipos de comunicação devem ser avaliados.
15
9. Ambiente com Latência (Protheus)

Para ambientes acima de 100 MS de latência, podemos utilizar duas ferramentas criada pela Totvs para cenários com
problema de link ou latência.
Broadband (https://tdn.totvs.com/pages/releaseview.action?pageId=271673853)
A fim de adequar o Protheus às diversas realidades de uso, principalmente para os casos em que o acesso ao Sistema se
dá remotamente, ou para clientes que não dispõem de muitos recursos em suas estações de trabalhado, o Sistema
oferece a funcionalidade Broadband, que possibilita restringir o acesso de determinado usuário ou a um ambiente
específico.
A otimização dos recursos deve ser avaliada de acordo com a necessidade de acesso ao Sistema ou de disponibilidade
de equipamentos, identificada pelo administrador do ambiente.
Estão disponíveis a restrição dos recursos de interface, tais como:
• Menu Funcional
• Painel Online
• Browser de Internet
• Detalhes do Browser
• Painel Transparente
Broker (https://tdn.totvs.com/display/tec/Balanceamento+de+carga+com+broker)
A função do Broker é uma ferramenta que pode ser utilizada para balancear não só as camadas do AppServer, mas
também os WebService, Coletores e Portais.
Esta ferramenta ajuda a tolerar a latência de link, onde os usuários não vão perder as informações que já preencheram,
e também evita uma queda de conexão durante o processamento de alguma rotina (caso a perda de conexão ou
latência do link seja breve).
Lembrando que é necessária uma avaliação dos meios de comunicação utilizados pelo cliente, para determinar qual a
melhor solução a ser implantada.
Também importante ressaltar que as opções acima, são para evitar as quedas de conexões. Porem, a alta latência vai
afetar a performance da aplicação.
16
10. Cenários do SIZING

Foi considerado no sizing os seguintes cenários que atendem a solicitação do cliente:
Cenário Recomendado (12.1.27) –

ERP Virtualizado e banco de dados em plataforma física.
Ambos com HA para o Hardware:
Foi considerado os seguintes requisitos:
• Alta disponibilidade para servidores e banco de dados (servidores físicos);

§ Sugestão de servidores físicos para as VM’s de aplicação;
• Sem necessidade. Ambiente em Cloud.
• Aplicação sobre plataforma virtualizada (VmWare);
§ Recomendação de servidor físico para banco de dados;
• Failover de Banco de Dados na edição Standard – SQL 2017 Standard 64 Bits;
o Banco de Dados na edição Standard;
o Instancia de Cluster de Failover AlwaysOn;
o Feature de Compressão (Compressão do banco de dados).
Se fizer uso da instancia de Failover AlwaysOn para SQL:
Ambos os cenários possuem baixo Recovery Point Objective (RPO) – Volume de dados que podem ser perdidos se um
desastre eliminar as informações sistêmicas.
Se fizer uso do Grupo de Disponibilidade (Availability Group) AlwaysOn para SQL (Apenas na Edição Enterprise);
Além de atender o RPO, o cenário também atenderá o RTO.

Menor Recovery Time Objective (RTO) – Após a ocorrência do Incidente que afeta a disponibilidade do ambiente, o RTO
é o período e o nível de serviço aos quais os processos do negócio devem ser restaurados, de forma a evitar consequências
inaceitáveis, associadas à ruptura da continuidade do ambiente.
17
11. Sizing de Aplicação VmWare

11.1 Cenário Recomendado – ERP em Plataforma VmWare
Segue abaixo o cenário recomendado para o ambiente TOTVS Produção, considerando o release 12.1.27.
Esse cenário considera a instalação do ERP em plataforma VmWare.
Lembrando que foi considerado o total de 850 conexões simultâneas, sendo 800 para Backoffice e 50 para Threads de Jobs.
O cenário já considera as threads de dicionário de dados no banco de dados (1700 threads totais).
Considerado também o TSS (até 50 mil NF/mês).
Considerar o método de balanceamento por memória inicialmente, podendo mudar durante o acompanhamento do
ambiente para CPU, conforme necessidade: https://tdn.totvs.com/pages/viewpage.action?pageId=553343368
18
Segue abaixo os serviços presentes em cada VM:
01 VM Principal – 08 vCPU’s e 12 GB de RAM: com APP Balance Monitor ERP, APP TOTVS Monitor Electron, APP Compilação,
APP Vip, APP Broker Client ERP e DBAccess Secundário;
Recomendamos o volume de 60GB no C:/Windows e o volume de 200GB no E:/Protheus, ambos com disco High Performance
(SSD/Flash). O Volume E:/Protheus é necessário que seja high performance.
06 VM’s Secundárias – 08 vCPU’s e 32 GB de RAM: com 03 APP Protheus Secundários (03 em cada VM) e 01 DBAccess
Secundário em cada VM;
(SSD/Flash).
01 VM DBAccess / License Virtual – 08 vCPU’s e 12 GB de RAM: com 01 APP License Virtual, 01 DBAccess Primário e 01
DBAccess TSS/TAF;
(SSD/Flash).
01 VM JOB Schedule – 04 vCPU’s e 08 GB de RAM: com APP JOB Primário Schedule, 02 APP JOB Schedule e 01 DBAccess
Secundário;
(SSD/Flash).
01 VM TSS / TAF – 04 vCPU’s e 08 GB de RAM: com 01 APP Broker WS TAF e 02 APP TSS 3.0 TAF ESOCIAL.
(SSD/Flash).
01 VM Opcional Disponibilidade (SPOFless e License) – 08 vCPU’s e 12 GB de RAM: com App License Virtual e 01 DBAccess
SPOFless ERP;
(SSD/Flash).
19
Ao total temos 10 VM’s de aplicação no ambiente de Produção, e 01 VM opcional para alta disponibilidade do DBAccess e
license.
Todas as VM’s instaladas com Windows Server 2019 Standard x64 (Podendo ser também o Windows Server 2016, ou
qualquer outro sistema operacional Windows homologado (Se atentar ao item 06 desse documento)).
A VM Primária possui a estrutura da aplicação.

O Serviço Vip está na VM Primária. Se precisar de mais Vips, pode ser necessário criar uma VM dedicada para eles.
Considerando que o cliente não possui uma visão clara do total de conexões simultâneas, foi considerado 06 VM’s para
atender o Backoffice, considerando até 140 conexões simultâneas em cada VM, totalizando 840 conexões simultâneas.
Como o cenário acordado com o cliente é para atender 800 conexões simultâneas, foi pensando em um cenário que atenda
de forma confortável 120 conexões simultâneas por VM (720 conexões simultâneas), possuindo uma pequena folga.
Como não há tempo hábil para uma analise de ambiente, de forma a validar o consumo das conexões dos usuários, esse
ambiente deverá ser acompanhado, podendo ser aumentando o numero de VM’s caso ocorra um numero maior de conexão,
que force o aumente de vCPU’s, podendo também ser limitado o numero de conexões por usuário, diminuindo assim o
consumo de recurso.
Foi considerado 32GB de RAM para cada VM de backoffice com serviços secundários.
Se o sizing fosse dimensionado para um cliente que ainda não estivesse em produção, consideraria iniciar com 40GB de RAM
em cada VM para o Go Live, podendo reduzir essa quantidade após acompanhamento, caso no período de fechamento
existam conexões distribuídas nas VM’s onde não ultrapassem o total de 28GB de RAM, tendo folga para qualquer
necessidade.
Considerando que já estão em produção, podem considerar iniciar com os 32GB de RAM, que já será um cenário melhor que
o ambiente atual, e acompanhem o ambiente principalmente no período de fechamento.
A variação depende claro do consumo de cada rotina, por esse motivo estou considerando média de 150MB à 200MB por
conexão, considerando 29GB em pico de 140 conexões simultâneas (já considerando as threads de dicionário de dados).
Sabendo que algumas rotinas podem fazer um consumo maior, recomendo o balance por memória, fazendo com que o
Broker realize o balance das conexões por memória RAM, distribuindo as conexões para os serviços com menor consumo de
memória.
Se cada conexão consumir até 200 MB, 140 conexões consumiriam 35GB de RAM, e por isso pode ser necessário aumentar
para 40GB de RAM. Tenha em mente que dependendo do uso dos usuários, isso pode ser necessário.
Para os serviços de jobs foi considerado o uso de um balance, criando assim um centralizador de operações, e distribuindo as
threads para os serviços de aplicação.
Considerei uma VM e uma quantidade de memória RAM que atenda os serviços, considerando até 20 Threads.
Caso precise de mais threads ou aumente os serviços de jobs, pode ser dobrado a quantidade de vCPU’s, além de considerar
a memória RAM necessária para suportar os novos serviços.
Não altere as vCPU’s das VM’s para cima, quando a VM possuir 08vCPU’s. O crescimento deve ser feito de forma horizontal,
adicionando VM’s conforme necessidade.
Para a VM de DBAccess e License, é possível fazer uso do DBAccess SPOFless e license modo cluster.
Caso tenham interesse, basta adicionar uma VM ao cenário, sendo essa uma réplica da VM DBAccess + License.
Dessa forma, caso ocorra uma falha no DBAccess primário, os serviços da segunda VM funcionariam como espelho,
mantendo o cenário disponível.
O License da VM espelho deve possuir licenças disponíveis.
Caso contrario o cliente deverá realizar o move das licenças no portal do cliente, migrando as licenças do license
primário, para o license modo cluster.
Para maiores informações, segue link: https://tdn.totvs.com/display/framework/TOTVS+License+Server+Virtual
20
Cenário Emergencial:
Considerando o informado pelo cliente em reunião, que criar uma quantidade elevada de VM’s pode ser um complicador,
e levando em conta a necessidade de urgência em melhorar o ambiente já para o fechamento de outubro, solicitei ao
cliente 03 VM’s adicionais ao cenário.
Dessa forma, a ideia é tentar reduzir ao máximo os custos, criando um cenário de baixo custo e possivelmente temporário,
passando ao cliente os prós e os contras dessa solução.
Considerando que nesse momento o cliente possui o ERP quase todo instalado em uma única VM com 72GB de RAM e
08vCPU’s, e levando em conta que durante a nossa reunião, o servidor teve um único pico de quase 80% (rapidamente
resolvido), trabalhando na maior parte do tempo entre 30% e 40% de consumo de vCPU’s, com média de 200 conexões em
real time, podemos considerar o seguinte cenário:
(VM Atual, com redução de memória)

01 VM Principal – 08 vCPU’s e 24 GB de RAM: com APP Balance Monitor ERP, APP TOTVS Monitor Electron, APP Compilação,
APP Vip, APP Broker Client ERP e DBAccess Secundário + APP JOB Primário Schedule, 02 APP JOB Schedule + 01 APP License
Virtual, 01 DBAccess Primário ;
(SSD/Flash). O Volume E:/Protheus é necessário que seja high performance.
(03 VM’s novas criadas para sustentar o backoffice)

03 VM’s Secundárias – 08 vCPU’s e 40 GB de RAM: com 03 APP Protheus Secundários (03 em cada VM) e 01 DBAccess
Secundário em cada VM;
(SSD/Flash).
(VM já existente no ambiente do cliente, que criou para colocar apenas o TSS)
01 VM TSS / TAF – 04 vCPU’s e 08 GB de RAM: com 01 APP Broker WS TAF e 02 APP TSS 3.0 TAF ESOCIAL + DBAccess do TSS.
(SSD/Flash).
Com esse cenário, teremos uma distribuição dos consumos de backoffice em 03 VM’s dedicadas.
Esse cenário suporta pouco mais de 400 conexões simultâneas de backoffice, e possivelmente no fechamento haverá um
consumo maior. Se durante o fechamento a VM estiver trabalhando acima de 60% de consumo de vCPU’s, o ideal seria
adicionar mais VM’s de backoffice, já que as VM’s já possuem 08vCPU’s.
Se estiver abaixo de 60%, e estiver precisando adicionar mais memória devido o acumulo de conexões, pode ser adicionado
mais memória.
Considerando esse ser um ambiente virtual em cloud, é possível também considerarem um cenário de VM’s temporárias,
adicionando VM’s no ambiente que funcionem apenas no período de fechamento, podendo após o período essas VM’s
serem desligadas, sem gerar custo a Maqcampo.
Isso pode ser considerando também para os fins de semana, podendo manter uma única vm secundária de backoffice ativa.
Para mais informações consultem o link: https://tdn.totvs.com/pages/viewpage.action?pageId=521638009
O cenário emergencial mínima problemas de segurança, já que o TSS se encontra em uma VM dedicada.
O serviço de license, precisa seguir a orientação de segurança conforme detalhado no link de license (pagina 21).
Esse cenário emergencial acaba colocando o DBAccess Primário e o License, junto ao servidor principal. Esse não é o melhor
cenário, mas considerando o cenário atual, é o melhor indicado considerando o acréscimo de apenas 03 VM’s.
Caso seja observado que no período de fechamento, o total de conexões solicitado pelo cliente em sizing tenha sido maior
do que o acompanhado, recomendo que se for possível adicionar mais uma VM, que seja para migrar o DBAccess Primário e
o license, criando uma VM dedicada para eles.
Isso gera maior fluidez ao ambiente, já que o DBAccess é o gateway de conexão com o banco de dados.
21
11.2 Volumetria VM’s
Segue abaixo a volumetria do cenário para o ERP Protheus 12.1.27:
Nunca configurar um maquina virtual com uma quantidade de vCPU superior ao número de CORES reais do Host de
virtualização.
Sempre optar por máquinas menores, facilitando o DRS (Distributed Resources Scheduler), favorecendo a distribuição dos
recursos na Farm de virtualização.
Se atentar a divisão de VM’s entre os servidores (Distribuição de VM’s na FARM). 

A cada 4 a 6vCPU, considerar 1 core físico, onde 4 é o melhor cenário e 6 cenário limite, exigindo monitoramento.
Se atentar para que as VM’s nos servidores sejam distribuídas de forma que a quantidade de cores fisicos e memoria RAM,
atenda a quantidade de VM’s (vCPU’s e RAM).
Caso ocorra uma falha em um dos servidores, se atentar para que a soma das Vm’s de um servidor não ultrapasse a
quantidade de cores física recomendada (caso a FARM possua outras VM’s, além das VM’s TOTVS).
22
11.3 Sugestão de Host Fisico para Aplicação VmWare

Ambiente será hospedado em cloud privado.
Por esse motivo, não há necessidade de especificação de host físico para hospedagem das VM’s.
Segue abaixo a volumetria necessária em storage para atender a aplicação:
Storage:
2 Controladoras com 2 canais de até 12 GB cada
HDs SAS 15k e SSD/Flash (Indicamos tier de duas camadas com uso de SSD/Flash)
Tier1
SSD/Flash - ERP Primário e Banco de dados - 200 GB;
Tier 2
SAS 15K - Volumes ERP e Banco de dados - 970 GB.
(No volume informado para o storage, está sendo contemplado os volumes de Sistema Operacional das VM’s).
Farm Aplicação VmWare - ERP

Volume líquido 200 GB ERP Primário – RAID 10 (SSD/Flash)
Volume líquido Produção 970 GB VM’s e GTW Farm – RAID 05
(600 GB para SO / 370 GB para Aplicação)
23
11.4 Softwares
Aplicação VmWare – Protheus:

Windows Server 2019 Standard / DataCenter 64 Bits (Pode ser o Windows Server 2016);
Considerar as cal’s de acesso para todas as conexões simultâneas;
Considerar o ODBC Driver up-to-date para SQL Server em todas as VM’s (Para a conexão do DbAccess com o
Banco de dados);
Para obter o driver mais atualizado, segue link:
https://docs.microsoft.com/pt-br/sql/connect/odbc/download-odbc-driver-for-sql-server?view=sql-server-ver15;
O instalador do License Server precisa de um ambiente de execução Java (JRE) para funcionar
adequadamente. As versões atualmente suportadas são a 7 e a 8. Caso você não possua o JRE
instalado, faça o download em https://www.java.com/pt_BR/download/manual.jsp
Cenário Recomendado: Sugestão de Servidores Fisicos para o Host de Aplicação:

Windows Server 2019 Standard / DataCenter 64 Bits (Pode ser o Windows Server 2016) para cada servidor.
o Para o FARM, uso do Windows é opcional.
11.5 Considerações
Considerando o cenário da Maqcampo em Cloud privado, o host físico deve ser especificado pela cloud para atender as VM’s
de aplicação, conforme tabela de volumetria especificada na pagina 23.
Caso as VM’s estejam em um único HOST físico, para cenário mínimo, importante considerar pelo menos dois processadores
Deca-core, totalizando 20 cores no host físico (Sem considerar o HT – Hyper Threading).
Para o cenário recomendado, o ideal é que o host fisico possua dois processadores de 12 cores cada.
Lembrando que o cenário possui 72 vCPU’s e 232 GB de memória RAM, sem considerar a VM SPOFless (08vCPU’s + 12GB de
RAM).
Para o cenário recomendo que considerem entre 04 e 06 vCPU’s por core físico. É claro que o consumo depende diretamente
do uso do ERP pelos usuários, e por isso o ambiente deve ser monitorado, de forma a evitar saturações de cores, falta de
memória RAM e fila em disco, gerando latência na operação.
24
12. Banco de Dados

12.1 Hardware Fisico
Banco de Dados SQL Server
Cluster de Failover AlwaysOn SQL

Instância de Cluster de Failover AlwaysOn
Windows Server 2019 Std./Dc. x64
SQL Server 2017 Standard Edition x64:
02 Servidores Físicos;
02 Processadores Dodeca-Core Xeon (12 cores por processador);
128 GB de memória RAM;
02 Volumes SSD – 256 GB – RAID 1;
Placa Controladora com Cache de Bateria;
02 Placas Ethernet dual-port 10GB;
2 Placas HBA de 12 GB;
Placa Fontes e Ventiladores Redundantes.
25
Storage:
2 Controladoras com 2 canais de 12 GB cada
HDs SAS 15k e SSD/Flash (Indicamos tier de duas camadas com uso de SSD/Flash)
Tier1
SSD/Flash - ERP Primário e Banco de dados - 700 GB;
Tier 2
SAS 15K - Volumes ERP e Banco de dados - 606 GB;
(No volume informado para o storage, não está sendo contemplado os volumes de Sistema Operacional, já que estão
presentes no disco local, em RAID 1).
Partições / Volumes de Bases de Dados

DATA - 125 GB
INDEX - 75 GB
LOG - 100 GB
BKP - 500 GB
AUD - 300 GB
TMP - 100 GB
System SQL - 100 GB
DTC - 5 GB
Quorum - 1 GB
Volumetria SQL
Vol. líquido de 100 GB para Binário SQL (System) – RAID 05 (SAS 15K)
Vol. Liquido de 100 GB para TEMPDB – RAID 10 (SSD / Flash)
Vol. Liquido de 01 GB para o Cluster Quorum – RAID 05 (SAS 15K)
Vol. Liquido de 05 GB para DTC (Opcional) – RAID 05 (SAS 15K)
Vol. Líquido de 500 GB para Backup – RAID 05 (SAS 15K)
Volumetria Bases de Dados ERP
BD ERP (200 GB)

Vol. líquido de 75 GB DataFiles de Dados (ERP) - RAID 10 (SSD / Flash)
Vol. líquido de 75 GB DataFiles de Índices (ERP) - RAID 10 (SSD / Flash)
Vol. líquido de 50 GB DataFile de Log (ERP) - RAID 10 (SSD / Flash)
BD TSS (100 GB)

Vol. líquido de 50 GB DataFiles de Dados + Índices (TSS TAF) - RAID 10 (SSD / Flash)
Vol. líquido de 50 GB DataFiles de Log (TSS TAF) - RAID 10 (SSD / Flash)
Auditoria do BD ERP (300 GB)

Vol. líquido de 300 GB para Auditoria (Opcional) - RAID 10 (SSD / Flash)
26
12.2 Considerações
Para o servidor de banco de dados, foi considerado 02 processadores de 12 cores cada, considerando as 1700 Threads de
aplicação, sendo 850 conexões simultâneas no ERP e 850 threads de dicionário de dados.
Esse cenário é o servidor recomendado.

Caso queira um cenário mínimo, é possível atender o ambiente com dois processadores deca-core (10 cores cada).
Para memória RAM, considerando o total de conexões simultâneas e volumetria, é possível atender com 128GB de memória
RAM.
Se atente que a edição standard do SQL é limitada em 128GB de RAM, e no futuro, com aumento de conexões e volumetria,
não é possível aumentar a quantidade de RAM nesta edição.
Não recomendo que atuem com menos de 128GB de RAM, principalmente considerando que durante o fechamento, o
cenário possui o total de aproximadamente 800 conexões simultâneas.
Limitações de edições do SQL 2017:
Limitações de edições do SQL 2019:
27
12.3 Softwares
Servidores Fisicos de Banco de Dados – SQL 2019:
Windows Server 2019 Standard / DataCenter 64 Bits (Pode ser o Windows Server 2016) para cada servidor.
SQL Server 2017 Standard Edition 64 Bits;
o SQL Compression (opcional);
o Instancia de Failover AlwaysOn.
13. Observações do Cenário Recomendado
Licença:
Considerar licenças de aplicação para o total de conexões simultâneas no ambiente de produção.
Considerar licenças para o DBAccess de Produção.
Para o cenário virtualizado, caso faça uso de licença por core, considerar o licenciamento para DBAccess Distribuído.
Atenção: Até o momento da geração desse sizing, a TOTVS faz uso de licença do DBAccess distribuído, considerando
cada servidor em que o DBAccess está instalado.
Caso faça uso de licença por core e não por user, entrar em contato com seu ESN para verificar se o ambiente esta apto.
https://tdn.engpro.totvs.com.br/pages/viewpage.action?pageId=552591356
License Server Virtual:

Recomendamos o uso do Software Key (TOTVS License Server Virtual) onde não é necessário o uso do Hardlock físico. 
O uso do license server Virtual é obrigatório. 
OBS: O controle de numeração deve ser feito pelo License Server.
http://tdn.totvs.com/display/framework/TOTVS+License+Server+Virtual
http://tdn.totvs.com/pages/releaseview.action?pageId=309411140
DbAccess:
Para cenários acima de 500 conexões simultâneas, deve ser aumentado a quantidade de Threads disponíveis no
dbaccess, sendo necessário alterar seguindo as recomendações publicada no TDN:
http://tdn.totvs.com/pages/viewpage.action?pageId=6064535
A parametrização pode variar conforme o cenário do cliente, e seus valores devem ser avaliados.
Para o cenário foi considerado um balanceamento das conexões no DbAccess, fazendo uso do DbAccess Distribuído.
Segue abaixo link do TDN para referência:
http://tdn.totvs.com/pages/viewpage.action?pageId=6064504
DbAccess SPOFless :
Quando o TOTVS | DBAccess está configurado para trabalhar no modo distribuído, o DBAccess (Primário) se
torna um SPOF, e em uma possível falha do mesmo (por questões de infraestrutura ou software), todos os
usuários conectados ao DBAccess podem ser afetados, de modo que os mesmos teriam que entrar novamente
no ERP.
Para mitigar esse cenário, foi projetado e implementado o DBAccess SPOFless, que de uma maneira resumida é
o espelhamento do DBAccess (Primário), criando um modelo tolerante a falhas e mais resiliente, de modo que,
em caso de falha do DBAccess (Primário) o espelhamento/réplica assume o papel de Primário do ambiente
distribuído.
Caso o cliente queira fazer uso do DBAccess SPOFless, recomendo que seja adicionado ao cenário mais uma
VM, com a mesma configuração da VM “DBAccess + License” (Já considerado no cenário).
Nessa VM também pode ser configurado um license server, funcionando como um cenário de alta
disponibilidade para o License Server Virtual:
https://tdn.totvs.com/display/tec/DBAccess+Master+SPOFLess
28
TEAM das Placas de Rede:

Para a montagem do ambiente, é recomendado que seja realizado o TEAM das placas de rede.
Volume Primário da Aplicação:
Foi especificado um volume de 200 GB para a aplicação, considerando os dicionários no banco de dados.
Não foi informado se fazem uso de grupo de empresa.
É recomendado pela TOTVS que o cliente utilize Grupo de Empresas, caso possua vários CNPJ’s. Se não
utiliza, solicite a um consultor TOTVS para verificar se é possível implementa-lo.
SmartClient via WEB:

A partir da build 131227A o Application Server responde nativamente como um servidor Web, fornecendo
segurança e escalabilidade ao ambiente Cloud do ERP TOTVS. Dessa forma, é possível utilizar qualquer
ferramenta de mercado de load balance, ou o broker, conforme documentação no TDN:
Broker:
https://tdn.totvs.com/display/tec/Balanceamento+de+carga+com+broker
SmartClient HTML – WebApp:

https://tdn.totvs.com/display/tec/WebApp+-
+Configurando+nativamente+o+Application+Server+como+servidor+Web
Sistema Operacional de Aplicação:

Todas as VM’s do ERP Protheus montados com sistema operacional Windows Server 2019 Standard ou
DataCenter 64 Bits.
Windows Server 2016 também está homologado, e pode ser considerado.
O volume de 60 GB para sistema operacional das VM’s é uma sugestão. Caso o cliente queira utilizar uma
outra quantidade de volume dedicada, favor respeitar a quantidade recomendada pelo fabricante para uma
boa performance.
Audit Trail (Opcional):

Para o Audit Trail, favor considerar um volume liquido dedicado ao audit Trail:
“Volume líquido 300 GB Audit Trail – RAID 10 (SSD/Flash)”.
O Volume deve ser alocado para o Datafile no banco de dados de produção (ERP).
Segue link do TDN com a nova indicação de utilizar Embedded Audit Trail:
http://tdn.totvs.com/display/public/PROT/Configurar+Embedded+Audit+Trail
http://tdn.totvs.com/display/public/framework/Embedded+Audit+Trail+-+aplicador
http://tdn.totvs.com/display/framework/Embedded+Audit+Trail+-+Configurador+de+tablespaces
Observação: O volume informado é uma indicação para o cliente. O consumo do volume depende diretamente
da quantidade de campos auditados, e da movimentação de dados nesses campos.
Ao se aproximar do volume total, deve ser realizado um backup e excluído os dados do banco.
O tempo para essa atividade deve ser avaliado pelo cliente, e caso necessário pode ser adicionado mais
volume (ou diminuído), para atender o tempo de necessidade para manutenção, conforme o cliente desejar.
Volume das Bases de dados:

As bases de dados podem ser iniciadas com um volume menor e crescer conforme a demanda.
Compressão da Base de dados ERP (Advanced Compression):

Apenas como informativo, quando o volume da base de dados se aproximar de 1TB, recomendo que seja
realizado a compressão dos dados e índices do banco ERP.
29
Versão MSSQL Server:

A versão apresentada no cenário é a SQL Server 2017, conforme solicitado pelo cliente.
A aplicação também é homologada para uso com o SQL Server 2019, no qual indico o seu uso.
Sistema Operacional SQL:

O Sistema operacional do servidor com o banco de dados SQL, deve ser definido com a Microsoft
(Plataformas Homologadas). O sistema apresentado é uma sugestão.
IOP’s/Latência:
O cliente faz uso do ERP, e não foi informado nenhum problema relacionados ao consumo de IOPS.
Recomendo que acompanhem o consumo durante o uso do ERP, principalmente durante o período de
fechamento.
O volume da VM Principal de aplicação e as base de dados, são os maiores consumidores de IOPS, e por isso
precisam de uma boa performance para leitura e escrita, além de prover menor latência.
É recomendado que esses volumes sejam colocados em uma LUN SSD/Flash (Disk High Performance).
SQL Enterprise
O uso da edição Enterprise é uma opção para o cliente.
Lembrando que a versão Standard está limitada em 128 GB de memória RAM.
Uso de BI
Caso o cliente faça uso de BI, com grande consumo em horário comercial na base de dados de produção, e caso
o BI não esteja utilizando o ambiente AlwaysOn Availability Group, recomendamos que avaliem o consumo de
hardware pelo banco de dados.
Frequência de Processadores:
Para os servidores fisicos, recomendo uma frequência igual ou se possível superior a 2.3 GHz, com “Turbo
Boost” acima de 3.0 GHz
Para o Farm VmWare, essa recomendação é de extrema importância, e deve ser seguida.
Zona Segura de Processamento:

A "zona segura de processamento" refere-se à quantidade que pode ser consumida sem atingir o limite de
saturação. Neste cenário, a zona segura é considerada ao respeitar a quantidade de recursos estipulada, ou
utilizando até 60% de CPU.
30
14. Ambiente DEV e QA
14.1 Aplicação - PL
O ambiente de DEV e QA (Desenvolvimento e Homologação) possui um número menor de conexões
simultâneas, se comparado com a produção.
Para DEV e QA em plataforma virtualizada, consideramos máxima de 100 conexões (Threads) simultâneas em
cada ambiente.
O objetivo do ambiente QA é testar funcionalidades. Para teste de performance, simulando o total de conexões
em produção, é necessário um ambiente réplica de produção.
Segue abaixo o cenário recomendado para o ambiente de DEV e QA.
31
14.2 Servidor Fisico

Segue abaixo o servidor recomendado para o banco de dados de DEV e QA:
Obs 1: Os discos de DEV e QA não precisam ser em SSD / Flash, podendo estar em SAS 15K.
Caso seja do interesse avaliar a performance de rotinas, o ideal é que seja utilizado SSD nos volumes de banco
de dados, conforme a produção.
Lembre-se que o tempo de migrações de releases, serão calculados nesse ambiente.
Obs 2: O volume de 600 GB para bases de dados, é um volume total considerando todas as bases somadas (DEV
e QA)
As bases podem ser iniciadas com um volume menor, e crescer conforme a demanda.
O mesmo vale para o volume de Backup.
Obs 3: O cenário de DEV e QA é uma sugestão. Caso o cliente queira seguir de forma diferente ao recomendado
no ambiente de DEV e QA, a TOTVS não se opõem.
Lembrando apenas que a infra de DEV e QA afeta os testes considerando avaliações de performance, e qualquer
tipo de avaliação de tempo, como o de migração de release.
32
14.3 Softwares
Servidor de Aplicação:
Windows Server 2019 Std./Dtc. 64 Bits;
Considerar as cal’s de acesso para as conexões de DEV e QA.
Considerar o ODBC Driver up-to-date para SQL Server em todas as VM’s (Para a conexão do DBAccess com o
Banco de dados);
Para obter o driver mais atualizado, segue link:
https://docs.microsoft.com/pt-br/sql/connect/odbc/download-odbc-driver-for-sql-server?view=sql-server-ver15;
o Considerar o mesmo client que o ambiente de produção.
O instalador do License Server precisa de um ambiente de execução Java (JRE) para funcionar
adequadamente. As versões atualmente suportadas são a 7 e a 8. Caso você não possua o JRE instalado,
faça o download em https://www.java.com/pt_BR/download/manual.jsp
Servidor de Banco de Dados:
Windows Server 2019 Standard 64 Bits;

SQL Server 2017 Std./Ent. Edition 64 Bits;
o Se possível, considerar a mesma Edição utilizada para produção.
14.4 Observações
• Licença:
Considerar licenças de aplicação para o total de conexões simultâneas no ambiente de DEV e QA.
Considerar licenças para o DBAccess de DEV e QA.
• License Server Virtual:

Recomendamos o uso do Software Key (TOTVS License Server Virtual) onde não é necessário o uso do Hardlock
físico. Para cenários com alta disponibilidade, o uso do License server Virtual é obrigatório. 
OBS: O controle de numeração deve ser feito pelo License Server.
http://tdn.totvs.com/display/framework/TOTVS+License+Server+Virtual
http://tdn.totvs.com/pages/releaseview.action?pageId=309411140
• Quantidade de conexões simultâneas:

O servidor dimensionado possui a capacidade de processamento e memória para testes, desenvolvimento e
homologação de rotinas.
Também é possível realizar a analise de performance de rotinas se optado pelo uso de SSD nos discos de banco
de dados.
Não é possível realizar um teste de stress, simulando todas as conexões simultâneas conforme a produção.
No momento do teste, deve ser inicializado os serviços relacionados, e executado o teste.
Não recomendo que todos os serviços estejam ativos.
• Sistema Operacional SQL:

O Sistema operacional do servidor com o banco de dados SQL deve ser definido com a Microsoft (Plataformas
Homologadas). O Sistema apresentado é uma sugestão.
• Audit Trail:
O volume considerado para base de dados de auditoria do ambiente de produção, deve ser o mesmo para o
ambiente de QA, de forma a poder subir a base de dados em caso de necessidade.
• Volume das bases de dados:

As bases de dados podem ser iniciadas com um volume menor e crescer conforme a demanda.
33
15. Requisitos de Software e Parâmetros do Sistema
15.1 Balanceamento Utilizando Broker

A versão 12 do Protheus inclui funcionalidades nativa de proxy reverso.
Existem 4 casos de uso mais comuns em que esta funcionalidade pode ser utilizada:
1.Balanceamento de conexões entre Smart Client desktop e servidor Protheus;

2.Balanceamento de conexões entre Clientes HTML e servidor Protheus;
3.Balanceamento de conexões entre clientes Telnet e servidor Protheus;
4.Balanceamento de conexões entre clientes de Web Services e servidor Protheus;
Com destaque para “Balance de SmartClient”:
Permite que se possa fazer o Balanceamento de carga entre os serviços de SmartClient, distribuindo a carga baseado no
numero de conexões que cada servidor está atendendo, e possibilita a reconexão em caso de falha de comunicação,
reestabelecendo a conexão automaticamente e de forma transparente para o usuário.
Para mais informações: https://tdn.totvs.com/display/tec/Balanceamento+de+carga+com+broker
16. Informações Adicionais
Lembramos que a infraestrutura pode variar de acordo com o crescimento do número

de usuários e/ou Base de Dados.
Lembramos ainda que, caso não alterem o numero de conexões e/ou módulos do
sistema, a infraestrutura informada no relatório é valida por no máximo 3 anos. Após
esse tempo a mesma deve ser revista e ajustada caso necessário.
O fator de performance dos ambientes está relacionado a quantidade de conexões

simultâneas, módulos contemplados, a distribuição de suas conexões e threads, além da
quantidade de registros integrados diariamente. Desta forma o consumo deve ser
monitorado, assim como a quantidade de conexões ao longo de sua utilização.
Crescimento da base de dados pode variar de acordo com a utilização do sistema, e com
o tempo pode ser necessário adicionar mais volume ao Storage.
Por isso, o volume deve ser monitorado.
Caso o cliente armazene documentos no storage, DirDoc do sistema, base histórica, etc,
devera ser criado um volume liquido dedicado.
Os volumes dos cenários de ERP contemplam o tamanho exato para atender a aplicação.
Caso faça uso de mais volume, adiciona-lo ao cenário.
Sobre a quantidade de nota para emissão, é importante o balanceamento do mesmo.
Caso haja uma base de dados dedicada a customizações, essa base deve ser
dimensionada pelo cliente/Projeto TOTVS.
Disclaimer: “Sizing sujeito a revisão caso configurações/especificações sejam alteradas”.
34
17. Pontos de Atenção VmWare

Seguem as considerações para ambientes utilizando VmWare:
• Para o dimensionamento do ambiente considerar 4 a 6 vCPU’s por core físico no cenário de produção;
• Versão 5.0 ou superior (preferencialmente versão 6.0 up to date);
• Configuração de disco para o Dicionário de dados: Thick Provision Eager Zerod;
• Placa de rede preferencial: VMXNET 3;
• Para uma gestão de core “Processadores Virtuais “é recomendado ter a Feature Vcops (dependendo da
versão vRealize), pois a mesma irá dimensionar o processamento em caso de aumento de dados ou
também ajudará a diminuir recursos quando o mesmo não tiver utilizando;
• Para configuração das VM’s conforme o Sizing, é importante que sigam as boas práticas VmWare
conforme tabela abaixo:
Conforme a tabela, respeite o numero de sockets presente no host da FARM.
Segue guia de boas praticas para o Hypervisor:

https://tdn.totvs.com/display/public/PROT/Ambientes+Virtualizados
https://tdn.totvs.com/display/public/PROT/Hyper-V+-+Ajustes+recomendados
https://tdn.totvs.com/display/public/PROT/VMWare+-+Ajustes+recomendados
35
18. Advertências Vm’s

Nunca configurar um maquina virtual com uma quantidade de vCPU superior ao número de CORES reais do Host de
virtualização.
Sempre optar por máquinas menores, facilitando o DRS (Distributed Resources Scheduler) favorecendo a distribuição dos
recursos na Farm de virtualização.
Se atentar a divisão de VM’s entre os servidores (Distribuição de VM’s na FARM). 

A cada 4 a 6vCPU, considerar 1 core físico, onde 4 é o melhor cenário e 6 cenário limite, exigindo monitoramento.
Se atentar para que as VM’s nos servidores sejam distribuídas de forma que a quantidade de cores fisicos e memoria RAM,
atenda a quantidade de VM’s (vCPU’s e RAM).
Caso ocorra uma falha em um dos servidores, se atentar para que a soma das Vm’s de um servidor não ultrapasse a
quantidade de cores física recomendada (caso a FARM possua outras VM’s, além das VM’s TOTVS).
Observar pré-requisitos do ambiente Multi Site Cluster:

https://docs.microsoft.com/en-us/windows-server/failover-clustering/clustering-requirements
Todos os Templates da Máquina Virtual são recomendados utilizar Sysprep. Caso não utilize, a máquina virtual pode
apresentar diversos problemas na sincronização, além de perda da relação de confiança com o Domínio da rede “Active
Directory”.
19. Considerações
Os itens abaixo devem ser considerados no momento da instalação:
Ø Firewall:
Após a montagem do ambiente, as portas utilizadas pela aplicação devem ser liberadas no firewall, principalmente
se possuem firewall interno.
Além das portas do ERP, favor considerar para o License:
36
Ø Antivírus:
O cliente pode utilizar qualquer antivírus de mercado.

Recomendo que deve ser considerado uma exceção no antivírus a pasta System do ERP, devido a geração de alguns
arquivos temporários da aplicação.
Lembrando que o dicionário de dados da aplicação, estará localizado no banco de dados.
Ø Segue abaixo alguns itens que devem ser considerados para a criação do banco de dados:
https://tdn.totvs.com.br/display/public/PROT/MSSQL
https://tdn.totvs.com/display/tec/DBAccess+-+Sobre
https://tdn.totvs.com/display/tec/DBAccess+-+Collation%2C+Character+Type+e+Encoding
https://tdn.totvs.com/display/tec/DBAccess+-+Como+criar+uma+fonte+de+dados+para+uso+com+Microsoft+SQL+Server
37
20. Requisitos de Ambiente

Comunicação GIGABIT com canal de 10GBIT FULL DUPLEX entre todos os Servidores utilizando SWITCH, preferencialmente
Layer 3 gerenciáveis.
Vale lembrar que tanto os servidores, quanto os Switchs devem ter suporte para a placa de rede de 10 GBIT.
Utilização de LAG para construção balanceamento/redundância no canal de rede.
Para cada conexão Protheus considerar consumo médio de 15k de banda e latência máxima do link de 120ms.
Para desempenho, recomendamos latência máxima de 100ms.
Lembrando que quanto menor a latência (mais próximo de 0ms), melhor a performance.
Para a conectividade do ambiente de FC (Fiber Channel) indicamos a utilização de dois switches para balanceamento e
redundância, com a quantidade de portas necessárias para atender a solução.
Recomendo possuir mais de um link para contingência.

Para a montagem do Cluster ou/e Farm, é recomendado que seja realizado o Team da placas de Rede.
Para o backup dos binários e repositórios da aplicação Protheus, pode ser utilizado softwares de mercado e o snapshot das
VM’s do Hypervisor.
O cenário da MAQCAMPO contempla o dicionário no banco de dados.

O backup dos dicionários de dados devem ser gerados pelos planos de manutenções do banco de dados.
21. Histórico de Revisões

Rev. Mês Ano Responsável Descrição da Alteração
00 Outubro 2021 Rafael dos Santos Sousa Emissão do Documento
38

SIZING Protheus MaqCampo

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SIZING Protheus MaqCampo

Enviado por

Direitos autorais:

Formatos disponíveis

Relatório de Dimensionamento

3. Ambiente Solicitado - Produção

Segue abaixo algumas informações uteis para conhecimento do cliente:

Alta Disponibilidade a nível de aplicação:

Banco de Dados em plataforma virtualizada:

Ø Possui alta disponibilidade (Cluster/AlwaysOn/Rac) no cenário atual?

Ø Favor responder o questionário de infra atual:

Segue abaixo os servidores presentes na Maqcampo:

- Servidor (banco de dados)

Ø Versão da aplicação atual? 12.1.027 – Out 2020

Ø Dicionário em disco com CtreeServer ou no banco de dados? Banco de dados.

Ø Qual a Build do:

o Binário: 7.00.191205P-20210114 – 64 bits

Ø Numero de usuários simultâneos na aplicação no momento de pico:

Ø Qual o sistema operacional da:

§ Aplicação: Windows Server 2019 Standard

Ø Versão do Banco de Dados (Oracle, SQL, DB2, etc.). Standard ou Enterprise?

NomeDoBanco DataFileSizeMB LogFileSizeMB

Ø A base de dados está comprimida? Não.

Ø Possui tabela ou índice particionado no banco de dados? Não.

Ø Utiliza Storage para armazenamento da base de dados? Se sim, responder:

Ø Rede entre os servidores é GB? Sim.

Ø Qual o modelo do switch utilizado pelos servidores de aplicação

§ Se possível, informe o Layer do switch: Não informado.

Ø Quais os módulos utilizados? Sem informação.

Ø Qual o pico de IOPS do servidor de banco de dados?

Exemplo: Servidor 1 – 1 Balance, 1 License, 1 CtreeServer e 7 slaves

Ø Deve ser considerado Site de Contingência (DR) /Backup? Não.

Ø Qual o Release da Aplicação que o Ambiente deve atender?

Ø Dimensionar aplicação para quantas conexões simultâneas?

Ø Considerar Audit Trail?

Ø Considerar ambiente de desenvolvimento e homologação (Dev/QA)?

Ø Gera notas fiscais eletrônicas? Se sim, responder:

Ø O Modulo Gestão Pessoal será utilizado? Se sim, responder:

Ø Será utilizado Portal? Se sim, responder:

Ø Será utilizado WebServices para integração do Protheus com outros sistemas?

Cenário atual possui dois serviços de JOB. Mantê-los.

Ø Deve ser considerado no Sizing (se houver) o ambiente Histórico?

Segue resumo do cenário Produção que o sizing deve atender:

PROTHEUS Banco de Dados

Banco de dados Audit Trail: 300 GB (Opcional);

O sizing está considerando 3 anos de uso.

4. Analise do cenário atual

Adicionando as threads de dicionário de dados, o ambiente deve atender 1700 threads.

Sendo esse um ambiente em Cloud, essa solução é possível.

Arquitetura com balanceamento de Carga e dicionário no banco de dados:

6. Sistema Operacional Homologado AppServer Protheus

Sistemas Operacionais Homologados:

7. Banco de Dados Homologados Protheus

Status EOL = End Of Life

9. Ambiente com Latência (Protheus)

10. Cenários do SIZING

Cenário Recomendado (12.1.27) –

Foi considerado os seguintes requisitos:

• Alta disponibilidade para servidores e banco de dados (servidores físicos);

Se fizer uso da instancia de Failover AlwaysOn para SQL:

Além de atender o RPO, o cenário também atenderá o RTO.

11. Sizing de Aplicação VmWare

Segue abaixo os serviços presentes em cada VM:

A VM Primária possui a estrutura da aplicação.

(VM Atual, com redução de memória)

(03 VM’s novas criadas para sustentar o backoffice)

11.2 Volumetria VM’s

Se atentar a divisão de VM’s entre os servidores (Distribuição de VM’s na FARM). 

Se atentar a divisão de VM’s entre os servidores (Distribuição de VM’s na FARM). 