System HardwareArchitecture Instance Design
System Hardware/Architecture Instance DesignThis section deals with planning for a system at targeted user loads and scenarios for a specific point in time. The concepts in this section are appropriate for planning any initial installation the system needs at the two-year mark or any stage of a system life cycle. As such, this section refers to this as instance planning. TIP So many factors play into an enterprise system's performance (as noted in the introduction to this chapter) that estimation is exactly that, estimation. It is the best guess for hardware/architecture needs to support an estimated user volume, usage scenario set, network/hardware environment, and data complexity. To plan for the needs of a system at any specific instance in time, you need to estimate system needs in the following areas:
Each of these areas is important in and of itself. However, each area also touches, or is related to, many of the other areas as well. The interplay between the areas is one more complexity factor of capacity planning. Knowledge of these areas helps to design the instance hardware/architecture and application topology. Since the release of the first version of the Microsoft EPM solution (Microsoft Project Server 2002), Microsoft has maintained a set of six example environment scenarios and the suggested architecture and topology for each. Many of the scenarios are further refined. Common practice has been to go through the requirement need planning in each of the areas listed previously, choose the closest one of the six Microsoft published scenarios for a starting point in terms of suggested hardware architecture and application topology, and then modify as needed. This process is supported by the Project Server 2003 Configuration Planning Guide. This document is updated frequently and is an excellent resource. The next few sections go into more detail in each of the areas specified previously. TIP Microsoft's detailed guidance for capacity planning is in the Project Server 2003 Configuration Planning Guide available at http://www.microsoft.com. Search by name"Project Server 2003 Configuration Planning Guide"because it is updated frequently. User Numbers and TypesTypes of users are defined by a combination of the interface they use to access project information and the scenarios they perform. The interfaces are either Microsoft Project Professional (ProjPro: the desktop thick client) or Project Web Access (PWA: the web interface). There are many typical user scenarios: project maintenance and updating, timesheet entry for project statusing, report viewing for analysis, and many others. The number of each type of user comes into play in two ways:
Data complexity is impacted by the number of team member resources in the database. These generally make up the majority of the PWA users. It is a generality, but the more resources there are (thousands versus hundreds versus tens), the more complex the security structure, resource selection, and assignments. Server load is impacted because of the user number/type relationship to peak usage scenarios, as described in the "Peak/Heavy Usage Scenarios" section later in this chapter. User numbers are meaningful mostly in regard to server usage concurrency and its impacts on performance. User Location and ConnectivityUser location is important because of network impacts between the user and the servers. Network latency is the primary concern here, although bandwidth or traffic can come into play as well. Again, these are generalities, but if users are not collocated in the same building as the servers, frequently bandwidth and latency issues must be addressed. These mostly impact thick client (Project Professional) users (typically project managers); however, in some instances these can impact Project Web Access (PWA) users as well.
Peak/Heavy Usage ScenariosPeak usage scenarios are periods of time during which many users are doing things that put significant loads on either servers or network infrastructures. Typical examples for the Project Server environment are
NOTE Project progression is the process of updating the status of a project plan for the current reporting period. This process is critical to tracking an ongoing project. The first scenario is primarily PWA related. An attempt should be made to realistically describe this scenario. For example, if there are 200 people in your company and the company rule is that everyone reports their time by 5:00 p.m. on Friday, define the peak usage scenario as 200 people entering time in 2 hours instead of 200 people entering time in 10 minutesunless of course you can show that, in fact, 200 people do enter time between 4:50 p.m. and 5:00 p.m. In some extreme cases it may be less costly in equipment to consider requesting that the 100 people in Department A enter time by 4:00 p.m., and the 100 people in Department B enter time by 5:00 p.m. The second scenario is primarily a project managerfocused scenario. In environments where PWA Timesheet functionality is used, the Monday following the time entry is typically when project managers review the time entered and apply it to the project plans to update current task status. This activity is typically called any one of several things: updating the project, project progressing, or project progression. NOTE In companies where PWA timesheets are not used, project progression is still performed but often less frequently. Typically this scenario involves a much smaller set of users but places a more data-intensive load on the server. Network EnvironmentThe network environment (that is, the network connectivity) is primarily important in regard to latency and bandwidth availability. Latency is the time it takes a packet of data to travel from a source computer to a destination computer. It is most relevant in regard to EPM between the client desktop and the SQL Server machine. This connection between the desktop thick client (which contains all the business logic) and the database server is very "chatty." In other words, many individual requests are made by the desktop client of the database server. Each request gets another set of information needed to build the project in the client machine memory. Network latency is added to each request and each response, compounding across the total of all request/response pairs. NOTE Microsoft is addressing the chatty nature of the connection between the desktop client (Project Professional) and the SQL database server in future releases of Project Server. The network latency is most easily measured by opening a Windows Command Shell window on the desktop machine and typing ping sqlservermachine, where sqlservermachine is the SQL Server on which the Project Server database is installed. The ping returns the round-trip time for a series of test packets sent. The latency is the one-way delay or half of the reported round-trip time. Microsoft suggests that any latency greater than 30ms may (depending on data complexity) cause a perceptible delay in opening or saving projects. If network delays are determined to be impacting performance, the solution is to use an application such as Terminal Services, as shown in Figure 26.1, which allows the user to be "remotely" connected using the thick client (Project Professional), which is actually running on a desktop server located near the database server. Figure 26.1. A user on a machine in the first building is actually remoting into a desktop (consider it a virtual desktop machine) in the server building. In a simplified way, you can think of the remote desktop as a camera view of a desktop on another personal computer somewhere distant from you. The camera view gets updated frequently, so it feels like it is living on your local machine even though what is actually happening is that you are seeing updates via screenshots passed to you from the remote machine. Passing only the screenshots from the remote machine reduces the amount of information that must travel back and forth to the client machine because all the heavy traffic is between the remote desktop and the SQL Server and does not include the client machine. NOTE The Terminal Services screenshot analogy is an oversimplification. Terminal Services algorithms have grown complex and leverage many "tricks" to reduce even further the amount of information that actually has to be sent between machines. In fact, full screenshots are rarely sent, a local cache is used, and only the changed portion of the remote screen is updated locally. Available bandwidth can also cause performance issues, as shown in Figure 26.2. An example of bandwidth availability impacting performance is as follows: Multiple users are in building A, and their servers are in building B. The two buildings are connected with a limited bandwidth connection. Users may see performance impacts whenever the available bandwidth is low, which may be an intermittent condition. For example, Project Server may appear very slow at 8:15, which happens to be when a deluge of people in building A arrive and log in to their email servers, using all available bandwidth between the buildings to sync their email. Figure 26.2. Peak bandwidth usage can impact user-perceived performance. The bandwidth usage shown is an example of bandwidth availability patterns even before Project Server is installed. Server EnvironmentServer environment is an area that may be impacted by topology (how many servers you have the application spread over) and what other applications share a server machine (for example, when loaded on the same machine, Microsoft's Internet Information Server and SQL Database Server continually fight over memory, dropping performance, unless SQL is configured to use only a fixed amount of memory). CAUTION Be wary of servers being used for any other nonProject Server applications. You will likely have no control (and little to no visibility) over the resource loads placed on the server by these "foreign" applications. Foreign applications also severely hinder your ability to determine what is actually causing performance degradation when you are performing proactive performance monitoring. Data ComplexityData complexity can vary greatly and typically increases over time as companies develop more refined project management practices and commission more complex projects. A project file may be as simple as a handful of tasks, without any resources assigned, and with no predecessor or successor links. On the other end of the spectrum, a project file may be as complex as tens of thousands of tasks, with multiple people assigned to each, and a high degree of interdependencies such that delaying one task causes a change to many others. As expected, there will be impacts to the amount of data delivered to and processed by the client machines. This in combination with user concurrency (during peak usage scenarios) impacts server loads. Client-Side EnvironmentThe available resources and power of the local desktop client machine are very much a factor for thick client (Project Professional) users. Project Professional contains all the business logic for schedule management, resource loading, and other project management operations. When a project is opened on the client machine, data is retrieved from the Project Server repository to the client machine in a series of transactions. Business rules are then applied and the data expanded in memory. NOTE Complex data is a term used throughout this chapter. Data can be complex in many ways:
Complex data requires more local resources, memory space, and processor time for the data to be unrolled into more accessible structures in local machine memory. Data Storage RequirementsData storage requirements are the physical disk space requirements for retaining the amount of data that will be kept over any period of time. Every resource defined and every project saved in the database uses physical space within the database(s) deployed with the EPM solution. The number of databases deployed depends on the architecture and features of the EPM solution deployed. Data storage estimates must take into account multiple areas:
A five-task project plan with no resources takes up considerably less physical space than a 10,000 task plan with three resources assigned to each task (thereby creating 3 * 10,000 = 30,000 assignment objects). The simplest way to develop a plan to estimate your physical space needs is to perform the following steps:
This mechanism mimics growth and allows an organization to better see the impact of data growth, especially the relationship between the number of concurrent assignments and the PWA administration settings for the date range to include for OLAP generation and the date range for resource availability calculation. These last two settings are both found in the PWA Administration web pages under the Manage Enterprise Features subpane. These two settings frequently bear the responsibility for causing the most database size variation. Each of these ranges may be designated as a sliding window of time. All tasks within this time range will be expanded in the database for reporting purposes. The expansion consists of creating a set of data records for each unique task/resource/day combination. This expansion is performed for the purposes of general OLAP analysis and resource availability reporting. TIP In the final estimations, don't forget project retention factorsthat is, the period of time after project closure for which an organization desires to retain that project information online. Organizations frequently retain projects in the database for several years. Although these projects are likely closed and no longer regularly viewed, they still take up space in the database. One aspect that is difficult to plan for is Windows SharePoint Services (WSS). Project Server can be set up to create a WSS subweb for each project created in Project Server. The WSS site is created from a template WSS subweb that can be modified. The WSS subweb site is a project team collaboration point for project life cycle documentation, project issues and risks, and anything else that a team finds helpful during a project. The simplest way to estimate the space needed for each of these sites is to look back at the artifacts historically created by projects, size them, and add an additional tolerance factor. The wildcard aspect of WSS sites is due to the fact that WSS sites can be created by a WSS administrator and be totally unrelated to projects. Many organizations find that these subwebs are useful collaboration points and create more for other uses. Because these subwebs are unplanned, coping with WSS database size and maintenance issues can come a lot earlier than originally planned. CAUTION SharePoint Portal Server (SPS) is commonly added at some point to provide simpler user-focused access and better search and indexing. With SPS, it is even easier for the number of sites to balloon. SPS implementation should be considered an enterprise implementation on its own and should be very carefully planned, or you may well find yourself with a "tiger by the tail." Miscellaneous Advanced AreasThe EPM solution involves many server products and desktop applications. These in turn can be hosted on multiple machines in multiple hardware configurations. Microsoft continues to add to and refine its existing publicly posted documentation. These should be the first recourse when planning very large implementations. The following list is a set of advanced topics that are more relevant in very large implementations. Many can easily be small books in themselves. Most organizations planning very large implementations will have some experience in these areas, so they are listed here to make sure that they are not overlooked. NOTE Project Server and the EPM solution are now (and have been since the release of Project Server 2003) the most documented Microsoft solution in Microsoft's history.
|
EAN: 2147483647
Pages: 227