Clustering-Architekturen (Teil 2)

Data General setzt mit Numa auf Standardkomponenten

31.01.1997

Historisch gesehen haben die Computerbauer aus Westboro, Massachusetts, in Sachen kommerzielle Numa-Systeme die Nase vorn. Seit Herbst 1995 vermarktet Data General mit der "Aviion 10000" einen Server auf Basis von Motorolas "88K"-Prozessoren, der nach dem Numa-Verfahren arbeitet. Wie beim Vorgängermodell "AV 9500" setzten die Entwickler vier CPUs und Cache auf ein Board. Hinzu kamen Arbeitsspeicher und ein PCI-I/O-System auf jeder Platine. Insgesamt acht Boards oder maximal 32 Prozessoren ließen sich in einem Rechner unterbringen.

Bei den AV-10000-Rechnern handelte es sich um Numa-Systeme, denn es gab einen nahen und einen entfernten Arbeitsspeicher sowie eine einzige Kopie des Betriebssystems - das herstellereigene Unix-Derivat DG-UX - für den ganzen Verbund. Für die Verbindung zwischen den Boards verwendete DG ein großes Backplane-System mit vier 250-MB/s-Systembussen.

Mit dem Umstieg auf Intel-Technik tauschte DG das eigenentwickelte RISC-Modell gegen die "SHV-Type-II"-Board-Technik des Chipgiganten ein. Nach den Worten von Steven Aucoin, Director Product Marketing der neugegründeten Numaliine Business Unit, die für Entwicklung und Vermarktung der Numa-Systeme verantwortlich zeichnet, ergaben sich daraus wesentlich niedrigere Kosten. Statt des breitbandigen Backplane-Systems der AV 10000 benutzt DG mit dem SCI-Bus (SCI = Scalable Coherent Interface) eine Verbindung, die den Standards der Normierungsgremien ANSI und IEEE entspricht. "Wir erhielten damit auch eine kostengünstigere Verbindungstechnik", begründet Aucoin den Umstieg.

Auf dem Intel-Board sitzen vier Pentium-Pro-CPUs mit jeweils 512 KB Cache und 4 GB Arbeitsspeicher. Für den Zugriff auf das Massenspeichersubsystem stehen zwölf PCI-I/O-Slots in Form von zwei Orion-PCI-Brücken zur Verfügung. Die Verbindung zu den Arbeitsspeichern anderer Quadboards stellt ein SCI-Adapter her, der ebenfalls auf dem Mainboard steckt. Das SCI-Subsystem besteht aus zwei SCI-Ringen, die jeweils eine Datenübertragungsrate von 500 MB/s schaffen (zur Funktion des SCI-Subsystems siehe Kasten).

Data Generals wichtigster Konkurrent Sequent verwendet in seiner "Numa-Q"-Architektur ein verändertes Board-Design, das auf 18 Layern basiert statt auf 13 wie beim Intel-Standardprodukt. Darüber hinaus sind die Platinen mit doppelter Kühlung, einem Monitoring-Chip und einer kürzeren Busverbindung zwischen den Prozessoren ausgestattet (siehe CW Nr. 47 vom 22. November 1996, Seite 39: "Zwei Ringe sollen . . .").

Das Kernstück der Sequent-Implementierung bildet die sogenannte "IQ-Link"-Karte, die auf jedem Quadboard sitzt und die Verbindung zum SCI-Subsystem herstellt. Sequent entwickelte die Karte zusammen mit dem französischen Hersteller Vitesse. Als "Datenpumpe" dient ein Gallium-Arsenid-Chip, der die Datenpakete empfängt und verschickt.

Ein weiterer Unterschied zum DG-Modell liegt im Systembus selbst. Sequent arbeitet mit einem unidirektionalen SCI-Ring mit 1 GB/s Datentransferrate. DG erreicht mit zwei bidirektionalen Ringen ebenfalls einen aggregierten Durchsatz von 1 GB/s, verspricht mit seinem Konzept allerdings einige Vorteile. So könne etwa bei Ausfall eines Rings der zweite dessen Aufgaben übernehmen. Bei Sequents Numa-Q-Architektur sei dies nicht möglich.

Obwohl Sequent bereits im Herbst 1996 einen Intel-basierten Server mit der Numa-Q-Technik zeigte, gibt man sich bei Data General gelassen, was die Marktchancen der eigenen Numa-Implementierung betrifft. "Nach meiner Meinung verfolgt Sequent einen eher proprietären Ansatz, mit eigenen Boards und eigenem Betriebssystem", erklärt Aucoin. "Wir verwenden Gate-Arrays, die mit Dolphins Interconnect-Technik zusammenarbeiten, Sequent arbeitet mit teuren Gallium-Arsenid-Gate-Arrays von Vitesse." Der Hersteller verkaufe die Rechner auch nicht an OEMs, sondern ausschließlich direkt und ziele eindeutig auf das High-end. Damit bleibe für DG genug Raum, in den darunter liegenden Marktsegmenten erfolgreich zu sein.

Thomas Reiter, Produkt-Marketing-Manager bei der deutschen Sequent-Niederlassung in München, bestätigt die Ausrichtung auf das High-end. Er wehrt sich allerdings gegen den Vorwurf, ein proprietäres System anzubieten. "Wir mußten feststellen, daß die Skalierbarkeit der Standard-Boards, wie sie von Dolphin vertrieben werden, nicht unseren Anforderungen entsprach." Deshalb habe man auf die Vitesse-Datenpumpe zurückgegriffen, die die vierfache Leistung der Dolphin-Adapterkarte biete. Das übrige System entspreche aber dem Standard-SCI-Protokoll.

Für Rick Westerman, Analyst bei der Meta Group in München, handelt es sich bei Numa-Q tatsächlich um eine proprietäre Technik. Die Darstellung Data Generals sei aber zu negativ: Sequent sei mit der Performance der Dolphin-SCI-Technik nicht zufrieden gewesen und habe das Modell verändert. Das System sei zwar nicht mehr vollständig kompatibel zum IEEE-Standard, biete jedoch mehr Leistung. DG benutze eine reine IEEE-Lösung.

Die Frage nach einem proprietären oder offenen System spiele aber kaum eine Rolle, glaubt Westerman. Die Interconnect-Lösung mit Gallium-Arsenid-Technik sei auf den ersten Blick zwar etwas teurer. Die Unternehmen wechselten aber auf Numa, weil sie ein High-end-System wollten. Betrachte man die gesamten Anschaffungskosten eines solchen Systems inklusive Hardware, Software und Speicher, so verursache die Gallium-Arsenid-Lösung etwa ein Prozent mehr Kosten. Dies könne für eine Investitionsentscheidung nicht ausschlaggebend sein.

Sequent gibt für seine Architektur theoretische Grenzen an. Demzufolge lassen sich maximal 252 Prozessoren auf 63 Quadboards koppeln. Bei DG zeigt man sich diesbezüglich zurückhaltender. Das Betriebssystem unterstütze heute bis zu 64 CPUs auf 16 Boards im laufenden Betrieb. Generell seien aber auch Konfigurationen mit mehr als 100 Prozessoren denkbar. Erste Numaliine-Rechner werden voraussichtlich im Frühjahr 1997 verfügbar sein.

Auf der Softwareseite fährt Data General zweigleisig. Das Unix-Derivat DG-UX sei bereits für Numa optimiert worden, so Aucoin. Man arbeite darüber hinaus mit SCO zusammen, um die Unterstützung von SCO Unixware für Numa sicherzustellen. Dies sei vor allem für den OEM-Markt von Bedeutung. So hätten sich etwa DGs OEM-Kunden ICL und Unisys auf SCO als Unix-Plattform verpflichtet. Für die eigene Aviion-Produktlinie sei derzeit aber noch DG-UX erste Wahl, das beispielsweise eine Reihe von Hochverfügbarkeitsfunktionen biete, die Unixware noch nicht liefern könne. Auf längere Sicht werde Unixware auch für die Aviion-Rechner an Bedeutung gewinnen.

Mit Windows NT hegt Data General in Zusammenhang mit Numa offenbar keine großen Pläne. "NT läuft im Labor auf unseren Numaliine-Systemen", berichtet Aucoin. Das große Problem sei allerdings die Skalierbarkeit. Für viele Anwendungen lasse sich das Microsoft-System sehr schlecht skalieren. Auch wenn sich die Skalierbarkeit von NT in SMP-Umgebungen (SMP = Symmetrisches Multiprocessing) künftig etwas verbessern sollte, werde Unix das dominierende Betriebssystem bleiben.

Entgegen früheren Ankündigungen und einschlägigen Berichten in der Fachpresse müssen neben dem Betriebssystem auch Datenbanken für Numa modifiziert werden. Diese Anwendungen laufen zwar in einer Numa-Umgebung, nutzen die Vorteile der Architektur aber nicht voll aus. "Die großen Datenbank-Management-Systeme erledigen eine Reihe von Aufgaben, die normalerweise das Betriebssystem ausführt", erklärt Aucoin. Oracle verwalte mit seinem Programm beispielsweise auch Dateisysteme. DG arbeite deshalb mit den großen Herstellern wie Oracle, Sybase oder Informix zusammen, um die Numa-Unterstützung zu gewährleisten. Dies bedeute aber nicht, daß Anwender für eine Datenbank ein spezielles Modul oder eine neue Version benötigten. Die Numa-Unterstützung werde immer in das Standardprodukt integriert sein.

RISC-Unix-Anbieter sind die Verlierer

Trotz der teilweise noch ausstehenden Software-Unterstützung sagt Westerman dem Numa-Konzept eine große Zukunft voraus. "Die Welt wird sich in zwei Richtungen aufteilen", prognostiziert der Meta-Group-Analyst. Einerseits werde ein Großteil der Anwender nach wie vor RISC-Maschinen unter Unix einsetzen. Andererseits nehme die Zahl derer, die Numa- oder Numa-ähnliche Systeme betrieben, stetig zu. Traditionelle RISC-Unix-Anbieter wie Sun, HP oder DEC würden gegenüber Herstellern mit Intel-basierten Unix-Maschinen Marktanteile verlieren.

Für den Wettbewerbsvorteil eines Herstellers sei weniger die Preisgestaltung entscheidend als der Faktor Time-to-Market, meint Westerman. Sequents Numa-System sei schon verfügbar, DGs Produkte nicht. "Wer heute ein Numa-System einsetzen will, kann dies praktisch nur von Sequent bekommen." Allerdings bedeute dies nicht unbedingt Nachteile für Data General. Westerman: "Der Numa-Markt ist groß genug für mindestens drei Anbieter."

SCI-Adapter regelt den Datenverkehr

Der SCI-Adapter spielt bei DGs Numa-Implementierung die Schlüsselrolle. Fordert ein Prozessor Daten an, die sich weder im Level-2-Cache noch im Arbeitsspeicher des eigenen Boards befinden, aktiviert der Adapter das SCI-Subsystem. Der Adapter schickt eine Datenanforderung in Form eines Pakets über den SCI-Bus an einen entfernten Rechnerknoten (= SHV-Board). Dieser sendet die Informationen an den anfragenden Knoten. Über den SCI-Adapter gelangen die Daten in den jeweiligen Prozessor auf dem Intel-Quadboard.

Der Adapter vergleicht dabei stets die Speicherinhalte auf dem lokalen Board mit den Daten anderer Rechnerknoten und stellt so sicher, daß alle Kopien einer Cache-Information auf dem gleichen Stand sind (Cache-Kohärenz). Auf diese Vorgehensweise ist der Begriff cc:Numa (Cache Coherent Non Uniform Memory Access) zurückzuführen. Da ein Numa-System ohne Cache-Kohärenz wenig Sinn macht, wird auf den Zusatz "cc" häufig verzichtet.

Ziel des Numa-Konzepts ist es, Daten, die eine CPU gerade zur Verarbeitung benötigt, möglichst im lokalen (nahen) Cache vorzuhalten, statt von einem entfernten Knoten Informationen über den langsameren Systembus zu transportieren. Die Zauberwörter dabei heißen Speicher-, Prozessor und I/O-Affinität und beziehen sich auf einen typischen Vorgang in einer Multiprocessing-Umgebung: Wird ein laufendes Programm durch einen Interrupt von einer höher gelegenen Anwendung gestoppt, verlagert das Betriebssystem dieses Programm normalerweise auf einen anderen Prozessor. Damit wird vermieden, daß der Job auf die Beendigung des als vorrangig eingestuften Programms warten muß.

In der Numa-Architektur versucht das Betriebssystem, eine Verarbeitungsaufgabe so oft wie möglich auf dieselbe CPU zu relokalisieren. Gelingt dies nicht, zielt das OS darauf ab, den Job zumindest auf dem gleichen Board zu plazieren. Nur wenn auch das wiederholt fehlschlägt, wird die Aufgabe auf einen anderen Rechnerknoten verlagert.

Die Entwickler wollen auf diese Weise erreichen, daß in weniger als fünf Prozent der Fälle auf eine entfernte Arbeitsspeicherreferenz über den SCI-Bus zugegriffen werden muß. Das Numa-System laufe zu 95 Prozent der Zeit mit der höheren internen Busgeschwindigkeit auf dem SHV-Board, proklamiert etwa Data General. Das Betriebssystem muß dazu fein abgestufte Locking-Scheduling-Algorithmen bereitstellen, die herkömmliche SMP-Betriebssysteme nicht bieten.