Eigenschaften von Scalable-Diensten

Sie können anhand einer Reihe von Kriterien feststellen, ob eine Anwendung als Scalable-Dienst ausgeführt werden kann. Um festzustellen, ob Ihre Anwendung als Scalable-Dienst ausgeführt werden kann, lesen Sie den Abschnitt Analysieren der Eignung einer Anwendung in Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS. Diese Kriterien werden nachfolgend zusammengefasst.

• Erstens: Ein solcher Dienst besteht aus einer oder mehreren Server instanzen. Jede Instanz wird auf einem anderen Knoten des Clusters ausgeführt. Zwei oder mehr Instanzen desselben Dienstes können nicht auf demselben Knoten ausgeführt werden.

• Zweitens: Wenn der Dienst einen externen logischen Datenspeicher zur Verfügung stellt, müssen Sie mit Bedacht vorgehen. Der gleichzeitige Zugriff auf diesen Speicher durch mehrere Serverinstanzen muss synchronisiert werden, um den Verlust von Aktualisierungen oder das Lesen von Daten zu verhindern, wenn diese gerade geändert werden. Beachten Sie, dass der Begriff "extern" verwendet wird, um diesen Speicher vom Arbeitsspeicherstatus zu unterscheiden. Der Begriff "logisch" weist darauf hin, dass der Speicher als einzelne Entität angezeigt wird, obwohl er möglicherweise repliziert wurde. Außerdem hat dieser logische Datenspeicher die Eigenschaft, dass eine Aktualisierung des Speichers durch eine beliebige Instanz sofort von anderen Instanzen "erkannt" wird.

  Das Sun Cluster-System stellt einen solchen externen Speicher über das Cluster-Dateisystem und die globalen Partitionen im raw-Modus zur Verfügung. Angenommen, ein Dienst schreibt neue Daten in eine externe Protokolldatei oder ändert die dort vorhandenen Daten. Wenn mehrere Instanzen dieses Dienstes ausgeführt werden, hat jede Instanz Zugriff auf dieses externe Protokoll und jede kann gleichzeitig auf dieses Protokoll zugreifen. Jede Instanz muss den Zugriff auf dieses Protokoll synchronisieren, andernfalls kommt es zu Interferenzen zwischen den Instanzen. Der Dienst kann die normale Solaris-Dateisperrung über fcntl(2) und lockf(3C) verwenden, um die gewünschte Synchronisierung zu erreichen.

  Ein weiteres Beispiel für diese Art des Speichers ist eine Backend-Datenbank, wie beispielsweise Hochverfügbarkeits-Oracle Real Application Clusters Guard für SPARC-basierte Cluster oder Oracle. Bei diesem Typ von Backend-Datenbankserver ist die Synchronisierung über Datenbankabfragen oder Aktualisierungstransaktionen integriert. So müssen Serverinstanzen nicht für jede einzelne Instanz eine eigene Synchronisierung durchführen.

  Der Sun IMAP-Server ist ein Beispiel für einen Dienst, bei dem es sich nicht um einen Scalable-Dienst handelt. Der Dienst aktualisiert einen Speicher, aber dieser Speicher ist privat. Wenn mehrere IMAP-Instanzen in diesen Speicher schreiben, werden die jeweiligen Einträge überschrieben, weil die Aktualisierungen nicht synchronisiert sind. Der IMAP-Server muss für die Synchronisierung eines gleichzeitigen Zugriffs umgeschrieben werden.

• Beachten Sie schließlich, dass Instanzen über private Daten verfügen können, die von den Daten anderer Instanzen getrennt sind. In einem solchen Fall muss der Dienst den gleichzeitigen Zugriff nicht selbst synchronisieren, weil die Daten privat sind und nur diese Instanz sie bearbeiten kann. In diesem Fall müssen Sie darauf achten, diese privaten Daten nicht unter dem Cluster-Dateisystem zu speichern, weil die Möglichkeit eines globalen Zugriffs besteht.