INDIA September 2011 virtual techdays

Transcription

1 Building highly Available Services on Windows Azure Platform Pooja Singh Technical Architect, Accenture Aakash Sharma Technical Lead, Accenture Laxmikant Bhole Senior Architect, Accenture

2 Assumptions You know the basics of Web/Worker roles SQL Azure Windows Azure Storage Windows Azure Diagnostics

3 S E S S I O N A G E N D A Topics Understand Availability Causes for unavailability What you get with Azure What you do on your own Guiding Principles Audience Developers & Architects community People with high available services needs Takeaway Windows Azure inherent attributes for building highly available services Architectural expectations for building highly available services

4 How do you define Availability What is acceptable Downtime What happens in case of failure All functionality required to be available? Degraded functionality to be available Failsafe Acceptable Performance

5 Cost of building highly available services Unavailability Vs High Availability Cost & Complexity Availability

6 INDIA September 2011 Implementation costs for a new project Implementation cost for a startup company that offers its software as a service with a hosting company. Traditional Azure 6

7 Causes for unavailability Increase in workload Non-scalable architecture Poor performance Platform Failures Upgrades Failure Hardware Network Transient conditions

8 What you get with Azure

9 Azure to rescue

10 Azure monthly service level agreement

11 Azure out-of-box features Elasticity Scale up/down compute resources on-demand Self Service Management Self recovery for nodes Fault Domains Storage Resilience 3 copies of storage Geo Replication Built-in network redundancy

12 What you need to do

13 Design for Increased Load

14 Is this Scalable? Web Role Instance 1 Load Balancer Web Role Instance 2 Web Role Instance 3 SQL Azure Web Role Instance 4

15 Is this Scalable? Web Role Instance 1 Web Role Instance 2 SQL Azure Load Balancer Queue Worker Role Instance Worker 1 Role Instance 2 Table storage Blob storage

16 Design for Scalability Use loosely coupled nodes Design for redundancy Scale OUT everything Better to have 50 one GB databases than one 50 GB database Test at scale

17 Design for Performance Service and data closer to user Same data center to avoid network latency CDN Caching Be mindful of the throughput and transaction thresholds Auto-scaling

18 How CDN works Contents closer to end-users 24 physical nodes globally CDN works for web apps & public blobs CDN Region A Users in Europe Azure Storage Copy of Blob A Blob A CDN Region B Users in Asia Copy of Blob A

19 Decide Upgrade Strategies

20 Upgrade Strategies VIP Swap New Service and DNS swap Upgrade Domains

21 How does upgrade domain work? Load Balancer DNS Myservice.Cloudapp.net Myservice v1 Myservice v2 Myservice v1 Myservice v2 Myservice v1 Myservice v2

22 Handle Failure

23 Fault Tolerance Self recovery Can your Service fix itself? Transaction & Recovery Loosely coupled Transaction rollback and recovery Network Failures Retry Logic

24 What is Retry logic? When - Network failure or transient conditions Service is temporarily unavailable E.g. SQL Azure Error The service is currently busy. Retry request after 10 seconds. What - Retry for any external connections SQL Azure Windows Azure Storage Service Bus Any external service How - Use RetryPolicy class or Transient Fault Handling Framework NoRetry Retry RetryExponential

25 Retry Code Example

26 Disaster Recovery

27 Disaster Recovery Backups Fault Domain Geo-replication Traffic Manager Performance Round Robin Failover

28 How Traffic Manager works Policies Performance Use when geo-distributed services Round Robin Failover Monitoring Large user base Small user base

29 Traffic Manager Performance Policy Decide which data center to connect East Asia DC Myservice-ea.cloudapp.net Myservice DNS myservice.com Policies Traffic Manager Monitoring North Europe DC Myservice-ne.cloudapp.net Myservice North Central U.S. DC Myservice-ncus.cloudapp.net Myservice

30 Load Test, Diagnostics & Monitoring Load test your service Visual Studio 2010 Ultimate Load Tests Diagnostics Windows Azure Diagnostics Service Management APIs Storage Management APIs CSS SQL Azure Diagnostics Monitoring Visual Studio profiling tools Windows Azure Management pack for SCOM

31 Guiding Principles

32 Guiding Principles Use loosely coupled roles Use of queues promotes loose coupling Handling fault tolerance Recover from fault Handling scalability in architecture Design for scalability Run multiple instances of each role Availability in case of role failure

33 Guiding Principles Design and code for instance failure Imbibe redundancy Monitor everything Take feedback to recover fast Load test Fail fast

34 References

35 THANKS September 2011 Please do give your Feedback, Complete evaluation at the end of this session. You could also write to be at : Laxmikant.Bhole@accenture.com