Applying the SAN to Web Transactional Workloads

Workloads generated from Internet or intranet sources can be very complex. Internet applications can generate transactions from simple reads of web pages to complex queries and updates of database structures. Based upon the processing architectures of web server software, which enable interactive web services, many of the workloads will be almost entirely transactional in nature. However, within this transactional model, another type of transaction type will emergethe messaging transaction.

Though messaging transactions are processed in real time, they will have a different set of processing characteristics than typical OLTP transactions. Messaging provides an asynchronous form of processing where the client application who has submitted the messaging transaction relinquishes any synchronous connection with the corresponding application. The most familiar of these is e-mail, although many other Internet transactions are message-based. This produces a different set of processing characteristics and certainly a more complex set of I/O operations.

Note 

The emergence of asynchronous processing of applications also produced an additional category of software termed middleware. The middleware, which has been used in both traditional interactive application processing architectures as well as Internet/web-based applications, provides the mechanisms for queuing a transaction for later processing. This can be for effective resource utilization or handling larger interactive transaction requests where synchronous processing is impossible . The use of middleware within applications can be a key indicator that storage networking can also be an effective supporting strategy given its architecture to handle multiple workloads and, in the case of middleware, handle multiple middleware queues.

Messaging workloads generate asynchronous I/O operations. This is actually a very simple model where an application transaction is submitted, and a request is queued for later processing. The client, or initiator , of the request is notified that the transaction has been accepted for later execution. The processing is executed at a later time or when required resources become available or are provided. All this is accomplished in a manner that doesnt require the user , or initiator, to wait for the transaction to complete and can continue to execute other transactions. Although the characterization of the messaging workloads can be estimated similar to OLTP as we demonstrated previously, care must be taken to account for delayed I/O and resulting byte transfer requirements that may go unaccounted for when estimating total I/O for web transaction workloads.

Note 

The difference between client and initiator is an important distinction because other software and internal storage bus processes operating on storage devices are initiators of messaging or asynchronous operations.

Web Internet transactional workloads, which well refer to as WIT workloads, also contain typical synchronous transactions, much like those described in our OLTP examples. Many older WIT workloads use file systems for their data organizational models and specifically their web-based file formats. However, the RDBMS vendors have made significant advances in providing a relational model database for web servers. Consequently, many new applications utilize a relational database demonstrating characteristics similar to databases supporting OLTP processing. The fundamental I/O resource requirement details continue to be contained in the I/O activities relative to user access, data organization, and data paths. An analysis of each of these areas begins to form a picture specific to WIT workloads.

In general, WITs require flexibility and multiple paths to sustain their I/O workloads. However, they are not as sensitive to multiple hop degradation given the amount of messaging contained with the workload. Therefore, a meshed configuration can provide both transactional synchronous support through single-hop data paths while messaging data can sustain longer paths due to their asynchronous processing.

The Data Organizational Model

WIT workloads simply use the OS file system as the data organizational method. This provides a straightforward view when determining byte transfer rates for WIT I/Os given the format of web file structures. However, this must be augmented when considering the amount and type of delayed I/Os generated from messaging transactions. Similar to the transactional structure of OLTP, the typical WIT I/O may be small but the random nature of arrival rates and unpredictability regarding the number of users provides a challenging configuration problem. This defines the need for placing WIT workloads in the most flexible environments possible.

User Access

Defining user traffic is the most challenging activity in estimating WIT workloads. In web-based processing environments, the classic time periods do not apply. This is especially true in retail-oriented web sites that rely on customer interaction for sales and which are open 24/7. The requirement to provide adequate service levels in an environment where user interaction crosses worldwide time zones means estimating WIT workloads becomes problematic and challenging at best.

It is not impossible, however. Many software packages and services provide an accounting of user access and traffic analysis. Though most are oriented toward information access and purchase patterns, there is sufficient information to provide a macro estimate of I/O workloads. User access in terms of time periods, time zones, and further seasonal factors demonstrate a SAN configurations ability to provide a flexible storage environment that supports OLTP and messaging types of I/Os.

Data Paths

The number of data paths, as with any workload, is key to the performance of WIT workloads. The influence of FC frame capacities may become a factor when analyzing switch port capacities, given that the nature of OLTP may prove to be overkill in some web transactions. However, in many cases, the FC frame capacity may become the required transport, given the increasing I/O content of web transactions which continue to grow with text, image, and other unstructured data needed for transport. Even though the SAN I/O comprises only a portion of the overall response time factor, given the move to larger Ethernet capacities in order to support client IP networks, the matching components have begun to come together.

Note 

FC frame payloads transport a maximum capacity of user data (approximately 2k).

Data paths for the WITs in a complex web environment, comprised of both OLTP, messaging, and batch loads, will likely surpass the number for typical OLTP. However, the gating factor to this continues to be the reliance of the web server file system. Its important to keep in mind that the probability of multiple data paths may have little or no effect if client requests are queued at the file system. Consequently, there may be a need to consider the following:

• The ratio of channels per server (for example, the number of HBAs per server)

• The need for SMP-enabled servers (meaning more concurrent processing)

• Ensure workload balancing can be used in some form (for instance, in a workload balance software package, processing affinity options, or process prioritization)

More detail on these options can be found in Part VI of the book.

The Design and Configuration of Web-Based Workloads

Figure 18-5 shows an example of a mesh configuration supporting the web-based workload. This configuration is comprised of three FC switches, 18 disk arrays, intersystem -link ports, and an integrated FC-SCSI bridge into a tape library. This supports our workload estimate using web-based consideration and using seven servers with two HBAs, respectively. It assumes a combination of web-based e-mail files, a transactional relational database supporting customer retail transactions, and a complement of web pages. This supports both transactional activity through the meshed configuration where numerous paths exist to the data while the messaging workload is supported by sufficient data paths with consideration for delayed I/O.

Figure 18-5: A web Internet transactional workload using a meshed SAN configuration