This topic describes considerations in planning hardware infrastructure.

Planning Hardware

Decisions about appropriate hardware for Microsoft Dynamics AX depend upon a number of factors. Some of the key factors are listed below.

  1. Evaluate and document the existing infrastructure:

    • Network bandwidth

    • Storage system in use

    • Operating system in use

    • Databases in use

    • Servers in use

    • Current processes for disaster recovery, availability, and scalability

    • Existing applications that need to integrate with Microsoft Dynamics AX

  2. Define and document:

    • Uses of system: Components and modules of Microsoft Dynamics AX you plan to deploy

    • Number of transactions over a period of time as well as total number of transactions during peak business hours

    • Number of active or concurrent users over a period of time as well as total number of active or concurrent users during peak business hours

    • External user access required

    • Web access required

    • Required availability

    • Projected growth rate

    • Number of sites and number of users connecting through a Wide Area Network (WAN)

    • Integration requirements: Are there any applications that need to integrate with Microsoft Dynamics AX and what is the workload generated by these applications? Are these transactions real-time or can they be batched?

  3. With this information in hand, you can start to determine how to structure the system. Key decisions are:

    • Whether any Microsoft Dynamics AX server components can be combined on a single computer, and if they can, which server components to combine.

    • What is your deployment plan for high availability and scalability for Microsoft Dynamics AX components?

    • What is your backup and recovery strategy (whether to have a cold, warm, or hot backup system for the database)?

Transactional Volume

The total average number of transactions processed per work hour is a key indicator of the requirement for storage (type and number of drives), size of the database server, number of AOS servers/clusters and/or batch servers, and network capacity. In Microsoft Dynamics AX, a transaction is defined as processing of a single line item. For example, a sales order with 100 line items would be considered as 100 transactions.

You need to estimate the number of transactions required for each module you plan to use and any corresponding transactions that may be triggered by changes taking place due to your original transactions. You also need to determine if there are any integration points to internal or external applications. For example, if a large volume of transactions is coming in from a Microsoft BizTalk Server, this needs to be factored into your transactional volume and topology planning.

You might want to determine if these transactions are real-time or if they can be batched and processed at off-peak hours. By default, Microsoft Dynamics AX is an integrated ERP application providing real-time updates throughout all modules as information is changed. However, it does provide a batch system for scheduled processing.

Number of Concurrent Users

The total number of concurrent users is one key indicator of the size of the Application Object Server (AOS) system required for proper response time and throughput. While this is not the only criterion used to plan the capacity of AOS servers or server clusters, it is an important factor.

Concurrent users are defined as Microsoft Dynamics AX rich clients, Web clients, mobile clients, or third-party applications that require some processing to take place in the Microsoft Dynamics AX system. Note that the number of concurrent users also impacts your network bandwidth and latency.

Network Requirements

You need to determine the number of users accessing Microsoft Dynamics AX with the rich client, Web client, or mobile client. Users accessing Microsoft Dynamics AX using the rich client must meet minimum network requirements. If those requirements are not met, consider deploying Windows Server Terminal Services.

Planning Hardware for additional components

The core components of a Microsoft Dynamics AX implementation consist of a rich client, an AOS server, an application server, and a database. Additional components include Enterprise Portal, Workflow, Reporting Services, Analysis Services, and Application Integration. You need to evaluate the workload generated for each component and the resource requirements for appropriate deployment with acceptable response time and throughput.

For example, if you have users accessing Microsoft Dynamics AX over a WAN using the Microsoft Dynamics AX Windows client, you should consider deploying Windows Server Terminal Services. Similarly, users accessing role-based home pages will create workload for Enterprise Portal, while users accessing Reporting Services reports will create workload for Report Server, the report database, and the Dynamics AX database.

See Also