1. Oracle Exadata Database Machineスタート・ガイド
  2. Exadata Database Machineの検出

3 Exadata Database Machineの検出

この章では、Enterprise Manager Cloud Control 13cを介してOracle Exadata Database Machineを検出する手順について説明します。

次の項では、Exadata Database Machineおよびサポートされているその他のターゲットを検出する方法について説明します。

  1. Oracle Exadata Database Machineの検出

  2. グリッド・インフラストラクチャおよびRACの検出

  3. CellCLIからRESTful APIへの使用の切り替え

Oracle Exadata Database Machineの検出

この項では、Enterprise Manager 13cでサポートされている各種の検出フローについて説明します。

2つの検出方法の比較:

EMCLI コンソール

  • EMCLIを使用したDatabase Machineの検出は、オフラインまたはバックグラウンドで複数のDatabase Machineの検出が必要になる検出プロセスをスクリプトで自動化する際に役立ちます。

  • 伝統的なプログラミング言語の構成を介してアクセスできるため、コマンドラインから、またはプログラムによって、タスクを作成および実行できます。EMCLIにより、各種オペレーティング・システムのテキスト・ベースのコンソール(シェルおよびコマンドライン・ウィンドウ)からEnterprise Manager機能にアクセスできます。

  • EMCLIは、Enterprise Managerのセキュリティおよびユーザー管理機能と完全に統合されているため、管理者は、Enterprise Managerコンソールと同じセキュリティと機密保持性を備えたEM CLIを使用して操作を実行できます。たとえば、管理者は、自分が権限を持つターゲットのみを表示し、操作することができます。

  • 検出の対話操作経験のために、コンソールを使用します。

  • 検出プロセス全体がパッケージ化され、Enterprise Managerコンソールで使用できます。

  • 検出プロセスは自己直感的です。必要な情報をダイアログ・ボックスに入力できるようにする必要があります。

  • この方法は、1回かぎりの設定に最適です。

コンソールを使用したOracle Exadata Database Machineターゲットの検出

Oracle Exadata Database Machineターゲットのフレッシュ検出

この検出フローでは、データベース・マシン・ターゲットの検出に関連するステップを示します。このフローは、Database Machineターゲットを再度検出する場合にお薦めのオプションです。

Oracle Exadata Database Machineは、物理構成または仮想構成でデプロイできます。Enterprise Managerは、これらの構成をどちらもサポートしています。仮想Exadata Database Machineの検出には、追加のステップが必要になります。こうした追加のステップは、必要に応じてインラインで処理します。

Oracle Virtual Platformの検出

仮想Exadataを検出する場合は、Oracle Exadata Database Machineターゲットの検出前に、Oracle Virtual Platformターゲットが検出されている必要があります。次のステップでは、Oracle Virtual Platformターゲットの検出について詳しく説明します。

ノート:

Exadata Database Machineの検出の実行にEMCLIを使用している場合は、その検出の一環として個別の検出操作なしにOracle Virtual Platformターゲットを検出できます。「EMCLIを使用したOracle Exadata Database Machineターゲットの検出」を参照してください。

  1. Enterprise Managerホームページから、「設定」メニュー(右上隅)、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。
  2. ターゲットの手動追加ページで、「ガイド付きプロセスを使用したターゲットの追加」をクリックします。
  3. 「ガイドされた検出」列の下にある「Oracle Virtual Platform」を選択して、「追加」をクリックします。
  4. 「Oracle Virtual Platformの検出」画面で、次の操作を実行します。
    1. 「モニタリング・エージェント」には、最初のコンピュート・ノードdomU (仮想マシン)にインストールされたエージェントを選択します。「フェイルオーバー・モニタリング・エージェント」には、2番目のコンピュート・ノードdomU (仮想マシン)のエージェントを選択します。
    2. 「資格証明プロパティ」には、rootユーザーまたはroot以外のユーザーのユーザー名を入力し、パスワードを指定します。
    3. 「ホスト名とIPアドレス」セクションでは、「追加」ボタンをクリックし、dom0サーバーの完全修飾ホスト名を入力(行ごとに1つ)して、「追加」をクリックします。
    4. 「送信」をクリックします。
    Oracle Virtual Platformの検出
  5. Oracle Virtual Platformターゲットの検出が完了したら、次の項に示すステップを実行して、Oracle Exadata Database Machineターゲットを検出します。
Oracle Exadata Database Machineの検出
  1. Enterprise Managerホームページから、「設定」メニュー(右上隅)、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。
  2. ターゲットの手動追加ページで、「ガイド付きプロセスを使用したターゲットの追加」をクリックします。
  3. 「ガイド付きプロセスを使用した追加」ウィンドウで、リストから「Oracle Exadataデータベース・マシン」を選択し、「追加」をクリックします。
  4. Oracle Exadata Database Machineの「検出」ページに、次の2つのオプションが示されます。このドキュメントでは、新しいExadata Databaseマシンとコンポーネントを検出するステップについて詳しく説明します。
    • 新しいDatabase Machineおよびそのハードウェア・コンポーネントをターゲットとして検出します。表が更新され、ターゲット・タイプおよび検出に必要な資格証明が表示されます。
    • ターゲットとして既存のDatabase Machineに新しく追加されたハードウェア・コンポーネントを検出します。ドロップダウン・メニューからDatabase Machineを選択します。表が更新され、ターゲット・タイプおよび検出に必要な資格証明が表示されます。その後の検出フローのダイアログは、この項に示したダイアログと似ていますが、未検出のコンポーネントにのみ限定されます。

    タスクを選択し、「ターゲットの検出」をクリックします。Exadata検出ウィザードが開始されます。

  5. 検出入力ページで、次の情報を入力します。
    • 「検出エージェント」セクションには、次のように入力します:
      • エージェントURL: 物理コンピュート・ノードにデプロイされているエージェントを選択します。仮想Exadataの場合は、domU (仮想マシン)コンピュート・ノードにデプロイされているエージェントを選択します。検索アイコンをクリックして、利用可能なエージェントから選択します。
    • 「構成図ファイル」セクションには、次のように入力します:
      • エージェントURLを指定すると、新しい行(ホスト名およびスキーマ・ファイル情報)が自動的に追加されます。デフォルトのスキーマ・ファイルdatabasemachine.xmlでは、Exadata Database Machineのハードウェア・コンポーネントについて説明されています。
      • 「資格証明の設定」をクリックして、ホストに対して資格証明を設定します。
      • 構成図ファイルの場所を確認して、必要に応じて変更します。
      • スキーマ・ファイルの名前をドロップダウン・メニューから選択します。

      ノート:

      次のいずれかに該当する場合のみ、構成図ファイルの場所をカスタマイズする必要があります。

      – 構成図ファイルがデフォルトの場所に存在しない。

      – Database Machineにストレージ拡張ラックが含まれている。

      – ハードウェア・コンポーネントが複数の構成図ファイルで指定されている。

    「次へ」をクリックします。

  6. 「インフィニバンド検出」ページの表示は、Oracle Exadata Database Machineが、インフィニバンド(IB)またはRDMA over Converged Ethernet (RoCE)のどちらのストレージ・ネットワークを備えているものとして識別されているかによって異なります。次に、スクリーンショットと各オプションの詳細を示します。

    これがIB Oracle Exadataの場合は、次の情報が必要です。

    • IBスイッチ・ホスト名: Oracle ExadataのいずれかのIBスイッチのホスト名。通常、IBスイッチのホスト名は事前に移入されています。
    • インフィニバンド・スイッチのILOMホストの資格証明: インフィニバンド・スイッチのILOMホストのrootユーザーまたはilom-adminユーザーの名前とパスワード。

      「次へ」をクリックします。

    これがOracle Exadata X8Mの場合、検出フローのこの時点で資格証明は必要ありません。「インフィニバンド検出」ページには、検出されるDatabase MachineにRoCEスイッチが含まれていることと、追加の入力が不要なことを示すメッセージが表示されます。

    「次へ」をクリックします。

    ノート:

    これがOracle Exadata X8Mの場合に、インフィニバンド情報を要求するフォームが表示されたときには、前のステップで指定したdatabasemachine.xmlへのアクセスに問題が発生した可能性があります。前に戻って、この問題を修正してください。databasemachine.xmlファイルの場所と資格証明が正しく指定されていることと、そのファイルが存在していることを確認してください。
  7. 「前提条件チェック」ページでは、Enterprise Managerにより、対象の環境に基づいて動的にハードウェア・コンポーネントの検出が試行されます。重大な問題が発生した場合は、「戻る」をクリックして、それを解決できます。Enterprise Managerにより、問題とその重大度(情報、警告またはクリティカル)が表示されます。

    警告の問題や情報メッセージが表示されることもあります。これが検出プロセスを妨げることはありません。

    「次へ」をクリックします。

  8. 「コンポーネント」ページでは、次のコンポーネントがすでに選択されています。必要でないコンポーネントは選択解除できます。コンポーネントの一部を次に示します。
    • コンピュート・ノード: Oracle Exadata Database Machineのコンピュート・ノードであるホストを選択します。
    • Oracle Exadata Storage Server: このOracle Exadata Database Machineターゲットの一部であるOracle Exadata Storage Serverを選択します。
    • インフィニバンド・スイッチ: これがIB Oracle Exadataの場合に表示されます。Oracle Exadata Database Machineの一部であるインフィニバンド・スイッチを選択します。これらは管理対象ターゲットとしても追加されます。
    • イーサネット・スイッチ: Oracle Exadata Database Machineの一部であるイーサネット・スイッチを選択します。これがIB Oracle Exadataの場合は、管理スイッチを選択します。これがOracle Exadata X8Mの場合は、管理スイッチとRoCEスイッチを選択します。イーサネット・スイッチは管理対象ターゲットとして追加されます。
    • コンピュート・ノードILOM: このOracle Exadata Database Machineの一部であるコンピュート・ノードのIntegrated Lights Out Manager (ILOM)を選択します。このILOMは、管理対象ターゲットとして追加されます。

    ノート:

    パーティション化されたラックは、手動で選択解除する必要のある他のコンポーネント(コンピュート・ノードなど)を示すことができます。

    データベース・マシンの検出: コンポーネント

    「次へ」をクリックします。

  9. デフォルトでは、エージェントはターゲットに自動的に割り当てられます。別のモニタリング・エージェントを追加するには:

    「モニタリング・エージェント」ページで、ポップアップ・ウィンドウから「エージェントの選択」をクリックし、Exadata Database Machineのターゲットごとに必要とされるエージェントを選択します。[Ctrl]キーを使用すると、複数のエージェントを選択できます。

    ノート:

    1つのエージェントをモニタリングとバックアップのエージェントとして使用すると、警告が表示されます。「エージェントの選択」をクリックして、別のエージェントを追加します(利用可能な場合)。

    データベース・マシンの検出: モニタリング・エージェント

    「次へ」をクリックします。

  10. 「資格証明」ページで、Oracle Exadata Database Machine内のすべてのコンポーネント(ストレージ・サーバー、PDU、インフィニバンド・スイッチなど)の資格証明を設定します。「資格証明の設定」をクリックして、コンポーネントの資格証明を設定します。すべてのタイプのコンポーネントのユーザーとパスワードが同じ場合は、「すべて同じ」を選択し、ユーザーとパスワードの組合せを入力します。
    • コンポーネントによっては、追加情報を提供する必要があります。たとえば、「Oracle Exadata Storage Server資格証明」ウィンドウでは、モニタリング資格証明とSNMP資格証明を入力する必要があります。
    • Oracle Exadata Storage Serverのモニタリングにお薦めのメカニズムは、RESTful APIです。RESTful APIを使用するには、ExaCLIユーザーが必要です。これに必要なExaCLIユーザーの作成方法の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』のExaCLIに使用するユーザーの作成に関する項を参照してください。
    • Exadataのコンポーネントから、ハードウェアおよびソフトウェアの障害についてのアラートを受信するために、EMではSNMPのサブスクリプションが必要になります。各コンポーネントの資格証明の画面には、SNMP構成のためのフィールドが表示されます。SNMPサブスクリプションには、すべてのサブスクリプションに対応するSNMP v3サブスクリプションの使用をお薦めします。IPv6環境では、SNMPV3の資格証明のみがサポートされます。
    • SNMPコミュニティ文字列はパスワードのようなものです。各SNMP Get-Requestとともに送信され、デバイスへのアクセスを許可または拒否します。対象の環境に適したコミュニティ文字列の詳細は、ネットワーク管理者に確認してください。
    • コンピュート・ノード・サーバーILOMの資格証明の場合、RESTful APIを使用してモニタリングする名前付き資格証明を追加で指定できます。「接続のテスト」をクリックして、SSHおよびRESTful API資格証明が適切に機能していることを確認します。RESTモニタリングのILOMバージョンは5.0.1以降である必要があります。また、RESTのモニタリングには、エージェント側で最新のExadataプラグイン・リリース更新を使用してください。

      Enterprise Managerで次のようにナビゲートすることにより、ILOM RESTアクセス・ポイントを昇格するためのコンピュート・ノードREST資格証明を作成できます: Enterprise Managerホームで「設定」をクリックし、「セキュリティ」をクリックし、「名前付き資格証明」をクリックし、REST資格証明の詳細を入力します。

    次の表に、資格証明の推奨値に関するサンプル・ガイドラインを示します。

    表3-1 資格証明の詳細

    コンポーネント 資格証明 モニタリング・メカニズム SNMPサブスクリプション ノート
    エージェント oracle (またはエージェント・インストールを所有するユーザー) . . .
    Oracle Exadata Storage Server celladministrator RESTful API SNMP V3 .
    インフィニバンド・スイッチ root / ilom-admin . SNMP V3 このコンポーネントは、RoCEベースのシステムの検出時には存在しません
    コンピュート・ノード・サーバーILOM root RESTful APIを使用したSSH/拡張モニタリング SNMP V3 RESTful APIを使用した拡張ILOMモニタリングの場合、rootとadminの両方のユーザー資格証明がサポートされます。
    PDU admin . SNMP V3 .
    イーサネット・スイッチ admin . SNMP V3 RoCEベースのシステムでは、これらの資格証明がRoCEスイッチの検出と管理スイッチの検出に使用されます。管理スイッチとRoCEスイッチのパスワードが異なる場合、パスワードはスイッチごとに指定できます。

    データベース・マシンの検出: 資格証明

    「次へ」をクリックします。

  11. 「確認」ページで、各セクションが正しいことを確認します。次の図は、適切な確認の例を示しています。
    データベース・マシンの検出: 確認

    「送信」をクリックします。

  12. Database Machineのコンポーネントの検出後、検出されたすべてのターゲットとコンポーネントを示す「ターゲット作成サマリー」ページが表示されます。エラーがある場合は、「ステータス」列に赤いフラグが表示されます。フラグの上にカーソルを重ねると、エラーに関する追加情報についてのポップアップ・ウィンドウが表示されます。
  13. 検出後の検証を実行してから、Enterprise Managerの使用を開始してください。

    「検出後の構成および確認」を参照してください。

SuperClusterシステムのExadata Database Machineのフレッシュ検出

Exadataプラグインを使用して、Oracle SuperClusterシステムを検出およびモニターできます。

モニターできるのは、LDOMおよびゾーンにインストールされているOracle SuperClusterのデータベースおよびExadataコンポーネントのみです。オペレーティング・システム・レベルで特定のLDOMまたは仮想化構成をモニターする場合は、Oracle Enterprise Systems Infrastructure Plug-in 13cを使用してください。

Systems Infrastructure Plug-inに付属するSuperCluster検出ウィザードの主な役割は、ZFSサーバーを含むSuperClusterハードウェア・ターゲットを検出することです(詳細は、emsiプラグインからsuperCluster検出ドキュメントを参照してください)。まず、このフローを詳細に検討してから、Exadata Database Machineの検出を実行するようにお薦めします。

Exadataプラグインを使用して、Oracle SuperClusterシステムを検出およびモニターできます。モニターできるのは、LDOMおよびゾーンにインストールされているOracle SuperClusterのデータベースおよびExadataコンポーネントのみです。オペレーティング・システム・レベルで特定のLDOMまたは仮想化構成をモニターする場合は、Oracle Enterprise Manager Ops Centerを使用してください。

Exadata Database MachineとしてOracle SuperClusterを検出するには:

  1. エージェントを管理ドメインおよびゾーンにプッシュするための前提条件を完了する方法は、Oracle® Enterprise Manager Cloud Control管理者ガイドのOracle Solarisゾーンの検出および昇格を参照してください。

  2. サービス・リクエスト(SR)を開き、最初のLDOMから次のファイルをアップロードします。

    /opt/oracle.SupportTools/onecommand/onecommand.params
/opt/oracle.SupportTools/onecommand/config.dat

    ノート:

    新しい構成で上書きするため、/opt/oracle.SupportTools/onecommandディレクトリのバックアップを作成します。

  3. Oracleサポートにより、構成ファイルに提供されている情報に基づいてファイルが生成されます。すべてのファイルを/opt/oracle.SupportTools/onecommandディレクトリにコピーします。

  4. このディレクトリ内のみでなく、/opt/oracle.SupportTools/emディレクトリ内のすべてのファイルにも、読取り権限が許可されていることを確認します。エージェントが、検出中にこれらのファイルを読取る必要があります。

  5. Enterprise Managerから自己更新を実行して、OMS上にSolaris SPARCエージェント・ソフトウェアをダウンロードします。ダウンロードしたソフトウェアをOMSに適用して、デプロイに使用可能にします。

    1. Enterprise Managerで、「設定」、「拡張性」、「自己更新」の順にクリックします。「エージェント・ソフトウェア」をクリックします。

    2. 「SPARC (64ビット)上のOracle Solaris」を選択します。

    3. ステータスが「使用可能」の場合、「アクション」メニューから「ダウンロード」をクリックします。

    4. 一度ダウンロードすると、同じ「自己更新」ページからOMSに適用する必要があります。

    オンラインまたはオフライン・モードでの自己更新の詳細は、Oracle® Enterprise Manager Cloud Control管理者ガイドのCloud Controlの更新を参照してください。

  6. Oracle SuperClusterの各データベース・ノードにエージェントをインストールします。

    1. Enterprise Managerで、「設定」、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

    2. 「ホスト・ターゲットの追加」(デフォルトで選択されています)を選択し、「ホストの追加」をクリックします。

    3. インストール・ウィザードを続行し、インストールの完了後、各ノードでroot.shを実行したことを確認してください。

  7. Database Machineの検出のため、データベース・ノードを構成します。

    このステップは、set_nodedesc.shを使用して、データベース・ノードのIPアドレス、ホスト・チャネルのアダプタID、インフィニバンド構成内の管理ホスト名を更新して、各データベース・ノードの説明を設定するために必要です。Enterprise Managerエージェントは、Database Machineを検出する際にこの情報を検索します。

    次を実行します。

    # ibnetdiscover | grep your_db_nodes

    何も出力が戻されない場合は、すべてのデータベース・ノードから次のコマンドを実行して、ノードの説明を設定します。

    # /bin/ib_set_node_desc_ssc.sh

  8. Enterprise Managerで、Manual Discoveryウィザードを使用して、Exadata Database Machineを検出します。この検出プロセスは、その他のExadata Database Machineターゲットについても同じです。See 「Oracle Exadata Database Machineの検出」を参照してください。

  9. HA RAC Clusterおよびクラスタ・データベースを検出して、ターゲットを通常どおりに構成します。

  10. 検出後の検証を実行してから、Enterprise Managerを使用したExadata Database Machineのモニターを開始してください。「検出後の構成および確認」を参照してください。

コンソールを使用したターゲット・タイプ12cのDatabase Machineデータベース・マシン・ターゲットの13cへの変換

Enterprise Manager 12cまたはターゲット・タイプが12cのEnterprise Manager 13cで検出されたExadata Database MachineをEnterprise Manager 13cでモニターされるように変換するには:

  1. 「データベース・マシン」メニューから、「12cメンバー・ターゲットの変換」を選択します。
  2. 変換オプションを選択します。

    • (デフォルト) 12cターゲットおよびその履歴データを削除します。このオプションを選択すると、レガシー・ターゲットのすべてのモニタリングが中止され、履歴データが削除されます。このオプションを選択すると、Enterprise Manager 13cターゲットのすべてのモニタリングをクリーンな状態で開始できます。

    • 12cターゲットおよびその履歴データを保持します。このオプションを選択すると、レガシー・ターゲットの履歴データが保持されます。

    変換オプションを選択したら、「次へ」をクリックします。

  3. 「資格証明」を設定します。変換を行う場合、変換するExadata Database Machineコンポーネントの資格証明を設定する必要があります。これらは、Exadataを構成するコンポーネントのサブセットです。推奨設定の詳細は、表3-1を参照してください。また、「Oracle Exadata Database Machineの検出」の対応するステップに示した関連の詳細も参照してください

    データベース・マシンの変換: 資格証明

    資格証明の設定が完了すると、「資格証明」ページが更新されて、変換対象のすべてのコンポーネントの資格証明セットが表示されます。「次へ」をクリックします。

  4. 次の3つのセクションで、変換対象のコンポーネントを確認します。

    • サマリー: このセクションには、変換されるターゲットの数、および変換後にターゲットで追加のモニタリング情報が使用可能になるかどうかが要約されます。

    • 変換するターゲット: この表には、Enterprise Manager 13cでモニタリングするために13cターゲット・タイプに変換されるすべてのEnterprise Manager 12cターゲットが表示され、新しいターゲット名の情報が提示されます。

    • 変換の影響を受けないターゲット: Enterprise Manager 13cでモニターするため、Exadata Database Machineのすべてのコンポーネントを変換する必要はありません。このリストには、変換する必要のないコンポーネントが示されます。これらのコンポーネントは、13cターゲット・タイプを使用して、すでにEnterprise Manager 13cによってモニターされています。

    「発行」をクリックして、変換を開始します。

  5. 「処理中」ポップアップ・ウィンドウが表示され、変換のステータスと変換対象コンポーネントの成功または失敗のサマリーが示されます。

    処理が完了するまでこのウィンドウを閉じない


    ターゲットの処理

    このオプションを選択して処理の完了後にウィンドウを閉じることも、「完了」をクリックすることもできます。

  6. 処理が完了すると、変換結果ページに、変換されたコンポーネントのサマリーと、変換に成功または失敗した各コンポーネントの詳細が示されます。

    データベース・マシンの変換: 変換結果

    このページから「残りの12cターゲットの変換」をクリックして、変換に失敗したコンポーネントの変換プロセスを繰り返します。「新しいデータベース・マシン・ホームページの起動」をクリックして、Enterprise Manager 13cでモニターされるすべての変換済コンポーネントが含まれる更新済ホームページを表示します。

EMCLIを使用したOracle Exadata Database Machineターゲットの検出

EMCLIベースの検出はカスタマイズできるため、コンポーネントを追加することや停止しているコンポーネントをスキップすることが可能です。また、モニタリング・エージェントの選択も可能です。EMCLIのDatabase Machine検出は、多重呼出し不変です。そのため、後続の実行では以前に検出されなかったターゲット(コンポーネント)の検出に最善を尽くし、すでに検出されていて構成済のターゲットは無視します。

この検出は、ローカルまたはリモートのエージェントを使用する物理および仮想のExadata Database Machine (IB/RoCE)のどちらでも動作します。

EMCLIを使用してDatabase Machineターゲットを検出するために、前提条件のタスクを必ず完了してください。完了する前提条件のリストは、「検出にEMCLIを使用する場合の前提条件」を参照してください。

検出のためのデプロイメント・プロシージャの発行

EMCLIにログインし、次のコマンドを実行してOracle Exadata Database Machineを検出します: 

 emcli   submit_procedure -name=DBMachineDiscovery -input_file="data://<input_file_absolute_path>"

前述のコマンドでは、次のとおりです。

  • DBMachineDiscovery: このデプロイメント・プロシージャは、EMCLIを使用してOracle Exadata Database Machineを検出する際に使用します。「EMCLIのデプロイメント・プロシージャ」を参照してください。

  • input_file_absolute_path: 前提条件のステップで作成した入力ファイルの完全パス。「入力ファイルの作成」を参照してください。

検出DPのステータスに関する通知を受け取るには、次に示すように、-notificationフラグを使用します。 

 emcli   submit_procedure -name=DBMachineDiscovery -input_file="data://<input_file_absolute_path>" -notification="scheduled, action required, running" ;
EMCLIのデプロイメント・プロシージャ

デプロイメント・プロシージャ(DP)のDBMachineDiscoveryは、EMCLIを使用してOracle Exadata Database Machineを検出する際に使用します。このDPは、次の2つのDPで構成されています。

  • DBMachineSystemCheck: このDPは、前提条件タスクの実行時に作成した入力ファイルを受け取り、一連の前提条件チェックを実行します。前提条件チェックが正常に完了すると、このDPは、次のDPで利用する出力ログ・ファイルを生成します。

  • DBMachineSystemCreation: このDPは、前提条件チェックのDPで生成した出力ログ・ファイルを利用して、Exadata Database Machineの検出を実行します。結果として、ターゲットの作成、アソシエーション、ターゲットの昇格などのステップが実行されます。

検出ステータスの表示

発行したデプロイメント・プロシージャのステータスは、EMCLIコマンドを使用してモニターすることも、Enterprise Manager UIからモニターすることもできます。

検出中にエラーが発生した場合は、デプロイメント・プロシージャの出力情報に基づいてエラーを解決してください。

「EMCLI検出の問題」を参照してください。

EMCLIを使用したデプロイメント・プロシージャのステータスの確認

検出デプロイメント・プロシージャの発行後、次に示すように、実行IDがコマンドラインに表示されます。

emcli submit_procedure -name=”DBMachineDiscovery” -input_file=data:”/home/user_jane/dpInput/emcli_discover_dp1_vir_remote” 

Schedule not specified, defaults to immediate. 
6979503EF41F2447E05338C8F70A1796
Deployment procedure submitted successfully

実行IDを使用して、ステータスを問い合せて、そのステータスを特定の形式で表示します。たとえば、実行IDが69818CF4995E0C88E05338C8F70AA2C3の場合は次のようになります。 

emcli get_instance_status -instance=69818CF4995E0C88E05338C8F70AA2C3 -xml -details -showJobOutput -tailLength=50

次に、前述のコマンドの出力例(xml形式)を示します。

</step>
<step isEnabled="true" name="promoteTargets" stepType="">
    <GUID>promoteTargets</GUID>
    <errorModeString>stop</errorModeString>
    <typeStep>Step</typeStep>
    <status></status>
    <startedOn>2018-04-10 08:56:28.0</startedOn>
    <lastUpdatedOn>2018-04-10 08:58:16.0</lastUpdatedOn>
    <completedOn>2018-04-10 08:58:16.0</completedOn>
コンソールを使用したデプロイメント・プロシージャのステータスの確認

検出のステータスと進行状況は、Enterprise Managerコンソールを使用して表示できます。

メインの「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」 > 「プロシージャ・アクティビティ」の順にクリックします。次のステータス情報が表示されます。

  • ターゲット検出のステータス: SuccessまたはFailure

  • 失敗した場合は、その理由と、それを修正するための追加情報。

    デプロイメント・プロシージャの出力に表示された問題を解決し、Enterprise Manager CLIまたはEnterprise Managerコンソールから検出を再発行してExadata Database Machineを検出するか、データベース・マシンの残りのコンポーネントを検出します。

EMCLIを使用した12cタイプのDatabase Machineターゲットの13cへの変換

Enterprise Manager 12cまたはターゲット・タイプが12cのEnterprise Manager 13cで検出されたExadata Database MachineをEnterprise Manager 13cでモニターされるように変換するには:

  1. データベース・マシン・ターゲットに関する情報を入力して、入力ファイルを作成します。次に、入力ファイルの例を示します。 

    #--------------Input File credentials example-------------- 
# Config Map 
configMap.dbmTargetName=<DB Machine Target Name>
configMap.retainOldTargets=false 

# Credentials 
credMap.ibIlomCred=<IB Switch ILOM Credentials> 
credMap.ibSnmpCred=<IB Switch SNMP Credentials> 
credMap.pduHttpCred=<PDU Credentials> 
credMap.pduSnmpCred=<PDU SNMP Credentials> 
credMap.ciscoIosCred=<CISCO Switch IOS Credentials> 
credMap.ciscoSnmpCred=<CISCO Switch SNMP Credentials> 
credMap.computenodeIlomCred=<Compute Node ILOM Credentials> 
credMap.computenodeAdminCred=<Compute Node Admin Credentials> 
credMap.computenodeSnmpCred=<Compute Node SNMP Credentials> 
credMap.computeSnmpOpt=false 
credMap.agentCred=<Agent Credentials>

    前述の例では、次のパラメータを使用しています。

    • configMap.dbmTargetName: 変換するデータベース・マシン・ターゲットの名前

    • configMap.retainOldTargets: 変換後に12cターゲットとその履歴データを保持できます。デフォルトでは、falseに設定されています。このオプションを選択すると、レガシー・ターゲットのすべてのモニタリングが中止され、履歴データが削除されます。または、trueに設定して、レガシー・ターゲットのモニタリングを停止し、その履歴データを保持することもできます。

    • credMap.ibIlomCred: IBスイッチのILOM資格証明

    • credMap.ibSnmpCred: IBスイッチのSNMP資格証明

    • credMap.pduHttpCred: PDUの資格証明

    • credMap.pduSnmpCred: PDUのSNMP資格証明

    • credMap.ciscoIosCred: CISCOスイッチのIOS資格証明

    • credMap.ciscoSnmpCred: CISCOスイッチのSNMP資格証明

    • credMap.computenodeIlomCred: コンピュート・ノードのILOM資格証明

    • credMap.computenodeAdminCred: コンピュート・ノードの管理資格証明。これは、credMap.computeSnmpOptがtrueに設定されている場合に指定します。

    • credMap.computenodeSnmpCred: コンピュート・ノードのSNMPサブスクリプション資格証明。これは、credMap.computeSnmpOptがtrueに設定されている場合に指定します。

    • credMap.computeSnmpOpt: コンピュート・ノードのSNMPサブスクリプション・フラグ。デフォルトでは、falseに設定されています。フラグがtrueに設定されている場合、ILOMの変換後に、それぞれのILOM SNMPがサブスクライブされます。

    • credMap.agentCred: コンピュート・ノードSNMPサブスクリプションのエージェント資格証明。

    資格証明の詳細は、名前付き資格証明とその作成コマンドを参照してください。

  2. 次のEMCLIコマンドを実行し、入力ファイルのパスを指定して、12cタイプから13cへのDatabase Machineターゲットの変換を開始します。 

    emcli submit_procedure -name=Convert12cTo13cDatabaseMachine -input_file=<input_file_path> -notification="scheduled, action required, running";

    コマンドの実行後、デプロイメント・プロシージャ(DP)番号をメモします。これは、コンソールで変換のステータスを確認するときに必要になります。

  3. コンソールでデプロイメント・プロシージャのステータスを確認するには、「エンタープライズ」メニューで「プロビジョニングとパッチ適用」をクリックし、「プロシージャ・アクティビティ」をクリックします。ページには、すべてのデプロイメント・プロシージャがリストされます。

  4. ステップ2で開始したデプロイメント・プロシージャに対応するリンクをクリックします。デプロイメント・プロシージャのプロシージャ・アクティビティ・ページが表示されます。

  5. 「プロシージャ・ステップ」で、「表示」→「すべて開く」をクリックします。これで、「前提条件」、「変換」、「サマリー」など、プロシージャのすべてのステップを表示できるようになります。各ステップのステータスは、同じセクションに表示されます。各ステップの詳細を表示するには、そのステップをクリックします。

    いずれかのステップで失敗した場合は、詳細な診断が実行され、修正を適用するための情報が利用可能になりま修正を適用した後、ステップ2で指定したEMCLIコマンドを再実行し、その後のステップを繰り返します。

    次の例では、ターゲットの1つが変換できないことを示す変換のサマリーを表示できます。


    EMCLIを使用した変換中の変換エラー

グリッド・インフラストラクチャおよびRACの検出

Grid Infrastructure (クラスタ)およびReal Application Cluster (RAC)に関連するターゲット(Oracle高可用性サービスおよびクラスタのターゲットやExadataのASM、データベース、リスナーおよび関連するターゲット)の検出プロセスは、その他のプラットフォームの場合と同じです。詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』のデータベース・ターゲットの検出と追加に関する項を参照してください。

CellCLIからRESTful APIへの使用の切り替え

任意の時点で、Exadata Storage Serverをロック・ダウンして、ExaCLIまたはRESTful APIによる監視/管理に切り替えられます。RESTful APIの使用をお薦めします。

RESTful APIユーザーが、「ExaCLIユーザーまたはRESTful APIユーザーの作成」のステップに従って作成されていることを確認します。

ExaCLIの詳細は、『Exadata Database Machineメンテナンス・ガイド』のExaCLIユーティリティの使用に関する項を参照してください。

トピック:

コンソールを使用したモニタリング構成の更新

Exadata Storage Serverごとに、モニタリング構成においてRESTful APIモニタリング資格証明を指定します。

  1. 「Exadata Storage Server」メニューから、「ターゲット設定」、「モニタリング構成」の順に選択します。

    「モニタリング構成」ダイアログ・ボックスが開きます。

  2. 「モニタリング・メカニズム」の値を次のように設定します。

    • ExaCLIの場合: 1
    • RESTful APIの場合: 2

  3. 「信頼自己署名証明書」を1に設定します。


    モニタリング構成: 「ExaCLIによるモニタリング」または「RESTful API」に設定します

    「OK」をクリックします。

  4. メインの「設定」メニューから、「セキュリティ」、「モニタリング資格証明」の順にクリックし、Exadata Storage Serverターゲットを選択します。

    Exadata Storage Serverごとに、RESTful APIモニタリング資格証明を入力します。

    「Save」をクリックします。

CellCLIからRESTful APIへの切替えのためのEMCLIの使用によるモニタリング構成の更新

ストレージ・サーバーの台数が多い場合、Enterprise Manager 13.5リリース更新11以降では、EMCLIを使用して、モニタリング構成全体を更新するための単一の入力ファイルによって複数のモニタリング資格証明を提供できます。この方法は、RESTful APIへの切替えが必要な場合のみサポートされます。

トピック:

EMCLIコマンドの構文

次のEMCLIコマンドでは、デプロイメント・プロシージャUpdateCellMonitorMechanismが発行され、入力ファイルconfig_file_pathによってモニタリング構成の詳細が提供されます。 

emcli submit_procedure -name=UpdateCellMonitorMechanism -input_file="<config_file_path>"

コマンド例:

emcli submit_procedure -name=UpdateCellMonitorMechanism -input_file="data:/u01/oracle/exa_discovery/emcli_cell_mon_creds_conversion"

submit_procedureコマンドの詳細は、コマンドライン・インタフェースのsubmit_procedureを参照してください。

入力ファイルのパラメータ

このデプロイメント・プロシージャについては入力ファイル内で次のパラメータを指定する必要があります。

ファイル・パラメータ 必須パラメータ 説明

dbMachineMap.dbMachineName.N

はい

ストレージ・サーバーのモニタリング・メカニズムを共通のREST API名前付き資格証明で更新する必要があるデータベース・マシンの名前。

Nは、データベース・マシンの索引番号です。たとえば、dbMachineMap.dbMachineName.0です。索引番号は0で始まり、新しいデータベース・マシン名が追加されるたびに増分されます。

dbMachineMap.agentNamedCreds.N

はい

各データベース・マシンに対応する、エージェントの名前付き資格証明。データベース・マシン名と同様に、Nはデータベースマシンの索引番号です。

たとえば、dbMachineMap.dbMachineName.0=myDatabase01の場合、同じ索引番号を使用した後の、そのデータベース・マシン用の対応するエージェント名前付き資格証明はdbMachineMap.agentNamedCreds.0=sysman:DB01_CREDSになります。

dbMachineMap.restNamedCreds

はい

Exadata Storage ServerのREST API名前付き資格証明。これを指定するための書式は次のとおりです。

<EM_USER>:<rest_named_creds>

dbMachineMap.monitoringMechanism

いいえ

デフォルトであり唯一受け入れられる値は2で、これはRESTful APIを示しています。

dbMachineMap.selfSignedCertificate

いいえ

デフォルト値は1であり、これは自己署名証明書を示しています。指定できるその他の値は0です。

dbMachineMap.securityProtocol

いいえ

デフォルト値はTLSv1.2です。

サンプル入力ファイル

次の例では、索引番号が0および1のデータベース・マシンのデータベース名はmyDatabase01およびmyDatabase02で、エージェントの名前付き資格証明はsysman:DB01_CREDSおよびsysman:DB02_CREDSです。 

dbMachineMap.dbMachineName.0=myDatabase01
dbMachineMap.dbMachineName.1=myDatabase02
dbMachineMap.agentNamedCreds.0=sysman:DB01_CREDS
dbMachineMap.agentNamedCreds.1=sysman:DB02_CREDS
dbMachineMap.restNamedCreds=sysman:rest_creds
dbMachineMap.monitoringMechanism=2
dbMachineMap.selfSignedCertificate=1
dbMachineMap.securityProtocol=TLSv1.2