Overview
I currently have a CentOS 7 server set up as a VM host using KVM. It has a 4TB (2x2TB mirrors) ZFS array that will be used for VM and file storage. This was set up as part of a process to rebuild an AD domain from scratch on top of Server 2012 R2 (the current 2008 R2 domain left by the old IT guy is a bit of a mess, and runs on an old Core 2-era desktop machine). We need Server 2012 R2 to implement Group Policy. There's a mix of 7/8.1/10 machines, but everything will be running Windows 10 likely within a few months. Users have a share on the server which is mounted to their machine as Z:
, and they also access shares on the server which hold documents used by various departments. We are also going to implement a new backup system (Crashplan/Carbonite/Mozy are the most likely options at this point).
Scale
The network consists of about 55 computers in the main office, as well as other computers outside of the office which will be connected later via OpenVPN. In total, I'm looking at around 150 computers. There are also at least that many users. In addition, the new domain will have somewhere around one to two dozen security groups.
Options
I'm trying to decide how best to handle file storage and sharing for the network. Specifically, whether I should bother with Samba or not, and if not, whether I should store the files in a disk image, or create a data volume on the ZFS array which is then passed to the Server 2012 VM as a raw block storage device.
Storing files in a disk image for use by a VM has always seemed like a poor solution to me. It's simple and will work, but I don't particularly like it. If I need to transfer those files to a Windows server, I have to either mount the image, or boot up the VM. Having all the files in a single image is convenient for transferring, but is an issue if the transfer is interrupted. This can be solved by using something like rsync, but that means I'm limited to transferring only to another Linux box. The other issue with using a disk image is that I'm then restricted to running the backup software inside of the VM (else I lose file-level access). Though I suppose I could probably mount the image read-only on the host, or add the image to another VM with read-only access specifically for the backup software.
I know that ZFS allows you to create data volumes which function as block-level devices that could then be passed through to the VM as a physical drive. This would basically mean having an NTFS partition in the ZFS array. I could give read-only access to this volume to another VM which would handle the backup software, or I could mount the volume as read-only on the bare-metal machine and potentially run the backup software inside of a Docker container. I could also transfer the files to another Linux host through a ZFS snapshot. Transferring to a Windows host would still mean mounting the volume or starting the VM.
The final option is to store all the files directly in the ZFS array and run Samba to share them out over the network. I'm expecting to have a fairly complex permissions hierarchy though, and I'm worried about managing that through Samba (I've only ever used Samba in home-server environments). On the other hand, I know I can effectively manage the hierarchy in Server 2012 R2, especially with Powershell. The other thing to consider is that I can run Samba directly on the VM host, inside of a VM, or inside of a Docker container, so it's fairly flexible.
Question
Which of these options will give me the most flexibility in the long run, without introducing unnecessary overhead or complexity? I want to keep my responsibilities as separated as I can, so I like the idea of having Samba share out the files while Server 2012 R2 handles AD and Group Policy (though I could also run a separate Server 2012 R2 instance instead of Samba for that purpose). However like I said, I'm hesitant to use Samba in a network of this scale. I am also worried about difficulties with troubleshooting file permissions if I use Samba (Windows is bad enough as it is, and that's the native option).
Any other potential solutions are also welcome.