The Business Application

By using the banking example, we can determine all the necessary considerations for identifying, describing, and characterizing the workloads. We first define the banking activities as the business application. Within the application are several subsets of activities, which can be directly related to application programs that support the banking business application. We will now convert our abstract teller infrastructure, supporting the banking application to a computer infrastructure with servers and related components that allow users to perform transactions. This is illustrated in Figure 17-3 and will serve as our basis for workload considerations for this chapter.

Figure 17-3: Banking configuration example: defining the business application

Using Figure 17-3, we see that identifying parts of the application becomes fairly straightforward, as an application development group defines the functions performed by the business application. This provides an inventory of application programs that have been developed and need to be available for meeting the users needs through their transactions. We evaluate each function, or program, to our computer configuration, as indicated in Figure 17-3.

We do this by understanding the data organizational structures required for each application program, the data paths it uses, and the user access requirements for each. For example, our checking deposit program uses a database and related log files to handle its processes. The user access demands that the deposits be reflected in the daily database but also in the statement of record for the customer, which is in another database. Further subsets of this information go toward an activity log used for updating other applications within the banking business application.

Deposit ApplicationWorkload Attributes

The previous information describing the banking transaction pretty much defines the data paths required for the deposit program. We then coalesce this information into a set of workload definitions for the deposit application. Based upon the organizational and user access information, we can define additional attributes of the data path . This allows us to describe the deposit application with the following attributes and begin identifying it as a workload.

• Data Organizational Method (DOM)   Relational database, flat files, and temporary suspense files.

• User Access (UA)   Online transactions that require immediate update to daily customer tables, with conditional processing based on secondary transactions to customer system record tables and log suspense files.

• Data Paths (DP)   Macro data paths require update access to daily customer tables, read access to daily suspense tables, and a system of record tables. In addition, there are multiple paths required to facilitate the reliability, availability, and serviceability of the application.

By further defining the technical attributes of the workload, we begin to make decisions on where this particular program will be placed within our infrastructure. These are illustrated in Figure 17-4, which are depicted as updates to our initial Figure 17-3. We can now overlay workloads within this configuration. What we have in our sample banking application is a classic OLTP workload that supports the deposit subset of functions. The OLTP workload dictates several configuration characteristics at a minimum, with additional considerations based upon estimated traffic and growth.

Figure 17-4: Placing workloads within an infrastructure

This defines a simple model for identifying and describing a macro set of attributes for the workload. Having done this, there are additional details that become necessary as we move to place the application into our sample configuration. Now it becomes necessary to further understand the resource utilization, traffic arrival rates, and environmental conditions surrounding the support of this workload. However, before we proceed with deriving additional details from the deposit application, we must address in summary fashion the analysis of the complete inventory of the Banking Application. This requires using the same process that created our initial workload definitions for the deposit application.

Given this iterative process, the importance of analyzing the entire Banking Application in context cannot be overemphasized. During this process, we find that many of the applications within the Banking Application have similar workload characteristics, such as same database, similar user access demands, and process requirements. On the other hand, we also recognize that many applications have completely diverse sets of attributes. Our example shows two other distinct workloads for placement within our configurationa batch workload and an archival workloadeach of which has a unique set of user transactional requirements.

Note 

It should be noted that such distinct workloads were chosen to reflect the ubiquitous nature of each configuration. These can be found in almost all IT data centers and remain applicable across business and scientific applications.

This requires an accumulation of resource, access, and environmental elements to derive a total picture of the workload. As such, our original example of the banking deposit becomes only a part of the Banking Online System, which we have concluded from its accumulated characteristics to be an OLTP workload, with a set of requirements designed to meet user expectations. Figure 17-5 offers guidelines for identifying workloads and defining their characteristics.

Figure 17-5: Guidelines for identifying and defining workloads

Another interesting aspect to this exercise is something you may have already concluded as we moved through our workload identification and definition stage. That is, with few exceptions, the majority of resource requirements and characteristics center around the I/O of the workload. Certainly I/O plays a pivotal role in processing transactions, given the necessity of timely execution of data acquisition and transfers in relation to response time. Within this simple concept lies an interesting conclusion: over 90 percent of the workloads that IT professionals deal with are I/O- intensive transactions. In other words, the majority of activities encapsulated within commercial processing consist of I/O-related activities.

The corollary to this observation is that the majority of workload planning and implementation centers on the I/O system that supports the processing infrastructure. A further realization is the importance storage architecture plays within the infrastructure and the tremendous impact putting storage on a network will have. Why? Because it changes the implementation strategy of the workload so dynamically that workload identification and definition becomes paramount. Otherwise, just throwing disparate workloads within a storage networking infrastructure can be a hit or miss affairone with a low probability of success. However, making it too simple and only implementing homogeneous workloads may not leverage the real value of storage network technology in how it supports disparate workloads.

The conclusion is that workload identification, definition, and planning are critical activities to the effective application of storage networks.