Migrating Applications

Overview

To migration applications from your existing cloud to your target cloud, be aware of the following requirements:

  • Stateless application profile that can deploy a fresh/clean copy of the application without a state in either cloud
  • A method to preserve and move the application state (containing data) – for example, take a database dump, copy it to cloud storage, then copy back, and restore the database.

If you have these two requirements in mind, the CloudCenter platform can help with your migration! The CloudCenter migrate feature helps you deploy a new, clean copy of the application to your target cloud and then perform the application state move based on the scripts you provide.

There is no reason to delete the VM(s) on the source side first – you can just leave them running or delete them after the migration is successful.

The migration scenarios in this section are just two examples to consider when migrating applications.

Migrating an N-Tier Application Containing Data

This section uses an application called RollerWeBlog to describe the CloudCenter process to migrate a three-tier Java web application with data running at the customer's location.

Migration Guidelines

  • Services:
    • CloudCenter does not provide out-of-box mapping for any cloud-specific service to an alternate service in another environment.
    • If using cloud-specific services (such as ELB or RDS), then the author/owner of the Application Profile must be aware that are making a decision to lock that Application Profile to a particular cloud (for example, AWS).
    • However, you can create a custom service definition and include the scripts required to detect whether it was being deployed in AWS or in VMWare or another cloud and then connect that application to either the ELB or their F5 load balancer.
  • DNS:
    • CloudCenter does not inherently update the DNS to point to a migrated deployment.
    • However, you can configure the migration process to include any scripts required to change the DNS mapping in your environment.
    • See CloudCenter External URL for additional context.

Process

To migrate an N-tier application with data, follow this process:

  1. Back up the data for the RollerWeBlog application. For this example:
    • The data backup file is called dbbkup.sql.
    • The RollerWeBlog application runs on a different cloud than CloudCenter.
  2. Identify the relevant componentsParameters and Macros, and Configuration Files for this application.
  3. Modify the Configuration File  (or properties file) to include CloudCenter-defined system macros to automatically plug in the appropriate values for parameters defined in the configuration file. Alternately, you can pass these  parameters as arguments to install or configuration scripts.
    • The RollerWeBlog application configuration file changes:

      ../WEB-INF/classes/myconfig-file
      installation.type=auto
      mediafiles.storage.dir=/usr/local/rollerdata/mediafiles
      search.index.dir=/usr/local/rollerdata/searchindex
      log4j.appender.roller.File=/usr/local/rollerdata/roller.log
      database.configurationType=jdbc
      database.jdbc.driverClass=com.mysql.jdbc.Driver
      database.jdbc.connectionURL=jdbc:mysql://%DB_TIER_IP%:3306/rollerdb?
      autoReconnect=true&useUnicode=true&characterEncoding=utf-8&mysqlEncoding=utf8
      database.jdbc.username=scott
      database.jdbc.password=tiger
      mail.configurationType=properties
      mail.hostname=smtp-server.example.com
      mail.username=scott
      mail.password=tiger
    • Prior to the macro substitution, the configuration file had the following description in the highlighted area: 
      database.jdbc.connectionURL=jdbc:mysql://localhost:3306/rollerdb?
      Effectively, the localhost IP address is replaced by a dynamically generated private IP address (database tier) during runtime using %DB_TIER_IP%.
    • In Application Profiles, users can define parameters to pass as arguments to the username and password field. Optionally, users can also include default values in scripts.
  4. After modifying the configuration files with system macros, create a .war application package and include the updated configuration file.
  5. Upload the application data (packages, configuration files, backup data, SQL script, and other scripts) to your shared directory in the Artifact Repository .
  6. Create an application directory under /storage/app/<application name> and upload the application data to the newly created directory.
  7. If the application requires certain parameters to be defined or overridden (administrator, username, and password), include them in the Topology Modeler's Global Parameters section.
  8. Define the application architecture and services using the Topology Modeler. For the RollerWeBlog example, use Tomcat as the web server, MySQL as the database, and NginX as the load balancer. For each tier, use the Properties panel to provide additional details. For example:
    • MySQL tier: Parameters, username, password, the path for the database script that has the backup data from a previous environment, and so forth.
    • RollerWeBlog tier: Define the path for the application binary file (roller.war) and the configuration file.
    • Similarly, provide the dependent details for the Tomcat and NginX tiers as well.
  9. Save the Java web app profile. Access your new application from the Apps tab and verify your changes for each tier. The application is now ready for deployment.
  10. Submit the application for deployment. The CCM sends the application package information (JSON package) to the CCO.
  11. View the deployment progress in the Status field.
  12. SSH or VNC to the cloud VM for additional troubleshooting access or to run additional commands and scripts.
  13. Once the deployment is complete, click the Access link to open the IP address for this application. You may need to specify the full path in the context of the application in the  Topology Modeler's Basic Information pane.
  14. Use the full path URL to access the migrated RollerWeBlog application.

Migrating an N-Tier Application Using Images

You can import existing application images running in a cloud and use them as custom images for a CloudCenter tenant.
This example describes a Siebel CRM application that uses an Oracle database with data running at the customer's location. The data is being migrated from a dedicated on-premises server to a cloud.

To migrate an N-tier application with data, using images, follow this process:

You need CloudCenter administrator privileges to perform this procedure.

  1. Back up the data running on the Siebel CRM application.
  2. Create an image for each tier in the application:
    1. The database with data.
    2. The Siebel CRM application with all dependencies.
  3. Identify the relevant componentsParameters and Macros , and Configuration Files for this application.
  4. Log into CCM UI and access Admin > Image:
    1. Click the Add New link to add a new image.
    2. In the Add a New Image page, fill in the fields to create a logical entry for your image in CloudCenter:
      • OS Type: The OS on which the image is based. For Siebel CRM, the OS is Linux.
      • Number of Network Interfaces: The base image dictates the number of NICs. See IP Allocation Mode for additional context.
  5. Map the logical CloudCenter Images to your actual image:

    1. In the Image Mappings section, select the Cloud Type for the image from the dropdown list.
    2. Enter the Image ID associated with the Cloud Type.

    3. Select all applicable Instance Types supported for this image. You can also override the image cost by not modifying the cost.
    4. After adding the mapping, you can view the mapped image by clicking the image name. You can edit/convert/delete images after creating them.
    5. Repeat the step for each image associated with each tier in this application (for example, the database image, SiebelDB).
    6. Users will see the newly added images during their application deployment process.
  6. Configuration Files (or properties file) to include CloudCenter-defined system macros to automatically plug in the appropriate values for parameters defined in the configuration file. Alternately, you can pass these as arguments to install or configuration scripts.
  7. After modifying the configuration files with system macros, create a .war application package and include the updated configuration file.
  8. Upload the application data (packages, configuration files, backup data, SQL script, and other scripts) to your secure, shared directory in the Artifact Repository:
    1. Create an application directory under /storage/app/<application name>.
    2. Upload the components to the Application Repository to the newly created directory.
  9. If the application requires certain parameters to be defined or overridden (administrator, username, and password), include them in the Topology Modeler's Global Parameters tab.
  10. Define the application architecture and services using the Topology Modeler. For each tier, use the Properties panel to provide additional details. For example:
    1. Siebel Database tier: Parameters, username, password, the path for the database script that has the backup data from a previous environment, and so forth.
    2. Siebel CRM tier: Define the path for the application binary file and the configuration file.
    3. Similarly, provide the dependent details for other applicable tiers as well.
  11. Save the N-Tier app profile as Siebel CRM application. Access your new application from the Apps tab and verify your changes for each tier. The application is now ready for deployment.
  12. Deploy the Application:
    1. Depending on the hardware requirement and application-specific requirements, select the cloud and instance types from the displayed list.
    2. Select the required Instance Types.

  13. Submit the application for deployment. The CCM sends the application package information (JSON package) to the CCO.
  14. View the deployment progress in the Status field.
  15. SSH or VNC to the cloud VM for additional troubleshooting access or to run additional commands and scripts.
  16. Once the deployment is complete, click the Access link (access URL) to open the IP address for this application. You may need to specify the full path in the context of the application in the Topology Builder's Basic Information pane.
  17. Use the full path URL to access the migrated Siebel CRM application.

 

 

  • No labels