WebSphere Application Server V8 System Administration...

© 2011 IBM Corporation

IBM Proof of Technology

WebSphere Application Server V8 System Administration Update

Discovering business application services, featuring IBM WebSphere Application Server ND V8


IBM Proof of Technology - Discovering business application services, featuring IBM WebSphere Application Server ND V8

2

Agenda

§ OSGi § Centralized Installation Manager § High Performance Extensible Logging (HPEL) § HA Features



3

Agenda




How does OSGi help reduce cost?

§ Enforces architecture and simplifies maintenance § Enables modular deployment § Enables co-existence of multiple versions of libraries

– Simplifies independent evolution of applications – Better separation of concern between application and middleware

§ Enables truly dynamic update of modules within applications

4

Bundle

Bundle

Package

Class Class Class

Package

Class Class Class

Package

Class Class Class

Package

Class Class Class

Explicit exports

Explicit dependencies



OSGi Bundles and Class Loading § OSGi Bundle – A jar containing:

– Classes and resources. – OSGi Bundle manifest.

§ What’s in the manifest: – Bundle-Version: Multiple

versions of bundles can live concurrently.

– Import-Package: What packages from other bundles does this bundle depend upon?

– Export-Package: What packages from this bundle are visible and reusable outside of the bundle?

§ Class Loading

– Each bundle has its own loader.

– No flat or monolithic classpath.

– Class sharing and visibility decided by declarative dependencies, not by class loader hierarchies.

– OSGi framework works out the dependencies including versions.

5

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: MyService bundle

Bundle-SymbolicName: com.sample.myservice

Bundle-Version: 1.0.0

Bundle-Activator: com.sample.myservice.Activator

Import-Package: com.something.i.need;version=1.1.2

Export-Package: com.myservice.api;version=1.0.0



Declarative OSGi Services Using Blueprint

§ XML Blueprint definition describes component configuration and scope – Optionally publish and consume components to/from OSGi service registry. –  Standardizes established Spring conventions

§ Simplifies unit test outside either Java EE or OSGi r/t.

§  In WebSphere Application Server, the Blueprint DI container is a part of the

server runtime (compared to the Spring container which is part of the application.)

6

dependencies injected publishes service consumes

service

A static assembly and configuration of

components (POJOs)‏ Blueprint bundle

OSGI-INF/blueprint/ blueprint.xml



Blueprint Simplifies Service Dynamism

§ Dynamic service lifecycle is managed by the Blueprint container § Service reference injected by container

– service can change over time – can be temporarily absent without the bundle caring

7

e-Commerce

<blueprint> <bean id=”shop” class=”org.example.ecomm.ShopImpl”>

<property name=”billingService” ref=”billingService” /> </bean>

<reference id=”billingService” interface=”org.example.bill.BillingService” />

</blueprint>

Billing

<blueprint> <service ref=”service” interface =

”org.example.bill.BillingService” /> <bean id=”biller” scope=”prototype”

class=”org.example.bill.impl.BillingServiceImpl” /> </blueprint>



How Do Enterprise Applications Use OSGi?

§ Enterprise OSGi focuses on application concerns including web technologies, fine-grained component assembly and access to persistence frameworks

– through exploitation of familiar Java EE technologies – in a manner suitable for a dynamic OSGi environment – using standards defined by the JCP and OSGi Alliance – introduces a multi-bundle Application archive

§ Enables enterprise Application containers and deployment systems to provide better support for:

– Sharing modules between applications – Multiple concurrent versions of modules – Dynamic update and extensions of applications

8

Application

Entities

Blueprint

Web components

<web.xml />

<persistence.xml/>

<blueprint.xml/>



OSGi Applications in WebSphere Applications Server § OSGi has been used internally in WebSphere Application Server since V6.1

and in Eclipse since R3.

§ Application-level exploitation is introduced in the WebSphere Application Server V7 Feature Pack for OSGi Applications and JPA 2.0 http://www.ibm.com/websphere/was/osgi

– Focused on modular development, deployment and management –  Informed by experience gained in Apache Aries –  Introduced the Blueprint-standardization of Spring XML bean definition format –  Introduced web application bundles (Java EE 5 web technologies) –  Integration with SCA for heterogeneous assembly and remote services. – Basic supports for application update and extension

§ OSGi Application support enhanced in WAS V8

–  In-place application update and extension – Post-deployment configuration – Performance Metrics –  Integrates with Java EE 6 web technologies

§ Development Tools support in RAD V8 for both WAS V7 and WAS V8: http://www.ibm.com/software/awdtools/developer/application/index.html

9



10

Dynamic Application Update of OSGi Apps

Application

Entities

Blueprint

Web components

<web.xml />

<persistence.xml/>

<blueprint.xml/>

APPLICATION.MF

§  Administratively preview new bundles before making updates §  In-place bundle update enables application to remain continuously available throughout the

update process



11

Dynamic Application Extension of OSGi Apps

§  Administratively add new functionality to deployed applications

§  Well-designed extensions result in zero application down-time as extensions are added and removed

TradeManager

TradeAPI

Application

TradeProvider2 (Extension)





12

No Java code changes; war modules -> bundles

Common, bundles may be easily factored out of the WARs and used at specific versions

Enhanced Modular Deployment Process

webA.jar WEB-INF/classes/servletA.class

WEB-INF/web.xml

META-INF/MANIFEST.MF


WEB-INF/web.xml



WEB-INF/web.xml


Bundle Repository

Import-Package


WEB-INF/web.xml


webA.war WEB-INF/classes/servletA.class

WEB-INF/web.xml

WEB-INF/lib/…

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar


WEB-INF/web.xml

WEB-INF/lib/…

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar


WEB-INF/web.xml

WEB-INF/lib/…

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar


WEB-INF/web.xml

WEB-INF/lib/…

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar



13

No Java code changes; war modules -> bundles

Common, bundles may be easily factored out of the WARs and used at specific versions

Enhanced Modular Deployment Process


WEB-INF/web.xml



WEB-INF/web.xml



WEB-INF/web.xml


Bundle Repository

Import-Package


WEB-INF/web.xml



WEB-INF/web.xml

WEB-INF/lib/…

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar


WEB-INF/web.xml

WEB-INF/lib/…

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar


WEB-INF/web.xml

WEB-INF/lib/…

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar


WEB-INF/web.xml

WEB-INF/lib/…

• Manage multiple versions of libraries across an enterprise • Isolate application

dependencies from the server runtime

• Centralized location to deliver critical fixes

• Flexibility to update to new versions one app

at a time

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar

logging f/w jar

persistence f/w jar

MVC f/w jar

DI f/w jar



Bundle Repository for Modular Deployment

14



Isolated and Shared Bundles §  In Java EE, modules are isolated within an application and applications are

isolated from one another. – Makes sharing modules difficult

§  In OSGi all bundles have shared visibility to the externals of all others bundles within an OSGi framework (JVM)

– Makes isolating applications difficult

15

Java EE App Server

Everything isolated Everything shared

EAR 1

Module A

Module B

Module C

EAR 2

Module A

Module G

Module C

OSGi v4.2 Framework

Isolation

Sharing



Isolated and Shared Bundles

16

§  The Equinox OSGi f/w used by WAS enables “composite bundles” to run in isolated child frameworks

–  WebSphere installs each OSGi Application into an isolated child framework. –  Shared bundles are installed into the (single) parent framework.

Everything isolated Everything shared

OSGi v4.2 Framework Java EE App Server

EAR 1

Module A

Module B

Module C

EAR 2

Module A

Module B

Module C

Java EE App Server

EAR 1

Module A

Module B

Module C

EAR 1

Module A

Module B

Module C

EAR 2

Module A

Module B

Module C

EAR 2

Module A

Module B

Module C

OSGi Applications in WAS

EBA 1

Bundle A

Bundle B

Bundle C

EBA 2

Bundle A

Bundle G

Isolated framework

Isolated framework

Shared framework



Application-centric Bundle Management

17

§  EBA Archives are installed as Application Assets in WAS Systems Management



Application-centric Bundle Management

§  Updates are pre-validated for resolution consistency before being committed §  Only the modified bundle(s) are installed §  In V7, the update takes effect after the application is restarted

18



Enhancements in V8 – in-place update

19

In-Place Update



Enhancements in V8 – post deployment configuration

20

Post-Install Configuration



Enhancements in V8 – in-place update

21

Deployment Manifest

“Fixed” Deployed Result:

- Fully-resolved - Locked-down versions

some.eba Deployment Manifest

New “Fixed” Deployed Result:

- Fully-resolved - Locked-down versions

some.eba

Provide any new configuration

§  Service dynamicity is exploited most easily using the Blueprint component model.

–  Container blocks requests while service is replaced

Note: If a web application bundle is restarted, web client traffic will see brief unavailability of service.



22

Agenda




23

What’s new in Centralized Installation Manager in V8

§  CIM is now available from the Job Manager §  Remotely drive IBM Installation Manager §  Install WebSphere Application Server, IBM HTTP Server, Application Clients, DMZ Secure

Proxy Server, Web Server Plug-ins and WebSphere Customization Toolbox §  Support job scheduling §  Support multiple cells §  Better scalability



24

WebSphere Application Server V8 CIM in Job Manager

Separation between Job Manager, Target Hosts and IM repositories.

CIM

IM Install Kit; Response File Install jobs

IM repository (offerings)

Host

Inventory info

Binary payload Job Mgr

IM install kits

IM



25

New Centralized Installation Manager Jobs

§  Inventory §  Install, update and uninstall Installation Manager (New capability in version 8) § Manage offerings (e.g. install, update, uninstall WebSphere Application Server) § Manage profiles (New capability in version 8) § Run command (New capability in version 8) §  Install SSH public key § Distribute, collect and delete file (New capability in version 8) § Test connection § Add or search Installation Manager agent data locations



26

Supported platforms and software

§  Supported platforms – Windows, Linux, AIX, Solaris, HP-UX, IBM i and z/OS

§  Supported Installation Manager version – Version 1.4.3 and later

§  Supported WebSphere Application Server version –  Install and uninstall of WebSphere Application Server V8 and the supplemental products

•  IBM HTTP Server •  Web Server Plug-ins •  WebSphere Customization Toolbox •  Application Client •  DMZ Secure Proxy Server



27

Centralized Installation Manager in Job Manager



28

Register a New Host



29

Target Properties



30

Add Installation Manager Installation Kit



31

Install IBM Installation Manager



32

Select Targets



33

Input the Job Parameters



34

Schedule Job



35

Review Job Parameters



36

Job Status



37

Target Resources



38

Other CIM Jobs



39

Agenda




40

What is HPEL and its Objectives

§ What is HPEL – High Performance Extensible Logging (HPEL) – New streamlined way of doing log and trace where logs are stored in binary

format. – Tools and API for simple access and filtering capabilities

§ HPEL Objectives – Improve performance – Make it easier to work with stored log and trace data – Provide a common logging solution for z/OS® and distributed platforms – Remove barriers to extensibility by allowing simple programmatic access to log

data



41

Value of HPEL §  Binary format with simple tools means:

– No more parsing of text with multiple formats – More data available, no truncation of logger names –  Flexibility to add information as needs arise – No more need to understand what is stored in what files and how rollover may impact which files to

review – No need to clear logs before a server restart – Speeds up logging and tracing

•  Log primitive over 6x faster than WAS v7 •  Trace primitive 3.8x faster than WAS v7

§  Trace speed improvements makes burdensome traces more reasonable and can allow applications to log more data with less performance penalty

–  Trace performance has half the impact of legacy –  Impact on applications varies based on amount of logging and tracing being done

§  Tools and the API specifically enable – Access to logs on local and remote servers – Advanced filtering to quickly eliminate noise and get to source of a problem – Merging of logs from different servers (API only)

§  Common solution for z/OS and distributed means the same PD skills/people can work in all environments



42

Enabling and Configuring HPEL

§ Only one logging framework can be active at any given time. Legacy (Basic Mode) is the default

§ Enabling HPEL – HPEL can be enabled by navigating to

the server “Logging and Tracing” panel and clicking on the “Switch to HPEL Mode”

– For z/OS platforms, the panel is slightly different where the “change log and trace mode” has to be clicked on to see the “Switch to HPEL Mode” button.

§ Once the configuration has been saved

and the server has been restarted, the HPEL Mode will be in effect



43

Enabling and Configuring HPEL (cont'd)

§ The HPEL configuration includes three types of information to configure

– Log data – binary files representing logged information

– Trace data – binary files representing trace

– Text log – optional text file similar to SystemOut.log.

§ The default configuration for HPEL is a good starting point, and the configuration details are generally not needed in order to analysis or PD on the logs § Text log should be disabled in an optimized production environment by selecting “Configure HPEL text log” and deselecting “Enable text log”



44

Command Line HPEL Log Viewer

§ Once HPEL is enabled and configured, the user is no longer required to understand the details of the individual files to do analysis.

§  The command line log viewer is one tool which can be used to perform problem determination with the log and trace in the repository.



45

Command-Line HPEL LogViewer

§ To get a listing of available LogViewer options: logViewer -help

§ LogViewer invoked from a profile's bin directory without any options will result in a display of all the log and trace messages of a server

§ To view the log and trace entries of the most recent server run: logViewer -latestInstance



46

Command-Line HPEL Log Viewer

§ Combining options to get a specific logger pattern (such as an application logger) that matches SEVERE level from most recent server run logViewer -includeLoggers ”com.ibm.*" -latestInstance -level WARNING



47

Agenda




48

SIBus HA with MQ

§ WebSphere MQ V7.0.1 provides High Availability of Queue Manager – One Queue Manager instance failovers to another Queue Manager instance in a

different machine with different IP Address

§ WebSphere Application Server V7, does not provide SIBus MQLink High Availability

– SIBus MQLink does not provide failover support since, MQLink Sender Channel takes only one hostname and port number.

§ WebSphere Application Server V8 supports high availability of multiple connections between SIBus and WebSphere MQ V7.0.1

–  In WebSphere Application Server V8, to support WebSphere MQ HA capability, MQLink Sender channel has been updated to take multiple connection names which can be used to connect to the Queue Manager instance to which Queue Manager failovers.



49

SIBus HA with MQ - Configuration



50

Resource Workload Routing/HA

§ Resource failover and retry logic for relational datasources and JCA connection factories

– Simplifies application development •  Minimizes the application code required to handle failure of connections to relational

databases and other JCA resources •  Provides a common mechanism for applications to uniformly respond to planned or

unplanned outages – Administrator can tailor datasources and connection factory configuration based on

application needs: •  number of connection retries •  alternate/failover resource •  pre-population of alternate/failover resource connection pool •  auto failback

– Full control of functionality available to scripts and programs via management MBean



51

Resource Workload Routing/HA - Configuration



52

SIMPLIFIED CHINESE HINDI JAPANESE

ARABIC RUSSIAN TRADITIONAL CHINESE TAMIL THAI

FRENCH

GERMAN

ITALIAN

SPANISH

BRAZILIAN PORTUGUESE

WebSphere Application Server V8 System Administration...

Documents

Transcript of WebSphere Application Server V8 System Administration...