Brief analysis of Windows Azure basic concept

Windows Azure Platform is constantly changing, so the concept of what it is is changing. In view of the future use of these children's shoes, so I based on the MSDN2010 year November 22 document and the Windows Azure programing Model 1.0 sorted this article.

A basic concept of Windows Azure

Windows Azure and Windows Azure platforms are not a thing, the platform refers to the cloud services platform built by Microsoft in several data centers around the world, including Windows Azure operating system and a number of columns of services such as SQL Azure and so on.

As with all cloud computing services, the Windows Azure platform simplifies the maintenance of technical facilities and software and provides flexible payment solutions based on on-demand principles, which not only ensures high availability and scalability of the infrastructure, It also guarantees the cost of covering long-term requirements that are required to buy servers and infrastructure.

Windows Azure operating system as the development, runtime, and control environment for Windows Azure platform. It has built-in load balancing and automatic management of resources.

Currently, the programming work for Windows Azure requires the following services and tools:

Windows Azure Compute Services Windows Azure Storage Services Windows Azure Platform Management Portal Windows Azure Devel opment Environment Windows Azure Tools for Visual Studio

Windows Azure Computing Service

Windows Azure provides a set of host environments that are based on the entire Internet level, built in multiple data centers across different parts of the globe, that users can use to execute managed code.

The relationship between several concepts in computing services is as follows:

Windows Azure Compute Service

--deployment

-Role

-Role

--depolyment

-Role

Note that this deployment azure is no matter what, each deployment is compiled with VS. a package with several role deployments

Currently, there are three kinds of Windows Azure roles: Web role: An environment specifically configured for Web applications, supporting IIS7 and ASP.net, which actually run on IIS7.0. Typically, it is used to handle external HTTP requests, and it also supports technical Worker role such as WCF, PHP, and Java: For general-purpose programs, it may be Virtual Machine role as a background handler for Web function (VM Role) provides a user-defined image to migrate existing Windows Server programs to Windows Azure environment

A service can mix multiple role types.

Role may need to interact with the run-time environment, so you must use the Windows Azure Managed API.

Windows Azure Storage Service

Windows Azure Storage Servies provides the ability to store persisted data in the cloud. It mainly includes the following basic services: BLOB service, used to store text and binary data Queue service, used to store the reliable persistent message Table service used by the service bureau to store the structured data that can be queried

The Windows Azure SDK provides a rest API and a managed API for accessing storage services. They support any form of access through HTTP/S

Windows Azure Platform Administration Portal

The management portal is a tool for managing the deployment and monitoring of Windows Azure services for users.

In the admin portal, we see some concepts: Deployment Health, which represents the status Affinity Groups of the deployed project, which allows users to optimize performance Management by organizing services and storage that are hosted on a geographic area basis. Resource Reporting that allows clients to access subscribers ' subscriptions, allowing users to check in cloud based SQL Azure Database Reporting Services service bus access, Access AppFabric Service Portal Virtual Network, Access Windows Azure Microsoft Connect Service

second, Windows Azure programming model

While Windows Azure has VM role, it is more likely to be an abstraction of the PAAs (Platform-service) hierarchy, so instead of completely replicating the old Windows Server-oriented programming model, it has created a new set of models to improve on the following three points: Management capabilities: As a PAAs application, the platform itself is responsible for handling a large number of management transactions, such as system upgrades, updates, patching, etc., so that users can not have to manage the environment of the program to run the situation-this is a very good way to save trouble. Usability: Avoid the offline service due to upgrades, patches, hardware errors, or other causes. Azure uses the redundant measures provided by the cloud platform to avoid these problems, so the Azure programming model itself is designed to ensure that the service continues to run. Scalable: Azure offers the scalability of the entire Internet level. It also allows for more flexible use of resources. three basic rules for the Windows Azure programming model

To take full advantage of the benefits of the Windows Azure platform, cloud-oriented cloud-based programs must adhere to the following three rules: A Windows Azure program consists of one or more roles (which can mix multiple role) a Windows Every roles in an azure program runs on more than one instances a Windows Azure program works correctly when any of the role instance go wrong

Only programs developed in full compliance with 3 rules can make your program fully enjoy the benefits of cloud computing.

As mentioned earlier, the role in Azure includes three kinds, Web role, Worker role, and VM role,

For example, a program can use Web role to process HTTP requests from users and then pass the request to work role. Such a way makes the whole program have a good scalability.

For any Windows Azure program, you should run at least two isolated instances for each of its role. Each instance runs on top of its own VM.

The following figure is the case of the actual running instance of the above diagram, and you can see that each role of the program runs multiple instances and is above a different VM. The developer should tell Windows Azure how many instances it needs to run for each role. Each particular instance of role runs the exact same code, so these instances can be replaced, so that Azure can automatically handle load balancing and fault tolerance. However, it is important to note thatAzure does not guarantee that requests for the same user can be handled by the same instance.

For the above program, when any instance of its role is hung, the system is guaranteed to work properly (unless all instance are hung, of course, this probability is much smaller than the probability of a hang)

Next, with a little bit of technical detail, let's look at the details of the Windows Azure programming model

Some of the working principles of the Windows Azure programming model Fabric Controller

Windows Azure runs in large data centers, and different instances of each program are deployed to different servers, with Fabric controller managing the computers in the datacenter. When we deploy a cloud program, we actually upload our service profiles and packages. The configuration file tells fabric controller to run an instance of role using a different host. And once the deployment is successful, fabric controller will continue to monitor the running of these programs, and when one of those instances hangs, it starts a new instance.

Because of the fabric controller,azure is able to have such good management capabilities, it automatically to the program and the underlying system environment maintenance and updates. As a result, the entire system has a good resistance to hardware errors caused by downtime,

In fact, in the selection of server hardware, Fabric controller is not random, and it configures different instances of a role to different fault domain (fault domains, including a range of hardware, such as computers, switches, etc. – apparently, they are at a point of failure) , so the hardware error does not ripple through the entire program.

On the software, when an instance of the program hangs, fabric controller restarts the program or restarts the VM that the program is running on. So how does Azure get the program to upgrade without downtime? Similar to the above fault domain, in azure, different instances of role are located in different update domains (update fields, and fault domain). When the new version of the program is deployed, the fabric controller will turn off the power of an update domain, upgrade it, and then launch it. Then the instances of the other update fields are processed. This enables the so-called not to upgrade the offline.

In terms of scalability, Azure not only allows users to specify how many instances of a role to run, but also allows programs with larger load changes to adjust the number of instances in real time through web portals or programs developed by themselves.

These benefits of technology seem so wonderful, but remember that Windows Azure is charged for each instance of running, so if a user uses only one instance to save costs, he violates the three principles of the programming model, so that Can not enjoy the above said the benefits. some of the more complicated issues

The Windows Azure programming model brings more than the three principles mentioned above, from a procedural point of view, we also have to see that this model has brought some new problems to our development environment, which we can generalize into the following 3 aspects: How instances interacts with the OS Instances how to interact with persistent storage interaction instances

First of all, from the point of view of the operating system, the traditional server system is managed by the operation team, while in Azure it is controlled by fabric controller, although it is highly automated with program control, but we also encounter some problems, such as how to let the program run in admin mode. Furthermore, the more serious problem is that the physical servers allowed by instance are always on different machines, so the information that the program writes to the local system is certainly unreliable. Although work role and web role can now run in admin mode, the above problem is still unresolved. This leads to the second problem: since the information that the program writes to the local system is not guaranteed, we need to know that it is non-persistent when we program, and that the data should be stored outside the role instances for different instances to access the data.

Similarly, storage must be redundant, and it must be able to handle a large amount of data. For very large data, traditional relational systems are not the best choice, so there is a data structure such as the blobs mentioned above.

In this illustration, the program uses two BLOBs and a table, but the Azure storage maintains a data mirror for each instance at the bottom, as well as across the physical system across the fault domain, so that even if some of the mirrors are hung, it is still available. It is important to note, however, that this mechanism of Windows Azure allows the data to be manipulated only by one instance at a time (read-write)

Finally, let's look at the interaction between the instances, which is a complex problem (think about process synchronization issues). Interaction between Instances

Usually when we design a program it is layered (logically divided into layer or physically divided tier) or divided into modules, which usually need to interact with each other, however, in azure, such interactions are slightly different from traditional programs. Remember that each instance of a particular role mentioned earlier is equivalent to replaceable. This means that a Web role passes a request to the worker role, but it should not be able to manage which instance of the particular worker role to handle the request, or even web role should not rely on an instance-dependent galaxy such as an IP address to communicate. We need a more general mechanism.

On the Azure platform, our program can communicate using the most common Windows Azure queues, and it works as follows:

In this case, one of the Web role's instance gets a request 1 This instance creates a piece of information that contains the work required for the request and writes it to Windows Azure queue (remember one of the basic 3 data structures mentioned above, So the queue and Blob are based on the same principle--one copy per instance--2, and then the Worker role reads the message from the queue, noting that it is written by the Web role. Delete this message from the queue after you finish working on it, yes, what you see is dequeue after work is done and then deleted, which is different from the normal queues we understand, for example, in Microsoft Message Queuing technology, A program can read the message in the queue is an atomic operation, if the program read the message error, then the read transaction will be restored, that is, the original message will be repeated, so that every message in the MSMQ queue can be sent in the order of the correct submission. But Windows Azure is a bit different, it does not support transactional read operations, so it cannot guarantee accurate on-demand delivery, in Azure, a message can be read and processed many times. Adding an instance of worker role read the message and finished working, but hung up before it was deleted, the read message is automatically reproduced after the timeout. The design mechanism, such as azure, is said to be a trade-off between speed and scalability and the reliability mentioned above-choosing speed.

Of course, in addition to queues, Azure can also use the API to let an instance discover other specific instances, and then send the request directly to each other.

Summary

This article briefly introduces some of the basic concepts on Winows Azure platform, then explains some of the principles of the Windows Azure programming model, and makes a little test of what to think about programs running on Windows Azure. In short, Windows Azure is relatively easy to use at the moment, and of course it's far from perfect, so let's expect it to be more mature.