Spricht man heute von massiv-parallelen Rechnersystemen im kommerziellen Bereich, so assoziiert man dies meist mit Systemen, die urspruenglich fuer den wissenschaftlichen Bereich entworfen wurden; sie suchen nun ein erweitertes Spektrum in Grenzbereichen der ehedem von Mainframes abgedeckten kommerziellen Anwendungen.

Drei Aufgabenfelder eignen sich als offensichtliches Einsatzgebiet paralleler Rechnerarchitekturen in der kommerziellen Welt. Allen voran der sogenannte Decision Support mit Applikationen wie EIS oder MIS, der im wesentlichen Informationen aus grossen Datenmengen gewinnt, um sie zur Planung, Kontrolle und Wettbewerbsanalyse zu nutzen. Anwendungen im Handel zeigen, dass hier ein starkes Interesse im Bereich der Analyse von Abverkaufsdaten (Scanning) besteht. Sortimentsoptimierung, Warenverbundsanalyse, Produktrentabilitaet, bezogen auf Regionen und aufgeschluesselt bis auf einzelne Filialen, sind keine Zukunftsvisionen. Antwortzeiten bei der Analyse von Bondaten auf dem Mainframe werden anstatt in Tagen in Minuten oder Stunden gemessen, und dies bei Datenbanken mit mehreren 100 GB.

Transaktionsverarbeitung ist wohl die natuerlichste Form von paralleler Verarbeitung, weil das Problem schon von vornherein parallelisiert ist. Als Beispiel sei die hollaendische Telekom (Dutch PTT) genannt, die ueber 50 Prozessoren und eine Datenbank mit ueber 400 GB zum Verarbeiten der Einzelgespraechsnachweise im Einsatz hat (etwa 40 Millionen Inserts pro Tag). Hier deutet sich schon an, dass nur sehr hochverfuegbare Computersysteme mit einem robusten Kernel-Betriebssystem und voll parallelisierten Datanbankoperationen fuer solche Anwendungsfelder in Frage kommen.

Auch im Trend liegen die "Messaging Systems". Diese verbinden Tausende von Benutzern in komplexen Netzwerken und versorgen Message Enabled Applications wie Electronic Mail, EDI oder Multimedia sowie die zugehoerige automatische Abrechnung. Der Nachrichtenverkehr verlaeuft parallel, viele der Serviceangebote koennen parallel oder verteilt stattfinden, und die Groessenanpassung erfolgt durch Hinzufuegen von Prozessoren, Kommunikationsanschluessen und Massenspeichern.

Sehr wichtig fuer die beiden letzten Bereiche ist eine hohe Verfuegbarkeit dieser Dienste. Auf den ersten Blick mag dies fuer die erste Kategorie nicht unbedingt erforderlich sein. Doch angesichts der Akzeptanz von Decision Support Systemen (DSS) in Marketing, Controlling, Marktforschung etc. spielt das Vorhandensein dieser Dienste eine ganz betraechtliche Rolle.

Viele Vorstoesse, wissenschaftliche Probleme mit massiv-parallelen Architekturen zu loesen, zielen lediglich auf hohe Gesamtrechenleistung. So sieht man haeufig Hunderte von Rechnern mit verhaeltnismaessig wenig Hauptspeicher und so gut wie keiner Peripherieverbindung auf engstem Raum.

Kommerzielle Anwendungen haben voellig andere Beduerfnisse. Zum Beispiel erfordern Datenbank- oder Transaktionsanwendungen schnelle Platten, viel Hauptspeicher und Prozessor-Cache im Verhaeltnis zur Rechenleistung. Parallelitaet ist nicht nur bei der Programmausfuehrung gefordert, sondern auch im Ein/

Ausgabe-Bereich. Deshalb nutzen viele Anwendungen die Multiprozessor-Architektur SMP (Symmetric Multiprocessing). Zunehmend wird den Benutzern die limitierte Skalierbarkeit dieser Systeme bewusst, und die Vorteile einer skalierbaren MPP- Architektur zeigen sich.

SMP-basierte Systeme muessen eine oder mehrere Hardware- Systemkomponenten (Hauptspeicher, Prozessorbus etc.) teilen. Dies fuehrt dazu, dass mit wachsender Prozessoranzahl der Leistungszuwachs immer geringer wird, bis sich letztlich kein oder sogar negativer Leistungszuwachs ergibt. Ueblicherweise verstaerken das Betriebssystem und Datenbank-Managementsystem diesen Prozess des Leistungsabfalls.

Im Gegensatz zu SMP-Systemen zeichnen sich MPP-Systeme (auch lose gekoppelte Systeme genannt) dadurch aus, dass sie keine oder nur wenige gemeinsam genutzte Systemkomponenten haben. Vorteile dieser Architektur sind vollstaendige, unabhaengige Verarbeitung der gestellten Aufgaben (starke Kapselung) - wenn dies vom Betriebssystem und Datenbanksystem unterstuetzt wird - und die daraus resultierende Skalierbarkeit.

Die lineare Skalierbarkeit von lose gekoppelten Tandem-Himalaya- Servern wurde kuerzlich mit dem Modell K10000 demonstriert. In einer Serie von vier Benchmarks wurden die besten jemals gemessenen TPC-C Werte annaehernd um den Faktor zehn uebertroffen, und gleichzeitig wurde gezeigt, dass die Maschine einen fast linearen Leistungszuwachs verzeichnen kann.

Viele kommerzielle Applika-tionen, besonders im Bereich der eingangs erwaehnten Transaktionsverarbeitung, tendieren heute in ihrem Anforderungsprofil in Richtung 24-Stunden-Betrieb an 365 Tagen im Jahr. Systemausfaelle, die im wissenschaftlichen Anwendungsbereich moeglicherweise toleriert werden, sind fuer kommerzielle Benutzer voellig unannehmbar.

Unter Annahme typischer Komponentenzuverlaessigkeit und fuer typische Konfigurationen aus dem MPP-Bereich hat man die Gesamtsystemverfuegbarkeit der Hardware im Modell gerechnet. Dieses Modell basiert auf einer Kombination von permanenten sowie transienten Fehlern, mit einem Verhaeltnis von 4,2 transienten pro permanentem Fehler.

Fehlertoleranz ist gerade in grossen Systemen wichtig

Transiente Fehler sind die unangenehmsten ueberhaupt: Sie treten daten- und umgebungsbedingt vereinzelt auf und lassen sich schlecht oder gar nicht reproduzieren, zum Beispiel um die Ursache festzustellen. Abbildung 1 zeigt die daraus resultierende MTTF (Mean Time To Failure) in Abhaengigkeit von der Systemgroesse.

Das Modell zeigt klar, wie wichtig Fehlertoleranz in groesseren Systemen mit vielen Prozessoren tatsaechlich ist. Ein 1000- Prozessor-System wuerde demnach einmal taeglich ausfallen. Der Einsatz von Fehlertoleranz erhoeht andererseits die Verfuegbarkeit um etwa vier Potenzen.

Der naechste Problembereich ist die Anwendungssoftware. Erfahrungen zeigen, dass durch rigorose Kapselung einzelner Softwarekomponenten, die in diesem lose gekoppelten System grundsaetzlich nur ueber Nachrichtenaustausch verkehren, 80 Prozent aller harten Softwarefehler weder zum Ausfall von Diensten noch zur Verfaelschung von Daten fuehren. Angesprochen sind hier Fehler in der Betriebs-, Datenbank- oder Kommunikationssoftware, die den Stillstand eines einzelnen Prozessors nach sich ziehen.

Transiente Fehler erschweren die Prognose

Weitere Verursacher von Ausfaellen sind Einfluesse, die durch das unglueckliche Zusammentreffen von Ereignissen im Gesamtsystem entstehen koennen (transiente Fehler). Solche Fehler sind in der Regel nur durch sorgfaeltige Analyse und das Aufbereiten von Statistikinformation greifbar zu machen.

Alle genannten Anforderungen muessen in einer Gesamtarchitektur muenden, die aus einem Zusammenspiel von fehlertoleranter Hard- und Software besteht. Vom Betriebssystem ueber die Datenbank bis hin zur Hardware ist also zu gewaehrleisten, dass sich die Komponenten ergaenzen.

Die Basis zur Bewaeltigung der bisher erlaeuterten Anforderungen bildet ein verteiltes und rein nachrichtenorientiertes Betriebssystem, wie der Nonstop-Kernel von Tandem, der folgende Vorteile aufweist:

Single System Image: Im wesentlichen bedeutet dies, dass alle wichtigen Funktionen unabhaengig davon, wo diese implementiert sind oder ausgefuehrt werden, in jedem Prozessor transparent zur Verfuegung stehen. Ob Betriebssystem-Funktion, Datenbankaufruf oder Kommunikation mit anderen Programmen, der Benutzer sieht keinen Unterschied zu einem herkoemmlichen System mit nur einem Prozessor.

Beim Ausfall einer Komponente, sei es ein Prozessor, eine Steuereinheit oder ein Kanal, sorgt das Betriebssystem automatisch fuer die Zuweisung alternativer Ressourcen. Eine weitere wichtige Aufgabe ist die Verhinderung von Split-Brain-Syndromen, die eine einheitliche und korrekte Reaktion auf Einzelausfaelle sichern.

Das Betriebssystem reagiert unterschiedlich auf Softwarefehler. Entdeckt es eine Inkonsistenz oder ein Fehlverhalten im Betriebssystem oder anderen systemnahen Komponenten, schaltet es den eigenen Prozessor ab, um eine Weiterverbreitung des Fehlers zu verhindern und um im zweiten Schritt eine Uebernahme der fraglichen Funktionen in ein anderes Modul zu erreichen. Durch die veraenderte Umgebung auf dem neuen Prozessor wiederholen sich transiente Softwarefehler mit grosser Wahrscheinlichkeit nicht.

Bei Fehlern von Applikationen wird das betroffene Programm beendet und die vorgesehene Fehlerbehandlung eingeleitet. Meist bedeutet dies auch eine Uebernahme der Aufgabe durch ein anderes Modul.

Message-System: Um schnell und problemlos zwischen Komponenten im selben wie auch in anderen Prozessoren kommunizieren zu koennen, gehoert in das Betriebssystem ein Message-System, das jede Komponente im Systemkomplex mit jeder anderen kommunizieren laesst.

Personalities: Wie bei heute ueblichen Mikrokernel-Konzepten offeriert Tandem unterschiedliche Betriebsystem-Umgebungen. Die Guardian-Personality (ein anderes Betriebssystem von Tandem) stellt einen Investitionsschutz fuer bestehende Kunden dar, waehrend die Unix-Personality als Zielplattform fuer offene, massiv- parallele Anwendungen (Server) gilt. Beide Personalities koennen gleichzeitig auf einem Prozessor vorhanden sein, um bestehende und offene Anwendungen parallel zu nutzen. Moeglich ist dies alles, indem die beiden Betriebssystem-Umgebungen auf den gleichen Basisfunktionen des Nonstop-Kernels aufbauen und sich nur durch unterschiedliche Betriebssystem-Aufrufe (API) unterscheiden.

Middleware: Eine wichtige Rolle fuer die Portabilitaet und Interoperabilitaet von Anwendungen spielt die Middleware mit ihren standardisierten APIs einerseits fuer die Applikation und als funktionale Kapselung des Betriebssystems andererseits.

Im Gegensatz zu allen bekannten Datenbanksystemen wurde Nonstop- SQL/MP von Anfang an fuer eine parallele Hardware-Architektur entwickelt. Seit 1987 ist das ANSI-SQL-konforme, relationale Datenbank-Managementsystem (RDBMS) bei zahlreichen Unternehmen im produktiven Einsatz.

Wichtige Funktionen, die im Laufe der Jahre hinzukamen, waren eine Nonstop-Verfuegbarkeit der Datenbank fuer Endbenutzeranfragen bei gleichzeitiger Pflege der Datenbank durch den DB-Administrator (Online-Reorganisation, Online-Backup/Recovery, Online-Partition- Split, Move, Drop, Add etc).

Nonstop-SQL/MP hat ein sehr effizientes verteiltes Lock-Management und eine skalierbare Client-Server-Architektur mit einer Aufgabenteilung, die den erforderlichen Nachrichtenverkehr stark reduziert. Es unterstuetzt sowohl die natuerliche Parallelitaet von konkurrierenden Transaktionen als auch die Dekomposition von Queries in viele parallel ablaufende Einzelvorgaenge (Parallel Query).

Ausfallsicherheit und Datenintegritaet

Funktionen, die einzelne Relationen betreffen, sind direkt auf den Basisfunktionen des Nonstop-Kernels, im sogenannten Data Access Manager (DAM), implementiert. Der DAM kann alle Funktionen, die eine Relation betreffen, direkt ausfuehren und im allgemeinen bereits erheblich reduzierte Daten an das DBMS weitergegeben. Typische Aufgaben fuer diese untere Ebene sind Aggregatfunktionen und sequentielle Suchvorgaenge. Mit einem Konzept der virtuellen Blockung zwischen DAM und DBMS werden vorselektierte Saetze in neue Bloecke gepackt, gebuendelt und hoechst effizient an den jeweiligen anderen Teil geleitet. Dies hat zur Folge, dass nur die ausgewaehlten Felder einer jeden Zeile durch das System zum DBMS transportiert werden muessen. Daraus resultiert ein drastisch verminderter Datentransport im gesamten System (Prozessor, Interprozessorbus).

Fazit: Fehlertolerante Hardware ist eine Voraussetzung fuer kommerzielle MPP-Rechner.

Schon heute, und mehr noch in der Zukunft werden MPP-Systeme zum Einsatz kommen. Man muss diesen Systemen aber auch trauen koennen. Ausfallsicherheit und absolute Datenintegritaet sind bei solchen Systemgroessen unumgaenglich.