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.
Related
I am new to Microsoft Azure and working on a MVP for a client. I am able to successfully deploy my ASP.NET MVC web app to a Web Role. The issue I'm facing is that Azure Web Role seems to recycle itself and revert to the deployment package. This leads to rollback of manual changes done (if any) after the deployment (like I allow user to upload profile images and am storing them in file system).
Is this the expected behavior? If not, when can I look from debugging purposes?
Looking for any help possible.
Is this the expected behavior? If not, when can I look from debugging
purposes?
It is expected behavior. Azure Fabric Controller is responsible for managing the Virtual Machines in which your WebRole runs. It takes care of patching the VM and do other maintenance related work on that VM. It is also responsible for taking out faulty VMs and replace them with brand new VMs. When the replacement happens, Fabric Controller will create the new VM based on the last deployment package.
You should not be making any changes manually after VM hosting WebRole has been created, these are Stateless VMs. Any changes you make to VM will be rolled back if Fabric Controller decides to recycle the VM. Please note that these changes do persist if the VM is simply rebooted.
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?
I have deployed a Web API written with .net Core to a local dev Azure Service Fabric cluster on my machine. I have plenty of disk space, memory, etc, and the app gets deployed there. However, success is intermittent. Sometimes it doesn't deploy to all the nodes, and now I have it deployed to all the nodes, but within the Azure Service Fabric Manager page, I see each application in each node has an Error status with the message: "The ServiceType was not registered within the configured timeout." I don't THINK I should have to remove and redeploy everything. Is there some way I can force it to 're-register' the installed service type? Microsoft docs are really really thin on troubleshooting these clusters.
Is there some way I can force it to 're-register' the installed service type?
On your local machine you can set the deployment to always remove the application when you're done debugging. However, if it's not completing in the first place I'm not sure if this workflow would still work.
Since we're on the topic, in the cloud I think you'd just have to use the Powershell scripts to first compare the existing app types and version and remove them before "updating". Since the orchestration of this is complicated I like to use tools to manage it.
In VSTS for instance there is an overwrite SameAppTypeAndVersion option.
And finally, if you're just tired of using the Service Fabric UI to remove the Application over and over while you troubleshoot it might be faster to use the icon in the system tray to reset the cluster to a fresh state.
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.