Since they don't already have a Storage FC infrastructure, I'd suggest going with a native ISCSI solution. That being said I'd suggest a storage array which allows for native ISCSI as well as FC attached storage. This would allow them to leverage the existing network infrastructure now, but if they need the benefits of FC in the future it would be more easily adoptable.
But without a lot more infromation it's really hard to say for sure.
My understanding is that a bridged ISCSI implementation includes FC components. The question stated they had no current FC infrasctrure. Building out a FC SAN can be pretty expensive, don't you think? That is why I went with a native solution.
As stated I might have misinterpreted some things. But I never really dealt with bridged topologies that much in iSCSI/FC environments. But I am looking forward to a clarification though.
Since they don't already have a Storage FC infrastructure, I'd suggest going with a native ISCSI solution. That being said I'd suggest a storage array which allows for native ISCSI as well as FC attached storage. This would allow them to leverage the existing network infrastructure now, but if they need the benefits of FC in the future it would be more easily adoptable.
You state that they currently don't have a native iSCSI solution and therefore recommend using a native implementation. But because they have no infrastructure limiting them right now, I would tend to recommend using bridged iSCSI. That way you can use a "standard" iSCSI infrastructure and use an entry level array that will serve you as you like (iSCSI in this case).
If the array is capable of also being accessed via FC you can alway purchase FC-HBAs and connect directly or via a switched infrastructure. And should you upgrade to another array or just purchase another array, you can always connect it via an FC-infrastructure, and you can still allow all of the iSCSI hosts to access such an array without having to purchase parts that would enable you to use a bridged iSCSI setup.
Actually as I understood it, a bridged iSCSI implementation can include FC-components, but they are not required as far as I am aware. An iSCSI bridged infrastructure just adds the functionality of bridging your IP devices to (for example) and FC-based array. Or I have the wrong idea of such a bridged device, but perhaps someone can shed some light on this matter?
I'm not sure, but i'll offer up a few quotes from the ISM book.
"A bridged iSCSI Implementation includes FC components in its configuration" and "Bridged topology enables the co-existence of FC with IP by providing iSCSI-to-FC bridging functionality. For example, the initiators can exist in an IP enviroonment while the storage remains in an FC SAN"
Seems pretty clear cut the me, anyone else what to chime in?
cincystorage
2 Intern
•
467 Posts
0
June 24th, 2009 08:00
Since they don't already have a Storage FC infrastructure, I'd suggest going with a native ISCSI solution. That being said I'd suggest a storage array which allows for native ISCSI as well as FC attached storage. This would allow them to leverage the existing network infrastructure now, but if they need the benefits of FC in the future it would be more easily adoptable.
But without a lot more infromation it's really hard to say for sure.
cincystorage
2 Intern
•
467 Posts
0
June 24th, 2009 12:00
Sebastian,
My understanding is that a bridged ISCSI implementation includes FC components. The question stated they had no current FC infrasctrure. Building out a FC SAN can be pretty expensive, don't you think? That is why I went with a native solution.
Raayman
47 Posts
0
June 24th, 2009 12:00
As stated I might have misinterpreted some things. But I never really dealt with bridged topologies that much in iSCSI/FC environments. But I am looking forward to a clarification though.
Raayman
47 Posts
0
June 24th, 2009 12:00
You state that they currently don't have a native iSCSI solution and therefore recommend using a native implementation. But because they have no infrastructure limiting them right now, I would tend to recommend using bridged iSCSI. That way you can use a "standard" iSCSI infrastructure and use an entry level array that will serve you as you like (iSCSI in this case).
If the array is capable of also being accessed via FC you can alway purchase FC-HBAs and connect directly or via a switched infrastructure. And should you upgrade to another array or just purchase another array, you can always connect it via an FC-infrastructure, and you can still allow all of the iSCSI hosts to access such an array without having to purchase parts that would enable you to use a bridged iSCSI setup.
Raayman
47 Posts
0
June 24th, 2009 12:00
Actually as I understood it, a bridged iSCSI implementation can include FC-components, but they are not required as far as I am aware. An iSCSI bridged infrastructure just adds the functionality of bridging your IP devices to (for example) and FC-based array. Or I have the wrong idea of such a bridged device, but perhaps someone can shed some light on this matter?
cincystorage
2 Intern
•
467 Posts
0
June 24th, 2009 12:00
I'm not sure, but i'll offer up a few quotes from the ISM book.
"A bridged iSCSI Implementation includes FC components in its configuration" and "Bridged topology enables the co-existence of FC with IP by providing iSCSI-to-FC bridging functionality. For example, the initiators can exist in an IP enviroonment while the storage remains in an FC SAN"
Seems pretty clear cut the me, anyone else what to chime in?