ストレージ・サーバーのpatchmgr構文

8.4.3.1 ストレージ・サーバーのpatchmgr構文

patchmgrを使用して、Oracle Exadataストレージ・サーバーのソフトウェアを更新できます。

前提条件

patchmgrは、Oracle Linuxを実行しているOracle Exadataデータベース・サーバーまたはOracle Exadata以外のシステムである駆動システムで実行されます。これにより、中央のサーバーからpatchmgrを実行して、複数のOracle Exadataシステムを更新できます

ストレージ・サーバーのpatchmgr構文

./patchmgr --cells cell_host_file 
  { --patch_check_prereq [--rolling] [--unkey] [--ignore_alerts] [--ignore_date_validations] |
    --patch [--rolling [--partner_cell_stagger {true|false}]] [--unkey] [--ignore_alerts] [--ignore_date_validations] | 
    --rollback_check_prereq [--rolling] [--unkey] [--ignore_alerts] [--ignore_date_validations] | 
    --rollback [--rolling [--partner_cell_stagger {true|false}]] [--unkey] [--ignore_alerts] [--ignore_date_validations] | 
    --cleanup [--unkey] }
  [ --log_dir { log_directory | auto } ]

メイン引数

引数	説明
`--cells cell_host_file`	cell_host_fileは、更新するストレージ・サーバーのホスト名を含むテキスト・ファイルです。ファイルには、1行に1つのストレージ・サーバー・ホスト名またはIPアドレスが含まれます。リスト・ファイルが指定されていない場合、ストレージ・サーバーのパッチ適用は失敗します。ノート: ストレージ・サーバーは、cell_host_fileにリストされているのと同じ順序で更新されない場合があります。デフォルトでは、2023年12月のOracle Exadata System Softwareリリース(22.1.18および23.1.9)以降、patchmgrにより、ストレージ・サーバー更新の順序が最適化されて、7つ以上のストレージ・サーバーが含まれているローリング更新の全体的なパフォーマンスが最大化されます。詳細は、`--partner_cell_stagger`オプションを参照してください。
`--patch_check_prereq`	すべてのストレージ・サーバーで前提条件チェックを実行して、パッチをストレージ・サーバーに適用できるかどうかを判断します。
`--patch`	可能な場合はファームウェアの更新(BIOS、ディスク・コントローラ、可能な場合はディスク・ドライブ)を含むパッチをストレージ・サーバー・リスト・ファイル内のすべてのストレージ・サーバーに適用します。
`--rollback_check_prereq`	すべてのストレージ・サーバーで前提条件チェックを実行して、ストレージ・サーバーをこの特定のパッチに対してロールバックできるかどうかを判断します。
`--rollback`	パッチをロールバックします。
`--cleanup`	すべてのストレージ・サーバーですべてのパッチ・ファイルおよび一時コンテンツをクリーン・アップします。クリーン・アップする前に、問題の診断および分析用のログと情報を収集します。パッチが失敗した場合は、各ストレージ・サーバーのディレクトリ`/root/_cellupd_dpullec_`を削除することにより、パッチ・ファイルのクリーン・アップを手動で実行できます。

サポートされているオプション

ストレージ・サーバーのパッチ適用およびロールバックでは、次のオプションがサポートされています。

表8-2 ストレージ・サーバーのpatchmgrオプション

オプション	説明
`--get property`	特定のプロパティに関する情報を取得します。プロパティは、`log_dir`に設定できます。これは、すべてのログ・ファイルに割り当てられたディレクトリです。
`--ignore_alerts`	Exadataストレージ・サーバーのアクティブ・ハードウェア・アラートを無視し、パッチ適用を続行します。
`--ignore_date_validations`	日付バージョン検証を無視します。これにより、日付スタンプを以前の最新のリリースにアップグレードできます。たとえば、22.1.14.0.0.230820から23.1.5.0.0.230818にアップグレードする場合です。
`--log_dir ( log_directory\| auto )`	ログ・ディレクトリへの絶対パスを指定するか、または`auto`を指定して、起動ディレクトリおよびノード・リスト・ファイルのコンテンツに基づくログ・ディレクトリを使用できます。 `-log_dir`オプションを指定すると、複数のパッチ・マネージャ呼出しを実行することも、root以外のユーザーとしてパッチ・マネージャを実行することもできます。
`--partner_cell_stagger {true\|false}`	ローリング更新時にストレージ・サーバーを更新する順序を決定します。 `true`: ストレージ・サーバー更新の順序を最適化して、全体的なパフォーマンスを最大化します。これは、Oracle Exadata System Softwareの2023年12月リリース(22.1.18および23.1.9)以降のデフォルトのオプションです。このオプションを使用すると、patchmgrにより、更新順序の次のストレージ・サーバーが、前のストレージ・サーバーのASMパートナでないことが保証されます。この順序付けにより、更新後のウィンドウが用意され、パートナが更新のためにオフラインになる前に、各ストレージ・サーバーが再起動してフラッシュ・キャッシュを再移入できるようになります。このオプションは、cell_host_fileに7つ以上のストレージ・サーバーが含まれている場合にのみ適用されます。それ以外の場合、patchmgrはcell_host_fileで指定された順序でセルを更新します。 `false`: cell_host_fileで指定された順序でセルを更新します。
`--rolling`	ローリング方式で更新を実行することを指定します。指定しない場合、更新は非ローリング方式で実行されます。環境変数`EXA_PATCH_ACTIVATE_TIMEOUT_SECONDS`は、グリッド・ディスクがアクティブ化されるまで待機するタイムアウト値を制御します。デフォルトでは36000 (10時間)に設定されます。ノート: `-rolling`オプションが指定されている場合でも、常に非ローリング方式で前提条件チェックとクリーン・アップが実行されます。
`--smtp_from "email_addr"`	patchmgr通知の送信元(from)の電子メール・アドレスを指定します。
`--smtp_to "email_addr1 email_addr2 email_addr3 ..."`	patchmgr通知の送信先(to)の電子メール・アドレスを指定します。
`--smtp_set_envelope_sender`	「Return-Path:」メール・ヘッダーと同じ送信元(from)アドレスが使用されることを指定します。
`--unkey`	終了する前にセルへのパスワードなしのSSHアクセスを削除します。

使用上のノート

Oracle Exadata System Softwareリリース19.3以降では、オプションの先頭に--を付けます。このリリースより前のリリースでは、オプションの先頭に-を付けました。
patchmgrの複数の起動は、--log_dirオプションを使用して同じソフトウェア・ディレクトリから同時に実行できます。これにより、patchmgrは、複数のOracle Exadataシステムを同じソフトウェア・ディレクトリから同時に更新できます。
Patchmgrは、rootユーザーとしてもroot以外のユーザーとしても実行できます。patchmgrを実行しているユーザーは、patchmgrが更新するサーバーまたはスイッチへのrootレベルのSSH等価が構成されている必要があります。patchmgrをroot以外のユーザーとして実行するには、-log_dirオプションを使用する必要があります。

例8-4 ストレージ・サーバー更新の前提条件チェックの実行後のストレージ・サーバーの更新

./patchmgr -cells cell_group -patch_check_prereq 
./patchmgr -cells cell_group -patch

例8-5 ローリング形式でのストレージ・サーバーの更新

次のコマンドは、ストレージ・サーバーをローリング形式で更新し、更新が進むと電子メール通知を受信し、更新が完了した後にセルへのパスワードなしのSSHアクセスを削除します。

./patchmgr -cells cell_group -patch -rolling -unkey -smtp_from "dbm01@example.com" -smtp_to "admin1@example.com,admin2@example.com"

例8-6 複数のストレージ・サーバーの一度での更新

次のコマンドは、3つのOracle Exadataシステム上のストレージ・サーバーを同じソフトウェア・ディレクトリから同時に更新します。1つはローリング更新を使用する更新、その他の更新は非ローリングです。

この例では:

各patchmgrコマンドは、別々の端末のウィンドウから実行する必要があります。
patchmgrの各実行では、component_list_fileの内容に基づいて自動的に生成される一意のロギング・ディレクトリ名が使用されます。

(terminal1) ./patchmgr -cells cell_group_exa01 -patch -rolling -log_dir auto 
(terminal2) ./patchmgr -cells cell_group_exa02 -patch -log_dir auto 
(terminal3) ./patchmgr -cells cell_group_exa03 -patch -log_dir auto

後続のpatchmgrの実行で、異なる内容の変更された component_list_fileを使用するが、以前のpatchmgrの実行と同じロギング・ディレクトリを使用するには、-get log_dirオプションを使用してロギング・ディレクトリを取得します。次に例を示します:

最初のpatchmgrの実行のロギング・ディレクトリは、自動的に生成されます。
```
./patchmgr -cells cell_group -patch -log_dir auto
```
最後のセルが更新に失敗し、patchmgrが最初のpatchmgrの実行と同じロギング・ディレクトリを使用して、最後のセルに対してのみ再実行されると仮定します。-get log_dirオプションを使用し、元のcomponent_list_fileを使用してロギング・ディレクトリを取得します。
```
./patchmgr -cells cell_group -patch -log_dir auto -get log_dir log_dir=/tmp/patch_12.2.1.1.1.170419/log/dm01cel01_dm01cel02_cacce4ee
```
最後のセルのみを含むようにcell_groupファイルを更新するか、最後のセルのみを含む別のファイルを使用します。最初のpatchmgrの実行からロギング・ディレクトリを指定すると、このセルのグループのすべてのログが同じロギング・ディレクトリに作成されます。
```
./patchmgr -cells cell_group -patch -log_dir /tmp/patch_12.2.1.1.1.170419/log/dm01cel01_dm01cel02_cacce4ee
```

関連トピック

SSH等価の設定

親トピック: patchmgrの構文