Migration

You can define an optional migration section in which you specify custom options and migration details for an environment. When you do not include a migration section in a composite template that you intend to use to migrate an environment, Command Central uses the default migration settings as described in How Command Central Processes a Composite Template for Installations of Release 10.3 or Higher. However, when you want to use a composite template for migration, you must always include the Provision section.

The migration section can include one or more of the following sections:

sourceType

Specifies whether to migrate an environment from an existing archive of the source nodes or directly from the source nodes included in the migration/nodes section. If you do not include this parameter or set the value to NODES, Command Central ignores the migration/archives section. If you set the value to ARCHIVES, Command Central ignores the migration/nodes section. The default is NODES.

Syntax:
sourceType: [ARCHIVES|NODES]

archives

Specifies the location of an existing archive of the source nodes. Note that Command Central ignores this section when sourceType: NODES and uses the node details in the migration/nodes section instead. By default, Command Central searches for the source archive on the Command Central host, in CommandCentral_directory/profiles/CCE/data/migration/source/nodeAlias.zip. If Command Central does not find the archive on its own host, it searches on the target host, in user.home/migration_source_nodeAlias.zip.

Syntax:
sourceType: ARCHIVES
archives:
  targetPath: path/to/source_archive.zip

options

Migration options to prepare the source nodes for migration. Following is a list of the options that you can customize:

  • snapshot

    Creates a template with products, fixes, configuration, and files from each source node. The template does not include product instances. The product instances are created by the product migration utilities. The default is false.

    Syntax:
    snapshot: 
      execute: {true | false}
  • pause

    Pauses all source run-time components. The default value is true.

    Syntax:
    pause: 
      execute: {true | false}
    Note: Command Central requests of all run-time components to pause, but a component processes this request only when it supports the pause operation. For example, Integration Server goes into Quiesce mode, instead of pausing.
  • shutdown

    Stops all source run-time components. This option also shuts down Platform Manager by running the shutdown.sh/bat script remotely through the remoteAccess service. You can set the shutdown option to false only when migrating to a different host on a Unix operating system. For all other types of migration, the default value is true.

    Important: To execute the shut-down operation successfully, Command Central must access the remote operating system through an SSH connection.
    Syntax:
    shutdown: 
      execute: {true | false}
  • backup

    Creates a backup of the source installation directory on the same host machine and transfers the backup archive to Command Central. Note that this step is skipped automatically when migrating on the same host. The backup operation is executed only when you set execute=true, which is the default value. The output of the backup operation is an archive.

    Important: To execute the back-up operation successfully, Command Central must access the remote operating system through an SSH connection.

    When migrating to a different host, in the sourcePath parameter you specify the location in which to create an archive of the installation on the source node and in the targetPath parameter - the location to which to transfer the archive on the target node.

    If you do not specify a value for sourcePath or targetPath, Command Central uses as default location:

    user.home/nodeAlias

    where user.home is the home directory of the user on the source or target machine respectively and nodeAlias is the alias of the source installation.

    To specify which files to exclude from the backup, use the excludes option.

    You can select which file types and file directories to exclude from the source archive in a more granular way, using the optional patterns and except parameters. For example, you can use these parameters when you want to reduce the size of the source archive, but still include required files when migrating to a new host. The patterns parameter specifies which file types and file directories to exclude from the source archive. The default value for patterns is [“*.log”], which means that by default only log files are excluded from the source archive. The except parameter includes a list of file names that are exceptions. The files listed in this parameter are included in the source archive, even when their file type is listed in the patterns parameter. For example, in the following template snippet, all jar files will get excluded from the source archive, except for the "wm-caf-server.jar" file:

    migration:
      options:
        backup:
          
          excludes:
            patterns: ["*.log", "*.jar", "*.zip"]
            except: ["wm-caf-server.jar"]
    Syntax:
    backup: 
      execute: {true | false}
      sourcePath: user.home/nodeAlias
      targetPath: user.home/nodeAlias 
      excludes:
        patterns:  [“*.log”,“*.jar”,“*.zip”,“path/to/directory/to/exclude/*”]
        except: [list-of-file-names-excepted-from-patterns]
  • rename

    Renames the source installation directory to migration_source_sourceVersion_installDir, where sourceVersion is the version of the source installation and installDir is the name of the source installation directory. The rename operation is executed only when migrating on the same host and installation directory (overinstall) or if you set execute=true.

    Syntax:
    rename: 
      execute: {true | false} 
      targetPath: <the path goes here>
      migration_source_sourceVersion_installDir
                         

source

A list of the source nodes that host each layer. The source nodes are defined in source/environment.type/layerAlias sections. For example, the source nodes for an “is” layer in a “cluster” environment are defined in the migration/source/cluster/is section.

nodes

Details about the source nodes, such as host, port, and bootstrap information. Note that Command Central ignores this section when sourceType: ARCHIVES and uses the source node archive specified in the migration/archives section instead.

Example

In the following composite template snippet, the “cluster” environment has a single “is” layer. The target migration nodes are identified from the “provision/cluster/is” section and the source migration nodes from the “migration/source/cluster/is” section. The source and target nodes use the same “is1” and “is2” hosts. Because the “migration/nodes” section does not have any properties, the source nodes map to the Platform Manager port “8093” and the “/opt/sag/test” installation directory, defined in the nodes/default section. The migrate operation creates a template with the products, fixes, configuration, and files for each source node, but does not create a backup archive. All run-time components, including Platform Manager are shut down before starting the migration process and the source installation directory is renamed to “migration_source_cc910”.

environments: 
    default: 
      cc.installer: ${}
      install.dir: /opt/sag/test 
      db.url: “jdbc:wm:sqlserver://dbhost1:1433;databaseName=db1” 
      db.username: user1 
      db.password: pass1 
    cluster: 
      is.hosts: [is1,is2] 
      
layers: 
    default: 
      productRepo: webMethods-12.1-mirror 
      fixRepo: webMethods-12.1-mirror 
    is: 
      templates: [spm-tuneup,is-server] 
     
templates: 
    spm-tuneup: 
      fixes: [wMFix.SPM.Core,wMFix.PIEspm] 
    is-server: 
      fixes: [wMFix.integrationServer.Core] 
      products: 
        integrationServer: 
          is_inst1: 
           primary.port: 5555 
           db.url: ${db.url} 
           db-username: ${db.username} 
           db-password: ${db.password} 
     
migration: 
    options: 
      snapshot: 
        execute: true 
      pause: 
        execute: true 
      backup: 
        execute: true 
        excludes: [“*.jar”,“*.log”] 
      shutdown: 
        execute: true 
      rename: 
        targetPath: /opt/sag/cc910 
    source: 
      cluster: 
        is: [is1,is2] 
    nodes: 
     
provision: 
    cluster: 
      is: [is1,is2] 
     
nodes: 
    default: 
      default: 
        port: 8093 
        secure: true 
        bootstrapInfo: 
          installer: ${cc.installer}
          installDir: ${install.dir}

Specifying Product Migration Settings In a Properties File

You can also include the migration settings in a properties file, named in the following format:

migrate_srcVersion-destVersion_sbs.dat

for example, migrate_9.12.0-10.1.0_sbs.dat

Add the .dat files in the composite template archive in the migration/productId directory.

If an inline template defined in the composite template includes only the product, but does not define any instances for that product, the settings in the .dat file under the directory with this product ID are applied for the product, but not for specific instances of the product. If the inline template includes the product and its instances, the settings in the .dat file for this product ID are applied for all instances defined for that product in the inline template.

Important: Note that on the Platform Manager side, the custom migration settings will be ignored if the migration source and target versions are different from the versions specified in the name of the custom migration settings file.

Example

In the following example, the product with ID “MwsProgramFiles” has a single instance with name “mws_inst1”. To use custom migration settings for “mws_inst1”, create a properties file with name “migrate_9.12.0-10.1.0_sbs.dat” in the migration/MwsProgramFiles directory. When applying the composite template, the custom migration settings from the file are applied for the “mws_inst1”.

templates 
    mws-server: 
      fixes: 
      products: 
        MwsProgramFiles: 
         mws_inst1: 
          http.port: 8585 
          db.url: ${db.url} 
          db.username: ${db.username} 
          db.password: ${db.password}