Azure NetApp Files (ANF) is the perfect fit for your enterprise, tier-one workloads in Azure. But as these workloads are mostly already running either on-premises or elsewhere in the cloud and are seldomly built from scratch, you need to find a solution to get them into Azure in the first place.
This is where NetApp Cloud Sync comes into play. Cloud Sync is a free tool for every ANF customer and can be used to migrate your data from an existing SMB share or NFS export into ANF. The source does not need to be located on-premises it can also be an existing file server already running somewhere in the cloud. Besides migrating data from an existing SMB or NFS source, it can also be used to move data from or to Azure Blob. We also had customers migrating their data from AWS S3 into ANF with Cloud Sync.
How does Cloud Sync work?
Getting started with Cloud Sync couldn’t be simpler. Head over to http://cloudsync.netapp.com, create an account, and deploy your data broker. The data broker is deployed either in your Azure VNET or on-premises close to your source data and handles the data transfer. As soon as you create a so-called “Sync Relationship” with ANF being either source of or target for your data, Cloud Sync will not charge for the data transfer.
You can either create your Sync Relationship to be recurring copy processes, which will keep your source and target in sync (as the name already implies), or you can set it to be a one-time copy operation. Ideally, this would be a set and forget solution, where you would set it up and would not need to constantly monitor the progress. For this to work you would need to be notified once there is a failure during synchronization, which is a feature that isn’t yet natively integrated into Cloud Sync. However, you can use the REST API to check for succeeded or failed syncs.
This is where the Cloud Sync Monitor comes in. This small Azure Logic App (https://github.com/fischerphilipp/CloudSyncMonitor), that you can deploy into your environment with the click of a button, sends mail notifications if a sync fails. These notifications would look like this:
Set up Cloud Sync Monitor
You only need three things to get Cloud Sync Monitor running:
- A Microsoft (Office) 365 account that will be used to send the notification mails from.
- The NetApp Cloud Central Refresh Token, which is used to grant access to Cloud Sync API services.
- Go to https://services.cloud.netapp.com/refresh-token and log in with the same username and password that you will also use to access Cloud Sync.
- Copy or save the refresh token somewhere, you will need it for deploying Cloud Sync Monitor.
- The following “Deploy to Azure” Button. This opens the Azure custom deployment screen that asks for some configuration details.
The custom deployment screen asks for the following configuration details
These settings are designed to be mostly self-explanatory. Nevertheless, I would like to highlight two of them:
- Office 365 Connection Name
- This is the Azure resource name for the Office 365 Connection that is being used for sending the notification mails. The connection has to be configured separately after deployment (see below).
- Only Report Errors
- The default setting is “true”, which means that you will only receive mails if there is a failed sync. If you set it to “false” you will receive mails for every sync no matter if was successful or if it failed. This can be used to test the Logic App and afterwards be changed to “true” again.
The only thing you need to do after deployment is to configure the Office 365 API connection to use your Office 365 account to send the mails. The connection resource is located within the same resource group that you specified during deployment.
That’s it, your Cloud Sync Monitoring is set up and sending mails.
If you need to, you can also change some of the parameters after the initial deployment without needing to re-deploy the Logic App.
A more detailed explanation of the parameters etc. can be found over at GitHub: https://github.com/fischerphilipp/CloudSyncMonitor