Forgive me. It has been more than six weeks since my last post. To make up for it, this post is pretty long, weighing in at around 3,000 words. On the plus side, you only need to read all of those words in the example code output you’re really interested.
Part of the reason I have been slacking on the blog front is that our team has been working to get our new content and infrastructure built, upgraded and ready for all of you to enjoy at the VMworlds this year. We have some pretty exciting new labs in coming, as well as a some of VMworld sessions about how we run things and how some people are using our labs: INF1311 – Deploy and Destroy 85K VMs in a week: VMware Hands-on Labs Backstage and SDDC2277 – A New Way of Evaluating VMware Products and Solutions – VMwareHands-on Labs
There are some cases when you have plenty of bandwidth between your source and target, and other times when that is just not possible. Sill, the data must go through! So, if bandwidth between clouds is on the lower end, or if we are refreshing a version of an existing vPod, our second replication mechanism using rsync may save us quite a bit of time.
It has been said in a variety of different ways that the best I/O is the one you don’t need to do – that is especially true for moving data over great distances and/or via low-bandwidth connections. For the 2013 content year, as we developed this solution we transferred our base vPods using the LFTP method, then used the base pods as “seeds” for an rsync differential replication.
This solution is a combination of the right tools and the right process. Either one used in isolation would not provide us as much benefit as using them together. I know it sounds a bit gestalt and maybe a little cheesy, but I hope you see what I mean when you read through this post. Continue reading