cap2860-10 reasons vmware vsphere is the best place to run java_final_us.pdf

7/27/2019 CAP2860-10 Reasons VMware vSphere Is the Best Place to Run Java_Final_US.pdf

1/141

10 Reasons VMware

vSphere Is the Best Placeto Run Java

Benjamin Corrie, VMware, Inc.

APP-CAP2860

#vmworldapps


2/141

2

Disclaimer

This session may contain product features that are

currently under development.

This session/overview of the new technology represents

no commitment from VMware to deliver these features in

any generally available product.

Features are subject to change, and must not be included in

contracts, purchase orders, or sales agreements of any kind.

Technical feasibility and market demand will affect final delivery.

Pricing and packaging for any new technologies or features

discussed or presented have not been determined.


3/141

3

This Talk and Me - @bensdoings

Internal Java summit last year

Re-enforce and discuss VMwares commitment to Java

Best practice now well-known, still very relevant and helpful

Shift focus from problem mitigation to exploring the benefits!

My history

Joined VMware from SpringSource

2 years teaching and consulting in Spring, OSGi, Java

Spent the last 2 years leading the EM4J project

First innovative integration effort between Java and vSphere

Entire career spent in Java

11 years at IBM working on Java

2002-2008 worked on internals of IBMs JVM

Designed and built intra-process class data sharing feature


4/141

4

Introduction: Spring values

The Spring Story

2000 Rod Johnson working in a bank, trying to use J2EE

2002 Rod publishes a 750 page book on how things could be better

The Spring Framework is born out of a search forSIMPLICITY

The secret to Springs success? Core values:

Reducing complexity

Increasing productivity

Provisioning flexibility

Tooling and monitoring

Open source / extensible

Automation Flexible integration

Easy to test / QA support


5/141

5

Introduction: Simplicity

Where are we battling complexity now?

The virtualized datacenter is an inherently complex system

Spring values in the datacenter?

YES! That is what this talk is all about

Java cuts across IT dev, QA, build infrastructure, server/runtime helpdesk

A lot of ground to cover. Higher level, designed to inspire!

High-level structure of this talk:

1. vSpheres first-class support for Java

Monitoring, ballooning, automation

2. VMwares commitment to the Java Platform

Configuration and flexibility, simplifying provisioning, integration, toolsand frameworks

3. vSphere goodness


6/141

6

Java: The Journey

Javas could easily have died out by now:

Applets: Java the language of the internet remember that?

Write once, run anywhere! no longer needed. Virtualization has shifted.

EJBs and early enterprise Java; J2ME; real-time Java?

Not only is Java not dead, its thriving! Why?

The JVM is a great software platform useful abstraction layer

Easy bet that the JVM will outlive the Java language

Debug support; JIT performance; reliability; monitoring; tooling; extensibility; open-source community

So much of it is still free!

Proliferation of new languages on the JVM: Scala, Groovy, Clojure etc.

Runtimes for other languages, such as JRuby


7/141

7

Java: Today

So is Java the language of the Cloud?

Cloud programming will need to be opinionated threading and memory in

particular

Is the JVM the runtimefor the cloud? much more likely!

If Java is so mature, why do customers still struggle?

Memory and configuration

Overwhelmingly still the #1 issue This is where VMwares first class integration support is focused

Performance

Usually GC performance == memory

Java heap sizes struggle to keep up with the data explosion

Java scales out better than it scales up what does scale out require?

Automation, scripting, cloning, provisioning, load balancing stay tuned!

Complexity

Java app servers can be very complex to deploy, manage and configure


8/141

8

VMwares First Class Support forJava


9/141

9

VMwares First Class Support for Java

Started with EM4J (Elastic memory for Java) project

Version 1.0 released 2011 as part of vFabric

vSphere can reclaim unused memory directly from the JVM

EM4J ballooning works best with a well-configured system

Well-configured == right sizing the VM and JVM(s)

Current best-practice prescribes static calculations for a dynamic system

Difficult and error-prone to calculate

Caution leads to significant over-provisioning and waste

Memory usage of Java from ESXi hosts perspective can be opaque andmisleading

Our solution

vCenter plugin specifically tailored for right-sizing VMs running Java

Empowers vSphere admins to significantly improve memory efficiency


10/141

10

Reason 1: EM4J Console Plugin

Brand new for 2012!

#1 GOAL

To empower vSphere administrators to confidently make informedconfiguration decisions to maximize memory efficiency in VMs running Java

Three main functions:

1) Help customers to right-size VMs running Java

2) Show useful real-time metrics on all Java workloads running in a VM 3) Provide advice and analysis on applying Java best-practice

So what is it?

Plugin to vCenter Web client

Lightweight guest collector agent collects metrics from the JVM and guest Ships with EM4J


11/141

11

How it looks

New Workloads tab

All Java

Workloads

in VM

Choose

from 4

functions


12/141

12

Hypervisor

VM

JVM

Garbage

Session

data

Working set

Over-provisioning and Memory Bloat

vRAM

Perceived perf

problem?


13/141

13

Hypervisor

VM

JVM

Garbage

Session

data

Working set

RESIZE


Perceived perf

problem?

Resize VM vRAM


14/141

14

Hypervisor

VM

Garbage

Session

data

Working set


Perceived perf

problem?

Resize VM

Resize JVM

(to be safe)JVM

vRAM


15/141

15

Hypervisor

VM

Garbage

Session

data

Working set


Perceived perf

problem?

Resize VM

Resize JVM

(to be safe)

JVM uses new

space becauseit can

Cac

he

data

JVM

vRAM


16/141

16

Hypervisor

Garbage

Session

data

Working set

VM


Perceived perf

problem?

Resize VM

Resize JVM

(to be safe)

JVM uses new

space becauseit can

VM consumed

mem increases Cac

he

data

JVM

vRAM


17/141

17

Hypervisor

Garbage

Session

data

Working set

Bu

ffer

Cac

he

VM


Perceived perf

problem?

Resize VM

Resize JVM

(to be safe)

JVM uses new

space becauseit can

VM consumed

mem increases

OS uses new

space for

optimizations

Cac

he

data

JVM

vRAM


18/141

18

Hypervisor

Garbage

Session

data

Working set

Bu

ffer

Cac

he

VM


Perceived perf

problem?

Resize VM

Resize JVM

(to be safe)

JVM uses new

space becauseit can

VM consumed

mem increases

OS uses new

space for

optimizations

VM consumed

mem increases

Cac

he

data

JVM

vRAM


19/141

19

Hypervisor

Garbage

Session

data

Working set

Bu

ffer

Cac

he

VM

Garbage

Cac

he

data

JVM

vRAM

Over-provisioning and Memory Waste

Cache becomes

stale


20/141

20

Hypervisor

Working set

Bu

ffer

Cac

he

VM

Garbage

JVM

vRAM


Cache becomes

stale

Garbage

Session

data


21/141

21

Hypervisor

Garbage

Working set

Bu

ffer

Cac

he

VM

Garbage

JVM

vRAM


Cache becomes

stale

Session data

becomes

garbage


22/141

22

Hypervisor

Garbage

Working set

Bu

ffer

Cac

he

VM

Garbage

JVM

vRAM


Cache becomes

stale

Session data

becomes

garbage

JVM is hoarding

memory

unavailable to

the guest


23/141

23

Hypervisor

Working set

Bu

ffer

Cac

he

VM

JVM

vRAM


Cache becomes

stale

Session data

becomes

garbage

JVM is hoarding

memory

unavailable to

the guest

even after GC!


24/141

24

Hypervisor

Working set

Bu

ffer

Cac

he

VM

JVM

vRAM


Cache becomes

stale

Session data

becomes

garbage

JVM is hoarding

memory

unavailable to

the guest

even after GC!

The VM is

hoardingmemory

unavailable to

the host


25/141

25

Hypervisor

Working set

Bu

ffer

Cac

he

VM

JVM

vRAM

Right-Sizing vs Ballooning

Ballooning is

only effective if

consumed isclose to vRAM!


26/141

26

Hypervisor

Working set

Bu

ffer

Cac

he

JVM

vRAM

Ba

lloon

VM


Ballooning is

only effective if


Working set


27/141

27

Hypervisor

Working set

JVM

vRAM

Ba

lloon

VM


Ballooning is

only effective if


Traditional

ballooning can

only reclaim

memoryavailable to the

guest

Working set


28/141

28

Hypervisor

Working set

JVM


Ballooning is

only effective if


Traditional

ballooning can

only reclaim


guest

More effective

to right-size in

the first place!

VM

JVM

Garbage

Working set

vRAM


29/141

29

Hypervisor

Working set

JVM


VM

JVM

Working set

vRAM

Ballooning is

only effective if


Traditional

ballooning can

only reclaim


guest

More effective

to right-size in

the first place!

Then consider

EM4J

ballooning

EM4J

balloon


30/141

30

Hypervisor

Host vs Guest Perspective

Why do we need any more

metrics?

H G P i


31/141

31

Hypervisor

Consumed vRAM



metrics?

Host sees consumed and

active memory

Active

H t G t P ti


32/141

32

Hypervisor

Consumed vRAM



metrics?

Host sees consumed andactive memory

Typically 1/3 of the Java heap is

very active and rest is spikey

Active

H t G t P ti


33/141

33

Hypervisor

Consumed vRAM


Active


metrics?




Is this VM right-sized? How canwe tell? Whats really going

on?

H t G t P ti


34/141

34

Hypervisor

Consumed vRAMJVM

Active



metrics?





on?

It could be this

Garbage

H t G t P ti


35/141

35

Hypervisor

Consumed vRAM

Garbage Garbage

JVM JVM

Active



metrics?





on?

It could be this

Or this

H t G t P ti


36/141

36

Hypervisor

Consumed vRAM

JVM

Active



metrics?





on?

It could be this

Or this

Or this

Host s G est Perspecti e


37/141

37

Hypervisor

Consumed vRAMJVM

Garbage Garbage

JVM JVM

JVM

JVM

Active

Garbage



metrics?





on?

It could be this

Or this

Or this

Or even this!

Avoiding Duplication


38/141

38

Avoiding Duplication

Doesnt this duplicate what Hyperic or vcOps already does?

No! We very deliberately didnt want to duplicate functionality

Our design goals were:

Gather the only statistics from the Guest, JVMs and hypervisor specifically for:

Making right-sizing decisions

Detecting potential performance issues

Represent those statistics in a way that shows clear historical trends over time Cumulative graph clearly showing how memory is divided up

Displays up to 7 days of historical trends

Simple setup

No database required

Agent starts as a Linux daemon process

Demo

Understanding EM4J Console History


39/141

39

JVM

OS & JVM native

VM

Garbage

Use

d

Free


Was

ted

Working set

-Xmx

vRAM



40/141

40

JVM

OS & JVM native

VM

Garbage

Use

d

Unuse

d


Working set

-Xmx

vRAM



41/141

41

JVM

OS & JVM native

VM

Garbage

Use

d

Unuse

d


Working set

-Xmx

vRAM



42/141

42

JVM

OS & JVM native

VM

Garbage

Use

d

Unuse

d


Was

ted

Working set

-Xmx

vRAM

Graphic: Historical Graphs


43/141

43

Graphic: Historical Graphs

Graphic: VM Could be Over-Sized


44/141

44

Graphic: VM Could be Over-Sized

JVM starts

Xmx4g

Other shows

O/S Usage

Committed

heap memory

increases

within -Xmx

JVM shuts

down

6GB heap startup

& shutdown

4GB JVM(s)

looks idle

(low committed heap)

FreeF

ree

Up to 7 days

Max potential

Graphic: VM is Over-Sized + Guest Balloon


45/141

45


Free



46/141

46


JVM

heap

growth

Free

Peak guest balloon

preserved as (gray)

min effective vRAM



47/141

47


JVM

heap

growth

Balloon

pressure

Free



48/141

48

Graphic: VM is Over Sized + Guest Balloon

JVM

heap

growth

Balloon

pressure

Free

JVM heap commits memory



49/141

49


JVM

heap

growth

Balloon

pressure


Free



50/141

50


JVM

heap

growth

Balloon

pressure


Free

Guest balloon constrains guest memory



51/141

51

Graphic: VM is Over Sized Guest Balloon

JVM

heap

growth

Balloon

pressure



Free



52/141

52


JVM

heap

growth

Balloon

pressure



Free



53/141

53


JVM

heap

growth

Balloon

pressure



Free



54/141

54

G ap c s O e S ed Guest a oo

JVM

heap

growth

Balloon

pressure



Free

and deflates



55/141

55

p

JVM

heap

growth

Balloon

pressure


Guest balloon constrains guest memory and deflates

Free



56/141

56

p

JVM

heap

growth

Balloon

pressure



Peak guest balloon

preserved as (gray)

min effective vRAM



57/141

57

p

JVM

heap

growth

Balloon

pressure



Peak guest balloon

preserved as (gray)

min effective vRAM

Blue crossing gray/yellow

== potential paging



58/141

58

p

JVM

heap

growth

Balloon

pressure



Peak guest balloon

preserved as (gray)

min effective vRAM

Blue crossing gray/yellow

== potential pagingBrown hitting yellow

== definite paging

Graphic: VM is Under-Sized


59/141

59

p

Potential heap exceeded vRAM!

is not a problem yet

but will be if the heap

gets fully committed

Prompts a memory alert

Graphic: VM is Under-Sized + Paging


60/141

60

p g g

Committed heap has hit vRAM limit so no free memory

Consequence isguest pagingSevere paging

triggers warning

Graphic: VM is Right-Sized


61/141

61

Most of the heap

is committed witha little headroom

Potential heap does not

exceed vRAM or guest balloon

Graphic: VM is Right-Sized + EM4J balloon


62/141

62

EM4J balloon constrains heap memory, not guest

Balloon

pressure

JVM

heap

growth

reducescommitted heap

higher

inflation

Free guest memory unaffected

Reason 2: EM4J Ballooning


63/141

63

EM4J ballooning introduced in 2011

Previously our best practice advice was dont over-commit

memory with Java Why? Depending on how Java is configured, it will hog memory from the guest

Guest ballooning reclaims memory from the guest by allocating sharablememory

If JVM(s) are hogging all the guest memory, theres very little to reclaim!

Paging out of the JVM heap can be very expensive with some GC algorithms

EM4J was designed to make Java not a special case

Hypervisor targets the JVM(s), rather than the guest for memory reclamation

Balloon driver plugs directly into standard Oracle Hotspot Java 6 & 7

The EM4J console now clearly shows ballooning/Java interaction

It shows the Guest balloon constraining free guest memory and the EM4Jballoon constraining free heap memory

Virtual Memory


64/141

64

guest

hypervisor

machinememory

physicalmemory

virtualmemory

virtual memory

physical memory

machine memory

guest

hypervisor

Application

OperatingSystem

Hypervisor

Virtual Memory


65/141

65

guest

hypervisor

virtual memory

physical memory

machine memory

guest

hypervisor

VM

App

OS

Hypervisor

Application Memory Management


66/141

66

Starts with no memory

Allocates memory through syscall to

operating system

Often frees memory voluntarilythrough syscall

Explicit memory allocation interface

with operating system Hypervisor

OS

App

Operating System Memory Management


67/141

67

Assumes it owns all physical memory

No memory allocation interface with

hardware

Does not explicitly allocate or free physicalmemory

Defines semantics of allocated and

free memory

Maintains free list and allocated lists ofphysical memory

Memory is free or allocated dependingon which list it resides

Hypervisor

OS

App

VM Memory Allocation


68/141

68

VM starts with no machine memory

allocated to it

No memory is used when powered off

Small footprint after power on and boot

Machine memory is lazily allocatedon demand

When applications or the OS read and

write to physical memory, machine

memory is provided to back it.Hypervisor

OS

App

VM Memory Reclamation


69/141

69

Guest physical memory not

freed in typical sense Guest OS moves memory to its

free list

Data in freed memory maynot have been modified

Hypervisor

OS

App

Guest

Free List



70/141

70



free list


Hypervisor

OS

App

Guest

Free List



71/141

71



free list


Hypervisor

OS

App

Guest

Free List



72/141

72



free list


Hypervisor isnt aware when

guest frees memory

Freed memory state unchanged

No access to guests free list

Unsure when to reclaim freedguest memory

Hypervisor

OS

App

Guest

Free List

VM Memory Reclamation Contd


73/141

73

Guest OS (inside the VM)

Allocates and frees

And allocates and frees


Hyper

visor

AppGuestfree list

Inside the VM

OS



74/141

74


Allocates and frees



Hyper

visor

AppGuestfree list

Inside the VM

OS



75/141

75


Allocates and frees



Hyper

visor

AppGuestfree list

Inside the VM

OS



76/141

76


Allocates and frees



Hyper

visor

AppGuestfree list

Inside the VM

OS



77/141

77


Allocates and frees



Hyper

visor

AppGuestfree list

Inside the VM

OS



78/141

78


Allocates and frees



Hyper

visor

AppGuestfree list

Inside the VM

OS



79/141

79


Allocates and frees



Hyper

visor

AppGuestfree list

Inside the VM

OS



80/141

80


Allocates and frees



VM Allocates

And allocates

And allocatesHyper

visor

AppGuestfree list

Inside the VM

OS

VM



81/141

81


Allocates and frees



VM Allocates

And allocates

And allocates

Hypervisor cant reclaim memory

through guest frees!

Hyper

visor

AppGuestfree list

Inside the VM

OS

VM

Policies: When to reclaim and which VMs?


82/141

82

When to reclaim?

Page sharing will occur as a background thread (TPS)

Ballooning, compression and swapping only occur if there is memory pressure A resource pool containing VMs can have an arbitrary memory limit

A physical host containing VMs can have a real physical memory limit

Once allocation requests risk violating available memory, reclamation begins

Which VMs?

The hypervisor estimates how much memory is active in a VM

VMs which are the least active are the primary reclamation targets

Java Memory Management


83/141

83

Interesting parallels!

The black box relationship between the hypervisor and the operating systemis very similar to that of the relationship between the JVM and the OS

Unlike native applications which allocate and free memory from the OS, theJVM manages its object heap as a black box

The OS allocates pages lazily to the heap, but they are never freed (unless inthe rare case where the heap shrinks)

OS

Guestfree list

JVM



84/141

84





OS

JVM JVM starts up

Guestfree list

heap



85/141

85





OS

JVM JVM starts up

Allocates some objectsGuestfree list

heap



86/141

86





OS

JVM JVM starts up

Allocates some objects

Allocates more objects

Guestfree list

heap



87/141

87





OS

JVM JVM starts up

Allocates some objects

Allocates more objects

Garbage Collection

Guestfree list

heap

Java Memory Management: Partially vs fully committed heap


88/141

88

OS

JVM

Java gives you the option to set a

min and max heap size

Partially committed heap Min < max (-Xms < -Xmx)

Heap grows to the high water mark of livedata through incremental growth

Typically wont shrink back down

More frequent, but shorter GCs

GC count: Garbage:0 0



89/141

89

OS

JVM







GC count: Garbage:0 01 1



90/141

90

OS

JVM










91/141

91

OS

JVM










92/141

92

OS

JVM










93/141

93

OS

JVM







Fully committed heap

Min == max (-Xms == -Xmx)

No heap growth, so data gradually fills the

heap until its full Less frequent, but longer GCs

Potentially wasteful for apps with smallamounts of med/long lived data

OS

JVM





94/141

94

OS

JVM












OS

JVM





95/141

95

OS

JVM












OS

JVM



Java with Guest Ballooning


96/141

96

So what happens if you use the

Guest balloon with Java?

Well, it depends!

There are some cases where it maywork just fine

OS

JVM Balloon

Partially committed heap



97/141

97



Well, it depends!


There are other cases where it cancause a sudden deterioration in

performance

OS

JVM Balloon


OS

JVM




98/141

98



Well, it depends!



performance

OS

JVM Balloon


OS

JVM Balloon




99/141

99



Well, it depends!



performance

The provisos are too complex to offerguarantees, hence the best practice

OS

JVM Balloon


OS

JVM Balloon


Graphic: Partially Committed Heap + Guest Balloon


100/141

100

Garbage collectionduring heap growth

keeps committed down

Balloon inflates, but doesnt conflict with committed heap

Graphic: Fully Committed Heap + Guest Balloon


101/141

101

Committed grows larger

Much of this is garbage

Balloon inflation leaves no free guest memory

Consequence is guest paging

& memory alert

Memory Reclamation with EM4J

VM t l b ll di bl d


102/141

102

VMware tools balloon disabled

EM4J balloon starts to inflate

Sharable memory is written to theJava heap

EM4J balloon inflates more

More sharable memory is written and

the pages are consolidated

The previously used memory is now

free to be used elsewhere

EM4J balloon inflates even more

The same thing happens again

OS

JVM


Balloon

Hypervisor

EM4J can respond very quickly to balloon inflation requests Memory can be reclaimed at up to 500MB/s

Memory Reclamation with EM4J Contd

Thi i i ti

F ll i d h


103/141

103

JVM

This scenario is wasting more

memory on the hypervisor

Remember how previously balloon

inflation caused swapping to disk?

OS

JVM


Balloon

Hypervisor


Thi i i ti

F ll itt d h


104/141

104

JVM





EM4J balloon inflates

No need for swap! OS

JVM


Balloon

Hypervisor


Thi i i ti

F ll itt d h


105/141

105

JVM






No need for swap!

A Garbage collection occurs

The balloon works with the GC

OS

JVM


Balloon

Hypervisor


Thi i i ti

F ll itt d h


106/141

106

JVM






No need for swap!



The JVM allocates more memory

The balloon is not overwritten

OS

JVM


Balloon

Hypervisor


This scenario is wasting more F ll itt d h


107/141

107

JVM






No need for swap!



The JVM allocates more memory

The balloon is not overwritten

The JVM shuts down

The balloon memory is still shared

OS


Balloon

Hypervisor

The meaning of Elastic memory

Memory is elastic when it is taken from less active VMs and


108/141

108


given to more active VMs

JVM

OS

JVM JVM

OS

JVM

Hypervisor




109/141

109



JVM

OS

JVM JVM

OS

JVM

Hypervisor

LOAD




110/141

110



JVM

OS

JVM JVM

OS

JVM

Hypervisor

LOAD




111/141

111



JVM

OS

JVM JVM

OS

JVM

Hypervisor

LOAD

Balloon




112/141

112



JVM

OS

JVM JVM

OS

JVM

Hypervisor

LOAD

Balloon




113/141

113



JVM

OS

JVM JVM

OS

JVM

Hypervisor




114/141

114



JVM

OS

JVM JVM

OS

JVM

Hypervisor

LOAD

Balloon




115/141

115



JVM

OS

JVM JVM

OS

JVM

Hypervisor

So How Much Can I Over-Commit?

It depends!


116/141

116

It depends!

Memory over-commit requires an area of memory to be constrained

Arbitrarily through Resource Pools or through over-committing host

The performance youll see is relative to the peak live working set of all theVMs running in the constrained memory area

which is very difficult to calculate statically

So how can I tell how big my working sets are? EM4J consoleCommitted

heap

There is always a cost

But with EM4J, the performance degradation is very linear

If there are large working sets, GC has to work harder to give back memory

For smaller working sets, EM4J ballooning may have almost no effect onperformance

Lets look at some graphs

Evaluation on a Larger System (host memory)


117/141

117

EM4J Ballooning Response Times High Live Working Set


118/141

118

0

20

40

60

80

100

120

140

160

180

200

1 3 5 7 911

13

15

17

19

21

23

25

27

29

31

33

35

37

39

41

43

45

47

49

51

53

55

57

59

61

63

65

67

69

71

73

75

77

79

81

83

85

87

89

91

93

95

97

99

Respons

etimemilliseconds

Test

Average Response Time Distribution(Serial GC)

Fully committed 10% overcommitted 20% overcommitted

30% overcommitted 40% overcommitted

EM4J Ballooning Response Times High vs Low working set


119/141

119

0

20

40

60

80

100

120

140

160

180

200

1 3 5 7 911

13

15

17

19

21

23

25

27

29

31

33

35

37

39

41

43

45

47

49

51

53

55

57

59

61

63

65

67

69

71

73

75

77

79

81

83

85

87

89

91

93

95

97

99

Respons

etimemilliseconds

Test

Average Response Time Distribution(Serial GC)

Fully committed 40% low tenured 40% high tenured

Typical Use Cases for EM4J Ballooning

1. Fit more VMs into the same area of memory


120/141

120

1. Fit more VMs into the same area of memory

Consolidation exercise. Works particularly well with variable loads

2. Same number of VMs, but increase heap and VM sizes If you want to give your JVMs more peak headroom without using more

memory

EM4J is part of vFabric

Find out more at the vFabric Booth


121/141

121

VMwares Commitment

to the Java Platform

Reason 3: Automation and Scripting

Pearls of QA wisdom:


122/141

122

Pearls of QA wisdom:

Work smarter, not harder difference is automation

If you ever do anything more than 3 times, write a script We should be automating at every level

Easy: build, patching, unit testing

Hard: system test, datacenter configuration, horizontal scaling, elasticity,provisioning

How is this relevant to Java and vSphere?

Example: How do we test EM4J?

Test matrix is huge!

4x GC policies, 2x heap config, 4x heap size, large/small pages, 4x memory profile, 2x

JVM versions, 5x degrees of over-commit (0, 10, 20, 30, 40) = 2560 combinations

In an ideal world, the only limit to our combinations should be our machine time!

For each VM: power off,

config power on

EM4J QA Setup


123/141

123

Virtual Center

Host n

Reservation,

vRAM,

vCPU

Configure Script

Migrate Script

Test Harness

(Java)

Loops over

test matrix

CSV generator (Java)

Spreadsheet

JVM

App Server 1

ManagesMatrix,VM list, VC

credentials,

prev results

Serialize

results

Load

results

Process & build

Reservation,

vRAM,

vCPU

config, power on

Cfg, start, stop test

(REST)

Host 1

VM 1

VM n

VIMAPI

Ruby

API

Automation Continued

This is not to show off


124/141

124

There are plenty of ways this could be improved!

Eg. Start with one master VM and test harness builds/destroys linked clones

Virtualization can transform QA automation

Extremely flexible, very controllable, easily scriptable

Hard to believe we used to sit in front of terminals to physical machines!

Open-source frameworks VIJava (vijava.sourceforge.net) driving vCenter with Java

Chef (www.opscode.com/chef/) configuring guests

jSCH (www.jcraft.com/jsch/) SSH with Java

Automation doesnt stop at QA!

VMware provides many, many solutions to automate provisioning of Javaproducts

Reason 4: Configuration and Flexibility

Resource management and monitoring is unparalleled


125/141

125

g g p

Weve just seen an example of the power of this in QA!

The ability to right-size is another good example

Being able to set the memory needs to exactly whats needed

Being able to set different priorities and QOS super easy to configure

How does this apply to Java?

vCPU over-commit is a significant advantage for Java

How highly parallel do you want GC to be? Easy to configure

vCenter monitoring

Most Java apps are memory-bound, not CPU bound

vCenter and vcOps clearly show where resource is under-utilized

vFabric Administration Server

New in vFabric 5.1: Administer tcServer, Gemfire, RabbitMQ using REST API

Reason 5: Provisioning Simplicity

What words come to mind when we think of Cloud?


126/141

126

Provisioning, simplicity, automation, elasticity, scalability

SO much progress from VMware on this in the last year

Java right at the heart of much of it

Serengeti project

Automatically deploys Hadoop Clusters to vSphere

Brand new this year and its open source!

How is this relevant?

Hadoop runs on Java and a Hadoop cluster is many Java VMs

App Director

Allows for total separation of application from infrastructure

Visual blueprints define application setups, then execute deployments!

Automated, simple, scalable way to deploy applications

App Director


127/141

127

Provisioning Simplicity More Examples

CloudFoundry


128/141

128

Our PaaS cloud solution now supports Java 7

Focus on application, not plumbing and its open source!

vFabric Data Director

Database as a service, integrated with resource management policies

Integration with other products and services via REST API

vSphere has provisioning simplicity built into its core vApps: Package up clusters of VMs and manage them as a single entity

Supporting developers

Build processes are growing significantly not uncommon for VM snapshots withentire development environment to be built nightly

Linked clones make roll-outs and updates so much simpler

Reason 6: Integration

Began with discussion about complexity of software stack


129/141

129

Integration becoming more and more of a challenge

Web Services and SOA have come round full circle

Complex state machines interacting different vendors products

Sync or async? Fat or thin? Layers upon layers. Who supports what?

Spring Integration tackled the problem of integrating services and transformingdata

This is why we created vFabric!

Java is right at the heart of the vFabric stack

Suite of products designed for creating and deploying 3-tier enterprise Java apps

So how is this relevant to integration?

There is real value in having a suite of products designed to work together, supportedand tested on vSphere with simplicity at the core

Continuing integration efforts eg. Rabbit plugin for Insight

NanoTrader

We dont just claim integration and simplicity


130/141

130

We have a team dedicated to proving it!

NanoTrader project designed to be a model for integration with vFabric

How do people go about learning Spring?

People learn by example and community support

Spring is opinionated, it doesnt force you to do the right thing, it makes itobvious

NanoTrader takes this to a higher abstraction

Demo app uses tcServer, RabbitMQ, SQLFire learn to integrate by example

Deploy NanoTrader using App Director and vCloud Director!

Integration goes beyond vFabric

So much of what weve already discussed involves simplifying integration

Automate the plumbing and focus on what matters

Reason 7: Tools and Frameworks

Cant talk about VMware and Java without mentioning Spring


131/141

131

Spring helps developers build and test enterprise apps more quickly, more reliablyand with more maintainable code

We provide awesome tooling for developers to build Spring, Groovy and Grailsapps

Blah, blah blah

Enough about Dev why is this interesting to Infra folks?

Imagine a developer builds an app, deploys it to the Cloud and then it breaks Is it your network? Is it a bug in the app? Is it looping? Is there a memory leak??

HELP!!!

When you code to a framework, you get significant benefits

Insight code can be instrumented to provide fine-grained heuristic analysis

Best practice design patterns greatly simplify adding and removing components Framework state exposed to monitoring tools such as Hyperic

Spring Tool Suite support for remote debugging

Spring Insight: Recent Activity


132/141

132

Spring Insight: Drill down to the Database Query!


133/141

133

Spring Insight: Integration with Rabbit MQ


134/141

134


135/141

135

vSphere Goodness!

Reason 8: vApps and Java

Great way to package multi-VM applications


136/141

136

Many VMware products are delivered as vApps

Operations such as power on/off can be applied to the vApp as a single entity

Fits well with provisioning simplicity story

First class Java support is invaluable!

Greatly simplifies the sizing and configuration of your vApp VMs

No guesswork in sizing decisions

Is JMX configured correctly? Are large pages set up and working?

Great value add for vApp customers

Packaging the EM4J monitoring agent gives invaluable insight to the field

Enabling EM4J ballooning out of the box

Zero cost in the case where theres no memory pressure

Efficient memory reclamation otherwise

Reservations can still be used to place a hard limit on the balloon

Other vSphere Goodness

Reason 9: DRS and vMotion


137/141

137

Hypervisor treats Java ballooning the same way as guest ballooning

Memory pressure can be configured to trigger VM migrations

Allows for much more resource flexibility

Eg. Batch job VMs start up during the night; causes ballooning in idle JavaAppServers; cleans up old session data. If the AppServers start to experience

unexpected load, VMs can be migrated and the balloons get kicked out

Reason 10: High Availability Simplicity of HA requires integrated failure detection at infrastructure level:

Physical host

Operating system

Network availability

VMs can be prioritized for restart priorities

Keep 2 VMs in lock-step with each other with shared storage

Summary and Questions

3 Years since VMware bought SpringSource


138/141

138

Vmware is taking Java seriously and embracing Spring values

Reducing complexity vFabric, NanoTrader, Spring Framework Increasing productivity Focus on tasks that matter, not plumbing!

Provisioning flexibilityApp Director, Data Director, Serengeti

Tooling and monitoringEM4J console, App Insight, Spring Tool Suite

Open source / extensible CloudFoundry, Serengeti, VIJava

Automation Powerful APIs for driving provisioning, configuration eg. VAS

Flexible integration RabbitMQ Insight integration, NanoTrader, Serengeti

Questions

Follow me on Twitter @bensdoings

Useful links

Watch AppDirector, NanoTrader and App Insight


139/141

139

http://www.vfabgirl.com/?p=33

Tuning Java for a VM at SF User Group https://www.youtube.com/watch?v=V3o4VNkTyTY

vFabric blog

http://blogs.vmware.com/vfabric/

EM4J documentation http://pubs.vmware.com/vfabric51/index.jsp?topic=/com.vmware.vfabric.platform.5.1/vfabric/intro.html
http://www.vfabgirl.com/?p=33https://www.youtube.com/watch?v=V3o4VNkTyTYhttp://blogs.vmware.com/vfabric/http://pubs.vmware.com/vfabric51/index.jsp?topic=/com.vmware.vfabric.platform.5.1/vfabric/intro.htmlhttp://pubs.vmware.com/vfabric51/index.jsp?topic=/com.vmware.vfabric.platform.5.1/vfabric/intro.htmlhttp://pubs.vmware.com/vfabric51/index.jsp?topic=/com.vmware.vfabric.platform.5.1/vfabric/intro.htmlhttp://blogs.vmware.com/vfabric/https://www.youtube.com/watch?v=V3o4VNkTyTYhttp://www.vfabgirl.com/?p=33


140/141

10 Reasons VMware

APP-CAP2860


141/141

10 Reasons VMwarevSphere Is the Best Place

to Run Java

Benjamin Corrie, VMware, Inc.

cap2860-10 reasons vmware vsphere is the best place to run java_final_us.pdf

Documents