On a related note (if somewhat off-topic)
Can somebody point me to a mailing list/resources for Enterprise Storage
Servers?
Recently I "inherited" the administration of an ESS F20 for no other reason
than the fact that I use space of it for my TSM disk pools (and the fact
that the current admin left in a hurry).
This is a nice, sturdy system but the admin software is idiosyncratic to say
the least and while I wait for the training to be approved, I'd like to have
a place I can turn to for tips and stuff.
(Thank god for the support contract, or I'd simply leave those "message"
lights on until smoke comes out of the cabinet)
I appreciate any pointers you can give me.
Regards
Rafael
On 11/30/05, Dearman, Richard <rdearm1 AT uic DOT edu> wrote:
>
> 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.
> >
> >
>
|
