3

The short question: can I share file and block level traffic on the same SAN? Perhaps more importantly, should I? The gory details are below...

I'm hopefully putting the finishing touches on a new SAN design, and our new planned storage (EMC VNXe3100) will support being an iSCSI target, our original goal. It also supports file-level storage as well via CIFS and NFS. Some of the features we hope to use (particularly deduplication) are only available via file-level shares.

The VNXe3100 has 2 controllers with 2 NICs per controller. Each NIC is going to a different switch, so either the controller or the switch can fail, and we should still be in business. This means that both file and block traffic would need to be enabled on each NIC. I'm assured by our rep that this is possible.

My plan is to put the VNXe and the 5 host servers on the same VLAN and subnet (call it 192.168.1.x). This should keep my block-level iSCSI stuff only in that VLAN with no route out. But I would have a route out to the rest of the network for the file-level traffic on a different subnet (192.168.55.x). So each NIC would have an IP address for block traffic in the 1.x range and another for file traffic in the 55.x range.

Since we are new to the world of iSCSI and the world of SAN/NAS devices, I want to make sure this isn't some horrible intermingling. But it would be really nice to expose our VMWare as NFS and get the VMs deduplicated on our hardware, and not having to maintain another file server would also be a bonus.

If there's something else I'm overlooking, I'm all ears.

Ben Pilbrow
  • 12,041
  • 5
  • 36
  • 57
CC.
  • 1,196
  • 1
  • 10
  • 22
  • VMware is a company and not a product. I have removed the [vmware] tag from your question as it doesn't really help us to organise your question. If you want a VMware related tag on the question, please consider one of the product specific VMware tags. – Ben Pilbrow May 25 '11 at 17:51

1 Answers1

3

I'm not familiar with the inner workings of EMC's arrays, but I've been lead to believe that they are a block SAN with a file-level NAS controller bolted on -- you can have iSCSI LUNs that go directly to your servers, or you can export them to the NAS head, and share them out as NFS/CIFS. You can have different LUNs set up with different access types, but a single LUN can be one or the other (block- or file-level access) but not both.

Other systems (ie, NetApp) work in reverse; NAS is their native format, and an iSCSI or FC LUN is just a single huge file that it serves out with those protocols (with some protection to keep you from inadvertently messing them up if you access the parent directory with NFS.)

With only 2 NICs per controller, you might run into some issues trying to mix block and file access. With file-level access (being based on IP), they rely on the underlying protocol stack for redundancy (typically you configure the ports in a failover bond group, with a single IP across the pair), whereas iSCSI descends from storage-world, and expects redundancy to be handled above it in the stack, by way of a multipathing driver on the attached hosts. It's likely that a port on the EMC can't be both configured with it's own IP for multipathing, and having a virtual IP in a failover group (notwithstanding failover of the whole controller; I'm not sure how the EMCs handle that). Doing iSCSI on top of a bonded interface can work, but you won't be able to get the added performance of multipathing.

techieb0y
  • 4,179
  • 17
  • 17
  • Very interesting. I feel like I have a handle on file-level, but the iSCSI redundancy is where I'm weak. I'll have to chase down how the hardware handles redundancy. Performance has been acceptable on our old system, so we're more focused on reliability this time around. – CC. May 25 '11 at 14:34