4
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 Foto: NASA 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 Linux-Magazin 03/05 Titelthema Super-DB 055-058_superdb 19.01.2005 15:37 Uhr Seite 55

elthema Klimaforscher verwalten riesige Datenbank unter ... · 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

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: elthema Klimaforscher verwalten riesige Datenbank unter ... · 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

Das Abtauen der Gletscher, den Anstiegdes Meeresspiegels, ja selbst so gravie-rende Folgen wie einen Zusammenbruchdes Golfstroms halten Wissenschaftlerals 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 verursachtenKlimawandel stützen.Auf der Suche nach solchen Beweisengreift die Klimaforschung einerseits aufempirische 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 Grundlagephysikalischer Gesetze durch mathema-tische Gleichungen simulieren.Solche Modelle sind trotz aller Problemein der Lage, das Klimasystem (Abbil-

dung 1) und seine Veränderungen zu si-mulieren. Sie vermitteln eine Vorstellungüber das Wechselspiel verschiedenerEinflussfaktoren – etwa der Treibhaus-gase – und haben den Zusammenhangzwischen der Erwärmung der letztenJahrzehnte und ihren von Menschen zuverantwortenden Ursachen aufgedeckt.

Informationsflut kanalisiert

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

Supercomputer stand. Die aufdiesem Rechner durch Simu-lationen erzeugten Datenwerden in einem Bandarchivgespeichert. Die Wissenschaftler, die siespäter auswerten, benötigenallerdings trotz des giganti-schen Umfangs und der Kom-plexität der Daten einen ein-fachen Zugang. Dazu gibt esam DKRZ eine von der Grup-pe Modelle und Daten amMax-Planck-Institut für Mete-orologie betreute Oracle-9i-Datenbank. Sie stellt zum ei-nen Informationen über Ex-perimente bereit und enthältzum anderen deren wichtigs-te Ergebnisse. Im Dezember 2004 um-fasste dies eine Datenmenge von etwa125 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 derGesamtzustand des Systems in diskretenZeitabständen von sechs Stunden Mo-dellzeit abgespeichert. Das System setztsich aus mehreren Parametern zusam-men: Temperatur, Niederschlag, Windund vielen anderen. Ein Problem ist die von der Rechnerleis-tung abhängige horizontale Auflösungder Modelle, die bei den globalen zurzeitbei etwa 250 Kilometer liegt. Eine solcheAuflö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 rechtkleiner Datenmengen für jeden einzel-nen Zeitschritt insgesamt gewaltigeSummen zusammen.

Aus einem Stück

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

Foto

:NAS

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

Linu

x-M

agaz

in 0

3/05

Tit

elth

ema

Su

per

-DB

055-058_superdb 19.01.2005 15:37 Uhr Seite 55

Page 2: elthema Klimaforscher verwalten riesige Datenbank unter ... · 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

Tit

elth

ema

56

Linu

x-M

agaz

in 0

3/05

Su

per

-DB

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

Verteilte Zukunft

Bei den für die Datenbank unter Linuxeingesetzten NEC-TX-7-Systemen han-delt es sich um Itanium-2-Rechner miteiner 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 eineStand-alone-Performance von 4,0 G-Flops. Der Speicherzugriff erfolgt per Cache-Coherent Non-Uniform MemoryAccess (CCNUMA). Das System ist in vier Zellen mit jeweilsvier CPUs organisiert. Eine High-Per-formance-Crossbar, die die TX-7-Rech-ner aus dem Supercomputing-Bereichgeerbt haben, verbindet diese Zellen zueinem Gesamtsystem mit bis zu 32CPUs. Hersteller NEC liefert es wahl-weise mit Linux oder HP-UX aus.Schon zu Beginn des Projekts wurdeklar, dass das neue Datenbanksystemaus mehreren kleineren, zusammenar-beitenden Zellen bestehen soll. Die NEC-TX-7-Maschinen und NECs HPC-Linuxeigneten sich zwar für 24 CPUs, aberOracle war nur für Red Hat und UnitedLinux zertifiziert. Diese Distributionenunterstützten im Planungsjahr 2003 we-der die CCNUMA-Architektur der TX-7-Hardware noch 24 CPUs, sodass derAusbaustand der Sun E15k mit ihnennicht 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-howund das gute Datenhandling dieser Platt-form waren schwer zu ersetzen. Also fieldie Entscheidung gegen einen Ansatzmit symmetrischem Multiprocessing undfür die bei Oracle Federate Database ge-nannte Struktur: fünf Rechner mit meh-reren Datenbankinstanzen und einer ge-meinsamen Darstellung der verfügbarenDaten nach außen.

Ergebnis- und Metadaten

Möglich wird dies durch die Trennungder Ergebnisdaten in Form von BLOBs(Binary Large Objects) und der Metada-ten, sozusagen dem Inhaltsverzeichnis.In diesem Inhaltsverzeichnis, also derMeta-Datenbank, musste nun ein Zeigerauf die BLOB-DB eingefügt werden, inder die Ergebnisdaten der Simulationenliegen. Durch die zentrale Verwaltungder Zugriffsrechte auf einem LDAP-Ser-ver mit Benutzeridentifikation über SSList ein quasi-transparenter Zugriff aufalle Datensätze möglich, obwohl sie inverschiedenen Datenbanken liegen.Der größte Aufwand ergab sich aus demTransfer der BLOB-Daten von der Sun-Architektur zu Linux. Denn das Formatvon Oracles binären Datenfiles ist zwi-

schen Oracle für Solaris und Oracle fürLinux unterschiedlich. Die auf dem altenBackend abgelegten Datenfiles ließensich daher nicht einfach auf den neuenMaschinen mounten.Eine Machbarkeitsstudie verglich zu-nächst die Performance verschiedenerdenkbarer Transportwege: Die erste Al-ternative war ein Export einzelner Datenvon der ursprünglichen Sun-DB, an-schließend Transfer per FTP zur neuenLinux-DB und nachfolgender Import. Al-ternative zwei bestand in einem RemoteSelect mit Hilfe eines Database-Linkszwischen den Maschinen. Geschwindig-keit und Handling überzeugten nur beider zweiten Methode.Kalkuliert war eine Laufzeit des Übertra-gungsskripts, das in PL/SQL entwickeltwurde, von mehreren Monaten. Hierwar es natürlich besonders spannend,abgebrochene und wieder anlaufendeÜbertragungen möglichst reibungslos zugestalten, denn während einer derartlangen Laufzeit musste zumindest miteinigen Wartungsarbeiten und Rebootsgerechnet werden.

Cluster bewährt sich

Auch wenn einige der im DKRZ verwen-deten Oracle-Komponenten, etwa derInternet Application Server, noch nichtfü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 derDatenbank

Tabelle 2: Typische Datenmengen

055-058_superdb 19.01.2005 15:37 Uhr Seite 56

Page 3: elthema Klimaforscher verwalten riesige Datenbank unter ... · 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

57

Linu

x-M

agaz

in 0

3/05

Tit

elth

ema

Su

per

-DB

weiterhin auf Solaris betrieben werdenmüssen, nahm der neue Linux-Daten-bankcluster den Datenstrom flüssig undstörungsfrei an. Dieser setzte sich ausder Migration und den parallel einflie-ßenden neuen Produktionsdaten, dieständig von den Post-Processing-Syste-men hinter dem Vektorrechner erzeugtwurden, zusammen. Bei Störungen oderbei zu geringem Cache für das Zwi-schenspeichern der Ergebnisse hättendie Produktionsläufe im Vektorrechnergestoppt werden müssen. Insgesamtwurden 8000 unpartitionierte und 4000partitionierte Tabellen mit 12980 Parti-tionen übertragen.

Globales Filesystemverkürzt Zugriffspfad

Das im DKRZ eingesetzte Linux ist einRed Hat Advanced Server mit Kernel2.4.18. Der Kernel wurde mit einigen für

den Betrieb im Datacenter erfor-derlichen Featuresübersetzt, zum Beispiel dem Supportfür das Global FileSystem (GFS). Das GFS ist eineWeiterentwicklungvon NFS (NetworkFile System). DerUnterschied zwi-schen beiden be-steht in erster Li-nie darin, dass dieDaten bei NFSüber das LAN vom

NFS-Server zum NFS-Client laufen. ImKlimarechenzentrum hätte dies zurFolge, dass die Daten vom Massenspei-cher (Bandsilo, Diskcache) über dasSAN zum NFS-Server gelangen müssten,bevor sie wiederum von dort über dasLAN beim Client eintreffen. Zwar beginnt ein GFS-Transfer genausomit einer Anfrage des Clients an den Ser-ver nach einem Datenblock beziehungs-weise nach einer Datei. Der GFS-Serverantwortet darauf jedoch nicht mit denangefragten Daten selbst, sondern ver-weist den Client auf eine Speicher-adresse, über die er die Daten direkt ausdem SAN vom gemeinsam genutztenMassenspeicher abholt. Der GFS-Serververwaltet dabei die Inode-Operationenauf dem Filesystem des Massenspei-chers, das dadurch konsistent bleibt(Abbildung 2). Da die meisten Wissenschaftler beson-ders an Zeitserien einzelner Variablen

(zum Beispiel an der Oberflächentempe-ratur) interessiert sind, werden auch dieDaten dieser Struktur entsprechend inder Datenbank gespeichert. Jede dieserZeitserien wird kontinuierlich in einereinzelnen Tabelle abgelegt. Die Daten ei-nes bestimmten Zeitpunkts bilden eineBLOB-Zeile. Einige Tabellen erreichenschon sehr bald eine Größe bis zu meh-reren 10 GByte. Die Abfragemimik er-laubt es den Benutzern jedoch, ihreDownloads beliebig granular zu gestal-ten, sodass sich die Datenmenge beimTransfer schnell reduziert.Bei der Implementation war der verfüg-bare Plattenplatz ein wichtiges Krite-rium. Zurzeit wird die Datenbank aufrund 20 TByte betrieben. Die aktuelleDatenbankgröße beträgt jedoch bereits125 TByte.

Mehr Platzbedarf alsPlatten

Um die gewaltige Datenmenge trotz die-ser Diskrepanz vorhalten zu können, istdie Oracle-Datenbank in die am DKRZbetriebene HSM-Umgebung eingebettet.Bei dem HSM-System handelt es sich umUnitree/DXUL (mittlerweile im Besitzvon EMC) auf der Grundlage von Linux.Ergänzt wird es durch ein Zusatzproduktnamens Disk Xtender. Diese Ergänzung verwaltet lokale File-systeme, deren Files sie nach bestimm-ten Kriterien automatisch auf ein Back-end-System kopiert, wonach sie gegebe-nenfalls von der Platte gelöscht werdenkönnen. Als Kriterien verwendet DiskXtender die Größe der Files sowie die

Abbildung 2: Die Clients können sich via Fiber Channel direkt aus dem SAN

(Storage Area Network) bedienen, die Adresse der von ihnen angefragten Daten

erhalten sie vom GFS-Server.

1/4 quer A210x81 mm zzgl. Beschnitt

IMS

Server Client

Remote Mount

SAN

Local Mount

Data-Transfer

Shared Disks

055-058_superdb 19.01.2005 15:37 Uhr Seite 57

Page 4: elthema Klimaforscher verwalten riesige Datenbank unter ... · 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

Tit

elth

ema

58

Linu

x-M

agaz

in 0

3/05

Su

per

-DB

Zeit der letzten Änderung beziehungs-weise des letzten Zugriffs.

Datenfiles und Partitionen

Das Verfahren würde normalerweise vonOracles Strategie durchkreuzt, die Da-tenfiles regelmäßig zu aktualisieren. Dasgilt jedoch nicht für Datenbankdateien,die nur lesbar sind. Solche Dateien blei-ben unverändert – wie sich ja auch diein ihnen gespeicherten Ergebnisse derSimulationen nicht mehr ändern. Außer-dem sind die Tabellen mit Hilfe einesSchlüssels unterteilt (Range Partitio-ning). Den Partitionen lassen sich wie-der eigene Datenfiles zuweisen. Damitergibt sich folgender Ablauf:■ Einfüllen der Daten in die Partition n.■ Sobald Partition n voll ist, erfolgt das

weitere Schreiben in Partition n+1.■ Partition n wird read-only gesetzt.■ Kopieren der Partition n in ein vom

Disk Xtender verwaltetes Filesystem.■ Löschen der ursprünglichen Daten-

bankdatei.■ Nun ist der Platz wieder frei für Parti-

tion n+1, die sich im weiteren Ver-lauf automatisch vergrößert.

Dateien, die der HSM-Mechanismusnach dem Kopieren in ein Disk-Xtender-Filesystem auslagert, werden dort inkleinere – konfigurierbar große Stücke –unterteilt (256 bis 512 MByte in der amKlimarechenzentrum verwendeten Kon-figuration).

Datenstummel bleibenliegen

Wird eine Datei komplett von der Plattegelöscht (gepurged), müsste sie zu-nächst aus Datenbanksicht offline ge-setzt werden, damit die Datenbank nichtversucht auch nur lesend auf das nichtmehr vorhandene File zugreifen. Um daszu vermeiden, lässt man nach dem Pur-gen der Datei immer den so genanntenStub, also den Kopf der Datei, auf derPlatte stehen. Die Länge dieses Stubs istkonfigurierbar. Für Oracle-Datenbankenempfiehlt sich eine Größe von 256KByte. Das Purgen entfernt also nur denTeil hinter diesem Header von der Platte.Aus Datenbanksicht bleibt die Dateiweiterhin verfügbar und muss folglichauch nicht offline gesetzt werden.

Greift ein Benutzerüber die Oracle-Datenbank auf ge-purgte Dateien zu,so startet der DiskXtender im Hinter-grund einen Pro-zess, der – trans-parent für den Benutzer und die Datenbank – dasjeweils benötigteStück (und nurdieses) zurücklädt.Der Download derDaten dauert dannentsprechend et-was länger. Um unnötige Bandzugriffezu vermeiden, ist es wichtig, beim Anle-gen der Tabellen die Speicherparametersorgfältig zu wählen.

Langsam, aber sparsam

Ein Bandzugriff dauert meist knapp fünfMinuten. In dieser Zeit wird das Bandausgesucht, automatisch in ein Lauf-werk geladen, bis zum Beginn der ge-wünschten Aufzeichnung vorgespultund gelesen. Danach gelangen die Datenvia FTP zu dem Datenbankrechner. Erstjetzt bekommt der Anwender seine Da-ten zu sehen, der gesamte Downloadläuft im Hintergrund.Der Vorteil kleinerer Downloads ist, dassdas System nicht immer die gesamte Da-tei von Band zurückzuladen braucht. Beigrößeren Downloads muss dieser Zyklusjedoch mehrfach wiederholt werden.Das kann dann zu sehr langen Down-load-Zeiten führen, da die Datenbanknur ein Benutzer des HSM-Systems un-ter mehreren ist. Als großer Vorteil ergibtsich jedoch ein drastisch verringerter Be-darf an Plattenplatz für die Datenbank.Erkauft wird dies jedoch mit einer er-höhten Antwortzeit des Systems.

Petabyte-Datenbankschon im Blick

Die Anforderungen an die Klimavorher-sage und damit auch an die Klimamo-delle werden in Zukunft weiter steigen.Neben einer verfeinerten regionalen Auf-lösung ist es ebenfalls erforderlich, zu-sätzliche physikalische Prozesse des Kli-

masystems abzubilden. Die von den Kli-mamodellen erzeugte Datenmenge wirdsich damit sicherlich nochmals beträcht-lich erhöhen. Die im Klimarechenzentrum verwendeteArchitektur einer verteilten Oracle-Da-tenbank unter Linux wird grundsätzlichdiesen Anforderungen gerecht. Die Zu-verlässigkeit und Verfügbarkeit der Kom-bination Oracle und Linux hat sich inder Praxis als gut erwiesen. Die imple-mentierte Lösung ist durch Hinzufügenweiterer TX-7-Zellen ausbaufähig. EinerPetabyte-Oracle-Datenbank unter Linuxin absehbarer Zeit steht damit prinzipiellnichts entgegen. (jcb) ■

Infos

[1] Deutsches Klimarechenzentrum GmbH:

[http://www.dkrz.de]

[2] Max-Planck-Institut für Meteorologie:

[http://http://www.mpimet.mpg.de]

[3] NEC HPCE Skalar SMP Page:

[http://www.hpce.nec.com/465.0.html]

[4] Oracle unter Linux:

[http://www.oracle.com/technologies/

linux/index.html]

[5] Atlas-Projekt: [http://sourceforge.net/

projects/atlas-64/]

[6] Top 500 Supercomputer:

[http://www.top500.org]

Die Autoren

Hannes Thiemann ist Geophysiker und Daten-

bankadministrator am Hamburger Max-Planck-

Institut für Meteorologie, Gruppe Modelle und

Daten.

Jan Schreiber arbeitet als freiberuflicher Ora-

cle-Consultant (Loopback.ORG).

HSM System

DB 1 DB 2 DB 3

DB 4 DB 5Vektorrechner Postprocessing

Global Filesystem

User

Abbildung 3: Ein hierarchisches Speichermanagement lagert im Hintergrund

Daten auf Bänder aus, damit bleibt die online benötigte Plattenkapazität

begrenzt. Allerdings ergeben sich unter Umständen recht lange Zugriffszeiten.

055-058_superdb 19.01.2005 15:37 Uhr Seite 58