An illustration of the server allocation process

---

This section illustrates the server allocation process. The scenario is an infrastructure for an online brokerage providing two transaction workloads and one parallel workload:

• One transactional workload simulates the common operations of online stock trading. This class of transactional workload represents business critical applications.

• The second transaction workload is an account management application through which brokerage customers maintain and view their account information. This application has a lower priority than the stock trading application, but is of higher priority than the parallel application.

• The parallel workload simulates financial analysis services that commercial brokerage houses offer to their customers, such as retirement portfolio analysis. Parallel applications can be broken into units that can be processed in parallel on multiple machines; their processing is typically complex and numerically intensive. The more CPUs made available to a parallel application, the faster the application runs. This class of applications falls in the value-add category, contrasted with those in the business critical category.

Our illustration assumes a business rule that processing transactional workloads has higher priority than processing parallel workloads. This business rule implies that whenever there is a surge in traffic to the business critical application, resources are taken away from the value-add application and assigned to the business critical application.

Figure 1-2 presents a high-level overview of an infrastructure using server allocation.

Figure 1-2: High-level overview of an infrastructure using server allocation

Figures 1-3 through 1-7 illustrate the server allocation process and how activity might be displayed as it happens.

Figure 1-3 introduces what we call the dashboard. The dashboard indicates how server allocation proceeds through the process of monitoring server use, determining through analysis which servers can no longer meet the SLA requirement, reducing the number of servers assigned to the parallel application, reallocating those servers to the WebSphere Network Dispatcher for use by high priority applications until the load returns to SLA limits, and returning the reallocated servers to the parallel application. When indicated, server allocation can provision an application to a server in the pool or, if necessary, invoke the Tivoli Intelligent ThinkDynamic Orchestrator to provision an additional server from the data center server pool.

Figure 1-3: Server allocation dashboard; servers are well below max SLAs in light traffic

The window labeled SAM Server Pool Monitor lists the five servers that comprise the infrastructure. For each server, the window shows what workload(s) is currently assigned, the workload priority, what applications are installed, and current CPU use. Note that Servers 14 and 15 are dedicated to the higher priority workloads, while Server 16, 17, and 18 can run more than one workload. The assignments and metrics are updated periodically as the system responds to traffic and manages the service level requirements for each workload by dynamically allocating and reallocating the servers.

During light traffic:

• Server 14 is assigned to the account management workload (blue), the priority 2 application

• Server 15 is assigned to the stock trading workload (green), the priority 1 application

• Servers 16, 17, and 18 are assigned to the portfolio workload (purple), the priority 3 application

The Transactional Workload Throughput window shows how the server pool is processing the traffic for each workload. The throughput scale changes as the throughput changes. In the same color as the workload designation above, the horizontal lines represent the minimum and maximum service level for the workload. The vertical bars, again in the same workload color, indicate average throughput (dark bar) and total throughput (light bar).

On the right of the dashboard, there are two driver windows, one for each transactional application. The drivers are used to simulate the workload traffic; traffic is low, around 40 concurrent users per application.

Figure 1-4 illustrates what happens when the traffic increases. For our illustration, we simulate 300 concurrent users for the Stock Trading workload and 200 for the Account Manager workload. As traffic increases, the available resources are used to such an extent that the service level agreements for both Stock Trading and Account Manager are exceeded. To handle the increased traffic and maintain the SLA, Server Allocation has already assigned Servers 16 and 17 to Stock Trading, making those additional resources available to the high priority application. Account Manager is also missing its SLA

Figure 1-4: Max SLAs are exceeded; Server Allocation will provision an application to Server 18

However, the traffic is such in this snapshot that even the combined resources of Servers 15, 16, and 17 can no longer maintain the SLA. The average Stock Trading throughput still exceeds the maximum SLA threshold. Look at the line for Server 18. The (P) Trade indicator in the Workloads Installed column indicates that Server Allocation is provisioning Server 18 with the Stock Trading application to provide the additional resource to process Stock Trading traffic.

The snapshot in Figure 1-5 now shows that Servers 15, 16, 17, and 18 are dedicated to Stock Trading. The bar graph for the last timing interval also shows that the SLA is still not being met, even after taking over the last server in the WebSphere server pool. Account Manager continues to miss its SLA. When this situation occurs, Server Allocation invokes the Tivoli Intelligent ThinkDynamic Orchestrator, which provisions another server from the data center pool.

Figure 1-5: All installed servers are at capacity; an additional server is needed to maintain SLA

The snapshot in Figure1-6 shows Server 19 has been added to the list of servers supporting the online brokerage. Most importantly, the combined resources of the servers allocated to Stock Trading are now consistently meeting the SLA.

Figure 1-6: An additional server is processing stock trades; max SLAs are being maintained

---