Thanks Andy (and the resto of you who've responded).
I'm taking the two drives per HBA with a grain of salt :-)
If you follow the recommendations to the letter -- not more than two drives
per HBA and only one HBA on a dedicated PCI bus you find you're limited to a
maximum of 24 drives per TSM server (I think the current systems max at 4
I/O drawers per system, and three PCI buses per drawer -- I *could* be a bit
behind the times :-)
While I'm currently getting 5 to 1 compression on my SAP/Oracle database, I
have a bit of difficulty believing I could actually drive four tape drives
at 150 MB/sec from the same system. This is why I'm willing to put three
drives on the same fiber.
The current concept is two dedicated hubs, each with three drives and a
connection to one of my two switches. If the hub price is higher than I
expect, they may become an 8 port switch with all six drives and a
connection to each of the other two switches (I don't like the single point
of failure here). Worst case, I don't do either and run directly from the
tape drive to my existing switches -- I have the ports to cover this, if the
rest of the team doesn't get too creative in budgeting next year's hardware.
I will be isolating the tape and disk to seperate HBAs. My TSM server is
also my SAP DB HA fallover system, so I'll have two HBAs for SAP and two for
TSM tape drives.
This should keep us going until the next major server swapout two years from
now.
Tom Kauffman
NIBCO, Inc
-----Original Message-----
From: Wilcox, Andy [mailto:andy.wilcox AT AQUILA-NETWORKS.CO DOT UK]
Sent: Thursday, September 11, 2003 4:24 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: How have you got your fiber-attached LTO drives connected
to your TSM server?
One consideration to make here is that the IBM recommendation for Fibre LTO
drives is no more the 2 per HBA. Although taking into consideration that
this was with LTO1 drives on 1Gb FC HBAs, I would assume you could get away
with up to four LTO1 drives per 2Gb FC HBA, but only 2 LTO2 drives per 2Gb
FC HBAs.
Another consideration is that you should isolate tape only traffic to the
HBA's serving the drives. Ideally you could have a separate zone on your san
switches to serve exactly this purpose (or even have dedicated switches for
serving the tape drives should costs allow).
As for the ideal of switches or hubs... You should definately go for
switches and not hubs. A switch will let you run pretty much full bandwidth
across all connected devices whereas a hub is just a looping device so your
max throughput is the speed of the SAN, eg 2Gb per second.
Hope this provides you with some more food for thought!
Cheers
Andy Wilcox
Midrange Services
Aquila Networks Services Ltd
> -----Original Message-----
> From: Tom Kauffman [SMTP:KauffmanT AT NIBCO DOT COM]
> Sent: 10 September 2003 17:39
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: How have you got your fiber-attached LTO drives connected to
> your TSM server?
>
> I will be going fiber-attach next year and will have two adapters in my
> TSM
> server.
>
> Do I put a fiber switch in the tape library (3584), tie all the drives to
> it, and run two fibers back to the TSM server?
>
> Do I run seperate fibers for all the drives back to my existing switches?
>
> Do I put a pair of fiber hubs in somewhere, and hook half the drives to
> each
> hub?
>
> Ah, yes, it's that wonderful time of year when the leaves start to turn --
> and the next year's budget projections are due :-)
>
> Tom Kauffman
> NIBCO, Inc
> CONFIDENTIALITY NOTICE: This e-mail and any attachments are for the
> exclusive and confidential use of the intended recipient. If you are not
> the intended recipient, please do not read, distribute or take action in
> reliance upon this message. If you have received this in error, please
> notify us immediately by return e-mail and promptly delete this message
> and its attachments from your computer system. We do not waive
> attorney-client or work product privilege by the transmission of this
> message.
>
>
> **************************************************************************
> **************************
> Confidentiality: This e-mail and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity
> to whom they are addressed. If you have received this e-mail in error,
> use of this information (including disclosure, copying or distribution)
> may be unlawful. Please notify postmaster AT aquila-networks.co DOT uk. and
> delete the message immediately.
>
> Security: Internet e-mail is not a 100% secure communications medium.
>
> Viruses: This e-mail (and any attachments) has been checked (using Sophos
> Sweep 3.68 + patches) and found to be clean from any virus infection
> before leaving.
> Therefore neither Aquila Networks Services Ltd nor Midlands Electricity
> plc or any of their group undertakings (as defined by the Companies Act
> 1989) (together referred to as the "Companies") accept legal
> responsibility for this message or liability for the consequences of any
> computer viruses which may have been transmitted by this e-mail.
>
> Monitoring: All electronic communications with the Companies may be
> monitored in accordance with the UK Regulation of Investigatory Powers
> Act, Lawful Business Practice Regulations, 2000. If you do not consent to
> such monitoring, you should contact the sender of this e-mail.
>
> Aquila Networks Services Limited,
> Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB
> Registered in England and Wales number 3600545
> This e-mail may be sent on behalf of any of the Companies.
> **************************************************************************
> **************************
CONFIDENTIALITY NOTICE: This e-mail and any attachments are for the exclusive
and confidential use of the intended recipient. If you are not the intended
recipient, please do not read, distribute or take action in reliance upon this
message. If you have received this in error, please notify us immediately by
return e-mail and promptly delete this message and its attachments from your
computer system. We do not waive attorney-client or work product privilege by
the transmission of this message.
|
