Überprüfung der Benutzer Equivalenz mit Cluvfy unter Oracle 10g und Solaris 10 schlägt fehl

Ziel

Dieser Blogeintrag beschreibt ein Problem bei der Ausführung des Cluster Verification Utility (Cluvfy) für eine angehende Oracle 10g Release 2 RAC Installation unter Solaris 10.

 

 

Umgebung

Das hier beschriebende Problem trat in einer Solaris 10 Umgebung auf, die aus zwei Knoten bestand und in der ein Oracle 10g Release RAC installiert werden sollte.

root@rac01 $ cat /etc/release                     Oracle Solaris 10 9/10 s10x_u9wos_14a X86      Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.                             Assembled 11 August 2010 

 

Problem

Bevor die Installation der Clusterware gestartet wurde, wurden die beiden Knoten mithilfe von Cluvfy überprüft. 

oracle@rac01 $ cd /u01/app/oracle/software/clusterware/cluvfy oracle@rac01 $ ./runcluvfy.sh stage -pre crsinst -n rac01,rac02-verbose  Vorprüfungen für Cluster-Services-Setup werden ausgeführt.  Knotenzugänglichkeit wird geprüft...  Prüfung: Knotenzugänglichkeit von Knoten "rac01"   Zielknoten                            Zugänglich?   ------------------------------------  ------------------------   rac01                                 ja   rac02                                 ja Ergebnis: Prüfung auf Knotenzugänglichkeit von Knoten "rac01" erfolgreich.   Benutzeräquivalenz wird überprüft...  Prüfung: Benutzeräquivalenz für Benutzer "oracle"   Knotenname                            Kommentar   ------------------------------------  ------------------------   rac01                                nicht erfolgreich   rac02                                nicht erfolgreich Ergebnis: Prüfung auf Benutzeräquivalenz nicht erfolgreich für Benutzer "oracle".  ERROR: Benutzeräquivalenz auf allen Knoten nicht verfügbar Überprüfung kann nicht fortgesetzt werden   Vorprüfung von Cluster-Services-Setup war auf allen Knoten nicht erfolgreich. 

Cluvfy brach bei der Überprüfung der Benutzerequivalenz ab. Eine mögliche Fehlerquelle ist eine fehlerhafte SSH Konfiguration. Damit Cluvfy alle beteiligten Knoten überprüfen kann, muss Cluvfy per SSH und ohne Eingabe eines Passwortes auf alle Knoten (auch den eigenen) zugreifen können.

oracle@rac01 $ ssh rac01 hostname rac01 oracle@rac01 $ ssh rac02 hostname rac02

Die SSH Konfiguration war fehlerfrei.

 

Um das Problem zu identifizieren wird Cluvfy im Debug Modus ausgeführt. Um den Debug Modus und das Schreiben eines Tracefiles unter Oracle 10g Release 2 zu aktivieren, muss die runcluvfy.sh Datei angepasst werden. Ich lege aber zuvor eine Kopie dieser Datei an, die ich runclufvy-debug.sh nenne.

oracle@rac01 $ cp runcluvfy.sh runcluvfy-debug.sh

Anschließend wird diese Datei editiert und die folgende Zeit auskommentiert.

oracle@rac01 $ vi runcluvfy-debug.sh # Cleanup the home for cluster verification software ALT: $RM -rf $CV_HOME NEU: # $RM -rf $CV_HOME

Im letzten Schritt wird ein Zielverzeichnis angelegt, die Umgebungsvariable CV_HOME gesetzt und das Tracing aktiviert.

oracle@rac01 $ mkdir /tmp/cvu/ oracle@rac01 $ CV_HOME=/tmp/cvu/ oracle@rac01 $ export CV_HOME oracle@rac01 $ export SRVM_TRACE=true

Für weitere Informationen siehe My Oracle Support Note 986822.1.

 

Das System kann nun mit Cluvfy erneut überprüft werden. Es muss darauf geachtet werden, dass die geänderte Datei runcluvfy-debug.sh verwendet wird.

oracle@rac01 $ ./runcluvfy-debug.sh stage -pre crsinst -n bonecrusher01,bonecrusher02 -verbose

Cluvfy legt in dem Verzeichnis $CV_HOME (in diesem Fall /tmp/cvu) ein Unterverzeichnis an, das als Namen die aktuelle Prozess ID der Benutzersitzung (z.B. 1922) verwendet.

 

Die Analyse des Tracefiles ergab folgendes Ergebnis.

oracle@rac01 $ cd /tmp/cvu/1922/cv/log oracle@rac01 $ more cvutrace.log.0 ... [Worker 0] [10:45:17:528] [UnixSystem.checkRemoteExecutionSetup:1838]  checkRemoteExecutionSetup:: Error checking user equivalence using Secured Shell '/usr/local/bin/ssh'; Tue Aug 23 10:45:17 CEST 2011 ...

Der Pfad für ssh ist falsch bzw. existiert in dieser Form unter Solaris nicht. Cluvfy kann dadurch nicht die Benutzer Equivalenz überprüfen und bricht mit einem Fehler ab.

 

Lösung

Um dieses Problem zu beheben wird ein symbolischer Link an die Stelle gesetzt, an der Cluvfy ssh erwartet. Das Verzeichnis /usr/local/bin muss zuvor angelegt werden.

root@rac01 $ mkdir -p /usr/local/bin root@rac01 $ ln -s /usr/bin/ssh /usr/local/bin/ssh

Cluvfy benötigt im späteren Verlauf zusätzlich noch scp. Auch hierfür muss ein symbolischer Link angelegt werden.

root@rac01 $ ln -s /usr/bin/scp /usr/local/bin/scp

Hinweis: Die oben aufgeführten Befehle müssen auf allen Knoten ausgeführt werden.

 

Bei der erneuten Ausführung von Cluvfy sollten nun keine Probleme mehr bei der Überprüfung der Benutzer Equivalenz auftreten.

Leave a Reply

Your email address will not be published.