jimmy narang 1. a service in the cloud has to: be able to handle arbitrary node failures be...
TRANSCRIPT
![Page 1: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/1.jpg)
1
An Introduction to Windows AzureJimmy Narang
![Page 2: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/2.jpg)
2
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
![Page 3: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/3.jpg)
3
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)
![Page 4: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/4.jpg)
4
Azure• 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
![Page 5: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/5.jpg)
5
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
![Page 6: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/6.jpg)
6
Web Role
Service Architecture continued …
Cloud Storage
LB
n role instances
Worker RoleWeb RoleWeb Role Worker RoleWeb Role Worker Role
External endpoint
Service Boundary
Internal endpointsExternal endpoint
m role instances
![Page 7: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/7.jpg)
7
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
![Page 8: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/8.jpg)
8
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 RoleEntryPoint class for worker roles; optional for
web roles.• Asp.Net for web roles
![Page 9: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/9.jpg)
9
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.
![Page 10: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/10.jpg)
10
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
![Page 11: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/11.jpg)
11
Azure Storage• Accessed from anywhere using account name and
storage key• Exposed in the form of URIs:• http://<accntName>.queue.core.windows.net/
<queueName>• http://<accntName>.blob.core.windows.net/
<container>/<blobName>• http://<accntName>.table.core.windows.net/
<tableName>
![Page 12: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/12.jpg)
12
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
![Page 13: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/13.jpg)
13
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
![Page 14: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/14.jpg)
14
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
![Page 15: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/15.jpg)
15
Queue: example
2 1
C1
C2
123
Producers Consumers
P 3 12
C1: GetMsg (returns 1)C2: GetMsg (returns 2)C2: DeleteMsg #2C1 diesC2: GetMsg (returns 3)Visibility Timeout on Msg#1C2: DeleteMsg #3C2: GetMsg (returns 1)
![Page 16: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/16.jpg)
16
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)
![Page 17: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/17.jpg)
17
Blobs: Access control• Hierarchy: accounts, containers, blobs• http://<account>.blob.core.windows.net/<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.)
![Page 18: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/18.jpg)
18
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)
![Page 19: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/19.jpg)
19
Blo
ck I
d 1
Blo
ck I
d 3
Blo
ck I
d 2
Blo
ck I
d 4
Blo
ck I
d 2
Blo
ck I
d 3
Blo
ck I
d 4
Blo
ck I
d 4
PutBlob (name);PutBlock(BlockId1);PutBlock(BlockId3);PutBlock(BlockId4);PutBlock(BlockId2);PutBlock(BlockId4);PutBlockList(BlockId2, BlockId3, BlockId4);
Block Blobs: example
![Page 20: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/20.jpg)
20
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
![Page 21: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/21.jpg)
21
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
![Page 22: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/22.jpg)
22
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
![Page 23: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/23.jpg)
23
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)
![Page 24: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/24.jpg)
24
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
![Page 25: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/25.jpg)
25
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
![Page 26: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/26.jpg)
26
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
![Page 27: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/27.jpg)
27
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
![Page 28: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/28.jpg)
28
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)
![Page 29: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/29.jpg)
29
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
![Page 30: Jimmy Narang 1. 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](https://reader030.vdocument.in/reader030/viewer/2022032604/56649e665503460f94b6072f/html5/thumbnails/30.jpg)
30
Azure: SDK and devFabric• <DEMO>