© 2010 IBM Corporation IBM System z Software Mehrwert von WebSphere Application Server auf IBM...

© 2010 IBM Corporation

IBM System z Software

Mehrwert von WebSphere Application Server auf IBM System z

Andreas Gröschl IT Specialist for WebSphere on z/OS

[email protected]

© 2010 IBM Corporation2

WebSphere Application Server (WAS) ist auf vielen Plattformen verfügbar

IBM System x

Application Server

Windows Linux

IBM Power Systems(System p and System i)

Application Server

IBM i IBM AIX Linux

IBM System z Mainframe

Application Server

z/OS Linux

Other

Application Server

Solaris

Open Standard Interfaces and Java Specifications

Platform-specific exploitation below the open standards

95%+ gemeinsamer Code

Der Rest ist plattformspezifischer Code.


Hardware Architecture

WebSphere Application Server for z/OS

Platform Operating System (z/OS)

Integration

Business Fabric

WSRR PortalESB

Process Server

WLM RRS RACF XCF

Welche Produkte basieren auf WebSphere Application Server für z/OS?


Gibt es etwas zu beachten beim Designen und Schreiben von Java code, der auf WebSphere z/OS laufen soll?

Antwort:

No!No!Java ist Java.

Der Vorteil eines Applikations-servers basierend auf offenen

Standards ist die Reduktion der Plattformabhänigkeiten

Unterscheidet sich Java auf dem Mainframe?


z/OS

Distributed

In anderen Worten – Das gleiche “Look and Feel“.

Welche Admin Console ist welche?


WZADMIN @ SC55:/WebSphereEd/wzcell/dmgr/DeploymentManager/profiles/default/bin>./wsadmin.sh –port 7010 –user wzadmin –password xyz –lang jython

WASX7209I: Connected to process "dmgr" on node wzdmnode using SOAP connector; The type of process is: DeploymentManager

WASX7031I: For help, enter: "print Help.help()"

wsadmin>AdminControl.completeObjectName("type=DeploymentManager,*")

'WebSphere:name=DeploymentManager,process=dmgr,platform=common,node=wzdmnode,diagnosticProvider=true,version=6.1.0.12,type=DeploymentManager,mbeanIdentifier=DeploymentManager,cell=wzcell,spec=1.0'

C:\zProducts\was61\AppServer\profiles\Dmgr01\bin>wsadmin -lang jython

WASX7209I: Connected to process "dmgr" on node Dmgr01 using SOAP connector; The type of process is: DeploymentManager

WASX7031I: For help, enter: "print Help.help()"

wsadmin>AdminControl.completeObjectName("type=DeploymentManager,*")

'WebSphere:name=DeploymentManager,process=dmgr,platform=common,node=Dmgr01,diagnosticProvider=true,version=6.1.0.9,type=DeploymentManager,mbeanIdentifier=DeploymentManager,cell=Dmgr01,spec=1.0'

Wsadmin Skripting auf z/OS vs. distributed


Reduktion des CPU Verbrauches durch:

Finanzielle Attraktivität durch Offload der Java-Workload auf zAAPs und zNALC Konditionen

Qualitity of Services durch WAS auf z/OS:

Komplette Integration ins Betriebssystem z/OS

Workload Manager (WLM), RACF Security und Tranaktionalität durch RRS

Intelligente Priorisierung der Workload

Konsolidierung der WAS Workload auf z/OS durch dynamische Ressourcenverwaltung

Bessere Verfügbarkeit durch die z10 Hardware und den WAS z/OS spezifischen Mini-Cluster (Multi-JVM Konstrukt)

Cross-Memory Kommunikation mit DB2 statt über das vergleichsweise rechenintensive TCP/IP Protokoll

Nutzung von Cross-Memory Kommunikaiton mit CICS und IMS statt IP-basierender Lösungen.

Intelligente Caching-Mechanismen auf z/OS mit FRCA

Mehrwerte von WebSphere auf z/OS


System z, z/OS, Linux, und WebSphere Application Server Auf der System z Hardware gibt es zwei unterschiedliche Ausprägungen vom WebSphere Application Server – WAS für Linux und WAS für z/OS

zVM

IFL

Linux for System z

System z HardwareLogically Partitioned

zOS

z/OSGuest

WebSphere Application Server

für Linux

WebSphere Application Serverfür z/OS

GuestIFLzOS

Coupling Facility

LPAR or CEC

Parallel Sysplex

1

2

3 4

5

Linux for System z als eigene LPARMöglich, aber nicht weit verbreitet. Die Lösung für Kunden, bei denen kein z/VM Skill vorhanden ist.

Linux for System z als zVM GastSehr weit verbeitet. Diese Variante bietet exzellente Virtualisierung mit zVM) and Linux und läuft auf dem IFL.

z/OS als zVM GastEin weiteres Beispiel für die Fähigkeiten der Virtualisierung durch zVM. WAS z/OS wird hier typischerweise in einer Entwicklungs- oder Test-Umgebung betrieben.

z/OS in einer non-Sysplex UmgebungWAS läuft direkt auf z/OS ohne zVM Virtualisierung. Eine Umgebung ohne Syplex wird typischerweiser nur in Test- oder kleinen Produktionsumgebungen verwendet.

z/OS in einer Parallel Sysplex UmgebungDas ist die Implementierung mit den besten Quality of Services. Hier haben wir die hohe Verfügbarkeit, Skalierbarkeit und den maximalen Nutzen an Plattform Spezifika.

WebSphere z/OS Design und Implementierung nutzt die Sysplex Fähigkeiten aus.


Security Fewer points of intrusionResilience Fewer Points of FailurePerformance Avoid Network LatencyOperations Fewer parts to manage Environmentals Less Hardware

Utilization Efficient use of resourcesScalability Batch and Transaction ProcessingAuditability Consistent identity Simplification Problem Determination/diagnosisTransaction Integrity Automatic recovery/rollback

Client

Client

Client

1st Tier 2nd Tier 3rd Tier

AppServer

AppServer

z/OSDatabase

Server

Networked Web ServingNetworked Web Servingvorher

Multiple Data Copies

Potentielle Vorteile von Konsolidierung von Anwendungen und Daten

Client

Client

Client

1st Tier

2nd Tier

IMSCICS

DB2

Standard CP

nachher

Integrated z/OS Application & Database Servicing

z/OS

DataPower

WAS

zAAP IFL

Linux

Integrated Application & Database Server

Single Data View

Die Konsolidierung einer Multi-Tier Architektur


Präsentations-logik

Geschäfts-logik

Daten-logik DB2

Der Effect der Verlagerung von Geschäftslogik zu den Daten auf z/OS:– Die durchschnittliche CPU-Zeit pro EJB Transaktion wurde um 77% reduziertum 77% reduziert.– Das transferierte Datenvolumen pro EJB Transaktion wurde um 99% reduziert.

Quelle: http://www.ibm.com/support/techdocs, Optimizing WebSphere Performance on DB2, WP100558

Der Vorteil der Datennähe: Ein PoC aus der Transport-Industrie

Durchschnittliche CPU-Zeit pro trx

(ms)

Datenvolumen pro Transaktion

(KB)

11.73

54.4

Durchschnittliche CPU-Zeit pro trx

(ms)

Datenvolumen pro Tranaktion

(KB)

2.64

0.5

Präsentations-logik

Geschäfts-logik

Daten-logik

Distributed


WAS V6.1

JDBC Type 4

Linux

DB2 V8.1

DD

F

z/OS

4 CPUs(32% busy)

4 CPUs (98% busy)

z Series Server : z9-EC, 8 x 1.7 GHz, 64 GB RAM

DB2 V8.1

DD

F

z/OS

8 CPUs im shared pool(91% busy)


WAS V6.1

JDBC Type 4

z/OS

DB2 V8.1

z/OS

8 CPUs(91% busy)


WAS V6.1

JDBC Type 2

unterschiedliche Maschinen unterschiedliche LPARs gleiche LPAR

150Transaktionen pro Sekunde



Wenn die Daten für Ihre bestehenden Java Enterprise Anwendungen bereits auf DB2 z/OS liegen, macht es aus technischer und finanzieller Sicht Sinn auch WAS z/OS in der gleichen LPAR zu betreiben. In diesem offiziellen Benchmark konnte der Durchsatz dadurch um 62% gesteigert werden.

Ermöglicht wird dieser hohe Durchsatz auf einer z/OS LPAR durch lokale Cross-Memory Kommunikation (JDBC Type 2) vom WAS z/OS mit dem DB2 z/OS . Ein Overhead durch Netzwerkprotokolle entsteht auf der gleichen LPAR nicht und reduziert damit auch den CPU-Verbrauch insgesamt.

Quelle: WebSphere z/OS – The Value of Co-Location Benchmark

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101476

+ 62%

Ergebnis eines WebSphere z/OS Co-location Benchmarks


LPAR

Die Nutzung von lokalen Cross-Memory KonnektorenImmer wenn WebSphere und weitere Zielsysteme wie DB2, CICS und MQ auf einer LPAR liegen, kann von lokalen Konnektoren profitiert werden. Datenzugriff:

CR SR

AppServer

DB2JDBC Type 2

CICSCTG Local

MQBindings

Vorteile:• Cross-Memory Geschwindigkeit

• Übertragung des Security Kontextes an andere z/OS Subsysteme

• Transaktionalität gewährleistet durch RRS im z/OS – ohne zusätzlichen Protokolle wie XA

• Vermeiderung der Serialisierung von Parametern

• Vermeidung von SSL OverheadLokale Kommunikation:Used for IIOP flows between servers on the same LPAR.

Vorteile:

• Die lokale X-memory Kommunikation benutzt keinen TCP/IP Stack

• Vermeidung von SSL Overhead

• Sehr schnell, sehr sicher

LPARLPAR memory

CR SR

AppServer

CR SR

AppServer

Cross Memory COMM

Eine Erweiterung: Die neuen

Optimized Local Adapters (WOLA)…


AppServer (WAS z/OS)

Servant Region

JVM

App App

WLM Queues

Servant Region

JVM

App App

90% Requests in 0.2 Sekunden

90% Requests in 1 Sekunde

Control Region

JVM

Request Gold Kunde

Request Silber Kunde

Verfügbarkeit: Bereits ein logischer Application Server kann aus mehreren Java Virtual Machines (JVM) bestehen.

Skalierbarkeit: Abhängig von der Auslastung kann der WLM automatisch zusätzliche JVMs starten.

Quality of Services: Die Workload kann durch den WLM priorisiert werden. SLA können definiert werden.

Verfügbarkeit und Skalierbarkeit - Ein logischer Application Server kann unter z/OS schon als Mini-Cluster aus mehreren JVMs bestehen, die je nach Last dynamisch gestartet werden können.

Definition von Service Level Agreements in Form von WLM Zielen ist möglich. Zum Beispiel können je nach Kundenstatus mehr Ressourcen zugeordnet werden.

Bessere Verfügbarkeit durch einen eingebauten Mini-Cluster


Intelligente Priorisierung von unterschiedlichster Workload auf z/OS

Klassifizierung und Prioriserung von einzelnen Transaktionen durch den z/OS Workload Manager (WLM) möglich.

Controller Region Servant Region

JVM

Application(s)

Servant Region

JVM

Application(s)

_____

_____

_____

_____

_____

_____

_____

WLM

Einkommende Requests

• HTTP / HTTPS• IIOP• MDB

21

3

Pull

Pull

4

Niedrigere Priorität o. unklassifiziert

Hohe Priorität

Hohe Priorität

Niedrigere Priorität

Der JVM werden mehr System Ressourcen zugewiesen

Dieser JVM werden weniger System Ressourcen zugewiesbaden

5

Hiermit können Anwendungen mit unterschiedlichsten SLA Anforderungen parallel betrieben werden. Der WLM versucht durch Zuweisung von zusätzlichen Ressourcen diese SLA's mit allen zur Verfügung stehenden Mitteln zu erfüllen und wird daran gemessen.


FRCA - Fast Response Cache Accelerator

FRCA ist ein sehr effizienter Cache, der vom TCP/IP Stack im z/OS zur Verfügung gestellt wird.

FRCA Funktionalität

FRCA API

TCP Stack

Physischer Adapter

In memory cache

(Data Space)

z/OS Operating System

Network

User System or Program

Benutzer

Wichtige Punkte:

• FRCA selbst ist nicht z/OS spezifisch … FRCA gibt es auch auf anderen Plattformen.

• FRCA ist ein sehr effizienter low-level Cache, der die CPU Verbauch reduzieren kann.

• Er ist ein wirklich sehr effizienter Cache

• Der Nutzen von FRCA ist sehr anwendungsabhängig.

• Je größer der statische Inhalt oder der cache-fähige dynamische Inhalt, desto größer ist der Mehrwert.

Nutzung des FRCA

Exits


Java-Workload kann auf den zAAP Prozessoren ausgelagert werden. Da für die auf dem zAAP keine Software Lizenzen benötigt werden, ist der zAAP für New Workload finanziell sehr attraktiv.

CR SR

AppServer

General Processor

ohne zAAPs

CR SR

AppServer

mit zAAPs

General Processor

zAAP Processor

Der Vorteil eines zAAPs:

• zAAP Prozessoren haben wesentlich geringe Anschaffungskosten gegenüber traditionellen Prozessoren (CPs)

• Der Offload von Java-Workload auf den zAAP erlaubt es traditionelle Workload parallel auf den CPs zu betreiben ohne finanzielle Auswirkung.

• Für die Java-Workload, die auf dem zAAP läuft müssen keine Software Lizenzen gezahlt werden.

Die komplette Workload wird vom CP

abgearbeitet

Non-Java Workload läuft auf dem CP, Java-Workload dagegen auf

dem zAAP

= Non-Java = Java

Work:

Abhängig von den Anwendungen können bis zu 90% der WebSphere Workload auf dem zAAP ausgelagert werden.

Der Mehrwert von zAAP Prozessoren


Voraussichtlicher z10 CPU-Bedarf – Projektion und Vergleich

Projektion der Testergebnisse auf die z10 (fester Faktor)

Summe CP zAAP zIIP

KVNeu zWAS 2.63 0.62 1.63 0.39

Summe CP zAAP zIIP

KVNeu zWAS 1.75 0.11 1.63 0.02

KVNeu dWAS 3.0 (Auslastung zu 70%)

Vergleich zu System p (Kaufmännische Betrachtung)

Realbedarf System z bei gleichem Durchsatz und Antwortzeit wie System p

KVNeu WAS System p 0.88 0.51 0.00 0.37(DB2 Hostanteil)

Gleicher Durchsatz und Antwortzeit wie bei System p (hochgerechnet)

Maximalwerte der Testdurchläufe

Vergleichbarkeit mit System p ist gewährleistet

zWAS benötigt 42% weniger CPU Ressourcen

Plattformvergleich im Versicherungsumfeld – WAS distributed vs. WAS z/OS – Eine Anwendung basierend auf Innovas HI


Kosten für das erste Jahr Kosten für Jahre 2-4

TCO Studie von einem großen IT-Dienstleister im Finanzsektor in Deutschland über WebSphere Application Server auf z/OS


Startpunkt – Wiederbenutzung von bestehenden WAS EJB AssetsMehr und mehr Kunden suchen eine Möglichkeit WAS z/OS EJB Assets aus bestehenden Batch Programmen oder aus anderen Subystemen wie CICS aufzurufen

WebSphere z/OS

EJB Assets

Batch Programs

CICS

Mehr und mehr Geschäftslogik wird in Form von EJBs

implementiert

Viele bestehende Lösungen sind designed worden, um aus dem WAS heraus (Outbound) andere Subsysteme aufzurufen.

Es gibt andere Lösungen für Verbindungen in den WebSphere herein (Inbound) zum Beispiel Webservices, aber keine erreicht vergleichbare Durchsatzraten wie WOLA.

WOLA wurde entwickelt, um eine eine hochskalierbare, transaktionale Inbound Lösung zur Verfügung zu stellen

Um das Bild zu komplementieren, wurde WOLA als bi-direktionale Lösung designed.


WebSphere Optimized Local Adapters – Was ist es?

eine hoch skallierbare transaktionale Kommunikationslösung

neue cross-memory Kommunikationsstruktur für WAS V7 und neuer, Erweiterung des internen WAS “Local Comm”

– im Mai 2009 in WAS 7.0.0.4 eingeführt, erweitert mit WAS 7.0.0.12

Diese Erweiterung ist realisiert durch ein neues Set von Modulen, die die API für Programme in externen Adressräumen zur Verfügung stellen, mit der diese mit WAS mittels des Deamon shared space Mechnismus kommunizieren können.

CR SR

AppServer

CR SR

DMGRDaemon

Shared Space

WOLACICSAssembler/Cobol/PLI/C or C++

z/OS BatchAssembler/Cobol/PLI/C or C++

UNIX Systems ServicesAssembler/Cobol/PLI/C or C++

Airline Control SystemAssembler/Cobol/PLI/C or C++

WOLA

WOLA

WOLA

bi-direktionale Pfade!

Cross memory “Local Comm”

CR SR

AppServer

IMSAssembler/Cobol/PLI/C or C++

WOLA

Neu in 7.0.0.12!

LPAR


Die Basis-Technologie für WOLA “Local Comm”

“Local Comm” ist eine intelligente Cross-Memory Lösung, die bisher für die Kommunikation zwischen einzelnen Server innerhalb einer Zelle und LPAR verwendet worden ist.

WAS benutzt Local Comm für die interne Kommuniktaion … zum Beispiel bei IIOP Verbindungen zwischen Servlet und EJB in unterschiedlichen

Servern. Kein TCP, kein SSL … sehr effizient.

CR SR

DMGRDaemon

Shared Space

CR SR

AppServer

CR SR

AppServer

Cross memory “Local Comm”

LPAR

CR SR

AppServer

CR SR

AppServer

Daemon

CR

Shared Space

Data Buffers

Data Buffers

Server Storage

Server Storage

Data Buffers

Above the bar owned by Daemon


Ein High-Level Überblick der WOLA Implementierung

Local CommExternal Address SpaceAssembler/Cobol/PLI/C or C++

WebSphere z/OS Cell auf einer LPAR

Externe Address Spaces benutzen die WOLA Module, um sich beim Daemon anzumelden und Local Comm zu verwenden.

Ein zur Verfügung gestellter JCA adapter stellt die Java outbound Schnittstelle zur Verfügung.

Für die inbound Kommunikation benötigt das EJB keinen WOLA JCA Adapter.

STEPLIB DD DSN=hlq.WOLA.LOADLIB

Die WOLA Implementierung wird durch APIs realisiert, die die Local Comm Funktion zur Verfügung stellen.

Shared Space

Daemon

AppServer

EJBsJCA

External

WOLA APIs

Der Daemon verwaltet den gemeinsamen above-the-bar Storage, in dem die WOLA Registierungen erfolgen und die Daten

ausgetauscht werden


Die WOLA Schnittstelle … mit Batch, CICS, IMS

Enterprise Java Bean(oder Servlet)

Enterprise Java Bean

WOLA Execute()ExecuteHome()

WOLA JCA Adapter

WOLA

CICS Program

CICS Program

WOLA BBO$/BBO#

WOLA Modules/APIs

Batch Programm

WOLA Module/APIs

WebSphere Umgebung

CICS UmgebungBatch Umgebung

EJBs initiieren einen Aufruf nach WOLA mittels eines vorhandenen

JCA-Adapters. Verschiedene WOLA spezifische Methoden ermöglichen

Service-Aufrufe

EJBs, die Ziel von WAS-inbound Aufrufen sind, implementieren die WOLA-eigenen Execute() und ExecuteHome() Klassen.

Aufrufe nach CICS werden über die WOLA-eigenen BBO$/BBO# tasks und Transaktionen vermittelt. Das Ziel-Programm in CICS bleibt unverändert, falls es über COMMAREA oder Channel/Container aufgerufen werden kann.

Ein CICS Programm, das einen outbound call initiieren will, muss die WOLA APIs nutzen

Ein Batch-Programm, das einen WAS aufrufen möchte, muss die

WOLA APIs nutzen.

Die verfügbaren WOLA Module/Klassen: STEPLIB, DFHRPL, DFSESL, ola.rar and ola_apis.jar Batch CICS WAS Development ToolIMS

BMP/MPP/ IFP

WOLA IMS

ESAF

IMS Dependent regionsWOLAOTMA

Eine WAS Anwendung kann eine existierende IMS Transaktion mittels WOLA über OTMA ohne Änderungen aufrufen.


WOLA FIS 7.0.0.12 – IMS Support - Basics

WOLA OTMA support

– Eine WAS Anwendung kann eine IMS Transaktion mittels WOLA über OTMA ohne Änderungen aufrufen

IMS WOLA APIs support

– die APIs erlauben es IMS Anwendungen in den folgenden IMS dependent regions, die WOLA APIs bidirektional zu nutzen, wenn beide auf dem gleichen z/OS System liegen

• Message Processing Programs (MPPs)

• IMS Fast path Programs (IFPs)

• Batch Message Programs (BMPs)

• Batch DL/I apps

– Basierend auf dem External Subsystem Attach Facility (ESAF)

• ‘WOLA’ subsystem – mit allen notwendigen EXITs (neue BBOAI- Module)

• WOLA APIs wurden erweitert, um zu erkennen, wann sie unter IMS laufen, um dann Requests an das WOLA Call ESAF exit zu leiten – und dann an WAS.

• Vorbereitungen für global transactions support


relative Vorteile für…

WOLA IMS-C

Teil von WebSphere Application Server für z/OSWOLA II mit WAS z/OS 7.0.0.12 ausgeliefert, IMS als separate FMID die mit IMS ausgeliefert wird

In der Lage, lokal oder remote IMS aufzurufenWOLA ist ausschließlich lokal nutzbar, IMS Connect unterstützt sowohl local mode als auch TCP-basierten Zugriff

Propagation/Zuweisung von User Identity von IMS nach WASWOLA kann User Credentials auf basis von thread-level ID in den WAS EJB container propagieren und zuweisen.

Bi-direktional und in der Lage, vorhandene IMS Transaktionen ohne Änderungen aufzurufen

Multi-segment messages WOLA über IMS OTMA unterstützt noch keine multi-segment messages. Coming soon.

WOLA ist eine ergänzende Technologie zu IMS Connect. Beide werden weiterhin ihre Berechtigung in einer Unternehmensarchitektur haben.

Global Transactions WAS nach IMS WOLA unterstützt dies noch nicht.

Global Transactions IMS nach WASWeder IMS ICAL callout noch WOLA unterstützen dies bisher.

Relativer Vergleich von WOLA und IMS Connect


Ein einfaches Use-Case Szenario

1. Eine Flat Record Datei dient als Input für das Batch Programm

2. WAS 7.0.0.4 WOLA modules werden über die STEPLIB im Batch JCL eingebunden

3. Das Batch Program nutzt WOLA APIs, um auf WAS zuzugreifen und das EJB aufzurufen

4. EJB startet Transaktionen in CICS, IMS mit Two-Phase Commit (2PC) mit WAS Connector Architektur

Daemon

Shared Space

CR SR

AppServerCICS

IMS

RRS

Flat record file

Batch Program

LPAR

Cell

14

WOLA Modules

2

3

Dieses Bild illustriert ein einfaches Use-Case Szenario: Ein Batch Programm nutzt eine bestehende EJB, um Daten in anderen Subsysteme zu

aktualisieren

Local Comm


Ein Performance-Vergleich zwischen WOLA und Web Services

Ein aktueller Benchmark vergleicht ein Web Services Aufruf vom WAS ins CICS mit einer WOLA Implementierung per X-Memory.

CICS Transaction Server

Program

WebSphere Application

Server

EJB

LPAR

SOAP/HTTP

SOAP/HTTP


Relativer Durchsatz für eine 100 Byte große Nachricht

Ein Vergleich des relativen Durchsatzes basierend auf dem Austausch einer 100 Byte großen Nachricht:

Small Messages(100 bytes)

Relativer DurchsatzBasiererend auf den CPU and Speicher Ressourcen des Benchmark Systems

Web ServicesNormalisierter Durchsatz von

“100”

WOLARelativer Durchsatz … im Verhältnis zur Web

Services Baseline

WOLA hatte einen 6X höheren Durchsatz

Wieso? Kein Netzwerk, kein XML Erstellung, kein XML Parsing, etc.

Performance measurements are dependent on many factors. Results vary. No guarantee of performance is implied by this chart


Neues Redpaper über WOLA

© 2010 IBM Corporation IBM System z Software Mehrwert von WebSphere Application Server auf IBM...

Documents

Transcript of © 2010 IBM Corporation IBM System z Software Mehrwert von WebSphere Application Server auf IBM...