In der Welt von "Cloud-Ready-Applikationen" und skalierbaren Lösungen spielt ein Begriff kaum mehr eine Rolle, der früher von großer Wichtigkeit war: Hochverfügbarkeit. Moderne Anwendungen, besonders wenn sie den Prinzipien der "Cloud-Ready-Architektur" folgen, sind üblicherweise implizit redundant: Sie sind in viele Mikrokomponenten gespalten und von jeder davon kann es innerhalb der Applikation beliebig viele Instanzen geben. Das Prinzip des Skalierens in die Breite bietet eben nicht nur den Vorteil, quasi beliebig viele Ressourcen nachzurüsten falls nötig. Es sorgt implizit auch dafür, dass der Ausfall einzelner Komponenten nicht ins Gewicht fällt, weil die verbliebenen Instanzen desselben Diensts die Aufgaben der ausgefallenen Instanz übernehmen. So hat sich das Konzept an verschiedenen Stellen durchgesetzt und zum Teil entstehen sogar Lösungen, um konventionelle Applikationen um Cluster-Fähigkeiten zu erweitern. Erinnert sei etwa an Galera für MariaDB und MySQL, das beide um einen Modus für den Multi-Master-Betrieb erweitert.
Andere Anwendungen beherrschen das Skalieren in die Breite hingegen nicht. Will der Admin für diese Dienste Hochverfügbarkeit implementieren, steht er vor einem Problem: Welche Instanz kümmert sich darum, dass die Aufgaben ausgefallener Instanzen auf andere Instanzen verteilt werden? Spätestens wenn der IT-Verantwortliche sich diese Frage stellt, ist er beim Thema Hochverfügbarkeits-Cluster angekommen – und damit implizit natürlich auch bei Cluster-Managern.
Aus Cloudsicht wirken Cluster-Manager wie aus der Zeit gefallen: Sie legen sich in einem Verbund aus mehreren Servern wie eine Art Wachhund auf die Lauer und prüfen regelmäßig, ob alles wie gewünscht funktioniert. Fällt dann beispielsweise ein Server aus, initiieren sie einen so genannten Failover: Dabei startet der Clustermanager die Dienste, die auf dem nun nicht mehr verfügbaren Knoten gelaufen sind, auf einem anderen
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.