We've used FC-SCSI bridges for many years now with no issues.  In fact, 
the library we use for NDMP has two of them in it (added a second last 
week).

To make it simple, t's all about bandwidth.  We look at the total, native 
bandwidth of our backup devices then multiply that by the typical 
compression that we see.  This gives us a decent approximation of how much 
data the drives can handle.  We then add in 10% - 20% extra (after 
compression for a safety net.

Let's say I just have one LTO2 drive doing Windows backups:   30MB/sec 
native * 1.5 compression = 45MB/sec; add 6.75 MB for safety net (round to 
7MB) and we have 52MB/sec that I need to push to this drive.  If this 
drive is doing Oracle, I would have (30MB/sec * 3 compression) = 90MB/sec; 
add 15 MB for safety net and we have 105MB/sec.  Does that seem high for a 
30MB/sec device?  Absolutely.  Remember that the native drive speed is the 
fastest that the heads can put data onto the media - period.  At 3:1 
compression, I need to push 90MB of data to keep the drive at 30MB =).

Using my target numbers I can then look at my connectivity to see the best 
way to lay things out.  We've found that the trick with FC-SCSI bridges is 
not forgetting to take the SCSI portion of it into account when planning 
for throughput.  Just because you have 2Gb FC coming in, doesn't mean 
you'll be able to push that through SCSI on the other end.  This is 
especially true when mixing drive types as the entire SCSI channel will 
drop to the speed of the slowest device.

I would also recommend dedicating one FC card/port for tape and a second 
one for disk.  This is a best practice (requirement?) with Sun servers. 
It's especially recommended if you're backing up those disks to tapes on 
the same system - data in from disk doesn't have to fight data out to 
tape.

If this data is coming in over the network, don't forget to factor that 
bandwidth in as well.  To push 200MB/sec to your tape devices (a single 
2Gb FC), you have to be able to pull that through the front end (2x GbE). 
The new 4Gb FC means 4 x GbE.

Finally, be sure this 1U server has the horsepower to move all this data. 
They don't in our environment so we have to use 4 CPU systems.

I hope that helps...

Jeff Mery - MCSE, MCP
National Instruments

-------------------------------------------------------------------------
"Allow me to extol the virtues of the Net Fairy, and of all the fantastic
dorks that make the nice packets go from here to there. Amen."
TB - Penny Arcade
-------------------------------------------------------------------------



Olaf Zaplinski <o.zaplinski AT BROADNET DOT DE> 
Sent by: Legato NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
07/21/2006 06:32 AM
Please respond to
Legato NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>; Please 
respond to
Olaf Zaplinski <o.zaplinski AT BROADNET DOT DE>


To
NETWORKER AT LISTSERV.TEMPLE DOT EDU
cc

Subject
Re: [Networker] Slightly off-topic query






Hmm, we are thinking of replacing our old server that has several SCSI 
HBAs 
attached to one LTO2, three LTO1, two disk devices and the library. Could 
we 
buy a SCSI/FC bridge, attach all SCSI devices to it and buy a small 1HE 
server with one FC HBA? Would that work, or would we get performance 
issues?

Olaf

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type 
"signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER