> The disk solution presented to me was a server/controller with a 36TB disk > array behind it. The server/controller would be connected via the OSA > Express3 10GbE.
If it's presented via an OSA, then you're dealing with either NFS or iSCSI, not FCP. In that case, it shouldn't matter at all who made the storage box. IP packets are wonderfully vendor-neutral -- one of the very nice things about network attached storage. In the past, TSM has not performed well with NFS-mounted filesystems. iSCSI (IMHO) is probably the better choice. Plan to dedicate an OSA triplet to the back-end disk traffic, and probably attach the triplet directly to the Linux guest running the TSM server. TSM is not efficient about disk usage optimization, so that connection will get a LOT of use. Making zVM process that traffic through a vswitch isn't pretty. > Yes, we know the channel attached tape drives aren't available in zLinux. > We are evaluating keeping all TSM storage pool data on disk. Keep in mind that data is heavily cached in RAM on Linux, and there is limited support for write-through (none at all on NFS). You *will* have both database and data file storage integrity problems if you get a unclean failure of the TSM server in an all-disk environment. Been there, done that, hated every second of it. If you're planning on relying on replication of data inside the storage array as your "backup copy", remember that the storage box can't replicate data that isn't written to the array yet - -and data in Linux buffer cache isn't written to the array yet. You also lose one of the best features of TSM (the automated migration to cheaper near and offline storage). It (all-disk configuration) works, but you're going to create yourself some interesting DR chicken-egg problems. > >The Linux TSM code is far less efficient than the z/OS (and z/VM) TSM > code was. Expect a >fair increase in CPU usage. > > I saw that in a pdf sent by TSM support. The pdf says: > "IBM does not plan to support TSM v6 server on z/OS > Why? > Increase cycle usage for v6 compared to v5, for the same workload > New TSM features such as server-side deduplication could drive even > higher > processor utilization." No "could" about it. You *will* see increased CPU utilization. The only plus to the Linux on Z version is it'll be IFL cycles instead of your CPs. > Our only upgrade option is to either AIX or zLinux. > We don't have AIX and would rather keep > the work on the zSeries. As Aria said, I'd investigate Intel Linux options for this. The Windows TSM server won't cut it, but given the raw MIPS orientation of the current TSM code base, you're better off getting the database and data transfer management pieces off the Z box entirely, and the Intel Linux TSM code works just as well with the TSM for z/OS Media code as the Linux on Z version. TSM development really needs to buy a clue on the channel-attached tape bit. I get it that running the TSM server on z/OS probably no longer makes sense, but it's just dumb to not support hardware the customer has already paid for. The method they used to support tape on TSM/VM would work fine for the Linux version... but there I go making sense again. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
