- Abstract
- Introduction
- Principles and Best Practices
- Migration Mechanics
- Case Studies in Migration
- Next Steps
- Copyright and Trademarks
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Case Studies in Migration
This section presents several case studies that illustrate the overall procedure and critical points for migrating workloads.
Case Study 1: Migration of a J2EE Application
Our goal in this case study is migration of a J2EE application running in WebSphere from one data center to another, to avoid downtime caused by a maintenance activity. It uses the WebSphere Application Server 8.5 image in the SCE image catalog as an image base. The tools available in the WAS 8.0 image will be used to migrate the J2EE application. All steps can be performed using command-line tools or scripts to enable automation, avoiding the need to use a GUI over the Internet. A DNS service directs users to the secondary server at the new data center; a BIND server is configured to do this. In addition, there is a HTML redirection at the IP of the primary to the secondary to allow for DNS cache refresh that may be caused by caching in users' browsers. Figure 4 shows the procedure.
)
Figure 4 Migration of a J2EE application.
These are the required steps:
- Set up the primary environment.
- Provision the primary server on an instance of WebSphere Application Server 8.5.
- Deploy the application to WAS.
- Configure IBM HTTP Server.
- Set up the DNS system on an instance on the cloud.
- Test the application.
- Set up the secondary system.
- Repeat deployment of the application as for the primary system.
- Redirect traffic to the secondary system with DNS.
- Post the maintenance message on the primary.
- Test that the secondary system acts as a replacement transparently to the client.
The key to this scenario is the use of the BIND DNS server. Install and start BIND from the Linux yum repository with the commands in Listing 3.
Listing 3—Installing and starting BIND.
$ sudo /bin/bash # yum install bind # service named start
You'll need to add a zone statement for your domain and include a zone file that contains the individual resource records for the domain. Edit the main configuration file /etc/named.conf.
Case Study 2: Using rsync to Synchronize Files for a Database Application
This case study demonstrates using rsync to synchronize a directory tree from a primary to a secondary virtual machine. rsync is an ideal tool for this purpose because it detects changes in the directory tree in the primary system efficiently and then compresses and copies those changes on the secondary system, where they're reassembled. The case study uses Apache Derby as an example database.
The steps to perform the migration are as follows:
- Set up Derby on the primary server.
- Create a database.
- Create a table and add a record.
- Use rsync to copy the database files.
- Test that you can view the database records in the secondary system.
- Add more data to the primary database, synchronize, and test for the new data on the secondary.
Figure 5 illustrates this procedure.
)
Figure 5 Migration of a Derby database.
The key to this scenario is the rsync command. Run the command in Listing 4 from the primary system to the secondary system to copy the MigrationTest directory. You need to have the SSH key on the primary server in the .ssh directory. You should execute the command from the command line of the primary server.
Listing 4—Copying the database directory with rsync.
$ rsync -avz -e "ssh -i .ssh/<key_name>" /home/idcuser/<database directory> idcuser@<secondary_server_ip>:/home/idcuser
The command <key_name> holds the SSH key filename, <database directory> is the directory where the Derby database is contained, and <secondary_server_ip> is the IP address of the secondary server.
Case Study 3: WebSphere Application Migration with Profiles
This case study is an example of the tools and approach for migrating a more complex application. The steps for the setup of the primary system are as follows (see Figure 6):
- Set up the Derby database.
- Enable user authentication.
- Run Derby in network mode.
- Run the Derby client in network mode.
- Install the example application.
- Perform WebSphere configuration with wsadmin Jython scripts.
- Create a JDBC provider.
- Create an authentication alias.
- Create and test a data source.
)
Figure 6 Migration of a WebSphere application using profile export.
WebSphere profiles include the applications packaged in them, as well as all other configuration settings. We'll use export of a profile to a configuration archive to migrate our upgraded example application. These steps are already automated in the WebSphere images in the SCE catalog, except for the additional customization specific to deployed applications.
The migration steps are as follows:
- Export the profile configuration archive from the primary WebSphere system.
- Copy the files to the secondary server.
- Test the database.
- Import the profile.
- Update the profile for the new hostname.
- Perform additional customization for application-specific settings, such as data sources.
Exporting and importing profiles requires a WebSphere restart. Use the manageprofiles command to export the profile. First stop the web server and admin server from the idcuser login. These steps are shown in Listing 5. Start the procedure logged in as idcuser in the SCE Linux virtual machine running WebSphere.
Listing 5—WebSphere profile export from the primary server.
$ sudo /opt/IBM/HTTPServer/bin/apachectl stop $ sudo /opt/IBM/HTTPServer/bin/adminctl stop $ su - virtuser $ /opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1 $ /opt/IBM/WebSphere/AppServer/bin//manageprofiles.sh -listProfiles [AppSrv01] $ /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh-backupProfile -profileName AppSrv01
Copy the backed-up profile from the previous step to the secondary server, stop the application server, and use the manageprofiles command to delete the existing profile and import the new one. These steps are shown in Listing 6.
Listing 6—Import of the WebSphere profile on the secondary server.
$ su - virtuser $ /opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1 $ /opt/IBM/WebSphere/AppServer/bin//manageprofiles.sh –delete AppSrv01 $ rm -rf /opt/IBM/WebSphere/Profiles/AppSrv01 $ /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh