4

I have a project on to replace the storage that our virtual farms are using. We replaced the hosts last year but due to budget constraints we couldn't afford to replace the storages until now.

A high end NAS from a well respected company has come to my attention. This NAS has 24 drive bays, 16GB RAM, an 8 core Xeon CPU and two 10GbaseT network interfaces.

I can outfit two of these things entirely with 960GB Samsung enterprise SSDs and still pay less than what I would for a single SAN from the likes of Dell outfitted with less spinning rust storage. I feel I can't ignore this.

So I guess I have two questions:

1) Could the NAS cope with the workload? The farm has three virtual hosts. It holds pretty much all of the business's servers including user file storage, DCs and a few SQL databases.

2) This thing talks iSCSI and NFS. It strikes me as a fairly bad idea to present this thing as block storage to the virtual hosts when in fact it isn't. Layering two file systems (VMFS and Ext3) on this thing seems wasteful whereas at least if I use NFS the VMDKs would be stored directly on the main file system. Would I be better using NFS or iSCSI?

  • Could the NAS cope with the workload? - What's the workload? You've told us what type of VM's will be running but you haven't actually stated what their IOPS workload is. Layering two file systems (VMFS and Ext3) on this thing seems wasteful - I don't understand that statement. iSCSI should present an unformatted block device to the hosts. Why would Ext3 be in play? – joeqwerty Jul 11 '17 at 21:14
  • I'm trying to get data on IOPs but getting useful information out of the SAN that we're using at the moment is like getting blood out of a stone. – Norphus Jul 12 '17 at 8:15
  • > I don't understand that statement. iSCSI should present an unformatted block device to the hosts. Why would Ext3 be in play? If this is anything like the other NASes masquerading as iSCSI devices that I've used in the past, they format their volumes using the OS's default file system. You then create a container on that file system which is presented to the remote system as block storage. The remote system then formats the container using its file system. The native file system of this NAS is Ext3 which is where that comes in. – Norphus Jul 12 '17 at 8:18
  • Why aren't you revealing the manufacturer of the NAS? – ewwhite Jul 14 '17 at 16:02
  • I wouldn't begin to call this a 'high-end NAS' sorry - for a start it'll only have one 'head'/controller - no resilience at all - I can't possibly recommend you go down this path - you're introducing a single-point-of-failure for your entire enterprise. – Chopper3 Jul 14 '17 at 16:06
6

So I guess I have two questions:

1) Could the NAS cope with the workload? The farm has three virtual hosts. It holds pretty much all of the business's servers including user file storage, DCs and a few SQL databases.

A: It's absolutely OK for NAS to handle your workload! Since 2012 it's preferred by Microsoft to have SMB3 which is file over iSCSI/FC protocols which are block. The problem is - very few SAN/NAS vendors have properly implemented SMB3 stack: most have issues with SMB Multichannel and SMB3 Direct (RDMA), and these guys are major driving force to adopt SMB3 in production. For example NetApp...

https://library.netapp.com/ecmdocs/ECMP1196891/html/GUID-3E1361E4-4170-4992-85B2-FEA71C06645F.html

Data ONTAP does not support the following SMB 3.0 functionality: SMB Multichannel SMB Direct SMB Directory Leasing SMB Encryption

2) This thing talks iSCSI and NFS. It strikes me as a fairly bad idea to present this thing as block storage to the virtual hosts when in fact it isn't. Layering two file systems (VMFS and Ext3) on this thing seems wasteful whereas at least if I use NFS the VMDKs would be stored directly on the main file system. Would I be better using NFS or iSCSI?

A: It's absolutely OK to use iSCSI with VMware, Hyper-V is OK-ish, but NFS is VMware only, you can't do NFS with Hyper-V (or SQL Server if you care, it isn't as bad but has own limitations).

https://www.starwindsoftware.com/blog/hyper-v-vms-on-nfs-share-why-hasnt-anyone-thought-of-that-earlier-they-did-in-fact-2

http://windowsitpro.com/hyper-v/hyper-v-vms-nfs

https://www.brentozar.com/archive/2012/01/sql-server-databases-on-network-shares-nas/

Back to iSCSI vs NFS. I guess both are identical from the performance point of view (unless you do iSER which isn't working great with ESXi 6.5), but NFS is much easier to manage!

http://www.unadulteratednerdery.com/2014/01/15/storage-for-vmware-setting-up-iscsi-vs-nfs-part-1/

http://community.netapp.com/t5/Network-Storage-Protocols-Discussions/NFS-or-iSCSI-for-ESXi-5-5-and-or-6/td-p/114345

My bet is on NFS here!

4

Have you ever thought of virtual SAN approach to building your storage? For the most part, it would be some sort of hyper-converged setup where you could have all the nodes utilizing the local storage and replicating the data between each other.

For the case, I can recommend two most obvious storage players.

HPE StoreVirtual: https://www.hpe.com/us/en/storage/storevirtual.html

StarWind vSAN: https://www.starwindsoftware.com/starwind-virtual-san-free

We were having a true love story with the latter, btw :) Just two all-flash nodes, 10 + 1gbe networking and dozen of VMs running on top. What I can say is that we've eventually got a redundancy at the nodes level and high I/O rate due to the fact that all the nodes in cluster were processing the traffic simultaneously, becoming a real active-active hci setup.

2

DISCLAIMER: If you pay for VMWare support, you probably don't want to use anything that's not VMWare certified.

Without knowing your system itself, we have measured 10G iSCSI vs. 16G Fibre Channel vs. 10G NFS on our own "cheap" Storage Systems. So far what we've seen is Fibre Channel is slightly better than iSCSI and both outperform NFS.

So if I had to decide it, I'd go with iSCSI.

  • Thank you for the answer! The NAS that I'm looking at is VMware certified and supports VAAI. It also appears on VMware's compatibility matrix. – Norphus Jul 11 '17 at 20:32
  • 2
    It's probably a Synology... I'm which case, I'd avoid. – ewwhite Jul 14 '17 at 16:03
  • @ewwhite yes, it was a Synology FS2017 unit. Any particular reason you'd avoid Synology? – Norphus Jul 14 '17 at 16:26
  • 1
    I can name a few reasons. Synology as a brand is fine. They make good products with sane storage stacks. They don't make very high end products, though. They don't have a solid clustering solution nailed down, and their products are directed at offices, rather than enterprise production systems. For example, if you choose to use their implementation of HA, you'll find your performance has been crushed. It's also only active / passive, and doesn't necessarily play nice with connected clients. – Spooler Jul 14 '17 at 17:06
  • 1
    It's trivial to fix Synology HA with something like IBM SVC or StarWind vSAN free :) starwindsoftware.com/blog/… – BaronSamedi1958 Jul 15 '17 at 8:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.