Like Lucky, I'd say "it depends".Originally Posted by adhillon
![]()
We've stress-tested an iSCSI connection from inside a Xen VM... a simple "dd if=/dev/zero of=/someiscsivol/tempfile ... " We easily got 500 Mbps load on the (gigabit ethernet) network. But under normal operation our iSCSI test VM produced close to no traffic, although the system disks are on iSCSI as well.
If your iSCSI initiator is doing heavy (iSCSI) disk I/O, I'd try to put both initiator and target on the same switch to avoid bottlenecks. If possible, use separate network interfaces for iSCSI and user traffic at the initiator side. Monitor especially the initiator and target links for throughput and the switch for load in general.
Under lower (I/O) load circumstances, you may not see any major impact on the general network performance at all.
Another thing to keep in mind is traffic and error isolation - do you need to avoid situations where user traffic might block iSCSI traffic (intended or accidentially)? Then go for a (more or less) isolated network. Need extra security against sniffing and DOS attacks? Isolate the network. How about fault tolerance? You might even want to set up alternate paths between iSCSI initiator and target.
There's more to it than can be said without knowing the defined requirements - check you SLA and the security requirements, those should give you a good starting point. Then try to estimate (or measure) the network load imposed by your iSCSI setup and check the available throughput on the network path(s). Then come up with a cool design and have the budgt owner send you back to the drawing board![]()
HTH,
Jens