Storage migration and consolidation with ibm total storage products redp3888

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 1

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.

2 Storage migration and consolidation with IBM TotalStorage products

Application Application Application
Server Server Server

SAN Volume Movement of data from
Controller installed old volume to new disk
SAN SAN and old storage SAN and reduction of old
mapped as virtual volume space from
volume to the server virtual volume

Virtual SAN Volume Controller Virtual SAN Volume Controller
Volume Volume Volume

New New
Disk Disk

Existing volume with
application data is
SAN-attached 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 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 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.


Node1 Node3

Node2 Data Movement During
Move Nodedata (SCSI or SAN)

Node4

Old IBM 3584
Library Library

IBM Tivoli Storage Manager Server

Database

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

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


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.

Data Movement
ARCH3494 ARCH3584
During Migration
(SCSI or SAN)
TLIB3494 TLIB3584

IBM 3494 Library IBM 3584 Library

IBM Tivoli Storage
Manager Server Off-site Data
Off-site Data
Movement Movement

Copy Pool Data
OFF3494 Cannot be OFF3584
(Copy Pool) Migrated (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.


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.


Library Control over TCP/IP
Library Control System

Drive
Data Path

Drive
Data Path

Backup
Application A

Drive
Data Path

Drive
Data Path

Backup
Application B

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


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.


Metadata over TCP/IP Library Control System

Library Sharing Software

Drive
Data and Library Control Path Library Control Path

Drive
Data Path inactive

Backup Server 1
Library Manager
Drive
Data Path inactive

Drive
Data Path inactive
Backup Server 2
Library Client

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.


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

Drive

Drive
Data Path inactive
Backup Application A logical partition 1
logical partition 2

Drive

Drive
Data Path inactive
Backup Application B

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


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.

Library Controller

DRIVE 1
Logical Zone 1
Library 1 iSeries App A
DRIVE 2

DRIVE 3 SAN
(with Zoning)
Logical xSeries App B
Library 2 Zone 2
DRIVE 4

DRIVE 5 Zone 3

Logical
Library 3
pSeries App C
DRIVE 6

Multiple hosts owning separate
logical library slots and drives
Linux App C

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.


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.


Media Management over TCP/IP

Contr
TSM Other Other Tape Virtualization
Servers Backup Apps
Servers

ol
TSM Server TSM Server TSM Server

Media, Library and
Drive Management
Data

RMM Server

SAN

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

SCSI Libraries without built-in Removable Media Hardware
Management (e.g., IBM 3584)
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.


Removable
DB2
Database Media Manager

Abstract Library
Manager Interface

ATL Library Offline Library
Manager 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.


Backup
Backup Backup
Application B
Application A Application X
TCP/IP Network

…

Media Management
Resource Sharing
Grouping & Pooling
SAN

Drive Slots Database
s

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, you’ll
first have to examine some issues.


OLD IBM Tivoli Storage NEW IBM Tivoli Storage
Manager Server Systems Manager Server Systems

Tivoli Storage Tivoli Storage

Consolidation
Manager Server Manager Server

Network

Network

Tivoli Storage Manager Clients

Tivoli Storage Manager Clients

Tivoli Storage Tivoli Storage

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


OLD Tivoli Storage NEW Tivoli Storage
Manager Systems Manager System
Tivoli Storage Manager server
is fully consolidated after
OLD_Server expired backup data
IP Address 10.1.1.1

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


IBM Tivoli Storage IBM Tivoli Storage
Manager Server 1 Manager Server 2
Administrator

Server

Export Import
Node

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.


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.


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.


export... toserver=NEW_SERVER

LAN

OLD NEW
Database Database

NEW Tivoli Storage
OLD Tivoli Storage Manager Server
Manager Server

OLD NEW
Storage Storage
Pool 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.


OLD Tivoli Storage NEW Tivoli Storage

OLD NEW
Database Database

OLD NEW
Intermediate
Storage Storage
Volume(s)
Pool Pool

export... devtype=... checkin libvol
checkout 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.


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 Windows Machine

Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual
Processor Video Network RAM Disk Processor Video Network RAM 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


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.


/usr
/filesystem1

/home vm1/disk1.dsk

vm1/disk2.dsk

vm3/disk2.dsk

C:

/filesystem2

C: vm2/disk1.dsk

vm3/disk1.dsk

D:

Virtual Machines Physical Machine

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.


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.


Storage migration and consolidation with ibm total storage products redp3888

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie Storage migration and consolidation with ibm total storage products redp3888

Ähnlich wie Storage migration and consolidation with ibm total storage products redp3888 (20)

Mehr von Banking at Ho Chi Minh city

Mehr von Banking at Ho Chi Minh city (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Storage migration and consolidation with ibm total storage products redp3888