ADSM-L

Re: VTS or san disk storage

2005-11-30 11:11:59
Subject: Re: VTS or san disk storage
From: "Dearman, Richard" <rdearm1 AT UIC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 30 Nov 2005 10:10:44 -0600
Your situation sounds even worse than mine.  When I lose a lun I only
lose that particular lun.  Other systems and luns on the controller are
still functional.  Although in order to get that lun back I must
shutdown every system connected to the controller then reboot the
controller and the lun comes back.  I was told later by HP that the
controller can only handle 6-9 I/O requests per lun per second.  I am
looking for other storage units that can handle more requests than that.
I noticed that I don't have this problem with IBM storage at least the
ssa's we don't have any IBM san storage.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Tab Trepagnier
Sent: Tuesday, November 29, 2005 5:20 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: VTS or san disk storage

Richard,

I share your pain.

We have an EMC Clariion CX500 SAN.  We have found that AIX in general,
and
TSM in particular, can just "hose" the sucker.

Your observations about write cache were echoed by EMC.  We had to turn
off write-cache on our TSM disk pool LUNs because the SAN storage
processors couldn't keep up with the incoming data rate and manage the
cache at the same time.

In our case, it manifested itself as a total network freeze!

Once our TSM server - a 2-way 6H1 - started writing to our five-disk
RAID-3 LUNs, the I/O would hog the SAN so that no other servers - like
our
domain controllers - would get any disk access.  Disk queue length on
the
DCs went to 50+.  With the DCs locked out of the disks, they couldn't
process DNS lookups, logins, etc. so our Active Directory LAN just hung.
The odd thing is that all our TSM disks are in their own disk pod; the
only thing shared between TSM and the remainder of the servers was the
internal fiber loops and the SPs.  There was no disk contention between
TSM and anything else.

We duplicated the problem when creating disk volumes in TSM.  We
duplicated the problem when our Windows-based Domino servers backed up
to
SAN-based disk pools.  We duplicated the problem when we copied a large
database from one Oracle server to another; both with data volumes on
the
SAN.  All of this occurred at data rates of about 50-55 MB/s.  We use
RAID-3 for TSM disk pools and RAID-5 for everything else.

With the write cache turned off we get more like 12 MB/s streaming to a
five-disk RAID-3 array.

So with TSM using the SAN as a major storage resource, we've had to give
up performance and reliability.  On the upside, at least it's only three
times as expensive as  tape!

Tab Trepagnier
TSM Administrator
Laitram, L.L.C.









"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 11/29/2005
09:48:08 AM:

> I have about 6TB of san disk space used for nightly backups and the
> management of it is just a pain.  For instance if you are using a
vendor
> such as HP for your san disks the compatibility with IBM equipment is
> not the greatest.  We use HP EMA 12000 with hsg80 san storage
> controllers.  TSM will max out the I/O to the san controllers then the
> particular lun will hang and then the san storage controller must be
> rebooted to get the lun accessible again to aix but even after the
> reboot the lun is available to aix but unreadable so now I lost all
the
> data on that lun.  I have run into this problem many times over the
past
> few years.  HP says disable caching at the controller level which may
> work but disk I/O will be extremely slow so that is not an option.
>
> You can attribute these problems to incompatible hardware but I would
> run what ever disk storage you choose through the ringer before you
> commit to it because I have had this problem with other san storage
> units as well.  We also keep disk storage in multiple locations across
> campus via long haul san connections which mean multiple luns to
manage
> and many filesystems which if you are in an HACMP configuration takes
> time for failover to occur and filesystem mounts to take place.
>
> In conclusion make sure what ever storage you choose is reliable and
> able to handle the high I/O load tsm will can on it.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of
> Paul Zarnowski
> Sent: Thursday, November 24, 2005 8:40 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: VTS or san disk storage
>
> At 11:33 AM 11/23/2005, Dearman, Richard wrote:
> >We currently use several TB of san based disk storage for our daily
> >backups which gets migrated during the day to multiple tape
libraries.
> >The san disk administration has become a nightmare [...]
>
> I am curious what kind of problems you are running into.  At the TSM
> Symposium at Oxford this year, IBM indicated that they were going to
> further develop the serial access disk support in TSM.  And, TSM 5.3
> just added the ability for a SAD devclass to span multiple
> filesystems.  After hearing this, we have been leaning towards
> investing in inexpensive disk managed by TSM rather than buying a VTL
> appliance.  I'm interested in other's comments about where,
> specifically, they are having problems managing SAD directly by TSM.
>
> ..Paul
>
>
>
> --
> Paul Zarnowski                            Ph: 607-255-4757
> Manager, Storage Systems                  Fx: 607-255-8521
> 719 Rhodes Hall, Ithaca, NY 14853-3801    Em: psz1 AT cornell DOT edu
>
> **************************EMAIL DISCLAIMER***************************
>
> This email and any files transmitted with it may be confidential and
are
> intended solely for the use of the individual or entity to whom they
are
> addressed.  If you are not the intended recipient or the individual
> responsible for delivering the e-mail to the intended recipient, any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it, is strictly prohibited.  If you have received
this
> e-mail in error, please delete it and notify the sender or contact
Health
> Information Management 312.413.4947.
>
>

<Prev in Thread] Current Thread [Next in Thread>