J and I and Me
2005-06-29
 
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:
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:
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/
 
Bookmark and Share
Comments: Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff