l-migrate2cloud-1-pd..

More documents

Recommendations

Info

developerWorks® ibm.com/developerWorks • What touchpoints into other systems does the application need? • Have I backed everything up recently? Notifying users In general, notifying your users is a good thing, even if you don't anticipate any downtime. In the case of the SmallPayroll.ca application, users tend to use the site at a consistent interval, corresponding with their two-week payroll cycle. Therefore, two weeks' notice would be a reasonable period. Sites like Google AdWords, which is the administrative interface for the Google advertising platform, give about a week's notice. If your website is more of a news site where users would not be as disrupted if it were down for an hour, you may choose to give notification on the day of the outage. The form of notification also varies depending on the nature of your site and how you currently communicate with your users. For SmallPayroll.ca, a prominent message when the user logs in will be enough. For example, a message like "The system will be unavailable between 12:01 a.m. and 1 a.m. Eastern time, June 24, 2010. Everything entered prior to this will still be saved. For more information, click here." This message provides the three key pieces of information that users need to know: • When the outage will happen, including the time zone • Reassurance that their data will be safe • Pointer to further information If possible, avoid using 12:00 a.m. or 12:00 p.m., including the term midnight. These tend to confuse people, as many are not sure if midnight on June 17 refers to early morning (12:01 a.m.) or very late (11:59 p.m.). Similarly, many are not sure whether noon means 12 a.m. or 12 p.m. It's much easier to add a minute and make the time unambiguous. Your details may be different, especially if you anticipate partial functionality during the outage. If you decide that you are going to put the notice up only during the outage (such as for a news site), the same information will still be helpful. My favorite site outage screen was along the lines of "The site is down for maintenance; back up around 3 p.m. EST. Play this game of Asteroids while you're waiting!" Don't neglect your internal users, either. If you have account representatives, you will want to give them notice in case their clients ask any questions. DNS considerations The domain name system (DNS) takes care of translating a name like www.example.com into an IP address like 192.0.32.10. Your computer connects to Initial migration Trademarks © Copyright IBM Corporation 2010. All rights reserved. Page 4 of 21
ibm.com/developerWorks developerWorks® IP addresses, so this translation is important. When migrating from one environment to another, you are almost guaranteed to be using a different IP address (the exception would be if you're staying in the same physical building). Computers cache the name-to-IP mapping for a certain period of time, known as the time to live (TTL), to reduce overall response time. When you make the switch from one environment to another—and therefore from one IP address to another—people who have the DNS entry cached will continue to try to use the old environment. The DNS entry for the application and its associated TTL must be managed carefully. TTLs are typically between one hour and one day. In preparation for a migration, though, you would want the TTL to be something short such as 5 minutes. This change must be made at least one TTL period before you intend to change the address, because computers get the TTL along with the name-to-IP mapping. For example, if the TTL for www.example.com were set to 86,400 seconds (one day), you would need to reset the TTL to 5 minutes at least one day before the migration. Decoupling the old and new environments It is essential that you fully test your new environment before migrating. All testing should happen in isolation from the production environment, preferably with a snapshot of production data so you can better exercise the new environment. Performing a full test with a snapshot of production data serves two purposes. The first is that you are more likely to spot errors if you are using real-world data, because it is more unpredictable than the test data used during development. Real-world data may refer to files that you forgot to copy over or that require certain configurations that were forgotten during your walk-through. The second reason to use production data is that you can practice your migration at the same time as you load data. You should be able to prove most aspects of your migration plan, except for the actual switch of environments. Even though you will be mocking up your new environment as if it were production, only one environment can be associated with the host name of the application. The easiest way to get around this requirement is to make a DNS override in your hosts file. In UNIX®, this file resides at /etc/hosts; in Windows®, it resides in C:\windows\system32\drivers\etc\hosts. Simply follow the format of the existing lines, and add an entry pointing your application's host name to its future IP address. Don't forget to do the same for any image servers or anything else that you will be moving. You will probably have to restart your browser, but after that, you will be able to enter your production URL and be taken to your new environment, instead. An Amazon EC2 primer Initial migration Trademarks © Copyright IBM Corporation 2010. All rights reserved. Page 5 of 21
Page 1 and 2: Migrate your Linux application to t
Page 3: ibm.com/developerWorks developerWor
Page 7 and 8: ibm.com/developerWorks developerWor
Page 21: ibm.com/developerWorks developerWor

l-migrate2cloud-1-pd..

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?