| Oracle® Enterprise Managerライフサイクル管理ガイド 12cリリース5 (12.1.0.5) B66837-13 |
|
 前 |
 次 |
ここでは、プロビジョニングやパッチ適用のデプロイメント・プロシージャを使用する際に発生する可能性がある一般的な問題の解決方法を説明します。特に、次の内容について説明します。
ここでは、一般的なデータベース・プロビジョニングの問題に関してトラブルシューティングのヒントを示します。
後述の詳細を参照してください。
後述の詳細を参照してください。
後述の詳細を参照してください。
前提条件チェックの出力を詳しく分析します。ほとんどの前提条件の失敗は自動的に修正されますが、デプロイメント・プロシージャが自動修正の環境要件のために失敗した可能性があります。次の原因が考えられます。
システムに対してローカルではないユーザーのグループ・メンバーシップ。ユーザーはディレクトリ・サービスに登録されるため、rootアクセス権を使用しても、デプロイメント・プロシージャでユーザーの属性を変更することはできません。
Solarisのゾーン分離。デプロイメント・プロシージャの実行ゾーンに、システム属性を変更する権限がない場合、デプロイメント・プロシージャの自動修正操作が失敗します。
後述の詳細を参照してください。
後述の詳細を参照してください。
データベースのプロビジョニングでバイナリを置くため、/tmpを除く一時ディレクトリを指定するには、次の手順を実行します。
デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。
「データベース・プロシージャ」ページで「Oracleデータベースのプロビジョニング」を選択し、「類似作成」をクリックします。
「類似作成プロシージャ」ページの「一般情報」タブで、デプロイメント・プロシージャの名前を入力します。
「プロシージャ・ユーティリティのステージング・パス」で、/tmpのかわりに使用するディレクトリ(例: /u01/working)を指定します。
「保存」をクリックします。
このデプロイメント・プロシージャはOracleデータベースのプロビジョニングに使用します。
後述の詳細を参照してください。
デプロイメント・プロシージャ内のステップが正常に実行したとき、返される終了コードは正の値です。ステップが失敗し、終了コードが正の値ではない場合、インシデントが生成され、OMSに格納されます。関連するすべてのログ・ファイルと診断情報(メモリー使用状況、ディスク・スペース、実行中プロセス情報など)が、パッケージ化されて格納されます。インシデント・コンソールにアクセスして、この情報をサービス・リクエストとしてパッケージ化して、My Oracle Supportにアップロードすることができます。新しいサービス・リクエストの作成方法の詳細は、インシデント・マネージャ・ページの「ヘルプ」をクリックします。
デプロイメント・プロシージャの実行ページでは、プロビジョニング操作に関連するすべてのリモート・ログ・ファイルがハイパーリンクとしてジョブ・ステップに表示されます。これらのハイパーリンクをクリックして、リモート・ログを表示できます。リモート・ログはOMSリポジトリに格納され、トラブルシューティングの際にMy Oracle Supportがアクセスすることができます。
後述の詳細を参照してください。
デプロイメント・プロシージャの実行が失敗した場合は、ジョブの実行詳細をチェックします。失敗したジョブ実行は再試行できます。または、失敗したステップを無視するように選択できます。たとえば、ディスク・スペース不足のためにデプロイメント・プロシージャの実行が失敗した場合は、ファイルを削除してからプロシージャの実行を再試行できます。デプロイメント・プロシージャの実行全体に影響しない問題(cluvyチェック・エラーなど)については、失敗したステップを無視して、デプロイメント・プロシージャを実行することができます。
ジョブ実行処理の再試行によって、「実行中」ステータスの新規ジョブ実行処理が作成されます。元のジョブ実行処理のステータスは変更されません。
失敗したステップを無視してプロシージャを再試行するには、次の手順を実行します。
プロシージャ・アクティビティ・ページで、関連するプロシージャをクリックします。
ジョブ・ステータス・ページで、失敗したステップのステータスをクリックします。
ステップ・ステータス・ページで、「無視」をクリックします。確認ページで「はい」をクリックします。
「再試行」をクリックします。失敗したステップが再試行されます。
ここでは、一般的なパッチ適用の問題に関してトラブルシューティングのヒントを示します。
ここでは、次のパッチ適用の問題について説明します。
後述の詳細を参照してください。
パッチ計画の分析中にパッチ計画が予期しないエラーで失敗しますが、資格証明は正しく、EMステージングの場所への書込み権限もあります。
たとえば、次のエラーがジョブの出力ページに表示されます。
”Unexpected error occurred while checking the Normal Oracle Home Credentials”
後述の詳細を参照してください。
ソフトウェア・ライブラリへのパッチのアップロード・ページを使用してパッチ・セットをアップロードするとき、パッチ属性を読み取れないというエラーが表示されることがあります。
次に例を示します。
ERROR:Failed to read patch attributes from the uploaded patch file <filename>.zip
後述の詳細を参照してください。
OPatchの更新ジョブを実行するとき、次のエラーで失敗することがあります。
2011-11-28 10:31:19,127 RemoteJobWorker 20236 ERROR em.jobs startDownload.772- OpatchUpdateLatest: java.lang.NullPointerException: Category, 'Oracle Software Updates', has no child named, 'OPatch' at oracle.sysman.emInternalSDK.core.patch.util. ComponentUtil.getComponentCategory (ComponentUtil.java:854)
2012年1月にリリースされたCloud Controlパッチを適用した後でも、次のエラーが表示されることがあります。
Category, 'Oracle Software Updates' already exists.
エラーが発生するのは、2つの「Patch Components」ディレクトリがソフトウェア・ライブラリで見つかった場合です。特に、パッチのアップロードまたはダウンロードのジョブを2つ(たとえば、OPatchパッチ・ダウンロード・ジョブと通常のパッチ・ダウンロード・ジョブ)実行すると、競合状態が生成し、Patch Componentsという名前のディレクトリが2つ作成されます。このように重複したディレクトリが作成されても、ソフトウェア・ライブラリにはエラーは表示されませんが、OPatchの更新ジョブを実行すると、ジョブがNullPointerExceptionで失敗します。
この問題を解決するには、次のいずれかを実行します。
ソフトウェア・ライブラリに2つの「Patch Components」ディレクトリが表示される場合は、エントリ数が少ない方のディレクトリを削除してから、失敗したパッチのアップロードまたはダウンロードのジョブを再試行します。ソフトウェア・ライブラリにアクセスするには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。
「Patch Components」ディレクトリは1つしか表示されないが、Oracleソフトウェアの更新がすでに存在するというエラーが表示される場合は、失敗したパッチのアップロードまたはダウンロードのジョブを再試行します。
この項では、次の問題について説明します。
後述の詳細を参照してください。
「プロキシ設定」ページの「My Oracle Supportとプロキシ接続」タブで、手動でプロキシ構成の詳細を指定すると、図F-1のような例外エラーが表示されることがあります。
ダイジェスト認証スキーマのみをサポートするプロキシ・サーバーの詳しい構成を指定した可能性があります。デフォルトでは、プロキシ・サーバーはBasic認証スキーマのみにマップされます。現在、ダイジェスト認証スキーマはサポートされていません。
この問題を解決するには、Basic認証スキーマを使用するようにプロキシ・サーバーを再構成します。
|
ヒント: HTTPクライアント・ロギングに関する接続の問題をより理解するため、次の手順を実行します。
|
ここでは、次のセキュリティの問題について説明します。
後述の詳細を参照してください。
パッチ計画を作成するときに、Oracleホーム優先資格証明の上書きを選択し、誤って、特権資格証明を通常Oracleホーム資格証明として設定すると(図F-2)、ログ・ファイルをEMStagedPatchesディレクトリに作成できないというエラーが表示されます。
次に例を示します。
”Unable to create the file <RAC_HOME>/EMStagedPatches/PA_APPLY_PATCH_09_02_2011_14_27_13.log"
次のエラーも表示されることがあります。
ERROR: SharedDeviceException. ACTION: Please check whether the configuration is supported or not.
この項では、次の問題について説明します。
後述の詳細を参照してください。
問題が管理リポジトリの詳細と計画の作成ウィザードのどちらに関連するかを判別します。このためには、ここで説明するコマンドとURLを使用して、管理リポジトリの詳細を取得してみてください。
URLによって正しい情報が返されるが、コンソールに表示されない場合は、計画の作成ウィザードに技術的な問題があります。この問題を解決するには、Oracleサポート・サービスにお問い合せください。
URLで返される情報が正しくない場合は、管理リポジトリに問題があります。この問題を解決するには、パッチ計画を再作成します。
管理リポジトリから詳細を取得するには、次のようにします。
パッチ計画のGUIDを取得します。次のコマンドを実行します。
select plan_guid from em_pc_plans where name='<name of the plan>”;
次に例を示します。
select plan_guid from em_pc_plans where name='t8';
このコマンドの結果は次のようになります。計画のGUIDをメモしてください。
PLAN_GUID -------------------- 96901DF943F9E3A4FF60B75FB0FAD62A
パッチ計画の一般情報(名前、タイプ、ステータス、計画の特権など)を取得します。このために次のURLを使用します。このような情報は、計画情報ステップや「レビューおよびデプロイ」ステップをデバッグするときに役立ちます。
https://<hostname>:<port>/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=planInfo
|
注意: このURLを使用してパッチ計画の情報を取得する前に、Cloud Controlにログインし、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「パッチと更新版」を選択します。 |
パッチの情報とパッチ計画に含まれる関連するターゲットの情報を取得します。このために次のURLを使用します。このような情報は、「パッチ」ステップや「確認」ステップをデバッグするときに役立ちます。
https://<hostname>:<port>/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=patches
パッチ計画で選択されたデプロイメント・オプションの情報を取得します。このために次のURLを使用します。このような情報は、「デプロイ・オプション」ステップや「資格証明」ステップをデバッグするときに役立ちます。
https://<hostname>:<port>/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=deploymentOptions
パッチ計画で設定された優先資格証明の情報を取得します。このために次のURLを使用します。このような情報は、「資格証明」ステップをデバッグするときに役立ちます。
https://<hostname>:port/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=preferredCredentials
パッチ計画で設定されたターゲット資格証明の情報を取得します。このために次のURLを使用します。このような情報は、「資格証明」ステップをデバッグするときに役立ちます。
https://<hostname>:port/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=targetCredentials
パッチ計画の競合のないパッチの情報を取得します。このために次のURLを使用します。このような情報は、「検証」ステップや「レビューおよびデプロイ」ステップをデバッグするときに役立ちます。
https://<hostname>:port/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=conflictFree
パッチ計画の抑制されたパッチの情報を取得します。このために次のURLを使用します。このような情報は、「パッチ」ステップをデバッグするときに役立ちます。
https://<hostname>:port/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=removedPatchList
後述の詳細を参照してください。
新しいパッチ計画を作成するとき、または既存のパッチ計画を編集するときに、新しいターゲットを追加すると、次のエラーが表示されます。
Wrong Platform. Expected: Oracle Solaris on SPARC (64-bit), found: null
管理リポジトリに、そのターゲットのプラットフォーム情報が含まれていない可能性があります。デフォルトでは、すべてのターゲットについて、ターゲットのOracleホームに存在するoraclehomeproperties.xmlファイルからインベントリ詳細が定期的に収集されます。インベントリ収集が完了していないか、失敗したために、管理リポジトリにデータが存在していない可能性があります。このような理由のため、該当のターゲットを追加することができません。
この問題を解決するには、ターゲットのOracleホームからインベントリ詳細を強制的に再収集します。
Oracleホームの詳細を取得するには、次の手順を実行します。
「ターゲット」メニューから「すべてのターゲット」を選択します。
「すべてのターゲット」ページの左側の「検索の絞込み」ペインで、「ターゲット・タイプ」メニューをクリックして展開します。
「ターゲット・タイプ」から「その他」をクリックし、「Oracleホーム」を選択します。
タイプが「Oracleホーム」のすべてのターゲットがリストされます。ホスト名を検索して、検索している「Oracleホーム」の詳細をドリルダウンすることもできます。
ターゲット・ホストの「Oracleホーム」からインベントリ詳細を取得するには、$EMDROOT/binディレクトリから次のコマンドを実行します。
$ emctl control agent runCollection <Oracle_Home_Target>:oracle_home oracle_home_config
ここで、<Oracle_Home_Target>は、プラットフォーム情報が存在しないターゲットのOracleホームの名前です。
次に例を示します。
$ emctl control agent runCollection db2_2_adc2170603:oracle_home oracle_home_config
この項では、次の問題について説明します。
後述の詳細を参照してください。
この問題を解決するには、Exadataターゲットで明示的にExadataプラグインをデプロイします。次の手順を実行します。
「Enterprise」メニューから、「拡張性」、「プラグイン」の順に選択します。
「プラグイン」ページの表から、デプロイするOracle Exadataプラグイン・バージョンを選択します。
「デプロイ先」をクリックし、「管理エージェント」を選択します。
「管理エージェント上のプラグインをデプロイします」ダイアログの「選択した管理エージェント」セクションで、「追加」をクリックしてプラグインをデプロイする管理エージェントを1つ以上選択し、「続行」をクリックします。次に「次へ」、「デプロイ」をクリックします。
この項では、次の問題について説明します。
後述の詳細を参照してください。
後述の詳細を参照してください。
後述の詳細を参照してください。
クラスタウェア・ターゲットにパッチを適用するパッチ計画を作成する際、「デプロイ・オプション」ページのパッチ対象セクションに、影響を受けるターゲットとなるクラスタASMとそのインスタンスが表示されません。これらは影響を受けるターゲットセクションにも表示されません。また、ホーム外モードでパッチ計画をデプロイした後、クラスタASMとそのインスタンスにメトリック収集エラーが表示されます。
この問題を解決するには、次の問合せを実行し、クラスタウェア・ターゲットのターゲット・プロパティClusterNameを検証します。
select property_value from mgmt$target_properties where target_name=<CRS Target Name> and property_name="ClusterName"
戻り値がCloud Controlのクラスタウェア・ターゲット名と異なる場合は、クラスタウェア・ターゲットとその他の関連ターゲットを削除し、再度検出します。この回の検出では、クラスタウェア・ターゲット名が前の問合せで戻された名前と一致することを確認します。
後述の詳細を参照してください。
ホーム外パッチ適用モードで複数のOracleホームにパッチを適用するパッチ計画を作成し、実際に計画をデプロイする前に、計画の作成ウィザードで「準備」をクリックしてパッチ計画を準備するときに、「準備に失敗しました」というメッセージが生成され、準備処理が失敗することがあります。
後述の詳細を参照してください。
後述の詳細を参照してください。
パッチ計画の分析が正常に終了した後で、計画の作成ウィザードの「確認」にナビゲートすると、「デプロイ」ボタンが無効になっていることがあります。また、確認ページの表も空です(パッチが表示されません)。このために、パッチ計画をデプロイできないことがあります。
後述の詳細を参照してください。
英語以外のロケールでは、分析、準備またはデプロイの際に、あるいはスイッチバックするときに、計画名が長いパッチ計画が失敗します。エラーは表示されません。かわりに、パッチ計画に対して、すぐに「失敗」状態が反映され、例外が<INSTANCE_HOME>/sysman/log/emoms.logファイルにロギングされます。
このエラーが発生するのは、パッチ計画名が長すぎる(64バイトを超える)場合です。プロビジョニング・アーカイブ・フレームワークではインスタンス名が64バイトに制限されます。このため、64バイト未満の計画名しか受け入れることができません。通常、インスタンス名は、パッチ計画名、計画操作およびタイム・スタンプを使用して構成されます(PlanName_PlanOperation_TimeStamp)。インスタンス名全体が64バイトを超えると、このエラーが表示されます。
この問題を解決するには、次のいずれかを実行します。
パッチ計画の分析、準備またはデプロイが失敗した場合は、計画名を編集して短くし、パッチ適用処理を再試行します。
パッチ計画が正常にデプロイされるとパッチ計画はロックされるため、スイッチバックがこのエラーで失敗した場合には、ウィザードで計画名を編集することはできません。かわりに、次のSQL updateコマンドを実行して、管理リポジトリ内の計画名を直接更新します。
update em_pc_plans set name = 'New shorter name' where name = 'Older longer name';
commit;
後述の詳細を参照してください。
パッチ計画の「準備」フェーズで、ホーム外パッチ適用によるクローンOracleホームのロック解除に失敗したため、クローンOracleホームでのパッチ計画が失敗しました。クローンOracleホームでのclone.pl実行手順が失敗しました。
ここでは、次の問題について説明します。
後述の詳細を参照してください。
パッチ計画を分析すると、そのパッチ計画に関して分析が進行中と表示され、対応するデプロイメント・プロシージャまたはジョブが正常に終了した後でもそのままになっていることがあります。
この問題は次のいずれかの原因によって発生することがあります。
デプロイメント・プロシージャの完了についてジョブ・システムからの通知が遅れているか、通知がない場合。通常、デプロイメント・プロシージャが終了すると、ジョブ・システムがデプロイメント・プロシージャに通知します。場合によっては、通知が遅れることや、ジョブ・システムからまったく通知されないことがあり、パッチ計画のステータスに常に「分析」状態と表示される原因になります。
パッチ計画のステータスの変更が遅れている場合。通常は、ジョブ・システムがデプロイメント・プロシージャに完了を通知した後、ジョブ・システムは新しいジョブを発行して、パッチ計画のステータスを変更します。負荷によっては新しいジョブが実行キューに長い間とどまることがあり、そのためにパッチ計画のステータスに常に「分析」状態と表示される原因になります。
パッチ計画のステータスを変更するジョブのエラー。場合によっては、パッチ計画のステータスを変更するために新しいジョブが発行された後で、管理リポジトリの更新の問題やシステム関連の問題があると、その新しいジョブが失敗することがあります。
管理リポジトリのタイムゾーンの問題。管理リポジトリがOracle RACデータベースで構成されている場合に、Oracle RACの各インスタンスが異なるタイムゾーンで実行しているとき、現在のシステム時刻を確認するために問合せが実行されると、そのリクエストを処理するインスタンスによっては不正確な時刻詳細が返されることがあります。時刻詳細が不正確なために、パッチ計画のステータスを変更するジョブが実行されないことがあります。これが、パッチ計画のステータスに常に「分析」状態と表示される原因になります。
後述の詳細を参照してください。
Oracle Clusterwareのパッチ適用のために作成されたパッチ計画を検証するとき、検証が失敗し(図F-4)、タイプhostのターゲット<target_name>のノード名がないと示されます。また、検証ページに示される解決方法は正しくありません。
後述の詳細を参照してください。
これまでに説明したように、分析エラーにはいくつかの原因があります。My Oracle Supportの接続の問題、ARUの問題、または管理リポジトリにアクセスして、パッチ計画、ターゲット、またはコミットされる処理の詳細を抽出する際の問題などです。このような問題が発生した場合は、該当する項で説明した解決方法に従います。それでも解決できない場合は、次の手順を実行して、ステップから収集する情報を含むサービス・リクエストまたはバグを発行します。
(オンライン・モードのみ)使用されているMy Oracle Support Webサイトが現在使用可能化どうかを確認します。
(オンライン・モードのみ)計画の分析が、発行されるターゲット分析の前に失敗した場合は、次のURLを実行してパッチ分析が予定どおりに機能しているかどうかを確認します。<em_url>を正しいEM URLで置き換え、<plan_name>を実際のパッチ計画名で置き換えます。
<em_url>/em/console/CSP/main/patch/plan?cmd=getAnalysisXML&type=att&planName=<plan_name>
返されるXMLに、パッチ計画に含まれる各Oracleホームに関する競合チェックのリクエストとレスポンスのXMLが含まれることを確認します。
次のファイルを開き、記録された正確なエラーまたは例外をチェックし、Oracleサポート・サービスに問い合せてください。
$<MIDDLEWARE_HOME>/gc_inst/em/EMGC_OMS1/sysman/log/emoms.log
この項では、次の項目について説明します。
後述の詳細を参照してください。
ホーム外パッチ適用を試行する際に、Oracleホームの構成をリフレッシュしていると、パッチ計画が次のエラーで失敗します。
12:58:38 [ERROR] Command failed with error: Can't deploy oracle.sysman.oh on https://<hostname>:<port>/emd/main/
ステージング・サーバー設定DPのチャネル情報収集ステップが、チャネルを正常にフェッチできませんでしたというエラー・メッセージで失敗します。これはどのように修正すればよいでしょうか。
このエラーが発生するのは、ネットワーク通信エラーがup2dateとULNの間にある場合です。https://linux.oracle.com/uln_faq.html - 9に従って、up2dateが正しいプロキシ設定で構成されていることをチェックします。問題が解決されたかどうかを確認するには、コマンドup2date -nox -show-channelsを使用します。このコマンドで、サブスクライブされたすべてのチャネルがリストされる場合、問題は解決されています。
「up2date –nox –show-channels」コマンドを使用しても、サブスクライブされたチャネルが正しくリストされません。これはどのように修正すればよいでしょうか。
/etc/sysconfig/rhn/sourcesファイルで、up2date defaultのコメントを解除し、構成されたすべてのローカルRPMリポジトリをコメント化します。
他のアーキテクチャとリリースのチャネルに登録するにはどうすればよいですか。
この方法や詳細(関連するFAQなど)は、https://linux.oracle.com/uln_faq.htmlを参照してください。
他のページを使用した後でグループの設定ページに戻ると、発行したジョブへのリンクが表示されなくなります。元に戻す方法はありますか。
詳細列の「表示」をクリックします。
エラー: パッケージ・リポジトリが見つかりませんでしたまたは「不明なホスト」エラーで、パッケージ情報ジョブが失敗します。これはどのように修正すればよいでしょうか。
選択したパッケージ・リポジトリが適切ではありません。yum-archコマンドとcreaterepoコマンドを実行してメタデータ・ファイルが作成されるかどうかをチェックします。OMSからRPMリポジトリへの接続が原因になることもあります。
デプロイメント・プロシージャの実行が正常に終了した後でも、コンプライアンス・レポートで、グループが準拠していないと表示されます。どうしてですか。
「コンプライアンスの収集」は24時間ごとに実行されるジョブです。コンプライアンス・レポートの更新は、ジョブの次回の実行まで待ってください。または、「ジョブ」タブに移動し、ジョブを編集してスケジュールを変更します。
エラー: パッケージ・リポジトリが見つかりませんでしたまたは「不明なホスト」エラーで、パッケージ情報ジョブが失敗します。これはどのように修正すればよいでしょうか。
選択したパッケージ・リポジトリが適切ではありません。yum-archコマンドとcreaterepoコマンドを実行してメタデータ・ファイルが作成されるかどうかをチェックします。OMSからRPMリポジトリへの接続が原因になることもあります。
パッケージ・リストが長すぎますというUIエラー・メッセージが表示されます。これはどのように修正すればよいでしょうか。
選択したパッケージの一部を選択解除します。このUIエラー・メッセージにより、選択解除するパッケージが示されます。
プロビジョニング・アプリケーションに関して構成するステージング・サーバー/ブート・サーバーがUIに表示されません。
管理エージェントがステージングまたはブート・サーバー・マシンにインストールされていないか、データをOMSにアップロードしていません。トラブルシューティング情報や既知の問題は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
ベア・メタル・マシンがブート・ファイルを見つけられないため、起動しません。
ターゲット・マシンのdhcp設定(/etc/dhcpd.conf)およびtftp設定を確認します。サービス(dhcpd、xinted、portmap)が実行しているかどうかをチェックします。必要であれば必要な設定の変更を行い、必要なサービスが停止している場合は起動します。
環境が正しく設定されていても、ベア・メタル・ボックスはネットワーク上ではブートされません。
または
DHCPサーバーは、ベア・メタル・マシンのMACアドレスに関するDHCPDISCOVERメッセージを取得しません。
ベア・メタル・マシンがブートされるサブネットのIPアドレスを含むようにDHCP構成を編集します。
オペレーティング・システムがベア・メタル・ボックスにプロビジョニングされた後で、「エージェント・インストール」が失敗します。
または
オペレーティング・システムのプロビジョニング後に、ホスト名がベア・メタル・ボックスに割り当てられていないでしょうか。
これは、dhcpd.confファイルのget-lease-hostnamesエントリがtrueに設定されている場合に発生することがあります。dhcpd.confファイルを編集してget-lease-hostnamesエントリをfalseに設定します。
また、ホスト名の長さがオペレーティング・システムのホスト名の長さに準拠していることを確認します。
ベア・メタル・マシンが最初のブートの後でハングします(tftpエラー/カーネル・エラー)。
これは、tftpサービスが実行していない場合に発生することがあります。tftpサービスを有効にします。/etc/xinetd.d/tftpファイルでdisableフラグをnoに変更します(disable=no)。dhcpの設定も確認します。
ベア・メタル・マシンがブートするときにカーネル・パニックが発生します。
ターゲット・マシンのdhcp設定およびtftp設定を確認し、必要に応じて変更します。まれに、コピーされたintirdとvmlinuzが破損している場合があります。RPMリポジトリからこれらを再びコピーすると、問題が修正されます。
初期カーネル・イメージをロードした後でベア・メタル・マシンがハングします。
これは、ネットワークが半二重の場合に発生することがあります。半二重ネットワークは直接サポートされませんが、次の手順を実行すると問題を修正できます。
キックスタート・ファイルでethtool -s eth0 duplex halfエントリをethtool -s eth0 duplex fullに変更します。
ベア・メタル・マシンがキックスタート・ファイルを見つけることができません(languageやkeyboardなどの値を手動で入力するためにRedhatの画面が表示されます)。
これは、STAGE_TOP_LEVEL_DIRECTORYがマウント不可またはアクセス不可の場合に発生します。ステージのトップ・レベルがターゲット・マシンにネットワークでアクセスできるようにします。非常にまれですが、ステージング・サーバーのホスト名の解決に関する問題があるために発生することあります。ファイルが存在しているホスト名のかわりにステージング・サーバーまたはNASサーバーのIPアドレスを入力し、プロビジョニング操作を再試行します。
ベア・メタル・マシンで、サイレント・インストールを実行できません(ネットワークの詳細を手動で入力するためにRedhatの画面が表示されます)。
DNSがステージング・サーバー・ホスト名について構成されており、正しいDNS情報をターゲット・マシンに配信するようにDHCPが構成されていることを確認します。問題が解消しない場合は、ホスト名のかわりにステージング・サーバーまたはNASサーバーのIPアドレスを入力し、プロビジョニング操作を再試行します。
プロビジョニングの後で、マシンがEnterprise Managerに登録されません。
これは、プロビジョニング操作の前にEnterprise ManagerエージェントがSTAGE_TOP_LEVEL_DIRECTORYに配置されていない場合に発生します。Enterprise Managerエージェントをこのディレクトリに配置し、操作を再試行します。また、エージェントを保護するために指定されたOMS登録パスワードが正しくない場合にも発生します。ターゲット・マシンのエージェントoracleホームに移動し、正しいOMS登録パスワードを指定してemctl secure agentコマンドを実行します。
OMSとプロビジョニングされたオペレーティング・システムのタイムゾーンをチェックします。プロビジョニングされたオペレーティング・システムのタイムゾーンがOMSのタイムゾーンと一致するように変更します。
64ビットOSのプロビジョニングで、エージェントがインストールされません。
OSのプロビジョニング中に、拡張OSプロパティ・ページでエージェントRPMのフルパスを指定します。
インフラストラクチャ・ページで、1つまたはすべてのステージング・サーバー、ブート・サーバーおよびRPMリポジトリが構成されていないため、プロビジョニング操作を開始できません。
Linuxのプロビジョニングで使用するために少なくとも1つのステージング・サーバー、ブート・サーバーおよびRPMリポジトリを設定します。
デプロイメント操作を発行すると、エラー「予期しないエラーが発生しました。詳細はログ・ファイルを確認してください。」がスローされます。ログには対応するメッセージ「内部名がBMPTypeのComponentTypeが見つかりませんでした」が含まれます。
ソフトウェア・ライブラリ・コンソールでソフトウェア・ライブラリを設定します。
デプロイメント・プロシージャがディレクトリ権限エラーで失敗します。
このエラーは、ターゲット・サーバー・マシンに対するユーザーの権限が不十分なために発生します。STAGE_TOP_LEVEL_DIRECTORYには、ステージング・サーバー・ユーザーの書込み権限が必要です。NASの場合、NASディレクトリはステージング・サーバーにマウントする必要があります。このエラーがブート・ディレクトリへの書込み中に発生した場合は、ブート・サーバー・ユーザーに書込み権限が必要です。
反転ユーザー名の検索に失敗しましたというエラーでベア・メタル・ボックスがブートできません。
DNSに、IPアドレスとホスト名のエントリがあることを確認します。
リファレンス・マシンからプロパティをフェッチすると、エラー「指定された資格証明にはルート・アクセス権がありません。」がスローされます。
リファレンス・マシンに指定された資格証明にsudoアクセス権が含まれることを確認します。
次のパッケージ/パッケージ・グループがRPMリポジトリにありません。パッケージ・リストを更新するか、デプロイメント・ページで正しいRPMリポジトリを選択してください。
このエラー・メッセージで示されたRPMパッケージがリポジトリに存在すること、およびスペリングが正しいことを確認します。存在しない場合は、パッケージをリポジトリにコピーするか、インストールを行わないでください。
PXE (プリブート実行環境)とは何ですか。
プリブート実行環境(PXEまたはPre-Execution Environment)は、使用可能なデータ・ストレージ・デバイス(ハード・ディスクなど)またはインストールされているオペレーティング・システムに依存せずに、ネットワーク・インタフェース・カードを使用してコンピュータをブートストラップする環境です。詳細は、付録D「PXEブートおよびKickstartテクノロジについて」を参照してください。
ベア・メタル・ボックスが追加されるサブネットとは別のサブネットにブート・サーバーを配置することはできますか。
はい。ただし、ベア・メタル・ボックスが追加されるのと同じサブネットへのブート・サーバーの配置をベスト・プラクティスとしてお薦めします。ネットワークが複数の仮想ネットワークに分割されており、各ネットワークに別のDHCP/PXEブート・サーバーがある場合、「割当て」では、指定のハードウェア・サーバーと同じネットワーク上のブート・サーバーを指定する必要があります。
リモート・サブネットのブート・サーバーを使用する場合は、次のいずれかを実行する必要があります。
-- DHCPトラフィックをリモート・サブネット上のDHCPサーバーに転送するように、ルーターを構成する必要があります。このトラフィックはブロードキャスト・トラフィックです。通常ルーターは、構成しないかぎりブロードキャスト・トラフィックを転送しません。ネットワーク・ルーターとしては、ハードウェアベースのルーター(Cisco Corporation製など)またはソフトウェアベースのルーター(Microsoft's RoutingやRemote Access Services (RRAS)など)を使用できます。どちらの場合も、DHCPトラフィックを指定のDHCPサーバーに送るようにルーターを構成する必要があります。
-- DHCP/BOOTPリレーにルーターを使用できない場合は、各サブネットで1つのマシンにDHCP/BOOTPリレー・エージェントを設定します。DHCP/BOOTPリレー・エージェントは、ローカル・ネットワーク上のDHCP対応クライアントと別の物理ネットワーク上のリモートDHCPサーバーの間で、リモートDHCPサーバーのIPアドレスを使用してDHCPおよびBOOTPメッセージ・トラフィックを送信します。
エージェントrpmがステージング・サーバーにステージングされるのはどうしてですか。
PXEを使用してネットワーク上でブートした後、エージェントrpmがターゲット・マシンにエージェントをインストールするために使用されます。オペレーティング・システムのプロビジョニングでは、「拡張プロパティ」で指定されたステージングの場所からエージェント・ビットもマシンにプッシュされます。
ステージング・サーバーとブート・サーバーにエージェントをインストールするためにエージェントrpmを使用できますか。
これができるのは、ステージング・サーバーまたはブート・サーバー・マシンのオペレーティング・システムがRedHat Linux 4.0、3.1または3.0、あるいはOracle Linux 4.0以降の場合のみです。詳細は、次のページにある「Oracle Management Agentインストールのためのエージェントrpmの使用」を参照してください。
http://www.oracle.com/technology/software/products/oem/htdocs/provisioning_agent.html
HTTP以外のプロトコルを使用してyumリポジトリにアクセスできますか。
rpmリポジトリはfile://またはftp://でも公開できますが、推奨する方法はhttp://です。これが高速かつ安全性も高い方法です。
ディレクティブのステータスの意味は何ですか。どうすれば変更できますか。
次の表で、ステータスの値と意味を確認してください。
表F-1 ステータス値
| ステータス | 説明 |
|---|---|
|
不完全 |
このステータスは、ディレクティブの作成中に一部のステップ(ディレクティブの実際のスクリプトのアップロードなど)が完了しなかったことを示します。または、ユーザーが作成中にディレクティブを保存し、ディレクティブの作成を完了するために実行する必要があるステップがあることを示します。 |
|
準備完了 |
これは、ディレクティブの作成が正常に終了し、コンポーネントやイメージと一緒に使用できる状態であることを示します。 |
|
アクティブ |
ユーザーは、「準備完了」ディレクティブのステータスを「アクティブ」に手動で変更して、プロビジョニングの準備ができたことを示すことができます。「アクティブにする」をクリックするとステータスが「アクティブ」に変更されます。 |
ディレクティブの成熟度レベルとは何ですか。どうすれば変更できますか。
表F-2で、ステータスの値と意味を確認してください。
表F-2 成熟度レベル
| 成熟度レベル | 成熟度レベルの説明 |
|---|---|
|
未テスト |
これは、ディレクティブがテストされていないことを示します。ディレクティブが作成されたときに割り当てられるデフォルトの成熟度レベルです。 |
|
ベータ |
ディレクティブをテストすると、「昇格」ボタンを使用して「ベータ」に手動で昇格できます。 |
|
本番 |
本番システムの実際のプロビジョニングにディレクティブを使用できるとユーザーが確認したら、「昇格」ボタンを使用して「本番」に手動で昇格できます。 |
複数のデプロイメントで同じコンポーネントを使用できますか。
はい。コンポーネントは再利用可能です。所定のコンポーネントを複数のデプロイメントに同時に含めることができます。
コンポーネントが編集された場合、そのコンポーネントに関連するスケジュール済デプロイメントを編集する必要がありますか。
はい。
Linux OSコンポーネントを作成する際に、リファレンス・マシンで管理エージェントが実行している必要がありますか。
はい。リファレンス・マシンは、Enterprise Managerの管理対象ターゲットの1つであることが必要です。
ディレクティブのステータスの意味は何ですか。どうすれば変更できますか。
コンポーネントのステータスはディレクティブのステータスと似ています。「ディレクティブのステータスの意味は何ですか。どうすれば変更できますか。」を参照してください。
コンポーネントの成熟度レベルとは何ですか。どうすれば変更できますか。
コンポーネントの成熟度レベルはディレクティブの成熟度レベルと似ています。「ディレクティブの成熟度レベルとは何ですか。どうすれば変更できますか。」を参照してください。
問題が発生して、ホストまたはOracleホームで構成をリフレッシュすることになった場合は、次に説明する手順に従います。
デプロイメント・プロシージャを実行する前に、ホストの構成をリフレッシュすることをお薦めします。次の手順を実行します。
Cloud Controlで、「エンタープライズ」メニューから「構成」を選択し、「ホスト構成のリフレッシュ」をクリックします。
ホスト構成のリフレッシュ・ページの「使用可能なホスト」ペインでデプロイメント・プロシージャが使用するホストを選択し、「選択したホスト」ペインに移動します。
「ホストのリフレッシュ」をクリックします。
ホスト構成情報は、ホストで稼働しているOracle Management Agentによって24時間ごとに自動的に更新されますが、ホストの構成情報を手動で更新することもできます。
|
注意: ターゲットにパッチを適用した後、Oracleホーム構成のリフレッシュがデプロイメント・プロシージャによって内部的に処理されます。ただし、なんらかの理由でリフレッシュが行われない場合は、ここで説明するようにOracleホーム構成を手動でリフレッシュできます。 |
1つのホストのホスト構成を手動で更新する手順は、次のとおりです。
Cloud Controlで、「ターゲット」メニューから「すべてのターゲット」を選択します。
すべてのターゲット・ページの「検索の絞込み」セクションで、「ターゲット・タイプ」をクリックしてメニューを展開し、メニューの「その他」をクリックし、さらに「Oracleホーム」をクリックします。
ページの右側がリフレッシュされ、Oracleホーム・ターゲットのみが表示されます。
ターゲット名をクリックして選択します。
<target_name>ホームページの「Oracleホーム」メニューで「構成」を選択し、「最新収集」をクリックします。
最新の構成: <target_name>ページの「アクション」メニューで、「リフレッシュ」を選択して、ホストのOracleホーム構成をリフレッシュします。
次の例は、ターゲット11107CRSHome_1_slc00eiiのOracleホーム構成をリフレッシュするためのステップです。
ここでは、デプロイメント・プロシージャの実行中に発生した問題を解決するために確認する必要があるログ・ファイルをしめします。
この項の内容は次のとおりです。
OMS関連のログ・ファイルを次に示します。
Enterprise Managerの一般的なトレース・ファイル
<EM_INSTANCE_BASE>/em/<OMS_NAME>/sysman/log/emoms.trc
Enterprise Managerの一般的なログ・ファイル
<EM_INSTANCE_BASE>/em/<OMS_NAME>/sysman/log/emoms.log
<EM_INSTANCE_BASE>は、OMSインスタンス・ベースのディレクトリです。デフォルトでは、OMSインスタンス・ベースのディレクトリはgc_instで、これはOracle Middlewareホームの親ディレクトリの下にあります。
管理エージェント関連のログ・ファイルを次に示します。
EMSTATE/sysman/log/gcagent.log
EMSTATE/sysman/log/gcagent.trc
必要であれば、詳細を取得するために、次の手順を実行してログ・レベルを再設定し、前の項で説明したログを取得します。
|
注意: 古いログをアーカイブし、ログ・レベルを再設定した後で、新たに実行して新しいログを取得することをお薦めします。 |
