We’ll start by installing Alteryx Server on a single node to see how it goes. Spoiler ahead: It went well. I had more trouble with the Windows box than I did with Alteryx itself!

The Windows Box

Since I’m on AWS, I have many, many choices in terms of the hardware to run. This is a good thing, because I can experiment with different combinations of RAM, CPU, and disk until I hit the combination that’s just right

I chose a t2.2xlarge which gives be 4 vCPU (or 2 “real world” cores) and 16 GB. Clearly I’m under the recommended minimum specs, but I just want a cheap box for now. The T series are good for playing around on because they’re cheap and offer Burstable Performance.

What this means is you get a bucket of (constantly recharging) credits that you “spend” on CPU. If you have a server that is constantly driving CPU, T’s are no good.

However, if your server just mostly “sits there” but has periods of high activity, T’s are awesome. In the image below, you can see how my box was pegged at 100% CPU while I was running a little experiment, and during that time I used up ~ 40 credits per minute. After CPU utlization dropped, so did my credit spend, and I started slowly “building them up” again.

If I were to choose a machine that would handle real production load, I’d probably go with an M or R series 2x or 4xlarge. These instances would give me between 8 and 16 vCPU (4 – 8 cores) with 32 – 128 GB of RAM

While I haven’t had time to prove this out (and don’t worry, I will) I suspect that using mechanical, spinning disks would be bad for overall system performance.

I want fast disks in case I push RAM utilization and start paging to disk. I bet those temporary *.yxdb files that we create during workflow execution will soak up a lot of disk bandwidth too. I went with EBS General Purpose SSDs, which are fast and relatively cost-effective.

Machine Configuration

A freshly provisioned ec2 instance will not be domain-joined automatically. You have two ways to go about this.

You can…

Choose your domain in Domain Join Directory and provide an IAM role which grants permissions to your machine to do this work on it’s own…

Or, you can join the domain yourself manually AFTER you’ve gotten the machine up and running.

Personally, I tend to go the latter route because I want to give my machine a “plain English” name before I domain join it so I don’t have to do anything in Directory Services afterwards.

So, I normally follow this process:

  • Launch Windows Server Manager and choose Local Server
  • Click my Computer Name and Change it to something else.
  • Click the More button and change the Primary DNS suffix to my domain (For example, if my domain is “foo.com”, I put that value here.) Reboot.
  • Open my Network and Internet Settings and Change Adapter Options.
  • Right-click my Adapter, Choose Properties and find/select Internet Protocol Version 4. Click the Properties button.
  • Stick in the DNS Server IP address for my Directory Service:
The IP address above came from the “DNS Address” list in AWS Directory Services Details, below:

The step above is really important otherwise your machine won’t be able to find the Domain Controller in order to join the domain.

  • After that, launch Server Manager again and click Local Server.
  • Click either the Workgroup or Computer Name, and then click Change.
  • Add “foo.com” to the Domain box and provide the administrator username / password you chose when you created your Directory Service catalog

Bam! reboot again and you’re domain joined.

Other Stuff to Load

At a minimum, you’ll need to add Domain Users. Potentially you’ll want to add computers and maybe change some of the DNS entries for your domain, too.

To that end, use Server Manager‘s Add Roles and Features menu item.

Add the following Remote Server Administration Tools:

  • AD DS and AD LDS Tools
  • DNS Server Tools

While you’re in this list, you might as well install the telnet client, too. It’s handy for connectivity troubleshooting.

Installing the hell out of Alteryx Server

Finally. We can actually install Alteryx Server now!

When setting up a new piece of software, my goal is to (generally) get the thing up and running without spending too much time in Help. I found that Alteryx Server cooperated with me in that regard.

I actually built two different servers (both with multiple nodes). I wanted to experiment with User-managed MongoDB. As a result, you’ll see configuration screens from multiple machines.

Running Setup is easy – just execute the installer. It doesn’t prompt you for much of anything till the end:

You’ll need to configure your server, and there is a bunch of stuff here. I realized I’d be crazy to try and cover everything in one post, so we’ll only get a screen or two in, then call it a day. I’ll continue in a different entry.

Luckily, if you just want a box you can play on, using the default suggestions will be just fine. I won’t hit every screen of the configuration dialog, just items I think are interesting.

And you may wonder to yourself, “Self, where are all these settings stored? How does the Server itself launch after a reboot?”

Well, Self: Settings are stored in RuntimeSettings.xml. There are actually two copies of this file. The one you’ll find in \Program Files\Alteryx\bin\RuntimeData contains all of the default settings for a server:

There’s another version of this file in \ProgramData\Alteryx. It only lists user-specific exceptions to defaults that YOU dialed in. Think of it as an override file:

When Windows starts, a Windows Service called AlteryxService.exe actually launches the “real” server, which is called AlteryxCloudCmd.exe. AlteryxService.exe actually passes in all the parameters necessary to get us moving.

Below, I’m using ProcessMon to spy on what’s happening on my system, and you can see AlteryxService.exe spawning 4 processes:

  • A service which Controls / Launches MongoDB
  • Two copies of the service which renders maps
  • One copy of AlteryxCloudCmd

I can also see AlteryxService.exe reading both of those RuntimeSettings.xml files like crazy:

Here’s Alteryx’s Mongo Controller actually spawing mongod.exe, the MongoDB daemon:

OK. Got a little off track. Like to understand how things work. Sorry. Back to configuration dialogs:

To start off with, I wanted a single machine that could do everything. It will:

  • Manage system settings and delegate tasks to “Workers”
  • Act as a worker itself, executing workflows with the Alteryx Engine
  • Provision a Web App (The Gallery) that folks can log in to, save work, collaborate, etc.

As you can see, I might choose to have this machine only carry out certain roles – that’s up to me. When I add a second node, I’ll have it act ONLY as a Worker.

One thing that struck me as a bit funny was the fact we installed Alteryx Designer on the machine. I wondered to myself why we needed a thick-client app on the same box as the Server. Many IT folks I know would frown on this as it could encourage mere mortals to “play on the server”.

Turns out we use Designer to install and configure things like the Alteryx Connect loaders, as well as additional Connections, etc. OK. Get it, still not sure I like it 🙂

…and we’re done. More configuration dialogs soon.

Leave a Reply

Old as dirt posts

Contact me.