Printable View
My understanding is that the storage and data networks should be isolated. However, I am also picking up information that states otherwise.
Is it advisable to have all iSCSI components (DSS Server, switches, NICs) along with the application servers on the same subnet? Is it feasible? Is it practical?
I think it depends on your situation. If you have a lot of data transfer without iSCSI Target in your system the transfer could be doubled. If you additionally configure the replication - you will get data transfer 3 times higher as before. So in many situation it is better to have it separated not only by simple subnetwork configuration - but by separated network hardware.
But if you will have situation that simple documents are copied over network from time to time - I don't think separated hardware is really needed. You will have only additional cost and more time spend on fixing problems if some network hardware will get broken.
Like Lucky, I'd say "it depends". ;)Quote:
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 :D
HTH,
Jens
Thanks for the quick feedback. It's good to know that we are on the right track i.e. we are using distinct hardware for the storage network.
We are new to iSCSI but are learning quickly - thanks to the forum. I would appreciate help with iSCSI replication/failover setup.
[Configuration]
2 storage servers: DSS1 and DSS2
3 x 2-port Bonds: Bond0, Bond1, Bond3 on each server
Bond0 - subnet 192.168.2.x
Bond1 - subnet 192.168.3.x
Bond2 - subnet 192.168.4.x
Plan is to use Bond0 & Bond1 for Virtual IP, and Bond3 for replication
2 Switches:
port #1 from each bond connects to switch #1
port #2 from each bond connects to switch #2
3-port trunk (3 x 1GB) between the two switches
2 Teamed NICs connect application server to storage switches.
NIC #1 connects to switch #1
NIC #2 connects to switch #2
[Questions]
What is recommended subnet(s) configuration for the environment?
Could we have all storage components in one subnet?
Are we complicating the issue with 3 subnets?
We would like to have two targets (for failover) defined in each application server.