Analysieren der Eignung einer Anwendung

Als erster Schritt beim Erstellen eines Datendienstes muss überprüft werden, ob die Zielanwendung alle Anforderungen für eine hohe Verfügbarkeit bzw. Skalierbarkeit erfüllt. Wenn die Anwendung nicht allen Anforderungen entspricht, können Sie möglicherweise deren Quellcode ändern, um die Anforderungen zu erfüllen.

Die folgende Liste fasst die Anforderungen für eine Anwendung, die hoch verfügbar oder skalierbar gemacht werden soll, zusammen. Weitere Einzelheiten und Hilfe beim Ändern des Anwendungsquellcodes finden Sie in Anhang B, Codeauflistungen für Beispieldatendienste.

Ein Scalable-Dienst muss alle folgenden Bedingungen für hohe Verfügbarkeit sowie einige zusätzliche Kriterien erfüllen.

• Sowohl Anwendungen mit Netzwerkunterstützung (Client/Server-Modell) als auch Anwendungen ohne Netzwerkunterstützung (ohne Clients) können in der Sun Cluster-Umgebung hoch verfügbar oder skalierbar gemacht werden. Sun Cluster kann jedoch keine verbesserte Verfügbarkeit in Time-Sharing-Umgebungen bereitstellen, in denen Anwendungen auf einem Server mit Zugriff über telnet oder rlogin ausgeführt werden.

• Die Anwendung muss Abstürze tolerieren. Das bedeutet, dass sie bei Bedarf Plattendaten wiederherstellen muss, wenn sie nach einem unerwarteten Knotenausfall neu gestartet wird. Zudem muss die Wiederherstellungszeit nach einem Absturz begrenzt sein. Absturztoleranz ist eine Voraussetzung dafür, dass eine Anwendung hoch verfügbar gemacht wird, da die Fähigkeit zum Wiederherstellen der Platte und Neustarten der Anwendung die Datenintegrität sicherstellt. Es ist nicht erforderlich, dass der Datendienst Verbindungen wiederherstellen kann.

• Die Anwendung darf nicht von dem realen Hostnamen des Knotens, auf dem sie ausgeführt wird, abhängen. Weitere Informationen finden Sie unter Hostnamen.

• Die Anwendung muss korrekt in Umgebungen laufen, in denen mehrere IP-Adressen als aktiv konfiguriert sind. Zum Beispiel sind dies Umgebungen mit Multihomed-Hosts, in denen sich der Knoten in mehr als einem öffentlichen Netzwerk befindet, oder Umgebungen mit Knoten, auf denen mehrere logische Schnittstellen auf einer Hardware-Schnittstelle als aktiv konfiguriert sind.

• Um hoch verfügbar zu sein, müssen sich die Anwendungsdaten in den Cluster-Dateisystemen befinden — siehe Multihost-Daten.

  Wenn die Anwendung einen fest verdrahteten Pfadnamen als Datenspeicherort verwendet, können Sie diesen Pfad in eine symbolische Verknüpfung ändern, die zu einem Speicherort im Cluster-Dateisystem zeigt, ohne dabei den Anwendungsquellcode zu ändern. Weitere Informationen finden Sie unter Verwenden von symbolischen Verknüpfungen für Multihost-Datenablage.

• Anwendungsbinärdateien und Bibliotheken können lokal auf jedem Knoten des Cluster-Dateisystems residieren. Der Vorteil hierbei besteht darin, dass eine einzige Installation ausreicht. Der Nachteil ist, dass laufende Aufrüstungen zu einem Problem werden, da die Binärdateien verwendet werden, solange die Anwendung unter Steuerung durch RGM ausgeführt wird.

• Der Client sollte in der Lage sein, eine Abfrage automatisch zu wiederholen, wenn das Zeitlimit für den ersten Versuch abgelaufen ist. Wenn die Anwendung und das Protokoll bereits den Fall eines einzelnen Serverabsturzes und -neustarts unterstützen, sind sie auch für das Failover bzw. Switchover der darin enthaltenen Ressourcengruppe geeignet. Weitere Informationen finden Sie unter Client-Wiederholversuch.

• Die Anwendung darf keine UNIX®-Domain-Sockets oder benannte Datenaustauschkanäle im Cluster-Dateisystem haben.

Zudem müssen Scalable-Dienste die folgenden Anforderungen erfüllen:

• Die Anwendung muss in der Lage sein, mehrere Instanzen auszuführen, die alle mit denselben Anwendungsdaten im Cluster-Dateisystem arbeiten.

• Die Anwendung muss Datenkonsistenz für den simultanen Zugriff von mehreren Knoten aus bereitstellen.

• Die Anwendung muss eine ausreichende Sperre mit einem global sichtbaren Mechanismus implementieren, wie zum Beispiel das Cluster-Dateisystem.

Bei einem Scalable-Dienst legen die Anwendungseigenschaften auch das Lastausgleichsverfahren fest. Zum Beispiel funktioniert das Lastausgleichsverfahren LB_WEIGHTED, das jeder Instanz die Antwort auf Client-Anforderungen ermöglicht, nicht für eine Anwendung, die einen Cache-Speicher auf dem Server für Client-Verbindungen verwendet. In diesem Fall muss ein Lastausgleichsverfahren angegeben werden, das den Datenverkehr eines bestimmten Clients auf eine Instanz der Anwendung beschränkt. Die Lastausgleichsverfahren LB_STICKY und LB_STICKY_WILD senden wiederholt alle Anforderungen von einem Client an dieselbe Anwendungsinstanz — wo sie einen Cache-Speicher verwenden können. Beachten Sie, dass RGM mehrere Client-Anforderungen von unterschiedlichen Clients unter den Instanzen des Dienstes verteilt. Weitere Informationen zum Einstellen der Lastausgleichsverfahren für Scalable-Datendienste finden Sie unter Implementieren einer Failover-Ressource.