Multitenant – ein passendes Szenario
Wir wollen uns ein Szenario vorstellen mit einer brandneuen, fiktiven Webanwendung, die äußerst innovativ und ansprechend daherkommt und somit auf zahlreiche pozentielle User im Lande attraktiv wirkt. Viele könnten sich gut vorstellen, diese Anwendung zunächst einmal ausgiebig zu testen und sie dann auch intensiv zu nutzen. Allerdings würden bei einem Kauf hohe Kosten anfallen. Des Weiteren könnte dieses Programm einem hochfrequenten Update-Zyklus unterliegen, sodass es sinnvoll erscheint, die Anwendung vom Hersteller zu mieten.
Der Anbieter könnte sie auf seiner Infrastruktur zur Verfügung stellen, für regelmäßige Wartung und Updates sorgen und gewährleisten, dass unterschiedliche User sich bei gleichzeitiger Nutzung nicht ins Gehege kommen. Dieses Szenario wird Ihnen vielleicht bekannt vorkommen, denn es firmiert unter dem Stichwort PaaS (Program as a Service) im Cloud-Kontext und war eines der Hype- Themen der vergangenen Jahre. Ob Hype oder nicht, es ist und bleibt eine plausible und gerechtfertigte Anforderung an moderne Unternehmens-IT-Systeme, solche Anwen-dungen mit den beschriebenen Anforderungen zur Ver-fügung zu stellen.
Was hat Oracle im Middelware-Segment anzubieten?
Oracle, als Big Player im IT-Sektor, setzt als Middleware-Komponente bekanntermaßen sehr stark auf WebLogic Server (WLS), welcher Ende 2015 einen eher klein wirkenden Versionssprung von Version 12.1.3 auf 12.2.1 vollzogen hat. Dahinter verbirgt sich jedoch neben zahlreichen Technologieanpassungen auf neue Standards und der Eliminierung von alten Schnittstellen ein gänzlich neues Konzept im WLS Kontext, nämlich die Thematik „Partitionierung von Domains".
Bevor wir die Technik der Partitionierung besprechen, soll zunächst der Bogen zu PaaS gespannt werden. Hilfreich bei dieser Betrachtung ist die Frage: „Wie war PaaS mit den ‚alten' Mitteln des WLS zu bewerkstelligen?" Nun, es kommt darauf an, eine Anwendung als vielfache Kopien betreiben zu können, die sich untereinander nicht beeinflussen können. Bislang konnte man mehrere Domains definieren, in jeder Domain war die Anwendung zu deployen und so konnten mehrere Instanzen derselben Anwendung laufen. Als Beispiel für ein PaaS-Szenario können unterschiedliche Unternehmensbereiche wie Entwicklung, Test, Integrationstest, Performanztest, Produktion angesehen werden.
Alles hatte die Domain zu leisten!
Eine Domain stellte bislang die umfassende Organisationseinheit in Bezug auf Server, Applikationen, Sicherheitsbereiche etc. dar. Alles, was in WebLogic-Umgebungen eingerichtet, deployt, administriert, gemanagt wird, befindet sich also in solch einer Domain. Es ist damit der allumfassende Container, welcher zentral administrierbar ist und dem dadurch eine starke Bedeutung zukommt, insbesondere in großen, kritischen Systemlandschaften.
Partitionen ebnen einen eleganten Weg zu Multitenant
Ab der neuen WLS Version 12.2.1 ist eine Domain nicht mehr die einzig mögliche Gruppierungsart, in der zusammengehörige Ressourcen gebündelt werden können. Innerhalb einer Domain können eine oder mehrere Partitionen angelegt werden. Dabei handelt es sich dann um eine Art Unterbereiche, die für sich alleine Applikationen und Ressourcen beinhalten können.
Partitionen sind eigene Teilbereiche einer Domain, die auch als slices bezeichnet werden. Und so kann man sich das Prinzip auch vorstellen – als eine Segmentierung oder Aufteilung einer Domain. Partitionen stellen eine eigenständige Laufzeitumgebung mit isolierter, unabhängiger Administration dar. Auch das Bild als eine Art „Mikro-Container" passt als Anschauung für das neue Konzept ganz gut; Mikro-Container, von denen sich eine unbegrenzte Anzahl innerhalb einer Domain befinden kann (siehe Abbildung 1). Die Eigenständigkeit und die Isolation der Partitionen resultiert aus dem Sachverhalt, dass jeder Partition sowohl eine eigene Sicherheitszone (realm) als auch ein eigener Namensraum (JNDI) zugeordnet ist
Anwendungen brauchen ihr Revier
Wir betrachten nun eine Anforderung, die darin besteht, eine Anwendungsgruppe „Finanzen" und eine „Personal" den entsprechenden Bereichen eines Unternehmens als Dienst anzubieten. In WLS Version 12.1.3 und früher sah die typische Reaktion auf diese Anforderung so aus, dass für jeden Klienten (Unternehmensbereiche, die Dienste beanspruchen möchten) eine eigene Domäne zu spendieren war. Dadurch ähneln sich solche Domains sehr stark und adäquate Ansätze, um doppelte Administrationsarbeiten zu erleichtern und zu automatisieren konnten z. B. mittels Templates erreicht werden. Durch diese Schablonen lässt sich das Anlegen und Betreiben solcher gleichartigen Domains stark vereinfachen und vor allem weniger fehleranfällig gestalten.
Das resultiert in unserer Anwendung mit HR- und Finanzanteilen in separaten Domains für die unterschiedlichen Klienten, was zum Einsatz von Templates führt, die sich für HR- und Finanzanwendungen eigenen. Das könnte allerdings nicht ausreichend sein für solche Klienten, die sich an eine Domain anmelden und sowohl HR- als auch Finanzdienste nutzen wollen. Dafür müsste mit dem starren Konzept der Domains eine dritte Art geschaffen werden, was ein drittes Template erforderte.
Resource Groups und Resource Group Templates
Wir kommen nun zu wichtigen Konzepten, mittels derer sich die zuvor genannte Bereitstellung von Anwendungsteilen für bestimmte Zielgruppen in Partitionen bewerkstelligen lassen. Ein neues Konzept im Zusammenhang mit Multitenant ist der der Resource Group (RG). In einer RG werden „deploybare" Dinge zusammengefasst, wie Anwendungen, passende Treiber (JDBC, JMS), spezielle Bibliotheken o. Ä. Eine RG lässt sich einer Partition zuordnen, was auch die Frage zum Teil beantwortet, wie sich Partitionen nutzen lassen. Der große Vorteil einer RG besteht in der Gruppierung von zusammengehörigen Bestandteilen einer Anwendung (z. B. Finanzanwendung, siehe Abbildung 2).
Und wie können wir nun elegant lösen, was das beschriebene Szenario verlangt? Dass nämlich ein Klient sowohl HR- als auch Finanzdienste nutzen möchte? Für die Antwort benötigen wir noch ein weiteres Konstrukt, und zwar das der Resource Group Template (RGT, siehe Abbildung 3). Zur Vermeidung von Redundanzen bei der Verwendung von Ressourcen, wie z. B. Anwendungsteile oder Treiber, können diese in RGTs definiert werden. Eine Resource Group, die diese Bestandteile nutzen möchte, braucht lediglich eine Referenzierung auf das passende RGT vorzunehmen. Somit müssen keine doppelten Ressourcen vorgehalten werden (also zweimal die HR-Bestandteile als Kopien), sondern es ist nur zu gewährleisten, dass die Referenzierung in der RG korrekt ausgeführt wird, dass z. B. korrekte URLs für JDBC-Verbindungen eingetragen sind.
Virtual Target – Ziele wünschenswert und hochwillkommen
Es fehlt aber noch etwas Entscheidendes ... das spürt man förmlich. Der aufmerksame Leser könnte sich fragen: „Wie adressiere ich denn nun eine Partition? Gibt es eine spezifische URL? Oder wie wird es gemacht?" Genau da setzt das Konstrukt Virtual Target (VT) ein, das uns mit diesen Möglichkeiten versorgt. Ein VT hat als Bestandteile (teilweise optional):
• Host-Name und Port
• optional URI
• Network access point und Channel
• protokollspezifi sche Konfi gurationen
• Target cluster und Managed Servers
Das sind allesamt bekannte Begriffe im WLS-Kontext und sie erlauben es, Partitionen gebrauchsfertig zu gestalten. So gelangen Requests von Webanwendungen gemäß der Angaben Host-Name, Port, URI zum dedizierten Ziel, nämlich z. B. zu einem speziellen Servlet. Das steckt innerhalb einer deployten EAR, welche ihrerseits einer RG angehört, die einer Partition zugeordnet ist. Zugegeben etwas verwirrend, aber es erfüllt seinen Zweck: Requests von spezifi schen Mandanten zielsicher auf spezifische Partitionen zu leiten.
Scope – Ich sehe nichts. Siehst du etwas?
Mit diesen neuen Dingen wie RGs und RGTs ergeben sich neue Fragestellungen, wie z. B. die nach dem des Scope von deployten Artefakten; also: Wo sind diese sichtbar und damit nutzbar? Beim Deployment bekommen wir vier Möglichkeiten an Zielen, die gewählt werden können:
• Global: Die Ressource ist in einer nicht partitionierten Domain nutzbar.
• RGT: Die Ressource steht allen RGs zur Verfügung, die auf die RGT referenzieren.
• RG (Partition): Die Ressource kann nur innerhalb der Partition mit der RG genutzt werden.
• RG auf Domainlevel: innerhalb der RG nutzbar, allerdings auf Domainlevel.
Das heißt auch, dass Applikationen oder Bibliotheken nicht auf mehrere Partitionen verteilt sein können – sie sind isoliert in den klaren Grenzen der Partition, was aber genau zu dem gewünschten Verhalten führt, vielen Mandanten unabhängige und sichere Dienste und Anwendung zur Verfügung zu stellen. Und das heißt Multitenancy.
Fazit
Liebling Kreuzberg beherrschte die „menschliche" Mandantenfähigkeit perfekt. In der IT beherrschen wir diese nun dank der Partitionen im WebLogic Server 12.2.1 wesentlich eleganter als bisher. Man hat nun einen Überblick bekommen, wie die Partitionen aufgebaut sind und wie man zu unabhängigen, lauffähigen Einheiten kommen kann (durch Virtual Targets, denen Resource Groups zugeordnet sind), die uns die Fähigkeit verleihen, mehrere Mandanten unabhängig und sicher mit Anwendungen und Rechnerkapazität zu versorgen. Dabei profitiert man zugleich von einer größeren Dichte und besseren Ressourcennutzung, weil es nicht länger nötig ist, ganze Domains zu definieren, um isolierte Umgebungen im WLS zu erhalten.
In unserem Seminar „WebLogic Server Administration" bieten wir eine Einführung in diese spannende, neue Thematik an und man lernt, wie man WebLogic selbst einsetzen köann. Für Fragen und Unterstützung zu diesem Thema stehen wir selbstverständlich gerne zur Verfügung.
Links
[1] Oracle Weblogic Server Multitenant
https://docs.oracle.com/middleware/1221/wls/WLSMT/concepts.htm
[2] Oracle Fuion Middleware
https://docs.oracle.com/middleware/1221/wls/
Glossar
Multitenant
Mandantenfähigkeit; eine Anwendung oder ein System mit unterschiedlichen Klienten (Mandanten) so zur Verfügung stellen, dass diese unabhängig voneinander sind, sich nicht gegenseitig stören oder beeinflussen.