--- title: "Recommendations for Microsoft Azure" description: "Best practices for deploying Aerospike on Microsoft Azure, covering OS, VM types, storage, and networking." --- # Recommendations for Microsoft Azure > For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt) > > All documentation pages available in markdown. This page describes recommendations for deploying Aerospike Database on Microsoft Azure, including operating system selection, VM sizing, networking, persistent disks, local SSDs, shadow device configuration, and fault tolerance. ## Operating system We recommend using the latest Ubuntu Server LTS as it has the most recent optimizations and bug fixes on Azure. You can find Ubuntu through the Azure portal or at [this page](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/canonical.0001-com-ubuntu-server-focal). ## Instance type Choose VM types based on the namespace storage model, memory requirements, CPU requirements, and network throughput for your workload. For local SSD workloads, evaluate current storage-optimized VM families, such as Lsv3, Lsv4, or newer generations available in your Azure region. Other VM families can be appropriate when their memory, CPU, storage, and network characteristics match your requirements. ## Network setup By default, machines within the same Virtual Network in Azure can communicate freely with each other. Aerospike uses TCP port 3000 for client traffic, ports 3001 and 3002 for intra-cluster fabric and heartbeat traffic, and port 3003 for administrative access. If database clients are in the same virtual network, they can connect over port 3000 without a separate firewall rule. No Aerospike ports should be open to the internet. You need a port for SSH access to your instances. The default TCP port is 22. All instances in Azure are assigned an internal IP address. These internal IP addresses should be used in the [mesh heartbeat](https://aerospike.com/docs/database/8.1.2/manage/network/heartbeat#mesh-unicast-heartbeat) configuration. ## Persistent disks - Azure provides storage in the form of VHD Disks in [Storage Account Overview](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-overview). - Azure [limits](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd) individual persistent disk performance. To achieve higher performance, you must provision additional disks and use them in parallel. Connecting multiple disks would not exceed the vm’s maximum io limit. - See [Azure managed disk types](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types) for a list supported disks. ## Local SSD Some Instance types come with local SSDs. This provides extremely good performance, with high input/output operations per second (IOPS) and low latency compared to the persistent disk options. However, these local SSDs are created and destroyed along with the virtual machine instance. In spite of this, the local SSD storage option can be used judiciously with an Aerospike cluster so that the data is always replicated on multiple local SSDs attached to multiple virtual machines in the cluster. Here is an example configuration snippet: ```plaintext storage-engine device { device /dev/sdb } ``` Local SSD IOPS are not limited by persistent Disk IOPS allocations or instance IOPS allocations. They have their own allocations. ::: note See [Premium Storage scalability](https://docs.microsoft.com/en-us/azure/storage/storage-premium-storage#premium-storage-scalability-and-performance-targets). ::: ## Shadow device configuration As noted above, some Azure instance types have local SSDs. These can be significantly faster than Premium Storage Disks, as they are network attached. But Azure treats local SSDs as cache and not suitable for long-term data, as these volumes are purged when the instance stops. To take advantage of local disks with the persistence guarantee of Azure Blob Storage, Aerospike has the [Shadow Device configuration](https://aerospike.com/docs/database/8.1.2/manage/namespace/storage/config/#setup-for-shadow-device) for the storage engine. The write throughput is still limited by the instance limit and storage volume, so this strategy gives good results when the percentage of writes is low. An example config would be as follows: ```plaintext storage-engine device{ device /dev/sdb /dev/sdc ... } ``` The shadow EBS device must have a size at least equal to the size of the direct-attached SSD. Otherwise, when you try to start your Aerospike cluster, it logs the critical error `shadow device is smaller than main device` and fails to start. Here is an example of the error message: ```plaintext May 05 2021 21:31:36 GMT: CRITICAL (drv_ssd): (drv_ssd.c:3290) shadow device /dev/sdc is smaller than main device - 2147483648 < 5368709120 ``` ::: note For data-in-memory use cases with persistence, it may also be preferable to use a local SSD device alongside a Premium Storage Disk volume. In this case, it would be to save on IOPS cost incurred on read during the defragmentation process. The reads would be performed against the local SSD device and re-written/defragmented blocks directly mirrored to the Premium Storage Disk volume. ::: ## Fault tolerance Azure has the concept of [Availability Sets](https://docs.microsoft.com/en-us/azure/virtual-machines/availability-set-overview). It consists of Update Domains and Fault Domains. ![My cool image](https://aerospike.com/docs/_astro/azure-udfd.wwegSzTx_22qc67.png) Update Domains are groups of physical systems that can be rebooted simultaneously in a maintenance event. Fault Domains are groups of physical systems that share power and network switch. - Aerospike suggests having the Availability Set to be defined with the most number of Update Domains and Fault Domains as possible. - Azure will not give notice of VM reboots for Update Domain interruptions. ::: caution VMs are migrated by Azure automatically should a Fault Domain issue arise. This live-migration process has historically been detrimental to Aerospike. Aerospike can be made more resilient against live migrations, but at the cost of performance. ::: ::: note Aerospike also provides XDR replication in our Enterprise Edition to facilitate DR scenarios ::: ## Additional information - [Azure VM sizes](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes) - [Azure managed disk types](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types)