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

7/31/2019 An Introduction to Storage Provisioning With Tivoli Provisioning Manager and Total Storage Productivity Center Re

1/78ibm.com/redbooks

Redpaper

Front cover

An Introduction to Storage

Provisioningwith Tivoli Provisioning Managerand TotalStorage Productivity Center

Steve Stru

Automate provisioning of SAN FileSystem

Simplify infrastructure

management

Eliminate human errors
http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/


2/78


3/78

International Technical Support Organization

An Introduction to Storage Provisioning with TivoliProvisioning Manager and TotalStorage ProductivityCenter

July 2005


4/78

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.

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 number5765-FS2).

Note: Before using this information and the product it supports, read the information in Notices on page v.


5/78

Copyright IBM Corp. 2005. All rights reserved.iii

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Chapter 1. An introduction to storage provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Problems caused by human error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Storage provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Automating complex tasks with Tivoli Provisioning Manager . . . . . . . . . . . . . . . . . 4

1.2.2 Tivoli Provisioning Manager and TotalStorage Productivity Center . . . . . . . . . . . . 5

Chapter 2. Tivoli Provisioning Manager support for storage provisioning . . . . . . . . . . 72.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.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. . . . . . . . . . . . . . . 413.1 Storage visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 Performing storage operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.1 Add Storage To Host operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.2 Add Storage Volume To Host operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.3 Implicit execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3 Creating storage templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 Controlling user access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 4. TotalStorage Productivity Center with Advanced Provisioning . . . . . . . . . 574.1 Value of TotalStorage Productivity Center with TPM . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2 TotalStorage Productivity Center logical operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3 Storage configuration discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.4 Tracking environment changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60


6/78

iv An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center

Chapter 5. A storage provisioning solution for SAN File System . . . . . . . . . . . . . . . . 615.1 An on demand storage environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2 The SAN File System solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.1 SAN File System physical environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.2 Storage usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3 Storage provisioning to simplify volume management . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.1 SAN File System automation tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.3.2 Modelling of SAN File System in TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


7/78

Copyright IBM Corp. 2005. All rights reserved.v

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. Consultyour local IBM representative for information on the products and services currently available in your area. Anyreference 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 notinfringe any IBM intellectual property right may be used instead. However, it is the user's responsibility toevaluate 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. Thefurnishing of this document does not give you any license to these patents. You can send license inquiries, inwriting, to:IBM Director of Licensing, IBM Corporation, Nor th 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 areinconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION "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 ofexpress 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 madeto the information herein; these changes will be incorporated in new editions of the publication. IBM may makeimprovements and/or changes in the product(s) and/or the program(s) described in this publication at any timewithout notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials 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 incurringany obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirm theaccuracy of performance, compatibility or any other claims related to non-IBM products. Questions on thecapabilities 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 themas 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 businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:This information contains sample application programs in source language, which illustrates programmingtechniques on various operating platforms. You may copy, modify, and distribute these sample programs inany 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 sampleprograms 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, anddistribute 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.


8/78

vi An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center

Trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States,other countries, or both:

AIX

BladeCenter

Enterprise Storage ServerEserver

Eserver

HACMP

ibm.comIBM

Redbooks (logo)

Redbooks

TivoliTotalStorage

The following terms are trademarks of other companies:

Java and all Java-based trademarks and logos are trademarks or registered trademarks of SunMicrosystems, Inc. in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in theUnited States, other countries, or both.

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, othercountries, 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.


9/78

Copyright IBM Corp. 2005. All rights reserved.1

Chapter 1. An introduction to storage

provisioning

This paper is intended as an introduction to the subject of storage provisioning and is writtenfor anyone who needs to understand IBMs automated storage provisioning tools. IBM

storage provisioning solutions are based on Tivoli Provisioning Manager (TPM) and IBMTotalStorage Productivity Center (TPC). This paper examines TPMs support for storageprovisioning 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-depthintroduction to provisioning and orchestration. For more information see the IBM RedbooksExploring Storage Management Efficiencies and Provisioning - Understanding IBMTotalStorage Productivity Center and IBM TotalStorage Productivity Center with Advanced

Provisioning, SG24-6373, and Provisioning On Demand Introducing IBM Tivoli IntelligentThinkDynamic 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. Thisshows 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


10/78

2 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center

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 whileconfiguring 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, thefailures would not have occurred.

SAN storage environments are complex and require many skills and a good understanding ofthe 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 ofnot 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 havebeen adopted to avoid misconfiguration of storage subsystems and storage networks. Theseshould 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 andmay not be able to immediately respond to an urgent (in the perspective of the client) storageprovisioning request.

Automated storage provisioning addresses these issues by enabling best practices to be

implemented through the idea of storage workflows. Workflows are reusable elements thatcapture 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 theprocess. This removes the possibility for error and allows for prompt and reliable execution, asthe workflows will consistently implement the rules and policies time after time.

1.2 Storage provisioningStorage 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 ofSAN attached storage involves administrators in a significant number of relatively complextasks 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 ahost. 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.


11/78

Chapter 1. An introduction to storage provisioning3

Figure 1-1 Storage provisioning tasks

The following list gives more details on the tasks that a storage administrator might have toperform 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.

Set paths (SAN fabric switches).

Determine if multiple paths are required. Create or update zones. Get active zone set.

Add zone to zone set. Activate zone set.

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 thestorage 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

LUN masking assignments

for volumes

SAN Volume Controller

volumes

SANSAN SAN Zone configurationchange

Host OS LUN

mapping updates

Server requiring SAN

attached storage

Volume ManagerAnd File system

updates


12/78


configuration of the environment might be necessary to determine these values. Best practicerules 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 keptup to date.

On the positive side, each of these tasks is well defined and usually can be quite simplyautomated through scripting. However, scripting the end-to-end operation is barely feasibledue 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, andalso 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 beautomated, 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 inFigure 1-2.

Figure 1-2 End-to-end provisioning

This ability to perform and coordinate provisioning tasks across a range of components andmanagement disciplines makes TPM an ideal automation tool for performing file system andvolume 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 intothe 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),

Fabric / Network

ConfigureNetworking

Attach Storage

Server Provisioning

Middleware

OperatingSystems

Applications

HardwareLayer

Security

Storage Provisioning

Virtualization

StorageDevices

ManagementApplications

Fabric

Security

Network Provisioning

Virtualization

Routers,Switches, etc.

ManagementApplications

Protocols

Security


13/78

Chapter 1. An introduction to storage provisioning5

direct attached, and SAN attached storage is supported, along with management of volumemanagers 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 withadditional storage provisioning capabilities. These additional capabilities are provided bycombining 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 inwhich TPM and TPC might be used.

Table 1-1 Comparison of TPM and TPC

TPM and TPC are targeted at different user groups within the data center. TPMs audience isIT infrastructure and server administrators who need to manage the roll-out of new

applications, servers, and infrastructure. TPC is aimed at storage administrators who managestorage 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 retainingtheir 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 platformsupport 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

Attribute Tivoli Provisioning Manager TotalStorage Productivity Center

Product description Data center solution with

automated storage provisioning

capabilities.

Complete storage management

solution with additional automated

storage provisioning capabilities(through TPM)

Positioning (ITILa)

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.

Release Managementb.

b. Release Management: The process of managing the rollout of new applications, servers, and infrastructure.

Availability Managementc

Capacity Managementd

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.

User Server administrator (typically)

deploying a new server.

Data center storage administrator

Device management BasicTPM automation packages

(workflows) comprise a tool kit that

can be customized to meet client

requirements.

Advancedcomplete,

comprehensive out-of-the-box

solution for storage management

Device interfaces Interfaces directly to supported

storage (Cisco, Brocade, McData)using CLIs.

Exploits multiple standards-based

interfaces to providecomprehensive management

(reporting and control) across

many vendors

Platform support Limited to only platforms supported

with TPM automation packages.

Heterogeneoussupports multiple

devices and vendors


14/78


management capabilities and with the potential to make intelligent choices based on othermetrics such as subsystem and fabric performance. These differences become more

significant with the introduction of new storage arrays such as the IBM TotalStorage DS6000and 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 toenhance the basic device management capabilities of TPM is looked at in more detail.


15/78


Chapter 2. Tivoli Provisioning Manager

support for storage provisioning

The use of TPM for server and application provisioning is dealt with in detail in otherdocuments 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 thestorage environment, its storage-related device operations, the use of templates to provide a

policy-based approach to provisioning, and its administrative interface for provisioningstorage. 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 tomanage 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 isshown in Figure 2-1 on page 8.

2


16/78


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 directrepresentation 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 stateof resources and determine whether resources are reserved to meet future requirements orcurrently 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 latersection we show how TPC can be used to automatically populate the TPM model with

storage information.


17/78

Chapter 2. Tivoli Provisioning Manager support for storage provisioning9

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 storagesubsystems, of which the logical device in TPM is astorage subsystem. Operations areperformed against these logical devices (for example, a storage subsystem), and workflowsare 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 requirerewriting 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 resourcescomprised 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 astorage environment. There are three device types related to the elements of a storage

environment that can be directly configured: SAN fabrics, storage subsystems, andhost-based volume managers and file systems (in TPM terminology,storage managers). Thefourth device type is astorage pool, which provides a logical grouping of storage subsystemvolumes. These logical devices and their relationships to the physical environment are shown

in Figure 2-2.

Figure 2-2 TPM logical storage devices

Storage

Subsystem

SAN SAN FabricSAN

File system,

Volume Manager

SAN Fabric,

SAN switches,

Connectivity

Fibre Adapters

Storage

Subsystem

Storage

Manager

Storage Pool

Storage

Logical Devices

Volumes

Storage

environment


18/78


The storage pool logical device is a grouping of storage subsystem volumes from one ormore 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 storagevolumes 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 toHost, andRemove Storage Volume. Associated with each device or resource modelled in theDCM by a logical device is a Device Driver, which is a package of workflows that implementthe LDOs for a specific vendors device. Figure 2-3 shows the approach that TPM takes tosupporting devices and resources through the use of logical devices, and how these translate

to the device-specific operations.

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

Associated with TPMs representation of a physical device or resource in the DCM as alogical device is aDevice Driver(also called a TPM automation package), which enablesTPM 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 arecomprised 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 anLDO could be implemented and the flow.

Data Centre Model

contains devices

A device, represented by a

logical device in the DCM is

associated with a Device Driver

to provide a set of capabilities

Logical devices provide

abstraction from physical

devices

- Storage Subsystem

Transitions can be Javaplugins, other workflows,

simple commands etc..

Workflows deliver

sequential transitions

Logical Devices Logical Operations

Logical Operations are actions

that can be executed on the

logical device

- Create Storage Volume

- Remove Storage Volume

A package of workflows to

implement Logical Operations

for a device is a Device Driver

- e.g. ESS Device Driver

Workflows

Simple

Command Java

Plugin

Workflow

Devices

Transitions

Device Driver


19/78


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 theoperation. This then unfolds into transition steps. Conditional branching can occur depending

on input parameters or information retrieved from the DCM about the environment. Actions onthe physical devices are performed through Java plug-ins, which act on device APIs orsimplecommands executed on a host or a device using Telnet or SSH1.

Interaction with devices is only handled through the device-specific workflows in the DeviceDriver or automation packages, which must be implemented for each specific device or OSplatform 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 thestorage 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 storagesubsystem. 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 12illustrates the implementation of the storage device drivers using command line interfaces.

1 SSH: Secure Shell, provides secure encrypted communications between two untrusted hosts over an insecure

network

Device

Driver

Logical

Operation

Workflow

Transition Transition Transition

Java PlugIn

Transition Transition

SimpleCommand

Workflow

Transition Transition

Java PlugIn

Data Centre

Logical

Operation

DeviceDriver

Workflow

SimpleCommand

SimpleCommand

Execute

Logical Operation


20/78


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 accuraterepresentation 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 theinput 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 selectedtemplate. 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 physicalstorage environment. This is represented in Figure 2-6 on page 13.

TPM

Server

File system

And OS

configuration

Zone

Configuration

Subsystem

Configuration

Logical Operation

execution

Telnet

Telnet/SSH

WorkflowsDevice Drivers

SANSANSimpleCommand

Telnet/SSH

TPM Storage

Device Drivers


21/78


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, theenvironment 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 sizeon 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 volumenames and zone names, or it can be used to provide a template for a workflow to use as astarting point, combining it with information retrieved from the DCM about the devices beingconfigured.

2.1.3 Administrative interface

To support the provisioning of storage capacity, the TPM user interface provides the ability tovisualize 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 TPMinventory view. Information can be presented in two ways, either via a detailed tabular l istingor 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, isshown in Figure 2-7 on page 14.

PhysicalEnvironment

Storage Template

Data Centre Model

Logical Operation

Updates

Environment

Changes

Environment

information

SANSAN


22/78


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 givesaccess 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 tworepresentations 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 logicalassociations 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 viewof the SAN topology.


23/78


Figure 2-8 Host storage topology view

When using TPM, there are two ways of initiating storage provisioning actions. Actions canbe initiated manually via the administrative interface by users, or initiated automatically assteps 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 avolume 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 inFigure 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 wellas server provisioning tasks. These perform end-to-end provisioning tasks of adding and


24/78


removing storage to and from a host. TheAdd Storage Volume to Hostperforms all the tasksto make the volume visible at a host: Select a volume, mask it to a host, configure SAN

zoning, and OS configuration. TheAdd Storage to Hostextends this to configure volumemanagers and file systems to make the storage usable at the host without human

intervention. TheRemove Storage/Storage Volumetasks deconfigure the file systems andvolume 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 theinventory 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 byTPM. These are:

Storage Managers SAN Fabrics Storage Subsystems Storage Pools

Using these four devices, the physical and logical components of a storage environment canbe 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 attributesof 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 volumemanagers, file systems, and storage subsystems.

Figure 2-10 TPM storage modelling using logical devices

The storage model is used to represent the current state of the real data center environmentwithin TPM. TPM can use this information directly without having to query the environment

Volume

Containers

Storage

Subsystem

TPM Object

Storage

Manager

Host Server

Logical Volumes

Storage Volumes

Physical Volumes

File systems

Mount Points

Storage On Port

Storage Pool

FS1FS2

LV1LV2

PV1PV3 PV2

SV1SV2SV3

FS3

LV3

PV4

SV4

VC1 VC2

S1

SAN

Fabric

Connections

SAN Switches


25/78


every time to understand what resources are available and the connectivity betweencomponents. 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 latestconfiguration. 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 StorageSubsystems 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, StorageTemplates, 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 volumemanagers 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.


26/78


Figure 2-12 Detailed view of the Storage Manager logical device

The Storage Manager represents both the file system manager and volume managercomponents 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 Volumesusing 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 ofAccess Servers. These allow TPM to represent otherservers, which might also be configured for access to the same file system, and logical andphysical 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 serversmanaged 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

Volume

Container

TPM Object

Storage

Manager

Host Server

Logical Volumes

Physical Volumes

File systems

Mount Points

Access Servers

FS2

LV2

PV3 PV2

S2S3

VC1

S1


27/78


system and volume manager, for example, AIX_LVM for all AIX hosts. This facilitates the useof Storage Templates to provide policy-based provisioning. When provisioning actions are

performed, the Storage Manager name is used to select only the templates that areappropriate 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
http://-/?-http://-/?-


28/78


Under each Storage Manager is the list of Volume Containers (Volume Groups) that aremanaged 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. Anexample 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 volumeis 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 itis 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 SANhas 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.


29/78


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 dualpath configuration.

ServersHost Bus Adapters (HBAs) in a server are modelled as interface cards, with a number ofports. 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 physicalconnection 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.

Interface Cards (HBAs)

TPM Object

Server

Zones

Ports

Physical Connections

SV1SV2SV3

Interface Cards

SAN Switches

1 2 3 4 Ports

5 6 7 8

WWNS

ZoneSet

Storage Subsystem

SAN Fabrics

SAN


30/78


Figure 2-18 Host fibre adapters

Storage subsystemsSAN 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 connectedto two Cisco 9509 switches.


31/78


Figure 2-19 Storage subsystem view, HBA definitions

SwitchesTo 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 bothswitches with a fixed number of ports (single card), as well as director class switches, whichhave 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 9509director, 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 diskaccess.


32/78


In the properties for Fabric1, the World Wide Name field is used by TPM to identify theprincipal 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 isonly 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 shownin 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 Setis the name of the Active Zone Set in thisfabric. With the TPM workflows for switch management from the Orchestration and

Provisioning Automation Library (OPAL2), this is the Zone Set against which zoning actionsare performed. When using TPC for switch management, TPC can automatically determine

and update the currently active zoneset.

Visualizing SAN Fabric connectivityAs well as the detailed switch device views showing the switch ports, the overall fabricconnectivity 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 connectedsubsystems. The icon view is shown in Figure 2-22 on page 25.

2 OPAL Web site: http://www.developer.ibm.com/tivoli/workflow.html
http://www.developer.ibm.com/tivoli/workflow.htmlhttp://www.developer.ibm.com/tivoli/workflow.html


33/78


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. Thisshows 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: StorageSubsystems, and also a logical grouping of storage volumes by type and capability intoStorage Pools. The two devices are shown in Figure 2-23.

Figure 2-23 Storage Subsystem and Storage Pool logical devices

Storage SubsystemsStorage Subsystems are modelled similarly to servers with interface cards and ports definingthe HBAs on the subsystem. An example is shown in Figure 2-24 on page 26.

Storage

Subsystem Storage Volumes

Storage On Port

Storage Pools

SV2SV3

SV4

SV1 SV4

SV6SV5 SV7

Pool 3

Pool 2Pool 1

Interface Cards

Ports


34/78


Figure 2-24 A Storage Subsystem represented in TPM

The volumes created on the subsystem are shown. Within TPM these are known as StorageVolumes. When a volume is mapped to a host port, this association is represented in theFibre Channel Port field. Some array types require that storage volumes are mapped tospecific adapters on the subsystem for access by host servers. This mapping is known as theFibre Adapter Port mapping(sometimes abbreviated to FA Port in TPM). The TPMterminology for this is Storage On Portand is used to support arrays that map volumes tospecific 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 anentry in the Fibre Channel Port field. This is not shown in the figure, as the array representeddoes 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 NationalStandards Institute (ANSI) and is the serial number of the storage subsystem. Specification of

this is not required in TPM.

Storage PoolsStorage Pools are used to group volumes of a similar type, that is, all RAID5 volumes, or allRAID1 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 orvolume type. Another use for storage pools is to implement the concept of volumereservation. 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 arerequired.

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 ofTPM, they can be defined into the pools to make volume selection a simpler task in a

workflow.


35/78


Storage Pools in TPM can also be referred to as Storage Allocation Pools. Similarly, thevolumes 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 thepool 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 arealso shown, indicating RAID level and the subsystem it exists in. The State/Assignment fieldindicates if a volume isAvailable for use,In Use (mapped to a host),Assigned(LUN maskedto 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 foradditional 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 administratorspecifying 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 samestorage configuration will automatically be used for each server. This approach of using

templates ensures that a consistent naming convention is enforced and that all servercomponents of an application are configured the same.


36/78


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 touse 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 areconfigured by TPM with the same storage configuration.

Settings form a hierarchical structure under the Volume Container settings, dividing intosettings related to the physical storage and the logical storage environments. Physicalenvironment 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 onpage 29.


37/78


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 thistemplate 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. Thesettings 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 LogicalVolume 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


38/78


At a logical level, these define how the volume manager will configure and carve up physicalvolumes 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 tobe of typesimple orspanned. Simple implies that the logical volume exists on a singlephysical volume only andspannedthat it is made up of one or more physical volumes.

2.3.3 Disk Partition SettingsDisk partition settings, shown in Figure 2-30, are used to make the association between aphysical volume and the logical volumes that will be created on it. They also define howphysical 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.
http://-/?-http://-/?-


39/78


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


40/78


2.3.6 Physical Volume Settings

The physical volume settings are used by the Storage Subsystem and Storage Pool logicaloperations 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, orcreate a new volume on a subsystem meeting the specifiedRAID Level, Function Type, andConsumable (minimum) size requirements. The Function Type is used for subsystems wherevolumes 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 willuse. 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 correctattributes.

2.3.7 Multipath settings

The multipath settings enable use of the powerful concept of datapaths. These define theexplicit 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 upbetween a host and the storage subsystem, providing secure storage access. Figure 2-34 on

page 33 shows an example of multipath settings.


41/78


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 thezone. 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 fromthe 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, orif 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 implementsa 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 operationsare 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.


42/78


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, andfile 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 ascreating 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 tobe 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, addingvolumes 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 theStorage 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 ofthese 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 inTPM. These relate to file system and Volume Manager tasks. The function of most operationsis evident from their names, although a few require further explanation.


43/78


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 andRemoveStorageFromHost operations are examples of more complex operations discussed

previously, which can perform end-to-end configuration of storage to and from hosts. Thisincludes zoning, creation of storage volumes on the subsystem, LUN masking, volume

manager, and file system operations. An implementation of the AddStorageToHost operationis 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 fromzones. Here the capabilities of TPM as a provisioning tool are focusing on the routine


44/78


day-to-day tasks performed in a storage environment to provision storage. Tools such asTPC 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 ofthe 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 volumesfrom a single storage subsystem. Storage Pools do not implement operations against specificvolumes, 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, andcreation and deletion of volumes in the pool. These operations are interchangeable with the

same Storage Subsystem operations. The three pool-specific operations are shown inFigure 2-37.

Figure 2-37 Storage Pool operations

The use of storage pools makes it easier to model tiered storage within TPM and alsoaccommodate the concept of volume reservation for specific future requirements. The

Storage Pool GetStorageVolumes LDO can search the entire pool for a volume meeting therequirements rather than a single subsystem, as is the case for the Storage Subsystem

implementation of the GetStorageVolumes LDO. Once a volume has been created andselected, 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 inTPM.


45/78


Figure 2-38 Storage Subsystem operations

These operations include the same three operations supported for Storage Pools:GetStorageVolume, CreateStorageVolume, and RemoveStorageVolume, and they can beused interchangeably with the Storage Pool operations in workflows. The operations provide

effective management of many types and vendors of storage subsystems, and includeoperations 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 systemmust 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 andassigning 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 ofinternal disk and SAN disk to OS device names, and the latter allows removal of either type of

disk.


46/78


Where the OS supports it, implementation of these operations allows storage to be mappedto 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 additionalstorage 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 Managerlogical 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 developedusing the building blocks provided by TPM. Chapter 5, A storage provisioning solution forSAN 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 simplifiedversion 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

}


47/78


}

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 templateto be used to create the volumes and file systems. A key subcomponent of this workflow isthe AddStorageVolumeToHost operation. This performs the volume-related tasks required,

and the AddStoragetoHost operation wraps this around with the file system and volumemanager 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 thetasks of creating and mapping the volume to the host. After creating the volume and mappingit to the host OS, the physical volumes, logical volumes, and file system are created.


48/78



49/78


Chapter 3. Provisioning Storage with Tivoli

Provisioning Manager

TPM provides a comprehensive environment within which users can provision storage. Froma 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 individualadministrators can see and do. Users are also assisted in performing storage operations by awizard-based approach to creating storage templates. These features are now looked at in

more detail.

3


50/78


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 singleHBA 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, theconnectivity 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.


51/78

Chapter 3. Provisioning Storage with Tivoli Provisioning Manager43

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 physicalvolume pv03 at the host. Right-click a resource to give more options such as the ability tohide relationships or resources.

3.2 Performing storage operations

TPM can be used in a number of ways to provision storage: Provisioning actions can beinitiated 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.


52/78


Figure 3-3 Host storage provisioning operations

The figure shows the four storage operations that can be initiated from the server view, withone 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 templatesas 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 inputare 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
http://-/?-http://-/?-


53/78

Chapter 3. Provisioning Storage with Tivoli Provisioning Manager45

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 shownhere.

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 operationonly 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 beused. 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.


54/78


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 StorageSubsystems and Volumes meeting these characteristics are presented and a volume

selected. Checking the execution status is the same as for the Add Storage To Hostoperation.

3.2.3 Implicit execution

If storage operations are initiated from server or application provisioning workflows, anadministrator cannot explicit

Documents

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