Let's say I have 3 instances in the Azure. Each is running separate layer of the application, as I described in this question Independent deployment of separate layers to Azure. For independent deployment of each layer (read Role) a separate Azure deployment project is created. The question is, what instance will be replaced, when I will be deploying, for example business layer? Can I be sure that the instances with UI and Data Access will stay untouched? How the instance to be replaced is found, based on name of the role?
To clarify, you have 3 layers, each hosted in a different windows azure role (not instance). If you have each role in a seperate deployment (seperate hosted services), then when you deploy, you are only going to be upgrading that layer. The other layers will not be impacted.
However if there are any signature differences, a dependent layer may break if the service its trying to call changes. Its for this reason that you want t omake sure any services support versioning and are always backwards compatible at least one version.
I've created a quick blog post with some screen shots of doing a single role upgrade. Note that the silverlight portal issued an exception for me while doing this and I've reported that error and will update the blog post if we find out what it was about.
Updated: There is bug in the silverlight management portal that currently prevents the performance of a single role upgrade. The Windows Azure team is aware of this and will be addressing it in a future update. No ETA for that update at this time. However, you can still perform the single role update/upgrade via the management API.
As Brent said, it is definitely possible to do a Single Role upgrade. It used to be that if you made any changes to the ServiceDefinition (change VM size, added new Config settings, updated Role Name or changed the instance count from the service definition that is currently deployed) when you upgraded that role, Azure Fabric Controller would not allow you to do in-place upgrade. Now, that is also possible. So you can do an in-place upgrade on Role and bump up the VM size. As always, you at least want to have 2 instances to ensure that you don't experience any downtime.
Ranjith
http://www.opstera.com
Related
Am trying to help a customer move their services from an Azure Direct subscription to a CSP subscription. In the guides I've found, the approach used for IaaS1 (the old/class Azure - ASM) differ from what's used if a client's services all belong to IaaS2 (the new portal - ARM).
My confusion arises from the fact that while things like Class VMs can be easily identified if one views a client's services under the new portal - they are annotated as "Classic", am not so sure about any other services originally created under the ASM model.
And to further complicate things, it seems as though, viewing a client's services in the classic portal shows both ASM and ARM services, and this, without any means of distinguishing between them!
So, how do I go about this?
My company developed an Azure Resource Manager-based solution that deploys a set of resources (essentially a Storage, SQL DB and Web App), and it is already implemented as our provisioning process for new customers.
However, we are now studying the best way to perform updates, and one of the hypotheses we are considering is having a specific template that updates the binaries of this application.
The idea is to have a separate template, that only has the web app, an app host and a MSDeploy resource that gets the latest version of our package and reuploads it to that web app.
The only problem I'm seeing with this solution is the ability to handle any changes in configuration that are necessary with newer version of the binaries - we do not want users to have to re-input any parameters they placed for the original deploy (done via a Deploy To Azure button), so, any configurations will have to be performed within the application - the plan is for it to use the Microsoft.WindowsAzure.Management.WebSites library.
The major limitation with using Microsoft.WindowsAzure.Management.WebSites is that you are restricted to authenticating with either a certificate or a service principal. Ideally we would like to find a way for the updates to not need any authentication other than the one you provide when you are deploying the update.
Is there any recommendation of best practices to follow for this kind of scenario?
Thank you.
Link to the equivalent discussion on TechNet
It is possible to update only via ARM templates.
For example connection strings can be added automatically to the application settings even when creating the dependent resources themselves.
Ex. Account storage connection string.
Only first time creation of your web sites will take a bit more time, something like 30 sec.
ARM will not destroy your WebApps if they exist already. it will update only.
If there are no changes, then the deployment is very fast.
If your changes require a new Appsettings parameter, you can enter it in ARM , check in to your repository.
and next deployment will pick up and update the WebApp.
So no need for anyone to log-in and update.
Our final decision was to give up on using ARM exclusively. The Service Principal solution, through the SDK, would allow us to use a Web Job or a Site Extension to perform (automatic or prompted) updates that included configuration changes. However, it would require "too many" privileges - why would a customer trust an application that can, at will, create new resources or update existing ones to increase his Azure bill?
The decision was made to utilize Powershell only for updates - if the customer can see the scripts and authenticate himself, this is not a concern. Sadly, this increases update complexity, but we found it to be a necessary evil.
I have an Azure Cloud Service out in production. I recently received the following message from Microsoft about upcoming service for their Cloud Services platform:
All Cloud Services running web and/or worker roles referenced below will experience downtime during this maintenance. Cloud Services with two or more role instances in different upgrade domains will have external connectivity at least 99.95 percent of the time. Please note that the SLA guaranteeing service availability only applies to services that are deployed with more than one instance per role. Azure updates one upgrade domain at a time. For more information about distribution of roles across upgrade domains and the update process, please visit the Update an Azure Service webpage.
The way I take the email, each instance is essentially a VM on a different host, and they'll be rebooting hosts throughout the maintentance period, so if I don't want to be out of service during this time, I need to ensure I have more than one instance. Is this accurate? If so, how do I "add" an instance?
That is correct.
You can increase your instance count by updating the configuration for the role. In Visual Studio, you can do this in the Properties window for the role and increase the Instance count setting. Then, redeploy the service.
A faster way is to download the configuration file (.cscfg) for the role from the Azure portal, update the instance count setting, and then upload the changed configuration file. The setting is in the Instances element shown here.
You can download the configuration file for the role from the Azure portal (portal.azure.com) by going to the Cloud Service blade and clicking on Settings in the toolbar. In the Settings blade click Configuration. In the Configuration blade are where you will find Download and Upload buttons in the toolbar.
The way I take the email, each instance is essentially a VM on a
different host, and they'll be rebooting hosts throughout the
maintentance period, so if I don't want to be out of service during
this time, I need to ensure I have more than one instance. Is this
accurate?
Your understanding is correct.
If so, how do I "add" an instance?
There are many ways to do it.
One would be to edit your role's configuration file (*.cscfg) and changing the Instances element's count property from 1 to 2 and then uploading this file through Azure Portal (Cloud Service --> Configure Tab --> Upload button)
Other one would be to change the instance count through "Scale" tab for Cloud Service in question. On this tab, you will see "Instance Count" setting. Just update it from 1 to 2.
Other options include PowerShell, writing code but I think the ones I mentioned above should be the easiest way to accomplish the task.
We are thinking of using Windows Azure for simulation. ~100 VM nodes each working on it's problem set and reporting back the result to a Master node.
I have created VM instances from the web UI. In order for this to work, we would need to use Azure API to bring servers up and shut them down once they are done.
Does anyone have any experience with something like this? I am looking for advise, gotchas etc.
thanks.
You sure can do it and I have helped other to make it happen on hundreds on nodes. Take a look at Windows Azure Rest API to configure your role as described here. While others may have other idea, I think the general steps would be as below:
Create a master machine or a webrole to manage your roles using REST API
Create a worker role instance and use it to clone multiple instances as if needed
Use REST API to start and shutdown worker role along with update the instance count when in need
Use Azure Boot Strapper to bootstrap the VM depend on your requirement
Azure REST based Service Management API can work from a web app or a standalone app, so you can also have a web role to make it happen from anywhere in world. This way you don't need any on premise components at all as it will be totally cloud solution. If you need any help on creating web role I sure can help.
You can provision Virtual Machines using Service Management REST API (there's also a managed API on NuGet).
But in your case you might want to consider using Cloud Services (PaaS). With Cloud Services you simply build your application, you package it and deploy it. Then using the portal or the management API you can simply configure the number of instances. There is even a command line tool (csmanage.exe) which allows you to to change the number of instances through the service configuration.
Would like to know how can i upgrade a single role of deployment application on hosted service using REST API.let say I have 2 web and 1 worker role and i would like to update/upgrade only one webrole out of 2 .I know that we can do it Azure Management Portal.
Would also like to know how rollback works in Azure.If I like to rollback deployment application to previous state, can i rollback?
You cannot modify the number of roles using the Service Management API. This is only possible by doing a new deployment (this is possible using the API).
The only thing you can do is modifying the number of instances by using the ChangeConfiguration request: Change Deployment Configuration
Rolling back a deployment to a previous state is possible using the REST API. What I tend to do when deploying a new version is by using a VIP swap:
I deploy the new version of my app to staging
I do a VIP swap (new version becomes production, old version becomes staging)
I shut down the staging version (without deleting it), this way the old version stops processing messages from queues etc.. in case my logic changed.
If I want to roll back, I simply turn the old deployment back on and do a VIP swap again. This way of working comes with 2 remarks:
You can only "revert" to the previous version of your app
You need to take into account that you might have changed external resources (like SQL Azure) and rolling back the application could break because of this change
Edit: Modified my rolling back answer with a link to the REST API
Good answer by #Sandrino. Just wanted to expand on in-place updates a bit. The Upgrade Deployment REST API call is what you'd use for updating a role. As Sandrino pointed out, you'll still need to push a new deployment package up (which includes all roles), but you can then specify to upgrade only a single role from the entire package by specifying the role name for the RoleToUpgrade element.
See this MSDN reference article on the Upgrade Deployment API call.
EDIT: All REST APIs are also available through PowerShell cmdlets (downloadable here). Take a look at Set-AzureDeployment, which has an Upgrade parameter set.