© codswollop, photocase.com
Noch heute bilden Mainframes das EDV-Rückgrat in vielen Unternehmen. Entsprechend schwer kommt ein Administrator an eine dieser Maschinen heran, um auch dort Linux zu installieren. Der Emulator Hercules bietet aber eine vollwertige Alternative zum Nulltarif.
Mainframes gelten als zuverlässig, aber auch als groß, kompliziert, teuer und nicht mehr zeitgemäß in der heutigen EDV-Landschaft. Doch trotz des Hype um Down- und Rightsizing existieren sie auch heute noch zu Recht. Interessant an ihnen sind ihr spezieller, auf hochgradige Redundanz ausgelegter Aufbau und ihr I/O-Durchsatz (siehe Kasten “Mainframe-Architektur”).
Mainframes sind, wie auch andere High-End-Serversysteme, sehr teuer. Deshalb kommt man naturgemäß nicht so einfach an ein System heran, um vielleicht nur zu lernen. Dank des Mainframe-Emulators Hercules, der die CPU-Architektur von IBMs S/360, S/370, S/390 und Z-Series emuliert, ist das aber auch nicht nötig. Selbst wenn Linux bereits produktiv auf einem Mainframe läuft, kann der Emulator gute Dienste für Tests und Entwicklung leisten.
Die folgenden Abschnitte beschreiben die Einrichtung und Konfiguration von Hercules und seiner virtuellen Hardware. Anschließend liegt der Schwerpunkt auf der Installation von Z-Linux auf Hercules. Der letzte Teil beschäftigt sich kurz mit Z/OS, quasi dem nativen Betriebssystem der Mainframes, und seinem frei verfügbaren Vorläufer MVS.
Die aktuelle Hercules-Version ist 3.05, die zum Beispiel mit Open Suse 10.3 ausgelieferte Version 3.04 unterstützt aktuelle Z-Linux-Varianten nicht. Deshalb sollten Interessierte die Projekt-Homepage [1] aufsuchen und dort den aktuellen Quellcode herunterladen. Das ebenfalls verfügbare RPM lässt sich zwar installieren, unterstützt aber keine Netzwerkverbindungen und ist damit ebenfalls ungeeignet.
Die Quellen entpackt man in einem Verzeichnis seiner Wahl, etwa »/usr/local/src«, wechselt dann in das Verzeichnis »/usr/local/src/hercules-3.05« und ruft »configure« wie in Listing 1 auf. Anschließend ist unbedingt die Datei »config.log« zu kontrollieren, insbesondere um zu prüfen, ob die Zlib-Unterstützung verfügbar ist. Wenn zum Beispiel unter Suse das Paket »zlib-devel« nicht installiert ist, lässt sich Hercules zwar ohne Probleme kompilieren und auch nutzen, die üblichen Zlib-komprimierten virtuellen Festplatten aber nicht.
|
Listing 1: Hercules bauen: |
|---|
01 #!/bin/bash 02 03 PREFIX=/usr/local 04 05 ./configure --prefix=$PREFIX 06 --enable-cckd-bzip2 07 --enable-optimization=yes 08 --disable-external-gui 09 --enable-setuid-hercifc |
Nach dem Configure-Lauf folgen das übliche »make« sowie »su -c “make install”«. Damit ist Hercules prinzipiell verfügbar, doch fehlen noch einige Nacharbeiten. In »/usr/local/share/hercules« steht die Dokumentation im HTML-Format. Weitere Quellen im Internet sind verlinkt, insbesondere die Mailingliste ist erster Anlaufpunkt bei Problemen.
|
Mainframe-Architektur |
|---|
|
Die aktuelle Generation von IBM-Mainframes, genannt Z9, gibt es in verschiedenen Größen: als Midrange-Systeme (Modell 2096) mit ein bis sieben Prozessoren und als Enterprise-Systeme (Modell 2094) mit ein bis 54 Prozessoren. So genannte Books enthalten das Multi Chip Module (MCM), Speicherkarten und Interconnects. Die Rechner haben ein bis vier Books, die MCMs in der Größe von 95 mal 95 Millimetern haben 12 bis 16 Processor Units (PUs, 64 Bit) mit jeweils zweimal 256 KByte L1-Cache (Instruktionen und Daten). Die Taktrate der PUs ist 1,6 GHz. Jedes MCM unterstützt 40 MByte L2-Cache, jedes Book bis zu 128 GByte an Hauptspeicher. Die PUs auf den MCMs haben unterschiedliche Aufgaben. Zwei PUs des ersten Books dienen als Reserve. Je zwei PUs pro MCM dienen als so genannte System Assist Processors (SAPs) – damit kommt man auf den maximalen Ausbau von 54 Prozessoren (64 minus viermal zwei SAPs minus zwei Spare). Die verfügbaren PUs wiederum werden über Microcode konfiguriert: als CPs (Central Processor), ICFs (Internal Coupling Facilities für den Aufbau von Mainframe-Clustern), IFLs (Integrated Facility for Linux), ZAAPs (System Z Application Assist Processor für die Ausführung von Java-Code) sowie ZIIP (System Z9 Integrated Information Processor für die Ausführung von DB2-Code). Die Konfiguration der PUs dient dabei nicht nur der Optimierung, sondern auch der Steuerung der Softwarekosten. Auf Mainframes hängen diese typischerweise von der Rechenleistung ab. Prozessoren wie ZAAP, ZIIP oder IFL, auf denen nur Z-Linux läuft, gehen damit nicht in die Berechnung der Kosten ein. In den meisten Fällen sind nicht alle PUs auf den MCMs aktiv. Der Rest steht für besondere Zwecke wie Capacity on Demand (CoD) oder die Notfallübernahme des Workload eines anderen Mainframe zur Verfügung. CoD ist zum Beispiel nützlich, um Leistungspeaks am Jahresende abzufangen, ohne das ganze Jahr über unnötigerweise teuere Rechenkapazität bezahlen zu müssen. Die notwendige Zusatzkapazität schaltet der Admin dann per IBM-Freigabecode für eine definierte Zeit hinzu. Betriebssysteme installiert der Admin typischerweise in logischen Partitionen. Die Z9 unterstützt bis zu 60 logische Partitionen, physische Ressourcen lassen sich dabei feingranular zuweisen, ob mit oder ohne Lastausgleich über Partitionen hinweg. Läuft auf einer Partition der Hypervisor Z/VM, sind der Anzahl parallel laufender Betriebssysteme nur durch die Hardware-Ressourcen Grenzen gesetzt. Mainframes sind nicht auf Number-Crunching getrimmt, dafür gibt es deutlich besser geeignete Architekturen. Die Stärke der Mainframes liegt im Bereich I/O, der in ein eigenes Subsystem ausgelagert ist. Ungeschlagen sind Mainframe-Systeme in der Ausführung gemischter Workloads. Im Unterschied zu typischen Unix-Installationen, bei denen zum Beispiel dedizierte Datenbankserver üblich sind, laufen auf Mainframes Datenbankserver, Transaktionsmonitore (Online-Dialoge) und Batch-Jobs auf einer einzigen logischen Partition. |
Wirtsystem einrichten
Wer TCP/IP-Networking mit einem Hercules-Gastsystem nutzen möchte, muss zuerst das Wirtsystem richtig konfigurieren. Zuerst sind die Rechte des Skripts »/usr/local/bin/hercifc« anzupassen, das die Tun/Tap-Netzwerkdevices beim Hercules-Start konfiguriert.
Wie bei allen direkten Zugriffen auf Devices sind dafür Root-Rechte nötig. Die Configure-Option »–enable-setuid-hercifc« (siehe Listing 1, Zeile 9) setzt zwar das SUID-Bit, aber das Installationsskript setzt die Gruppe der Datei auf »root«, was für normale Benutzer die Ausführung verhindert. Nach
chgrp users /usr/local/bin/hercifc chmod 4750 /usr/local/bin/hercifc
sind die Rechte richtig gesetzt. Die folgenden Absätze gelten in dieser Form nur für Open-Suse-Systeme, auf anderen unterscheiden sich aber nur einige Details. Für die virtuelle Netzwerkverbindung nutzt Hercules das Tun/Tap-Device, das auf normalen Systemen den Owner »root:root« und die Rechte »0600« besitzt. Wieder ist der Zugriff für normale Nutzer blockiert. Allerdings nützt es wenig, die Rechte manuell zu ändern: Nach dem nächsten Reboot ist wieder alles beim Alten.
Auf aktuellen Systemen verwaltet Udev die Devices, weshalb die entsprechende Udev-Regel anzupassen ist. Auf Open-Suse-Systemen heißt die relevante Datei »/etc/udev/rules.d/50-udev-default.rules«, hier fügt der Admin die folgende Zeile ein:
KERNEL=="tun", GROUP="users", NAME="net/%k",MODE="0660"
Nach »rm /dev/net/tun« und »modprobe tun« besitzt »/dev/net/tun« die richtigen Rechte. Wer jetzt nach einem Reboot feststellt, dass das Device wieder die falschen Rechte hat, sollte nicht verzweifeln. Beim Systemstart kopiert das Skript »/etc/init.d/boot.udev« eine Reihe von Devices von »/lib/udev/devices« nach »/dev«. Es gilt also, das Tun-Device in diesem Verzeichnis zu löschen oder die Rechte anzupassen:
chgrp users /lib/udev/devices/net/tun chmod 660 /lib/udev/devices/net/tun
Das Tun/Tap-Device ermöglicht eine Punkt-zu-Punkt-Verbindung zwischen Wirt und Gast. Andere Virtualisierer sprechen hier von Host-only Networking. Soll das Gastsystem Zugriff auf das lokale Netz oder sogar das Internet bekommen, ist NAT einzurichten.
Dazu schaltet der Admin zuerst IP-Forwarding ein, entweder permanent in »/etc/sysconfig/sysctl« (»IP_FORWARD =yes«) oder manuell mit Hilfe der Eingabe:
echo "1" > /proc/sys/net/ipv4/ip_forward
Anschließend definiert er zwei Firewall-Regeln:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i tun0 -j ACCEPT
Damit ist das Wirtsystem vorbereitet. Der nächste Schritt erstellt und konfiguriert die virtuelle Hardware.
Virtuelle Mainframes
Hercules unterstützt eine ganze Reihe virtueller Hardwarekomponenten, für Z-Linux genügen aber Festplatten und eine Netzwerkverbindung. Da es sich um einen High-End-Server handelt, spielen Video-, Audio- und USB-Unterstützung keine Rolle. Hercules unterstützt zwar emulierte Drucker, doch für die alten zeilenorientierten 1403-Drucker (Abbildung 1) gibt es keine Linux-Treiber. Das ist aber keine große Einschränkung, man druckt einfach per Netzwerk auf dem Cups-Server des Wirts oder einen anderen Druckserver.
Abbildung 1: Relikt aus der guten alten Zeit: Ein IBM-1403-Zeilendrucker.
Die Definition der virtuellen Hardware geschieht über eine Konfigurationsdatei (siehe Listing 2), die der Emulator beim Start hinter der Option »-f« erwartet. Hercules macht keinerlei Vorgaben hinsichtlich Name und Verzeichnisstruktur. Je nach persönlichen Vorlieben kann der Admin alle Dateien in einem Verzeichnis oder nach Typ in Unterverzeichnissen halten. Virtuelle Festplatten sind wie bei anderen Emulatoren normale Dateien. Festplatten heißen in IBM-Speak DASD (Direct Attached Storage Device). Für die Z-Linux-Installation legen die folgenden Befehle die Festplatten an:
dasdinit -z -lfs dasd/sys1.dasd 3390-3 SYS1 dasdinit -z -lfs dasd/sys2.dasd 3390-3 SYS2
Die Option »-z« konfiguriert Zlib-Kompression. Alternativ wählt »-bz2« Bzip2-Kompression, das ist aber wegen des langsameren Verfahrens mit Performance-Einbußen verbunden und steht in keiner vernünftigen Relation zum eingesparten Plattenplatz. Die Option »-lfs« bedeutet Large File Support, »dasdinit« teilt die Festplatte also nicht in 2 GByte große Teile auf. Je nach DASD-Größe empfiehlt es sich, diese Option wegzulassen, damit die Dateien noch auf DVD-Medien sicherbar sind.
|
Listing 2: |
|---|
01 #
02 # Configuration file for Hercules & CentOS 4.5 s390
03 #
04
05 MODPATH ${MODPATH_HERCULES:=/usr/local/lib/hercules}
06
07 CPUSERIAL 002623
08 CPUMODEL 2096
09 MAINSIZE 780
10 XPNDSIZE 0 # Expanded storage size in megabytes
11 CNSLPORT 3270 # TCP port number to which consoles connect
12 HTTPROOT ${HTTPROOT_HERCULES:=/usr/local/share/hercules/}
13 HTTPPORT 9091 # HTTP server
14 NUMCPU 1 # Number of CPUs
15 NUMVEC 1 # Vector facilities emulated
16 SYSEPOCH 1900
17 TZOFFSET +0000
18 OSTAILOR LINUX # OS tailoring
19 PANRATE SLOW # Panel refresh rate
20 ARCHMODE ESAME # Architecture mode S/370, ESA/390 or ESAME
21 PGMPRDOS RESTRICTED
22
23
24 # Device list
25 # --- ---- --------------------
26
27 # DASD
28
29 0A01 3390 dasd/sys1.dasd
30 0A02 3390 dasd/sys2.dasd
31
32 # Channel to channel: CTCI ip-linux-guest ip-linux-host
33
34 0cc0.2 3088 CTCI 192.168.2.2 192.168.2.1
|
Die Dateinamen (hier »dasd/sysX.dasd«) sind beliebig wählbar. Der Typ der Festplatte (3390-3) bestimmt die Größe, im Beispielfall ungefähr 2,7 GByte. Eine Aufstellung der verfügbaren Typen und ihrer Größe liefert die Hercules-Dokumentation, der Kasten “Festplatten für Mainframes” gibt ein paar Hintergrundinformationen.
|
Festplatten für |
|---|
|
Historisch gesehen gab es eine ganze Reihe Festplattentypen für Großrechner, doch wurde irgendwann die Zugriffsschicht virtualisiert, sodass heute selbst auf aktuellen Großrechnern noch 3390-Volumes üblich sind, obwohl es sich physisch um ganz normale Plattensysteme handelt, wie sie auch Midrange-Systeme nutzen. Ebenso historisch bedingt ist es, dass die Recheneinheiten bei Großrechnern nicht Mega- und Gigabytes sind, sondern Cylinder und Tracks. Die 3390-3 hat 3339 Cylinder. Nützlich für die Umrechnung in übliche Größen ist die Website [2]. 3390-Volumes haben 15 Tracks pro Cylinder (acht zweiseitige Scheiben, eine für Kontrollinformationen) mit 56832 Bytes pro Track. Das Wissen um die physische Struktur der Festplatten und der direkte Zugriff auf sie erlaubte es in der Anfangszeit der EDV, die Zugriffszeiten zu optimieren: Passen die Daten in einen Cylinder, so kann das System sie ohne Kopfbewegung lesen. |
Der letzte Parameter für »dasdinit«, der »VOLSER«-Name (also das Plattenlabel), wäre unter Linux auch entbehrlich, die Installation überschreibt ihn sowieso. Als letzten Schritt trägt der Admin die Festplatten in die Hercules-Konfigurationsdatei ein (siehe Listing 2, Zeilen 29 und 30) und vergibt dadurch auch die Device-Adressen, unter denen Linux die Festplatten dann findet.
Netzwerkschnittstelle
Hercules emuliert verschiedene Typen von Netzwerkverbindungen. Am leichtesten konfiguriert sich die Channel-to-Channel-Verbindung (kurz CTC). Es ist nur eine Zeile in die Konfigurationsdatei einzutragen (Listing 2, Zeile 34). Sie konfiguriert zwei CTC-Devices vom Typ 3088 auf den Adressen 0cc0 und 0cc1 und vergibt die Adresse 192.168.2.2 für den Gast sowie 192.168.2.1 für den Wirt. Die genaue Syntax, insbesondere für die Device-Adressen, erklärt die HTML-Dokumentation. Hercules startet nun mit dem Befehl:
hercules -f conf/centos45.conf > hercules.log
Abbildung 2 zeigt die initiale Ausgabe auf der Hercules-Konsole. Wichtig ist die Meldung »HHCCT073I«, die mitteilt, dass das Netzwerk-Device »tun0« geöffnet ist. Leider kann man sich darauf nicht hundertprozentig verlassen, das hängt letztlich von den Rechten von »hercifc« ab. Sicherheit schaffen nur die Ausgaben (Listing 3) der Befehle »route -n« und »ifconfig«. Sowohl in der Routingtabelle (Zeile 4) als auch in der Netzwerkkonfiguration (Zeilen 12 bis 18) muss das »tun0«-Device vorkommen.
Abbildung 2: Die Hercules-Konsole zeigt beim Start die unterstützten Features.
|
Listing 3: Überprüfung |
|---|
01 [root@sirius:~] # route -n 02 Kernel IP routing table 03 Destination Gateway Genmask Flags Metric Ref Use Iface 04 192.168.2.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 05 ... 06 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 07 [root@sirius:~] # ifconfig 08 eth0 ... 09 10 lo ... 11 12 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 13 inet addr:192.168.2.1 P-t-P:192.168.2.2 Mask:255.255.255.255 14 UP POINTOPOINT RUNNING MTU:1500 Metric:1 15 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 16 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 17 collisions:0 txqueuelen:500 18 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) |
Hercules-Konsole
Die Hercules-Konsole dient der Steuerung des Systems. Hercules kennt eine ganze Reihe von Befehlen. Die Dokumentation ist leider manchmal etwas knapp, aber insgesamt ausreichend. Wichtigster Befehl ist »ipl«. Auch das ist ein Begriff aus der IBM-Mainframe-Sprache und bedeutet Initial Program Load. Der Befehl stößt also den Bootprozess an. Nützlich ist auch der Befehl »maxrates«, der unter anderem die Mips ausgibt (der Kasten “Leistungsmessung am Mainframe” erklärt ein paar Hintergründe).
|
Leistungsmessung am |
|---|
|
Die Leistung von Mainframes wird üblicherweise in Mips (Million Instructions per Second) oder einer abgeleiteten Größe davon angegeben. Kritiker sprechen auch von “Meaningless Information on Performance for Salespeople”. Der Hintergrund: Die Prozessorleistung hängt nicht nur von der gesamten Hardware-Umgebung, sondern auch vom so genannten Workload ab. Das heißt, dass es in der nutzbaren Leistung einen großen Unterschied ausmacht, ob zum Beispiel viel oder wenig Online-Betrieb zu bewältigen ist. Aus diesem Grund haben sich Benchmarks wie Specint etabliert. Für Mainframes hat IBM eigene Workload-Definitionen etabliert, die aber nicht mehr als Anhangspunkte für die Nutzer sind. Die Tabelle auf [10] zeigt Mips-Zahlen für die aktuelle und vorherige Rechnergeneration in verschiedenen Ausstattungen unterZ/OS 1.6. Das aktuelle Modell in Maximalausstattung kommt auf fast 18000 Mips. In den Datenblättern zur aktuellen Z9-Architektur findet sich davon nichts, hier gibt IBM die relative Rechenleistung im Vergleich zu älteren Maschinen an. Ein sinnvoller Ansatz für Rechenzentren, die migrieren wollen. Hercules ist von solchen Zahlen weit entfernt. Auf einem Pentium M (Centrino, 1,5 GHz) läuft Z-Linux im Peak mit 32 Mips, im Dauerbetrieb unter Last mit immerhin um die 25 Mips. Ein Athlon64 3000+ kommt im 32-Bit-Modus nur auf 21/15 Mips (Peak und Dauer). Interessanterweise ist Hercules einer der ganz wenigen Fälle, die vom 64-Bit-Modus deutlich profitieren – hier ist eine Steigerung um ungefähr 20 Prozent drin. Wer ein 64-Bit Betriebssystem unter Hercules fahren will, ist mit einer 64-Bit-Basis sowieso deutlich schneller. Die Leistung aktueller PCs reicht also völlig aus, um einen leichten Mainframe-Workload zu simulieren. Wer mit dem freien MVS 3.8 auf modernen PCs arbeitet, hat sogar ein Vielfaches der damals üblichen Rechenleistung zur Verfügung: Die Rechner aus der MVS-3.8-Zeit kamen nur auf einstellige Mips-Werte. |
Hercules kennt noch zwei alternative Konsolen. Die [Esc]-Taste schaltet zwischen der zeilenorientierten Konsole aus Abbildung 2 und der semi-grafischen Konsole aus Abbildung 3 um, deren Ansichten aktuelle Leistungsdaten bieten – die Inhalte der Register flimmern am Auge des Betrachters vorbei.
Wer Hercules remote betreiben will, kann die HTTP-Konsole nutzen (Abbildung 4) und sie in der Konfigurationsdatei (Listing 2, ab Zeile 12) einstellen. Dort lässt sich auch eine Authentifizierung über Benutzername und Passwort konfigurieren, aber es bleibt trotzdem eine unsichere HTTP-Verbindung.
Abbildung 3: Die semi-grafische Hercules-Konsole als farbige Alternative zur Zeilenkonsole.
Abbildung 4: Die Hercules-Konsole im Webbrowser wirkt recht aufgeräumt.
Installation von Z-Linux
Es gibt bei Mainframes zwei Systemarchitekturen: Z-Linux mit 31 Bit (S390) und Z-Linux mit 64 Bit (S390x). Bei der 31-Bit-Variante ist nur die Adressierung 31-, die Daten selbst sind 32-bittig. Das hat historische Gründe: Es gab einen 24-Bit-Zwischenschritt (vor der Linux-Zeit), aus Kompatibilitätsgründen musste später das oberste Bit herhalten, um zwischen 24-Bit- und 31-Bit-Modus zu unterscheiden.
Das Angebot an Linux-Distributionen für Z-Linux ist etwas eingeschränkt. Die zwei großen Distributoren haben entsprechende Versionen zwar im Angebot, aber sie sind nicht frei verfügbar. Wer ein freies 64-Bit-Z-Linux haben will, muss deshalb auf das veraltete Think Blue/64-Linux [3] oder auf das aktuellere, aber auch nicht mehr taufrische Centos 4.5 [4] ausweichen, das in diesem Artikel zum Einsatz kommt.
Eine gute und aktuelle Alternative ist Debian, es pflegt die 31-Bit-Architektur innerhalb der Releases. Die Installation von Debian unterscheidet sich in der Anfangsphase nur marginal von der bei Centos, sodass der Artikel darauf nicht näher eingeht – und nach der ersten Phase unterscheidet sich die Debian-Installation sowieso nicht von einer normalen Debian-Netzwerkinstallation.
Installationsschritte
Auch Centos ist auf dem Mainframe über das Netzwerk zu installieren, da Mainframes und auch Hercules keine CD-Laufwerke kennen. Deshalb muss der Admin die gemountete DVD per NFS exportieren oder den DVD-Inhalt in ein exportiertes Verzeichnis kopieren. Anschließend bootet der Befehl »ipl /cdrom/generic.ins« das System von der Hercules-Konsole.
Ab jetzt sollten die vom normalen Linux gewohnten Bootmeldungen über den Bildschirm flimmern. Als Nächstes startet das Netzwerk-Konfigurationsprogramm, das alle für den Aufbau einer Verbindung notwendigen Informationen abfragt. Die Meldungen und die Antworten zeigt Listing 4. Wichtig dabei: Befehle, die mit einem Punkt beginnen, leitet die Hercules-Konsole an das gestartete System weiter.
|
Listing 4: Installation Z-Linux |
|---|
001: Which kind of network device do you intend to use: 002: .ctc 003: Enter the bus ID and the device number of your CCW devices. 004: CTC/ESCON and LCS need two subchannels: 005: (e.g. "0.0.0600,0.0.0601" will configure the CTC or ESCON interface 006: with the subchannels 0x600 and 0x601) 007: QETH needs three subchannels p.e. 0.0.0300,0.0.0301,0.0.0302 008: .0.0.0cc0,0.0.0cc1 009: Enter the FQDN of your new Linux guest (e.g. s390.redhat.com): 010: .emu-guest.bablokb-local.de 011: Enter the IP address of your new Linux guest: 012: .192.168.2.2 013: Enter the network address of the new Linux guest: 014: .192.168.2.0 015: Enter the IP of your CTC / ESCON / IUCV point-to-point partner: 016: .192.168.2.1 017: Select which protocol should be used for the CTC interface 018: 0 for compatibility with p.e. VM TCP service machine (default) 019: 1 for enhanced package checking for Linux peers 020: 3 for compatibility with OS/390 or z/OS peers 021: .0 022: Enter your DNS server(s), separated by colons (:): 023: .10.173.112.250 024: Enter your DNS search domain(s) (if any), separated by colons (:): 025: . 026: Enter DASD range (e.g. 200-203 or 200,201,202,203) 027: Press <Enter> for autoprobing (not recommended): 028: .0a01-0a02 029: 030: Starting telnetd and sshd to allow login over the network. 031: 032: Connect now to 192.168.2.2 to start the installation. |
Nach Abschluss dieser Phase erscheint die Meldung in Zeile 32. Jetzt startet der Admin eine SSH-Verbindung zu der Gastadresse und findet sich im normalen Centos-Installationsprogramm Anaconda wieder. Nach einigen Einstellungen und dem Mount der Installationsquellen über NFS geht alles seinen gewohnten Gang. Da die virtuelle Netzwerkverbindung nicht wirklich fix ist, kann der Installateur sich jetzt eine kleine Pause gönnen und das System etwa ein bis zwei Stunden vor sich hin werkeln lassen.
Auf echten Mainframes sieht der Vorgang etwas anders aus. Hier besteht die Alternative zwischen HMC (Hardware Management Console) und bootbaren Tapes oder man bereitet auf Z/OS-Seite ein Volume für Z-Linux vor. Infos dazu liefert das etwas veraltete Redbook [5]. Generell sind die IBM-Redbooks als Quelle aller möglichen Informationen sehr zu empfehlen, es gibt sogar ein eigenes Redbook-Portal für Linux [6].
Ein fertig installiertes System startet in Hercules der schon beschriebene Befehl »ipl«. Als Parameter erwartet der Emulator die Adresse des Bootvolume, im Beispiel also »ipl 0a01«. Nach dem IPL erscheint ein Grub-ähnliches Bootmenü, das System startet nach 15 Sekunden aber auch selbstständig. Über die Konsole laufen jetzt die üblichen Startmeldungen eines (Red-Hat-)Linux-Systems, bis der Login-Prompt erscheint.
Auch wenn technisch ein Login auf der Konsole möglich ist: Das direkte Arbeiten auf der Konsole ist sehr unpraktisch, da der Anwender vor jede Eingabe einen Punkt setzen muss und nicht jedes Programm konsolentauglich ist, zum Beispiel Ncurses-basierte Software. Er arbeitet also besser von einem anderen Rechner aus per SSH.
Festplatten dynamisch hinzufügen
Prinzipiell unterscheidet sich Z-Linux nicht von einem Linux auf einer anderen Plattform. Eine wichtige Ausnahme ist der Umgang mit der Hardware. Das folgende Anwendungsbeispiel hängt eine weitere Festplatte in das System ein und mountet sie auf »/home«. Zuerst ist – wie oben beschrieben – eine neue Festplatte zu erzeugen (Datei »dasd/home.dasd«). Hercules emuliert ein hochverfügbares System, deshalb fährt der Admin Z-Linux nicht herunter, sondern macht das neue Device über die Hercules-Konsole bekannt:
attach 0a03 3390 dasd/home.dasd
Auf Z-Linux-Seite zeigt »lsdasd -s -a« die Liste der verfügbaren DASD-Devices und es ist ein neues Device als offline zu sehen. Was für Mainframe-Operatoren »vary online« ist, erledigt Root mit:
echo 1 > /sys/bus/ccw/drivers/dasd-eckd/0.0.0a03/online
Eine Kontrolle mit »lsdasd« und ein Blick in das »/dev«-Verzeichnis zeigen, dass jetzt ein Device »dasdc« existiert. Als Nächstes muss dieses Device Low-Level formatiert und partitioniert werden. Ersteres erledigt »dasdfmt«, das zweite »fdasd«:
dasdfmt -p -v -l HOME01 -b 4096 -d cdl -f /dev/dasdc fdasd -a /dev/dasdc mke2fs -j /dev/dasdc mount /dev/dasdc /home
Wer mehrere Partitionen anlegen will, ruft »fdasd« ohne den Parameter »-a« auf. Es erscheint ein Fdisk-ähnliches Menü für die Partitionierung. Im Beispiel dient das gesamte Volume als eine große Partition. Allerdings geht das neue Device beim nächsten Reboot verloren. Um dies zu verhindern, sind mehrere Schritte notwendig. Zuerst ist das Device fest in die Hercules-Konfigurationsdatei einzutragen, und der Mount-Eintrag wandert in die »/etc/fstab«.
Das Kernelmodul »dasd_mod« verlangt beim Start als Option die verfügbaren Devices, das erledigt eine Änderung in der »/etc/modprobe.conf«:
options dasd_mod dasd=0a01-0a03
Zu guter Letzt fehlt noch eine neue Initrd für den Systemstart. Wer sichergehen will, kopiert die vorhandene Initrd und ergänzt das Bootmenü in »/etc/zipl.conf«, um im Fehlerfall die alte Version starten zu können:
cd /boot mv initrd-2.6.9-55.EL.img initrd-2.6.9-55.EL.img.orig mkinitrd -v initrd-2.6.9-55.EL.img 2.6.9-55.EL vi /etc/zipl.conf # -> Anpassen, um Original-initrd laden zu können zipl -V
Das Vorgehen ist also ähnlich wie bei dem alten Linux-Bootloader Lilo, bei dem der Benutzer auch nach Änderungen an der Konfigurationsdatei das Lilo-Programm aufrufen musste.
Shadow Files statt Snapshots
Hercules kennt zwar keine Snapshots wie andere Virtualisierer, implementiert aber so genannte Shadow Files, die zu einem ähnlichen Ergebnis führen. Dazu sind nur die Zeilen mit der Festplattenkonfiguration etwas abzuändern (vergleiche Listing 2 ab Zeile 29):
0A01 3390 dasd/sys1.dasd ro sf=shadow/sys1_*.dasd 0A02 3390 dasd/sys2.dasd ro sf=shadow/sys2_*.dasd
Nach dem Start schreibt Hercules automatisch in die Dateien »shadow/sysX_1.dasd«. Der Befehl »sf+ *« (statt »*« kann auch eine Device-Adresse stehen) auf der Hercules-Konsole erzeugt einen neuen Satz von Shadow-Dateien bis zur maximalen Anzahl von acht.
Die Befehle »sf- * merge« und »sf- * nomerge« akzeptieren beziehungsweise verwerfen die Änderungen der aktuellen Shadow-Stufe. Akzeptieren bedeutet dabei, dass »sf- merge« die Änderungen zum Beispiel aus »sys1_2.dasd« nach »sys1_1.dasd» schreibt. Um Änderungen in die Originaldateien (hier »sys1.dasd«) zu übernehmen, muss der Mainframe-Admin »sf- * force« eingeben (oder die Read-only-Option »ro« weglassen).
Die Hercules-Befehle »suspend« und »resume« sichern den kompletten Systemzustand und stellen ihn auch wieder her. Allerdings funktioniert dieser praktische Mechanismus nicht in jedem Fall: Zumindest Z-Linux arbeitet anschließend nicht mehr weiter.
Aus Linux-Sicht ist wie erwähnt die Mainframe-Architektur nur eine Architektur von vielen. Allerdings lohnt es sich auch, etwas über den Tellerrand hinauszuschauen und einen Blick auf die anderen Betriebssysteme zu werfen, die normalerweise auf Mainframes laufen. Das Betriebssystem aktueller Mainframe-Systeme ist Z/OS in der Version 1.x – Version 1.9 steht aber erst seit 28. September bereit, was bedeutet, dass noch kaum jemand sie nutzt.
Leider ist Z/OS nicht frei verfügbar. Es gibt zwar für Entwickler das so genannte ADCD-Paket sowie ein Z/OS-Demopaket, doch müssen Interessenten für die legale Nutzung eine IBM-Maschine zumindest leasen. Damit bleibt als Alternative für Hercules nur der Großvater des aktuellen Z/OS – MVS 3.8.
MVS (Multiple Virtual Storage) selbst ist eine Weiterentwicklung früherer IBM-Betriebssysteme. Direkter Vorfahr ist die OS/360-Variante MVT (Multitasking with a variable number of tasks). MVS wurde dann das Betriebssystem für die nächste Hardwaregeneration, die System/370-Rechner, die ab 1972 virtuellen Speicher unterstützten. Interessanterweise arbeiteten auch schon die älteren S/360-67-Modelle mit virtuellem Speicher, aber zu damaliger Zeit sah IBM Batch-Verarbeitung als so viel wichtiger an, dass die Firma die Hardware-Unterstützung für Speichervirtualisierung zuerst nicht in die S/370 übernahm.
MVS wurde 1974 freigegeben und führt direkt über MVS/XA, MVS/ESA, OS/390 zu Z/OS. MVS ist frei verfügbar, da damals Betriebssysteme nicht lizenziert, sondern offen verteilt wurden. Für Hercules gibt es ein schlüsselfertiges MVS-System: MVS Turnkey (Download von [7], umfassende Infos auf [8]). Die einzige nötige Zusatzsoftware ist ein 3270-Terminal-Emulator: Linux-Nutzer installieren dazu das x3270-Paket ihrer Distribution.
Wer jetzt meint, mal schnell ein Mainframe-System aufsetzen und nutzen zu können, wird bald mit der harten Realität konfrontiert. Zwar kann er mit dem Cookbook von [8] das System starten und auch wieder herunterfahren – aber ohne genau zu wissen, was er tut. Ohne Mainframe-Erfahrung bringt das allerdings wenig. Wer sich ernsthaft mit der Materie befasst und die verfügbare Dokumentation – auch aktuelle Z/OS-Dokumentationen, die bei IBM frei erhältlich sind – durcharbeitet, wird viel Freude am eigenen Mainframe haben.
|
Das |
|---|
|
Mainframes waren immer teuer und die Rechenleistung stets zu knapp: Die Herausforderung war und ist, das vorhandene System optimal und möglichst bis zum Anschlag auszunutzen. Anfang der 70er Jahre waren Computer unglaublich teuer. Nach einer Meldung der “Computerwoche” von Ende 1974 kostete ein Midrange-System 3 Model 8 (ein Urahn der AS/400 – jetzt I-Series-Rechner) mit 16 KByte Zentraleinheit und 2,5 MByte Plattenspeicher samt Matrixdrucker und Anschlüssen 5641 Mark Miete pro Monat ohne Mehrwertsteuer. Nach heutigen Preisen wären das ungefähr 6650 Euro. Richtige Mainframes waren entsprechend teurer, dafür wurden bis zu sechsstellige Monatsmieten fällig. Während Linux sich noch immer mit verschiedenen Schedulern rumplagt, um eine möglichst faire und optimale Ressourcennutzung zu garantieren, sind die Bewohner der Mainframe-Welt einen anderen Weg gegangen. Auf dem Mainframe muss der Nutzer die Ressourcen angeben, die er braucht. Damit kann das System selbst entscheiden, ob das Programm jetzt, später oder gar nicht laufen soll beziehungsweise darf. Ein kleines Beispiel soll dies verdeutlichen. In Listing 5 ist ein klassisches Kopierprogramm abgedruckt. Das sieht sehr kompliziert im Vergleich zum »cp«-Kommando unter Linux aus (ist es auch), es hat aber nicht nur den Nachteil der Komplexität, sondern auch Vorteile. Jobs auf dem Mainframe sind auch in der Zeit nach den Lochkarten gewissermaßen Kartenstapel in Dateien. Der abgedruckte Job (in der Job Control Language, kurz JCL) fängt deshalb mit einer Jobkarte an. Diese spezifiziert Speicher, Laufzeit und Jobklasse. Darüber lässt sich die Priorität schon recht gut steuern. Anschließend folgt das Kopierprogramm »IEBGENER« mit seinen Parametern. Host-Programme greifen auf Dateien über logische Dateinamen zu, bei »IEBGENER« sind das »SYSUT1« und »SYSUT2«. Diese definiert man in so genannten DD-Karten (Data Definition). KatalogisierenBei »SYSUT1« (Zeile 5), der Eingabedatei, ist die Disposition »OLD« zu finden. Das bedeutet, dass der Job die Datei exklusiv benötigt. Verarbeitet ein anderer Job gerade diese Datei, dann wartet der neue. Das System wird also gar nicht erst damit belastet und der erfolgreiche Lauf des Jobs ist nicht gefährdet. Eine Alternative wäre »DISP=SHR« gewesen, dies erlaubt geteilten (lesenden) Zugriff – für ein Kopierprogramm vielleicht die realistischere Alternative. Interessant ist die Spezifikation der Zieldatei in den Zeilen 6 bis 9. Die Disposition ist »(NEW,CATLG)«, das bedeutet, dass die Datei noch nicht existieren darf und erst nach dem erfolgreichen Lauf katalogisiert wird. Existiert die Datei schon, läuft der Job gar nicht erst an. Die weiteren Angaben legen den Platzbedarf (primär fünf Cylinder, zusätzlich bis zu 15-mal zwei Cylinder) und das physische Dateiformat fest. Unter Linux kann ein wild gewordenes Programm das Dateisystem volllaufen lassen, auf dem Mainframe stoppt das System Programme, die den von ihnen angeforderten Platzbedarf überschreiten. Optimale AuslastungDieses Beispiel zeigt, dass Optimierung immer mit zusätzlichem Aufwand verbunden ist. Früher bei den deutlich kleineren Rechnern war dies lebenswichtig, heutige Mainframes bieten Möglichkeiten, die darüber hinausgehen. Das Prinzip, den Rechner optimal zu nutzen, ist geblieben. Eine Auslastung von 90 Prozent im Dauerbetrieb ist durchaus möglich und aus Kostengründen auch sinnvoll. Ein weiteres Beispiel für die optimale Nutzung von Ressourcen ist das Protokoll, mit dem Mainframe-Terminals mit dem Host kommunizieren. Echte Terminals gibt es schon gar nicht mehr, heute emulieren Programme wie x3270 das Protokoll. Im Gegensatz zu Unix-Tastaturtreibern, die jeden Tastendruck gesondert verarbeiten müssen, füllt der Anwender im 3270-Bildschirm alle Felder aus und schickt dann den gesamten Bildschirminhalt auf einmal weg. Dieser Ablauf reduziert die Anzahl der Verarbeitungsschritte, macht allerdings auch Programme wie Vi oder Emacs unmöglich. |
|
Listing 5: Eine Datei mit |
|---|
01 //MYJOB JOB (COPY),'COPY',CLASS=A,MSGCLASS=A,REGION=256K, 02 // TIME=5,MSGLEVEL=(1,1),NOTIFY=HERC04 03 //COPY EXEC PGM=IEBGENER 04 //SYSPRINT DD SYSOUT=* 05 //SYSUT1 DD DISP=OLD,DSN=HERC04.DATEI2 06 //SYSUT2 DD DSN=HERC04.DATEI2.BAK,DISP=(NEW,CATLG), 07 // UNIT=SYSDA,VOL=SER=PUB002, 08 // SPACE=(CYL,(5,2,0)), 09 // DCB=(RECFM=FB,LRECL=80,BLKSIZE=4096,DSORG=PS) 10 //SYSIN DD DUMMY |
Déjà vu
Mit Hercules steht ein stabiler Emulator für die Mainframe-Architektur zur Verfügung. Auf einem leistungsfähigen Midrange-System ausgeführt sollte die Performance sogar ausreichen, um eine Z-Linux-Test-LPAR zu ersetzen. Wer seine Software nach Z-Linux portieren möchte, nutzt Hercules oder alternativ das “Community Development System for Linux” (LCDS), ein Service, den IBM zur Verfügung stellt [9].
Wer an Computergeschichte interessiert ist, sollte unbedingt die verschiedenen Artikel zu den IBM-Systemen (Hardware und Betriebssysteme) auf Wikipedia lesen. Auch auf IBM-Webseiten liegen interessante historische Informationen. Ein Déjà-vu-Effekt stellt sich dabei immer wieder ein: Es begegnet einem Ende der 60er Jahre nicht nur ein Hypervisor, sondern auch die Tatsache, dass schon damals Betriebssysteme und wichtige Teile davon von einer aktiven Open-Source-Community entwickelt und genutzt wurden, etwa JES2 – als Houston Automatic Spooling Program alias HASP bei der NASA entstanden. (ofr)
|
Infos |
|---|
|
[1] Hercules: [http://www.hercules-390.org] [2] Umrechnungstabelle für DASD-Größen: [http://www.sdisw.com/vm/dasd_capacity.html] [3] Think Blue/64-Linux: [http://linux.zseries.org] [4] Centos: [http://www.centos.org] [5] Redbook, “Linux for IBM eServer zSeries and S/390 Distributions”: [http://www.redbooks.ibm.com/redbooks/pdfs/sg246264.pdf] [6] Redbook-Portal für Linux: [http://www.redbooks.ibm.com/Redbooks.nsf/portals/Linux] [7] MVS 3.8J Turnkey: [http://www.ibiblio.org/jmaynard/turnkey-mvs-3.zip] [8] Infos zum Turnkey-System: [http://www.bsp-gmbh.com/turnkey/index.html] [9] Community Development System for Linux (LCDS): [http://www-03.ibm.com/systems/z/os/linux/lcds] [10] Mips-Werte aktueller Mainframes: [http://www-03.ibm.com/servers/ch/downloads/gold/LSPR-Mips_2005_08_17.pdf] |
|
Der Autor |
|---|
|
Bernhard Bablok betreut bei der Allianz Shared Infrastructure Services ein großes Datawarehouse mit technischen Performance-Messdaten von Mainframes bis zu Servern. Wenn er nicht Musik hört, mit dem Radl oder zu Fuß unterwegs ist, beschäftigt er sich mit Themen rund um Linux und Objektorientierung. Er ist unter [mail@bablokb.de] zu erreichen. |
