As the cloud computing paradigm continues to evolve and mature, organizations have a range of service providers to choose from. This is good news, for clients need no longer feel tied-in to their existing vendor; any dissatisfaction can be addressed by cloud vendor migration, moving to a vendor that offers a more desirable mix of pricing, features, stability and value added services. However, any cloud migration must be systematic, to avoid loss of data or downtime. Further, there are additional considerations for user-generated content (UGC) websites.
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
1) Changing the DNS’ time to live (TTL) value: Domain name system (DNS) plays an important role in websites running user generated content (UGC). TTL is the time up to which data will be cached in the DNS. At least two days before the process of cloud migration, the DNS admin should be informed to reduce the TTL value to, let’s say, two minutes. While this does increase the DNS load temporarily, it helps make the migration process smooth. For one, should anything go wrong, it’s easier to rollback and point the DNS to the old server without facing a downtime of hours. Secondly, users logging in to a website in the process of cloud migration should get access to updated data on the new server as quickly as possible, rather than be directed to the old server due to persistence of the cache for longer periods of time.
2) Components involved in running the website: In coordination with the company stake holders, prepare a list of components involved in running the website. This will include content, videos, images, database, storage, database administrators and firewall experts. Additionally, because of UGC, if the size of data is in GB or TB, additional work will be required when it comes to cloud migration.
3) Make sure new infrastructure works: Before you stop paying your old cloud vendor, make sure that your entire infrastructure is smoothly running with the new cloud service provider and that nothing is still being served from the old infrastructure after cloud migration.
Case in point
A company running a content management system (CMS) driven website www.abcd.com opts for cloud vendor migration. The website serves stored images and uses MySQL DB as the backend. Both the cloud vendors (the current and the future one) are based in India and have good network connectivity. Described below is a walkthrough on effective cloud migration with configuration details of the CMS.
The CMS runs with the following components:
• Front end on Apache 2.2, PHP 5.3 and PHP-MySQL. (Dependency -> MySQL DB to produce content on site | Storage to serve images | Authorize.XYZ.com API to check authentication).
Website URL: www.abcd.com (for users)
• CMS: Runs on Apache 2.2, PHP 5.3 and PHP-MySQL (Dependency -> MySQL DB to produce content on site | Storage to serve images.
URL: admin.abcd.com (for company employees)
• MySQL Database: MySQL 6.0 (Dependency -> NONE).
• Images: Apache + PHP 5.3 (Dependency -> Storage) (Problematic area: 800 GB | UGC).
• Authorization: Runs on Apache 2.2, PHP 5.3 and PHP-MySQL (Dependency -> MySQL to fetch user information).
Since MySQL is common to all components, the cloud migration process will be prioritized with respect to MySQL.
Step 1: The first step will involve migrating MySQL or building replication for synchronization. Change the DNS TTL to two minutes. For instance, if your DNS TTL is 24 hours then reducing TTL to two minutes will actually take 24 hours to propagate. Hence, DNS modification and MySQL sync will run in parallel.
Step 2: The next big challenge is the UGC. Initiate a copy process to the new provider’s storage to move the TBs of data. Meanwhile, static and non-UGC content (such as PHP files, CSS files, logos/images, JS files and SWF) can be moved immediately to new storage.
Step 3: Set up the Web server in the new cloud provider’s environment to run the websites (www.abcd.com, admin.abcd.com and auth.abcd.com). Configure Apache and other services and applications to point to the migrated MySQL server. Note that since the DNS entry has not been modified, everything is still running from the old infrastructure.
Step 4: The quality control team now tests applications running on the new infrastructure. It can use the local DNS server to point to the new infrastructure or use the HOSTS file to check out the migrated but not yet live site.
Step 5: Change the pointer of admin.abcd.com to the new infrastructure’s web server/load balancer. Login to both infrastructures and ascertain whether the old infrastructure is still being accessed. At this point, all the requests should hit only the new infrastructure, with the possible exception of images.abcd.com, as the total size might be in terabytes.
Step 6: Assuming everything is complete (DB, DNS, WWW, and AUTH) and 75% content is copied to the new infrastructure, create a sub-domain images1.abcd.com and point it to the old images.abcd.com. Tweak the application to pick up and serve UGC from local storage. If content is not present in the local server, then the application can serve images from images1.abcd.com (this path must be present in DB.)
Step 7: Cloud migration is now complete. However, do not pull the plug on the old infrastructure for at least a week. This will ensure that oversights do not disrupt normal service.
While following the above procedure ensures smooth cloud migration from one vendor to another, frequent migration is not advisable due to the huge overheads involved. A small mistake could translate into big losses, so carefully choose your cloud service provider.
About the author: Dipankar Sinha is project manager for infrastructure and hosting at Hungama Digital. Sinha specializes in cloud hosting and development, application architecture design, and infrastructure implementation and management. He has earlier worked with Kreeda Games, Cleartrip.com, and Puretech Internet.
(As told to Anuradha Ramamirtham)
Disclaimer: The cloud migration procedures detailed in this article are based on certain assumptions, and may not be suitable for all environments.
This was first published in June 2011