This topic describes how an internet company seamlessly migrated its application from another cloud provider to OSS using Data Online Migration and the mirroring-based back-to-origin feature.
Background
A customer, an internet service company, runs its primary business on another cloud provider. The business provides online services for editing images and videos. The customer has about 100 million existing files, totaling approximately 320 TB, stored with the provider. About 20 GB of new data is generated daily. OSS provides an access bandwidth of 250 MB/s, while the business requires a maximum bandwidth of 50 MB/s.
To support business growth, the company plans to migrate its application to the OSS platform. Due to the large volume of existing data, the migration must ensure business continuity and meet the following requirements:
-
The migration must not interrupt business operations or affect user access to data.
-
The migration must guarantee data integrity and allow the application to cut over to OSS seamlessly.
Migration plan
Based on the customer's requirements, the recommended migration plan is as follows:
-
Use Data Online Migration to migrate the customer's existing data from the source cloud service to OSS. Business operations remain on the original platform until this initial migration is complete.
-
After the existing data is migrated, configure mirroring-based back-to-origin in OSS to point to the source cloud service. This allows OSS to serve requests for incremental data that has not yet been migrated.
-
Cut over the application to OSS. At this point, all data is read from and written to OSS.
-
After the cutover, new data is no longer generated on the source cloud service. Use Data Online Migration again to migrate the remaining incremental data to OSS.
-
After all data is migrated and verified, delete the data from the source.
Step 1: Migrate existing data
-
Create a migration job to migrate the existing data.
a. Create an OSS bucket to store the migrated data. For more information, see Create a bucket.
b. Create a data address and then create a full migration job. For more information, see the migration implementation document for the corresponding tutorial in Migration tutorials.
ImportantFor the migration job, set the overwrite policy to Overwrite objects with the same name if the last modified time is later than that of the destination object. This ensures that when you restart the job, only incremental data is migrated.
-
After the migration is complete, view the migration report to compare the data at the source and destination and confirm that all data has been successfully migrated.
Step 2: Configure mirroring-based back-to-origin
Migrating the existing data takes about 25 days. During the data migration process, the origin site continuously generates new data. To avoid business interruptions and achieve a seamless business switchover, you also need to configure the mirroring-based back-to-origin feature. When a file requested by a user is not found in OSS, OSS automatically fetches the corresponding file from the origin site, saves it to OSS, and returns the content directly to the user.
-
Log on to the OSS console.
-
In the left-side navigation pane, click Buckets.
-
On the Buckets page, click the name of the bucket that you want to configure.
-
In the left-side navigation pane, choose Data Management > Mirroring-based Back-to-origin.
-
Click Create Rule. In the Create Rule panel that appears, configure the back-to-origin information.
Enter the source origin URL in the format
http://[BucketName].bcebos.com/data/in the Origin URL field. For example, if the OSS access URL isbucketname.oss-endpoint.com/image.jpg, OSS fetches the object fromhttp://abcbj.bcebos.com/data/image.jpg.-
Method: Select Mirroring.
-
Condition: The default condition is the HTTP 404 status code. You can also configure an Object Name Prefix and an File Name Suffix based on your requirements.
-
Origin URL: Enter the access URL of the source cloud service.
-
For more information about parameter settings, see Configure back-to-origin rules.
NoteYou can configure up to five mirroring-based back-to-origin rules, and all rules take effect simultaneously. If you have multiple sources, you can configure multiple rules and use a different Object Name Prefix for each to route requests to the correct source.
-
-
Click OK.
Step 3: Cut over to OSS
Update your application servers to point to OSS for all read and write operations. After this change, incremental data is no longer generated at the source.
Step 4: Migrate incremental data
During the migration of existing data, about 100,000 new files totaling around 500 GB were generated at the source. This incremental data must also be migrated to OSS.
-
Restart the migration job. The service performs a full scan of the source files and migrates only the incremental files to the destination based on their last modified time.
-
After the migration is complete, view the migration report to compare the data at the source and destination and confirm that all data has been successfully migrated.