November 27th, 2024

So how many replicas should my VM Application use?

Joseph Calev
Principal Software Engineer, Azure Core Compute

One great advantage of VM Applications is the ability to specify how many replicas you want for each VM Application version. While documentation exists on how to specify replicas, we don’t really provide advice on determining how many replicas to use. The goal of this post is to rectify that gap.

First, the basics. When you specify a replica count, we create one storage account behind the scenes for each replica. These are shared across versions of the same application. So, if you have version 1, 2, and 3, and each has 3 replicas, then they’ll all use the same storage account underneath. Different applications will have their own storage accounts. They won’t share.

If you are using block blobs, which is most common, then you’re limited to three replicas. If you use page blobs, the limit is much higher, but then your blobs need to be 512 byte aligned.

That being said, the major factor in deciding the number of replicas is egress. That’s the number of simultaneous connections to the storage account. The amount varies by region, but a good rule-of-thumb is 200 simultaneous connections per storage account. Keep in mind this is per region, because each region has its own accounts. We intentionally avoid cross-region copies.

Next, you need to factor in the size of your application. Larger files will take longer to download. How long depends on a number of conditions, but if you’re concerned about bandwidth you should run some tests to determine how long on average it takes to download, deducting perhaps thirty seconds for getting the information to download the package to the VM.

Then, you must determine how many simultaneous application downloads you will have at a time. The most common scenario where this may stress the system is a large VMSS being updated at the same time. However, many companies use upgrade domains for VMSS, in which case fewer instances will be updated at the same time. How many will actually be updated at a time will obviously depend on your business needs.

One scenario you may have to factor is the creation of a large VMSS. Since the goal is the simultaneous creation of VM instances, that means your application may be downloaded to every one simultaneously. There some delay exists for retries, this won’t help as much for large packages. The obvious solution here is to add your application as a subsequent request that takes advantage of upgrade domains. If that is not possible, then you will need to factor these in to the number of replicas.

From there, it should be a simple calculation. In practice, we’ve found that three replicas per region meet the vast majority of needs, but the page blob route exists just in case.

Note that there are retry mechanisms built into VM application package download. If we have an issue with one replica, we’ll automatically try another one. If the download fails in mid-run, we’ll also continue where we left off rather than trying to download the entire package from the beginning.

Author

Joseph Calev
Principal Software Engineer, Azure Core Compute

Software Engineer Lead at Microsoft. Focusing on enabling customer scenarios for VM extensions and applications.

0 comments