※本ページは、”Exadata : Giving Customers more Value and Convenience – Simplified Management of Third-party Software” の翻訳です。

はじめに

Oracle Exadataは、シンプルさ、運用効率、および管理の合理化を実現します。統合された可用性の高い安全なエンタープライズ・データベース・プラットフォームですべての規模と重大度のOracleワークロードに最高のパフォーマンスを発揮します。Exadata開発チームは、新機能や機能強化を頻繁に追加することでイノベーションとプラットフォームの価値を追求し、実際のユースケースに深く焦点を当てています。Exadataでサードパーティ・ソフトウェアを実行しているお客様には、依存関係処理の改善によるメンテナンス作業を最小限に抑えるExadata patchmgrの拡張についてお伝えできることを嬉しく思います。

サードパーティのソフトウェア依存関係を検出および管理するためのpatchmgrのインテリジェンス

Exadataへのインストールを目的としたサード・パーティ・ソフトウェアは、主にソフトウェアの配布、管理および更新のためにLinuxで使用されるパッケージ管理システムであるRPMとして提供されます。サード・パーティのソフトウェアRPMは、Exadataの更新中に競合を引き起こす可能性があります。標準的な方法は、Exadataシステム・ソフトウェアの更新前にサード・パーティ・ソフトウェアをアンインストールしてから、更新後に再インストールすることです。Exadata System Software 25.1の新しい拡張機能は、5つの簡単な手順で、サードパーティ製ソフトウェアのアンインストール/再インストールを行わずにExadataを更新できるように設計されています。

Exadata更新時のサード・パーティ・ソフトウェアの管理

Exadataを更新する準備ができており、1つ以上のサード・パーティ・ソフトウェア・アプリケーションがデータベース・サーバーにインストールされています。

ステップ1: サードパーティ・ソフトウェアとの競合の事前チェック

patchmgrコマンドを–precheckオプションとともに使用して、更新とともにアップグレードされるライブラリとサード・パーティのソフトウェアが競合するかどうかを確認します。コマンドの出力がローカルコンソールに表示されます。出力は詳細であり、検出されたライブラリの依存関係の問題または競合が顕著に示されます。

–precheckオプションを指定したpatchmgrコマンドのコマンド構文および説明を次に示します。

./patchmgr --precheck --dbnodes db_nodes_list --log_dir_auto /home/oracle/patchmgr/log --repo { base_URL | zipped_iso_file }                

Option help
===========
./patchmgr                           # Invoke the patchmgr utility
--precheck                           # Intelligently determine dependency errors on each node
                                     # Run the pre-upgrade validation checks in the database nodes
                                     # specified in the host list, in a non-rolling fashion.
--dbnodes                            # The db_nodes_list is a text file identifying the database
                                     # servers that are the target of the patchmgr operation.
                                     # The file must exist and contain one target database server host
                                     # name or IP address on each line. The server running patchmgr
                                     # cannot be included in the file
--log_dir_auto                       # The absolute path to the log directory, or you can specify
                                     # "auto" to use a log directory that is based on the
                                     # directory you started patchmgr from and the content of the nodes list file.
                                     # Specifying the --log_dir option enables you to run multiple
                                     # patch manager invocations and also to run patch manager
                                     # as a non-root user.
--repo {base_URL | zipped_iso_file} # zip file with the Exadata ISO for the target release

例として、次のスクリーンショットは、「<<<<<<<<<<」を使用して手動で強調表示された競合を含む実際の出力を取得します。この例では、競合マーカーは、バージョン0.189のパッケージelfutils-debuginfod-clientで、パッケージelfutils-libelfがバージョン0.189である必要があることを示していますが、Exadataの更新では、elfutils-libelfをバージョン0.190に更新する予定です。

dependency

検出された競合(読みやすくするために拡大)を示すログの行は次のとおりです。
 

dependency

この依存関係の競合は、patchmgrによってインテリジェントに識別され、事前チェック中に問題としてコールアウトされるため、更新の前に対処する必要があります。
前述のログは、アプリケーションexadata-sun-kvm-computenode-minimumがelfutils-libelfをバージョン0.190以上にする必要があることも指摘しています。この状況は、あるアプリケーションがベースとなるパッケージをバージョン0.189にする必要があり、別のアプリケーションがバージョン0.190以上を必要とする場合の依存関係の競合を反映しています。

ステップ2: 必要に応じて、サードパーティ製ソフトウェアの更新されたRPMを取得します。

事前チェックでサード・パーティのソフトウェアとの競合が示された場合、サード・パーティのソフトウェアRPMも更新する必要があります。そのためには、更新されたサード・パーティ・ソフトウェアRPMをソフトウェア・ベンダーから取得し、追加のRPMリストに追加する必要があります。この更新されたサード・パーティ・ソフトウェアを新しいライブラリに対してテストし、アップグレード後にExadataでスムーズに操作できるようにすることがベンダーに求められます。このテストは個別に完了する必要があり、更新されたRPMをインストール用に提供する前に機能を確認する必要があります。

前述の例では、クライアントelfutils-debuginfod-client-0.189-3.e18.x86_64はバージョン0.189で、事前チェックは競合を示します。更新されたクライアント・バージョンelfutils-debuginfod-client-0.190-3.e18.x86_64は適切なバージョンであり、競合しません。同様に、更新されたサード・パーティ・ソフトウェアRPMが使用可能である必要があります。

ステップ3: ネストされた依存性パッケージおよびRPMの決定

Linuxでのパッケージ依存関係は階層的に拡張でき、各依存関係はさらにネストされた依存関係に依存する可能性があります。ベスト・プラクティスは、additional-rpmsリストの事前チェックおよび更新を繰り返し使用して反復チェックを実行し、最終的に必要な依存関係の包括的なリストを取得することです。階層のすべてのレベルが更新を成功させるには、事前チェックに合格する必要があります。すべての依存関係が理解されたら、更新をスムーズに完了するために必要なパッケージの完全なリストに関するすべての情報があります。

patchmgrコマンドでRPMリストを指定するオプションは複数あります。

  1. patchmgrコマンドラインのカンマ区切りRPMリスト。次のテキスト・ブロックでOption 1として表示されます
  2. 必要なRPMを含むローカル・ディレクトリを指し示します(次のテキスト・ブロックにOption 2として示されています)。
  3. 次のテキスト・ブロックのOption 3に示すように、patchmgrコマンドラインのリストで指定します。
  4. 次のテキスト・ブロックのOption4のyumまたはdnfリポジトリから必要なRPMをダウンロードします
# Options for specifying additional-rpms

Option 1: [--additional-rpms [ rpm_spec[,rpm_spec]...]]
              # Optionally specifies additional packages (RPMs) to include during
              # a pre-check or update operation. You can specify the additional RPMs
              # as a comma-separated list

Option 2: [--additional-rpms [rpm_dir]]   
              # Variant of Option 1 but with a rpm directory specified. This is
              # where the additional RPM list is maintained. 

Option 3: [--additional-rpms-list rpm_list]  
             # Optionally specify a text file containing the list of additional
             # packages (RPMs) to include during a pre-check or update operation.
             # In the file, each RPM must be specified on a separate line.

Option 4: --additional-rpms-from-repo   
              # Optionally instructs the update target server(s) to download the RPMs
              # directly from a Yum or DNF repository. A suitable repository must be
              # configured on the target server and the configured repository must be
              # accessible from the target server

NOTE: The option description text is partially reproduced here. The Oracle official
patchmgr command reference has a complete description of each option.

ステップ3が正常に完了すると、必要なすべての依存関係が決定され、新しいテスト済みのサードパーティ製ソフトウェアも使用できます。

ステップ4: 最後のadditional-rpmsリストによる事前チェックテスト

新しい拡張patchmgr機能は、追加のRPMを参照、プルおよびマージできるようになりました。追加のRPMは、前のステップで作成したadditional-RPMsディレクトリから取得されます。

このadditional-RPMsリストにリストされているRPMは、新しく利用可能なオプション(–additional-RPMs)によってpatchmgrによってインストールできるようになりました。patchmgrは、additional-RPMsリストのRPMを更新中の各データベース・サーバーにダウンロードし、patchmgr更新操作でこれらのRPMをマージします。

patchmgrコマンドの構文と最後の事前チェックを示します。

 

$ patchmgr \
  --dbnodes db_nodes_list \
                # The database_node_file is a text file identifying the database
                # servers that are the target of the patchmgr operation.
                # The file must exist and contain one target database server host
                # name or IP address on each line. The server running patchmgr
                # cannot be included in the file.
  --precheck    # Final pre-check
  --repo /scratch/u01/patchmgr/builds/exadata_ol8_25.1.0.0.0.xxxxxx_Linux-x86-64.zip \
                # zip file with the Exadata ISO for the release being updated to
  --target_version 25.1.0.0.0.xxxxxx \ # The full patch version
  --log_dir auto \ # The absolute path to the log directory, or you can specify
                # auto to use a log directory that is based on the directory
                # you started patchmgr from and the content of the nodes list file.
                # Specifying the --log_dir option enables you to run multiple
                # patch manager invocations and also to run patch manager
                # as a non-root user.
  --additional_rpms /scratch/u01/patchmgr/test/                 
                # Precheck using the required RPMs

ステップ5: Exadata更新の完了

サードパーティ製のソフトウェアおよび依存関係RPMが準備されており、更新の準備ができています。patchmgrコマンドを再度実行し、–upgradeオプションを指定して更新を完了します。

upgradeオプションを指定したpatchmgrコマンドの構文を示します。

 

# Run the patchmgr command with the upgrade option
$ patchmgr \
--dbnodes db_nodes_list \
                # The database_node_file is a text file identifying the database
                # servers that are the target of the patchmgr operation.
                # The file must exist and contain one target database server host
                # name or IP address on each line. The server running patchmgr
                # cannot be included in the file.
--upgrade       # Update
--repo /scratch/u01/patchmgr/builds/exadata_ol8_25.1.0.0.0.xxxxxx_Linux-x86-64.zip \
                # zip file with the Exadata ISO for the release being updated to
                # Specifying a web-based repository is also allowed.
                # Example: http://
  /yum/EXADATA/dbserver/24.2/latest/x86_64/
    --target_version 25.1.0.0.0.xxxxxx \      # The full patch version
--log_dir auto \           # The absolute path to the log directory, or you can specify
                # auto to use a log directory that is based on the directory
                # you started patchmgr from and the content of the nodes list file.
                # Specifying the --log_dir option enables you to run multiple
                # patch manager invocations and also to run patch manager
                # as a non-root user.
--additional_rpms /scratch/u01/patchmgr/test/             
                # Required RPMs

 

これでExadataの更新が完了します。カバーの下では、patchmgrコマンドがトリガーされると、additional-RPMsリストのRPMがデータベース・ノードにダウンロードされ、更新に挿入されます。サード・パーティのソフトウェアRPMも、新しく決定された依存性パッケージとともに更新され、必要なすべての依存性に対処されるため、サード・パーティのソフトウェアは、サード・パーティのソフトウェアをアンインストールして再インストールする追加負荷なしで引き続き動作します。

まとめ

Exadata System Software 25.1は、サードパーティ・ソフトウェアをインストールするお客様にとって大きな機能拡張をもたらします。Exadataプラットフォームの更新中の依存関係の競合は、前述のように、5つの簡単なステップでpatchmgrによって検出および対処されます。お客様は、Exadataインフラストラクチャを最新の状態に保ちながら、Exadata更新の前後にサードパーティ・ソフトウェアが機能し続けるようになりました。お客様は、重要なサードパーティ・ソフトウェアに影響を与えずに、必要なRPMまたは更新されたRPMを自信を持って計画して設定し、Exadataを更新できます。この機能改善は、運用効率、合理化されたサードパーティ・ソフトウェア管理、および顧客へのより大きな価値と利便性の提供に対するOracleのコミットメントを反映しています。

謝辞

この記事は、Rene KundersmaとChris Craftの貴重な洞察とガイダンスから利益を得ています。Reneは、このイノベーションのアーキテクトであり、ChrisはOracleの熟練技術者です。