IBM SmartCloud Desktop Infrastructure with IBM Virtual Desktop Reference architecture. 07 February 2013

Transcription

1 IBM SmartCloud Desktop Infrastructure with IBM Virtual Desktop 07 February 2013 Copyright IBM Corporation, 2013

2 Table of contents Introduction...1 Architectural overview...1 Component model...2 IBM Virtual Desktop provisioning... 6 Storage model... 7 Operational model...8 Compute servers... 8 Management servers Systems management Networking Shared storage Operational model component summary Deployment diagram Resources...14 Trademarks and special notices...15

3 Introduction This document describes the reference architecture for using IBM Virtual Desktop. It should be read in conjunction with the IBM SmartCloud Desktop Infrastructure (SDI) reference architecture document available at ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure. The business problem, business value, and requirements are described in the IBM SmartCloud Desktop Infrastructure reference architecture and are not repeated here for brevity. This document gives an architecture overview and component model of the IBM Virtual Desktop with Virtual Enterprise Remote Desktop Environment () from Virtual Bridges and then describes the deployment model of the IBM Virtual Desktop using different numbers of users. Architectural overview Figure 1 shows all of the main features of the IBM SmartCloud Desktop (SDI) reference architecture with IBM Virtual Desktop. Directory Services, DNS, DHCP Internet Clients FIREWALL Gateway or 3 rd party VPN FIREWALL Distributed Connection Broker Distributed Connection Broker Dynamic Desktops Dynamic Desktops Cluster Server (1) Cluster Master Cluster Server (n..) Cluster Master Shared Data Store Cluster Internal Client Figure 1. SDI reference architecture with IBM Virtual Desktop This reference architecture also does not address the issues of remote access and authorization, data traffic reduction, traffic monitoring, and general issues of multi-site deployment and network management. This document limits the discussion to the components inside the customer s intranet. 1

4 Component model Figure 2 is a layered view of the SDI infrastructure mapped to the IBM Virtual Desktop solution for virtual desktop infrastructure (VDI) using the hypervisor. Console Client tools Client Devices Client tools Client tools Administrator GUIs for Support Services HTTP/HTTPS RDP, SPICE or NX Local SAS Drives Desktop Provisioning and Monitoring Distributed Connection Broker Storage Optimizer Cluster Management (Active) Management Services Gold Master image (GM) Session 1 (GM) based differences Session n (GM) based differences Virtual Desktops Local SAS Drives Desktop Provisioning and Monitoring Distributed Connection Broker Storage Optimizer Cluster Management (Passive) Management Services Gold Master image (GM) Session 1 (GM) based differences Session n (GM) based differences Virtual Desktops Support Services Protocols Directory DNS DHCP OS Licensing VDI Server (Cluster Master) Additional VDI Servers NFS or CIFS Cluster Meta Data Guest Image Repository Static User Image File Server Profiles IBM Virtual Desktop Infrastructure 6.x Support Services Figure 2: Component model for SDI with IBM Virtual Desktop The main components for IBM Virtual Desktop are described as follows. The IBM SmartCloud Desktop Infrastructure reference architecture document available at ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure can be used as a guide. Note that all IBM Virtual Desktop management components are either installed on each compute server node, shared storage or on the client device. 2

5 console A single web-based console provides centralized gold image management to create, publish, update, clone, and delete images. The console enables granular desktop security and session policies based on Active Directory or any other directory server. End-user desktop sessions are started through the console. The user gets highly secure access to assigned guest sessions through the Simple Protocol for Independent Computing Environments (SPICE), Remote Desktop Protocol (RDP), or NX protocols. Desktop provisioning and monitoring Distributed connection broker and hypervisor Each server supports rules-based provisioning to automate virtual desktop deployment. Rules-based provisioning deploys virtual desktops at user login time. A well-designed set of provisioning rules allows virtual desktop deployments to be driven from an authentication system rather than from itself. The servers also monitor each user session that users have launched and report the data back to the cluster master. The operator can access this data using the console. Each Server includes a distributed connection broker and a KVM-based hypervisor for VDI sessions. Storage Optimizer Storage Optimizer, am cache input/output (I/O) technology, works by caching the I/O operations from each virtual desktop onto VDI compute nodes for common data reads and transient data writes. replicates shared virtual desktop data at scheduled intervals, while running virtual desktop workloads from the server direct-attached storage (DAS). Cluster management (cluster master) The cluster master is responsible for managing the cluster of servers. It performs tasks such as assigning user desktops to the VDI servers on which they will run. After logging in to the cluster, a user's session resumes regardless of which VDI server is available. There is only one active cluster master, but any number of VDI servers can be designated a cluster master candidate for fail-over purposes. automatically assigns the role of cluster master to one of the candidate servers. A cluster master candidate is defined through the menu after a bare-metal installation or through the post-installation configuration script after a traditional installation. This technology allows the IBM Virtual Desktop to scale as simply as adding a new server to a web-server farm. The cluster master relies on the VDI servers to provide and maintain state information based on what is running on those systems and performs the following tasks: The cluster master performs load balancing and relays these results in the form of referrals when new clients connect to the cluster. Existing clients are referred to the 3

6 VDI servers where sessions are already running. The cluster master is accessed through secure (https) port Any candidate must assign this port to cluster master communication. The load-balancing algorithm can result in new sessions always starting on the same server, until that server's cumulative load rises to the level of the other servers. VDI server The VDI server is one of many nodes in the cluster that serve virtual desktops to users. Users connect to the cluster using an entry point and a session point. When VDI servers start, they immediately attempt to connect to the cluster master, and retry every three seconds if they cannot connect. After they are connected, they broadcast their current state of any running sessions to the cluster master. VDI servers broadcast their system-level status (processor load, total session count) every three seconds to the cluster master. The entry point is any VDI server in the cluster. When a new connection starts, the VDI server automatically checks the cluster master for either a matching persistent session (if one exists), or a recommended VDI server to host the new session. The VDI server communicates this information back to the client as a referral. The session point is the referral s IP address. Clients disconnect from the entry point and connect to the session point. Because connections are dynamic, the cluster master would have made a reservation for the session point on the particular server that receives it. Users then authenticate against the configured repository and are either connected to an existing persistent session or given a new session. Local SAS drives These are locally attached compute server drives configured as RAID-0. No persistent data is stored on these drives so faulttolerance is not required. The local serial-attached SCSI (SAS) drives store: The operating system (OS) The copy on write delta files that are presented to the users as virtual desktops. These deltas are discarded at the end of each session. The user profile is persistent because it is not stored in these deltas. The image read cache, which is a full local copy of the gold master image that is cached locally on disk and subsequently loaded in local free system RAM for faster 4

7 Gold master image user session access, further reducing the I/O per second (IOPS) on the local drives. Changes for each user s dynamic virtual desktop are stored in copy-on-write delta files. cluster meta data The state of the cluster, networking and role of each server is stored in a series of files that are maintained on the shared storage device. Guest image repository A read-only instance of all available desktop images. The servers read from this to verify that they have the latest instance of the gold master, and if there are any new gold masters that must be cached. Administrators can check out images for modification from this location to ensure that gold master changes originate from a managed source. Static user image This is an image file that is deployed as a static desktop. It is stored and accessed on the shared storage. Each user has a static image, which is initialized as a replica of the gold master image. user profiles An integrated profile management solution that adds persistent profiles to any gold master nonpersistent desktop. The result is the flexibility and optimization of nonpersistent gold master images combined with persistent user profiles without the need for external tools such as Microsoft Roaming Profiles (MSRP) or third-party profiling solutions. IBM Virtual Desktop also integrates with external tools if the environment so requires. Gold master image The gold image model enables creation and management of a small set of desktop images that are used a large number of users. supports Microsoft Windows XP, Windows 2008, Windows 7, and any flavor of Linux desktop from the same infrastructure. Users run a nonpersistent session of the gold master image with all of their personal settings and documents written to a separate disk. This model reduces the number of images to manage, which helps reduce storage and maintenance costs. Because images are readonly, this solution provides native malware resistance to all desktop sessions. Client devices Supported client devices include Windows, Mac and Linux. ios, and Android platforms. Thin-client and zero-client technologies are also supported. Client devices can be repurposed to extend hardware useful life, thin clients for low cost of hardware ownership, mobile devices to support bring your own device (BYOD), bring your own PC (BYOPC) or even laptops provisioned with a VDI image providing offline virtual desktops for highly mobile users. tools Typically installed on the client device, these JAVA and ActiveX controls enhance the user experience such as display 5

8 connections, USB redirection and follow me printing. RDP, Spice, NX The virtual desktop image is streamed to the end user access device using the display protocol. The protocols available are RDP, Spice, and NX (no system for Linux guest operating systems). IBM Virtual Desktop provisioning IBM Virtual Desktop supports different modes for virtual desktop deployment. Organizations can start with one deployment model, and migrate to another as adoption in an organization grows. Figure 3 shows the supported deployment modes. Kiosk Fully Persistent Nonpersistent Dynamic Dynamic Long-Life Static User layer My Docs fileshare Nonpersistent Persistent Persistent Persistent System image Nonpersistent Non- Persistent Persistent until Gold-Image update Persistent IBM Virtual Desktop s default end-user deployment is a personalized desktop. Figure 3: IBM Virtual Desktop deployment modes The four supported deployment modes are nonpersistent, dynamic, dynamic long-life, and static. The default deployment mode for IBM Virtual Desktop is a dynamic session for the end user. 6

9 Nonpersistent A nonpersistent desktop is a desktop session that does not maintain any transient session data or user profile data between session starts. These session types are usually found in public areas where kiosks would be used. Dynamic Dynamic desktops keep all system image changes in transient storage, which gets flushed automatically when the desktops exit a session or the gold image changes. The difference between dynamic and dynamic longlife is how changes to the system image are handled. For normal dynamic desktops, transient changes are only kept until the desktop is shut down. Users will get a fresh copy of the gold image each time the session is launched. Changes to the gold image are removed after every shutdown. This is same as the stateless virtual desktop model described in the IBM SDI. Dynamic long-life Dynamic long-life desktops are similar to dynamic desktops except that user changes to the system image are preserved until the gold image changes. This mode is typically used to enable frequent anti-virus updates without requiring gold image changes. Static Static desktops are provisioned from a gold image and are then owned by a user, meaning the user is responsible for all changes to the system areas. They do not inherit changes from the gold image like dynamic desktops do. Static desktops allow users to install their own applications, make system configuration changes, and apply security patches within their virtual machines (VMs). This is same as the dedicated virtual desktop model described in the IBM SDI. Storage model The storage model is a combination of both local storage and shared storage. Local storage Local storage is used by IBM Virtual Desktop to store a cached copy of the gold master image, and the transient storage for each concurrent user session. Part of the Storage Optimizer I/O methodology is to use a write cache, which is used by dynamic desktops to minimize the actual per-user persistent storage of a given gold image configuration. For example, if a gold image installation consumes 16 GB of storage, each deployed user running a dynamic instance of it might need less than 1 GB of persistent storage space, plus some temporary storage (transient storage) because only the delta from the gold image is stored for each user. The write cache requires transient storage. Transient storage requirements vary greatly depending on applications, use, and even runtime length of sessions. However, a conservative estimate is 20% of the gold image size for each deployed instance. The write cache uses locally attached storage in the compute node, which is less expensive than shared storage. It is important to consider the space needed to store the copies of the gold images when sizing the direct-attached storage (DAS). 7

10 Note that can use solid state drives (SSDs) but performance data indicates that inexpensive Serial Advanced Technology Attachment (SATA) drives are most cost-effective solution for the IBM Virtual Desktop solution. Shared storage Shared storage is needed when there is more than one VDI server in the cluster. Dynamic VMs use the following shared storage:: User profile information, which is presented in a virtual desktop as a D drive for Windows VMs and a \home path for Linux VMs. IBM Virtual Desktop persists the user profile including the hidden AppData folder into user profile disks for each user. In addition, there is an option to store user documents (Windows 7 libraries or Windows XP My Documents ) outside of the user profile disk by redirecting these folders to a network file system (NFS) share. The golden master image. The centralized master images used for all users to create virtual desktops through associated delta (CoW) files. Operational model Although the IBM Virtual Desktop supports multiple deployment models, the operational model for this reference architecture focuses on dynamic desktop sessions with end-user persistent data. In order to illustrate the operational model for different sized customer environments, four different models are provided for supporting 600, 1500, 4500, and users. Note that the operational model for users is essentially 7 times larger than the model for 1500 users and therefore, user between 1500 and can be extrapolated, by using different multiples of the 1500 user model. Compute servers Compute servers are servers that run the hypervisor, connection, distribution brokers and host IBM Virtual Desktop VMs (user sessions). This reference architecture assumes a VM memory size of 1.5 GB. IBM testing has shown that 125 users per server with 256 GB of memory is a good baseline and has on average 75% utilization of the processors in the server. If a server goes down, then users on that server need to be transferred to the remaining servers. For this degraded failover case, IBM testing showed that 150 user per server have on average 90% utilization. It is important to keep this 25% headroom on servers to cope with possible failover scenarios. Other than the limit imposed by the processor power, the number of compute servers required for a given number of users is in direct proportion to the memory size required for the VM and the number of users. Figure 4 shows the number of users that can be supported given the VM size (on the horizontal axis) and the amount of memory in the server given a limit of 150 users per compute server. In this reference architecture and in most cases, IBM recommends that the compute server has 256 GB of main memory. If the average VM size is less than 1.25 GB of memory, then 192 GB of memory is sufficient, as additional memory would be unused. Servers requiring only 128 GB are unlikely because the cut-off point for eliminating wasted memory is <0.75 GB per VM. 8

11 160 Memory Available on Server (GB): Number of VMs VM Size (GB) 4 Figure 4: Number of users supported by main memory and VM size The compute servers can be either IBM x240 Flex System nodes or IBM System x 3550 rack servers. The detailed specification is as follows: Processor: 2 x E C 2.7 GHz 20 MB Cache 1600 MHz 130 W Memory: 256 GB as 16 x 16 GB DIMMs (2Rx4, 1.5 V PC CL11 ECC DDR3 LP RDIMM) Network interface card (NIC): Integrated 10 GbE adapter for x240 Flex System nodes or Emulex Dual Port 10 GbE SFP+ Embedded Virtual Fabric Adapter for x3550 rack servers Local Storage: 2 x 900 GB 10k SAS drives in RAID-0 Table 1 shows the number of compute servers needed for each user size (assuming a VM size of 1.5 GB): VM size 1.5 GB 600 users 1500 users 4500 users users Compute users Compute users (failover) Failover ratio 4:1 5:1 5:1 7:1 Table 1: IBM Virtual Desktop compute servers needed Power users require larger VMs but also need more processor power and therefore it is not usually worth considering servers with more memory than 256 GB. If the VMs are larger than 1.5 GB, fewer users can be accommodated per server, thus the number of servers needs to be increased appropriately, and memory should be sufficient again on a per-server basis. If the VMs are smaller than 1.5 GB, then compute servers with less memory can be used because too many users would overwhelm the processor power of the servers. 9

12 Management servers IBM Virtual Desktop does not require a separate set of systems to manage the compute servers. Each compute server is a candidate to become the cluster master. Note that it is assumed that common services such as Microsoft Active Directory, Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Microsoft licensing servers already exist in the customer environment. Systems management Assuming the use of IBM Flex System compute servers, it is recommended to have one or more IBM Flex System Manager nodes, especially in case of the larger configurations, to provide additional systems management capability. Networking As described in the IBM SmartCloud Desktop Infrastructure reference architecture available at ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure there are 3 virtual LANs (VLANs) that each share part of the bandwidth in a 10 Gb Ethernet (GbE) network. All of the compute servers, management servers, and shared storage are connected to the 10 GbE network using a 10 GbE switch. The IBM RackSwitch G8124E and G8264R switches are recommended as they support virtual LANS (VLANs) using IBM Virtual Fabric. Note that although the IBM PureFlex chassis supports internal 10 GbE switches, these are not used because a separate switch is needed for the external shared storage. The IBM Flex System Fabric EN4091 Pass-thru Module is used to pass the 10 GbE connections to the external switch. For 4500 users or fewer, the IBM G8124E 24-port switch can be used. Above 4500 users, multiple IBM G8264R 48-port switches should be used instead as these switches provide more ports. For redundancy an additional or spare switch should be available. Table 2 summarizes the number of 10 GbE switches for each user size: 10 GbE network switch 600 users 1500 users 4500 users users G8124E 24-port switch 2 (1 + 1) 2 (1 + 1) 3 (2 + 1) 0 G8264R 48-port switch (2 + 1) Table 2: 10 GbE network switches needed Separate 1 GbE switches are used for the IT administration network. Again, it is recommended that a spare switch should be available in case of failure. Table 3 summarizes the number of switches for each user size: 1 GbE network switch 600 users 1500 users 4500 users users G port switch 2 (1 + 1) 2 (1 + 1) 2 (1 + 1) 3 (2 + 1) Table 3: 1 GbE network switches needed For smaller configurations and Flex-based systems, consider consolidating the 1GbE network into the 10GbE switch using SFP RJ45 transceivers 10

13 Shared storage VDI workloads such as virtual desktop provisioning, VM loading across the network, and access to user profiles and data files place huge demands on network shared storage. This reference architecture first describes the performance requirements of dynamic virtual desktops and then shows the storage configuration that meets those requirements. Experimentation with VDI infrastructures shows that the input/output operation (IOP) performance takes precedence over storage capacity. This means that more of the slower speed drives are needed to get the required performance than higher speed drives. Even with the fastest drives available today (15k RPM), there still can be excess capacity in the storage system. The large rate of IOPs and therefore large number of drives needed for dedicated virtual desktops can be ameliorated to some extent by caching read data in flash memory (flash cache feature of some N series controllers). However there is a limit to how much flash memory is useful because of the relatively low percentage of read operations. In terms of the IBM System Storage N series range of storage systems, the largest 15k RPM SAS drive is 600 GB. These disks require a larger expansion cabinet with 24 disks in a 4U enclosure. The same number of slower speed 10K SAS drives in a small form factor (SFF) 2.5 in. can be put in a 2U enclosure. In this case superior performance wins over the cost of rack density and the storage configurations all use 600 GB 15k RPM SAS drives. The storage configurations are based on the peak performance requirement, which usually occurs during a so-called logon storm. This is when all workers at a company arrive at the same time in the morning and try to start their virtual desktops, all at the same time. The storage configurations also have conservative assumptions about the VM size, changes to the VM, and user data sizes to ensure that the configurations can cope with the most demanding user scenarios. As mentioned above, the storage configurations tend to have more storage that is strictly required in order to meet the performance objectives for IOPs. In the IBM experience, this extra storage is more than sufficient for the other types of data needed for VDI such as cluster meta data and system log files. Note that the storage configurations do not include facilities for data replication, data compression, or data deduplication. These are all value-added features that might or might not be required. These features might also have an effect on the storage configuration. The storage configurations, where possible, do include flash memory as a means to cache frequently used data. Dynamic virtual desktops (with persistent user profiles) Dynamic virtual desktops using IBM Virtual Desktop uses the transient disk for desktop sessions, and read/write to shared storage for end user persistent data (My documents and AppData). Table 4 summarizes the peak IOPs and disk space requirements for dynamic virtual desktops on a peruser basis. Dynamic virtual desktop (with persistent user profiles) Protocol Size IOPs Write % User Data Files NFS 5 GB 5 75% Table 4: Dynamic shared storage performance requirements 11

14 Table 5 summarizes the storage configuration needed for each user size. In this case, the flash cache does not help at all so a lower end controller with failover is used. It is also assumed that 100% of the users at peak load times require concurrent access to user data files and profiles. Dynamic storage 600 users 1500 users 4500 users users Controller and model number N3220 A22 N3220 A22 N3220 A22 N3220 A22 10 GbE mezzanine cards Flash cache N/A N/A N/A N/A 600 GB 15K rpm drives Spare drives EXN3000 expansion unit Table 5: Dynamic shared storage configuration Operational model component summary Table 6 summarizes the items needed for dynamic desktops (with persistent user profiles) for each user size Dynamic virtual desktop 600 users 1500 users 4500 users users Compute servers Management servers GbE network switches 2 x G8124E 2 x G8124E 3 x G8124E 3 x G8264R 1 GbE network switches 2 x G x G x G x G8052 PureFlex Flex System Manager nodes (optional, only for Flex) Flex Chassis with EN4901 pass-thru module (only for Flex) Storage servers N3220 A22 N3220 A22 N3220 A22 N3220 A22 Storage extensions EXN3000 x 1 EXN3000 x 1 EXN3000 x 3 EXN3000 x 7 Total height (Flex System servers) 20U 20U 49U 109U Total height (x3550 rack servers) 15U 22U 55U 123U Number of racks or 4 Table 6: Operational model summary for dynamic virtual desktop (with persistent user profiles) 12

15 Deployment diagram Figure 5 shows the deployment diagram for an IBM Flex-based system that supports 4500 dynamic virtual desktops (with persistent user profiles). The first rack contains the compute servers and the second rack contains the storage servers and disks. Cxx Each Cluster server has 125 user VMs 1 GbE Switch 1 GbE Switch 10 GbE Switch 10 GbE Switch 10 GbE Switch C1 C2 Flex Chassis 1 C3 C5 C7 C9 C11 Empty EN4091 Pass-thru C4 C6 C8 C10 C12 Empty Flex Chassis 2 Flex Chassis 3 C13 C15 C17 C19 C21 C23 FSM C25 C27 C29 C31 C33 C35 FSM EN4091 Pass-thru EN4091 Pass-thru C14 C16 C18 C20 C22 C24 Empty C26 C28 C30 C32 C34 C36 Empty IBM N3220 A22 DS4243 Extension (24 x 600GB 15k RPM) DS4243 Extension (24 x 600GB 15k RPM) DS4243 Extension (24 x 600GB 15k RPM) Rack 1 Rack 2 Figure 5: Deployment diagram for 4500 dynamic desktops (with persistent user profiles) 13

16 Resources IBM SmartCloud Desktop Infrastructure reference architecture ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure IBM Virtual Desktop ibm.com/smarterplanet/us/en/smartbusiness/virtualdesktop/index.html vbridges.com/products/verde/ 14

17 Trademarks and special notices Copyright IBM Corporation References in this document to IBM products or services do not imply that IBM intends to make them available in every country. 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. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. 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 "Copyright and trademark information" at Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. Information is provided "AS IS" without warranty of any kind. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Information concerning non-ibm products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-ibm list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-ibm products. Questions on the capability of non-ibm products should be addressed to the supplier of those products. All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction. Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here. Photographs shown are of engineering prototypes. Changes may be incorporated in production models. 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 15