Datendienste

Der Begriff Datendienst beschreibt eine Anwendung wie Sun Java System Web Server oder Oracle, die eher zur Ausführung auf einem Cluster als auf einem Einzelserver konfiguriert wurde. Ein Datendienst besteht aus einer Anwendung, spezialisierten Sun Cluster-Konfigurationsdateien und Sun Cluster -Verwaltungsmethoden, mit denen die nachfolgenden Anwendungsaktionen gesteuert werden.

• Beginn

• Anhalten

• Überwachen und Ergreifen von Korrekturmaßnahmen

Informationen zu Datendienst-Typen finden Sie unter Datendienste in Sun Cluster Überblick für das Betriebssystem Solaris.

In Abbildung 3–4 cwird eine Anwendung, die auf einem einzigen Anwendungsserver ausgeführt wird (Einzelservermodell) mit derselben Anwendung auf einem Cluster (Cluster-Servermodell) verglichen. Der einzige Unterschied zwischen den beiden Konfigurationen besteht darin, dass die Cluster-Anwendung ggf. schneller ausgeführt wird und eine bessere Hochverfügbarkeit zeigt.

Abbildung 3–4 Standardkonfiguration versus Client/Server-Konfiguration als Cluster

Beim Einzelservermodell konfigurieren Sie die Anwendung für den Zugriff auf den Server über eine bestimmte öffentliche Netzwerkschnittstelle (einen Hostnamen). Der Hostname ist diesem realen Server zugeordnet.

Beim geclusterten Servermodell ist die öffentliche Netzwerkschnittstelle ein logischer Hostname oder eine gemeinsam genutzte Adresse. Der Begriff Netzwerkressourcen bezeichnet sowohl die logischen Hostnamen als auch die gemeinsam genutzten Adressen.

Für bestimmte Datendienste müssen Sie entweder logische Hostnamen oder gemeinsam genutzte Adressen als Netzwerkschnittstellen angeben. Logische Hostnamen und gemeinsam genutzte Adressen sind nicht austauschbar. Für andere Datendienste können Sie wahlweise logische Hostnamen oder gemeinsam genutzte Adressen angeben. Details zum jeweils erforderlichen Schnittstellentyp finden Sie in den Angaben zur Installation und Konfiguration für den jeweiligen Datendienst.

Eine Netzwerkressource ist keinem spezifischen realen Server zugeordnet. Netzwerkressourcen können zwischen den realen Servern migrieren.

Eine Netzwerkressource ist zunächst einem einzigen Knoten zugeordnet, dem Primärknoten. Wenn der Primärknoten ausfällt, werden Netzwerkressource und Anwendungsressource mit einem Failover-Vorgang auf einen anderen Cluster-Knoten (einen Sekundärknoten) umgeleitet. Wenn die Netzwerkressource ein Failover durchführt, wird die Anwendungsressource nach einer kurzen Verzögerung auf dem Sekundärknoten weiter ausgeführt.

In Abbildung 3–5 wird das Einzelservermodell mit dem geclusterten Servermodell verglichen. Beachten Sie, dass eine Netzwerkressource (in diesem Beispiel ein logischer Hostname) in einem geclusterten Servermodell zwischen mindestens zwei Cluster-Knoten wechseln kann. Die Anwendung ist zur Verwendung dieses logischen Hostnamens anstelle eines Hostnamens konfiguriert, der einem bestimmten Server zugeordnet ist.

Abbildung 3–5 Festgelegter Hostname versus logischer Hostname

gemeinsam genutzte Adresse ist zunächst ebenfalls einem einzigen Knoten zugeordnet. Dieser Knoten wird als globaler Schnittstellenknoten (GIF-Knoten) bezeichnet. Eine gemeinsam genutzte Adresse (die so genannte globale Schnittstelle) wird als einzige Netzwerkschnittstelle zum Cluster eingesetzt.

Der Unterschied zwischen dem Modell logischer Hostname und dem Modell Scalable-Dienst besteht darin, dass beim letztgenannten auf jedem Knoten die gemeinsam genutzte Adresse auf der Schleifenschnittstelle ebenfalls aktiv konfiguriert ist. Dank dieser Konfiguration können mehrere Instanzen eines Datendienstes auf mehreren Knoten gleichzeitig aktiv sein. Der Begriff "Scalable-Dienst" bedeutet, dass Sie die CPU-Leistung für die Anwendung durch Hinzufügen zusätzlicher Cluster-Knoten erhöhen können und die Leistung verbessert wird.

Wenn der globale Schnittstellenknoten ausfällt, kann die gemeinsam genutzte Adresse auf einem anderen Knoten gestartet werden, auf dem ebenfalls eine Instanz der Anwendung ausgeführt wird (wobei dieser andere Knoten zum globalen Schnittstellenknoten wird). Oder die gemeinsam genutzte Adresse wird mit einem Failover auf einen anderen Cluster-Knoten verschoben, auf dem die Anwendung zuvor nicht ausgeführt wurde.

In Abbildung 3–6 wird die Einzelserverkonfiguration mit der Cluster-Konfiguration mit Scalable-Diensten verglichen. Beachten Sie, dass die gemeinsam genutzte Adresse in der Scalable-Dienst-Konfiguration auf allen Knoten vorhanden ist. Ähnlich wie bei der Verwendung eines logischen Hostnamens für Failover-Datendienste wird die Anwendung zur Verwendung dieser gemeinsam genutzten Adresse anstelle eines einem bestimmten Server zugeordneten Hostnamens konfiguriert.

Abbildung 3–6 Festgelegter Hostname versus gemeinsam genutzte Adresse

Datendienstmethoden

Die Sun Cluster-Software stellt eine Reihe von Dienstverwaltungsmethoden zur Verfügung. Diese Methoden werden vom Ressourcengruppen-Manager (RGM) gesteuert und eingesetzt, um die Anwendung auf den Cluster-Knoten zu starten, anzuhalten und zu überwachen. Mit diesen Methoden, der Cluster-Framework-Software und den Multihostgeräten können die Anwendungen als Failover- oder Scalable-Datendienste verwendet werden.

Der RGM verwaltet auch Ressourcen im Cluster einschließlich der Anwendungsinstanzen und Netzwerkressourcen (logische Hostnamen und gemeinsam genutzte Adressen).

Zusätzlich zu den Methoden der Sun Cluster-Software stellt das Sun Cluster-System auch eine API und verschiedene Datendienst-Entwicklungstools zur Verfügung. Mit diesen Tools können Anwendungsprogrammierer die Datendienstmethoden entwickeln, die sie zum Ausführen anderer Anwendungen als hoch verfügbare Datendienste mit der Sun Cluster-Software benötigen.

Failover-Datendienste

Wenn der Knoten ausfällt, auf dem der Datendienst ausgeführt wird (der Primärknoten), migriert der Dienst ohne Benutzereingriff auf einen anderen funktionsfähigen Knoten. Failover-Dienste verwenden eine Failover-Ressourcengruppe, die Ressourcen für Anwendungsinstanzen und Netzwerkressourcen enthält (logische Hostnamen). Logische Hostnamen sind IP-Adressen, die auf einem Knoten als aktiv konfiguriert werden können. Später werden sie auf dem Originalknoten automatisch dekonfiguriert und auf einem anderen Knoten konfiguriert.

Für Failover-Datendienste werden die Anwendungsinstanzen nur auf einem einzigen Knoten ausgeführt. Wenn der Fehler-Monitor einen Fehler erkennt, versucht er entweder die Instanz auf demselben Knoten erneut zu starten oder die Instanz auf einem anderen Knoten zu starten (Failover). Das Ergebnis hängt davon ab, wie der Datendienst konfiguriert wurde.

Skalierbare Datendienste

Der Scalable-Datendienst kann aktive Instanzen auf mehreren Knoten ausführen. Scalable-Dienste verwenden die beiden folgenden Ressourcengruppen:

• Eine Scalable-Ressourcengruppe enthält die Anwendungsressourcen.

• Eine Failover-Ressourcengruppe enthält die 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). Diese Anforderungen werden auf Grundlage mehrerer vordefinierter Algorithmen, die in den Lastausgleichsverfahren festgelegt sind, an die Knoten verteilt. Der Cluster kann die Dienstlast mithilfe des Lastausgleichsverfahrens zwischen mehreren Knoten ausgleichen. Mehrere globale Schnittstellen können auf anderen Knoten vorhanden sein, die weitere, gemeinsam genutzte Adressen hosten.

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 bei der Ausführung 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 der Dienst weiter auf den restlichen Knoten ausgeführt und führt möglicherweise zu einer Reduzierung des Dienstdurchsatzes.

---

Hinweis –

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, die zwischen den beiden für Scalable-Dienste bestehen. Dieses Beispiel enthält drei Ressourcengruppen. Die Failover-Ressourcengruppe enthält Anwendungsressourcen für hoch verfügbare DNS und Netzwerkressourcen, die sowohl vom hoch verfügbaren DNS als auch vom hoch verfügbaren Apache Web Server genutzt werden (nur in SPARC-basierten Clustern verwendet). 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. Außerdem hängen alle Apache-Anwendungsressourcen von der Netzwerkressource schost-2 ab, die eine gemeinsam genutzte Adresse ist (gestrichelte Linien).

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

Lastausgleichsverfahren

Der Lastausgleich verbessert die Leistung der Scalable-Dienste sowohl bei der Antwortzeit als auch beim Durchsatz. Es gibt zwei Klassen von Scalable-Datendiensten.

• Rein

• Sticky

Bei einem reinen Dienst, kann jede Instanz Client-Anforderungen beantworten. Bei einem Sticky-Dienst kann ein Client Anforderungen an dieselbe Instanz senden. 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, jeder Knoten in einem Drei-Knoten-Cluster hat eine Gewichtung von 1. 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 SunPlex-Manager-GUI 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" gegenüber der Serverinstanz bezeichnet, die 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.

Beispiel: Ein Webbrowser auf dem Client stellt mithilfe von drei verschiedenen TCP-Verbindungen eine Verbindung mit einer gemeinsam genutzten IP-Adresse an Port 80 her. Die Verbindungen tauschen jedoch zwischengespeicherte Sitzungsinformationen über den 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. .

Beispiel: Ein E-Commerce-Kunde füllt seinen Einkaufskorb mit Artikeln mithilfe von 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 "Sticky-Platzhalter" bei Ports, die dieselbe IP-Adresse aufweisen.

Ein gutes Beispiel dieses Verfahrens ist der passive FTP-Modus. Beispiel: Ein Client stellt an Port 21 eine Verbindung mit einem FTP-Server her. Anschließend wird er 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 über die Steuerinformationen angegeben hat. .

Für jedes dieser Sticky-Verfahren ist das gewichtete Lastausgleichsverfahren standardmäßig gültig. Daher wird die ursprüngliche Client-Anforderung an die vom Lastausgleich vorgegebene Instanz geleitet. Nachdem der Client eine Affinität zum Knoten mit der ausgeführten Instanz aufgebaut hat, werden zukünftige Anforderungen unter bestimmten Bedingungen an diese Instanz geleitet. Der Knoten muss zugänglich sein und das Lastausgleichsverfahren darf sich nicht geändert haben.

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. Allerdings muss dafür die Gesamtanzahl der Verbindungen groß genug sein. 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. Beispielsweise würde die erste Anforderung an Knoten 1, die zweite Anforderung an Knoten 2 geleitet 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 für die 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_WILD-Wert für die Load_balancing_policy-Ressourceneigenschaft eingestellt.

Failback-Einstellungen

Ressourcengruppen wechseln beim Failover von einem Knoten auf einen anderen. Wenn ein solcher Failover auftritt, wird der ursprüngliche Sekundärknoten zum neuen Primärknoten Die Failback-Einstellungen legen die Aktionen fest, die ausgeführt werden, sobald der ursprüngliche Primärknoten wieder online gebracht wird. Die Optionen sind, entweder den ursprünglichen Primärknoten wieder zum Primärknoten zu machen (Failback) oder den aktuellen Primärknoten als solchen zu belassen. Sie geben die gewünschte Option mit der Einstellung der Failback -Ressourcengruppeneigenschaft an.

Bei bestimmten Instanzen kann die Failback-Einstellung zu einer reduzierten Verfügbarkeit der Ressourcengruppe führen, wenn der Originalknoten mit der Ressource ausfällt und mehrmals neu bootet.

Fehler-Monitore der Datendienste

Jeder Sun Cluster-Datendienst stellt einen Fehler-Monitor zur Verfügung, der regelmäßig den Datendienst auf einwandfreies Funktionieren prüft. Ein Fehler-Monitor prüft, ob der bzw. die Anwendungsdämon(en) ausgeführt und die Clients bedient werden. Aufgrund der von den Testsignalen zurückgebenen Informationen können vordefinierte Aktionen wie ein Neustart eines Dämons oder das Einleiten eines Failovers ausgelöst werden.