Es geht auch ohne Grossrechner Unix ist jetzt auf dem Weg zum Betriebssystem fuer OLTP

11.06.1993

*Daniel Hewett ist Support-Manager der Sequoia Systems Inc. Europe, Heidelberg.

Seit kurzem gibt es eine ganze Reihe von Herstellern, die Unix auch fuer die Online-Transaktionsverarbeitung OLTP anbieten. Seit im Herbst vergangenen Jahres selbst die IBM mit CICS/6000 in diesen Markt eingestiegen ist, verstummen die Zweifel an der Einsetzbarkeit solcher Systeme in kommerzielle DV-Umgebungen. Daniel Hewett* zeigt im folgenden die Staerken von Unix-basierten OLTP-Systemen auf.

Die Versuche OLTP zu definieren, rufen eine kontroverse und emotionsgeladene Diskussion hervor. Eine allgemeingueltige Definition gibt es nicht und wird es wohl auch nicht geben. Daher laesst sich diese Form der Datenverarbeitung gewoehnlich durch die Eigenschaften der Umgebung definieren, in der sie eingesetzt ist.

Typischerweise verarbeiten OLTP-Systeme grosse Mengen von Daten im interaktiven, sprich: Online-Betrieb, fuehren also umfangreiche Transaktionen durch. Diese Aufgaben gleichen sich in hohem Masse. Sie beziehen sich auf grosse Datenpools und erledigen simple Aufgaben wie eine wiederholte Datenbankanfrage oder Kontoaktualisierung. Diese Vorgaenge treten meist in schneller Folge auf. Der Online-User verlangt von einem Transaktionsverarbeitungs-System ueblicherweise Antwortzeiten ueber das Netz im Bereich von einer Sekunde oder darunter.

Transaktionen koennen nicht dynamisch verifiziert oder wiederholt werden, daher muessen OLTP-Systeme gewaehrleisten, dass sie vollstaendig ablaufen. Mit anderen Worten: Ein OLTP-System muss faehig sein, zwischen dem Beginn und dem Ende einer Transaktion zu unterscheiden und einen Mechanismus bereitstellen, um missglueckte Transaktionen anzuzeigen oder sie zu wiederholen. Weiterhin sollte gesichert sein, dass die Datensammlungen oder Datenbanken, auf deren Grundlage die Anwendungen laufen, verfuegbar sind, wenn sie gebraucht werden und darueber hinaus gegen Eingriffe in die Datenintegritaet geschuetzt sind.

Heute verlassen sich immer mehr Unternehmen auf Systeme mit OLTP- Merkmalen, um einen Wettbewerbsvorteil zu erreichen. Diese Systeme reagieren schnell auf Benutzeranfragen. Ausserdem haben sie zentrale Bedeutung fuer die Einnahmenentwicklung eines Unternehmens. Sie nehmen Transaktionsdaten auf, die sie in angemessener Zeit verarbeiten. Die Benutzer erhalten verbindliche Antworten zu genau dem von den Kunden gewuenschten Zeitpunkt (vgl. Kasten, Seite 38).

Bei den im Kasten aufgefuehrten Beispielen ist das Online- Transaktionsverarbeitungs-System von der Betriebsumgebung abhaengig. Sie stellt die noetigen OLTP-Kapazitaeten bereit.

Die Umgebung besteht aus einem Betriebssystem, das die verfuegbaren Hard- und Softwareressourcen kontrolliert und optimiert sowie aus einer verlaesslichen Hardwareplattform. OLTP- Anwendungen sind von den zugrundeliegenden Systemfaehigkeiten absolut abhaengig, wenn es um ihre datenverarbeitenden Funktionen geht.

Folgende Eigenschaften einer Betriebsumgebung sind fuer OLTP- Anwendungen besonders wichtig:

- Datenbank- oder Dateisystem-Softwarepakete muessen die sogenannten Acid-Eigenschaften Atomizitaet, Konsistenz, Isolation und Dauerhaftigkeit garantieren.

Daneben wird eine Software benoetigt, die die Transaktionsverarbeitung ueberwacht und den Transaktionsfluss regelt.

- Das OLTP-Betriebssystem und die Hardware muessen in der Lage sein, grosse Mengen an Transaktionen in akzeptabler Zeit zu erledigen. Die Antwortzeiten sollten unterhalb einer Sekunde liegen. Das Betriebssystem muss der Anwendung die Leistungsfaehigkeit der benutzten Hardwareplattform zur Verfuegung stellen koennen.

- Das Betriebssystem ist zudem fuer die Unterstuetzung grosser, schneller und flexibler I/O-Konfigurationen zustaendig. Es muss in der Lage sein, viele hundert interaktiv arbeitende Anwender gleichzeitig zu versorgen. Es muss daher zumindest irgendeine Form der Multiprogrammierung unterstuetzen. Weiterhin sollten Vorkehrungen zur physischen Vernetzung einer grossen Anzahl von Usern getroffen werden koennen.

Die Unterstuetzung grosser Datenbankstrukturen auf Platte und im physischen Speicher ist ebenfalls von Bedeutung. Ausserdem muessen die fuer Wartung und Verwaltung des Betriebssystems zustaendigen Funktionen so konzipiert sein, dass sie mit solchen Datenstrukturen umgehen koennen.

- Unerlaesslich ist auch eine Garantie fuer Datensicherheit und Systemverfuegbarkeit. Oft muessen Daten ohne Ausfallzeiten verarbeitet werden. Nachpruefbare Zuverlaessigkeit ist ebenfalls ein wichtiger Gesichtspunkt.

- Eine sichere Verarbeitungsumgebung haelt die Gefaehrdung der Ablaeufe so gering wie moeglich und gewaehrleistet Datensicherheit. Das Betriebssystem muss die OLTP-Anwendung bei der Abwehr nicht autorisierter System- und Datenzugriffe unterstuetzen. Das Verfaelschen von Daten, sowohl absichtlich und zielgerichtet als auch durch ein Missgeschick, muss ausgeschlossen sein.

Dieser Anforderungskatalog laesst sich noch um einige Features erweitern, die fuer einen sinnvollen OLTP-Betrieb wuenschenswert sind. Dazu gehoert eine skalierbare Betriebssystem-Architektur, die hilft, Hardware-Investitionen zu minimieren und dabei die Systemverfuegbarkeit steigert. Skalierbare Systeme ermoeglichen dem Anwender einen gleitenden Uebergang von geringer Systembelastung zu hohen Anforderungen.

Ausserdem sollte die Betriebssystem-Architektur anpassungsfaehig genug konzipiert sein, um Innovationen bei neuen Hardware- und Softwaretechnologien zu unterstuetzen. Im Idealfall bedeutet das, dass sich neue Loesungen in ein existierendes System integrieren lassen, ohne die bereits funktionierenden Ablaeufe unterbrechen zu muessen. Ein in geeigneter Weise flexibel gestaltetes System wuerde eine derartige modulare Aufruestung sowohl im Hardware- als auch im Softwarebereich erlauben.

Schliesslich wird die Forderung nach einer offenen Architektur immer dringlicher. Solche Systeme sind in der Regel von den Anschaffungskosten her guenstiger, erleichtern die Anwendungsentwicklung und ermoeglichen eine systemuebergreifende Kompatibilitaet. Schliesslich sind auch OLTP-Anwendungen nicht isoliert, sondern muessen sowohl am gleichen Ort als auch ueber grosse Distanzen mit anderen Anwendungen kommunizieren.

Wie gut schneidet Unix bei diesen hohen Anforderungen an ein Betriebssystem ab, was leistet es in heutigen OLTP-Umgebungen?

Die Vorteile von Unix liegen auf der Hand. Urspruenglich machte AT&T den Unix-Quellcode gegen Gebuehr fuer jeden zugaenglich. Diese Vertriebspolitik fuehrte zur Vorstellung von Unix als einem offen konstruierten System. Eigenschaften und Umfang von Unix waren einer wachsenden Zahl von Interessierten bekannt und verstaendlich. Es gab keinen Versuch, die innere Arbeitsweise des Unix- Betriebssystems zu verheimlichen.

Als Nebeneffekte dieser Offenheit gelten: Portierbarkeit der Anwendungssoftware, Verfuegbarkeit von relationalen Datenbanksystemen und TP-Ueberwachungssoftware, eine Unmenge Tools und Utilities und die Zusammenarbeit mit anderen Systemen ueber ein vielfaeltiges Angebot an Uebertragungsprotokollen.

Diese Faehigkeiten verlangen die Anwender nun auch fuer den kommerziellen Einsatz und wollen daher OLTP-Systeme in den Anwendungskatalog aufgenommen wissen.

Von Anfang an war das Betriebssystem Unix modular und in deutlich unterscheidbaren Schichten aufgebaut. Die Hardwarefunktionalitaet wurde durch ihre Implementierung in den Unix-Kernel klar vom nicht hardwarespezifischen Code getrennt.

Dieses modulare Design machte die Unix-Umgebung relativ leicht ueber eine Reihe deutlich verschiedener Hardware-Architekturen transportierbar.

Ausserdem zeigten einige Prinzipien des urspruenglichen Unix- Designs dessen Eignung als OLTP-Umgebung von vornherein. Unix war als Multitasking- und Multiuser-faehiges Betriebssystem entwickelt worden.

Der Mehrprogramm-Betrieb erlaubt einzelnen Benutzern und Anwendungen gleichzeitig den Zugriff auf die Systemressourcen. Dazu gehoeren auch eine Zeitablaufplanung fuer den Gemeinschaftsbetrieb, Speicherverwaltungsroutinen, Kommunikationsmoeglichkeiten zwischen Prozessen sowie Mehrplatz- Sicherheitsmassnahmen wie Benutzeridentifizierung und - autorisierung.

Das Dateisystem ist hierarchisch aufgebaut und so implementiert, dass es auswechselbar bleibt. Ausserdem kann es mehrere gleichzeitig arbeitende Benutzer durch Kontrolle und Schutz der Zugriffsbeschraenkungen unterstuetzen. Geraete- und Datei-Ein- und Ausgabe wurden zueinander kompatibel und strukturunabhaengig entworfen. Ein weites Spektrum von Software-Entwicklungswerkzeugen und die Programmiersprache C ermutigten zur Entwicklung von Anwendungspaketen.

Die ersten kommerziellen Unix-Versionen tauchten 1974 auf. Diese Produkte waren dazu bestimmt, auf Rechnern wie der PDP-11 von DEC zu laufen. Bis Mitte der 80er Jahre unterstuetzte Unix weder Hochleistungs-CPUs, umfangreiche Netzwerk- und Terminalverbindungen noch grosse physische Speicher- und Platten- Implementierungen oder Hardware-Simultanverarbeitung. Auch waren weder die Verarbeitungsfunktionen noch der Code des Kernels hinreichend zuverlaessig.

Wichtiger fuer den OLTP-Bereich ist, dass die I/O-Leistung und Flexibilitaet innerhalb von Unix schon immer als die Schwachstellen des Betriebssystems galten. Dateistrukturen und Dateiumfang liessen viel zu wuenschen uebrig. Fragmentierung und geringe Blockgroesse verhinderten hohe Uebertragungsraten von und zu den Plattenlaufwerken.

Die Unzuverlaessigkeit dieses Subsystems fuehrte bei Fehlfunktionen zu Problemen mit den Dateien. Der Mangel an Adressierbarkeit bei grossen Platten-Verbundsystemen limitierte darueber hinaus die Groesse der Datenbanken.

Die Art der Vernetzung von Terminals und Rechnern passte selten zu den anderen verfuegbaren Geraeten. So konnten grosse Platten- Verbundsysteme und Netz- oder Terminalsysteme nicht auf demselben System koexistieren.

Das Problem der Datenintegritaet hat man einfach links liegenlassen, da Zuverlaessigkeit nicht zu den urspruenglichen Zielen von Unix gehoerte. Das gleiche gilt fuer die Systemverfuegbarkeit. Jeder Kenner ist vertraut mit der sogenannten Unix-Panic. Schon dieses eine Merkmal liess DV-Managern, die Unix fuer OLTP-Anwendungen in Erwaegung zogen, Schauer ueber den Ruecken laufen.

Weitere Einschraenkungen ergaben sich durch die Notwendigkeit, das Betriebssystem bei jeder Kernel-Aenderung neu zu generieren. Dazu gehoerte die Modifizierung der Kernel-Parameter, die Rekompilierung des Kernels und der Neustart des Systems. Die Algorithmen fuer die Zeitverwaltung von Prozessen und Transaktionen basierten auf einem Zeitscheiben-Mechanismus nach der unflexiblen Reihum-Methode. Es gab keine Moeglichkeit, wichtigen Transaktionen im System Prioritaeten zuzuweisen.

Aufgrund dieser Maengel ist es kein Wunder, dass den fruehen Unix- Versionen die Faehigkeit abgesprochen wurde, in grossem Massstab Online-Transaktionsverarbeitungen zu unterstuetzen. Der Bedarf an OLTP war jedoch vorhanden. Nun fiel den Hardwareherstellern, die Unix-Systeme als Betriebssystem fuer ihre Hardware mitlieferten, die Aufgabe zu, am Unix-Kernel spezielle Veraenderungen vorzunehmen, um OLTP zu ermoeglichen.

Doch bevor die Anbieter diese Aufgabe in Angriff nehmen konnten, war es noetig, einen Satz allgemeiner Funktionen festzulegen. Die Gemeinsamkeiten wurden inzwischen durch die verschiedenen Komponenten der System-V-Interface-Definition (SVID) und durch Routinen, die in der System V Verification Suite (SVVS) zu finden sind, fixiert. Jede Anwendung, die in Uebereinstimmung mit der SVVS geschrieben wird, ist relativ einfach auf dazu konforme Plattformen portierbar.

Der modulare Aufbau der Unix-Architektur erlaubte eine Modifikation des zugrundeliegenden Unix-Kernels, waehrend das spezifische Look and feel einer robusten Betriebsumgebung fuer Endanwender und Anwendungsentwickler beibehalten wurde. Die wahrscheinlich bedeutendste Veraenderung an den Kernel-Routinen betraf die Unterstuetzung einer groesseren Anzahl von Prozessoren mit hoeherer Leistung.

Dabei gab es zwei Varianten. Eine Herstellergruppe richtete sich auf hierarchische Multiprozessor-Umgebungen aus. Andere entschlossen sich, eine Unix-Architektur in Form lockerer Verbaende zu implementieren.

Das Ergebnis ist die als System V bekannte Version des Unix- Betriebssystems. Es unterstuetzt inzwischen in der Version V.4 symmetrisches Multiprocessing und kommt in bestimmten Implementierungen selbst mit massiv-parallelen Prozessorarchitekturen zurecht.

Ein zweiter Problemkreis war die Speicherverwaltung. Fruehe Unix- Versionen unterstuetzten hier einmal mehr nur simple Prozess- Auslagerungsroutinen, um einen Mehrprogramm-Betrieb zu ermoeglichen. Die urspruenglichen Anforderungen setzten lediglich voraus, dass das System den Ueberblick behielt, welche Speicherabschnitte zu welchen ausgefuehrten Programmen zuzuordnen waren. Wenn das System mehr Speicherplatz benoetigte, wurden ganze Programme vom Hauptspeicher auf Platte ausgelagert.

An den Unix-Speicherverwaltungs-Komponenten sind zahlreiche Veraenderungen vorgenommen worden, damit sich auch ein Teil von Prozessen verlagern und eine Aufteilung von Programmablaeufen auf mehrere Speicherseiten - soweit die Hardware dies erlaubte - realisieren liess.

Funktionen zur gemeinsamen Nutzung von Speicherbereichen durch mehrere Prozesse kamen hinzu. Diese gemeinsam genutzten Abschnitte konnten vor Swapping und Paging geschuetzt werden. Auch Daten und Text eines Prozesses liessen sich im Speicher bei Ablaeufen mit hoher Prioritaet gegen ein Verlagern sperren.

Gemeinsam genutzter Speicherplatz ist eine besonders wichtige Einrichtung, um Unix fuer OLTP-Umgebungen zu optimieren. Erst dieses Feature macht es moeglich, grosse Datenbanken effizient zu bearbeiten und die Antwortzeiten zu verbessern, da aktuelle Daten anstatt auf Platte im physischen Speicher gehalten wurden.

Die OLTP-Anbieter bemuehten sich auch, die Zahl der moeglichen Arbeitsplaetze zu erhoehen, die sich an ein Unix-System anschliessen lassen. Interne Datenstrukturen von Unix sind inzwischen dahingehend geaendert, dass zumindest grundsaetzlich eine unbegrenzte Zahl von interaktiven Terminalverbindungen unterstuetzt wird. Das System laesst mehrere Ablaeufe gleichzeitig zu. Auf der Hardwareseite stehen jetzt Schnittstellen sowie Verbindungsstrukturen fuer lokale Netze (LANund Weitbereichsnetze (WANzur Verfuegung.

Weitere Bemuehungen galten der Sicherung der Datenintegritaet. Hier lagen lange Zeit die groessten Vorbehalte der Anwender. Der Unix- Kernel ist jedoch durch AT&T und das Unix System Laboratory (USL) einem staendigen Debugging unterworfen und in seiner Zuverlaessigkeit verbessert worden.

Einzelne Hersteller haben Probleme des Kernels unabhaengig von USL beseitigt. Sie entfernten oder maskierten die beruechtigten Panic- Fehler, schrieben Teile des Kernels unter Zuhilfenahme von Fehlervermeidungs-Techniken um und stellten, im Falle von Sequoia, Software-uebergreifende Detektions- und Wiederherstellungs- Mechanismen bereit.

Viele OLTP-Umgebungen verlangen eine kontinuierliche Systemverfuegbarkeit. Um sie zu garantieren, setzten die Hardware- Anbieter auf die Verwendung von besonders erprobten Bauteilen mit hohen Fehlertoleranzen. Auf diese Weise konnte die Zuverlaessigkeit von Unix erheblich gesteigert werden. Auch die Plattenspiegelung ist hier ein zentrales Feature.

Zu den Erweiterungen gehoert auch die Moeglichkeit, Kernel- Parameter waehrend des Programmlaufs - "on the fly" - zu aendern und die Leistung waehrenddessen online zu ueberwachen. Somit sind "sys gens" fuer das Betriebssystem nicht mehr erforderlich, was die Nutzungszeit des Gesamtsystems verbessert. Die Chance, Wartungsarbeiten am System online durchzufuehren, einschliesslich der Online-Ergaenzung von Ressourcen, sorgt ebenfalls fuer kontinuierlich verfuegbare Systeme, die fuer OLTP-Umgebungen unbezahlbar sind.

Ein weiteres zentrales OLTP-Merkmal ist realisiert worden: Es koennen feste Prioritaetsschemata bereitgestellt werden. Dies erlaubt den Ablauf der Transaktionen in einer zweckmaessigen Reihenfolge und laesst relativ wichtigen Transaktionen mehr CPU- Zeit.

Waehrend all dieser Veraenderungen an der Unix- Betriebssystemumgebung blieb eine gemeinsame, standardisierte Linie erkennbar. Anwender, die mit einer bestimmten Auspraegung von Unix vertraut sind, werden kaum Schwierigkeiten haben, zu irgendeinem anderen Unix-System zu wechseln. In aehnlicher Weise lassen sich Anwendungen, die auf SVVS oder SVID abgestimmt wurden, ohne grossen Aufwand auf andere normgerechte Systeme portieren. Dazu gehoeren auch aktuelle Anwendungspakete von Drittanbietern, also etwa relationalen Datenbank-Systeme fuer OLTP und TP- Ueberwachungsprogramme. Der groesste Vorteil liegt jedoch in der Optimierung der Hardware-, Software- und Personalkosten.

Dreh- und Angelpunkt der naeheren Zukunft von Unix als Grundlage fuer OLTP ist die Konsolidierung und Standardisierung der vielen bereits bestehenden OLTP-Funktionen. Die aufgelisteten Leistungsmerkmale haben sich in bezug auf die Anforderungen der Online-Transaktionsverarbeitung bereits bewaehrt. In den naechsten Jahren werden sich USL und die wachsende Zahl der Unix-Anbieter darauf konzentrieren, standardorientierte Unix-Plattformen mit OLTP-Faehigkeiten zu implementieren.

Beispiele fuer OLTP-Anwendungen

Das klassische und oft zitierte Beispiel fuer den OLTP-Einsatz ist das Reservierungssystem der Fluggesellschaften. Es besteht aus einer grossen Datenbank, die Flugplaene, Preise und Informationen ueber die Verfuegbarkeit von Sitzplaetzen enthaelt.

Zugang zu dieser Datenbank erhalten Reisebueros, Unternehmen und private Anwender, die den Reservierungsservice in Anspruch nehmen wollen, durch ein grosses Kommunikations-Netzwerk. Ausserdem wird diese Datenbank von den Fluggesellschaften mit neuen Flugplaenen und Ticketpreisen aktualisiert.

Sobald Anwender auf das System zugreifen koennen, fuehren sie eine Reservierungsfunktion - also eine Transaktion - durch. Das System bestaetigt alle abgeschlossenen Transaktionen. Sobald ein Platz zu einem festgesetzten Preis reserviert wurde, erhaelt der Benutzer die Bestaetigung oder sein Ticket. Das System muss intelligent und flexibel genug sein, denselben Platz nicht zweimal zu vergeben (obwohl dies oft absichtlich geschieht) und die Datenbank ueber kurzfristige Veraenderungen des Flugplans zu informieren.

Dieser fuer unsere Zwecke

vereinfacht dargestellte Ablauf kann einige tausend Mal pro Sekunde auftreten, und das 24 Stunden am Tag. Das Sabre-System der American Airlines erledigt ueber 2500 Transaktionen pro Sekunde, rund um die Uhr, sieben Tage die Woche, 365 Tage im Jahr. Diese enorme Menge an interaktiven Transaktionen macht es nicht leicht, die Forderung der Anwender nach sekundenschnellen Antwortzeiten zu erfuellen und dabei auch die Zuverlaessigkeit der Buchungen zu gewaehrleisten.

Als anderes Beispiel fuer OLTP-Einsatz seien die Geldautomaten genannt, die in Banken den Kassierer ersetzen. Sie bieten Genauigkeit, Systemverfuegbarkeit und schnelle Antwortzeiten. Diese Transaktionen sind klar definiert und bestehen im allgemeinen aus Anfragen des Benutzers ueber den Kontostand, Abhebungen, Einzahlungen und anderen Buchungen.

Benutzer von Geldautomaten erwarten verlaessliche und schnelle Bankdienste. Dazu gehoert, dass die Dienstleistung rund um die Uhr verfuegbar ist. Nichts wuerde die Kunden schneller zur Konkurrenz treiben als ein Netz von Automaten, die nicht zu jeder Tageszeit in Betrieb sind.