Scalable-Datendienste

Der Scalable-Datendienst kann aktive Instanzen auf mehreren Knoten ausführen. Scalable-Dienste verwenden zwei Ressourcengruppen: eine Scalable-Ressourcengruppe mit den Anwendungsressourcen und eine Failover-Ressourcengruppe mit den Netzwerkressourcen (gemeinsam genutzte Adressen), von denen der Scalable-Dienst abhängt. Die Scalable-Ressourcengruppe kann auf mehreren Knoten online sein, so dass mehrere Instanzen dieses Dienstes gleichzeitig ausgeführt werden können. Die Failover-Ressourcengruppe, welche die gemeinsam genutzten Adressen hostet, ist jeweils nur auf einem Knoten online. Alle Knoten, die einen Scalable-Dienst hosten, verwenden dieselbe gemeinsam genutzte Adresse, um den Dienst zu hosten.

Dienstanforderungen erreichen den Cluster über eine einzige Netzwerkschnittstelle (die globale Schnittstelle) und werden anhand unterschiedlicher, vordefinierter Algorithmen auf die Knoten verteilt, die im Rahmen des Lastausgleichsverfahrens eingestellt wurden. Der Cluster kann die Dienstlast mithilfe des Lastausgleichsverfahrens zwischen mehreren Knoten ausgleichen. Beachten Sie, dass mehrere globale Schnittstellen auf anderen Knoten weitere, gemeinsam genutzte Adressen hosten können.

Bei Scalable-Diensten werden die Anwendungsinstanzen auf mehreren Knoten gleichzeitig ausgeführt. Wenn der Knoten mit der globalen Schnittstelle ausfällt, wird die globale Schnittstelle auf einen anderen Knoten verschoben. Wenn eine Anwendungsinstanz fehlschlägt, versucht die Instanz, auf demselben Knoten neu zu starten.

Wenn eine Anwendungsinstanz nicht auf demselben Knoten neu gestartet werden kann und ein anderer, nicht verwendeter Knoten für die Ausführung des Dienstes konfiguriert ist, wird der Dienst im Rahmen eines Failover-Vorgangs auf den nicht verwendeten Knoten verschoben. Andernfalls wird er weiter auf den restlichen Knoten ausgeführt und führt möglicherweise zu einer Reduzierung des Dienstdurchsatzes.

Der TCP-Zustand für jede Anwendungsinstanz bleibt auf dem Knoten mit der Instanz, nicht auf dem Knoten mit der globalen Schnittstelle. Deswegen hat ein Ausfall des Knotens mit der globalen Schnittstelle keine Auswirkung auf die Verbindung.

Abbildung 3–7 zeigt ein Beispiel für eine Failover- und eine Scalabe-Ressourcengruppe und die Abhängigkeiten für Scalable-Dienste. Dieses Beispiel enthält drei Ressourcengruppen. Die Failover-Ressourcengruppe enthält Anwendungsressourcen für hoch verfügbaren DNS und Netzwerkressourcen, die sowohl vom hoch verfügbaren DNS als auch vom hoch verfügbaren Apache Web Server genutzt werden. Die Scalable-Ressourcengruppen enthalten nur Anwendungsinstanzen des Apache Web Servers. Beachten Sie, dass Ressourcengruppenabhängigkeiten zwischen den Scalable- und den Failover-Ressourcengruppen (durchgezogene Linien) bestehen, und dass alle Apache-Anwendungsressourcen von der Netzwerkressource schost-2 abhängen, die eine gemeinsam genutzte Adresse ist (gestrichelte Linien).

Abbildung 3–7 Beispiel für Failover- und Scalable-Ressourcengruppen

Scalable-Dienst-Architektur

Das wichtigste Ziel eines Cluster-Netzwerks besteht darin, Skalierbarkeit für Datendienste zu ermöglichen. Skalierbarkeit bedeutet, dass ein Datendienst trotz steigender Belastung eine konstante Antwortzeit beibehalten kann, weil dem Cluster neue Knoten hinzugefügt und neue Serverinstanzen ausgeführt werden. Solche Dienste werden als Scalable-Datendienste bezeichnet. Ein gutes Beispiel für einen Scalable-Datendienst ist ein Webdienst. In der Regel besteht ein Scalable-Datendienst aus mehreren Instanzen, von denen jede auf unterschiedlichen Cluster-Knoten ausgeführt wird. Insgesamt verhalten sich diese Instanzen aus Sicht eines Remote-Clients wie ein einziger Dienst und führen die Funktionen dieses Dienstes aus. Ein Scalable-Webdienst kann zum Beispiel aus mehreren httpd-Dämonen auf unterschiedlichen Knoten bestehen. Jeder httpd-Dämon kann eine Client-Anforderung bedienen. Welcher Dämon die Anforderung bedient, hängt vom Lastausgleichsverfahren ab. Die Antwort an den Client kommt scheinbar vom Dienst und nicht vom konkreten Dämon, der die Anforderung bedient hat, so dass der Eindruck eines einzigen Dienstes gewahrt wird.

Ein Scalable-Dienst besteht aus Folgendem:

• die Scalable-Dienste unterstützende Netzwerkinfrastruktur,

• Lastausgleichsverfahren,

• Unterstützung für Netzwerk und Datendienste (unter Verwendung des Ressourcengruppen-Manager).

Die nachstehende Abbildung zeigt eine Scalable-Dienst-Architektur.

Abbildung 3–8 Scalable-Dienst-Architektur

Die Knoten, welche die globale Schnittstelle nicht hosten (Proxy-Knoten), hosten die gemeinsam genutzte Adresse auf ihren Schleifenschnittstellen. Die an der globalen Schnittstelle eintreffenden Pakete werden anhand konfigurierbarer Lastausgleichsverfahren auf andere Cluster-Knoten verteilt. Die möglichen Lastausgleichsverfahren werden im Folgenden beschrieben.

Lastausgleichsverfahren

Der Lastausgleich verbessert die Leistung der Scalable-Dienste sowohl bei der Antwortzeit als auch beim Durchsatz.

Es gibt zwei Klassen von Scalable-Datendiensten: reine und sticky. Ein reiner Dienst ist ein Dienst, bei dem jede Instanz Client-Anforderungen beantworten kann. Ein Sticky-Dienst ist ein Dienst, bei dem ein Client Anforderungen an dieselbe Instanz sendet. Diese Anforderungen werden nicht an andere Instanzen umgeleitet.

Ein reiner Dienst verwendet ein gewichtetes Lastausgleichsverfahren. Bei diesem Lastausgleichsverfahren werden Client-Anforderungen standardmäßig gleichmäßig auf die Serverinstanzen im Cluster verteilt. Angenommen, dass jeder Knoten in einem Drei-Knoten-Cluster eine Gewichtung von 1 hat. Jeder Knoten bedient 1/3 der Anforderungen aller beliebigen Clients im Auftrag des Dienstes. Gewichtungen können jederzeit vom Verwalter über die scrgadm(1M)-Befehlsschnittstelle oder über die GUI von SunPlex-Manager geändert werden.

Ein Sticky-Dienst hat zwei Typen, normal-sticky und Platzhalter-Sticky. Mit Sticky-Diensten können Sitzungen auf Anwendungsebene gleichzeitig über mehrere TCP-Verbindungen ausgeführt werden, um den Zustandsspeicher (Anwendungssitzungszustand) gemeinsam zu nutzen.

Mit normalen Sticky-Diensten kann ein Client den Zustand zwischen mehreren gleichzeitigen TCP-Verbindungen teilen. Der Client wird als “sticky” bezeichnet, weil die Serverinstanz einen einzigen Port abhört. Der Client hat die Sicherheit, dass alle seine Anforderungen an dieselbe Serverinstanz gehen. Voraussetzung hierfür ist, dass die Instanz aktiv und zugänglich bleibt und das Lastausgleichsverfahren nicht geändert wird, solange der Dienst online ist.

Ein Webbrowser auf dem Client stellt zum Beispiel mithilfe von drei verschiedenen TCP-Verbindungen eine Verbindung mit einer gemeinsam genutzten IP-Adresse an Port 80 her, aber die Verbindungen tauschen zwischengespeicherte Sitzungsinformationen mit dem Dienst aus.

Eine Verallgemeinerung eines Sticky-Verfahrens erstreckt sich auf mehrere Scalable-Dienste, die im Hintergrund Sitzungsinformationen bei derselben Instanz austauschen. Wenn diese Dienste im Hintergrund Sitzungsinformation bei derselben Instanz austauschen, wird der Client als “sticky” bezeichnet, weil mehrere Serverinstanzen auf demselben Knoten unterschiedliche Ports abhören.

Ein E-Commerce-Kunde füllt seinen Einkaufskorb zum Beispiel mit Artikeln und verwendet das normale HTTP an Port 80, wechselt dann jedoch zum Senden sicherer Daten mit SSL auf Port 443, um die Artikel im Einkaufskorb mit Kreditkarte zu bezahlen.

Platzhalter-Sticky-Dienste verwenden dynamisch zugewiesene Port-Nummern, erwarten jedoch trotzdem, dass die Client-Anforderungen an denselben Knoten geleitet werden. Der Client ist in Bezug auf dieselbe IP-Adresse “Sticky-Platzhalter” bei den Ports.

Ein gutes Beispiel dieses Verfahrens ist der passive FTP-Modus. Ein Client stellt an Port 21 eine Verbindung mit einem FTP-Server her und wird vom Server angewiesen, eine neue Verbindung mit einem Listener-Port-Server im dynamischen Port-Bereich herzustellen. Alle Anforderungen an diese IP-Adresse werden an denselben Knoten weitergeleitet, den der Server dem Client mit den Steuerinformationen angegeben hat.

Beachten Sie, dass das gewichtete Lastausgleichsverfahren für jedes dieser Sticky-Verfahren standardmäßig gültig ist, so dass die ursprüngliche Client-Anforderung an die vom Lastausgleich vorgegebene Instanz geleitet wird. Nachdem der Client eine Affinität zum Knoten mit der ausgeführten Instanz aufgebaut hat, werden zukünftige Anforderungen an diese Instanz geleitet, solange der Knoten zugänglich ist und das Lastausgleichsverfahren nicht geändert wird.

Weitere Details zu spezifischen Lastausgleichsverfahren werden nachstehend erläutert.

• Gewichtet. Die Last wird entsprechend den angegebenenen Gewichtungswerten auf mehrere Knoten verteilt. Dieses Verfahren wird mit dem LB_WEIGHTED-Wert für die Load_balancing_weights-Eigenschaft eingestellt. Wenn die Gewichtung für einen Knoten nicht ausdrücklich angegeben ist, beträgt die Standardgewichtung für diesen Knoten Eins.

  Das gewichtete Verfahren leitet einen gewissen Prozentsatz des Datenverkehrs von Clients auf einen bestimmten Knoten. Bei X=Gewichtung und A=Gesamtgewichtung aller aktiven Knoten ist davon auszugehen, dass etwa X/A aller neuen Verbindungen zu einem aktiven Knoten geleitet werden, wenn die Gesamtanzahl der Verbindungen groß genug ist. Dieses Verfahren befasst sich nicht mit einzelnen Anforderungen.

  Beachten Sie, dass es sich nicht um ein Round-Robin-Verfahren handelt. Bei einem Round-Robin-Verfahren würde jede Anforderung eines Clients an einen unterschiedlichen Knoten geleitet: die erste Anforderung an Knoten 1, die zweite Anforderung an Knoten 2 und so weiter.

• Sticky. Bei diesem Verfahren ist der Satz an Ports bei der Konfiguration der Anwendungsressourcen bekannt. Dieses Verfahren wird mit dem LB_STICKY-Wert der Load_balancing_policy-Ressourceneigenschaft eingestellt.

• Sticky-Platzhalter. Dieses Verfahren ist eine Obermenge des normalen “Sticky”-Verfahrens. Bei einem durch die IP-Adresse identifizierten Scalable-Dienst werden die Ports vom Server zugewiesen (und sind vorher nicht bekannt). Die Ports können sich ändern. Dieses Verfahren wird mit dem LB_STICKY_WILDWert der Load_balancing_policy-Ressourceneigenschaft eingestellt.