Das Motto «You make it, we break it» möchte Eric Grancher nicht ganz ernstgenommen wissen. Aber es treffe manchmal durchaus zu, sagt der Datenbank-Chef des Forschungszentrums Cern im Interview mit Computerworld. Mehrere IT-Firmen stellen den Wissenschaftlern in Genf die neusten Produkte zur Verfügung, damit die Hard- und Software unter den Extrembedingungen getestet werden kann. Die Hardware stammt zum Beispiel von Intel oder Siemens. Die Datenbanken unter anderem von Oracle – Granchers Spezialgebiet. So kennt er dann auch die Grenzen der neusten Cloud-Lösungen.

Eric Grancher: Ich bin 1996 zum Cern gekommen, um dort mit Oracle-Datenbanken zu arbeiten. Das Cern war schon ein grosser Kunde von Oracle. Sie sind mit Version 2.3 gestartet, was in den frühen 1980er Jahren gewesen sein muss. Damals befand sich gerade der Elektronen-Positronen-Beschleuniger im Bau – der Vorläufer des heutigen Teilchenbeschleunigers. Die Kollegen suchten ein System für die Kontrolle der Maschinen und analysierten die auf dem Markt befindlichen Technologien. Sie kamen zu dem Ergebnis, dass die Oracle-Datenbank die richtige Lösung war. Das war also der Anfang. Seitdem verwenden wir Oracle-Technologie, viele der Datenbanklösungen, aber nicht nur.

Grancher: Die Datenbank ist heute wie damals ein Element des Kontrollsystems des Teilchenbeschleunigers. Mittlerweile setzen wir zusätzlich eine Datenbank für die Experimente ein. Die beiden Systeme arbeiten aber unabhängig voneinander: Eine Datenbank sammelt Messwerte zum Beispiel aus dem Tunnel, in dem die Teilchen beschleunigt werden. Die Experimente sind dann diejenigen Orte, an denen die Teilchen miteinander kollidieren. Dort werden natürlich ebenfalls Messungen vorgenommen, die eine separate Datenbank speichert.

Insbesondere die Messungen während der Experimente stellen eine grosse Herausforderung dar: Einerseits ist die Anlage sehr komplex und erfordert Dutzende von Ingenieure, die anhand der Aufzeichnungen des Kontrollsystems die Telemetrie kontinuierlich überwachen. In dem System laufen ausserdem die Messwerte der Gas-, Luft- und Alarmanlagen zusammen. Weiter zeichnen die Kontrollsysteme alle Zustände der riesigen Magneten auf, die an den Orten circa 100 Meter unter der Erdoberfläche installiert sind. Die Magneten werden ihrerseits mit Kühltechnik und weiterer elektronischer Ausrüstung versorgt, die selbstverständlich ebenfalls kontrolliert werden müssen.

Grancher: Korrekt. Aber ich setze noch einen drauf: Messungen finden 150'000 Mal pro Sekunde statt. An jedem Tag des Jahres. Denn wir müssen jederzeit informiert sein, in welchem Zustand die Anlage sich befindet und wo wir allenfalls Verbesserungen vornehmen müssen.

Für die Datenbanken bedeutet das: Sie dienen einerseits für traditionelle Anforderungen wie dem Management der IT-Infrastruktur mit Computing-Ressourcen und Speicher. Andererseits erfüllen sie einen «Business-Zweck», wenn man es so nennen will. Denn sie übernehmen genau so die Administration der Ingenieursarbeiten, steuern Change Requests und müssen bei neuen Experimente-Designs nachgeführt werden.

Grancher: Das System ist tatsächlich hoch komplex und hat sich natürlich über die Jahre immer weiter entwickelt. Ein Teil davon ist im Rahmen des Cern «openlab» aufgebaut worden. Diese Zusammenarbeit mit Industriepartnern wie Intel, Oracle und zum Beispiel Siemens. Das Kontrollsystem für den Teilchenbeschleuniger basiert auf einer Siemens-Industrielösung, bei der Cern mitgeholfen hat, die Skalierbarkeit für riesige Datenmengen sicherzustellen. Dafür haben wir hier einen idealen Anwendungsfall. Die übrigen Komponenten – und es gibt viele weitere Bestandteile – sind über das Netzwerk mit den Datenbanken verbunden. Alles muss auf Höchstleistung ausgelegt sein, die Anlagen, die Schnittstellen, die Netze und natürlich auch die dahinterliegende IT-Infrastruktur mit der Datenbank.

Grancher: Ja, haben wir ein adäquates Lizenzpaket von Oracle, das uns die hohe Ausnutzung erlaubt. Allerdings nutzt Cern natürlich nicht ausschliesslich kommerzielle Software. Wenn die kommerziellen Produkte einen Vorteil für das Kerngeschäft bieten, bezahlen wir für den zusätzlichen Nutzen. Im Datenbank-Bereich ist das der Fall bei Oracle. Abseits davon setzen wir aber auch andere Lösungen ein, abhängig davon, ob ein Produkt wie MySQL oder Postgres den Zweck erfüllt und ein Geschäftsproblem löst.

Grancher: Die Idee des openlabs ist, dass wir gemeinsam mit Partnern aus der Industrie an einigen wirklich herausfordernden Projekten arbeiten. Die Arbeiten in den Cern-Laboratorien zeichnen sich durch sehr hohe Komplexität aus, genauso wie durch einen riesigen Bedarf an skalierbaren Ressourcen. Von welchen Dimensionen wir hier sprechen, habe ich eben angedeutet. Durch die Kooperation mit Anbietern können wir leichter unsere Probleme lösen. Die Hersteller können im Gegenzug Erfahrungen sammeln mit ihren Produkten unter Extrembedingungen – hohe Last und die Notwendigkeit zur Integration mit anderen Systemen, die es im kommerziellen Bereich ebenfalls gibt. Diese «Stresstests» helfen den Partnern bei der Weiterentwicklung ihrer Produkte, nach dem nicht ganz ernst gemeinten Motto: «You make it, we break it». Die Anwendungen im Cern inspirieren die Partner auch zum Programmieren vollkommen neuer Lösungen, die sie bei uns testen und dann vermarkten können. Gemeinsam mit Intel und Siemens gehört Oracle zu den ersten Mitgliedern des Cern openlab.

Grancher: Nur in Einzelfällen war das Cern an der Entwicklung von neuen Produkten beteiligt. Teilweise bekamen wir neue Funktionen sehr früh zu sehen und konnten sie in unseren Umgebungen testen. Anhand unserer Rückmeldung wurden dann Fehler identifiziert und Verbesserungen eingepflegt. Ein Beispiel ist Oracle RAC (Real Application Clusters), eine Clustering-Lösung für Datenbanken. Ein anderes ist Oracle ASM (Automatic Storage Management) für das Verwalten von verteilten Speicherressourcen.

Grancher: An der Entwicklung der Autonomous Database waren wir nicht beteiligt. Aber im Herbst vergangenen Jahres haben wir auf der Grundlage der Technologie eine Anwendung realisiert: Am «Open Day» besuchen rund 75'000 Menschen die verschiedenen Einrichtungen des Cern. An dem Tag bieten wir Demonstrationen, Führungen sowie Vorträge für Gross und Klein an.

In den Vorjahren wurde die Koordination dieses Anlasses mit verschiedenen Tools gemanaged. Eine Anwendung gab es für die Registrierung und Verteilung der Besucher, eine zweite regelte den Zutritt der Interessierten zu den Laboratorien.

Grancher: So weit ging die Anwendung dann auch nicht [schmunzelt]. Die Planung war recht kurzfristig, so dass den Kollegen nicht viel Zeit blieb für die Programmierung. Sie entschieden sich für die Cloud, damit die Anwendung skalierbar ist für die grosse Zahl der Besucher. Sie sollte bei geringer Last genau so performant funktionieren wie bei vielen Zugriffen zur gleichen Zeit, wenn sich die Interessenten beispielsweise vor dem Anlass noch kurzfristig registrieren.

Für das Frontend mit einer Java-Applikation in Docker-Containern wurden ebenfalls Cloud-Instanzen gebucht, so dass es ebenfalls skalierbar war. Alle Applikationen wurden im Oracle-Rechenzentrum in Frankfurt installiert.

Unter dem Strich mussten wir so nur die Zeit für die Entwicklung der Applikationen aufbringen. Der Aufwand für das Deployment von Datenbanken, Patches und Updates blieb uns erspart. Für jemanden wie mich, der typischerweise On-Premises installiert, war das auch eine neue – und gute – Erfahrung.

Grancher: Bis anhin gibt es beim Cern keinen Plan, alle Datenbanken im grossen Stil in Autonomous Databases zu migrieren. Der einfache Grund ist, dass die meisten unserer Workloads in einem internen Netzwerk arbeiten und nicht im öffentlichen Internet. Denn die Forschungsdaten sind sehr sensibel.
Wenn aber in Zukunft ein Ingenieur auf uns zukommt, der eine neue Applikation benötigt, kann die Autonomous Database durchaus eine Alternative sein. Während wir bis anhin alle Software in unserem Rechenzentrum installiert haben, können wir neu auch die Cloud erwägen – je nach Anwendungsfall, Datensicherheitsvorschriften und Leistungsressourcen.

Grancher: Nicht unbedingt. Bei der Wahl des Rechenzentrums haben wir nach meinem Wissen keine rechtlichen Einschränkungen – wie sie etwa Banken oder die öffentlichen Verwaltungen haben. Auch ist die Besucherregistrierung nicht sicherheitskritisch in irgendeiner Hinsicht.

Grancher: Der Hauptgrund war die kurze Latenzzeit. Bemerkenswert ist auch noch, dass wir zwar eine kürzere Latenz bei dem Rechenzentrum in Zürich haben, aber eine höhere Bandbreite zu dem Rechenzentrum in Frankfurt. Der Grund ist, dass es in Oracles Rechenzentrum in Frankfurt eine Verbindung zum europäischen Forschungsnetzwerk «Géant» gibt. Über «Géant» hat Cern mindestens eine 10-Gigabit-Verbindung in die Oracle Cloud. Aber natürlich nicht nur wir, sondern auch alle anderen europäischen Forschungseinrichtungen.

Grancher: Aus Sicherheitsgründen kann ich heute nicht einmal von meinem Laptop aus eine Verbindung zu den Kontrollsystemen herstellen. Die Systeme sind in einem komplett abgeschotteten Netzwerk installiert. Das gleiche gilt für das Experimental-Netzwerk in den Tunneln 100 Meter unterhalb der Erde. Beide werden wir nicht verändern. Und sie sind für unsere Zwecke adäquat dimensioniert, so dass eine Skalierbarkeit durch Cloud-Ressourcen keinen Gewinn bedeuten würde.

Bei anderen Applikationen kann die Cloud aber durchaus eine Option sein. Denn wenn wir keine Ressourcen für die Bereitstellung von Datenbanken und Servern aufwenden müssen, sondern die Leistungen per Mausklick aus der Cloud beziehen können, kann sich eine neue Anwendung schnell rechnen. Weiter hat Oracle in der Cloud-Umgebung einige Automatisierungsroutinen implementiert, die On-Premises nicht verfügbar sind. Das Autonomous Transaction Processing (ATP) ist ein Beispiel, für das es On-Premises kein Äquivalent gibt. Diese Routinen ersparen uns und allen anderen Anwendern möglicherweise viel Arbeit. Sie sind dann gute Argumente, eine Applikation in der Cloud zu realisieren.