Inside Windows Azure Storage Name Title Microsoft Corporation

Geographically Distributed across 3 Regions Thousands of services/applications Anywhere at Anytime Access to your data Durability and Scalability 70 Petabytes raw storage today Grows to >200 Petabytes by start of 2012

Telemetry for Kinect Game Saves in Cloud Microsoft Zune Media Storage and Delivery Facebook and Twitter Near Real-Time Search

Bing Realtime facebook/twitter search ingestion engine Bing Ingestion Engine (Azure Service) VM Windows Azure Queues Index Facebook/Twitter data within 15 seconds of update Windows Azure Tables User postings Status updates ………… peak 40,000 Requests/sec 2~3 billion Requests per day Took 1 dev 2 months to design, build and release to production

What’s new for Blobs, Tables and Queues

Abstractions Blobs File system in the cloud Tables Massively scalable structured storage Queues Reliable storage and delivery of messages Drives Durable NTFS volumes for Windows Azure applications

User creates a globally unique storage account name Choose the primary location to host storage account

Account Table Entities Queue Messages Container Blobs

A highly scalable and durable file system in the cloud

Windows Azure Tables – What is new? Insert entity Update entity Merge Replace Delete entity Query entity Entity Group Transactions Query Projection ($select) Project only selected columns Upsert Entity InsertOrReplace InsertOrMerge

Windows Azure Tables - Projection public class Customer { public string PartitionKey { get; set; } // Customer Name public string RowKey { get; set; }// Customer Phone Number public DateTime CustomerSince { get; set; } public double TotalPurchase { get; set; } public string State { get; set; } // 100 more properties including profile picture etc.… } // Partial entity defined here public class CustomerDiscount { public string PartitionKey { get; set; } public string RowKey { get; set; } public double TotalPurchase { get; set; } }

Windows Azure Tables - Projection

Windows Azure Tables - Upsert

Provides reliable message delivery Programming semantics – Ensures that a message can be processed at least once Put message into the queue Get message makes the message invisible in queue for a specified invisibility timeout Delete message once done processing to remove message from queue If worker crashes, message becomes visible for another worker to process

Azure Queue Work items Web Role Worker Role Current time 7:00 Get Message with 5 minutes visibility timeout 7:05AM 7:04 Extend visibility timeout with another 5 minutes 7:09AM Periodically store progress information in message content 7:07 7:09 Retrieve progress from queue message and resume

Windows Azure Storage Analytics

Goal Capabilities Enable customers to understand and debug their usage of storage

Provides ability to answer commonly asked questions: Did a specific request make it to the storage service and how long did it take? What Client IP issued a “Delete container” request and when? How many requests were issued by a specific client or to a specific set of objects? list goes on and on…

The following are some of the fields logged for each record: Log Version Accessing Account Owner Account Service Type Request URL Object Key Request ID Operation Number Request Version Operation Type Start Time Application End to End Latency Storage Server Latency Authentication Type Request Status HTTP Status Code Client IP User Agent Referrer Client Request ID ETag LMT Request Packet Size Request Header Size Response Packet Size Response Header Size Request MD5 Server MD5 Conditions Used

Log Entry Example Log Version: 1.0 Start Time: T18:02: Z Operation Type: PutBlob Status: Success HTTP Status Code: 201 Application E2E Latency (milliseconds): 28 Storage Server Latency (milliseconds): 21 Accessing Account: sally Owner Account: sally Service Type: blob Request URL: PUT Object Key: /sally/thumbnails/lake.jpg Request ID: fb658ee f5-81e2-4bfdc178fea3 Operation Number: 0 Request Version: Client IP: Client Request ID: req12345 Log Entry in Blob: 1.0; T18:02: Z;PutBlob;Success;201;28;21;authenticate d;sally;sally;blob;" s/lake.jpg?timeout=30000";"/sally/thumbnails/lake.jpg";fb658 ee f5-81e2-4bfdc178fea3;0; ; ;438;100;223;0;100;;"66CbMXKirxDeTr82SXBKbg==";"0x8CE 1B67AD25AA05";Thursday, 28-Jul-11 18:02:40 GMT;;;;"req12345“

Provides ability to answer commonly asked questions: How many transactions did my service issue per hour over the past week? How many anonymous Get Blob requests were issued to my storage account? My application is not performing as expected, what is the availability and performance of storage for a given time period? list goes on and on…

Client application running in cloud start experiencing slow table access Compare Application E2E latency with Storage Server latency Storage Server Latency Application E2E Latency

Total Transactions

Logs Stored as blobs in separate Blob Container in the storage account being monitored Metrics Stored as entities in a separate metrics Azure Tables in the storage account being monitored Isolation $logs and $Metrics have separate resource limits and throttling from the rest of the storage account traffic

Geo-Replication

East Asia South East Asia Europe West North Europe South Central US North Central US Geo-replication

North Central US Azure DNS DNS lookup Data access HostnameIP Address account.blob.core.windows.netNorth Central US Failover Update DNS South Central US Existing URL works after failover Failover Trigger – failover would only be used if primary could not be recovered Asynchronous Geo-replication – may lose recent updates during failover Typically geo-replicate data within minutes, though no SLA guarantee Geo-replication South Central US

Windows Azure Storage Internals

Design Goals Highly Available Storage with Strong Consistency Provide access to data in face of hardware failures Durability Replicate data several times within and across data centers Scalability Need to scale to exabytes and beyond Automatically load balance data to meet peak traffic demands Provide a global namespace to access data around the world Additional details can be found in this white paper: “Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency”, ACM Symposium on Operating System Principals (SOSP), Oct

Storage Stamp LB Storage Location Service Access blob storage via the URL: Data access Inter-stamp (Geo) replication Partition Layer Front-Ends DFS Layer Intra-stamp replication Storage Stamp LB Partition Layer Front-Ends DFS Layer Intra-stamp replication

M DFS Servers Paxos M M Distributed File System (DFS) Layer

Partition Server M Paxos M M Partition Server Partition Server Partition Server Partition Master Lock Service Partition Layer DFS Layer DFS Servers

Partition Server M Paxos Front End Layer FE M M Partition Server Partition Server Partition Server Partition Master FE Lock Service Partition Layer DFS Layer DFS Servers

Partition Server M Paxos Front End Layer FE Incoming Write Request M M Partition Server Partition Server Partition Server Partition Master FE Lock Service Ack Partition Layer DFS Layer DFS Servers

Account Name Container Name Blob Name aaaa aaaaa …….. zzzz zzzzz Storage Stamp Partition Server Partition Server Account Name Container Name Blob Name richardvideostennis ……… zzzz zzzzz Account Name Container Name Blob Name harrypicturessunset ……… richardvideossoccer Partition Server Partition Master Front-End Server PS 2 PS 3 PS 1 A-H: PS1 H’-R: PS2 R’-Z: PS3 A-H: PS1 H’-R: PS2 R’-Z: PS3 Partition Map Blob Index Partition Map Account Name Container Name Blob Name aaaa aaaaa ……… harrypicturessunrise A-H R’-Z H’-R

DFS Layer Partition Server 1 Partition Server 2 Partition Server 3 Partition Server 4 - RangePartition - Server Load Legend PM

1.Scalability targets of a single storage account 2.Scalability targets for Blobs, Table Entities and Queues within a storage account

Scalability targets of a single storage account Account Scalability Targets Capacity – Up to 100 TBs Transactions – Up to 5000 entities per second Bandwidth – Up to 3 gigabits per second Partition data across storage accounts to go beyond these targets

Scalability targets for Blobs, Table Entities and Queues within a storage account Single Blob – up to 60MBytes per second Single PartitionKey in a Table – up to 500 entities per second Single Queue - up to 500 messages per second

Feedback and questions Session feedback

Thank You

© 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.