Advance with Assist shares quick solutions to common challenges encountered by the InterWorks Assist on-demand team.
Question: I need to migrate Tableau Server; what are my options? Should I be using something like Azure Site Recovery or AWS AMIs to move my cluster?
The Challenges
There are a few challenges to using any sort of snapshot-based technology to migrate a Tableau Server deployment, especially a multi-node deployment. This goes for Azure Site Recovery, deploying instances from Amazon Web Services AMIs, or even a Veeam Instant Recovery on-premises.
Single-Node Deployments
- To ensure it hasn’t been cloned onto new hardware, Tableau’s licensing service looks at several identifiers, such as the network adaptor MAC address and the VM (or instance) unique identifier. Since these snapshot-based tools generate new VMs, these IDs change, and it invalidates the Tableau license activation.
- Server hostname. If the server’s hostname changes, Tableau Server will cease to function.
Multi-Node Deployments
- All the challenges from Single-Node, plus:
- IP addresses. In a clustered environment, if the IP addresses of the servers change, the nodes will not be able to communicate with the TSM controller.
- Snapshot time differences. Depending on how far apart in time the snapshots were taken across the nodes, the migrated Tableau Server may not be able to get all the processes in sync again.
The Potential Workarounds
There are workarounds for some of these, with varying amounts of pain:
- Deactivate all Tableau Server licenses before taking the snapshot that will be used to migrate the environment. Tableau services need to be stopped during this to prevent users’ roles from being changed to Unlicensed.
- If IP addresses will be changing, the worker nodes could be removed before the migration and re-added to the cluster after.
- If some services fail to synchronize after the migration, a Tableau Server backup could be restored onto the migrated environment.
- There is no workaround for hostname changes – a rebuild is required.
A Better Solution
In most cases, the best course of action is to build a new Tableau Server environment up in parallel (taking advantage of one of the two non-production environments the Tableau licenses allow) and restore in a backup. Let’s look at that process:
- Provision new server VMs/instances. Since you’re building fresh instances anyway, now might be a good time to evaluate if switching from Windows to Linux makes sense. Or maybe it’s time to make the leap to that new release of Tableau Server you’ve been putting off.
- Install Tableau Server on the new environment, matching the process topology between old and new.
- Migrate content and settings. Here’s Tableau’s documentation about that process.
- If the environments will run in parallel for a while, disable schedules on the new environment to prevent duplicate subscriptions and extract refreshes.
- Test out the new environment.
- When it’s time to switch over:
- Restore in a fresh backup if the new environment needs to catch up with changes made to the old one during testing.
- Re-enable schedules.
- Point DNS or the load balancer at the new environment.
While this does require some work, all of it except the very last step can be done without downtime or impact to the production environment, unlike each of the workarounds mentioned before.
InterWorks Is Here to Help
The Assist team is always here to help. To learn more about Assist by InterWorks, check out this blog post to see how Assist can help you with your data and tech challenges. Looking for more support around licensing? Don’t hesitate to let our team know if you need help planning your next migration!
