Oracle In-Memory Performance ohne Lizenzkosten

, ,

Im einem unserer Kundenprojekte werden für eine Bundesbehörde die Daten von ärztlichen Behandlungskosten ausgewertet. Hierfür sind teils komplexe Auswertungen nötig, die in weiten Teilen mit dem Oracle Analytics Server (OAS) in Echtzeit erfolgen. Um für die Anwender von Ad-Hoc-Reports keine allzu langen Wartezeiten entstehen zu lassen, wird seit 2021 die Oracle In-Memory Option verwendet, und zwar in der lizenzfreien Base-Level-Variante. Da diese nur die Bereitstellung von 16GB Daten zulässt, wurde ein reduzierter Data Mart entworfen. Auf diese Weise ist trotz der Limitierungen der kostenlosen In-Memory-Variante eine messbare Beschleunigung der Abfragen möglich geworden.

Komplexe Abfragen

Der Datamart des Data Warehouse (DWH) beherbergt 420 Millionen Fakten zuzüglich der entsprechenden Dimensionen. Die Auswertungen bestehen sowohl aus Standardberichten als auch aus interaktiven „Drill Down Reports“. Aus der Zeitdimension und den Dimensionen der zuständigen Bearbeitungsbehörden und Kunden werden für diese Berichte Hierarchien gebildet, die sich je nach Auswertung neu gruppieren. In den Auswertungen spielen die Laufzeiten der Anträge verteilt auf die Bearbeitungsstelle und bestimmte zu errechnende Intervalle (Wochen, Monate und bestimmte Meilensteine in der Antragsbearbeitung) eine entscheidende Rolle. Die fachliche Logik für die so errechneten Kennzahlen wurde im BI-Team zu den ursprünglich vorhandenen Anforderungen ergänzt oder sogar neu erstellt. Die Entwicklung wurde teilweise parallel zur Festschreibung der Anforderungen quasi agil vorangetrieben. Aus diesen Gründen wurde ein Großteil der fachlichen Logik direkt im BI-Tool (OAS, damals OBIEE) entworfen – die Entwicklungszyklen boten keinen Platz für die vorherige Ausgestaltung von ETL-Prozessen.

Lange Wartezeiten

Aus diesen Gründen ist das Datenmodell des Data Mart, aus dem die Berichte versorgt werden, nah an der Datenquelle gestaltet. Die Fakten und Dimensionen sind nicht so gestaltet, dass die Berichte direkt versorgt werden können. Dazu kommt, dass es mehrere Zeitstrahlen gibt, an denen sich die Daten ausrichten (Bi-/Tritemporale Historisierung nach der Zeit des Auftauchens der Datensätze im DWH sowie mehrerer fachlicher Zeitlinien). Die daraus resultieren SQL-Abfragen des OAS sind dementsprechend aufwendig und müssen oft mehrere Fakten miteinander verbinden. Das führte zu langen Wartezeiten beim Erstellen der Berichte. Der Zugriff auf die Standardberichte ist schneller, wenn der OAS diese bereits einmal ausgeführt hat und im Cache hält. Daher werden diese jeden Morgen einmal mit Hilfe eines OAS-Agenten ausgeführt. Das kann aber nur mit einigen wenigen Standardwerten erfolgen. Soll ein individueller Bericht ausgegeben werden, ergeben sich nach wie vor noch längere Wartezeiten.

Ein Datamart in Kleidergrößen

Um die Datenmengen, die kombiniert werden müssen, zu reduzieren, wurden Tabellen mit dem Suffix „XS“ eingeführt – angelehnt an die extra kleine Kleidergröße. In den XS-Tabellen werden nur die Fakten der gängigsten Anfrageintervalle aufgenommen. Dieser Prozess wurde in einer Zeit entwickelt, in der es nicht gelang, das OAS Repository so einzurichten, dass das Partitionierungskriterium zuverlässig aufgenommen wurde. Bei der Planung der In-Memory-Konfiguration erwies sich der XS-Datamart neben dem nur noch als Archiv genutzten vollständigen Datamart in Größe L als sehr hilfreich. Denn der gesamte Inhalt der XS-Größe passt in den 16GB-Storage, der für die nutzbaren Daten als maximale Größe (Base-Level-Lizenzvariante) durch Oracle vorgegeben ist.

Beauftragung und Einrichtung

Eine separate Beauftragung oder Installation der In-Memory-Option war nicht erforderlich. Lediglich die SGA (System Global Area – Speicherbereich der Oracle Datenbank) wurde vergrößert, um Platz für die In-Memory-Area zu schaffen. Die Konfiguration dafür bestand aus dem Setzen von drei Initialisierungs-Parametern:

alter system set inmemory_force=base_level scope=spfile;
alter system set inmemory_size=16G scope=spfile;
alter system set sga_target=42G scope=spfile;

Die Datenbank verfügt über 90 GB RAM in der Produktionsinstanz.
Anschließend ist die angepasste Konfiguration zum Beispiel im AWR-Bericht wie folgt zu sehen:

Der Parameter INMEMORY_SIZE wird in der CDB eingestellt.

Funktionsweise der In-Memory-Option

Bei der Oracle In-Memory-Option handelt es sich um eine Erweiterung der relationalen Datenbank von Oracle. Die Daten werden zusätzlich zur bisherigen Speicherung in der Datenbank auch im Arbeitsspeicher des Datenbankservers gehalten, und zwar im sogenannten „Column Store“. Dabei werden die Daten mittels einer speziellen Komprimierungstechnik (Columnar Compression) stark komprimiert. Je nach Konfiguration sind Kompressionsraten zwischen 2 und 20 möglich. 
Der entscheidende Unterschied zwischen einem reinen Caching der Zugriffe, wie im Database Buffer Cache, und dem In-Memory-Column-Store liegt darin, dass für In-Memory die Daten nicht zeilenweise (bzw. als Tabellenblöcke) in den Arbeitsspeicher geladen werden, sondern spaltenweise komprimiert im RAM gehalten werden. Diese Speichermethode erlaubt sehr effiziente Abfragen auf einzelne oder wenige Spalten von großen Tabellen mit vielen Zeilen, die mittels Filtern eingeschränkt und aggregiert werden. Diese Art von Abfragen kommen typischerweise in Data Warehouses vor.
Ist die In-Memory-Option aktiviert, stehen die Daten sowohl zeilenweise als auch spaltenweise (im In-Memory-Column-Store) zur Verfügung. Je nach Art der Abfrage wird auf die einzelnen Tabellenblöcke (auf Disk oder via Buffer Cache) oder auf den Column Store zugegriffen. Änderungen werden im Column Store nachgeführt, sodass die In-Memory-Option ohne applikatorische Anpassungen verwendet werden kann.

Das Base Level Feature unterstützt alle In Memory Funktionen außer:

  • Automatic In-Memory  (AIM)
  • Compression levels außer MEMCOMPRESS FOR QUERY LOW
  • Excluded columns (Es werden immer alle Spalten einer Tabelle geladen)
  • CELLMEMORY Feature in Exadata

Alle anderen Database In-Memory Features wie In-Memory Expressions, Join Groups, Automatic Data Optimization (ADO) und FastStart stehen zur Verfügung.

Auslagern der XS-Tabellen in die In-Memory-Area

Die Faktendaten in unserem Projekt haben einen Umfang von ca. 45 GB (420 Millionen Zeilen), dazu kommen 116 MB Dimensionen (2 Millionen Zeilen).
Der XS-Datamart hat aktuell einen Umfang von 11 GB (150 Millionen Zeilen). Es sind ein Jahr Abrechnungsdaten enthalten, allerdings inklusive der aktuell bestehenden Referenzen zwischen XS- und XL-Daten.
Die XS-Tabellen entstehen, indem zuerst die Daten für die kompletten Tabellen zusammengerechnet und dann die überflüssigen Daten wieder entfernt werden. All dies erfolgt im Rahmen der nächtlichen Beladung mit dem Oracle Data Integrator (ODI).
Die relevanten Tabellen des XS-Datamarts werden anschließend mittels „ALTER TABLE INMEMORY“ in den In-Memory-Bereich geladen. Hierfür wurden PL/SQL-Prozeduren in einem bestehenden PL/SQL-Package angelegt, die den XS-Datamart be- und entladen.

Leistungssteigerung in den Abfragen

Nach dem erstmaligen Einrichten der In-Memory-Area wurden zunächst einige bekannte Abfragen in der Entwicklungstestumgebung ausgeführt, die für ihre langen Antwortzeiten bekannt waren:

Die Laufzeit des obigen Statements war:

TestLaufzeit sPlan
Archiv-Tabellen7,8
XS-Tabellen ohne IM4Hash Join. Nested Loops, Full Scan, Fast Full Scan, Range Scan
XS mit IM0,233Hash join, inmemory full

Ergebnisse für die Anwender

In den Ausführungsplänen des oben genannten Statements in der Produktion lassen sich die In-Memory-Zugriffe gut erkennen.

Die Performance-Steigerung nur in diesem Fall beträgt bei einer Antwortzeit von 0,445 statt 3,359 Sekunden fast Faktor 8.

Beobachtung des In-Memory-Bereiches

Der Füllstand der In-Memory-Area lässt sich mit einer einfachen View beobachten:

Während des Betriebes kann man die Arbeit der In-Memory-Option beim Befüllen des Speicherbereiches auch im AWR-Report beobachten:

Den Füllstand des In-Memory-Speicherbereiches beobachten wir in einem einfachen OAS-Bericht.

Fazit

Ist es möglich, einen Datamart zu erzeugen, der nicht größer als 16GB ist, kann man die kostenfreie BASE LEVEL Variante der Oracle-In-Memory Option durchaus mit messbarem Erfolg einsetzen. Dies erfordert allerdings bei nichttrivialen DWH-Größen die Entwicklung eines Frameworks, das diesen reduzierten Datamart auch pflegt. Wir erledigen das im ODI und mit PL/SQL. Es muss allerdings auch im OAS eine Subject-Area für den reduzierten Bereich erstellt werden. Das ist ein Mehraufwand, den das Projekt für eine in entscheidenden Teilen achtfache Beschleunigung zu tragen gewillt ist.

Quellen

  1. Mike Dietrich: Oracle Database In-Memory BASE_LEVEL Feature available since 19.8.0
  2. Dani Schnider: Oracle In-Memory & Data Warehouse: Die perfekte Kombination?
  3. Oracle Database In-Memory Base Level Feature
  4. Oracle 12c Multitenant – Inmemory admin basics

BI in der Cloud – lohnt sich das?

,

Es gibt eine Menge einzelne BI-Angebote in der Cloud, aber ein komplettes Data-Warehouse? Ist das heute bereits realisierbar, oder lohnt es sich noch nicht?

Sollen DWH-Architekturen verändert oder neu aufgebaut werden, stellt sich zunehmend auch die Frage, ob das DWH mitsamt BI-Backend nicht auch in „die Cloud“ verlagert werden kann. Neben den dafür allseitig angeführten Argumenten wie verringerte Bereitstellungszeiten, Elastizität und Kostenersparnis reizen viele Entscheider gerade die Möglichkeiten, die BI-Tools in der Cloud versprechen: Anwender würden immer die aktuelle Version des BI-Stack nutzen und eine hohe Verfügbarkeit ließe sich trotz überschaubarer eigener IT-Ressourcen garantieren. Ein agiles Self-Service-BI verspräche zudem, die Mauer zwischen IT und Business zu überwinden, weil Anwender neue Auswertungen schnell und selbst entwerfen und auch sogleich testen könnten.

Welche Möglichkeiten bieten sich im Einzelnen zur Realisierung an?

Transaktionales BI

Viele Unternehmen sammeln die ersten Erfahrungen auf dem Weg in die Oracle-Cloud mit den „BI Apps“. Eigentlich sind diese eine On-Premise-Lösung, um schnell Daten aus einer Anwendung aufzubereiten und so darzustellen, wie man es von Oracles BI-Lösungen gewohnt ist – inklusive Dashboards und interaktiven Analysen. Relativ früh wurden die BI-Apps in der Oracle-Cloud angeboten. Für die gerne ebenfalls in der Cloud betriebenen Oracle-Applikationen wie HCM (Human Capital Management) existieren fertige Lösungen, die die gewünschten Ergebnisse bereits fertig aufbereitet präsentieren. Selbst die fachliche Logik, also das Wissen darum, welche für die Analyse notwendigen Zahlen in welchen Tabellen der Anwendung verborgen sind, wird bereits mitgeliefert. Der Kunde spart sich die gesamte Wertschöpfungskette des klassischen Data Warehouse: Quellsystem-Analyse, Datenmodellierung, ETL und Erstellung von Dashboards und Reports.

Die BI-Apps sind Teil des sogenannten Oracle-Transactional-Business-Intelligence (OTBI). Transaktional, weil die BI-Elemente direkt aus den operativen Vorsystemen, den transaktionalen Anwendungen, gespeist werden. Wann immer schnelle Analysen aus den Oracle-Applications benötigt werden, ist OTBI eine interessante Lösung: Obwohl schnell und schlank, steht die Aufbereitung der erhaltenen Daten denen der klassischen Präsentation, wie man sie aus On-Premise-OBIEE-Systemen gewohnt ist, kaum in etwas nach – und ist mit minimalem Aufwand in der Oracle-Cloud verfügbar. OTBI ist für viele Oracle-Cloud-Apps einfach als Zusatzoption buchbar.

Was das transaktionale Reporting nicht leistet, ist die Integration verschiedener Quellen, also die klassische Aufgabe des Enterprise Data Warehouse (EDWH). Daten können nur dort aufbereitet und dargestellt werden, wo die notwendigen Transformationen zwischen Quelle und BI-Darstellung durch Oracle vorbereitet sind. Sollen eigene Integrationen durchgeführt oder Daten aus verschiedenen Quellen konsolidiert werden, muss weiter ausgeholt werden.

BI Cloud Services und Analytics Cloud

Neben OTBI unterhält Oracle ein weiteres Cloud-basiertes Angebot: Business-Intelligence-Cloud-Services. BICS ist die Cloud-Alternative zur Installation des Oracle-Business-Intelligence-Servers (OBIEE) im eigenen Hause.

Zur Anpassung an die Cloud-Umgebung hat Oracle vor allem die Funktionalität des Admin-Tools in eine neue Oberfläche integriert. Das traditionelle Admin-Tool läuft lokal auf einem Entwickler-PC. Mit ihm wird das OBIEE-Repository erstellt: den physischen Datenbankobjekten werden logische Entitäten gegenübergestellt, die beispielsweise Tabellen durch Joins über entsprechende gemeinsame Attribute verbinden, und schließlich wird das für den Benutzer sichtbare Universum aus geschäftlichen Relationen definiert. Diese Funktionalität wurde nun mit Hilfe des neuen Cloud-Admin-Tools weitgehend vom Windows-Client und seiner in die Jahre gekommenen Optik befreit und per Web-Browser nutzbar gemacht.

Einen großen Sprung nach vorne haben die Oracle-BI-Cloud-Angebote durch die Einführung der Analytics-Cloud (OAC) erfahren. Denn BICS wies einige Nachteile auf:

  • Es konnten ausschließlich die Inhalte einerDatenbank aufbereitet werden.
  • Es konnten keine Agenten verwendet werden.
  • Der BI-Publisher und Essbase wurden nicht unterstützt

BICS wurde daher eher als ein abteilungsfokussiertes Angebot eingeschätzt, das für den unternehmensweiten Einsatz nur bedingt tauglich schien. Dementsprechend verhielt sich auch das Preismodell: für USD 3.500[1],– pro Jahr erhielt der Kunde BICS mit einer dazugehörigen Cloud-Datenbank, die auf ein Storage-Volumen von 50 GB und einen Durchsatz von 300 GB begrenzt war.

OAC überwindet all diese Einschränkungen und bringt den zusätzlichen Vorteil mit, dass der zu Grunde liegende Datenbankdienst frei gewählt werden und auch eine bereits vorhandene Datenbanklizenz genutzt werden kann. Im Gegensatz zu BICS ist OAC ein für die Cloud neu entwickeltes Produkt[2]. Die Kosten belaufen sich in der „non-metered“, also pauschal abgerechneten Version auf USD 3.000,– pro Monat und OCPU[3]für die Standard und USD 6.000,– Listenpreis[4]pro Monat und OCPU für die Enterprise Edition. Die Enterprise Edition beinhaltet auch Essbase.

Angebot Kostenpunkt Umfang Zielgruppe
OTBI (-E) Je nach Anwendung Cloud Fusion
spezifisches  transaktionales Berichtswesen
Abteilung bzw.
Organisation (-E)
BICS USD 30k/Jahr/10 Nutzer

(USD 1000/Monat +
USD 150/Monat/Named User)

Abgespecktes OBIEE in der Cloud Abteilung
OAC USD 36(SE)-72k(EE)/Jahr/OCPU

+ DB + IaaS

BI in der Cloud Abteilung und Unternehmen (mit eigener DB und ETL)

Wie jedes BI-Tool muss auch OAC mit den darzubietenden Daten bestückt werden. In der physischen Schicht des OBIEE bzw. BICS könnten natürlich transaktionale Daten der Vorsysteme direkt angeboten werden. Nun ist es aber so, dass die Data-Warehouse-Community ihre Referenzarchitektur nicht ohne Grund entworfen hat: Performance, Konformität und Konsistenz sind nur einige Schlagwörter, die eine Architektur bezeichnen, die sich auf Dauer zwar nicht ganz ohne Aufwand an Modellierung, Ladelogik und Speicherplatz realisieren lässt. Die aber eben doch in den allermeisten Fällen langfristig Zeit und Aufwand spart und zudem die entscheidenden Ergebnisse realistisch liefern kann.

DWH – Platform-as-a-Service

Ein klassisches, vollständiges Data-Warehouse kann Daten aus verschiedenen Quellen annehmen, aufbereiten und in ein gemeinsames Datenmodell integrieren. Die Daten werden – oft weiter zurückreichend als die Quellsysteme – historisiert, und durch Konsolidierung werden Redundanzen vermieden. Für die weitere Verarbeitung werden üblicherweise verschiedene Schichten angelegt: Die Stage, der Core und ein oder mehrere Data-Marts. Die Daten werden auseinandergenommen, transformiert und in ein dimensionales Modell geladen. Um das zu erreichen, werden eine Datenbank zur Ablage der jeweiligen Datenschichten und ein Extract-Transform-Load (ETL)-Tool benötigt.

Selbstverständlich bietet Oracle auch die Datenbank in der Cloud an. Dieses Angebot existiert in verschiedenen Ausprägungen[5]:

  • Database-Schema-Service: Ein Schema in einer Cloud-Datenbank mit 50 GB Volumen.
  • Exadata-Express: Eine Pluggable-Database (PDB) in einer 12.2 Cloud-Datenbank, ebenfalls mit einem Datenvolumen bis 50 GB.
  • Database-Cloud-Service (DBCS): Eine Datenbank auf einer Linux-VM in der Oracle-Public-Cloud, installierbar per Web-Tool in verschieden großen Ausprägungen.
  • Exadata-Cloud-Service: DBCS auf Exadata.
  • (Exadata)-Cloud-Service on Bare-Metal-Servers: DBCS auf einer dedizierter Hardware, die exklusiv für den Kunden reserviert ist (Private Cloud).

Für eine DWH-Datenbank empfiehlt sich, so lange – etwa aus Sicherheitsgründen[6]–  keine dedizierte Hardware benötigt wird, aber DWH-typische Anforderungen an Durchsatz und Zuverlässigkeit bestehen, der Exadata-Cloud-Service.

Allerdings ist von den verfügbaren Methoden, Daten in DBCS zu laden (SQL-Developer-Anbindung, APEX-Maske, REST- und SOAP-Interface sowie ein spezieller Adapter namens DataSync) nur letztere in der Lage, überhaupt Daten in den in DWH-Umgebungen üblichen Größenordnungen entgegenzunehmen. Es handelt sich dabei um ein Java-Tool, das die Daten aus der Quelle lädt und in die DBCS-Datenbank schiebt.

Der eigentlich angestrebte Weg, Daten der Quell-Systeme in ein DWH zu laden, ist aber in der Regel die Nutzung eines ETL-Tools, im Oracle Umfeld gerne des Oracle-Data-Integrators (ODI). Der ODI verfügt über eine Vielzahl von Lade-Adaptern, aber die besten Ergebnisse werden der Erfahrung nach mit der Nutzung von direkten Datenbank-Links erzielt, zumindest, wenn das Quellsystem auch eine Oracle-Datenbank verwendet.

Infrastructure-as-a-Service

Viele Anbieter von Cloud-Lösungen haben versucht, den Markt mit einer naheliegenden Strategie aufzurollen: Zunächst werden die Angebote mit überschaubarer Komplexität in die Cloud verlagert: Produkte, die mit möglichst wenig Anpassungen bei einer möglichst großen Kundenzahl erfolgreich einsatzbar sein könnten.

Auch Oracle hatte im ersten Schritt universell einsetzbare Produkte als Software-as-a-Service (SaaS) oder Platform-as-a-service (PaaS) anzubieten: HCM, BI-Apps, OTBI-Bausteine und BICS. Aber spätestens, wenn ein mehrschichtiges DWH mit selbstmodellierten Schichten, verschiedenen, auch noch nicht in der Cloud vorliegenden Quellen und angepassten ETL-Strecken, die diese konsolidieren aufgebaut werden soll, reichen die vorgefertigten Cloud-Angebote nicht mehr aus, und es bleibt nur der Ansatz Infrastructure-as-a-Service (IaaS) übrig. Hier wird zwar die Infrastruktur in der Cloud betrieben, aber deren Grenzschicht ist das Betriebssystem. Der Kunde erhält eigene virtuelle Maschinen, auf denen er dann die DWH-Komponenten selbst installieren und betreiben muss.

So gibt es zwar ein Produkt mit dem Namen „Oracle Data Integrator Cloud Service“, aber die Installationsanleitung umfasst sämtliche Schritte, die nötig sind, um das Repository, das Studio und die Agenten manuell auf der Kommandozeile in einer VM zu installieren.

In diesem Markt ist das Angebot von Oracle vergleichbar, wenn nicht austauschbar, mit dem anderer Anbieter wie AWS[7]. Es können zwar einige der ursprünglichen Ziele der Cloud-Migration realisiert werden, der Kunde muss keine eigene Hardware vorhalten und pflegen, aber der Aufwand für die Installation und Wartung der Software bleibt ihm nicht erspart.

Das Endresultat ist ein Gemischtwarenladen

Der Autor hat im vergangenen Jahr ein Cloud-DWH-Einführungsprojekt begleitet, das sämtliche hier diskutierten Aspekte umfasste und auch von Oracle konzipiert wurde.

Der Prototyp der neuen BI-Landschaft bestand aus Applikationen, die größtenteils bereits in der Cloud verwendet wurden: HCM, UCM, Field Service, Finance. ETL wurde mit dem ODI ausgeführt, der als IaaS-Komponente in der Oracle-Compute-Cloud installiert war. Die ODI Studio Clients liefen lokal oder auf einem Terminal-Server in der Compute-Cloud. Modelliert wurde mit einem lokal auf den Entwickler-PCs installierten SQL-Developer-Data-Modeler. Die Versionskontrolle erfolgte über Subversion, dessen Server wiederum in der Compute-Cloud beheimatet war. Die Datenbanken waren in einer Exadata-Cloud-Service-Quarter-Rack-Umgebung untergebracht. Als BI-Komponente diente BI-Analytics-Cloud-Service. Daten aus bestehenden On-Premise-Systemen wurden über einen ODI-Agenten geladen und teilweise in der Storage-Cloud abgelegt.

Eines der angetroffenen Probleme war, das selbst die Oracle-Cloud-Apps nicht immer über automatisiert benutzbare Schnittstellen verfügten, sondern darauf ausgelegt waren, Exporte als Dateien, die per Hand aus einer GUI erzeugt werden sollen, auszuführen. Werden solche Applikationen On-Premise betrieben, existiert meist die Möglichkeit, ETL direkt aus dem Datenmodell der Anwendung zu betreiben – bei den Cloud-Apps ist die Datensenke der Anwendung aber ein geschlossenes System.

Fazit

Die aktuell[8]bereitstehenden Oracle-Cloud-BI-Angebote sind in erster Linie dort erfolgreich einsetzbar, wo es um schnelle, abgrenzbare Lösungen geht. Ein Enterprise-Datawarehouse ist aber in den meisten Fällen kein einfach abgrenzbares Projekt. Der Gedanke, die komplette Business-Intelligence in die Cloud zu verlagern, ist für Entscheider sehr attraktiv, aber nicht immer zufriedenstellend umsetzbar. Hier muss selbst konzipiert, entwickelt und installiert werden. Bestehende Hardware in die Cloud zu verlagern, das funktioniert bei Oracle wie bei Amazon selbstverständlich. Ob die Komplexität der Schnittstellen der unterschiedlichen Cloud-Produkte untereinander am Ende des Tages einfacher zu handhaben ist als technische Schnittstellen von On-Premise betriebenen Systemen, bleibt hingegen abzuwarten. Die Gesamtsumme an Komplexität sowohl technischer als auch vertraglicher Art erhöht sich durch den Cloud-Einsatz sicher nicht.

Und es gibt noch einen anderen Aspekt: Ein strategischer Vorteil eines EDWH ist, einen konsolidierten und vollständigen Datenpool jederzeit im Zugriff zu haben. Erfolgreiche Unternehmen möchten sich natürlich auf ihr Kerngeschäft konzentrieren und keine Unsummen für Anschaffung und Betrieb im Zweifel schnell veralteter IT ausgeben. Aber die Verteilung der eigenen Daten auf eine Vielzahl von gemieteten Cloud-Anwendungen birgt die Gefahr, eben diesen Vorteil aufzugeben. Es droht eine Zersiedelung des Datenbestandes, in der die Übersicht und vor allem auch die Hoheit über die eigenen Daten verloren gehen kann. Und die Entscheidung, die eigene IT nur bei einem Cloud-Provider anzusiedeln, erhöht wiederum die Abhängigkeit von eben diesem Anbieter[9].

Alternativ gibt es ja auch noch die Möglichkeit, sich eine private Cloud auf Basis der Engineered-Systems oder Cloud-Machine aufzubauen.


 [1] Bei den Preisen werden im Folgenden stets die Listenpreise angeführt

[2] BICS ist aus der Code-Basis des OBIEE entstanden, einem um die Jahrtausendwende entstandenen und mehrmals weiterverkauften Produkt, dessen Code-Qualität Gerüchten zufolge nicht geeignet war, daraus ein echtes Cloud-Produkt zu erzeugen. Siehe auch: http://redpillanalytics.com/introducing-oracle-analytics-cloud/

[3] Oracle Cloud Version der Prozessormetrik bei der Lizenzberechnung (Oracle Core Factor)

[4] https://cloud.oracle.com/enUS/oac/pricing, Stand Mitte 2017

[5] Sehr schön ist auch der „Oracle Public Cloud Data Transfer Service“ zum Migrieren großer Datenmengen in die Cloud: Oracle schickt dem Kunden eine ZS4 Storage Appliance, auf die die Daten zwischengelagert und dann an Oracle zurückgeschickt werden.

[6] Etwa wegen der aktuellen Angriffsmöglichkeiten auf die Isolation virtueller Systeme (Spectre und Meltdown)

[7] Nichtsdestotrotz läuft die Datenbank in der Oracle Cloud einer Enkitec-Studie zufolge deutlich effektiver als bei vergleichbaren IaaS-Providern wie AWS. Siehe auch: https://www.accenture.com/t20161013T060358Z__w__/us-en/_acnmedia/PDF-34/Accenture-Oracle-Cloud-Performance-Test-October2016.pdf

[8] Das angesprochene Projekt fand im Frühjahr 2017 statt.

[9] IT-Infrastruktur in die Cloud zu verlagern, bedeutet, sie von Fremdanbietern betreiben zu lassen, und bedingt ein engeres Verhältnis als etwa ein Lizenzabkommen für Software. Ändert der Anbieter beispielsweise kurzfristig seine Geschäftsbedingungen in einer inakzeptablen Weise, kann es sehr schwer fallen, die Cloud wieder zu verlassen. Für Aufsehen hat in der Oracle-Community im Januar 2017 beispielsweise die Entscheidung gesorgt, überraschend die Core-Factor-Table zu Ungunsten von Nicht-Oracle-IaaS-Providern zu ändern. Siehe: https://oracle-base.com/articles/misc/oracle-databases-in-the-cloud

Oracle Wallets hacken

, , ,

Oracle Wallets werden benutzt, um SSL Zertifikate, die dazugehörigen Schlüssel, aber auch Klartext-Passwörter (Secure Enterprise Password Store) abzulegen. Sie werden normalerweise durch ein Wallet-Passwort geschützt, das bei jedem Öffnen oder Auslesen eingegeben werden muß.

Um auch automatisiert mit Wallets arbeiten zu können, gibt es die Auto-Login-Funktion. Wird diese aktiviert, wird eine zusätzliche Datei im Wallet erzeugt, die sogenannte Single Sign On Datei (.sso). Diese ist ebenfalls verschlüsselt, aber nicht mit einem benutzerdefinierten Passwort, sondern mit einem Standard-Passwort. Auto-Login-Wallets werden in der Regel verwendet, um eine automatisierte Anmeldung an der Datenbank durchführen zu können, ohne dass ein Passwort im Klartext in Skripten, Konfigurationsdateien oder Umgebungsvariablen abgelegt werden muss.

Damit es nicht möglich ist, ein Wallet einfach zu kopieren und von einem anderen Rechner aus zu verwenden, gibt es die Auto-Login-Local-Funktion. Wird diese für ein Wallet eingestellt, so kann das Auto Login Wallet nur auf dem Rechner verwendet werden, auf dem es erzeugt wurde.

Weiterlesen

Enterprise Security mit LDAP und PKI – Varianten der zentralen Benutzerverwaltung für Oracle Datenbanken

, , ,

Einleitung

Direkte Benutzerkonten und Passwörter in der Datenbank sind eine Sicherheits-Schwachstelle, da in der Regel keine eindeutige Zuordnung von natürlichen Personen zu Benutzerkonten möglich ist, keine unternehmenseinheitliche Sicherheitsregel durchgesetzt werden kann und ausgeschiedene Mitarbeiter nicht sicher und sofort aus sämtlichen Systemen ausgeschlossen werden können.

In diesem Artikel werden die verschiedenen Möglichkeiten aufgezeigt, Enterprise Single Sign On und Public Key Infrastructure (PKI) zu nutzen, um Datenbankbenutzer zu authentifizieren. Anhand von Projekterfahrungen aus der Praxis wird die Integration der Oracle Datenbank mit LDAP-Verzeichnissen (OID, OUD) und Microsoft ActiveDirectory mit und ohne Oracle Virtual Directory (OVD) erklärt sowie die Einführung von SmartCard-basierter PKI als Alternative vorgestellt. Weiterlesen

Performance Probleme mit der Oracle ZFS Appliance

, , , , ,

Für das Data Warehouse eines unserer Projektkunden, eines großen Telekommunikationsversorgers, hat dieser eine Oracle ZFS Appliance angeschafft und per Infiniband direkt mit seinen Exadata-Produktionssystemen verbunden, um ein schnelles Datensicherungs-Medium zu gewinnen, mit dem auch unkompliziert neue Test- und Entwicklungs-Umgebungen erzeugt werden können.

Die ZFS Storage Appliance (ZA) kann, wie jedes moderne Storage-System, Snapshots erzeugen, ohne nennenswert Zeit mit dem Kopieren der Daten zu verbringen. Diese können als Klone auch zum Schreiben geöffnet werden und so als Grundlage für neue Datenbanken dienen. Waren die Entwicklungsdatenbanken bisher stark veraltet, da das Erstellen aus der Produktion viel Zeit und Speicherplatz brauchte, können diese nun spontan geklont und auch einmal auf Zuruf in den Ausgangsstand zurückgesetzt werden. Die dafür notwendigen Schritte auf der ZA werden durch ein Oracle Tool namens Snapshot Management Utility (SMU) erleichtert, der den kompletten Prozess des Klonens inklusive dem notwendigen Recovery der Datenbanken dirigiert. Die Datenbanken werden dann mittels RMAN BACKUP AS COPY als inkrementelles Backup auf den NFS-Share der ZA  gesichert, wo sie als Datafiles vorliegen und nach einem Recovery geöffnet werden können.

Zunächst wurden auf der ZFS Appliance die entsprechenden Projekte und Shares angelegt. Wir haben einen ZA Cluster verwendet, der aus zwei Köpfen besteht, die jeweils alle Platten sehen, aber nur die ihnen zugewiesenen verwenden. In jedem Kopf sind Solid State Disks (SSDs) als Schreib-Cache (ZIL) verbaut. Fällt ein Kopf aus, kann der jeweils andere seine Platten übernehmen. Dieser Vorgang dauert übrigens tatsächlich einige Zeit, hinzu kommt, dass die Caches, wie nach jedem Neustart eines Kopfes, neu gefüllt werden müssen.

Aus Performance-Gründen haben wir nur einen ZFS Pool pro Kopf eingerichtet und ihn als Mirror (und nicht als RAIDZ) konfiguriert. Laut den Vorgaben aus dem entsprechenden Oracle Whitepaper für den Datenbank-Betrieb auf der ZA wurden dann die Shares für Datafiles, Redo und Archivelog entsprechend mit den passenden Einstellungen für Logbias, Recordsize, Kompression und Primarycache konfiguriert:

Share

Logbias

Recordsize

Primarycache

Compression

DATAFILES

latency (oder throughput)

db_blocksize

all

LZJB

INDIZES

latency

db_blocksize

all

off

CONTROLFILES

latency

128k

all

LZJB

Von der in ZFS prinzipiell unterstützen Deduplikation ist übrigens für diesen Einsatzzweck stark abzuraten, da die erforderlichen Ordnungstabellen sehr viel Platz im RAM benötigen und dort mit dem Cache kollidieren.

Die SSDs für das ZIL wurden gestriped eingerichtet. Ein Fehler auf einer SSD kann nun zusammen mit einem Stromausfall und dem daraus folgenden Verlust des Hauptspeicher-Inhaltes zu Datenverlust führen, aber wählt man hier die Konfiguration als Mirror, wird im Latency-Modus die maximale Schreibrate durch den Cache durch die Bandbreite einer SSD begrenzt – zu langsam für uns.

Auf der Exadata als Quellsystem und einer X4-2 Maschine, die als Datenbankserver für die Klon-Datenbankenvorgesehen ist, werden nun die Linux-Interfaces für Infiniband eingerichtet:

Enable LACP Link Aggregation
ifcfg-ibx MTU: 65520
Connected Mode

Dann werden die ZA-Shares per dNFS eingehängt. dNFS wickelt die wesentlichen Übertragungsprozesse direkt in den Oracle-Prozessen ab und führt für den Database Writer sowie für RMAN zu erheblichen Geschwindigkeitsvorteilen. Wir haben die folgenden Linux NFS- und Mount-Options verwendet:

rw, bg, hard, nointr, rsize=1048576, wsize=1048576, tcp, vers=3,timeo=600

Die Einstellungen in /etc/sysctl.conf waren:

net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=0
net.core.netdev_max_backlog=250000
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.rmem_default=16777216
net.core.wmem_default=16777216
net.core.optmem_max=16777216
net.ipv4.tcp_mem="16777216 16777216 16777216"
net.ipv4.tcp_rmem="4096 87380 16777216"
net.ipv4.tcp_wmem="4096 65536 16777216"

dNFS in Kombination mit Remote Direct Memory Access (RDMA) erbrachte die besten Ergebnisse. Allerdings ist RDMA nicht in allen Konfigurationen von Oracle mit dNFS unterstützt.

Insgesamt blieben die Lese- und vor allem Schreibraten, die wir von den Linux-Servern gegen die ZA bekamen, weit hinter den Erwartungen zurück.

Mit dd, CTAS aus der Datenbank oder anderen Testwerkzeuge haben wir folgende Durchsätze gemessen:

Konfiguration / Test

Durchsatz lesend

Durchsatz schreibend

Initiale Konfig, RMAN/OS

 

260 MB/s

CTAS, INSERT APPEND 

 

100 MB/s

Kernel-NFS

400 MB/s

 

dNFS

1,9 GB/s

 

Adaptive Direct IO, NOLOG, throughput bias, rs=128k, IPoIB

1,6 GB/s

 

NFS over RDMA

3,5 GB/s

400 MB/s pro Pool

Bündel-Test, Latency Mode

5,5 GB/s mit beiden Köpfen

1 GB/s

ORION Test

 

600 MB/s (ein Kopf)

_adaptive_direct_read=TRUE

 

55 MB/s (DOP=10)

Mit Patch für Bug 19339320

 

115 MB/s

_direct_io_wslots=32, parallel_execution_message_size=65536

 

315 MB/s

Schreiben mit vielen parallelen Sessions

 

1,2 GB/s

Mit allen SSDs

 

1,7 GB/s

NFS/IPoIB Durchsatz X4-2 / ZA

1,25GB/s pro Interface

 

Ziel mit 2x 4G Wirespeed

7 GB/s

4 GB/s (sustained IO)

Oracle-Angabe

(27TB/h), 17,3GB/s on ZA

 

Viele der genannten Tests beruhen auf Vorschlägen durch den Oracle Support. Wegen dieser Performance sind seit einigen Monaten zwei Oracle-SRs und ist mittlerweile ein Bug offen. In den Griff bekommen haben wir die Probleme bisher trotz Überprüfung von allen denkbaren Komponenten bis hinunter zur Verkabelung und Einsatzes mehrere Oracle-Engineers vor Ort nicht. Eventuell ist hier ein Bug in den Mellanox-Treibern oder im Linux Kernel verantwortlich?

DB Link Passwörter Metadaten in 11.2.0.4

, ,

Seit der Datenbank Version 11.2.0.4 funktioniert das Auslesen der Beschreibungen für Datenbank-Links über DBMS_METADATA.GET_DDL nicht mehr. Statt des Passwort Hashes wird nun eine Bind Variable angezeigt.

Die Passwörter von Datenbank-Links wurden früher in der PASSWORD-Spalte der Tabelle SYS.LINK$ im Klartext abgelegt und waren einfach lesbar. In Version 10gR1 wurde der Zugriff auf diese Tabelle aus der Rolle SELECT ANY DICTIONARY entfernt, mit 10gR2 wurde die Spalte PASSWORDX eingeführt, die nun nur noch den Hash speichert.  Mit der Sicherheit dieses Hashes steht es allerdings auch nicht zum Besten.

Während es in älteren Versionen möglich war, die komplette Link-Beschreibung inklusive der Passwort-Hashes in einer „BY VALUES“-Klausel auszulesen, sieht das Ergebnis in 11.2.0.4 so aus:

SQL> SELECT OWNER, DB_LINK, DBMS_METADATA.GET_DDL('DB_LINK',DB_LINK,OWNER) as DDL FROM DBA_DB_LINKS;
OWNER          DB_LINK      DDL
-------------- ------------ ----------------------------------------------------------
SYS            TEST_LINK    CREATE DATABASE LINK "TEST_LINK"
                            CONNECT TO "DBLINK_ACCOUNT" IDENTIFIED BY VALUES ':1'
                            USING 'TNSALIAS'

Der für den Link notwendige Hash steht allerdings immer noch in der PASSWORDX-Spalte der SYS.LINK$-Tabelle, und kann mit Hilfe von DBMS_CRYPTO recht einfach ausgelesen werden:

SQL> select 
 name, 
 userid, 
 utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr(passwordx,19)), 
  4353, (substr(passwordx,3,16)))) 
from sys.link$;

NAME       USERID         UTL_RAW.CAST_TO_VARCHAR2(DBMS_CRYPTO.DECRYPT
                          ((SUBSTR(PASSWORDX,19)),4353,(SUBSTR(PASSWORDX,3,16))))
---------- ---------      -------------------------------------------------------
TEST_LINK  DBLINK_ACCOUNT GEHEIMESPASSWORT

Oft wird eine solche Möglichkeit benötigt, um Skripte zu erstellen, die Objekte wie Links zusammensuchen, um sie zu paketieren und für Deployment bereitzustellen.

Dieser Bug in der Datenbank Version 11.2.0.4 ist bei Oracle klassifiziert unter: Bug 18461318. Der Status dieses Bus steht allerdings auf „44 – Not Feasible to fix, to Filer„, was nicht sehr vielversprechend klingt.


Update 23.11.2017: Es findet eine Verschlüsselung, keine Hash-Wert-Berechnung, des Link-Passwortes statt, und diese lässt sich brechen.

Virtual Desktop Infrastructure in der Praxis

,

Erfahrungen mit einer VDI-Umgebung im Testbetrieb

Motivation und Ausgangssituation

Die Gelegenheit, ein Büro als Projekt „auf der grünen Wiese“ komplett neu mit Arbeitsplätzen auszustatten, ergibt sich nicht mehr allzu häufig. Finden wir sonst in der Regel gewachsene Strukturen vor, lässt für ein solches Projekt die Frage stellen, welche Arbeitsmittel denn genutzt werden sollen.

  • „Traditionelle“ PCs (Windows), Workstations (Linux) oder Apple Macintosh Computer in Form von „Blechkisten unter dem Schreibtisch“. Diese Geräte sind sperrig, aber bieten hohe Performance am Arbeitsplatz. Soll auch remote oder im Home Office gearbeitet werden, muss ein zusätzliches Notebook gestellt werden. Hier stellt sich als nächstes die Frage, wie gut die Synchronisation der Daten zwischen mehreren Geräten funktioniert. Selbst bei Verwendung von Active Directory-Profilen oder mobilen Homeverzeichnissen am MacOSX Server klappt es inder Praxis oft nicht, auf zwei verschiedenen Geräten gleichzeitig mit den gleichen Anwendungen auf den gleichen Daten arbeiten zu können. Und die Zahl der Menschen, die ausschließlich an ihrem Büro-Arbeitsplatz arbeiten, nimmt sicher stetig ab.
  • Notebooks mit Dockingstation, die angedockt als vollwertige Workstation funktionieren. Hier entfällt das Synchronisationsproblem, man arbeitet nur noch an einem Gerät. Probleme entstehen hier bei Anwendungen mit hohem Resourcenbedarf, die das Notebook überfordern, weil dieses zu langsam ist, nicht über genug Arbeitspeicher verfügt und -vor allem bei modernen Notebooks mit SSD- nicht genug Platz für das Arbeiten mit Sammlungen grosser Dateien hat. Ebenfalls problematisch ist, dass Unternehmensdaten auf mobilen Geräten gespeichert sind. Im Falle von Spionage oder dem Diebstahl des Notebooks besteht die Gefahr, dass wichtige Daten in die falschen Hände geraten. Notebooks sind außerdem über verschiedene Hardware-Schnittstellen wie USB und Firewire besonders effizient angreifbar. Im Zweifelsfall kann selbst eine Datenverschlüsselung (Full Disk Encryption) überwunden werden. Ausserdem müssen auch hier mobile Homeverzeichnisse, Profile oder automatische Datensicherungen mit entsprechendem Synchronisationsaufwand benutzt werden, um sicherzustellen, dass ein verlorengegangenes oder defektes Notebook schnell und ohne Datenverlust wieder hergestellt werden kann.
  • BYOD: Der Anwender bringt sein eigenes Notebook mit („Bring Your Own Device“). Hier stellen sich diverse Fragen nach Datensicherheit auf privaten Geräten, der Verstrickung von IT-Support in selbstgepflegte und nicht standartisierte Betriebssystem-Installationen und der Trennung von Firmen- und privaten Daten. In Deutschland sind gesetzliche Regelungen zu beachten, die das Verhältnis zwischen Arbeitnehmer und Unternehmen bezüglich des Datenschutzes regeln. Ein vielversprechender Ansatz ist, den Firmen-Desktop als virtuelles Image auf dem vom Benutzer verwalteten Gerät laufen zu lassen. So sind der Firmen-Arbeitsplatz und der private Desktop voneinander getrennt. Dieses Image muss aber auch synchronisiert werden. Die Alternative ist, überhaupt keine Daten auf dem Gerät mehr vorzuhalten, indem man einen Terminalserver oder Anwendungsvirtualisierung verwendet. Hier laufen alle Programme auf dem Server im Unternehmen, und der Client dient quasi nur noch als Display und Eingabegerät, auf dem sich keine Daten mehr befinden. Dieses Konzept funktioniert natürlich nur, so lange eine ausreichend performante Netzwerkanbindung besteht. Für das Arbeiten im Zug oder Flugzeug ist ein Terminalserver nicht geeignet.
  • Mobile Geräte. Werden ausschliesslich Web-Applikationen (oder gar native Apps für mobile Geräte) benutzt, lassen sich ganz neue Wege gehen. Hier muss nur noch ein absolut minimal installiertes Gerät bereitgestellt werden, das im Wesentlichen nur einen Web-Browser mitbringt. Es kann ein Tablet verwendet werden, oder ein Chromebook. Bis auf bestimmte Sicherheitseinstellung wie der VPN-Zugang muss nach dem Kauf des Gerätes fast nichts mehr angepasst werden. Aber die wenigsten Unternehmen werden in der Praxis auf Desktop-Computer und entsprechende native Anwendungen verzichten können.

Im vorliegenden Fall spielten Sicherheitsüberlegungen eine entscheidende Rolle. Unternehmensdaten sollten sich nicht auf Notebooks befinden, denn auch gute Festplattenverschlüsselung wie TrueCrypt oder FileVault wurde als nicht ausreichend sicher gegen physikalische Angriffe (das laufende Gerät wird im Hotelzimmer oder bei einer Zollkontrolle mit Malware infiziert bzw der Arbeitsspeicher durch physikalischen Zugriff ausgelesen) empfunden.

Aus diesem Grund wurde eine Evaluationsumgebung für eine Virtual Desktop Infrastruktur (VDI) aufgebaut.

Überblick der VDI-Charakteristiken

VDI wird von mehreren Herstellern (VMWare, Microsoft und Oracle) angeboten. Die Idee dahinter ist, Desktop-PC’s zu virtualisieren und auf einem entsprechenden Server laufen zu lassen. Das Display der Anwender wird nun nur noch als Anzeigegerät verwendet, das Betriebssystem und sämtliche Applikationen laufen auf dem Virtualisierungsserver, und sämtliche Daten und Speicherinhalte bleiben auf dem Storage-Server.

Hieraus ergeben sich eine Reihe von Vorteilen:

  • Die Clients bzw. Terminals, die die PCs und Workstations ersetzen, sind kostengünstig, energieeffizient und langlebig. Sie enthalten nur wenige und unkomplizierte Komponenten und keine beweglichen Teile.
  • Notebooks oder iPads als mobile Zugriffs-Clients müssen nur minimal konfiguriert werden (der VPN-Zugang muss eingerichtet und die Virtual-Desktop-Software installiert werden) und enthalten dann keine Unternehmensdaten, sondern dienen immer nor als Sichtgeräte. Auch bei Verlust und Diebstahl ist damit nicht viel anzufangen, sie sind einfach zu ersetzen (weil einfach neu zu installieren), und da sie keine Daten enthalten, können diese nicht nur nicht gestohlen, sondern deren Herausgabe auch nicht erpresst werden, indem etwa die Herausgabe eines Verschlüsselungspasswort abgepresst wird.
  • Durch eine Web-Schnittstelle (bei Oracle Global Desktop genannt) kann in der Regel auch ganz ohne eigenes Endgerät über einen Web-Browser auf den Unternehmens-Desktop zugrgriffen werden. Dieser läuft dann im Browser-Fenster wie ein Film ab.
  • Da die Desktops im Data Center laufen, laufen sie auf Server-Hardware, die Ausfälle durch Versagen billiger PC- oder Notebook-Komponenten lassen sich vermeiden. Redundant ausgelegt, kann eine hohe Zuverlässigkeit des Gesamtsystems erreicht werden.
  • Aus dem gleichen Grund kann eine systematische Datensicherung erfolgen, ohne das ein Notebook synchronisiert werden muss.
  • Desktops lassen sich versionieren und klonen. Eine Windows- oder Linux-Desktop-Installation inklusive der benötigten Applikation kann einmal als Master erstellt und dann in kurzer Zeit geklont und für die einzelnen Anwender bereitgestellt werden. So kann es einfacher sein, eine einheitliche Installationsbasis zu erreichen. Ebenso können Updates zentral und systematisch ausgerollt und Bedrohungen zentral erfasst werden, da sich alle Desktops für die IT-Administration immer im Zugriff befinden.
  • Der Desktop eines Anwenders kann nacheinander auf verschiedenen Geräten (Workstation/Terminal, Notebook, iPad, Web) verwendet werden, ohne das er neu gestartet werden muss. Eine Anwendung kann also weiterlaufen, während sie heute auf dem einen und morgen von unterwegs auf einem anderen Gerät verwendet wird. Ein Anwender kann also seinen tagsüber verwendeten Desktop mit allen Apps abends im Zug oder zu Hause weiterverwenden, und alle Apps sind sind währenddessen weitergelaufen, und ihre Netzwerk-Verbindungen blieben erhalten.
  • Ein Anwender kann auf einem Gerät mehrere Desktops unterschiedlicher Betriebssysteme oder Terminalserver gleichzeitig bzw. nacheinander nutzen.
  • Sicherheitsentscheidungen sind sofort umsetzbar: Ein gesperrter Account ist sofort nicht mehr benutzbar, und alle damit erreichbaren Daten sind sofort nicht mehr zu erreichen.
  • Ein kompromittierter, mit Malware oder Viren verseuchter oder einfach defekter Desktop kann vergleichsweise einfach und schnell neu bereitgestellt werden, indem ein neuer Klon des Master-desktop gezogen wird.

…und Nachteilen:

  • Das Setup der Server ist nicht zu unterschätzen: Virtualisierungs-, Storage und Management-Server müssen eingerichtet, überwacht und betrieben werden.
  • Ein entsprechendes Skillset der IT-Administration muss aufgebaut werden.
  • Ohne Netzwerkanbindung ist kein Arbeiten an den Desktops mehr möglich.
  • Die verwendete Server-Hardware ist durchgehend teuerer als billige Notebook- oder Workstation-Hardware. Da auch triviale Operationen wir beispielsweise das immer wieder ausgeführte Laden von Windows und Office für jeden Desktop auf dem Server abgearbeitet werden muss, relativiert sich die Kostenersparnis schnell.
  • Das zentrale System lässt sich zwar redundant auslegen und absichern, aber wenn es doch einmal ausfällt, kann kein Anwender mehr arbeiten.
  • Es kann schwierig sein, Anwendungen voneinander zu isolieren, und zu verhindern, dass eine CPU- und speicherhungrige Applikation die Ressourcen anderer Anwender „auffrisst“.
  • Die Güte der Grafik und das Antwortzeitverhalten eines optimal konfigurierten PC’s mit hochwertiger Grafik kann in der Regel nicht erreicht werden.
  • Auf Grund technischer und lizenzrechtlicher Einschränkungen lassen sich Macintosh-Desktop’s in keiner der VDI-Umgebungen virtualisiert einsetzen.

Nach einer grundsätzlichen Marktübersicht wurde entschieden, die Evaluationsumgebung als Proof-of-Concept mit der Sun / Oracle Lösung bereitzustellen.

Aufbau der Virtual Desktop Infrastruktur

Als Grundlage dienten zwei VDI-Server: Ein Server für das VDI-Management, der den VDI-Dienst selbst sowie die Software für das Mangement der SunRay-Clients (Sun Ray Server Software, SRSS) und den Secure Global Desktop (SGD, früher als Tarantella benannt) beherbergt. Als Datenbank für die Statusinformationen aller Komponenten sollte eine bereits vorhandene zentrale MySQL-Datenbank verwendet werden, dies gestaltete sich bei der Installation allerdings als so schwierig, dass schließlich eine separate MySQL-Instanz auf dem VDI-Management-Server erzeugt wurde – diese Möglichkeit sehen die Installationsskripte selbst vor. Dieser Server wurde mit Solaris 11 eingerichtet und direkt danach wurde Oracle VDI 3.5 installiert.

EIn weiterer Server wurde als Virtualisierungsserver konfiguriert. Hier wurde aus Kompatibilitätsgründen Solaris 10 verwendet, und danach im Wesentlichen VirtualBox installiert. VDI steuert Virtualbox über SSH-Kommandos und die Ausgabe über RDP, daher ist für das Management kein spezieller Adapter notwendig. Virtualbox muss in einer speziellen Version, die zu VDI kompatibel ist, und der Entwicklung von VirtualBox etwas hinterher hängt, verwendet werden.

Als Storage-Provider wurde ein ZFS-iSCSI-Filer verwendet. Da keine Sun Storage Appliance zur Verfügung stand, wurde ein weiterer Server mit Solaris 10 und ZFS eingerichtet. Leider ist Solaris 11 mit seinen vielen Verbesserungen im ZFS (zum Beispiel -endlich- Encryption) nicht als VDI Storage Provider verwendbar, da Oracle den iSCSI-Stack ausgetauscht hat. Hier kommt nun COMSTAR zum Einsatz, und Oracle VDI 3.5 ist leider nicht damit kompatibel. Ansonsten ist die Einrichtung des Storage Providers aber einfach, der iSCSI-Servide muss nur eingeschaltet werden, dann kommuniziert die VDI über SSH mit dem ZFS Server und richtet die ZFS-Filesysteme für die „Festplatten“ der Desktops und die ZFS-Snapshots der Desktop-Templates selbstständig ein. Die Datensicherung erfolgte über „zfs send“ bzw das Skript „zetaback“ auf einen zweiten ZFS-Server.

Der Zugriff auf die Desktops sollte mehrschichtig möglich sein:

  • Über Thin Clients. Hier wurden Sun Ray Clients angeschafft. Diese Terminals von Sun bzw. Oracle werden schon sehr lange in verschiedenen Versionen produziert. Allen gemeinsam ist, dass sie einen SmardCard-Reader zur Authentifikation besitzen. Die ersten Versionen (SunRay-1 und -2) waren kleine Desktop-Boxen mit VGA- und/oder DVI-Anschluss für externe Displays sowie USB für Tastaturen und Eingabegeräte. Spätere Versionen kamen mit FC-Netzwerkinterfaces für gesicherte Netzwerke (Baureihe -FS) und integriertem Display (Modell 270). Die Baureihe wird von Oracle weitergeführt und ist aktuell auch mit 21″-Displays erhältlich.
  • Über vorhandene Notebooks und MacBooks, auch mobil über das VPN. Hier wird die Oracle Virtual Desktop Client (OVDC) verwendet, die es für Windows. Linux und MacOSX gibt. Diese simuliert einen Sun Ray Client und unterstützt auch gängige USB-SmartCard-Reader, die dann wir ein Original-SunRay-SmardCard-Reader zur Anmeldung verwendet werden können.
  • Über iPad-Tablets. Für IOS gibt es im Apple App Store die Oracle OVDC App. Wird ein Cisco VPN verwendet, kann sich das iPad direkt im VPN anmelden und dann die OVDC App direkt verwendet werden. Ein SmardCard-Schnittstelle fehlt hier leider. Eine externe Bluetooth-Tastatur funktioniert, und die Maus wird per Touch simuliert.
  • Über das Web mittels SGD / Tarantella. Einzelne virtualisierte Anwendungen oder komplette Desktops können so über das Web erreicht werden. Auch hier fehlt natürlich die SmartCard-Unterstützung.

Die Authentifikation der Benutzer kann über Usernamen und zusätzlich über SmardCards erfolgen. Von Oracle gibt es ein Demo-Pack mit 100 SC-Cards, die in den SunRay Clients und in gängigen USB-Lesegeräten funktionieren. VDI kann so konfiguriert werden, dass eine SmardCard („Token“) mit einem Benutzer und einer Menge an vorgandenen Desktops assoziiert wird. Wird die Karte eingesteckt, ist der damit assiziierte Benutzer vorausgewählt, und Desktops, die an die Karte gebunden sind, können nur verwendet werden, wenn sie eingesteckt ist. Wird die Karte aus einer SunRay entfernt, und in eine andere gesteckt, erscheint der aktuell verwendete Desktop sofort am neuen Terminal. Es ist also möglich, seinen Desktop von einem Raum in den anderen „mitzunehmen“. Diese Möglichkeit macht das System im Gesundheitssektor interessant, wo es neben Regierungsbehörden in den USA relativ häufig verwendet wird, da es dem medizinischen Personal ermöglicht, von Zimmer zu Zimmer zu gehen und beispielweise Röntgenbilder überall zu zeigen – eine Möglichkeit, die aber mittlerweile auch mit Tablet’s besteht.

Wird die Smartcard als Zugriffsberechtigung eingesetzt, ergibt sich unmittelbar eine Two-Factor-Authentication für den Desktop-Zugriff. Für die Anmeldung ist neben einem Faktor, den nur der Benutzer kennt, also dem Passwort („something you know“) immer auch ein Gegenstand im Besitz des Anwenders („something you have“) erforderlich.

Für die passwort-basierte Authentifizierung wurde das Firmen-LDAP verwendet. Es ist in der VDI-Konfiguration direkt möglich, einen LDAP oder Active Directory Server einzubinden. Im vorliegenden Fall handelete es sich um einen Oracle Internet Directory Service.

Einrichtung der Desktops

Es wurden drei Desktop-Pools eingerichtet:

  • Linux Ubuntu LTS
  • Windows 7
  • Windows XP

Laut der Oracle Dokumentation müssen die Desktops mit der Virtualbox-Version, unter der sie nachher in der VDI betrieben werden sollen, installiert werden. Daher war es nötig, zur Installation VirtualBox direkt unter Solaris auf dem Virtualisierungs-Server zu starten und die Ausgabe über X11 zu leiten. Alternatv kann der VirtualBox Guest „headless“ betrieben und per RDP verwendet werden.

Die weitere Installation des Desktops erfolgt dann auf ein Disk Image, dass im Dateisysten des Virtual Box Servers liegt. Es kann dann das Installationsmedium als ISO-Image eingehängt und das Betriebssystem installiert werden. Bereits nach einer rudimentären, aber startfähigen Installation kann der Desktop als Template in VDI importiert werden. Dazu wird in VDI zunächst ein entsprechender Pool für diese Art von Desktops angelegt, und dann der Desktop importiert. Nun ist dessen Image bereits auf dem Storage-Server per iSCSI abgelegt, und das lokale Image aus der initialen Installation kann gelöscht werden.

In den Pool-Einstellungen werden die Ausführungsparameter, die zugeteilten Ressourcen (CPU, RAM) und die Art der Bereitstellung abgelegt. Grundsätzlich gibt es selbstständig und manuell klonende Pools. Bei automatisch bereitstellenden Pools (autocloning) wird ein Zielgröße angegeben, und das System sorgt dann dafür, das stets die entsprechende Anzahl von Desktops zur Verfügung steht. Jeder Desktop bleibt bestehen, bis er „wieder eingeschmolzen“ („recycle)“ wird. Je nach Konfiguration geschieht dies entweder nach Aufforderung, oder wenn der Desktop heruntergefahren, oder die Karte entfernt wird. In diesem Fall wird dem Anwender bei der nächsten Anmeldung ein frischer Desktop aus dem Pool zugeteilt, und der Pool im Hingerund mit einem neuen Desktop, der aus dem Template geklont wird, aufgefüllt.

Die Templates werden über Revisionen verwaltet. Bei Änderungen im Template wie der Installation von Updates oder neuer Software können diese zunächst getestet werden, ist alles zur Zufriedenheit, wird eine neue Version des Templates erzeugt und kann sofort oder zu einem bestimmten Zeitpunkt zur Erzeugung neuer Desktops als Grundlage verwendet werden. Dementsprechend kann auch auf jede alte Version des Templates zurück gewechselt werden. Dieses Szenario könnte zum Beispiel bei Malware-Attacken sehr nützlich sein – über Nacht können alle vorhandenen Desktops gelöscht und das Template korrigiert bzw auf einen Zeitpunkt vor dem Problem zurückgestellt werden.

Im Laufe der weiteren Installation sollten zunächst die VirtualBox-Guest-Additions installiert werden, damit Tastatur und Maus funktionieren und die Bildschirmauflösung korrekt angepasst wird. Nach der Installation der Software-Updates kann die Unternehmensanpassung vorgenommen werden, indem Authentifikation und Profileverwaltung sowie Sicherheitsrichtlinien eingestellt werden. In unserem Fall würde für Windows eine LDAP-Athentifikation am OID über die Open Source Software pGina eingerichtet. Für Linux wurde die Standard-LDAP-Konfiguration verwendet, die Home-Verzeichnisse wurden von einem NFS Server gemountet.

Erfahrungen aus dem Praxisbetrieb

Die Akzeptanz des Systems bei den Test-Benutzern war unterschiedlich und von der Alternative abhängig. Gut aufgenommen wurde das System, wenn es verfügbar und die Terminals gut ausgestattet waren (gutes Display mit nativer Auflösung). Anwender, die als alternative Arbeitsumgebung beispielweise ein aktuelles MacBook mit SSD und Retina-Display besassen, hatten ihre Mühe mit der virtualisierten Umgebung.Der Bildaufbau des Dektops ist über das Netz immer etwas langsamer als bei Desktop-Hardware mit entsprechenden Grafik-Chips.

Laufen ressourcenhungrige Anwendungen in mehreren virtuellen Desktops, kam es in der Testumgebung recht bald zu einer Überlastung des Virtualisierungsservers und / oder des Storage Servers. Eine Anbindung des Storage über ein dediziertes Storage LAN brachte hier etwas Linderung. Gundsätzlich ist zu überlegen, inwieweit gerade eine Testumgebung von Beginn an optiomal ausgestattet werden kann. In einer produktiven Umgebung sollten mehrere Virtualisierungsserver mit einsprechender Kapazität bereitgestellt werden, ebenso eine redundante Auslegung des VDI-Verwaltungsservers (hier ist ein Parallelberieb möglich). Fehlt eine entsprechende Auslegung im Testbetrieb, besteht die reale Gefahr, dass die Anwender die gesamte Lösung nicht akzeptieren, da die Vorteile sich dem Anwender nicht unbedingt auf den ersten Blick erschließen, eine schlechte Performance oder Verfügbarkeit aber unmittelbar ins Auge fällt. Hier ist natürlich ein Problem, wenn für die Testumgebung nur ein begrenztes Budget zur Verfügung steht.

Gerade die subjektive Performance-Wahrnehmung wird gesteigert, wenn die Desktops so konfiguriert werden, dass keine oder nur einfarbige Hintergrundbilder eingestellt sind. In der Oracle Dokumentation sind weitere sinnvolle Tipps zur Konfiguration erwähnt, zum Beispiel entsprechende Windows-Grundeinstellungen. Bildschirmschoner müssen natürlich generell abgeschaltet werden, da sie die anderen Desktops lähmen. Einen sehr grossen Unterschied machen die unter Windows leider unvermeidlichen Virescnanner – bei allengetesteten Produkten verminderte sich die Performance des Desktops nach dem Einschalten spürbar. Bestimmte Produkte wie Symantec funktionieren in VirtualBox überhaupt nicht. Die besten Erfahrungen haben wir mit Kaspersky gemacht.

Laufen die VDI-Server im Single Instance Betrieb und sind nicht redundant ausgelegt, hat ein Ausfall den sofortigen Ausfall sämtlicher Desktops zur Folge. Sind die Ressourcen des VirtualBox-Servers erschöpft, wird der Start neuer Desktops ausgesetzt, und Anwender bekommen bei der Anmeldung die Meldung, dass Ihnen kein Desktop zur Verfügung steht.

Die Authentifizierung mit SmardCards klappt in der Praxis gut, so lange kiene nicht SmatCard-fähigen Geräte verwendet werden solllen – ist dies der Fall, ist das Konzept natürlich durchbrochen, weil die Desktops doch wieder auf Anmeldung mit Username und Passwort konfiguriert werden müssen. Es lassen sich dann beide Verfahren gleichzeitig nutzen, aber die Verwendung der Karte bringt nun keinen Sicherheitsgewinn mehr. Eine Lösung könnte hier eventuell sein, verschiedene Desktops bzw. Pools mit unterschiedlicher Sicherheitseinstufung einzurichten, von denen nur einer für die Anmeldung ohne Karte zugelassen ist.

Wird die Two-Factor-Authentication mit Karte aus Sicherheitsgründen erzwungen, bringt dies natürlich nur einen tatsächlichen Gewinn, wenn die Anwender Ihre Zugangskarten nicht im Terminal stecken lassen oder in den Rollcontainer legen – auch nicht bei kurzen Pausen. Eine gute Lösung wäre sicher, die Hausausweise oder Zugangskarten, wenn vorhanden, mit der SmartCard auf einer Karte zu integrieren, so dass die Karte aus dem Terminal entfernt werden muss, wenn das Gebäude verlassen und wieder betreten werden soll. Eine entsprechende Karte mit SunRay-kompatibler SmardCard-Funktionalität und KABA-kompatibler RFID-Kompatibilität war aber im Rahmen dieses Tests nicht mit vertretbarem Aufwand zu beschaffen. Andererseits muss natürlich auch erwähnt werden, dass die SunRay Terminals keine kryptographischen Funktionen der SmartCards nutzen – es wird lediglich die Sereiennummer der Karte ausgelesen und als Token-ID in VDI verwendet. Hier bieten sich auch interessante Ansätze zu weiteren Anwendungen, zum Beispiel für die PKI-Authentifikation gegenüber weiteren Systemen, auf der SmardCard.

Entscheidend für die Benutzbarkeit des Gesamtsystems ist die Transparenz neue geklonter Desktops. Müssen nach dem Bereitstellen viele Einstellungen angepasst oder gar fehlende Anwendungen nachinstalliert werden, stellt die Neubereitstellung ein erhebliches Hindernis dar. Hier ist besondere Geschicklichkeit im Umgang mit den Lizensierungsfunktionen von Windows und den eingesetzten Applikationen gefragt. Die VDI Umgebung sueht die Möglichkeit vor, die Windows-Lizensierung im Rahmen des Desktop Clonings automatisch vorzunehmen, in der Praxis hat dies mit den vorhendenen Windows-Lizenzen allerdings nicht funktioniert. Ebenso wichtig ist eine vollständige Profilverwaltung mit Active Directory, damit die persönlichen Verzeichnisse der Anwender eine Neubereitstellung des Desktops überdauern. Fehlen nach dem Neu-Klonen die im Benutzerverzeichnis abgelegten Dokumente, entsteht nachvollziehbare Frustration. In unserem Fall war dies mit pGina nicht möglich, daher musste das automatische Klonen neuer Desktops in den Windows-Pools abgeschaltet werden. Bei Linux war dies kein Problem, dafür hatten verschiedene Apps wie Firefox permamanente Probleme mit per NFS eingehängten Home-Verzeichnissen, aber dies ist eine andere Geschichte und gehört zu den Problemen, die nicht direkt mit VDI zusammenhängen.

Die User Experience war an den SunRay-Terminals am besten. Wichtig ist, Original-Sun-Tastaturen zu verwenden, denn bei normalen USB-Tastaturen wurde die Tatstaturbelegung nicht automatisch erkannt, so dass es zu Problemen bei der Passwort-Eingabe kommt. In Guest-OS selbst kann die korrekte Tastaturbelegung dann natürlich eingestellt werden.

Kleine Schwierigkeiten gab es mit den VirtualBox Guest Additions – diese waren teilweise instabil und erfüllten ihre Funktion nach einiger Zeit nicht mehr vollständig. Dies hatte zur Folge, dass Desktops nicht mehr durch den VDI Controller heruntergefahren oder in den Ruhezustand versetzt werden konnten und manuell in der VDI-Kontrolle ausgeschaltet werden mussten.

Als durchgehend positiv wurde die Möglichkeit wahrgenommen, bei Bedarf auch mehrere Desktops unterschiedlicher Betriebssysteme zur Verfügung zu haben. Ebenfalls sehr positiv wurde die Möglichkeit aufgenommen, die Arbeitsplätze nicht nur zentral administrieren, sondrn auch zentrall starten, stoppen und gegenenfalls auch komplett neu initialisieren zu können – und das sogar sehr schnell.

Fazit

VDI ist eine zu traditioneller IT alternative Methode, Desktops im Unternehmen bereitzustellen. Installation und Betrieb der Oracle-Umgebung erscheinen mittlerweile stabil und ausgereift.

Die Arbeit an den virtualisierten Desktops ist flexibel, aber die Benutzer-Erfahrung (snappiness) ist weniger direkt als bei einem gut eingerichteten lokalen Desktop.

Aus Sicht der Unternehmens-IT ist der Einsatz von VDI sicherlich sinnvoll, um Sicherheitsanforderungen abzubilden. Der Hauptvorteil ist, das die Daten das Unternehmen zu keiner Zeit verlassen, und der Zugriff, ebenso wie die verwendete Software, zentral administriert werden kann.

In der Kostenbetrachtung egalisieren sich die Unterschiede bei Betrieb von VDI und traditionellen Desktops. Für kleine Unternehmen wird es sehr schwierig sein, die hohen Kosten für eine hochverfügbare Serverumgebung mit ausreichender Leistung zu budgetieren.

Literatur und Verweise

Datenbankmigration nach Unicode

, ,

cpi-partner-kyrill-schnitt

Einer unserer Kunden ist in der Güterbeförderung auf der Schiene im europäischen Raum tätig. Die Anwendung, mit dem die Abrechnung der Transporte gesteuert wird, basiert auf Oracle Forms und der Oracle Datenbank 11gR2. Dieses System weist sehr viele Schnittstellen unterschiedlichster Natur auf: zum Host, auf dem die Schienenbewegungen erfasst werden, zu einem anderen, ebenfalls Oracle-Forms-basierten System, in dem die Auftraege gesteuert werden, zu SAP, zur Bank und zum Druckdienstleister, der aus den aus der Datenbank geschriebenen XML-Dateien PDF-Dokumente erzeugt.

Im Rahmen der europäischen Integration bekommt das System Zuwachs. Die Bahnen aus osteuropäischen Laendern sollen angeschlossen werden. Dabei ergibt sich ein Problem: In diesen Ländern ist der kyrillische Zeichensatz weit verbreitet. Firmennamen, Ortsnamen, Strassennamen tragen kyrillische Bezeichnungen. Das System soll also in die Lage versetzt werden, neben west- auch osteuropäische Zeichen zu unterstützen. Also muss das gesamte System aus Datenbank, Forms-Server und eigenentwickelten Schnittstellen in Unicode migriert werden. Und da die Datenmengen ständig wachsen, sollte die Umstellung so bald wie möglich erfolgen.

Für neue Datenbank-Installationen ist Unicode, oder UTF-8, bereits seit längerer Zeit Standard. Auch bei Java und XML ist die Verwendung von Unicode längst üblich. Neue Oracle-Datenbank-Installationen werden vom Oracle Universal Installer als Default im Oracle-Zeichensatz AL32UTF8 (NCHAR AL32UTF16) angelegt. Dieser Zeichensatz wird auch als UTF-8 bezeichnet und sollte nicht mit dem Oracle-Zeichensatz UTF8 verwechselt werden. Bei Oracle’s UTF8, auch als CESU-8 bezeichnet, handelt es sich um einen Legacy-Zeichensatz, dessen Verwendung nicht mehr empfohlen wird. Er stammt noch auf den Anfangszeiten von Oracle’s Engagement in Unicode.

AL32UTF8 ist ein dynamischer Multibyte-Zeichensatz, der 1-4 Bytes pro abzubildendem Zeichen verwendet. Für ASCII-Zeichen wird 1 Byte, für europäische Zeichen und solche aus dem mittleren Osten werden in der Regel 2 Bytes, für asiatische Zeichen in der Regel 3 Bytes verwendet. AL32UTF8 entspricht der Unicode 4.0-Konvention.

Für neue erstellte Datenbanken hat Oracle also sinnvolle Default-Einstellungen gesetzt, aber was macht man mit bestehenden Datenbanken? Ältere, westeuropäische Oracle-Installation verwendet oft WE8ISO8859P15, das war auch hier der Fall.

Migrationspfade

Traditionell gibt es zwei Arten der Datenbankmigration nach Unicode:

  • Der Neuaufbau einer frischen Datenbank im neuen Zeichensatz mit anschliessendem Re-Import der Daten. Bei diesem Ansatz wird eine neue Datenbank parallel aufgebaut. Beim Importieren der Daten wird der Zeichensatz dann durch Data Pump konvertiert. Das hat zunächst den Vorteil, den Neuaufbau parallel zum laufenden Betrieb und ohne Zeitdruck durchführen zu können. Allerdings werden hierfür dann auch doppelte Ressourcen benötigt: Es braucht Platz für den Parallelbetrieb der neuen Datenbank. Die Anforderungen an die Downtime („Betra“ – Betriebsausfall) hängen stark vom Datenvolumen ab, denn auch mit Data Pump dauert das Ex- und Importieren abhängig von CPU- und Storage-Leistung lange – in diesem Fall zu lange, um in die maximal mögliche Downtime von zwei Tagen zu passen.
  • Die Migration mit den CSSCAN/CSALTER-Tools. Bei diesen Verfahren wird mit dem Oracle-Tool CSSCAN zunächst überprüft, welche Konflikte in den vorhandenen Daten vorhanden sind. Bestimmte Probleme mit den Ausgangsdaten müssen manuell oder durch Reimport gelöst werden. Diese Tools sind allerdings mittlerweile etwas in die Jahre gekommen und können kein komplexeren Probleme wie das Verlängern von Spaltenbreiten (s.u.) oder die Konvertierung von Data Dictionary Objekten lösen.

Darüberhinaus gibt es einige neuere Ansätze:

  • DMU. Das Thema Unicode-Migration scheint in der letzten Zeit an Aktualität gewonnen zu haben und Oracle hat sich zur Datenbank-Version 11 entschlossen, ein Java GUI Tool zu entwickeln, welches versucht, den gesamten Prozess in einem geführten Workflow abzubilden. Der „Database Assistant for Unicode“ scannt die Datenbank, bereitet die Ergebnisse in einer anschaulichen Übersicht auf, bietet zur Behebung von Qualitätsproblemen einen eigenen Dateneditor und führt abschliessend die Konvertierung und eine abschliessende Kontrolle durch.
  • Abgehängte Migration mit Streams. Hier wird die Datenbank zunächst geklont. Zwischen der Original-Datenbank und der Kopie wird dann eine Streams-Replikation eingerichtet. Ist diese fertig, wird sie wieder angehalten, und nun kann die Kopie in aller Ruhe mit DMU konvertiert werden. Abschliessend wird die Replikation wieder aktiviert, und die Änderungen, die sich in der Zwischenzeit auf der Originalseite angesammelt haben, können übertragen werden. Streams ist in der Lage, diese während der Übertragung nach Unicode zu konvertieren. Sind beide Datenbanken auf dem gleichen Stand, kann der Betrieb in einer sehr kurzen Auszeit auf die Kopie umgeschaltet werden. Diese Methode bietet gleich eine ganze Reihe von Vorteilen: Sie ist neben der kurzen Umschaltzeit beliebig wiederholbar. Zudem kann die konvertierte Datenbank beliebig intensiv getestet werden, bevor sie live geschaltet wird. Wird ein Fehler gefunden, kann der Prozess jederzeit neu begonnen werden.

dmu textlogo

Bei diesem Projekt kamen aus Ressourcengründen alle Verfahren, die den parallelen Aufbau vorsehen, nicht in Frage. Dennoch sollte die Migration in ein Zeitfenster von einem Wochenende passen. Nach einigen Tests zur Geschwindigkeit des Datenex- und Imports wurde schnell klar, dass die 800Gigabyte Daten kaum in diesem Zeitfenster importiert werden konnten – vom zusätzlich notwendigen Aufbau der Unicode-Datenbank ganz abgesehen. Denn im Zeitfenster eines Wochendes müssen am Sonntag vormittag alle Umbauarbeiten abgeschlossen sein, da ein Rückfall auf ein vollständiges Restore mittags beschlossen werden müsste, wenn dieser bis Montag morgen garantiert durchgeführt werden soll. Erste Tests müssten also bis Sonntag Mittag erfolgreich absolviert werden. Aus diesen Gründen kamen nur noch die Methoden CSSCAN und DMU in Frage.

Probleme mit den Ausgangsdaten

cpi_vorgefundene_zeichen

In der nächsten Phase wurde mit CSSCAN und DMU eine Bestandsaufnahme über die in der Ausgangs-Datenbank vorhandenen Daten erhoben. Dabei wurden verschiedene Kategorien vom Ausgangszeichen angetroffen:

  • Daten, die nicht konvertiert werden müssen. Hierbei handelt es sich um Zahlen oder Zeichen, die im Ausgangs- und Ziel-Zeichensatz identisch abgebildet werden. 98% der Daten fielen in diese Kategorie.
  • Daten, die konvertiert werden müssen und können. Dies betraf 1% der Daten, 235 Millionen Zellen. Diese „straighforward“-Konvertierung kann das DMU-Tool von sich aus vornehmen. Aus dieser Kategorie waren neben VARCHAR2 auch LONG und CLOB-Typen vorhanden.
  • Daten, die eine Anpassung der Feldlängen im Datenmodell erfordern („over column limit“). Diese Problematik resultiert daraus, dass Feldlängen in Zeichenlängen früher als Anzahl der verwendeten Bytes angegeben wurden. Unglücklicherweise ist dies immer noch der Default, wenn Tabellen in Oracle angelegt werden. Erst wenn die Umgebungsvariable „nls_length_semantics“ auf „char“ gesetzt wird, oder bei der Spaltendefinition explizit das Wort „CHAR“ angegeben wird, wird die Feldlänge, abhängig vom Datenbank-Zeichensatz, als Anzahl von Zeichen interpretiert. Als BYTE angelegte Spalten können bei einem Multibyte-Zeichensatz wie UTF-8 nicht die ursprünglich vorgesehene Anzahl an Zeichen aufnehmen. Die Spaltendefinitionen müssen daher geändert und die Spaltenlängen vergrößert werden.
  • Zeichenketten, die im Multibyte-Zeichensatz so lang werden, dass sie nicht mehr in ein VARCHAR2-Feld passen („over type limit“). Ein VARCHAR2-Feld kann mit maximal 4000 Byte definiert werden. Solche Daten müssen gesondert behandelt werden, zum Beispiel, indem das VARCHAR-Feld in ein CLOB umgewandelt wird, oder in dem der Inhalt auf zwei VARCHAR-Felder aufgeteilt wird. Solche Änderungen am Datenmodell erfordern natürlich in der Regel auch applikatorische Anpassungen.
  • Daten, die offensichtlich nicht im Datenbank-Zeichensatz vorliegen („invalid binary representation“). Der binäre Wert dieser Zeichen hat keine Entsprechung im Zeichensatz der Datenbank. Da der Ausgangszeichernsatz nicht festeht (der der Datenbank ist es offensichtlich nicht), kann auch keine sinnvolle Konvertierung vorgenommen werden. Diese Daten sind aber auch vor der Konverung schon fehlerhaft: garbage in, garbage out. Wie diese Daten in die Datenbank gekommen sind, lässt sich oft nicht mehr festellen. Meist dürfte es an einem falsch konfigurierten Datenbank-Client liegen, dessen NLS_LANG-Konfiguration nicht der aktuellen Einstellung des Client-Betriebssystems oder dem Aufbau einer Import-Datei entspricht.

Sonderzeichen im Data Dictionary

Ein weiteres Problem für die Konvertierung sind Sonderzeichen im Data Dictionary. Diese kann der DMU nur in einigen Fällen konvertieren. In diesem Fall sorgten insbesondere Umlaute in Triggern und PL/SQL Packages für Probleme.

Eine Möglichkeit, damit umzugehen, ist, diese Objekte einzeln zu überarbeiten und entsprechende Sonderzeichen zu entfernen. Bei umfangreicher installierter Software ist dies allerdings meist nicht möglich. Andere Alternativen sind, diese Objekt zu ex- und nach der Migration wieder zu re-importieren, oder die Software zu löschen und neu zu installieren.

Ablauf der Migration

Das Projekt gliederte sich in drei Phasen: Bestandsaufnahme, Bereinigung und Konvertierung.

Bestandsaufnahme

dbpropscane

Für die Bestandsaufnahme erfolgte zunächst ein Scan mit dem DMU. Dazu muss zunächst die DMU-Software installiert werden. Jeder Computer mit Verbindung zur Datenbank kommt dafür in Frage, da die Java-Software des DMU prinzipiell unter jedem System mit Java JDK1.6 läuft. Auch in der Datenbank muss ein Package installiert werden: SYS.DBMS_DUMA_INTERNAL. Dies geschieht durch Einspielen des Skriptes ?/rdbms/admin/prvtdumi.plb. Die Datenbank sollte möglichst 11.2.0.3 sein, frühere Versionen erfordern das Einspielen von Patches.

Das Tool kann auch auf dem Datenbankserver selbst gestartet werden, dann muss aber im Fall von UNIX als Server-Betriebssystem für eine stabile Ausgabe von X11 Sorge getragen werden. Aus diesem Grund wurde ein Windows-PC verwendet. Ideal wäre ein Terminalserver oder ein Client in einer Virtual-Desktop-Umgebung, denn die Abläufe mit dem DMU dauern in der Regel sehr lange und während der Migration wäre ein Netzwerkausfall zwischen Datenbank und DMU-Client verheerend, ebenso wie ein Absturz des Client-Computers selbst.

Der Scan erfordert SYSDBA-Berechtigungen und kann während der Produktionszeiten erfolgen. Die Parallelität, mit der der DMU die Datenbank scannt, kann konfiguriert werden, läuft nur ein Prozess, dauert es entsprechend länger. In der Praxis konnten wir mit 8 Scan-Prozessen ohne Probleme während des Betriebes arbeiten, in den Nachtstunden wurde mit 16 Prozessen gearbeitet. Ein Scan dauerte etwa 3 Stunden.

migstattab

Bei Tests ergab sich die Situation, dass während des Scans die Netzwerkverbindung abbrach. Dauerte dieser Unterbruch zu lange, verlor der DMU die logische Verbindung zur Datenbank und reagierte nicht mehr. Nach einem Neustart erkennt der DMU die Situation und versucht, sein internes Repository (DMU-Tabellen im SYS-Schema) zu bereinigen. Dies kann sehr lange dauern und der DMU ist währenddessen nicht benutzbar. In einigen Fällen kam dieser Vorgang gar nicht mehr zum Ende. Entfernte man die Sessions des DMU aus der Datenbank, startete der Prozess bei der nächsten DMU-Anmeldung von Neuem. Einzige Abhilfe brachte in dieser Situation das Deinstallieren des Repositories. Dies kann mit Hilfe des Skriptes drop_repository.sql geschehen, das sich im /admin-Verzeichnis des Tools findet, und hat keine Nebenwirkungen: Danach kann das Tools sich wieder an der Datenbank anmelden und baut ein neues Repository auf. Danach ist natürlich ein frischer Scan nötig.

Bereinigung

DMU_edit_row

Ist die Bestandsaufnahme abgeschlossen, kann in die Ergebnisanalyse eingestiegen werden. In unserem Fall wurde zunächst versucht, die ermittelten Probleme in möglichst viele gleichartige Klassen zu unterteilen, die dann mit Skripten angegangen werden konnten. Zunächst wurde ein Skript erstellt, dass alle Tabellen mit BYTE-Spaltendefinitionen in CHAR-Definition umwandelt. Dies kann schlicht mittels „alter table .. modify“ erfolgen. Dann wurden individuelle Lösungen für die „over type limit“-Fälle geschneidert, meist wurden hier VARCHAR2-Felder in CLOB imgewandelt werden, dazu legt man am Besten eine temporäre CLOB-Spalte an, kopiert den Inhalt der VARCHAR2-Spalte mit einem UPDATE-Statement, lösche diese und benennt das CLOB in den ursprünglichen Namen der VARCHAR-Spalte um.

Bei den „Invalid Binary Representation“-Fällen war ein wenig detektivischer Spürsinn gefragt. Mit etwas Phantasie gelang es in den meisten Fällen den ursprünglichen Zeichensatz zu erraten. Dann konnten spezialisierte Update-Statements geschrieben werden, die die ungültigen Zeichen zusammengefasst bereinigten. Bei der Entwicklung dieser Korrekturscripte wurde versucht, die Datenqualität gleich dauerhaft zu verbessern, und die eine oder andere Stunde an Recherche über die korrekte Schreibweise osteuropäischer Orte und internationaler Produktbezeichnungen aufgewendet.

Die verbleibenden Fälle, das waren diejenigen, die weniger als zehn Vorkommen aufwiesen, wurden in Einzelfallbearbeitung bereinigt. Der DMU bietet hierzu ein schönes interaktives Interface an, dass die fragwürdigen Zeichen gleich farblich hervorhebt.

Ist die in der Datenbank vorhandene Software in einem eigenen Schema installiert und von dem Schema, in dem die Daten liegen, getrennt, so hat man Glück und kann das Software-Schema exportieren und löschen und anschließend befinden sich keine problematischen Objekte mehr im Data Dictionary. Im vorliegenden Fall war dies nicht möglich, und die betroffenen Trigger und Packages mussten per Skript gelöscht werden. Zum Re-Installieren der Software nach der Migration muss dann natürlich die Software entweder neu installiert werden können. Ist kein Installationsmechanismus vorhanden, müssen diese Objekte, ebenfalls per Skript, neu angelegt werden. Hierfür hat es sich nach einigen Tests mit Perl und dem SQL Developer als am sinnvollsten erwiesen, die Definitionen dieser Objekte vorher mit DBMS_METADATA.GET_DDL zu extrahieren und entsprechende Installationsskripte erstellen zu lassen. Um Umstände zu vermeiden, wurde das PERFSTAT-Schema, das ebenfalls betroffen war, kurzerhand entfernt – PERFSTAT kann hinterher neu angelegt werden.

Zum Abschluss empfiehlt es sich, einen Blick auf den Volumenzuwachs zu werfen. Durch die Multibyte-Repräsentation wächst während der Konvertierung die Datenmenge. Es ist also entsprechend Platz in ASM oder den Filesystemen vorzusehen und darauf zu achten, dass die Datafiles hinreichend Reserven aufweisen oder auf AUTOEXTEND stehen. In unserem Fall haben wir etwa 10% Volumenzuwachs gesehen, das entsprach auch der Vorabschätzung des DMU.

Die Bereinigungsphase ist abgeschlossen, wenn das Status Panel des DMU nach einem abschliessenden Scan den Status „ready for conversion“ anzeigt.

Konvertierung

Vor der Konvertierung sollte sichergestellt werden, dass für die umfangreichen UPDATEs, die das Tool absetzt, genügend Platz für die Archive Logs bereitsteht, bzw ob es sinnvoll ist, ARCHIVELOG während der Migration komplett abzuschalten, was sich natürlich sehr positiv auf die Laufzeit auswirkt.

Es gibt in der Version 1.1 des DMU einen Bug, der während der Konvertierung zu einem Abbruch mit dem Fehler „ORA-22839: Direct updates on SYS_NC columns are disallowed“ führen kann. Um dies zu vermeiden, sollte vor der Konvertierung ein Event 22838 gesetzt werden: „alter system set events ‚22838 TRACENAME CONTEXT LEVEL 1, FOREVER'“.

Vor der Konvertierung sollten zudem alle Jobs abgeschaltet werden („alter system set job_queue_processes=0“).

Die Konvertierung selbst konnte ohne Probleme durchgeführt werden. Die Konvertierungszeit lag bei 17 Stunden. Sollten während der Konvertierung einfache Probleme wie eine volle FRA oder ein fehlendes AUTOEXTEND auftreten, hält DMU an und bietet die Möglichkeit, den Vorgang fortzusetzen, wenn das Problem behoben wurde.

conversion_successfull

Nacharbeiten

Nach der Konvertierung ist der Datenbank-Zeichensatz umgestellt, nun müssen eventuell noch entsprechende Client-Settings angepasst werden, zum Beispiel die Konfiguration von NLS_LANG.

Außerdem ist es empfehlenswert, den Parameter NLS_LENGTH_SEMANTICS=CHAR in der Datenbank zu setzen und die Nls_Length-Semantics-Konfiguration der Clients anzupassen, damit zukünftige Objekte nicht in BYTE-Semantik angelegt werden. Beim SQL Developer kann diese Einstellung in den Settings gesetzt werden. Hier empfiehlt sich eine entsprechende Information aller Entwickler. Auch bei Software-Lieferprozessen, die oft in der Unix-Shell mit sqlplus erfolgen, sollte darauf geachtet werden, hier die richtige Konfiguration, auch von NLS_LANG, zu wählen. Wenn Software-Pakete weiterhin im alten Zeichensatz geliefert werden und eingespielt werden sollen, muss die Variable NLS_LANG beim Aufruf von SQLPlus auf dem Wert für den Zeichensatz stehen, in dem die Datei erzeugt wurde.

sqldeveloper_nls_settings

Nach dem evtl. erforderlichen Re-Import von Software sollten alle Datenbankobjekte unter besonderer Beachtung der korrekten NLS-Settings neu kompiliert werden – ebenso die Views und Materialized Views, die sich evtl vorher auf Tabellen mit BYTE-Semantik bezogen haben. Es empfiehlt sich eine abschließende Kontrolle in dba_tab_columns (CHAR_USED=C) und dba_plsql_object_settings (nls_length_semantics), ob alle Objekte in Char-Semantik vorliegen.

Wird Forms verwendet, muss auch auf dem Forms-Server die NLS-Konfiguration angepasst sowie alle Forms-Module neu übersetzt werden, da sich die Signatur in der Datenbank aller Wahrscheinlichkeit nach geändert hat.

Schnittstellen

Für dateibasierte Schnittstellen, inklusive XML, dass direkt aus der Datenbank erzeugt wird, muss geprüft werden, ob diese zukünftig in Unicode liefern dürfen. Ist dies nicht der Fall, muss die Ausgabe entsprechend konvertiert werden – zum Beispiel mit Hilfe der Funktionen utl_file.put_raw und utl_i18n.string_to_raw.

Sind Clients nicht Unicode-fähig, können sie weiterhin im alten Zeichensatz betrieben werden, wenn deren NLS-Konfiguration entsprechend eingestellt ist (z.B. auf WE8ISO8859P15). Bei diesem Mischbetrieb können sich allerdings Probleme beim Liefern von ISO8859-XML-Dateien ergeben. Bisher im Datenbestand vorhandene Inhalte sind 1:1 abbildbar, da AL32UTF8 eine Obermenge von WE8ISO8859P15 und ISO8859 ist. Nach der Unicode-Umstellung können allerdings auch Unicode-Zeichen eingegeben werden, die in ISO8859 nicht darstellbar sind. Diese Zeichen würden dann im XML durch das Ersetzungszeichen ersetzt werden. Im ungünstigsten Fall könnte also das Ersetzungszeichen „¿“ statt eines kyrillischen Zeichens ausgegeben werden.

Quellen

CERA-Datenbank am DKRZ gewinnt im Winter 2005 Award

,

2005TopTenWinners Die CERA-Datenbank für Klimaforschungsergebnisse am DKRZ Hamburg hat als mit 223 Terabyte größte Datenbank weltweit den internationalen  2005 Award der Winter Corporation in der Kategorie „Wissenschaft“ gewonnen. Nach dieser Untersuchung  steht die momentan größte Datenbank aller Teilnehmer des Awards in  Hamburg und läuft unter Linux und Oracle.

Diese Datenbank wurde in Ausgabe 03/05 des LINUX-MAGAZINs bereits vorgestellt.

Der Winter Corp 2005 Award wurde diesen Monat für die größten  Datenbanken weltweit vergeben. Der
Award für die größte Datenbank überhaupt ging an die Oracle-Datenbank  CERA der Max-Planck-Institutes am Deutschen Klimarechenzentrum DKRZ  in Hamburg.

Der Award wird in mehreren Kategorien vergeben (Datenbankgröße, Transaktionen, Durchsatzvolumen, OLTP oder Data-Warehouse). Die CERA-Datenbank ist die Gewinnerin in Punkto Datenbankgröße, gefolgt von der „Yahoo Search eMarketing“ Datenbank mit einer Größe von 100  Terabyte.

Die CERA-Datenbank läuft unter Linux und Oracle auf NEC TX-7 Itanium-64 Hardware. Sie wurde durch NEC, die Gruppe „Modelle &  Daten“ am Max-Planck-Institut? für Meteorologie in Hamburg (MPI) und Loopback.ORG it-consulting als Oracle-Berater 2003 installiert. Dabei kommt ein mit LDAP synchronisierter Federate Database Ansatz,  bestehend aus 5 Linux-Zellen, zum Einsatz.

In der CERA-Datenbank werden Ergebnisse der Klimaforschung
gespeichert und zum wissenschaftlichen Austausch bereitgehalten. Über
ein Web-Frontend (implementiert in Java mit dem Oracle Application
Server) haben die Nutzer direkten Zugriff auf den gesamten
Datenbestand. Die gespeicherten Daten sind größtenteils Ergebnisse
aus Klimamodellrechnungen in bestimmten Gitterauflösungen, die
Anhaltspunkte zur Entwicklung der globalen Erwärmung liefern sollen.

Presseerklärung der Winter Corp: http://www.wintercorp.com/PressReleases/ttp2005_pressrelease_091405.htm
Max-Planck-Institut: http://www.mpimet.mpg.de/

LinuxMagazin Artikel zur CERA-Datenbank

, , ,

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)