Verwendung von Spezialprozessoren Der Host – Reloaded Verwendung von Spezialprozessoren Ralph Rohfleisch, Systemtechnik und Pascal Meyer, Anwendungsentwicklung | JBFOne 2009

Ziel dieses Vortrags Sie erfahren, welche Spezialprozessoren in einer zSerie aktiviert werden können Sie lernen die technische Implementation kennen Sie hören etwas über die wirtschaftlichen Auswirkungen Sie erfahren, in welchen Bereichen diese Prozessoren in der FIDUCIA eingesetzt werden und zukünftig eingesetzt werden könnten Sie erhalten einen Ausblick auf die zukünftige Entwicklung

Agenda Überblick über die Spezialprozessoren in einer z10 zIIP und zAAP IFL zFuture Zusammenfassung

Agenda Überblick über die Spezialprozessoren in einer z10 zIIP und zAAP IFL zFuture Zusammenfassung

Überblick über die Spezialprozessoren Quelle IBM © 2009

Hardware-Implementierung der Spezialprozessoren Auf einem Multichip Module befinden sich bis zu 20 PU-Cores, davon sind maximal 16 konfigurierbar Aus dieser physikalischen Implementierung werden auch die Spezialprozessoren definiert Ein Spezialprozessor unterscheidet sich damit weder bei der physikalischen Implementierung noch im Befehlssatz von einem “normalen klassischen” Prozessor Eine Ausnahme besteht bei den Kryptoprozessoren, die als gesonderte physikalische Implementierung auf der Crypto-Express-Adapterkarte ausgeliefert werden. Kryptoprozessoren werden jedoch üblicherweise nicht unter der Rubrik „Spezialprozessoren“ behandelt Quelle IBM © 2009

Spezialprozessoren auf der Zeitachse Quelle IBM © 2009

Agenda Überblick über die Spezialprozessoren in einer z10 zIIP und zAAP IFL zFuture Zusammenfassung

Die Motivation der IBM zur Einführung der Spezialprozessoren zAAP und zIIP war der zunehmende Wettbewerb Wettbewerb durch Distributed-Plattform Durch zunehmenden Wettbewerb mit den Distributed-Plattformen, insbesondere im Bereich der Unix-Systeme, wurde zunächst der Spezialprozessor zAAP in 2004 für JAVA-Workload eingeführt 2 Jahre später folgte der zIIP, der zunächst nur für Workload aus dem distributed Umfeld (für DB2-Workload nur über das DRDA/TCPIP Protokoll kommend, z. B. JDBC mit TYPE 4) verfügbar war Zielsetzung dieser Spezialprozessoren Beide Prozessoren wurden aus rein wirtschaftlichen Zielsetzungen bereitgestellt Das physikalische Design des Prozessors wird nicht verändert Workload, der nicht auf einen zAAP/zIIP dispatched werden kann, ist jederzeit auf einem klassischen Prozessor ausführbar Wirtschaftliche Sonderbedingungen bei zAAP/zIIP Die Hardwareanschaffung ist mit etwa 100TE pro Prozessor wesentlich günstiger als bei den klassischen Prozessoren Der auf zAAP/zIIP prozessierte Workload ist softwarekostenfrei Durch den Einsatz der Spezialprozessoren entstehen jedoch weitere Nebeneffekte, die in eine wirtschaftliche Betrachtung einfließen sollten

Die Nutzung der zIIP/zAAP ist unter den Betriebssystemen z/OS und z/VM möglich Alle CoD-Möglichkeiten (Capacity on Demand) sind für die Spezialprozessoren verfügbar Die IBM hat für eigene Anwendungen und für zertifizierte Hersteller von System- Anwendungssoftware ein Interface (API) bereitgestellt Die Implementierung des Interface gilt als sehr schwierig, weil bestimmte Instruktionssätze im SRB-Mode nicht zur Verfügung stehen Mit z/OS 1.11 kann auch zAAP-Workload auf zIIPs verarbeitet werden CP Work IBM Dispatcher zOS SE-API jeder Workload 80 % Usage of SE? No! Yes you can! Special Engine nur durch IBM bestimmter Workload und nur Systemmode (SRB) (Reduced Instructions)

Obwohl die Spezialprozessoren softwarekostenfrei sind, ist der Betrieb aus wirtschaftlicher Sicht mit Kosten verbunden zAAP / zIIP – Wirtschaftliche Betrachtung Erträge durch den Einsatz von Spezialprozessoren Durch den Einsatz der Spezialprozessoren entstehen keine Software-Kosten; weder MLC noch OTC noch Flat-Software-Kosten Durch den Einsatz der Spezialprozessoren können die klassischen Prozessoren entlastet werden, womit eine Investition in die teuren Prozessoren vermieden werden kann Aufwände durch den Einsatz von Spezialprozessoren einmalige Hardware-Anschaffung; ca. 100 TE Wartungskosten Reduzierung der Gesamtkapazität bei Einbau neuer Prozessoren; ca. 120 MIPS pro Prozessor an Kapazitätsreduzierung zIIP und zAAP stellen erhöhte Ansprüche an die Kapazitätsplanung und das Performancemanagement

Von vermutlich einem der ersten zIIP-Nutzer in Europa wurden diese bereits 2006 in Betrieb genommen zIIP-Einsatz bei der FIDUCIA IT AG IBM Case Study FIDUCIA IT AG http://www-03.ibm.com/systems/de/resources/ibm-2550-CS_FIDUCIA_LowRes.pdf Knapp 10 % des gesamten Workloads konnten im Bereich DB2 auf den zIIPs verarbeitet werden Per heute sind etwa 8.000 zIIP-MIPS zur Verarbeitung verfügbar

Die FIDUCIA startete eine zIIP-Initiative im Jahr 2008 IBM lieferte nach 2006 nur noch einige wenige Produkte mit zIIP-Support Daher bat die FIDUCIA IT AG im Jahr 2008 die großen Hersteller (BMC, CA, Compuware, SAS, SI) von Standard-Software in einem allgemeinen Anschreiben um Unterstützung der Special Engines Positive Rückmeldungen aus dem Markt Die Firma BMC implementierte Anfang 2009 die zIIP-Unterstützung in MainView (30 %-Offload) Die Firma SI (LDMS) implementierte im 3. Quartal 2009 zIIP-Unterstützung (5-10 % Offload-Potenzial) In der Zwischenzeit gilt die Unterstützung von Spezialprozessoren als wichtiges Merkmal bei der Produktauswahl BMC 300 Mips SI 50 Mips

Agenda Überblick über die Spezialprozessoren in einer z10 zIIP und zAAP IFL zFuture Zusammenfassung

Die IFLs sollen eine Server-Konsolidierung ermöglichen Unix Server Farms Integrated Facility for Linux Verfügbar seit 2000 Konsolidierung vieler Einzelsysteme mit geringer Auslastung unter z/VM Linux, Solaris, AIX … Geringere Hardware/Software-Kosten Einfacherer effizienterer Betrieb Einfachere Infrastruktur Hosting von Applikationen mit hohem IO-Bedarf Annäherung von OpenSystems- und Mainframe-Anwendungen Flacheres Netzwerk Geringere Latenzzeiten Consolidation z/VM System Z IFLs

IFLs werden weltweit bei einigen großen Instituten produktiv eingesetzt Einige größere Projekte IBM intern: 4000 Server auf 5 z10 (2007 – 2009) Japanische Bank: exklusiver Betrieb unter zLinux Allianz: 60 produktive Wintel Server -> z10 (05/2009) US-Postal: 2 z10 für Oracle RAC (06/2009) Ansätze in der FIDUCIA DB2-Gateways LDMS-Server Oracle DB2 -> abgelöst LDMs -> Test / Migration FSV -> wurde auf Open verlagert Communication Network Services (IMSConnect / MQ Zugang zum Host) -> potentieller Kandidat Oracle -> Erfolgreicher PoC

Der Portierungsaufwand ist applikationsabhängig Jede Linux-Anwendung ist auch unter zLinux lauffähig … sofern sie Plattform- unabhängig kodiert ist In welcher Sprache, auf welcher Plattform läuft aktuell die Anwendung? Java Klassische Sprachen (C/C++, …): Little Endian/Big Endian nicht am Betriebssystem vorbei programmieren Codepage (von z/OS nach z/Linux -> Ebcdic / Ascii) Fazit: ein hoch qualitatives Testing ist während der Portierung erforderlich

PoC Oracle auf zLinux: Testaufbau OTMA DB2 UDF Oracle AQ MQ Series CEC IMS TM STC (BMP) FAQ-Gateway Batch - FU306 BLOB read/write MPP STProc Aufruf Accounting Massen Isrt zOS IP STack Lpar 1 Lpar 3 Int.con. Lpar 2 Hypersocket Hypersocket Int.con. Interconnecttest

PoC Oracle DB auf zLinux – Ergebnisse Masseninsert BLOBs Für den Test liefen auf jeder Instanz acht Batchjobs mit 64k-Blobs parallel Der Durchsatz bei Hypersocket steigt sowohl bei der Transaktionsrate als auch bei der Redosize gegenüber OSA2 um 50% an, gegenüber dem RIAT-Umfeld um ca. 100% (Wert im RIAT hochgerechnet)

PoC Oracle DB auf zLinux – Ergebnisse Stored Procedure Dieser Test adressiert die Netzlatenzproblematik der Onlinezugriffe von IMS auf die Oracle-DB (Beispiel: Stored Procedure-Aufrufe bei SEPA) Die Antwortzeit bei Hypersocket ist gegenüber OSA2 um Faktor 3 schneller gegenüber dem RIAT-Umfeld um Faktor 4 schneller

Beispielhafter Aufbau für die FIDUCIA Produktionsumgebungen CECX z/linux agree1 zOS agree1 MQ01 Series MGW AMI Hypersockets IMS1 ORA11 DB21 OCI UDF Horizon AQ HORIZON Portale OSA3 JDBC CECY z/linux agree1 zOS agree1 MQB1 Series MGW Hypersockets AMI IMB1 ORAB1 DB11 OCI UDF Horizon AQ

Beispielhafter Aufbau für die FIDUCIA Produktionsumgebungen z/linux agree1 zOS agree1 zOS agree3 MQ01 Series z/linux agree3 MQ03 Series ORA11 IMS1 DB21 ORA13 IMS3 DB23 z/linux agree2 zOS agree2 z/linux agree4 zOS agree4 MQ02 Series MQ04 Series ORA12 IMS2 DB22 ORA14 IMS4 DB24 CEC1 CEC3 z/linux agree1 zOS agree1 z/linux agree3 zOS agree3 MQB1 Series MQB3 Series ORAB1 IMB1 DB11 ORAB3 IMB3 DB13 z/linux agree2 zOS agree2 z/linux agree4 zOS agree4 MQB2 Series MQB4 Series ORAB2 IMB2 DB12 ORAB4 IMB4 DB14 CEC2 CEC4

Betrieb Oracle auf zLinux Potentieller Mehrwert für die FIDUCIA Die Nähe zu den klassischen Anwendungen ist gegeben Oracle-RAC kann mit dem gleichen Servicelevel wie die klassischen z/OS-Produkte betrieben werden keine/minimale Hardware Aufrüstung erforderlich Beibehalten der vorhandenen Betriebsverfahren Integration in die aktuelle Subsystem-Architektur (acht produktive agree Systeme) die Test/Integration/PIT/GIT/RIAT-Schulungssysteme können gemeinsame Hardware nutzen Wirtschaftlichkeit Einsparungen sind im Oracle-Lizenzbereich zu erwarten, da weniger CPUs lizenziert werden müssten. Dabei fällt die Vielzahl der Testsysteme besonders ins Gewicht höhere Kosten würden vor allem für den Hauptspeicher anfallen Energie-Ersparnis durch Konsolidierung der vorhandenen Hardware Personalaufwand im Regelbetrieb wird nahezu identisch oder etwas geringer sein in der Aufbauphase fallen Schulungskosten in SYT und ITB an

Agenda Überblick über die Spezialprozessoren in einer z10 zIIP und zAAP IFL zFuture Zusammenfassung

Besser geeignet für Distributed Unterschiedliche Anforderungen der Applikationen können am besten durch unterschiedliche Plattformen abgedeckt werden CPU Intensive – e.g. numerically intensive, etc. Protocol Serving – e.g. static HTTP, firewall, etc. Skewless OTLP – e.g. simple and predictable transaction processing Besser geeignet für Z Java™ Heavy – e.g. CPU intensive Java applications Java Light – e.g. data intensive Java applications Database – e.g. Oracle DBMS or dynamic HTTP server Mixed High – e.g. multiple, CPU-intense simple applications Mixed Low – e.g. multiple, data-intense applications or skewed OLTP, MQ Besser geeignet für Distributed I/O Bound – e.g. high I/O content applications Data Intensive – large working set and/or high I/O content applications

Der Hybrid Ansatz der IBM Management und Monitoring mehrerer Betriebssysteme als ein virtuelles System Beschleunigung von Mainframe Workloads Verbesserte QoS für Applikationen mit Nähe zu Mainframe-Daten Mainframe Integriertes System Management Accelerators und Blades + +

Beste Verfügbarkeit, Ausfallsicherheit, Sicherheit, … Die Umsetzung der zHybrid Architektur am Beispiel einer DB2-Applikation Anwendungen DBA-Tools, Console DB2 IBM Smart Analytics Optimizer Data Manager Buffer Manager Log Manager Beste Verfügbarkeit, Ausfallsicherheit, Sicherheit, … Fülle an günstigen Ressourcen Linux on Blades z/OS on z10

Agenda Überblick über die Spezialprozessoren in einer z10 zIIP und zAAP IFL zFuture Zusammenfassung

Zusammenfassung Die Spezialprozessoren zAAP und zIIP stellen einen wichtigen Faktor zur Senkung der TCO-Kosten auf der IBM z-Plattform dar Die technische Unterstützung der Spezialprozessoren ist eine Herausforderung für die Hersteller Der Einsatz entsprechender Software kann einen Wettbewerbsvorteil für den Anwender bedeuten Für Hersteller und Anwender ergibt sich bei erfolgreichem Spezialprozessor-Support eine Win-Win-Situation, die genutzt werden sollte Die Verwendung von IFLs, das heißt z/Linux, könnte für Anwendungen, die eng mit dem agree Backendsystem gekoppelt sind, wegen geringerer Latenzzeiten eine interessante Variante sein zFuture basiert auf einer Hybrid-Architektur, die unterschiedliche Betriebssystemplattformen in einem logischen, virtuellen System verwaltet

Fragen? – Diskussion? Ralph Rohfleisch Pascal Meyer Systemtechnik ralph.rohfleisch@fiducia.de 0721 / 4004 4657 Pascal Meyer Anwendungsentwicklung pascal.meyer@fiducia.deamde 0721 / 4004 2834

Ihr IT-Partner Vielen Dank