Suddenly since a couple of days ago I cannot deploy to my Azure cloud service to the staging environment. Deployment fails with:
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.
I do have my database virtual machine, my web-/workerroles and my Azure Storage account in the same affinity group talking to each other via a virtual network and I believe it is important to keep it that way to minimize network latency. Has anyone experienced this problem and could you solve it without getting rid of the affinity group?
Related
I use Azure- windows VM for running some services, the services are very stable(after testing).
The server run one day and after that he has fallen and i get this message.
**
Diagnose and solve problems
In Activity log
Resource health
Solved
The problem was in 'Auto-shutdown' it was enabled to 'Scheduled shutdown'. you can find it under - HOME --> VM --> Auto-shutdown(under the title Operations).
From the Activity Log, we can see the Azure Lab Service initiated the VM deallocation.
When you create a Lab Service in Azure, there is an option for you to automatically shut down virtual machines when users disconnect. It's probably the reason. This could help save costs.
It's the same Lab policy when you create template VMs in the lab Account or change it later.
I want to understand how does this Web / Worker role under cloud service work. As per my understanding, we have to define the required Web / Worker role instance count in CSDEF file, and Azure will create VMs (Instances) under the cloud service automatically. How about the application is updated and new code is deployed? Will the existing instances destroyed and new instances will be created or only the changed code will be updated in IIS? How does it work in the backend?
Note: Basically I have four instances in a web role and I want to create around 20 local user accounts in the VMs to manage it by different teams. I want to ensure the accounts do not get deleted whenever deployment is done.
Basically I have four instances in a web role and I want to create
around 20 local user accounts in the VMs to manage it by different
teams. I want to ensure the accounts do not get deleted whenever
deployment is done.
Simple answer: Don't Do This!
Azure Cloud Services are essentially Stateless Virtual Machines. What that means is that anything you do in the VM (like installing software etc.) after a VM is created for you can be removed. Though this doesn't apply when you simply deploy the new version of the code but there are times when Microsoft takes down faulty VMs and stand up new VMs for you automatically from the last package file you used to create/update the deployment. In this scenario, any changes you have made will be lost.
Cloud services should be considered stateless. The disks won't necessarily be destroyed on every deployment, but you must plan for it. Any configuration or operations you wish to perform prior to the role starting up must be defined as a startup task in the CSDEF file.
When I create a VM in Azure, it is creating an accompanying Cloud Service and Network Resource. I found that the Cloud Service is there as a deployment layer. I have not found why the Network Interface is there.
Since this particular circumstance is not going to have a deployment associated with it as it is used as an Elasticsearch server, I technically will not be needing the Cloud Service. However, when I delete the service, it takes the VM with it even though I do not expressly select it for delete.
My two specific questions:
1st - Why is there a Cloud Service created and not able to be deleted without repercussions when there is not deployment necessary?
2nd - Why is the Network Interface created and not able to be deleted without repercussions?
Both questions are with the understanding that this is an Elasticsearch VM.
A cloud service is a required artefact of an ASM/classic deployment if a VM. It is not needed in an Azure Resource Manager deployment, which is what you should use for new deployments. However, the two types of deployment are orthogonal, so you may need to keep using ASM if you already have VMs deployed that way. If so, you should consider migrating them to ARM.
I am having an issue deploying to the Staging environment of my Windows Azure Cloud Service.
This is something I do frequently without issue before doing a swap to Production (once I have validated everything is OK in Staging). Today for some reason I am getting this error when trying to deploy:
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. The long running operation tracking ID was: da5cc14aaba6228683cb4e8888b835e1.
Seeing as my deployment package has not changed since the last time I successfully performed an update of my Staging environment (apart from one line of code for a bug fix) I can't see this being an issue with my package. I am hoping this is transient Azure environment issue - anyone any ideas as to what this may be?
There is a fragmentation issue in the cluster you are trying to deploy to. The ops team is engaged and working to resolve and you should be able to deploy again later tonight or tomorrow.
Some additional information:
Once you create a deployment (either prod or staging slot) in a cloud service your entire cloud service (both prod and staging slots) are pinned to a cluster of machines (there are some Mark Russinovich fabric videos with more details if you are interested). So if there is a problem in a cluster, or you try to deploy a VM size not available in the cluster such as the new D series machines, then you may fail if the specific cluster can't allocate the request. To resolve this you can deploy to a brand new cloud service which will allow the fabric to check all clusters in that datacenter/region to satisfy the allocation request.
Consider a different upgrade strategy for scenarios like this. A lot of services will upgrade by creating a new deployment in a new cloud service, thus getting a new URL and IP address, and then modify the CNAME or A Record in order to transition clients to the new service.
If you see this issue again you can usually get a fast resolution by opening a support incident - http://azure.microsoft.com/en-us/support/options/
Update: We have a new blog post that describes this scenario and the common causes - http://azure.microsoft.com/blog/2015/03/19/allocation-failure-and-remediation/.
We had a similar allocation failed issue recently deploying our Azure Cloud Service:
Azure Cloud Service Deployment Error
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.
Allocation Failed - Resolution
Delete Existing Cloud Service
Create New Cloud Service target different Data Center or Resource Group (upload SSL certs required)
Redeploy cloud service package
Relink VSO Team Projects
I suspect the issue has something to do with a corrupt resource group or recent Azure upgrades that were not backwards compatible with older resource groups.
I am trying to created many virtual machines under a cloud service.
But i am not able to create more than two !! It gives an error telling deployment slot already taken.Even if i change the deployment name , it is giving the same error
The VMs need exclusive access to the deployment so you'll only be able to create one VM at a time.
Wait until the second VM you are creating completes, then try again.