ADSM-L

Re: SUN F6800's

2003-05-07 20:37:04
Subject: Re: SUN F6800's
From: "Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 7 May 2003 20:35:52 -0400
In my opinion, you will run out of IP stack and CPU before you ever kill the
LTOs or the Hitachi disk.  Put your TSM database on the Hitachi!  2500
clients are going to create a huge TSM database.  You need to look at that.
You will need all the speed you can get to backup the TSM database in a
reasonable amount of time.  I would use the JBODs for mirrored RAID
sequential storage pools or if you are gutsy RAID 0 unprotected before I
would use the Hitachi for that.

We have a SF6800 and 2 SF4800s.  I would never run TSM Server on SUN unless
I am using it for a snapshoted filesystem mount.  For one of our SF4800s we
are doing that, but it is not implemented yet.  The TSM server of choice is
AIX.  However, it may be much better with the new Solstice DiskSuite.  We
have converted from Veritas Volume Manager and VxFS to Solstice DiskSuite
and find the performance fine on UFS File Systems.  We moved the data from a
Shark F20 to a Shark 800 and a SF6800 using (4) 3590 E1A drives in a SAN
backup configuration of an SAP database 1.5TB (750GB actual data) runs in 1
hour and 40 minutes.  There were only 4 disk paths and 2 tape paths (SUN
Qlogic HBAs).  When we change it to 6 drives it runs in 1 hour and 30
minutes or 500GB/hr.  Essentially, we maxed out the tape paths.  Our SAN is
only a 1 Gig McData SAN so that slows things down as well.  I do not know of
anyone that has saved a SAP Database at a rate of 500GB/hr using TSM with
this minimal of a tape configuration.  The SUN Local folks had never seen a
backup run that fast.

Now for the sticky wicket.  The SunFire x800 series cPCI and cPCI "IO Boats"
have a design flaw that cause them to hard crash when using an IO intensive
application like TSM on them.  SUN had to replace one of our 3800s with a
4800 and replace the IO boats in the 6800 and 4800.  I have never seen a
machine crash that hard, no diagnostics, no core, no panic.  Apparently,
there is a center-plane parity condition.  It took SUN about a week to
figure out that TSM, our Shark, and Solaris were not the problem.
Apparently, about 5 customers have experienced this.

-----Original Message-----
From: Zlatko Krastev/ACIT [mailto:acit AT ATTGLOBAL DOT NET]
Sent: Wednesday, May 07, 2003 5:22 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: SUN F6800's


If all those 2500 systems are workstations and the daily load is spread
evenly across or you want everything to go to disk first, then you will need
several LAN adapters and several FC adapters for those 10 TB diskpools.

But if among these systems you have big servers - go for LAN-free. If you
can shave off 4-5 TB of the load to go direct to SAN the task can be solved
without going to F6800. If backups must go to disk first you can still
consider SANergy + LAN-free to a filepool (but each migration from
sequential filepool will use only one drive and you have to use several
filepools).

Can you provide information how these 6TB/daily are distributed?

Zlatko Krastev
IT Consultant






"Reiss David IT751 (ext-CDI)" <david.reiss AT SIEMENS DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> 05.05.2003 
23:59
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: SUN F6800's


Yeah.  More info:

I'm looking to do about 6 TB of data backed up per day, into a library with
a capicity of around 400 TB (20 LTO2 drives in a Storage Tek 5500 most
likely).  About 2500 systems to backup total.

This will run intergrated into a SAN environment (HP XP1024) with roughly 10
TB of disk reservered for TSM Disk Storage Pools, and the SF6800 will also
have a Fibre JBOD attachement (probably storedge 3510 -- 12 x146GB disk) for
the TSM database and logvolumes.  I'm going to be backing up to the disk
pools first, and then migrating to tape later.

The reason we have been looking at the SF6800 is the simple fact that we can
load it up with fibre cards for attachment into the SAN switches so that we
can use the SAN for as much of our backups as possible.  Our current XP1024
(really Hatachi 9980 disk under the hood) is about 50 TB of total disk
storage, with I'm told, plans for it to be about 140 TB in the next year to
18 months.  There are multipule SAN switches built in here, so we should be
able to do more than the 2G SAN speed due to the mulipule feeds from various
switches.

Basically, SUN tells me that we should be able to jam the 6800 with IO out
the ying-yang.  I am wondering if they are correct for a TSM setup.

We'll be intergating this with our current soluation of two old H70's and a
3494 with 28 3590E1A drives with a capicity of about 100 TB. The problems
with it being that we are always processor and RAM limitiation of the
servers.  All Fibre attached with about 5 TB of disk in the SAN now.

I want the choke point of the backup systems to be the tape Drives and SAN
disk, so that when we do reach limits... we won't have to worry about
needing new servers or more RAM...  I want to be able to know that we can
just drop some more tape drives or more disk into place, and run with it.
Scalibility is very important here.

I don't mind overkilling something to a point, but the 6800 does almost seem
to be overkill to me.  Half my issue with it is sitting back and thinking
"So, they want to sell me a 6800.  Just go with it." Followed by weird
ToolMan grunting.   :-)

The IO requirements are what appears to be driving me toward it.  The
processors and RAM... while nice... those aren't driving factors.

Thank you,

David N. Reiss
TSM Support Engineer
david.reiss AT siemens DOT com
407-736-3912


-----Original Message-----
From: Cowperthwaite, Eric [mailto:eric.cowperthwaite AT EDS DOT COM]
Sent: Monday, May 05, 2003 4:13 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: SUN F6800's


David,

The majority of our TSM servers run on Sun workgroup platforms, ranging from
E420R's to V480 and V880 machines. We have one on an E3500, but the V880 has
more I/O capacity than an E3500. Bottom line, you probably are wasting money
on an SF6800, although maybe we could give a bit more insight if we knew
what your I/O requirements were.

Eric W. Cowperthwaite
EDS Operations Solutions
California Medicaid (Medi-Cal)
eric.cowperthwaite AT eds DOT com


-----Original Message-----
From: Reiss David IT751 (ext-CDI) [mailto:david.reiss AT SIEMENS DOT COM]
Sent: Monday, May 05, 2003 7:41 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: SUN F6800's

Is anyone out there running a TSM Server on a dedicated Sun F6800 machine?
We are sizing our servers for replacement and in sizing IO Requirements with
Sun, TSM, and Storage Tek, we're being directed at the F6800 (which almost
seems like overkill to me) by our vendors.

I was thinking that the V880 or V1280 would be where they would end up
putting us, but the costs of a couple of V1280's or one F6800 with two
domains seem to be about the same.  So, is anybody out there using a very
large machine like the F6800 dedicated to its existance as a TSM server, and
are you experiencing any problems with them?

Normally, I have worked with large RS/6000 AIX machines but my current
company doesn't like AIX, so I'm running with the Solaris bulls now.

Thanks,

David N. Reiss
TSM Support Engineer
david.reiss AT siemens DOT com
407-736-3912

<Prev in Thread] Current Thread [Next in Thread>