Manager, setzt auf Kotlin! Über Ängste und geniale Vorteile.

Jedes einzelne Mal, wo ich Kotlin statt Java eingesetzt habe, habe ich es genossen. Kein einziges Mal habe ich es bereut. Trotzdem stoße ich immer wieder auf Ängste und Hemmungen, Kotlin einzusetzen – sowohl bei Managern als auch bei Entwicklern.

In diesem Blogpost möchte ich Ihre Ängste als Manager in Bezug auf Kotlin besprechen. Gleichermaßen möchte ich darauf eingehen, welche Vorteile Kotlin Ihnen bringt. Es gibt außerdem einen ähnlichen Blogpost für Entwickler (in Englisch), der etwas mehr in technische Details einsteigt.

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

Clustering im JBoss AS 7 und EAP 6

Übersicht

Die Möglichkeit verschiedene Server zu einem Cluster zu kombinieren, der seine internen Server vor den Clients verbirgt und eine virtuelle Plattform für eine Anwendung zur Verfügung stellt, ist für Geschäftsanwendungen wichtig. Clustering wird verwendet, um u. a. Folgendes zu erreichen:

  • Hohe Skalierbarkeit, indem dem Cluster günstige Rechnerressourcen auf Nachfrage hinzugefügt werden, oder
  • Hohe Verfügbarkeit, indem ein transparentes Failover verwendet wird, welches Ausfälle der internen Server verbirgt.

Normalerweise beschränken sich hohe Skalierbarkeit und hohe Verfügbarkeit gegenseitig. Es ist aber auch möglich, beides zu erreichen. So kann der JBoss Application Server konfiguriert werden, um beide Eigenschaften zu unterstützen.

Dieser Post ist der erste einer Blogpostserie über Clustering mit dem JBoss AS 7. Hier setzen wir den Fokus auf die grundlegenden Konzepte hinter JBoss AS 7 Clustering und zeigen, wie man eine grundlegende geclusterte Umgebung mit einer einfachen Java EE-Anwendung aufsetzt.

In dieser Serie konzentrieren wir uns auf JBoss AS 7 beziehungsweise die EAP 6, welche die von Red Hat unterstützte Version des JBoss Application Servers ist. Zukünftige Posts werden bestimmte Subsysteme des JBoss AS behandeln, wie HornetQ oder Infinispan.

Weiterlesen