Practical Architectures Part 1: Scale Out File Servers & Firewalls: To do or not to do?
Hello there, I'm back with Part 1 of a 2 post series that will try and address (hopefully) some of the more quirkier questions I / We've been getting about trying to put a firewall, in between a SOFS deployment and the Hyper-V nodes it connects to
WHAT!? Are you serious? Why would you do that?
Yeah, these, amongst several others are the reactions we get when someone throws this requirement at us: 'I know that the SOFS is great, but I want a firewall between the Hyper-V Hosts and the SOFS/ JBOD deployment in question, so I can ensure that the storage traffic is secure.'
Frankly speaking, there is no need for a firewall in between the Hyper-V Hosts SOFS/ JBOD's, and I'll go a bit in detail and elaborate on the What, Why and How's below.
First and foremost, go check out this fantastic article by Jason Gerend on how to Provide cost-effective storage for Hyper-V workloads by using Windows Server https://technet.microsoft.com/en-us/library/dn554251.aspx?f=255&MSPPError=-2147217396 and scroll down to the third diagram where he has outlined how the actual SOFS architecture looks at a High Level.
Now then, I guess you're read Jason's article and figured out What a Scale-Out File Server is and How it functions. 2 questions answered, now we move on to the requirement posed by some folks to us below.
If you've looked at Jason's article, you'll have noticed the 10GB Ethernet (Multiple Links) part in the design. What we've been asked is that is the following a recommended/ supported design:
Notice the Hardware Firewall performing Stateful inspection of SMB traffic, as it sits atop the SOFS Nodes, acting as an additional layer for the SMB traffic passing to and fro from the 10 Gb Ethernet switch(es) and the SOFS nodes? Sounds very straightforward right? It isn't so actually. Let's see why.
- The Firewall will work as it's designed to do, but what you are ending up overlooking, is the kind of impact this is going to have on your SOFS and the resultant IO. This is what we term as a 'Bump in the Wire' situation, when an additional piece of equipment/ software is lobbed in between a perfectly good architecture simply to meet an age old/ antiquated security requirement/ or probably in 95% of the cases, a completely wrong interpretation of the requirement thereof.
- To make this work, to a very basic level, you will have to configure the firewall to operate in Layer-2 Transparent Mode. What this means, is that a transparent firewall (or Layer 2 firewall), on the other hand, acts like a “stealth firewall” and is not seen as a Layer 3 hop to connected devices. The appliance connects the same Layer 3 network subnet on its inside and outside ports, but each interface of the firewall resides in a different Layer 2 Vlan.
- This is a really bad move, since now you also end up with the possibility of the firewall inserting loops into your networks. See what happened there?
So while your intentions may be noble, you're going to end up with a mess on your hands once your workloads start asking for more IOPS.
So a couple of points to make here:
1. Could this 'bump in the wire' approach work? Answer: Maybe, maybe not.
2. Is this 'bump in the wire' approach supported/ recommended by Microsoft? Answer: No.
3. You definitely do not place a firewall in between your SAN arrays and the workloads, so why try this approach here?
4. If you're worried about someone trying to sniff traffic on the network, do remember that SMB 3.0 traffic is not your standard TCP/IP traffic. There's a whole lot of differences.
5. Check out Encryption in SMB 3.0: A Protocol Perspective https://blogs.msdn.com/b/openspecification/archive/2012/10/05/encryption-in-smb-3-0-a-protocol-perspective.aspx on how to Encrypt your SMB 3.0 traffic.
Now for me to draw up a Practical Architecture for how the SOFS and JBOD connectivity looks like on the network, when implemented per documented Best Practices
Comments
- Anonymous
May 27, 2015
Hello Abhishek,
This is very helpful blog.