Verwendung von Spezialprozessoren

Präsentation zum Thema: "Verwendung von Spezialprozessoren"—  Präsentation transkript:

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

2 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

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

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

5 Überblick über die Spezialprozessoren
Quelle IBM © 2009

6 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

7 Spezialprozessoren auf der Zeitachse
Quelle IBM © 2009

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

9 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

10 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)

11 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

12 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 Knapp 10 % des gesamten Workloads konnten im Bereich DB2 auf den zIIPs verarbeitet werden Per heute sind etwa zIIP-MIPS zur Verarbeitung verfügbar

13 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

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

15 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

16 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

17 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

18 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

19 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)

20 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

21 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

22 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

23 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

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

25 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

26 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 + +

27 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

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

29 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

30 Fragen? – Diskussion? Ralph Rohfleisch Pascal Meyer Systemtechnik
0721 / Pascal Meyer Anwendungsentwicklung 0721 /

31 Ihr IT-Partner Vielen Dank