Simplify Cloning by Using Hosts File

Oftentimes, you will find there is a need to install a same application on different systems.  In our case, we have a multi-tier setup for benchmark:

• Oracle Application Testing Suite (OATS)
• Application Server
• Database Server

This means that individual server need to communicate with other servers using their domain names.

In this article, we will discuss the simplest way of cloning an application from one environment to another.

Hosts File

The hosts file allows you to define which domain names (websites) are linked to which IP addresses. On some platforms, it takes precedence over your DNS servers.  However, the hosts file is under the direct control of the local computer's administrator unlike the DNS. So your DNS servers may say oracle.com is linked to a specific IP address, but you can have oracle.com go anywhere you want by using hosts file.

In Microsoft Windows, hosts file is located at locations depending on your OS.  For example, for NT, 2000, XP (x86 & x64), 2003, Vista, 7and 8, it is located at:

• %SystemRoot%\system32\drivers\etc\hosts
• Need to have write permission on this file for the editing user

In Linux, hosts file is located at:

• /etc/hosts

Hosts file is a plain text file and you can use any text editor to modify it as long as you are given the permission. After modification, it will take effect immediately without rebooting. So, you can restart your application to see the new changes right away.

Redirection

In its function of resolving host names, the hosts file may be used to define any host name or domain name for use in the local system. This may be used either beneficially or maliciously for various effects.  In this article, we will discuss using the mapping to redirect a website (i.e., source of cloning) to another website (i.e., destination of cloning) during the cloning of a multi-tier environment.  Because our multi-tier environment exists in a private network, there is no security concern for us.  However, it is possible for you to face serious security attacks if your hosts file is compromised^[3].

As we all know, to deploy and configure any web application is a non trivial task.  As performance engineers, we often need to create similar systems on different set of servers.  Instead of  deploying and configuring web applications from scratch, it will be easier to just do the cloning.

After cloning the application from one system to another, you then need to fix platform-specific part in the cloned image.  For example, you need to change the domain names referenced in the URLs from old server's to new server's.  Domain names can also be embedded in configuration files, scripts, etc.  Either you can do a global search and replace them or you can modify hosts file to map same host names to the new IP addresses.  The latter is easier.

Cloning^[4]

Cloning can be done in three stages and the most important stage is the preparation or pre-cloning.  In the following, we cover the tasks involved in these stages for Linux platforms.  For Windows, the steps are similar.

• Pre-cloning Stage
• nohup
• Cloning can take hours to finish.  
• If you use "putty" to access Linux box, remember to use "nohup" command
• nohup is used to run a command that is immune to hangups
• For example, you can prefix your cloning command with nohup and redirect the stderr and stdout to cloning.out file:
• nohup {cloning command} &> cloning.out &
• Be the right user that has the privilege to do the cloning.  
• Sometimes, you may need to be the "root" user to do the cloning.  After the cloning, you can then reduce the accessibility to the correct level.
• Create the same path structure on the destination as source's
• Create symbolic links if needed
• You may need to be root user to create the path.  But, reduce the accessibility to the correct level later.
• Find the file system (or disk) that is big enough to hold the cloned image
• Free space left should allow application data to grow after it starts running
• Hosts file
• Save the original hosts file
• Shutdown server instances before cloning
• Cloning Stage
  • Copy everthing needed from source machine to destination machine.  This can include
    • Server installation
    • Scripts
    • hosts file
    • Copy the new hosts file from source to destination machine and make appropriate changes
    • Validate the changes.  For example, you can use ping command to test 
  • Use rsync command to clone
  • Syntax:
  • rsync -az aroot@sourceServer:/export/home/bench/ATG/RUP3 /export/home/bench/ATG/
  • Don't forget to use nohup for the rsync
  • Try the command out with a small copy first
  • Be patient—the cloning could take hours
• Post-cloning Stage
• Verify that your cloned environment work as expected
• You can test this by stages.  For example, you can
1. Run your front end (or OATS) against original Application Server and Database Server first.  After verifying that your front end system is working correctly, move to next.
2. Run your application server against original Databasse Server. After verifying that your middle tier is working correctly, move to next.
3. Verifying your database server is working correctly.
4. Run your application server against your new database server.
5. And so on.
• Document what you have done

Warning

Cloning applications seems to be straightforward.  But, there are limitations and caveats. You can read [5,6,9,10] for such details.  If you are cloning Oracle Fusion Middleware, read [7].  If you are moving from a test to a production environment, read [8].  Finally, you must pay attention to the license-violations-and-compliance issue when you plan a cloning.

References

1. Oracle Application Testing Suite
2. 6 Surprising Uses For The Windows Hosts File
3. Hosts (Wikipedia)
4. Cloning Application Server Middle-Tier Instances
5. General Considerations and Limitations for Cloning
6. ORA-00313: open failed for members of log group 1 of thread 1
7. Cloning Oracle Fusion Middleware (Chapter 20)
8. Moving from a Test to a Production Environment (Chapter 21)
9. Cloning Issue—What If Host Name(s) Are Stored in the Database
10. ORA-01031: insufficient privileges
11. Migrating Oracle B2B from Test to Production (T2P) (Chap 10 of the Book "Getting Started with Oracle SOA B2B Integration: A Hands-On Tutorial")
• This section provides a real-world scenario to replicate (clone) the test environment to production for Oracle SOA.
• Oracle Fusion Middleware provides a series of scripts for this task.
12. Oracle Products: What Patching, Migration, and Upgrade Mean? (Xml and More)
• For your Oracle production systems, follow official recommendations as shown in this article.