Índice
Objetivo
O objetivo deste guia é ilustrar os exemplos de sizing para utilização no fluig.
Solicitação de sizing
No processo de solicitação de sizing, há um formulário com uma série de questões que devem ser respondidas sobre a utilização do fluig no cliente. As respostas devem ser aproximadas a experiência que o cliente terá sobre a utilização da plataforma.
Clientes fluig devem contatar os parceiros e canais fluig para solicitar o sizing para ambientes. Na sequência o canal irá tomar as seguintes ações de contato:
- Para fluig em execução na Nuvem TOTVS deve-se contatar o time de Projetos Cloud para que seu sizing seja homologado.
- Para fluig em execução em servidores próprios, deve-se contatar o time de Infra Services TOTVS, assim você terá todo o apoio através de reuniões de entendimento, visitas técnicas quando necessárias, modelos de sizing, dentre outros serviços.
Atenção: Caso o dimensionamento (sizing) não for elaborado pelos times mencionados acima, não será homologado pelo fluig, estando fora dos requisitos e escopo de atendimento do suporte fluig. |
Informações para elaborar dimensionamento
- Quantidade de usuários conectados simultaneamente
Por padrão de mercado, a quantidade de usuários conectados ao mesmo tempo é um valor entre 10% e 30% do total de usuários cadastrados em base.
Ou seja, se você tem 1000 usuários cadastrados você terá entre 100 e 300 usuários conectados simultaneamente. - Quantidade de documentos publicados na implantação
- Quantidade de documentos versionados mensalmente
- Tamanho médio dos arquivos publicados (em Kbytes)
Esta métrica está diretamente relacionada ao espaço em disco que será sugerido para o cliente. Sugerimos utilizar o repositório de documentos em um Storage com discos SAS de 15k em RAID-1. - Quantidade de processos workflow que será aberta mensalmente
Esta métrica está relacionada ao poder de processamento das máquinas onde estarão as instâncias de fluig. Quanto mais processos abertos mais máquinas serão necessárias.
Disponibilidade do ambiente
Acompanhe os cenários abaixo considerando a criticidade de disponibilidade do ambiente.
Quando um ambiente é de alta disponibilidade, estamos falando que este é um ambiente crítico e não pode ficar fora do ar. Para que a disponibilidade seja garantida todas as máquinas envolvidas em um ambiente de alta disponibilidade devem possuir redundância de pelo menos 1 máquina. Estas trabalharam de maneira conjunta dividindo o processamento. Caso uma máquina cair a máquina que ainda está no ar assumirá todo o processamento. Além de redundância esses ambientes devem ter plano de backup diário. Projetos que demandam este tipo de ambiente são os de maior custo para o cliente.
|
Quando um ambiente é de média disponibilidade, estamos falando de um ambiente no qual impacta a operação do cliente. Ou seja, se o ambiente ficar fora do ar no período de expediente do cliente esta queda causará impacto em sua operação.
Este ambiente é distribuído para minimizar os pontos de falha. Este modelo é o de menor custo para o cliente, entretanto é o mais vulnerável.
|
Quando um ambiente é de baixa disponibilidade estamos falando de um ambiente no qual não impacta diretamente na operação do cliente, ou seja, se o ambiente ficar fora durante alguns minutos no horário de expediente do cliente esta queda não impactará em sua operação. Este modelo é o de menor custo para o cliente, entretanto é o mais vulnerável.
|
|
Servidor de aplicação
Acompanhe o detalhamento de cálculo dos requisitos do cliente.
Cálculo do disco para o Storage de repositório
Para calcular a quantidade média de disco que o cliente utilizará vamos utilizar três campos do formulário de sizing do fluig que são:
- Qual é a quantidade de documentos publicados na implantação?
- Qual é a quantidade média de documentos que serão publicados/versionados por mês?
- Indique o tamanho médio dos documentos que serão publicados. (O valor deve estar em Kbytes.)
Vamos utilizar alguns valores de exemplo para os campos citados acima.
Qual é a quantidade de documentos publicados na implantação? | 15.000 |
Qual é a quantidade média de documentos que serão publicados/versionados por mês? | 500 |
Indique o tamanho médio dos documentos que serão publicados. (O valor deve estar em Kbytes.) | 4096 |
Valor de referência:
1 MB em KB = 1024
1 GB em MB = 1024
Após termos o valor em MB de cada documentos faremos o cálculo dos documentos que serão publicados no momento da implantação. 4 MB x 15.000 = 60.000 MB/1024 = 58,6 GB
|
Agora já sabemos que no momento da implantação do fluig será consumido aproximadamente 60 GB do repositório de documentos do fluig. Vamos calcular então, os documentos versionados por mês. 4 MB x 500 = 2.000 MB = 1,95 GB
|
Para finalizar o cálculo de disco, basta multiplicar para vermos o total utilizado no ano e depois nos 3 próximos anos. 1,95 GB x 12 meses = 23,4 GB 23,4 GB x 3 anos = 70,3 GB
|
TOTAL de disco sugerido para o cliente é 70 GB + 60 GB + 20 GB de arredondamento* = 150 GB. *Como o tamanho dos documentos pode variar em relação ao valor informado pelo cliente, nós podemos arredondar para 150 GB, pois este é um valor ínfimo que não afeta os custos do projeto.
|
|
Cálculo dos usuários conectados simultaneamente
O fluig suporta hoje 150 usuários conectados simultaneamente por instância do JBoss. A cada 150 usuários adicione outra máquina para o servidor de aplicação.
Estas máquinas devem, obrigatoriamente, trabalhar com Load balancer. |
Cálculo de abertura de solicitações workflow
Existem dois fatores que influenciam diretamente no cálculo de solicitações por servidor de aplicação.
Quando um processo workflow desenhado dentro do fluig não possuir nenhum tipo de integração com outro sistema externo podemos levar em consideração a abertura de 10 solicitações por minuto.
Quando um processo workflow desenhado dentro do fluig possuir algum tipo de integração com outro sistema externo (como, Protheus, RM, Datasul etc) podemos levar em consideração a abertura de 5 solicitações por minuto, isto por que deve-se considerar o tempo de resposta dos servidores de integração. Vários fatores podem interferir no tempo de resposta, como por exemplo: se o método invocado é de alta complexidade, latência de rede entre o fluig e o servidor de integração, parametrizações do sistema no qual o fluig está se integrando, dentre outros.