topic Re: Mirroring Prod Environment in QA and DR in Alteryx Server Discussions

Mirroring Prod Environment in QA and DR

raychase — Fri, 07 Dec 2018 01:43:18 GMT

Hello,

My company has been using a Production environment of Alteryx Server for about a year. I've been asked to set up proper QA and DR environments. I have three VMs, all with the same version of Alteryx Server installed. I have also created a .bat file that runs a nightly backup of the MongoDB (from Prod) and places copies on the QA and DR boxes. My primary concern is the QA environment, as I want to have all Data Connections, Workflows, Studios, Users, etc. from the Prod environment available for testing purposes. Is it as simple as restoring the MongoDB backup in the QA environment? It should be noted that I do not want the scheduled jobs to run on QA, as there would be potential overwrite of outputs. When I tried this restoration process, I could see all of my users/studios/workflows; however, my data connections were absent, and I wasn't even able to add new ones (it was a blank page). When I clicked on jobs, I was prompted with an error about the workers not being found. Please advise what the best practice is for replicating Prod on QA, but disabling all of the scheduled workflows.

The goal for the DR environment is to have an identical version of Alteryx Server installed; however, the services would not be running. This environment would only be used in the case of a disaster, and should be able to handle the exact duties of the Prod environment. As such, I WOULD want the scheduled jobs to run. Please advise how to best coordinate these environments.

Re: Mirroring Prod Environment in QA and DR

patrick_mcauliffe — Fri, 07 Dec 2018 12:57:37 GMT

@raychase

Assuming all three are in the same domain....

To disable all schedules, I would turn that option off in the system settings of your QA and DR.

Options-->Advanced Options--> System Settings --> "Next" to Worker Configuration and uncheck "Allow machine to run scheduled Alteryx workflows".

To make sure the connections are replicated across all, backup the connection files:

User Type Connections:

C:\Users\[username]\AppData\Roaming\Alteryx\Engine

UserAlias.xml

UserConnections.xml (In-DB)

System Type Connections:

C:\ProgramData\Alteryx\Engine

SystemAlias.XML

SystemConnections.xml (In-DB)

And any DSN set up through ODBC manager can be moved from the registry:

For User DSN data sources:

HKEY_CURRENT_USER > Software > ODBC

For System DSN data sources:

HKEY_LOCAL_MACHINE > Software > ODBC

Re: Mirroring Prod Environment in QA and DR

raychase — Fri, 07 Dec 2018 16:47:52 GMT

Thanks for the response, Patrick.

When data connections are added on the Gallery itself, where would these connections be stored? My impression is that these are "System Type" connections; however, I cannot locate the SystemAlias or SystemConnections files.

What differentiates a System Type from a User Type connection? We try to manage all of our connections via the Gallery (we have a couple of dedicated admins that handle these).

Great job including the DSN bit, I had no idea that I could back those up as well.

If I could sort out the Data Connections from the gal

Re: Mirroring Prod Environment in QA and DR

raychase — Fri, 07 Dec 2018 16:48:34 GMT

Cut myself off there...

If I could sort out the Data Connections from the Gallery, I'll be all set.

Thanks again!

Re: Mirroring Prod Environment in QA and DR

patrick_mcauliffe — Tue, 18 Dec 2018 14:43:58 GMT

Hey @raychase, sorry for the late reply.

The difference between System and User connections is the need for availability across multiple users sharing the same machine.

Aliases set up as system will be available to other users logged into the same machine which also have an Alteryx license.

Connections set up as User type are only available to the user that set them up.

Connections set up through the Gallery are stored in the MongoDB. Use the database "AlteryxGallery" and the collection "dataConnections".

If you're running the QA or Dev environment from a backup of the MongoDB, then those should be connected.

Are they not?