Application Models for utility computing

Ulrich (Uli) HomannChief ArchitectMicrosoft Enterprise Services

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

“Sins” of our fathers

Synchronicty is Dead

“Success” - a design tenet

SOYP – capacity planning methodology

Application architects – Belts-and-suspenders people?

Solution approaches

Constraint based planningSe

rvic

e U

nits

Ava

ilabl

e

#’s of DC’s

You can:• Increase DC count• Hold # DC• Decrease # DC

•With a corresponding• Increase Capacity• Hold capacity steady• Decrease Capacity

Key lesson: Servers use vital resources whether on or off

DataCenter Se

rvic

e U

nits

Con

sum

ed

Energy Spend

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

Where does capacity go?

Data CenterBenefit

Planned Capacity Limit

Safety MarginReserved Capacity

Overhead

Waste

Application design most effectively impacts waste %

“Run It Full”

A Responsible Dynamic Topology?

SQL IIS IIS ASP ASP

IIS ASPIIS

IIS

ASP

ASP

Windows packaging taxonomyComponent

Feature

Workload

Solution

Product

Component Component

Feature

Role

Component

Feature

Role Role

Workload

-Reusable, self-describing unit of testing, distribution and servicing

Product building block which, in combination with other features or components, delivers a set of functionality

Composition of features that forms the unit of management (deployment, update, etc)

Composition of often related roles that run together on a server or set of servers

–A set of integrated workloads that together address a specific problem for a targeted customer segment

–A SKU or solution packaged as a product

Segment your solution

<ITService>

<Server Group>

<Server>

<ServerRole>

Service Model

<Site>

Simple topology view

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’

Initial Size

• 2 SharePoint App Servers

• 1 SQL Server

Growth Unit ACapacity Driver: # of users

• +1 SharePoint Application Server

Growth Unit BCapacity 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 1 99

Farm configuration

RPS

4 by 2 120

Farm configuration

RPS

3 by 1 115

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

Projected Load Profile

Jan Mar

May Ju

lSe

pNov

Jan Mar

May Ju

lSe

pNov

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

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

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