elthema Klimaforscher verwalten riesige Datenbank unter ... TX-7-Maschinen und NECs HPC-Linux eigneten

  • View
    0

  • Download
    0

Embed Size (px)

Text of elthema Klimaforscher verwalten riesige Datenbank unter ... TX-7-Maschinen und NECs HPC-Linux...

  • Das Abtauen der Gletscher, den Anstieg des Meeresspiegels, ja selbst so gravie- rende Folgen wie einen Zusammenbruch des Golfstroms halten Wissenschaftler als Folge eines Klimawandels für mög- lich. Wirksame Gegenmaßnahmen erfor- dern einschneidende politische Ent- scheidungen – und die müssen sich auf überzeugende wissenschaftliche Bewei- se für einen von Menschen verursachten Klimawandel stützen. Auf der Suche nach solchen Beweisen greift die Klimaforschung einerseits auf empirische Daten zurück, die zum Bei- spiel die Erwärmung am Ende des 20. Jahrhunderts als Ausnahme in den letz- ten 1000 Jahren belegt haben. Anderer- seits arbeitet sie mit Modellen, die Kli- maveränderungen auf der Grundlage physikalischer Gesetze durch mathema- tische Gleichungen simulieren. Solche Modelle sind trotz aller Probleme in der Lage, das Klimasystem (Abbil- dung 1) und seine Veränderungen zu si- mulieren. Sie vermitteln eine Vorstellung über das Wechselspiel verschiedener Einflussfaktoren – etwa der Treibhaus- gase – und haben den Zusammenhang zwischen der Erwärmung der letzten Jahrzehnte und ihren von Menschen zu verantwortenden Ursachen aufgedeckt.

    Informationsflut kanalisiert

    Diese Simulationen produzieren gewal- tige Datenmengen und erfordern Hoch- leistungsrechner, wie sie am Deutschen Klimarechenzentrum (DKRZ) in Ham- burg durch eine kleine Gruppe von Wis- senschaftlern betreut werden. Die wert- vollste Ressource des Zentrums ist ein Vektorrechner von NEC, der Mitte 2004 ganz vorn auf der Top-500-Liste der

    Supercomputer stand. Die auf diesem Rechner durch Simu- lationen erzeugten Daten werden in einem Bandarchiv gespeichert. Die Wissenschaftler, die sie später auswerten, benötigen allerdings trotz des giganti- schen Umfangs und der Kom- plexität der Daten einen ein- fachen Zugang. Dazu gibt es am DKRZ eine von der Grup- pe Modelle und Daten am Max-Planck-Institut für Mete- orologie betreute Oracle-9i- Datenbank. Sie stellt zum ei- nen Informationen über Ex- perimente bereit und enthält zum anderen deren wichtigs- te Ergebnisse. Im Dezember 2004 um- fasste dies eine Datenmenge von etwa 125 TByte mit stark zunehmender Ten- denz (siehe Tabelle 1).

    Globus im Gitternetz

    Klimamodelle rechnen auf einem welt- umspannenden, dreidimensionalen Git- ter. Für jeden der Gitterpunkte wird der Gesamtzustand des Systems in diskreten Zeitabständen von sechs Stunden Mo- dellzeit abgespeichert. Das System setzt sich aus mehreren Parametern zusam- men: Temperatur, Niederschlag, Wind und vielen anderen. Ein Problem ist die von der Rechnerleis- tung abhängige horizontale Auflösung der Modelle, die bei den globalen zurzeit bei etwa 250 Kilometer liegt. Eine solche Auflösung erlaubt weder regionale Pro- gnosen noch die Wiedergabe von räum- lich und zeitlich sich schnell verändern- den Prozessen wie etwa der Wolkenbil- dung. Auch die adäquate Wiedergabe

    der vielen Rückkopplungen im Klima- system ist ein Problem. Tabelle 2 gibt ei- nen Überblick über die anfallenden Da- ten. Wie sich zeigt, kommen trotz recht kleiner Datenmengen für jeden einzel- nen Zeitschritt insgesamt gewaltige Summen zusammen.

    Aus einem Stück

    Bis vor kurzem wurde am DKRZ noch eine recht traditionelle Architektur ein- gesetzt. Vektorrechner waren über LAN an ein Hierarchical Storage Management System (HSM) gekoppelt. Auch skalare Postprocessing-Rechner von Sun waren via LAN angeschlossen, ebenso eine Sun E15k, auf der die noch recht überschau- bare monolithische Oracle-Datenbank mit einer Größe von 25 TByte lief. Ab Anfang 2002 stattete NEC High Per- formance Computing Europe (HPCE) das DKRZ mit dem neuen Vektorrechner SX-6 aus. Die neueste Generation der SX-Serie dominierte zu diesem Zeitpunkt

    Fo to

    :N AS

    A

    Eine 125 TByte große Datenbank unter Linux speichert Simulationsergebnisse im Deutschen Klimarechenzen- trum. Eine ausgefeilte hierarchische Speicherlösung begrenzt den benötigten Plattenplatz. Hannes Thiemann, Jan Schreiber

    Klimaforscher verwalten riesige Datenbank unter Linux

    Klima in der Welt von morgen

    55

    Li nu

    x- M

    ag az

    in 0

    3/ 05

    T it

    el th

    em a

    S u

    p er

    -D B

    055-058_superdb 19.01.2005 15:37 Uhr Seite 55

  • T it

    el th

    em a

    56

    Li nu

    x- M

    ag az

    in 0

    3/ 05

    S u

    p er

    -D B

    die Top-500-Benchmark-Liste mit den schnellsten Supercomputern weltweit, Spitzenreiter war der in Tokyo instal- lierte Earth Simulator. Die SX-6er behiel- ten ihre Führungsposition bis zum Herbst 2004. Im Zuge des Umbaus im DKRZ wurde zudem entschieden, auch für die Verwaltung der Simulationser- gebnisse ein neues Konzept zu entwi- ckeln und sich von dem monolithischen, Sun-basierten Ansatz zu entfernen und stattdessen auf Linux zu setzen.

    Verteilte Zukunft

    Bei den für die Datenbank unter Linux eingesetzten NEC-TX-7-Systemen han- delt es sich um Itanium-2-Rechner mit einer Taktrate von 1 bis 1,5 GHz und 3 MByte Level-3-Cache auf dem Chip. Der Systembus kann 6,4 GByte/s trans- portieren, das System schafft damit eine Stand-alone-Performance von 4,0 G- Flops. Der Speicherzugriff erfolgt per Cache-Coherent Non-Uniform Memory Access (CCNUMA). Das System ist in vier Zellen mit jeweils vier CPUs organisiert. Eine High-Per- formance-Crossbar, die die TX-7-Rech- ner aus dem Supercomputing-Bereich geerbt haben, verbindet diese Zellen zu einem Gesamtsystem mit bis zu 32 CPUs. Hersteller NEC liefert es wahl- weise mit Linux oder HP-UX aus. Schon zu Beginn des Projekts wurde klar, dass das neue Datenbanksystem aus mehreren kleineren, zusammenar- beitenden Zellen bestehen soll. Die NEC- TX-7-Maschinen und NECs HPC-Linux eigneten sich zwar für 24 CPUs, aber Oracle war nur für Red Hat und United Linux zertifiziert. Diese Distributionen unterstützten im Planungsjahr 2003 we- der die CCNUMA-Architektur der TX-7- Hardware noch 24 CPUs, sodass der Ausbaustand der Sun E15k mit ihnen nicht nachzubilden war.

    Oracle hatte sich aber am DKRZ be- währt. Der kommerziell verfügbare Sup- port, die guten Erfahrungen mit der Ska- lierbarkeit, das vorhandene Know-how und das gute Datenhandling dieser Platt- form waren schwer zu ersetzen. Also fiel die Entscheidung gegen einen Ansatz mit symmetrischem Multiprocessing und für die bei Oracle Federate Database ge- nannte Struktur: fünf Rechner mit meh- reren Datenbankinstanzen und einer ge- meinsamen Darstellung der verfügbaren Daten nach außen.

    Ergebnis- und Metadaten

    Möglich wird dies durch die Trennung der Ergebnisdaten in Form von BLOBs (Binary Large Objects) und der Metada- ten, sozusagen dem Inhaltsverzeichnis. In diesem Inhaltsverzeichnis, also der Meta-Datenbank, musste nun ein Zeiger auf die BLOB-DB eingefügt werden, in der die Ergebnisdaten der Simulationen liegen. Durch die zentrale Verwaltung der Zugriffsrechte auf einem LDAP-Ser- ver mit Benutzeridentifikation über SSL ist ein quasi-transparenter Zugriff auf alle Datensätze möglich, obwohl sie in verschiedenen Datenbanken liegen. Der größte Aufwand ergab sich aus dem Transfer der BLOB-Daten von der Sun- Architektur zu Linux. Denn das Format von Oracles binären Datenfiles ist zwi-

    schen Oracle für Solaris und Oracle für Linux unterschiedlich. Die auf dem alten Backend abgelegten Datenfiles ließen sich daher nicht einfach auf den neuen Maschinen mounten. Eine Machbarkeitsstudie verglich zu- nächst die Performance verschiedener denkbarer Transportwege: Die erste Al- ternative war ein Export einzelner Daten von der ursprünglichen Sun-DB, an- schließend Transfer per FTP zur neuen Linux-DB und nachfolgender Import. Al- ternative zwei bestand in einem Remote Select mit Hilfe eines Database-Links zwischen den Maschinen. Geschwindig- keit und Handling überzeugten nur bei der zweiten Methode. Kalkuliert war eine Laufzeit des Übertra- gungsskripts, das in PL/SQL entwickelt wurde, von mehreren Monaten. Hier war es natürlich besonders spannend, abgebrochene und wieder anlaufende Übertragungen möglichst reibungslos zu gestalten, denn während einer derart langen Laufzeit musste zumindest mit einigen Wartungsarbeiten und Reboots gerechnet werden.

    Cluster bewährt sich

    Auch wenn einige der im DKRZ verwen- deten Oracle-Komponenten, etwa der Internet Application Server, noch nicht für Itanium und Linux vorliegen und

    Abbildung 1: Die komplexen Phänomene und Prozesse, die unser Klima bestimmen, lassen sich durch

    komplizierte Gleichungssysteme in Hochleistungsrechnern simulieren.

    Jahr DB-Größe

    1999 2 TByte

    2000 4 TByte

    2001 7 TByte

    2002 11 TByte

    2003 25 TByte

    2004 125 TByte

    Auflösung pro Zeitschritt pro Modellmonat pro 500-Jahreslauf

    110 km 100 KByte 5,2 GByte 30 TByte

    300 km 16 MByte 650 MByte 3,7 TByte

    Tabelle 1: Größenwachstum der Datenbank

    Tabelle 2: Typische Datenmengen

    055-058_superdb 19.01.2005 15:37 Uhr Seite 56

  • 57

    Li nu

    x- M

    ag az

    in 0

    3/ 05

    T it

    el th

    em a

    S u

    p er

    -D B

    weiterhin auf Solaris betrieben werden müssen, nahm der neue Linux-Daten- bankcluster den Datenstrom flüssig und störungsfrei an. Dieser setzte sich aus der Migration und den parallel einflie- ßenden neuen Produktionsdaten, die ständig von den Post-Processing-Syste- men hinter dem Vektorrechner erzeugt wurden, zusammen. Bei Störungen oder bei zu geringem Cache für das Zwi- schenspeichern der Ergebnisse hätten die Produktionsläufe im Vektorrechner gestoppt werden müssen. Insgesamt wurden 8000 unpartitionierte und 4000 p