BUSINESS CONTEXT

Part of IMC strategy is to move existing customers from on-premises OA installations to IMC managed PaaS environments (MS Azure Cloud). This will allow to lower operational and maintenance costs, both for IMC and the customer. Moreover, this will streamline adoption of pure CloudBlue platform - without traditional and legacy services. The article describes overall Method Of Procedure (MOP) for such migrations.

SUPPORTED CONFIGURATIONS

  • OA 7.4 and OA 8.0 is supported
  • OA Platform core components is supported (OSS, BSS, UI, Branding, DNS, Online Stores, APS endpoints)
  • OA Cloud modules and services are supported: Office 365, Azure, WebHosting Plesk, etc

UNSUPPORTED CONFIGURATIONS

  • OA traditional hosting modules are NOT supported: legacy Linux and Windows shared hosting, WebHosting Linux (NG), Qmail, Blackberry, Hosted Exchange, SharePoint, Lync, VPS

METHOD OF PROCEDURE

1. Plan migration maintenance windows

1.1. APS1/APS2 nodes

1.2. Branding and UI nodes

1.3. Nameserver nodes

1.4. BSS Online store nodes

1.5. OSS MN + OSS DB nodes

1.6. BSS MN + BSS DB nodes

  • 1.1, 1.2, 1.3, 1.4 requires short downtime windows. Subscriptions' provisioning is delayed; Control panels are available both for provider and customers.
  • 1.5, 1.6 requires longer downtime windows. Subscriptions provisioning is NOT possible. Control panels are NOT available.

2. Execute OA node(s) migration within planned maintenance windows

2.1. APS2 nodes (Yola, PSB, Acronis)

2.1.1 Prerequisites

  1. New (target) APS endpoint nodes have been deployed and are ready to be used (verify connections from and to OSS and BSS)
    • Make sure that all RPMs for the endpoint have been installed
    • Verify that php/perl configuration and modules are identical on source and target node
    • Copy certificates if required from source to target node
  2. Check target RED network AzureIP
  3. Prepare the script switch_endpoint.py (see KB132952) at the current (source) management node

2.1.2 Migration

  1. Turn off Apache/Nginx on source node
  2. Update the endpoint URL using the script switch_endpoint.py
  3. Perform test order and/or upgrade of a resource
  4. Optional: Manually copy logfiles

2.2. APS2 nodes (Office 365 Endpoint)

The migration is based on the procedure provided by RnD: KB132952

During this migration a new endpoint is deployed, the database will be migrated and the endpoint will be updated on OA side using the script described in the KB article.

2.2.1 Prerequisites

  1. New (target) endpoint has been deployed and is ready to be used (verify connections from and to OA and BA)
  2. prepare the script switch_endpoint.py (see KB132952) at the current management node.

2.2.2 Migration

  1. Turn off IIS
  2. Create a backup of the database using the PowerShell command OR MSSQL Studio features.
  3. Copy the database to the target node
  4. Import the database at the target node
  5. Compare the files settings.conf and be sure that it is configured identically (check for OrderStatus for instance)
  6. Restart IIS on the target node
  7. Update the endpoint URL using the script switch_endpoint.py
  8. Perform test order and/or upgrade of a resource and monitor the sitelog of Office 365 node.
  9. Manually copy the logfiles from source node to target node (sitelog, preload etc.)

2.3. APS1 nodes (extprov)

2.3.1 Prerequisites

  1. Be sure that password-less SSH connection between source and target node is possible (required to copy data)
  2. New Azure RED IP zone is available via VPN and on Azure.
  3. Optional (depends on migration option): Shut DOWN pa-agent and backup the folder /usr/local/pem/APS (alternative: create a rsync prior the migration)
  4. Prepare target Azure node with exact same version of PHP and Perl, same modules, same settings

2.3.2 Migration

NB: Allows to prepare a new node for APS 1 packages, test the migration for each package upfront and then switch the endpoint in the OA database at a specific time. See also:APS1 node migration article

  1. Deploy new VM in Azure, with same OS and software versions as current gateway. Network: Azure RED IP (+ Public IP)
  2. Compare configurations and be sure they are identical (mainly php.ini and yum)
  3. Register the new Azure VM in OA as new node
  4. Foreach APS package create a test subscription (Main APS must be tested: F-Secure, Backup Online) Work with "ready to provide" and "not ready to provide" to activate or deactivate new node for testing
  5. Optional: Search an existing test-subscription, update the APS endpoint in the OA database and try to create and delete a service user, increase resource limits To update the APS endpoint in OA database, use: update aps_external_application_instances set host_id=<new host id> where app_instance_id in (select app_instance_id from saas_application_instances sai join aps_applications ap on sai.app_id=ap.app_id where sai.sub_id=<test subscription id> and ap.name=<Application name>);
  6. Disable pa-agent on source node and mark it as "not ready to provide" in OA
  7. Copy the folder /usr/local/pem/APS to the target node, if not synced already
  8. Switch all subscription to the new host_id, use: update aps_external_application_instances set host_id=<new host id> where host_id=<old host id>;
  9. Un-register source node in OA

2.4. Branding and UI nodes

2.4.1 Prerequisites

  1. Write down current DNS entries pointing to the public IP address, be sure to check external domains
  2. Write down new public IP addresses of Azure

2.4.2 Migration

NB: Brands migration article

  1. Register new UI node(s) in OA
  2. Goto OA and switch the brand to the newly registered node
  3. Change all DNS entries to the new public IP address

2.5. Nameserver nodes

The migration is based on the procedure provided by RnD: KB132931 Basically it removes a node and re-registers a new node. During this procedure the backend IP of the nameserver will change autoamtically to the new node.

2.5.1 Prerequisites

  1. Acquire access to OpenSRS
  2. Write down all DNS entries based on the current public IPs of the nameserver. (applicable tables in OA are: dns_resource_records and dns_services)
  3. Lookup if any external domain is in use which must be updated too

2.5.2 Migration

  1. For each Nameserver perform the steps described in KB132931
  2. Be sure to sync all domains accordingly
  3. Update the IP address of the currently moved nameserver
  4. Update glue records at OpenSRS (first nameserver must be removed, then new glue record can be added)

2.6. BSS Online store nodes

The migration is based on the procedure which was used to upgrade from CentOS 6 to CentOS 7: KB130128

2.6.1 Prerequisites

  1. Be sure that password-less SSH connection between source and target node is possible (required to copy data)
  2. New Azure RED zone is available via VPN and on Azure
  3. Be sure that the network interface names are identical on source and target node. If this cannot be done, you need to update the NIC names before you start the migration
  4. Write Down all DNS entries which point to the current public IP Address(es)
  5. Write Down new public IP address of the store
  6. Export all Online Stores to create a backup

2.6.2 Migration

  1. Initiate the precheck: python ba_backup_restore.py --store=10.94.117.203 --check
  2. Initiate Backup: python ba_backup_restore.py --store=10.94.117.203 --backup
  3. Transfer directory /var/backup to target node
  4. Change Backend IP Address in OA database (Guide: Renumber Backnet and Frontnet in OA Database): Tables:
    • aps_property_value
    • aps_application
    • aps_packages
    • aps_application_instances
    • configured_ips
    • property_values
    • confman_parameters

  5. Change Backup IP in BA Database Tables: StoreSyncConf

  6. Re-register the BA Online Store node

  7. On the management node initiate the restore: python ba_backup_restore.py --store=10.94.117.203 --restore
  8. Update all DNS entries with the new public Azure IP address
  9. Test function of BA Store

2.7. OSS MN + OSS DB nodes

2.7.1 Prerequisites

  1. Be sure that password-less SSH connection between source and target node is possible (required to copy data)
  2. Use temporary IP Address (Migration Network) outside of current network. This is required as the network subnets cannot overlap between Azure and on-prem. In order for the migration script to copy the data to the target node a dummy network is used
  3. Be sure that the network interface names are identical on source and target node. If this cannot be done, you need to update the NIC names before you start the migration.
  4. OSS version must OA7.4

2.7.2 Migration

Follow the guide in KB132973 carefully. Ignore Hotfix check ... they should be installed already

  1. Initiate the precheck: ./mn_backup.sh -o /BACKUP -t mn-backup-precheck (deprecated: ./mn_backup.sh --dst-mn-ip 10.10.1.21 --dst-db-ip 10.94.1.21 -o /BACKUP -r /RESTORE -t mn-migration-precheck --inplace-db-migr)

  2. Initiate backup: This will stop on-prem services !! ./mn_backup.sh -o /BACKUP -t mn-backup (deprecated: ./mn_backup.sh --dst-mn-ip 10.10.1.21 --dst-db-ip 10.94.1.21 -o /BACKUP -r /RESTORE -t mn-migration --inplace-db-migr)

  3. Transfer backup directory to target node

  4. On Azure:

    • Shut down target node
    • Remove dummy network interface
    • Add the address space and subnet of the target network
    • Add correct target network interface → be sure that it shows up at first place, if not remove the blue network and re-add it after orange (target) network was added.
    • Remove the routing for that Network via the VPN
    • Start target node

  5. On Prem DC: be be sure that network on prem network is now reached via VPN at Azure. Update all routes if required.

  6. On the target Azure node initiate the restore:

    • Set same hostname as source node had
    • As IP Address the real target IP address is used, instead of the dummy migration network. ./install.py --migrate --communication_ip=10.94.61.39
  7. Test function of OA, i.e. log in via branding node, move around in UI, switch to BA

2.8. BSS MN node

The migration is based on the procedure that was used to upgrade from CentOS 6 to CentOS 7: KB130127

Please cross check with latest procedure updates in BAA APP migration article

2.8.1 Prerequisites

  1. Payment Processors: for dummy or universal payment methods reconfiguration is NOT required
  2. Domain Gateway - OpenSRS: Be sure that the new public IP Address is allowed to connect to OpenSRS
  3. Optional: Be sure that new public IP is allowed to connect to SSL Store if it is in use.
  4. Be sure that password-less SSH connection between source and target node is possible (required to copy data)
  5. Use temporary IP Address (Migration Network) outside of current network. This is required as the network subnets cannot overlap between Azure and on-prem DC. In order for the migration script to copy the data to the target node a dummy network is used.
  6. Be sure that the network interface names are identical on source and target node. If this cannot be done, you need to update the NIC names before you start the migration.
  7. Backup: Screen Customizations
  8. Backup: locale customization
  9. Be sure that target and source node have the same timezone configured

2.8.2 Migration

Follow the guide at KB130127 carefully.

  1. Initiate the precheck: python ba_backup_restore.py --app=10.10.1.204 --check 10.10.1.204 is the IP of the TARGET node

  2. Initiate backup: This will stop on-prem services !! python ba_backup_restore.py --app=10.10.1.204 --backup

  3. Transfer folder /var/backup to the target node

  4. On Azure (after all nodes of the same network have been migrated):

    • Shut down target node
    • Remove dummy network interface
    • Add the address space and subnet of the target network
    • Add correct target network interface → be sure that it shows up at first place, if not remove the blue network and re-add it after orange (target) network was added.
    • Remove the routing for that Network via the VPN
    • Start target node

  5. On Prem DC: be be sure that network on prem network is now reached via VPN at Azure. Update all routes if required.

  6. Re-Register BA Application node in OA; Verify and change if required the bm_bridge IP in the OA database: oss=> begin; oss=> update bmbridge_settings set value = replace(value, '<source IP>', '<Azure IP>'); oss=> commit; (or rollback;)

  7. On the target node initiate the restore(As IP Address the real target IP address is used, instead of the dummy migration network): python ba_backup_restore.py --app=10.94.45.204 --restore

  8. Manually copy screen and locale customizations (restart BA afterwards)

  9. Replace/Verify IP Addresses in

    • /usr/local/bm/conf/ip_access.db
    • /usr/local/bm/etc/ssm.conf.d/xrproxy_auth.conf
    • /usr/local/bm/etc/ssm.conf.d/xmlrpcd_auth.conf

  10. Copy auto payment processing: /sbin/autoprocesspayments.sh

  11. Test function of BA, i.e. log in via branding node, move around in UI

  12. Verify connections to OpenSRS

2.9. BSS DB node

The migration is based on the procedure that was used to upgrade from CentOS 6 to CentOS 7: KB130126

Please cross check with the latest procedure update in the article:BA+DB+migration

2.9.1 Prerequisites

  1. Be sure that password-less SSH connection between source and target node is possible (required to copy data)
  2. Use temporary IP Address (Migration Network) outside of current network. This is required as the network subnets cannot overlap between Azure and on-prem. In order for the migration script to copy the data to the target node a dummy network is used.
  3. Be sure that the network interface names are identical on source and target node. If this cannot be done, you need to update the NIC names before you start the migration.

2.9.2 Migration

Follow the guide at KB130126 carefully.

  1. Initiate the precheck: python ba_backup_restore.py --db=10.10.1.205 --check

  2. Initiate backup: python ba_backup_restore.py --db=10.10.1.205 --backup

  3. On Azure (after all nodes of the same network have been migrated):

    • Shut down target node
    • Remove dummy network interface
    • Add the address space and subnet of the target network
    • Add correct target network interface → be sure that it shows up at first place, if not remove the blue network and re-add it after orange (target) network was added.
    • Remove the routing for that Network via the VPN
    • Start target node

  4. On Prem DC: be be sure that network on prem network is now reached via VPN at Azure. Update all routes if required.

  5. Re-register node in OA oss=> begin; oss=> update bmbridge_settings set value = replace(value, '<source IP>', '<Azure IP>'); oss=> commit; (or rollback;)

  6. On the target node initiate the restore: As IP Address the real target IP address is used, instead of the dummy migration network. python ba_backup_restore.py --db=10.94.45.205 --restore

  7. Test function of BA, i.e. log in via branding node, move around in UI

OUTCOME

  • Migrated OA instance available for provider and customers via same control panel access URLs
  • Moved OA instance has exact the same configuration and keeps all Operational and Billing history
  • Public available OA IP addresses are re-configured and accessible as Azure Cloud public IPs
  • OA private IP addresses can be changed in order to do security re-zoning (red/orange/green zones)

Internal content

Link on internal Article