Beruflich Dokumente
Kultur Dokumente
In this IBM Redpaper publication, we discuss best practices for deploying and utilizing advanced Brocade Fabric OS (FOS) features to identify, monitor, and protect Fibre Channel (FC) SANs from problematic device and media behavior. Fabric Operating System: This paper covers Brocade Fabric OS command options up to and including version 6.4.2b. If you are using a code level higher than this, the guidance and strategy provided by the paper is still applicable. However, you might find additional options available that allow even greater granularity in establishing specific alerting features.
Introduction
Faulty or improperly configured devices, misbehaving hosts, and faulty or substandard FC media can significantly impact the performance of FC fabrics and the applications they support. In most real-world scenarios, these issues cannot be corrected or completely mitigated within the fabric itself. Instead, the behavior must be addressed directly. However, with the proper knowledge and capabilities, the fabric can often identify and, in some cases, mitigate or protect against the effects of these misbehaving components to provide better fabric resiliency. This document provides a high-level description of the most commonly experienced, detrimental device and link behaviors, and explains how to use features in recent levels of Fabric OS (FOS) to protect your data center. In FOS 6.1, Brocade introduced Port Fencing as part of the optional Fabric Watch offering. In FOS 6.3, Brocade added a new set of base features referred to as Bottleneck Detection. This was extended in FOS 6.4 with broader monitoring, improved configuration, and detection capabilities for additional types of bottlenecks. For further details about the features described in this publication, see the following product documents, available with registration at http://my.brocade.com/wps/portal: Fabric OS Administrators Guide (version 6.4, 53-1001763-02) Fabric OS Command Reference Manual (version 6.4, 53_1001764_02) Fabric Watch Administrators Guide (version 6.4.1, 53-1001770-01)
ibm.com/redbooks
Configuring Performance Monitoring and Thresholds in Brocade Data Center Fabric Manager (DCFM), GA-BP-247-00 Bottleneck Detection Best Practices Guide, GA-BP-383-00 It is assumed that readers of this document are familiar with the basic functionality of features, such as bottleneck detection, fabric watch, and port fencing.
Fabric resiliency
Two primary aspects of fabric resiliency are captured in this document: Detecting abnormal behavior in external components (typically servers and hosts, storage devices, or faulty links) so that the negative impact on the fabric can be addressed. Providing mechanisms that protect the fabric from adverse effects caused by a faulty component. This includes one or more actions that can be invoked automatically by a switch, when faulty behavior is detected, to contain and isolate the impact of the misbehaving component in the fabric. This should be considered a temporary measure. Ultimately, the faulty or improperly configured component must be addressed to resolve the problem completely and permanently. There are two common classes of abnormal behavior originating from fabric components: Misbehaving high-latency end devices (hosts or storage) End devices that do not respond as quickly as expected, and therefore cause the fabric to hold frames for excessive periods of time (referred to as slow draining devices), can result in application performance degradation or, in extreme cases, I/O failure. Common examples of moderate device latency include disk arrays that are overloaded and hosts that cannot process data as fast as they request it. Severe latencies are caused by badly misbehaving devices that stop receiving, accepting, or acknowledging frames for excessive periods of time. The Bottleneck Detection feature of the Brocade FOS discussed in this document is specifically designed to identify and raise alerts for high-latency or slow draining devices within the SAN. Faulty media (fiber optic cables and small form-factor pluggable (SFP) transceivers and optics) Faulty media can cause frame loss due to excessive cyclic redundancy check (CRC) errors, invalid transmission words, and other conditions. This might result in I/O failure and application performance degradation. The Fabric Watch monitoring feature of the Brocade FOS discussed in this document is designed to identify and raise alerts for these types of conditions. Be aware that FC switches cannot correct bad node behavior or faulty media. Instead, they can only attempt to alert and compensate for it. Ultimately, the problems must be addressed at the host, target device, or media where the source of the error actually resides.
Most of those features and capabilities are available and supported on the majority of 4 Gbps and 8 Gbps platforms, provided that the most recent FOS releases are used. Some features might require optional licensing. This section discusses these features, minimum release levels, licensing requirements, and platform limitations. It is strongly suggested that you review the additional documentation listed the Introduction on page 1 to understand all of the tools available for maintaining a FC SAN environment. Also, be sure to read the FOS Release Notes. Note: To use all of the capabilities described in this document, switches need to be running FOS 6.4.0 or later.
Bottleneck Detection
Bottleneck Detection was introduced in FOS 6.3.0 with monitoring for device latency conditions, and then enhanced in FOS 6.4.0 with added support for congestion detection on both E_Ports and F_Ports. FOS 6.4 also added improved reporting options and simplified configuration capabilities. The FOS 6.3.1b release (and later) included enhancement in the algorithm for detecting device latency, making it more accurate. Bottleneck Detection does not require a license, and it is supported on both 4 and 8 Gbps platforms.
Device latencies
A device experiencing latencies responds more slowly than expected. The device does not return buffer credits (through R_RDY primitives) to the transmitting switch fast enough to support the offered load, even though the offered load is less than the maximum physical capacity of the link connected to the device, as shown in Figure 1.
Figure 1 Buffer backup on ingress port 6 on B1 causes latency bottleneck upstream on S1, port 3
After it exhausts all available credits, the switch port connected to the device needs to hold additional outbound frames until a buffer credit is returned by the device. When a device is not responding in a timely fashion, the transmitting switch is forced to hold frames for longer periods of time, thus resulting in high buffer occupancy. This, in turn, results in the switch lowering the rate at which it returns buffer credits to other transmitting switches. This effect propagates through switches (and potentially, multiple switches with devices attempting to send frames to devices attached to the switch with the high-latency device), and ultimately impacts the fabric. See Figure 2.
Note: The impact to the fabric (and other traffic flows) varies based on the severity of the latency exhibited by the device. The longer the delay caused by the device in returning credits to the switch, the more severe the problem.
Latency detection
Using Bottleneck Detection to detect devices that exhibit latency, and Fabric Watch to detect frame timeouts, is considered best practice and therefore strongly recommended.
returns from a device is higher than expected. When the condition is detected, Bottleneck Detection reports latency bottlenecks at F_Ports based on configurable thresholds. These reports can then be leveraged to: Determine the specific device port on which device latency is occurring and raise an alert Determine the severity and duration of the latency behavior Determine the actual device latency in the range of 100 microseconds to hundreds of milliseconds Enter bottleneckmon --show to display the percent congestion on specified ports, as shown in Example 1.
Example 1 Using the bottleneckmon --show command to display percent congestion
switch:admin> bottleneckmon --show -interval 5 -span 30 1/16 =========================================================== Thu Jun 16 13:24:11 UTC 2011 =========================================================== Percentage of From To affected secs =========================================================== Jun 16 13:24:06 Jun 16 13:24:11 0.00% (no data for 3 seconds) Jun 16 13:24:01 Jun 16 13:24:06 66.67% (no data for 2 seconds) Jun 16 13:23:56 Jun 16 13:24:01 25.00% (no data for 1 seconds) Jun 16 13:23:51 Jun 16 13:23:56 100.00% (no data for 1 seconds) Jun 16 13:23:46 Jun 16 13:23:51 66.67% (no data for 2 seconds) Jun 16 13:23:41 Jun 16 13:23:46 100.00% (no data for 2 seconds)
To reduce frame drops on E_Ports on core switches, the edge switches that host the end server or storage devices can be configured to have a shorter Hold Time compared to the core switches by using the Edge Hold Time feature (available in FOS 6.3.1b and later). This setting lowers the Hold Time on the edge of the network, which reduces the likelihood of frame loss on the core of the network, effectively mitigating the impact of the misbehaving device. For this reason, it is useful to enable the Edge Hold Time feature. See Configuring Edge Hold Time on page 14 for details about how to enable the Edge Hold Time feature. Enabling and configuring the Edge Hold Time is a nondisruptive operation.
Fabric configuration
Fabrics can be architected to mitigate some impacts of device latency. Isolating the device flows (host or storage pair) that exhibit high latencies, either by putting them in their own fabric or on their own blade or switch, contains the impact of the latencies to the fabric, blade or switch that contains the high-latency device flows. Features such as Integrated Routing (FC Routing) and local switching provide architectural-level solutions that limit the need for more complex monitoring and mitigation capabilities. However, using fabric design as a protection mechanism requires some knowledge of which devices are likely to exhibit latency.
Faulty media
In addition to high-latency devices causing disruptions to data centers, fabric problems are often the result of faulty media. Faulty media can include bad cables, SFPs, extension equipment, receptacles, patch panels, improper connections, and so on. Media can fault on any port type (E_Port or F_Port) and fail, often unpredictably and intermittently, making it even harder to diagnose. Faulty media involving F_Ports results in an impact to the end device attached to the F_Port and to devices communicating with this device. Failures on E_Ports can have an even greater impact. Many flows (host and target pairs) can simultaneously traverse a single E_Port. In large fabrics, this can be hundreds or thousands of flows. In the event of a media failure involving one of these links, it is possible to disrupt some or all of the flows utilizing the path. Severe cases of faulty media, such as a disconnected cable, can result in a complete failure of the media, which effectively brings a port offline. This is typically easy to detect and identify. When this occurs on an F_Port, the impact is specific to flows involving the F_Port. E_Ports are typically redundant, so severe failures on E_Ports typically only result in a minor drop in bandwidth because the fabric automatically utilizes redundant paths. Also, error reporting built into FOS readily identifies the failed link and port, allowing for simple corrective action and repair. With moderate cases of faulty media, failures occur but the port can remain online or transition between online and offline. This can cause repeated errors, which can occur indefinitely or until the media fails completely. When these types of failures occur on E_Ports, the result can be devastating because there can be repeated errors that impact many flows. This can result in significant impacts to applications that last for prolonged durations. Signatures of these types of failures include the following: CRC errors on frames Invalid Transfer Words (includes encoder out errors) State Changes (ports going offline or online repeatedly) Credit loss (complete loss of credit on a virtual channel (VC) on an E_Port prevents traffic from flowing on that VC, resulting in frame loss and I/O failures for devices utilizing the VC)
Fabric Watch
Enable Fabric Watch to monitor for CRC errors, Invalid Transfer Words, and State Changes. Configure for alerts on reaching low thresholds and fence (disable) a port when reaching high thresholds. See Configuring Port Fencing on page 12 for details about how to enable and configure Fabric Watch Port Fencing.
Bottleneck Detection
The Bottleneck Detection feature can detect different types of bottlenecks in a fabric. Lost buffer credits can result in extreme congestion by slowing the aggregate throughput of a connection. Bottleneck Detection can detect ports that are blocked due to lost credits, and generate special lost credit alerts for the E_Port in this condition (available in FOS 6.3.1b and later). Bottleneck Detection can also generate alerts on upstream E_Ports blocked due to a downstream latency condition such as an E_Port with lost credits or a high-latency device. Bottleneck Detection can optionally create alerts when latencies are detected. Prior to FOS 6.4, alerts are sent to RASlog. Simple Network Management Protocol (SNMP) alerts were introduced in FOS 6.4. See Configuring Bottleneck Detection on page 9 for useful suggestions about configuring and using this feature. FOS version 6.3.2d and above allows for Bottleneck Detection SNMP alerts to be sent through RASLOG AN-1003. AN-1003 itself is not an actual error condition, but rather an indication of a potential bottleneck device. The change in this version 6.3 code level and above provides an easy interface for clients to trap Bottleneck Detection alerts through SNMP.
any period of 300 seconds (default value for time) with a minimum of 300 seconds (default value for qtime) between alerts. switch:admin> bottleneckmon --enable -alert *
switch:admin> bottleneckmon --status Port Alerts? Threshold Time(s) Quiet Time(s) ======================================================================= 3 N ---4 Y 0.100 300 300 5 Y 0.100 300 300 6 N ----
10
Time: the time window in seconds in which bottleneck conditions are monitored and compared against the threshold Quiet Time (qtime) options Note: Bottleneck Detection must be disabled on a port before any of the settings can be modified. To change settings on a port: 1. Connect to the switch to which the target port belongs and log in as administrator. 2. Enter bottleneckmon --disable to disable Bottleneck Detection on the port. 3. Enter bottleneckmon --enable to enable Bottleneck Detection, specify the new threshold values, and set the alert option. Example 3 changes the Bottleneck Detection settings on port 4. In this example, the bottleneck --status commands show the before and after settings.
Example 3 Before and after running the bottleneck --status command
switch:admin> bottleneckmon --status Port Alerts? Threshold Time(s) Quiet Time(s) ======================================================================= 4 Y 0.800 300 300 switch:admin> bottleneckmon -disable 4 switch:admin> bottleneckmon -enable thresh 0.6 time 420 4 switch:admin> bottleneckmon -status Port Alerts? Threshold Time(s) Quiet Time(s) ======================================================================= 4 Y 0.600 420 300
fcr_saturn1:root> bottleneckmon --show -interval 5 -span 30 3 ============================================================= Mon Jun 15 18:54:35 UTC 2010 ============================================================= From To affected secs ============================================================= Jun 15 18:54:30 Jun 15 18:54:35 80.00% Jun 15 18:54:25 Jun 15 18:54:30 40.00% Jun 15 18:54:20 Jun 15 18:54:25 0.00% Jun 15 18:54:15 Jun 15 18:54:20 0.00%
Fabric Resiliency Best Practices
11
20.00% 80.00%
2010/03/16-03:40:47, [AN-1003], 21760, FID 128, WARNING, sw0, Latency bottleneck at slot 0, port 38. 100.00 percent of last 300 seconds were affected. Avg. time b/w transmits 80407.3975 us.
12
Use portThconfig to customize Port Fencing thresholds: switch:admin> portthconfig --set -trigger above -action email switch:admin> portthconfig --set -action email switch:admin> portthconfig --set above -action email switch:admin> portthconfig --set -action email port -area crc -highthreshold -value 2 port -area crc -highthreshold -trigger below port -ar crc -lowthreshold -value 1 -trigger port -ar crc -lowthreshold -trigger below
To apply the new custom settings so that they become effective: switch:admin> portthconfig --apply port -area crc -action cust -thresh_level custom To display the port threshold configuration for all port types and areas: switch:admin> portthconfig --show
13
After you select the type of thresholds for an environment, set the low threshold with an action of ALERT (RASlog, email, SNMP trap). The alert will be triggered whenever the low threshold is exceeded. Set the high threshold with an action of Fence. The port will be fenced (disabled) whenever the high threshold is detected.
IBM_SAN384B_27_VF:admin> configure Not all options will be available on an enabled switch. To disable the switch, use the "switchDisable" command. Configure... Fabric parameters (yes, y, no, n): [no] yes Configure edge hold time (yes, y, no, n): [yes] Edge hold time: (100..500) [100] The edge_hold_time value is persistently stored in the configuration file. All configuration file operations, such as upload and download, are supported for this feature. Note: This setting is only available in FOS 6.3.1b and later.
Suggested implementation
Implement the resiliency features provided by the Brocade FOS by using a two-phase approach. In Phase 1, enable only the alerting and monitoring features using the suggested threshold values. In Phase 2, enable the mitigation (fencing) features. This approach allows you to gain experience in the environment (over a 30-day period, for example) using these features, and also provides an opportunity for you to identify and address pre-existing conditions that might exist in the environment, prior to enabling mitigation actions. Note: The suggested approach and associated thresholds presented have been identified as appropriate for most environments. It is possible that specific environments might require alternate settings to meet specific requirements.
14
The resiliency features discussed in this paper were introduced and enhanced over several levels of FOS code. This section specifically refers to the capabilities provided by FOS codes 6.3 and later. FOS code 6.3 contains the majority of these new features. FOS 6.4 introduced additional enhancements, most notably in regard to bottleneck detection. Note: Port Fencing for Class 3 (C3) discards or timeouts is supported on 8 Gbps in FOS 6.3 and later. However, it was not supported on 4 Gbps until FOS 6.3.1b.
Phase 1
Step 1: Enable Fabric Watch alerting
Enable Fabric Watch Alerting on both F_Ports and E_Ports. Table 3 lists suggested values.
Table 3 Suggested Fabric Watch Alerting thresholds for F_Ports and E_Ports Condition Link Resets State Change CRC Invalid Transfer Word C3TX_TO (C3 Discard) F_Ports Low 3 High 5 Low 3 High 7 Low 5 High 20 Low 25 High 40 Low 3 High 5 E_Ports Low 2 Low 2 Low 2 Low 10 NA
Note: The C3 Discard Frames Threshold cannot be applied to an E_Port. Thresholds can be defined using either the Fabric Watch GUI or the command line. Figure 3 on page 19 shows the Fabric Watch Threshold Configuration tab. Example 7 on page 16 shows the CLI commands used to set the low and high threshold values for F_Ports and E_Ports. See the following product documents, available with registration at http://my.brocade.com/wps/portal/registration: Note: Thresholds can also be defined using DCFM; however, detailing the use of DCFM is beyond the scope of this paper. For information about using DCFM to set monitoring thresholds, see the following product documents, available with registration at http://my.brocade.com/wps/portal: IBM System Storage publication Data Center Fabric Manager User Manual Supporting DCFM version 10.4.x, GC52-1304-03, at http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003231 Configuring Performance Monitoring and Thresholds in Brocade Data Center Fabric Manager (DCFM), GA-BP-247-00 at http://www.brocade.com/downloads/documents/white_papers/DCFM_PerfMon_Thresho lds_GA-BP-247-00.pdf
15
Example 7 CLI commands used to set strongly suggested threshold values portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog portthconfig --set -action raslog fop-port -area LR -lowthreshold -value 3 -trigger above fop-port -area LR -highthreshold -value 5 -trigger above fop-port -area ST -lowthreshold -value 3 -trigger above fop-port -area ST -highthreshold -value 7 -trigger above fop-port -area CRC -lowthreshold -value 5 -trigger above fop-port -area CRC -highthreshold -value 20 -trigger above fop-port -area ITW -lowthreshold -value 25 -trigger above fop-port -area ITW -highthreshold -value 40 -trigger above fop-port -area C3TX_TO -lowthreshold -value 3 -trigger above fop-port -area C3TX_TO -highthreshold -value 5 -trigger above e-port -area LR -lowthreshold -value 2 -trigger above e-port -area ST -lowthreshold -value 2 -trigger above e-port -area CRC -lowthreshold -value 2 -trigger above e-port -area ITW -lowthreshold -value 10 -trigger above e-port -area C3TX_TO -lowthreshold -value 2 -trigger above
After the custom thresholds and actions have been defined as shown in Example 7, they must then be applied. Example 8 shows the CLI commands used to apply the custom defined threshold and action for each area.
Example 8 CLI commands used to apply custom defined thresholds and actions portthconfig portthconfig portthconfig portthconfig portthconfig portthconfig portthconfig portthconfig portthconfig portthconfig portthconfig portthconfig --apply --apply --apply --apply --apply --apply --apply --apply --apply --apply --apply --apply fop-port -area LR -action_level cust -threhsold_level cust fop-port -area LR -action_level cust -threhsold_level cust fop-port -area ST -action_level cust -threhsold_level cust fop-port -area ST -action_level cust -threhsold_level cust fop-port -area CRC -action_level cust -threhsold_level cust fop-port -area CRC -action_level cust -threhsold_level cust fop-port -area ITW -action_level cust -threhsold_level cust fop-port -area ITW -action_level cust -threhsold_level cust fop-port -area C3TX_TO -action_level cust -threhsold_level cust fop-port -area C3TX_TO -action_level cust -threhsold_level cust e-port -area LR -action_level cust -threhsold_level cust e-port -area ST -action_level cust -threhsold_level cust
16
portthconfig --apply e-port -area CRC -action_level cust -threhsold_level cust portthconfig --apply e-port -area ITW -action_level cust -threhsold_level cust portthconfig --apply e-port -area C3TX_TO -action_level cust -threhsold_level cust
Note: For threshold alerts to be acted upon by writing them to the RASlog, sending an email, or sending an SNMP trap, the -trigger and -action parameters must be specified. Multiple actions can be specified when separated by commas. Example: portthconfig --set fop-port -area LR -lowthreshold -value 3 -trigger above -action raslog,email,snmp
butane:admin> bottleneckmon --enable -alert 1 butane:admin> bottleneckmon --enable -alert 2 butane:admin> bottleneckmon --enable -alert 3 butane:admin> bottleneckmon --status Port Alerts? Threshold Time (s) Quiet Time (s) ====================================================================== 1 Y 0.100 300 300 2 Y 0.100 300 300 3 Y 0.100 300 300 butane:admin>
17
Example 10 shows the commands used to enable Bottleneck Detection alerting on FOS 6.4. Be aware that on FOS 6.4, all ports are enabled together on a logical switch basis.
Example 10 Enabling Bottleneck Detection alerting (for FOS 6.4 and later)
max2:admin> bottleneckmon --enable -alert * max2:admin> bottleneckmon --status Bottleneck detection - Enabled ============================== Switch-wide alerting parameters: ============================ Alerts - Yes Action requested - No Latency threshold for alert - 0.100 Congestion threshold for alert - 0.800 Averaging time for alert - 300 seconds Quiet time for alert - 300 seconds
max2:admin> configure Not all options will be available on an enabled switch. To disable the switch, use the "switchDisable" command. Configure... Fabric parameters (yes, y, no, n): [no] yes Configure edge hold time (yes, y, no, n): [no] yes Edge hold time: (100..500) [100] max2:admin>
Phase 2
Step 4: Enable Fabric Watch Port Fencing
Enable Fabric Watch Port Fencing on F_Ports only. Fencing will occur on the high threshold values defined in Phase 1. See Table 3 on page 15 for information about those values.
18
Note: Although the high threshold values used by port fencing can be defined using the Fabric Watch GUI, port fencing can only be enabled from the command line or through DCFM. For information about using DCFM, see the following document, available with registration at http://my.brocade.com/wps/portal: IBM System Storage Data Center Fabric Manager User Manual, Supporting DCFM version 10.4.x, GC52-1304-03 at http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003231. Figure 3 shows the Fabric Watch Threshold Configuration menu.
19
Note: The recommended threshold settings defined here were found to be appropriate for most environments. In some cases, these settings will be adjusted for the specific environment. If alerting is triggering on events that do not represent a problem, then the values can either be returned to the default values or tuned through trial and error.
Suggested initial aggressive values are: FOS 6.3: thresh=(0.1), time=(120), qtime=(120) FOS 6.4: lthresh=(0.1), cthresh=(0.75), time=(120), qtime=(120) Example 13 shows the commands for changing Bottleneck Detection alerting using FOS 6.3.1b.
Example 13 Changing Bottleneck Detection alerting (for FOS 6.3.1b)
butane:admin> bottleneckmon --enable -alert -thresh 0.1 -time 120 -qtime 120 1 butane:admin> bottleneckmon --enable -alert -thresh 0.1 -time 120 -qtime 120 2 butane:admin> bottleneckmon --enable -alert -thresh 0.1 -time 120 -qtime 120 3 butane:admin> bottleneckmon --status Port Alerts? Threshold Time (s) Quiet Time (s) ====================================================================== 1 Y 0.100 120 120 2 Y 0.100 120 120 3 Y 0.100 120 120 butane:admin>
Example 14 shows the commands for changing Bottleneck Detection alerting using FOS 6.4.
Example 14 Changing Bottleneck Detection alerting (for FOS 6.4)
max2:admin> bottleneckmon --config -lthresh .1 -cthresh .75 -time 120 -qtime 120 -alert max2:admin> bottleneckmon --status Bottleneck detection - Enabled ============================== Switch-wide alerting parameters: ============================ Alerts Latency threshold for alert Congestion threshold for alert Averaging time for alert Quiet time for alert max2:admin>
20
21
22
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
Copyright International Business Machines Corporation 2012. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
23
This document REDP-4722-01 was created or updated on July 13, 2012. Send us your comments in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com/redbooks Send your comments in an email to: redbooks@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400 U.S.A.
Redpaper
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol ( or ), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:
Global Technology Services IBM Redbooks Redpaper Redbooks (logo) RS/6000 System Storage
The following terms are trademarks of other companies: Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Other company, product, or service names may be trademarks or service marks of others.
24