Open Source im professionellen Einsatz

© codswollop, photocase.com

Der Mainframe-Emulator Hercules

Große Kiste, kleine Kosten

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:
Argumente für Configure

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.

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:
Hercules-Konfiguration für Centos 4.5

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
Mainframes

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.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 8 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook