Storage migration and consolidation with ibm total storage products redp3888

Redbooks Paper

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

Roland TretauJoe A BurnettNorbert EngstKazue Okano

© Copyright IBM Corp. 2004. All rights reserved. ibm.com/redbooks 1

http://www.redbooks.ibm.com/


Volume migration using SAN Volume ControllerStorage 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.

2 Storage migration and consolidation with IBM TotalStorage products

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

SAN

Volume

ApplicationServer

SAN

Volume

ApplicationServer

SAN Volume ControllerVirtualVolume

SAN

Volume

ApplicationServer

SAN Volume ControllerVirtualVolume

NewDisk

NewDisk

SAN VolumeController installedand old storagemapped as virtualvolume to the server

Movement of data fromold volume to new diskand reduction of old volume space fromvirtual volume

Data

Existing volume withapplication data isSAN-attached

Storage migration and consolidation with IBM TotalStorage products 3

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


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

Migrating complete storage pools to a new tape technologyAs 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

Node4

Node2

Node1

OldLibrary

IBM Tivoli Storage Manager Server

Database

Data Movement DuringMove Nodedata (SCSI or SAN)

Node3

IBM 3584Library

LAN or SAN

Node1 Node2 Node3 Node4

Tracking information about objectlocation on tape is updated as

movement occurs


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.

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.

IBM 3494 Library IBM 3584 Library

TLIB3494 TLIB3584

Data MovementDuring Migration(SCSI or SAN)

IBM Tivoli Storage Manager Server

ARCH3494 ARCH3584

OFF3494(Copy Pool)

OFF3584(Copy Pool)

Off-site DataMovement

Off-site DataMovement

Copy Pool DataCannot beMigrated


Tape consolidationTape 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 librariesLarge 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.


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 don’t 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

BackupApplication B

Backup Application A

Library Control over TCP/IP

Drive

Drive

Drive

Drive

Library Control System

Data Path

Data Path

Data Path

Data Path

BackupApplication B


Library Control over TCP/IP

DriveDrive

DriveDrive

DriveDrive

DriveDrive


Data Path

Data Path

Data Path

Data Path


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


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.

Backup Server 2Library Client

Backup Server 1Library Manager

Data Path

Metadata over TCP/IP

Drive

Drive

Drive

Drive


Library Sharing Software

Data Path

Data Path

Library Control PathData and Library Control Path

inactive

inactive

inactive

Backup Server 2Library Client

Backup Server 1Library Manager

Data Path

Metadata over TCP/IP

DriveDrive

DriveDrive

DriveDrive

DriveDrive


Library Sharing Software

Data Path

Data Path

Library Control PathData and Library Control Path

inactive

inactive

inactive

Note: Keep in mind that every backup server needs administration.


Logical partitioning with tape librariesToday, 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.

Figure 6 Logical partitioning

The IBM 3584 UltraScalable tape library was IBM’s 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

Data and Library Control Path

Library Control PathDrive

Drive

Drive

Drive


Backup Application B


Data Path


Data Path

Library Control Path

inactive

inactive

logical partition 1

logical partition 2


Library Control PathDrive

Drive

Drive

Drive


Backup Application B


Data Path


Data Path

Library Control Path

inactive

inactive

logical partition 1

logical partition 2


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®. It’s also possible to implement software-based tape library sharing within a logical partition such as the one depicted in Figure 7 as Zone 3.

Figure 7 Multipath logical libraries in a switched fabric SAN

It’s 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.

iSeries App A

xSeries App B

pSeries App C

Multiple hosts owning separatelogical library slots and drives

DRIVE 1

DRIVE 2

Logical Library 1

Logical Library 2

Logical Library 3

Library Controller

DRIVE 3

DRIVE 4

DRIVE 5

DRIVE 6

Zone 3

Zone 2

Zone 1

SAN (with Zoning)SAN

(with Zoning)

Linux App C


Removable media managementOver 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.


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.

Libraries with integratedManagement (e.g., IBM 3494)

Media Management over TCP/IP

Media, Library and Drive Management

SANSAN

Control

Data

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

Removable Media Hardware

StreamingDevices (Drives)

Media ChangerDevices

SCSI/FC SCSI/FC

Removable Media Hardware

Media Changer Devices

Streaming Devices (Drives)

SCSI/FC Prop. Interface

Library Mgmt.

TSM ServerTSM ServerTSM Server






TSMServers

OtherApps

Other BackupServers

Tape Virtualization

RMM ServerRMM Server


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.

DB2DatabaseRemovable

Media Manager

Abstract Library Manager Interface

ATL LibraryManager

ATL LibraryManager

Offline LibraryManager

Offline LibraryManager


Figure 10 Media management in heterogeneous software environments

IBM Tivoli Storage Manager server consolidationIf 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, you’ll first have to examine some issues.

SAN

TCP/IP Network

Tape Library

…

Media ManagementResource SharingGrouping & Pooling

Backup Application BBackup

Application ABackup

Application X

DatabaseDrives

Slots


Figure 11 Consolidation fof IBM Tivoli Storage Manager servers

Case 1 - switch to a new serverBasically, 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 don’t 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 server’s 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.

Consolidation

Network Network

Network

Tivoli Storage Manager Server

Network

Tivoli Storage Manager Clients

OLD IBM Tivoli StorageManager Server Systems

NEW IBM Tivoli StorageManager Server Systems

Tivoli Storage Manager Clients




Tivoli Storage Manager Clients Tivoli Storage Manager Clients


Figure 12 Switching to a new server for consolidation

The database export and import functionIBM 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 client’s 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.

Network

OLD Tivoli Storage Manager Systems

NEW Tivoli Storage Manager System

dsmc -servername=old_tsm

OLD_Server IP Address 10.1.1.1

Tivoli Storage Manager server is fully consolidated after expired backup data

NEW_Server IP Address 10.1.1.3

Restore Data

dsmc -servername=new_tsm

servername old_tsm commethod tcpip tcpserveraddress 10.1.1.1 . .servername new_tsmcommethod tcpip tcpserveraddress 10.1.1.3 . .

dsm.sys (UNIX)

Backup Data


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.

IBM Tivoli StorageManager Server 1

Administrator

Server

Node

Policy

Export

IBM Tivoli StorageManager Server 2

Import


Exporting to sequential mediaServer 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 administrationThese commands move administrative data such as name, password, privilege classes, and administrator lock/unlocking information for server access.

Export/import nodeThese 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.


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 policyThese 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 serverThese 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 serverIf 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.


Figure 14 Exporting the data directory to a new server

Case 3 - export to sequential volumeThis 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.

export... toserver=NEW_SERVER

OLDStorage

Pool

OLDDatabase

NEWStorage

Pool

NEWDatabase

OLD Tivoli Storage Manager Server

NEW Tivoli Storage Manager Server

LAN


Figure 15 Export to sequential volume

VMware backup considerationsVMware 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.

export... devtype=...checkout libvol

OLDStorage

Pool

OLDDatabase

NEWStorage

Pool

NEWDatabase

OLD Tivoli StorageManager Server

NEW Tivoli Storage Manager Server

IntermediateVolume(s)

checkin libvolimport ... devtype=...


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.

Figure 16 Backup considerations on a VMware installation

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.

VirtualProcessor

VirtualNetwork

VirtualRAM

VirtualVideo

VirtualDisk

Virtual Linux Machine

VirtualProcessor

VirtualNetwork

VirtualRAM

VirtualVideo

VirtualDisk

Virtual Windows Machine

VMware Application / Virtualization Layer

Physical Hardware Architecture (x86)

Processor(s) Video Network RAM Disk

Backup client inside virtual machine allows forfile-level backups

VMware layer handles all translationand physical resource management

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


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 machine’s backup/archive client installation function can then be used to restore files to a more current version than the existing backup copy.


Figure 17 Mapping virtual volumes as physical files on a host 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.

Virtual Machines Physical Machine

C:\

C:\

D:\

/usr

/home

/filesystem1

/filesystem2

vm1/disk2.dsk

vm3/disk2.dsk

vm3/disk1.dsk

vm2/disk1.dsk

vm1/disk1.dsk


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:

[email protected]� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. QXXE Building 80-E2, 650 Harry RoadSan Jose, California 95120-6099 U.S.A.

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

AIX®ESCON®Eserver®Eserver®FICON®

ibm.com®IBM®iSeries™pSeries®Redbooks (logo) ™

Tivoli®TotalStorage®xSeries®

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.

®



http://www.ibm.com/redbooks/

http://www.ibm.com/redbooks/

http://www.redbooks.ibm.com/contacts.html

Technology

Storage migration and consolidation with ibm total storage products redp3888