Workload migration on the cloud

Alex Amies, aamies@cn.ibm.com
Cloud Architect
October, 2012

IBM SmartCloud Enterprise
Workload Migration for the Cloud
SCE Developers Group presentation

© 2012 IBM Corporation

Agenda

Workload migration overview and concepts

Best practices

Applications kinds and challenges

Migrating data

Tools for workload migration

Case studies
– Migrating a WebSphere application with wsadmin and DNS
– Synchronising files for a database application with rsync
– Migrating with WebSphere profiles and administration scripting
– X.509 Certificate management

Next steps and resources

2 © 2012 IBM Corporation

Overview
Motivation

Minimize service disruption while application or infrastructure is under maintenance
This presentation

Understand challenges and tasks associated with workload migration

Best practices and tools

Recipes for simple applications
What is workload migration for planned maintenance?

Migration of the service provided by application to a secondary location while the primary
system is unavailable due to maintenance or other business reaason

Includes moving the application to the secondary location with the system configured in the
same way and the data complete and in a consistent state

Reasons for maintenance cloud service upgrade or maintenance by virtual machine owner

Differs from high availability and disaster recovery in that workload migration activities are
primarily for planned reasons


Overview: business context
Lightly used applications

Usually only a single server

Want to migrate application to a secondary location during a maintenance
activity to avoid inconvenience caused to used

Primary focus of this presentation

Cloud enables economic way to continue operations
Heavily used applications

High availability and disaster recovery justified

Use DR site as secondary in case of maintenance

Cloud enables economical disaster recovery at a secondary site
Critical applications

Cloud enables multiple active servers distributed globally

Need specialised techniques for active-active data replication between different
data centers


Overview: migration concepts

Data Center 1
Primary

HTTP(S) Web Application
Server Server
Database
Redirect

Port
User
application Export
data
Data Center 2
Secondary

Web Application
Server Server

Database


Overview: related scenarios
Migration from outside SCE into SCE

Very similar to migrating within SCE

Need to factor in differences in the way virtual machine instances are created
High availability

High availability is mostly concerned with maintaining availability in the event of
a hardware failure

Some overlap of tools but many HA tools do not work over a high latency
network connection (eg over the Internet in a different geographic area)

Example: WebSphere clustering needs to operate over a low latency network
Disaster recovery

Similar goals and set of tools to application migration

Since DR tools and literature are more focussed on mission critical applications,
this presentation is focussed on less critical applications and economic methods


Some best practices
Base instances on standard images available at multiple data centers with an automated,
repeatable install procedure to ensure portability.
Disadvantages of using image capture in a simple way for migration

Downtime due to saving instances to images and time to copy images between data
centers.

The primary hostname and IP address are embedded in WebSphere, DB2, and other
software configuration files that may be frozen in images

Advantage: easy to do, uses standard features, OK for single system user
Refer to servers via DNS aliases (CNAMEs)

There are more portable than primary hostname and IP address

Multiple aliases can be added for servers and changed when needed

The primary hostname and IP address are embedded in configuration files so cannot be
changed

Example: alias www.myserver.com, primary hostname vhost12345.ihost.com
Use HTML / HTTP redirect and maintenance message on server to be taken offline

Clients may cache old DNS names depending on DNS Time to Live


Simple use of image capture: leads to long downtime

Data Center 1
Primary
Application Image
1. Normal use
Server library
User (1, 11)
2. Quiesce system
10. Redirect 3. Save image 4. Copy image
Volume
11. Use secondary
5. Clone volume

Data Center 2
Secondary
Application
Administrator Server Volume
(2-10)

Key Image
Downtime is text in red 7. Create instance
8. Configure library
6. Image import
9. Test

Best practices and trade-offs
Transitioning from a primary to a secondary system

Quiescing versus zero downtime

In order to avoid losing data entered by users at the point when a server is brought down for
maintenance it is a best practice to have a quiescing period. That is the server should not
allow any further transactions to begin but gracefully complete all ongoing transactions.

If the goal is zero downtime then we want to immediately transfer from the primary to the
secondary system. However, this cannot easily done without loosing ongoing transactions
running on the primary, at least not without a more advanced active-active configuration.

High availability versus portability

High availability configurations are generally within a single data center and involve addition
of permanently deployed secondary systems.

If you need to move a whole set of primary and secondary servers to an alternate data center
then the work to do that is considerably greater


Best practices: tool selection
Reduce dependency on network latency when working across data centers

Some software, especially software made to manage clusters, needs low network latency.

Examples of tools that do not need low latency are WebSphere Job Manager, DB2 HADR for
keeping databases synchronized, and rsync for keeping directory trees synchronized

Use secure tools

Prefer tools that can be used in a secure mode or operate the whole system in a secure zone
using VPNs

Use tools that are reliable

Tunnelling or proxifying over SSH can make the connection secure but SSH tunnels can be
prone to break

Prefer application specific SSL connections or a VPN

Use tools that reduce down time

WebSphere profile management tools can migrate an entire application profile to another
system but you need to shut down WebSphere to do this

The WebSphere wsadmin scripting tool can allow more granular management

Best Practices: portability
Portable approach to building highly available systems

Traditional approach to high availability

Try to build and maintain redundant components for any part of the system that might fail

Expensive and requires lots of expertise

Portable approach to high availability

Treat any node in a system as disposable and immediately replaceable by other nodes in a large cluster

Not applicable to many business systems

Portable approach emphasizing automation and repeatability

Recognize that most causes of down time are due to maintenance and within our control

Easier for applications that are simple, single node systems but more difficult for complex applications

Be ready to re-instantiate the application and reload data when needed using cloud-based automation
techniques

This approach can also function as a highly available system if some tolerance for downtime can be
accepted in the event of an unexpected system failure

Maybe be acceptable in many business contexts

Disadvantage: requires administrator expertise or development effort


Automation approach: minimizes downtime, less data to transfer

Data Center 1
Primary
Application
1. Normal use
Server
User (1, 10)
3. Export configuration data
9.Redirect 5. Quiesce system
6. Export application data
10. Use secondary

Data Center 2
Secondary
Application
Administrator 2. Create instance
Server
(2-9)
Image
Key 4. Import configuration data library
Downtime is text in red 7. Import application data
8. Test


Simple applications and problems in migrating them
• Web servers and application servers
– WebSphere Application Server
• Machine name embedded in profile configuration files
• Can be migrated without special steps sometimes but not others
• WebSphere image in catalog has functions in script to overcome this
problem
– Tomcat
– Apache HTTP server
• Database systems
– DB2
• Fully qualified host name embedded in configuration
• X.509 certificates (SSL)
– Server host name should match common name (CN) in subject of certificate,
otherwise it will not be trusted
– Browsers will refuse to allow you to use a web site where the cert does not
match the server
• Software licenses
– Licenses of many IBM and Microsoft software products can be applied to SCE
virtual machines
– Licenses for other commercial software is often based on either IP address of
MAC

Composite applications and problems in migrating them

• Composite systems, eg application server and database, monitoring systems
– With ability to specify host names when provisioning virtual machines these systems
may be able to be migrated more easily
• Complex systems in one VM or multiple with
– Load balancers, firewalls, DNS servers
– These systems are very sensitive to exact values of IP addresses

Sources of data that become unavailable
– For example, REST services on another system that become unavailable
– Make a local cache and store messages that arrive for processing later


Migrating data
• Kinds of data
– Configuration data
– Application data
– Encrypted and hashed data (keys, passwords)
• Problems
– Relationships with environment
• Host names, network, IP address, data center name, etc
– Unique IDs

Universally unique (UUID / GUID)

System / random generated or database auto-increment
– Salting of passwords
• Passwords are combined with a random number before hashing to prevent reversing
• Approaches
– Copy data bit-for-bit
• Virtual machine image copy / import falls into this category
• May need to extract and replace certain parameters at the secondary location. See Image
Developer's Guide.
– Regenerate data in an predictable way
• Considerable effort to automate

Tools for workload migration: overview
• Cloud infrastructure
– Multiple data centers
– Application APIs and self service user interface
– Image library, import copy and export, volume cloning
• System virtualization
– Enables portability of systems
– Ability to save instance to images
– Build the system so that it can be ported to a base image in the catalog at an alternate
data center
– Network resources
• Operating system and network level tools
– SSH / SCP
– DNS
– Traffic management tools
– rsync

Middleware tools
– Web server HTTP and HTML page redirects
– WebSphere and other application server utilities
16 – Database utilities © 2012 IBM Corporation

Tools for workload migration: cloud infrastructure
• Multiple data centers
– The availability of multiple data centers to run workloads on provides an alternate
location to avoid a number of causes for service disruption
• Self service user interface
– Can be used to provision new resources quickly and for a short time
– Even if the self service interface becomes unavailable then virtual machines
themselves rarely become unavailable
• Application APIs and command line tool
– Can be used to automate provisioning and management of virtual resources

Image capture and the image catalog
– Image capture is useful in many contexts
– Provides a large selection of images available at all data centers to provide a base
– In the demo we use a WebSphere Application Server in the public image catalog. This
reduces the amount of installation and configuration needed. In particular, scripts in the
image remove the machine name embedded in WebSphere configuration files

Image clones and software bundles
– Systematic tools that separate software bundles as re-usable assets that can be
installed into base image binaries
– Software bundles can enable you to create templates that can be used to replicate
17
similar virtual machines at different data centers © 2012 IBM Corporation

Tools for workload migration: system virtualization

• Copy, clone, and import of images
– Images can be copied from the image library to a volume
– Storage volume cloning is used to transfer from one data center to another
– Image import is used at the other data center to import from the cloned volume
• Ability to save instance to images
– Create a base image that can be easily ported. This may involve developing start-up
scripts that extract and modify key parameters that may change when provisioning a
new virtual machine
– Build the system so that it can be ported to a base image in the catalog at an alternate
data center
– This enables the workload to be moved without having to clone the image, which can
be a large copy operations (>5 GB) across the Internet
• Network resources
– Virtual IP addresses – not portable between data centers


Tools for workload migration: operating system level tools
• SSH / SCP
– Fundamental tools for working in the cloud to remote login and copy data securely
– Can be used either interactively or in scripts
• DNS
– Important for directing users and systems without being tied to IP addresses
– Can move servers without making it apparent to clients
– Requires registration or configuration to point to a nameserver at the client
– Compared to virtual IP addresses the advantages of DNS names are
• Portable between data centers
• Multiple host names can map to one server
– BIND is the most widely used DNS system and the one that we will use for the demo
– See backup slides for more detail
• rsync
– Remote synchronization of file systems between Linux server, copies differences only
– Standard utility on Linux servers on SCE
• Traffic management tools
– Virtual appliances in the SCE image catalog
– Riverbed Traffic Manager
19 – Dyn © 2012 IBM Corporation

Tools for workload migration: middleware tools

• HTML page redirects in HTML <head> element
<meta http-equiv="Refresh" content="0; url=http://www.example2.com/" />
• Web server HTTP redirects
– 302 used for temporary redirect
HTTP/1.1 302 Found
Location: http://www.example2.com/index.html
– Use Apache module mod_rewrite to send this for all URLs served by the system being
maintained
• WebSphere and other application server utilities
– Many commands and tools enable portability of both application code and application
server configuration settings
– WebSphere wsadmin scripting tool allows for automation of management operations in
WebSphere written in Jython
– Written using the Bean Scripting Framework and can be extended

Database utilities
– Tools should not be sensitive to network latency if you hope to migrate to other data
centers
– DB2 HADR
– Table export and import

Tools: Approaches to migrating WebSphere applications
Other application servers similar but may not have all options
Leverage base WebSphere images

Leverage base WebSphere images at different data centers, template extracting variable parameters has
already been created by the WebSphere image development team

Re-installing the application requires only copying the application binaries and configuration files

Configuration files can be profile, properties, or individual tracking of parameters

Deployment and configuration can be manual, commands, script, or monitored directory

Use techniques in the SCE Customizing Images and Software Bundles

Save image, transfer, and modify

Need to copy a large binary file across the Internet and adjust for frozen properties or create your own
template

UseWebSphere administrative tasks changeHostname and renameNode

Own installation of WebSphere software

WebSphere images in catalog are the Base Edition

If you need Network Deployment Edition then you will need to install it yourself and create your own
template to extract and modify variable parameters

Install binaries in base image and defer creation of profiles until activation time [Willenborg 2007]

Liberty profile

A lightweight WebSphere profile based on simple XML files

Tools: WebSphere wsadmin scripting tool
The wsadmin tool is ideal for automating management actions for WAS.

The If you are unsure of the command to use try the action on the WebSphere administration
UI and copy the script action or use the help command, as shown below. Jython is the
preferred language for scripting. Enter virtuser and the password you provided in the previous
step when prompted by wsadmin. If you are making changes interactively, use the save()
command before exiting with the exit command.

$ su - virtuser
$ /opt/IBM/WebSphere/AppServer/bin/wsadmin.sh -lang jython
. . .
wsadmin> print Help.help()
. . .
wsadmin> print Help.AdminConfig()
. . .
wsadmin>print AdminConfig.help("list")
. . .
print AdminTask.help("-commands", "list*")
. . .
wsadmin> AdminConfig.save()
Wsadmin> exit


Tools: WebSphere administration scripting help
Enable this in the System | Console Preference dialog

Log saved in
/opt/IBM/WebSphere/Profiles/AppSrv01/logs/server1/commandAssistanceJythonCommands_virtuser.log


Tools: WebSphere wsadmin scripting tool (continued)
Certificates Executing scripts in batch mode

It can be even move effective to automate with batch scripts. In this way a Jython script can
be copied and executed without any interaction. For example to get a list of certificate stores
with the wsadmin Jython script below. Save the file to a script called list_certs.py.

print AdminTask.listKeyStores('[-all true -keyStoreUsage SSLKeys ]')

You can execute this from the wsadmin console, as shown below.

$ /opt/IBM/WebSphere/Profiles/AppSrv01/bin/wsadmin.sh -lang jython -f
/home/virtuser/list_certs.py
. . .
NodeDefaultKeyStore(cells/BaseAppSrvCell|security.xml#KeyStore_BaseAppSrvNode_1)
NodeDefaultTrustStore(cells/BaseAppSrvCell|security.xml#KeyStore_BaseAppSrvNode_2)

This also demonstrates how to execute wsadmin scripts in batch mode. Many of the following
slides simply list the Jython commands and assume that they are executed in batch mode, as
above.


Tools: WebSphere wsadmin scripting tool (continued)
Configuration with properties files

Properties files can be extracted from a primary server edited, and imported into a secondary
server. This can simplify migration considerably. There is no need to start and stop the
WebSphere process as with exporting and importing a profile. Profiles are supposed to strip
environment information but, in some cases, still embed environment settings like IP
addresses and hostnames, which need to be changed. The properties approach mitigates
these problems. However, it is not possible to modify every configuration setting with this
approach. The command to extract the properties from a server is

AdminTask.extractConfigProperties('-configData Server=server1 -propertiesFileName
/home/virtuser/myProperties.props')

This will export all the properties for server1 to the file /home/virtuser/myProperties.props. The
file can be edited with a text editor or program, copied to the secondary server, and imported
with the command below. You will need to save the changes afterwards.

AdminTask.applyConfigProperties('-propertiesFileName /home/virtuser/myProperties.props
-validate true')
AdminConfig.save()


Case Study
Migration of a stand-alone WebSphere application with
wsadmin and DNS


Case study: Migration for a J2EE application
Based on a WAS stand-alone topology

Goal: workload migration from one data center to another to avoid downtime caused by
planned maintenance on SCE, based on features available today
– The maintenance plan does not guarantee that one of any two given data centers will
always be up at the same time
• Base plan on being able to instantiate a new WAS server at a secondary data center and
migrating application and
– Using WAS 8.5 image in catalog as a image to base the case study on for a stand-
alone WAS topology with web server in front
• The image is WebSphere Application Server Base Edition
• Use tools available in the WAS 8.0 image to migrate the J2EE application
• Prefer command line tools to enable automation and avoid need to use GUI over the
Internet
– DNS service to point users to the secondary server at the new data center - need an
external service
• Configure BIND server to do this
• Redirection at the IP of the primary to the secondary to allow for DNS cache refresh


Case study: Schematic Diagram

Data Center 1
Primary

HTTP(S) IBM HTTP HTTP WAS App
Server Server

DNS
EAR
User
export

Data Center 2
Secondary

IBM HTTP HTTP WAS App
Server Server

DNS
Server


Steps in case study

Setup primary environment
1)Provision primary server on an instance of WebSphere Application Server 8.5
2)Deploy application to WAS
3)Configure IBM HTTP Server
4)Setup DNS system on an instance in the cloud
5)Test application
Setup secondary system
1)Repeat deployment of application as for primary system
2)Redirect traffic to secondary system with DNS
3)Post maintenance message on primary
Test switch over to secondary system
1)Test secondary system acts as a replacement transparently to client


Demo prerequisites

1) User account on SCE
2) Command line tool setup
3) SSH key defined
4) Basic knowledge of Linux, SCE, and WebSphere
5) SSH client (PuTTY) and secure copy (WinSCP) installed
6) Simple J2EE application created with Rational Application Server. The sample application is
shown in the next slide.


Example Enterprise Application


Limitations and assumptions of tools used in case study

1) Not a complete and automate cut over
2) Loss of data and finite down time during cut over. In particular, loss of user session.
3) There is no quiescing period to allow users to complete their transactions gracefully but this
is recommended.
4) Application is a stateless application
5) Normal practice is to have primary and secondary DNS nameservers.


Step 1a: Provision WAS 8.0 instance
Search on the string 'WebSphere Application Server V8.0' or use the describe-
images command to find the image


Step 1b: Provision WAS 8.5 instance
Find instance provisioning parameters
The image ID of the IBM WebSphere Application Server V8.5 - BYOL image in the Singapore
data center is 20056246. To find out the supported virtual machine instance sizes use the
describe-image command, as shown below.

> ic-describe-image.cmd -u <user_id> -g <password_file> -w <passphrase> -k
20027636
Executing action: DescribeImage ...
ID: 20056246
Name: IBM WebSphere Application Server Version 8.5 32b - BYOL
. . .
Location: 141
Image Size: 15.143166 Gib
----------------------------------
InstanceType ID: COP64.2/4096/60
Label: Copper 64 bit
Detail: Copper - 64 bit (vCPU: 2, RAM: 4 GiB, Disk: 60 GiB)
. . .


Step 1c: Provision WAS 8.5 instance
Submit instance provisioning request
To provision an instance use the create-instance command, as shown below.

> ic-create-instance.cmd -u <user_id> -g <password_file> -w <passphrase> -k
20056229 -n <instance_name> -t "COP32.1/2048/60" -L 141 -m
"{WASAdminPassword:***,WASProfileType:production}"
Executing action: CreateInstance ...
The request has been submitted successfully.
1 instances!
----------------------------------
ID: 293212
Name: WAW85Sing
Hostname:
InstanceType: COP64.2/4096/60
IP:
KeyName: <key_name>
Owner: <user_id>
RequestID: 293212
RequestName: <instance_name>
Status: NEW

Step 1d: Provision WAS 8.5 instance
Wait for instance provisioning to complete
You need to wait until the status becomes ACTIVE before being able to use the instance. You can do that
with the describe-instance command, as shown below, supplying the instance ID from the output of the
command above.

>ic-describe-instance.cmd -u <user_id> -g <password_file> -w <passphrase> -l
291017
Executing action: DescribeInstance ...
ID: 293212
Name: <instance_name>
Image ID: 20056246
Hostname: vhost0773.dc1.sg.ap.compute.ihost.com
InstanceType: COP64.2/4096/60
IP: 170.225.163.8
KeyName: <key_name>
Owner: <user_id>
RequestID: 293512
RequestName: was85Sing
Status: ACTIVE
Location: 141
. . .

Step 1e: Check WebSphere server status
Use the WebSphere command like to check server status
The WebSphere server should start by default when the virtual machine boots. However, it can take some
time to start up. We can check the status via command line with the serverStatus command. Execute
the command shown below as the WebSphere virtuser via SSH.

$ /opt/IBM/WebSphere/AppServer/bin/serverStatus.sh -all
. . .
ADMU0508I: The Application Server "server1" is STARTED

If the server is not started then you can start it with the startServer command below.

$ /opt/IBM/WebSphere/AppServer/bin/startServer.sh server1


Step 2a: Deploy application to WAS
Use the WAS Admin Scripting tool to configure directory monitoring

The WAS directory monitoring feature allows you to deploy applications by copying enterprise
archive files to a certain directory. Logon to the server with PuTTY, change to virtuser, and
execute the commands below. Enter virtuser and the password you provided in the previous
step when prompted by wsadmin.

$ su - virtuser
$ /opt/IBM/WebSphere/AppServer/bin/wsadmin.sh -lang jython

wsadmin> AdminConfig.modify('(cells/BaseAppSrvCell|
cell.xml#MonitoredDirectoryDeployment_1)', '[[enabled "true"]
[monitoredDirectory "${USER_INSTALL_ROOT}/monitoredDeployableApps"]
[pollingInterval "5"]]')

wsadmin> AdminConfig.save()

Wsadmin> exit


Use the WAS Integrated Solution Console to configure directory monitoring

You need to restart the server before these changes will take effect. To do that logon to the
server with PuTTY, change to virtuser, and restart the server with the commands below.

> su - virtuser
> /opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1
> /opt/IBM/WebSphere/AppServer/bin/startServer.sh server1


Use the WAS Integrated Solution Console to check that directory monitoring is configured. Log onto the
WAS administrative console (Ingrated Solution Console / ISC) at the address below.
https://<ip_address>:9043/ibm/console/logon.jsp and to to Applications | Global Deployment Settings.


Step 2b: Deploy application to WAS
Copy the EAR file to the monitored directory

Demo uses a simple enterprise application packages as an EAR file, called migrationEAR.ear.
Copy the EAR file to the primary server using PuTTY pscp program as idcuser, as shown
below.

> pscp -i <key_file> migrationEAR.ear idcuser@<primary_server>:migrationEAR.ear

As idcuser, change owner and copy to monitored directory

$ sudo chown virtuser:users migrationEAR.ear
$ sudo mv migrationEAR.ear
/opt/IBM/WebSphere/Profiles/AppSrv01/monitoredDeployableApps/servers/server1/.

The application will show up in the WebSphere administrative console (next page)


Step 2c: Deploy application to WAS
Check that the example enterprise application is show in the Enterprise Application
in ISC


Use the WAS Admin Scripting tool to verify application status

Rather than using the WebSphere administrive console you can use the wsadmin scripting tool
to verify the application status. To do that change to virtuser, and execute the commands
below.

> su - virtuser
> /opt/IBM/WebSphere/AppServer/bin/wsadmin.sh -lang jython

wsadmin> AdminApp.list()
'migrationEAR
query'
Wsadmin> exit


Step 2d: Deploy application to WAS
Test the application by pointing your browser directly to WebSphere at the IP and
port address of primary server


HTTP Server Plug-in

The IBM HTTP Server is bundled with the WebSphere image and configured by default.
Generate the plug-in by selecting the check box for the web server and click the Generate
Plug-in button.


Step 3b: Deploy application to WAS
Alternative - start the HTTP Server from the command line

If the IBM HTTP server is not already running start it with the apachectl command and check
that it is running and accessible with the curl command.

$ sudo /opt/IBM/HTTPServer/bin/apachectl start
$ curl localhost


Step 4: Test Application
Point browser at IP address of web server (port 80)


Step 5a: Setup DNS System
Install the BIND named service

Provision a RHEL 6.2 (64-bit) system with the command

>ic-create-instance.cmd -u <user_id> -g <password_file> -w <passphrase> -k
20025211 -n BIND_RHEL6 -t "COP64.2/4096/60" -L 141

Install BIND from the yum repository with the commands below

$ sudo /bin/bash
# yum install bind

Start server and verify installation (see backup slides for nslookup and dig tools)

# service named start
# dig www.yahoo.com
# nslookup www.yahoo.com localhost


Step 5b: Setup DNS System
Configure BIND for our test domain

We will make our server the primary name server for the domain mymigration.test. We will
add a zone statement for this and include a zone file that will contain the individual Resource
Records for the domain. Edit the main configuration file /etc/named.conf and add the
following section

zone "mymigrationtest.com" {
type master;
file "mymigrationtest.com";
};

Edit the lines that related to the listener and query restrictions.

listen-on port 53 { any; };
. . .
allow-query { any; };


Step 5b: Setup DNS System
Add DNS records

Create the include file /etc/named/mymigration.test for the domain and add a name text as
shown below. It includes Time to Live ($TTL), root name ($ORIGIN), start of Authority (SOA)
entries, and some Address (A) Resource Records. Use your own host name and IP address.

$TTL 1h
$ORIGIN mymigrationtest.com.
@ 1D IN SOA ns hostmaster (
2006100201 ; se = serial number
1h ; ref = refresh
15m ; ret = update retry
3w ; ex = expiry
3h ; min = minimum
)
IN NS ns.mymigrationtest.com.
ns IN A 170.224.168.200
vhost0773 IN A 170.225.163.8
www IN CNAME vhost0773
db IN CNAME vhost0773


Step 5c: Setup DNS System
Start the BIND named service

Set the service on by default and start it with the commands below

# chkconfig named on
# service named start

Open the port 53 in the firewall for both UDP and TCP with the commands below.

# vi /etc/sysconfig/iptables
# Add line allowing any port if accessed from the local machine.
. . .
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
. . .
# /sbin/service iptables restart


Step 5c: Setup DNS System
Configure your DNS client

On a Linux system edit the /etc/resolv.conf file adding a line like shown below. Use the IP
address of your own DNS server.
nameserver 170.225.163.150

Test it out using the dig command on the VM with the BIND server
# dig www.mymigrationtest.com
;; ANSWER SECTION:
www.mymigrationtest.com. 3600 IN CNAME vhost0773.mymigrationtest.com.
vhost0773.mymigrationtest.com. 3600 IN A 170.225.163.8
. . .

# nslookup www.mymigrationtest.com
Server: 170.224.168.200
Address: 170.224.168.200#53

www.mymigrationtest.com canonical name = vhost0915.mymigrationtest.com.
Name: vhost0773.mymigrationtest.com
Address: 170.225.163.8


Step 5c: Test Application
Configure Windows client to use the nameserver


Step 5c: Test Application
Point browser at hostname of web server
(www.mymigrationtest.com/migrationWAR/TestServlet)

Sometimes the DNS resolution can be cached for a long time on Windows.
If you have trouble try on Linux. If you do not have access to a Linux
desktop try using curl:

$ curl http://www.mymigrationtest.com/migrationWAR/TestServlet
Hello migration test - from vhost0773


Step 6a: Setup Secondary System
Repeat steps from Step 1c provisioning primary system but in secondary data center

The ID of the RTP data center is 41. The image ID of the IBM WebSphere Application Server
V8.5 - BYOL image in the RTP data center is 20056236.

> ic-create-instance.cmd -u <user_id> -g <password_file> -w <passphrase> -k
20056236 -n <instance_name> -t "COP32.1/2048/60" -L 41 -m
"{WASAdminPassword:***,WASProfileType:production}"

Either repeat application deployment install and configuration steps for the primary steps as
explained above or export the profile of the primary and import into the secondary system. If
you decide to export the profile then you will need to stop the server while you export the
profile.


Step 6b: Setup Secondary System
Export the WebSphere profile from primary to the secondary machine

In our simple example we have not made any configuration changes to WebSphere. If we
had, we could extract the properties from the primary system with the command below.

AdminTask.extractConfigProperties('-configData Server=server1 -propertiesFileName
/home/virtuser/myProperties.props')

This will export all the properties for server1 to the file /home/virtuser/myProperties.props. The
file should be scanned for any IP addresses or host names associated with the primary
environment and changed with a text editor or program. Then it should be copied to the
secondary server, imported with the command below, and then the changes saved.

AdminTask.applyConfigProperties('-propertiesFileName /home/virtuser/myProperties.props
-validate true')
AdminConfig.save()


Step 7: Redirect traffic to secondary server
Change CNAME record to point at new web server

Edit the include file /etc/named/mymigration.test for the domain and add a name text as
shown below. Use your own host name and IP address. Restart the nameserver after making
the change.

$TTL 1h
$ORIGIN mymigrationtest.com.
@ 1D IN SOA ns hostmaster (
2006100201 ; se = serial number
1h ; ref = refresh
15m ; ret = update retry
3w ; ex = expiry
3h ; min = minimum
)
IN NS ns.mymigrationtest.com.
ns IN A 170.224.168.200
vhost0773 IN A 170.225.163.8
vhost2242 IN A 170.224.168.202
www IN CNAME vhost2242
db IN CNAME vhost2242


Step 8: Post maintenance message on primary server
Copy maintenance message in HTML file with message and redirect to index.html
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<meta http-equiv="Refresh" content="10; url=http://170.224.168.202" />
<title>Maintenance message</title>
</head>
<body>
<h1>Maintenance message</h1>
<p>
This server is under maintenance.
Please go to <a href='http://170.224.168.200'>http://170.224.168.202</a>
</p>
</body>
</html>


Step 8: Post maintenance message on primary server
Copy maintenance message in HTML file with message and redirect to index.html


Step 9: Test secondary system
Show browser


Steps to extend to a more complex service

1) Use a more professional redirect with HTTP server configuration
2) Use DB2 HADR to migrate the database data
3) Use rsync to synchronize files in the WAS monitored directory that may change
4) Expand to a composite application with multiple instances – use DNS for system
dependencies
5) Use VLAN to avoid opening of ports on internet for communication between instances in
composite system
6) Migrate SSL certificates


Case Study
Synchronizing files for a database application using rsync


Scenario: Synchronizing file systems
from primary to secondary virtual machines with rsync

This scenario will demonstrate using rsync to synchronize a directory tree from a primary to a secondary
virtual machine. rsync is an ideal tool for doing this. rsync efficiently detects changes in the directory tree in
the primary system then compresses and copies those changes on the secondary system, where they are
re-assembled.

In the scenario we will set up database on primary and secondary servers and use rsync to synchronize the
database files from the primary server to the secondary. It will use SSH to copy the files for security over
the Internet.

Steps
1) Setup Derby on the primary server
2) Create a database
3) Create a table and add a record
4) Use rsync to copy the database files.
5) Test that you can view the database records in the secondary system.
6) Add more data to the primary database, synchronize, and test for the new data on the secondary.



Data Center 1
Primary

SSH
Derby
Database

Administrator SSH rsync

Data Center 2
Secondary

Derby
Database


Step 1a: Installing the Apache Derby Database

Concepts
– Apache Derby is a lightweight embedded database that we will use to demonstrate a
scenario migrating a database application on the cloud
– Derby can be freely downloaded from http://db.apache.org/derby/.

Basic installation with download using cURL. Adjust for the latest version of Derby and mirror
closest to you. Perform the commands below as root.

# mkdir /opt/Apache
# cd /opt/Apache
# curl -o db-derby-10.9.1.0-bin.zip http://labs.mop.com/apache-mirror//db/derby/db-derby-
10.9.1.0/db-derby-10.9.1.0-bin.zip
# unzip db-derby-10.9.1.0-bin.zip
# export JAVA_HOME=/opt/IBM/WebSphere/AppServer/java
# export PATH=$JAVA_HOME/bin:$PATH
# export DERBY_HOME=/opt/Apache/db-derby-10.9.1.0-bin
# export CLASSPATH=$DERBY_HOME/lib/derby.jar:$DERBY_HOME/lib/derbytools.jar:.
# cd $DERBY_HOME/bin
# . ./setEmbeddedCP


Step 1b: Confirming the Derby installation
Verify the Derby install with the command below

# java org.apache.derby.tools.sysinfo
------------------ Java Information ------------------
Java Version: 1.6.0
Java Vendor: IBM Corporation
. . .


Step 2: Setting up a database
Use the ij tool to create a database. We use a directory outside where the software is installed. Execute the
following commands as idcuser.

$ export JAVA_HOME=/opt/IBM/WebSphere/AppServer/java
$ export PATH=$JAVA_HOME/bin:$PATH
$ export DERBY_HOME=/opt/Apache/db-derby-10.9.1.0-bin
$ export CLASSPATH=$DERBY_HOME/lib/derby.jar:$DERBY_HOME/lib/derbytools.jar:.
$ java org.apache.derby.tools.ij
ij version 10.9
ij> connect 'jdbc:derby:MigrationTest;create=true';
ij> exit;

This will create the files shown below
# ls
MigrationTest derby.log

The MigrationTest directory contains the database data files.


Step 3: Creating a table and adding data
Use the ij tool to define a table and add data. We need to specify the location of the data directory with the
derby.system.home system property when connecting if it is not the current directory.

$ java -Dderby.system.home=/home/idcuser org.apache.derby.tools.ij
java org.apache.derby.tools.ij
ij version 10.9
ij> connect 'jdbc:derby:MigrationTest';
ij> CREATE TABLE users(id INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1,
INCREMENT BY 1), username VARCHAR(40));
ij> INSERT INTO users(username) VALUES ('a.user');
ij> SELECT * FROM users;
ID |USERNAME
----------------------------------------------------
1 |a.user
1 row selected
ij> disconnect;
ij> exit;

The generated value for id illustrates the introduction of a common challenge with migrating data.


Step 4: Use rsync to copy the database files

Concepts
– rsync is a utility that copies differences in a directory tree from a source server to the
destination server
– The data is compressed and may be run over SSH
– Optionally, can configure a machine to act as a hosting server for automated sync
between multiple servers.

Basic use. Run the command below 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.

$ rsync -avz -e "ssh -i .ssh/july26_key" /home/idcuser/MigrationTest
idcuser@170.224.170.123:/home/idcuser
sending incremental file list
MigrationTest/
MigrationTest/service.properties
MigrationTest/log/
MigrationTest/log/log.ctrl
. . .


Step 5: Testing the database on the secondary server
Test that you can access the data in Derby on the secondary server. First, repeat step 1 on the secondary
system to setup Derby.

$ export JAVA_HOME=/opt/IBM/WebSphere/AppServer/java
$ export PATH=$JAVA_HOME/bin:$PATH
$ export DERBY_HOME=/opt/Apache/db-derby-10.9.1.0-bin
$ export CLASSPATH=$DERBY_HOME/lib/derby.jar:$DERBY_HOME/lib/derbytools.jar:.
ij version 10.9
ID |USERNAME
----------------------------------------------------
1 |a.user
ij> disconnect;
ij> exit;


Step 6: Use rsync to synchonize data

Add a user to the primary server and use rysync again.

ij> INSERT INTO users(username) VALUES ('b.user');
ij> disconnect;
ij> exit;
$ rsync -avz -e "ssh -i .ssh/july26_key" /home/idcuser/MigrationTest
idcuser@170.224.170.123:/home/idcuser
sending incremental file list
. . .

Notice that there are far fewer files now. Check that the new data is now available on the secondary
system. You will need to log out and log back into the database with ij to clear the data cache.


Problems and steps to extend to a more complex scenario

1) It is difficult to synchronize data to a secondary system consistently without either using
specialized HADR tools or shutting down the service for the period of the migration
operation.
2) The main problem with copying the underlying database files is that the database must be
inactive at the time the synchronization is done. Otherwise, the files copied may not be
consistent. To be sure, it is best to shut down down the database or disconnect, in the case
of Derby.
3) Use database tools for import and export instead of copying raw files. This will avoid the
danger copying of inconsistent files but be careful of autogenerated sequences.
4) Setup a cron job to automate synchronization of data
5) Use specialized database tools, like DB2 HADR.


WebSphere application migration with profiles


WebSphere scripting and command line utilities
Tools and approach for migrating a more complex application
Primary system setup
a) Setup Derby database
•
Enable user authentication
•
Run Derby in network mode
•
Run Derby client in network mode
•
Install example application
a) WebSphere configuration with wsadmin Jython scripts
•
Create a JDBC provider
•
Create an authentication alias
•
Create and test a data source

Migration Steps

More resources

Sample scripts



Data Center 1
Primary

WebSphere JDBC
HTTP(S)
Server

User Profile
rsync
export
Data Center 2
Secondary

WebSphere JDBC
Server

Create Image
instance
library

Primary setup: Enable user authentication for Derby

When we access a database from an application we typically supply a user name and
password. There are several options for managing users and enforcing authentication in
Derby. We will use the simplest type: BUILTIN. To enable this create the file derby.properties
in the Derby installation (system) directory, with the text shown below.

derby.authentication.provider=BUILTIN
derby.user.virtuser=******
derby.connection.requireAuthentication=true

This sets the user repository to the der file and creates a user virtuser with the given password. For
convenience put the environment variables in .bashrc, as shown below.

$ vi /home/idcuser/.bashrc
. . .
export JAVA_HOME=/opt/IBM/WebSphere/AppServer/java
export PATH=$JAVA_HOME/bin:$PATH
export DERBY_HOME=/opt/Apache/db-derby-10.9.1.0-bin
export CLASSPATH=$DERBY_HOME/lib/derby.jar:$DERBY_HOME/lib/derbytools.jar:.


Primary setup: Run Derby in network mode
One problem that we are very dependent on where the Derby database is installed, the user
that owns the files, and limited in the number of users that can connect. To overcome that we
can run Derby in network mode. Set JAVA_HOME, DERBY_HOME, PATH, and CLASSPATH as
above. Start up the server as idcuser, as shown below in the installation directory (not where
you created the database before).

$ sudo /bin/bash
# cd /opt/Apache/db-derby-10.9.1.0-bin
# java -jar $DERBY_HOME/lib/derbyrun.jar server start
Tue Oct 23 01:40:45 UTC 2012 : Security manager installed using the Basic server security
policy.
Tue Oct 23 01:40:45 UTC 2012 : Apache Derby Network Server - 10.9.1.0 - (1344872) started and
ready to accept connections on port 1527

The server start on port 1527 by default. Edit the firewall rules to allow a local connection and restart the
firewall. You may also need to add a rule explicitly for the IP address of the machine.

$ sudo vi /etc/sysconfig/iptables
. . .
[edit]
-A INPUT -p tcp -m tcp -s 127.0.0.1 --dport 1527 -j ACCEPT
. . .
$ sudo /sbin/service iptables restart

Primary setup: Run the Derby client in network mode

The connect to the database as a client enter the following command.

$ java -jar $DERBY_HOME/lib/derbyrun.jar ij

This will start the ij client in network mode. You will need to connect to the database from within ij. You can
do that with the command below.

ij> CONNECT
'jdbc:derby://localhost:1527/MigrationTest;create=true;user=virtuser;password=******';
ij> CREATE TABLE users(id INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1,
INCREMENT BY 1), username VARCHAR(40));
ij> INSERT INTO users(username) VALUES ('a.user');

The connection URL includes host, port, and database information. The database is recreated again, this
time with virtuser as the owner. This is important to associate a database SCHEMA with the database. The
following select statement exercises the connection.


Primary setup: Defining a JDBC provider
Define a JDBC data source for the Derby database installed above
The Apache Derby JDBC driver is bundled with WebSphere.

The Jython script to define a JDBC data source for Derby is

AdminTask.createJDBCProvider('[-scope Cell=BaseAppSrvCell -databaseType Derby
-providerType "Derby Network Server Using Derby Client 40" -implementationType
"Connection pool data source" -name "Derby Network Server Using Derby Client 40"
-description "Derby Network Server Provider that uses the Derby Client 40."
-classpath [${DERBY_JDBC_DRIVER_PATH}/derbyclient.jar ] -nativePath "" ]')
AdminConfig.save()

This defines a JDBC driver for Derby in network mode. The alternative is to run
Derby in embedded mode.


Primary setup: Defining an authentication alias
Define an authentication alias for the Derby database installed above
An authentication alias is a feature that stores a user name and password
combination in WebSphere, encrypting the password so that it cannot be read.

The Jython script to define an authentication alias is

AdminTask.createAuthDataEntry('[-alias DerbyMigrationTest -user virtuser
-password ******** -description "Connection to the Derby MigrationTest database"
]')
AdminConfig.save()

After executing this script you will be able to use the alias when defining a
datasource definition. It is visible under Global security > JAAS - J2C authentication
data in the WebSphere console. Need to enable Derby for native authentication to
use this.


Primary setup: Defining a data source
Define a data source for the Derby database installed above
A data source encapsulates connection to a specific database

The Jython script to define a data source is

AdminTask.createDatasource('"Derby Network Server Using Derby Client
40(cells/BaseAppSrvCell|resources.xml#JDBCProvider_1350960071099)"', '[-name
MigrationTest -jndiName MigrationTest -dataStoreHelperClassName
com.ibm.websphere.rsadapter.DerbyNetworkServerDataStoreHelper
-containerManagedPersistence false -componentManagedAuthenticationAlias
BaseAppSrvNode/DerbyMigrationTest -configureResourceProperties [[databaseName
java.lang.String MigrationTest]]]')
AdminConfig.save()

The default server hostname localhost and port will be used. It is visible under
Resources > Data sources in the WebSphere console. The difficult point about this
command is determining the ID of the JDBC provider, which is generated by
WebSphere. You can use the AdminTask.listJDBCProviders() command to find it.


Primary setup: Testing the data source
Test that data source is properly configured
A data source encapsulates connection to a specific database

The Jython script to test the data source is

AdminControl.invoke('WebSphere:name=DataSourceCfgHelper,process=server1,platform
=dynamicproxy,node=BaseAppSrvNode,version=8.5.0.0,type=DataSourceCfgHelper,mbean
Identifier=DataSourceCfgHelper,cell=BaseAppSrvCell,spec=1.0', 'testConnection',
'[cells/BaseAppSrvCell|resources.xml#DataSource_1350963565192]',
'[java.lang.String]')

The output of this method should be 0.


Primary setup: example application (part 1)
Application will exercise the data source that we have just configured
The Servlet class definition and getConnection method provide a way to get a Connection
object.
package com.ibm.example.web;

import java.io.*;
import java.sql.*;
import java.util.*;
import javax.naming.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.sql.DataSource;

public class TestDataSourceServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
private static String DS_NAME ="MigrationTest";

private Connection getConnection() throws NamingException, SQLException {
InitialContext ic = new InitialContext();
DataSource ds = (DataSource) ic.lookup(DS_NAME);
return ds.getConnection();
}
. . .

The listUsers method provides a way to get a list of user names.

public List<String> listUsers() throws SQLException, NamingException {
System.out.println("listUsers");
Connection con = getConnection();
Statement s = con.createStatement();
ResultSet rs = s.executeQuery("SELECT * FROM users");
List<String> users = new ArrayList<String>();
while (rs.next()) {
users.add(rs.getString(2));
}
return users;
}


The doGet method is the entry point for the HTTP request

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException {
System.out.println("TestDataSourceServlet.doGet entered");
PrintWriter writer = response.getWriter();
try {
List<String> users = listUsers();
for (String user : users)
writer.println(user);
} catch (SQLException e) {
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e.getMessage());
e.printStackTrace();
} catch (NamingException e) {
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e.getMessage());
e.printStackTrace();
}
}
}


Primary setup: invoking the example application
Package the application into the migrationEAR and copy to the monitored directory
as before. Invoke the Servlet using the URL
http://<primary_ip>:9080/migrationWAR/TestDataSourceServlet.


Migration: Overview
Alternate approach based on profile export when migrating a J2EE application
WebSphere profiles include the applications packaged in them and all other configuration
settings. We will 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 SCE
catalog, except for the additional customization specific to deployed applications.

Steps
1) Export the profile configuration archive from the primary WebSphere system
2) Copy files to the secondary server
3) Test the database
4) Import the profile
5) Update profile for the new host name
6) Perform additional customization for application specific settings, eg data sources


Migration 1: Exporting profile from primary system
Alternate step when migrating a WebSphere application
The profile contains all the configuration properties and topology settings fro the primary
system, compared with properties, which only has configuration properties. However, exporting
and importing profiles requires a restart. Use the manageprofiles command to export the
profile. First stop the web server and admin server from the idcuser login.

$ sudo /opt/IBM/HTTPServer/bin/apachectl stop
$ sudo /opt/IBM/HTTPServer/bin/adminctl stop

Stop the application server and use the manageprofiles command to find and export the
profile

$ 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 -backupFile /home/virtuser/AppSrv01.car
INSTCONFSUCCESS: Success: The profile backup operation was successful.


Migration 2: Copy Derby and WebSphere files
Use rysnc as in case study to copy Derby directory tree

Shutdown the database and copy the directory tree with rsync

$ sudo java -jar $DERBY_HOME/lib/derbyrun.jar server shutdown
$ sudo rsync -avz -e "ssh -i /home/idcuser/.ssh/july26_key" /opt/Apache/db-derby-10.9.1.0-bin
idcuser@170.225.161.191:/tmp

Since the WebSphere profile and .bashrc are just singles file use the scp command to copy it

$ sudo scp -i /home/idcuser/.ssh/july26_key /home/virtuser/AppSrv01.car
idcuser@170.225.161.191:/tmp/AppSrv01.car
$ scp -i /home/idcuser/.ssh/july26_key /home/idcuser/.bashrc idcuser@170.225.161.191:.bashrc

Log into the secondary machine and move the files to the proper places, edit firewall rules, and
change owner of the configuration archive.

# mv /tmp/db-derby-10.9.1.0-bin /opt/Apache/.
# vi /etc/sysconfig/iptables
# /sbin/service iptables restart
# chown virtuser:users /tmp/AppSrv01.car


Migration 3: Test database
Test Derby server and client

Start the Derby server

$ sudo /bin/bash
# cd /opt/Apache/db-derby-10.9.1.0-bin
# java -jar $DERBY_HOME/lib/derbyrun.jar server start

Start the Derby client and check that the database can be used normally.

$ java -jar $DERBY_HOME/lib/derbyrun.jar ij
ij> CONNECT 'jdbc:derby://localhost:1527/MigrationTest;user=virtuser;password=******';
. . .
ij> exit;


Migration 4: Configure Secondary WebSphere System
Import the WebSphere profile into secondary system
The profile contains all the runtime settings fro the primary system. Use the manageprofiles
command to import the profile. First make sure that the web server and admin server are
stopped.

$ sudo /opt/IBM/HTTPServer/bin/apachectl stop
$ sudo /opt/IBM/HTTPServer/bin/adminctl stop

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.

$ 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 -restoreProfile -backupFile
/tmp/AppSrv01.car
INSTCONFSUCCESS: Success: The profile was successfully restored.


Migration 5: Check application on secondary system
Startup WebSphere with the new profile

Startup WebSphere with the command

$ /opt/IBM/WebSphere/AppServer/bin/startServer.sh server1

Invoke the application in a browser with the URL
http://<secondary_ip>:9080/migrationWAR/TestDataSourceServlet.


Migration issues found
Problems with importing the WebSphere profile

The profile contains the host name and IP address frozen in several parts of the profile

SSL certificates

Web server definition

The SSL certificate can be ignored but the web server definition needs to be fixed before it can
be used. The files listed below need to be edited to replace the IP address with the IP address
of the secondary server. Stop the server before making the edits.

$ cd /opt/IBM/WebSphere/Profiles/AppSrv01/config/cells/BaseAppSrvCell/nodes/BaseAppSrvNode
$ grep 170.225.164.30 *
serverindex.xml:
. . .
$ cd
/opt/IBM/WebSphere/Profiles/AppSrv01/config/cells/BaseAppSrvCell/nodes/BaseAppSrvNode/servers
/webserver1
$ grep 170.225.164.30 *
httpd.conf:ServerName 170.225.164.30:80
plugin-cfg.xml: <Transport Hostname="170.225.164.30" Port="9080" Protocol="http"/>
plugin-cfg.xml: <Transport Hostname="170.225.164.30" Port="9443" Protocol="https">
$ grep vhost0773 *
Binary file plugin-key.kdb matches

More resources: Samples scripts
Sample Scripts provide many examples using wsadmin Jython

http://www.ibm.com/developerworks/websphere/library/samples/SampleScripts.html


Import / export

Traverse all objects and exports to a file, import is in another script

WebSphere administration scripts

Miscellaneous administrative tasks, start server, stop server, export an application, etc

WebSphere automated deployment scripts

Deploy and manage applications


X.509 Certificate management with WebSphere wsadmin


X.509 Certificate management: Overview
Certificates are used by web servers to provide secure connections to end users
and to provide secure communications between systems.


You cannot simply migrate certificates from one server to another. The CN of the subject in
certificates must match the host name of the server that they are used on.

You can sometimes avoid the problem by adding an exception in the browser, disabling host
name checking in code, or completely disabling checking in code

You can to use a common certificate signing authority to avoid the need for exceptions

Tools

OpenSSL

An open source toolkit for implementing SSL and TLS

Includes tools for creating certificates, including processing certificate signing requests

Ikeyman

An open source toolkit for implementing SSL and TLS

Graphical tool for certificate management for the IBM

WebSphere wsadmin
• Helps to automate management of the certificates within the WebSphere Application
Server system

X.509 Certificate management: Host name matching


Certificate management: Querying certificates
Certificates are stored in either a regular certificate store or a signer certificate store.

You can get a list of certificate stores with the wsadmin Jython script below. Save the file to a
script called list_certs.py.

print AdminTask.listKeyStores('[-all true -keyStoreUsage SSLKeys ]')

You can execute this from the wsadmin console, as shown below.

$ /opt/IBM/WebSphere/Profiles/AppSrv01/bin/wsadmin.sh -lang jython -f
/home/virtuser/list_certs.py
. . .
NodeDefaultKeyStore(cells/BaseAppSrvCell|security.xml#KeyStore_BaseAppSrvNode_1)
NodeDefaultTrustStore(cells/BaseAppSrvCell|security.xml#KeyStore_BaseAppSrvNode_2)


Certificate management: Adding new certificates
Certificates are used by web servers to provide secure connections to end users
and to provide secure communications between systems.

You can use the WebSphere administrative console, scripting tool, and command to do
generate certificate signing requests and import certificates. The command to generate a new
certificate signing request is

/opt/IBM/WebSphere/Profiles/AppSrv01/bin/createCertRequest.sh

You will need to use a third party service or another tool, such as openSSL, to sign the
certificate request. That service will have its own signer certificate, which should be imported.
The Jython script to import a signer certificate is

AdminTask.addSignerCertificate('[-keyStoreName NodeDefaultSignersStore -keyStoreScope
(cell):BaseAppSrvCell:(node):BaseAppSrvNode -certificateFilePath /home/virtuser/my_signer.cer
-base64Encoded true -certificateAlias my_signer ]')
AdminConfig.save()

This will import the signer certificate from the file /home/virtuser/my_signer.cer and give it the
alias my_signer.


Resources
1) Amies, Sluiman, Tong, Liu, 2012. Developing and Hosting Applications on the Cloud, ISBN-
13: 978-0-13-306684-5, http://www.amazon.com/dp/B008FP2G5O.
2) Apache Foundation, 2012. Apache Module mod_rewrite,
http://httpd.apache.org/docs/current/mod/mod_rewrite.html.
3) Apache Foundation 2012. Apache Derby Database project web site,
http://db.apache.org/derby/index.html.
4) Batla, M., 2012. WebSphere Application Server V8.5 Administration and Configuration
Guide, IBM Redbook, http://www.redbooks.ibm.com/.
5) Holve, M. 2005. A tutorial on using rsync, http://everythinglinux.org/rsync/.
6) IBM 2010, WebSphere Application Server V7 Migration Guide, Red Paper,
http://www.redbooks.ibm.com/redpieces/pdfs/redp4635.pdf.
7) IBM 2012, IBM SmartCloud Enterprise Command Line Tool Reference,
https://www-147.ibm.com/cloud/enterprise/support
8) IBM, 2012. Sample Scripts for WebSphere Application Server,
http://www.ibm.com/developerworks/websphere/library/samples/SampleScripts.html
9) IBM, 2012. WebSphere Application Server 8.5 InfoCenter,
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp
10)IBM 2012. Knowledge Collection: Migration planning for WebSphere Application Server,
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27008724.


Resources (continued)
1) IBM, 2012. SmartCloud Enterprise Customizing Images and Software Bundles,
http://www.ibm.com/cloud/enterprise.
2) IBM Authors, Preparing for IBM PureApplication System: Article series on onboarding your
applications, developerWorks,
http://www.ibm.com/developerworks/websphere/library/techarticles/1204_pureapp_articles/1204_
.
3) Internet Systems Consortium, BIND, web page,
https://www.isc.org/software/bind/documentation
4) OpenSSL project web site, http://www.openssl.org/.
5) Red Hat, Red Hat Enterprise Linux, documentation page,
https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_Linux/.
6) rsync project, http://rsync.samba.org/.
7) Willenborg, et al, 2008. Using virtual image templates to deploy WebSphere Application
Server,
http://www.ibm.com/developerworks/websphere/techjournal/0705_willenborg/0705_willenborg.htm


Backup


DNS troubleshooting tools


Tools for workload migration – DNS
Concepts
– Domain Name System (DNS) allows servers to change without affecting end users, who connect to
a service via a URL that includes a hostname
– A Resource Record (RR) is a mapping of a hostname to an IP addresses
– Multiple hostnames may be associated with an IP address
– Default port 53
Client configuration
– A DNS resolver is provided by the OS to eliminate need for applications to implement their own
– Set nameserver in /etc/resolv.conf on Linux systems
– In response to a non-recursive query the nameserver does not query other servers
– In response to a recursive query the nameserver will query other servers
– The length of time that a client will cache a record is called the Time to Live (TTL)
– Common tool to discover more about names is nslookup, eg
$ nslookup <name> [nameserver]
Server (nameserver)
– A caching server stores a cache of name to address mappings and queries root servers with a
recursive request when it gets a ansked for a name that it does not have in its cache
– An authoritative server stores the definitions for a zone of name to address mappings
– DNS security extensions (DNSSEC) now includes cryptographic methods to prevent misuse of
the system
– Options include setting up your own server, a specialized appliance for traffic management (eg
Riverbed Stingray), or third party service if providing DNS name resolution for public systems

Tools for workload migration – BIND
• Concepts
– BIND acts as a DNS namesever binding host names to IP addresses
– BIND is an open source DNS nameserver and is the most popular in use
– Difficult to configure – due to hacking of public DNS servers security has become more
restrictive intrusive
• Client configuration
– We can configure clients to point to our own DNS service with or without registering our
own DNS server
• Server
– Bundled with RHEL
– Can act as either a caching server or an authoritative server or both
– Stores host name to IP mappings in Resource Records
– BIND includes a nameserver that runs as named and a remote administration utility
called rndc


Tools for workload migration – DNS Data
Types of Resource Record (RR)
– Address (A) records
– Canonical names (CNAME) records
– Start of Authority (SOA)
– Mail (MX) records
– Pointer (PTR) records
– Others
Address (A) records
– Maps a host name to an IP address
Canonical names (CNAME) records
– An alias of another hostname
– Used to provide multiple hostnames for a given server
Start of Authority (SOA)
– Used by an authoritative server to defines naming characteristics for a zone (domain), such as the
domain name and time to live


Tools for workload migration – DNS Tools
nslookup – included with Linux Standard Base (LSB)
Concepts
– A common tool to discover more about names is nslookup, basic form is
$ nslookup <name> [nameserver]
Example
# nslookup www.yahoo.com
Server: 170.224.55.203
Address: 170.224.55.203#53

Non-authoritative answer:
www.yahoo.com canonical name = fd-fp3.wg1.b.yahoo.com.
fd-fp3.wg1.b.yahoo.com canonical name = ds-fp3.wg1.b.yahoo.com.
ds-fp3.wg1.b.yahoo.com canonical name = ds-any-fp3-lfb.wa1.b.yahoo.com.
ds-any-fp3-lfb.wa1.b.yahoo.com canonical name = ds-any-fp3-
real.wa1.b.yahoo.com.
Name: ds-any-fp3-real.wa1.b.yahoo.com
Address: 98.139.183.24


Tools for workload migration – DNS Tools
dig – client tool included with BIND
Concepts
– Similar to nslookup but more useful, basic form is
$ dig [@nameserver] <name>
Example
# dig www.yahoo.com
;; QUESTION SECTION:
;www.yahoo.com. IN A
;; ANSWER SECTION:
www.yahoo.com. 300 IN CNAME fd-fp3.wg1.b.yahoo.com.
fd-fp3.wg1.b.yahoo.com. 300 IN CNAME ds-fp3.wg1.b.yahoo.com.
ds-fp3.wg1.b.yahoo.com. 60 IN CNAME ds-any-fp3-lfb.wa1.b.yahoo.com.
ds-any-fp3-lfb.wa1.b.yahoo.com. 300 IN CNAME ds-any-fp3-real.wa1.b.yahoo.com.
ds-any-fp3-real.wa1.b.yahoo.com. 60 IN A 98.139.183.24
;; AUTHORITY SECTION:
wa1.b.yahoo.com. 389035 IN NS yf2.yahoo.com.
wa1.b.yahoo.com. 389035 IN NS yf1.yahoo.com.
;; ADDITIONAL SECTION:
yf1.yahoo.com. 78789 IN A 68.142.254.15
yf2.yahoo.com. 78789 IN A 68.180.130.15
;; Query time: 35 msec
;; SERVER: 170.224.55.202#53(170.224.55.202)


Trademarks and notes

©IBM Corporation 2012

IBM, the IBM logo, ibm.com, Cognos, DB2, Informix, Lotus, Rational, SmartCloud, System x, Tivoli and
WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the
United States, other countries, or both. If these and other IBM trademarked terms are marked on their first
occurrence in this information with the appropriate symbol (® or ™), these symbols indicate US registered or
common law trademarks owned by IBM at the time this information was published. Such trademarks may
also be registered or common law trademarks in other countries. A current list of IBM trademarks is
available on the web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml
Intel is a trademark of Intel Corporation or its subsidiaries in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or
both.

Other company, product and service names may be trademarks or service marks of others.
References in this publication to IBM products or services do not imply that IBM intends to make them
available in all countries in which IBM operates.


Workload migration on the cloud

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a Workload migration on the cloud

Semelhante a Workload migration on the cloud (20)

Último

Último (20)

Workload migration on the cloud