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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] On Behalf Of > Tab Trepagnier > Sent: Tuesday, November 29, 2005 5:20 PM > To: ADSM-L@VM.MARIST.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@VM.MARIST.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:[EMAIL PROTECTED] On Behalf > Of > > Paul Zarnowski > > Sent: Thursday, November 24, 2005 8:40 AM > > To: ADSM-L@VM.MARIST.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: [EMAIL PROTECTED] > > > > **************************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. > > > > >