For each upgrade domain a status change event will be raised and the instance can decide whether it will handle the change or whether it needs to be restarted. Once the instances in that upgrade domain have reported that they are ready (either by handling the change, or by coming back online after restarting) then the fabric controller will move to the next upgrade domain.

12/29/2010

Tracing is probably one of the most discussed topics in the Windows Azure world. Not because it is freaking cool – but because it can be very tedious and partly massively counter-intuitive.

One way of doing tracing is to use System.Diagnostics features like traces sources and trace listeners. This has been in place since .NET 2.0. Since .NET 3.0 and the rise of WCF (Windows Communication Foundation) there was also extensive usage of the XmlWriterTraceListener. We can see numberless occurrences of the typical .svclog file extension in many .NET projects around the world. And we can view these files with the SvcTraceViewer.exetool from the Windows SDK.

All nice and well. But what about Windows Azure? In Windows Azure there is a default trace listener called Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener from the Microsoft.WindowsAzure.Diagnostics assembly.

If you use this guy and want to trace data via trace sources, your data will be stored in Windows Azure Storage tables. Take some time to play around with it and find out that the data in there is close to useless and surely not very consumer-friendly (i.e. try to search for some particular text or error message. Horror).

So, taking these two facts I thought it would be helpful to have a custom trace listener which I can configure just through my config file which uses Azure local storage to store .svclog files. From there on I am using scheduled transfers (which I demonstrated here) to move the .svclog files (which are now custom error logs for Windows Azure) to Azure blob storage. From there I can just open them up with the tool of my choice.

You can write your trace data explicitly to files or use tracing facilities like .NET’s trace source and listener infrastructure (or third party frameworks like log4net or nlog or…). So, this is not really news

In your Windows Azure applications you can configure the diagnostics monitor to include special folders – which you obtain a reference to through a local resource in VM’s local storage - to its configuration whose files will then be transferred to the configured Azure Storage blob container.

And a side note: of course this whole process incurs costs. Costs for data storage in Azure Storage. Costs for transactions (i.e. calls) against Azure Storage and costs for transferring the data from Azure Storage out of the data center for remote inspection.

Alright – this is the base for the next blog post which shows how to use a well-known trace log citizen from System.Diagnostics land in the cloud.

To get started monitoring your Azure applications with an enterprise-style systems management solution, you need to do the following:

Install SCOM. SCOM is a beast, but the good news is you can install all the components (including Active Directory and SQL Server) on a single server. Here is a very nice walkthrough – long and tedious, but very good.

Download and import the Azure management pack (MP) for SCOM. Note that the MP is still RC at the time of this writing but Microsoft support treats it like an RTM version already.

12/17/2010

Maybe we could blame Microsoft to name the new VM role feature (Windows Server 2008 R2 is supported as guest OS, 2011 should show broader OS support) introduced at PDC10 in a confusing way – but the fact remains: it is based on the Azure service model & the Windows Azure Fabric Controller (FC) is still in charge of everything. Although you uploaded your own prepared VM the FC may and will decide to take your VM instances offline, start new instances, reprogram the load balancers etc.

Yes, Windows Azure Compute is about PaaS (Platform-as-a-Service), also with the VM role now in place. Don’t get confused by the new role feature name. Your applications (and thus roles!) need to be state-agnostic.

BTW: What is not possible with the VM role today is automatic OS updates/patching. This means that you have no feasible option to have an up-to-date OS. When you try to run Windows Update this might work (actually it should). But then two things can happen:

your VM needs to reboot due to the Windows Update patches

FC decides to reboot your VM, or take it offline and hook up an new instance

In either case you end up with your original VM – bingo (and in the first case you will feel like in Groundhog Day… “Hey babe –dududu – I got you babe…”). Therefore, the official hands-on lab illustrates to disable WU entirely.