Von CW-Redakteurin Sabine Ranft
MÜNCHEN (COMPUTERWOCHE) - Bei der Migration von SNA auf IP prallen zwei Welten aufeinander. Schon die Konzeption der Netze weicht grundlegend voneinander ab. Das hat auch für den Mainframe, traditionell in SNA-Umgebungen beheimatet, Konsequenzen: Er lässt sich nicht ohne weiteres in TCP/IP-Landschaften integrieren. Nur wer die auftauchenden Klippen geschickt umschifft, dürfte mit seinem Netz glücklich werden.
Die Dinosaurier der DV sind noch nicht ausgestorben. In Banken und Versicherungen sowie vielen Rechenzentren dienen sie nach wie vor als riesige Datenspeicher und beherbergen wichtige Anwendungen. Doch ihre Rolle wandelt sich: Der Mainframe gewinnt eine immer stärkere Bedeutung als universeller Daten- und Applikations-Server mit intelligenten Clients. Dies weckt bei IT-Verantwortlichen den Wunsch nach Windows- und IP-orientierten Anwendungen sowie dezentralen Datenwelten. Eine Vorstellung, die sich allein auf Basis des IBM-Protokolls Systems Network Architecture (SNA) nicht realisieren lässt. Daher denken viele Firmen über eine Ablösung oder Ergänzung dieses Verfahrens durch das Internet Protocol (IP) nach.
Problem Token Ring
Normalerweise trifft man SNA und Hosts im Token-Ring-Umfeld an. Das hat historische Gründe: Die Mainframes (beziehungsweise ihre Vorrechner) waren von Haus aus mit Token-Ring-Anschlüssen ausgestattet, weil IBM dieses Verfahren immer favorisiert hatte. Mit dem Aufkommen IP-typischer Applikationen wie etwa Intranets begannen die Anwender, in ihren Token-Ring-Netzen neben SNA auch IP zu betreiben.
Für die Koexistenz beider Protokolle sind mehrere Varianten denkbar: Schicht-2-Netze, protokollbasierende virtuelle LANs (VLANs) oder Schicht-3-Netze. Auf die erste Alternative sollte man verzichten, weil sie keine Trennung der Broadcast-Domänen vorsieht. Neben dem Verkehrsproblem in solchen Netzen wirken sich darin auch doppelt vergebene IP-Adressen sofort nachteilig auf das gesamte Netz aus.
Virtuelle LANs dagegen eröffnen die Chance einer sanften Migration. Sie fassen zum Beispiel alle SNA-Nutzer in einer logischen Gruppe zusammen und die IP-Nutzer in einer anderen. Allerdings sind protokollbasierende VLANs noch nicht endgültig standardisiert und schrecken zudem durch ihre Komplexität bei der Konfiguration der Switches und bei der Fehlersuche ab. Zumindest im Backbone bieten sich daher Layer-3-Netze an. Um hier die Komplexität zu begrenzen, rät Behrooz Moayeri, Netzwerkspezialist von Comconsult in Aachen, in dem Seminar "Der Mainframe im IP-Netz", wo nicht zwingend erforderlich auf aufwändige Mechanismen wie Quality of Service (QoS) zu verzichten.
Die beschriebenen Möglichkeiten, IP neben SNA zu betreiben (Layer 2, VLANs, Layer 3), stehen auch Token-Ring-Anwendern zur Verfügung. Allerdings ist klar, dass der Token Ring keine Zukunft mehr hat - zum Beispiel, weil dessen Bandbreite von 16 Mbit/s oft nicht mehr ausreicht und High Speed Token Ring nur noch von einem Hersteller (Madge) unterstützt wird. Daher wächst der Druck auf Token-Ring-Anwender, auf Ethernet zu migrieren.
Für diesen Schritt existieren laut Moayeri zwei Alternativen: Entweder man überträgt die Protokollvielfalt - in der Regel SNA und IP - eins zu eins von Token Ring auf Ethernet, oder die Umstellung auf IP als einziges Protokoll erfolgt gleichzeitig mit der Token-Ring-Ethernet-Migration. Für die zweite Möglichkeit spricht, dass IP ohnehin die strategische Ausrichtung in der DV widerspiegelt. Zudem müssen die Endgeräte bei dieser Variante nur einmal angefasst werden. Der Haken an der Geschichte: Anwendungen und Endgeräte im Mainframe-Umfeld basieren heute meist noch nicht auf IP und lassen sich nicht kurzfristig umstellen. Falls im neuen Netz nur IP betrieben werden soll, muss daher das alte Netz vorübergehend erhalten bleiben. Das bringt einen Mehraufwand mit sich. Entweder man nimmt das in Kauf oder wählt doch die erste Alternative.
Keine Alles-oder-Nichts-Entscheidung
Wie diese Diskussion zeigt, ist die Migration auf IP keine Alles-oder-Nichts-Entscheidung. Oft bleiben die SNA-Ströme erhalten. Das kann zum Beispiel in einem getrennten (SNA-)Bereich des Netzes der Fall sein. Meist werden die SNA-Daten jedoch in IP eingepackt. Der Standard hierfür heißt "Data Link Switching" (DLSw). Dafür braucht man DLSw-taugliche Switches. Auf den Clients sorgt das DLSw Client Access Protocol (DCAP) für den Zugang. Falls nur wenige IP-Anwendungen geplant sind, kann auch umgekehrt IP in SNA eingepackt werden. Für den Umgang mit den Altanwendungen gibt es "kein Allheilmittel, aber verschiedene Wege, die sich beschreiten lassen", so Moayeri.
Am elegantesten wäre es, die Legacy-Applikationen einfach umzuschreiben. "Aber das machen die wenigsten", kommentiert Peter Hager, SNA-Spezialist und Geschäftsführer bei der Net´Q GmbH aus München. Er verweist auf Befragungen, in denen Kunden schon vor sechs Jahren angaben, gewisse Anwendungen (IMS-Transaktionen) innerhalb von drei Jahren auf IP umstellen zu wollen. Bei einer inzwischen erfolgten erneuten Befragung lautete die Antwort genauso - in der Zwischenzeit war nichts passiert. "Der Wille ist zwar da, aber es fehlen Spezialisten", fasst Hager das Dilemma der Anwender zusammen.
3270 dank Telnet kein Problem mehr
Immerhin bereitet eine Sorte Applikationen heutzutage keine Bauchschmerzen mehr: die 3270-Anwendungen. Sie stellen 95 Prozent der Mainframe-Anwendungen und basieren auf entsprechenden dummen Terminals. Mit Hilfe des Telnet-Protokolls lassen sie sich über IP übertragen. Der Datenstrom von 3270-Terminals unterscheidet sich von Telnet vor allem in zwei Punkten: Die Kommunikation erfolgt in Blöcken, nicht in einzelnen Zeichen. Und die Terminals verwenden die EBCDIC- statt der ASCII-Darstellung. Welche Darstellungsform bei der Übertragung gewählt wird, handelt der Telnet-Server auf Seite des Mainframes mit dem Telnet-Client aus. Je nachdem, wo der Server platziert wird, kann er einen "Single Point of Failure" darstellen. Das bedeutet, wenn er ausfällt, ist die Verbindung zum Host unterbrochen. Während "Telnet 3270" noch einige Einschränkungen aufweist (keine Emulation von 328x-Druckern oder fehlendes Handling von SNA-Antworten), sind diese Schwachstellen in der Erweiterung Telnet 3270E (TN3270E) behoben.
Als ebenfalls unproblematisch gilt mittlerweile der physikalische Netzanschluss des Mainframes. Er erfolgt über OSA-Express-Adapter von IBM. Sie sind für Fast Ethernet, Gigabit Ethernet und ATM verfügbar. Die Fast-Ethernet- und die ATM-Variante unterstützen SNA und IP, die Gigabit-Ethernet-Variante nur IP. Eine Alternative, etwa für nicht OSA-Express-fähige ältere Mainframe-Generationen, bietet zum Beispiel der CIP-Router (Channel Interface Program) von Cisco. Laut Hager bleibt der Durchsatz einer solchen Lösung jedoch hinter dem der Adapter zurück.
Schwierigkeiten resultieren dagegen aus der völlig unterschiedlichen Netzkonzeption bei SNA und IP. SNA-Netze gelten als schnell und robust. IP-Netze dagegen haben dieselben Adressierungsprobleme wie das Internet. Es muss ein durchgängiges und transparentes Adresskonzept erarbeitet und mit allen Teilnehmern abgestimmt werden. Das geschieht über so genannte DNS- (Domain Name System) und DHCP-Server (DHCP = Dynamic Host Configuration Protocol), die zusätzlich aufgebaut werden müssen. SNA macht das im Prinzip alles selbst. Auch um die Garantie von Bandbreiten und Verfügbarkeit musste sich unter SNA niemand kümmern. Im IP-Netz dagegen sind dafür Service Level Agreements (SLAs) nötig - oder höhere Netzkapazitäten. Unter Umständen ist es sinnvoll, Lasttests vorzunehmen, weil IP-Anwendungen wie Streaming-Video ein anderes Lastverhalten haben als typische SNA-Anwendungen.
Ein weiteres Problem betrifft das Drucken, da viele LAN-Printer keine SNA-Datenströme verstehen. Für die Umwandlung gibt es zwei Möglichkeiten: Entweder sie findet schon im Host statt oder am Drucker. Falls auf dem Host die Freeware "Samba", ein NT-Fileserver für Unix-Systeme, läuft, ist das Problem vom Tisch. Dann agiert der Mainframe wie ein ganz normaler Server. Sonst fährt man SNA bis zum Drucker und hat dort einen Drucker-Port, der die Umsetzung vornimmt.
Zum Hemmschuh für die Migration können sich auch die Implementierungskosten entwickeln. Das ist etwa der Fall, wenn Router-Upgrades erforderlich sind, die in Netzen mit rund 8000 Routern wie bei der amerikanischen Sozialbehörde Social Security Administration leicht Zusatzausgaben in Höhe von zwei Milliarden Dollar verursachen. Müssen außerdem noch die Endgeräte ausgetauscht werden, kommt die Kostenlawine ins Rollen. "Das holt einen wieder auf den Boden der Tatsachen zurück", gibt Hager zu.
Doch Kosten und Technik sind nicht die einzigen Fallstricke, über die Anwender bei der Mainframe-Migration auf IP stolpern können. Auch mangelnde Planung zieht oft ernsthafte Konsequenzen nach sich. "Der häufigste Fehler besteht darin, dass sich niemand genügend Gedanken gemacht hat, warum das (SNA-)Netz so war, wie es war", kritisiert Hartwig Bazzanella, Geschäftsführer der NCB Informationstechnik AG in Herrenberg. Im einzelnen ist nämlich zu klären, welche Applikationen auf welchem Endgerät mit welchen Daten arbeiten und welche Anwendungen auf dem Server oder dem Host laufen. Man muss wissen, wie sieht der Weg dorthin aus und welcher Service Level auf dieser Verbindung nötig ist. Erst dann kann das Design des neuen Netzes beginnen. Oft entstehen durch die Migration auch Sicherheitslücken, besonders bei den Host-Anwendungen.
Werden die mit der Mainframe-Integration in TCP/IP-Netze verbundenen Risiken nicht ernst genommen, kann eine erhebliche Destabilisierung sowohl des Mainframes als auch der gesamten IP-Umgebung eintreten. Ein typisches Merkmal ist die sprunghaft erhöhte Anzahl von Neustarts des Mainframes (Initial Program Load = IPL). So genannte "Locate Storms", die etwa einem Broadcast Storm in einem IP-Netz entsprechen, drücken die Performance und blockieren Rechner. Auch die Verfügbarkeit des ganzen Netzes kann darunter leiden.
Zusammenfassend entwirft Hager folgendes Szenario für eine sinnvolle Migration: Workstations sollten auf IP umgestellt und 3270-Datenströme über Telnet übertragen werden. Es kann außerdem sinnvoll sein, andere Alt-Anwendungen über IP zu tunneln (via Data Link Switching). Zwischen den Mainframes sollte man SNA durch dessen Weiterentwicklung Advanced Peer-to-Peer Networking (APPN) ersetzen und den "Enterprise Extender" nutzen. Der Enterprise Extender ist eine (Gateway-)Software, die auf der einen Seite APPN spricht und auf der anderen Seite IP bedient.
Einen Ausblick in die Zukunft der Mainframes wagt Hartwig Bazzanella von NCB: Er sieht den Host künftig in der Rolle eines Superservers. Ein Superserver integriert 50 bis mehrere hundert normale NT- oder OS/2-Server. Konkret könnte der Mainframe etwa als logischer Linux-Cluster genutzt werden. Allerdings ist das heute noch Zukunftsmusik. Logische Linux-Cluster befinden sich gerade in der Testphase.
GLOSSAR: Mainframe-Jargon
SNA: IBM entwickelte seine Systems Network Architecture in den 70er Jahren. Weit mehr als ein Protokoll, das die Kommunikation zwischen zwei Komponenten regelt, definiert SNA auch bestimmte Geräte im Netz und welche Funktionen diese erfüllen.
TCP/IP: Die Protokollfamilie Transport Control Protocol/Internet Protocol verdankt ihren Erfolg dem Internet. Sie ermöglicht die Kommunikation zwischen unterschiedlichsten Geräten, die über feste und dynamische IP-Adressen angesprochen werden. TCP/IP erobert zunehmend auch die Unternehmensnetze.
DLSw: Data Link Switching ist eine von der Internet Engineering Task Force (IETF) im Request for Comment (RFC) 1795 offen gelegte Spezifikation. Sie sieht die Kapselung von SNA und Netbios in TCP/IP vor. So lassen sich diese normalerweise nicht zueinander kompatiblen Verfahren gleichzeitig betreiben.
APPN: Bei Advanced Peer-to-Peer Networking handelt es sich um eine Weiterentwicklung von SNA. Sie macht SNA-Daten routbar und erlaubt neben Terminals auch anderen Geräten den Zugriff auf Host-Anwendungen und -Daten.
Enterprise Extender: (Gateway-)Software für Mainframes, die auf der einen Seite APPN und auf der anderen Seite IP bedient.
OSA-Express: Adapter für den physikalischen Netzanschluss von Mainframes aus dem Hause IBM. Die Fast-Ethernet- und die ATM-Varianten unterstützen IP und SNA, die Gigabit-Ethernet-Adapter nur IP. Außerdem lassen sie sich nicht in älteren Mainframe-Generationen einsetzen.
ASCII: American Standard Code for Information Interchange = Amerikanischer Normcode für Informationsaustausch (verbreiteter Zeichencode für PCs).
EBCDIC: Extended Binary-Coded Decimal Interchange Code = erweiterter binär verschlüsselter Dezimalzahlenaustausch-Code (vor allem bei Großrechnern verwendet).
3270: Spezielle Sorte von Host-Anwendungen und -Terminals. 3270-Datenströme werden nicht in Zeichen, sondern ganzen Blöcken übertragen. Zudem fußt die Übertragung auf der EBCDIC-Codierung (nicht auf ASCII).
TN3270(E): Überträgt 3270-Datenströme mit dem Telnet-Protokoll über IP. TN3270 unterliegt diversen Einschränkungen: Beispielsweise sind keine Emulation von 328x-Druckern und keine Weiterleitung von SNA-Responses möglich. Der Client geht davon aus, dass alle zum Telnet-Server gesendeten Daten entweder verarbeitet werden oder verloren gehen. Diese Schwachstellen sind in der Erweiterung TN3270E beseitigt.
Samba: Die Freeware Samba ist eines der gebräuchlichsten Produkte, um auf dem Host normale PC-Welten zu betreiben. Sie kann sämtliche File- und Daten-Dienste, die normalerweise von vielen Servern erbracht werden, auf den Mainframe verlagern und Dateien an die Endgeräte übertragen.