Article ID: 114400, created on Jul 18, 2012, last review on Nov 11, 2014

  • Applies to:
  • Operations Automation 5.4

Linux Shared Hosting NG: Migration

Migration methods

In case both Standard and NG Linux Shared Hosting services are deployed in POA Provider may migrate websites from Standard to NG hosting.

Two migration ways are supported:

  • "by-host" migration - transfers all websites from a hardware or virtual node during a single migration procedure. To migrate websites from two or more nodes, perform "by-host" migration for every node one by one.

  • "by-subscription" migration - transfers websites of selected subscriptions to target NG hosting (websites to be migrated can be provisioned on different Shared Hosting Nodes).

Limitations

  • Migration tool does not provide any way to migrate MySQL or PostreSQL databases.
  • Servers with customer backups cannot be migrated.
  • When migration begins, websites cannot be utilized or accessed via FTP or or SSH. For migration period websites are being suspended. After migration is completed, websites automatically become active.
  • Hosts with branding sites cannot be migrated.
  • Customer backups created before migration can be only partially restored: database backups are restored as expected, disk content is not automatically restored (but can be restored manually).

Preparation steps

For "by-host" migration:

  • If source server is PVC container Offline Management must be disabled for it, to avoid IP address conflict after migration.
  • Make sure that only the following POA applications are running on the source server:

    • logparser
    • logrotate
    • crontab
    • Apache
    • Proftpd

    For both "by-host" and "by-subscription" migration methods:

  • Ensure that proper IP pools are attached to the target server. For "by-host" migration target node must have all used IP pools from source node attached.
  • Ensure that SSH access without password is enabled from source to target director node (it is necessary for web sites content synchronization). Distribute SSH keys between servers to enable password-less SSH access from source to target server.
  • Create or choose existing Service Templates and Resource Types for the websites on Linux Shared Hosting NG. Subscriptions of migrated websites will be upgraded to these Service Templates during migration. If you create new Service Templates, make sure they comply with the Linux Shared Hosting NG configuration restrictions. For more details on configuring Linux Shared Hosting NG Service Template, refer to the POA Provider's Guide > Linux Shared Hosting NG Service > Webspace Management Operations > Setting Resource Limits for Service Template section.
  • If source and target Service Templates contain resources for APS applications, make sure they use same Resource Types. Using different Resource Type of the same application in source and target Service Templates may cause application deletion during migration.
  • If migration is performed on integrated installation of POA and PBA (PBA >= 5.0 is supported), create appropriate Service Plans in PBA. To allow upgrade of current subscription Service Plan to new one and opposite downgrade, you must update possible upgrade/downgrade lists of both plans in PBA. For instructions on configuring Service Plans in PBA refer to Provider's Guide > Managing Service Plans > Configuring Service Plan Allowed Upgrades/Downgrades section. To upgrade subscriptions to the target Service Plans in PBA migration script will place Upgrade Order for each subscription that is migrated.
  • Make sure that the target Web Cluster NG or Web Server NG uses the same version of webalizer as the source node. Webalizer version of Web Cluster is shown on the summary page of cluster. Webalizer version of source node can be found in the list of packages installed on it in POA Provider Control Panel. If any of the conditions above are not satisfied, migration procedure does not start and the pre-migration checker indicates problem with appropriate message.SSH. For migration period websites acquire suspended state. After migration is completed, websites automatically become active.

IP Management

  1. "By-host" migration.

    During migration IP addresses from source host are automatically propagated to NG Load Balancer and Web Servers, so websites retain their IP addresses and there is no need in DNS reconfiguration. Migration of websites is not performed instantly, so there is short period of downtime.

  2. "By-subscription" migration.

    Websites on exclusive IPs are switched to shared IP, thereby returning free IPs to attached IP pools. Shared website IP from source host is then replaced with one of the shared IPs from target host. Finally previously "exclusive IP" websites are switched back to exclusive IPs, thereby allocating new IPs from IP pools attached to target host. DNS reconfiguration tasks are scheduled automatically. Migrated websites will not retain initial IPs even after reversion.

Service Templates/Plans mapping

Subscriptions based on the Service Templates/Plans for Standard Shared Hosting will be upgraded to the Linux Shared Hosting NG ones during migration.

Create a configuration file with mapping between Standard Shared Hosting Service Templates and Linux Shared Hosting NG Service Templates using the format described below.

  1. Standalone POA installation (no PBA):

     # All subscriptions based on Service Template <source_st_id> will be upgraded to Service Template <target_st_id>
     [service templates]
     <source_st_id>=<target_st_id>
    
  2. POA is integrated with PBA:

    # All subscriptions based on Service Plan <source_sp_id> will be upgraded to Service Plan #<target_sp_id>
     [service plans]
     <source_sp_id>=<target_sp_id>
    

    For example:

    # All subscriptions based on service template #3 will be upgraded to service template #15
    # All subscriptions based on service template #5 will be upgraded to service template #16
    [service templates]
     3=15
     5=16
    

    Comments are allowed starting with the # symbol. The section [service_templates] defines the mapping between the old and the new POA Service Templates. The section [service_plans] defines the mapping between the old and the new PBA Service Plans.

Running migration

After all preparations steps are completed run the migration procedure.

  1. Place the archive with migration script poa-lshng-migration-<POA major version>-<build-number>.tar.gz to the POA Management Node and unpack it.
  2. On the POA Management Node, create a migration configuration file with the properly structured content.
  3. Run the migration script.

"By-host" migration

  • Standalone POA: ./migrate.py --target-id <id_of_cluster_or_web_server_ng> --source-id <host_id> --config <path_to_config>
  • POA integrated with PBA: ./migrate.py --target-id <id_of_cluster_or_server_ng> --source-id <host_id> --config <path_to_config> --with-pba

    For example:./migrate.py --target-id 20 --source-id 3 --config ./migrate.cfg

For the parameters description, refer to the table below:

Parameter Description
target-id <id_of_ng> Specifies the target Web Cluster/Server NG unique identification number that is assigned to it during its creation.
source-id <host_id> Specifies the source node unique identification number that is assigned to it during its creation.
config <path_to_config> Specifies the location of the migration configuration file.

"By-subscription" migration:

  • Standalone POA: ./migrate.py --target-id <id_of_cluster_or_web_server_ng> --subscription-id <sub_id> --config <path_to_config>
  • POA integrated with PBA: ./migrate.py --target-id <id_of_cluster_or_server_ng> --subscription-id <sub_id> --config <path_to_config> --with-pba

For example:./migrate.py --target-id 20 --subscription-id 3 --config ./migrate.cfg

For the parameters description, refer to the table below:

Parameter Description
target-id <id_of_ng> Specifies the target Web Cluster/Server NG unique identification number that is assigned to it during its creation
subscription-id <sub_id> Specifies unique identification number of subscription to be migrated
config <path_to_config> Specifies the location of the migration configuration file.

To revert the successfully finished or partially performed migration use the following command: ./migrate.py --checkpoint-file /root/migrate8.cpt revert The migration script will suggest the proper checkpoint file to perform reversion.

Troubleshooting

The migration script saves the execution log to the /root/migrate.log file. Look into it in case of errors.

See the main Knowledgebase article #114326 Linux Shared Hosting NG: General Information, Best Practices and Troubleshooting for more information about NG Hosting in Parallels Automation.

caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae 2554725ed606193dd9bbce21365bed4e ac82ce33439a9c1feec4ff4f2f638899 e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF