保守性の問題

このセクションでは、サービス、サポート、アップグレード、およびデータ保護機能に関連する既知の問題と回避策について説明します。

コンポーネントのアップグレード順序が変更されました

プラットフォームの更新時、「最初にコンピュート・ノードを更新する必要があります」。この順序でコンピュート・ノードを更新しないと、アップグレードが失敗してシステムが中断する可能性があります。

回避策: 次の順序でプラットフォーム・アップグレードを完了します:

コンピュート・ノード
管理ノード
管理ノードのオペレーティング・システム
MySQL Clusterデータベース
シークレット・サービス
コンポーネントのファームウェア
Kubernetesクラスタ
マイクロサービス

バグ: 34358305

バージョン: 3.0.1

終了したインスタンスのDR構成が自動的にリフレッシュされない

DR構成の一部であるインスタンスを終了すると、スイッチオーバーまたはフェイルオーバー操作は、終了したインスタンスが原因で失敗します。正しい手順は、最初にDR構成からインスタンスを削除してから、インスタンスを終了することです。最初にインスタンスを削除するのを忘れた場合は、DR構成を手動でリフレッシュして、終了したインスタンスのエントリを削除する必要があります。 DR構成を関連するリソースの状態と同期させることは、データ損失からの保護に不可欠です。

回避策: この動作が予想されます。終了する前にDR構成からインスタンスを削除するか、最初にインスタンスを削除せずにインスタンスを終了した場合はDR構成をリフレッシュしてください。

バグ: 33265549

バージョン: 3.0.1

クラスタ状態が異常なときに管理ノードをリブートすると、プラットフォームの整合性の問題が発生

管理ノードのリブートは、正確なタイミングで、多くの場合特定の順序で、制御された方法で多くの内部相互依存操作を実行する必要があるため、デリケートな手順です。管理ノードが正しくリブートせず、クラスタに再参加した場合、アプライアンス・プラットフォームとインフラストラクチャ・サービスの不安定化につながる可能性があります。症状は次のとおりです: CrashLoopBackOff状態のマイクロサービス・ポッド、MySQLクラスタ・ノード間のデータ競合、NDBクラスタ・デーモン・プロセスの繰返し再起動など。

回避策: 管理ノードをリブートする前に、常にMySQLクラスタが正常なヘルスであることを確認します。管理ノードのコマンド行から、次の例に示すコマンドを実行します。出力が類似せず、クラスタの問題を示している場合は、restart /Systemコマンドを使用して、影響を受ける管理ノードの電源をILOM経由で再投入してください。

予防措置として、すべての管理ノードをリブートする必要がある場合 - たとえば、完全な管理クラスタのアップグレード・シナリオでは、2つの管理ノードのリブート操作間で少なくとも10分の間隔を確認してください。

# ndb_mgm -e show
Connected to Management Server at: pcamn01:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     3 node(s)
id=17   @253.255.0.33  (mysql-8.0.25 ndb-8.0.25, Nodegroup: 0)
id=18   @253.255.0.34  (mysql-8.0.25 ndb-8.0.25, Nodegroup: 0, *)
id=19   @253.255.0.35  (mysql-8.0.25 ndb-8.0.25, Nodegroup: 0)

[ndb_mgmd(MGM)] 3 node(s)
id=1    @253.255.0.33  (mysql-8.0.25 ndb-8.0.25)
id=2    @253.255.0.34  (mysql-8.0.25 ndb-8.0.25)
id=3    @253.255.0.35  (mysql-8.0.25 ndb-8.0.25)

[mysqld(API)]   18 node(s)
id=33   @253.255.0.33  (mysql-8.0.25 ndb-8.0.25)
id=34   @253.255.0.33  (mysql-8.0.25 ndb-8.0.25)
[...]

バグ: 34484128

バージョン: 3.0.2

ULNミラーは、コンピュート・ノードのパッチ適用に必要なパラメータではありません

現在のパッチ適用機能の実装では、すべてのパッチ・リクエストにULNフィールドが必要です。管理者は、このフィールドを使用して、データ・センター・ネットワーク内に設定されたULNミラーのURLを指定します。ただし、管理ノードの共有ストレージ上のセカンダリ内部ULNミラーからパッチが適用されるという点で、コンピュート・ノードには若干異なる方法でパッチが適用されます。そのため、ULN URLは技術的にはコンピュート・ノードにパッチを適用する必要はありませんが、パッチ適用コードでは必須パラメータとみなされるため、入力する必要があります。

回避策: コンピュート・ノードにパッチを適用する場合は、パッチ・リクエストにパラメータとしてデータ・センターのULNミラーへのURLを含めます。提供されたURLに関係なく、管理ノードからアクセス可能なセカンダリULNミラーを使用してパッチ適用が実行されます。

バグ: 33730639

バージョン: 3.0.1

ネットワーク・コントローラのパッチ・コマンドのタイムアウト

プラットフォームにパッチを適用すると、ネットワーク・コントローラの更新中にタイムアウトしたためにプロセスが失敗することがあります。この場合、ログには「ERROR [pcanwctl upgrade Failed]」などのエントリが含まれます。

回避策: 同じパッチ・コマンドを再度実行します。操作が成功するはずです。

バグ: 33963876

バージョン: 3.0.1

アプライアンス・アップグレード用のISOイメージをダウンロードする際の低転送速度

アプライアンス・ソフトウェアのアップグレードの準備中に、ISOイメージがアプライアンスの内部ストレージにダウンロードされている間、転送速度が非常に低くなることがあります。ダウンロードが完了するまでに何時間もかかることが予想される場合は、スパイン・スイッチで非常に多くの翻訳が実行されている可能性があります。これは、スパイン・スイッチをリロードする必要があることを示します。

さらに、アプライアンス・ソフトウェア・バージョン3.0.2-b1081557を実行しているシステムの場合 - アクティブな「Kubernetesエンジン」クラスタが存在する3.0.2-b1325160では、OKEネットワーク・ロード・バランサにアクセスできない場合があります。

回避策: Oracleに連絡してください。 NAT統計を確認し、スイッチをリロードする手順が提供されます。

アプライアンス・ソフトウェアを最新バージョンにアップグレードすると、準備フェーズ中にスイッチがリロードされます。この時点以降、回避策は不要になります。

バグ: 37807342

バージョン: 3.0.2

ポートが停止しているときにアップグレードまたはパッチ手順を切り替えない

スパイン・スイッチとリーフ・スイッチは、高可用性(HA)のためにペアで構成され、新しいファームウェアは、単一のコマンドで起動されるローリング・アップグレードまたはパッチ操作によってインストールされます。スイッチ内の特定のポートが停止すると、HA構成が影響を受け、新しいファームウェアのインストール中にアップグレードまたはパッチ操作によって短い停止が発生します。スイッチ・ポートが停止しているときに、アップグレードおよびパッチ・コマンドをブロックするためのチェック・イン・プレースはありません。接続はリストアされますが、HAを再度有効にするには、非アクティブなスイッチ・ポートを修正する必要があります。

回避策: リーフ・スイッチおよびスパイン・スイッチをアップグレードまたはパッチ適用する前に、すべてのデバイスで必要なすべてのポートがアクティブであることを確認します。 Grafanaでスイッチのステータスを確認します。異常なポートが検出された場合は、この問題が最初に修正されていることを確認します。スイッチ・ペアの高可用性構成をリストアできるように、使用できないスイッチ・ポートを修正する必要があります。

バグ: 37049316

バージョン: 3.0.1

ワークフロー・サービスからのレスポンスを待機中にOracle Cloud Infrastructureイメージのアップグレードが失敗

アップグレード手順は、アップグレード・ワークフロー・サービス(UWS)を介して調整される多くのタスクで構成されます。アプライアンス上のOracle Cloud Infrastructureイメージのアップグレード中に、UWSがレスポンスの送信に失敗し、アップグレード・ワークフローがタイムアウトすることがあります。 Upgraderログは、問題を次のように記録します:

[2025-05-21 19:38:57 1393662] ERROR (util_tasks:306) [Waiting for UWS response (Waiting for a response from UWS)] Failed 
Did not receive a response from UWS, manually import with 'importPlatformImages' command
[2025-05-21 19:38:58 1393662] INFO (util_tasks:310) [UpgradePlanUpdateTask (None)] Not Run 
Task did not run. This task only runs when OciConfigurationTask's upgrade is True AND Upgrade OCI Instance images has status of Passed.
[2025-05-21 19:38:58 1393662] INFO (oci_configuration:52) Component='ociImages', path='None', upgrade-required=True, upgrade-plan=True

回避策: サービスWeb UIまたはサービスCLIからイメージのアップグレードを再試行します。アップグレードは、次の試行で正常に完了すると予想されます。

バグ: 37984531

バージョン: 3.0.2

不完全なバックアップ・ジョブが原因でアップグレードが失敗

アプライアンス・ソフトウェアのアップグレード時に、タイムアウトが発生する前に内部バックアップが正常に完了しないため、プラットフォームのアップグレード段階が失敗することがあります。この場合、コマンド出力には次のものが含まれます:

[2025-02-09 01:59:43 5321] INFO (util_tasks:1773) Waiting for BRS cronjob Upgrade to finish processing.
[2025-02-09 01:59:43 5321] ERROR (util_tasks:306) [BRS cronjob Upgrade (Recreate BRS cronjob)] Failed

ログには、次の例のような詳細が含まれています:

Tasks 64 - Name = BRS cronjob Upgrade
Tasks 64 - Message = Command: ['kubectl', '-n', 'default', 'exec', 'brs-76c968c746-58gm4', '-c', 'brs', '--', '/usr/sbin/default-backup'] failed (255): stderr: time="2025-02-09T01:47:59Z" level=error msg="exec failed: unable to start container process: error adding pid 76969 to cgroups: failed to write 76969: openat2 /sys/fs/cgroup/systemd/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod4a3334cf_a8fd_4608_a709_3a6703c6627c.slice/crio-d97e021a3b22d8d805b8fcede91266f59fb177002fab108d3f34affd43858d95.scope/cgroup.procs: no such file or directory"
command terminated with exit code 255

回避策: 管理ノードにログインします。バックアップ(BRSサービス)のcronjobを制御するポッドを削除します。新しいポッドが自動的に起動されます。

# kubectl delete pod brs-76c968c746-58gm4
pod "brs-76c968c746-58gm4" deleted

# kubectl get pods -A | grep brs
default                   brs-76c968c746-kcdnh           3/3     Running    0       47s

# kubectl exec -it brs-76c968c746-kcdnh -c brs -- /usr/sbin/default-backup
# echo $?
0

バグ: 37572149

バージョン: 3.0.2

アップグレード準備コマンド後のIAM Service Reports同期ステータス・エラー

アプライアンス・ソフトウェア・アップグレードの準備フェーズ中に、最新のアップグレード機能が実行中のシステムに追加されます。管理サービスは、このプロセスの必須コンポーネントであり、preUpgradeコマンドの実行時にすでに更新されます。これにより、IAMサービスと緊密に統合された管理サービス間で一時的なバージョンが一致しなくなります。

IAMへの新しい管理APIコールは、次の「サービスCLI」例に示すように、対応するバージョンのIAM Serviceがシステムで使用可能になるまで失敗する可能性があります:

PCA-ADMIN> show iamservice
Data:
 Id = 66acfdd4-aa4e-4bda-ba9d-001d67fccf96
 Type = IamService
 IAM Link Mode = AUTO_SYNC
 Overall Communication State = Error
 Communication Error Message = Error processing iam.syncstatus.get response: PCA_GENERAL_000014: Error returned from IAM service. Code: 'NotSupportedError'. Message: 'Not Supported'
 Name = Iam Service
 Work State = Normal
 FaultIds 1 = id:f021e0a9-11b5-4483-a077-7a62049e637b type:Fault name:IamServiceSyncStatusFaultStatusFault(Iam Service)

回避策: エラー・メッセージは、IAM Serviceとの同期の問題があることを示唆していますが、実際にはすべての内部操作が予想どおりに進んでいます。 IAMサービスは、プラットフォームおよびコンテナ化されたマイクロサービスのアップグレード・ステップが完了したときに最新であり、その後エラーが消えます。回避策は必要ありません。

バグ: 37775091

バージョン: 3.0.2

共有ブロック・ボリュームを持つインスタンスは、異なるディザスタ・リカバリ構成の一部にできません

複数のインスタンス間で共有されるブロック・ボリュームをアタッチできます。これらのインスタンスをディザスタ・リカバリ(DR)構成に追加すると、そのアタッチされたボリュームは専用のZFSストレージ・プロジェクトに移動されます。ただし、インスタンスがそれぞれ別のZFSストレージ・プロジェクトを持つ異なるDR構成に属している場合、システムは共有ブロック・ボリュームを移動できません。そのため、常に無効なDR構成になります。そのため、ディザスタ・リカバリ・サービスでは、共有ブロック・ボリュームを含むコンピュート・インスタンスを異なるDR構成に追加することはサポートしていません。

回避策: 共有ブロック・ボリュームを持つインスタンスを同じDR構成に含めたり、共有ボリュームではなく各インスタンスに異なるブロック・ボリュームをアタッチすることを検討してください。

バグ: 34566745

バージョン: 3.0.2

イニシエータ・グループが存在しないため、DRフェイルオーバー・エラーが発生しました

ネイティブ・ディザスタ・リカバリ・サービスでは、フェイルオーバー計画がプライマリ・システムの停止時に使用されます。ただし、このサービスによって、プライマリ・システムの稼働中に管理者がフェイルオーバーを実行することは防止されません。フェイルオーバー中に、プライマリとスタンバイの間でロール・リバーサルを実行できるように、DRサービスは、スタンバイ・システムのZFS Storage Applianceに格納されているレプリケートされたデータのLUN情報を変更します。プライマリ・システムがオンラインの場合は、レプリケーション更新が5分ごとに送信され、スタンバイのLUNパラメータに加えられた変更が元に戻されます。これにより、ロール・リバーサルが失敗し、次の例のようなエラーが発生します:

The initiator group '225fc1ba7c38_grp' no longer exists. It may have been destroyed or 
renamed by another administrator, or this LUN may have been imported from another system.

回避策: プライマリ・システムがオンラインの場合、フェイルオーバーを実行しないでください。かわりにスイッチオーバーを使用します。

このフェイルオーバー・エラーが発生した場合、リカバリ・プロシージャにはZFS Storage Applianceに対する変更が含まれます。 Oracleに連絡してください。

バグ: 37988746

バージョン: 3.0.2

サポート・バンドルの生成時にタイムアウトが発生

Oracleサポートから支援をリクエストする場合は、通常、リクエストとともにサポート・バンドルをアップロードする必要があります。次の例のようなコマンドを使用して、管理ノードからサポート・バンドルが生成されます:

# support-bundles -m time_slice --all -s 2022-01-01T00:00:00.000Z -e 2022-01-02T00:00:00.000Z

指定したタイム・スライスについて収集されるログ・エントリが多数ある場合は、API例外および"「コマンドを実行できません」"というエラー・メッセージでプロセスがタイムアウトする可能性があります。実際、データ収集はバックグラウンドで続行されますが、エラーの原因は、データ収集プロセスを実行しているKubernetesポッドへのwebsocket接続のタイムアウトです。

回避策: サポート・バンドルのデータを収集するときにこのタイムアウトの問題が発生した場合は、より短い時間スライスを指定して、収集されるデータの量を減らしてください。プロセスが30分以内に完了した場合、エラーは発生しません。

バグ: 33749450

バージョン: 3.0.2

DR操作が断続的に失敗

負荷が高い特定の状況では、サイト・ガードEMスクリプトがPCA DR REST APIを使用してDR操作を実行しようとすると、Private Cloud Appliance 3.0でDR操作を実行するサイト・ガード・ユーザーがセッション外エラーが発生することがあります。

この状態は、システムがリクエストによってオーバーロードされた場合に発生します。

回避策: 操作を再試行します。

バグ: 33934952

バージョン: 3.0.1, 3.0.2

MN01アップグレードする最後の管理ノードの場合、ホストのアップグレードが失敗

管理ノードへのアップグレードとパッチは、順番に実行されます。 MN01がその順序で最後になると、管理ノードのアップグレードまたはパッチ操作が失敗します。この問題を回避するには、管理ノードのアップグレードまたはパッチ適用操作を開始する前に、管理ノードの仮想IPアドレスがMN02 に割り当てられていることを確認してください。

回避策: アップグレードまたはパッチ適用の前に、管理ノートの仮想IPアドレスをMN02に割り当てます。

# pcs resource move mgmt-rg pcamn02

バグ: 35554754

バージョン: 3.0.2

Kubernetesクラスタへのパッチ適用またはアップグレード時のノードの排出の失敗

マイクロサービス・ポッドが不適切な状態になるのを回避するために、各Kubernetesノードは、次の使用可能なバージョンにアップグレードされる前にドレインされます。 Upgraderを使用すると、ノードを続行する前にすべてのポッドを正常に削除できます。ただし、ポッドがスタックしている場合、または時間内に削除されない場合、アップグレード・プロセスまたはパッチ・プロセスは停止します。

回避策: ポッドが削除されないためにKubernetesノードを排出できない場合は、障害の原因となるポッドを手動で削除する必要があります。

sshを使用してKubernetesノードにログオンし、適切なホスト名を使用して次のコマンドを実行します:
```
# kubectl drain pcamn00 --ignore-daemonsets --delete-local-data
```
排出が終わるのを待ちます。コマンド出力は、: node/pcamn00 drained。
drainコマンドが失敗した場合、出力には障害の原因となっているポッドが示されます。 drainコマンドを再度実行して--forceオプションを追加するか、deleteコマンドを使用します。
```
# kubectl delete pod pod-name --force
```
たとえば:
```
# kubectl delete pod pod-name --force
```
Kubernetesアップグレードまたはパッチ・コマンドを再実行します。 Upgraderは、プロセスが中断された場所から続行します。

バグ: 37291231

バージョン: 3.0.2

Oracle Auto Service Requestアップグレード後に無効

Oracle Auto Service Request (ASR)にPrivate Cloud Applianceが登録されており、サービスがアプライアンスで有効になっている場合、アプライアンス・ソフトウェアのアップグレード後にASRサービスが無効になることがあります。この問題は、バージョン3.0.2-b925538にアップグレードする際に確認されています。

回避策: アプライアンス・ソフトウェアのアップグレード後に、ASR構成を確認します。 ASRサービスが無効になっている場合は、手動で再度有効にします。「Oracle Private Cloud Appliance管理者ガイド」の「ステータスおよびヘルス・モニタリング」章の「自動サービス・リクエストの使用」を参照してください。

バグ: 35704133

バージョン: 3.0.2

`NotReady`状態のコンピュート・ノードによるアップグレードまたはパッチ適用のブロック

Linuxの既知の問題により、コンピュート・ノードがパッチ適用またはアップグレードをブロックする可能性があります。この問題は、コンピュート・ノードをアップグレードしてリブートしたあとに発生します。ノードはNotReady状態にリブートされるため、それ以上のパッチ適用やアップグレードはできません。

回避策: 影響を受けるコンピュート・ノードをリブートし、アップグレードまたはパッチを続行します。

バグ: 36835607

バージョン: 3.0.2

サイト・ガード事前チェック・ジョブが失敗

サイト・ガード・ユーザーがDR事前チェックを実行すると、事前チェックがエラーで失敗することがあります:

"Incorrect hostname found in DNS for local IP nn.nn.nnn.nnn"

このエラーは、ドメイン名に大文字が含まれている場合に発生します。ドメイン名では大文字はサポートされていません。

回避策: Oracle Supportに連絡してください。

バグ: 36710199

バージョン: 3.0.2

アプライアンスのアップグレード中にインスタンスの移行が失敗

Private Cloud Applianceをソフトウェア・バージョン3.0.2-b1325160にアップグレードすると、インスタンスが別のコンピュート・ノードへの移行に失敗することがあります。ロールバックにより、影響を受けるインスタンスが元のホスト・コンピュート・ノードに戻り、アクティブなワークロードが中断されます。この問題は、ハイパーバイザのレベルで統計収集中の競合するコマンドおよびタイムアウトによって発生します。

この特定のバージョン・アップグレードの一部として、vmstats-exporterは準備フェーズ中にアンインストールされ、プラットフォーム・アップグレード中に再インストールされます。その時点まで、VM統計にはNO DATAが表示されます。

回避策: バージョン3.0.2-b1325160へのアップグレードが完了すると、問題は解決されます。

バグ: 36936775

バージョン: 3.0.2