Fit For Purpose Platform Architecture Selection and Design

Joe Temple IBM (jliitemp@us.ibm.com)

Aug 6, 2012 AM Session

11853

What is Fit for Purpose (F4P)?

Fit for Purpose is a client centric thought process that when applied, yields infrastructure architecture decisions which are in line with the client’s

requirements and local conditions.

It is based on the fundamental principles that “one size does not fit all” and that “local factors matter.”

System z

System x

Power

Time Horizon ISV Support

Non-functional Requirements

Environmental Constraints

Strategic Direction

TCO Model Skills

Politics

Architecture

Technology Adoption

Deployment Model

Scale

Geographic Considerations

A Client’s Decision Matrix

Data integrity/value

Compute / Memory intensity

High

Medium

Transaction volumes

Availability

Longevity of solution

Recovery

Cost of acquisition

3 to 5 years

Low

High

Low Medium

High

Medium

Low Low

X86

Medium

Medium

High

z

Data volumes High

Medium

Low

Low

Medium

High

Low

> 5 years

High

Know the current IT Environment

Understand the workload

Examine costs

Know the legacy, workload, and costs

Fit for Purpose Categorized Workloads

Mixed Workload – Type 1 • Scales up • Updates to shared data

and work queues • Complex virtualization • Business Intelligence

with heavy data sharing and ad hoc queries

Parallel Data Structures – Type 3

Small Discrete – Type 4

Application Function Data Structure Usage Pattern SLA Integration Scale

Highly Threaded – Type 2

• Scales well on clusters • XML parsing • Buisness intelligence

with Structured Queries • HPC applications

• Scales well on large SMP

• Web application servers • Single instance of an

ERP system • Some partitioned

databases

• Limited scaling needs • HTTP servers • File and print • FTP servers • Small end user apps

Black are design factors Blue are local factors

1

2

Using Pfister’s paradigm we can map the workload types to our existing platforms and new platforms we build as a result of a WOS study

795

p775

Pfisters Paradigm and the Trends

Sing

le T

hrea

ded

Wor

k

Data Load

Con

tent

ion

and

Coh

eren

ce

Saturation

Parallel Nirvana

Parallel Hell

Parallel Purgatory

Que

ry L

oads

Scaled up OLTP and “Mixed” Loads S

ingle Threaded

Loads

with clustering and replication w

ith d

ata

upda

tes w

ith structure

There is a clear trade off at work here: §  To have more threads you must give up thread speed and cache/thread §  Machine capacity metrics govern how that tradeoff is made. In turn the

metrics are designed for the “style” of computing used by each machine’s base market.

Workload Optimization 8 Socket MachinesBubble Size is Parallel Fitness - Thread Count

0

0.5

1

1.5

0 0.5 1 1.5

Data Fitness - Cache/Thread

Ser

ial F

itnes

s - C

lk *

S

MT

Take

Dow

nz196p780 STp780 SMT2p780 SMT4p780T STp780T SMT2p780T SMT4X7560 STX7560 HTX7542

”

Workload Optimization

0"

0.2"

0.4"

0.6"

0.8"

1"

1.2"

)0.5" 0" 0.5" 1" 1.5"

Thread

'Spe

ed'

Cache/Thread'

'Socket'Designs'in'Fitness'Space'Bubble'Size'is'threads'

Super"Cluster"

Exadata"2)2"

Exadata"8)2"

Power"780"SMT4"

Power"780T"SMT2"

Power"780T"ST"

z196"

Sandy"Bridge"

Throughput and Capacity Relating Fitness to workloads

•  We observe:

Throughput ~ Thread Count x Thread Speed

•  Also:

Thread Capacity ~ Cache / Thread x Thread Speed

•  We Assert:

Performance ~ Thread Capacity and Throughput

•  We Define:

Performance = w(Thread Capacity) +(1-w)(Throughput)

Capacity is a weighted average of Thread Capacity and Throughput

Machines have different Throughput and Thread Capacity

Note that Very High Throughput à Very Low Thread Capacity (and Vice Versa)

Therefore to achieve Very High Throughput workload must have Very Low Weight

0"

0.1"

0.2"

0.3"

0.4"

0.5"

0.6"

0.7"

0.8"

0.9"

1"

0" 0.2" 0.4" 0.6" 0.8" 1"

Super"Cluster"

Exadata"2:2"

Exadata"8:2"

Sandy"Bridge"

Power"780"SMT4"

Power"780T"SMT2"

Power"780T"ST"

z196"

Envelope"

Single Core Relative Capacity

Note that relative capacity is not linear with weight.

0"

1"

2"

3"

4"

5"

6"

7"

8"

9"

0" 0.2" 0.4" 0.6" 0.8" 1" 1.2"

Sand

y&Bridge&Core&pe

r&Core&

weight&

Sandy"Bridge"

Power"7"ITE"

Power"7"

Power"7T"

z196"

Local factors take the form of Operational Trade offs

•  Operations governed by “Normalized Headroom”

•  HR = (1-u)/u = c2Nt0/twait

•  HR(avg) = kcN2 => (SLA)(Variability)(Scaling)

•  U = 1/(1+HR)

•  t = t0 + twait

•  twait = (t0)(c2N)(u/(1-u)) = (t0)(c2N)/HR = (1/weighted capacity)(variability)(scaling)/HR

M/G/1 system

T0 ~ 1/Capacity

What are you Optimizing?

IBM Integrated Systems cover the fitness space and key legacies Fi

tnes

s fo

r sin

gle

thre

aded

wor

k

Fitness for Data Centric Work

z/OS® Linux®

i5/OS™ Linux AIX

Windows AIX Linux Solaris™

System x5™

3850

Windows Linux Solaris™

IBM BladeCenter™

Power775™

Con

tent

ion

and

Coh

eren

ce

Saturation

New Nehalem Scalable Blades

Windows Linux Solaris™

Windows AIX Linux Solaris™

Choose based on Fit

zEnterprise

Pure Systems

Enterprise Power

Federation bridges gaps and also avoids stretching processor brands

System x5™

3950

Exadata SC

Positioning with Throughput and Thread Capacity

!Thread

Today Pure Systems is a match for workloads with lower weight.

SC