Wasabi Object Replication With CTERA

CTERA is a global file system management platform that has been validated for use with Wasabi. For details on how Wasabi works with CTERA, refer to CTERA.

This article describes the procedure to use Wasabi Object Replication to replicate objects from one region to another within the same continent. This can be used to recover from natural disasters or other events in a region.

Requirements

CTERA installed and licensed. This solution was tested with version 8.3.3000.26.
Active Wasabi Cloud Storage account.
Access to the Wasabi Console as your account’s root user or with equivalent IAM permissions.
Active CTERA storage node pointing to a Wasabi bucket.
Existing files reside in a Wasabi source bucket.
Access to your CTERA portal as an admin.
Additionally, in case of a disaster:
- Access to your CTERA server via SSH or via its hypervisor console as the root user.
- Ability to take a VM snapshot of your CTERA database server.

High-Level Steps

Follow the high-level steps below to implement Object Replication from a source bucket to a destination bucket in another region with CTERA. These are detailed further in the sections below.>

Sign up for notifications to be sent to your account email address.
Create a Wasabi "destination" bucket where the source bucket will be replicated to.
Configure an object replication job on the source bucket pointing to the destination bucket.
In the case of a disaster:
- Contact CTERA Support.
- Take a full snapshot of the VM running the CTERA database.
- Rename the source bucket.
- Change the destination bucket’s name to be the original source bucket’s name.
- Reconfigure the CTERA storage node’s Wasabi URL to point to the destination bucket’s region.

Sign Up for Object Replication Notifications

Signing up for notifications will allow you to receive information about any object replication failures as well as when the initial replication has finished.

Log in to the Wasabi Console.
Navigate to Settings, then click Notifications. Next to Object Replication, enable email notifications. Enter your Multi-Factor Authentication (MFA) code, and click Save Changes.

Creating the Wasabi Destination Bucket

The destination bucket is the bucket that the source bucket will replicate to.

Navigate to Buckets and search for the source bucket. Note the name and region of the source bucket. In this example, we are using an “mt-ctera-bucket-1” source bucket in Wasabi's us-east-1 region.
Choose the region within the same continent for the destination bucket.
This configuration example discusses the use of Wasabi's us-east-1 storage region for the source and us-west-2 for the destination. For a list of regions, see Available Storage Regions.
Navigate to Buckets, then click Create Bucket.
Enter the destination bucket name, select the region for the bucket, and click Create Bucket. In this example, we are naming the destination bucket “mt-ctera-bucket-2”.

Creating an Object Replication Job

Navigate to Buckets and click the name of the SOURCE bucket.
Click the Settings gear wheel on the right side of the screen.
Click the Object Replication tab, then click Create Replication Job.
Select the Replication Type. For this example, we are selecting Replicate to a bucket within this account. Give the job a name, and click in the Destination Bucket text field to select the destination bucket. Click the checkbox next to Sync Deleted Objects. This allows CTERA to control the lifecycle of the source bucket, and older files that CTERA deletes from the source bucket will also be deleted from the destination bucket. Then click Create.
The objects in the source bucket will now begin to replicate to the destination. There is no ETA for completion as this depends on many factors, such as the number of objects, and so on. Since you signed up for Object Replication email notifications, you will receive an email when the initial replication is complete.

Appendix A - In case of a Disaster

In the case of a disaster that affects your source bucket, proceed with this section.

Contact CTERA Support to advise them you are about to failover to a different Wasabi bucket using the following procedure.
Log in to your CTERA server via SSH or via its hypervisor console as the root user and issue the following command to stop the CTERA service.
```
portal-manage.sh stop
```
Take a full snapshot of the VM running the CTERA database.
Start the CTERA service.
```
portal-manage.sh start
```
Log in to the Wasabi Console.
Pause the object replication job on your SOURCE bucket. Click Buckets, then select the name of your source bucket.
Click the Settings gear wheel on the right side of the screen.
Click the Object Replication tab, then click the Action button (3 vertical dots) next to your replication job.
Click Pause.
Click Pause on the popup window.
The status will now show the job is paused.
Click Buckets. Click on the Actions button (3 vertical dots) next to the SOURCE bucket.
Click Rename.
Give the bucket a new name and click Rename Bucket. This must be a name that is unique within Wasabi.
Click on the Actions button (3 vertical dots) next to the DESTINATION bucket.
Click Rename.
Give the bucket the name of the ORIGINAL SOURCE bucket. Click Rename Bucket.
You will see two buckets in your bucket list: one which is the source bucket with a new name, and the one that is the destination bucket with the original source bucket’s name. Note the region of the destination bucket (us-west-2 in our example).
Log in to your CTERA console as an admin.
Under Main click Storage Nodes. Click the name of your Wasabi source bucket storage node. Note that it is disconnected.
Update the Endpoint to point to the destination bucket’s region (us-west-2 in our example). See Service URLs for Wasabi's Storage Regions for a list of Wasabi endpoint URLs. Everything else stays the same. Click Save.
You will now see the Wasabi storage node as being connected.
Verify CTERA can see the files in the destination bucket.