So, we were installing Alteryx Server and I got a wee bit distracted and wanted to figure out which components start in what order and what files they used.

I’ve satisfied that urge, so let’s continue with more configuration screens.

Disk, Disk, Disk

There are multiple properties that let you define where you should “store stuff”. For example (and at the highest level), where the Server’s “Global Workspace” goes:

…and then one for the Controller’s Workspace:

…and yet another for the location where the MongoDB repository should stash its stuff:

…and you guessed it, one more for the Worker component:

Don’t forget the Gallery and Logfiles!

Notice the pattern? Lots of files being written (and read), and they’re all getting dropped into C: by default. At scale, this could be tons of disk activity and we’re not even thinking about the fact the OS will be hitting the same volume too.

I haven’t done any load testing, but this screams “Disk Latency!” to me, especially when I load all services (Controller, Worker, Mongo, Gallery) on one box. I’m just playing around right now, so “I don’t care“. But at a minimum I’d watch disk latency closely in production and more likely just go ahead and add a D: drive and put some or all of these stores there.

Mongo

Sorry, can’t pass up a cheap joke.

You likely noticed the option to use an “embedded” MongoDB (the default) or to point to one of your own instances. Mongo is what we use as our repository to save your workflow definitions, usernames & passwords, etc. All that good stuff lands in Mongo.

If you want to use your own instance of MongoDB, there’s an excellent Community article that can jump-start your efforts on Windows. Windows makes me sad today AND I’m lazy, so I went with a pre-rolled Linux image that has Mongo ready to eat.

This image is made by Bitnami, and it’s cheaper to run on the same hardware than it’s Windows equivalent. That’s also nice. I was pleasantly surprised by the level of support out there, too. Lots of “how to” articles on how to configure it.

So, I’ve added another machine to the menagerie. Not uncommon for me:

Mongo uses the same security group as the other boxes in the private subnet, so there is no way for someone in the outside world to connect directly to it. Here’s the config screen for my second Alteryx Server environment where I tried out User-managed Mongo:

One more thing when it comes to Mongo: You DO know about RoboMongo (now Robo 3T), right? It’s an awesome client that I use on the Mac and Windows to avoid having to learn a bunch of MongoDB Kung Fu. Here I am, all connected up to the “local”, embedded MongoDB AlteryxGallery database, and I’m checking User credentials out:

Or, here’s me connecting to my “User Managed” instance of Mongo in Linux, and I can read logs and see my Alteryx Server connecting up from a remote machine:

Anyway, this is light-years easier than using the CLI, but then you don’t get as much geek cred. Whatever.

Fix Up Your Address

Remember that you may end up shooting out email from Server or providing links to your Workflows. To make sure they resolve correctly, you should probably fix this sucker up and not just leave it as http://localhost/gallery. Here is the not-so-friendly machine name of one of my just-about-to-be-destroyed test boxes:

You may recall I use an Application Load Balancer to get traffic to this “private” machine. Here’s how that works:

I’ve created a “target group” for Alteryx Server, Connect, and Promote. Each group can have as many machines in it as I want.

Then, you create a “listener” – I have one sitting on port 80, facing the outside world. Note that the default rule forwards traffic to my alteryx-server group, above.

…but that’s not all!

…You can also add rules to a listener. So depending on whether a user is trying to get to promote.mydomain.com, connect.mydomain.com, or gallery.mydomain.com, I forward ’em to different target group where an EC2 instance is waiting to service the request:

I made a mistake here! Can you tell what it is? Still works, though.

Let’s Add Workers!

So simple. Just stand up another box and run setup again.

Then, go to your Controller and grab the Controller Token out of General Configuration:

In the System Settings tool for your new machine, tell it to act as a Worker (or whatever else you want it to do):

…Then plug in the machine name of your Controller, and provide the Token:

Easy. Even my manager could do it.

Don’t forget to give your new Worker a really orginal name, like worker1:

Based on the settings above, this new worker will ONLY run Workflows assigned to it by someone. If I login to Gallery, here’s how it looks:

So, it’s 5p in the afternoon. I’m done. Going to proof-read this (very) quickly and then drink beer. Next up: Connect!

Leave a Reply

Old as dirt posts

Contact me.