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. What is going on?

4. About that energy bill Server power is small part of overall bill CPU $$ is less than 1% of total – Trend is towards more efficient CPU, – Lower rack power densities (amps/foot 3 ) on horizon Driven by low power, multi-core CPU’s Disk is more complicated – Mass storage consumes more than CPU, Fan, Memory, Face drives combined – Keeping DB on line all the time consumes more than all CPU’s involved Big power spend is cooling Bottom Line – Turning off servers doesn’t get you much $$ power savings in DC – Today – critical resources are AMPS available to be used Floor space available Cooling capacity – Net result DC’s are always full to capacity – Plenty of data to process Scale unit is full DC – Server power consumption is not the issue – Virtualization wins will be around throughput optimization Optimizing the way your applications use available resources Use the capacity you have more efficiently Slow or stop your DC growth

10. Solution approaches

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

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

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

15. Segment your solution Service Model Simple topology view

16. 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;

17. 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)

18. Start slow and grow in ‘scale units’ Initial Size 2 SharePoint App Servers 1 SQL Server Growth Unit A Capacity Driver: # of users +1 SharePoint Application Server Growth Unit B Capacity driver: content db size +1 SQL Server Max Growth 4 SharePoint App Servers 2 SQL Server Pete’s SharePoint order (representing max growth): - 50,000 users - 20,000 team sites - 150MB/site - Responses per second: 100 Farm configuration RPS 2 by 199 Farm configuration RPS 4 by 2120 Farm configuration RPS 3 by 1115 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

19. Projected Load Profile

20. Load by Time of Day

21. 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

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

23. © 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.