Alpha-Cluster unter Linux erfreuen sich als wissenschaftliche Rechenmaschinen großer Beliebtheit. Ein Erfahrungsbericht aus der Genomforschung.

Manche haben die gute alte Alpha von Digital (später Compaq) schon totgesagt, als Mitte 2001 die “Technologie- und Marketingvereinbarung” zwischen Compaq und Intel durch die Newsticker lief[1]. In der Genomforschung erfreut sich diese Architektur allerdings seit Jahren großer Beliebtheit. So arbeiten unter anderem Firmen wie Celera Genomics, das Sanger Centre (beide maßgeblich an der Sequenzierung des menschlichen Genoms beteiligt) oder die Sandia National Laboratories mit Alphas.

Das war ein Grund, warum auch in dem Göttingen Genomics Laboratory die Entscheidung fiel, beim Aufbau einer neuen Bio-Computing-Plattform im Rahmen des Kompetenznetzwerks Genomik (Genom-Forschung an Mikroorganismen)[2] Alpha-Rechner einzusetzen. Die 64-Bit-CPUs und die sehr guten Benchmarks[3] sprachen neben der konsequenten 64-Bit-Architektur und der Größe des adressierbaren Hauptspeichers von 4 GByte für diese Maschinen – einige der in der Genomforschung benötigten Applikationen (Phrap oder auch BLAST) können wahre Speicherfresser sein. Zudem spielten die guten Erfahrungen des lokalen Rechenzentrums mit Alpha-Rechnern eine wichtige Rolle bei der Entscheidung.

Hardware für den Cluster

Sechs Compaq-ES45-Server (auch unter dem Namen Titan bekannt) mit ebenso vielen USVs (R3000XR), ein Gigabit-Switch, ein Konsolen-Switch und ein 15-Zoll-TFT-Display, alles in zwei etwas tieferen 19-Zoll-Schränken verbaut (Abbildung 1), dienen zum Zusammensetzen, zur Annotation und zur Bearbeitung mikrobieller Genome. Außerdem ermöglichen sie es der wissenschaftlichen Gemeinde, die gewonnenen Daten nach für andere Gruppen interessanten DNS-Abschnitten zu durchsuchen.

Die ES45-Server verfügen jeweils über vier 64-bittige, mit einer Frequenz von 1 GHz laufende 21264C-CPUs (EV68) mit je 8 MByte L2-Cache in Double-Data-Rate-Technik[4]. Auf jeden der sechs Server kommen 16 GByte RAM, eine Grafikkarte, ein Gigabit-Ethernet-Adapter (Alteon AceNIC), ein Fibre-Channel-Adapter (QLogic ISP2200) und zwei loka-le Ultra-SCSI-3-Festplatten (10000 Umdrehungen je Minute, hot-plugable).

Jede Maschine wird von je drei Netzteilen à 720 Watt versorgt, die ihren Strom aus mit 16 Ampere abgesicherten Drehstromanschlüssen erhalten. Die 18 Netzteile produzieren eine nicht unerhebliche Menge an Abwärme, so dass Abluft und Klimaanlage im Serverraum aufgestockt werden mussten.

Abbildung 1: Die beiden 19-Zoll-Schränke des Göttinger Genomik-Clusters.

Vernetzte Datenlager

Das zugehörige Storage Area Network (SAN) ist bei der Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen (GWDG) untergebracht und über eine dedizierte Lichtwellenleiter-Verbindung von etwa vier Kilometern Kabellänge mit dem Alpha-Cluster verbunden. Es besteht aus dem 16-Port-Fibre-Channel-Switch, dem Compaq-EMA12000-RAID-System und Festplatten mit einem Nettovolumen von 2 Terabyte[5].

Das EMA12000 enthält zwei HSG80-Controller mit je zwei Fibre-Channel-Ports für einen automatischen Fail-Over. Da ein Controller über sechs Kanäle verfügt, bot es sich mit Rücksicht auf Performance und Ausfallsicherheit an, genau sechs der 36-GByte-Platten zu einem RAID-5-Set von (6-1)*36 GByte = 180 GByte zusammenzufassen. Damit scheint das SAN für die Rechner des Clusters aus neun SCSI-Laufwerken zu je 180 GByte zu bestehen, die sich – einmal per Fiber Channel zugänglich – ganz regulär als »/dev/sda«, »/dev/sdb« und so weiter ansprechen lassen.

Außer den Controllern wurden auch Kühlung und Stromversorgung redundant ausgelegt; die Platten sind selbstverständlich hot-plugable. Abbildung 4 gibt einen Überblick über die Anbindung der einzelnen Rechner an das SAN. Dabei wurde ein Storage-Netz aus Switches entsprechend dem Fabric-Konzept[6] aufgebaut. Als Fabric bezeichnet man den Bereich zwischen zwei Fibre-Channel-Ports. Das einzelne Endgerät mit FC-Port muss dabei nur eine einfache Punkt-zu-Punkt-Verbindung zwischen sich selbst und beispielsweise dem nächsten Switch managen.

Das hellere RAID-Set dient dem Cluster als »/opt«-Filesystem und liefert von allen Nodes benötigte Datenbanken und Programme. Hingegen stellen die grau unterlegten Sets das »/home«-Filesystem des Clusters dar, das unter Linux als RAID 0 verwirklicht wurde[7]. Da die benutzten Platten im EMA12000 auf zwei Controller verteilt sind, von denen sie als RAID 5 verwaltet werden, ist auch für Datensicherheit gesorgt, die bei reinem RAID 0 nicht gegeben wäre. Die Performance der SAN-Laufwerke ist dabei durchaus akzeptabel (Listing 1).

Um sich die aufwändigen Bonnie++-Messungen zu sparen, ermöglicht eine Web-Oberfläche einen Überblick über den aktuellen Datendurchsatz auf den Ports des Storageworks-Switchs (Abbildung 6). Die Daten können per SNMP ausgelesen und mit Tools wie »mrtg«[25] visualisiert werden.

Abbildung 4: Überblick über das Göttinger SAN.

Listing 1: Dem SAN auf den Tacho geschaut.

Abbildung 6: Mit diesem Web-Interface gewinnt man die Übersicht über den Durchsatz der einzelnen Ports auf dem SAN-Switch. Alternativ lassen sich die Daten auch per SNMP abgreifen und individuell aufbereiten.

Die Software-Seite

Zum Backup der RAID-Systeme kommt das Tivoli-System[9] der GWDG mit momentan 25 TByte Speicherkapazität auf Magnetbandbasis zum Einsatz. Da es für Linux-Alpha keine Tivoli-Clients gibt, sind die vorhandenen Filesysteme des Clusters aber an einen Intel-basierten Server zu exportieren, der diese zusätzlich zu seinen eigenen sichert.

Die Anbindung der einzelnen Rechner an das gemeinsame Dateisystem im SAN wird von einem als Masternode konfigurierten ES45-Server bewerkstelligt, der einzelne Verzeichnisse per NFS exportiert. Sein Ausfall brächte den Cluster derzeit zum Stehen, weshalb eine Fail-Over-Strategie auf ihre Umsetzung wartet. Dabei sollen sich die einzelnen Nodes durch Heart-Beat-Pakete gegenseitig prüfen. Erweist sich der Masternode dabei als nicht erreichbar, stellt ein Ersatznode seine Konfiguration um und übernimmt die NFS-Funktionalität.

Als Cluster-Software kommen zwei Systeme zum Einsatz: das Batchsystem OpenPBS[10] (siehe Beitrag über Jobmanagement-Systeme) und die freie Implementation des Message Passing Interface (MPI) für paralleles und verteiltes Rechnen, MPICH[11]. Letztere enthält auch eine Reihe von Tools zur Entwicklung und Analyse von parallelen Programmen auf der Basis des MPI-Toolkits. Als Bio-Applikationen werden vor allem BLAST, FAST[12], das Staden-Paket[13] zum Editieren der Sequenzen sowie Phrap und Phred[14] eingesetzt.

Linux-Installation mit kleinen Hürden

Dass die Rechner des Clusters unter Linux laufen, war keineswegs von Anfang an sicher. Zur Auswahl stand auch True64, das zum Beispiel schon aufgrund des in Compaqs Tru-Cluster-Software enthaltenen Cluster-weiten Dateisystems mit einem gemeinsam genutzten Root-Verzeichnis zunächst prädestiniert schien.

Bei der Entscheidung zu Gunsten von Linux spielte einerseits eine Rolle, dass das Betriebssystem der Abteilung von den Intel-basierten Servern her bereits bekannt war und kein Bedarf an einer weiteren, proprietären Lösung bestand. Andererseits sprachen auch seine weite Verbreitung im Bioinformatik-Umfeld und die gute Verfügbarkeit von Dokumentationen im Internet (zum Beispiel[15]) für den Pinguin.

Für die Alpha-Plattform zertifizierte Pakete bieten die Distributoren Red Hat, SuSE, Caldera und Turbolinux an. Dass Red Hat in jener Zeit gerade die Weiterentwicklung seiner Distribution in Zusammenarbeit mit Compaq ankündigte[16], gab letztlich den Ausschlag: Auf den Cluster-Rechnern kommt Red Hat Linux 7.1 zum Einsatz.

Bei der Installation[17] auf ES45-Servern ist zu beachten, dass die Grafikkarte unbedingt in einem Slot des PCI-Busses 0 stecken muss, sonst bleibt die Alpha-spezifische, für PC-Umsteiger etwas gewöhnungsbedürftige SRM-Konsole (eine Unix-ähnliche Boot-Firmware) bei dem Versuch Linux zu booten mit der Meldung »Jumping to bootstrap code« unweigerlich hängen. Schönheitsfehler des Red-Hat-2.4.3smp-Kernels (etwa die sich ständig verstellende Systemzeit) lassen sich durch Verwendung von Kernel 2.4.17 vermeiden.

Die Anbindung an das SAN klingt in der Theorie einfach: Kernel-Unterstützung für die Fibre-Channel-Karte einkompilieren, booten, partitionieren mit »fdisk«, Dateisystem erstellen mit »mkfs« und es schließlich mit »mount« verfügbar machen. Für die 64-Bit-Fibre-Channel-Adapter von QLogic mit dem ISP2200-Chip, die ab Kernel 2.4 unterstützt werden, sind dennoch einige in Listing 2 beschriebene Anpassungen nötig. Eine gute Übersicht zu Linux und Fibre Channel findet man unter[6].

Zudem gilt es, noch einige BIOS-Einstellungen der QLogic-Karten zu ändern (siehe Tabelle 1). Da ES45-Server dazu von sich aus keine Möglichkeit bieten, muss man einen etwas unkonventionellen Weg gehen und die 64-Bit-Karten in den 32-Bit-Slot eines PCs stecken und beim Hochfahren des Rechners [Alt] +[Q] drücken.

Listing 2: Fibre-Channel-Anbindung im Kernel 2.4.17.

Tabelle 1: BIOS-Einstellungen für den QLogic 2200.

Genom-Datenverarbeitung

Der klassische Arbeitsablauf beim Bio-Computing im Göttinger Genom-Labor sieht folgendermaßen aus: Automatische DNS-Sequenzierer liefern die zu verarbeitenden Daten – in unserem Fall DNS-Sequenzen, die dann entweder automatisch oder durch die Benutzer per Samba oder Appletalk auf ein SAN-Laufwerk kopiert werden. Als Nächstes sorgen die Alphas für das so genannte Basecalling und das Assemblieren der Genome.

Das Basecalling ordnet den einzelnen Signalen aus den Sequenzier-Daten die entsprechenden DNS-Basen zu. Zudem erhält jede virtuelle Base einen Qualitätswert, der angibt, mit welcher Verlässlichkeit die zugewiesene Base im sequenzierten DNS-Strang auch tatsächlich an dieser Stelle auftaucht.

Beim Assemblieren werden kurze (etwa 800 Basenpaare lange) DNS-Sequenzen zusammengesetzt, die im Prinzip nichts anderes darstellen als kurze Strings. Anhand von Überlappungen an den String-Enden entstehen größere zusammenhängende Zeichenketten, die letztlich die Gesamtsequenz eines Organismus darstellen.

Der Assembly-Prozess ist eine sehr RAM- und CPU-intensive Anwendung. So gelangte eine alte Sun Enterprise mit 2 GByte RAM schnell an ihre Grenzen; eine ES40 mit 4 GByte RAM war zwar schneller, hatte aber auch mit ihrer 4-GByte-RAM-Begrenzung zu kämpfen. Diese Erfahrungen führten dazu, dass bei der Anschaffung der neuen Maschinen besser auf genügend Hauptspeicher geachtet wurde. Die momentane Ausbaustufe des Clusters erlaubt mehrere parallele Assemblies und trägt somit der steigenden Anzahl von Sequenzierprojekten Rechnung.

Abbildung 2: Der Compaq-Storageworks-SAN-Switch mit Display und Bedienfeld für Konfiguration und Abfrage von Statusinformationen ist in der Mitte zu bestaunen. Die roten Kabel führen zu den Alphas.

Bio-Applikationen

In unserem Labor setzen wir das Paket mit Phred und Phrap[14] zur Verarbeitung (also Basecalling und Assembly) der produzierten Sequenzdaten ein. Eine Parallelversion von Phrap existiert zwar[19], wurde aber wegen ihrer exorbitanten Lizenzkosten nicht angeschafft. Doch auch mit der nicht-parallelen Version der Software lässt sich die Produktivität steigern, da durchaus mehrere Assemblies nebeneinander auf separaten Prozessoren laufen können.

Der nächste Schritt im Arbeitsablauf besteht darin, in den verfügbaren Genomdaten nach Genen zu suchen und diesen durch Vergleiche mit bekannten Genen eine Funktion zuzuordnen. Bei diesem Prozess der Annotation geht man davon aus, dass Gene, die auf DNS- beziehungsweise Protein-Ebene eine ausreichende Ähnlichkeit zu bekannten Genen aufweisen, dieselbe Funktion wie jene erfüllen. Für die Aufgabe wurden vor allem zwei Algorithmen entwickelt: BLAST und FAST (siehe Kasten “Algorithmen”).

Für die Annotation ist ein separater Server zuständig, der allerdings Anfragen an einen so genannten FAST/BLAST-Server stellt, der auf dem Alpha-Cluster läuft. Da BLAST erst im Rahmen der Software-Entwicklung in der Arbeitsgruppe parallelisiert werden soll, kommt das OpenPBS-Batchsystem zum Einsatz. BLAST stellt dem Benutzer über eine WWW-Oberfläche eine benutzerfreundliche Schnittstelle für den Abgleich von DNS- und Protein-Daten mit Protein-/DNS-Datenbanken[20] zur Verfügung. Die im Netz verfügbare WWW-BLAST-Version[21] ist nicht auf die Batch-Verarbeitung von Prozessen in Clustern ausgelegt, konnte aber mit einigen Änderungen in den mitgelieferten CGI-Skripten angepasst werden.

Bei FAST kommt eine parallelisierte Version[12] unter MPI zum Einsatz, die mit Hilfe der freien MPI-Implementation MPICH[11] auf bis zu fünf Nodes des Clusters läuft (dabei ist MPICH als SMP-Cluster konfiguriert). Die Software führt Abgleiche mit den Protein-/DNS-Datenbanken durch, die im SAN für alle Nodes verfügbar sind. Im Vergleich zum bisherigen System (zwei Pentium-III-1-GHz-SMP-Maschinen) als FAST-Clients zeigt sich eine deutliche Durchsatzsteigerung beim Annotationsprozess: Dieser Vorgang dauerte bisher bis zu fünf Tage pro Genom mit etwa 3500 Genen.

Auch das Update der Genom-Annotationsdaten kann deutlich beschleunigt werden, wenn neue DNS-Sequenzen aus dem Labor vorliegen (was täglich der Fall ist). Eine abschließende genaue Messung des Geschwindigkeitsgewinns erfolgte bislang aber noch nicht.

Da nun kontinuierlich ein aktuelles Abbild des Sequenzierfortschritts auf Annotationsebene zur Verfügung steht, erhalten die Forscher, die stets unruhig auf die Ergebnisse der Sequenzierung warten, schneller und vor allem verlässlichere Ergebnisse.

Open und closed Source

Alle genannten Bio-Applikationen liegen im Quelltext vor und lassen sich (fast) problemlos kompilieren und installieren. Als Compiler kam dabei zuerst der »gcc« und später der für Linux und EV6-CPUs optimierte Compaq-C-Compiler zum Einsatz[23].

Im Bereich der Systemsoftware sieht das etwas anders aus: Nicht nur der erwähnte Tivoli-Backup-Client liegt nicht als Open-Source-Software vor; Compaq gibt ebenfalls weder die Quellen der mitgelieferten Lansafe-III-USV-Software noch eine Linux-Version für Alphas heraus. Deshalb übernimmt mittlerweile der klassische »powerd«-Daemon[24] das Überprüfen der Stromversorgung.

Abbildung 2: Der Compaq-Storageworks-SAN-Switch mit Display und Bedienfeld für Konfiguration und Abfrage von Statusinformationen ist in der Mitte zu bestaunen. Die roten Kabel führen zu den Alphas.

Ausblick

Für die Zukunft ist geplant, die einzelnen Nodes von einem oder zwei Boot-Servern über das interne Gigabit-Ethernet zu booten und alle Filesysteme per NFS zu mounten. Gedacht wird dabei auch an den Einsatz eines Global-Filesystems über alle Nodes, um jedem einzelnen Node einen Anschluss an das SAN zu ermöglichen.

Momentan besteht dafür aber noch kein Bedarf, da die NFS-Anbindung stabil und schnell genug ist. Durch die Verwendung mehrerer Boot- und NFS-Server soll letztlich die Redundanz erhört werden. Auf Software-Seite ist geplant, so viel Software wie möglich mit dem Compaq-C-Compiler zu übersetzen und deren Geschwindigkeit im Vergleich zum »gcc« zu testen.

Abbildung 5: Die Begrüßungswebseite des Storageworks Switch zeigt die aktiven Komponenten des SAN-Fabric. Durch Klicken auf die Switches gelangt man direkt in die entsprechenden Konfigurationsdialoge.

Fazit

Eine Cluster-Lösung bietet den bekannten Vorteil der Redundanz und die Möglichkeit, weitere Systeme unabhängig von der verwendeten Prozessorarchitektur schnell in einen bestehenden Cluster zu integrieren. Die Verwendung eines Batchsystems ist für den Benutzer dabei nahezu transparent und ermöglicht die gleichmäßige Auslastung gleicher wie unterschiedlicher Systeme. Dabei können auch Spezialanwendungen auf bestimmten Rechnern bevorzugt laufen, indem man die Queues entsprechend einrichtet. Die Verwendung von MPICH hat sich als Möglichkeit erwiesen, schnell und einfach parallelisierte Software zu nutzen. Das System lässt sich leicht auf Cluster anwenden und bietet einen gewaltigen Performancegewinn im Vergleich zur sequenziellen Ausführung auf einzelnen Rechnern.

Aus meiner Sicht haben sich die Erwartungen an den Göttinger Cluster größtenteils erfüllt. Die Vorteile eines offenen Systems konnten auf dieser leistungsfähigen Architektur ausgenutzt werden. Man muss sich allerdings darüber klar sein, dass man auf Quelltexte angewiesen ist, wenn man nicht auf vorgefertigte, kommerzielle Lösungen mit proprietärer Software setzt. Problematisch ist etwa das Fehlen eines Tivoli-Clients für Alpha/Linux, obwohl eine Implementierung für Alpha/DigitalUNIX oder OpenVMS vorhanden ist. (pju)