TSM Server on a p590/595/570 LPAR

[moon-buddy]

Quick one:

Has anyone installed a TSM Server in production mode on a separate LPAR with a p590/595/570?

Logically looking at it, there seems to be no technical issue in doing so; but is this even supported? Sounds logical: all that must be done is provide the LPAR that the TSM server resides on its own I/O, dedicated network connections, etc.

Thoughts?

 

[zatogo]

While I haven't done the actual creation of the LPAR...I have installed a number of TSM instances on separate LPARs...in fact, I have a customer in Chicago with a 570 currently configured as 5 LPARs...each with its own TSM Server instance.

As you mentioned...assigning an adequate amount of resources (fiber ports, ethernet ports, processor amount, memory, etc) is key.

 

[cwilloug]

Moon - That's how thing's were set up here, p570 with HMC, and just one install of TSM on it. The old admin was going to put a test TSM instance on there to, but never got around to it.

 

[heada]

I've done it on a p520 (p550/p560/p570/p575/p590/p595 are all the same, just bigger) As far as TSM knows, it is a different server than any other LPAR. You'll need resources allocated to the LPAR (network, HBAs, storage, CPU, RAM, etc) or set it up via VIO (not recommended as TSM is high I/O)

-Aaron

 

[moon-buddy]

Thanks guys.

Right now, I have my system on an aging p520. The logic of having it on a p590/595 is to lessen the footprint in our Data Center.

My only concern at this point is the disk allocation for the TSM Database. As it stands, the most likely scenario is to have the DB disk on a SAN. I do have issues with this. I prefer a system that is self-contained, and would not be affected by any maintenance routines other than its own.

Any insights?

 

[BBB]

You could always mirror the db disks to internal disks as well. Or you could just mirror the logs to internal disk, that way you could do a point in time recovery if the san disks die (restore db, roll forward from internal mirror of log). Still won't stop the system being affected by maintenance though, but you'll probably get better performance out of the san disks if they're decent.

 

[heada]

Ask for mirroring between SAN disk devices since you're already tied to the SAN for access to the tape devices. With them mirrored between two different disk devices they can take the path to one of the devices down and you'll continue to work correctly.

-Aaron

 

[ckeeney]

We have a p595 with 21 LPAR's running on it, one of these LPAR's does contain the TSM Server. It is connected to an IBM DS8100 SAN storage unit where all drives exist. We have no problems here.

 

[zatogo]

I'm slowly warming up to the idea of putting the TSM DB Volumes on SAN disk -- most of my counterparts in the consulting firm I work for do this.

I'm still a little leary about it because two of my customers (which I suppose is not that many) over the past five years have had "incidents" where their TSM DB got corrupted and had to be restored from tape.

 

[sra006]

P570 setup for tsm

We've used P570 for over 3 yesrs and had a very good record for
performance and reliability.
The setup uses 6 instances on P570 lpar with 6 cpus and 6 network gigabit cards combined into an etherchannel. one instance is used as a library manager the rest are library clients.
(we have 4 3584 libraries with total of 84 drives).
The databeses, log and stgpools are on Hitachi ams1000 and we set them up as raw devices.
If you allocate luns on AMS or any SAN unit size them corresponding to the log db or stgpools files. I.E our log volumes are 13G lun, DB volumes - 20G luns, stgpools - 100G.
We use tsm mirror for logs and db and aix mirror for stgpools.
Last year we have added another P570 LPAR and made a cluster for two lpars
Regards,
Al.

 

[BrianP]

TSM on a LPAR

We currently run TSM on LPAR's in 2 P570's with the DB connected to SAN disk. We have no issues with either the LPAR's or the SAN disk (knock on wood), even after one of the SAN switches got fried. The nice thing about the P5's is that you can now do concurrent firmware upgrades, reducing the downtime requirements. As for concerns about LPAR's, I have been running them since 1999, and have never had an unscheduled downtime due to a hardware failure. Now that i think of it, I don't think I have ever had a LPAR'able box down for a hardware failure.
If you are concerned about using a SAN, make sure that you have quality SAN design such as 2 seperate SAN fabrics, proper zoning, quality SAN arrays with a minimum of n+1 redundancy and mirror your DB.

 

[moon-buddy]

Brian,

Technology wise, there is no issue with running TSM on an LPAR. What cautions me to do it is the non-isolation of backup system with the rest of the Production system most especially with a SAN holding the DB and/or storage pools.

I have been in and around SANs but I am totally 100% not sold with the idea of having one single point of failure for DR and Production environments.

Ed

 

[BrianP]

Ed,

I agree with you on the concerns of housing TSM on the same system as those that you are protecting. The reality of it, I guess, is that most companies are trying to reduce the overall footprint of the data center as you have stated. With this, as you are doing, we have to assess the risk of consolidation. In our case, the LPAR servers are much more durable than the stand alone servers, as they seem to be designed with more resilliency. If I only had a single LPAR server and had most of my production systems on it, I would definitly agree with you and I would keep TSM seperate (we happen to have 9 LPAR'able frames). Nowadays, I am more concerned with have all the same equipment in the same physical area of the data center (Like clustered servers in the same rack). From a SAN perspective, we have shared storage arrays with other production systems in past, but today we currently have all the TSM storage pools on their own storage arrays (SAN attached)-- more for performance reasons.

If you would like to get into more detail on availability, send me an e-mail.

Brian