An introduction to windows azure
1 / 30

An Introduction to Windows Azure - PowerPoint PPT Presentation

  • Uploaded on

An Introduction to Windows Azure. Jimmy Narang. Cloud Services. A service in the cloud has to: Be able to handle arbitrary node failures Be available all the time Be able to scale up or down on demand without the need to re-write the code Handle platform or software upgrades.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'An Introduction to Windows Azure' - alda

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Cloud services
Cloud Services

  • A service in the cloud has to:

    • Be able to handle arbitrary node failures

    • Be available all the time

    • Be able to scale up or down on demand without the need to re-write the code

    • Handle platform or software upgrades

Cloud services architecture
Cloud Services: Architecture

  • The service design must be:

    • Loosely coupled

    • Such that node failures do not affect functionality

    • Nodes can be initialized and added easily

    • State of the service is decoupled from nodes

    • Scale can be achieved through quantity (scale out)


  • Cloud: thousands of connected servers

  • Azure: an operating system for the cloud

    • Abstracts away hardware – switches, servers, disks, routers, load-balancers

    • Manages deployment, so that developer can upload code and hit ‘run’

    • Provides reliable common storage that can be accessed from any mode

    • Provides a familiar development platform

Azure service architecture
Azure Service Architecture

  • A service boundary

  • Roles

    • Each role has a number of identical instances

    • Two types of roles: web roles and worker role

  • Storage

    • Accessible from any instance

    • Blobs, tables, queues

  • Endpoints

    • External: communicate outside the service boundary

    • Internal: communicate within the service boundary

Service architecture continued
Service Architecture continued …

Service Boundary

m role instances

n role instances

Web Role

Worker Role

Web Role

Web Role

Worker Role


Web Role

Worker Role

External endpoint

Internal endpoints

Cloud Storage

External endpoint

Azure programming model
Azure: Programming Model

  • Developers write their code and describe a service model

  • Service model includes role definitions, VM Size, instance counts, endpoints, etc.

  • code + service model is packed and uploaded to Azure, which deploys the service in Microsoft Datacenters

Roles and role instances
Roles and Role Instances

  • Two types: web roles and worker roles

  • No Admin access; cannot install applications

  • Choose a particular VM capacity for each role

  • Specify number of instances per role

    • Azure starts a fresh instance if an existing one crashes

  • Code:

    • Extend RoleEntryPointclass for worker roles; optional for web roles.

    • Asp.Net for web roles

External endpoints
External Endpoints

  • Each service runs in an isolated boundary

  • The service deployment is assigned a Virtual IP address (VIP)

    • The service is reachable externally via ‘external endpoints’ on this VIP

  • External endpoints: ports selected to be exposed to the outside world for in-coming connections to the service

    • Usually http and https on web roles (i.e., port no. 80 and 81)

    • Can be TCP endpoints on worker roles

  • Both web and worker roles can make outbound connections to Internet resources

    • via HTTP or HTTPS and via Microsoft .NET APIs for TCP/IP sockets.

Internal endpoints
Internal Endpoints

  • Azure provides APIs to obtain internal IPs of each instance in each role

  • Roles can define ‘internal endpoints’ (ports exposed within the service) to communicate between instances

Azure storage
Azure Storage

  • Accessed from anywhere using account name and storage key

  • Exposed in the form of URIs:

    • http://<accntName><queueName>

    • http://<accntName><container>/<blobName>

    • http://<accntName><tableName>

Azure storage queues
Azure Storage: Queues

  • Queues: often the best way to communicate between roles

  • Messages can be 8kb max

    • use messages as pointers to blobs/tables for larger data

  • Can create several queues per account

  • Not guaranteed Fifo; no priority queues either.

  • Guaranteed each message will be seen at least once

Queue operations
Queue Operations

  • Create / Delete queue

  • Get / Put message

  • Peek message (queueName, n)

  • Delete message (queueName, msgId, popreceipt)

    • ‘get message’ does not lead to deletion!

  • Clear Queue

Queue messages
Queue Messages

  • MessageID: A GUID associated with each msg

  • VisibilityTimeOut: default 30 seconds, max: 2 hours. Messages not deleted within this interval will return to the queue

  • PopReceipt: A string retrieved with every get-msg.

  • PopReceipt+MsgID required to delete a msg

  • MessageTTl: (7 days) messages not deleted within this interval are garbage collected

Queue example
Queue: example



C1: GetMsg (returns 1)

C2: GetMsg (returns 2)

C2: DeleteMsg #2

C1 dies

C2: GetMsg (returns 3)

Visibility Timeout on Msg#1

C2: DeleteMsg#3

C2: GetMsg (returns 1)












Azure storage blobs
Azure storage: Blobs

  • A large chunk of (raw binary) data

  • Blob Operations:

    • Create / Delete

    • Read / Write: byte range (page blob) or blocks (block blob)

    • Lease the blob

    • Create a Snapshot

    • Create a copy

    • Mount as Drive (page blob)

Blobs access control
Blobs: Access control

  • Hierarchy: accounts, containers, blobs

    • http://<account><container>/<blobname>

    • An account can contain multiple containers

    • A container can contain blobs or other containers

  • Fine grained access control can be granted to containers/blobs (grant permissions for individual operations such as read, write, delete, list, take snapshot etc.)

Block blobs
Block Blobs

  • A blob as a sequential list of blocks

  • Each block has an ID

  • Blocks are immutable

  • Upload blocks out of order / in parallel

    • PutBlock to upload block

    • PutBlockList to stitch uploaded blocks into blob

  • Order of upload doesn’t matter; order in Putblocklist matters.

  • Putblocklist: First commit wins (all uncommitted blocks are garbage collected)

Block blobs example
Block Blobs: example







PutBlockList(BlockId2, BlockId3, BlockId4);

Block Id 1

Block Id 3

Block Id 2

Block Id 4

Block Id 4

Block Id 2

Block Id 3

Block Id 4

Page blobs
Page Blobs

  • Page blobs: A collection of pages

  • Specify blob size at creation time.

    • Entire range initialized to 0 at creation

  • Read/Write specific byte ranges, no ‘commit’ required (unlike block blobs)

  • 512 Byte alignment required for write operations; not required for read

Blobs leasing
Blobs: leasing

  • A lease is a timed (1 min) lock on a block

    • Acquire lease: create a lease for a blob without one

    • Renew: request to hold the existing lease

    • Release

    • Break: to end the lease but ensure that another instance cannot acquire it until the current lease has expired

Azure storage tables
Azure storage: Tables

  • Can scale up to billions of entries and terabytes of data

  • Contain set of ‘entities’ (rows) with ‘properties’ (columns)

  • (Partition Key, Row Key) defines the primary key

    • Partition key is used to partition the table into storage nodes

    • Row key uniquely identifies an entity within a partition

Azure storage tables1
Azure storage: Tables

  • No Fixed schema, except for Partition Key, Row Key, and Timestamp

    • Properties are stored as <name, typed value>

    • Two entities can have very different properties

  • Common data types – int, string, guid, timestamp etc. – supported.

  • Limits on the size of an entity (1MB), and # of properties(255, including keys & timestamp)

Table operations
Table: Operations

  • Queries:

    • always return whole entities, no projections

    • Only ‘From’, ‘Take’ (max 1000), ‘where’ operators supported – no select, sort, group-by, join, etc.

    • Normal Boolean and comparison operators supported.

    • For good performance, ‘where’ should have the partition key

  • Insert / Delete

  • Update: Replaces the original entity

  • Merge: modifies properties in place

Tables consistency
Tables: Consistency

  • ACID guaranteed for transactions involving a single entity.

  • Group Transactions have restrictions, such as:

    • Only possible for entities in the same partition

    • Entity needs to be identified by primary key

    • Max 100 operations per ‘batch’

  • Snapshot isolation: there will be no dirty reads

  • Application needs to ensure cross-table consistency

Tables partitioning
Tables: Partitioning

  • A partition (i.e. all entities with the same partition key) are served by the same ‘node’

    • ‘node’ here should not be thought of as a single server, but a single ‘place’.

    • Entity locality: Entities within the same partition are stored together

  • Tradeoffs in choosing the partition key:

    • large partitions: efficient group queries

    • small partitions: spread across more nodes => greater scalability

Tables concurrency
Tables: Concurrency

  • Updating an entity is a multi-step process:

    • Get the entity from the server

    • Update it locally, and submit to server

  • Entity can get changed in that time

  • Use E-tags (“version numbers”) stored in the header associated with each entity

    • Update only if version number matches with the one you were expecting

    • Or use If-Match * to unconditionally update

Azure diagnostics
Azure Diagnostics

  • Use for debugging, performance monitoring, traffic analysis etc.

  • Based on logging: no remote desktop access to instances

  • Choose the required Log sources: Azure, IIS logs, Windows event logs, Perf counters, Crash dumps (and others)

  • Then dump the logs locally or store them in Azure storage (at scheduled intervals or on-demand)

Azure other features
Azure: other features

  • X Drive

    • Mount a page blob as a VHD (per instance)

  • SQL Azure

    • Complete relational SQL storage in the cloud

  • Azure appliance

    • A container of pre-configured hardware with Azure installed

  • Content Delivery Network

    • Mark public blobs to be copied to edge locations across a region

Azure sdk and devfabric
Azure: SDK and devFabric

  • <DEMO>