Deployment patterns for Fusion Middleware. a best practice session by Simon Haslam & Jacco H. Landlust

Size: px

Start display at page:

Download "Deployment patterns for Fusion Middleware. a best practice session by Simon Haslam & Jacco H. Landlust"

Tracy Bruce
10 years ago
Views:

1 Deployment patterns for Fusion Middleware a best practice session by Simon Haslam & Jacco H. Landlust 1

2 `id jacco` Oracle Since 2000, Linux since 2001 Independent Red Stack Administrator Oracle ACE since 2006 Infrastructure: Architecture, High Availability, Troubleshooting & Performance 2

2006 Infrastructure: Architecture, High Availability,

3 `id simon` Oracle since 1996 (UNIX since 1989) Founded Veriton in 1996 Oracle ACE Director since 2009 Arhitecture, Design, Installation 3

4 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

5 Agenda Best Practices for Designing a Fusion Middleware 11g Infrastructure 5

6 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

7 Gartner 8-12 % TCO in Design + Develop + Test % TCO in Maintaining 7

8 Middleware is not Trivial It s (mission) critical Complicated: lots of moving parts Get involved in projects from the start 8

9 Domain Machine A Machine B AdminServer Managed Server Cluster Managed Server Managed Server Node Manager Node Manager 9

10 Real Agenda 1. Logical Design 2. Physical Implementation 3. Maintaining, the Full Life Cycle 10

11 Logical Design 11

12 Decide upon Definitions Before you design the infrastructure Brief your whole team (including management) Clear naming convention 12

13 Document your Train of Thought Tedious but usefull for future use Don t wait till after the project / implementation Mark facts as facts and opinions as opinion Formulas and rules 13

14 We Love Pictures Node 1 SOA WLS CRS SOA Cluster Node 2 SOA WLS CRS ACFS SAN 1 SAN 2 If it s to complicated too draw on a diagram, it s most likely wrong 14

15 Segregation between Environments DTAP & SOD Separation of servers & network 15

16 Design for Security SOD SSL whenever possible Also in DEV Firewall Connection Filters 16

17 Don t mix Layered Products in One Domain oracle_common scripts dependencies on upgrade / patching 17

18 Nodemanager: Domain vs Node Node specific: settings are domain wide Domain specific configuration Separation of OS users SSL trust-stores 18

19 Separate System Components from Java Components Automatic network separation Different purpose 19

20 Never run Apps in AdminServer Mixture of management tooling & customer applications Difficult troubleshooting 20

21 Cluster Everything From the start (one node cluster) Find unexpected behaviour because of cluster as soon as possible Extending clusters is easy 21

22 Separate Directories Use personal accounts for administrators Separate application users from infrastructure users 22

23 Physical Implementation 23

24 x86 We ve only seen x86/x64 customers running Linux Buy the fasted kit you can get 24

25 Scale-up vs Scale-out Larger JVM give more GC issues Our customers do scale-out SAME 25

26 Virtualization Not for vmotion-like functionality Cloning (if you put the effort into it) Partition hardware 26

27 Operating System Don t adopt a new OS because of WLS The best OS is the one you re an expert at 27

28 Shared Storage NFS OCFS2 GFS2 ACFS rsync 28

29 Shared Storage: take notice of HTTP lockfiles Large logfiles UCM tmpdirs 29

30 Use VIP s whenever Possible Faster failover upon node failure Easier to rebuild on new node Logical separation of application and machine 30

31 Get a LoadBalancer Performance Stability SSL offloading 31

32 orainventory in MW_HOME orainventory only used by installers & opatch self-contained package easier backups 32

33 Separate Binaries from Configuration Replace binaries more easy Local disk for binaries Backup configuration 33

34 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

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

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

37 JDBC min-connections = max-connections Statement cache size < open_cursors FAN (GridLink) when on RAC See session # :15 on Wednesday 37

38 Centralize Configuration No configfiles that need to be changed in JAR/EAR files No environment dependent ear-files. Easier to maintain 38

39 Logging Centralize logging Logrotation on size + time Easier troubleshooting 39

40 Standardize Troughout all environments Easier troubleshooting (at 2 AM) 40

41 Automate Standardizes installation No differences between prod and test 41

42 Test Test Test Find bugs before go-live Benchmark Stress test until break Predictable performance 42

43 Maintaining the full life cycle 43

44 Track Changes Audit provider Record changes with WLST 44

45 Record Incidents adrci: - Build-in fault diagnostibility infrastructure - Health monitor reports - Package incidents & problem information 45

46 learn WLST mbeanbrowser Automating tasks 46

47 Manage deployments Learn Ant CloningClient.jar No environment specific ear-files Plan.xml 47

48 Out of Place Upgrades 48

49 Grid Control Stack monitoring SLA checks Corrective action library 49

50 MOS Configurations Not OCM per-se Faster SR handling 50

51 Summary 51

52 first Think, then Act 52

53 Standardize & Automate 53

54 Document & Test 54

WebLogic on Oracle Database Appliance: Combining High Availability and Simplicity

WebLogic on Oracle Database Appliance: Combining High Availability and Simplicity Frances Zhao-Perez Alexandra Huff Oracle CAF Product Management Simon Haslam Technical Director O-box Safe Harbor Statement