Data Center Dan
  • Blog
  • About
  • Contact

NetApp SnapMirror Fails with Plenty of Free Space

4/3/2014

0 Comments

 
SnapMirror should be a class all itself. There are a lot of reasons a SnapMirror can fail, and a lot of ways to set it up to succeed. 

One such failure I dealt with recently involved a simple SnapMirror with a daily schedule. The problem was that it was failing out about the same point—150GB—and then went into a non-SnapMirrored state. However, the hosting aggregate container had over 2TB of free space, and the volume itself had 162GB available . . . what in the world?

The answer lies in how the source and destination volumes were provisioned. Here is what NetApp Says in Technical Report 3563: 
Volume SnapMirror® replicates an entire FlexVol volume, most often used for disaster recovery. It is an efficient data replication product that transfers only the data present on the source system to the destination system during the initial baseline transfer. All transfers from that point forward only transfer modified data blocks to the destination. Volume SnapMirror seamlessly integrates with thin provisioning to 
initially transfer and write to the destination only used data. — NetApp TR-3563
Here's the depiction that NetApp offers in technical report. It is a great way to understand the benefits of thin provisioning for disaster recovery replication.
Picture
But what about when the source is thick-provisioned? In our case here, the source volume was a Cisco Unified Communications datastore, and Cisco UC requires thick (eager-zeroed) provisioning. Ah, there's the rub. 
Volume SnapMirror seamlessly integrates with thin provisioning to initially transfer and write to the destination only used data.
The problem is that from a "used data" perspective, the entire LUN is "used"—though NetApp System Manager will still report gigabytes and gigabytes of available space. So in this case, SnapMirroring from a thick-provisioned LUN to a thin-provisioned LUN of the same size failed right at the end every time, because the destination needed to be just a bit bigger than the source due to thick-provisioning. I added a few extra GBs for good measure, and wallah! SnapMirrored!
0 Comments



Leave a Reply.

    Author

    Husband.Father. Lifelong Learner & Teacher. #NetAppATeam. #vExpert.
    All posts are my own.

    Picture
    Picture
    Tweets by @dancbarber
    Check Out koodzo.com!

    Archives

    March 2017
    June 2016
    December 2015
    July 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    July 2014
    June 2014
    May 2014
    April 2014
    March 2014

    Categories

    All
    Best Practices
    Cisco Nexus
    Cisco UCS
    Cloud
    Compute
    Design
    Disaster Recovery
    ESXi
    Flash
    FlexPod
    Geeknicks
    HA/DRS
    HomeLab
    Horizon
    Hyper-Converged
    Management
    Memory
    NetApp
    Networking
    NFS
    Performance Optimization
    Power
    ProTips
    SAN
    Scripts
    Security
    Servers
    SQL
    Storage
    Training/Certification
    Troubleshooting
    VCenter
    VDI
    VMware
    VSOM/vCOPS
    VUM
    Windows

    RSS Feed