none
Server 2012 R2 physical storage versus virtual and Replica

    Question

  • I have a situation where I need to put about about 20 TB of storage on a 2012 R2 file server.

    Option 1

    I could make the computer a HyperV host and run a 2012 R2 File Server VM in it with the 20 TB  as a VHDX attached to it.  If I do that  I would have the ability to use it as a Replica source. And I could also have DFS with another similarly configured  fully virtualized file server.

    Option 2 is to have everything physical. In this case I would be able to have DFS but not Replica.

    Option 3 is to have both file servers as VM with physical storage - I get DFS but not Replica for the data.

    Option 4 is to have server A file server all physical - storage and OS -  and server B all virtual - no Replica but DFS available.

    Option 5 is to have server A file server VM but storage physical, server B all virtual - again DFS for data and Replica for VM but no Replica for data.

    Option 6 - have file server A OS physical, storage virtual and similarly on the other end with Server B. - DFS available, Replica not

    Option 7 - have file server A OS physical, storage virtual and on the other side OS Virtual and storage physical - DFS available, Replica not

    Option 8

    I could switch the scenario around whereby the production server would be all virtual and the second all physical - again Replica not available but DFS available.

    (I think that sums up the options - sorry for the dizzying array and possible duplications.)

    My question are the pro's and con's of the above  scenarios.

    Points I am interested in

    Basic storage performance - physical 20 TB vs 20 TB VHDX

    Replica performance for 20 TB

    DFS performance for 20 TB

    Combining Replica and DFS for 20 TB - possible? advisable? performance?

    I would appreciate feedback from folks with experience in the above.

    Monday, September 30, 2013 8:31 PM

All replies

  • Hi,

    Please help me confirm:

    1. What kind of storage of the 20TB space?

    I asks this because if it is a LUN of a SAN or JBOD hard disks, you could separate them to 2x10TB and connect to both of your physical servers.

    2. Why you need DFS?

    If it is for load-balance or failover, you will also consider enough storage space for DFS replication. That's why I ask if you could separate your 20TB space.

    3. Why you need Replica (I assume it means VM Replica - the new feature of Hyper-V in 2012 R2)?

    If just for data replication, I think DFS replication will also work.

    (It seems I misunderstood at first so I edited my reply)


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.


    Wednesday, October 02, 2013 8:59 AM
  • Both DFS and Hyper-V Replica do some sort of a failover but both are more of a Disaster Recovery then a Business Continuity solutions. So you need ask yourself one question: what RTO and RPO your system should have? In other words: how soon failover should happen and how much data you can lose? DFS is a bad match for a file server as it replicates closed files. This means if a 1 GB file was edited for a day and grow to 10 GB and DFS was not replicating it because it's open and then power fill go out on a source - you're going to lose whole 10 GB of a changes / updates. Hyper-V Replica on the other side utilizes CBT which is Changed Block Tracking and will fire changes on a small granularity, 30 seconds is the smallest one with R2 (was 2 minutes with pre-R2). However you're still going to lose the data. And still failover is either questionable or non-automatic... Good idea would be creating failover file server on source (guest VM cluster will work with SMB 3.0 just fine, make sure it would not be SoFS as it's a bad match for a typical file server workload) *and* combine it with Hyper-V replica on a destination to have a decent DR plan. I would completely avoid DFS however. 

    StarWind iSCSI SAN & NAS

    Wednesday, October 02, 2013 4:09 PM
  •  Shaon Shan:

    20 TB is a RAID array attached to a Windows 2012 Server. That's how much space the data takes.

    DFS - so I can have the data duplicated as people open and close files.

    Replica so I can have a Replica of the VM and the VHDX.

    StarWind iSCSI SAN & NAS:

    Thanks (as always) for the insight into DFS.

    What about VHDX vs physical for the storage?

    Also what are your thoughts on Scale Out File Storage including Storage Spaces. 

    The particular system I am thinking about is an architect firm with about 50 architects - currently accessing a SAN that is past its prime - technologically and also capacity-wise -  and we do not want to upgrade it because of cost and vendor lock-in. So the primary network traffic is large files being copied from the server to the workstation and back.

    Thursday, October 03, 2013 7:45 AM
  • [ ... ]

    What about VHDX vs physical for the storage?

    Also what are your thoughts on Scale Out File Storage including Storage Spaces. 

    The particular system I am thinking about is an architect firm with about 50 architects - currently accessing a SAN that is past its prime - technologically and also capacity-wise -  and we do not want to upgrade it because of cost and vendor lock-in. So the primary network traffic is large files being copied from the server to the workstation and back.

    1) It does not matter. Thick-provisioned VHDX do such a minor impact on performance it could be neglected. Thin-provisioned should be avoided because of the performance reasons.

    2) SoFS has zero sense in general. SMB 3.0 cannot be clustered on its own without block based back end (it's VERY different here compared to pNFS) so if you'd throw away SoFS layer and feed that shared storage directly to Hyper-V / Windows cluster it would be both cheaper (no server hardware for the middle layer, no Windows licenses to power SoFS nodes) and faster (less I/O latency, say SAS goes directly to hypervisor boxes). Microsoft has no local clustered file system like VMware has with VMFS (honestly combination of NTFS and SMB bolt-on is a joke) so it's pushing SMB 3.0 instead of an iSCSI. And SoFS is a very good thing to Micrsosft as it allows to sell more Windows licenses (surprise!) at the end of the day. All MS presentations on how cool SoFS concept is are based on a HUGE installations with many hypervisor nodes and they naturally cannot share SAS back end storage w/o intermediate layer efficiently. Here SoFS makes sense (maybe). But in your particular case - no. 

    3) You may think about feeding SAS directly to your hypervisor boxes. For a 2 or 3 node setup it's very easy. Or if you don't want to mess with an external SAS hardware and expensive SAS spindles and use cheap and capacity-wise SATA there are bunch of software companies doing virtual SAN thing for Hyper-V / Windows. That's what every other hypervisor on this planet (KVM, ESXi and Xen) can do out of box.


    StarWind iSCSI SAN & NAS

    Thursday, October 03, 2013 10:14 AM
  • Thanks for all the great info.

    By thin provisioning you mean I only allot let's say 2TB and then let the VHDX grow upon demand.

    Saturday, October 05, 2013 1:54 AM