locked
Storage Replica questions RRS feed

  • Question

  • I have been poking around on the Storage Replica technology and have a few questions.  

    1. Does it require storage spaces to work, or will "normal" volumes also replicate?

    2. Do the protected/replicated volumes require ReFS, or will NTFS work as well?

    3. Can you turn on replication for system drives (somewhat in relation to the ReFS question, as ReFS is not yet recommended for system drives I believe).

    4. Technet (https://technet.microsoft.com/en-ca/library/mt126103.aspx) seems to indicate that you need <5ms connection (assuming RTT) and at least 1 Gb connection. Is that actually true, even for async replication?

    Thanks for any assistance/clarification on these points.

    Tuesday, May 10, 2016 7:26 PM

Answers

  • Howdy.
    1. Storage Spaces, Storage Spaces Direct, iSCSI, SAN LUN, local disks - all supported.
    2. SR replicates at the block level, so the data volume file system is irrelevant (we don't even know what it is). NTFS and REFS are fine. See https://aka.ms/sroverview
    3. No, we currently block replication on the system volume. This may change in a later version.
    4. These are our strong recommendation numbers for synchronous replication in TP5. If you have less bandwidth and higher latency, we don't stop you, but you will only be hurting yourself. You're right that this should say 'synchronous' here, I'll update it.
    Thanks for your interest!

    Ned Pyle [MSFT] | Principal Program Manager for Storage Replica, DFS Replication, Scale-out File Server, SMB, other stuff

    • Marked as answer by jadeddog Thursday, May 12, 2016 2:36 PM
    Wednesday, May 11, 2016 3:47 AM

All replies

  • Howdy.
    1. Storage Spaces, Storage Spaces Direct, iSCSI, SAN LUN, local disks - all supported.
    2. SR replicates at the block level, so the data volume file system is irrelevant (we don't even know what it is). NTFS and REFS are fine. See https://aka.ms/sroverview
    3. No, we currently block replication on the system volume. This may change in a later version.
    4. These are our strong recommendation numbers for synchronous replication in TP5. If you have less bandwidth and higher latency, we don't stop you, but you will only be hurting yourself. You're right that this should say 'synchronous' here, I'll update it.
    Thanks for your interest!

    Ned Pyle [MSFT] | Principal Program Manager for Storage Replica, DFS Replication, Scale-out File Server, SMB, other stuff

    • Marked as answer by jadeddog Thursday, May 12, 2016 2:36 PM
    Wednesday, May 11, 2016 3:47 AM
  • I also updated our TechNet content to make some of this more plain, it will start appearing shortly. Take a look and let me know what you think.

    https://aka.ms/sroverview

    https://aka.ms/srstretch

    https://aka.ms/srs2s

    https://aka.ms/src2c

    And what does it take to get a topic marked as the correct answer around here, anyways? I own the darn feature in question! :D


    Ned Pyle [MSFT] | Principal Program Manager for Storage Replica, DFS Replication, Scale-out File Server, SMB, other stuff


    Thursday, May 12, 2016 12:43 AM
  • haha, I marked it as answered.  My alert isn't working for some reason, so I didn't get an email update when you answered :)

    Thanks a bunch for the information, that was extremely helpful.  Too bad about that system volume limitation.

    One quick follow-up question in regards to the <5 ms/1 GB.  This makes perfect sense for sync.  I'm assuming the standard type of response regarding async exists?  The more bandwidth/less latency the better, resulting in lower RPOs?

    One last question (hopefully last anyhow).  Is the log volume at the source "network-aware"?  I am thinking of a scenario where the WAN between the two sites is lost.  I'm assuming the source log just fills up as the replication network is now gone, and it starts sending change blocks when the network comes back up?

    Thanks again.  Very interesting technology, and could really help out in a lot of non-VM DR situations, especially if you guys ever remove the system volume restriction.  If there wasn't that restriction it would be bordering on a perfect feature IMO.

    Thursday, May 12, 2016 2:48 PM
  • Cool! 100% correct on the async.  I will just quote myself here from TechNet, as I am super lazy:

    The Microsoft implementation of asynchronous replication is different than most. Most industry implementations of asynchronous replication rely on snapshot-based replication, where periodic differential transfers move to the other node and merge. Storage Replica asynchronous replication operates just like synchronous replication, except that it removes the requirement for a serialized synchronous acknowledgment from the destination. This means that SR theoretically has a lower RPO as it continuously replicates. However, this also means it relies on internal application consistency guarantees rather than using snapshots to force consistency in application files. SR guarantees crash consistency in all replication modes.

    So while latency and bandwidth are not IO performance limiters, they could make your RPOs hit the basement due to lack of throughout. Furthermore, I recommend taking VSS snapshots periodically to get app-consistent checkpoints. these will replicate too, and that's going to be some additional IO overhead on the wire.

    Yes, the nodes are aware of network loss and will replay. if the log wraps, we will replay from the bitmap. If that's lost, we will replay initial sync (with seeding flag automatically enabled).

    Thanks!


    Ned Pyle [MSFT] | Principal Program Manager for Storage Replica, DFS Replication, Scale-out File Server, SMB, other stuff


    Thursday, May 12, 2016 5:16 PM