Install N-able N-central on Microsoft Azure Managed Disks

The instructions below walk you through a new installation of N-able N-central in the Microsoft Azure Manage Disks environment. Microsoft Azure Classic deployment is no longer supported, however, Azure Resource Manager without Manage Disks is still supported.

While we recommend new deployments use this Azure Managed Disk deployment method, the 100GB, 200GB, 500GB and 1TB VHD images are still available for Azure Resource Manager without Managed Disks, and is available and supported for reinstalling and restoring N-able N-central from a backup.

Unlike all other N-able N-central deployments, Azure Managed Disks (MD) deployments support/require at least one Data disk in addition to the Operating System Disk. When you use the deployment script and assign one Data disk, Azure creates a RAID 0 array of the one disk. If you assign X data disks, Azure creates a RAID 0 of those X disks. N-able N-central uses a RAID 0 to combine multiple Data disks into a single mount point, while writing to all disks in parallel. This increases the IOPS throughput by X times.

Additionally, Azure MD deployments have no SWAP Volume, as N-able N-central uses the Resource Disk for the SWAP Volume. The Azure MD OS Disk image is 8 GB, as the install dynamically expands the image to match the deployed Managed Disk size on first boot.

Azure MD images are published to each Public Azure Region, so you no longer need to upload the VHD. It is important to know that there are some Azure Regions that are restricted to certain Azure users. These are a second, geographically separated Azure Region in the same country, or in the case of the EU, another nearby country that is reserved for customers needing in-country disaster recovery. For information on Azure regions, see https://azure.microsoft.com/en-us/global-infrastructure/geographies/#overview.

Deployment

Deploying N-able N-central to Azure with Managed Disks is simplified by using a Deployment PowerShell script. The script requires PowerShell 7 (formerly PowerShell Core) and the Azure PowerShell Module. You can run the script on any operating system that supports the cross platform PowerShell 7.

You must have basic knowledge of how to use Microsoft Azure, Windows PowerShell and how to install and configure N-able N-central.

The script is available for download on the N-able N-central release page of the N-able Partner Success Center.

After downloading the PowerShell Script, you need to edit the settings at the top of the script to meet your requirements. Some items are required, while others can be left with the defaults unless they need to use specific values, such as the virtual network settings. The script contains full documentation explaining all included options.

Ultra_SSD Data Disks are not supported.

Before you deploy a dual stack application in Azure, you must configure your subscription for this preview feature using the following Azure PowerShell.

Register as follows:

Register-AzProviderFeature -FeatureName AllowIPv6VirtualNetwork -ProviderNamespace Microsoft.Network

It takes up to 30 minutes for feature registration to complete.

You can check your registration status by running the following Azure PowerShell command:

Get-AzProviderFeature -FeatureName AllowIPv6VirtualNetwork -ProviderNamespace Microsoft.Network

After the registration is complete, run the following command:

Register-AzResourceProvider -ProviderNamespace Microsoft.Network

Once you have modified the PowerShell Install Script with your settings, you only need to launch it in a PowerShell console and it will complete the deployment for you. If you have not already logged into your Azure account from PowerShell, the script will prompt you to log in.

If you are using Windows, you may need to complete the following steps to run the script. For more information see the Microsoft article, Set-Execution Policy.

  1. Ensure your PowerShell Execution Policy is set to "Remote-Signed".
  2. Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

  3. Un-Block the Install Script.
  4. Unblock-File -Path .\AzureMD.ps1

First run

After the PowerShell Script has completed successfully, wait a few minutes before logging into the Web UI. On first run, N-able N-central will expand the OS disk, create a software RAID from the data disks, and move the database to it, then reset the trial license. This process can take 10 - 15 minutes to complete.

If you try to log in to the web UI right after they VM is deployed, you will be kicked out, and the web UI will be unresponsive for a few minutes while the first run tasks complete.

If you deploy the VM more than 15 days after the Azure image was generated, you will be able to tell the first run activities have not been completed by the expired license warning on the login page. Once the first run tasks complete, the license error will no longer be present.

VM Sizing

Always size N-able N-central for your expected number of devices in the future. Try to plan for at least 2 - 3 years in the future.

The maximum number of supported Data Disks is defined by the Azure VM size. You will need to consult the Azure Documentation for their VM size before deciding on the number of Data Disks. Azure VM sizing can be a little tricky, and may require some trial and error to determine the best VM size for any particular deployment.

VM sizing must support Generation 2 VMs.

Rough guidelines are as follows:

Number of Devices Recommended Azure Size CPU Cores Memory OS Disk Data Disks
(Total)
Up to 1,000 Standard_DS2_v2 2 4 GB 80 GB 20 GB
Up to 3,000 Standard_DS3_v2 4 8 GB 110 GB 60 GB
Up to 6,000 Standard_DS4_v2 8 16 GB 200 GB 125 GB
Up to 9,000 Standard_DS5_v2 12 24 GB 300 GB 200 GB
Up to 12,000 Standard_DS5_v2 16 32 GB 400 GB 275 GB
Up to 16,000 Standard_DS32s_v3 22 48 GB 550 GB 375 GB
Up to 20,000 Standard_F32s_v2 28 64 GB 700 GB 500 GB
Up to 24,000 Standard_F48s_v2 34 80 GB 875 GB 650 GB

Notes

  • The recommendations are based on N-able N-central requirements balanced with Azure Maximum IOPS. For example, N-able recommends "Standard_DS5_v2" as apposed to the newer generation "Standard_D16s_v3", because the "Standard_DS5_v2" has a maximum IOPS of 51200 as compared to 25600 for the "Standard_D16s_v3".
  • For best performance, we recommend using the maximum number of Data disks your VM size permits. More small disks will provide better IOPS performance than fewer larger disks.

  • The OS disk is still used for temporary storage during the nightly backup to reduce IOPS on the data disks, as well as for the Backup Volume. Therefore there needs to be at least the size of the Data disk, plus OS files, Repository and 15% for the Backup Volume. As a result, the total disk utilization is slightly more than for non-Azure deployments.
  • N-able N-central is only supported on Instance types that provide local SSD storage. For Azure based N-able N-central deployments, the Local SSD Resource Disk is used for the swap-file, in place of the swap volume on all other N-able N-central deployments. An example of an unsupported instance type without local SSD storage would be the Dsv4 Series (not to be confused with the supported Ddsv4 Series).

  • N-able N-central is only currently supported on Instance types that provide Intel Processors. The newer AMD EPYC Processor instances have not been tested and verified. An example of an unsupported AMD EPYC instance type would be the Dasv4 Series.

What's next?

With N-able N-central installed: