CERA Eine Oracle Datenbank in der Klimaforschung Hannes Thiemann Gruppe Modelle und Daten (M&D) am Max-Planck-Institut für Meteorologie, Hamburg Arne Brüning Server Technologies Competence Center Oracle Deutschland GmbH, Hamburg

Überblick Vorstellung M&D & Cera Die Lösung Ausblick Was sind Klimamodelle Die Daten Die Lösung Die Hardware Die Anwendung Wohin mit 1 PB? Ausblick

„Modelle und Daten“ (M&D) und „Deutsches Klimarechenzentrum“ (DKRZ)

„Modelle und Daten“ (M&D) und „Deutsches Klimarechenzentrum“ (DKRZ) Die Hauptaufgabe von M&D sowie DKRZ besteht darin, die deutsche und europäische Erdsystemforschung in ihrer Arbeit zu unterstützen. Der Schwerpunkt von M&D liegt bei der Anwendung von Klimamodellen und dem Zugang zu Klimadaten Der Schwerpunkt vom DKRZ liegt im Betrieb modernster Höchstleistungsrechner und Datenserver sowie der damit verbundenen Dienste.

Die Aufgabe

Phänomene und Prozesse im Klimamodell Nono

Numerische Klimamodelle (I) Klimamodelle simulieren das Klimasystem und seine Veränderungen. Das Klimasystem setzt sich aus den Subsystemen Atmosphäre, Ozean, Biosphäre und Kryosphäre (Eis und Schnee) zusammen. Die Komponenten des Klimasystems variieren in typischer Weise auf unterschiedlichen Zeitskalen, die von Stunden (Wettererscheinungen) über Monate (Oberflächenströmungen der Ozeane) bis zu Jahrtausenden (Landeismassen) reichen. Klimamodelle versuchen, dieses komplexe dynamische System in mathematischen Gleichungen zu beschreiben, die auf physikalischen Gesetzen beruhen. Auf diese Weise entsteht ein "Modellklima", in dem z.B. für die Atmosphäre die dreidimensionale Zirkulation, der Wasserdampfgehalt, Wolken und Strahlungshaushalt sowie die Wärmeflüsse simuliert werden.

Numerische Klimamodelle (II) In numerischen Klimamodellen wird die Erde mit einem dreidimensionalen Gitter überzogen, und für die Dynamik an den Gitterpunkten werden Gleichungen erstellt. Wie gut auf diese Weise das wirkliche Klima simuliert wird, hängt von der Maschenweite des Gitternetzes ab, die wiederum eine Folge der verfügbaren Computerleistung ist.

Beispiel eines 3D Gitters in einem Atmosphärenmodell

Datenentstehung Für jeden Punkt des verwendeten Gitters speichert das Klimamodell in diskreten Zeitabständen den kompletten Zustand des physikalischen Systems ab. Im Normalfall sind dies einige Dutzend Variablen, so z.B. Temperatur, Niederschlag, Luftdruck. Die Abspeicherung der Daten erfolgt in der Regel in einem Datenblock in dem alle diese Variablen auf allen Gitterpunkten zusammengefasst sind

Beispiele verschiedener Gitterauflösungen 600km 400km 300km 110km

Typische Auswertung Quelle: IPCC

Typische Datenmengen Modell Datenmenge (einzelne Variable, einzelnes Höhenlevel) pro Zeitschritt Datenmenge (gesamtes Modell) pro Modellmonat Datenmenge (gesamtes Modell) pro 500 Jahreslauf T42L19 (300 km) 16 KB 650 MB 3.7 TB T106L31 (110 km) 100 KB 5.2 GB 30 TB

Die Anwendung Cera

Allgemeine Topologie

CERA CERA – Climate and Environmental Climate and Archive Um Benutzern den Zugang zu am DKRZ erzeugten bzw. verwendeten Daten zu erleichtern, implementierte M&D eine Oracle Datenbank Enthält vornehmlich Daten aus Vorhersagen numerischer Klimamodelle, die dazu dienen Klimarisiken der Erde abzuschätzen. Den Datenproduzenten bietet sich hierdurch die Möglichkeit, Ihre Daten langfristig zu speichern und zu dokumentieren. Die Benutzer können aufgrund der Dokumentation für sie relevante Daten suchen, finden und extrahieren. Der Zugriff erfolgt über Intra- und Internet Gegenwärtige Größe der Datenbank: ca. 22 Terabyte in ca. 13000 Datenfiles Projektierte Größe der Datenbank in ca. 4 Jahren: 0.5 Petabyte

Umsetzung in Oracle Jede Zeitserie einer einzelnen 2-dimensionalen Variable wird in einer Tabelle als BLOB abgespeichert. Damit entsprechen einem typischen Experiment je nach Konfiguration etwa 200 bis 450 Tabellen. Eine einzelne Tabelle kann bei einem 500 Jahres-Experiment somit eine Größe von bis zu 70 GB erreichen. Die Daten werden, während das Modell läuft, bereits in die Klimadatenbank eingefüllt. Einfüll-Programme (OCI, Oracle Call Interface) bearbeiten den Rohdatenblock, der von den Klimamodellen erzeugt wird.

Umsetzung in Oracle (I) Jede Zeitserie einer einzelnen 2-dimensionalen Variable wird in einer Tabelle abgespeichert. Damit entsprechen einem typischen Experiment je nach Konfiguration etwa 200 bis 450 Tabellen. Für jede 2-dimensionale Variable werden die Daten jedes Speicherzeitpunktes in einem einzelnen Blob in dieser Tabelle abgespeichert. Eine einzelne Tabelle kann bei einem 500 Jahres-Experiment somit eine Größe von bis zu 70 GB erreichen.

Umsetzung in Oracle (II) Die Daten werden, während das Modell läuft, bereits in die Klimadatenbank eingefüllt. Zu diesem Zweck gibt es einen Satz von Einfüll-Programmen, die auf der Basis von OCI (Oracle Call Interface) arbeiten. Diese Programme bearbeiten den Rohdatenblock, der von den Klimamodellen erzeugt wird. Die Einfüll-Programme sind noch nicht synchron an den Modelllauf gekoppelt. Vielmehr werden die Daten zwischengespeichert.

Der Benutzerzugriff erfolgt über ein Java Applet. Benutzeroberfläche Der Benutzerzugriff erfolgt über ein Java Applet.

Die Hardware

Hardware Die vom DKRZ betriebene NEC SX-6/192M24/ 192 mit einer theoretischen Peak Performance von 1536 Gflops steht auf Platz 33 der 21. Top500 Liste der schnellsten Rechner weltweit. (www.top500.org)

Storage Am DKRZ werden derzeit 4 Silos des Typs Storage Tek betrieben. Bei insgesamt ca. 5150 nutzbaren Stellplätzen pro Silo ergibt sich bei 200 Gbyte pro Cartridge somit eine nutzbare Gesamtkapazität von ca. 4 Petabyte.

Datenserver Für den Datenservice werden verschiedene Rechner verwendet Sun (E12k und 4800) NEC TX7 (Linux 64 bit)

Die Probleme & die Lösungen

Problem: Migration auf iA64 Linux mit 24 CPU‘s NEC TX-7 Intel Itanium2 24 CPU ccNuma-Boards @ 4 CPU‘s HW-Partitionierbar Oracle9iDB für iA64-Linux „druckfrisch“ NEC-Linux unterstützt 24 CPU‘s, aber ... ... Oracle unterstützt nur United Linux und Red Hat ... die wiederum weder NUMA, noch 24 CPU‘s unterstützen

Problem: „Nur“ 65.535 Datafiles Datenfiles die gegenwärtig befüllt werden, können noch nicht read only gesetzt werden Plattenplatz reicht nicht aus, um neue Modellläufe komplett zu speichern, ohne daß bereits Daten ausgelagert werden müssen Aus Handling-Gründen ca. 10 GB/File = max. 655.350 TB Benötigt wird aber min. 1 PB!!! Datenfiles die gegenwärtig befüllt werden, können noch nicht read only gesetzt werden. Der verfügbare Plattenplatz reicht nicht aus, um neue Modellläufe komplett zu speichern, ohne das bereits Daten ausgelagert werden müssen. Daraus resultiert, das kleinere Datenfiles verwendet werden müssen. Die maximale Zahl der Datenfiles pro Datenbank liegt bei ca. 65000, dies ist völlig ungenügend für diese Anwendung. Als Resultat daraus ergibt sich, das die Datenmenge auf mehrere Datenbanken aufgeteilt werden muß.

Problem: Datenverlust bei langlaufenden Simulationen Eine Klimasimulation kann mehrere Monate dauern Damit wären im Falles eines Datenverlustes auch die Ergebnisse mehrerer Monate verloren. Lösung: Partitioning Option (Range Partitioning) Vermindertes Risiko durch R/O-Setzen der einzelnen Partitionen und Auslagerung Eine Klimasimulation kann mehrere Monate dauern Damit wären im Falles eines Datenverlustes auch die Ergebnisse mehrerer Monate verloren. Um dieses Risiko zu verringern, wird die Oracle Partitioning Option verwendet. Basierend auf dem Range-Partitioning werden dabei Tabellenbereiche auf einzelne Tablespaces abgebildet. Diese Tablespaces werden, sobald eine Partition komplett gefüllt ist , read only gesetzt und gesichert.

Problem: Wie migriert man 30 TB von Sun nach Linux online? Nur ca. 9 TB Daten auf Disk, der Rest im StorageTek Silo Grössere Down-Zeiten nicht akzeptabel

Die Lösung HW-Partitioning und separate Datenbanken NEC TX-7 1 1 1 1 1 1 1 2 3 4 5 6

Die Lösung HW-Partitioning und separate Datenbanken 1 6 Metadaten Enterprise User Security OID S U N 1 1 2 1 31 1 4 1 5 DB-Link

Problem: Wie bekommt man ein Petabyte in eine Oracle-DB Nur 9 TB Platte Daten nur Read-Only => Tablespace Read-Only Nologging! Problem beim Crash, dafür nur einmal sichern Alte Lösung (Erklärung Offline nehmen, per ftp-schicken, init.ora-Parameter) Lösung: EMC/Legato DiskExternder Die Daten werden, nachdem sie von dem Klimamodell erzeugt wurden, nicht mehr verändert. Dies erlaubt es, die Tablespaces mit den Blob-Daten in den Status „Read Only“ zu setzen. Da die Datentabellen mit der nologging-Option erzeugt werden, werden in den Redo-Log Dateien nur wenige Informationen protokolliert. Solange Tablespaces noch nicht read only sind, wären Daten im Falle eines Chrashes nicht rekonstruierbar. Nach dem Setzen von Read Only genügt jedoch eine einmalige Sicherung um Datenrecovery durchführen zu können. Datenfiles die gegenwärtig befüllt werden, können noch nicht read only gesetzt werden. Der verfügbare Plattenplatz reicht nicht aus, um neue Modellläufe komplett zu speichern, ohne das bereits Daten ausgelagert werden müssen. Daraus resultiert, das kleinere Datenfiles verwendet werden müssen. Die maximale Zahl der Datenfiles pro Datenbank liegt bei ca. 65000, dies ist völlig ungenügend für diese Anwendung. Als Resultat daraus ergibt sich, das die Datenmenge auf mehrere Datenbanken aufgeteilt werden muß.

EMC DiskXtender (I) EMC DiskXtender Data Manager ist eine Anwendung, die lokale Filesysteme verwaltet. Sie ist speziell ausgerichtet auf Filesysteme die Dateien von Oracle Datenbanken enthalten. Dateien werden automatisch auf ein Backend Speichersystem kopiert. Bei Bedarf werden Dateien von der lokalen Disk gepurged. Lediglich ein „Stub“ von 256k bleibt von jeder Datei auf Platte. Bei Zugriff werden lediglich benötigte Segmente der Dateien zurückgeladen.

EMC DiskXtender (II) Durch die Verwendung von dxdb verringert sich der Plattenbedarf enorm. Zur Zeit wird die Datenbank mit einem Gesamtplattenplatz von ca. 9 TeraByte betrieben. Alle Datenfiles sind ständig online. Der Zugriff ist jedoch durch die Einbindung des HSM – Systems verlangsamt. Die Lösung ist nur für Read Only Tablespaces geeignet, da von Read Write Tablespaces ansonsten ständig neue „Versionen“ auf Band gesichert werden müssten.

Ausblick Mega, Giga, Tera, Peta, Exa, Zetta, Yotta ... Daten 1 6 Metadaten 1 6 Metadaten Daten Enterprise User Security OID 1 1 1 2 1 2 1 31 1 31 1 4 1 4 1 5 1 5 Real Application Clusters

Kontakt Hannes Thiemann (thiemann@dkrz.de) Modelle und Daten Max-Planck-Institut für Meteorologie Bundesstrasse 55 20146 Hamburg Arne Brüning (arne.bruening@oracle.com) Server Technologies Competence Center Oracle Deutschland GmbH Niederlassung Hamburg