| ![[Photo of the Author]](../../common/images2/CuneytGoksu.jpg)  von  Cüneyt Göksu
 <cuneytgoksu(at)usa.net>
 
 Über den Autor:
 
 Datenbankspezialist, der seit mehr als zwölf Jahren mit allen
    kommerziellen Datenbanken auf größeren Plattformen arbeitet, darunter auch
    Linux! 
 Übersetzt ins Deutsche von:
 Viktor Horvath <ViktorHorvath(at)gmx.net>
 
 Inhalt:
 | 
 
| Linux für S/390 (IBM z/Series)![[Illustration]](../../common/images2/article328/ibm390.gif)  Zusammenfassung:
 
 S/390 ist eine robuste Hardware-Plattform von IBM für große
    Unternehmen. Jetzt läuft Linux darauf. _________________ _________________ _________________
 
 | 
     
Geschichtliches
    Als das Betriebssystem Linux 1991 erschien, arbeitete es auf IBM
    PC-Kompatiblen. Seither ist es auf viele andere Architekturen portiert
    worden: Apple, Atari und 68000-basierte Amiga-Computer, Sun
    SPARC-Workstations, Alpha-basierte PCs und MIPS, PowerPC, HP PA-RISC und
    ARM.
    S/390 ist der Name der Großrechnerarchitektur von IBM. Sie wurde in
    großem Umfang mit IBMs Betriebssystemen VM, VSE und z/OS (früher MVS und
    OS/390) benutzt. IBM hat 1999 Linux zu einem „nativen“
    Betriebssystem für diese solide Architektur gewählt.
    Der wichtigste Grund, Linux auf der S/390-Plattform zu implementieren,
    war die Konsolidierung der Verbindung zwischen alten Applikationen,
    Linux-Applikationen und Middleware wie Webserver, Mailserver, Application
    Server, Firewall etc.
    Die Ansicht ist verbreitet, daß Linux als eine API oder Emulation auf
    der S/390-Plattform arbeitet, aber das stimmt nicht, es läuft als ein
    „natives“ Betriebssystem, so daß die Möglichkeiten der ganzen
    Hardware dieser Plattform ausgeschöpft werden können. Der Linux-Kernel und
    der Common Code werden ohne jede Modifikation benutzt, und die
    Systemstruktur von Linux bleibt unberührt. Nur einige
    „Anpassungen“ sind nötig, um Spezifika der S/390-Architektur zu
    berücksichtigen. Sie arbeitet mit dem ASCII-Zeichencode anstatt mit
    EBCIDIC.
     
Linux-Integration in die S/390 und zSeries-Architektur
    Linux kann auf drei verschiedenen Weisen auf einer S/390 installiert
      werden.
    
      - Nativ: Es wird direkt auf der Hardware installiert -
      wahrscheinlich nicht die Lösung der Wahl, weil nur ein Betriebssystem
      auf der Hardwareebene läuft.
- Logische Partitionen (LPAR): Die Hardware-Partitionierung
      ermöglicht bis zu 15 „logische Partitionen“, auf jeder läuft
      ein getrenntes Betriebssystem, traditionelle wie MVS, VSE, OS/390 oder
      Linux.
- Virtuelle Partitionen (z/VM): Das wird z/Series Virtualization
      Technology genannt. Es unterstützt eine hohe Zahl von Linux-Images (über
      1000) mit weitreichenden Fähigkeiten zum Systemmanagement auf derselben
      Hardware. Diese Art der Installation ist sehr flexibel und gut für
      Server-Systeme.
Im folgenden Diagramm werden diese drei Installationswege gezeigt:
     
 
    
    Wenn die Zahl der benötigten Linux-Server 15 oder weniger ist, ist die
      LPAR-Lösung eine gute Wahl. Wenn du mehr brauchst, 100 oder 1000
      Linux-Images, ist z/VM die Antwort.
    Red Hat, SuSE und Turbolinux sind größere Distributionen für S/390 und
    zSeries. Du kannst die Links unten benutzen, um sie herunterzuladen.
    
    
    SuSE: 
    
    
    TurboLinux: 
    
    Es gibt auch einige Distributionen mit vorkompilierter Software. Du
      kannst sie über diese Links bekommen.
    
     
Distributionen für S/390 und zSeries
    
     
    Die Voraussetzungen für Linux auf der S/390
    
      - 9672 G5/G6, Multirise 3000 oder z/Series 800, 900, 990
      IBM-Prozessor
- 64 MB Speicher (Minimum - hängt von der Distribution und den
	Applikationen ab)
- 500 Zylinder Plattenplatz (Minimalsystem für das Model 3390)
- Unterstützung von IBM Netzwerken: Ethernet, Token Ring, Fast
      Ethernet, ESCON, OSA oder HiperSocket (mindestens eins davon). Es werden
      noch mehr Arten unterstützt.
- Bevor Linux ein Gerät benutzen kann, muß der entsprechende Treiber
      für das zSeries bzw. S/390-Gerät dem Kernel zur Verfügung stehen.
- Es gibt kernelresidente und externe Treiber für S/390 und
      zSeries-Geräte.
- Externe Treiber sind Module, die auf Anforderung über Befehle mit
      Parametern geladen werden.
- Residente Treiber erhalten ihre Parameter während des Bootvorgangs
      von einer Zeile mit Kernelparametern, die in einer Datei steht.
- Es gibt Treiber, deren Quelltext nicht offenliegt (OCO - Object Code
      Only). Sie unterliegen bestimmten Lizenzbedingungen (z.B. QETH für OSA
      Express GbE und Hipersocket, Tape 3590). OCO-Treiber sind nicht unbedingt
      in jeder Distribution vorhanden. Wenn sie fehlen, müssen sie von IBM
      DeveloperWorks heruntergeladen werden.
Warum Linux für S/390?
    Der wichtigste Grund ist die Konsolidierung der Server.
    Die dreischichtige Applikations-Architektur kann leicht in
    zweischichtiger Hardware umgesetzt werden. Die drei klassischen Schritte
    Client - Application Server - Data Server können in der S/390 etwa so
    zusammengefaßt werden: Application Servers - Datenbanken. Hipersocket und
    Fiberchannel unterstützen die Merkmale des Kommunikationssubsystems, und
    Verbindungsprobleme verschwinden. Alte Applikationen wurden zu verteilten
    und dann zu web-basierten Applikationen. Zuerst wurden Daten, dann
    Applikationen überallhin verteilt. Die Zahl der Server stieg enorm an, was
    einige Problemem mit sich brachte:
    
      - Jeder neue Server bedeutet neue Hardware, Speicher, höheren Bedarf an
      Kühlung, Verkabelung, Verbindungen etc. Diese „physischen“
      Parameter müssen beobachtet und angepaßt werden.
- Alle Software in einem jeden Server muß lizensiert werden, was
      zusätzliche Kosten bedeutet. Zum Beispiel muß deine Datenbank auf jedem
      Server für jeden Prozessor lizensiert werden.
- Die Verbindungen sind ein weiterer wichtiger Punkt. Kabel, Gateways,
      Switches, Routers und all solche Komponenten erhöhen die
      Gesamtkosten.
- Wiederherstellungslösungen nach Ausfällen sind mit individuellen
      Servern kaum zu schaffen. Die Operations- und Wartungskosten steigen,
      alles wird mit einer sehr großen Serverzahl komplizierter bis ganz
      unmöglich.
- Datenbank-, Applikations- und Systemmanagement sowie die CPU- und
      Lastverteilung müssen für jeden Server einzeln erledigt werden.
Das waren einige der möglichen Probleme, wenn Linux-Images auf
    verschiedener Hardware laufen. Wenn sie alle auf einer einzigen
    S/390-Plattform untergebracht sind, verändert sich die Situation:
    
      - Obwohl alle Linux-Images sich dieselbe Hardware teilen (CPU,
      Eingabe/Ausgabe-Subsystem, Speicher etc.), verhalten sie sich wie
      individuelle, jeweils exklusive logische Server und können für
      verschiedene Arten von Applikationen genutzt werden. Auf diese Weise hat
      eine höhere Zahl von Servern keine höheren Wartungskosten. Sie können
      leicht überwacht und kontrolliert werden, sie sparen Zeit. Die Ressourcen
      werden geteilt, aber der Durchsatz des Systems wird maximiert.
- Alle Server teilen sich dieselbe CPU, so daß die Kosten für
      Softwarelizenzen fallen.
- Alle Verbindungen zwischen den Servern sind intern, so daß der
      hardwarebedingte Kommunikations-Overhead gegen Null geht und die
      Netzwerk-Performance maximiert wird.
- Einen neuen Server hinzuzufügen ist ebenso einfach wie das Klonen
      eines logischen Servers.
- Wiederherstellung nach Ausfällen ist viel einfacher, realistischer
      und machbarer. DASD (Direct Access Storage Device)-Farmen und Subsysteme
      können schnell und sicher in Minuten kopiert werden mit FlashCopy, PPRC
      (Peer-To-Peer-Remote-Copy) oder Snapshot.
     
     
Weiterführende Literatur:
    
      - Linux for S/390, IBM Redbook
- Linux for z/Series, Atruro Calandrino, zSeries Tech.
      Support
Talkback für diesen Artikel
Jeder Artikel hat seine eigene Seite für Kommentare und Rückmeldungen. Auf dieser Seite kann jeder eigene Kommentare abgeben und die Kommentare anderer Leser sehen:
<--, zurück zum index dieser Ausgabe 
2004-03-01, generated by lfparser version 2.46