High-Availability Best Practices
This guide includes the high-availability best practices for Server admins.
Alteryx Server provides a fully scalable architecture that allows an organization to automate data analytics, tackle bigger projects, process larger datasets, and put self-service data analytics into the hands of multiple decision makers. From scaling Worker nodes to Server nodes to the MongoDB persistence layer, Alteryx Server allows organizations to efficiently manage their automated and self-service data analytics needs.
Organizations can scale their Workers in case the number of jobs needing to be executed increases and scale the Server in case the number of self-service Server users increases. To ensure the availability of your Alteryx Server environment and to protect your workflows and data from disaster, organizations can deploy a user-managed instance of the MongoDB and enable advanced features such as Replica Sets and Sharding.
The focus of this document is to answer the following questions:
- How to scale the Controller within an Alteryx Server environment?
- How to setup a redundant Controller within an Alteryx Server Environment?
Before we get started, it is important to note that only a single Controller can be active at a given time, meaning it requires an active-passive setup. Organizations can automate the failover of a Controller by using Failover Clustering which is built-in to Microsoft Windows Server. Failover Clustering is responsible for monitoring the AlteryxService and the availability of the server on the network. If the AlteryxService fails or the server goes down, Failover Clustering automates the failover of the Controller functionality to a secondary server.
You find here information how to setup an Alteryx Server environment with redundant Controllers and how to automate the failover of the Controller in the event of an outage. These instructions are intended for scaled-out Alteryx Server environments. When enabling an Alteryx Server environment for automated failover of the Controller, it requires configuration changes to all Server UI and Worker nodes. The configuration changes are also described in detail in the following steps.
With the encryption that DCM uses, credentials that are encrypted with one node might no longer function when failing over to a second node in this configuration. We currently recommend you to use alternative forms of credential storage with a High Availability Controller. Please contact firstname.lastname@example.org if you have additional questions and reference TGAL-7256.