fit for purpose platform architecture selection and design...fit for purpose platform architecture...
Post on 07-Jul-2020
7 Views
Preview:
TRANSCRIPT
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
top related