Oracle Cloud Infrastructureドキュメント

Exadata Cloud Infrastructureシステムの手動によるパッチ適用および更新

このトピックでは、クラウド自動化外でExadata Cloud Serviceの様々なコンポーネントに対してパッチ適用および更新を行う手順について説明します。

dbaascliを使用したパッチ適用および更新の詳細は、「dbaascliを使用したOracle Grid InfrastructureおよびOracle Databaseへのパッチ適用」を参照してください。

ノート

パッチ適用操作時の継続的サービスの実現の詳細は、MAAソリューションの継続的サービスのアプリケーション・チェックリスト(ホワイト・ペーパー)を参照してください。

関連トピック

親トピック: Exadata Cloud Infrastructureシステムのパッチ適用および更新

Oracle DatabaseおよびOracle Grid Infrastructureソフトウェアへの手動によるパッチ適用

夏時間、および一部の定期パッチまたは個別パッチでは、状況により、ソフトウェアに手動でパッチを適用する必要があります。

Oracle DatabaseおよびOracle Grid Infrastructureソフトウェアの定期的なパッチ適用を実行するには、Oracle Exadata Database Service on Dedicated Infrastructureが提供する機能を使用することをお薦めします。ただし、状況によっては、Oracle DatabaseまたはOracle Grid Infrastructureソフトウェアに手動でパッチを適用する必要があります:
  • 夏時間(DST)パッチ適用: ローリング方法では適用できないため、Oracle Database DST定義のパッチはExadata Cloud Infrastructureの定期パッチ・セットに含まれていません。Oracle Database DST定義にパッチを適用する必要がある場合は、手動で行う必要があります。My Oracle Support Doc ID 412160.1を参照してください。
  • 非定期パッチまたは個別パッチ適用: 定期パッチ・セットに含まれないパッチを必要とする問題が発生した場合は、Oracleサポート・サービスと連携して適切なパッチを識別および適用します。

Oracle Databaseへのパッチ適用に関する一般的な情報は、使用しているリリースの『Oracle Databaseアップグレード・ガイド』のパッチ・セットの更新および要件に関する情報を参照してください。

ExadataクラウドVMクラスタOSの手動更新

patchmgrツールを使用して、Exadataコンピュート・ノードのオペレーティング・システムを更新します。

このユーティリティでは、再起動前、再起動時および再起動後のステップの実行など、1つ以上のコンピュート・ノードの更新全体がリモートで管理されます。ユーティリティは、Exadataコンピュート・ノードまたはOracle Linuxを実行しているExadata以外のサーバーから実行できます。ユーティリティを実行するサーバーは、「駆動システム」と呼ばれます。駆動システムを使用して、それ自体を更新することはできません。したがって、駆動システムが、更新しているシステム上のExadataコンピュート・ノードの1つである場合、別の駆動システム上で別途操作を実行してそのサーバーを更新する必要があります。

次の2つのシナリオは、更新を実行する一般的な方法を示しています:

シナリオ1: 非Exadata駆動システム

Exadataシステムの更新を実行する最も簡単な方法は、別のOracle Linuxサーバーを使用して、システムのすべてのExadataコンピュート・ノードを更新することです。

シナリオ2: Exadataノード駆動システム

1つのExadataコンピュート・ノードを使用して、システムの残りのコンピュート・ノードの更新を駆動し、更新されたノードのいずれかを使用して元のExadataドライバ・ノードで更新を駆動できます。

例: node1、node2、node3、node4という4つのコンピュート・ノードがあるハーフ・ラックExadataシステムを更新しています。まず、node1を使用してnode2、node3およびnode4の更新を駆動します。次に、node2を使用してnode1の更新を駆動します。

駆動システムには、ユーティリティによって更新される各コンピュート・ノードに対するルート・ユーザーSSHアクセスが必要です。

親トピック: Exadata Cloud Infrastructureシステムの手動によるパッチ適用および更新

OSの更新の準備

使用可能な最新のソフトウェア・バージョンおよび適切なyumリポジトリへの接続を確認します

注意:

Exadata Cloud InfrastructureインスタンスにNetworkManagerをインストールしないでください。このパッケージをインストールしてシステムを再起動すると、システムへのアクセスが著しく損なわれます。
  • 更新を開始する前に、Exadata Cloud Serviceソフトウェア・バージョン(ドキュメントID 2333222.1)を確認して、最新のソフトウェア・バージョンと使用するターゲット・バージョンを判断してください。
  • 更新プロセスの一部のステップでは、YUMリポジトリを指定する必要があります。YUMリポジトリのURLは次のとおりです: 
    http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/<latest_version>/base/x86_64.

    リージョン識別子は、Oracle Cloud Infrastructureリージョンの識別に使用されるテキスト文字列です(例: us-phoenix-1)。リージョン識別子の完全なリストは、リージョンで確認できます。

    次のcurlコマンドを実行して、Exadata Cloud Serviceインスタンス・リージョンのYUMリポジトリの最新バージョンを確認できます: 
    curl -s -X GET http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
    次の例では、米国西部(フェニックス)リージョンのYUMリポジトリの最新バージョンが返されます: 
    curl -s -X GET http://yum-us-phoenix-1.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
<a href="18.1.4.0.0/">18.1.4.0.0/</a> 01-Mar-2018 03:36 -
  • OS更新を適用するには、YUMリポジトリへのアクセスを許可するようにシステムのVCNを構成する必要があります。詳細は、オプション2: オブジェクト・ストレージとYUMリポジトリの両方へのサービス・ゲートウェイを参照してください。

Exadata Cloud Infrastructureインスタンスのすべてのコンピュート・ノードでOSを更新するには

patchmgrを使用してすべてのコンピュート・ノードを更新する手順。

この手順の例では、次のことが想定されています:

  • システムには、node1およびnode2という2つのコンピュート・ノードがあります。
  • ターゲット・バージョンは18.1.4.0.0.180125.3です。
  • 2つのノードはそれぞれ、もう一方のノードの更新の駆動システムとして使用されます。
  1. 環境の詳細を収集します。
    1. rootとしてnode1にSSHし、次のコマンドを実行してExadataのバージョンを確認します: 
      [root@node1]# imageinfo -ver
12.2.1.1.4.171128
    2. gridユーザーに切り替えて、クラスタ内のすべてのコンピュートを識別します。
      [root@node1]# su - grid
[grid@node1]$ olsnodes
node1
node1
  2. 駆動システムを構成します。
    1. node1でrootユーザーに切り替えて、root sshキー・ペア(id_rsaおよびid_rsa.pub)がすでに存在するかどうかを確認します。存在しない場合は生成します。
      [root@node1 .ssh]#  ls /root/.ssh/id_rsa*
ls: cannot access /root/.ssh/id_rsa*: No such file or directory
[root@node1 .ssh]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
93:47:b0:83:75:f2:3e:e6:23:b3:0a:06:ed:00:20:a5 root@node1.fraad1client.exadataclientne.oraclevcn.com
The key's randomart image is:
+--[ RSA 2048]----+
|o..     + .      |
|o.     o *       |
|E     . o o      |
| . .     =       |
|  o .   S =      |
|   +     = .     |
|    +   o o      |
|   . .   + .     |
|      ...        |
+-----------------+
    2. 公開キーをターゲット・ノードに配布して、このステップを確認します。この例では、ターゲット・ノードはnode2のみです。
      [root@node1 .ssh]# scp -i ~opc/.ssh/id_rsa ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
id_rsa.pub

[root@node2 ~]# ls -al /tmp/id_rsa.node1.pub
-rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
[root@node2 ~]# date
Wed Feb 28 03:33:45 UTC 2018
    3. ターゲット・ノード(この例ではnode2)で、ルートのauthorized_keysファイルにnode1のルート公開キーを追加します。
      [root@node2 ~]# cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. dbserver.patch.zipをp21634633_12*_Linux-x86-64.zipとして駆動システム(この例ではnode1)にダウンロードし、解凍します。この.zip内のファイルの詳細は、dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Server Softwareの更新(ドキュメントID 1553103.1)を参照してください。
      [root@node1 patch]# mkdir /root/patch
[root@node1 patch]# cd /root/patch
[root@node1 patch]# unzip p21634633_181400_Linux-x86-64.zip
Archive:  p21634633_181400_Linux-x86-64.zip   creating: dbserver_patch_5.180228.2/
   creating: dbserver_patch_5.180228.2/ibdiagtools/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/cable_check.pl
  inflating: dbserver_patch_5.180228.2/ibdiagtools/setup-ssh
  inflating: dbserver_patch_5.180228.2/ibdiagtools/VERSION_FILE
 extracting: dbserver_patch_5.180228.2/ibdiagtools/xmonib.sh
  inflating: dbserver_patch_5.180228.2/ibdiagtools/monitord
  inflating: dbserver_patch_5.180228.2/ibdiagtools/checkbadlinks.pl
   creating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/VerifyTopologyUtility.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/verifylib.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Node.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Rack.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Group.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Switch.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topology-zfs
  inflating: dbserver_patch_5.180228.2/ibdiagtools/dcli
   creating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteScriptGenerator.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/CommonUtils.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/SolarisAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/LinuxAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteLauncher.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteConfig.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/spawnProc.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/runDiagnostics.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/OSAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/SampleOutputs.txt
  inflating: dbserver_patch_5.180228.2/ibdiagtools/infinicheck
  inflating: dbserver_patch_5.180228.2/ibdiagtools/ibping_test
  inflating: dbserver_patch_5.180228.2/ibdiagtools/tar_ibdiagtools
  inflating: dbserver_patch_5.180228.2/ibdiagtools/verify-topology
  inflating: dbserver_patch_5.180228.2/installfw_exadata_ssh
   creating: dbserver_patch_5.180228.2/linux.db.rpms/
  inflating: dbserver_patch_5.180228.2/md5sum_files.lst
  inflating: dbserver_patch_5.180228.2/patchmgr
  inflating: dbserver_patch_5.180228.2/xcp
  inflating: dbserver_patch_5.180228.2/ExadataSendNotification.pm
  inflating: dbserver_patch_5.180228.2/ExadataImageNotification.pl
  inflating: dbserver_patch_5.180228.2/kernelupgrade_oldbios.sh
  inflating: dbserver_patch_5.180228.2/cellboot_usb_pci_path
  inflating: dbserver_patch_5.180228.2/exadata.img.env
  inflating: dbserver_patch_5.180228.2/README.txt
  inflating: dbserver_patch_5.180228.2/exadataLogger.pm
  inflating: dbserver_patch_5.180228.2/patch_bug_26678971
  inflating: dbserver_patch_5.180228.2/dcli
  inflating: dbserver_patch_5.180228.2/patchReport.py
 extracting: dbserver_patch_5.180228.2/dbnodeupdate.zip
   creating: dbserver_patch_5.180228.2/plugins/
  inflating: dbserver_patch_5.180228.2/plugins/010-check_17854520.sh
  inflating: dbserver_patch_5.180228.2/plugins/020-check_22468216.sh
  inflating: dbserver_patch_5.180228.2/plugins/040-check_22896791.sh
  inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_bash
  inflating: dbserver_patch_5.180228.2/plugins/050-check_22651315.sh
  inflating: dbserver_patch_5.180228.2/plugins/005-check_22909764.sh
  inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_perl
  inflating: dbserver_patch_5.180228.2/plugins/030-check_24625612.sh
  inflating: dbserver_patch_5.180228.2/patchmgr_functions
  inflating: dbserver_patch_5.180228.2/exadata.img.hw
  inflating: dbserver_patch_5.180228.2/libxcp.so.1
  inflating: dbserver_patch_5.180228.2/imageLogger
  inflating: dbserver_patch_5.180228.2/ExaXMLNode.pm
  inflating: dbserver_patch_5.180228.2/fwverify
    5. 更新するコンピュート・ノードのリストを含むdbs_groupファイルを作成します。ステップ1でolsnodesコマンドを実行した後にリストされたノード(駆動システム・ノードを除く)を含めます。この例では、dbs_groupにnode2のみを含めます。
      [root@node1 patch]# cd /root/patch/dbserver_patch_5.180228
[root@node1 dbserver_patch_5.180228]# cat dbs_group
node2
  3. パッチ適用の事前チェック操作を実行します。
    ノート

    次のステップで実行するバックアップに影響を与える可能性のあるシステムへの変更を防ぐために、-nomodify_at_prereqオプションを指定して事前チェック操作を実行する必要があります。そうしないと、ロールバックが必要な場合にバックアップがシステムを元の状態にロールバックできない可能性があります。 
    patchmgr -dbnodes dbs_group -precheck -yum_repo <yum_repository> -target_version <target_version> -nomodify_at_prereq
    出力は次の例のようになります: 
    [root@node1 dbserver_patch_5.180228]# ./patchmgr -dbnodes dbs_group -precheck -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -nomodify_at_prereq

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:22:45 +0000        :Working: DO: Initiate precheck on 1 node(s)
2018-02-28 21:24:57 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:15 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:47 +0000        :Working: DO: dbnodeupdate.sh running a precheck on node(s).
2018-02-28 21:28:23 +0000        :SUCCESS: DONE: Initiate precheck on node(s).
  4. 現在のシステムをバックアップします。
    ノート

    システムに変更を加える前のこの段階が、バックアップを取得するのに適切な段階です。 
    patchmgr -dbnodes dbs_group -backup -yum_repo <yum_repository> -target_version <target_version>  -allow_active_network_mounts
    出力は次の例のようになります: 
    [root@node1 dbserver_patch_5.180228]#  ./patchmgr -dbnodes dbs_group -backup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on 1 node(s).
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on node(s)
2018-02-28 21:29:01 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:18 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:51 +0000        :Working: DO: dbnodeupdate.sh running a backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on 1 node(s).
  5. 更新されるターゲット・コンピュート・ノードからすべてのカスタムRPMを削除します。カスタムRPMは事前チェックの結果でレポートされます。これには、システムのプロビジョニング後に手動でインストールされたRPMが含まれます。
    • バージョン12.1.2.3.4.170111からシステムを更新するときに、事前チェックの結果にkrb5-workstation-1.10.3-57.el6.x86_64が含まれる場合は、これを削除します。(このアイテムは、このバージョンではカスタムRPMとみなされます。)
    • exadata-sun-vm-computenode-exactまたはoracle-ofed-release-guestは削除しないでください。この2つのRPMは、更新プロセス中に自動的に処理されます。
  6. nohupコマンドを実行して更新を実行します。
    nohup patchmgr -dbnodes dbs_group -upgrade -nobackup -yum_repo <yum_repository> -target_version <target_version> -allow_active_network_mounts &
    出力は次の例のようになります:
    [root@node1 dbserver_patch_5.180228]# nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -allow_active_network_mounts &

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
NOTE    Database nodes will reboot during the update process.
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
*********************************************************************************************************

2018-02-28 21:36:26 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:36:26 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:37:44 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:38:43 +0000        :SUCCESS: DONE: Initiate prepare steps on node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on 1 node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on node(s)
2018-02-28 21:38:49 +0000        :Working: DO: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :SUCCESS: DONE: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :Working: DO: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :INFO   : node2 is ready to reboot.
2018-02-28 21:48:41 +0000        :SUCCESS: DONE: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :Working: DO: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :SUCCESS: DONE: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :Working: DO: Waiting to ensure node2 is down before reboot.
2018-02-28 21:56:18 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:56:19 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:37 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:42 +0000        :SEEMS ALREADY UP TO DATE: node2
2018-02-28 21:57:43 +0000        :SUCCESS: DONE: Initiate update on node(s)
  7. 更新操作が完了したら、更新されたコンピュート・ノード上のカーネルのバージョンを確認します。
    [root@node2 ~]# imageinfo -ver
18.1.4.0.0.180125.3
  8. (この例のように)駆動システムが更新の必要なコンピュート・ノードの場合、更新したコンピュート・ノードを駆動システムとして使用してこの手順のステップ2から7を繰り返し、残りのコンピュート・ノードを更新します。この更新例では、node2を使用してnode1を更新します。
  9. 各コンピュート・ノードで、rootとしてuptrack-installコマンドを実行して、使用可能なkspliceの更新をインストールします。
    uptrack-install --all -y

追加のオペレーティング・システム・パッケージのインストール

Oracle Exadata Database Service on Dedicated Infrastructureの追加のオペレーティング・システム・パッケージをインストールする前に、次のガイドラインを確認します。

カーネルまたはInfiniBand固有のパッケージを変更しない場合は、Oracle Exadata Database Service on Dedicated Infrastructureでオペレーティング・システム・パッケージをインストールおよび更新できます。ただし、インストール、テスト、動作保証、エラー解決などのOracleテクニカル・サポートは、インストールするOracle以外のソフトウェアには適用されません。

また、Oracle Exadataソフトウェア更新とは別にパッケージを追加または更新すると、Oracle Exadataソフトウェア更新の適用時にこれらのパッケージの追加または更新によって問題が発生する可能性があることに注意してください。追加のソフトウェア・パッケージによって、Oracle Exadataの更新を中断する可能性のある新しい依存関係が追加されるため、問題が発生することがあります。そのため、カスタマイズは最小限に抑えることをお薦めします。

追加のパッケージをインストールする場合は、それらのパッケージの削除および再インストールを自動化するスクリプトを用意することをお薦めします。Oracle Exadataの更新後、追加のパッケージをインストールする場合は、追加のパッケージにも互換性があることと、それらのパッケージが引き続き必要であることを確認します。

詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

Exadata Cloud Infrastructureインスタンスでのツールの更新

クラウド固有のツールは、dbaascliコマンドなど、ローカル操作のためにExadata Cloud InfrastructureゲストVMで使用されます。

クラウド・ツールは、新しいリリースが使用可能になると、Oracleによって自動的に更新されます。必要に応じて、dbaascliを使用したクラウド・ツールの更新のステップに従って、VMクラスタ内のすべての仮想マシンに最新バージョンのクラウド・ツールがあることを確認できます