My New Whitepaper on Managing Deployments/Upgrades in Azure

I just published on the Aditi site a new whitepaper on the specifics of how upgrades work in Azure.   Here’s the introl.  Unfortunately if you want the entire paper you go to the Aditi site and fill and fill have to request it to be mailed to you next day.  Sorry about that…

http://blog.aditi.com/cloud/how-to-manage-deployments-upgrades-on-windows-azure/

==================================================

Managing deployments and updates to Windows Azure applications is a very similar process as to how it is done for on-premise applications.  You can upgrade your application on every server all at once.

Windows Azure offers the concept of a “VIP-swap” where you can deploy or update your Azure application in one shot. Or you can do it incrementally with custom-defined granularity across groups of Azure servers.

Azure provides the concept Update Domains to help you manage this process of updating your application in a sequential manner.  The option you choose is based upon your business and application requirements for system availability to users as well as your tolerance for having more than one version of your application available to users during the upgrade process.

A common thread of discussion facing IT Ops personnel new to Windows Azure are:

• How to manage application changes with respect to deployment, updates, and down times?
• How does one update a service when only some parts of its configuration need to change?
• What about down time and do I need to take my whole application down to update just a part of it?
• Can I update it incrementally over the range of servers?
• Do I deploy an application directly into user circulation within an environment or can I verify base functionality before making it public?

Answers to this question are complex even if you are managing all your servers yourself on-premise. On the Azure Cloud, it can get even more confusing. The deployment issues revolve around a few key Azure concepts – VIP swaps, deletion/redeploy of a service, service updates, and update domains.

Click on the link below to download this whitepaper for an in-depth guide on how to manage application changes with respect to deployment, updates, and down times on Windows Azure.

http://blog.aditi.com/cloud/how-to-manage-deployments-upgrades-on-windows-azure/

Advertisement

SQL Server on IaaS VM Spanning Multiple Disks

A best practice for SQL Server is to store the data/log/backup files on a disk other than the OS Disk. This transfers over to SQL Server installed on an Azure IaaS VM.  Due to storage requirements it may be necessary to have more than one physical disk compose a logical disk for these log files.  Another best practice to increase IOPS (Input Output Operations) on SQL Server running on an Azure VM is to store each of these physical disks in their own Azure blob storage account.

However, the Azure Management portal will not give us the ability during VHD provisioning to select a preferred storage account.  By default the VHD will be created at the storage account where our OSDisk is created.  Therefore you must take the following steps to attach the disks one-by-one to the VM. Once that is done you create one spanned disk for data, and one for logs/backup, using the Computer Management Admin console.  Then within SQL Server Management Studio you replace the default C:\xxx locations for SQL Server data, logs, and backup files with the spanned disk volumes.

To create and attach the data disks to the VM you must do the following:

1. From the Azure Portal for the VM select “Attach an empty disk” and create a new VHD. By default it will be created at the default OSDisk Azure storage location X for the VM
2. Create a new Azure destination storage account Y. You will create one account for each VHD as best practice
3. With ClumsyLeaf Cloud Explorer expand both the destination storage account X (left hand pane) and the source storage container with the blob containing the new VHD (right hand pane) from step 1.
4. Drag/copy the VHD blob from original storage location X (right hand pane) to the new destination storage location Y (left hand pane)

   An alternative way to do the VHD copy is to use the Azure command line from your local machine defined in this Aditi blog entry http://blog.aditi.com/2012/11/how-to-copy-files-between-windows-azure.html. You will first need to download the NodeJS tool first from here to your local machine. A third copy option is to use the PowerShell command Add-AzureDisk with the –ImportFrom parameter.

5. In the Azure Portal select Detach Disk for the specific VM
6. Once the disk is detached go to the Azure Portal VM screen and click on Disks, the select Attach Created Disk
7. In the Browse Cloud Storage dialog for VHD URL field locate the storage blob to which you copied the VHD to in step 4, and select Open and complete the dialog.
8. Repeat the steps again for as many disks as you need to attach to that the VM running SQL Server.

Azure Tips from the IT Pro Water Cooler

With the release of Infrastructure as a Service (IaaS) this summer there seems to suddenly be an increased interest for IT Pros in Windows Azure. Originally most of Azure’s features, like Web and worker roles, were focused primarily upon developers. This accidentally led to Windows Azure being erroneously viewed by the IT Pro community as a chance for developers to bleed over into the roles of the IT Pro.  It has also been viewed unfairly as a driver behind their jobs eventually going away. After all – if the Cloud handles all the deployment, installation, and patching of the core software, and provisioning of the hardware, what roles still exists for IT Pros in that environment?

Once you get a better understanding of the types of opportunities that are created by the Cloud you can see that the theory of an obsolete IT Pro replaced by Windows Azure is not very realistic. For the IT Pro Azure VMs and Azure Web sites with the introduction of IaaS, Windows Azure is now also an ITPro platform. As an IT Pro it might help to think of Azure as an extension of your IT department.

Over the next few posts I will be discussing concise Windows Azure tips and best practices for IT Pros.  Let’s start with our first topic – Deployment.

Deployment

• With Windows Azure, developers can go right to Azure and deploy their applications.  For your on-premise server you would not allow developers to do direct deployment to production. IT Pros need to take this control back! To manage deployment and keep developers from directly deploying from Visual Studio (they can also deploy with configuration files) create two Azure accounts – one account for development and one for production. Give them the development account to work with and do what they want. However, when they have to deploy to production they need to go through your account and you do it for them.

• When you deploy try to keep the Azure storage and code on the same location.  You can create and use affinity groups to help with that. So if you have a market in the Far East you can easily deploy it all into the Far East.  This is an advantage for deployment you get with the cloud.  You cannot change a data center but you can choose a region of the world. The affinity group guarantees a hosted service and storage will be in the same datacenter. Group application pieces into a single deployment package when they must be hosted in the same data center.    Note – you cannot use affinity groups with Windows Azure SQL Database.

Management Certificates

Closely related to the topic of deployment is the management of certificates in the Azure portal.  Each subscription should have its own separate Azure service management certificate which is unique to that subscription.   To use a management or service certificates it must be uploaded through the Windows Azure Platform Management Portal.  Windows Azure uses both management certificates and service certificates.

• Management Certificates – Stored at the subscription level, these certificates are used to enable Windows Azure using the ‘management’ tools:  SDK tools, the Windows Azure Tools for Visual Studio, or REST API calls.  These certificates are independent of any hosted service or deployment.
• Service Certificates – Stored at the hosted service level, these certificates are used by your deployed services.

Typical IT policies define distinct roles for parties associated with application Development, Test, Integration, Deployment, and Production. These policies restrict roles from operations that exceed their defined responsibilities. Here are some suggestions on how to manage certificates for these roles.

Development – Share a certificate between all the developers to allow freedom of development.

Integration – Have its’ own management certificate

Test – Certificate shared only with the Operations team

Deployment – Used for deployment roles and only distributed to parties responsible for application deployment

Production – Certificate shared only with the Operations team