Oracle ADF Architecture TV - Deployment - System Topologies

1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.


Real World ADF Design & Architecture Principles Server Topologies

ORACLE PRODUCT

LOGO

15th Feb 2013 v1.0


Learning Objectives

•  At the end of this module you should be able to:

–  Identify a WLS topology that suits your requirements – Understand the restrictions of ADF Runtime Libraries & how this

impacts your WLS topology – Appreciate that high availability is a sliding scale of requirements

and can raise the costs of your systems significantly

Image: imagerymajestic/ FreeDigitalPhotos.net


Program Agenda

•  Server Topology Introduction •  WebLogic Server Topology •  System Topology


Server Topology Introduction

•  Investigate WLS server topologies and “system” topologies for ADF

•  Learning path –  Start with overly simplistic development topologies to assist learning –  Progress to considering production topologies

•  We will consider ADF infrastructure only –  No other Java EE (e.g. JMS) or FMW components (e.g. MDS or WebCenter)


WLS Topology Challenges & Considerations

•  How to support? –  Scaling –  Application failover and high availability –  Fine grained JVM tuning per application

•  How to control? –  Security –  Maintenance costs –  License costs


Program Agenda



WLS Quick Refresher

•  Hosts = physical or virtual machines •  Domains = cross server configurations •  Managed servers = run applications •  AdminServer = administrates managed

servers •  Node manager = starts managed servers

(not considered beyond here) •  JVM per managed server •  Cluster = collection of managed servers

Image: Oracle Fusion Middleware 11g Architecture and Management – McGraw Hill Oracle press


Minimal “Developer PC” Topology

•  1 ADF application •  1 WLS “AdminServer” (~managed server) •  1 WLS Machine •  1 ADF Runtime version •  1 WLS Domain

MachineY

AdminServer

ADF Runtimes V12.1.2

ADF v12.1.2 Application1

DomainA


Minimal “Developer PC” Topology

•  Advantages –  Little server configuration and maintenance –  JVM can be tuned to single application –  Low license costs

•  Disadvantages –  Really only suitable for Developer PCs –  Security risk in AdminServer used for applications –  No clustering, no high availability –  Application not tested for clustering


Multiple Application Topology

•  >1 ADF applications •  1 WLS “AdminServer” •  1 WLS Machine •  1 ADF Runtime version •  1 WLS Domain

Challenge addressed: Support multiple ADF applications

MachineX

AdminServer




ADF Runtimes v12.1.2

DomainA


Multiple Application Topology •  Advantages

–  Little server configuration and maintenance –  Running multiple applications –  Low license costs with one physical machine.

•  Disadvantages –  Really only suitable for Developer PCs –  Security risk in AdminServer used for applications –  No clustering, no high availability –  Application not tested for clustering

–  Can’t support multiple ADF Runtimes –  Host bounce reboots all applications –  One JVM has to cater for all application, can’t be tuned for 1 app


Multiple ADF Runtimes Topology

ADF Runtimes v12.1.2.0.0

•  Only 1 version of ADF Runtimes can be installed in a domain

•  = (1 Domain + 1 Machine + Managed Server) x ADF Runtime versions

•  ADF applications must be deployed to domain of same ADF Runtime version

Challenge addressed: Supporting multiple ADF applications on different ADF Runtime versions

DomainA

MachineX

AdminServer




DomainB

MachineY

AdminServer

ADF Runtimes V11.1.1.6

ADF v11.1.1.6 Application3


Multi-ADF Runtimes Topology

•  Advantages –  Run multiple applications on separate domains –  Host bounce limited to smaller subset of applications

•  Disadvantages –  Security risk in AdminServer used for applications –  No clustering, no high availability –  Application not tested for clustering –  JVM configuration still can’t be tuned for 1 app

–  Licensing costs –  Maintenance costs


Split AdminServer Topology

ADF Runtimes v12.1.2.0.0

•  AdminServer split from Managed Server •  Managed Server hosts ADF application

•  AdminServer still runs on same physical host to reduce license cost

•  Can be turned off when not in use

Challenge addressed: Reserving AdminServer for administration, creating separate managed server for application(s)

DomainA

MachineX

AdminServer ServerA_X_1




Split AdminServer Topology

•  Advantages –  AdminServer can be shutdown and restarted separate to application’s managed

server, enhancing security if needed –  JVM for manager server can be tuned for ADF application only

•  Disadvantages –  No clustering, no high availability –  Application not tested for clustering


Single Machine Cluster Topology

DomainA

MachineX

Cluster

AdminServer ServerA_X_1 ServerA_X_2



Instance2


Instance1 •  Managed servers host same ADF

applications •  Applications share state through

serialization

Challenge addressed: graceful application state failover


Single Machine Cluster

•  Advantages –  If application fails can switch over to other application instance on cluster –  Allows you to test failover – making it suitable for test environments –  Low license costs

•  Disadvantages –  If machine/host fails, all applications and state are lost –  Overhead of running 2 JVMs on one machine –  No scalability benefits


Multi Machine Cluster Topology

DomainA

MachineY

Cluster

AdminServer ServerA_Y_1 ServerA_Z_2



Instance2


Instance1 •  Managed servers host same ADF

applications, applications share state through serialization

•  Applications are split across machines •  Automatically restart failed nodes with

node manager

Challenge addressed: graceful application failover and scalability

MachineZ MachineX


Multi Machine Cluster

•  Advantages –  If application fails can switch over to other application instance on cluster –  Additional machines increase scalability of applications

•  Disadvantages –  Configuration and maintenance –  Hardware & license costs


Program Agenda



System Topologies

•  Consider suitable production topologies

•  Ignored discussing logical “VM” and physical hosts •  WLS topologies have been diagrammatically simplified to hide detail •  No consideration of high availability at the persistence layers


System Topology Challenges & Considerations

•  Scalability •  High availability and failover •  Security •  Compression and caching •  Others?


Assumptions

•  Following slides assume Oracle products will be used for all parts of the solution stack

•  3rd party products can be substituted, product names will vary

•  High availability of the Oracle RDBMS and Oracle Identity Management solutions will not be considered


Low Volume Topology

•  1 server is sufficient for load •  No interest in HA or failover •  WLS is authenticating/authorizing client via LDAP

RDBMS

LDAP

Managed Server

WLS Domain

Client(s)


Managed Server

WLS Domain

Non Clustered Scalable Topology

•  Scalability achieved by adding separate servers (physical) •  Load balancer splits requests and provides client session affinity •  Load balancer can be a hardware appliance or software HTTP proxy •  Application failover is not a requirement

RDBMS

Client(s)

Managed Server

WLS Domain

LDAP

Load Balancer


High Volume Topology

RDBMS

Client(s)

WLS Domain

LDAP

Load Balancer

Cluster

Managed Server(s)

Web Cache

HTTP Server

HTTP Server

•  HTTP servers offload processing from WLS including compression, SSL termination (if not done at the LB)

•  Web cache (or CDN) allows offloaded processing for serving static content •  Oracle Traffic Director can replace both these functions •  WLS Clustering gives high availability and failover

Web Cache


Active Active Topology

RDBMS

Client(s) WLS Domain

LDAP

Local Load

Balancer

Cluster

Managed Server(s)

HTTP Server

HTTP Server

RDBMS

WLS Domain

LDAP

Local Load

Balancer

Cluster

Managed Server(s)

HTTP Server

HTTP Server

Global Load

Balancer

•  Off site disaster recovery •  http://bit.ly/N7EiWa

Web Cache

Web Cache

Web Cache

Web Cache


Secure Topology

RDBMS

WLS Domain

LDAP Cluster

Managed Server(s)

HTTP Server

HTTP Server

Firewall

•  Internet delivered applications will use firewalls to isolate the external resources from the outside.

•  More than one firewall can be used to create a DMZ in case the first firewall is penetrated

DMZ

Firewall Firewall

Client(s) Load

Balancer

Web Cache

Web Cache


SSL Termination?

RDBMS

WLS Domain

LDAP Cluster

Managed Server(s)

HTTP Server

HTTP Server

DMZ

Firewall Firewall

Client(s) Load

Balancer

Web Cache

Web Cache

Image: imagerymajestic/ FreeDigitalPhotos.net

What are viable locations to terminate the SSL?

Do we need SSL on the inside too?


Conclusion

•  “High availability” as a requirement isn’t a yes or no answer

–  It’s a sliding scale of options –  The higher the HA requirement

• The more complex server topologies and configuration you require • The higher your license costs • The more staff you require to maintain the setup


Further Reading

•  Understanding WLS Domains http://bit.ly/USU7lX •  FMW High Availability Guide http://bit.ly/VHJhjn


Technology

Oracle ADF Architecture TV - Deployment - System Topologies