Alle IBM-Rechner der zSeries-Reihe sind mit PR/SM ausgerüstet. Damit kann ein physischer Rechner in mehrere logische Partitons eingeteilt werden. Auf den z800- und z900-Rechnern sind maximal 15 und auf den z990-Rechnern 30 bzw. 60 LPARs möglich.

Es können Hunderte und Tausende Systeme parallel auf einer physischen Hardware betrieben werden. Damit kann die Effizienz gesteigert und die Kosten gesenkt werden.

TCO (Total Cost of Ownership) Betrachtungen

Es gibt bereits zahlreiche Analysen zu den TCOs in diesem Bereich, wobei man immer aufpassen muss, wer die Analysen finanziert bzw. sponsort. Vor allem von Anwendern gibt es jedoch zahlrleiche Kosten-Analysen, wobei Linux und vor allem Linux auf dem Mainframe in der Regel sehr gut wegkommt.

Einer der grossen Vorteile des Mainframes im Bereich der Virtualisierung ergibt sich aus der Tatsache, dass sich die Techniken der Virtualisierung über viele Jahre (bei VM beispielsweise über 30 Jahre) hinweg entwickelt haben und einen sehr hohen Leistungs- und Reifegrad erreicht haben. Über Virtualisierungs-Techniken ist es möglich, mehrere Systeme glechzeitig auf dem gleichen physischen Rechner zu betreiben. Hierfür stehen zwei Alternativen zur Verfügung: Logical Partioning (LPAR) auf der Basis einer Hardware/Microcode-Lösung und z/VM als eine Software-Lösung. Welche Lösung die sinnvollste ist, hängt von einigen Faktoren ab, auf die noch eingegangen wird. Das Konzept der virtuellen Maschinen ist Anfang der 70er-Jahre entstanden, als die Rechner im Verhältnis noch deutlich teurer waren als heute. Selbst grosse Unternehmen konnten es sich nicht leisten, einen separaten physischen Rechner für Testzwecke einzusetzen. Das Leben der Systemadministratoren war dann dadurch gekennzeichnet, dass sie viele Aktivitäten in Randzeiten (Nachtstunden, Wochenenden) durchführen mussten. Mit dem Betriebssystem "Virtual Machine" (VM) wurde das plötzlich deutlich einfacher, da damit mehrere logische Server als separate virtuelle Maschinen auf der gleichen physischen Hardware eingesetzt werden konnten. Die erste VM-Version für den Mainframe kam 1972 auf den Markt und wurde ein grosser Erfolg. VM besteht aus einem sogenannten Hypervisor, der Control Program (CP) genannt wurde. Ein Benutzer meldet sich an diesem Control Program an und startet von dort eine Gastmaschine. In dieser Gastmaschine wird dann das gewünschte Betriebssystem aktiviert. Als Ergänzung zu dem Control Program gibt es noch das Conversational Monitoring System (CMS) , das als eigenständiges Betriebssystem in einer Gastmaschine gestartet werden kann und eine interaktive Schnittstelle (vergleichbar dem TSO oder einer UNIX-Shell) zur Verfügung stellt. Über dieses CMS steht eine grosse Anzuhl von Werkzeugen zur Verfügung, mit denen der Aufbau und die Verwaltung von virtuellen Systemen vereinfacht und automatisiert werden kann. Das ursprüngliche VM als Betriebssystem und Software-Lösung hatte allerdings auch einige gravierende Nachteile. Overhead Da es sich um eine Software-Lösung handelt, braucht diese Lösung natürlich auch Ressourcen in Form von CPU-Zyklen, Hauptspeicher, Plattenplatz und I/Os. Der Overhead zu damaligen Zeit war oft beträchtlich. Es wurden in einigen Fällen 40% und mehr gemessen. Zusätzliche Skills notwendig Da es sich bei VM um ein separates Betriebssystem handelt, muss dieses natürlich auch gepflegt und betreut werden. Das heisst, dass sowohl von Seiten der Systemadministration (Einrichten und Pflege des Systems) als auch für den Betrieb (Operating) zusätzliches Wissen aufgebaut werden musste, damit VM vernünftig und zuverlässig eingesetzt werden konnte. Lizenzkosten Da VM eine Software-Lösung ist, spielen auch die Lizenzkosten eine Rolle. Wer die Preise im Mainframe-Bereich kennt, weiss, dass es sich hier schnell um beträchtliche Summen handelt, die zu Buche stehen. Unter anderem diese Nachteile haben dazu geführt, dass sich vor allem Mitbewerber von IBM Gedanken gemacht haben, ob es nicht eine Alternative als Virtualisierungstechnik gibt, die die Nachteile von VM vermeidet. Tatsächlich war es dann das Unternehmen Amdahl, das zur damaligen Zeit noch IBM-kompatible Rechner hergestellt hat, das mit einem Verfahren zur Virtualisierung auf den Markt kam, das auf einer Hardware-Microcode-Lösung basiert. Amdahl nannte diese Einrichtung "Multiple Domain Feature" und rannte damit bei vielen Kunden offene Türen ein. Mit diesem MDF war es möglich, einen physischen Rechner in mehrere logische Rechner, sogenannte Domains, einzuteilen und in diesen Domains voneinander unabhängige Betriebssysteme zu starten. Der Overhead war sehr gering (zwischen 2 und 4 Prozent), die Einrichtung einer derartigen Umgebung relative einfach und vor allem wurden keine Software-Lizenzgebühren fällig. Der Erfolg von Amdahl zwang die Mitbewerber zum Nachziehen. Zur damaligen Zeit war auch die japanische Firma Hitachi noch mit IBM-kompatiblen Mainframes auf dem Markt präsent und brachte mit dem "Multiple Logical Partitioning Feature" (MLPF) eine ähnliche Technik heraus. Auch IBM war zum Nachziehen gezwungen und nannte die entsprechende Technik Logical Partitioning (LPAR) und die Steuerungskomponente "Processor Resource / System Manager" (PR/SM). Vorteil der Hardware Microcode-Lösung ist der geringe Overhead, das einfache Handling und die Tatsache, dass keine Lizenzkosten anfallen. Nachteil im Vergleich mit VM ist, dass die Anzahl Partitions eingeschränkt ist (je nach Maschinentyp zwischen 15 und 60) und die Partitions im Vorfeld eingerichtet werden müssen und diesen wiederum fix und dediziert Hauptspeicher zugewiesen werden muss. Wie für alle anderen Betriebssysteme stehen somit auch für den Einsatz von Linux beide Varianten zur Verfügung. Linux in einer LPAR macht dann Sinn, wenn das System sehr Ressourcen-intensiv ist. Linux unter VM macht dann Sinn, wenn es sich um Systeme handelt, die weniger Ressourcen-intensiv sind. Die LPAR-Variante ist auch dann sinnvoll, wenn die Anzahl Linux-Systeme begrenzt ist und sich wenig ändert.

Das Konzept der Channel-to-Channel (CTC) Verbindungen wurde bereits in der /360-Architektur eingeführt. Die Idee dabei ist es, dass zwei Prozessoren über eine Kanalschnittstelle (Channel-to-Channel Adapter) miteinander kommunizieren können. Es handelt sich dabei um eine Punkt-zu-Punkt Verbindung. Da nur die beiden Endpunkte direkt angeschlossen sind, gilt eine derartige Verbindung als sehr sicher. MIt z/VM kann ein Channel-to-Channel Adapter virtuell abgebildet werden. Diese Technink wird beispielsweise genutzt, wenn Linux mit anderen Systemen wie VSE/ESA oder z/OS zusammengebracht werden sollen. Virtuelle Netzkarten

Eine weitere Alternative ist die mit z/VM Version 4 eingeführte virtuelle Network Interface Card. Eine NIC wird für die Anbindung eines Rechners in einem LAN benötigt. Spezielle NIC-Protokolle, die von z/VM unterstützt werden, sind Hipersockets und OSA-Express QDIO (Queued Direct I/O). OSA und CTC

Anschlüsse mit hohen Bandbreiten sind auch für Verbindungen mit der Aussenwelt wichtig. Die wichtigsten Möglichkeiten:

Verfügbarkeit ist ein Attribut für ein System, das aus der Sichtweise der Endanwender betrachtet werden muss. Unter einem Hochverfügbarkeitssystem versteht man ein System, das den Enbenutzer praktisch unterbrechungsfrei zur Verfügung steht. In Prozentzahlen ausgedrückt beginnt die Hochverfügbarkeit be 99,99%, das entspricht einer jährlichen Ausfallzeit von unter einer Stunde. Hochverfügbarkeit bedeutet entgegen einer landläufigen Meinung nicht, dass keine Komponenten ausfallen dürfen. Es bedeutet vielmehr, dass ein Hochverfügbarkeits-System Ausfälle von Systemkomponenten erkennt und sich darauf konzentriert, dass eine Anwendung trotz eines Ausfalls einzelner Komponenten weiterhin verfügbar bleibt. Ein System ist immer nur so gut, wie das schwächste Glied in der Kette. Linux und der Mainframe bilden lediglich eine Grundlage für eine Hochverfügbarkeits-Plattform. Damit die Hochverfügbarkeit tatsächlich erreicht wird, müssen die Anwendungssysteme, die Middleware und auch Management-Werkzeuge aufeinander abgestimmt werden. Hier geht es nun hauptsächlich darum, was Linux und der Mainframe zu einer Hochverfügbarkeits-Lösung beitragen kann. Sowohl zSeries als auch z/VM haben sich über Jahre hinweg entwickelt und verfügen über eine grosse Anzahl an geeigneten Werkzeugen, um die Verfügbarkeits-Aktivitäten zu unterstützen. Linux gibt es zwar erst seit einem Jahrzehnt, hat sich jedoch in dieser Zeit bereits den Ruf erworben, robust zu sein und bringt einen stetig wachsenden Werkzeugkasten für die Unterstützung der Hochverfügbarkeit mit. Die Kombination aus den beiden Welten ermöglicht es so auch Linux, in dieser Liga mitzuspielen. So können beispielsweise Anwendungsserver für e-Business Anwendungen konfiguriert werden, die einen Ausfall eines Prozessors, eines Plattengerätes und auch eines Linux Betriebssystems verkraften, ohne dass dies die Anwender bemerken. Die Kosten einer Konfiguration für Hochverfügbarkeit ist eng verknüpft mit den Fehlersitutationen, gegen die ein System gewappnet werden soll. Das Designteam einer Hochverfügbarkeitslösung muss vor allem Abwägungen vornehmen bzgl. Risiken vs. Kosten.

Verfügbarkeit des Mainframes

Das "z", das die Mainframe-Serverreihe kennzeichnet, steht für "Zero-Outage". Damit ist gemeint, dass das Design auf ständige Verfügbarkeit ausgerichtet ist. Es geht darum, möglichst viele, wenn nicht alle "Single Points of Failures" zu eliminieren. In allen Speicherbausteinen ist ein Error Correction Code (ECC) eingebaut, der dafür sorgt, dass Bitfehler "im Fluge" korrigiert werden. Wenn ein Prozessor ausfällt, wird er automatisch durch einen Ersatzprozessor ersetzt. Die Hochverfügbarkeit in Verbindung mit dem klassischen MVS mit z/OS als neuester Version basiert zu einem grossen Anteil auf der Clustering-Technik, die auf dem IBM-Mainframe unter dem Namen "Sysplex" bekannt ist. Linux auf dem Mainframe ist heute allerdings noch nicht Sysplex-fähig, so dass die berühmten "Five Nines", d.h. eine Verfügbarkeit von 99,999% in Verbindung mit Linux noch nicht erreichbar ist. Single Points of Failure (SPoF)

Single Points of Failure werden hauptsächlich durch Doppelführung von Komponenten eliminiert. Redundanz gibt es auf diversen Ebenen. Ausgehend von den Prozessoren kann die Redundanz weitergeführt werden bis zu redundanten Application Servern, die auf unterschiedlichen physischen Maschinen eingerichtet werden.

Es ist möglich, redundante Linux Gastsysteme zu konfigurieren, wobei die Verfügbarkeit gesteigert wird, indem ein sekundäres Linuxsystem darauf wartet, dass ein primäres Linuxsystem ausfällt, um dessen Workload(s) zu übernehmen. Es gibt zwei Ansätze, dies zu erreichen: Hot Standy oder Clustering.

Das z/VM nutzt vollumfänglich die Vorteile der zSeries Hardware und kann so konfiguriert werden, dass davon auch die Gastsysteme vollumfänglich profitieren. Das Hardware-Konfigurationsfile, das die Umgebung steuert, in der das z/VM ausgeführt wird, sollte immer so ausgelegt, sein, dass mindestens jeweils zwei Hardware-Ressourcen definiert sind. D.h.: Mindestens zwei CPUs, mindestens zwei Pfade zu den Plattengeräten und mindestens zwei LAN-Verbindungen. Hier sind drei Linux Gastsysteme definiert, wobei für jedes zwei virtuelle CPUs definiert wurden. Da keine dedizierten Zugriffswege genutzt werden, muss die Pfadredundanz nicht berücksichtigt werden. Darum kümmert sich das z/VM. Nun kann natürlich auch das z/VM ausfallen. Es handelt sich dabei zwar um ein äusserst stabiles Betriebssystem, das normalerweise nicht ausfällt. Allerdings spielt hier der Faktor Mensch eine entscheidende Rolle, so dass auch der Ausfall des z/VM berücksichtigt werden muss. Der Restart des z/VM kann weitgehend automatisiert werden. Dennoch dauert es natürlich eine gewisse Zeit, bis das z/VM und die darunter betriebenen Gastsysteme neu hochgefahren sind, so dass damit kein Hochverfügbarkeits-Szenario reallisiert werden kann. Wenn die Ausfallzeit verkürzt werden muss, ist es unumgänglich, dass ein zweites z/VM benötigt wird. Dieses zweite z/VM kann in einer anderen LPAR auf derselben Maschine eingerichtet werden, wobei vorausgesetzt wird, dass die zSeries Hardware nicht für den Ausfall verantwortlich ist. Dies ist zwar sehr unwahrscheinlich, wenn jedoch auch dieser Fall berücksichtigt werden muss, muss das z/VM auf einer anderen physischen Maschine untergebracht werden, möglicherweise gar an einem anderen Ort, wenn zusätzlich auch ein Katastrophenausfall berücksichtigt werden soll.

Welche Skills sind notwendig, um Linux auf dem Mainframe zu betreiben? Das Linux Know-how am Personalmarkt zu bekommen, ist heute kein Problem mehr. Linux wird heute in den meisten Lehrplänen an Hochschulen, Fachhochschulen und anderen Bildungseinrichtungen berücksichtigt. Da Linux ein UNIX-ähnliches System ist, fühlt sich auch ein UNIX-Administrator, der mit Linux arbeitet, schnell zuhause. Da Linux auf dem Mainframe das gleiche Linux wie auf allen anderen Plattformen darstellt, ist das alles kein Problem. Die Herausforderung für einen Linux/UNIX Spezialisten, der mit Linux auf dem Mainframe zurechtkommen soll, ist es, die Hardware des  Mainframes zu verstehen sowie die Arbeitsweise und den Umgang mit z/VM zu erlernen. Ausserdem haben viele am Anfang Mühe, sich an die bestehenden Strukturen und Abläufe, die im Mainframe-Bereich etabliert sind, zu gewöhnen.

Die Mainframe-Spezialisten wiederum, die mit Linux auf dem Mainframe konfrontiert werden, müssen die Linux/UNIX-Welt kennenlernen. Das mit UNIX allgemein ist meist nicht mehr das grosse Problem, da die meisten Mainframe-Profis mit UNIX System Services (die POSIX-Schnittstellen im z/OS) schon Erfahrung gesammelt haben. Was für sie meist neu ist, ist der Umgang und die Erfahrung mit Open Source. Ein Linux Administrator sollte mit den Aktivitäten der Open Source Gemeinde vertraut sein und am Ball bleiben, wenn es darum geht, mitzubekommen, welche Neuigkeiten es gibt, die möglicherweise für die eigene Umgebung interessant sein können. Das Interesse und möglicherweise auch die aktive Mitarbeit an den Aktivitäten der Open Source Gemeinde ist etwas Ähnliches wie beispielsweise die Mitarbeit in Benutzergruppen wie Guide und Share für Mainframe-Spezialisten, wobei die Kommunikation und der Erfahrungsaustausch in Verbindung mit Open Source allerdings seinen Schwerpunkt im Internet hat. Es gibt zahlreiche Spezialisten, die schon jahrelang eng zusammenarbeiten, sich jedoch noch nie gesehen haben.

In einer Mainframe-Umgebung ist es meist typisch, dass viele (hunderte) Linux-Systeme verwaltet werden müssen. Für die Vereinfachung der Administration sollte man versuchen, die Anzahl unterschiedlicher Standardsysteme möglichst klein zu halten. Dies kann zwar auch bei physischen Serverfarmen Sinn machen, jedoch sind die Vorteile in einer Mainframe-Umgebung besonders offensichtlich. Auf dem Mainframe ist das sogenannte "Code-Sharing" möglich. Linux ermöglicht es, dass das Filesystem auf mehrere Platten verteilt wird. Das z/VM wiederum kann diese Platten mehreren Linux-Systemen gleichzeitig verfügbar machen in Form von sogenannten read-only Minidisks. Somit können mehrere Linux-Systeme das gleiche physische Filesystem nutzen. Man kann somit Daten, die während des Betriebs nicht verändert werden, physisch einmal auf eine Platte legen, auf die dann von vielen Linux-Images gemeinsam zugegriffen wird. Die Administration wird damit natürlich erleichtert. Ausserdem wird weniger Plattenplatz benötigt. Das Code-Sharing kann direkt realisiert werden, indem eine "Read-Only-Platte" eingesetzt wird, auf die von mehreren Images zugegriffen werden kann oder in der Form des Kopierens, indem von einer Masterkopie weitere Kopien erstellt werden. Eine Hot-Standby Konfiguration kann mit Hilfe von z/VM sehr einfach aufgebaut werden, indem zwei redundante Images aufgebaut werden, die ein gemeinsames Filesystem nutzen. Ob und wie die Daten auf Platte behandelt werden, hängt davon ab, ob nur lesend oder auch schreibend darauf zugegriffen wird. Bei einem Webserver und statischen HTML-Dokumenten beispielsweise kann ein sehr kostengünstiges Hot-Standby System aufgebaut werden. Allerdings ist hierfür eine sorgfältige Planung notwendig. Da einige Files systemspezifisch unterschiedlich sein müssen, können nicht alle Files gemeinsam genutzt werden, sondern müssen jeweils individuell für die unterschiedlichen Systeme verfügbar sein.