[openib-general] IB and FC
Dror Goldenberg
gdror at mellanox.co.il
Sun Oct 16 23:27:44 PDT 2005
> From: Mohit Katiyar, Noida [mailto:mohitka at noida.hcltech.com]
> Sent: Saturday, October 15, 2005 3:40 PM
>
> While in the figure given below the client to IB FC gateway speed is >
> 10 GB/s and from Gateway to I/O storage is 2GB/s and if port
> aggregation
> is applied at gateway then 4GB/s. So the total effective speed from
> client to I/O storage can max be reached at 4GB/s
>
> IB cables
> Client ----|
> Client -- -| |----- FC Switch---|
> . | IB cables | |
> . |--IB FC ------ | |-------I/O storage
> | Gateway | |
> Client ----| Router |----- FC Switch---|
>
> Figure 2
>
>
>
> So can anyone explain me am I correct in my approach? Are there any
> other advantages in shifting from figure 1 architecture to figure 2
> architecture?
The Gateway from IB to FC can also be a storage virtualization device, in
which
case it may stripe data amongst multiple FC devices. In this case you can
get higher
bandwidth (aggregate) to the storage boxes, because there are going to be
many of them. Caching may also be doable in the gateway.
This may also be an intermediate solution that will enable you to connect
native
IB storage boxes in the future. In which case you're going to be able to
connect both your existing FC storage boxes and new IB storage boxes to the
IB fabric.
>
> It does not seem any advantageous in shifting from FC SAN to IB FC SAN
> through such a pattern?
Another reason can be cost. If your clients already have IB adapters because
they
are doing clustering or for other reason, then why buy a FC adapter to each
client ?
Just use the IB as a consolidated fabric and through the GW you can access
the storage. You saved the cost of the FC adapters.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051017/57dfed89/attachment.html>
More information about the general
mailing list