Clustering mit Java

Dieser Vortrag wurde von Sun Research und zwar von Grzegorz Czajkowski und Mick Jordan bestritten. Mick Jordan war mir irgendwie bekannt und einmal Googeln ergab dann, dass ich auch tatsächlich recht hatte: Er hatte an dem Thema orthogonale Persistenz gearbeitet, was auch an der Uni Hamburg, wo ich studiert habe, ein Thema war. Der macht also nicht erst seit gestern coole Forschung...

Das ganze ging damit los, zu Definieren, was ein Cluster ist. Es kam ungefähr raus: Ein Cluster ist ein System aus mehreren Rechnern. Nun stellt sich die Frage, was in der Java Welt ein System ist. Hier gibt es verschiedene Antworten:

• Ein System ist eine JVM
• Ein System ist eine Java EE Ablaufumgebung
• Ein System ist ein Subset einer Java EE Ablaufumgebung (Servlet Container, EJB Container, JNDI)
• Ein System wird durch die Applikation festgelegt. Das ist zum Beispiel bei JGroups oder JINI der Fall.

Es ging dann damit weiter, dass dargestellt wurde, dass Research auf die JVM guckt, während die Produkte auf Java EE Clustering schauen. Böse Zungen behaupten nun natürlich, dass Research grundsätzlich nichts praxisrelevantes macht. Aber ganz ist es nicht. Die Idee ein einziges System Image eines ganzen Clusters zu haben ist zum Beispiel für High Performance Computing durchaus sinnvoll, bei dem System Failure auch recht egal ist, was bei Java EE natürlich eine extrem wichtige Motivation für Cluster ist.

Es gab dann eine Übersicht existierender Research Systeme nach "A Distributed Runtime for Java: Yesterday and Today" (Michael Factor, Assaf Schuster, Konstantin Shagin, IPDPS 2004). Folgende Arten von Systemen wurden unterschieden:

• Cluster Aware JVMs
• Compileren auf ein Cluster-fähiges System (z.B. Distributed Shared Memory)
• Standard JVMs und modifizierter Source- oder Bytecode für die Plattform

Letzteres wird heute am meisten gemacht, da Änderungen an der JVM nicht mehr wirklich trivial sind.

Zusammenfassend ist also das Problem, dass zwischen Produkten und Forschung eine Lücke gibt und Produkte machen daher ad-hoc Lösungen.

Die Frage, die sich natürlich stellt, ist, ob der Ansatz eines einzigen System Images wirklich sinnvoll ist. Außerdem gibt es wohl kaum Angaben über die Performance der existierenden Ansätze und Failure Resistance ist wahrscheinlich ein Problem. Also?

Isolates

Der neue Ansatz sind Isolates,, die in JSR 121 gerade standardisiert werden. Dieser JSR läuft seit 2000, steht aber jetzt im 2nd Public Review und wird wohl wirklich bald abgeschlossen.

Die Idee ist, eine Art eigenen Java Prozess mit eigenem Main starten zu können. Dies kann dann ein eigener Betriebssystem Prozess sein, der potentiell auf einem anderen Rechner läuft. Im Gegensatz zu Threads kann man keine Daten gemeinsam benutzen, sondern muss sie explizit kopieren. Dieses Thema hatte ich auf der JAOO letztes Jahr auch schon mal gesehen und als sehr cool empfunden. Allerdings war es für mich zu dem Zeitpunkt eher eine Möglichkeit, innerhalb eines Application Servers zum Beispiel die JMS Implementierung als eigenen Betriebssystem Prozess zu haben, um ihn dann getrennt mit Ressourcen und Prioritäten zu versorgen. Das ist halt ein Problem, dass man bei Java im Moment hat: Eine JVM ist ein Prozess und Steuerung durch das Betriebssystem sind kaum sinnvoll machbar, weil man nur den ganzen Prozess verwalten kann. Das ist schade, denn genau in diesem Bereich sind Betriebssysteme eigentlich gut...

Cluster und Isolates

Aber zurück zum Thema. Die Idee ist nun:
"A sea if isolates on top of a cluster"

Damit kann man einen Cluster gut abbilden. Die nächste Idee ist ein Aggregate. Dies ist die Menge von Isolates auf einem bestimmten Knoten. Man kann nun Isolates und Aggregates remote steuern und starten.

Das wirklich interessante und für mich neue war dann das Administrieren der Aggregates. Man kann z.B. die verfügbare CPU, Speicher und Netz konfigureiern mit einer Resource Management API. Die kann Resource Domains definieren, den man Isolates zuordnen kann. Dort gibt es dann Warnungen oder echte Beschränkungen, wenn ein Limit überschritten wird.

Das ganze ist recht mächtig. Man kann globale Regeln definieren oder lokale Regeln, also solche, die nur ein Isolate betreffen. Das ganze ist programmierbar und damit sowohl flexibel als auch gefährlich. Ich habe dann noch nachgefragt, ob die globale Sicht über den Cluster nicht nur eingeschränkt sinnvoll ist, weil so ein globaler Zustand eventuell sehr teuer zu ermitteln ist. Die Antwort war, dass er eben nur ermittelt wird, wenn der Code tatsächlich ausgeführt wird und man muss halt wissen, was man tut.

Fazit

Dieses Vorhaben ist extrem wichtig, um im Enterprise in Zukunft noch bessere Java Unterstützung zu haben. Hier - wie auch schon bei dem BEA Vortrag - wird deutlich, dass die JVM immer mehr Ähnlichkeit mit einem Betriebssystem bekommen. Die Frage hier ist allerdings, ob und wann wirklich JVMs kommen, die die Features so umsetzten, wie man das bei Enterprise Anwendungen braucht. Auf jeden Fall bin ich mir unsicher, ob im .NET Umfeld ähnliche Dinge passsieren...

Links

http://research.sun.com/projects/barcelona/  ¶ 16:12