Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

© 2010 IBM Corporation IBM System z Software Mehrwert von WebSphere Application Server auf IBM System z Andreas Gröschl IT Specialist for WebSphere on.

Ähnliche Präsentationen


Präsentation zum Thema: "© 2010 IBM Corporation IBM System z Software Mehrwert von WebSphere Application Server auf IBM System z Andreas Gröschl IT Specialist for WebSphere on."—  Präsentation transkript:

1 © 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

2 © 2010 IBM Corporation 2 WebSphere Application Server (WAS) ist auf vielen Plattformen verfügbar IBM System x Application Server WindowsLinux IBM Power Systems (System p and System i) Application Server IBM iIBM AIXLinux IBM System z Mainframe Application Server z/OSLinux 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.

3 © 2010 IBM Corporation Hardware Architecture WebSphere Application Server for z/OS Platform Operating System (z/OS) Integration Business Fabric WSRR PortalESB Process Server WLMRRS RACFXCF Welche Produkte basieren auf WebSphere Application Server für z/OS?

4 © 2010 IBM Corporation 4 Gibt es etwas zu beachten beim Designen und Schreiben von Java code, der auf WebSphere z/OS laufen soll? Antwort: 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?

5 © 2010 IBM Corporation z/OS Distributed In anderen Worten – Das gleiche “Look and Feel“. Welche Admin Console ist welche?

6 © 2010 IBM Corporation 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,diagnosticProvid er=true,version= ,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,diagnosticProvide r=true,version= ,type=DeploymentManager,mbeanIdentifier=DeploymentManager,cell=Dmgr01,spec= 1.0 ' Wsadmin Skripting auf z/OS vs. distributed

7 © 2010 IBM Corporation 7 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

8 © 2010 IBM Corporation 8 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 Hardware Logically Partitioned zOS z/OS Guest WebSphere Application Server für Linux WebSphere Application Server für z/OS Guest IFL zOS Coupling Facility LPAR or CEC Parallel Sysplex Linux for System z als eigene LPAR Mö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 Gast Sehr weit verbeitet. Diese Variante bietet exzellente Virtualisierung mit zVM) and Linux und läuft auf dem IFL. z/OS als zVM Gast Ein 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 Umgebung WAS 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 Umgebung Das 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.

9 © 2010 IBM Corporation 9  SecurityFewer points of intrusion  ResilienceFewer Points of Failure  PerformanceAvoid Network Latency  OperationsFewer parts to manage  EnvironmentalsLess Hardware  UtilizationEfficient use of resources  ScalabilityBatch and Transaction Processing  AuditabilityConsistent identity  SimplificationProblem Determination/diagnosis  Transaction IntegrityAutomatic recovery/rollback Client 1 st Tier 2 nd Tier 3 rd Tier App Server z/OS Database Server Networked Web Serving vorher Multiple Data Copies Potentielle Vorteile von Konsolidierung von Anwendungen und Daten Client 1 st Tier 2 nd Tier IMS CICS DB2 Standard CP nachher Integrated z/OS Application & Database Servicing z/OS Data Power WAS zAAP IFL Linux Integrated Application & Database Server Single Data View Die Konsolidierung einer Multi-Tier Architektur

10 © 2010 IBM Corporation 10 Präsentations- logik Geschäfts- logik Daten - logik DB2  Der Effect der Verlagerung von Geschäftslogik zu den Daten auf z/OS: um 77% reduziert –Die durchschnittliche CPU-Zeit pro EJB Transaktion wurde um 77% reduziert. –Das transferierte Datenvolumen pro EJB Transaktion wurde um 99% reduziert. Quelle: Optimizing WebSphere Performance on DB2, WP Der Vorteil der Datennähe: Ein PoC aus der Transport-Industrie Durchschnittliche CPU-Zeit pro trx (ms)‏ Datenvolumen pro Transaktion (KB)‏ Durchschnittliche CPU-Zeit pro trx (ms)‏ Datenvolumen pro Tranaktion (KB)‏ Präsentations- logik Geschäfts- logik Daten- logik Distributed

11 © 2010 IBM Corporation WAS V6.1 JDBC Type 4 Linux DB2 V8.1 DDF 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 DDF z/OS 8 CPUs im shared pool (91% busy) z Series Server : z9-EC, 8 x 1.7 GHz, 64 GB RAM WAS V6.1 JDBC Type 4 z/OS DB2 V8.1 z/OS 8 CPUs (91% busy) z Series Server : z9-EC, 8 x 1.7 GHz, 64 GB RAM WAS V6.1 JDBC Type 2 unterschiedliche Maschinenunterschiedliche LPARsgleiche LPAR 150 Transaktionen pro Sekunde 160 Transaktionen pro Sekunde 243 Transaktionen 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 + 62% Ergebnis eines WebSphere z/OS Co-location Benchmarks

12 © 2010 IBM Corporation 12 LPAR Die Nutzung von lokalen Cross-Memory Konnektoren Immer wenn WebSphere und weitere Zielsysteme wie DB2, CICS und MQ auf einer LPAR liegen, kann von lokalen Konnektoren profitiert werden. Datenzugriff: CRSR AppServer DB2 JDBC Type 2 CICS CTG Local MQ Bindings 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 Overhead Lokale 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 LPAR LPAR memory CRSR AppServer CRSR AppServer Cross Memory COMM Eine Erweiterung: Die neuen Optimized Local Adapters (WOLA) …

13 © 2010 IBM Corporation 13 AppServer (WAS z/OS) Servant Region JVM App WLM Queues Servant Region JVM 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

14 © 2010 IBM Corporation 14 Intelligente Priorisierung von unterschiedlichster Workload auf z/OS Klassifizierung und Prioriserung von einzelnen Transaktionen durch den z/OS Workload Manager (WLM) möglich. Controller RegionServant Region JVM Application(s) Servant Region JVM Application(s) _____ WLM Einkommende Requests HTTP / HTTPS IIOP MDB 213 Pull 4 Niedrigere Priorität o. unklassifiziert Hohe Priorität Niedrigere Priorität Der JVM werden mehr System Ressourcen zugewiesen Dieser JVM werden weniger System Ressourcen zugewiesbade n 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.

15 © 2010 IBM Corporation 15 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

16 © 2010 IBM Corporation 16 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. CRSR AppServer General Processor ohne zAAPs CRSR 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

17 © 2010 IBM Corporation Voraussichtlicher z10 CPU-Bedarf – Projektion und Vergleich Projektion der Testergebnisse auf die z10 (fester Faktor) SummeCPzAAPzIIP KVNeu zWAS SummeCPzAAPzIIP KVNeu zWAS 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 (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

18 © 2010 IBM Corporation 18 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

19 © 2010 IBM Corporation 19 Startpunkt – Wiederbenutzung von bestehenden WAS EJB Assets Mehr 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.

20 © 2010 IBM Corporation 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 eingeführt, erweitert mit WAS 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 CRSR DMGR Daemon Shared Space WOLA CICS Assembler/Cobol/PLI/C or C++ z/OS Batch Assembler/Cobol/PLI/C or C++ UNIX Systems Services Assembler/Cobol/PLI/C or C++ Airline Control System Assembler/Cobol/PLI/C or C++ WOLA bi-direktionale Pfade! Cross memory “Local Comm” CRSR AppServer IMS Assembler/Cobol/PLI/C or C++ WOLA Neu in ! LPAR

21 © 2010 IBM Corporation 21 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. CRSR DMGR Daemon Shared Space CRSR AppServer CRSR AppServer Cross memory “Local Comm” LPAR CRSR AppServer CRSR AppServer Daemon CR Shared Space Data Buffers Server Storage Data Buffers Above the bar owned by Daemon

22 © 2010 IBM Corporation 22 Ein High-Level Überblick der WOLA Implementierung Local Comm External Address Space Assembler/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 EJBs JCA External WOLA APIs Der Daemon verwaltet den gemeinsamen above-the-bar Storage, in dem die WOLA Registierungen erfolgen und die Daten ausgetauscht werden

23 © 2010 IBM Corporation 23 Die WOLA Schnittstelle … mit Batch, CICS, IMS Enterprise Java Bean (oder Servlet) Enterprise Java Bean WOLA Execute() ExecuteHome() WOLA JCA Adapter WOLA CICS Program WOLA BBO$/BBO# WOLA Modules/APIs Batch Programm WOLA Module/APIs WebSphere Umgebung CICS Umgebung Batch 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 BatchCICSWASDevelopment ToolIMS BMP/MPP/ IFP WOLA IMS ESAF IMS Dependent regions WOLA OTMA Eine WAS Anwendung kann eine existierende IMS Transaktion mittels WOLA über OTMA ohne Änderungen aufrufen.

24 © 2010 IBM Corporation 24 WOLA FIS – 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

25 © 2010 IBM Corporation 25 relative Vorteile für… WOLA IMS-C Teil von WebSphere Application Server für z/OS WOLA II mit WAS z/OS ausgeliefert, IMS als separate FMID die mit IMS ausgeliefert wird In der Lage, lokal oder remote IMS aufzurufen WOLA 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 WAS WOLA 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 WAS Weder IMS ICAL callout noch WOLA unterstützen dies bisher. Relativer Vergleich von WOLA und IMS Connect

26 © 2010 IBM Corporation 26 Ein einfaches Use-Case Szenario 1.Eine Flat Record Datei dient als Input für das Batch Programm 2.WAS 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 AppServer CICSIMS RRS Flat record file Batch Program LPAR Cell 14 WOLA Modules 23 Dieses Bild illustriert ein einfaches Use-Case Szenario: Ein Batch Programm nutzt eine bestehende EJB, um Daten in anderen Subsysteme zu aktualisieren Local Comm

27 © 2010 IBM Corporation 27 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

28 © 2010 IBM Corporation 28 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 Durchsatz Basiererend auf den CPU and Speicher Ressourcen des Benchmark Systems Web Services Normalisierter Durchsatz von “100” WOLA Relativer 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

29 © 2010 IBM Corporation 29 Neues Redpaper über WOLA

30 © 2010 IBM Corporation 30


Herunterladen ppt "© 2010 IBM Corporation IBM System z Software Mehrwert von WebSphere Application Server auf IBM System z Andreas Gröschl IT Specialist for WebSphere on."

Ähnliche Präsentationen


Google-Anzeigen