BCO1269: SRM 5.0 What’s new and Recommendations

Unlike the last session I attended, this one was very good and had quite a bit of great technical material that went beyond common sense most IT guys have. SRM 5.0 is a major release that addressed many of the shortcomings of the 4.x releases. Highlights include:

  • Customers need simple, reliable DR
  • vSphere Replication is storage array independent and happens at the ESXi host level
  • RPO is 15 minutes to 24 hours. You cannot do less than 15 minutes, so this is not suited for applications that must use synchronous replication and have zero data loss like the finance sector.
  • You can take snapshots of the source VM, but they are collapsed at the recovery site
  • Recommend that you don’t use snapshots
  • The replication engine dynamically changes block sizes and speed to ensure the RPO is met. If your RPO is 1 hour it doesn’t wait for 59 minutes then try to burst the data in 60 seconds.
  • Replication is a property of the VM
  • Array based replication can have much shorter RPOs, compression, and WAN optimizer friendly. vSphere replication has none of these features.
  • v1.0 limitations include:
    • ISOs and floppies are not replicated
    • Powered off or suspended VMs are not replicated
    • Non-critical files like swap, stats and dumps are not replicated
    • pRDMs, FT, linked clones and VM templates are not replicated
    • Requires VM HW version 7 or 8
    • A vCenter server is required at both sites
  • Scalability enhancements for SRM include
    • Protection of up to 1000 VMs
    • 10 parallel recovery plans
    • 150 protection groups
    • 500 VMs per protection group
    • These limits are not enforced, just the most VMware has tested and approved
  • Planned migration is a new workflow
    • Used when a controlled migration can be used instead of the smoking hole scenario
    • Will stop if any errors are encountered
    • Shuts down the VMs gracefully
    • Very orderly failover process
    • Application consistent recovery
  • Failback is a new workflow
    • Failback in 4.x was in the nicest sense extremely scary and very manual with high risk
    • Replays existing recovery plan in reverse
    • “Reprotect” feature in the GUI
    • Only supported by SRA/LUN-level replication
    • Failback only supports original VMs, not any new VMs stood up after the original failover
  • Brand new GUI
    • Both sites visible in a single pane of glass
    • Still strongly recommend that customers use Linked Mode
    • Able to set IPs for both sites in the GUI
    • IPv6 support
    • No more sysprep or customization specs needed
    • Huge Re-IP performance increase (huge!)
    • Supports in-guest callouts and scripts for custom app control
    • Extended the APIs for better integration
  • Dependencies
    • Increased to 5 priority groups
    • All actions are parallel within a group unless otherwise specified
    • Able to now craft more elaborate and controlled dependencies but in a far easier manner
    • Tip: Don’t get TOO creative or it will extend your recovery time and may miss your RTO

For customers that have previously used or looked at SRM before and didn’t bite, it’s time to look at it again. The failback support with array based replication is huge! You may still find you need a different product, like InMage, but SRM of yesterday is not the SRM of tomorrow. SRM 5.0 is due out “soon” according to VMware. I did a hands-on lab of SRM, and I will stay it was quite slick and I came away very impressed with the changes.

Print Friendly, PDF & Email

Related Posts

Subscribe
Notify of
0 Comments
Inline Feedbacks
View all comments