Dieser Abschnitt beschreibt Fehler oder Auslassungen in der Dokumentation, Online-Hilfe bzw. Online-Dokumentation (Manpages) zu Sun Cluster 3.2.
In diesem Abschnitt werden Fehler und Auslassungen im Sun Cluster Concepts Guide for Solaris OS behandelt.
Die folgenden Informationen im Abschnitt Sun Cluster Topologies for x86 in Sun Cluster Concepts Guide for Solaris OS sind für Sun Cluster 3.2 nicht gültig: "Sun Cluster unterstützt in x86-basierten Systemen zwei Knoten in einem Cluster."
Diese Informationen müssen wie folgt lauten: "Eine Sun Cluster-Konfiguration mit x86-basierten Systemen unterstützt bis zu acht Knoten in einem Cluster, der unter Oracle RAC ausgeführt wird, bzw. bis zu vier Knoten in einem Cluster, der nicht unter Oracle RAC ausgeführt wird."
In diesem Abschnitt werden Fehler und Auslassungen im Sun Cluster Handbuch Softwareinstallation für Solaris OS behandelt.
Wenn Sie einen Cluster aktualisieren, auf dem auch die Sun Cluster Geographic Edition-Software ausgeführt wird, müssen Sie zusätzliche vorbereitende Schritte durchführen, bevor Sie mit der Aktualisierung der Sun Cluster-Software beginnen. Zu diesen Schritten gehört das Herunterfahren der Sun Cluster Geographic Edition-Infrastruktur. Lesen Sie die Verfahren in Kapitel 4, Upgrading the Sun Cluster Geographic Edition Software in Sun Cluster Geographic Edition Installation Guide im Sun Cluster Geographic Edition Installation Guide . In diesen Verfahren wird beschrieben, an welcher Stelle Sie auf das Sun Cluster-Software-Installationshandbuch zurückgreifen müssen, um die Aktualisierung der Sun Cluster-Software durchzuführen.
In diesem Abschnitt werden Fehler und Auslassungen im Sun Cluster Data Services Planning and Administration Guide for Solaris OS behandelt.
Unter Resource Type Properties in Sun Cluster Data Services Planning and Administration Guide for Solaris OS fehlt in der Beschreibung der Ressourceneigenschaft Failover eine Anmerkung zur Unterstützung von skalierbaren Diensten in nicht globalen Zonen. Diese Unterstützung ist für Ressourcen gewährleistet, deren Ressourcentypeigenschaft Failover als FALSCH und deren Ressourceneigenschaft Skalierbar als WAHR festgelegt ist. Diese Kombination der Eigenschaften gibt einen skalierbaren Dienst an, der eine SharedAddress-Ressource für den Netzwerklastenausgleich verwendet. In Sun Cluster 3.2 können Sie einen skalierbaren Dienst dieses Typs in einer Ressourcengruppe konfigurieren, die in einer nicht globalen Zone ausgeführt wird. Sie können einen skalierbaren Dienst jedoch nicht für die Ausführung in mehreren nicht globalen Zonen auf demselben Knoten konfigurieren.
In diesem Abschnitt werden Fehler und Auslassungen im Sun Cluster Data Service for MaxDB Guide for Solaris OS behandelt.
Sun Cluster Data Service for MaxDB unterstützt nicht globale Zonen auf SPARC- und x86-basierten Systemen. Für diese Unterstützung sind folgende Änderungen im Sun Cluster Data Service MaxDB Guide notwendig. Die folgenden Schritte können auf einem Cluster ausgeführt werden, der für eine Ausführung in globalen Zonen konfiguriert wurde. Wenn der Cluster in nicht globalen Zonen ausgeführt werden soll, sind manche Schritte möglicherweise nicht erforderlich. Diese Schritte enthalten einen entsprechenden Hinweis.
Stellen Sie sicher, dass die Netzwerkressourcen in jeder Zone in der Datei /etc/hosts vorhanden sind, um mögliche Fehler aufgrund der Name-Service-Suche zu vermeiden.
Erstellen Sie in jeder Zone in der Datei /etc/group einen Eintrag für die MaxDB-Gruppe und fügen Sie der Gruppe gegebenenfalls Benutzer hinzu.
Erstellen Sie in jeder Zone einen Eintrag für die MaxDB-Benutzer-ID.
Aktualisieren Sie mit folgendem Befehl die Dateien /etc/passwd und /etc/shadow mit einem Eintrag für die Benutzer-ID:
# useradd -u uid -g group -d /sap-home maxdb user |
Erstellen Sie Einhängepunkt-Verzeichnisse in den Zonen, in denen MaxDB potenziell ausgeführt wird.
Konfigurieren Sie die Datei /etc/nsswitch.conf so, dass Sun Cluster HA for MaxDB bei einem Switchover oder Failover ordnungsgemäß gestartet und beendet wird.
Aktualisieren Sie in jeder Zone die Datei /etc/services mit allen erforderlichen MaxDB-Ports, die von den globalen Zonen /etc/services abgerufen wurden. Dieser Schritt ist unter Umständen nicht notwendig, wenn MaxDB in nicht globalen Zonen installiert wird.
Kopieren Sie /etc/opt/sdb aus der globalen Zone auf alle Knoten in der lokalen Zone. Dieser Schritt ist unter Umständen nicht notwendig, wenn MaxDB in nicht globalen Zonen installiert wird.
Kopieren Sie /var/spool/sql aus der globalen Zone auf alle Knoten in der lokalen Zone. Dieser Schritt ist unter Umständen nicht notwendig, wenn MaxDB in nicht globalen Zonen installiert wird.
Führen Sie auf x86-basierten Systemen crle -64 -u -l /sapmnt/MaxDBSystemName/exe in allen lokalen Zonen aus, in denen MaxDB ausgeführt wird.
In diesem Abschnitt werden Fehler und Auslassungen im Sun Cluster Data Service for SAP Guide for Solaris OS behandelt.
Sun Cluster Data Service for SAP unterstützt nicht globale Zonen auf SPARC- und x86-basierten Systemen. Für diese Unterstützung sind folgende Änderungen im Sun Cluster Data Service SAP notwendig. Die folgenden Schritte können auf einem Cluster ausgeführt werden, der für eine Ausführung in globalen Zonen konfiguriert wurde. Wenn der Cluster in nicht globalen Zonen ausgeführt werden soll, sind manche Schritte möglicherweise nicht erforderlich. Diese Schritte enthalten einen entpsrechenden Hinweis.
Stellen Sie sicher, dass die Netzwerkressourcen in jeder Zone in der Datei /etc/hosts vorhanden sind, um mögliche Fehler aufgrund der Name-Service-Suche zu vermeiden.
Erstellen Sie in jeder Zone in der Datei /etc/group einen Eintrag für die SAP-Gruppe und fügen Sie der Gruppe gegebenenfalls Benutzer hinzu.
Erstellen Sie in jeder Zone einen Eintrag für die SAP-Benutzer-ID.
Aktualisieren Sie mit folgendem Befehl die Dateien /etc/passwd und /etc/shadow mit einem Eintrag für die Benutzer-ID:
# useradd -u uid -g group -d /sap-home sap user |
Erstellen Sie Einhängepunkt-Verzeichnisse in den Zonen, in denen SAP potenziell ausgeführt wird.
Konfigurieren Sie die Datei /etc/nsswitch.conf so, dass Sun Cluster HA for SAP bei einem Switchover oder Failover ordnungsgemäß gestartet und beendet wird.
Aktualisieren Sie in jeder Zone die Datei /etc/services mit allen erforderlichen SAP-Ports, die von den globalen Zonen /etc/services abgerufen wurden. Dieser Schritt ist unter Umständen nicht notwendig, wenn SAP in nicht globalen Zonen installiert wird.
Führen Sie auf x86-basierten Systemen crle -64 -u -l /sapmnt/SAPSystemName/exe in allen lokalen Zonen aus, in denen SAP ausgeführt werden soll.
In diesem Abschnitt werden Fehler und Auslassungen im Sun Cluster Data Service for SAP liveCache Guide for Solaris OS behandelt.
Sun Cluster Data Service for SAP liveCache unterstützt nicht globale Zonen auf SPARC- und x86-basierten Systemen. Für diese Unterstützung sind folgende Änderungen im Sun Cluster Data Service SAP liveCache Guide notwendig. Die folgenden Schritte können auf einem Cluster ausgeführt werden, der für eine Ausführung in globalen Zonen konfiguriert wurde. Wenn der Cluster in nicht globalen Zonen ausgeführt werden soll, sind manche Schritte möglicherweise nicht erforderlich. Diese Schritte enthalten einen entpsrechenden Hinweis.
Stellen Sie sicher, dass die Netzwerkressourcen in jeder Zone in der Datei /etc/hosts vorhanden sind, um mögliche Fehler aufgrund der Name-Service-Suche zu vermeiden.
Erstellen Sie in jeder Zone in der Datei /etc/group einen Eintrag für die SAP liveCache-Gruppe und fügen Sie der Gruppe gegebenenfalls Benutzer hinzu.
Erstellen Sie in jeder Zone einen Eintrag für die SAP liveCache-Benutzer-ID.
Aktualisieren Sie mit folgendem Befehl die Dateien /etc/passwd und /etc/shadow mit einem Eintrag für die Benutzer-ID:
# useradd -u uid -g group -d /sap-home sap user |
Erstellen Sie Einhängepunkt-Verzeichnisse in den Zonen, in denen SAP liveCache potenziell ausgeführt wird.
Konfigurieren Sie die Datei /etc/nsswitch.conf so, dass Sun Cluster HA for SAP liveCache bei einem Switchover oder Failover ordnungsgemäß gestartet und beendet wird.
Aktualisieren Sie in jeder Zone die Datei /etc/services mit allen erforderlichen SAP liveCache-Ports, die von den globalen Zonen /etc/services abgerufen wurden. Dieser Schritt ist unter Umständen nicht notwendig, wenn SAP liveCache in nicht globalen Zonen installiert wird.
Kopieren Sie /etc/opt/sdb aus der globalen Zone auf alle Knoten in der lokalen Zone. Dieser Schritt ist unter Umständen nicht notwendig, wenn SAP liveCache in nicht globalen Zonen installiert wird.
Kopieren Sie /var/spool/sql aus der globalen Zone auf alle Knoten in der lokalen Zone. Dieser Schritt ist unter Umständen nicht notwendig, wenn SAP liveCache in nicht globalen Zonen installiert wird.
Führen Sie auf x86-basierten Systemen crle -64 -u -l /sapmnt/SAPSystemName/exe in allen lokalen Zonen aus, in denen SAP liveCache ausgeführt wird.
In diesem Abschnitt werden Fehler und Auslassungen im Sun Cluster Data Service for SAP Web Application Server Guide for Solaris OS behandelt.
In SAP 7.0 und NW2004SR1 wird beim Starten einer SAP-Instanz standardmäßig der sapstartsrv-Prozess gestartet. Der sapstartsrv-Prozess wird von Sun Cluster HA for SAP Web Application Server gesteuert. Das heißt, wenn Sun Cluster HA for SAP Web Application Server eine SAP-Instanz beendet oder ein Failover der Instanz durchführt, wird der sapstartsrv-Prozess nicht beendet.
Um zu verhindern, dass der sapstartsrv-Prozess beim Starten einer SAP-Instanz durch Sun Cluster HA for SAP Web Application gestartet wird, müssen Sie das Skript startsap bearbeiten. Zusätzlich müssen Sie die Datei /etc/rc3.d/S90sapinit auf allen Sun Cluster-Knoten in /etc/rc3.d/xxS90sapinit umbenennen.
Sun Cluster Data Service for SAP Web Application Server unterstützt nicht globale Zonen auf SPARC- und x86-basierten Systemen. Für diese Unterstützung sind folgende Änderungen im Sun Cluster Data Service SAP Web Application Server Guide notwendig. Die folgenden Schritte können auf einem Cluster ausgeführt werden, der für eine Ausführung in globalen Zonen konfiguriert wurde. Wenn der Cluster in nicht globalen Zonen ausgeführt werden soll, sind manche Schritte möglicherweise nicht erforderlich. Diese Schritte enthalten einen entpsrechenden Hinweis.
Stellen Sie sicher, dass die Netzwerkressourcen in jeder Zone in der Datei /etc/hosts vorhanden sind, um mögliche Fehler aufgrund der Name-Service-Suche zu vermeiden.
Erstellen Sie in jeder Zone in der Datei /etc/group einen Eintrag für die SAP Web Application Server-Gruppe und fügen Sie der Gruppe gegebenenfalls Benutzer hinzu.
Erstellen Sie in jeder Zone einen Eintrag für die SAP Web Application Server-Benutzer-ID.
Aktualisieren Sie mit folgendem Befehl die Dateien /etc/passwd und /etc/shadow mit einem Eintrag für die Benutzer-ID:
# useradd -u uid -g group -d /sap-home sap user |
Erstellen Sie Einhängepunkt-Verzeichnisse in den Zonen, in denen SAP Web Application Server potenziell ausgeführt wird.
Konfigurieren Sie die Datei /etc/nsswitch.conf so, dass Sun Cluster HA for SAP bei einem Switchover oder Failover ordnungsgemäß gestartet und beendet wird.
Aktualisieren Sie in jeder Zone die Datei /etc/services mit allen erforderlichen SAP-Ports, die von den globalen Zonen /etc/services abgerufen wurden. Dieser Schritt ist unter Umständen nicht notwendig, wenn SAP Web Application Server in nicht globalen Zonen installiert wird.
Führen Sie auf x86-basierten Systemen crle -64 -u -l /sapmnt/SAPSystemName/exe in allen lokalen Zonen aus, in denen SAP ausgeführt werden soll.
Führen Sie folgendes Verfahren durch, um eine HAStoragePlus-Ressource für nicht globale Zonen zu konfigurieren.
Die in der Datei /etc/vfstab enthaltenen Einträge für Cluster-Dateisysteme müssen in den Einhängepunkt-Optionen das globale Kennwort enthalten.
Der Zugriff auf die SAP-Binärdateien, die mit der Ressource HAStoragePlus hoch verfügbar gemacht werden, müssen von nicht globalen Zonen aus möglich sein.
In nicht globalen Zonen müssen Dateisysteme, die von verschiedenen Ressourcen in unterschiedlichen Ressourcengruppen verwendet werden, in derselben HAStoragePlus-Ressource vorhanden sein, die sich wiederum in einer skalierbaren Ressourcengruppe befinden muss. Die Knotenliste der skalierbaren HAStoragePlus-Ressourcengruppe muss ein übergeordneter Satz der Knotenlisten der Anwendungsressourcengruppen sein, die von den Dateisystemen abhängige Ressourcen enthalten. Die von den Dateisystemen abhängigen Anwendungsressourcen müssen eine starke Ressourcenabhängigkeit zur HAStoragePlus-Ressource aufweisen. Die abhängige Anwendungsressourcengruppe muss außerdem eine starke positive Gruppenaffinität zu der skalierbaren HAStoragePlus-Ressourcengruppe aufweisen.
Melden Sie sich auf jedem Cluster im Knoten als Superuser bzw. als Benutzer mit der RBAC-Autorisierung solaris.cluster.modify an.
Erstellen Sie die skalierbare Ressourcengruppe, die die HAStoragePlus-Ressource enthält, mit nicht globalen Zonen.
# clresourcegroup create \ -p Maximum_primaries=m\ -p Desired_primaries=n\ [-n node-zone-list] hasp-resource-group |
Gibt die maximale Anzahl aktiver Primärknoten für diese Ressourcengruppe an.
Gibt die maximale Anzahl aktiver Primärknoten an, auf denen die Ressourcengruppe einen Startversuch durchführen soll.
Gibt in der Knotenliste einer HAStoragePlus-Ressourcengruppe die Liste der Knotennamen an:Zonennamen-Paare wie in der Knotenliste der HAStoragePlus -Ressourcengruppe, in denen SAP-Instanzen online gehen können.
Gibt den Namen der hinzuzufügenden skalierbaren Ressourcengruppe an. Der Name muss mit einem ASCII-Zeichen beginnen.
Registrieren Sie den Ressourcentyp für die HAStoragePlus-Ressource.
# clresourcetype register HAStoragePlus |
Erstellen Sie die HAStoragePlus-Ressource hasp-resource und legen Sie Einhängepunkte für das SAP-Dateisystem und globale Gerätepfade fest.
# clresource create -g hasp-resource-group -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=/dev/global/dsk/d5s2,dsk/d6 \ -p affinityon=false -p FilesystemMountPoints=/sapmnt/JSC,/usr/sap/trans,/usr/sap/JSC hasp-resource |
Gibt den Namen der Ressourcengruppe an.
Enthält die folgenden Werte:
Gruppennamen globaler Geräte, z. B. sap-dg, dsk/d5 .
Pfade zu globalen Geräten, z. B. /dev/global/dsk/d5s2, /dev/md/sap-dg/dsk/d6.
Enthält die folgenden Werte:
Einhängepunkte für lokale oder Cluster-Dateisysteme, z. B. /local/mirrlogA,/local/mirrlogB,/sapmnt/JSC,/usr/sap/JSC.
Die HAStoragePlus-Ressource wird erstellt und aktiviert.
Registrieren Sie den Ressourcentyp für die SAP-Anwendung.
# clresourcetype register resource-type |
Gibt den Namen des hinzuzufügenden Ressourcentyps an. Weitere Informationen finden Sie unter Unterstützte Produkte.
Erstellen Sie eine SAP-Ressourcengruppe.
# clresourcegroup create [-n node-zone-list] -p RG_affinities=++hastorageplus-rg resource-group-1 |
Gibt die Ressourcengruppe der SAP-Dienste an.
Fügen Sie die SAP-Anwendungsressource zu resource-group-1 hinzu und legen Sie eine Abhängigkeit zu hastorageplus-1 fest.
# clresource create -g resource-group-1 -t SUNW.application \ [-p "extension-property[{node-specifier}]"=value, ?] \ -p Resource_dependencies=hastorageplus-1 resource |
Bringen Sie die Failover-Ressourcengruppe online.
# clresourcegroup online resource-group-1 |
In diesem Abschnitt werden Fehler und Auslassungen im Sun Cluster System Administration Guide for Solaris OS behandelt.
Führen Sie folgendes Verfahren durch, um eine Anwendung zu Testzwecken außerhalb des Clusters auszuführen.
Ermitteln Sie, ob das Quorum-Gerät im Solaris Volume Manager-Metaset verwendet wird und ob das Quorum-Gerät scsi2- oder scsi3-Reservierungen verwendet.
# clquorum show |
Wenn das Quorum-Gerät im Solaris Volume Manager-Metaset vorhanden ist, fügen Sie ein neues Quorum-Gerät hinzu, das nicht Bestandteil des Metasets ist und zu einem späteren Zeitpunkt im Nicht-Cluster-Modus gestartet werden soll.
# clquorum add did |
Entfernen Sie das alte Quorum-Gerät.
# clqorum remove did |
Wenn das Quorum-Gerät eine scsi2-Reservierung verwendet, entfernen Sie die scsi2-Reservierung von dem alten Quorum-Gerät und vergewissern Sie sich, dass keine weiteren scsi2-Reservierungen vorhanden sind.
# /usr/cluster/lib/sc/pgre -c pgre_scrub -d /dev/did/rdsk/dids2 # /usr/cluster/lib/sc/pgre -c pgre_inkeys -d /dev/did/rdsk/dids2 |
Entnehmen Sie den Knoten, der im Nicht-Cluster-Modus gestartet werden soll.
# clresourcegroup evacuate -n targetnode |
Nehmen Sie alle Ressourcengruppen offline, die HAStorage- oder HAStoragePlus-Ressourcen sowie Geräte oder Dateisysteme enthalten, die von dem Metaset betroffen sind, das später im Nicht-Cluster-Modus gestartet werden soll.
# clresourcegroup offline resourcegroupname |
Deaktivieren Sie alle Ressourcen in den offline genommenen Ressourcengruppen.
# clresource disable resourcename |
Beenden Sie die Verwaltung der Ressourcengruppe.
# clresourcegroup unmanage resourcegroupname |
Nehmen Sie die entsprechende(n) Gerätegruppe(n) offline.
# cldevicegroup offline devicegroupname |
Deaktivieren Sie die Gerätegruppe(n).
# cldevicegroup disable devicegroupname |
Booten Sie den passiven Knoten im Nicht-Cluster-Modus.
# reboot -x |
Überprüfen Sie, ob der Boot-Vorgang auf dem passiven Knoten abgeschlossen wurde, bevor Sie fortfahren.
Solaris 9
Die Eingabeaufforderung wird erst nach Abschluss des Boot-Vorgangs angezeigt. Es ist keine Aktion erforderlich.
Solaris 10
# svcs -x |
Ermitteln Sie, ob scsi3-Reservierungen auf den Datenträgern in den Metasets enthalten sind. Führen Sie auf allen Datenträgern in den Metasets folgende Befehle aus:
# /usr/cluster/lib/sc/scsi -c inkeys -d /dev/did/rdsk/dids2 |
Löschen Sie alle vorhandenen scsi3-Reservierungen auf den Datenträgern.
# /usr/cluster/lib/sc/scsi -c scrub -d /dev/did/rdsk/dids2 |
Fügen Sie dem entnommenen Knoten das Metaset hinzu.
# metaset -s name -C take -f |
Hängen Sie das bzw. die Dateisysteme ein, die sich auf dem angegebenen Gerät im Metaset befinden.
# mount device mountpoint |
Starten Sie die Anwendungen und führen Sie den gewünschten Test durch. Wenn der Test abgeschlossen ist, beenden Sie die Anwendung.
Starten Sie den Knoten neu und warten Sie, bis der Startvorgang abgeschlossen wurde.
# reboot |
Bringen Sie die Gerätegruppe(n) online.
# cldevicegroup online -e devicegroupname |
Starten Sie die Ressourcegruppe(n).
# clresourcegroup online -eM resourcegroupname |
Sun Cluster unterstützt die Solaris IP-Filterfunktion. Es gelten jedoch folgende Einschränkungen:
Es werden nur Failover-Datendienste unterstützt.
Sun Cluster unterstützt die IP-Filterfunktion nicht für skalierbare Datendienste.
Es wird nur Filterung ohne Status unterstützt.
NAT-Routing wird nicht unterstützt.
Übersetzung von lokalen Adressen mit NAT wird unterstützt. Bei der NAT-Übersetzung werden die Pakete sofort neu geschrieben. Daher ist dieser Vorgang für die Cluster-Software transparent.
Bearbeiten Sie in der Datei /etc/iu.ap die öffentlichen NIC-Einträge, sodass in den Einträgen clhbsndr pfil als Modulliste aufgeführt wird.
pfil muss das letzte Modul in der Liste sein.
Wenn Sie für öffentliche und private Netzwerke denselben Adaptertyp verwenden, wird durch Ihre Änderung an der /etc/iu.ap-Datei pfil an die privaten Netzwerkdatenströme weitergegeben. Das Cluster-Transportmodul entfernt bei der Datenstromerstellung jedoch alle nicht erwünschten Module, sodass pfil aus den privaten Netzwerkströmen entfernt wird.
Um sicherzustellen , das der IP-Filter im Nicht-Cluster-Modus ordnungsgemäß ausgeführt wird, aktualisieren Sie die Datei /etc/ipf/pfil.ap.
Aktualisierungen der Datei /etc/iu.ap unterscheiden sich hiervon in manchen Punkten. Weitere Informationen finden Sie in der Dokumentation zum IP-Filter.
Starten Sie alle betroffenen Knoten neu.
Sie können die Knoten nacheinander starten.
Fügen Sie auf allen betroffenen Knoten der Datei /etc/ipf/ipf.conf Filterregeln hinzu. Informationen zur Syntax von IP-Filterregeln finden Sie auf der Manpage ipf(4)
Beachten Sie beim Hinzufügen von Filterregeln zu Sun Cluster-Knoten folgende Richtlinien und Anforderungen:
Sun Cluster führt Failover über Netzwerkadressen von Knoten zu Knoten aus. Beim Failover ist kein besonderes Verfahren und kein Code erforderlich.
Sämtliche Filterregeln, die auf IP-Adressen von Ressourcen für logischen Hostnamen und gemeinsam genutzte Adressen verweisen, müssen auf allen Cluster-Knoten identisch sein.
Regeln auf einem Standby-Knoten verweisen auf eine nicht vorhandene IP-Adresse. Diese Regel bleibt Bestandteil des aktiven Regelsatzes des IP-Filters und tritt in Kraft, wenn der Knoten die Adresse nach einem Failover erhält.
Alle Filterregeln für NICSs in einer IPMP-Gruppe müssen identisch sein. Das heißt, wenn eine Regel schnittstellenspezifisch ist, müssen dieselben Regeln auch für alle übrigen Schnittstellen in derselben IPMP-Gruppe vorhanden sein.
Aktivieren Sie den SMF-Dienst ipfilter.
# svcadm enable /network/ipfilter:default |
In diesem Abschnitt werden Fehler und Auslassungen im Sun Cluster Data Services Developer’s Guide for Solaris OS behandelt.
Unter Resource Type Properties in Sun Cluster Data Services Developer’s Guide for Solaris OS fehlt in der Beschreibung der Ressourceneigenschaft Failover eine Anmerkung zur Unterstützung von skalierbaren Diensten in nicht globalen Zonen. Diese Unterstützung ist für Ressourcen gewährleistet, deren Ressourcentypeigenschaft Failover als FALSCH und deren Ressourceneigenschaft Skalierbar als WAHR festgelegt ist. Diese Kombination der Eigenschaften gibt einen skalierbaren Dienst an, der eine SharedAddress-Ressource für den Netzwerklastenausgleich verwendet. In Sun Cluster 3.2 können Sie einen skalierbaren Dienst dieses Typs in einer Ressourcengruppe konfigurieren, die in einer nicht globalen Zone ausgeführt wird. Sie können einen skalierbaren Dienst jedoch nicht für die Ausführung in mehreren nicht globalen Zonen auf demselben Knoten konfigurieren.
Die Beschreibung der Änderung im Verhalten bei Methoden-Timeouts in Sun Cluster 3.2 fehlt. Wenn ein RGM-Methodenaufruf das Zeitlimit überschreitet, wird der Prozess mit dem Signal SIGABRT beendet und nicht mehr mit dem Signal SIGTERM. Dadurch wird für alle Mitglieder der Prozessgruppe eine Core-Datei erstellt.
Vermeiden Sie das Erstellen von Datendienstmethoden, bei denen eine neue Prozessgruppe erstellt wird. Wenn für Ihre Datendienstmethode keine neue Prozessgruppe erstellt werden muss, erstellen Sie zusätzlich einen Signal-Handler für die Signale SIGTERM und SIGABRT. Erstellen Sie die Signal-Handler so, dass das Signal SIGTERM bzw. SIGABRT zur untergeordneten Prozessgruppe weitergeleitet wird, bevor der Signal-Handler den übergeordneten Prozess beendet. Dadurch wird die Wahrscheinlichkeit erhöht, dass alle von der Methode erzeugten Prozesse ordnungsgemäß beendet werden.
Kapitel 12, Cluster Reconfiguration Notification Protocol in Sun Cluster Data Services Developer’s Guide for Solaris OS fehlt die Anmerkung, dass unter Solaris 10 OS das Cluster Reconfiguration Notification Protocol (CRNP) nur in globalen Zonen ausgeführt wird.
Unter Setting Up the Development Environment for Writing a Data Service in Sun Cluster Data Services Developer’s Guide for Solaris OS wird in einem Hinweis angemerkt, dass die Entwicklerdistribution bzw. die Gesamtdistribution der Solaris-Softwaregruppe erforderlich ist. Dieser Hinweis bezieht sich auf die Entwicklungsmaschine. Da der Hinweis auf eine Anmerkung zum Test des Datendienstes in einem Cluster folgt, kann diese Anforderung fälschlicherweise als Anforderung für den Cluster, auf dem der Datendienst ausgeführt wird, verstanden werden.
In diesem Abschnitt werden Fehler und Auslassungen aus dem Sun Cluster Quorum Server User’s Guide behandelt.
Die folgenden Installationsanforderungen und -anweisungen fehlen oder sind unklar:
Die Solaris-Softwareanforderungen für die Sun Cluster-Software gelten auch für die Quorum Server-Software.
Die unterstützten Hardware-Plattformen für einen Quorum-Server sind mit denen für einen Cluster-Knoten identisch.
Ein Quorum-Server muss nicht auf der gleichen Hardware- oder Software-Plattform konfiguriert werden, wie der bzw. die Cluster, für den bzw. die das Quorum bereitgestellt wird. Beispiel: Ein x86-basierter Rechner, auf dem Solaris 9 OS ausgeführt wird, kann als Quorum-Server für ein SPARC-basierten Cluster konfiguriert werden, auf dem Solaris 10 OS ausgeführt wird.
Ein Quorum-Server kann auf einem Cluster-Knoten konfiguriert werden, um Quorum für andere Cluster bereitzustellen als dem Cluster, zu dem der Knoten gehört. Ein Quorum-Server, der auf einem Cluster-Knoten konfiguriert ist, ist jedoch nicht hochverfügbar.
In diesem Abschnitt werden Fehler, Auslassungen sowie hinzugefügte Informationen zu den Sun Cluster-Manpages behandelt.
Im folgenden überarbeiteten Abschnitt "Übersicht" sowie im neu hinzugefügten Abschnitt "Optionen" der Manpage ccp(1M) wird die neue Secure Shell-Unterstützung für Cluster Control Panel-(CCP-)-Dienstprogramme beschrieben:
SYNOPSIS
$CLUSTER_HOME/bin/ccp [-s] [-l username] [-p ssh-port] {clustername | nodename} |
OPTIONEN
Die folgenden Optionen werden unterstützt:
Gibt den Benutzernamen für die ssh-Verbindung an. Diese Option wird an das Dienstprogramm cconsole, crlogin oder cssh weitergegeben, wenn das Dienstprogramm von CCP aus gestartet wird. Das Dienstprogramm ctelnet ignoriert diese Option.
Wenn die Option -l nicht angegeben ist, wird der Benutzername, der CCP gestartet hat, übernommen.
Gibt die zu verwendende Secure Shell-Portnummer an. Diese Option wird an das Dienstprogramm cssh weitergegeben, wenn das Dienstprogramm von CCP aus gestartet wird. Die Dienstprogramme cconsole, crlogin und ctelnet ignorieren diese Option.
Wenn die Option -p nicht angegeben ist, wird Portnummer 22 für sichere Verbindungen verwendet.
Gibt an, dass anstelle von telnet-Verbindungen Secure Shell-Verbindungen zu Knotenkonsolen verwendet werden. Diese Option wird an das Dienstprogramm cconsole weitergegeben, wenn das Dienstprogramm von CCP aus gestartet wird. Die Dienstprogramme crlogin, cssh und ctelnet ignorieren diese Option.
Wenn die Option -s nicht angegeben ist, verwendet das cconsole-Dienstprogramm telnet-Verbindungen für Konsolenverbindungen.
Um die Option -s zu überschreiben, heben Sie im Menü "Optionen" der grafischen Benutzeroberfläche (GUI) von cconsole die Auswahl des Kontrollkästchens "SSH verwenden" auf.
Im folgenden überarbeiteten Abschnitt "Übersicht" sowie im neu hinzugefügten Abschnitt "Optionen" der hier zusammengefassten Manpages cconsole, crlogin, cssh und ctelnet wird die neue Secure Shell-Unterstützung für Cluster Control Panel-Dienstprogramme beschrieben:
SYNOPSIS
$CLUSTER_HOME/bin/cconsole [-s] [-l username] [clustername… | nodename…] $CLUSTER_HOME/bin/crlogin [-l username] [clustername… | nodename…] $CLUSTER_HOME/bin/cssh [-l username] [-p ssh-port] [clustername… | nodename…] $CLUSTER_HOME/bin/ctelnet [clustername… | nodename…] |
BESCHREIBUNG
Dieses Dienstprogramm stellt direkte Secure Shell-Verbindungen zu den Cluster-Knoten her.
OPTIONEN
Gibt den ssh-Benutzernamen für Remote-Verbindungen an. Diese Option ist mit den Befehlen cconsole, crlogin und cssh gültig.
Der Argumentwert wird gespeichert, sodass zu einem späteren Zeitpunkt angegebene Cluster und Knoten denselben Namen beim Verbindungsaufbau verwenden.
Wenn die Option -l nicht angegeben ist, wird der Benutzername, der den Befehl gestartet hat, übernommen.
Gibt die zu verwendende Secure Shell-Portnummer an. Diese Option ist mit dem Befehl cssh gültig.
Wenn die Option -p nicht angegeben ist, wird Portnummer 22 für sichere Verbindungen verwendet.
Gibt an, dass anstelle von telnet-Verbindungen Secure Shell-Verbindungen zu Knotenkonsolen verwendet werden. Diese Option ist mit dem Befehl cconsole gültig.
Wenn die Option -s nicht angegeben ist, verwendet das Dienstprogramm telnet-Verbindungen für Konsolenverbindungen.
Um die Option -s von der grafischen Benutzeroberfläche (GUI) des Dienstprogramms cconsole aus zu überschreiben, heben Sie im Menü "Optionen" die Auswahl des Kontrollkästchens "SSH verwenden" auf.
Die Beschreibung des Unterbefehls remove impliziert, dass der Befehl bei bestimmten Voraussetzungen nicht ausgeführt werden kann. Der Befehl kann unter diesen Voraussetzungen ausgeführt werden, die Ergebnisse können den Cluster jedoch negativ beeinflussen. Im Folgenden wird eine genauere Beschreibung der Anforderungen und das Verhalten für den Unterbefehl remove gegeben:
Folgen Sie den folgenden Anweisungen, um einen Knoten aus einem Cluster zu entfernen. Wenn Sie diese Anweisungen nicht befolgen, kann das Entfernen eines Knotens das Quorum des Clusters beeinträchtigen.
Heben Sie die Konfiguration des zu entfernenden Knotens auf allen entsprechenden Quorum-Geräten auf, es sei denn, Sie geben auch die Option -f an.
Stellen Sie sicher, dass der zu entfernende Knoten kein aktives Cluster-Mitglied ist.
Entfernen Sie keinen Knoten aus einem Dreiknoten-Cluster, es sei denn, mindestens ein gemeinsam genutztes Quorum-Gerät ist konfiguriert.
Der Befehl clnode remove entfernt einen Teilsatz der Verweise auf den Knoten aus der Cluster-Konfigurationsdatenbank. Wenn Sie zudem die Option -f angeben, entfernt der Unterbefehl alle Verweise auf den Knoten.
Bevor Sie den Befehl clnode remove zum Entfernen eines Knotens aus dem Cluster erfolgreich verwenden können, müssen Sie zunächst den Befehl claccess add verwenden, um den Knoten der Cluster-Authentifizierungsliste hinzuzufügen, falls dieser noch nicht in der Liste vorhanden ist. Verwenden Sie den Befehl claccess list oder claccess show, um die aktuelle Cluster-Authentifizierungsliste anzuzeigen. Verwenden Sie anschließend aus Sicherheitsgründen den Befehl claccess deny-all, um zukünftigen Zugriff auf die Cluster-Konfiguration durch einen Cluster-Knoten zu verhindern. Weitere Informationen finden Sie auf der Man Page claccess(1CL).
Die folgende Option fehlt auf der Man Page clresource(1CL):
Diese Option gibt an, dass der Befehl auf Ressourcen angewendet wird, deren Ressourcengruppen angehalten sind, vorausgesetzt, Sie geben den Operanden + an. Wenn Sie den Operanden + ohne die Option u angeben, ignoriert der Befehl alle Ressourcen, deren Ressourcengruppen angehalten sind.
Die Option -u ist gültig, wenn der Operand + für die Unterbefehle clear, disable, enable, monitor, set und unmonitor angegeben ist.
In der Beschreibung des Operanden + sollte darauf hingewiesen werden, dass der Befehl bei der Verwendung des Operanden mit den Unterbefehlen clear, disable, enable, monitor, set oder unmonitor alle Ressourcen ignoriert, deren Ressourcengruppen angehalten sind, es sei denn, Sie geben die Option -u ebenfalls an.
Die in den Definitionen der Operanden + und - angeführten Beispiele für die Optionen -p, -x und -y sind fehlerhaft. Die Definitionen sollten wie folgt lauten:
Fügt einen Wert bzw. mehrere Werte einem Zeichenfolgen-Array-Wert hinzu. Dieser Operator wird nur für den festgelegten Unterbefehl akzeptiert. Sie können diesen Operator nur für solche Eigenschaften angeben, die Listen mit Zeichenfolgenwerten akzeptieren, beispielsweise Resource_dependencies.
Entfernt einen Wert bzw. mehrere Werte aus einem Zeichenfolgen-Array-Wert. Dieser Operator wird nur für den festgelegten Unterbefehl akzeptiert. Sie können diesen Operator nur für solche Eigenschaften angeben, die Listen mit Zeichenfolgenwerten akzeptieren, beispielsweise Resource_dependencies.
In der Befehlssyntax und -beschreibung des Unterbefehls evacuate wird fälschlicherweise angegeben, dass Sie mehr als einen Knoten bzw. eine Zone mit einem Befehlsaufruf herunterfahren können. Mit dem Befehl evacuate kann jedoch jeweils nur ein Knoten oder eine Zone angegeben werden.
Die folgende Option fehlt auf der Man Page clresourcegroup(1CL):
Diese Option gibt an, dass der Befehl auf angehaltene Ressourcen angewendet wird, vorausgesetzt, Sie geben den Operanden + an. Wenn Sie den Operanden + ohne die Option u angeben, ignoriert der Befehl alle angehaltenen Ressourcengruppen.
Die Option -u ist gültig, wenn der Operand + für die Unterbefehle add-node, manage, offline, online, quiesce, remaster, remove-node, restart, set, switch und unmanage angegeben ist.
In der Beschreibung des Operanden + sollte darauf hingewiesen werden, dass der Befehl bei der Verwendung des Operanden mit den Unterbefehlen add-node, manage, offline, online, quiesce, remaster, remove-node, restart, set, switch oder unmanage alle angehaltenen Ressourcengruppen ignoriert, es sei denn, Sie geben auch die Option -u an.
Die Verwendung der Eigenschaft Network_resources_used wurde in Sun Cluster 3.2 geändert. Wenn Sie dieser Eigenschaft keinen Wert zuweisen, wird dieser Wert automatisch vom RGM basierend auf der Einstellung der Eigenschaften der Ressourcenabhängigkeiten aktualisiert. Sie müssen die Einstellung für diese Eigenschaft nicht direkt festlegen. Legen Sie stattdessen die Eigenschaft Resource_dependencies, Resource_dependencies_offline_restart, Resource_dependencies_restartoder Resource_dependencies_weak fest.
Um die Kompatibilität mit früheren Versionen der Sun Cluster-Software zu gewährleisten, können Sie den Wert der Eigenschaft Network_resources_used weiterhin direkt festlegen. In diesem Fall wird der Wert für die Eigenschaft Network_resources_used nicht von den Einstellungen der Eigenschaften der Ressourcenabhängigkeiten abgeleitet.
Wenn Sie der Eigenschaft Network_resources_used einen Ressourcennamen hinzufügen, wird der Ressourcenname automatisch auch der Eigenschaft Resource_dependencies hinzugefügt. Diese Abhängigkeit kann nur aufgehoben werden, indem Sie sie aus der Eigenschaft Network_resources_used entfernen. Wenn Sie nicht sicher sind, ob der Eigenschaft Resource_dependencies oder Network_resources_used ursprünglich eine Netzwerkressourcen-Abhängigkeit hinzugefügt wurde, entfernen Sie die Abhängigkeit aus beiden Eigenschaften. Der folgende Befehl entfernt beispielsweise eine Abhängigkeit der Ressource r1 von der Netzwerkressource r2. Dies geschieht unabhängig davon, ob die Abhängigkeit der Eigenschaft Network_resources_used oder Resource_dependencies hinzugefügt wurde:
# clresource set -p Network_resources_used-=r2 -p Resource_dependencies-=r2 r1 |
Die Man Page r_properties(5) enthält falsche Beschreibungen der Eigenschaften Resource_dependencies, Resource_dependencies_offline_restart , Resource_dependencies_restart und Resource_dependencies_weak. Eine richtige Beschreibung dieser Eigenschaften finden Sie unter Resource Properties in Sun Cluster Data Services Developer’s Guide for Solaris OS.
In der Beschreibung der Ressourceneigenschaft Skalierbar fehlt eine Anmerkung zur Unterstützung skalierbarer Dienste in nicht globalen Zonen. Diese Unterstützung ist für Ressourcen gewährleistet, deren Ressourcentypeigenschaft Failover als FALSCH und deren Ressourceneigenschaft Skalierbar als WAHR festgelegt ist. Diese Kombination der Eigenschaften gibt einen skalierbaren Dienst an, der eine SharedAddress-Ressource für den Netzwerklastenausgleich verwendet. In Sun Cluster 3.2 können Sie einen skalierbaren Dienst dieses Typs in einer Ressourcengruppe konfigurieren, die in einer nicht globalen Zone ausgeführt wird. Sie können einen skalierbaren Dienst jedoch nicht für die Ausführung in mehreren nicht globalen Zonen auf demselben Knoten konfigurieren.
Die Beschreibung der Ressourcentypeigenschaft Failover enthält eine falsche Anmerkung zur Unterstützung skalierbarer Dienste in nicht globalen Zonen in Sun Cluster 3.2. Diese Unterstützung ist für Ressourcen gewährleistet, deren Ressourcentypeigenschaft Failover als FALSCH und deren Ressourceneigenschaft Skalierbar als WAHR festgelegt ist.
Nicht richtig: Sie können keinen skalierbaren Dienst dieses Typs in Zonen verwenden.
Korrekt: Sie könenn einen skalierbaren Dienst dieses Typs in einer Ressourcengruppe konfigurieren, die in einer nicht globalen Zone ausgeführt wird. Sie können einen skalierbaren Dienst jedoch nicht für die Ausführung in mehreren nicht globalen Zonen auf demselben Knoten konfigurieren.
Die folgenden Informationen ergänzen den Abschnitt "Beschreibung" der Manpage serialport(4):
Um Secure Shell-Verbindungen zu Knotenkonsolen zu unterstützen, geben Sie in der Datei /etc/serialports den Namen des Konsolenzugriffsgeräts und die Secure Shell-Portnummer für jeden Knoten an. Wenn Sie die standardmäßige Secure Shell-Konfiguration auf dem Konsolenzugriffsgerät verwenden, geben Sie die Portnummer 22 an.
Auf der Manpage SUNW.Event(5) fehlt die Anmerkung, dass unter Solaris 10 OS der Cluster Reconfiguration Notification Protocol (CRNP) ausschließlich in der globalen Zone ausgeführt werden kann.