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. > >
