Table of Contents
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.