Redbooks Paper

Roland Tretau Joe A Burnett Norbert Engst Kazue Okano

Storage migration and consolidation with IBM TotalStorage products

Overview
This IBM Redpaper discusses how to migrate and consolidate your storage management environment using IBM TotalStorage products. It also discusses common client environments and explains how a company can benefit from migrating to a more efficient storage management environment. Additionally, we show how IBM Tivoli Storage Manager works with VMware software. VMWare is an EMC company that provides virtual infrastructure products for Intel-based systems enabling enterprises to simplify their IT, leverage existing computing investments and respond faster to changing business needs. The following areas of backup and migration strategies are covered: Volume migration using SAN Volume Controller on page 2 Migration of data between tape technologies on page 3 Tape consolidation on page 7 IBM Tivoli Storage Manager server consolidation on page 16 VMware backup considerations on page 23

Copyright IBM Corp. 2004. All rights reserved.

ibm.com/redbooks

Volume migration using SAN Volume Controller

Storage Area Networks (SAN) are very common in the industry today. A SAN provides fast, reliable access to data. However, some common problems with assigning volumes or logical unit numbers (LUNs) to servers sometimes arise. The possibility of inefficient utilization of volume space and the inability to resize the space are always present, but with little or no impact to the production environment. For example, some of the volume space might be needed by another client on the SAN and can become unused on the client to which it is assigned. However, migrating data from one volume to another requires a scheduled outage, sometimes an unacceptable option in a production environment. By utilizing the IBM TotalStorage SAN Volume Controller in your environment, you can eliminate these common issues and facilitate future growth. Figure 1 on page 3 illustrates the steps necessary to migrate an existing SAN storage volume to a hardware configuration using an IBM TotalStorage SAN Volume Controller. The first step identifies the initial configuration of attaching a volume to an application server using a SAN. The IBM TotalStorage SAN Volume Controller is then installed, a virtual volume created, and the existing data volume is mapped to the virtual volume. The application server now sees the virtual volume with all the existing data mapped to it. In the last step, the storage allocated to the virtual volume is increased using additional disk space managed by the IBM TotalStorage SAN Volume Controller. The data is migrated to this new disk, and the original volume space is eliminated from the mapped virtual volume.

Storage migration and consolidation with IBM TotalStorage products

Application Server

Application Server

Application Server

SAN

SAN

SAN Volume Controller installed and old storage mapped as virtual volume to the server

SAN

Movement of data from old volume to new disk and reduction of old volume space from virtual volume

Volume

Virtual Volume

SAN Volume Controller

Virtual Volume

SAN Volume Controller

New Disk Existing volume with application data is SAN-attached

New Disk

Volume

Volume

Data

Figure 1 Migrating SAN disk volume data to SAN Volume Controller storage

Data migration from the original volume to the virtual volume using additional disks can be accomplished without interrupting data availability. The application server can continue to read, write, and process data as it is migrated. Transparency of these operations to the application server makes the IBM TotalStorage SAN Volume Controller a very effective tool in managing SAN-attached storage.

Migration of data between tape technologies

IBM Tivoli Storage Manager provides an efficient method of migrating data that resides on older media to a more contemporary media. While planning your storage management strategy, it is important to take into consideration the fact that as time passes, tape and media technologies will become obsolete. They

Storage migration and consolidation with IBM TotalStorage products

could possibly be physically unavailable if an archived tape or other media is kept off site for data retrieval. Don't take the risk that a specific tape drive you sent off site last week will be available in ten years. You should have a plan to perform a technical refresh of your media and drive technologies after a specified number of years to either move the data to new media, or migrate it to newer, higher capacity media using newer drive technologies. Data within IBM Tivoli Storage Manager is stored on a per client basis, and each of these clients' data resides in a storage pool hierarchy. Each storage pool, in turn, consists of allocated media volumes (such as, tapes, disks, or optical volumes). Storage pools are associated with particular technologies based on the media volumes that comprise them, and a storage management administrator can move or migrate this data across storage pools within IBM Tivoli Storage Manager. This makes the transition to a different form of media transparent to the clients to whom the data belongs and without interruption in data availability. There are two methods used to perform data migration: Migrating individual nodes Migrating complete storage pools to a new tape technology

Migrating individual nodes

The first method, using individual nodes, is more labor-intensive; however, it allows for movement of data from one storage pool to another based on the priority of moving particular client nodes. You may prefer to migrate data on specific servers to higher performance media and drives, because these servers have a higher priority to have their data recovered should a data loss event occur. Figure 2 on page 5 shows how client or node data is moved out of a storage pool residing in an older technology library to a newly defined storage pool in an IBM 3584 UltraScalable Tape Library using the move nodedata command. A major benefit of IBM Tivoli Storage Manager is that if Node4 requires a restore operation, IBM Tivoli Storage Manager will know that the data required still resides in the older library. If a restore request occurs for Node3, IBM Tivoli Storage Manager knows to retrieve the data from the IBM 3584 library since IBM Tivoli Storage Manager's internal database is updated with the current location of the data as the migration takes place. It is conceivable that a restore request could be performed during the migration process from one media type to the other. IBM Tivoli Storage Manager would simply load the appropriate media from both libraries if necessary to complete the request. Once the data movement has been completed for all nodes to the storage pool in the IBM 3584 library, the older library may be disconnected and its storage pool definitions deleted within IBM Tivoli Storage Manager, since data no longer resides there.

Storage migration and consolidation with IBM TotalStorage products

Node1 Node2

Node3

Data Movement During Move Nodedata (SCSI or SAN)

Node4

Old Library

IBM 3584 Library

IBM Tivoli Storage Manager Server

Database

Tracking information about object location on tape is updated as movement occurs

LAN or SAN

Node1

Node2

Node3

Node4

Figure 2 Using move nodedata command to migrate data across tape technologies

Migrating complete storage pools to a new tape technology

As we discussed earlier, migration of individual nodes from one storage pool to another involves manually issuing commands to migrate the information using the move nodedata command. This is an effective way of giving specific clients priority of relocation to the newer technology. However, if there are hundreds of gigabytes or even terabytes of data spanning across hundreds of different clients, moving the data using this method becomes inefficient. On the other hand, a major advantage of IBM Tivoli Storage Manager is the storage pool hierarchy method it employs to store data. The same method is used to bring data into a disk storage pool during your scheduled backup time period and then later migrate that data to tape using the nextstgpool and migration threshold parameters. By attaching a new library or tape technology to an existing IBM Tivoli Storage Manager server, as shown in Figure 3 on page 6, and then setting the nextstgpool parameter of the storage pool where the existing

Storage migration and consolidation with IBM TotalStorage products

data resides to a storage pool value comprised of the new technology, the migration threshold parameter of the older storage pool(s) can be set to 0. Over the course of the next few hours, or days if necessary, the data will safely migrate to the new storage pools during background processing.

ARCH3494

Data Movement During Migration (SCSI or SAN)

TLIB3494

ARCH3584

TLIB3584

IBM 3494 Library IBM Tivoli Storage Manager Server

IBM 3584 Library

Off-site Data Movement

Off-site Data Movement

OFF3494 (Copy Pool)

Copy Pool Data Cannot be Migrated

OFF3584 (Copy Pool)

Figure 3 Migrating storage pool data using migration destination and thresholds

Once data begins to populate the storage pools on the new media, it will be necessary to run a backup storage pool process on these if you have created a new off-site pool based on the new media. The move data and move nodedata commands cannot be used on copy pool data; however, the internal IBM Tivoli Storage Manager database will be updated to reflect the new location of the data that is associated with the pre-existing copy pool. In the event of a media failure or loss of data in the new media storage pool, the database will still reference the backup copy of the pool data and the missing data can be restored from there. Once the storage pools on the new media have been successfully populated, a new copy pool can be created on the new media and backup storage pool commands can be run to reproduce the data on the new media. This will totally remove your dependence on the older media technology.

Storage migration and consolidation with IBM TotalStorage products

Tape consolidation
Tape consolidation has become an important topic since the quantity of data used in open systems environments started to reach mainframe proportions. This subchapter explains the technological move from dedicated to shared libraries and later to logical partitioned libraries. A removable media manager combines the advantages of library sharing with the advantages of logical partitioning. It can be seen as an initial step to tape virtualization.

Types of tape libraries

Large tape libraries that consist of lots of frames, such as the IBM Enterprise Tape Library 3494 for mainframes, have existed for many years. Many companies are using integrated computers to manage them. Connected servers send mount requests through the TCP/IP (transmission control protocol/Internet protocol) network to the library management computer that controls the robotics to physically mount the tapes. The tape drives in 3494 have a small computer systems interface (SCSI) or fibre channel interface. Open system servers can be directly attached to it, while mainframes need special controllers that transfer enterprise system connection (ESCON) or fiber connection (FICON) protocols to the fibre channel or SCSI.

Storage migration and consolidation with IBM TotalStorage products

Library Control over TCP/IP

Library Control System

Drive Data Path

Data Path Backup Application A

Drive

Drive Data Path

Data Path Backup Application B

Drive

Figure 4 Classical IP managed library

As the control information goes through the TCP/IP network, this type of library is sometimes called an IP library. In Figure 4 the functionality of an IP library with open attachment is depicted in a very basic way. Open systems servers have fibre channel or SCSI connections to tape drives. The Library Control System handles the robotics of the libraries by sending commands over the TCP/IP network. In cases of fibre channels, it is common to use a switched fabric environment. We chose not to use this type of environment in our scenarios to keep them simple and comparable. In the open systems environment, smaller libraries designed for affordable solutions are widely used. These libraries dont have a dedicated management computer attached, so the control of the robotics has to be done via SCSI commands from the attached server. Even if the attachment is connected via the fibre channel, this type of library is often called an SCSI library and sometimes called a jukebox. The content of SCSI libraries has to be managed by software

Storage migration and consolidation with IBM TotalStorage products

solutions, usually network backup applications. To prevent confusion and loss of data, only one server may have control over the tape volumes and the robotics of the library. The classic way to use an SCSI library is to connect it to a backup server like the IBM Tivoli Storage Manager and to do backups from clients over the TCP/IP network. Network backup is an established and approved method.

Tape library sharing

When more and more business critical applications like databases and mailing systems were migrated to the open systems world, the requirements for doing backups changed. Open systems data has also become an important asset, crucial for companies economic survival. When the IT world embraced switched fabric environments, IBM Tivoli Storage Manager servers provided a practical way to share drives. With this realization, IBM introduced functionality for tape library sharing in the IBM Tivoli Storage Manager. It works only in a SAN environment, because it requires any-to-any connectivity. The tape library manager, which can be on one of the backup servers, controls the robotics. As illustrated in Figure 5, fibre attached tape drives have an active or inactive control path, which is a serial connection that goes from the drives to the library robotics.

Storage migration and consolidation with IBM TotalStorage products

Metadata over TCP/IP

Library Control System

Library Sharing Software Drive

Data and Library Control Path

Library Control Path

Data Path Backup Server 1 Library Manager

Drive

inactive

Drive Data Path inactive

Data Path Backup Server 2 Library Client

Drive

inactive

Figure 5 Software-based tape library sharing with an SCSI library

Tape library sharing works in a heterogeneous hardware environment but requires a homogeneous software solution. With the IBM Tivoli Storage Manager, it is possible to share an SCSI library between backup servers running under AIX, Windows, Linux, HP-UX and Solaris. If a single IBM Tivoli Storage Manager is not able to perform the backups in a reasonable time frame due to a heavy workload, tape library sharing is a good way to share tape resources. Incidentally, tape library sharing was a precursor to the LAN (local area network) backup method. For more details on storage management concepts please refer to the following IBM Redbook: IBM Tivoli Storage Management Concepts, SG24-4877-03. Note: Keep in mind that every backup server needs administration.

10

Storage migration and consolidation with IBM TotalStorage products

Logical partitioning with tape libraries

Today, businesses are needing to warehouse enormous amounts of data. There is an increasing need for data consolidation in the open systems world, and SCSI libraries have become larger as a result. There is a trend to share a library between different hardware platforms such as iSeries and Unix, or between competing network backup solutions. In Figure 6, this type of sharing is schematically illustrated. The drive and slots are divided into disjunctive partitions, with each drive and any slot belonging to only one partition.

Library Control System

Data and Library Control Path

Drive

Library Control Path

Data Path Backup Application A

Drive

inactive logical partition 1 logical partition 2

Data and Library Control Path

Drive

Library Control Path

Data Path Backup Application B

Drive

inactive

Figure 6 Logical partitioning

The IBM 3584 UltraScalable tape library was IBMs first SCSI library that could be divided into many logical partitions. These partitions share robotics and appear to be connected to the server as a separate smaller library would be. In principle each drive within an IBM 3584, in conjunction with an array of slots, can build a separate partition. In reality two or more drives are used in logical

Storage migration and consolidation with IBM TotalStorage products

11

partitions. In the IBM Tivoli Storage Manager, for example, it is recommended that you use a least three drives per backup server. Figure 7 shows how a physical library can be shared between different open systems and midrange platforms like iSeries, xSeries and pSeries. Its also possible to implement software-based tape library sharing within a logical partition such as the one depicted in Figure 7 as Zone 3.

Library Controller

DRIVE 1

Logical Library 1
DRIVE 2

Zone 1 iSeries App A

DRIVE 3

SAN
(with Zoning) xSeries App B Zone 2

Logical Library 2
DRIVE 4

DRIVE 5

Zone 3

Logical Library 3
DRIVE 6

pSeries App C

Multiple hosts owning separate logical library slots and drives

Linux App C

Figure 7 Multipath logical libraries in a switched fabric SAN

Its common to have some logical libraries in an IBM 3584 tape library. The slots of a logical library have to be in consecutive order. If a logical library has to be enlarged or reduced, the other logical libraries may also have to be changed. This is a critical step, because the administrator has to move the cartridges and take care that none of the tapes are overwritten by other applications. This approach may be practical in a two frame library, but imagine trying to do this for a fully equipped IBM 3584 library with 16 frames and more than 6000 tape cartridge slots.

12

Storage migration and consolidation with IBM TotalStorage products

Removable media management

Over time, open systems tape environments, which are SCSI-controlled tape libraries without integrated management computers like the IBM 3584 UltraScalable tape library, can also hold up to nearly 200 LTO 2 (linear tape open) tape drives and an uncompressed data capacity of up to about 1.3 terabytes. Until recently, these dimensions were unfamiliar territory for open systems and previously only known in mainframe environments, that is until IBM introduced the 3494 Enterprise Tape Library, which has an integrated management computer. The open world is more heterogeneous and distributed than the large system environment. This is due to the incompatibility of hardware and software of different vendors. Even if the tape libraries can be logically partitioned, there is a requirement to be able to share the tape resources and to have a powerful tape media management methodology. In this type of open systems environment, a mainframe-class media management solution is required, including a policy-based media life cycle management component. In large companies, media management solutions must be able to catalog and manage access to thousands of media. Companies are also interested in logging accesses, failures and cartridge life cycles. As cartridges can also be stored outside of physical tape libraries, media management must keep track of the depositories of all media. A removable media management solution provides: mechanisms for secure sharing of tape resources among multiple heterogeneous applications enhanced access control mechanisms an enterprise-wide repository for removable media policy based media management to control media access, synchronization, prioritization and tracking.

Storage migration and consolidation with IBM TotalStorage products

13

Media Management over TCP/IP

ol Contr

TSM Servers

Other Backup Servers

TSM Server TSM Server TSM Server TSM Server TSM Server TSM Server

Other Apps

Tape Virtualization

TSM Server TSM Server TSM Server

Data

Media, Library and Drive Management

RMM Server

SAN
SCSI/FC Streaming Devices (Drives) SCSI/FC Media Changer Devices SCSI/FC Prop. Interface Library Mgmt. Streaming Devices (Drives) Media Changer Devices

Removable Media Hardware

SCSI Libraries without built-in Management (e.g., IBM 3584)

Removable Media Hardware

Libraries with integrated Management (e.g., IBM 3494)

Figure 8 Removable media management

A removable media manager is middleware that allows heterogeneous sharing of tape libraries with respect to applications, operating systems and library vendors without the need to implement static partitioning and dedicated drives. Without a tape resource management solution, different applications could access the tape resources in an uncoordinated manner. On the other hand, with a removable media manager, administration, access control and reporting are centralized in one solution. The management and tracking of off-site media pools, as shown in Figure 9, are integrated inside the removable media manager.

14

Storage migration and consolidation with IBM TotalStorage products

DB2 Database

Removable Media Manager

Abstract Library Manager Interface

ATL Library Manager

Offline Library Manager

Figure 9 Integrated off-site management and tracking

A removable media manager combines the benefits of tape library sharing and logical partitioning. A single pool of tape drives and a pool of scratch cartridges can dynamically be shared between different backup applications, as shown in Figure 10. The backup applications may access virtual tape libraries that appear altogether larger than the actual hardware really is. Physical resources will be allocated on demand. Mount requests of different applications can be queued and prioritized between the applications in case of over allocation. A cartridge life cycle management policy is also included, complete with vaulting and tape quality management.

Storage migration and consolidation with IBM TotalStorage products

15

Backup Application A

Backup Application B

Backup Application X

TCP/IP Network

Media Management Resource Sharing Grouping & Pooling

SAN
Drive s Slots
Database

Tape Library

Figure 10 Media management in heterogeneous software environments

IBM Tivoli Storage Manager server consolidation

If you have already used IBM Tivoli Storage Manager to manage storage media for multiple separate systems, you may have entertained the possibility of consolidating them. Figure 11 is an example of how you might go about it. Perhaps you are using older IBM Tivoli Storage Manager servers and want to upgrade to more robust IBM Tivoli Storage Manager servers. Or, maybe you are using multiple IBM Tivoli Storage Manager servers to back up a local disk, but you want to use a larger tape library and to share it between multiple servers. If the IBM Tivoli Storage Manager clients can use both an old IBM Tivoli Storage Manager server and a new IBM Tivoli Storage Manager server as depicted in Figure 12, server consolidation can be implemented rather easily. If not, youll first have to examine some issues.

16

Storage migration and consolidation with IBM TotalStorage products

OLD IBM Tivoli Storage

Manager Server Systems

NEW IBM Tivoli Storage

Manager Server Systems

Tivoli Storage Manager Server

Tivoli Storage Manager Server

Consolidation

Network

Network

Tivoli Storage Manager Clients

Tivoli Storage Manager Clients Tivoli Storage Manager Server Tivoli Storage Manager Server

Network

Network

Tivoli Storage Manager Clients

Tivoli Storage Manager Clients

Figure 11 Consolidation fof IBM Tivoli Storage Manager servers

Case 1 - switch to a new server

Basically, we recommend that you consider consolidating multiple IBM Tivoli Storage Manager servers as we describe in this first case. It is very simple and you dont need a large amount of advance preparation time. It involves maintaining the existing IBM Tivoli Storage Manager clients and performing all future backups on a new IBM Tivoli Storage Manager server. And if you need to restore the old backup data, you just specify the old IBM Tivoli Storage Manager servers option as shown in Figure 12. Thus, two or more servers exist until the old backup data is expired. After all backup data is expired, you just use the new IBM Tivoli Storage Manager server. The old servers are not needed any more.

Storage migration and consolidation with IBM TotalStorage products

17

OLD Tivoli Storage Manager Systems

OLD_Server IP Address 10.1.1.1 Tivoli Storage Manager server is fully consolidated after expired backup data

NEW Tivoli Storage Manager System

NEW_Server IP Address 10.1.1.3

Restore Data

Backup Data

Network
dsmc -servername=old_tsm dsmc -servername=new_tsm

dsm.sys (UNIX)
servername old_tsm commethod tcpip tcpserveraddress 10.1.1.1 . . servername new_tsm commethod tcpip tcpserveraddress 10.1.1.3 . .

Figure 12 Switching to a new server for consolidation

The database export and import function

IBM Tivoli Storage Manager software provides a function that allows you to consolidate IBM Tivoli Storage Manager servers. It copies all the server information, or a subset of the server control information such as administrator, node, server, or policy information, from the IBM Tivoli Storage Manager server, as shown in Figure 13. Also the clients backup, archival, and space-managed files are exported with the client control information. You can export the complete server or just parts of it, for example, the data that is stored on just a few clients.

18

Storage migration and consolidation with IBM TotalStorage products

IBM Tivoli Storage Manager Server 1

Administrator

IBM Tivoli Storage Manager Server 2

Server

Export

Node

Import

Policy

Figure 13 Exporting data from server 1, using volumes to import data to server 2

The export commands create an operating-system-independent, self-describing copy of the specified server information. The original database is not required to recover data from this volume. IBM Tivoli Storage Manager does not keep track of file expiration, so the information contained can be recovered onto any server at any time. This is not a substitute for disaster recovery. Export and import is a relatively time-consuming process, so it is designed primarily for one-time data movement. IBM Tivoli Storage Manager offers two ways of exporting data: Export to sequential media. Export directly to another IBM Tivoli Storage Manager server in the network. The target server can be on the same platform or a different one. If you choose the first option, to export to sequential media, the target server must support the same tape media that the source server does. Restrictions: Export from an IBM Tivoli Storage Manager server cannot be imported by earlier versions. Nodes of type NAS cannot be exported.

Storage migration and consolidation with IBM TotalStorage products

19

Exporting to sequential media

Server information can be exported to any sequential medium, including volumes of a deviceclass FILE or opticals. The target server must support the same or a compatible type of media. The exported data will then be imported in a separate process on the target server. This is described in further detail in Case 3 - export to sequential volume on page 22.

Exporting directly to another server

If there is a network connection between two IBM Tivoli Storage Manager servers, the export can be executed directly via the network to the target server. This results in an immediate import process on the target server. No external media is needed to transport the data from the source to the target server. For further explanation about this technique, read Case 2 - export the data directly to a new server on page 21.

Export/import administration
These commands move administrative data such as name, password, privilege classes, and administrator lock/unlocking information for server access.

Export/import node
These commands move client node definitions. Each client node definition includes the user ID, password, name of the policy domain to which the client is assigned, file compression status, backup/archive delete authority, and client node lock / unlocking data for server access. Client data can be exported in the same process. The following groupings of files are supported: Active and inactive versions of backup files, archive copies of files, and space-managed files Active versions of backup files, archive copies of files, and space-managed files Active and inactive versions of backup files Active versions of backup files Archive copies of files Space-managed files An incremental export can limit the amount of data being exported. In this case, the export command specifies the date (FROMDATE) and time (FROMTIME) the data was stored on the server. All data stored on the server before that specified date and time will not be exported.

20

Storage migration and consolidation with IBM TotalStorage products

If the exported client node already exists on the target server, IBM Tivoli Storage Manager can merge the client file data during import. During this process, backup objects are inserted as new active or inactive versions depending on their insertion date and time. Double archive and space management objects will be skipped. If merging is not used, IBM Tivoli Storage Manager will create a new renamed file space for the imported client.

Export/import policy
These commands move policy information from one or more policy domains. They include data such as policy domain and set definitions, management class definitions, backup, copy group, and archive group definitions, schedule definitions for each policy domain, and client node associations.

Export/import server
These commands move all or part of the server control information and client file data (if specified). These include definitions for administrator, client node, policy and schedule for each policy domain. They can optionally include: file space definitions, access authorization information, and backup, archived, and space-managed files. You can import client file data using the previously described procedures.

Case 2 - export the data directly to a new server

If your existing IBM Tivoli Storage Manager server is version 5.1.5 or higher, you can use this scenario. In Case 2, data is exported directly from the old IBM Tivoli Storage Manager server to the new Tivoli Storage Manager server over the LAN. This method is preferred to the one described in Case 3 because it does not require the extra step of writing data to intermediate volumes before moving it to the new server, which takes more time to accomplish. In this case, the old backup and storage pool data can be exported directly to the new server database and storage pool as shown in Figure 14. If, on the other hand you have huge amounts of data, you will have to consider the time frame and resources required.

Storage migration and consolidation with IBM TotalStorage products

21

export... toserver=NEW_SERVER

LAN

OLD Database

NEW Database

OLD Tivoli Storage Manager Server

OLD Storage Pool

NEW Tivoli Storage Manager Server

NEW Storage Pool

Figure 14 Exporting the data directory to a new server

Case 3 - export to sequential volume

This case is similar to Case 2 - export the data directly to a new server on page 21, except that it does require the extra step of writing intermediate volumes before delivering the exported data to a new server as shown in Figure 15. Thus the servers do not use the LAN for sending the exported data. You export the information and the data from the old server and check out the volume. Then you check in the volume and import the information and the data to the new server. The number of processes for export and import is one per command. This means it is advisable to use one mount point for export or import and another mount point for the intermediate volumes. So if you have huge amounts of data you have to consider the duration of time and resources required. Additionally, you can prepare the empty volume to use intermediate volume.

22

Storage migration and consolidation with IBM TotalStorage products

OLD Tivoli Storage Manager Server

NEW Tivoli Storage Manager Server

OLD Database

NEW Database

OLD Storage Pool

Intermediate Volume(s)

NEW Storage Pool

export... devtype=... checkout libvol

checkin libvol import ... devtype=...

Figure 15 Export to sequential volume

VMware backup considerations

VMware is a company that provides virtual infrastructure products for Intel-based systems. It is also a product of the same name that enables virtual machines on an x86 platform. By using the VMware product, it is possible to have multiple concurrent virtual machines running on one physical machine, with the VMware application managing the resource allocation for processor, memory, and disk across the virtual machines. Each virtual machine can be utilized just like a separate physical machine. The virtualization layer is transparent to the operating system installed on each of the virtual machine instances, and most commercial applications (including IBM Tivoli Storage Manager server and client) can operate within a virtual machine. Consolidation of multiple physical machines onto one physical machine running VMware has become a very popular and economical way of reducing total cost of ownership for many companies. For example, four machines that average 20% processor utilization can be consolidated onto one physical machine that averages greater than 80% processor utilization, a more efficient use of hardware resources.

Storage migration and consolidation with IBM TotalStorage products

23

Figure 16 illustrates the VMware architecture. As noted in the illustration, the Tivoli Storage Manager backup client can be installed on both the operating system that manages the physical hardware as well as the operating system that is within the virtual machine. Each installation method provides distinct benefits. Installing a backup client within the operating system of the virtual machine allows access to the individual files within the file systems, allowing multiple versions of each file within the virtual instances to be retained. Note: If an application has certain files open, these files cannot be reliably backed up. Close all open files before beginning the transports. All rules on open files in relation to a backup strategy still apply with this scenario.

Backup client inside virtual machine allows for file-level backups

Virtual Linux Machine

Virtual Processor Virtual Video Virtual Network Virtual RAM Virtual Disk Virtual Processor

Virtual Windows Machine

Virtual Video Virtual Network Virtual RAM Virtual Disk

VMware Application / Virtualization Layer

VMware layer handles all translation and physical resource management

Physical Hardware Architecture (x86)

Processor(s) Video Network RAM Disk

Backup client on physical machine allows virtual disks to be backed up as individual files, providing an image backup capability

Figure 16 Backup considerations on a VMware installation

24

Storage migration and consolidation with IBM TotalStorage products

Installing a backup client on the host machine where the VMware Workstation application is installed (and where the virtual machines are running) allows for entire drives or volumes of the virtual machines to be backed up as individual files when the virtual machines are paused or shut down. This is shown in Figure 17. On enterprise-class implementations of VMware, such as the VMware ESX Server product, the drives can be released for backup as individual files by utilizing scripts and the built-in API of VMware. This provides functionality comparable to an image backup of a raw logical volume. In the event of data loss resulting from human error, it is usually sufficient to restore individual files using the backup/archive client within the virtual machine. For a more catastrophic loss, such as a virus infection, the flat file that represents the virtual drive can be restored to the directory where it resides on the host machine. If this is insufficient, once the flat file is restored, the virtual machines backup/archive client installation function can then be used to restore files to a more current version than the existing backup copy.

Storage migration and consolidation with IBM TotalStorage products

25

/usr

/filesystem1

/home

vm1/disk1.dsk vm1/disk2.dsk vm3/disk2.dsk

C:\

/filesystem2

C:\

vm2/disk1.dsk vm3/disk1.dsk

D:\

Virtual Machines
Figure 17 Mapping virtual volumes as physical files on a host machine

Physical Machine

When implementing a backup/recovery solution for a VMware installation, it is important to back up the configuration files for each virtual machine. These contain information such as the amount of RAM that is allocated, the virtual networking configuration, and other important details.

26

Storage migration and consolidation with IBM TotalStorage products

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.

Copyright IBM Corp. 2004. All rights reserved.

27

This document created or updated on September 16, 2004. Send us your comments in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an Internet note to: redbook@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2, 650 Harry Road San Jose, California 95120-6099 U.S.A.

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX ibm.com Tivoli ESCON IBM TotalStorage Eserver iSeries xSeries Eserver pSeries FICON Redbooks (logo) The following terms are trademarks of other companies: Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation 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. Linux is a registered 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.

28

Storage migration and consolidation with IBM TotalStorage products