Hosting Ark Node(s) in Microsoft Azure

with Template Deployment Walk-through

There are plenty of guides out there on how to create Ark Nodes, secure your node, and compilations of these with Ark Stats.

Rather than go through these other tasks one-by-one, which have been detailed by professionals in the links above, I want to put emphasis on WHERE the servers are hosted.

Most guides have you use a cheap DigitalOcean droplet, or some other $5 server. While economical, it’s certainly not meeting minimum Ark requirements at that point. By shifting to the use of Azure, you can make the VMs Highly Available, Scalable, and easily replicate-able via templates from the web-portal. There are also PowerShell automation capabilities by using this platform.

**We will do the following:**Create an Azure Portal / Resource Manager logonDeploy our first virtual machine — Create a new “Resource Group” — Configure the Azure Firewall (“Network Security Group”)Use the first virtual machine to create a templateDeploy another Ark Node VM via this template, and join to an “Availability Set” with the first VM

**Minimum requirements for running an Ark node, per Ark.io documentation:**Operating System: Ubuntu 16.04CPU: 1 core (More is better)RAM: 4GB (More is better)Disk: 20GB — SSD recommended

Some quick Azure breakdown on sizing near these requirements can be found at: https://azure.microsoft.com/en-us/pricing/calculator/

Let’s get started with the basics. We’re going to Login @ HTTPS://portal.azure.com — Use a credit card for a trial if desired for the creation of an account. There are also Developer Program Benefits of $150 per month if you have an existing MSDN account.

Once logged into your Azure Resource Manager Dashboard, click “+ New” and it will open a ‘Blade’ of options. — We’re going to be using the ever-popular Ubuntu Server 16.04 LTS VM (Long-Term Servicing branch Virtual Machine)

+ New -> Search for Ubuntu 16.04 OR click on the quickstart tile

Once you select / find the Ubuntu 16.04 LTS Virtual Machine, click on it and it will open up the creation steps.

If you’re confident with SSH authentication, please feel free to do so with this virtual machine. If you’re not familiar and do not have a good grasp, you can read about it here: https://help.ubuntu.com/community/SSH/OpenSSH/Keys

SSH/OpenSSH/Keys - Community Help Wiki_Public key authentication is a much better solution than passwords for most people. In fact, if you don't mind leaving…_help.ubuntu.com

For ease of follow-ability, we’re going to stick with Password Based authentication. We will also be creating a new “Resource Group” which is a sort of Azure resource-container. All items related to each other, Ark in this instance, will be added to this Resource Group. In the future, it’ll be easy to find and manage all of these inter-related items we’re making.

General Configuration Settings to Follow

Important parts to note here, are the Disk type (SSD is default), the non-root username, as well as the Resource Group. Here we are creating a brand-new Resource Group for all of our Ark Nodes, named ARK_RG1. The location listed is where the Virtual Machines, storage, and virtual networking will be housed and can be managed from a single grouping.

Hit Next, and you’ll be required to pick a Machine Size (Basically how much do you want to spend vs. Resource allocations).

You have a few options to meet the System Requirements, depending on how you want to proceed. A good rule of thumb is to start low, and ramp up the resources as needed. While it does require a reboot when you ‘Scale Up’, it is definitely more cost effective to start smaller.

All pricing and availability for this guide is based on US South Central region for Azure (May vary between datacenters)

I will be rolling out “B1MS Standard” sized VMs for the guide. If I join the node network, and my nodes begin to lag behind, I can easily “Scale up” to other VM performance levels by running a quick few clicks, and a reboot.

Click Select to continue on your VM size selection to continue. Next are the Optional Features configurations section. I’m going to walk through each section because they each spawn their own ‘Blade’ of settings:

High Availability: Click + “Create New” — Name: Something easy to recognize — Fault Domains (Virtual machines in the same fault domain share a common power source and physical network switch.): Minimum of 2 — Update Domains: (Virtual machines in the same update domain will be restarted together during planned maintenance. Azure never restarts more than one update domain at a time.): recommended 5 for Scale-Out

Picture of Settings for High Availability

Storage — Managed Disks?: Yes

Network: — Virtual Network: +”Create New” — — Defaults are fine, unless you run more than 256 servers in this subnet or have a special / different name.

— Subnet: Defaults are fine, unless you run more than 256 servers in this subnet or have a special / different name.

— Public IP Address: +”Create New” — — Default name is fine. Assignment = Dynamic (Can be changed later if desired). Means it will NOT have a static IP address.

— Network Security Group (Firewall): This is where we set the Azure firewall for your resources. This will be the firewall laying in front of your VMs. — — Default: default-allow-ssh is set to port 22. This can be changed at any time, if you desire to change the SSH port to something custom. (See Ark Installation port recommendations when you get there) → Click +Add an inbound rule → Click “Advanced” and input settings:Source: Any (This can be changed if you want to limit access based on public-ip addresses inbound)Source port ranges: * Destination: Any (Can also be changed)Destination port ranges: 4001–4002 (Ark Ports)Protocol: TCPAction: AllowPriority: 100Name: Ark-Port_4001–4002 →Click “OK”

Extensions: None

Auto-Shutdown: Off

Monitoring: — Boot diagnostics: Off (Unless you begin having boot issues, it can be turned on later) — Guest OS diagnostics: Off (Can be turned on later if desired)

Click “Next” to proceed to the Summary page.

This next page validates that everything you did up to this point is safe to deploy. It also lists everything you’ve configured, and most importantly, lets you download templates and parameters to make deployment faster in the future.

Click “Download template and parameters” to get a ZIP file of template files. You can optionally add this new template to your “Template Library” by clicking “Add to Library”

Summary Screen and Template download options

By clicking “Add to Library” you will need to Name the template, and leave a somewhat detailed description of the deployment.

Once done saving your template, click on “Create” from the ‘Summary’ section of our original deployment. This will create the first VM in Azure.

Create Button

It will take 5 or so minutes before your server is fully deployed.

To view your VMs / Resource Group, navigate to Resource Groups > ARK_RG1 — Here, you will be able to view all of the storage groups, virtual machines, the firewall (NSG) settings, and the availability set.

Click on your VM, in my instance “ArkNode1” in the Resource Group ARK_RG1

We want to set a DNS address for this VM, so you can use a dynamic DNS name instead of a static IP for connectivity. Click on “Configure” under “DNS Name” in the Virtual Machine’s Overview.

DNS Menu in the VM ‘Blade’

Set the DNS name to whatever you please. For ease for remembering, I am naming it the same of the VM itself.

The DNS Name will be whatever you choose + The Azure Cloudapp domain for your datacenter location

This means, when using PuTTY to connect into this VM, you can use the DNS Name of: arknode1.southcentralus.cloudapp.azure.com

This is dynamically updated DNS by Azure’s back-end, so you do not need to set that yourself either if your VM changes public IP dynamically.

This means, when using PuTTY to connect into this VM, you can use the DNS Name of: arknode1.southcentralus.cloudapp.azure.com

Alternatively, you can choose ‘Static’ IP, however there is a monthly cost associated with a static vs dynamic.

Before we begin any kind of Ark Node configuration, which unfortunately at this time is not easily automated, let us perform a Template Deployment of a second VM to this availability group. By learning this skill, you can deploy any number of additional VMs quickly without needing to adjust all of the minute details of the first time through.

In the Azure search panel, type in “Template” and select the “Templates (preview)”

Searching in Azure for Templates (Preview)

Select the template you created earlier and saved to your Template Library, I named mine “ark_node_template”, and it will open it up.

All settings preserved, nice!

Click “Deploy” to bring up the parameters that need to be set for the new template deployment. They are initially are all BLANK.

To fill these values in with our old VM’s data, and make the slight necessary adjustments, do the following:

Click on “Edit Parameters” to bring up options for editing the background data.

Using the Downloaded ZIP file from earlier, which you need to have extracted somewhere on your computer, click “Load File” on the ‘Edit Parameters’ page.

“Load file” in top-left opens up the file explorer

Click “Save” after it uploads your parameters JSON file, and it will take you back to a now fully-populated set of deployment information.

There are a few fields that need adjustment, so be certain to fill in / adjust as necessary. For me, the following needed adjustment:

Resource Group — Set to ARK_RG1Virtual Machine Name — ArkNode2 (New VM Name)Network Interface Name — arknode1762 (New Network Interface for the VM)Admin Password — <set accordingly>PUBLICIPADDRESSNAME — ArkNode2-ip (New / separate public IP for this VM) — Sidenote: You will need to go into the VM and set the DNS address for this as well.

All other items in the parameter list are safe to keep identical, as they are re-usable and overlapping.

Click “Agree” and “Purchase” to initiate the deployment of this new VM.

After the typical 5 or so minutes, it should end successfully. Go ahead and double-check the VM settings from it’s device page in your Resource Group.

You are now free to connect to both of your VMs via PuTTY, using your assigned / created login names and password from the configuration steps.

Can also deploy as many VMs as your wallet can handle with this setup, and not just for Ark-related applications either. It’s a fairly generic setup for any VM farm in Azure.

By placing both VMs into a High Availability Set, with 2 fault domains, we guarantee Azure’s 99.99% uptime of at least 1 server in the event their datacenter has outages of any kind.

I will be working on an updated guide, for the setup and configuration of Ark itself via Ansible. This way commands can be invoked against multiple servers simultaneously, so we can configure the Ark Nodes without sitting at the console the whole time. (Will update this article when that one is completed)

Good Resources / References:

Ark.io setup of a node: https://blog.ark.io/how-to-setup-a-node-for-ark-and-a-basic-cheat-sheet-4f82910719da

Secure your node: https://blog.ark.io/how-to-secure-your-ark-node-541254028616

Quick config of an Ark Node by Jarunik: https://medium.com/@jarunik/installing-and-managing-an-ark-node-577a9074b9bb