| Oracle® Virtual Assembly Builderユーザーズ・ガイド 11g リリース1 (11.1.1.6) B66713-01 |
|
 前 |
 次 |
次の各項では、Oracle Virtual Assembly Builderのトラブルシューティングに関するテクニックについて説明し、トラブルシューティング項目を特定します。
この項では、一般的な問題のトラブルシューティングについて説明します。
abctlまたはabstudio.shを起動しようとしてこのエラーが表示され、稼働しているOracle Virtual Assembly Builderクライアントが他にないことを確認した場合、マシンでファイル・ロックが不足している可能性があります。
Oracle Virtual Assembly Builder Studioまたはabctlを使用して同時操作を実行しているときにも、このようなエラーが表示されることがあります。この問題を解決するには、ロックの解放が遅くなる環境上の問題がないかどうかをチェックしてください。
phone homeのタイムアウトをトラブルシューティングする手順は、次のとおりです。
Oracle Virtual Assembly Builderホストのファイアウォールがオフになっていることを確認します。
rootとして、次のコマンドを実行します。
$/sbin/service iptables status $/sbin/service iptables stop
マシンの再起動時に自動的に起動するようにファイアウォールが構成されている場合があります。これを回避するには、次のコマンドを実行して完全にオフにします。
$/sbin/chkconfig iptables off
phone homeのデフォルトのタイムアウトは、15分です。タイムアウトは、<Deployer WLS domain root>/ovab/config/deployer/deployer.propertiesで増やすことができます。
このファイルが存在しない場合は、作成してphoneHomeTimeout=<number of seconds>のような行を追加します。
この項では、イントロスペクションおよびファイル・セット取得の問題のトラブルシューティングについて説明します。
デプロイされた仮想マシン(VM)のイントロスペクションは、イントロスペクションに使用される一時ディレクトリがマウントされたNFS共有で、NFSファイルがロックされている場合、完了に失敗することがあります。この問題を回避するには、ロックをオフにしてNFSファイル・システムを再マウントします。
mount -o nolock example:/scratch /net/example/scratch
リモート操作のログは、リモート操作の最後にローカル・ディレクトリ$AB_INSTANCE/logs/remote_<remote machine name>/にコピーされます。たとえば、リモート・マシンがabc12345の場合、ログは$AB_INSTANCE/logs/remote_abc12345.example.com/に格納されます。
デフォルトのリモート作業ディレクトリは/tmp/abRemote_<remote username>ですが、これは、-remoteWorkingDirフラグを使用してオーバーライドできます。
リモート・イントロスペクション/パッケージングを実行できず、「接続できません」エラーが表示される場合、1つの可能性として、リモート・マシンでipv6を実行しているのにsshd_configファイルが正しくないことが考えられます。
リモート・システムがipv6およびipv4を使用するように構成されている場合、次の行がsshd_configファイルに指定されている必要があります。
AddressFamily any
(AddressFamily inetではありません)
リモート・パスワードの入力後にリモート操作がハングする場合、強制終了された前のリモート操作から残された孤立したリモート・プロセスによる可能性があります。リモート作業ディレクトリがリモート・プロセス下から移されると、この事象が発生する場合があります。リモート・マシンに移動して孤立したリモート・プロセスをすべて強制終了し、リモート作業ディレクトリをクリーンアップして再度リモート操作を試行してください。
リモート・プロセスは、次のように表示されます。
aime1 11662 1 0 11:51 ? 00:00:01 /tmp/user/abRemote_aime1/ab_home/jre/jre/bin/java -Doracle.core.ojdl.logging.config.file=/tmp/user/abRemote_aime1/ab_instance/config/logging.xml -Djava.util.logging.config.class=oracle.core.ojdl.logging.LoggingConfiguration -Djava.security.egd=file:/dev/./your -Dassemblybuilder.spif.app=apps/remotingapp -jar /tmp/kaw/abRemote_aime1/ab_home/jlib/oracle.as.assemblybuilder.spif_0.1.0.jar
リモート操作(イントロスペクションおよびファイル・セット作成)が正常に機能するように、参照システムのSSHポート転送を有効にする必要があります。次のようにして、ssh構成ファイルをチェックします。
~/.ssh/config /etc/ssh/ssh_config
指定したremoteUserのシェルがログイン時にstdout/stderrに出力する場合、次のエラーが発生することがあります。
Error: Error initializing the remote connection. Caused by: OAB-90061: Unable to create connection to remote server. Cause: Timed out trying to connect to IPV4 and IPV6 sockets.
リモート・ユーザーのプロファイルおよびrcファイルをチェックし、これを実行するロジックを取り除きます。あるいは、別のリモート・ユーザーを指定し、sudoUserパラメータを使用して参照インストールを調査/取得する権限を持つユーザーを指定します。
テンプレート作成操作が失敗した場合、次のことをチェックします。
イントール時またはインストール後、$ORACLE_HOME/oracleRoot.shをrootとして実行したことを確認します。
modifyjeosがインストールされていることを確認します。
ovaユーティリティがインストールされていることを確認します。
有効なベース・イメージ(System.img)およびvm.cfgファイルがあることを確認します。ファイル権限が正しいことを確認します。
ディスク領域が不足していないことを確認します。
取得するファイル・セットに対してループ・デバイス数が十分であることを確認します。D.3.1項「不十分なループ・デバイス数」を参照してください。
大量のファイル・セットがある一般製品のテンプレートを作成するにはOracle Virtual Assembly BuilderホストのLinuxループ・デバイス数が足りないという問題が発生する場合があります。
テンプレートの作成時、Oracle Virtual Assembly Builderおよびmodifyjeosでは、テンプレートのディスクごとに使用可能なLinuxループ・デバイスが1つ(つまり、System.imgおよびAB.imgのそれぞれに1つと、製品ディスクごとに1つ)必要です。一般的なOracle Linuxシステムには、ループ・デバイスが7つしかありません。つまり、最大5つのファイル・セットがあるテンプレートに対してテンプレートを作成できます。
ファイル・セットがそれより多いアプライアンスのテンプレートを作成するには、ループ・デバイスを追加作成する必要があります。これを実行する方法は、次のとおりです。
/etc/modprobe.confを編集します。次のような行を追加します。
options loop max_loop=<n>
<n>は、作成するループ・デバイスの数です。
rootとして次のコマンドを実行し、Linuxカーネル・ループ・モジュールをアンロードおよびリロードします。
# /sbin/modprobe -r loop # /sbin/modprobe -v loop
新しいループ・デバイスが作成されたことを確認します。
$ ls -l /dev/loop*
<n>個のループ・デバイスが見つかります。
この項では、デプロイヤ通信の失敗のトラブルシューティングについて説明します。
次のエラーが発生することがあります。
Caused by: Invalid deployer response returned. Cause: OAB-113409 - An invalid response was returned by the deployer. Action: OAB-113409 - Please check the deployer log for additional details.
デプロイヤをホストするOracle WebLogic Serverのデプロイメントをチェックし、デプロイヤ・アプリケーションの状態が「アクティブ」であり、ステータスが「OK」であることを確認します。
デプロイヤとやり取りしようとして401/403エラーが発生した場合、デプロイヤをホストするOracle WebLogic Serverのコンソールで次の項目をチェックします。
「デプロイメント」 > デプロイヤに移動し、セキュリティ・モデルが「CustomRoles」であることを確認します。
「デプロイメント」 > デプロイヤ > [セキュリティ] > [ロール] > 「Application Admin」に移動し、条件にCloud AdminsグループまたはApplication Adminsグループが含まれていることを確認します。
「デプロイメント」 > デプロイヤ > [セキュリティ] > [ロール] > 「Cloud Admin」に移動し、条件にCloud Adminsグループが含まれていることを確認します。
「セキュリティ・レルム」 > 「myrealm」 > [ユーザーとグループ] > [グループ]に移動し、「Application Admins」と「Cloud Admins」が存在し、DefaultAuthenticatorによって処理されることを確認します。
「セキュリティ・レルム」 > 「myrealm」 > [ユーザーとグループ] > [ユーザー]に移動し、「applicationAdmin」と「cloudAdmin」が存在し、DefaultAuthenticatorによって処理されることを確認します。
「デプロイメント」 > デプロイヤ > [セキュリティ] > [URLパターン]に移動し、root url-patternにロール定義がないことを確認します。
クライアントで接続を作成するときに、ユーザー名が手順5で示した2つのうちのいずれかであり、そのユーザーのパスワードとともに指定されていることを確認します。
登録が応答なしになった場合、次のことをチェックします。
登録がまったく成功していない場合は、Oracle VMコンソールを直接使用(Oracle Virtual Assembly Builderをバイパス)してテンプレートの登録を試みます。この方法が成功しない場合、問題はOracle VM環境にあります。
非常に大規模なアセンブリ・アーカイブがあるか、ネットワークが低速の場合、デプロイヤが実行されているOracle WebLogic ServerとOracle VM Managerが実行されているOracle WebLogic Serverの両方について、「スタック・スレッド最大時間」設定の増加が必要なことがあります。管理コンソールで、サーバーの「チューニング」タブを使用してこの設定にアクセスします。
この項では、デプロイメントの失敗のトラブルシューティングについて説明します。
Studioログまたはデプロイヤ・ログから失敗の原因を特定できない場合、調査を続行する必要があります。Oracle VM Managerコンソールにログインし、アセンブリのVMが作成および起動されているかどうかを確認します。
VMが作成されなかった理由を示すものがないか、デプロイヤと、Oracle VMおよびOracle VM Serverのログをチェックします。
|
注意: 特にOracle Virtual Assembly Builder以外でクリーンアップ・タイプのアクティビティがOracle VM環境で実行された場合、デプロイヤの状態キャッシュがOracle VM環境と同期しなくなる可能性があります。アセンブリがOracle VM環境から実際には削除されている場合に、デプロイヤでは登録またはデプロイされていると記録されていることがあります。この事象が発生した場合、Oracle Virtual Assembly Builderを使用してアーカイブを登録解除およびアンデプロイしてから、もう一度登録およびデプロイする必要があります。 |
VMが作成されたのに実行されない場合、次の手順を実行します。
VMが起動されなかった理由を示すものがないか、デプロイヤと、Oracle VMおよびOracle VM Serverのログをチェックします。
手動によるVMの起動を試み、有効な出力が得られるかどうかを確認します。
失敗したVMを作成したOracle VM Serverマシンにログインします(Oracle VM Managerコンソールから、プール内のどのマシンがVMを所有しているかを確認できます)。
問題のVMのvm.cfgを探します。このファイルは/OVS/Repositories下のどこかにあり、Oracle VMコンソールからのIDがパスに含まれています。
xm create -f <vm.cfg file>コマンドを使用してVMを起動します。
ディスク・イメージのマウントを試み、ログが作成されるかどうかを確認します。(これは、VMが起動した後、なんらかの理由で停止した場合が考えられます)。Oracle Enterprise Linuxイメージは複数のディスクで構成されます。AB.img、System.img、Product_001.imgなど、該当するディスクをマウントする必要があります。
Oracle Virtual Assembly BuilderログはAB.imgディスクにあります。ただし、Oracle VM環境に登録されると、そのイメージの名前は変わります。新しい名前になったイメージの場所を探すには、vm.cfgを見つける必要があります。このファイルは/OVS/Repositories下のどこかにあり、Oracle VMコンソールからのVM IDがパスに含まれています。
見つかったイメージ・ファイルへのパスを使用して、ループ・デバイスを特定します。
#kpartx -a <path to img file> #kpartx -l <path to img file>
前のコマンドのリスト出力から、どのループ・デバイスがディスクにマップされているかを特定できます。ディスクをマウントし、ループ・デバイスを指定します。
#mount /dev/mapper/loop?p? /mnt
上の最初の疑問符(?)はループ・デバイス数を表し、通常ゼロですが異なる数値でもかまいません。2番目の疑問符はパーティション番号で、通常ゼロですが異なる数値でもかまいません。
/mntに移動し、ファイルを調べます。再構成がログの作成に十分である場合、AB.imgのにログは/mnt/logsにあります。
次のように入力します。
#umount /dev/mapper/loop?p? #kpartx -d AB.img
マシンのネットワーク構成がなんらかの理由で正常に完了しませんでした。DHCPを使用している場合は、Oracle VM環境でDHCPをサポートしていることを確認します。静的IPアドレスを使用している場合は、対応するホスト名をデプロイメント・プランに指定していることも確認します。この指定は必須です。
次のネットワーク関連プロパティをすべてデプロイメント・プランに指定する必要があります。
アセンブリ・レベル
network_name (ターゲット(Oracle VM)環境のネットワーク名と一致する必要あり)
各アプライアンスのネットワーク・プロパティ内
hostname (静的IPを使用する場合)
default-gateway
dns-domains (1つのみサポート)
dns-servers (1つのみサポート)
各アプライアンスのネットワーク・インタフェース(NIC)ごと
ip_address (静的IPを使用する場合)
netmask
usedhcp (静的IPを使用する場合はfalse)
VMにアクセスする手順は、次のとおりです。
失敗したVMを作成したOracle VM Serverマシンにログインします(Oracle VM Managerコンソールから、プール内のどのマシンがVMを所有しているかを確認できます)。
xm listコマンドを実行します。
返されたリストでVMを探します。Oracle VM ManagerコンソールでVM IDを探します。
xm console <VM ID>コマンドを実行し、[Enter]を押して資格証明(user: root、password: テンプレート作成時に指定したパスワード)を指定します。
失敗をトリアージする手順は、次のとおりです。
/assemblybuilder/logs下のログをチェックします。ログがない場合は、次の手順を続行します。
abサービスがインストールされたかどうかを確認します。abサービスは、/etc/init.d/abにインストールされます。そこにない場合は、oraclevm-templateサービス・ログ/var/log/oraclevm-templateを調べます。oraclevm-templateサービスによって、abサービスはインストールされます。
abサービスがない場合、ORACLE_HOMEのab_service.shおよびoraclevm-template.shに対する権限が正しいことを確認します。これらのファイルは、実行可能です。実行可能でない場合は、権限を修正し、アセンブリ・アーカイブを再作成してアップロードおよび登録し、デプロイを再試行します。
遅延バインドが正しくない、またはVMに送信されなかったと考えられる場合は、/assemblybuilder/etc/vmapi get +コマンドを実行できます。
このコマンドにより、遅延バインドが出力されます。
VMが起動しpingできる場合、VMのネットワーク構成は正常に完了しました。
失敗したVMにログインして、/assemblybuilder/logs下のログをチェックします。ログ・セクションで、各種ログ・ファイルの内容に関する詳細を確認します。rootユーザーおよびテンプレートの作成時に指定したパスワードを使用して、マシンへのsshを実行できる必要があります。
遅延バインドが正しくない、またはVMに送信されなかったと考えられる場合は、/assemblybuilder/etc/vmapi get +コマンドを実行できます。
このコマンドにより、遅延バインドが出力されます。
この項には、ログの場所と説明が記載されています。複数の異なるログとログの場所がありますが、これらは失敗をトリアージする時期を知るのに役立ちます。
Studioログのログ・レベルは、$AB_INSTANCE/config/logging.xmlを編集して変更することができます。目的のレベルを指定して次の行を変更します。
<logger name="oracle.as.assemblybuilder" level="FINE">
ローカル・ログ
$AB_INSTANCE/logs/assemblybuilder.log
$AB_INSTANCE/logs/bottler/* - テンプレート作成時に使用されるmodifyjeosツールからの出力
リモート・ログ
リモート操作のログは、リモート操作の最後にローカル・ディレクトリ$AB_INSTANCE/logs/remote_<remote machine name>/にコピーされます。たとえば、リモート・マシンがabc12345の場合、ログは$AB_INSTANCE/logs/remote_abc12345.example.com/に格納されます。
デフォルトのリモート作業ディレクトリは/tmp/abRemote_<remote username>ですが、これは、-remoteWorkingDirフラグを使用してオーバーライドできます。
デプロイヤ・アプリケーション・ログ・メッセージは、デプロイヤ・アプリケーションがデプロイされたWLSのサーバー・ログまたはドメイン・ログ、あるいはその両方にあります。また、Oracle WebLogic Serverのstdout/stderrにも関連情報やスタック・トレースが含まれることがあります。
<Deployer WLS domain root>/servers/<server targeted by Deployer app>/logs/*
Oracle VM
/u01/app/oracle/ovm-manager-3/machine1/base_adf domain/servers/AdminServer/logs/AdminServer.log
Oracle VM Server
/var/log/ovs-agent.log
/assemblybuilder/logs/ab.out - Oracle Virtual Assembly Builderインフラストラクチャ・コードおよびプラグイン・コードからのstdout/stderrおよび進捗メッセージ
/assemblybuilder/logs/assemblybuilder.log - Oracle Virtual Assembly Builderインフラストラクチャ・コードおよびプラグイン・コードからのログ・メッセージ
/assemblybuilder/logs/command.out - RehydrateUtils.runCommand()メソッドまたはrunCommandAs()メソッドを使用して起動されたコマンドの環境およびコマンド詳細
/assemblybuilder/logs/proc.<unique>.log - 渡されたdaemonフラグがtrueだったRehydrateUtils.runCommand()またはrunCommandAs()を使用して起動されたプロセスからのstdout/stderr
