An Introduction To Storage Provisioning With Tivoli Provisioning Manager and Total Storage Productivity Center Redp3900

Front cover
An Introduction to Storage Provisioning

with Tivoli Provisioning Manager and TotalStorage Productivity Center
Automate provisioning of SAN File System Simplify infrastructure management Eliminate human errors
Steve Strutt
ibm.com/redbooks
Redpaper
International Technical Support Organization An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center July 2005
Note: Before using this information and the product it supports, read the information in Notices on page v.
First Edition (July 2005) This edition applies to Version 3, Release 1 of IBM Tivoli Provisioning Manager (product number 5724-I15), Version 2 of IBM TotalStorage Productivity Center with Advanced Provisioning (product number 5608-UC0), and Version 2, Release 2 Modification level 1 of IBM TotalStorage SAN File System (product number 5765-FS2).
Copyright International Business Machines Corporation 2005. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi Chapter 1. An introduction to storage provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Problems caused by human error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Storage provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Automating complex tasks with Tivoli Provisioning Manager . . . . . . . . . . . . . . . . . 1.2.2 Tivoli Provisioning Manager and TotalStorage Productivity Center . . . . . . . . . . . . 1 2 2 4 5
Chapter 2. Tivoli Provisioning Manager support for storage provisioning . . . . . . . . . . 7 2.1 Data center model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1 Logical operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.2 Storage templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.3 Administrative interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Representing the storage environment on TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1 Representing Storage Managers in TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.2 Representing SAN Fabrics in TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.3 Representing Storage subsystems in TPM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3 Specifying a servers storage needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3.1 Volume Container Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.3.2 Logical Volume Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3.3 Disk Partition Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.3.4 File System Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.3.5 File system mount settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3.6 Physical Volume Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3.7 Multipath settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4 Storage Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.4.1 Storage Manager operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.4.2 SAN Fabric operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.4.3 Storage Pool operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.4.4 Storage Subsystem operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.4.5 Operating system operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.4.6 End-to-end storage provisioning operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Chapter 3. Provisioning Storage with Tivoli Provisioning Manager. . . . . . . . . . . . . . . 3.1 Storage visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Performing storage operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Add Storage To Host operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Add Storage Volume To Host operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Implicit execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Creating storage templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Controlling user access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 4. TotalStorage Productivity Center with Advanced Provisioning . . . . . . . . . 4.1 Value of TotalStorage Productivity Center with TPM . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 TotalStorage Productivity Center logical operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Storage configuration discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Tracking environment changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 42 43 44 45 46 47 55 57 58 58 59 60
Copyright IBM Corp. 2005. All rights reserved.
iii
Chapter 5. A storage provisioning solution for SAN File System . . . . . . . . . . . . . . . . 5.1 An on demand storage environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 The SAN File System solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 SAN File System physical environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Storage usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Storage provisioning to simplify volume management . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 SAN File System automation tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Modelling of SAN File System in TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61 62 63 63 64 65 66 67
iv
An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
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 Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites 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 illustrates 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. 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 IBM's application programming interfaces.
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:
AIX BladeCenter Enterprise Storage Server Eserver Eserver HACMP ibm.com IBM Redbooks (logo) Redbooks Tivoli TotalStorage
The following terms are trademarks of other companies: Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. 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. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others.
vi
Chapter 1.
An introduction to storage provisioning

This paper is intended as an introduction to the subject of storage provisioning and is written for anyone who needs to understand IBMs automated storage provisioning tools. IBM storage provisioning solutions are based on Tivoli Provisioning Manager (TPM) and IBM TotalStorage Productivity Center (TPC). This paper examines TPMs support for storage provisioning in detail and describes how it can be used standalone or combined with TPC to create a comprehensive storage infrastructure management and provisioning solution. It is assumed that the reader already has some familiarity with configuring SAN storage, so the details of how to configure storage manually are not covered here. Much has already been written about TPM, and the reader is directed to these materials for an in-depth introduction to provisioning and orchestration. For more information see the IBM Redbooks Exploring Storage Management Efficiencies and Provisioning - Understanding IBM TotalStorage Productivity Center and IBM TotalStorage Productivity Center with Advanced Provisioning, SG24-6373, and Provisioning On Demand Introducing IBM Tivoli Intelligent ThinkDynamic Orchestrator, SG24-8888. To illustrate the power of automated storage provisioning, an example of a storage provisioning solution written to manage an IBM TotalStorage SAN File System is used. This shows how automated storage provisioning can simplify tasks, eliminate the chance of human error, and reduce the time taken to provision servers with SAN attached storage.
1.1 Problems caused by human error

During December 2004, a large European commercial bank suffered two major server outages during their busiest pre Christmas trading period due to human error while configuring storage capacity. The problem was traced back to the banks documented practices around configuring storage devices not being followed by an administrator. Had the documented practices been followed while configuring the additional storage capacity, the failures would not have occurred. SAN storage environments are complex and require many skills and a good understanding of the task being performed. Many storage arrays have limitations around the number of hosts per adapter or LUNs per adapter. Additionally there are accepted rules around SAN zoning of not mixing UNIX and Windows hosts in the same zones. As a consequence, over a number of years, many organizations have developed policies and best practices that have been adopted to avoid misconfiguration of storage subsystems and storage networks. These should ensure that environments are configured correctly and avoid problems, but the occasional human error can still occur. In addition, manual storage provisioning can introduce undesirable delays and corresponding dropoffs in service. The typical storage administrator has many demands on their time and may not be able to immediately respond to an urgent (in the perspective of the client) storage provisioning request. Automated storage provisioning addresses these issues by enabling best practices to be implemented through the idea of storage workflows. Workflows are reusable elements that capture IT expert know-how, and represent the steps that must be followed in order to carry out a particular operation. These are repeatable and eliminate the human element of the process. This removes the possibility for error and allows for prompt and reliable execution, as the workflows will consistently implement the rules and policies time after time.
1.2 Storage provisioning

Storage provisioning is the name given to all the tasks around the configuration of storage, performed manually or via automation, as discussed here. Typically, storage provisioning of SAN attached storage involves administrators in a significant number of relatively complex tasks with little support from the devices and individual management tools. The assumption is that the administrators are trained in each device and understand how to configure it. Also, each storage device is configured in isolation, and several interfaces must be used to perform the end-to-end task of, for example, adding a new file system on SAN attached storage to a host. The three areas of servers, SAN switches, and subsystems that must be configured and the generic tasks that have to be performed are shown in Figure 1-1 on page 3.
Server requiring SAN attached storage

Volume Manager And File system updates
Host OS LUN mapping updates
SAN SAN
SAN Zone configuration change
LUN masking assignments for volumes

SAN Volume Controller volumes
Figure 1-1 Storage provisioning tasks
The following list gives more details on the tasks that a storage administrator might have to perform to add additional storage: Add a volume (storage subsystem). Select storage subsystem. Select or create new volume. Select host HBA ports (WWNs). Select subsystem controller ports (WWNs). Map volume to controller ports. Map volume to host HBA ports. Determine if multiple paths are required. Create or update zones. Get active zone set. Add zone to zone set. Activate zone set.
Set paths (SAN fabric switches).
Set up replication (if necessary). Map the HBA LUNs to the operating system and file system. Update volume group and file system (host server). Add physical volume to volume group. Add physical volume to logical volume. Create or extend file system. Extend application to use additional space. Reconfigure backup. As well as the task itself, input values are needed, which require a detailed knowledge of the storage environment, such as the WWNs of HBAs in the hosts and subsystems, existing zones, etc. Reference to additional tools or documentation detailing the last known
Chapter 1. An introduction to storage provisioning
configuration of the environment might be necessary to determine these values. Best practice rules for maintaining the environment must be applied consistently; this is complex and requires a significant amount of skill to ensure any documentation of the environment is kept up to date. On the positive side, each of these tasks is well defined and usually can be quite simply automated through scripting. However, scripting the end-to-end operation is barely feasible due to the number of input values and the number of tasks. Also, the script would be host, switch, and subsystem specific, requiring rewrites if changes occur in the environment, and also requiring different scripts for each variation. A solution to this problem is to automate the process using workflow automation.
1.2.1 Automating complex tasks with Tivoli Provisioning Manager

IBM Tivoli Provisioning Manager (TPM) provides an environment on which IT tasks can be automated, such as the provisioning and configuring of servers, operating systems, middleware, applications, storage, and network devices. This is an end-to-end approach to provisioning. When a server is installed in a data center, applications must be installed on it, along with its required network connectivity to access other resources, as well as the storage the applications will use. This comprehensive approach to provisioning is shown in Figure 1-2.
Applications Security Middleware
Attach Storage
Operating Systems Hardware Layer
Configure Networking
Server Provisioning
Management Applications Virtualization Storage Devices Fabric Security Management Applications Security Virtualization
Fabric / Network
Routers, Switches, etc. Protocols
Storage Provisioning
Network Provisioning
Figure 1-2 End-to-end provisioning
This ability to perform and coordinate provisioning tasks across a range of components and management disciplines makes TPM an ideal automation tool for performing file system and volume management tasks and for the provisioning of SAN attached storage in general. A clear benefit of using TPM to provision storage is that these tasks can be incorporated into the wider server and application provisioning scenarios, significantly reducing the time and administrative effort in delivering new applications and servers. TPMs storage provisioning capabilities utilize its workflow engine to automate and manage the tasks associated with configuring storage. Provisioning of Network File System (NFS),
direct attached, and SAN attached storage is supported, along with management of volume managers and file systems.
1.2.2 Tivoli Provisioning Manager and TotalStorage Productivity Center

Although TPM provides storage provisioning capabilities, it is not a storage management solution. The IBM solution for storage management is IBM TotalStorage Productivity Center (TPC), which is a comprehensive storage infrastructure management solution. TPC provides heterogeneous device, fabric, and data management and reporting capabilities with additional storage provisioning capabilities. These additional capabilities are provided by combining TPM and TPC into a complete storage management and provisioning solution, usually refered to as TPC with Advanced Provisioning. Table 1-1 shows the different roles in which TPM and TPC might be used.
Table 1-1 Comparison of TPM and TPC Attribute Product description Tivoli Provisioning Manager Data center solution with automated storage provisioning capabilities. Release Managementb. Server administrator (typically) deploying a new server. BasicTPM automation packages (workflows) comprise a tool kit that can be customized to meet client requirements. Interfaces directly to supported storage (Cisco, Brocade, McData) using CLIs. TotalStorage Productivity Center Complete storage management solution with additional automated storage provisioning capabilities (through TPM) Availability Managementc Capacity Managementd Data center storage administrator Advancedcomplete, comprehensive out-of-the-box solution for storage management Exploits multiple standards-based interfaces to provide comprehensive management (reporting and control) across many vendors Heterogeneoussupports multiple devices and vendors
Positioning (ITILa) User Device management
Device interfaces
Platform support
Limited to only platforms supported with TPM automation packages.
a. IT Infrastructure Library: A process-based methodology that is used by IT departments to ensure that they can deliver IT services to end users in a controlled and disciplined way. b. Release Management: The process of managing the rollout of new applications, servers, and infrastructure. c. Availability Management: Includes planning, implementation, management, and optimization of IT services so that they can be used where and when the business requires. d. Ensures that sufficient IT infrastructure resources are available cost-effectively when needed.
TPM and TPC are targeted at different user groups within the data center. TPMs audience is IT infrastructure and server administrators who need to manage the roll-out of new applications, servers, and infrastructure. TPC is aimed at storage administrators who manage storage capacity. In their own areas they deliver best-of-breed functionality, integrating into a single solution that addresses a broad range of management requirements while retaining their own unique differentiating features. TPM is a comprehensive storage provisioning solution, providing the infrastructure and facilities to provision storage capacity. However, its out-of-the-box device and platform support is limited in comparison with TPC. TPC extends TPMs storage provisioning capabilities to provide broad standards-based device support, with a richer set of device
Chapter 1. An introduction to storage provisioning
management capabilities and with the potential to make intelligent choices based on other metrics such as subsystem and fabric performance. These differences become more significant with the introduction of new storage arrays such as the IBM TotalStorage DS6000 and DS8000, where there is much greater choice over volume selection criteria, including RAID array sizes, underlying disk volume sizes, etc. Later in this paper the use of TPC to enhance the basic device management capabilities of TPM is looked at in more detail.
Chapter 2.
Tivoli Provisioning Manager support for storage provisioning

The use of TPM for server and application provisioning is dealt with in detail in other documents and its functionality will only be looked at briefly here. Our focus is on storage provisioning, and only the elements relevant to this are covered. TPM supports the provisioning of storage in a number of ways: Via its representation of the storage environment, its storage-related device operations, the use of templates to provide a policy-based approach to provisioning, and its administrative interface for provisioning storage. Representing the data centers resources and assets in TPM as an environment model is the first step towards automation of the environment using workflows and device operations. The environment model and device operations work together to enable TPM to manage all aspects of a data center IT environment from servers and networks, to firewalls and storage. An example of a simple physical storage environment represented in TPM is shown in Figure 2-1 on page 8.
Figure 2-1 View of a simple storage environment on TPM
This figure shows the physical connections from a number of storage hosts via a Cisco 9509 switch to an IBM TotalStorage SAN Volume Controller (SVC). The model is a direct representation of the physical environment, which is kept in synchronization with the real environment. Some benefits of this approach are that it allows TPM to track the usage state of resources and determine whether resources are reserved to meet future requirements or currently available for use. It also allows the logical grouping of resources together into pools, enabling automation to select the most appropriate resource to fulfil a requirement. In a later section we show how TPC can be used to automatically populate the TPM model with storage information.
2.1 Data center model

Representing the physical data center environment as a model within TPM enables it to manage different types of devices from many vendors by abstracting the physical devices, assets, and resources in the data center into generic classes of devices. The resulting data center model (DCM) contains all the assets and resources of the data center, both physical and logical, and their relationships and state. In TPM terminology these are logical devices, which it understands how to manipulate. The IBM TotalStorage SAN Volume Controller (SVC) and IBM TotalStorage Enterprise Storage Server (ESS) are examples of storage subsystems, of which the logical device in TPM is a storage subsystem. Operations are performed against these logical devices (for example, a storage subsystem), and workflows are written to use logical devices and hence are device independent. The same workflows can be used against different devices of the same logical device type and do not require rewriting if the environment changes or contains more than one device type. Each device represented in the DCM is one of a number of logical device types modelled by TPM (for example, storage subsystems, routers, firewalls, etc.). Logical assets and resources comprised of a number of physical and logical components, such as monitoring applications and SAN fabrics, are also represented by logical devices. TPM defines four different logical device types for storage that represent the elements of a storage environment. There are three device types related to the elements of a storage environment that can be directly configured: SAN fabrics, storage subsystems, and host-based volume managers and file systems (in TPM terminology, storage managers). The fourth device type is a storage pool, which provides a logical grouping of storage subsystem volumes. These logical devices and their relationships to the physical environment are shown in Figure 2-2.
Storage environment
File system, Volume Manager
Storage Logical Devices

Storage Manager
SAN SAN
SAN Fabric, SAN switches, Connectivity Fibre Adapters
SAN Fabric
Storage Subsystem Storage Subsystem Volumes Storage Pool
Figure 2-2 TPM logical storage devices
Chapter 2. Tivoli Provisioning Manager support for storage provisioning
The storage pool logical device is a grouping of storage subsystem volumes from one or more subsystems. Rather than directing an operation to get a new storage volume at a single specific subsystem, the operation can be performed against a pool of pre-existing storage volumes from multiple subsystems. The use of pools also enables the concept of tiered storage to be modelled in TPM. The next section looks at how TPM uses these logical devices to manage real devices.
2.1.1 Logical operations

For each Logical Device type, TPM defines a number of Logical Device Operations (LDOs) that can be performed against that type of idealized device. Using an example of a Storage Subsystem, some of the defined operations are Create Storage Volume, Mask Volume to Host, and Remove Storage Volume. Associated with each device or resource modelled in the DCM by a logical device is a Device Driver, which is a package of workflows that implement the LDOs for a specific vendors device. Figure 2-3 shows the approach that TPM takes to supporting devices and resources through the use of logical devices, and how these translate to the device-specific operations.
Data Centre Model contains devices
Logical devices provide abstraction from physical devices - Storage Subsystem Logical Devices
Devices
Logical Operations are actions that can be executed on the logical device - Create Storage Volume - Remove Storage Volume Workflows deliver sequential transitions Transitions can be Java plugins, other workflows, simple commands etc.. Transitions
Workflow Simple Command
Logical Operations
Device Driver A device, represented by a logical device in the DCM is associated with a Device Driver to provide a set of capabilities
Workflows A package of workflows to implement Logical Operations for a device is a Device Driver - e.g. ESS Device Driver
Java Plugin
Figure 2-3 The TPM approach to device-specific support
Associated with TPMs representation of a physical device or resource in the DCM as a logical device is a Device Driver (also called a TPM automation package), which enables TPM to perform device-specific actions against the real device or resource. As in the figure, operations against an ESS storage subsystem represented as a logical device would execute ESS-specific workflows from the ESS Device Driver. The workflows themselves are comprised of transitions or steps. These can be other workflows, simple commands issued to a device, or a Java plug-in to call a device API. Figure 2-4 on page 11 represents how an LDO could be implemented and the flow.
10
Execute Logical Operation

Logical Operation Workflow Transition Transition Transition
Device Driver
Workflow Simple Command Transition Transition Logical Operation

Device Driver
Java PlugIn
Simple Command
Workflow
Transition
Transition
Java PlugIn
Data Centre
Simple Command
Figure 2-4 Logical Device Operation implementation
A combination of the operation being executed and the Device Driver associated with the logical device determines which device-specific workflow will be called to perform the operation. This then unfolds into transition steps. Conditional branching can occur depending on input parameters or information retrieved from the DCM about the environment. Actions on the physical devices are performed through Java plug-ins, which act on device APIs or simple commands executed on a host or a device using Telnet or SSH1. Interaction with devices is only handled through the device-specific workflows in the Device Driver or automation packages, which must be implemented for each specific device or OS platform that requires configuration in the storage environment. Interaction with a device is via any of the external interfaces it supports, such as an API or command line interface. At the host server, the Storage Manager LDOs provide support for configuration of the storage via volume managers and file systems. On the storage network, SAN Fabric LDOs manage the zone configuration to ensure secure access between the host and storage subsystem. At the subsystem, Storage Subsystem LDOs create new volumes and configure LUN masking to provide secure data access to storage volumes. Figure 2-5 on page 12 illustrates the implementation of the storage device drivers using command line interfaces.
SSH: Secure Shell, provides secure encrypted communications between two untrusted hosts over an insecure network
11
Logical Operation execution

File system And OS configuration Telnet/SSH
TPM Server
Device Drivers Workflows
TPM Storage Device Drivers
Zone Configuration Telnet
Simple Command
SAN SAN
Telnet/SSH Subsystem Configuration
Figure 2-5 TPM storage logical operation implementation
Changes made to the physical environment by the operations, such as the mapping of storage volumes to hosts, are reflected in the DCM to ensure that the DCM is an accurate representation of the physical environment for input to future operations.
2.1.2 Storage templates

TPM implements a policy-based approach to storage provisioning. Rather than specifying the input parameters to every operation, TPM uses templates of storage settings. Templates can be defined once, and each operation will take its input values from the currently selected template. Storage templates are specific to TPMs support for storage and are used to define the input parameters to the logical operations to perform operations against the physical storage environment. This is represented in Figure 2-6 on page 13.
12
Storage Template
Logical Operation
Environment information
Environment Changes Updates
SAN SAN
Physical Environment
Data Centre Model
Figure 2-6 Storage templates
Policy information from the storage template and environment information from the DCM is provided as input to operations. As changes are made to the physical environment, the environment model is updated by the operation to reflect the new state. Storage templates provide input parameters for all aspects of configuring storage for a host server. These extend from the file system type and mount point, through to the volume size on the subsystem and the adapter ports on the subsystem, through which a volume is accessible. Templates can specify input parameters down to the last detail, such as volume names and zone names, or it can be used to provide a template for a workflow to use as a starting point, combining it with information retrieved from the DCM about the devices being configured.
2.1.3 Administrative interface

To support the provisioning of storage capacity, the TPM user interface provides the ability to visualize the storage configuration and perform provisioning actions. The data center model is a live representation of the storage environment and can be visualized using the TPM inventory view. Information can be presented in two ways, either via a detailed tabular listing or a topology view. Users can initiate storage provisioning actions from these views. The detailed view of storage components shows HBA configuration, volumes, file systems, fibre connectivity, etc. The TPM inventory view, showing the detailed view of a server, is shown in Figure 2-7 on page 14.
13
Figure 2-7 TPM administrative interface showing a hosts storage resources
The TPM inventory view is selected in the left hand pane, using the View tab. This gives access to the inventory of all the devices represented in TPM. When a device is selected it is shown in the right-hand pane, in a number of formats. For storage there are two representations of the storage environment. The previous figure shows a detailed view, where all the device components are displayed along with detailed configuration information. Alternatively, there is a topology view or icon view, which shows the physical and logical associations between components. Figure 2-8 on page 15 shows the storage icon view for the same host server and its storage components, while Figure 2-1 on page 8 is an icon view of the SAN topology.
14
Figure 2-8 Host storage topology view
When using TPM, there are two ways of initiating storage provisioning actions. Actions can be initiated manually via the administrative interface by users, or initiated automatically as steps in server or application provisioning workflows. Individual granular provisioning steps or more complex end-to-end tasks can be initiated. Individual actions, such as masking a volume to a host, can be invoked from the inventory views of each device, or end-to-end storage provisioning actions can be initiated from the server inventory view, as shown in Figure 2-9.
Figure 2-9 TPM administrative interface showing storage provisioning operations
From a servers Edit menu tab, several storage provisioning actions can be initiated, as well as server provisioning tasks. These perform end-to-end provisioning tasks of adding and
15
removing storage to and from a host. The Add Storage Volume to Host performs all the tasks to make the volume visible at a host: Select a volume, mask it to a host, configure SAN zoning, and OS configuration. The Add Storage to Host extends this to configure volume managers and file systems to make the storage usable at the host without human intervention. The Remove Storage/Storage Volume tasks deconfigure the file systems and volume managers, and remove the storage. These end-to-end tasks are discussed in more detail later in the paper. Other storage provisioning tasks can be performed from the inventory views of servers, volumes, SAN fabrics, volume groups, and file systems.
2.2 Representing the storage environment on TPM

The four storage logical devices that enable a storage environment to be represented by TPM. These are: Storage Managers SAN Fabrics Storage Subsystems Storage Pools Using these four devices, the physical and logical components of a storage environment can be represented in the DCM, and hence managed by TPM. Figure 2-10 describes the relationship between the TPM storage devices and most of the physical and logical attributes of the storage components that are modelled by them. A small number of attributes are excluded to improve clarity. This model is very flexible for describing many variants of volume managers, file systems, and storage subsystems.
TPM Object
S1
Host Server Volume Containers Mount Points
VC1
VC2
Storage Manager
FS2 LV2 PV3 PV2
FS1 LV1 PV1
FS3 LV3 PV4
File systems Logical Volumes Physical Volumes
SAN Fabric
Connections SAN Switches Storage On Port
Storage Subsystem Storage Pool
SV3
SV2
SV1
SV4
Storage Volumes
Figure 2-10 TPM storage modelling using logical devices
The storage model is used to represent the current state of the real data center environment within TPM. TPM can use this information directly without having to query the environment 16
every time to understand what resources are available and the connectivity between components. As TPM operations make changes to the physical storage configuration and the use state of volumes (available, reserved, in-use), TPM updates its model to reflect the latest configuration. This saves TPM from having to query the environment each time it performs an operation. The storage devices defined to TPM are accessible via the TPM inventory view, under the Storage heading, as shown in Figure 2-11.
Figure 2-11 Storage logical devices in the TPM inventory view
This TPM inventory view in the above figure shows the expanded Storage heading, showing the four storage logical device types in the left-hand window pane, with the Storage Subsystems inventory view selected. To display the relevant devices defined to TPM, select the entry in the inventory view. This view also shows a fifth storage construct, Storage Templates, from where the inventory of Storage Templates can be listed. We will now look at each of the four logical devices in detail.
2.2.1 Representing Storage Managers in TPM

The Storage Manager logical device in TPM is used to model file systems and volume managers and their constituent components such as volume groups, logical volumes, physical volumes, and relationships on a host server. Figure 2-12 on page 18 shows a detailed view of the Storage Manager device.
17
TPM Object
S1 VC1 S3 S2
Host Server Volume Container Access Servers Mount Points
Storage Manager
FS2 LV2 PV3 PV2
File systems Logical Volumes Physical Volumes
Figure 2-12 Detailed view of the Storage Manager logical device
The Storage Manager represents both the file system manager and volume manager components on a host (these are not represented separately in TPM). Within the Storage Manager are defined the TPM Volume Containers; in a file system such as JFS on AIX, these are the Volume Groups. Within the Volume Container, the Physical Volumes are defined into that container (group) and the Logical Volumes built from the Physical Volumes using the volume manager software. Then the file systems are layered on top of the Logical Volumes by the file system software. The model also includes the concept of Access Servers. These allow TPM to represent other servers, which might also be configured for access to the same file system, and logical and physical volumes. This would be the case with clustered file systems or a file system configured for failover with MSCS on Windows or HACMP on AIX. Figure 2-13 shows the TPM inventory view of all the Storage Managers defined for servers managed by TPM. There is one entry here for each host with a volume manager/file system managed by TPM.
Figure 2-13 Storage Manager inventory view
The figure shows the volume group defined for this server, vg1. The name used for the Storage Manager definition on a server is the same for each host with the same type of file 18
system and volume manager, for example, AIX_LVM for all AIX hosts. This facilitates the use of Storage Templates to provide policy-based provisioning. When provisioning actions are performed, the Storage Manager name is used to select only the templates that are appropriate to a host and specify the same Storage Manager. Figure 2-14 shows the corresponding host view of a Storage Manager for host ibmp660-1.
Figure 2-14 Host view of a Storage Manager definition
Selecting a Storage Manager shows the volume containers (volume groups) defined under it, as in Figure 2-15.
Figure 2-15 Volume Containers defined under a Storage Manager
19
Under each Storage Manager is the list of Volume Containers (Volume Groups) that are managed by TPM. Drilling down into a Volume Container shows the Logical and Physical Volumes, and File Systems on the host server managed in this volume container. An example is shown in Figure 2-16.
Figure 2-16 Host view of a Volume Container
The Logical Volumes represented here are created by TPM logical operations against the Volume Manager on a host. Physical Volumes are created on a host when a storage volume is masked from the storage subsystem to the host server and the OS device mapping has been completed. The Physical Volume must be associated with a Volume Container before it is shown by TPM in the Volume Container (volume group), as in Figure 2-26 on page 27.
2.2.2 Representing SAN Fabrics in TPM

TPM provides comprehensive support for representing SAN fabrics. Each item in the SAN has effective coverage. The essential point is that this directly represents the physical environment and the fibre connectivity between hosts, storage devices, and SAN switches. The model is shown in Figure 2-17 on page 21. There are four physical elements: Servers, SAN switches, storage subsystems, and the connections between them. The logical configuration of zone sets and zones is also represented.
20
TPM Object Server
Interface Cards (HBAs) Ports Physical Connections ZoneSet Zones

WWNS 1 5 2 6 3 7 4 8
Ports Interface Cards SAN Switches SAN Fabrics SAN
SV3
SV2
SV1
Storage Subsystem
Figure 2-17 SAN Fabric model in TPM
The figure shows all the elements of TPMs SAN Fabric model with a single SAN containing two fabrics. The server and storage subsystem have ports connected to both fabrics in a dual path configuration.
Servers
Host Bus Adapters (HBAs) in a server are modelled as interface cards, with a number of ports. Figure 2-18 on page 22 is an example of the TPM representation of a host with one HBA with two ports. On a port, the WWN of the port is defined, along with its physical connection to a switch and any zones that the port is defined in. The information recorded about host SAN connectivity is essential for automatically performing SAN zoning operations, as it enables the SAN Fabrics the host is connected to, to be determined. Furthermore, it determines the SAN Fabrics at which zoning operations need to be directed for this host.
21
Figure 2-18 Host fibre adapters
Storage subsystems
SAN connectivity for storage subsystems is represented similarly to host servers with interface cards and ports. Figure 2-19 on page 23 shows an SVC with four HBAs connected to two Cisco 9509 switches.
22
Figure 2-19 Storage subsystem view, HBA definitions
Switches
To support modelling of different types of SAN switches, a switch contains a number of interface cards, with each card containing a number of ports. This enables TPM to model both switches with a fixed number of ports (single card), as well as director class switches, which have a number of card bays containing cards with varying numbers of ports. Figure 2-20 shows a typical SAN fabric defined in TPM. The core of this fabric is a Cisco 9509 director, with a Cisco 9140 edge switch.
Figure 2-20 SAN Fabric view of switches and storage subsystems
The left-hand pane shows that two fabrics were defined: Fabric1 and Fabric2. These represent the two fabrics that provide a fully redundant dual path configuration for disk access.
23
In the properties for Fabric1, the World Wide Name field is used by TPM to identify the principal switch in the fabric through which it will perform zoning operations. The same WWN must also be defined on the principal switch. This name is largely symbolic within TPMit is only used to locate the principal switch in the fabric through which zoning operations are performed, and does not have to be the real fabric WWN. A detailed view of a switch is shown in Figure 2-21its World Wide Name attribute being the same as for the SAN fabric.
Figure 2-21 SAN switch view
Back in Figure 2-20 on page 23, Active Zone Set is the name of the Active Zone Set in this fabric. With the TPM workflows for switch management from the Orchestration and Provisioning Automation Library (OPAL2), this is the Zone Set against which zoning actions are performed. When using TPC for switch management, TPC can automatically determine and update the currently active zoneset.
Visualizing SAN Fabric connectivity

As well as the detailed switch device views showing the switch ports, the overall fabric connectivity can be visualized. Select the View menu item to show the switch environment on a topology icon view, showing the connections between hosts, the switch, and connected subsystems. The icon view is shown in Figure 2-22 on page 25.
OPAL Web site: http://www.developer.ibm.com/tivoli/workflow.html
24
Figure 2-22 SAN switch icon view
The icon view is currently in effect, as this menu item is grayed out on the View tab. This shows all the hosts and storage devices connect to the switch 9509-1.
2.2.3 Representing Storage subsystems in TPM

Physical storage in storage arrays in TPM is represented by two logical devices: Storage Subsystems, and also a logical grouping of storage volumes by type and capability into Storage Pools. The two devices are shown in Figure 2-23.
Ports Interface Cards
Storage Subsystem Storage Pools
Storage On Port
SV3 Pool 1 SV2 SV1 Pool 2 Pool 3 SV5 SV6 SV7 SV4 SV4
Storage Volumes
Figure 2-23 Storage Subsystem and Storage Pool logical devices
Storage Subsystems
Storage Subsystems are modelled similarly to servers with interface cards and ports defining the HBAs on the subsystem. An example is shown in Figure 2-24 on page 26.
25
Figure 2-24 A Storage Subsystem represented in TPM
The volumes created on the subsystem are shown. Within TPM these are known as Storage Volumes. When a volume is mapped to a host port, this association is represented in the Fibre Channel Port field. Some array types require that storage volumes are mapped to specific adapters on the subsystem for access by host servers. This mapping is known as the Fibre Adapter Port mapping (sometimes abbreviated to FA Port in TPM). The TPM terminology for this is Storage On Port and is used to support arrays that map volumes to specific subsystem adapters (for example, EMC and HP arrays). During workflow execution, this mapping can be used to determine which subsystem adapter should be zoned to a host to give it access to a storage volume. This mapping is also represented in this view by an entry in the Fibre Channel Port field. This is not shown in the figure, as the array represented does not require it. In the figure, there is a field for the ANSI T10 ID. This can be used to uniquely identify a storage subsystem. T10 is the definition of the SCSI standard by the America National Standards Institute (ANSI) and is the serial number of the storage subsystem. Specification of this is not required in TPM.
Storage Pools
Storage Pools are used to group volumes of a similar type, that is, all RAID5 volumes, or all RAID1 volumes or pools of tiered storage. The use of pools makes it easier to select volumes of a particular type without having to specify all the detailed parameters such as RAID level or volume type. Another use for storage pools is to implement the concept of volume reservation. When there is a known future requirement for significant quantities of storage, the volumes could be temporarily allocated to a reservation pool or pools until they are required. When a volume is created in TPM on the storage subsystem, it can also be assigned to a storage pool. Alternatively, if volumes on the storage subsystem are pre-created outside of TPM, they can be defined into the pools to make volume selection a simpler task in a workflow.
26
Storage Pools in TPM can also be referred to as Storage Allocation Pools. Similarly, the volumes within a pool are sometimes referred to as Storage Allocation Pool Elements (SAPEs). The TPM Storage Pool inventory list is shown in Figure 2-25. In this example the pool names used are the SVC managed disk group names. The naming convention includes the RAID level and the volume size of the managed disks.
Figure 2-25 Storage Pool inventory
Figure 2-26 shows a list of volumes in Storage Pool F1_36_R5. A volumes capabilities are also shown, indicating RAID level and the subsystem it exists in. The State/Assignment field indicates if a volume is Available for use, In Use (mapped to a host), Assigned (LUN masked to a host, but not yet mapped), Reserved (being used by an executing workflow), or Unknown. The use of volume states helps to determine the availability of volumes to satisfy requests for additional volumes.
Figure 2-26 Volumes in a Storage Pool
The pool name reflects the type of disk storage in the pool; as this is a pool of SVC volumes, the name reflects that the backing storage is 36-GB volumes in a RAID 5 configuration.
2.3 Specifying a servers storage needs

TPM uses a policy-based approach to storage provisioning. Instead of an administrator specifying the input parameters to every operation, TPM uses Storage Templates that can be reused. A single template can be defined for a group of application servers and the same storage configuration will automatically be used for each server. This approach of using templates ensures that a consistent naming convention is enforced and that all server components of an application are configured the same.
27
Within a storage template TPM implements settings for: Volume Containers (Volume Group) Physical Volumes Disk Partitions Logical Volumes File Systems File System Mount Points Data Paths Multipath Software The settings are used as input to the Logical Device Operations and the workflows that implement them. Though the settings define values, the workflow implementations are free to use the values passed, modify them, or determine their own based on best practices coded into the workflows. A typical usage might be to pass the prefix for a SAN fabric zone name, and the workflow determines the unique full name of the zone based on the host being zoned and the prefix. Figure 2-27 is an example of the different storage settings that can be specified.
Figure 2-27 An example storage template
The logical and physical volume names to be used and the volume sizes and types can be defined. Using templates in this fashion ensures that all servers added to the cluster are configured by TPM with the same storage configuration. Settings form a hierarchical structure under the Volume Container settings, dividing into settings related to the physical storage and the logical storage environments. Physical environment settings, including volume size, type, and storage subsystem are grouped under the Physical Volume settings. Logical storage settings, such as file system type, capacity, and block sizes are grouped under the Logical Volume settings. We will look at each of these settings in more detail.
2.3.1 Volume Container Settings

The Volume Container settings are used as a template to create new Volume Containers (Volume Groups) for servers in the application cluster. An example is shown in Figure 2-28 on page 29.
28
Figure 2-28 Volume Container Settings
The Storage Manager field in the Volume Container settings defines which Storage Managers the volume container is eligible to be created under, and hence which hosts this template can be used on, based on a hosts Storage Manager definition. The field also defines the Physical Partition size to be used by the volume manager for the volumes. The settings for the Physical and Logical Volumes, and File Systems that will be created within the container are under each Volume Container Settings object.
2.3.2 Logical Volume Settings

The Logical Volume Settings are provided as input for the volume manager on the host to create new logical volumes. An example is shown in Figure 2-29.
Figure 2-29 Logical Volume Settings
29
At a logical level, these define how the volume manager will configure and carve up physical volumes to make logical volumes. If the volume manager supports capabilities such as software RAID, they can be specified here, though typically the volume type is more likely to be of type simple or spanned. Simple implies that the logical volume exists on a single physical volume only and spanned that it is made up of one or more physical volumes.
2.3.3 Disk Partition Settings

Disk partition settings, shown in Figure 2-30, are used to make the association between a physical volume and the logical volumes that will be created on it. They also define how physical volumes can be partitioned into smaller volumes for Intel-based servers.
Figure 2-30 Disk Partition Settings
2.3.4 File System Settings

File system settings determine the type of file system to be created. Figure 2-31 on page 31 shows an example.
30
Figure 2-31 File System Settings
All the required attributes of the file system are defined here.
2.3.5 File system mount settings

File system mount settings, shown in Figure 2-32, determine where the created file system will be mounted.
Figure 2-32 File system mount settings
31
2.3.6 Physical Volume Settings

The physical volume settings are used by the Storage Subsystem and Storage Pool logical operations as a template to select or create new Storage Volumes on a subsystem or in a storage pool. An example is shown in Figure 2-33.
Figure 2-33 Physical Volume Settings
These policy parameters allow TPM to automatically select a volume from a storage pool, or create a new volume on a subsystem meeting the specified RAID Level, Function Type, and Consumable (minimum) size requirements. The Function Type is used for subsystems where volumes are predefined and their usage is configured, such as EMC BCVs (Business Continuance Volumes). The consumable size is the smallest size of volume that TPM will use. When a volume is required it will either create a volume of the requested size or select the smallest existing volume larger than the consumable size, which has the correct attributes.
2.3.7 Multipath settings

The multipath settings enable use of the powerful concept of datapaths. These define the explicit routes or paths between a hosts ports and a storage subsystems ports in the SAN fabric. The settings contain all the attributes that allow zoning to be automatically set up between a host and the storage subsystem, providing secure storage access. Figure 2-34 on page 33 shows an example of multipath settings.
32
Figure 2-34 Multipath settings
When fully specified, multipath settings can be used to determine the LUN ID at the host, the zone t be used, and the subsystem fibre ports and the host HBA ports to be included in the zone. All parameters relating to connectivity between the host and the storage subsystem are defined in one place, taking an end-to-end view of this operation, rather than looking at it from the perspective of each device that needs configuring (that is, the hosts, SAN switch, and storage subsystem). The parameters passed can be used directly by the zoning workflows, or if a workflow determines, more appropriate values can take precedence.
2.4 Storage Operations

As well as modelling the storage environment and a servers storage needs, TPM implements a set of storage-related Logical Device Operations, which act on the physical storage environment and update the model within TPM to reflect these changes. These operations are grouped by the Logical Device type they operate on: Storage Manager Add/remove file system, logical volume, physical volume, volume container. Storage Subsystem Create/delete storage volume, mask/unmask storage volume.
33
Storage Pool Create/delete storage volume in pool, mask/unmask storage volume. SAN Switch Create/delete zone, add/remove WWN/Port To/from Zone. Operating System Create physical disk, create SAN disk, delete physical disk. Before these operations can be used, the device drivers or automation packages that implement them have to be created for the specific switch, subsystem, volume manager, and file system. A number of examples of TPM and TPC device drivers that implement these operations for different platforms, switches, and storage subsystems can be found on OPAL. Most operations are extremely granular and perform only a single specific task, such as creating a storage volume or adding a SAN zone member. Usable workflows are then built up from these smaller building block elements. This provides great flexibility and enables TPM to be customized to meet a wide variety of requirements, and implement the best practices related to specific environments; however, building a storage provisioning solution from scratch using just these basic building blocks would be extremely time consuming. In addition to providing the basic building blocks, TPM also provides operations that represent end-to-end storage provisioning tasks such as creating file systems from scratch, adding volumes to hosts, and extending file systems. These encapsulate all the sub-operations required to perform the request task, such as creating a volume, then mapping it to the host, and finally creating a file system on the new volume. These operations also exploit the Storage Template approach to policy-based provisioning. The templates provide all the necessary parameters required to perform the end-to-end operations. An example of one of these operations is looked at in more detail later.
2.4.1 Storage Manager operations

Figure 2-35 on page 35 shows the Storage Manager operations that can be performed in TPM. These relate to file system and Volume Manager tasks. The function of most operations is evident from their names, although a few require further explanation.
34
Figure 2-35 Storage Manager operations
Most operations are extremely granular and perform only the single specific task as implied by the Logical Device Operations (LDOs) name. The AddStorageToHost and RemoveStorageFromHost operations are examples of more complex operations discussed previously, which can perform end-to-end configuration of storage to and from hosts. This includes zoning, creation of storage volumes on the subsystem, LUN masking, volume manager, and file system operations. An implementation of the AddStorageToHost operation is looked at in 2.4.6, End-to-end storage provisioning operations on page 38.
2.4.2 SAN Fabric operations

Figure 2-36 shows the SAN Fabric operations that can be performed in TPM.
Figure 2-36 SAN Fabric operations
These include creating and deleting new zones, and adding and removing members from zones. Here the capabilities of TPM as a provisioning tool are focusing on the routine
35
day-to-day tasks performed in a storage environment to provision storage. Tools such as TPC are required to provide in-depth management functionality.
2.4.3 Storage Pool operations

Storage Pools offer a way to pool storage capacity. This can be within a single storage subsystem or across several storage subsystems, and enables volume selection from any of the subsystems that have volumes in the pool. This enables volumes to be grouped by type, and also the creation of larger volume pools than would be possible by grouping volumes from a single storage subsystem. Storage Pools do not implement operations against specific volumes, such as masking and mapping, as these are performed on the subsystem where the volume resides. Supported operations relate to volume selection from the pool, and creation and deletion of volumes in the pool. These operations are interchangeable with the same Storage Subsystem operations. The three pool-specific operations are shown in Figure 2-37.
Figure 2-37 Storage Pool operations
The use of storage pools makes it easier to model tiered storage within TPM and also accommodate the concept of volume reservation for specific future requirements. The Storage Pool GetStorageVolumes LDO can search the entire pool for a volume meeting the requirements rather than a single subsystem, as is the case for the Storage Subsystem implementation of the GetStorageVolumes LDO. Once a volume has been created and selected, subsequent operations are performed by the Storage Subsystem LDOs.
2.4.4 Storage Subsystem operations

Figure 2-38 on page 37 shows the Storage Subsystem operations that can be performed in TPM.
36
Figure 2-38 Storage Subsystem operations
These operations include the same three operations supported for Storage Pools: GetStorageVolume, CreateStorageVolume, and RemoveStorageVolume, and they can be used interchangeably with the Storage Pool operations in workflows. The operations provide effective management of many types and vendors of storage subsystems, and include operations to support management of EMC arrays.
2.4.5 Operating system operations

In addition to the configuration of storage devices and file systems, a hosts' operating system must also be configured to recognize that new storage volumes have been mapped to it. Each operating system has its own methods and commands for discovering new devices and assigning device names. Operating System Logical Operations therefore provide TPM with the mechanism to support multiple OSs. The TPM operating system operations are shown in Figure 2-39.
Figure 2-39 Operating System operations
Three of these operations relate to storage: CreateDASDPhysicalVolume, CreateSANPhysicalVolume, and RemovePhysicalVolume. The first two relate to mapping of internal disk and SAN disk to OS device names, and the latter allows removal of either type of disk.
37
Where the OS supports it, implementation of these operations allows storage to be mapped to a host while the host is online, without requiring a reboot. This reduces the time taken to provision new storage and avoids having to schedule a system outage to attach additional storage capacity.
2.4.6 End-to-end storage provisioning operations

Most of the operations looked at so far can be considered as building blocks to create an end-to-end storage provisioning solution. TPM also provides a number of Storage Manager logical operations that allow workflows that implement end-to-end operations to be invoked. These are: AddStorageToHost RemoveStorageFromHost AddStorageVolumetoHost RemoveStorageVolumeFromHost ExtendFileSystem ExtendLogicalVolume These operations form the basis for a complete storage provisioning solution for standard file systems and devices. Alternatively, custom storage provisioning solutions can be developed using the building blocks provided by TPM. Chapter 5, A storage provisioning solution for SAN File System on page 61, presents a custom storage provisioning solution developed to manage an IBM TotalStorage SAN File System. As an example of a complete end-to-end provisioning task, Example 2-1 shows a simplified version of the AddStorageToHost operation.
Example 2-1 AddStorageToHost operation StorageManager.AddStorageToHost (xx) { StorageManager.createVolumeContainter (xx) StorageManager.addServerToVolumeContainer (xx) for each PhysicalVolumeSettings in VolumeContainerSettings { find MultiPathSettings find StorageSubsystem/StoragePool from MultiPathSettings StorageVolume = StorageSubsystem.getStorageVolume (xx) or StoragePool.getStorageVolume (xx) get MultiPathSettings install MultiPathSettings.software StorageManager.addStorageVolumeToHost (xx) { for each DathPathSettings in MultiPathSettings { find faPortId find hbaPortId by find fabricId find zoneSetId find zoneId if (zoneId = null) { fabric.createZone (fabricId, zoneName, cPortId[]) } StorageSubsystem.mapStorageVolumeToFA (xx) StorageSubsystem.lunMasking (xx) OperatingSystem.createSANPhysicalVolume (xx) } } for each PhysicalVolume { StorageManager.addPhysicalVolumeToVolumeContainer }
38
} for each LogicalVolumeSetting in VolumeContainerSettings { StorageManager.createLogicalVolume (xx) for each PhysicalVolume { StorageManager.addPVToLV (xx) } } } StorageManager.createFS (xx) }
The inputs to the workflow are the name of the server and the name of the storage template to be used to create the volumes and file systems. A key subcomponent of this workflow is the AddStorageVolumeToHost operation. This performs the volume-related tasks required, and the AddStoragetoHost operation wraps this around with the file system and volume manager tasks to create usable storage. After creating the Volume Group on the host and the corresponding Volume Container object in TPM, the Physical Volume Settings are used to determine the size and type of Storage Volumes required. The AddStorageVolumeToHost operation is invoked to perform all the tasks of creating and mapping the volume to the host. After creating the volume and mapping it to the host OS, the physical volumes, logical volumes, and file system are created.
39
40
Chapter 3.
Provisioning Storage with Tivoli Provisioning Manager

TPM provides a comprehensive environment within which users can provision storage. From a single point, storage resources managed by TPM can be viewed and configured. This is all controlled by role-based security, which provides a high level of control over what individual administrators can see and do. Users are also assisted in performing storage operations by a wizard-based approach to creating storage templates. These features are now looked at in more detail.
41
3.1 Storage visualization

From the TPM inventory view, a hosts storage resources can be visualized in two ways: Either as a detailed tabular style of storage components, or as a topology style icon view. Figure 3-1 is an example of the icon view of a host's storage assets.
Figure 3-1 Icon view of host storage assets
This figure shows the logical and physical storage resources for host ibmp660-1. A single HBA connects via two ports to port 2 on SAN switches 9509-1 and 9509-2. The physical volumes on the host as well as the storage volumes mapped to the host are shown. Note that, as the storage volumes are not explicitly mapped via an HBA on the subsystem, the connectivity to the switch is not shown. The logical associations between the Storage Volumes and Physical Volumes are also hidden in this view to improve clarity. Hover the mouse over a physical volume or storage volume to show the logical relationships between the resources, as shown in Figure 3-2 on page 43.
42
Figure 3-2 Host storage asset relationships
The dotted lines in this figure show that storage volume AIX_vol3 in storage subsystem SVC_TEC is mapped to HBA0:0 and HBA0:1 at the host, and is represented by physical volume pv03 at the host. Right-click a resource to give more options such as the ability to hide relationships or resources.
3.2 Performing storage operations

TPM can be used in a number of ways to provision storage: Provisioning actions can be initiated either automatically as part of a server and application provisioning action, or manually via the TPM user interface. Figure 3-3 on page 44 shows the provisioning actions that can be performed directly from the TPM server inventory view.
Chapter 3. Provisioning Storage with Tivoli Provisioning Manager
43
Figure 3-3 Host storage provisioning operations
The figure shows the four storage operations that can be initiated from the server view, with one highlighted. Two of these storage operations are looked at in detail here, Add Storage Volume To Host and Add Storage To Host. Both of these operations use storage templates as input. The Storage Manager task must be completed first to define the storage manager type for the server before storage can be managed for the first time.
3.2.1 Add Storage To Host operation

Figure 3-4 shows the initial dialog for the operation Add Storage To Host with a storage template selected. The eligible storage templates that can be selected to provide policy input are determined by the Storage Manager defined on the host server. Only templates with the same Storage Manager as the server are presented as options for input to the operation.
Figure 3-4 Add Storage To Host dialog window
44
In the figure, only one storage template has been defined for Storage Manager (AIX_LVM), and is presented in the dialog. Click OK to initiate the operation. Figure 3-5 shows the message indicating that the operation had been initiated.
Figure 3-5 Add Storage To Host execution window
The operation has been initiated as request 10331. The status of completed and executing workflows can be tracked from the Deployment Requests task in the TPM Configuration View, as shown in Figure 3-6.
Figure 3-6 Add Storage To Host deployment window
The operation has completed successfully. Search options can be specified to show the status of requests selected by status, name, time, or explicitly by deployment ID as shown here.
3.2.2 Add Storage Volume To Host operation

Figure 3-7 on page 46 shows the initial Add Storage Volume To Host dialog. As the operation only creates the physical storage elements and not Logical Volume Manager or file system entities, the settings from any storage template definition for any Storage Manager can be used. As only a subset of a storage template settings are required to create a new volume, the individual settings to be used from the template can be selected.
45
Figure 3-7 Add Storage Volume To Host dialog window
Having specified the Storage Manager, the Volume Container Settings and Physical Volume Settings in the templates determine the volume characteristics required. Eligible Storage Subsystems and Volumes meeting these characteristics are presented and a volume selected. Checking the execution status is the same as for the Add Storage To Host operation.
3.2.3 Implicit execution

If storage operations are initiated from server or application provisioning workflows, an administrator cannot explicitly specify the storage templatethe storage template to be used is determined implicitly. Each server application group can have a Server Template, which defines the default storage template for a server. A Server Template is shown in Figure 3-8 on page 47.
46
Figure 3-8 Server template
The figure shows a server template with an associated storage template defined. Server templates can be assigned to resource pools, application tiers, and individual systems in TPM. They can be created using the Server Template heading via the TPM Application View as in the previous figure. Figure 3-9 shows a server inventory view; the server template associated with the server can be seen on the right-hand side of the server properties.
Figure 3-9 Server template associations
3.3 Creating storage templates

To guide users in creating new storage templates, TPM uses a wizard-based approach to prompt for the correct values. From the TPM Tasks view, as shown in Figure 3-10 on page 48, select the Create Storage Template task under the Storage Management heading. In step 1, specify a name for the storage template.
47
Figure 3-10 Storage template wizard step 1
In step 2 (Figure 3-11) enter the Volume Container settings. One or more sets of settings can be created.
In step 3 (Figure 3-12 on page 49) define the Physical Volume settings. One or more sets of settings can be created.
48
DASD settings relate to internal disks internal in the server. SAN settings relate to externally attached storage, typically SAN attached. In step 4 (Figure 3-13 on page 50) enter the Datapath/Multipath settings. One or more sets of settings can be created.Typically there will be two datapath settings, one for each fabric the server is connected to.
49
In step 5 (Figure 3-14 on page 51) enter the Logical Volume settings. One or more sets of settings can be created.
50
In step 6 (Figure 3-15 on page 52) enter the File System settings. One or more sets of settings can be created for each Logical Volume.
51
In step 7 (Figure 3-16 on page 53) enter the File System Mount settings for each file system.
52
In step 8 (Figure 3-17 on page 54) enter the Partition settings if required.
53
Step 8 (Figure 3-18 on page 55) is a summary of all the settings configured and enables them to be modified before completion. Click Finish to save the new storage template.
54
3.4 Controlling user access

TPM provides the ability to tightly control what an administrator can see and do, using security roles and access permissions. Figure 3-19 on page 56 shows the default security roles defined in TPM and the default rights of a Storage Operator.
55
Figure 3-19 TPM storage operator permissions
Access to individual views as well as individual devices within a view can be controlled. From a storage provisioning perspective this enables all the various tasks and views related to server and application provisioning to be removed from the storage administrators sight. Application administrators could also be given the ability to provision additional storage related to only the applications they are responsible for.
56
Chapter 4.
TotalStorage Productivity Center with Advanced Provisioning

As discussed earlier, while TPM provides storage provisioning capabilities, it is not a storage infrastructure management tool. The IBM solution for enterprise storage management is IBM TotalStorage Productivity Center (TPC), which is a comprehensive integrated storage management solution. Though TPM can be used by itself to provision storage, when combined with TPC it provides a complete storage management and provisioning solution. Additionally, using TPC and TPM together provides an enhanced storage provisioning capability through TPC's broader device support and richer device management features. The additional benefit of using TPC for device management over direct management from TPM is likely to increase when devices such as the IBM TotalStorage DS6000 and DS8000 are being used. TPC is in a position to exploit the unique differentiating features of these devices and in the future use other volume selection criteria such as actual measured volume performance via its performance reporting features.
57
4.1 Value of TotalStorage Productivity Center with TPM

By itself TPM provides a comprehensive workflow provisioning and management environment for storage. The TotalStorage Productivity Center components, TPC for Disk, and TPC for Fabric complement these capabilities to provide a complete solution. Table 4-1 illustrates the additional benefits that the complete solution provides.
Table 4-1 TPC versus TPM capabilities Capability Population of TPM Data Center Model with information about storage environment, storage devices, switches, zones, HBAs, and connectivity Management of drift between modelled environment and physical environment Disk subsystem support TPM TPC with TPM
Manual. Must be manually

determined and entered by hand.
Automated through discovery

and population through use of TPC for Fabric and TPC for Disk discovery capabilities
Manual. Changes that are

performed outside of TPM must be updated in the DCM manually.
Automated through TPC for Disk

and Fabric. Best - Single device driver based on SMI-S open standards. TotalStorage, DS4x00, DS6000, DS8000, SVC and ESS Future any SMI-S compliant device
Good - Device driver required for each vendor and where model ranges use different interfaces. Drivers available for EMC and ESS.
Fabric switch support
Good - Cisco, Brocade, McData.
Best - Single device driver based

on ANSI mgmt interfaces. Brocade, Cisco, McData, Qlogic, and CNT
Time to provision Device operations
Good - Parsed response through command line. Good - Only TPM defined logical operations.
Best - Immediate response

through use of device APIs.
Best - TPM defined logical

operations and a rich set of Java plug-ins, which can exploit device-specific features through the SMI-S interface.
Some of these areas will now be looked at in more detail.
4.2 TotalStorage Productivity Center logical operations

TPC supports all of the storage logical operations as defined by TPM; however, it provides a richer set of device management features, which can be exploited by the workflows implementing these operations. These effect greater control over the storage environment and allow more intelligent selection of storage subsystems and volumes. Figure 4-1 on page 59 shows how TPC 2.1 integrates with TPM for device management.
58
Logical Operation execution
File system and Volume Manager configuration
TPM Server
Device Drivers Workflows
Zone Configuration API
SAN SAN
TPC Device Driver
Java PlugIn
API
TPC Server
API Subsystem Configuration
Figure 4-1 TPC usage with TPM
TPC-specific device drivers are used for all the storage devices represented by SAN Fabric, Storage Subsystem, and Storage Pool logical devices in the DCM. With TPM, the supplied device drivers talk directly to the devices concerned using CLIs, while with the TPC drivers, a Java plug-in is used to talk to the TPC for Disk and Fabric components over an API. This opens up all of the management capabilities of TPC for Disk and Fabric to be used by workflows, and enables all the devices supported by TPC for Disk and Fabric (disk arrays, SAN switches) to be controlled by TPM for provisioning storage. This greatly increases the number of storage subsystems that can be managed by TPM.
4.3 Storage configuration discovery

One of the most significant tasks when setting up a storage provisioning solution is the need to discover the existing environment configuration. With TPM this means populating the DCM with information about the existing storage configuration. The TPM GUI provides a mechanism to enter device and configuration information; however, this can be a somewhat long-winded task for a large environment. Alternatively, existing information can be represented in XML and imported. TPC provides a simpler and more dynamic solution by providing workflows to automatically populate the DCM from TPC with fabric and storage subsystem information. Both TPC for Disk and Fabric have automatic discovery mechanisms for determining the SAN fabric topology and storage subsystem configuration and storing this in their databases. The TPC-provided workflows can access these TPC databases via a set of Java plug-ins and automatically update the DCM with a complete view of the storage environment. This feature in its own right provides significant benefit to TPM and greatly simplifies the tasks of configuring TPM as a storage provisioning solution. It also complements the TPM built-in server and IP network auto discovery features.
Chapter 4. TotalStorage Productivity Center with Advanced Provisioning
59
4.4 Tracking environment changes

One of the challenges with any provisioning solution is to ensure that the model of the data center environment used to track resource configuration is kept in synchronization with the real state of the resources in the data center. Divergence between the model and the actual resources is termed configuration drift and occurs when administrators make manual changes to the environment that TPM is not aware of. The consequence of this is that discrepancies between the model and the real data center can result in workflow failures, as resources may not exist or be in the state that TPM expects them to be. The combined TPM and TPC solution provides an answer to this challenge. In addition to providing device configuration capabilities, the TPC componentsTPC for Fabric and TPC for Diskprovide near real-time tracking of storage device status and configuration. This provides a mechanism for the combined solution though which the DCM model can be automatically kept up to date in near real time. Without the use of TPC, changes have to be identified and then manually updated in the DCM.
60
Chapter 5.
A storage provisioning solution for SAN File System

This chapter looks at an example of a TPM-based storage provisioning solution written to manage an IBM TotalStorage SAN File System.
61
5.1 An on demand storage environment

To enable an IT server provider to provide on demand storage services, with pay-by-use charging and low administrative overhead, a solution based on the IBM TotalStorage SAN File System and Tivoli Provisioning Manager was developed and implemented. Key requirements specified for the storage environment by the provider were: Low administrative overhead and skill requirements Automated management Pooling and sharing of capacity between users Sharing of data between hosts Support for Web server orchestration Heterogeneous platform support The need was for a single storage infrastructure that would be managed simply, but also offer great flexibility and low costs. Flexibility and pooling of storage were delivered by deploying a SAN File System and IBM TotalStorage SAN Volume Controller (SVC). This provides a common infrastructure with a single set of management tools for a heterogeneous environment. Storage provisioning using IBM Tivoli Provisioning Manager (TPM) was implemented to automate and simplify management of SAN File Systems SAN infrastructure and support an orchestrated Web server environment. The use of provisioning reduced the need for key, scarce storage skills and delivering low management costs. Figure 5-1 shows a logical view of the solution, with applications sharing virtualized storage under control of the IBM orchestration and provisioning tools.
Applications
SFS shared file system
Orchestration and Provisioning CISCO MDS
Virtualised storage
Figure 5-1 On demand environment
The focus here is primarily on the storage provisioning solution developed for this environment. The SAN File System architecture provisioning approach described here is also applicable to other SAN File System environments, as the management tasks described are common to any environment. This provisioning solution is a specific example of the power of TPM to create a fully automated storage environment using storage provisioning.
62
5.2 The SAN File System solution

The SAN File System environment and the associated provisioning solution support two user communities: An on demand storage environment offering usage-based pricing and capacity on demand for traditional applications and servers. A fully orchestrated application environment. Server and application orchestration provides dynamic provisioning of IBM Sserver BladeCenter blade servers as application loads demand. This additionally exploits SAN File Systems data sharing capabilities for high-performance, scalable, and secure sharing of application and Web site file storage between servers in the application clusters. The use of a SAN File System enables the service provider to deliver competitively priced storage service offerings to all its clients though the use of pooled disk storage and low file system administration overheads. A key requirement was low management cost, and since SAN technologies were new to the service provider, management of the SAN infrastructure needed to be task-orientated by administrators not skilled in SAN or storage technologies. The storage provisioning solution based on TPM provided the ability to manage the environment simply by using a number of defined provisioning tasks, significantly reducing the need for skilled administrators.
5.2.1 SAN File System physical environment

Figure 5-2 shows the environment as deployed with fibre channel attached SAN File System clients sharing virtualized storage presented via an IBM TotalStorage SAN Volume Controller (SVC). The SAN fabric is CISCO MDS 9509 directors with 9140 edge switches. Disk storage is over 40TB of DS4300 with FC and SATA disk. Hosts are Intel HS20 blades in IBM BladeCenter racks running Microsoft Windows and RedHat Linux, as well as standalone HP Intel servers and Sun Solaris servers.
SAN FS clients IBM BladeCenter Management Infrastructure

Tivoli Enterprise Tivoli Provisioning Manager TotalStorage Productivity Centre for Fabric TotalStorage Productivity Centre for Data Tivoli Storage Manager
CISCO MDS
TotalStorage SAN File System
TotalStorage SAN Volume Controller TotalStorage 3584 Tape Library TotalStorage DS4300 Disk Array
Figure 5-2 Physical SAN File System environment
Chapter 5. A storage provisioning solution for SAN File System
63
5.2.2 Storage usage

The two user communities share the SAN File System environment. All users exploit the storage pooling and sharing of capacity managed through TPM.
Storage on demand environment

The on demand storage environment offers usage-based pricing and capacity on demand for traditional applications and servers. The different application user groups exist in different branches of the SAN File System file system structure, but share the same pools of SAN File System disk storage, as shown in Figure 5-3.
Apache
MS Exchange
MS SQL Server
MS IIS
User Groups
SAN FS shared file system
Shared capacity
SAN FS User Pool
Figure 5-3 Shared storage environment
The different user groups share the same SAN File System Pools, with all groups having access to the total pool capacity. Free space is aggregated across all the users of the pool and is available on demand for capacity growth. Users are only charged for their usage and not for unused space. The cost of providing the free space buffer is spread across all users by the cost model.
Orchestration environment
The orchestrated application environment offers dynamic provisioning of IBM Eserver BladeCenter blade servers as application loads demand using orchestration and provisioning. This is shown in Figure 5-4 on page 65.
64
En e r pr i s e C n. . . t o Ev en t G r ou ps O p t on s i
E nt er p r i se C on so l e S our ce G o up s r O pt o ns i H el p
Internet
D t ba se a a T v ol i Pl us i T vo i / en t r i lS y S yst em L og f e s il H p e l N um ber of M es sages U da t O p e N 2 2 2 2 2
Eve nt G r ou ps
Ev en t S ou r ce s
N two r s e k E v en t M e ss ag e Li st E ve nt Vi ew T asks Au t m a t d T asks o e
To ta l : 1 1
D t ab ase s a
FATA L
CRIC I AL T
MN R I O
W RIN A N G
H M SS AR LE
U K N WN N O
O PEN S er v c es i
AC O W KN LED G ED
C SE D LO
C as s l
Se ver i t y
O rg n i i 157. 83. 7. 33 2 157. 83. 7. 30 2 157. 83. 7. 28 2
H o st N am e
M ess ag e
C SED LO C SED LO C SED LO C SED LO P rn t rs i e C SED LO C SED LO C SED LO C SED LO C SED LO O N PE A pp i ca t on s l i V i w M essages e
D B_Tabl e_Ful l D B_Tabl e_Ful l D B_Tabl e_Ful l D B_C apaci t y D B_C apaci t y D B_C apaci t y D B_C apaci t y D B_C apaci t y D B_C apaci t y D B_C apaci t y
FATA L FATA L FATA L C IIC L RT A C IIC L RT A C IIC L RT A C IIC L RT A C IIC L RT A C IIC L RT A W R I G A NN
D as al l London Aust n i
157. 83. 7. 34 2 157. 83. 7. 33 2 157. 83. 7. 35 2 157. 83. 7. 36 2 157. 83. 7. 37 2 157. 83. 7. 38 2 157. 83. 7. 39 2
Tokyo Sydney LA R O E Par s i D r ot et i H oust on
e i w
Ac t i n S o
a t t us
A c n o w l e d g e Me s a g e k
C ose M l essage
Hosted web site Application Cluster Web servers (Apache etc)
Load Balancer
Server orchestrated in
Server orchestrated out
SAN FS shared file system
Web site data on shared SAN FS storage
SAN FS User Pool
Figure 5-4 Orchestrated Web serving using SAN File System
This exploits SAN File Systems data sharing capabilities, to share a single copy of Web site data between multiple Web servers. As load increases on the Web site due to increased user activity, additional servers are provisioned into the application cluster, spreading the workload evenly across the new larger pool of servers. SAN File System provides for high-performance, scalable, and secure sharing of the application and Web site file storage between servers in the application clusters. The ability of the storage provisioning solution to automatically add new SAN File System clients on demand without manual intervention is essential to the ability to rapidly orchestrate in new Web servers as utilization levels change. The new servers connect into and share the existing single copy of the Web site data in the SAN File System environment.
5.3 Storage provisioning to simplify volume management

A SAN File System solution reduces and simplifies volume management tasks compared to traditional file systems, as there are typically far fewer LUNs to manage. Provisioning can further simplify administration by automating the remaining volume management tasks required to add new clients or capacity. Another benefit is that administrators do not require substantial SAN administration skills, which are scarce. Volume management tasks for a SAN File System are only needed when new client servers are added or additional storage capacity is required. The volume management tasks associated with configuring SAN-attached storage in a SAN File System environment are similar to those for server-centric file systems, including the Linux extended file system V3 (EXT3), windows NTFS, and the AIX journaled file system (JFS). Compared to these server-centric file systems, these tasks are performed much less frequently, typically only when all free space in a pool has been exhausted. Tasks include: Loading and configuring the host bus adapter (HBA) driver Loading and configuring multipathing software, such as IBM Subsystem Device Driver Zoning the SAN Masking the storage subsystem LUNs
65
Figure 5-5 illustrates the actions automated by the storage provisioning solution.
Existing SAN FS clients
New SAN FS client being added to environment Host OS device mapping updates to realise new volumes at host
SAN FS User Pool
SAN SAN
SAN Zone configuration change to include new server Update LUN masking assignments for all volumes in SAN-FS user pool to allow access from new server
SAN Volume Controller Volumes
Figure 5-5 Provisioning tasks to introduce a new SAN File System client
When an administrator wants to add a new SAN File System client, the SAN zoning must be updated to enable the new host to see the storage subsystem, by adding it to existing zones or creating new zones. The subsystem LUN masking assignments for all the volumes in the SFS user pool must be updated to enable the new client to see the subsystem volumes. Finally, the HBA driver and multi-pathing software at the host must be reconfigured to map the LUNs presented from the storage subsystem to the operating system and the SAN File System client as physical disks. While relatively simple for an administrator to perform, these tasks have to be carried out for each volume in a SAN File System User Pool as new clients are added or for each server using the pool when a new volume is added to the pool. The tasks also require coordination to ensure successful execution and to guarantee that prerequisite tasks have been completed. These SAN File System management tasks are ideal candidates for automation using provisioning workflows, reducing administrative effort for day-to-day operation of a SAN environment.
5.3.1 SAN File System automation tasks

These are the principal automated tasks that were created to configure and manage the SAN File System environment: Addition and removal of SAN File System clients Creation and deletion of SAN File System storage pools Creation and deletion of SAN File System filesets Addition and removal of client access to storage pools Addition and removal of space in SAN File System storage pools Performing these tasks by hand for a large environment could require a significant amount of effort and has a high potential for human error. Instead, the SAN File System combined with provisioning software enables the management tasks to be broken into repeatable steps, automated through workflows. This helps reduce human error and simplifies the tasks of 66
administrators so that they do not need specialized skills to perform complex SAN administrative tasks.
SAN File System workflows

Several workflows are used to manage the SAN File System environment and simplify administration. These coordinate the configuration of the several infrastructure components. The six basic SFS management workflows are: Add and remove hosts. SFS_AddHostToSFSPool SFS_RemoveHostFromSFSPool Add and remove pools. SFS_CreateSFSPool Create a new SFS user pool with no storage. SFS_DeleteSFSPool Delete an SFS User pool, removing all data. Add and remove storage space. SFS_AddSpaceToSFSPool SFS_RemoveVolumeFromPool Some of the other workflows that are involved in the basic management workflows are: SFS_CheckClientStatus Check to see if a SAN File System client is active and talking to an MDS cluster. SFS_RediscoverLuns Performs SFS LUN rediscover to find new volumes after pool changes. SFS_CheckVolumeStatus Performs SFS query to check status of SFS volume.
5.3.2 Modelling of SAN File System in TPM

Central to enabling easy management of the SAN File System environment is the ability to model the SAN File System configuration in the TPM DCM. Figure 5-6 on page 68 shows a SAN File System user pool managed by TPM.
67
Figure 5-6 SAN File System user pool managed by TPM
Within TPM the SAN File System user pool is represented by a TPM Volume Container. Servers that have been zoned and masked to be able to see the volumes in the pool are shown as access servers. The SAN File System volumes in the user pool are represented as TPM Logical Volumes. To simplify management and enable SAN File System resources to be easily tracked and identified, the volumes created on the SVC use the pool name as a prefix, for example, Webpool_1. Using the TPM DCM to model SAN File System in this fashion simplifies the task of management, as there is a ready list of servers that use and have access to the pool and the list of volumes in the pool. The server list is used as input to the AddSpaceToSFSPool workflow to determine which servers require the newly created volume to be masked to them. The volume list is used as input to the AddHostToSFSPool workflow, to determine the storage volumes that must be masked to the new SFS client so it can access the pool.
68
Back cover
An Introduction to Storage Provisioning

with Tivoli Provisioning Manager and TotalStorage Productivity Center
Automate provisioning of SAN File System Simplify infrastructure management Eliminate human errors
This IBM Redpaper is an introduction to storage provisioning and is written for anyone who needs to understand IBM automated storage provisioning tools. The IBM storage provisioning solution is based on Tivoli Provisioning Manager. This paper examines TPMs support for storage provisioning in detail and describe how it can be used standalone or combined with IBM TotalStorage Productivity Center to create a comprehensive storage management and provisioning solution. To illustrate the power of automated storage provisioning, an example of a storage provisioning solution written to manage an IBM TotalStorage SAN File System is used. This shows how automated storage provisioning can simplify tasks, eliminate the chance of human error, and reduce the time taken to provision servers with SAN attached storage.
Redpaper
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

An Introduction To Storage Provisioning With Tivoli Provisioning Manager and Total Storage Productivity Center Redp3900

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

An Introduction To Storage Provisioning With Tivoli Provisioning Manager and Total Storage Productivity Center Redp3900

Diunggah oleh

Hak Cipta:

Format Tersedia

Front cover

An Introduction to Storage Provisioning

Copyright IBM Corp. 2005. All rights reserved.

Copyright IBM Corp. 2005. All rights reserved.

An introduction to storage provisioning

Copyright IBM Corp. 2005. All rights reserved.

1.1 Problems caused by human error

1.2 Storage provisioning

Server requiring SAN attached storage

Host OS LUN mapping updates

SAN Zone configuration change

LUN masking assignments for volumes

Figure 1-1 Storage provisioning tasks

Set paths (SAN fabric switches).

1.2.1 Automating complex tasks with Tivoli Provisioning Manager

Applications Security Middleware

Operating Systems Hardware Layer

Routers, Switches, etc. Protocols

Figure 1-2 End-to-end provisioning

1.2.2 Tivoli Provisioning Manager and TotalStorage Productivity Center

Positioning (ITILa) User Device management

Limited to only platforms supported with TPM automation packages.

Chapter 1. An introduction to storage provisioning

Tivoli Provisioning Manager support for storage provisioning

Copyright IBM Corp. 2005. All rights reserved.

Figure 2-1 View of a simple storage environment on TPM

2.1 Data center model

Storage Logical Devices

SAN Fabric, SAN switches, Connectivity Fibre Adapters

Storage Subsystem Storage Subsystem Volumes Storage Pool

Figure 2-2 TPM logical storage devices

Chapter 2. Tivoli Provisioning Manager support for storage provisioning

2.1.1 Logical operations

Data Centre Model contains devices

Figure 2-3 The TPM approach to device-specific support

Execute Logical Operation

Workflow Simple Command Transition Transition Logical Operation

Figure 2-4 Logical Device Operation implementation

Chapter 2. Tivoli Provisioning Manager support for storage provisioning

Logical Operation execution

TPM Storage Device Drivers

Zone Configuration Telnet

Telnet/SSH Subsystem Configuration

Figure 2-5 TPM storage logical operation implementation

2.1.2 Storage templates

Environment Changes Updates

Data Centre Model

Figure 2-6 Storage templates

2.1.3 Administrative interface

Chapter 2. Tivoli Provisioning Manager support for storage provisioning

Figure 2-7 TPM administrative interface showing a hosts storage resources

Figure 2-8 Host storage topology view

Figure 2-9 TPM administrative interface showing storage provisioning operations

2.2 Representing the storage environment on TPM

Host Server Volume Containers Mount Points

FS2 LV2 PV3 PV2

FS1 LV1 PV1

FS3 LV3 PV4

File systems Logical Volumes Physical Volumes

Connections SAN Switches Storage On Port

Storage Subsystem Storage Pool

Figure 2-10 TPM storage modelling using logical devices