Why should iscsi SAN traffic be isolated? I'm trying to explain to my network guy why we should isolate the traffic.
-
Please read http://www.techrepublic.com/blog/data-center/iscsi-storage-networks-full-separation-or-not/ – Andy Sep 23 '14 at 14:34
-
11How could you be explaining it to him if you don't know? You're advocating for a particular architectural design and implementation without yourself knowing why that particular architectural design and implementation is important. – joeqwerty Sep 23 '14 at 14:40
-
1No I do know but these are old school network guys that just want to throw mor bandwidth at the issue. I was just hoping to get more info on what I could tell them on why and what can happen if its not isolated. – Jeffery Jarrells Sep 24 '14 at 17:59
3 Answers
Because:
- Very, very bad things will happen if someone gains unauthorized access to your storage network
- Very, very bad things will happen if you have your iSCSI traffic not separated, and someone finds it a great idea to muck around with the STP topology at an edge switch, with the result of your entire network AND your storage subsystem going down at once
- Very, very bad things will happen if iSCSI network design isn't done carefully. Keeping it on isolated VLANs makes it much much harder to do something silly, like trying to carry iSCSI traffic across a router or a firewall (there shouldn't be any routers or firewalls on a iSCSI network)
- Very, very bad things will happen if your storage/virtualization admin wants to implement jumbo frames, and your network admin doesn't want to implement jumbo frames. Keeping iSCSI separated on dedicated switches will prevent this from happening. Even sharing switches with regular network traffic will prevent MTU mismatch, as you would only increase the MTU on the switches that has iSCSI traffic - not the connected switches.
I could probably list more reasons, but I think it's enough to get an idea. Don't mix iSCSI traffic with any other kind of traffic on the same ports. If you have decent switches then go ahead and share the switch fabric with other traffic, but keep iSCSI on separate ports in separate VLANs.
![](../../users/profiles/9140.webp)
- 19,532
- 4
- 55
- 75
Because not doing so allows regular traffic to impact on storage traffic, which is a bad idea as it means that say a user's download could delay an important read or write.
![](../../users/profiles/1435.webp)
- 100,240
- 9
- 106
- 238
-
That's an argument for QoS. Would you also argue in favor of isolating VoIP traffic? – MSalters Sep 24 '14 at 14:24
-
-
That's by design - QoS lets non-timesensitive data wait for more urgent data such as iSCSI traffic. – MSalters Sep 24 '14 at 14:45
You don't want side effects from traffic disturb your SAN access. We have a small VMWare VSphere environment where we at first had both VMotion and iSCSI traffic going through the same switches on the same network. Different network adapters, but the same network. A bug in ESXi 5.0 made the hosts randomly lose access to the iSCSI SAN whenever a longer VMotion action that made use of more than 1 network adapter was active. Depending on the SAN solution and the iSCSI clients used you can expect all sorts of funny behavior when you mix traffic. Of course it can run without any problem too, but that usually only lasts until that one day when your colleagues are all on vacation and suddenly all hell breaks loose.
Another problem when you have iSCSI SAN systems in your default network: someone could use an IP address assigned to your SAN node. That would probably not happen on accident, but someone trying to get you or the company in trouble could scan your network, discover the SAN and use any IP-enabled device to make your SAN magically disappear.
![](../../users/profiles/71683.webp)
- 296
- 3
- 6