iSCSI traffic on it's own vlan vs. the production vlan
I was trying to find information on why it is best practices to migrate your iSCSI traffic to a sperate VLAN from your production VLAN? It seems redundant since you have to add the routes to allow for traffic to flow between both VLANs. Why not keep them on the same VLAN?
Think of the iSCSI VLAN as if it were a special kind of I/O controller bus rather than a network. This VLAN should be, internal to itself, very flat (no subnets or gateways). It is holding the place that a SAS or SATA controller's cable would hold in direct attached storage.
If the server is connected to the 10.0.0.0 LAN, for example, and you access it through an address on that LAN, your iSCSI VLAN might be 192.168.10.0. Only the servers using the iSCSI targets and the iSCSI host itself need be on the iSCSI VLAN and there is never a need to route traffic from 10.0.0.0 over to 192.168.1.0. Each server sees both networks since each server has an address on each network (either two different NICs or one NIC with two IP addresses. Two different NICs is preferable). In this way, you can monkey with the properties of the iSCSI LAN to tune it for I/O (jumbo frames, larger windows, etc..) without affecting the communication LAN and all the clients on that LAN. Also, since iSCSI will often put a lot of data on a network, your regular communications are not squeezed out in favor of iSCSI traffic.
If the server is connected to the 10.0.0.0 LAN, for example, and you access it through an address on that LAN, your iSCSI VLAN might be 192.168.10.0. Only the servers using the iSCSI targets and the iSCSI host itself need be on the iSCSI VLAN and there is never a need to route traffic from 10.0.0.0 over to 192.168.1.0. Each server sees both networks since each server has an address on each network (either two different NICs or one NIC with two IP addresses. Two different NICs is preferable). In this way, you can monkey with the properties of the iSCSI LAN to tune it for I/O (jumbo frames, larger windows, etc..) without affecting the communication LAN and all the clients on that LAN. Also, since iSCSI will often put a lot of data on a network, your regular communications are not squeezed out in favor of iSCSI traffic.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Re-reading your question (when not on my BB) I see you are more focused on VLANs as opposed to separate switches and I agree with the other two posts that answer this question though I would add that the separation is all about performance and less about data breaches. However to follow up on my post, the specific port configuration is listed in this document and you should review it if you are building an iSCSI SAN even if you are not buying the Equallogic product. Also keep in mind that the backend iSCSI switch design often times employs stacked switches with EtherChannels spanning both switches for redundancy and dual controllers on the arrays; all in the name of uptime.
http://www.cns-service.com/equallogic/pdfs/tr-cisco-3750-2970-switches.pdf
http://www.cns-service.com/equallogic/pdfs/tr-cisco-3750-2970-switches.pdf
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
BTW.. My iSCSI host is "OpenFiler" which is a linux based free appliance.. Works great... was a little tough to figure out how to configure it!!
-Steve
-Steve
You shouldn't need to route data in or out of the iSCSI VLAN; it should be contained within it self, with one or more NIC's on the servers dedicated to iSCSI, and one or more seperate NIC's attached to the rest of the network. Your regular network should not be able to talk to any of the iSCSI ports/NIC's, nor vice versa.