ASZ-3034 Build a WebSphere Linux Cloud on System z: From Roll-Your-Own to Pre-Integrated

© 2015 IBM Corporation
Build a WebSphere Linux Cloud on System z:
From Roll-Your-Own to Pre-Integrated
Stephen Kinder – BlueMix Runtime Sr. Architect IBM
Tom Seelbach – WebSphere Architect and Advocate IBM
ASZ-3034

Please Note
IBM’s statements regarding its plans, directions, and intent are subject to change
or withdrawal without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general
product direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a
commitment, promise, or legal obligation to deliver any material, code or
functionality. Information about potential future products may not be incorporated
into any contract. The development, release, and timing of any future features or
functionality described for our products remains at our sole discretion.
Performance is based on measurements and projections using standard IBM
benchmarks in a controlled environment. The actual throughput or performance
that any user will experience will vary depending upon many factors, including
considerations such as the amount of multiprogramming in the user’s job stream,
the I/O configuration, the storage configuration, and the workload processed.
Therefore, no assurance can be given that an individual user will achieve results
similar to those stated here.
1

About the Speakers
 Stephen Kinder
– Bluemix Runtime Sr. Architect, WAS Hypervisor Edition Chief Architect
•Steve has been appointed a senior member of IBM's technical staff and an architect on the
Bluemix runtime team. In addition, leads WebSphere Hypervisor Edition and virtualization
development for WebSphere Application Server. He has 25 years of middleware and operating
systems development experience..
kinder@us.ibm.com @StephenKinder 845-435-4854
 Tom Seelbach
– WebSphere Architect and Advocate
•Tom is a WebSphere developer and architect, working on WebSphere clustering. He has a
special interest in virtualization and very large scale WebSphere topologies running on leading
edge platforms.
seelbach@us.ibm.com @tsee
2

Abstract
Do you need the most reliable, secure, and cost-effective on-premise cloud platform? Look no further:
a cloud based on WebSphere and Linux on System z is the answer. This session traces the evolution
of successful server consolidation to Linux on System z, from brute-force physical moves to virtual
topology to sophisticated workload placement. We'll cover techniques and considerations to ensure a
rich, dense, enterprise environment. The material is derived from interactions with our enterprise
mainframe customers running world-class data centers.
We will briefly describe the new Enterprise Cloud System that unites leading IBM software, storage,
and server technologies into one simple, flexible, and secure factory-integrated solution.
We will show examples of System z based cloud environments which provide everything you expect
from System z: extreme reliability, secure, geo-dispersed, high performance clouds. We will describe
application development and deployment patterns that both help and hurt in a virtualized cloud
environment. From the admin perspective we will explore heap and GC tuning, idle server tuning, and
stacking options. We will also present a very effective performance tuning approach for large scale
virtualized environments.
We also present Liberty profile performance in a virtualized environment, relative to a traditional
WebSphere application server.
3

Session agenda:
• System z
• Adjusting the programmer's perspective – Real vs Virtual
• WebSphere Idle Tuning and startup tuning
• Heap and GC tuning matter
• Avoid duplicate caches
• Don't underestimate the development environment
• Shared disk installation
• Re-think performance tuning
• Stacking options
• Liberty profile – a game changer for virtual environments
• Attracting good workloads to Z
• z13 and Trends in virtualization
4

Advantages of Deploying Clouds on System z
90%+ utilization
Increased
Productivity
100,000 virtual servers
Higher
Utilization
80% less energy
More Efficient Data
Center
Greater Reliability,
Availability
• Advanced workload
management that
provisions resources
on the fly for 90%+
utilization and
maximizes ROI
• U.S. Bank reduced
provisioning time from
45 days to 20 minutes
• 79% less TCA vs.
leading public cloud
• Up to 100% CPU
utilization
• “Shared everything”
architecture
• Manage up to 100,000
virtual servers
• Up to 80% less energy
than existing
distributed servers
• Less floor space
• Fewer parts to
manage
• Built-in hardware
redundancy
• Decades of RAS
innovation
• Capacity and Backup
on Demand
• Ultimate security
5 5

6
Z Systems has multi-layered virtualization built-in
- the most secure commercially available
6
Hardware-enforced isolation: 10% of circuits support virtualization
Software layer (z/VM)
provides support for large
number of of Linux
virtual servers
Firmware layer (PR/SM)
Coupled with RACF security
rated at EAL5+
- x86 hypervisors can’t
meet that
- Enables multiple VM
instances per server
- Guarantees workload
isolation
http://www-01.ibm.com/software/os/systemz/seminar/mainframe/handouts/ Unique innovations...pdf
IFL1 IFL2 IFL3CP1 CP2 CP3 CP4
IBM z Systems
Physical CPUs
LPAR1 LPAR2 LPAR3 LPAR4
Logical CPUs
IFL4
Memory
I/O and Network
…
z/OS
Workload
z/TPF
Workload
z/VM z/VM
Linux
Work
load
Linux
Work
load
Linux
Work
load
Linux
Work
load

Huge numbers of workloads can be run on a z Systems private
cloud
• Each z/VM instance can support many Linux virtual guests
• 10 TB memory and increase in number of LPARs (from 60 to 85) in z13
leads to even more workloads
• (Documented limit of the most popular x86 hypervisor is 512 virtual
machines per host)*
• Capacity on Demand allows addition of Linux cores temporarily to meet demand
• For large scale growth, z/VM clustering allows for up to 4 z/VM systems to be
clustered in a single system image
Live Guest Relocation
feature makes it easy
to move Linux virtual
servers to balance
workload across servers,
to group virtual servers
with dependencies,
or to more easily manage
maintenance
7
Cluster
Simplified cluster
management
Work
load
z/VM
Linux Linux
Work
load
Work
load
z/VM
Linux Linux
Work
load
z/VM
Linux Linux
Work
load
Work
load
z/VM
Linux
Work
load
Shared disks
and resources
Linux
Work
load
*http://www.vmware.com/pdf/vsphere5/r55/vsphere-55-configuration-maximums.pdf

Factors that make z Systems a cost effective
platform for private cloud computing
• Consolidation of many workloads drives system utilization to very high levels
virtually eliminating any wasted or idle resources
• CPU Pooling in z/VM allows for creation of a pool of CPU resources available
to a groups of virtual servers
• Allows for better management of resources
• Cost is managed across the
whole pool, allowing for better
cost per workload
• z13 with Simultaneous Multi-threading
means each Linux core can provide
more capacity at the same cost
8
z/VM informs PR/SM that it will exploit SMT
PR/SM dispatches as appropriate to physical cores
Each IFL thread is essentially an independent processor, so
each IFL has MORE capacity => more work can run per core
IFL IFL
Thread Thread Thread Thread
PR/SM
Physical Hardware
LPAR: z/VM
Wkld Wkld Wkld Wkld…

9
VM Comparison – Virtualization technology matters

10
z/VM 6.3 - Smarter Computing with Efficiency at Scale
• Better performance for large virtual machines
– 4x increase in memory scalability while continuing to maintain nearly 100% resource
utilization
• Reduce LPAR sprawl for additional horizontal scalabililty
– up to 4x more virtual machines in a single LPAR depending on workload
characteristics
• Reduced administrative expense for management of a smaller number
of large capacity z/VM host servers
Higher server consolidation ratio with support for more
virtual servers than any other platform in a single
footprint 2
Improved Performance with HiperDispatch
‒ Improved price performance as a result of higher and more efficient utilization of
CPU hardware resources1
Improving price performance with efficient dispatching of CPUs
Learn More: www.vm.ibm.com1 The performance boost expected with HiperDispatch depends on workload characteristics. Memory-intensive workloads running on
large numbers of logical processors (16 to 32) are most likely to achieve the highest performance gains.
2 Based on IBM internal measurements and projections.
Improved economies of scale with z/VM Support for 1TB of
Real Memory

System z I/O Architecture – Design Matters
11

Management of z/VM and Linux workloads is
simplified through use of Web-based graphical tool
• Intuitive GUI-based workspace
with powerful drag-and-drop
capability
• Automatically detects all
resources in the environment
• Simplifies and automates
management
• Monitors, provisions,
relocate guests, manages
user accounts
• Significantly reduces
administration requirements and
costs
IBM Wave virtualization management software
for z/VM and Linux on z Systems platforms
12
Multiple views all systems
in the configuration
Point and click interface

Session agenda:
• System z
• Adjusting the programmer’s perspective – Real vs. Virtual
13

Programmer's perspective on the “real server” world
Get programmers
to change their perspective
• On dedicated servers it “doesn’t matter” if the
application uses all the resources of the server
• “Real” server practices that hurt on virtualized systems:
• Extra CPU burned by an idling application, background process,
and/or redundant processing isn't wasted because other processes
can't use it anyway.
• Extra memory used because it’s dedicated, can't be shared anyway.
If the application doesn’t use it, memory will just sit there unused.
• No need to debug mem leaks – just reboot the world daily
– A twofer!!! extra memory used all day, and CPU burned on restart. Ugh
14

Programmer's perspective on the virtualized world
• Gone are the days of unlimited CPU and memory dedicated to a single
application.
• Applications need to be concerned with the impact on their hypervisor
neighbors.
• Virtualized Systems have cost advantages
• efficient use of CPU and memory, faster server provisioning, easier disaster
recovery, administration, lower power, space,cooling consumption
• SysAdmins will pack as many guests as possible into a single hypervisor
instance.
• See “Java Design and Coding for Virtualized Environments”
• http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102089
Kindergarten principles:
Share
Play nicely with others
Speak only when spoken to
15

Session agenda:
• System z
• WebSphere Idle Tuning and Startup Tuning
• z13 - Trends in virtualization
16

WebSphere idle tuning
• WebSphere Idle Tuning Guide:
• http://www-
03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101894
Goal: Prevent the App Server infrastructure from consuming CPU in the absence
of application workload
Why its important: Its not the CPU time, its the page hits !!!
• Idle servers don't touch pages, allowing VM to swap out the memory
• WebSphere is tuned by default for optimum throughput and
performance. It performs background processing which keeps the
server active
• Liberty Profile: A new level of efficiency and silence
• Tuning examples:
• Applications: pay attention to timers in your application!
• WebSphere: Tune the EJB cache, and JSP reload intervals
• Network: Tune node sync interval, and HA Manager heartbeat
• External: IP Sprayer keep-alive messages, monitoring tools
17

WebSphere startup tuning
Multi server startup has a huge impact on CPU and I/O
• Primarily due to classloading and JIT
• Biggest impact on environments with high CPU over-commit
•Preprocessing of annotations
metadata-complete – saves CPU (see KnowledgeCenter)
•use ripple start to minimize impact on overall environment
•In memory file DCSS can be used to speed IO
•Use Java shareclasses and AOT to speed startup
•JSP precompile, don't compile on startup
•Virtual Enterprise (VE)/Intelligent Management
• Dynamic clusters for HA. Only start one server if the application can tolerate a
minimal interruption
• elastic mode / on demand startup of the guest
•See WebSphere Idle Tuning Guide
18

Session agenda:
• System z
19

Best Practice – Heap size and GC tuning matter
Memory is the most constrained resource in dense virtual environments
• Side effect of consolidation of idle physical servers
• We've see over commit of 40x on CPU, but only up to 4x on memory due to
paging, large applications, caches and limitations of some hypervisors.
• Where possible, make the heap as small as possible without causing
excessive GC overhead
• classic tradeoff – GC touches many pages vs. Throughput
– CPU vs. Memory tradeoff
• Use 31 bit WAS vs 64 bit if possible. 64Bit native libs are larger.
• Choose the GC policy carefully based on application characteristics.
• i.e gencon may be less disruptive than optthruput - ymmv
• Always run with -verbose:gc
• causes little overhead and you MUST understand verbose:gc data.
• Use the Java Diagnostic Guide: http://www.ibm.com/developerworks/java/jdk/diagnosis/
• - See chapter 2: heap sizing
20

Best Practice – Avoid duplicate caches
• Local caches typical on dedicated servers to improve performance
• HTTP sessions, database buffers, rules cache, ...
• Redundant caches consume memory, the most constrained resource
• Cache hits touch memory pages, prevent guest from going dormant
Use a caching tier or dedicated services to avoid duplicate caches
• Provides uniform response characteristics per your requirement
• i.e Extreme Scale provides near local cache performance without the
virtualization penalties incurred by duplicate caches
Know your response time requirement
• “Fast as possible” is not a requirement. Its a wish, with a downside for
another application
• Anecdote: Throttle all workload to SLA at the load balancer
– Results in no calls about slow servers, there is no peak/valley
21

Development environment
• Don’t underestimate your development environment
The consolidated dev box is a production box.
• Agile development drives intense utilization of resources:
• Deployments
• Test Runs
• Server Re-Starts
• Compiles / builds
• Regression tests keep growing.
• “Spikey workload” that tends to be underestimated.
Undersized system cause dissatisfaction if spikes align
• Zero batch window, Its a 24 hr/day cycle
• Can be faster to suspend / resume a guest than restart an AppServer loaded with
applications.
• stop/begin is faster than suspend/resume because it just takes CPU away from the
guest – but use caution because you can lose state if z/VM is recycled.
• Can build images per app version and “put them on the shelf” to use when
needed
• Use Liberty where possible – Fit for Purpose, Small Footprint, Fast startup.
22

WebSphere shared installation
• We've seen this pattern on PowerVM and System z
• One master copy of WebSphere
• Related software including fixpacks, Feature Packs, iFixes, ...
• Mount the shared master copy read-Only on other servers
• Simplifies maintenance: To move to a new version, just relink and
reboot
• See Sharing a WebSphere installation among Many Linux for
System Z Servers http://www-
03.ibm.com/systems/z/os/linux/resources/doc_wp.html
WAS-MASTER
Each Linux system
sees this logical
view.
Physical disk layout.
/opt/WebSphere
/opt/IBMIHS
/opt/wasprofile
/opt/wasprofile/
/opt/WebSphere
/opt/IBMIHS
WAS-CLONE1 WAS-CLONE2
/opt/wasprofile
R/O
Link
R/O
Link
…
23

Session agenda:
• System z
24

25
Performance tuning experience: (1 of 5)
Constrained approach - background
Customer tuned a large scale benefits enrollment application
•peak usage during a 2 month period
Tuned from scratch using a constrained resource approach:
•Phase 1: Start with a single server, allocate minimum CPU, memory, and
guest size , minimal workload
•Phase 2: create cells with multiple instances of the phase 1 config.
Increase test workload
•Production: replicate phase 2 cell config to meet production level workload

Constrained approach - results and benefits
Before tuning:
•9.25GB 4vCPU Guest, 4 AppServers w/1.3GB Heap
•200+ AppServers total
After:
•4GB 3vCPU Guest (z196) or 4vCPU (z10), 1 AppServer w/2.5GB Heap
Savings:
Reduced: vCPU by 100+ (70%), RAM by 300+ GB (73%),
JVMs by 160 (80%) - while maintaining the same SLA
Reduced risk of “bleed-over” - If a bug, or other condition cause excessive
resource consumption, a tightly tuned server will have limited negative impact on its
neighbors
–i.e LPAR restart, restart all servers (CPU intensive, especially if too many
vCPU per server)
–i.e DB connection slowdown (memory intensive if pool is too large)
–Capacity on demand available if needed by adding guests, IFLs
26

27
Performance tuning experience:(3 of 5)
Constrained approach – methodology (1 of 2)
A disciplined, constrained resource approach to tuning
Start with minimal infrastructure resources
•i.e 2 CPUs, minimal memory, default thread pools
•Apply WebSphere idle server tuning suggestions
Add resources sparingly: Only add when bottleneck has been identified and
there is no other means to relieve it
•Heap increases
•Connection pools (especially web container thread pool)
•VCPU
•application
Tune GC
•This was done in phase 2. Consider a “first pass” in phase 1
Measure results with every config change
•Know your SLA goals – i.e. expected transaction rate and response time
•Done when you reach your goals – diminishing returns

28
Constrained approach – methodology (2 of 2)
Automated, iterative test runs
1 hour to reset DB, reset application/logs, reset servers, 8 minute
warm-up, run test at load, capture measurements, format and
correlate measurements, produce report.
Include Hypervisor Measurements – OS sampling can be flawed in virtual
environments.
Have a “control VM” with known work profile / behavior
•i.e idle, and with known workload
•Observe behavior w.r.t. workload variance.
Agile principle: Start performance test early in the development
cycle
•Reliable early application drivers a must

29
Performance Tuning Experience: (5 of 5)
Constrained Approach – Key enablers
Know-how
Experience to know what to measure, how to extrapolate
results, know which knob to turn, and how to automate
Partitioned workload
User load is partitioned and routed to the correct cell by front-
end load balancer
 Back end DB's also partitioned by user
 Maintains the integrity of cell level performance testing

Session agenda:
• System z
30

31
App server stacking options - overview
• WebSphere Application Server Horizontal versus Vertical JVM
Stacking Report
• http://public.dhe.ibm.com/software/dw/linux390/perf/ZSW03213-USEN-00.pdf
• Is it better to host all App Servers on a single z/VM guest (vertical
JVM stacking), or distribute the servers across multiple guests
(horizontal JVM stacking)?
• YMMV – The results depend to some degree on the workload
• Management overhead is concentrated differently depending on
scaling choices:
• The management overhead in z/VM scales with the number of
guests.
• The management overhead in Linux® scales with the number of
JVMs per Linux instance

App server stacking options – test setup
• Hardware
• 1 LPAR on z196, 24 CPUs, 200GB Central storage + 2 GB expanded
• Software
• z/VM 6.1, SLES11 SP1, WebSphere 7.1
• Workload: SOA based workload without database back-end
• Guest Setup
• no memory over-commitment
#guests
200 1 24 24 1 : 1.0 8.3 200 200
100 2 12 24 1 : 1.0 8.3 100 200
50 4 6 24 1 : 1.0 8.3 50 200
20 10 3 30 1 : 1.3 6.7 20 200
CPU Overcommitment
10 20 2 40 1 : 1.7 5.0 10 200
4 50 1 50 1 : 2.1 4.0 4 200
Uniprocessor2 100 1 100 1 : 4.2 2.0 2 200
1 200 1 200 1 : 8.3 1.0 1 200
#JVMs
per guest
#VCPUs
per guest
total of
#VCPUs
CPU
real : virt
JVMs
per vCPU
guest
memory size
[GB]
total virtual
memory size
[GB]
32

App server stacking options – overall results
zLinux supports a wide range of stacking configurations
•User space (WebSphere JVM and application) consume most CPU
• Linux and VM efficient at managing a wide range of configurations
•The amount of CPUs per guest is important!
• decreases with the decreasing number of JVMs per System
• but increases with the Uniprocessor cases
33

App server stacking options – virtual CPU utilization
The amount of virtual CPU has an impact on the total CPU load
• Impact on throughput is moderate
• CPU over-commitment level is one factor, but there are other system effects.
• Validates the constrained tuning approach. Do NOT allocate more vCPU than you
need.
34

Session agenda:
• System z
35

WAS 8.5.5 - Liberty profile performance
Designed for virtual environments!
•Startup time
• Elapsed & CPU
•Memory footprint
•Idle server resource consumptions
•Throughput
36

Liberty performance: z/VM test configuration
• Hardware:
• Z196, 1 LPAR with 4 dedicated processors
• 32 GB central, 16 GB XSTORE and 4 paging volumes
– No paging during tests
• Linux guest
• 2048 MB virtual memory, 4 vCPU
• Software
• Liberty 8.5.5
• WebSphere v8.5.5
• DayTrader3 – IBM standard benchmark - simulates online
stock trading.
37

Liberty performance: startup time
• class loading is biggest contributor to server startup time difference
7.2
14.3
1.5
3.2
1
2.2
0
2
4
6
8
10
12
14
16
Elapsed Time CPU Time
T
i
m
e
i
n
S
e
c
Startup Time - WAS 8.5.5 - tWAS vs Liberty profile
tWAS Liberty profile Liberty profile on zEC12
33%
31%
38

0
0.5
1
1.5
2
2.5
3
3.5
4
V8.5.5 full profile Liberty CPU Time(default) Liberty CPU Time(default with Java 8)
Liberty CPU Time(No file mon * ) Liberty CPU Time (No file+Xtune ** )
.4 sec
2.8 sec
.2 sec
1.3 sec
1.4 sec
0 1 2 3 4
Liberty performance: Idle CPU time
CPU seconds/hour
WAS V8.5.5. 2.8
Liberty (default) 1.4
Liberty (default w/Java8) 1.3
Liberty (No file mon*) .4
Liberty(No file +Xtune) .2
Hours
** -Xtune=virtualized option, available as of Java 7 SR4
* Liberty File Monitoring polls file system for new application versions
– Great for developers, turn it off for production
39

Liberty performance: memory footprint
• Liberty JVM max heap size was set to 256 MB in each case
• Resident memory or working set for this workload is approx 70% less in Liberty profile
compare to WAS full profile.
761
298
68
646
85
40
0
100
200
300
400
500
600
700
800
VIRTUAL Mem RESIDENT Mem SHR Mem
S
i
z
e
i
n
M
B
Memory Footprint - WAS 8.5.5 full profile vs Liberty profile
WAS 8.5.5 Full Profile WAS 8.5.5 Liberty Profile
40

0
20000
40000
60000
80000
100000
120000
140000
160000
ETR ITR
T
r
a
n
s
/
S
e
c
Throughput - WAS 8.5.5 full profile vs Liberty profile
Full Profile Liberty Profile Liberty Profile with Java 8 Liberty Profile on zEC12
29%
29%
Liberty performance: throughput
 DayTrader 3 - ping servlet without DB connection
 Primitive throughput is ITR within 1 % variance – Liberty being a little better.
41

Session agenda:
• System z
43

Attracting good workloads to Z
• adverse selection //en.wikipedia.org/wiki/Adverse_selection
“...a market process in which undesired results occur when buyers and sellers have asymmetric
information (access to different information); the "bad" products or services are more likely to be
selected. For examples,
• a bank that sets one price for all of its checking account customers runs the risk of being
adversely selected against by its low-balance, high-activity (and hence least profitable)
customers”
•when an organization uses average cost as a basis for chargeback, they will attract heavy,
resource intensive, users. This in turn will drive up the average cost and cause a negative
feedback loop which makes the platform appear more expensive than it should.
Key Concepts:
• Segregation of workloads by “types”(fit-for-purpose) can create the
appearance of cost differentials between platforms
• Chargeback systems typically average costs over users of a platform and
charge by some convenient unit (images, cores, CPU minutes, etc.)
• Averages hide workloads which are handled well by System z
44

45
Using This Classification Scheme We See That Most
VMs Are Small to Medium
• 1148 Total VMs
• 93% of VMs are Zombie through Medium and consume 53% of all resources
• Only 7% are Large through Monster consuming 47% of all resources
• Averaging over all classes hides this important fact
7% of VM’s
43% of the Resources
93% of VM’s
57% of the Resources

46
The Largest Virtual Machines Consume Significantly
More Resources Than the Smallest
193 VMs
0.28GHz/VM
133 VMs
0.60GHz/VM
75 VMs
1.20GHz/VM
47 VMs
2.13GHz/VM
24 VMs
4.58GHz/VM
5 VMs
7.00GHz/VM
671 VMs
0.14GHz/VM
50x Difference in Capacity Requirements between Smallest and Largest VMs

Time-based Overview of Utilization
47
Including Weekend Spike No Weekend Spike
Site 1
Site 2

Attracting New workloads - Conclusions
• Weekend workload looks like data backup
• Storage overcommit may allow tight packing of workloads with better
economies
• I/O capabilities of IBM System z may significantly smooth weekend
peaks
• Other platforms use more CP to do I/O that System z and when
measured for fit for purpose may show “CP usage” when on System z it
would be offloaded.
48

49
Lessons Learned to Improve Competitiveness
• Get the zombies (or at least some of them) on your platform!!!
• Remember – Averages hide everything!
•Be careful about “qualifying” applications … you may end up with
the “worst” ones!!! You will increase the relative cost of hosting on
your environment and decrease the relative cost of hosting on the
other environment.
•This creates a false impression of cost and drives adverse
selection

50
IBM Eagle Team
• Team of Analysts specializing in Cost of Ownership Studies
• Studies performed analyzing cost issues around:
• Offload
• Consolidation
• Chargeback Systems
• Platform Comparisons
• Capacity
• Studies are data driven using customer data
• Contact: eagletco@us.ibm.com

Session agenda:
• System z
51

Z13, zEC12 and zBC12
compute in any
configuration
Standard Linux
Environment
• Red Hat/SUSE
• 3000+ Applications
IBM Deployment Expertise
done in the factory with
on-site personalisation
Factory Integrated and Tested
Delivered in ½ time of other
Integrated Systems*
Production Ready in Hours
Scale up to 8000 VMs
Industry Leading Availability
Proven Security
32% cheaper than x86
60% cheaper than Public
Cloud
Fully Automated Cloud
Orchestration &
Monitoring
Storwize V7000 or
DS8870 in any config
IBM Cloud Manager
with Openstack
Omegamon for z/VM
TSM
Operations Manager
Backup Manager
IBM Wave
“The new z13 certainly isn’t the first IBM
mainframe to be “cloud ready,” but it offers
numerous features that are crucial to the
success of every cloud-bound service
provider and business.”

Trends in virtualization for server consolidations
• Its all about density
• Even more memory optimization and sharing capabilities
• Linux containers
• Illusion of isolation
• i.e. System z LPAR is EAL5
• Linux containers 
• Simplification
• less knobs, smarter tuning
– Across all the layers (hardware, hyp, OS, WebSphere, Java,...)
– Exploit Patterns as a way to replicate best practices quickly
• Self-service
• Continued focus on “idle” behavior
• Reduce background processes and make them smarter
• Liberty profile: only enable the features you need
• Exploit virtualization friendly programming models that are
– Distributed cache
– Networked
• More specialized servers / engine
• New hardware like SSD for more efficient paging and reduced startup times.
56

Contributors – thank you!
• Juergen Doelle – System z Linux performance
• Steven Wehr - System z Linux infrastructure architect
• Bruce Hayden - ATS Specialist - System z – z/VM and Linux
• Beena Hotchandani - WebSphere performance analyst
• Roger Rogers – IBM Competitive Project Office Eagle Team TCO Analyst
• IBM Competitive Project Office
• Customers who have worked closely with us
57

Notices and Disclaimers
Copyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or
transmitted in any form without written permission from IBM.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with
IBM.
Information in these presentations (including information relating to products that have not yet been announced by IBM) has been
reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM
shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY,
EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF
THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT
OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the
agreements under which they are provided.
Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without
notice.
Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are
presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual
performance, cost, savings or other results in other operating environments may vary.
References in this document to IBM products, programs, or services does not imply that IBM intends to make such products,
programs or services available in all countries in which IBM operates or does business.
Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not
necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither
intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.
It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal
counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s
business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or
represent or warrant that its services or products will ensure that the customer is in compliance with any law.

Notices and Disclaimers (con’t)
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products in connection with this
publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to
interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE.
The provision of the information contained herein is not intended to, and does not, grant any right or license under any
IBM patents, copyrights, trademarks or other intellectual property right.
• IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document
Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand,
ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™,
PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®,
pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®,
urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of
International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and
service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on
the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.

Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee
Portal to complete your session
surveys from your smartphone,
laptop or conference kiosk.

ASZ-3034 Build a WebSphere Linux Cloud on System z: From Roll-Your-Own to Pre-Integrated

More Related Content

What's hot (20)

Similar to ASZ-3034 Build a WebSphere Linux Cloud on System z: From Roll-Your-Own to Pre-Integrated (20)

More from WASdev Community (20)

Recently uploaded (20)

ASZ-3034 Build a WebSphere Linux Cloud on System z: From Roll-Your-Own to Pre-Integrated