Azure Data Center Migration just got easier..
在 一月 12, 2015 上貼文
How do you migrate your cloud assets from one Azure data center to another? How do you move your cloud deployment from one subscription to another in the same data center? These are fairly common scenarios, for example when Microsoft adds a new data center closer to your current one which provides lower latency, or you want to duplicate your current cloud deployment to a test deployment, and vice versa. In each case, migration can be a complex manual affair. Writing a script to add automation, customization and repeatability to your data center migration can become a major programming project, with extensive investment in error handling in case a problem occurs mid-migration. Persistent Systems have released a free open source solution developed in collaboration with the Microsoft Azure CAT team in Bangalore that takes much of the pain away from these types of migration. The solution, aptly named Azure Data Center Migration Solution (ADCMS) and licensed under Apache v2.0, provides a highly flexible and extensible method of moving assets from one Azure data center to another. With a focus on atomicity, this utility is designed to handle interruptions and either start from where it left off or roll back. ADCMS produces a JSON based template of your subscription configuration metadata (including affinity groups, networks, disks, availability sets, load balancers and cloud services) which can then be used to stand up a replica, or edited to produce a modified version. This methodology enables export, import and migration. The solution can be downloaded from github, and comes with a comprehensive user guide. For more information, see the Persistent Systems blog post announcing the release. You can also see ADCMS in action in the this video. ..and for more detail, refer to the more detailed engineer posting from architect Satish Nikam on LinkedIn. A key advantage of this solution is the flexibility and extensibility provided by the template based and open source approach. One caveat to keep in mind, is that migration is performed offline – you need to shut down VMs before migration to maintain disk consistency.