Azure Getting Started - VM Size Guide

SoftNAS on Azure front-ends Azure VHDs (block-based storage) and presents it as volumes in industry standard formats such as CIFS/SMB, NFS, AFP, and iSCSI. This allows organizations to use Azure-based storage without changing the format of their app data, improving flexibility. 

By also leveraging Blob storage, SoftNAS can increase the storage capacity of mid-range Azure sizes significantly, ensuring our customers save money by only paying for the storage they need, rather than the larger network capacities, additional RAM, and extra cores that would be required in order to provision the same storage capacity with block-based storage.

Microsoft Azure provides computing virtual machines running on the XenSource hypervisor. Each instance is a unique copy of a virtual machine image. There are over 200 possible combinations of the Azure virtual machine. When choosing a virtual machine type for production deployment, give careful consideration to the overall storage demand and best practices for performance.  The top two things to consider are IOPS and Throughput. SoftNAS® specific configurations to consider are the use of Deduplication and/or Compression.

SoftNAS® offers the broadest range of instance sizes and region availability on Microsoft Azure™. It’s important to select the right instance size to configure a storage solution that is the right combination of performance and price for your use case. General guidance and a guide tool are provided to help you select the virtual machine size for your workload to get your project started. Our instance size calculation tool is available directly on our main website here.

The SoftNAS Cost Savings Calculator is designed to help new users find the right initial instance size for their workload quickly and easily. Buurst always recommends further analysis and testing of their selected instance until workload characteristics are fully understood. This will allow the customer to then refine their instance size selection to the perfect balance of performance and cost.

The guidance below is intended to help you choose the initial VM size for your SoftNAS server.

Your storage system's data efficiency depends on many factors, not least of which are the resources you assign to it. This is true of any platform, not just Azure. Resources that SoftNAS leverages includes CPU and RAM, both of which are important to improve read and write speeds. SoftNAS leverages both Ram and disk for caching to optimize read and write performance. SoftNAS also support data reduction features such as deduplication or compression which does consume CPU cycles and must be considered when choosing your instance. 

The performance of your workload on SoftNAS is dependent on the type of storage used and the format of stored data. A data store is a generic term for what SoftNAS utilizes at the back end to hold the data. Data stores can vary from all SSD (typically on a block type data store) to hard disk drives which are often used for expansive storage like object-based data stores.

The right formula for providing a good workload experience starts with the use case. This means first understanding whether your first consideration is high performance, or if your use case requires large amounts of storage at a lower cost.

For a full-featured, high-performance test case, one that allows you to set up advanced features such as high availability and replication, or to test a realistic simulated heavy workload, we highly recommend an instance size of DS4v2 or larger for anything beyond a very limited scope POC. 
  • Consider the following criteria when determining the appropriate Azure VM size for your use case.


A complete reference for Azure virtual machine sizes can be found here.

Memory

  • Azure VMs provide memory based upon the size of the VM, the larger the size, the more memory provided.
  • Memory can be used for caching to improve performance.
  • Consider using a larger VM size with more memory if you have a read intensive workload that can benefit from larger memory-based Read cache.
  • Large size block reads will use up Read cache more quickly and will benefit from the availability of additional memory.

CPU/Cores

  • SoftNAS CPU requirements will be based upon the data to be processed, like any storage solution. However, when features such as deduplication, encryption, compression, or software RAID are applied, CPU requirements will increase due to the added workload. 
  • Consider using a VM with more CPU cores to get better performance with deduplication, encryption, compression and/or RAID enabled. A good rule of thumb is to calculate half again the CPU requirements for data processing alone.

Network

  • Network speed can be a key factor to consider depending on your workloads data transfer and throughput requirements.
  • Azure defines its VM network performance as “moderate”, “high” or “very high”. SoftNAS does not recommend use of VMs with a “moderate” network rating for production workloads (or for POCs in which you hope to simulate production workloads).


Examples of VM Sizes with High or Very High network performance:

  • DS3_v2
  • DS4_v2
  • DS14_v2

Ensure that you verify speeds yourself before selecting a size.  Changes in Azure might of occurred since the time of writing this documentation.

Block Storage

If your workload depends on the use of Block storage, the amount of block storage that can be associated with a VM is a good starting point.   As seen in the table to the right, the size of your VM (based on the number of vCPUs) dictates the number of 1TB Block disks that can be associated with the VM.


Max Storage

The default maximum storage account capacity per storage account is 5 PiB.

Use multiple storage accounts to provide up to 16 PiB of storage.

VM SizevCPU

Memory

(GiB)

Temp Storage

(SSD - GiB)

Max Data Disk

(Block Only)

Network
DS3_v24142816High
DS4_v28285632High
DS14_v21611222464Very High

Ephemeral SSD

  • SoftNAS recommends the use of VMs with available SSD ephemeral storage for performance production workloads to be used for caching and system activity.
    • Actual usable storage will depend on the features you select for your SoftNAS deployment
    • Some storage will be used for the OS and SoftNAS code.  Assume about 10% of the storage.
    • Cache settings can also use part of this storage
    • Enabling deduplication increases your usable storage.
    • Replication will use more storage. Assume about 50% for planning purposes.
    • The amount of ephemeral SSD available will depend on the VM size chosen.
  • SSD Storage (ephemeral) should NOT be considered as additional disk space for storage. It is meant for caching operations.

Premium Block (SSD)

  • For workloads with high performance needs, Premium Block SSD storage can be added to your SoftNAS environment via additional Azure Storage Accounts of type Premium.
  • SoftNAS fully supports Azure Premium Storage, and can front-end the high-performance, low-latency disk support this storage provides for VMs running I/O intensive workloads. These disks store data on solid state drives, improving both read and write capacity of your workloads considerably. 
  • DS, DSv2 or GS series Azure VMs support attaching several Premium Storage disks, so that your applications can have up to 64 TB of high performance storage per VM. With Premium Storage, your applications can achieve 80,000 IOPS (input/output operations per second) per VM and 2000 MB per second disk throughput per VM with extremely low latencies for read operations. These disks are only available in certain regions.
  • More information regarding Premium Storage can be found here.

Standard Block (HDD)

  • For workloads with lower performance needs, Standard Block storage storage can be added to your SoftNAS environment via additional Azure Storage Accounts of type Standard for a lower cost solution.
  • The amount of Standard Block storage you can add is limited by your VM size as indicated in the above table. 
  • Note, if you use Standard Block storage for your VM system disk, the system disk will count as one of your available Standard Block disks on the VM.

Cache Storage

SoftNAS® provides the ability to add Read Cache and Write Log devices to a storage pool. Read Cache provides an additional layer of cache, in addition to RAM memory cache. The Write Log provides a cache for incoming writes to be written temporarily to high-speed storage, then later staged to lower-speed spindle-based storage. Premium Block SSD is recommended for both Read Cache and Write Log. 

The amount of Read Cache or Write Log storage you configure will depend on your workload.

More information regarding configuration of Read Cache and Write Logs can be found here.

Suggestions:

With so many factors involved in the exact sizing of an Azure VM for SoftNAS, the below information provides some initial guidance to help you choose an initial size for your VM in a production environment. 


Small:  
For production environments that require less than 200GB of storage, you may want to consider a D3v2 VM as your starting point.   Memory is adequate for a most of standard workloads, provided they do not require “very high” performing network speeds. 

Medium:  A DS4v2 VM is a good starting point if you need more storage than is provided by a DS3v2.  It also has the extra memory and CPU resources to handle the processing and caching for standard workloads the require more storage than a DS3v2, and still provides good (but not the best) network properties.

Large:  For workloads that require a very high speed network connection due to the amount of data transferred over a network connection, you should consider a VM in the DS14v2 range. In addition to the very high speed network, this level of VM gives you a lot more storage and the CPU and memory capacity a SoftNAS deployment needs to perform at its best. 

With the addition of blob storage support, SoftNAS is not as dependent on Azure Compute sizes when it comes to providing storage. If storage is a priority concern, above RAM, CPU and Network performance, lower cost configurations leveraging smaller Azure sizes with both local block storage and object storage are possible.