Migration Mechanics
Applications can have various migration challenges, depending on the different system components from which they're composed. Let's take a look at some examples.
Types of Applications and Associated Migration Problems
Table 2 lists components that can be particularly difficult to migrate per component.
Table 2
Component types and migration challenges.
Component Type |
Example |
Challenges |
Web server |
IBM HTTP Server*, Apache web server |
|
Application server* |
WebSphere Application Server (WAS)*, Apache Tomcat |
|
Database systems |
IBM DB2*, Apache Derby* |
Machine names and IP addresses embedded in profile configuration files |
Commercial software |
|
Licenses often based on either IP address or MAC |
LDAP servers |
IBM Tivoli Directory Server |
Salt (random number for password hashing) |
Monitoring systems |
IBM Tivoli Monitoring |
References to monitored systems |
Load balancers |
Stingray Traffic Manager |
References to managed systems |
Firewalls |
Linux iptables |
References to managed systems |
* These components will be treated in the case studies section, but the concepts presented there can be applied to other products in the same component family.
Application servers are typical examples of systems with the machine name embedded in profile configuration files, which will not port cleanly between virtual machines on the cloud with simple image capture. These can usually be migrated with special steps, but creating a reusable virtual machine image takes some development effort. The WebSphere Application Server in the SCE image catalog was built to overcome this problem.
Similarly, the hostname of a web server with an X.509 certificate used for SSL connections should match the common name in the subject of the certificate, otherwise it won't be trusted. Browsers will flag this problem and offer the option to create an exception if you're familiar with the provider of the service. This setup may be acceptable for some applications with a small community of users, but new production-grade certificates signed by a trusted certificate authority should be used for Internet-facing applications.
Migrating Data
Different kinds of data can present various challenges during migration, and different approaches can be used to address these challenges, as shown in Table 3.
Table 3
Types of data and related migration challenges.
Type of Data |
Examples |
Challenges |
Configuration data |
Hostnames, network, IP address, data center name |
Close relationship to environment |
Application data |
As stored in a relational database |
• Universally unique (UUID/GUID) • System/random-generated or database auto-increment |
Encrypted and hashed data |
Keys, passwords |
Salting of passwords |
In password salting, passwords are combined with a random number before hashing to prevent the risk of a third party obtaining the password database and reversing the hash to obtain the passwords.
Approaches to migrating data can be either to copy data bit-for-bit or use an application-specific import/export utility. Virtual machine image capture falls into the bit-for-bit category. The challenge with using this approach is that you may need to extract and replace certain parameters at the secondary location. This is actually a common problem in basic image development. IBM SmartCloud Enterprise Image Developer's Guide is a good reference, with more details on image development. (An SCE user account is required for access to the guide.) Application-specific import/export utilities, such as database backup and restore tools, regenerate data in a predictable way, which takes some specialized knowledge of individual systems to automate.
Tools for Workload Migration
Table 4 shows a summary of tools that will be used in the case studies for workload migration.
Table 4
Summary of tools for workload migration.
Type of Tool |
Examples |
Uses |
Cloud infrastructure management tools |
API, self-service user interface |
Image management, import copy and export, volume cloning, system virtualization |
Operating system and network-level tools |
SSH/SCP (secure copy), DNS/BIND, traffic management tools such as Stingray, rsync |
Bit-for-bit data replication, traffic management |
Middleware utilities |
WebSphere wsadmin |
Web server HTTP and HTML page redirects, system configuration |
Database utilities |
Database backup and restore, DB2 HADR |
Import and export of application data, transaction log replication |
The availability of multiple data centers in IBM SmartCloud Enterprise is an important feature for providing alternate locations to avoid a number of causes of service disruption. The cloud self-service user interface can provision new resources quickly and short-term. The APIs and command-line tool provide alternatives to the web console that can be used for automating migration tasks. For example, the APIs can be used to automate provisioning and management of virtual machines and other cloud resources. Image capture is useful in many contexts, in addition to being the simple approach to workload migration.
An important feature of SCE is the image catalog, which provides a large selection of images available at all data centers to provide a base image for customization. In the case studies for this article, we use a WebSphere Application Server in the SCE public image catalog. This system reduces the amount of installation and configuration needed. In particular, scripts in the image remove the machine name embedded in WebSphere configuration files.
Software bundles are another important SCE feature, allowing you to create templates to replicate similar virtual machines at different data centers, without leading to virtual machine sprawl.
SSH and SCP are fundamental tools for working on the cloud to login and execute scripts remotely, as well as copying data securely. The standard Linux tool rsync is used for remote synchronization of file systems between Linux servers. It works by detecting and copying only the differences in directory hierarchies. The rsync command can be used easily on top of SSH for secure data transport.
DNS is an important tool for directing users and systems without being tied to IP addresses. It allows you to move servers without making that change apparent to clients. DNS requires registration or configuration to point to a name server at the client. Unlike virtual IP addresses, DNS names are portable between data centers, and multiple DNS hostnames can map to one server. BIND is the most widely used DNS system; we use it for the first case study.
Traffic management tools can be used to route web traffic in a similar way to DNS, but they're more specialized for the purpose, easier to use, and provide additional capabilities such as geo-routing (routing to a web server based on the geographic location of the user). Virtual appliances in the SCE image catalog that provide traffic management include Riverbed Traffic Manager and Dyn.
HTML page redirects are useful for quiescing a system with a maintenance message included to inform the user of the activity. This can be done with the HTML <head> element, as shown in the code fragment in Listing 1.
Listing 1HTML page redirect.
<meta http-equiv="Refresh" content="0; url=http://www.example2.com/" />
Web server HTTP redirects can be used to prevent users from accessing all points in the primary system during maintenance. The HTTP code 302 should be used for temporary redirects. Listing 2 shows an example.
Listing 2HTTP redirect.
HTTP/1.1 302 Found Location: http://www.example2.com/index.html
The Apache web server module mod_rewrite can be used to send this for all URLs served by the system being maintained.
WebSphere and other applications provide many configuration utilities. A number of these commands and tools enable portability of both application code and application-server configuration settings. The WebSphere wsadmin scripting tool allows for automation of management operations in WebSphere written in Jython. It's written using the Bean Scripting Framework and can be extended.
Approaches to Migrating WebSphere Applications
WebSphere receives some of the focus in the case studies because it's a primary container for IBM applications. It also provides services that make workload migration much more efficient. Other application servers are similar but might not have all the options that WebSphere provides. Table 5 provides a summary of approaches to migrating WebSphere applications, some of which we'll leverage in the case studies.
Table 5
Summary of approaches to migrating WebSphere applications.
Approach |
Description |
Leverage SCE base WebSphere images in public catalog |
|
Capture image, transfer, and modify |
|
Own installation of WebSphere software |
|
Liberty profile |
A lightweight WebSphere profile based on simple XML files |