Avoiding allocation failure error in Microsoft Azure
In some cases you may encounter an allocation failure error when you are trying to perform an action which includes:
- Deleting and recreating a VM
- Creating a new VM
- Deploying new packages
- Deploying updates to existing deployments
- Starting a VM from stopped de-allocated state
Below let’s take a look at the different versions of this error message that you may see depending on the type of operation that you are trying to perform and also let’s understand what an affinity group is and how it looks within a datacenter before finally taking a look at the reason and recommendations to avoid this allocation failure.
Different versions of allocation failure errors
"Allocation failed; unable to satisfy constraints in request. The requested new service deployment is bound to an Affinity Group, or it targets a Virtual Network, or there is an existing deployment under this hosted service. Any of these conditions constrains the new deployment to specific Azure resources. Please retry later or try reducing the VM size or number of role instances. Alternatively, if possible, remove the aforementioned constraints or try deploying to a different region."
"Service allocation failure"
“The server encountered an internal error. Please retry the request.”
Understanding affinity groups
Affinity groups are a way you can group your cloud services by proximity to each other in the Azure datacenter in order to achieve optimal performance. When you create an affinity group, it lets Azure know to keep all of the services that belong to your affinity group as physically close to each other as possible. For example, if you want to keep the services running your data and your code together, you would specify the same affinity group for those cloud services. They would then run on hardware that is located close together in the datacenter. This can reduce latency and increase performance.
Affinity group from a datacenter perspective
Windows Azure partitions nodes in a datacenter into clusters, with each cluster containing about a thousand nodes/blades. When you create an affinity group this affinity group is pinned/bound to a particular cluster. All services created within an affinity group are housed within a single cluster, and currently don’t span across clusters/datacenter.
Reason behind this error
In some cases as availability of free blades or free space within a blade in a cluster fluctuates, the constraints to find an allocation for the service may not be met. When these constraints are not satisfied, we return back an allocation failure error message.
Recommendations to avoid this error
To avoid this error create multiple affinity groups to house services that are not required to be placed together, spin up smaller numbers of VM’s at a time, ensure retry logic is in place when an operation is unsuccessful and also utilize multiple datacenters for your deployments.
Comments
Anonymous
October 09, 2014
We are hitting this error even though we are not using any affinity groups. Do you know why? We have quite a few number of services running in a single data center.Anonymous
October 13, 2014
I am also unable to start a couple of simple VMs from a Stopped (Deallocated) state. There are no affinity groups and sizing one of them from A0 to A1 made no difference. The error message is unhelpful - The server encountered an internal error. Please retry the request. - And I have retried 15-20 times on each VM.Anonymous
December 02, 2014
We're getting this - again without any affinity groups. It just refuses to update the production or stage unless we first delete it in the portal (which loses the virtual IP). Every time... 15:18:54 - Uploading Package... 15:20:02 - Updating... 15:20:50 - The server encountered an internal error. Please retry the request.Anonymous
January 04, 2015
You will also get this error is you have hit your core quota. Lately though I am getting this in every instance