Zum Inhalt springen
  • Von: DOAG online
  • 23.05.2018

Die Arbeit mit der Exadata: Herausfordernd und spannend zugleich

Markus Böhmer und sein Kollege Sebastian Stamm von Arvato Systems werden bei den DOAG 2018 Exa & Middleware Days am 19. Juni in Frankfurt von ihrem aktuellen Projekt berichten. Geplant war dafür zunächst die Einbettung von Oracle Exadatas in eine non-CDB-Architektur, bis der Kunde für eine Überraschung sorgte. Die Migration in eine CDB-Architektur wurde daraufhin erforderlich. Was die Exadata für ihn ausmacht und wie das Projekt durch die neue Zielsetzung sogar noch an Reiz gewonnen hat, verrät uns Markus Böhmer im Interview.

Herr Böhmer, wie genau sieht Ihre Arbeit im Bereich Oracle aus?

Hier mache ich im Grunde alles. Von Kunden mit Single-Instance auf Standard-Edition über RACs bis zu dem Konstrukt, das wir in unserem Talk vorstellen. Dieses gefällt mir persönlich sehr gut und ist technisch wunderbar herausfordernd: Wir haben es hier mit zwei Exadatas mit RACs zu tun. Diese RACs sind dann mit Dataguard jeweils zu einer Primary und Standby Datenbank als Hochverfügbarkeitslösung verbunden.

Wie wirkt sich das auf die Zuständigkeitsverteilung aus?

Wir sind eine Abteilung mit zehn Mitarbeitern. Die einen haben ihren technischen Schwerpunkt auf RAC, Standby, Performance-Analyse... Bei uns macht jeder generell alles und muss jedem Kunden zur Seite stehen können. Aber man hat natürlich Schwerpunktkunden. Entsprechend arbeiten wir oft an denselben Projekten.

Was sind aus Ihrer Sicht die Stärken und die Schwächen von Exadata?

Die Schwächen sind wie immer bei Oracle die Lizenzkosten. Aber die Stärken einer Exadata sind ganz klar: Oracle liefert aus einem Haus Betriebssystem, Hardware und Datenbank und stimmt die Komponenten aufeinander ab. So hat die Exadata auch Datenbank-Software in ihren Storage Servern. Und diese übernehmen Rechenleistung, womit die eigentlichen Datenbankserver wieder entlastet werden. Eine Exadata ist ein wunderbares Konstrukt, das auf die Arbeit einer Oracle-Datenbank zugeschnitten ist. Das bringt natürlich mehr als wenn ich versuche mir etwas zusammenzubauen. Da fehlt mir einfach der Software-Teil. Und wenn ich einmal nicht weiterkomme, habe ich auch den Service aus einer Hand. Es findet kein Support-Ping Pong statt.

Das klingt gut! Ist denn während Ihrer Beschäftigung mit Exadata schon mal etwas schiefgelaufen?

Ich persönlich habe noch keine Exadata an die Grenze ihrer Auslastung gebracht. Ich weiß, dass ein Kunde in unserem Haus es wohl einmal geschafft hat, eine Exadata an ihre Auslastungsgrenze zu bringen, aber das war auf einen Fehler in der Anwendung zurückzuführen. Im Tagesbetrieb habe ich es dagegen noch nie erlebt, dass es Performanceprobleme gegeben hätte, die auf die Hardware oder auf die Datenbank-Software zurückzuführen gewesen wären. Wenn wir mal Performance-Probleme hatten, dann liefen sowohl die Hardware als auch die Datenbank reibungslos und es handelte sich um ein Applikationsproblem. Häufig ist es doch so: Wenn jemand sagt, ich brauche zwei Datensätze und durchsuche dafür vier Milliarden, dann ist nicht zu erwarten, dass da in 20 Millisekunden etwas zurückkommt. Es kommt auch immer darauf an, wie ich meine Abfragen gestalte, wie ich die Inhalte strukturiere. Ich persönlich kenne kein Gerät, das in Konkurrenz zur Exadata steht. Ich gebe zu, dass ich da die Oracle-Brille aufhabe. Aber was die Engineered Systems angeht, gibt es nichts Vergleichbares. Auch die ODA – der kleine Bruder der Exadatas – ist ein klasse Gerät.

Vielleicht verraten Sie uns ein wenig über die Infrastruktur des Kunden, um den es in Ihrem Talk gehen wird?

Geplant waren zwei Rechenzentren, die ein paar Kilometer auseinander liegen, für den Fall, dass schlimmstenfalls eines ausfällt. Wir haben jetzt knapp 25-30 km zwischen den beiden Rechenzentren. In jedem steht eine Exadata. In einem Rechenzentrum laufen die Datenbanken des Kunden als RACs. Angefangen haben wir unter der Voraussetzung, dass es sich um 10-15 Mandanten handelt. Für jeden Mandanten wollte der Kunde eine einzelne Datenbank. Zunächst haben wir uns für eine non-CDB-Architektur entschieden. Mit der überschaubaren Zahl an Datenbanken war das ja kein Problem. Dann hieß es allerdings, dass mehr Mandanten hinzukommen würden. Wir haben dem Kunden daraufhin Multitenant vorgeschlagen, und der Hinweis, dass die Verwaltung einfacher wird und das Hinzufügen von Mandanten schneller geht, diente als schlagkräftiges Argument. Mehr zu den genauen Umständen verraten wir dann in unserem Talk vor Ort…

In welchem Stadium befindet sich das Projekt aktuell?

Aktuell befinden wir uns in der Migrationsphase auf die PDBs. Auf der Ausfallseite haben wir ebenfalls für das notwendige Sicherheitsnetz gesorgt, die Container-Datenbanken haben im Ausfallrechenzentrum jeweils noch eine Standby, so dass wir im Fall eines Ausfalls auf der Datenbank-Seite sicher sind. Bei den Applikationsservern handelt es sich um Tomcats mit für den Kunden geschriebenen Applikationen. Diese sind virtualisiert und ebenfalls in das Ausfallkonzept eingebettet.

Das klingt so, als sei das Projekt schon so gut wie abgeschlossen.

Mit dem Abschluss rechnen wir in den nächsten Wochen. Aber alle Anpassungen, die jetzt noch kommen, sind kleineren Kalibers und eher Politur. Wir stehen natürlich auch mit den Entwicklern der Applikationen in Kontakt. Da im Moment zwar ein Testbetrieb läuft, aber noch nichts wirklich produktiv ist, kommen da immer wieder Anfragen sowohl von uns als auch von den Entwicklern.

Ist dies das erste Projekt, bei dessen Umsetzung Sie sich einen neuen Plan zurechtlegen mussten?

Für uns zwei war es ohnehin das erste Projekt in dieser Größe. Ein Kunde mit so vielen Mandanten, der gleichzeitig einen solchen Schwerpunkt auf Ausfallsicherheit legt und der sagt, dass ihm ein halber Kilometer Entfernung zwischen den Rechenzentren nicht genügt, sondern mehrere Kilometer dazwischen liegen sollen, ist schon eine Herausforderung. Das will organisiert sein. Da brauche ich ein bestimmtes Netzwerk zwischen den beiden Rechenzentren, ich brauche auf beiden Seiten Storage, Exadatas, Sicherungsmöglichkeiten… Mit unserem Talk auf dem Exaday möchten wir Fachleute erreichen, die in einer ähnlichen Situation sind. Wir haben natürlich einige Erfahrungen gemacht und festgestellt: Okay, dies und jenes ist doch nicht so günstig, da müssen wir noch ein wenig umstellen. Ich bin sehr gespannt darauf, die Teilnehmer auf die Reise mitzunehmen und Feedback zu bekommen.

Würden Sie sagen, dass sich Ihre Erwartungen erfüllt haben?

Im Moment setzen wir Achtel-Racks ein und haben im Prinzip die geringste Ausbaustufe der Exadata – viel hat sie also nicht zu tun. Wir sind ja auch noch nicht im Produktivbetrieb. Allerdings dürfte die Exadata auch später nicht ausgelastet sein. Und wenn es irgendwann dazu kommt, dass man extra Power braucht, bauen wir sie eben weiter aus und machen aus dem Achtel-Rack ein Viertel-Rack. Allein die Tatsache, dass wir die Zeit gefunden haben, um unsere Datenbankstruktur von Single-Instanzen, die ja von Oracle ohnehin deprecated sind, auf Multitenant-Datenbanken zu migrieren, zeigt, dass wir Luft hatten. Natürlich war das mit einem gewissen Aufwand verbunden. Aber alles, was wir jetzt an Anstrengung mehr leisten, haben wir hinterher an Arbeit weniger. Für die Zukunft gehen wir sogar davon aus, dass die Multitenant-Architektur noch performanter sein wird als die Single-Instanzen, da bei Multitenant durch das Container-Konstrukt Ressourcen geteilt werden. Ich habe nicht so einen riesen Resourcen-Overhead. Prozesse und Speicher werden von der CDB allokiert und von den Pluggables gemeinsam genutzt. Gerade dadurch sollte ein positiver Effekt auf die Performance erzielt werden.

Sie möchten mehr über Middleware- und Engineered Systems erfahren? Dann buchen Sie Ihr Ticket für die DOAG 2018 Exa- und Middleware Days. Als DOAG-Mitglied erhalten Sie 30 Prozent Nachlass auf reguläre Ticketpreise!