Lastverteilung und Failover für entfernte EJB Clients in EAP6 und JBoss AS 7

In den letzten Posts dieser Serie über die Clusterfähigkeiten der JBoss EAP6 und des AS7 ging es um grundlegende Konzepte, Clusterknoten im Domain-Mode verwalten, und skalierbare Hochverfügbarkeitscluster. In diesem Post wird es um den Zugriff von entfernten EJB Clients auf Clustersysteme gehen. Wir werden erklären, wie ein entfernter Java Client transparent auf EJB Komponenten zugreifen kann und dabei sowohl clientseitiges Failover als auch clientseitige Lastverteilung realisiert wird. Darüber hinaus werden wir kurz darstellen wie EJB Komponenten serverseitig konfiguriert werden müssen.

Weiterlesen

Skalierbare Hochverfügbarkeitscluster mit JBoss AS 7 und EAP 6

Übersicht

Im kürzlich erschienenen Blog-Post Clustering im JBoss AS 7/EAP 6 haben wir gezeigt, wie in der neuen EAP 6 und im JBoss AS 7 einfaches Clustering verwendet werden kann. Die EAP 6 ist im Grunde genommen ein AS 7 mit offiziellem RedHat-Support. Der Cluster, den wir in diesem Post verwendet haben, war relativ klein und schlicht. Dieser Post behandelt deutlich komplexere Cluster-Strukturen, wie man diese baut und wie man den neuen Domain-Mode für Cluster verwendet. Es gibt viele Wege größere JBoss Cluster-Umgebungen zu bauen und zu verwalten. Wir werden zwei Möglichkeiten zeigen, um das zu erreichen: Die eine verwendet Separierungstechniken, die auch für ältere JBoss-Versionen verwendet werden können und die andere nutzt ein Infinispan-Feature, das Distribution genannt wird.

Skalierbarkeit vs. Verfügbarkeit

Die größte Schwierigkeit beim Bauen eines Clusters ist es, sowohl hohe Verfügbarkeit als auch Skalierbarkeit zu erreichen.

Verfügbarkeit für einen Cluster bedeutet: Wenn ein Knoten ausfällt werden alle Sessions dieses Knotens nahtlos von einem anderen Knoten übernommen. Dies kann durch Session-Replikation erreicht werden. Session-Replikation ist vorkonfiguriert und aktiviert im ha Profil in der Datei domain.xml. Flache Replikation bedeutet, dass alle Sessions auf alle anderen Knoten kopiert werden: Bei vier Knoten mit je 1 GB Speicher kann der Cluster nur 1 GB Speicher nutzen, weil alle Knoten jeweils Kopien der anderen Knoten speichern. Der Cluster wird also nicht 4 * 1 GB = 4 GB Speicher haben. Wenn man weitere Knoten hinzufügt erhält man nicht mehr Speicher, man verliert sogar Speicher durch den anfallenden Overhead der Replikation. Allerdings erhält man eine höhere Verfügbarkeit und noch wichtiger: mehr Netzwerkverkehr ebenfalls verursacht durch den Overhead der Replikation (alle Änderungen müssen auf alle anderen Knoten verteilt werden). Diese Cluster-Topologie nennen wir vollständige Replikation.
Weiterlesen