ADSM-L

Re: AW: [ADSM-L] Migration Speed Has Plummeted

2005-08-19 11:56:54
Subject: Re: AW: [ADSM-L] Migration Speed Has Plummeted
From: Ben Bullock <bbullock AT MICRON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 19 Aug 2005 09:56:25 -0600
        Hmm, my suggestions were made assuming she would put the raw
devices into a typical storage pool of a "DISK" type. 

        I saw the discussion about the serial/random disk usage and the
SATA, and how it could be the reason for her performance problem, and I
was buying that reasoning until she showed us how she had created her
volume. 

        I ~believe~ she is taking 10+ LUNs, combining them into 1
logical volume, creating a filesystem on the volume, likely doing a
'dsmfmt' and then putting it into a storagepool with a type of "DISK".
(one of her screen shots definitely showed the storagepool was "DISK")

        Once I saw that, I could see why her performance was poor, every
concurrent session migrating from that diskpool will access that one
volume at the same time, causing all the LUNS underneath to be busy at
the same time, causing a lot of head contention.(as per my earlier email
about TSM's round-robin access of volumes in a Storagepool). Seeing that
configuration, I think that the underlying SATA disks are the root
problem, but her aggregating them into 1 huge volume is the reason.
        
        I believe she will see somewhat better performance if she
migrates all the data off her current 1TB storagepool volume, removes
the volume from the storagepool, unmount the filesystem, removes the
filesystem and the underlying LV, creates volumes with a 1-to-1
LV-to-LUN relation and the defines all those raw LVs into the
storagepool. 

        The pain would be getting all the data migrated off that one
volume, but once all the data is migrated off the vol, it's not a lot of
work a the AIX level to take the vol apart and put it back together. I
would suggest she try this before changing the filesystem to a type of
"FILE" and then encountering the additional "gotchas" that I have read
in this listserv having to do with reclamations and aggregates.

My 2-cents, 
Take it with a grain of salt, preferably while it is on the edge of a
Margarita glass. ;-)
Ben
 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Stapleton, Mark
Sent: Thursday, August 18, 2005 9:45 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: AW: [ADSM-L] Migration Speed Has Plummeted

FYI, per the TSM manual, raw filesystems should *not* be used in a
file-based disk pool. At this time, file-based disk pools are the way to
go with SATA disks (performance-wise).

--
Mark Stapleton (stapleton AT berbee DOT com)
IBM Certified Advanced Deployment Professional
  Tivoli Storage Management Solutions 2005 IBM Certified Advanced
Technical Expert (CATE) AIX Office 262.521.5627

 

>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
>Of Leigh Reed
>Sent: Wednesday, August 17, 2005 5:16 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: AW: [ADSM-L] Migration Speed Has Plummeted
>
>Joni,
>
>If you read Ben Bullock's recent posting, I agree with everything he 
>has said. I would definitely use raw disk volumes (in a Unix world).
>
>
>Leigh
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
>Of Joni Moyer
>Sent: 17 August 2005 20:31
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: [ADSM-L] AW: [ADSM-L] Migration Speed Has Plummeted
>
>Hi Leigh,
>
>I have just added EMC fibre channel disk from a CX700 in the following 
>pieces of physical disk under the filesystem /tsmdev/stgpool1
>
>CHRS044     /tsmdev/stgpool1
>
>lun 175           100 GB
>lun 178           100 GB
>lun 181           100 GB
>lun 184           100 GB
>lun 187           100 GB
>lun 190           100 GB
>lun 193           100 GB
>lun 199           100 GB
>lun 204           100 GB
>lun 210           100 GB
>
>Total       1000 GB
>
>When you stated using many small TSM disk storage pool volumes, would 
>anyone happen to know what a good, acceptable size TSM volume would be?
>Thanks!
>
>********************************
>Joni Moyer
>Highmark
>Storage Systems
>Work:(717)302-6603
>Fax:(717)302-5974
>joni.moyer AT highmark DOT com
>********************************
>
>
>
>             "Leigh Reed"
>             <L.Reed AT MDX.AC DOT UK
>             >
>To
>             Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU
>             Dist Stor
>cc
>             Manager"
>             <[email protected]
>Subject
>             .EDU>                     Re: AW: [ADSM-L] Migration Speed
>                                       Has Plummeted
>
>             08/17/2005 10:39
>             AM
>
>
>             Please respond to
>             "ADSM: Dist Stor
>                 Manager"
>             <[email protected]
>                   .EDU>
>
>
>
>
>
>
>Joni
>
>The following URL is to the TSM V5.3 Technical Guide Redbook.
>
>If you go to section 3.4.6, it discusses some changes in TSM 5.3 that 
>lend themselves to 'disk only backups'
>Obviously, if you're not at 5.3 yet, then they may not be of use to 
>you.
>
>I personally would consider SATA disk as a possible replacement to 
>sequential tape, but I would still use good quality fast disk as 
>traditional 'random' disk pool to stage the nightly backups. I think 
>that it is widely recognised that significantly 'slicing up' the 
>diskpool into a large number of smallish volumes, greatly improves 
>performance (certainly on the backup). I believe that this is because 
>of the 'multi-threaded' nature of TSM.
>
>I would imagine that the config for the best performance of SATA disk 
>as random TSM backuppool, would be to configure each SATA disk as a 
>single TSM volume within the backuppool and ensure that you have enough

>SATA disks/backuppool volumes as you have sessions in at the same time.
>
>However, with SATA disk capacity increasing rapidly, it's not efficient

>to have a 100 x 250GB SATA disks (100 TSM volumes) sitting in your 
>backuppool, that only ever get 10% utilised.
>
>I must state that this is just my opinion, I have no direct experience 
>with SATA disks.
>
>Leigh
>