Analysieren der Eignung einer Anwendung

Als erster Schritt beim Erstellen eines Datendienstes muss überprüft werden, ob die Zielanwendung alle Anforderungen für hohe Verfügbarkeit bzw. Skalierbarkeit erfüllt. Wenn die Anwendung nicht alle Anforderungen erfüllt, können Sie den Quellcode der Anwendung ändern, um sie hoch verfügbar oder skalierbar zu machen.

Die folgende Liste fasst die Anforderungen für eine Anwendung, die hoch verfügbar oder skalierbar gemacht werden soll, zusammen. Wenn Sie weitere Informationen benötigen oder den Quellcode der Anwendung ändern möchten, lesen Sie Anhang B, Codeauflistungen für Beispieldatendienste.

Ein Scalable-Dienst muss für eine hohe Verfügbarkeit die folgenden Bedingungen sowie einige zusätzliche Kriterien erfüllen, die in der nachfolgenden Liste beschrieben werden.

• Alle Anwendungen mit Netzwerkunterstützung (Client-Server-Modell) und ohne Netzwerkunterstützung (ohne Client) sind potenzielle Kandidaten für eine hohe Verfügbarkeit oder Skalierbarkeit in der Sun Cluster-Umgebung. Sun Cluster kann jedoch keine erweiterte Verfügbarkeit in Timesharing-Umgebungen bereitstellen, in denen Anwendungen auf einem Server ausgeführt werden, auf den über telnet oder rlogin zugegriffen wird.

• 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. Der Datendienst muss keine Verbindungen wiederherstellen können.

• Die Anwendung muss nicht vom physikalischen Hostnamen des Knotens abhängig sein, auf dem sie ausgeführt wird. Weitere Informationen finden Sie im Abschnitt 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 Cluster-Dateisystemen befinden. Weitere Informationen finden Sie im Abschnitt Multihost-Daten.

  Wenn die Anwendung einen hart verdrahteten Pfadnamen für den Speicherort der Daten verwendet, können Sie diesen Pfad in eine symbolische Verknüpfung ändern, die auf einen Speicherort im Cluster-Dateisystem verweist, ohne den Quellcode der Anwendung zu ändern. Weitere Informationen finden Sie im Abschnitt Verwenden von symbolischen Verknüpfungen für Multihost-Datenablage .

• Die Binärdateien und Bibliotheken der Anwendung können auf jedem Knoten oder im Cluster-Dateisystem lokal gespeichert werden. Der Vorteil der Speicherung im Cluster-Dateisystem besteht darin, dass eine Einzelinstallation ausreichend ist. Der Nachteil besteht darin, dass bei parallelen Updates die Binärdateien verwendet werden, wenn die Anwendung unter 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 im Abschnitt Client-Wiederholversuch.

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

Außerdem müssen die Scalable-Dienste folgende 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. Das Lastausgleichsverfahren Lb_weighted, das eine Reaktion auf Client-Anforderungen für jede Instanz zulässt, funktioniert nicht bei einer Anwendung, die einen im Speicher vorhandenen Cache 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, sodass sie einen im Speicher vorhandenen Cache verwenden können. Beachten Sie, dass RGM mehrere Client-Anforderungen von unterschiedlichen Clients unter den Instanzen des Dienstes verteilt. Weitere Informationen zum Festlegen des Lastausgleichsverfahrens für skalierbare Datendienste finden Sie im Abschnitt Implementieren einer Failover-Ressource.