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

[email protected] @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.

[email protected] @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 IFL3 CP1 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

Workload

Linux

Workload

Linux

Workload

Linux

Workload

http://www-01.ibm.com/software/os/systemz/seminar/mainframe/handouts/



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.com 1 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

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101894



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

http://www-03.ibm.com/systems/z/os/linux/resources/doc_wp.htmlRelink




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 200CPU 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

CPUreal : 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

Liberty HPEL Benchmark

42

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

http://en.wikipedia.org/wiki/Adverse_selection

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: [email protected]

mailto:[email protected]

Session agenda:

• System z












51

z13 - Java

52

z13 - Java

53

z13 - WebSphere

54

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

Questions?

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.

http://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.

Date post:	18-Jul-2015
Category:	Software
Upload:	wasdev-community
View:	83 times
Download:	1 times