Server Hardware

At last, you have cleared all the hurdles and have enough information to sit down and design your EPM solution hardware infrastructure. You can choose from two basic approaches. The first approach assumes that you have all the required information to design your EPM solution hardware infrastructure, that the quality of that information is good, and that there are few doubts and uncertainties about the information providedfor example, information about use of WSS-based features such as issues, risks, and document libraries. Also, this approach assumes that you have a large enough budget to design a robust EPM solution hardware infrastructure that can handle all expected future load increases for the next few years.

NOTE

You do not want to find yourself in the situation where you need to deal with a large initial estimation error 18 months after the EPM solution is implemented and the solution hardware architecture you designed is not flexible enough to be scaled up or out further.

The second approach has a more humble beginning. Initially, you may recognize that you do not have enough good information about future growth needs or information about all usage patterns and feature use. Also, your budget is perhaps constrained at this point. If that is the situation you find yourself in, there are still ways you can design a flexible enough hardware architecture that will allow you to grow and scale up or out in the future without experiencing major pains of redesigning your whole EPM solution architecture from scratch.

The first approach will be discussed here first.

Based on the best practices of many EPM system implementers, you need to gather information about and have an understanding of the following:

• The network topology (bandwidth available and the network latency between client machines and servers)

• The range of complexity of your individual enterprise project plans

• Total numbers of Project Professional 2003 users and Project Web Access (PWA) users and combine this information with client peak usage scenarios determined by your business processes such as

  • Weekly Friday afternoon timesheet submission

  • Monday morning project plan review and updates with the actual work information submitted on the previous Friday

This information, especially the peak usage levels for various scenarios determined by business processes, is estimated based on a vision of the EPM system usage several years into the future.

Then, the collected information can be reviewed in relationship and compared with the six configuration profiles documented in Microsoft's Project Server 2003 Planning Configuration Guide. It is absolutely essential that the EPM system implementer's and her firm's personal experience with other EPM implementations is also considered and reviewed. Reliance on only the six configuration profiles documented by Microsoft is risky because EPM system performance is extremely sensitive to the data complexity of individual project plans in many ways.

This EPM solution architecture design process typically results in an order for machines, the definition of a specific EPM solution topology across those machines, and creates a scenario of the customer having an EPM system ready for future growth.

This is a necessary process you should go through when designing your EPM solution architecture and is the best practice of today. However, many clients cannot accurately predict the needs of tomorrow or the acceptance of the system within their companies and frequently either underestimate or overestimate the speed of the deployments.

NOTE

For large EPM solution implementations you probably want to start with hardware architecture based on three servers as an absolute minimum. The first server would run SQL Server 2000 and Analysis Services. The second server would be your Project Server 2003 front-end application and also run the Views Publishing and Session Manager services. The Project Server 2003 box should be configured as a single node web farm for possible future server node additions. The third server would be dedicated to WSS.

The second approach to designing your EPM solution hardware is an initially more humble approach and may be more acceptable for clients without large budgets.

Many clients cannot afford to invest in a system scoped and architected for forecasted/expected usage levels two or three years down the road. They require the ability to start small and grow and scale up or out their EPM solution architecture. For this scenario, some general guidance based on current best practice knowledge would be helpful, but, unfortunately, very little information is readily available. This section attempts to define some basic principles for the second "start small and grow" scenario.

The best practice to date is to get the best possible hardware your budget can afford for your Microsoft SQL Server 2000 and, if absolutely necessary, run all EPM solution components from this single server box for small deployments or pilot projects.

Optionally, you can consider starting with two servers, one running Project Server 2003 and the second, more powerful server, running your SQL Server 2000 and Analysis Services. The question in this case is where to install and run WSS. The answer depends on how heavily the EPM solution features based on WSS will be used and whether your SQL Server 2000 hardware provides enough capacity to handle additional load from WSS.

The next scale point would be to break out the Project Server 2003 front-end application to a separate server machine. If you want to keep your options open for scaling out your EPM solution architecture in the future, install and configure this Project Server front-end server as a single node web farm for possible future server node additions.

After this point, your options can become vague and are even more dependent on individual EPM solution implementation. Moving SQL 2000 Analysis Services or Views Publishing service off the SQL Server 2000 box are typically the next steps. In most cases, SQL 2000 Analysis Services is usually moved first. Moving the Views Publishing service to another server is a trade-off because it may run faster and reduce the amount of network traffic between EPM system servers when it is running on the SQL Server 2000 box. However, the SQL Server 2000 machine CPU is impacted, and you have to make sure that your SQL Server 2000 machine has enough capacity to handle additional load from the Views Publishing service.

Database segmentation techniques should be an option reserved for cases when you deal with extreme performance issues of your EPM system. Figure 6.1 presents detailed hardware architecture diagrams showing some of your scaling options.

Figure 6.1. Some scaling options you can consider when using the "start small and grow" scenario for your EPM solution.

Both of the previous scenarios (large initial EPM hardware architecture and "start small and grow") require life cycle monitoring of system performance. In general, the most critical measure of performance is the user perception of the EPM solution performance. Unfortunately, the user perceived performance is the end result of a complex system, and you also have to sometimes determine whether the user perception of the system performance is correct. You need to be able to make adjustments to your EPM system and react quickly to address your user concerns.

NOTE

For additional hardware configuration details and examples of six configuration profiles, review Microsoft's Project Server 2003 Planning Configuration Guide, Chapter 6, "Selecting a Project Server Configuration." The Guide is available for download from http://www.microsoft.com/downloads/details.aspx?FamilyID=5f467651-4f7c-4aa5-9243-a529b8b49015&DisplayLang=en.