Application models for utility computing Ulrich Uli Homann

Application models for utility computing Ulrich (Uli) Homann Chief Architect, WW Enterprise Services Microsoft Corp. Session Code: ARC 307

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

Will your Data Centers be Rated by the Government? Congress Passed Public Law 109 -431 Outcome: EPA Energy Star Program • Energy Star for Servers May 2009 release Dec 2006 Jan 2010 release EPA to study and promote IT Efficiency • Energy Star for DCs EPA provided response August 2007 http: //www. energystar. gov/index. cfm? c=prod_development. server_efficiency http: //www. energystar. gov/ia/partners/prod_development/downloads/EPA_Datacenter_Report_Congress_Final 1. pdf 4

Why the Government Cares? In the US: Capacity Growth = 0. 8%/yr Usage Growth = 1. 1%/yr DC Growth = 15%/yr Today in US 1. 8 to 2. 0% US Projections: 2020 10% 2030 30 -40% 5

All of this Drives Costs - Data Center Economics have Changed! Microsoft‘s Annualized Costs Ops DC Energy Belady, C. , “In the Data Center, Power and Cooling Costs More than IT Equipment it Supports” Electronics Cooling Magazine (Feb 2007) 6 IT

Where Data Center Power Goes Utility Load PUE = --------- = 2 IT Load Source: EYP Mission Critical Facilities Inc. , New York Microsoft is focusing on all the pieces of the pie 7

“Sins” of our fathers From an application development perspective

Synchronicty is Dead

“Success” - a design tenet

SOYP – capacity planning methodology

Solution approaches

Constraint based planning Data Center You can: Service Units Consumed Service Units Available Energy Spend • Increase DC count • Hold # DC • Decrease # DC • With a corresponding • Increase Capacity • Hold capacity steady • Decrease Capacity 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 #’s of DC’s Key lesson: Servers use vital resources whether on or off

Trends in DC design Configuration & Construction Modularize the Data Center Use the same kit of parts in pre-manufactured modules Solution to accept racks, skids or containers Redundancy & Reliability customized to each DC Class Facility to accommodate Variable Power Density Cost Reduce capital cost/MW by Class Leverage industry to drive down initial & operating costs Time To Market - Move to lowest $ Cost DC investment Data Center Facility delivered with the servers >ROIC – return on invested capital Sustainability Lowest yearly average PUE in the Industry 2008 < 1. 5, 2010 < 1. 25, 2012 < 1. 125 Calculate TCOE not just operational efficiency Initiative to reduce building, copper, water Drive to Chiller-less data centers and aggressive outside economization

Next Gen DC - Key Characteristics üModular üScalable üPlug-and-play infrastructure üFactory pre-assembled PACs & PMBs üRapid deployment üDemountable ü"Fail Small“ üReduce TTM üReduced construction üSustainable measures Pre-assembled containers (PAC) Pre-manufactured buildings (PMB)

A Responsible Dynamic Topology? P AS IIS IIS L SQ IIS P AS

Key transformation elements Approach: • Modular • As-needed reliability • As-needed maintainability • Manufacturing-oriented • Services-based ‘Traditional’ New Space Watts Per layer thinking Integrated systems Monolithic Modular Network-centric Custom Standard ‘Free-form’ variability Managed variability (product line approach)

Services-based approach Saa. S • Deployed software operates as service • Applications run on standardized ‘hosts’ – Share. Point, etc Paa. S • Standardized platform services • Windows Azure Services platform as possible template Iaa. S DCaa. S • Resource-pool based model for physical resource (compute, storage, network) • Virtualized environment (goal: 100%) • Modular dc build out strategy • Possible Op. Ex model with partners

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

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!

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)

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

Jan feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Projected Load Profile

Load by Time of Day 0 2 4 6 8 10 12 14 16 18 20 22 24

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

question & answer

Resources www. microsoft. com/teched www. microsoft. com/learning Sessions On-Demand & Community Microsoft Certification & Training Resources http: //microsoft. com/technet http: //microsoft. com/msdn Resources for IT Professionals Resources for Developers

Complete an evaluation on Comm. Net and enter to win an Xbox 360 Elite!

© 2009 Microsoft Corporation. All rights reserved. Microsoft, 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.