Landlust Haslam Deployment Patterns For Fusion Middleware 11g v2

Deployment patterns
for Fusion Middleware

a best practice session by
Simon Haslam & Jacco H. Landlust
1
maandag 10 oktober 2011
`id jacco`
Oracle Since 2000, Linux since 2001
Independent Red Stack Administrator
Oracle ACE since 2006
Infrastructure: Architecture, High Availability,

Troubleshooting & Performance
http://oraclemva.wordpress.com
2
`id simon`
Oracle since 1996 (UNIX since 1989)
Founded Veriton in 1996
Oracle ACE Director since 2009
Arhitecture, Design, Installation
http://simonhaslam.co.uk
3
Disclaimer
Best practices of our (Limited) experience
We are not working for Oracle
We do not pretend this list is complete
We are not native American speakers

4
Agenda
Best Practices for Designing a Fusion
Middleware 11g Infrastructure
5
Normal Design Process
1. Some product is bought (or build in-house) that
runs on FMW 11g
2. Buy some kit
3. a DBA is sent to OU to get training
4. The week after training DBA has to build and
maintain a production platform with help from one
or more developers
5. Start running production (and into trouble... )
6
Gartner
8 - 12 % TCO in Design + Develop + Test
88 - 92 % TCO in Maintaining
7
Middleware is not
Trivial
Its (mission) critical
Complicated: lots of moving parts
Get involved in projects from the start

8
Domain
Node Manager
Node Manager
Machine A Machine B
AdminServer
Cluster
Managed Server
Managed Server
Managed Server
9
Real Agenda
1. Logical Design
2. Physical Implementation
3. Maintaining, the Full Life Cycle
10
Logical Design
11
Decide upon
Denitions
Before you design the infrastructure
Brief your whole team (including

management)
Clear naming convention

12
Document your
Train of Thought
Tedious but usefull for future use
Dont wait till after the project /

implementation
Mark facts as facts and opinions as opinion
Formulas and rules

13
We Love Pictures
Node 2 Node 1
SOA Cluster SOA
CRS
SOA
CRS
SAN 2 SAN 1
ACFS
WLS WLS
If its to complicated too draw on
a diagram, its most likely wrong
14
Segregation between
Environments
DTAP & SOD
Separation of servers & network

15
Design for Security
SOD
SSL whenever possible
Also in DEV
Firewall
Connection Filters
16
Dont mix Layered
Products in One
Domain
oracle_common scripts
dependencies on upgrade / patching

17
Nodemanager:
Domain vs Node
Node specic: settings are domain wide
Domain specic conguration
Separation of OS users
SSL trust-stores
18
Separate
System Components
from
Java Components
Automatic network separation
Different purpose
19
Never run Apps in
AdminServer
Mixture of management tooling &

customer applications
Difcult troubleshooting
20
Cluster Everything
From the start (one node cluster)
Find unexpected behaviour because of

cluster as soon as possible
Extending clusters is easy

21
Separate Directories
Use personal accounts for administrators
Separate application users from

infrastructure users
22
Physical Implementation
23
x86
Weve only seen x86/x64 customers

running Linux
Buy the fasted kit you can get

24
Scale-up vs
Scale-out
Larger JVM give more GC issues
Our customers do scale-out
SAME
25
Virtualization
Not for vmotion-like functionality
Cloning (if you put the effort into it)
Partition hardware
26
Operating System
Dont adopt a new OS because of WLS
The best OS is the one youre an expert at

27
Shared Storage
NFS
OCFS2
GFS2
ACFS
rsync
28
Shared Storage:
take notice of
HTTP lockles
Large logles
UCM tmpdirs
29
Use VIPs
whenever Possible
Faster failover upon node failure
Easier to rebuild on new node
Logical separation of application and

machine
30
Get a LoadBalancer
Performance
Stability
SSL ofoading
31
oraInventory in
MW_HOME
oraInventory only used by installers &

oPatch
self-contained package
easier backups
32
Separate Binaries
from Conguration
Replace binaries more easy
Local disk for binaries
Backup conguration
33
Only use Java-based
Nodemanager
Easier to setup
Lots of bugs exist for script-based

nodemanager
SSL is a pain on script based nodemanager

(if not impossible)
34
Separate
AS from MS
On different boxes
Easier upgrade path
No interference of management tooling
(if you have the licenses)

35
Setup AdminChannel
(and port)
Separate admin trafc from application
Dedicated listen thread
Has to run over SSL

36
JDBC
min-connections = max-connections
Statement cache size < open_cursors
FAN (GridLink) when on RAC

See session #20942 13:15 on Wednesday
37
Centralize
Conguration
No congles that need to be changed in

JAR/EAR les
No environment dependent ear-les.
Easier to maintain
38
Logging
Centralize logging
Logrotation on size + time
Easier troubleshooting
39
Standardize
Troughout all environments
Easier troubleshooting (at 2 AM)

40
Automate
Standardizes installation
No differences between prod and test

41
Test Test Test
Find bugs before go-live
Benchmark
Stress test until break
Predictable performance
42
Maintaining
the full life cycle
43
Track Changes
Audit provider
Record changes with WLST

44
Record Incidents
adrci:
-
Build-in fault diagnostibility infrastructure
-
Health monitor reports
-
Package incidents & problem information
45
learn WLST
mBeanbrowser
Automating tasks
46
Manage deployments
Learn Ant
CloningClient.jar
No environment specic ear-les
Plan.xml
47
Out of Place
Upgrades
48
Grid Control
Stack monitoring
SLA checks
Corrective action library

49
MOS
Congurations
Not OCM per-se
Faster SR handling
50
Summary
51
rst Think, then Act
52
Standardize
&
Automate
53
Document & Test
54

Landlust Haslam Deployment Patterns For Fusion Middleware 11g v2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Landlust Haslam Deployment Patterns For Fusion Middleware 11g v2

Transféré par

Droits d'auteur :

Formats disponibles

Deployment patterns

for Fusion Middleware

Oracle Since 2000, Linux since 2001

Independent Red Stack Administrator

Oracle ACE since 2006

Infrastructure: Architecture, High Availability,

Oracle since 1996 (UNIX since 1989)

Founded Veriton in 1996

Oracle ACE Director since 2009

Arhitecture, Design, Installation

Best practices of our (Limited) experience

We are not working for Oracle

We do not pretend this list is complete

We are not native American speakers

8 - 12 % TCO in Design + Develop + Test

Its (mission) critical

Complicated: lots of moving parts

Get involved in projects from the start

Before you design the infrastructure

Brief your whole team (including

Clear naming convention

Tedious but usefull for future use

Dont wait till after the project /

Mark facts as facts and opinions as opinion

Formulas and rules

DTAP & SOD

Separation of servers & network

SSL whenever possible

dependencies on upgrade / patching

Node specic: settings are domain wide

Domain specic conguration

Automatic network separation

Mixture of management tooling &

From the start (one node cluster)

Find unexpected behaviour because of

Extending clusters is easy

Use personal accounts for administrators

Separate application users from

Weve only seen x86/x64 customers

Buy the fasted kit you can get

Larger JVM give more GC issues

Our customers do scale-out

Not for vmotion-like functionality

Cloning (if you put the effort into it)

Dont adopt a new OS because of WLS

The best OS is the one youre an expert at

Faster failover upon node failure

Easier to rebuild on new node

Logical separation of application and

oraInventory only used by installers &

Replace binaries more easy

Local disk for binaries

Lots of bugs exist for script-based

SSL is a pain on script based nodemanager

Easier upgrade path

No interference of management tooling

(if you have the licenses)

Separate admin trafc from application

Dedicated listen thread

Has to run over SSL

Statement cache size < open_cursors

FAN (GridLink) when on RAC

No congles that need to be changed in