Pessoal, publico este artigo afim de discutir com vocês quais os melhores caminhos para se gerar um documento de Sizing o mais correto possível. Espero que o conteúdo abaixo agregue conhecimento a vocês e que, a partir deste, muitas dicas sejam feitas afim de que eu possa entender e aprender como vocês trabalham para criar o Sizing para seus clientes!
Desta forma acredito que teremos um resultado final útil a todos nós!
Creio que o primeiro passo para criarmos um sizing conciso, que faça sentido frente ao cliente e que o faça se sentir seguro do investimento a ser feito, nós precisamos conhecer a arquitetura do Dynamics AX. Não conhecer estes pontos prejudicará o resultado final do sizing.
Sugiro então a leitura dos links abaixo:
http://go.microsoft.com/fwlink/?LinkId=286895
http://go.microsoft.com/fwlink/?LinkId=286896
Após a leitura acima, podemos dizer que o AX2012 trabalha com uma arquitetura de 03 camadas (Three-Tier Architecture). Esta arquitetura separa os componentes de Banco de Dados, Aplicação e Client, que são os 03 componentes básicos para a instalação do Dynamics AX.
O SQL Server fica na camada de banco de dados e armazena os dados da aplicação em tabelas.
A aplicação (AOS) fica na camada de mesmo nome, e é responsável por executar as logicas contidas nos objetos da aplicação, tais como métodos de tabelas e classes.
A ultima camada é o Client, responsável por exibir os objetos da aplicação tais como formulários e relatórios.
Outros componentes como Workflow, BI, Enterprise Portal, AIF e Help Server precisam ser avaliados e levados em consideração.
Tendo o conhecimento da arquitetura do Dynamics AX e de seus componentes, o responsável pela criação do sizing deverá questionar o cliente até entender por completo suas necessidades e caracteristicas para somente após poder criar este documento de sizing.
Algumas perguntas que devem ser feitas:
Qual o volume máximo de transações esperados por hora durante o horário maior utilização do AX?
Toda a arquitetura de sizing do Dynamics AX deve ser desenhada para suportar o maior numero possível de transações por hora no dia de maior movimento da empresa.
Todas as transações abaixo, mas não somente elas, devem ser consideradas:
- Linhas Ordens de Venda
- Linhas de Ordem de Compra
- Linhas de Ordens de Produção
Qual é quantidade de registros no arquivo de dados?
Este dado é de extrema importância, obtendo esta informação poderemos estimar o tamanho inicial do banco de dados do Dynamics AX, e com isso dimensionar corretamento o disco correto para o servidor de banco de dados.
Quais módulos serão utilizados no Dynamics AX?
Obter esta informação nos permite determinar a quantidade ideal de servidores, tendo em vista que cada modulo aumenta a quantidade de transações no AX.
Haverá integração do AX com sistemas terceiros?
Entender as necessidades de integração do AX com programas terceiros é importante na construção do sizing. Algumas perguntas podem ajudar a determinar os requisitos de hardware para uma correta integração com o Dynamics AX:
- Qual sistema será integrado ao Microsoft Dynamics AX?
- Qual o método de transporte a ser utilizado?
- O método de transporte ajudará a definir quantos servidores serão necessários para a integração. Por exemplo, a utilização do sistema de arquivos para um sistema externo talvez exija a utilização de um servidor de FTP. Ou a utilização do AIF vai exigir a utilização de um servidor de IIS.
- O método de comunicação deverá ser Síncrono ou Assíncrono?
- Se documentos precisam ser enviados ou recebidos em uma determinada ordem a comunicação síncrona será exigida para que um documento não seja enviado até que o primeiro não seja recebido por completo.
Customizações, desenvolvimentos, serão necessários?
Determinar se customizações serão necessárias ajudará a definir como elas serão implementadas. Vejam este
link para entender do que estou falando!
Quantos usuários utilizarão o Microsoft Dynamics AX?
Saber quantos usuários utilizarão o sistema e como eles o acessarão nos ajudará a definir a quantidade correta de servidores de AOS. Também é importante saber se o Enterprise Portal será utilizado e quantas integrações existirão.
O Dynamics AX será acessado de fora da empresa?
Não é recomendado utilizar o Dynamics AX sem a utilização de programas específicos para publicação de aplicações tais como o
Remote Desktop Services. Em caso de necessidade de acesso externo, mais servidores serão necessários, e caso existe a necessidade de alta disponibilidade do acesso a este recurso, a quantidade necessária de servidores aumenta.
Obs: Se a latência na rede for maior do que 50ms o uso do Remote Desktop services é aconselhavel.
O Enterprise Portal será utilizado? De que forma?
O Enterprise Portal é utilizado para a exibição do Role Center para o Dynamics AX Client e pode ser utilizado para o acesso a recursos via navegador, Internet Explorer. Analisar a utilização do Enterprise Portal e a necessidade ou não de alta disponibilidade deste recursos é importante.
Haverão muitos trabalhos em lotes?
Dependendo da quantidade de trabalhos em lotes, servidores dedicados serão necessários. também precisamos avaliar qual a disponibilidade requerida para os servidores de lotes do AX. Pode ser necessário a criação de um cluster de AOS para os trabalhos em lotes.
A empresa precisa de um cluster de AOS dedicado?
O Microsoft Dynamics AX permite a criação de cluster de AOS para o balanceamento de carga e alta disponibilidade deste serviço. Para mais informações sobre servidores de Load Balance para AOs consultem este
link.
Quantos ambientes serão utilizados na implementação do AX?
Em uma implementação padrão é comum utilizarmos 03 ambientes, Desenvolvimento, Homologação e Produção. Contudo, outros ambientes podem ser uteis e ajudam a evitar problemas. Ambientes como os descritos abaixo podem ser disponibilizados para a implementação caso aprovado pelo cliente.
Treinamento - Ambiente dedicado a treinamento dos usuários. Este é um ambiente simples e limpo, sem customizações ou dados. Este ambiente também é útil para identificar problemas e como o ambiente trabalha de forma nativa.
Pré-Produção - Este é um ambiente idêntico ao ambiente de produção, utilizado para a validação de customizações antes de estar serem migradas em definitivo para a produção. Este também pode servir como um ambiente de testes para identificar problemas em customizações aplicadas em produção de forma errada.
A empresa necessita de alta disponibilidade dos serviços de IIS?
Sabemos que o serviço de IIS é utilizado por vários componentes do AX tais como Web Services, Enterprise Portal e Help Server. Caso a empresa necessite de alta disponibilidade para qualquer destes componentes o numero de servidores aumentará.
A alta disponibilidade de banco de dados é necessária?
Havendo a necessidade de alta disponibilidade de qualquer um dos itens acima, obviamente também será necessário configurar a alta disponibilidade dos serviços de banco de dados! Desta forma deveremos configurar corretamente a quantidade e configuração do hardware para banco de dados. Para mais detalhes sobre alta disponibilidade de SQL Server consultem este
link.
Qual o nível de Disaster Recovery exigido pelo cliente?
Todas as implementações do Dynamics AX deveriam incluir um plano de Disaster Recovery. No caso de falha de qualquer dos componentes do Dynamics AX precisamos ser capazes de recuperar as informações e disponibilizar o sistema o quanto antes. O Clustes de SQL Server nos ajuda a ter mais segurança em relação ao banco de dados, mas algumas outras perguntas devem ser feitas:
- Que tecnologia será utilizada na criação do plano de Disaster Recovery?
- Qual o intervalo aceitável de perda de dados?
- Quanto o tempo aceitável para a disponibilização do sistema?
- Onde serão disponibilizados os dados de backup? Onde será o Disaster Recovery Site?
- Este local deverá sempre ser fora da infra estrutura da empresa de forma a evitar problemas físicos e desastres naturais!
Este
link nos dará mais detalhes sobre o assunto acima!
Qual a estrategia de backup a ser utilizada?
A estrategia de backup deve incluir qual o melhor tipo de backup (Full, Diferencial ou Transaction Log), a frequência do backup e onde os arquivos de backup serão armazenados. Logicamente a estrategia deve envolver o processo de restore deste backup em um ambiente de testes afim de validar a integridade dos backups. Analise também o espaço em disco necessário para um backup full e se a compressão de arquivo será utilizada nas rotinas de backup. Outras dicas podem ser encontradas neste
link.
Para nos ajudar a construir o sizing ideal existem alguns Guidelines que podem nos ajudar. Atenção a este ponto pois cada sizing varia de acordo com as necessidades de cada cliente, os guidelines indicados aqui servem somente como um parâmetro inicial e devem ser considerados como tal.
Database Server Sizing Guidelines
O sizing para o banco de dados do Microsoft Dynamics AX deverá ser baseado no volume de transações concorrentes. É mais importante entender a quantidade e carga das transações do que saber a quantidade de usuários concorrentes.
O guideline para banco de dados inclui o seguinte:
O servidor deverá ser dedicado ao banco de dados do Dynamics AX.
CPU - O servidor deverá possuir um núcleo de processador para cada 4 ou 12 mil transações por hora, com um minimo de 04 núcleos. Por exemplo, uma empresa que insere 48mil transações por hora deverá possuir um servidor com 04 a 12 núcleos de processador.
Memoria - Para cada núcleo de processador é necessário ter de 02 a 04GB RAM. Portanto, em um servidor com 08 núcleos precisaríamos de um minimo de 16GB RAM ou máximo de 32GB.
Storage - Arquivos de dados, logs e tempdb devem ser armazenados em RAID 10. Logicamente o disco deverá possuir espaço o suficiente para suportar o volume de dados do AX.
Application Object Server (AOS) Sizing Guidelines
Este guideline deverá ser utilizado como ponto de partida, mas outros elementos como módulos a serem utilizados, integrações e customizações devem ser levadas em considerações na geração do sizing final.
Assim como o servidor de banco de dados, o AOS Server deve ser configurado tendo como base o volume de transações, logicamente a quantidade de usuários deverá ser levada em consideração.
CPU - O servidor deverá possuir um núcleo de processador para cada 4 ou 12 mil transações por hora. Um núcleo também deverá existir para cada 25/100 usuários concorrentes.
Memoria - 04GB ou 08GB RAM devem ser alocados para cada AOS.
Obs: Uma alternativa é criar servidores de AOS com 04 núcleos de processador e 08GB RAM e adicionar mais servidores de AOS a cada 48mil transações por hora ou a cada 250 usuários concorrentes.
Batch Server - Servidores de AOS utilizados como servidores de lotes devem possuir de 01 a 04 threads alocados para cada núcleo.
Enterprise Portal Sizing Guidelines
CPU - O servidor de Enterprise Portal deverá possuir de 2 a 16 núcleos dependendo do numero de usuários e complexidade das transações. Normalmente 01 núcleo para cada 120 usuários deve ser adicionado.
Memoria - 02GB RAM devem ser alocados para cada núcleo de processador.
Terminal Server Sizing Guidelines
Ao criar o sizing para este serviço é necessário, logicamente, considerar a quantidade de usuários que vão utilizar este serviço para determinar a configuração do servidor. Este servidor possivelmente terá aplicativos como o Microsoft Office e outros e por esta razão a configuração do servidor sofrerá alterações.
CPU - Um minimo de 02 núcleos devem ser alocados para servidores de RDS.
Memoria - Um minimo de 04GB RAM devem ser alocados para este servidor. Deverão ser alocados 200MB para cada usuário a que vai acessar este servidor.
Rede - Caso a latência da rede local seja maior do que 50ms ou seja necessário efetuar o acesso ao AX de fora da rede é indicada a utilização do RDS.
Benchmarks
Para ajudar a construir sizing ideal é indicado a utilização dos documentos de benchmark gerados pela Microsoft. Estes documentos podem ser adquiridos através deste
link. A leitura destes documentos é importante!
Espero que este post gere uma discussão saudável e que o final dela seja a melhor pratica para a geração do sizing para o Microsoft Dynamics AX.
Este post foi baseado em diversas documentações da Microsoft, ao encontrar falhas no post como erros de português ou mesmo informações incorretas ficarei grato se me corrigirem! Erros acontecem!
Este post será constantemente atualizado visando melhorar o conteúdo e também meu entendimento sobre os assuntos aqui escritos.
"Este post foi criado baseado em diversas documentações da Microsoft, mas apesar disso este post reflete apenas a minha opinião de forma que a empresa Microsoft nada tem a ver com o que escrevi aqui."
