Schlagwortarchiv für: oracle linux dkrz cera

Eine 125 TByte große Datenbank unter Linux speichert Simulationsergebnisse im Deutschen Klimarechenzentrum.
Eine ausgefeilte hierarchische Speicherlösung begrenzt den benötigten Plattenplatz.

Von Hannes Thiemann und Jan Schreiber

Erschienen im Linux-Magazin 03/2005

Das Abtauen der Gletscher, den Anstieg des Meeresspiegels, ja selbst so gravierende Folgen wie einen Zusammenbruch des Golfstroms halten Wissenschaftler als Folge eines Klimawandels für möglich. Wirksame Gegenmaßnahmen erfordern einschneidende politische Entscheidungen – und die müssen sich auf überzeugende wissenschaftliche Beweise 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 Beispiel die Erwärmung am Ende des 20. Jahrhunderts als Ausnahme in den letzten 1000 Jahren belegt haben. Andererseits arbeitet sie mit Modellen, die Klimaveränderungen auf der Grundlage physikalischer Gesetze durch mathematische Gleichungen simulieren. Solche Modelle sind trotz aller Probleme in der Lage, das Klimasystem und seine Veränderungen zu simulieren. Sie vermitteln eine Vorstellung über das Wechselspiel verschiedener Einflussfaktoren – etwa der Treibhausgase – und haben den Zusammenhang zwischen der Erwärmung der letzten Jahrzehnte und ihren von Menschen zu verantwortenden Ursachen aufgedeckt.

Informationsflut kanalisiert

Diese Simulationen produzieren gewaltige Datenmengen und erfordern Hochleistungsrechner, wie sie am Deutschen Klimarechenzentrum (DKRZ) in Hamburg durch eine kleine Gruppe von Wissenschaftlern betreut werden. Die wertvollste 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 Simulationen erzeugten Daten werden in einem Bandarchiv gespeichert. Die Wissenschaftler, die sie später auswerten, benötigen allerdings trotz des gigantischen Umfangs und der Komplexität der Daten einen einfachen Zugang. Dazu gibt es am DKRZ eine von der Gruppe Modelle und Daten am Max-Planck-Institut für Meteorologie betreute Oracle-9i- Datenbank. Sie stellt zum einen Informationen über Experimente bereit und enthält zum anderen deren wichtigste Ergebnisse. Im Dezember 2004 umfasste dies eine Datenmenge von etwa 125 TByte mit stark zunehmender Tendenz

Globus im Gitternetz

Klimamodelle rechnen auf einem weltumspannenden, dreidimensionalen Gitter. Für jeden der Gitterpunkte wird der Gesamtzustand des Systems in diskreten Zeitabständen von sechs Stunden Modellzeit abgespeichert. Das System setzt sich aus mehreren Parametern zusammen: Temperatur, Niederschlag, Wind und vielen anderen. Ein Problem ist die von der Rechnerleistung abhängige horizontale Auflösung der Modelle, die bei den globalen zurzeit bei etwa 250 Kilometer liegt. Eine solche Auflösung erlaubt weder regionale Prognosen noch die Wiedergabe von räumlich und zeitlich sich schnell verändernden Prozessen wie etwa der Wolkenbildung. Auch die adäquate Wiedergabe der vielen Rückkopplungen im Klimasystem ist ein Problem. Tabelle 2 gibt einen Überblick über die anfallenden Daten. Wie sich zeigt, kommen trotz recht kleiner Datenmengen für jeden einzelnen Zeitschritt insgesamt gewaltige Summen zusammen.

Aus einem Stück

Bis vor kurzem wurde am DKRZ noch eine recht traditionelle Architektur eingesetzt. 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 überschaubare monolithische Oracle-Datenbank mit einer Größe von 25 TByte lief.
Ab Anfang 2002 stattete NEC High Performance Computing Europe (HPCE) das DKRZ mit dem neuen Vektorrechner SX-6 aus. Die neueste Generation der SX-Serie dominierte zu diesem Zeitpunk tdie Top-500-Benchmark-Liste mit den schnellsten Supercomputern weltweit, Spitzenreiter war der in Tokyo installierte Earth Simulator. Die SX-6er behielten ihre Führungsposition bis zum Herbst 2004.

Im Zuge des Umbaus im DKRZ wurde zudem entschieden, auch für die Verwaltung der Simulationsergebnisse ein neues Konzept zu entwickeln 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 handelt 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 transportieren, das System schafft damit eine Stand-alone-Performance von 4,0 GFlops. Der Speicherzugriff erfolgt per Cache-Coherent Non-Uniform Memory Access (CCNUMA). Das System ist in vier Zellen mit jeweils vier CPUs organisiert. Eine High-Performance- Crossbar, die die TX-7-Rechner aus dem Supercomputing-Bereich geerbt haben, verbindet diese Zellen zu einem Gesamtsystem mit bis zu 32
CPUs. Hersteller NEC liefert es wahlweise mit Linux oder HP-UX aus.

Schon zu Beginn des Projekts wurde klar, dass das neue Datenbanksystem aus mehreren kleineren, zusammenarbeitenden
Zellen bestehen soll. Die NECTX- 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 weder 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 bewährt. Der kommerziell verfügbare Support, die guten Erfahrungen mit der Skalierbarkeit, das vorhandene Know-how
und das gute Datenhandling dieser Plattform waren schwer zu ersetzen. Also fiel die Entscheidung gegen einen Ansatz mit symmetrischem Multiprocessing und für die bei Oracle Federate Database genannte Struktur: fünf Rechner mit mehreren
Datenbankinstanzen und einer gemeinsamen 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 Metadaten, 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-Server 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 zwischen 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 zunächst die Performance verschiedener denkbarer Transportwege: Die erste Alternative
war ein Export einzelner Daten von der ursprünglichen Sun-DB, anschließend Transfer per FTP zur neuen
Linux-DB und nachfolgender Import. Alternative zwei bestand in einem Remote Select mit Hilfe eines Database-Links zwischen den Maschinen. Geschwindigkeit und Handling überzeugten nur bei der zweiten Methode. Kalkuliert war eine Laufzeit des Übertragungsskripts, 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 verwendeten Oracle-Komponenten, etwa der Internet Application Server, noch nicht
für Itanium und Linux vorliegen und weiterhin auf Solaris betrieben werden müssen, nahm der neue Linux-Datenbankcluster 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-Systemen hinter dem Vektorrechner erzeugt wurden, zusammen. Bei Störungen oder bei zu geringem Cache für das Zwischenspeichern der Ergebnisse hätten die Produktionsläufe im Vektorrechner gestoppt werden müssen. Insgesamt wurden 8000 unpartitionierte und 4000 partitionierte Tabellen mit 12980 Partitionen übertragen.

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

Globales Filesystem verkürzt Zugriffspfad

Das im DKRZ eingesetzte Linux ist ein Red Hat Advanced Server mit Kernel 2.4.18. Der Kernel wurde mit einigen für
den Betrieb im Datacenter erforderlichen Features übersetzt, zum Beispiel dem Support für das Global File System (GFS). Das GFS ist eine Weiterentwicklung von NFS (Network File System). Der Unterschied zwischen beiden besteht in erster Linie darin, dass die
Daten bei NFS über das LAN vom NFS-Server zum NFS-Client laufen. Im Klimarechenzentrum hätte dies zur Folge, dass die Daten vom Massenspeicher (Bandsilo, Diskcache) über das SAN zum NFS-Server gelangen müssten, bevor sie wiederum von dort über das LAN beim Client eintreffen.
Zwar beginnt ein GFS-Transfer genauso mit einer Anfrage des Clients an den Server nach einem Datenblock beziehungsweise
nach einer Datei. Der GFS-Server antwortet darauf jedoch nicht mit den angefragten Daten selbst, sondern verweist den Client auf eine Speicheradresse, über die er die Daten direkt aus dem SAN vom gemeinsam genutzten Massenspeicher abholt. Der GFS-Server verwaltet dabei die Inode-Operationen auf dem Filesystem des Massenspeichers, das dadurch konsistent bleibt
Da die meisten Wissenschaftler besonders an Zeitserien einzelner Variablen (zum Beispiel an der Oberflächentemperatur) interessiert sind, werden auch die Daten dieser Struktur entsprechend in der Datenbank gespeichert. Jede dieser
Zeitserien wird kontinuierlich in einer einzelnen Tabelle abgelegt. Die Daten eines bestimmten Zeitpunkts bilden eine BLOB-Zeile. Einige Tabellen erreichen schon sehr bald eine Größe bis zu mehreren 10 GByte. Die Abfragemimik erlaubt es den Benutzern jedoch, ihre Downloads beliebig granular zu gestalten, sodass sich die Datenmenge beim Transfer schnell reduziert.
Bei der Implementation war der verfügbare Plattenplatz ein wichtiges Kriterium. Zurzeit wird die Datenbank auf rund 20 TByte betrieben. Die aktuelle Datenbankgröße beträgt jedoch bereits 125 TByte.

Mehr Platzbedarf als Platten

Um die gewaltige Datenmenge trotz dieser Diskrepanz vorhalten zu können, ist die Oracle-Datenbank in die am DKRZ betriebene HSM-Umgebung eingebettet. Bei dem HSM-System handelt es sich um Unitree/DXUL (mittlerweile im Besitz von EMC) auf der Grundlage von Linux. Ergänzt wird es durch ein Zusatzprodukt namens Disk Xtender. Diese Ergänzung verwaltet lokale Filesysteme,
deren Files sie nach bestimmten Kriterien automatisch auf ein Backend- System kopiert, wonach sie gegebenenfalls von der Platte gelöscht werden können. Als Kriterien verwendet Disk Xtender die Größe der Files sowie die Zeit der letzten Änderung beziehungsweise des letzten Zugriffs.

Datenfiles und Partitionen

Das Verfahren würde normalerweise von Oracles Strategie durchkreuzt, die Datenfiles regelmäßig zu aktualisieren. Das gilt jedoch nicht für Datenbankdateien, die nur lesbar sind. Solche Dateien bleiben unverändert – wie sich ja auch die in ihnen gespeicherten Ergebnisse der Simulationen nicht mehr ändern. Außerdem sind die Tabellen mit Hilfe eines Schlüssels unterteilt (Range Partitioning). Den Partitionen lassen sich wieder eigene Datenfiles zuweisen.

Damit ergibt 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 Datenbankdatei.
■ Nun ist der Platz wieder frei für Partition n+1, die sich im weiteren Verlauf automatisch vergrößert.

Dateien, die der HSM-Mechanismus nach dem Kopieren in ein Disk-Xtender- Filesystem auslagert, werden dort in kleinere – konfigurierbar große Stücke – unterteilt (256 bis 512 MByte in der am Klimarechenzentrum verwendeten Konfiguration).

Datenstummel bleiben liegen

Wird eine Datei komplett von der Platte gelöscht (gepurged), müsste sie zunächst aus Datenbanksicht offline gesetzt werden, damit die Datenbank nicht versucht auch nur lesend auf das nicht mehr vorhandene File zugreifen. Um das zu vermeiden, lässt man nach dem Purgen der Datei immer den so genannten Stub, also den Kopf der Datei, auf der Platte stehen. Die Länge dieses Stubs ist konfigurierbar. Für Oracle-Datenbanken empfiehlt sich eine Größe von 256 KByte. Das Purgen entfernt also nur den Teil hinter diesem Header von der Platte. Aus Datenbanksicht bleibt die Datei weiterhin verfügbar und muss folglich auch nicht offline gesetzt werden. Greift ein Benutzer über die Oracle-Datenbank auf gepurgte Dateien zu, so startet der Disk Xtender im Hintergrund einen Prozess, der – transparent für den Benutzer und die Datenbank – das jeweils benötigte Stück (und nur dieses) zurücklädt. Der Download der Daten dauert dann entsprechend etwas länger. Um unnötige Bandzugriffe zu vermeiden, ist es wichtig, beim Anlegen der Tabellen die Speicherparameter sorgfältig zu wählen.

Langsam, aber sparsam

Ein Bandzugriff dauert meist knapp fünf Minuten. In dieser Zeit wird das Band ausgesucht, automatisch in ein Laufwerk geladen, bis zum Beginn der gewünschten Aufzeichnung vorgespult und gelesen. Danach gelangen die Daten via FTP zu dem Datenbankrechner. Erst jetzt bekommt der Anwender seine Daten zu sehen, der gesamte Download läuft im Hintergrund. Der Vorteil kleinerer Downloads ist, dass das System nicht immer die gesamte Datei von Band zurückzuladen braucht. Bei größeren Downloads muss dieser Zyklus jedoch mehrfach wiederholt werden. Das kann dann zu sehr langen Download-Zeiten führen, da die Datenbank nur ein Benutzer des HSM-Systems unter mehreren ist. Als großer Vorteil ergibt sich jedoch ein drastisch verringerter Bedarf an Plattenplatz für die Datenbank. Erkauft wird dies jedoch mit einer erhöhten Antwortzeit des Systems.

Petabyte-Datenbank schon im Blick

Die Anforderungen an die Klimavorhersage und damit auch an die Klimamodelle werden in Zukunft weiter steigen. Neben einer verfeinerten regionalen Auflösung ist es ebenfalls erforderlich, zusätzliche physikalische Prozesse des Klimasystems abzubilden. Die von den Klimamodellen erzeugte Datenmenge wird sich damit sicherlich nochmals beträchtlich erhöhen. Die im Klimarechenzentrum verwendete Architektur einer verteilten Oracle-Datenbank unter Linux wird grundsätzlich diesen Anforderungen gerecht. Die Zuverlässigkeit und Verfügbarkeit der Kombination Oracle und Linux hat sich in der Praxis als gut erwiesen. Die implementierte Lösung ist durch Hinzufügen weiterer TX-7-Zellen ausbaufähig. Einer Petabyte-Oracle-Datenbank unter Linux in absehbarer Zeit steht damit prinzipiell nichts entgegen. (jcb)

Info
[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/inux/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 Datenbankadministrator am Hamburger Max-Planck- Institut für Meteorologie, Gruppe Modelle und Daten.

Jan Schreiber arbeitet als freiberuflicher Oracle-Consultant (Loopback.ORG)