Understand Persistent VM Disk (2)

Since all persistent PVM disks are eventually stored in blob storage, there must be a way to manage these disks and the .vhd files in the blob storage. The tools and portal to manage these are simple and straight forward, but understanding below key concepts would be very helpful for you to use those tools.

There are three stages of a .vhd file or a PVM disk:

1. raw .vhd file in blob storage (use any blob explore tool to manage this)
2. .vhd files recognized by PVM as disks (use Azure portal to create/delete disk)
3. PVM disk attached to a PVM instance (use Azure portal to attach/detach disk)

O/S disk vs. Data disk: this is decided when you recognize a raw blob file as a disk. O/S disk can be used to create a VM instance.

Image vs. Disk: Image is "sysprepared" O/S disk. You can use either Image or O/S Disk to create a VM instance. If you use O/S Disk, all the old user name, machine name etc. persist, while everything is as from scratch if you use Image.

Understand Persistant VM disks (1)

Persistent VM (PVM) is Azure's IaaS offering comparable to Amazon's EC2. Unlike EC2 which uses local disks for the majority of the time, PVM uses Azure blob storage to store disks. This design has multiple implications.

On the good side, your data in the disks are more reliable, as every Azure blob automatically has 3 local copies which are always synchronized and another 3 copies in a different data center 100+ miles away which is delay synchronized. On the bad side, the disk I/O performance might be impacted. For this reason, PVM do use both Azure blob backed disks and local only disks to optimize the disk I/O, so it's important to understand where each disk lives. Below is the explanation:

C: disk is the OS disk. Persisted in blob storage.

D: disk is local disk. Not persisted, but very fast.

F: disk is additional user data disk. Persisted in blob.

Azure Web Site

When we were developing the CloudSamurai multi-tenant framework, we were aware that there is an official Microsoft project doing the same thing as CloudSamurai using the similar ARR approach. Of course, the MS official project must be more mature and more complete in features. Although, we didn't know when and how this official MS offering would be available.


In the latest Azure June 2012 release, the 'Azure Web Site' is unveiled. This is the MS-self hosted version of high-density share-IIS multi-tenant web site solution. It is expected that the customer-hosted version be released in the next big release. Here is the official description of 'Azure Web Site':


"Quickly and easily deploy sites to a highly scalable cloud environment with the frameworks and open source apps of your choice using Windows Azure Web Sites. Get started for free and scale as you go on a cloud platform that enables automatic scale-out options across shared and reserved instances for greater isolation and performance."


You should also check ScottG's blog for more information:
http://weblogs.asp.net/scottgu/archive/2012/06/07/meet-the-new-windows-azure.aspx

Messaging VS. Notifying

Messaging is the basis of all SOA design, however most people don't know the essense of 'Message' in SOA is actrually 'to convey as little information as possible'. If you can convey less infomation but still get the task done, the design would be better than if you convey more information. Because by doing so, you reduced the inter-system dependency.


The essense of 'Message in SOA' is thus not WCF, not SOAP, not Web Service. It's about how to share information between different entities, while try to keep the dependency between entity as little as possible. Some people use xml as message, while transmit a very complex and big xml. It's not a good practice. Sharing little knowledge. The less the better.


In this sense, Notifying would be a better design than Messaging, because Notify only convey a simple code while Message can be very complex. We learned a lot from project Cloud Samurai(http://cloudsamurai.codeplex.com/), and thus decided to use Notify rather than Message in the project.

Emerging Order

As we found in several Azure projects, designing complex inter-system interaction is very challenging. Most Azure projects would involve multiple VMs, and multiple components or processes inside each VM, so they are typical inter-system design problems.


SOA (Service Oriented Architecture), although sounds old, is probobaly the most effective way to handle this challenges. However, we need to take a special view through the SOA len. We should emphasis more on Independence. If we can design autonomous and independent components, who can respond to the environment and messages in an intellectural and responsive way, the Order of the inter-system will Emerge as a result.  The complex behavior of the inter-system is hard to be designed, rather it will emerge from the group of independent components.


We learned a lot about the principle of Emerging Order from this project.
http://cloudsamurai.codeplex.com/

Use VSTS to load test Azure based app

How to do load test on Azure based app? Using VSTS in Azure is a natural choice, since both the test rig and servers been tested would be in cloud and be freely scaled out. However, testing with VSTS in Azure today could be painful, mainly due to the network issues. We acturally did such a test recently. Below is our findings.


(The to-be-released new persistent VM role, as well as the improved Azure network capabilities like Brooklyn and internal DNS, will hopefully make the VSTS testing in Auzre much easier in the future.)

• Can we do VSTS load test from Azure and test App in Azure?
• Yes
• Deployment architecture
• (this is the design works for us, but not necessarily the best design.)
• Test Controller in Azure, worker role
• Test Agents in Azure, worker role
• Controller and Agents are in the same worker role, on different instances
• Use Azure connect to group Test Controller and Test Agents so that they can see each other
• VSTS test DB in SQL Azure
• App server (being tested) in Azure, whatever role
• Workarounds and Pains
• VSTS DB doesn’t work directly in SQL Azure
• We used customized DB scripts
• Test Rig (Agent/Controller/TestedServer) is very unstable in Azure
• Controller may lose connection to Agent. Agent may not start.
• If this happens during the test, the test will fail.
• We are forced to use only up to 3 agents.
• Every time this happens, we need to restart the service in Agents or controller.
• Hard to collect performance counters