ADSM-L

Re: [ADSM-L] Move data from DISK pool to FILE pool

2009-07-29 03:41:12
Subject: Re: [ADSM-L] Move data from DISK pool to FILE pool
From: Grigori Solonovitch <G.Solonovitch AT BKME DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 29 Jul 2009 10:39:38 +0300
Hello Steven,
We have IBM DS8100 with:
  - 146GB Enterprise disks (RAID5) for data;
  - 500GB FATA (RAID5) for backup and archive data;
  - 900GB FATA (RAID6) for backup and archive data.
DS8100 is shared by nodes and TSM Server using different arrays for data and 
backup data.
Regards,

Grigori G. Solonovitch

Senior Technical Architect

Information Technology  Bank of Kuwait and Middle East  http://www.bkme.com

Phone: (+965) 2231-2274  Mobile: (+965) 99798073  E-Mail: G.Solonovitch AT bkme 
DOT com

Please consider the environment before printing this Email


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Steven Langdale
Sent: Wednesday, July 29, 2009 8:57 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Move data from DISK pool to FILE pool

Hello Grigori

What SAN have you got, and is it shared storage?  I ask because there has
been discussion on FS fragmentation but surely this is meaningless if your
using a SAN.

Steven Langdale
Global Information Services
EAME SAN/Storage Planning and Implementation
( Phone : +44 (0)1733 584175
( Mob: +44 (0)7876 216782
ü Conference: +44 (0)208 609 7400 Code: 331817
+ Email: steven.langdale AT cat DOT com





Grigori Solonovitch <G.Solonovitch AT BKME DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
29/07/2009 06:37
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] Move data from DISK pool to FILE pool




Caterpillar: Confidential Green Retain Until: 28/08/2009



Hello Christian,

Thank you very much for your proposal. I understand that it is much easier
to use migration, but I am still going to use procedure based on data
movement because of:
     1) migration is totally controlled by TSM Server and depends on
number of nodes and number of migration processes. I am afraid to overlap
migration activity and backup/restore operations. TSM Server can be
overloaded because both the source and target storage pools are on SAN
disks with very high performance. Data movement is manually controlled and
can be done at time with minimal backup/restore activity (for example, at
the weekends);
     2) unfortunately there are limitations in disk space. I am not able
to allocate FILE storage pool with the same size as DISK storage pool
initially. I am planning to move raw logical volumes selectively to
release SAN data volume from DISK pool, allocate it to FILE pool and
continue process like this till all data will be moved.

We are converting DISK pools to FILE pools as a preparation to upgrade to
TSM 6.1 with de-duplication. We hope to save some disk space in primary
storage pools and increase expiry period for data. Unfortunately, another
option based on IBM VTL hardware with de-duplication is very costly (high
available VTL, upgrade existing old libraries and stop using old SSA disks
at Head Office and Disaster Site is approximately $1,000,000). So we have
no choice nowadays.

In addition, I have discussed all disadvantages of using file systems for
primary pools with IBM. According to IBM:
1) using JFS2 file system will reduce risk in general, because it is much
better than old JFS file system;
2) all virtual volumes have to be allocated manually and sequentially to
avoid fragmentation (maxscratch=0);
3) file system utilization have to be kept as close as possible to 100% to
prevent any possibility of fragmentation.
I understand it will be real headache to monitor and control FILE storage
pools in this case, but I have no choise.

Thank you very much for all other comments and proposals for my request.

Kindest regards,

Grigori G. Solonovitch

Senior Technical Architect

Information Technology  Bank of Kuwait and Middle East
http://www.bkme.com

Phone: (+965) 2231-2274  Mobile: (+965) 99798073  E-Mail:
G.Solonovitch AT bkme DOT com

Please consider the environment before printing this Email


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Christian Svensson
Sent: Tuesday, July 28, 2009 3:30 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] SV: Move data from DISK pool to FILE pool

Hi,
If I where you I should like this instead.


1) Rename your old Diskpool
2) Create your File Pool with the same name as the old Diskpool
3) Update your Diskpool with HIGH=0 LOW=0 and NEXT=FILEPOOL (Disable Cache
also if you have any)
4) Wait 2-3 days
5) Delete all Volumes in your DISKPOOL and Delete DISKPOOL

Now will you migrate the data and you can still backup to your new STG
POOL with any issue an no extra work for you.

But why do you wanna move to FILE CLASS? Do you wanna use De-duplication?
You know you will delay your backups and get a lot of fragmentation if you
don't pre-create all Volumes? This has nothing with TSM really, but most
of the issue is the filesystem, TSM need to create the file first before
TSM can save any data to that volume, and that will create a delay.
If TSM creates multiple volumes, then will you get fragmentation.
I normally don't recommend anyone to have FILE CLASS as first storage
pool. I only use that if a customer want to have a VTL but don't have any
money to buy a real VTL.

Best Regards
Christian Svensson

Cell: +46-70-325 1577
E-mail: Christian.Svensson AT cristie DOT se
Skype: cristie.christian.svensson
________________________________________
Från: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] f&#246;r Grigori
Solonovitch [G.Solonovitch AT BKME DOT COM]
Skickat: den 28 juli 2009 12:35
Till: ADSM-L AT VM.MARIST DOT EDU
Ämne: Move data from DISK pool to FILE pool

Dear TSMers,
We have TSM 5.5.1.1 under AIX 5.3.
I need to move data from DISK primary storage pool (raw logical volumes)
to FILE primary storage pool (JFS2 file system).
There are 3 tape copy pools for DISK primary pool.
I am going to use next procedure:
1) create FILE primary storage pool with appropriate size;
2) move data from DISK primary storage pool to FILE pool by "move data
<vol> stg=<FILE> reconstruct=no" (volume by volume);
3) delete DISK primary storage pool;
4) rename FILE storage pool to old DISK pool name.
My expectations:
1)     all existing tape copy pools, made for DISK pool, will be still
legal for FILE primary storage pool (no need to make extra backups and it
is possible to restore any data in FILE storage pool);
2)     no need to modify any copy groups connected to old DISK pool
because of the same storage pool name;
3)     expiry process will continue to work normally;
4)     full/incremental backup history will be untouched by data movement.
Am I right?
I will deeply appreciate any comments.
Thank you very much in advance.
Kindest regards,


Grigori G. Solonovitch

Senior Technical Architect

Information Technology  Bank of Kuwait and Middle East
http://www.bkme.com

Phone: (+965) 2231-2274  Mobile: (+965) 99798073  E-Mail:
G.Solonovitch AT bkme DOT com<mailto:G.Solonovitch AT bkme DOT com>

Please consider the environment before printing this Email


Please consider the environment before printing this Email.

________________________________
"This email message and any attachments transmitted with it may contain
confidential and proprietary information, intended only for the named
recipient(s). If you have received this message in error, or if you are
not the named recipient(s), please delete this email after notifying the
sender immediately. BKME cannot guarantee the integrity of this
communication and accepts no liability for any damage caused by this email
or its attachments due to viruses, any other defects, interception or
unauthorized modification. The information, views, opinions and comments
of this message are those of the individual and not necessarily endorsed
by BKME."

"This email message and any attachments transmitted with it may contain 
confidential and proprietary information, intended only for the named 
recipient(s). If you have received this message in error, or if you are not the 
named recipient(s), please delete this email after notifying the sender 
immediately. BKME cannot guarantee the integrity of this communication and 
accepts no liability for any damage caused by this email or its attachments due 
to viruses, any other defects, interception or unauthorized modification. The 
information, views, opinions and comments of this message are those of the 
individual and not necessarily endorsed by BKME."