High Level Overview of Windows Azure - EPC Group
1 like789 views
The document discusses the architecture of Windows Azure SQL Database and Windows Azure Table Storage. It describes four layers - client, services, platform, and infrastructure - for SQL Database. For Table Storage, it covers key concepts like entities, partitions, queries with no fixed schema, and how tables are designed for scalability with partitions and transaction support within partitions.
![Application Connectivity
Considerations And Best Practices
•
login: [login]@[server]
•
Idle connections
•
Long running transactions
•
DoS guard
•
Failover events
•
Throttling
•
Connection pooling and Retry logic
•
Latency introduced for updates
•
No cross-database dependencies](https://image.slidesharecdn.com/highleveloverviewofwindows-epcgroup-140107144649-phpapp02/85/High-Level-Overview-of-Windows-Azure-EPC-Group-5-320.jpg)
More Related Content
![[WSO2Con EU 2017] WSO2 Unleashed: Full Stack Automation, Pitfalls and Solutions](https://cdn.slidesharecdn.com/ss_thumbnails/fiot-final-171107115910-thumbnail.jpg?width=560&fit=bounds)
Similar to High Level Overview of Windows Azure - EPC Group (20)
![Creation of cloud application using microsoft azure by vaishali sahare [katkar]](https://cdn.slidesharecdn.com/ss_thumbnails/creationofcloudapplicationusingmicrosoftazurebyvaishalisaharekatkar-170316091730-thumbnail.jpg?width=560&fit=bounds)
More from EPC Group (20)
High Level Overview of Windows Azure - EPC Group
- 3. Client Layer - Used by application to communicate directly with SQL Database. • Services Layer – Gateway between Client layer and Platform layer. • Platform Layer – Includes physical servicers and services that support the Services layer. • Infrastructure Layer – IT administration of the physical HW and OS. •
- 4. Topics to Review • Windows Azure SQL Database • Architecture Application Connectivity Scalability • • Architecture Querying • • • Windows Azure Table Storage • • • Best Practices and Considerations Cost Transactions
- 5. Application Connectivity Considerations And Best Practices • login: [login]@[server] • Idle connections • Long running transactions • DoS guard • Failover events • Throttling • Connection pooling and Retry logic • Latency introduced for updates • No cross-database dependencies
- 6. A Seamless Offering from the Private Cloud to the Public Cloud
- 7. Scalability Model For The Cloud Cloud Applications Require Scale Beyond Scale-Up Demand the Best Economics • • • • Best Price/Performance Elasticity + Pay-as-you-go
- 8. Obstacles • • • • • • Defining the Tenant Establishing Tenant’s surrogate key Elastic Scalability (Splits/Merges/Tenant Moving) Application Lifecycle Management (Dev; Test; Deploy; Upgrades) Overcoming limitations of existing tools & available features Transient nature of connectivity
- 13. No Fixed Schema
- 14. Querying
- 15. Purpose of the PartitionKey Entity Locality • Entities in the same partition will be stored together Efficient querying and cache locality • Endeavour to include partition key in all queries • Entity Group Transactions • Atomic multiple Insert/Update/Delete in same partition in a single transaction Table Scalability • • • Target throughput – 20,000 tps/partition, several thousand tps/account Windows Azure monitors the usage patterns of partitions Automatically load balance partitions • • Each partition can be served by a different storage node Scale to meet the traffic needs of your table
- 16. Partitions and Partition Ranges PARTITIONKEY (CATEGORY) ROWKEY (TITLE) TIMESTAMP MODELYEAR Bikes Super Duper Cycle … 2009 Bikes Quick Cycle 200 Deluxe … 2007 … … … … Canoes Whitewater … 2009 Canoes Flatwater … 2006 Rafts PARTITIONKEY (CATEGORY) … 14ft Super ROWKEY Tourer (TITLE) … … TIMESTAMP … 1999 MODELYEAR … Rafts Skis … … 1999 2009 … … … … Skis Tents 14ft Super Tourer Fabrikam Back Trackers … … Fabrikam Back Super Palace Trackers … … 2009 2008 … … … … Tents Super Palace … 2008 … …
Editor's Notes
- #11: Here we can see that the Front-End layer takes incoming requests, and a given front-end server can talk to all of the partition servers it needs to in order to process the incoming requests. The partition layer consists of all of the partition servers, with a master system to perform the automatic load balancing (described below) and assignments of partitions. As shown in the figure, each partition server is assigned a set of object partitions (Blobs, Entities, Queues). The Partition Master constantly monitors the overall load on each partition sever as well the individual partitions, and uses this for load balancing. Then the lowest layer of the storage architecture is the Distributed File System layer, which stores and replicates the data, and all partition servers can access any of the DFS severs.It is important to understand that partitions are not tied to specific partition servers, since the data is stored in the DFS layer. The partition layer can therefore easily load balance and assign partitions to different partition servers, since any partition server can potentially provide access to any partition.The partition layer assigns partitions to partition severs based on each partition’s load. A given partition server may serve many partitions, and the Partition Master continuously monitors the load on all partition servers. If it sees that a partition server has too much load, the partition layer will automatically load balance some of the partitions from that partition server to a partition server with low load.