Diskussion:Shared Nothing Architecture

Der Artikel fokussiert sich zu sehr auf Datenbanken und Statusinformationen.

Cluster-Zoo Überblick

Unterscheidung nach Aufgabenstellung:

• Verfügbarkeits-Cluster (höhere Verfügbarkeit als ein einzelnes System)
• Performance-Cluster (höhere Performance als ein einzelnes System)

Unterscheidung nach Architektur:

• Shared-Ressource-Cluster

Mindestens eine (Hardware-)Ressource, häufig der Massenspeicher, ist von allen Knoten des Clusters erreichbar. Der Cluster-Manager regelt welcher Knoten wann "Eigentümer" dieser gemeinsam genutzten Ressource ist. Sie gehört zu jedem Zeitpunkt exakt einem Knoten im Cluster. Daher bietet diese Architektur keine Möglichkeit eine höhere Performance als ein einzelnes System zu erreichen. Wenn der aktuelle Eigentümer der Ressource ausfällt, kann ein anderer Knoten Eigentümer der Ressource werden, und sie somit Hochverfügbar machen. Der Cluster-Manager ist oft Teil des Betriebssystems, oder arbeitet eng mit dem Betriebssystem zusammen, da Hardware-Ressourcen verwaltet werde müssen.

Beispiel: Hochverfügbare Storagesysteme

Bedingungen:

• Mindestens zwei Knoten. Da die gemeinsam genutzten Ressource Mitglied des Quorums ist, können auch mit nur zwei Knoten vom Quorum Mehrheitsentscheidungen getroffen werden.
• Die gemeinsam genutzte Ressource ist in sich auch Hochverfügbar. (z.B. Massenspeicher besteht aus einem RAID-Verbund)
• Ein ggf. erforderlicher Server-Prozess muß nicht für den Cluster-Betrieb ausgelegt sein, da er immer nur auf einem Knoten, dem aktuellen "Eigentümer" der Ressource, ausgeführt wird.

• Shared-Nothing-Cluster

Es gibt keine gemeinsam genutzten und somit limitierend wirkende (Hardware-)Ressourcen. Daher kann die Leistung aller Knoten, zwecks Leistungssteigerung, kombiniert werden. Frühe Formen dieser Architektur waren immer "read-only", da die Daten auf den Knoten durch Hilfsprozesse von zentraler Stelle aus (ausserhalb des Clusters) synchronisiert werden. Ein Cluster-Manager ist nicht zwingend erforderlich, da keine Entscheidungen zu treffen sind. Meist ist ein vorgeschalteter Loadbalancer erforderlich, um die Anfragen über alle (laufenden) Knoten des Clusters hinweg zu verteilen, und somit die Leistung der Knoten zu kombinieren. Da alle Knoten eines Clusters über identische Kopien der Daten verfügen, ist bei einem Knotenausfall die Verfügbarkeit dieser Daten weiterhin gegeben.

Beispiel: Webserver die den statischen Anteil von Webseiten ausliefern

Bedingungen:

• Keine

Moderne Formen heben die "read-only" Einschränkung auf. Der Cluster-Manager ist Bestandteil des Server-Prozesses, und kümmert sich um die Synchronisierung der Daten über die Knoten des Clusters hinweg. Es sind Cluster mit Knoten die unterschiedliche Betriebssysteme haben vorstellbar, da die Cluster-Funktionalität, völlig unabhängig vom Betriebssystem, durch den Server-Prozess bereitgestellt wird. Auch hier ist häufig ein vorgeschalteter Loadbalancer erforderlich um die Leistung der Knoten zu kombinieren. Ausnahmen sind Lösungen die eigene Clients verwenden, die selbsttätig mit dem Server-Prozess kommunizieren, um den optimalen Knoten für ihr Anliegen zu ermitteln, oder zumindest eine Liste existierender Knoten zu erhalten. Ob die Daten Hochverfügbar sind oder nicht (Faktisch ob eintreffende Daten auf mehr als einem Knoten gespeichert werden oder nicht), kann oft über Konfigurationsparameter festgelegt werden.

Beispiel: Apache Kafka

Bedingungen:

• Mindestens drei Knoten, damit vom Quorum Mehrheitsentscheidungen getroffen werden können.
• Der Server-Prozess bringt einen Cluster-Manager mit, daher bezeichnet man solche Lösungen auch schon mal als "Applikations-Cluster"

Die Diskussionen: "Es gibt einige Diskussionen darüber, ob eine Webanwendung mit verschiedenen, unabhängigen Netzwerkrechnern, aber einer einzigen, zentralen Datenbank, z. B. in Form eines Computerclusters als ein Shared-Nothing-System betrachtet werden soll."

Das beschriebene System hat keine gemeinsame Aufgabenstellung, sonder zwei unabhängige Aufgabenstellungen (einerseits Datenbank, andererseits Webanwendung). Wenn die Diskussion nur um den "Webanwendungsteil" geht, dann ist es ganz klar kein "shared-nothing" Cluster. Denn die Webanwendung wird, egal wieviele Knoten ich hinzufüge, durch die maximale Leistung der Datenbank, als gemeinsam genutzte Ressource, stets in ihrer maximalen Leistung begrenzt. Nun mag man anführen, das die Datenbank als "shared-ressource" keinem Webanwendungs-Knoten zu irgendeinem Zeitpunkt exklusiv zugeordnet wird. Dies ist aber nur scheinbar so. Man stelle sich einfach alte Hardware, mit einem einzelnen Kern als Datenbank-Server vor, der eben zu jedem Zeitpunkt immer nur eine einzelne Anfrage abarbeiten kann. Schon hat man exakt das Verhalten eines klassischen shared-ressource Clusters. Bei heutigen mehrkern Systemen handelt es sich eben nicht um eine, sondern um mehrere Ressourcen (eine Ressource pro Kern) die sich die Anwendungsserver teilen können.

Quelle: Meine Diplomarbeit (zu Alt um Online verfügbar zu sein), zwei Jahrzehnte praktischer Erfahrung im Cluster Umfeld und scharfes Nachdenken. ;)