1 / 21

Application Models for utility computing

Application Models for utility computing. Ulrich ( Uli ) Homann Chief Architect Microsoft Enterprise Services . Session Objectives And Takeaways. Highlight the looming energy crisis in the data center Understand the application designers role in reducing energy consumption

dava
Télécharger la présentation

Application Models for utility computing

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Application Models for utility computing Ulrich (Uli) Homann Chief Architect Microsoft Enterprise Services

  2. Session Objectives And Takeaways • Highlight the looming energy crisis in the data center • Understand the application designers role in reducing energy consumption • Understand how virtualization can support you in going Green

  3. “Sins” of our fathers

  4. Synchronicty is Dead

  5. “Success” - a design tenet

  6. SOYP – capacity planning methodology

  7. Application architects – Belts-and-suspenders people?

  8. Solution approaches

  9. Constraint based planning Energy Spend • You can: • Increase DC count • Hold # DC • Decrease # DC • With a corresponding • Increase Capacity • Hold capacity steady • Decrease Capacity Service Units Available Service Units Consumed • You can: • Increase DC size • Hold DC Size • Decrease DC size • With a corresponding • Increase power $$ • No change • Increase flexibility at a cost of faster to full Data Center #’s of DC’s Key lesson: Servers use vital resources whether on or off

  10. Where does capacity go? Data Center Reserved Capacity Safety Margin Waste Planned Capacity Limit Benefit Application design most effectively impacts waste % Overhead “Run It Full”

  11. A Responsible Dynamic Topology? SQL ASP ASP ASP ASP ASP IIS IIS IIS IIS IIS

  12. Segment your solution Service Model <ITService> <Site> <Server Group> Simple topology view <Server> <ServerRole>

  13. Server (workload) segmentation • Server Groups manage like servers (workloads); • Today Server Groups are static – numbers of instances are effectively fixed; • Enable your solutions and deployment to allow the infrastructure to reduce and increase the numbers of servers in any given server group at any given time; The term “server” doesn’t mean what it used to anymore!

  14. Server Role segmentation • Introduce Server Roles as part of your solution • Going from component to Services is not granular enough • Group related functionality in Server Roles • E.g. Payrolls, general ledger • Plan your Services deployment with Server Role isolation in mind • Allow the infrastructure to dynamically start and stop server roles (deployed as VM’s)

  15. Start slow and grow in ‘scale units’ • Pete’s SharePoint order (representing max growth): • 50,000 users • 20,000 team sites • 150MB/site • Responses per second: 100 • Monitoring counters in the operational configuration and monitoring environment (SC OM 2007) trigger growth (or shrink) provisioning once the specific capacity driver hits 80% of specified value: • Growth based upon RPS (growth type A): initial size – 99 RPS; counter is set to 80 RPS • Growth based upon content db size (growth type B): initial size – 0.8 TB; counter is set to 0.7 TB

  16. Projected Load Profile

  17. Load by Time of Day

  18. Enable Virtualization and "Run Full" • Decompose application into work loads (servers) that can be dynamically scheduled • Break dependencies between your product’s services • Allow customers to pick time of day, day of week, etc, and allocate capacity of individual parts dynamically • If one server role is “out” right now, application should not break • Define scale units for your server roles so that they can be reduced in size to a minimal level and grown in chunks • Application server roles should not break if resources get allocated by quota by application role • (20% CPU for you, 60% for you) • Monitoring can no longer assume all parts are “on” at all times. • Server roles become dependency bound for scheduling of parts that need to run together. • If inseparable parts, put in same server role, deploy in same image • Break up the work types that your application does so they can operate out of band over units of time • Synchronicity (scale out) is not by server. It is by virtual server image. • Parts communicate across images

  19. Resources • Green Computing Architecture Journal: http://msdn.microsoft.com/en-us/architecture/dd393308.aspx • Specific article about app patterns: http://msdn.microsoft.com/en-us/architecture/dd393307.aspx

  20. © 2008 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.

More Related