Verwenden des Cluster-Interconnect für den Datendienstverkehr

Ein Cluster benötigt mehrere Netzwerkverbindungen zwischen den Knoten, die den Cluster-Interconnect bilden. Die Cluster-Software verwendet mehrere Interconnects, um die Hochverfügbarkeit und die Leistung zu verbessern. Für den internen Datenverkehr (zum Beispiel Dateisystemdaten oder Scalable-Dienstdaten) werden Meldungen über alle verfügbaren Interconnects im Round-Robin-Verfahren gesendet.

Der Cluster-Interconnect steht auch Anwendungen zur hoch verfügbaren Kommunikation zwischen den Knoten zur Verfügung. Eine verteilte Anwendung kann zum Beispiel Komponenten auf unterschiedlichen Knoten ausführen, die miteinander kommunizieren müssen. Indem der Cluster-Interconnect anstelle des öffentlichen Netzwerks verwendet wird, bleiben diese Verbindungen beim Versagen einer einzelnen Verknüpfung bestehen.

Um den Cluster-Interconnect für die Datenverbindung zwischen den Knoten zu verwenden, muss eine Anwendung die während der Cluster-Installation konfigurierten privaten Hostnamen verwenden. Wenn zum Beispiel der private Hostname für Knoten 1 clusternode1-priv ist, kommunizieren Sie mit diesem Namen über den Cluster-Interconnect mit Knoten 1. TCP-Sockets, die mit diesem Namen geöffnet wurden, werden über den Cluster-Interconnect geleitet und können bei einem Netzwerkfehler transparent umgeleitet werden.

Beachten Sie, dass der Cluster-Interconnnect jeden beliebigen, während der Installation gewählten Namen verwenden kann, da die privaten Hostnamen während der Installation konfiguriert werden können. Den tatsächlichen Namen erhalten Sie über scha_cluster_get(3HA) mit dem Argument scha_privatelink_hostname_node.

Bei Verwendung des Cluster-Interconnects auf Anwendungsebene wird ein einizger Interconnect zwischen jedem Knotenpaar eingesetzt; wenn möglich werden jedoch getrennte Interconnects für unterschiedliche Knotenpaare eingesetzt. Angenommen, eine Anwendung wird auf drei SPARC-basierten Knoten ausgeführt und kommuniziert über den Cluster-Interconnect. Die Kommunikation zwischen den Knoten 1 und 2 kann über die Schnittstelle hme0 erfolgen, während die Kommunikation zwischen den Knoten 1 und 3 über die Schnittstelle qfe1 erfolgen kann. Das bedeutet, dass die Anwendungskommunikation zwischen zwei beliebigen Knoten auf einen einzigen Interconnect beschränkt ist, während die Cluster-interne Kommunikation über alle Interconnects verteilt wird.

Beachten Sie, dass die Anwendung den Interconnect mit dem internen Cluster-Datenverkehr teilt, so dass die für die Anwendung verfügbare Bandbreite von der Bandbreite abhängt, die für anderen Cluster-Datenverkehr verwendet wird. Im Fall eines Versagens kann der interne Datenverkehr im Round-Robin-Verfahren auf die restlichen Interconnects umgeleitet werden, während die Anwendungsverbindungen mit einem versagenden Interconnect auf einen funktionierenden Interconnect umgeschaltet werden können.

Zwei Adresstypen unterstützen den Cluster-Interconnect, und mit gethostbyname(3N) werden für einen privaten Hostnamen in der Regel zwei IP-Adressen zurückgegeben. Die erste Adresse wird als logische Pro-Paar-Adresse bezeichnet, die zweite Adresse als logische Pro-Knoten-Adresse.

Jedem Knotenpaar wird eine eigene logische Pro-Paar-Adresse zugewiesen. Dieses kleine logische Netzwerk unterstützt Failover-Vorgänge von Verbindungen. Jedem Knoten wird außerdem eine feste Pro-Knoten-Adresse zugewiesen. Mit anderen Worten, die logischen Pro-Paar-Adressen für clusternode1-priv sind auf jedem Knoten anders, während die logische Pro-Knoten-Adresse für clusternode1-priv für jeden Knoten gleich ist. Ein Knoten hat jedoch für sich selbst keine Pro-Paar-Adresse, so dass mit gethostbyname (clusternode1-priv) auf Knoten 1 nur die logische Pro-Knoten-Adresse zurückgegeben wird.

Beachten Sie, dass Anwendungen, die Verbindungen über den Cluster-Interconnect zulassen und dann aus Sicherheitsgründen die IP-Adresse überprüfen, alle IP-Adressen überprüfen müssen, die mit gethostbyname zurückgegeben werden, und nicht nur die erste IP-Adresse.

Wenn Sie in Ihrer Anwendung an allen Stellen konsistente IP-Adressen benötigen, konfigurieren Sie Anwendung so, dass die Pro-Knoten-Adresse sowohl an die Client- als auch an die Serverseite angebunden ist; so scheinen alle Verbindungen über die Pro-Knoten-Adresse zu laufen.