CloudBlue Technical Support

Linux Shared Hosting NG: Migration

Migration methods

In case both Standard and NG Linux Shared Hosting services are deployed in OA, 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 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 a PVC container, Offline Management must be disabled for it, to avoid IP address conflict after migration.

• Make sure that only the following OA 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, the target node must have all used IP pools from the source node attached.
• Ensure that SSH access without password is enabled from the source to the target director node (it is necessary for web sites content synchronization). Distribute SSH keys between the servers to enable passwordless SSH access from the source to the 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 OA Provider's Guide > Shared Apache Web Hosting > Webspace Management Operations > Setting Resource Limits for Service Template section.
• If the 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 OA and BA (PBA >= 5.0 is supported), create appropriate Service Plans in BA. 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 BA. For instructions on configuring Service Plans in BA, refer to Provider's Guide > Managing Service Plans > Configuring Service Plan Allowed Upgrades/Downgrades section. To upgrade subscriptions to the target Service Plans in BA, 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 OA 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 an appropriate message. 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 the 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 a 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 the 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 OA installation (no BA):

    # 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. OA is integrated with BA:

   # 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 OA Service Templates. The section [service_plans] defines the mapping between the old and the new BA Service Plans.

Running migration

After all preparation 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 OA: ./migrate.py --target-id <id_of_cluster_or_web_server_ng> --source-id <host_id> --config <path_to_config>

• OA integrated with BA: ./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:

"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:

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 Operations Automation.

Internal content