機械翻訳について

第7章 トラブルシューティング

目次

• 7.1 Oracle Private Cloud Applianceロギング・パラメータの設定
• 7.2 Oracle Private Cloud Appliance更新のプロキシ設定の追加
• 7.3 Oracle VM Agentパスワードの変更
• 7.4 Oracle Private Cloud Applianceアップグレーダとの組合せによる手動のアップグレード前チェックおよびアップグレード後チェックの実行
• 7.5 パスワード変更後のバックアップのリストア
• 7.6 SNMPサーバー・モニタリングの有効化
• 7.7 SSL暗号化でのカスタムCA証明書の使用
  • 7.7.1 キーストアの作成
  • 7.7.2 キーストアのインポート
• 7.8 プロビジョニングに失敗した場合のコンピュート・ノードの再プロビジョニング
• 7.9 コンピュート・ノードのプロビジョニング解除および置換
• 7.10 コンピュート・ノードをプロビジョニングする際のタイムアウトの問題の排除
• 7.11 テナント・グループの構成の不一致からのリカバリ
• 7.12 最良パフォーマンスのためのXen CPU頻度スケーリングの構成

この章では、複数の一般的な問題のシナリオを解決する方法について説明します。

7.1 Oracle Private Cloud Applianceロギング・パラメータの設定

トラブルシューティングの際に、サポート問合せを開いている場合は、Oracle Private Cloud Applianceのロギング・パラメータの変更が必要になることがあります。 この設定は/etc/ovca.confに含まれており、CLIを使用して変更できます。

環境内の2つの管理ノードそれぞれについて、次の手順を実行する必要があります。

管理ノードのOracle Private Cloud Applianceロギング・パラメータの変更

1. 管理ノードへのコマンドライン・アクセスを取得します。 通常、これはSSHを使用して実行され、グローバルOracle Private Cloud Applianceパスワードを持つルート・ユーザーとしてログインします。

2. 第4章、「Oracle Private Cloud Applianceコマンドライン・インタフェース(CLI)」で説明されているように、CLIを使用してアプライアンス・ログ設定を表示または変更します。 構成ファイルが破損する可能性を防ぐため、CLIは/etc/ovca.confファイルの読取りおよび編集を安全に行います。

   • 構成ファイル内の構成可能な設定の現在の値を表示するには、次のようにCLIを実行します。

     # pca-admin show system-properties

   • ログ・レベルを変更するには:

     # pca-admin set system-property log_level service LEVEL

     service引数は、新しいログ・レベルが適用されるログ・ファイル・カテゴリです。 次のサービスを指定できます: バックアップ, cli診断,モニター, ovca, snmp, syncservice

     LEVEL値は次のいずれかです: DEBUG、INFO、WARNING、ERROR、CRITICAL

   • ログ・ファイル・サイズを変更するには:

     # pca-admin set system-property log_size SIZE

     SIZEは、MBで表され、1から512までの数値です。

   • 格納されているバックアップ・ログ・ファイルの数を変更するには、次の手順を実行します。

     # pca-admin set system-property log_count COUNT

     COUNTは、0から100までの様々なファイルです。

   • ログ・ファイルが格納されるロケーションを変更するには、次のようにします。

     # pca-admin set system-property log_file service PATH

     PATHは、選択したserviceのログ・ファイルが格納される新しいロケーションです。 次のサービスを指定できます: backup、cli、diagnosis、monitor、ovca、snmpおよびsyncservice。

     注意

     新しいログ・ファイルのパスが存在することを確認します。 それ以外の場合は、ログ・サーバーは動作を停止します。

     /var/logは、常にエントリの先頭に付加されます。 絶対パスは、/var/log/PATH に変換されます。

     管理ノードのアップグレード時には、ログ・ファイルのパスはデフォルト値にリセットされます。

3. 新しいログ・レベルの設定は、管理ノードがリブートされた後、またはサービスがアクティブ管理ノード・シェルでservice ovca restartコマンドを実行して再起動された後にのみ有効になります。

7.2 Oracle Private Cloud Appliance更新のプロキシ設定の追加

データ・センターが無制限のインターネット・アクセスを提供せず、HTTP、HTTPSまたはFTPトラフィックを制御するためのプロキシ・サーバーが存在する場合、ソフトウェア更新を実行するなどの理由から、外部リソースにアクセスできるように管理ノードを構成する必要がある場合があります。

環境内の2つの管理ノードそれぞれについて、次の手順を実行する必要があります。

管理ノードに対するプロキシ設定の追加

1. 管理ノードへのコマンドライン・アクセスを取得します。 通常、これはSSHを使用して実行され、グローバルOracle Private Cloud Applianceパスワードを持つルート・ユーザーとしてログインします。

2. 第4章、「Oracle Private Cloud Applianceコマンドライン・インタフェース(CLI)」の説明に従ってCLIを使用して、プロキシ設定を表示または変更します。 構成ファイルが破損する可能性を防ぐため、CLIは/etc/ovca.confファイルの読取りおよび編集を安全に行います。

   • 構成ファイル内の構成可能な設定の現在の値を表示するには、次のようにCLIを実行します。

     # pca-admin show system-properties

   • HTTPプロキシを設定するには、次のようにします。

     # pca-admin set system-property http_proxy http://IP:PORT

     IPはプロキシ・サーバーのIPアドレス、PORTはリスニングを行うTCPポートです。

     注意

     プロキシ・サーバーでユーザー名とパスワードが必要な場合は、プロキシ・サービスにアクセスするときにこれらを指定する必要があります。 プロキシURLの一部として資格証明を指定しないでください。これは、機密情報を保護されていない接続で送信することを意味するためです。

   • HTTPSプロキシを設定するには:

     # pca-admin set system-property https_proxy https://IP:PORT

   • FTPプロキシを設定する手順は、次のとおりです。

     # pca-admin set system-property ftp_proxy ftp://IP:PORT

3. 単一パラメータを設定すると、構成ファイルが自動的にリライトされ、プロキシ設定がただちにアクティブになります。

7.3 Oracle VM Agentパスワードの変更

Oracle VM Agentのパスワードは、Oracle Private Cloud Appliance Dashboardの認証タブ、およびOracle Private Cloud Appliance CLIのupdate passwordコマンドでは変更できません。 エージェント・パスワードを変更する必要がある場合は、Oracle VM Managerを使用します。

Oracle VM Agentパスワードの変更手順は、次のロケーションにあります: Oracle VM Managerリリース3.4ユーザーズ・ガイドのOracle VM ServersでのOracle VM Agentパスワードの変更。

7.4 Oracle Private Cloud Applianceアップグレーダとの組合せによる手動のアップグレード前チェックおよびアップグレード後チェックの実行

コントローラ・ソフトウェアの更新は、Oracle Private Cloud Applianceアップグレーダを使用してインストールする必要があります。 アップグレーダ・ツールにより多数の前提条件チェックが自動化されますが、アップグレード・プロセスの前後に手動で実行する必要があるタスクもいくつかあります。 この項では、手動タスクを示します。 詳細は、「ドキュメントID 2442664.1」 for Controllerソフトウェア・リリース2.3.4のサポート・ノートまたはControllerソフトウェア・リリース2.4.2のサポート・ノート「ドキュメントID 2605884.1」を参照してください。

検証のみモードでOracle Private Cloud Applianceアップグレーダを起動します。 これらのステップは、第3.3.3項、「アップグレードの準備の確認」で説明されています。 アップグレーダによって報告された問題を修正し、すべてのチェックがエラーなしで完了するまで検証手順を繰り返します。 その後、手動でアップグレード前チェックに進みます。

手動アップグレード前チェックの実行

1. WebLogicパスワードを確認します。

   アクティブ管理ノードで、次のコマンドを実行します:

   # cd /u01/app/oracle/ovm-manager-3/bin
   # ./ovm_admin --listusers

   要求された場合にはWebLogicパスワードを入力します。 パスワードが正しくない場合、ovm_admin コマンドは失敗し、リターン・コード1で終了します。 パスワードが正しい場合は、コマンドによってユーザーが一覧表示され、0のリターン・コードで終了します。 パスワードが正しくない場合は、Oracle Private Cloud Appliance webインタフェースにログインして、wls-weblogicパスワードを必要なパスワードに変更します。

2. 管理ノードに接続されている外部ストレージLUNがないことを確認してください。

   いずれの管理ノードからも外部ストレージLUNが表示されないことを確認してください。 詳細は、「ドキュメントID 2148589.1」のサポート・ノートを参照してください。

3. 管理ノードでカスタマイズされたinet設定を確認してください。

   次に示すアップグレード・パスによっては、xinetdをアップグレードする場合があります。 この場合、変更された設定は自動的にデフォルトにリセットされます。 カスタムinet設定を書き留めて、アップグレード・プロセスの完了後に確認します。 これらの設定変更は、/etc/postfix/main.cfファイルに格納されます。

4. MySQLデータベースのオブジェクト数を登録します。

   アクティブ管理ノードのrootユーザーとして、スクリプトnumber_of_jobs_and_objects.shをダウンロードして実行します。 「ドキュメントID 2442664.1」 for Controllerソフトウェア・リリース2.3.4のサポート・ノートまたはControllerソフトウェア・リリース2.4.2のサポート・ノート「ドキュメントID 2605884.1」にアタッチされています。 データベース内のオブジェクト数およびジョブ数を戻します。 これらの番号を記録します。

5. 管理ノードのフェイルオーバーを検証します。

   アクティブ管理ノードをリブートして、スタンバイ管理ノードがアクティブなロールを引き継ぐことができることを確認します。

6. 内部ZFS Storage Applianceに使用されているNFSプロトコルを確認してください。

   両方の管理ノードで、コマンドnfsstat -mを実行します。 マウントされた各シェアは、NFSv4プロトコルを使用する必要があります。

7. 両方の管理ノードの/etc/yum.confファイルを確認します。

   プロキシがYUM用に構成されている場合、ファイルからその行をコメント・アウトまたは削除します。

すべてのアップグレード前チェックに対してシステムを発行し、アップグレードの準備が完了していることを確認したら、コントローラ・ソフトウェア更新を実行します。 これらのステップは、第3.3.4項、「コントローラ・ソフトウェア更新の実行」で説明されています。 コントローラ・ソフトウェアを正常にアップグレードしたら、管理ノードおよびコンピュート・ノードのアップグレード後手動チェックに進みます。

管理ノードでの手動アップグレード後チェックの実行

1. 管理対象外のストレージ・アレイの名前を確認します。

   アップグレード後に非管理ストレージ・アレイの名前が正しく表示されなくなった場合は、「ドキュメントID 2244130.1」のサポート・ノートに記載されている回避策に従ってください。

2. Oracle VMで、エラーおよび警告をチェックします。

   Oracle VM Manager web UIで、次のことが発生しないことを確認します。

   • コンピュート・ノードまたはストレージ・サーバーに対するパ・ドラック・アイコン

   • コンピュート・ノード、リポジトリまたはストレージ・サーバーに対する赤いエラー・アイコン

   • コンピュート・ノード、リポジトリまたはストレージ・サーバーに対する黄色の警告アイコン

3. Oracle Private Cloud Applianceダッシュボードのすべてのコンポーネントのステータスを確認します。

   ハードウェア・ビューの各ハードウェア・コンポーネントの右側に緑色のチェック・マークが表示され、赤いエラー・アイコンが表示されていないことを確認します。

4. ネットワークをチェックします。

   すべてのネットワークを検証します - ファクトリのデフォルトおよびカスタム - 存在し、正しく構成されています。

コンピュート・ノードでの手動アップグレード後チェックの実行

1. すべてのコンピュート・ノードのmin_free_kbytes設定を変更します。

   「ドキュメントID 2314504.1」のサポート・ノートを参照してください。 対応するステップを適用し、変更が永続的になったらコンピュート・ノードを再起動します。

2. fmパッケージがすべてのコンピュート・ノードにインストールされていることを確認してください。

   rpm -q fmコマンドを実行します。 パッケージがインストールされていない場合は、次のコマンドを実行します。

   # chkconfig ipmi on; service ipmi start; LFMA_UPDATE=1 /usr/bin/yum install fm -q -y -\-nogpgcheck

3. 仮想マシン・テストを実行します。

   仮想マシンのテストを開始し、ネットワークが機能していることを確認します。 互換性のあるコンピュート・ノードに仮想マシンを移行し、ライブ・マイグレーションが正しく動作することを確認します。

7.5 パスワード変更後のバックアップのリストア

Oracle VM Managerまたはその関連コンポーネントOracle WebLogic ServerおよびOracle MySQLデータベースのパスワードを変更した場合、パスワード変更の前に行われたバックアップからOracle VM Managerをリストアする必要があると、パスワードは同期されなくなります。 このパスワードの不一致により、Oracle VM Managerはデータベースに接続できずに起動できないため、最初にパスワードが同じであることを確認する必要があります。

ノート

次のステップは、バックアップ後にパスワードが変更された場合に固有ではありません。 リストア操作に適用されます。

Oracle VM Manager 3.4.2を含むリリース2.3.1では、データベース・データ・ディレクトリのクリーンアップがリストア・プロセスに組み込まれるため、このステップをスキップできます。

Oracle VM Managerをバックアップからリストアする際のパスワードの不一致の解決

1. Oracle VM Manager MySQLデータベースの手動バックアップを作成して、誤ったデータ損失を防ぎます。 アクティブ管理ノードのコマンドラインで、次のコマンドを実行します。

   • 2.2.x以前のリリース:

     # /u01/app/oracle/ovm-manager-3/bin/createBackup.sh -n ManualBackup1

   • 2.3.1以上のリリース:

     # /u01/app/oracle/ovm-manager-3/ovm_tools/bin/BackupDatabase -w
     INFO:  Backup started to:
              /u01/app/oracle/mysql/dbbackup/ManualBackup-20190524_102412

2. Oracle Private Cloud ApplianceのDashboardで、Oracle MySQLのデータベース・パスワードをバックアップ時の状態に戻します。

3. アクティブ管理ノードのコマンドラインで、rootユーザーとしてOracle VM ManagerおよびMySQLサービスを停止し、MySQLデータを削除します。

   # service ovmm stop
   # service ovmm_mysql stop
   # cd /u01/app/oracle/mysql/data
   # rm -rf appfw ibdata ib_logfile* mysql mysqld.err ovs performance_schema

4. oracleユーザーとして、選択したバックアップからデータベースをリストアします。

   • 2.2.x以前のリリース:

     # su oracle
     $ bash /u01/app/oracle/ovm-manager-3/ovm_shell/tools/RestoreDatabase.sh BackupToBeRestored
     INFO: Expanding the backup image...
     INFO: Applying logs to the backup snapshot...
     INFO: Restoring the backup...
     INFO: Success - Done!
     INFO: Log of operations performed is available at: 
           /u01/app/oracle/mysql/dbbackup/BackupToBeRestored/Restore.log

   • 2.3.1以上のリリース:

     # su oracle
     $ bash /u01/app/oracle/ovm-manager-3/ovm_tools/bin/RestoreDatabase.sh BackupToBeRestored
     INFO: Expanding the backup image...
     INFO: Applying logs to the backup snapshot...
     INFO: Restoring the backup...
     INFO: Success - Done!
     INFO: Log of operations performed is available at: 
           /u01/app/oracle/mysql/dbbackup/BackupToBeRestored/Restore.log

5. rootユーザーとして、MySQLおよびOracle VM Managerサービスを起動します。

   $ su root
   # service ovmm_mysql start
   # service ovmm start

   両方のサービスが正常に再起動されると、リストア操作が完了します。

7.6 SNMPサーバー・モニタリングの有効化

トラブルシューティングまたはハードウェア・モニタリングのため、Oracle Private Cloud Applianceのサーバー上でSNMPを有効にすると役立つ場合があります。 SNMPのツールは使用できますが、プロトコルがデフォルトで有効になっていません。 この項では、標準的なOracle Linuxおよびその他のOracle Private Cloud Appliance Management Information Base (MIB)を使用してSNMPを有効にする方法を説明します。

管理ノードでのSNMPの有効化

1. SSHおよびスーパーユーザー権限のあるアカウントを使用して、管理ノードにログインします。

   ノート

   この手順で使用するデータ・センターのIPアドレスは例です。

   # ssh root@10.100.1.101
   root@10.100.1.101's password:
   [root@ovcamn05r1 ~]#

2. マウントされたディレクトリ/nfs/shared_storage/mgmt_image/Packagesで必要なrpmパッケージを特定します。このパッケージは、ZFSストレージ・アプライアンスのMGMT_ROOTファイル・システムにあります。 次のパッケージは、Oracle Private Cloud Appliance ISOイメージの一部です。

   • net-snmp-5.7.2-49.el7_9.1.x86_64

   • net-snmp-agent-libs-5.7.2-49.el7_9.1.x86_64

   • net-snmp-libs-5.7.2-49.el7_9.1.x86_64

   • net-snmp-utils-5.7.2-49.el7_9.1.x86_64

   • ovca-snmp-0.9-3.el7.x86_64.rpm

   • lm_sensors-libs-3.4.0-8.20160601gitf9185e5.el7.x86_64.rpm

3. 次のコマンドを実行して、これらのパッケージをインストールします。

   # rpm -ivh net-snmp-utils-5.7.2-49.el7_9.1.x86_64.rpm net-snmp-5.7.2-49.el7_9.1.x86_64.rpm /
   net-snmp-agent-libs-5.7.2-49.el7_9.1.x86_64.rpm /
   net-snmp-libs-5.7.2-49.el7_9.1.x86_64.rpm lm_sensors-3.4.0-8.20160601gitf9185e5.el7.x86_64.rpm

4. SNMP構成ファイルの作成: /etc/snmp/snmpd.conf。

   これは、標準のサンプル構成です。

   rocommunity public
   syslocation MyDataCenter
   dlmod ovca /usr/lib64/ovca-snmp/ovca.so

5. snmpdサービスを有効にします。

   # systemctl start snmpd

6. 必要に応じて、ブート時にsnmpdサービスを有効にします。

   # systemctl enable snmpd

7. ファイアウォール上のSNMPポートを開きます。

   # firewall-cmd --permanent --zone=public --add-port=161/udp
   # firewall-cmd --permanent --zone=public --add-port=162/udp
   # firewall-cmd --reload

   この管理ノードでSNMPを使用する準備ができました。 標準的なOracle Linux MIBに加えて、次のデータも提供されます。

   • ORACLE-OVCA-MIB::ovcaVersion

   • ORACLE-OVCA-MIB::ovcaType

   • ORACLE-OVCA-MIB::ovcaStatus

   • ORACLE-OVCA-MIB::nodeTable

   使用例:

   # snmpwalk  -v 1 -c public -O e 130.35.70.186 ORACLE-OVCA-MIB::ovcaVersion
   # snmpwalk  -v 1 -c public -O e 130.35.70.111 ORACLE-OVCA-MIB::ovcaStatus
   # snmpwalk  -v 1 -c public -O e 130.35.70.111 ORACLE-OVCA-MIB::nodeTable

8. 2番目の管理ノードでこの手順を繰り返します。

コンピュート・ノードでのSNMPの有効化

ノート

Oracle Private Cloud Applianceコンピュート・ノードでは、net-snmp、net-snmp-utilsおよびnet-snmp-libsはファクトリにすでにインストールされていますが、SNMPサービスは有効化または構成されていません。

1. スーパーユーザー権限でSSHおよびアカウントを使用して、コンピュート・ノードにログインします。 アプライアンスの内部管理ネットワークを介してアクセスできます。

   ssh root@192.168.4.5
   root@192.168.4.5's password:
   [root@ovcacn27r1 ~]#

2. SNMP構成ファイルの作成: /etc/snmp/snmpd.confおよびこの行が含まれていることを確認します。

   rocommunity public
   

3. snmpdサービスを有効にします。

   # systemctl start snmpd

   このコンピュート・ノードでSNMPを使用する準備ができました。

4. 必要に応じて、ブート時にsnmpdサービスを有効にします。

   # systemctl enable snmpd

5. Oracle Private Cloud Appliance環境にインストールされている他のすべてのコンピュート・ノードで、この手順を繰り返します。

7.7 SSL暗号化でのカスタムCA証明書の使用

• 7.7.1 キーストアの作成
• 7.7.2 キーストアのインポート

デフォルトでは、Oracle Private Cloud ApplianceおよびOracle VM Managerは認証に自己署名されたSSL証明書を使用します。 すべてのHTTPトラフィックにSSL暗号化を提供する機能がありますが、既知で認識されている認証局(CA)から独自のカスタムの信頼できる証明書を取得してインストールすることをお薦めします。

Oracle Private Cloud ApplianceダッシュボードとOracle VM Manager webインタフェースの両方は、Oracle WebLogic Serverで稼働します。 デジタル証明書とキーストアを更新する機能は、JDKのJava KeytoolとともにOracle VM Key Toolによって提供されます。 ツールは、Oracle Private Cloud Appliance管理ノードにインストールされます。

7.7.1 キーストアの作成

サード・パーティのCA証明書がまだない場合は、新しいキーストアを作成できます。 作成するキーストアには、秘密キーのエントリが1つ含まれます。 キーストアを作成した後、その秘密キーの証明書署名リクエスト(CSR)を生成し、CSRをサードパーティのCAに送信します。 その後、CAはCSRに署名し、署名済のSSL証明書とCA証明書のコピーを返し、この証明書をキーストアにインポートします。

カスタムCA証明書を使用するキーストアの作成

1. SSHおよびスーパーユーザー権限のあるアカウントを使用して、管理ノードにログインします。

   ノート

   この手順で使用するデータ・センターのIPアドレスは例です。

   # ssh root@10.100.1.101
   root@10.100.1.101's password:
   [root@ovcamn05r1 ~]#

2. Oracle VM Manager WebLogicドメインのセキュリティ・ディレクトリに移動します。

   # cd /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security

3. 新規キーストアを作成します。 所有権をユーザー・グループdbaのユーザーoracleに移動します。

   # /u01/app/oracle/java/bin/keytool -genkeypair -alias ca -keyalg RSA -keysize 2048 \
   -keypass W******1 -storetype jks -keystore mykeystore.jks -storepass W******1
   # chown oracle.dba mykeystore.jks

4. 証明書署名リクエスト(CSR)を生成します。 所有権をユーザー・グループdbaのユーザーoracleに移動します。

   # /u01/app/oracle/java/bin/keytool -certreq -alias ca -file pcakey.csr \
   -keypass W******1 -storetype jks -keystore mykeystore.jks -storepass W******1
   # chown oracle.dba pcakey.csr

5. CSRファイルを、署名のために関連するサード・パーティCAに送信します。

6. CAから返された署名済ファイルの場合、ユーザー・グループdbaのユーザーoracleに所有権を移します。

   # chown oracle.dba ca_cert_file
   # chown oracle.dba ssl_cert_file

7. 署名付きCA証明書をキーストアにインポートします。

   # /u01/app/oracle/java/bin/keytool -importcert -trustcacerts -noprompt -alias ca \
   -file ca_cert_file -storetype jks -keystore mykeystore.jks -storepass W******1

8. 署名付きSSL証明書をキーストアにインポートします。

   # /u01/app/oracle/java/bin/keytool -importcert -trustcacerts -noprompt -alias ca \
   -file ssl_cert_file -keypass W******1 -storetype jks -keystore mykeystore.jks \
   -storepass W******1

9. setsslkeyコマンドを使用して、新しいキーストアを使用するようにシステムを構成します。

   # /u01/app/oracle/ovm-manager-3/ovm_upgrade/bin/ovmkeytool.sh setsslkey
   Path for SSL keystore: /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/mykeystore.jks
   Keystore password: 
   Alias of key to use as SSL key: ca
   Key password: 
   Updating keystore information in WebLogic
   Oracle MiddleWare Home (MW_HOME): [/u01/app/oracle/Middleware] 
   WebLogic domain directory: [/u01/app/oracle/ovm-manager-3/domains/ovm_domain] 
   Oracle WebLogic Server name: [AdminServer] 
   WebLogic username: [weblogic] 
   WebLogic password: [********] 
   WLST session logged at: /tmp/wlst-session5820685079094897641.log

10. クライアント証明書のログインを構成します。

    # /u01/app/oracle/ovm-manager-3/bin/configure_client_cert_login.sh \
    /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/pcakey.crt

11. Oracle Private Cloud Appliance Dashboardにログインして、新しいSSL構成をテストします。 そこから、OVMマネージャへのログイン・ボタンを使用してOracle VM Managerに進みます。 ブラウザに、接続がセキュアであることが示されます。

7.7.2 キーストアのインポート

CA証明書とSSL証明書がすでにある場合は、SSL証明書を使用してキーストアを作成します。 その後、そのキーストアをOracle Private Cloud Applianceにインポートし、SSLキーストアとして構成できます。

注意

以前のバージョンのOracle Private Cloud Applianceソフトウェアでovmkeytool.shを使用してカスタム・キーを生成した場合、コントローラ・ソフトウェアを更新する前にキーを再生成する必要があります。 手順は、「ドキュメントID 2597439.1」のサポート・ノートを参照してください。

既存のCAおよびSSL証明書を含むキーストアのインポート

1. SSHおよびスーパーユーザー権限のあるアカウントを使用して、管理ノードにログインします。

   ノート

   この手順で使用するデータ・センターのIPアドレスは例です。

   # ssh root@10.100.1.101
   root@10.100.1.101's password:
   [root@ovcamn05r1 ~]#

2. キーストアをインポートします。

   # /u01/app/oracle/java/bin/keytool -importkeystore -noprompt \
   -srckeystore existing_keystore.jks -srcstoretype source_format -srcstorepass W******1
   -destkeystore mykeystore.jks -deststoretype jks -deststorepass W******1

3. setsslkeyコマンドを使用して、新しいキーストアを使用するようにシステムを構成します。

   # /u01/app/oracle/ovm-manager-3/ovm_upgrade/bin/ovmkeytool.sh setsslkey
   Path for SSL keystore: /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/mykeystore.jks
   Keystore password: 
   Alias of key to use as SSL key: ca
   Key password: 
   Updating keystore information in WebLogic
   Oracle MiddleWare Home (MW_HOME): [/u01/app/oracle/Middleware] 
   WebLogic domain directory: [/u01/app/oracle/ovm-manager-3/domains/ovm_domain] 
   Oracle WebLogic Server name: [AdminServer] 
   WebLogic username: [weblogic] 
   WebLogic password: [********] 
   WLST session logged at: /tmp/wlst-session5820685079094897641.log

4. クライアント証明書のログインを構成します。

   # /u01/app/oracle/ovm-manager-3/bin/configure_client_cert_login.sh /path/to/cacert

   /path/to/cacert は、CA証明書への絶対パスです。

5. Oracle Private Cloud Appliance Dashboardにログインして、新しいSSL構成をテストします。 そこから、OVMマネージャへのログイン・ボタンを使用してOracle VM Managerに進みます。 ブラウザに、接続がセキュアであることが示されます。

7.8 プロビジョニングに失敗した場合のコンピュート・ノードの再プロビジョニング

コンピュート・ノードのプロビジョニングは、様々な構成ステップおよびインストール・ステップが含まれる複雑な編成済プロセスで、いくつかの再起動です。 接続の変動、タイミングの問題やその他の予期しないイベントが発生したために、コンピュート・ノードが断続的な状態でスタックしたり、エラー・ステータスになる可能性があります。 ソリューションは、コンピュート・ノードを再プロビジョニングすることです。

警告

再プロビジョニングは、プロビジョニングの完了に失敗したコンピュート・ノードに「唯一の」を適用する必要があります。

正しくプロビジョニングされてコンピュート・ノードを実行するために、環境から完全にコンピュート・ノードをロックしたり、機能の損失やデータ破損を引き起こす可能性のある不正な使用を防ぐために、再プロビジョニング機能がブロックされます。

プロビジョニングに失敗した場合のコンピュート・ノードの再プロビジョニング

1. Oracle Private Cloud Applianceダッシュボードにログインします。

2. 「ハードウェア・ビュー」タブに移動します。

3. エラー・ステータスであるか、プロビジョニング・プロセスでスタックになったコンピュート・ノードをロールオーバーします。

   ポップアップ・ウィンドウに、構成およびステータス情報のサマリーが表示されます。

   図7.1 コンピュート・ノード情報およびハードウェア・ビューの再プロビジョニング・ボタン

   
   
   

4. コンピュート・ノードのプロビジョニングが不完全で、サーバーが断続的なステータスで数時間スタックしている場合は、ポップアップ・ウィンドウの「再プロビジョニング」ボタンをクリックします。

5. 確認ダイアログ・ボックスが表示されたら、OKをクリックして、コンピュート・ノードの再プロビジョニングを開始します。

サーバーをOracle VMサーバー・プールに追加した後で、コンピュート・ノードのプロビジョニングが失敗する場合は、追加のリカバリ・ステップが必要な場合があります。 再プロビジョニングに関連付けられたクリーンアップ・メカニズムでは、Oracle VM構成からコンピュート・ノードを削除できない場合があります。 たとえば、サーバーがロック状態であるか、サーバー・プールのアクティブ・ロールを所有している場合は、手動で構成解除する必要があります。 この場合、別の方法では許可されないOracle VM Managerで操作を実行する必要があります。 コンピュート・ノードの電源を手動でオンにする必要がある場合もあります。

Oracle VM構成からのコンピュート・ノードの削除

1. Oracle VM Managerユーザー・インタフェースにログインします。

   詳細な手順は、第5.2項、「Oracle VM Manager Web UIへのログイン」を参照してください。

2. 「サーバーおよびVM」タブに移動し、Rack1_ServerPoolというサーバー・プールに、正常にプロビジョニングできなかったコンピュート・ノードが含まれていることを確認します。

3. 実行中のジョブが原因でコンピュート・ノードがロックされている場合は、Oracle VM Managerの「ジョブ」タブで中止します。

   Oracle VMでのジョブの使用方法の詳細は、「Oracle VM Managerユーザーズ・ガイド」を参照してください。 「ジョブ・タブ」というタイトルの項を参照してください。

4. Oracle VMサーバー・プールからコンピュート・ノードを削除します。

   『Oracle VM Managerユーザー・ガイド』の「サーバー・プールの編集」というタイトルの項を参照してください。 サーバー・プールを編集する際には、選択したサーバーのリストからコンピュート・ノードを移動してください。 コンピュート・ノードが未割当てサーバー・フォルダに移動されます。

5. Oracle VM Managerからコンピュート・ノードを削除します。

   「Oracle VM Managerユーザーズ・ガイド」の「サーバーの削除」というタイトルの項の指示に従ってください。

障害が発生しているコンピュート・ノードがOracle VM構成から削除された場合、Oracle Private Cloud Applianceダッシュボードに戻って再プロビジョニングしてください。 コンピュート・ノードの電源が切断されていて再プロビジョニングを開始できない場合は、サーバーの電源を手動で投入します。

7.9 コンピュート・ノードのプロビジョニング解除および置換

障害のあるコンピュート・ノードを交換または修復する必要がある場合、あるいは、容量が高ければ新しいモデルを優先してコンピュート・ノードがリタイアされ、パフォーマンスが高ければ、コンピュート・ノードをアプライアンス・ラックから取り外す前にプロビジョニング解除することを強くお薦めします。 プロビジョニング解除によって、コンピュート・ノードのすべての構成エントリが確実に削除されるため、置換のコンピュート・ノードがインストールされたときに競合が発生しません。

修復または置換のためのコンピュート・ノードのプロビジョニング解除

1. Oracle VM Managerユーザー・インタフェースにログインします。

   詳細な手順は、第5.2項、「Oracle VM Manager Web UIへのログイン」を参照してください。

2. プロビジョニング解除するコンピュート・ノード以外のすべての仮想マシンを移行します。 コンピュート・ノードでVMが実行されている場合、プロビジョニング解除コマンドは失敗します。

3. SSHおよびスーパーユーザー権限でアカウントを使用して、アクティブな管理ノードにログインし、Oracle Private Cloud Applianceコマンドライン・インタフェースを起動します。

   # ssh root@10.100.1.101
   root@10.100.1.101's password:
   root@ovcamn05r1 ~]# pca-admin
   Welcome to PCA! Release: 2.4.2
   PCA>

4. プロビジョニングをロックして、プロビジョニング解除直後にコンピュート・ノードを再プロビジョニングできないようにします。

   PCA> create lock provisioning
   Status: Success

5. 削除するコンピュート・ノードをプロビジョニング解除します。 必要に応じて、追加のコンピュート・ノードに対して繰り返します。

   PCA> deprovision compute-node ovcacn29r1
   ************************************************************
    WARNING !!! THIS IS A DESTRUCTIVE OPERATION.
   ************************************************************
   Are you sure [y/N]:y
   Shutting down dhcpd:                                [ OK ]
   Starting dhcpd:                                     [ OK ]
   Shutting down dnsmasq:                              [ OK ]
   Starting dnsmasq:                                   [ OK ]
   
   Status: Success

6. 必要なコンピュート・ノードが正常にプロビジョニング解除されたら、プロビジョニング・ロックを解放します。 アプライアンスは通常の動作を再開します。

   PCA> delete lock provisioning
   ************************************************************
    WARNING !!! THIS IS A DESTRUCTIVE OPERATION.
   ************************************************************
   Are you sure [y/N]:y
   Status: Success

必要な修理が完了した場合、または交換用のコンピュート・ノードの準備が整ったら、コンピュート・ノードをラックに取り付け、必要なケーブルを接続します。 コントローラ・ソフトウェアによって新しいコンピュート・ノードが検出され、プロビジョニング・プロセスが自動的に起動されます。

7.10 コンピュート・ノードをプロビジョニングする際のタイムアウトの問題の排除

プロビジョニング・プロセスは、Oracle VM Managerのレベルで実行される多くの構成操作と、個々のOracle VM Serversまたはコンピュート・ノードのアプライアンス・レベル・オーケストレーションです。 仮想化環境が大きくなるに従って - つまり、仮想マシン、ストレージ・パスおよびネットワークの数が増えると、様々な検出タスクの完了に必要な時間が大幅に増加します。

最大タスク継続時間は、標準的な基本ラック設定に確実に対応するように構成されています。 ただし、指定された点で、既存の構成の複雑さは、多数のコンピュート・ノードにレプリケートする場合、標準のタイムアウトよりもタスクの期間が長くなります。 その結果、プロビジョニングの失敗が発生します。

多くのプロビジョニング・タスクは共通のタイムアウト・メカニズムを使用するように設計されているため、グローバル・タイムアウトの増加のみではこの問題を解決できません。 これを行うと、システムの全体的なパフォーマンスが低下します。 この問題を解決するために、システム構成ファイルの複数の設定によりタイムアウトの詳細な定義を行うために、追加のコードが実装されました: /var/lib/ovca/ovca-system.conf。

追加のコンピュート・ノードをプロビジョニングする際にタイムアウト問題が発生した場合、構成の特定のタイムアウト設定を調整することで解決できることがあります。 ジョブの失敗の発生に応じて、storage_refresh_timeout、discover_server_timeoutまたはその他のパラメータを変更すると、プロビジョニング操作を正常に完了できます。 この変更は、両方の管理ノードに適用する必要があります。

タイムアウトの問題が原因でコンピュート・ノードでプロビジョニングに失敗した場合は、Oracle担当者に連絡してください。 Oracleの製品担当者は、これらの失敗を分析し、必要に応じて新しいタイムアウト・パラメータを推奨できます。

7.11 テナント・グループの構成の不一致からのリカバリ

テナント・グループは基本的にはOracle VMサーバー・プールであり、アプライアンス・レベルで作成および管理されます。また、すべてのプール・メンバーに対して自動カスタム・ネットワーク構成をサポートします。 Oracle VM Managerにテナント・グループが表示されます。管理者はサーバー・プールを変更することがありますが、そのような操作はOracle Private Cloud Applianceでサポートされておらず、構成が不一致になります。

Oracle VM Managerでテナント・グループの構成を誤って変更した場合は、この項の手順に従って、環境の一貫性のない状態を修正します。

注意

次に説明する操作で問題が解決されない場合は、影響を受けるコンピュート・ノードを再プロビジョニングする必要があります。 このため、停止時間が発生し、データが失われる可能性があります。

テナント・グループへのサーバーの追加

Oracle VM Managerを使用してプールまたはテナント・グループにサーバーを追加しようとすると、操作は成功します。 ただし、新しく追加されたサーバーは、サーバーが追加されたことをOracle Private Cloud Applianceコントローラ・ソフトウェアが認識しないため、テナント・グループに関連付けられているカスタム・ネットワークに接続されません。

この状況を修正するには、まずOracle VM Managerでテナント・グループからサーバーを再度削除します。 次に、Oracle Private Cloud Appliance CLIを介して正しいメソッドで、サーバーをテナント・グループに再度追加します。 第2.7.2項、「テナント・グループの構成」を参照してください。

その結果、Oracle VM ManagerとOracle Private Cloud Applianceは再度同期します。

テナント・グループからのサーバーの削除

Oracle VM Managerを使用してプールまたはテナント・グループからサーバーを削除しようとすると、操作は成功します。 ただし、Oracle Private Cloud Applianceコントローラ・ソフトウェアは、サーバーが削除されたことを認識しておらず、テナント・グループに関連付けられているカスタム・ネットワーク構成がサーバーから削除されることはありません。

この時点で、Oracle Private Cloud Applianceはサーバーがまだテナント・グループのメンバーであると想定し、Oracle Private Cloud Appliance CLIを使用してテナント・グループからサーバーを削除しようとすると、エラーが発生します。

PCA> remove compute-node ovcacn09r1 myTenantGroup
************************************************************
 WARNING !!! THIS IS A DESTRUCTIVE OPERATION.
************************************************************
Are you sure [y/N]:y

Status: Failure
Error Message: Error (SERVER_001): Exception while trying to 
remove the server ovcacn09r1 from tenant group myTenantGroup.
ovcacn09r1 is not a member of the Tenant Group myTenantGroup.

この状況を修正するには、Oracle VM Managerを使用して、以前に削除したサーバーをテナント・グループに再度追加します。 その後、Oracle Private Cloud Appliance CLIを使用してテナント・グループからサーバーを削除します。 第2.7.2項、「テナント・グループの構成」を参照してください。 remove serverコマンドが正常に適用されると、サーバーはテナント・グループから削除され、カスタム・ネットワーク構成は削除され、サーバーはOracle VM Managerの未割当てのサーバー・グループに配置されます。 その結果、Oracle VM ManagerとOracle Private Cloud Applianceは再度同期します。

7.12 最良パフォーマンスのためのXen CPU頻度スケーリングの構成

Xenハイパーバイザは、CPU頻度スケーリングを使用してパフォーマンスと電力消費を分散するメカニズムを提供します。 このメカニズムは、Current Governorと呼ばれ、CPUがアイドル状態のときにクロック速度をスロットルすることで消費電力を削減できます。

Oracle VM Serverの特定のバージョンでは、デフォルトでCurrent Governorがondemandに設定されており、これは負荷に基づいてCPUクロックを動的にスケーリングします。 Oracleでは、Oracle Private Cloud Applianceコンピュート・ノードでperformanceの設定により、Current Governorを実行することが推奨されています。 特に、Oracle VM Serverのアップグレード後にシステムが予期したとおりに動作していない場合は、Current Governorが正しく構成されていることを確認してください。

コンピュート・ノードの現在の管理設定を確認するには、SSHを使用してログインし、Oracle Linuxプロンプトで次のコマンドを入力します。

]# xenpm get-cpufreq-para
cpu id               : 0
affected_cpus        : 0
cpuinfo frequency    : max [2301000] min [1200000] cur [2301000]
scaling_driver       : acpi-cpufreq
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : performance
scaling_avail_freq   : *2301000 2300000 2200000 2100000 2000000 1900000 1800000 1700000 1600000 1500000 1400000 1300000 1200000
scaling frequency    : max [2301000] min [1200000] cur [2301000]
turbo mode           : enabled
[...]

このコマンドによって、コンピュート・ノード内のすべてのCPUがリストされます。 current_governorパラメータがperformance以外に設定されている場合、Current Governor構成を変更する必要があります。

パフォーマンス・モードを手動で設定するには、次のコマンドを入力します: xenpm set-scaling-governor performance。

この設定を永続的にするには、grub.cfgファイルに追加します。

1. 次の例に示すように、/etc/default/grubテンプレート・ファイルにxen cpu頻度設定を追加します。

   GRUB_CMDLINE_XEN="dom0_mem=max:6144M allowsuperpage dom0_vcpus_pin dom0_max_vcpus=20 cpufreq=xen:performance max_cstate=1"

2. 次のコマンドを使用して、grub.cfgを再構築します。

   # grub2-mkconfig -o /boot/grub2/grub.cfg

Copyright © 2013, 2021, Oracle and/or its affiliates. 法律上の注意点