Der Datendienst Sun Cluster HA für Oracle 3.0 kann unter Sun Cluster 3.1 nur dann ausgeführt werden, wenn er unter folgenden Versionen der Solaris-Betriebsumgebung verwendet wird:
Solaris 8, 32-Bit-Version
Solaris 8, 64-Bit-Version
Solaris 9, 32-Bit-Version
Der Datendienst Sun Cluster HA für Oracle 3.0 kann nicht unter Sun Cluster 3.1 ausgeführt werden, wenn die 64-Bit-Version von Solaris 9 verwendet wird.
Beachten Sie die Dokumentation zur Option Oracle Parallel Fail Safe/Real Application Clusters Guard von Oracle Parallel Server/Real Application Cluster, da Sie die Hostnamen nach der Installation der Sun Cluster-Software nicht mehr ändern können.
Weitere Informationen über die Beschränkungen bei Hostnamen und Knotennamen finden Sie in der Dokumentation von Oracle Parallel Fail Safe/Real Application Clusters Guard.
Wenn der VERITAS NetBackup-Client ein Cluster ist, kann nur ein logischer Host als Client konfiguriert werden, weil nur eine bp.conf-Datei vorhanden ist.
Wenn der NetBackup-Client ein Cluster ist und einer der logischen Hosts im Cluster als NetBackup-Client konfiguriert ist, kann NetBackup von den realen Hosts keine Sicherungskopien herstellen.
Im Cluster, auf dem der Master-Server läuft, ist der Master-Server der einzige logische Host, von dem Sicherheitskopien erstellt werden können.
An den Master-Server können keine Sicherungsmedien angeschlossen werden, weshalb ein oder mehrere Medienserver erforderlich sind.
In einer Sun Cluster-Umgebung wird Robotersteuerung nur auf Medienservern und nicht auf dem auf Sun Cluster laufenden NetBackup-Master-Server unterstützt.
Ein Sun Cluster-Knoten darf nicht gleichzeitig NFS-Client von einem über Sun Cluster HA für NFS exportierten Dateisystem sein, das auf einem Knoten im selben Cluster unterstützt wird. Ein derartiges übergreifendes Einhängen von Sun Cluster HA für NFS ist nicht zulässig. Verwenden Sie das Cluster-Dateisystem, um Cluster-Knoten Dateien gemeinsam zu nutzen.
Anwendungen, die lokal im Cluster laufen, dürfen Dateien in einem über NFS exportierten Dateisystem nicht sperren. Sonst könnten lokale Sperren (z. B. flock(3UCB) oder fcntl(2)) die Möglichkeit zum Neustarten von Lock Manager (lockd) stören. Beim Neustart könnte einem gesperrten lokalen Prozess eine Sperre gewährt werden, die eigentlich einem Remote-Client vorbehalten sein sollte. Das würde ein unvorhersehbares Verhalten verursachen.
Sun Cluster HA für NFS erfordert, dass alle NFS-Client-Einhängungen “harte” Einhängungen sind.
Verwenden Sie für Sun Cluster HA für NFS keine Hostnamen-Alias für Netzwerk-Ressourcen. Bei NFS-Clients, in die Cluster-Dateisysteme eingehängt sind, die Hostnamen-Alias verwenden, können Probleme bei der Aufhebung von statd-Sperren auftreten.
Sun Cluster 3.1 unterstützt Secure NFS oder die Verwendung von Kerberos mit NFS, genauer gesagt, die Optionen secure und kerberos des Untersystems share_nfs(1M), nicht. Sun Cluster 3.1 unterstützt jedoch die Verwendung von sicheren Ports für NFS durch Hinzufügen des Eintrags set nfssrv:nfs_portmon=1 in der Datei /etc/system auf Cluster-Knoten.
Verwenden Sie nicht NIS für Benennungsdienste in einem Cluster, auf dem Sun Cluster HA für SAP liveCache läuft, da der NIS-Eintrag nur verwendet wird, wenn Dateien nicht verfügbar sind.
Weitere Verfahrensinformationen über die mit dieser Beschränkung zusammenhängenden Passwortanforderungen von nssswitch.conf finden Sie im Abschnitt “Preparing the Nodes and Disks” in Sun Cluster 3.1 Data Service for SAP liveCache Guide .