このコンテンツを正しく表示するには、JavaScriptが有効になっている必要があります

第6章既知の制約および回避策

この章では、Oracle Private Cloud Appliance (PCA)の既知の制限および回避策について説明します。

6.1 Oracle Private Cloud Applianceハードウェア

この項では、ハードウェアに関連する制限および回避策について説明します。

6.1.1 コンピュート・ノードのブート順序がLSIバイオス・バッテリ・エラーによって中断されました

コンピュート・ノードの電源を長時間切れた場合(1週間またはそれ以上)、ユーザーがキーを押して続行するまで待機して、バッテリ・エラーが原因でLSI BIOSが停止する可能性があります。

回避策: 約10分間待機して、ブート中にコンピュート・ノードがスタックしていることを確認します。 Oracle Private Cloud Applianceダッシュボードの再プロビジョニング・ボタンを使用してサーバーを再起動し、プロビジョニング・プロセスを再起動します。

バグ16985965

6.1.2 Oracle Linuxプロンプトから再起動すると管理ノードがハングする可能性

再起動コマンドが管理ノードのOracle Linuxコマンドラインから発行されると、起動中にオペレーティング・システムがハングする可能性があります。リカバリでは、サーバーILOMを使用して手動で操作する必要があります。

回避策: 再起動中に管理ノードがハングした場合、ILOMにログインし、これらの2つのコマンドを連続して実行します: stop -f /SYSおよびstart /SYS。管理ノードは正常に再起動する必要があります。

バグ28871758

6.1.3 Oracle ZFS Storage Appliance Firmwareのアップグレード8.7.20には2フェーズの手順が必要

リリース2.3.4より前に出荷されたOracle PCAラックでは、ZFS Storage Applianceのコントローラに、旧バージョンのオペレーティング・ソフトウェア(AK-NAS)がすべてインストールされていました。新しいバージョンは、Oracle PCAリリース2.3.4での使用に対して適格ですが、直接アップグレードすることはできません。 8.7.14のバージョンへの中間アップグレードが必要です。

回避策: ストレージ・ヘッドのファームウェアを2回アップグレードする: 1番目は8.7.14をバージョン作成し、次に8.7.20をバージョンします。必要なファームウェアのバージョンが両方とも、Oracle PCAリリース2.3.4コントローラ・ソフトウェアの一部として提供されます。アップグレード手順については、「Oracle Private Cloud Appliance管理者ガイド」の「Oracle Private Cloud Applianceの更新」の章にある" 「Oracle ZFS Storage Applianceでのオペレーティング・ソフトウェアのアップグレード」 "のセクションを参照してください。

バグ28913616

6.1.4 スタンバイ内の残りのLUNへのiSCSI接続リードの割込み

コンピュート・ノードとそのLUN間のネットワーク接続が中断されると、1つ以上のコンピュート・ノードが「スタンバイ」状態であるように1つ以上のiSCSI LUNをマークすることが発生する場合があります。 VMの再起動やコンピュート・ノードの再起動など、システムは停止時間を必要としない操作によってこの状態から自動的にリカバリすることはできません。スタンバイLUNは、LinuxカーネルおよびZFS Storage ApplianceがLUNパスのフェイルオーバーを処理するために使用する特定のメソッドによって発生します。

回避策: この問題は、ZFS Storage Applianceファームウェア・バージョンAK 8.7.6で解決されました。欠落しているLUNパスおよびスタンバイLUNの問題に対処した顧客は、Oracle Private Cloud Applianceをアップグレードする前に、ZFS Storage ApplianceファームウェアをバージョンAK 8.7.6または以降に更新する必要があります。

バグ24522087

6.1.5 Emulexファイバ・チャネルHBA検出最大128個のLUN

オプションのBroadcom/Emulexファイバ・チャネル拡張カードをOracle Server X8-2およびOracle Server X9-2コンピュート・ノードで使用し、FC構成によってコンピュート・ノードとFCストレージ・ハードウェアの間に128個のLUNが生成される場合、128個のLUNのみが検出される可能性があります。これは通常、Emulex HBAのドライバ・パラメータが原因です。

回避策: 影響を受ける各コンピュート・ノードで次のステップを実行して、Emulex lpcfドライバ設定を更新します。

Emulexカードを含むコンピュート・ノードで、ファイル/etc/default/grubを変更します。 GRUB_CMDLINE_LINUXパラメータの最後に、表示されているscsi_modおよびlpfcモジュール・オプションを追加します。
```
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg/lvroot rd.lvm.lv=vg/lvswap \
rd.lvm.lv=vg/lvusr rhgb quiet numa=off transparent_hugepage=never \
scsi_mod.max_luns=4096 scsi_mod.max_report_luns=4096 lpfc.lpfc_max_luns=4096"
```
grub構成を新しいパラメータで再構築します。
```
# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
```
コンピュート・ノードを再起動します。

バグ30461433、33114489

6.1.6 ファイバ・チャネルLUNパスの検出は、他のOracle VM操作によって中断されます

ファイバ・チャネル・ストレージの設定時に、FCスイッチ上のゾーンが作成されると、接続されているコンピュート・ノードがLUNに表示されます。検出操作は自動的に開始され、検出されたすべてのLUNがコンピュート・ノードのマルチパス構成に追加されます。ストレージ構成に多数のLUNが含まれている場合は、マルチパス構成の完了に時間がかかることがあります。マルチパス構成が終了していないかぎり、システムの負荷が大きく、同時Oracle VM操作では一部のFC LUNパスがマルチパスに追加されない場合があります。

回避策: FC LUNの検出中にOracle VM操作を行わないようにすることをお薦めします。特に、コンピュート・ノード・プロビジョニングおよびテナント・グループ構成に関連するすべての操作は、ストレージ・レイヤーのリフレッシュを含んでいるため、中断されます。 LUNがコンピュート・ノードに表示されると、ほぼ即時に検出されます。一方、マルチパス構成のステージは時間がかかり、リソースを集中的に使用します。

lsscsiコマンドを使用して、検出されるLUNパスの数を確認します。コマンド出力は、LUNパスの数とシステム・ディスクの数に等しくなります。次に、すべてのパスがマルチパスに追加されたことを確認します。 multipath -llコマンドの出力がlsscsi command minus 1(システム・ディスク向け)の出力と同じになると、マルチパス構成は完了します。

# lsscsi | wc -l
251
# multipath -ll | grep "active ready running" | wc -l
250

マルチパス構成が完了すると、すべてのOracle VM操作を再開できます。

バグ30461555

6.1.7 ファイバ・チャネルLUNの構成中の悪いOracle VMパフォーマンス

ファイバ・チャネルLUNの検出は、時間がかかるリソース集中型の操作です。その結果、Oracle VMジョブが完了するまでに異常に長い時間がかかります。このため、FCストレージの構成を完了して、新しいOracle VM操作を開始する前に構成が安定していることを確認することをお薦めします。

回避策: ファイバ・チャネル・ストレージの設定および構成変更は、他のOracle VM操作が不要なときにスケジュールします。第6.1.6項、「ファイバ・チャネルLUNパス検出は他のOracle VM操作によって中断されます」で説明されているように、すべてのFC構成ジョブが完了していることを確認します。 FC構成が終了すると、すべてのOracle VM操作を再開できます。

バグ30461478

6.1.8 ILOMファームウェアでSSHループバックを許可しない

3.2.4より新しいOracle Integrated Lights Out Manager (ILOM)ファームウェア・リリースでは、サービス・プロセッサの構成に、allowed_servicesと呼ばれるフィールドが含まれ、インタフェースで許可されるサービスを制御します。デフォルトでは、ループバック・インタフェースでSSHは許可されていません。ただし、Oracle Enterprise Managerはこのメカニズムを使用してOracle Private Cloud Appliance管理ノードを登録します。したがって、ILOMバージョンが3.2.4より新しい場合、SSHを手動で有効にする必要があります。

回避策: 管理ノードでILOMバージョンが3.2.4より新しいものである場合は、ネットワーク構成のallowed_servicesフィールドにSSHが含まれていることを確認してください。 NETMGT EthernetポートからILOM CLIにログインし、次のコマンドを入力します。

-> cd /SP/network/interconnect
-> set hostmanaged=false
-> set allowed_services=fault-transport,ipmi,snmp,ssh
-> set hostmanaged=true

バグ26953763

6.1.9 Megaraidファームウェア・クラッシュ・ダンプは使用できません

ILOMコンソールのログには、次のような多くのメッセージが含まれる可能性があります。

[ 1756.232496] megaraid_sas 0000:50:00.0: Firmware crash dump is not available
[ 1763.578890] megaraid_sas 0000:50:00.0: Firmware crash dump is not available
[ 2773.220852] megaraid_sas 0000:50:00.0: Firmware crash dump is not available

これらは通知であり、エラーや警告ではありません。専用のコントローラ・ファームウェアのクラッシュ・ダンプ機能は、Oracle Private Cloud Applianceでは必要ないため、有効ではありません。

回避策: この動作はバグではありません。回避方法は必要ありません。

バグ30274703

6.1.10 ネットワーク再起動後の北-南トラフィック接続障害

この問題は、Cisco SwitchファームウェアをNX-OS I7(7)以降のバージョンにアップグレードしていない場合に発生することがあります。「Oracle Private Cloud Appliance管理者ガイド」の「Oracle Private Cloud Applianceの更新」セクション内の" 「Ciscoスイッチ・ファームウェアのアップグレード」 "セクションを参照してください

バグ29585636

6.1.11 一部のサービスではハードウェア管理パックのアップグレードが必要

Oracle Auto Service RequestやOracle Enterprise Manager Agentなど、Oracle Private Cloud Applianceで稼働している特定のセカンダリ・サービスは、Oracle Hardware Management Packの特定または最小バージョンに依存します。設計上、コントローラ・ソフトウェアのアップグレードには、ISOイメージに含まれている新しいOracle Hardware Management PackまたはサーバーILOMバージョンのインストールは含まれません。この場合、ハードウェア管理パックは機能低下状態のままで、サーバー上で実行されているILOMバージョンと完全に互換性がありません。

回避策: Oracle Private Cloud Appliance Controllerソフトウェアのアップグレード時に、すべてのコンポーネント・ファームウェアがインストールされたController Softwareのリリースの認証バージョンと一致することを確認してください。 Oracle Hardware Management Packに依存するサービスを正しく動作させるには、関連するoracle-hmp*.rpmパッケージをコントローラ・ソフトウェアISOに配布されているバージョンにアップグレードしてください。

バグ30123062

6.1.12 コンピュート・ノードのUSBデバイス未使用

Oracle Private Cloud Applianceコンピュート・ノードのUSBデバイスは使用されません。アップグレードまたはリブート後にコンピュート・ノードのUSBデバイス名が変更された場合、コンピュート・ノードまたはOracle Private Cloud Applianceに機能的な影響はありません。

バグ32998531

6.1.13 FCパスが最大のFC HBAを含むコンピュート・ノードは、再プロビジョニング中にデッド状態で終了

この失敗の原因は、通常、リ・プロビジョニング中にノードをコンピュートするために提示された多数のFC LUN (約100個のLUN)で表示されるFC LUNパス・フラッピングの問題です。これが発生した場合、回避策に従ってください。

回避策:

コンピュート・ノードを停止し、電源が切断されていることを確認します。
外部ストレージ・アレイにログインし、コンピュート・ノードのFCイニシエータをイニシエータ・グループ(このCNへのLUNの提示に使用されたイニシエータ・グループ)から削除します。

これは一時的な変更です。これは後で追加します。
コンピュート・ノードを再起動します。
multipath -Fコマンドを使用して、FC LUNが存在しないことを確認します(iSCSI LUNが存在できます)。
コンピュート・ノードを再プロビジョニングします。
(Emulexのみ)コンピュート・ノードにログインし、Emulexドライバのgrubカスタマイゼーションを再度適用します。「セクション6.1.5、「Emulexファイバ・チャネルHBAが最大128個のLUNを検出する」」を参照してください。
外部ストレージにログインし、コンピュート・ノードのFCイニシエータをイニシエータ・グループに再度追加します。
Oracle VM Manager UIにログインし、管理されていないFibreChannelストレージ・アレイに管理サーバーとしてコンピュート・ノードを追加します。
管理対象外FibreChannelストレージ・アレイをリフレッシュします。
すべてのFC LUNが検出されない場合は、第6.1.14項、「FC LUNのパス・フラッピングを伴うコンピュート・ノードFC HBA (Qlogic/Emulex)」の回避策を適用する必要がある場合があります。

バグ33134228

6.1.14 FC LUNによるコンピュート・ノードのFC HBA (Qlogic/Emulex)パスのフラッピング

次のシナリオで数百のFC LUNがコンピュート・ノードに表示されると、パス・フラッピングが発生する可能性があります:

コンピュート・ノードの再プロビジョニング後
コンピュート・ノードのアップグレード後
通常の動作時

パス・フラッピングがシステムで発生する場合は、コンピュート・ノードに次のエラーが表示されます:

tailf /var/log/devmon.logには、次のようなイベント・メッセージのフラッドがあります:

AGENT_NOTIFY EVENT : Jul 29 19:56:38 {STORAGE} [CHANGE_DM_SD] (dm-961)
3600144f0d987aa07000061027d9c48c6-10:0:0:1917
(failed:0x2100000e1e1b95c0:3600144f0d987aa07000061027d9c48c6)
AGENT_NOTIFY EVENT : Jul 29 19:56:38 {STORAGE} [CHANGE_DM_SD] (dm-988)
3600144f0d987aa07000061027db248e1-10:0:0:1971
(failed:0x2100000e1e1b95c0:3600144f0d987aa07000061027db248e1)
AGENT_NOTIFY EVENT : Jul 29 19:56:38 {STORAGE} [CHANGE_DM_SD] (dm-988)
3600144f0d987aa07000061027db248e1-10:0:0:1971
(active:0x2100000e1e1b95c0:3600144f0d987aa07000061027db248e1)
AGENT_NOTIFY EVENT : Jul 29 19:56:39 {STORAGE} [CHANGE_DM_SD] (dm-961)
3600144f0d987aa07000061027d9c48c6-10:0:0:1917
(active:0x2100000e1e1b95c0:3600144f0d987aa07000061027d9c48c6)

この問題は、/var/log/devmon.logが新しいCHANGE_DM_SDメッセージのロギングを停止すると解決されます。

systemd-udevdプロセスは、topコマンドで100%のCPUを消費します。

これは、systemd-udevdがCPUを大量に消費しなくなった場合に解決されます。
multipath -llコマンドで一部のLUNが表示されないことがあります。予想されるLUNの割合を示す場合があります。
multipath -ll | grep "active ready running" | wc -lコマンドでは、すべてのLUNをカウントできません。予想されるLUNの割合を示す場合があります。

回避策: この手順に従って、パス・フラッピングを解決します。

コンピュート・ノードにrootとしてログインし、systemctl restart multipathdコマンドを実行します。
4つの出力がすべて解決され、正しい数のFC LUN/パスが表示されるまで、上記の検出コマンドの実行を続行します。
3-4分後にいずれのモニタリング・シナリオも解決しない場合は、ステップ1を繰り返します。

バグ33171816

6.1.15 ファイバ・チャネルLUNでコンピューティング・ノードのアップグレードが失敗

コンピュート・ノードにEmulexまたはQLogicファイバ・チャネルHBAが含まれる場合、コンピュート・ノードのアップグレード手順がファイバ・チャネルlunパスのフラッピングの問題のために失敗することがあります。この回避策に従って、問題を回避してください:Oracle Support Document 27945 01.1 ([PCA 2.4.4 ] Upgrader Tool - FC Lunが制限を超えるとコンピュート・ノードのアップグレードに失敗。

6.1.16 `nc: command not found`が原因でPCA障害モニター・チェック`firewall_monitor`が失敗

コンピュート・ノードでFaultmonitor firewall_monitorチェックに失敗すると、このログ・エラーが表示されます:

[2021-08-03 16:30:15 605830] ERROR (ovmfaultmonitor_utils:487) invalid
literal for int() with base 10: '-bash: nc: command not found'
Traceback (most recent call last):
  File
"/usr/lib/python2.7/site-packages/ovca/monitor/faultmonitor/ovmfaultmonitor/ov
mfaultmonitor_utils.py", line 458, in firewall_monitor
    cmd_outputs[server][port] = int(output.strip())
ValueError: invalid literal for int() with base 10: '-bash: nc: command not
found.

Phonehomeが有効になっている場合は、falseレポートを作成してPhonehomeにプッシュするポート・エラーが発生しています。 firewall_monitorは、Oracle VM Managerに必要なポートおよびコンピュート・ノードが開いているかどうかを検証します。このエラーを手動で修正するには、次に記載されている回避策を適用: Oracle Supportドキュメント27973 64.1 ([PCA 2.4.4 ]障害モニター・チェックfirewall_monitorが「nc」のために失敗: コマンドが見つかりません")。

バグ33186553

6.2 Oracle Private Cloud Applianceソフトウェア

この項では、ソフトウェアに関連する制限および回避策について説明します。

6.2.1 アプライアンス・コンポーネントへの追加ソフトウェアのインストール禁止

Oracle Private Cloud Applianceはアプライアンスとして配布されます: 選択したハードウェアおよびソフトウェア・コンポーネントで構成される、完全で管理されたシステム。事前構成されたアプライアンス・コンポーネントに追加のソフトウェア・パッケージをインストールする場合、それはコンピュート・ノード、管理ノード、またはストレージ・コンポーネントであるため、アプライアンスの操作を全体として混乱させる可能性のある新しい変数を導入することになります。他の指示がないかぎり、Oracleは、サード・パーティから、またはOracle Linux YUMリポジトリなどのOracle独自のソフトウェア・チャネルから追加パッケージをインストールまたはアップグレードするように指示します。

回避策: 内部のOracle Private Cloud Applianceシステム・コンポーネントには追加のソフトウェアをインストールしません。内部プロセスで特定の追加ツールが必要な場合は、Oracleの担当者に連絡してこれらの要件を話し合ってください。

6.2.2 ノード・マネージャにノードのオフライン・ステータスが表示されない

ノード・マネージャ・データベースのロールは、プロビジョニング時にコンピュート・ノードが経由する様々な状態を追跡することです。プロビジョニングが成功した後、データベースは停止しても「実行」としてノードをリストし続けます。完全に機能しているノードでは、サーバー・ステータスがOracle VM Managerによって追跡されます。ただし、Oracle Private Cloud Applianceダッシュボードには、ノード・マネージャのステータス情報が表示されます。これによって、ダッシュボードとOracle VM Manager間で情報に一貫性がなくなる可能性がありますが、バグとはみなされません。

回避策: 操作コンピュート・ノードのステータスを検証するには、Oracle VM Managerユーザー・インタフェースを使用します。

バグ17456373

6.2.3 コンピュート・ノードの状態の変更の説明アクティブ・プロビジョニング・ロック

provisioningまたはall_provisioningタイプのロックの目的は、すべてのコンピュート・ノードがプロビジョニング・プロセスの開始または継続を回避することです。ただし、アクティブなロックが設定されているときに、実行中のコンピュート・ノードをOracle Private Cloud Appliance CLIから再プロビジョニングしようとすると、コンピュート・ノードの状態はreprovision_onlyに変更され、"DEAD"にマークされます。プロビジョニング・ロックが非アクティブ化されている場合、コンピュート・ノードのプロビジョニングは通常どおり続行されます。

バグ22151616

6.2.4 プロビジョニング完了前にOracle VM Serverプールで使用可能なコンピュート・ノード

コンピュート・ノードのプロビジョニングは完了までに数時間かかる場合があります。ただし、これらのノードはプロセスの初期にOracle VMサーバー・プールに追加されますが、メンテナンス・モードにはなりません。理論上は、検出されたサーバーをOracle VM Managerで使用できますが、Oracle Private Cloud Applianceダッシュボードでプロビジョニングが完了したことが示されるまで、どんな方法でも構成を変更しないでください。

回避策: コンピュート・ノードのプロビジョニングの完了を待機します。 Oracle VM Managerでは、コンピュート・ノードやサーバー・プールは変更しないでください。

バグ22159111

6.2.5 ホスト・コンピュート・ノードが再プロビジョニングされたときに、仮想マシンが実行中ステータスになっています

Oracle Private Cloud Appliance CLIを使用すると、実行中の仮想マシンをホストしている場合でも、コンピュート・ノードの再プロビジョニングを強制的に実行できます。コンピュート・ノードはメンテナンス・モードになっていません。したがって、アクティブな仮想マシンが停止したり、別のコンピュート・ノードに移行されることはありません。かわりに、これらのVMは「実行」ステータスのままで、Oracle VM Managerはホスト・コンピュート・ノードをn/aとして報告します。

注意

仮想マシンをホストするコンピュート・ノードの再プロビジョニングは不正だとみなされます。適切なプラクティスは、再プロビジョニング操作またはソフトウェア更新を開始する前に、すべての仮想マシンをコンピュート・ノードから移行することです。

回避策: この特定の状況では、VMは移行できなくなります。これらは強制終了し、再起動する必要があります。再起動が成功すると、サーバー・プールに定義された起動ポリシーに従って、別のホスト・コンピュート・ノードの通常動作に戻ります。

バグ22018046

6.2.6 Ethernetベースのシステム管理ノードに非機能bond0ネットワーク・インタフェースがある

ネットワーク・インタフェース・ボンディングのドライバがロードされると、デフォルトのbond0インタフェースが自動的に生成されます。ただし、このインタフェースは、Ethernetベースのネットワーク・アーキテクチャを使用して、Oracle Private Cloud Applianceの管理ノードでアクティブ化または使用されません。

回避策: bond0インタフェースは、使用可能な方法で構成されていないため、Ethernetベースのシステムで無視できます。 InfiniBandベースのシステムでは、bond0インタフェースは機能的で構成されています。

バグ29559810

6.2.7 VxLANカプセル化によるネットワーク・パフォーマンスへの影響

Oracle Private Cloud ApplianceのすべてのEthernetネットワーク・ファブリックの設計は、VxLANのカプセル化と分散に重点的に依存しています。このようにプロトコル・レイヤーを追加するにはCPUサイクルが追加され、その結果、通常のタグ付けまたはタグ付けされていないトラフィックと比較したネットワーク・パフォーマンスが低下します。特に、VMとの接続を影響することがあります。 VxLAN処理のCPU負荷を補うために、VMネットワーク上のMTU (Maximum Transmission Unit)を9000バイトに増やすことができます。これは、標準アプライアンス・ネットワーク全体の設定です。ただし、最終ポイント間でさらに大きなMTU設定がサポートされるように、ネットワーク・パスを慎重に分析する必要があります: 中間ネットワーク・デバイスが1500バイトのMTUのみをサポートしている場合、9000バイトのパケットの断片化によりパフォーマンスが低下します。

回避策: VMトラフィックのデフォルトのMTUが1500バイトで必要なネットワーク・パフォーマンスを取得できない場合は、VMネットワークおよびVM自体でMTUを9000バイトまで増やすことを検討する必要があります。

バグ29664090

6.2.8 カスタム・ネットワークVLANタグの変更はサポートされていません

カスタム・ネットワークを作成すると、技術的には作成可能です。 - サポートされない - Oracle VM ManagerのVLANタグを変更します。ただし、コンピュート・ノードを追加しようとすると、システムはサーバー上にネットワーク・インタフェースを作成しますが、変更されたVLAN構成の有効化に失敗します。この時点で、カスタム・ネットワークは失敗状態でスタックしています: ネットワークやインタフェースを削除することはできません。また、VLANの構成を元のタグに戻すことはできません。

回避策: Oracle VM Managerでは、アプライアンス・レベルのネットワークは変更しないでください。回避策については説明されていません。また、リカバリ操作には、Oracle Private Cloud Appliance環境の停止時間が大幅に必要なものもあります。

バグ23250544

6.2.9 ブレーク・アウト・ポートの結果が'None'という名前のポート・グループでのアップリンクの構成

ブレークアウト・ケーブルを使用してカスタム・ネットワーク構成のアップリンク・ポートを分割し、その後、Oracle Private Cloud Appliance CLIを使用してポート・ペアの構成を開始すると、4つのすべてのブレークアウト・ポートが構成データベースに同時に格納されます。これは、4つのブレークアウト・ポートの最初の2つをポート・グループに追加したときに、同じケーブルの残りの2つのブレークアウト・ポートが自動的に"None"という名前の別のポート・グループに追加され、これは無効のままになります。ブレークアウト・ポートの2番目のペアをポート・グループに追加すると、"None"が選択したポート・グループ名で置換され、ポート・グループが有効になります。例のコマンドのシーケンスでは、ステップごとの構成変更のステップを示しています。

PCA> create uplink-port-group custom_ext_1 '1:1 1:2' 10g-4x
Status: Success

PCA> list uplink-port-group
Port_Group_Name    Ports      Mode    Speed    Breakout_Mode    Enabled   State
---------------    -----      ----    -----    -------------    -------   -----
default_5_1        5:1 5:2    LAG     10g      10g-4x           True      (up)* Not all ports are up
default_5_2        5:3 5:4    LAG     10g      10g-4x           False     down
custom_ext_1       1:1 1:2    LAG     10g      10g-4x           True      up
None               1:3 1:4    LAG     10g      10g-4x           False     up
----------------
4 rows displayed
Status: Success

PCA> create uplink-port-group custom_ext_2 '1:3 1:4' 10g-4x
Status: Success

PCA> list uplink-port-group
Port_Group_Name    Ports      Mode    Speed    Breakout_Mode    Enabled   State
---------------    -----      ----    -----    -------------    -------   -----
default_5_1        5:1 5:2    LAG     10g      10g-4x           True      (up)* Not all ports are up
default_5_2        5:3 5:4    LAG     10g      10g-4x           False     down
custom_ext_1       1:1 1:2    LAG     10g      10g-4x           True      up
custom_ext_2       1:3 1:4    LAG     10g      10g-4x           True      up
----------------
4 rows displayed
Status: Success

回避策: 4つすべてのブレークアウト・ポートを同時にネットワーク構成に追加する必要があるため、この動作は設計によるものです。ポート・グループに"None"という名前が付けられ、それが4方向のブレークアウト・ケーブルで構成されている場合、それ以外(一時的に)構成されていても、これは無視できます。

バグ30426198

6.2.10 DPMサーバー・プール・ポリシーのテナント・グループ設定の同期化

Oracle Private Cloud Appliance内のテナント・グループはOracle VMサーバー・プールに基づいており、テナント・グループに含まれるサーバー全体にわたるネットワークとストレージの追加構成が使用されます。コンピュート・ノードがテナント・グループに追加されると、そのネットワークおよびストレージ構成は、テナント・グループにすでに存在する他のサーバーと同期されます。このプロセスには数分かかるため、分散型電源管理(DPM)ポリシーがOracle VMサーバー・プールに対してアクティブな場合は中断されることがあります。 DPMポリシーでは、コンピュート・ノードのテナント・グループ構成プロセスがまだ進行中である間に、新規コンピュート・ノードが実行中の仮想マシンが含まれないため強制的に停止される場合があります。不完全な構成では、コンピュート・ノードのレベルまたはテナント・グループで操作の問題が発生します。

回避策: サーバー・プール・ポリシーが要件な場合、テナント・グループを変更する際、または拡張コンピュート・ノードのインストールおよび構成中に、一時的にオフにすることをお薦めします。

バグ30478940

6.2.11 ホストのネットワーク・パラメータの検証が許可されすぎます

ホスト・ネットワークを定義する場合、プレフィクス、ネットマスクおよびRoute_Destinationパラメータに対して無効な値または矛盾する値を入力できます。たとえば、最初のオクテットとして0が付いたプレフィクスを入力した場合、0で始まるコンピュート・ノードのEthernetインタフェースでIPアドレスの構成が試行されます。また、入力したルート宛先のネットマスク部分が無効の場合でも、例外が発生してもネットワークはまだ作成されています。このように構成されていないネットワークが無効な状態の場合、標準コマンドで再構成または削除することはできません。

回避策: Enterを押す前にCLIコマンド・パラメータをダブル・チェックしてください。無効なネットワーク構成が適用されている場合は、--forceオプションを使用してネットワークを削除します。

バグ25729227

6.2.12 ホスト・ネットワーク上では仮想アプライアンスをインポートできません

ホスト・ネットワークは、アプライアンス外部のコンピュート・ノードおよびホスト間の接続性を提供します。外部ストレージを環境に接続するために実装されます。仮想アプライアンス(以前のリリースのOracle VMおよびOracle Private Cloud Applianceのアセンブリとも呼ばれる)を、ホスト・ネットワーク上のロケーションからインポートしようとすると、Oracle VM Managerでは、アクティブ管理ノードをインポート操作のプロキシとして使用するようにコンピュート・ノードに指示されるため、失敗する可能性があります。

回避策: 仮想アプライアンスがアクティブ管理ノードからアクセス可能なロケーションに存在することを確認してください。

バグ25801215

6.2.13 `multipath.conf`でのZFS Storage Applianceのカスタマイズはサポートされていません

multipath.confのZFSスタンザは、Oracle Private Cloud Applianceソフトウェアによって制御されます。内部ZFS Storage Applianceはアプライアンスの重要なコンポーネントであり、マルチパス構成は内部要件にあわせて調整されます。アプライアンスのパフォーマンスおよび機能に悪影響を与える可能性があるため、multipath.confでZFSパラメータを変更しないでください。

カスタマイズが(外部)ZFSストレージに適用された場合でも、Oracle Private Cloud Appliance Controllerソフトウェアの更新時に上書きされます。更新前に、ファイルのバックアップが保存されます。他のベンダーからのストレージ・デバイスに対するmultipath.confのその他のスタンザでのカスタマイズは、アップグレード中も保持されます。

バグ25821423

6.2.14 顧客が作成したLUNが間違ったイニシエータ・グループにマップされます

Oracle Private Cloud Appliance内部ZFS Storage ApplianceにLUNを追加するときは、OVMターゲット・グループの下にLUNを追加する必要があります。このデフォルト・ターゲット・グループのみがサポートされます。追加のターゲット・グループは使用できません。ただし、イニシエータ側ではデフォルトの構成を使用しないでください。使用しない場合は、すべてのLUNが"All Initiators"グループにマップされ、システム内のすべてのノードがアクセス可能になります。このような構成は、アプライアンス内でいくつかの問題を発生させる可能性があります。

かわりに、内部ストレージ上の追加のカスタムLUNを1つ以上のカスタム・イニシエータ・グループにマップする必要があります。これにより、LUNは目的のイニシエータにマップされ、アプライアンス・ソフトウェアによってデフォルトの"All Initiators"グループに再マップされません。

回避策: 内部ZFS Storage Applianceに追加のカスタムLUNを作成するときは、常にデフォルトのターゲット・グループを使用しますが、LUNが1つ以上のカスタム・イニシエータ・グループにマップされていることを確認してください。

Oracle Bug#22309236およびOracle Bug#18155778

6.2.15 仮想マシンを実行しているストレージ・ヘッド・フェイルオーバーの中断

ZFS Storage Applianceのストレージ・ヘッド間でフェイルオーバーが発生すると、仮想マシン操作がディスク・アクセスの一時的な損失によって中断する可能性があります。ゲスト・オペレーティング・システム、およびゲストとOracle VMの構成によっては、VMがハング、電源切断、またはリブートする場合があります。この動作は、ストレージ・フェイルオーバーが完了するのに十分なリカバリ時間を許容しないiSCSI構成パラメータが原因です。

回避策: /etc/iscsi/iscsid.confファイルのnode.session.timeo.replacement _timeoutの値を増やしてください。詳細は、「ドキュメントID 2189806.1」のサポート・ノートを参照してください。

バグ24439070

6.2.16 複数のコンポーネント・パスワードの変更により、Oracle VM Managerで認証失敗

Oracle Private Cloud Appliance Dashboardを使用して様々なアプライアンス・コンポーネントに複数の異なるパスワードを設定すると、Oracle VM Managerからロックされたり、Oracle VM Managerと他のコンポーネント間の通信が失敗する場合があります。これは、認証が失敗したためです。この問題は、部分的に失敗したパスワード更新が原因で発生します。この場合、コンポーネントは新規パスワードを受け入れましたが、別のコンポーネントは引き続き古いパスワードを使用して接続します。

Oracle VM Managerおよび直接関連するコンポーネントOracle WebLogic ServerおよびOracle MySQLデータベースが関与する場合、認証の問題のリスクはかなり高くなります。これらのコンポーネントのパスワードを変更するには、ovmmサービスを再起動する必要があります。別のパスワード変更が数分以内に発生した場合、ovmmサービスがアクティブでなかったためにOracle VM Managerを更新する操作は失敗する可能性があります。認証エラーにより、ovmmサービスが再起動できなくなります。

回避策: Oracle Private Cloud Applianceダッシュボードを使用してアプライアンス・コンポーネントに異なるパスワードを設定する場合は、10分間隔で1つずつ変更してください。パスワード変更の結果、ovmmサービスが停止した場合は、再起動してからさらに変更を加えるようにしてください。認証の問題によりovmmサービスが再起動しない場合は、ファイル/nfs/shared_storage/wls1/servers/AdminServer/security/boot.propertiesを以前のバージョンのファイル(boot.properties.old)に置き換える必要があります。

バグ26007398

6.2.17 プロビジョニング中に拡張コンピュート・ノードのILOMパスワードが同期されません

ラック・コンポーネントをカスタム・パスワードで構成した後は、新しくインストールされた拡張コンピュート・ノードのコンピュート・ノードILOMは、Walletでユーザーが設定したパスワードを自動的に引き継ぎません。コンピュート・ノードは、正しくプロビジョニングし、ファクトリ出荷時のデフォルト・パスワードを使用していても、WalletはそのILOMへのアクセス権を維持します。ただし、カスタム・パスワードがすべてのコンポーネントにわたり正しく同期されるようにすることをお薦めします。

回避策: Oracle Private Cloud Appliance DashboardまたはCLIを使用してコンピュート・ノードILOMパスワードを設定または更新します。これにより、Walletとコンピュート・ノードILOMの両方で新しいパスワードが設定されます。

バグ26143197

6.2.18 管理ノードのフェイルオーバー後のSSHホスト・キーの不一致

SSHを使用してアクティブ管理ノードにログインする場合、通常は、両方の管理ノード間で共有されている仮想IPアドレスを使用します。ただし、これらは個別の物理ホストであるため、異なるホスト・キーを持ちます。ホスト鍵がSSHクライアントに格納されていて、セカンダリ管理ノードへのフェイルオーバーが発生した場合、次に仮想IPアドレス経由でSSH接続を作成しようとするとホスト鍵検証が失敗します。

回避策: SSHクライアントにホスト・キーを格納しないでください。キーが格納されている場合は、通常は.ssh/known_hostsのユーザー・ディレクトリ内にあるクライアント・ファイル・システムから削除します。

バグ22915408

6.2.19 データ・センター・ネットワーク経由では外部ストレージを検出できません

デフォルトのコンピュート・ノード構成では、データ・センター・ネットワークの追加ストレージ・リソースへの接続は許可されません。コンピュート・ノードは、ホストする仮想マシンに対してパブリック接続を有効にするために、データ・センター・サブネットに接続されていますが、コンピュート・ノードのネットワーク・インタフェースには、そのサブネットのIPアドレスがありません。そのため、SANまたはファイル・サーバーの検出は失敗します。

バグ17508885

6.2.20 Mozilla Firefoxがユーザー・インタフェースとのセキュアな接続を確立できません

Oracle Private Cloud ApplianceダッシュボードとOracle VM Managerユーザー・インタフェースはどちらも、Oracle WebLogic Server、Oracle Application Development Framework (ADF)およびOracle JDK 6に基づくアーキテクチャで稼働します。このアーキテクチャでサポートされている暗号化プロトコルは、SSLv3およびTLSv1.0です。 Mozilla Firefox版の38.2.0以降では、自己署名証明書を使用したSSLv3接続をサポートしていません。結果として、ユーザー・インタフェースのログイン・ページを開こうとすると、エラー・メッセージが表示されることがあります。

回避策: デフォルトのMozilla Firefoxセキュリティ・プロトコルを次のようにオーバーライドします。

Mozilla Firefoxアドレス・バーに、ブラウザ構成にアクセスするためのabout:configと入力します。
「私の約束に注意してください。」をクリックして、拡張設定の変更に関する警告を確認します。
詳細設定のリストで、検索バーを使用してエントリをフィルタ処理し、変更する設定を探します。
次のエントリをダブルクリックして新しい値を入力し、構成プリファレンスを変更します。
- security.tls.version.fallback-limit: 1
- security.ssl3.dhe_rsa_aes_128_sha: false
- security.ssl3.dhe_rsa_aes_256_sha: false
また、必要であれば、構成プリファレンスsecurity.tls.insecure_fallback_hostsを変更し、影響を受けるホストをカンマ区切りのリストとして(ドメイン名またはIPアドレスとして)入力します。
Mozilla Firefoxの拡張構成タブを閉じます。セキュアな接続の失敗の影響を受けるページが正常にロードされます。

Oracle Bug#21622475およびOracle Bug#21803485

6.2.21 高可用性の仮想マシンはフェイルオーバーの実行時に5分後に再起動します

Oracle Private Cloud Appliance内のコンピュート・ノードは、プロビジョニング中、すべて単一のクラスタ化サーバー・プールに配置されます。クラスタ化サーバー・プールは、プロビジョニング・プロセスの一部として作成されます。構成パラメータの1つにクラスタ・タイムアウトがあります: サーバーがフェイルオーバー・イベントがトリガーされるまで使用できない時間。誤検出を回避し、このような不要なフェイルオーバーを回避するために、Oracle Private Cloud Applianceサーバー・プールのタイムアウトは300秒に設定されています。結果として、高可用性(HA VM)で構成された仮想マシンは、そのホストに障害が発生しても5分間使用できなくなります。クラスタ・タイムアウトを過ぎると、HA VMはサーバー・プール内の別のコンピュート・ノードで自動的に再起動されます。

この動作は、バグではなく設計されたものです。サーバー・プール・クラスタ構成は、フェイルオーバーの発生後にVMの再起動に遅延が発生します。

6.2.22 CLIのupdate applianceコマンドの非推奨

Oracle Private Cloud Applianceコマンドライン・インタフェースには、2.3.4がコントローラ・ソフトウェア・イメージを解凍し、新しいソフトウェア・スタックでアプライアンスを更新する前のリリースで使用されるupdate applianceコマンドが含まれています。この機能は現在アップグレーダ・ツールの一部です。このためCLIコマンドは非推奨であり、次のリリースで削除されます。

回避策: 将来の更新およびアップグレーダは、Oracle Private Cloud Appliance Upgraderを通じて実行されます。

バグ29913246

6.2.23 単一コマンド・モードでの特定のCLIコマンドの失敗

Oracle Private Cloud Applianceコマンドライン・インタフェースは、クローズされたシェル環境を使用して、またはシングル・コマンド・モードで対話モードで使用できます。シングル・コマンド・モードを使用する場合、コマンドと引数はOracle Linuxコマンド・プロンプトで1行として入力します。そのような1つのコマンドに引用符などの特殊文字が含まれている場合、それらを取り除いて正しく解釈できません。

回避策: コマンド引数から特殊文字を削除しないように、対話型モードでCLIを使用します。シングル・コマンド・モードを使用する必要がある場合は、必要に応じて引数を一重引用符および二重引用符で囲み、外部引用符のみが削除されるようにします。たとえば、このコマンドを次のように変更します。

# pca-admin create uplink-port-group myPortGroup '2:1 2:2' 10g-4x

変更後

# pca-admin create uplink-port-group myPortGroup "'2:1 2:2'" 10g-4x

同じ引用符を二重に使用しないでください。

バグ30421250

6.2.24 アップグレーダは異なる順序でログに記録します

Oracle Private Cloud Applianceアップグレーダ・テストの実行方法が変更されたため、テストを実行するたびにチェックの出力が異なる順序で表示される可能性があります。

この動作はバグではありません。回避策は必要ありません。

バグ30078487

6.2.25 高ネットワーク負荷中のDHCPタイムアウトによる仮想マシンの消失IPアドレス

Oracle Private Cloud Applianceが最大限度に構成され、高負荷が実行されている場合、一般的なDHCP/IP帯域幅の制限を超えるという状況が発生する可能性があります。この場合、DHCPクライアントは、最終的にタイムアウトになって仮想マシンIPアドレスが失われるため、0.0.0.0にリセットされます。これは、完全な帯域幅の容量でシステムが動作している場合の正常な動作です。

回避策: 十分な帯域幅が使用可能な場合は、仮想マシンからdhclientコマンドを発行して新しいIPアドレスをリクエストして、この状況からリカバリしてください。

バグ301 43723

6.2.26 ストレージ・ネットワークに仮想マシン・ロールを追加すると、クラスタでハートビート・ネットワークが失われる

Oracle Private Cloud Appliance上のOracle VM Mangerのストレージ・ネットワークに仮想マシン・ロールを追加しようとすると、クラスタでハートビート・ネットワーキングが失われ、実行中の仮想マシンとそのワークロードに影響を与える可能性があります。この操作はOracle Private Cloud Applianceではサポートされていません。

回避策: VMロールをstorage-intネットワークに追加しないでください。

バグ30936974

6.2.27 管理ネットワークに仮想マシン・ロールを追加すると、Oracle VM Managerがコンピュート・ノードとの接続を失います

Oracle Private Cloud ApplianceでOracle VM Mangerの管理ネットワークに仮想マシン・ロールを追加しようとすると、コンピュート・ノードとの接続が失われます。コンピュート・ノードはまだ起動していますが、マネージャはコンピュート・ノードと通信できないため、ラックは機能低下状態のままになります。この操作はOracle Private Cloud Applianceではサポートされていません。

回避策: VMロールをmgmt-intネットワークに追加しないでください。

バグ30937049

6.2.28 アップグレード中のスタンバイ管理ノードの誤った再起動によるアップグレードの一時停止

リリース2.3.4または2.4.xのいずれかのリリースからOracle Private Cloud Appliance Controller Softwareリリース2.4.3にアップグレードする場合は、最初に元のスタンバイ管理ノードをアップグレードする必要があります。このアップグレードの一部は、アップグレード・プロセス中に自動的に行われるこのノードの再起動です。このリブート後、元のスタンバイ管理ノードが新しいアクティブ・ノードになります。次のステップでは、元のアクティブ管理ノードをアップグレードします。ただし、かわりに元のスタンバイ・ノードを再び誤って再起動した場合(現在は新しいアクティブであるノード)は、新しいアクティブ・ノードのOracle Private Cloud Applianceサービスが失敗するため、アップグレードを続行できません。

回避策: 元のアクティブ・ノードをリブートします。これにより、新しいアクティブ・ノードのOracle Private Cloud Applianceサービスが再起動され、元のアクティブ・ノードのアップグレードを続行できます。

バグ30968544

6.2.29 互換性のないスパイン・スイッチ構成をロードするとストレージ・ネットワークが停止

ethernetベースのシステムでOracle Private Cloud Appliance Controller Softwareリリース2.4.3にアップグレードする場合、ストレージ・ネットワーク・アップグレードの完了前にスパイン・スイッチ構成を手動で変更しようとしないでください。これを行うと、管理ノードがストレージ・ネットワークへのアクセスを失う可能性があります。管理ノードが再起動される場合もあります。

また、Ethernetベースのシステムでコントローラ・ソフトウェア・リリース2.4.3へのアップグレードが完了したら、以前のソフトウェア・リリースからスパイン・スイッチ・バックアップをリロードしないでください。これにより、管理ノードがストレージ・ネットワークへのアクセスを失う可能性があります。管理ノードが再起動される場合もあります。たとえば、次のエラー・メッセージが表示される場合があります:

192.0.2.1 is unreachable
[root@ovcamn05r1 data]# ping 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
 
 
Mount points under shared storage are gone.
[root@ovcamn05r1 ~]# ls /nfs/shared_storage/
logs NO_STORAGE_MOUNTED
 
 
No master management node any more. o2cb service is offline. Both management nodes are slave now.
[root@ovcamn05r1 ~]# pca-check-master
o2cb service is offline.
NODE: 192.0.2.2 MASTER: False

回避策: スパイン・スイッチ構成で行われた変更を手動でロールバックし、両方の管理ノードを再起動します。

バグ31407007

6.2.30 バックアップ中にZFSSAテイクオーバーが実行されると、クラウド・バックアップ・タスクがハングアップ

ZFSストレージ・アプライアンスへの接続が中断されると、Oracle Cloud Infrastructureプロセスは操作を終了し、タスク・データベースで失敗とマークします。管理ノードの再起動など、状態を更新するメカニズムがない場合があります。

回避策: タスクが状態を変更できない場合は、タスク・データベースからタスクを削除し、oci_backupロック・ファイルを削除して、新しいバックアップ操作を実行します。「Oracle Private Cloud Appliance管理者ガイド」の「Oracle Private Cloud Applianceのモニタリングおよび管理」セクション内の" 「クラウド・バックアップ」 "を参照してください。

バグ31028898

6.2.31 MNフェイルオーバー中にVMをOracle Cloud Infrastructureにエクスポート・ジョブが中断として表示されるが、バックグラウンドで実行されている

アクティブな管理ノードの再起動またはクラッシュ時にVMのOracle Cloud Infrastructureへのエクスポート・ジョブが実行されている場合、そのジョブ・ステータスはOracle VM Manager上のAbortedに変更されます。場合によっては、Abortメッセージにかかわらず、エクスポータ・アプライアンスでエクスポート・ジョブが続行されます。

回避策: Oracle Cloud InfrastructureへのVMのエクスポート・ジョブを再起動します。ジョブがバックグラウンドでまだ実行されている場合は、ポップアップ・メッセージに「VMのエクスポート操作はすでに進行中です」が表示されます。管理ノードのフェイルオーバーによりエクスポート・ジョブが正常に中断された場合、エクスポート・ジョブは再起動されます。

バグ31687516

6.2.32 非推奨の`pca-admin diagnose software`コマンドの削除

Oracle Private Cloud Applianceソフトウェア・コントローラ・バージョン2.4.3リリースでは、pca-admin diagnose softwareコマンドは機能しなくなりました。

回避策: 別のヘルス・チェック・ツールを使用して診断機能を使用できるようになりました。詳細は、「Oracle Private Cloud Appliance管理者ガイド」の「Oracle Private Cloud Applianceのモニタリングおよび管理」セクションのヘルス・モニタリングを参照してください。

バグ31705580

6.2.33 仮想マシンの`get`メッセージが200秒後に失敗しました - `kube clusters`が同時に作成される場合に表示されます

Oracle Private Cloud Appliance Cloud Native Environmentリリース1.2 OVAを使用してkube clustersを作成する場合、複数のクラスタを同時に起動しようとすると、一部のクラスタが次のメッセージで失敗することがあります:

Error_Code           VM_ERROR_004
Error_Message        Error (VM_ERROR_004): Virtual machine
autonas-cc3-master-3 get message failed after 200 seconds:
com.oracle.linux.keepalived.master-addr,com.oracle.linux.k8s.error,com.oracle.
linux.k8s.script-result,com.oracle.linux.keepalived.error.

回避策: 失敗したkubeクラスタを停止してから、そのkubeクラスタを再起動します。

バグ32799556

6.2.34 管理ノードのアップグレードの開始時に、Kubeクラスタの作成/削除を進行中にはできません

管理ノードをソフトウェア・コントローラ・リリース2.4.3からソフトウェア・コントローラ・リリース2.4.4にアップグレードする場合、kubeクラスタの起動または停止操作は開始しないでください。アップグレード手順の一部として、管理ノードのフェイルオーバーが発生します。このフェイルオーバーにより、kubeクラスタがアップグレード時に起動または停止しようとしていた場合、kubeクラスタが縮退状態になることがあります。

回避策: 失敗したkube clusterを停止し、そのkube clusterを再起動します。これらの操作では、破損したVMがクリーンアップされ、再作成されます。

バグ32880993

6.2.35 `o2cb`サービス・ステータス・レポート" `Registering O2CB cluster "ocfs2": Failed` "コンピュート・ノードのプロビジョニング後の状態

コンピュート・ノードのプロビジョニング後、Oracle Private Cloud Applianceリリース2.4.3から2.4.4へのアップグレード中に、o2cbサービスでエラー・メッセージが表示される場合があります。問合せを実行すると、サービスはアクティブ状態になりますが、次の例に示すように、一部のクラスタは失敗状態を示す場合があります。

[root@ovcacn08r1 ~]# service o2cb status
Redirecting to /bin/systemctl status o2cb.service
● o2cb.service - Load o2cb Modules
   Loaded: loaded (/usr/lib/systemd/system/o2cb.service; enabled; vendor
preset: disabled)
   Active: active (exited) since Thu 2021-04-22 09:00:51 UTC; 21h ago
 Main PID: 2407 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/o2cb.service

Apr 22 09:00:51 ovcacn08r1 o2cb.init[2407]: Loading stack plugin "o2cb": OK
Apr 22 09:00:51 ovcacn08r1 o2cb.init[2407]: Loading filesystem "ocfs2_dlmfs":
OK
Apr 22 09:00:51 ovcacn08r1 o2cb.init[2407]: Creating directory '/dlm': OK
Apr 22 09:00:51 ovcacn08r1 o2cb.init[2407]: Mounting ocfs2_dlmfs filesystem
at /dlm: OK
Apr 22 09:00:51 ovcacn08r1 o2cb.init[2407]: Setting cluster stack "o2cb": OK
Apr 22 09:00:51 ovcacn08r1 o2cb.init[2407]: Registering O2CB cluster "ocfs2":
Failed
Apr 22 09:00:51 ovcacn08r1 o2cb.init[2407]: o2cb: Unknown cluster 'ocfs2'
Apr 22 09:00:51 ovcacn08r1 o2cb.init[2407]: Unregistering O2CB cluster
"ocfs2": Failed
Apr 22 09:00:51 ovcacn08r1 o2cb.init[2407]: o2cb: Cluster 'ocfs2' is not
active
Apr 22 09:00:51 ovcacn08r1 systemd[1]: Started Load o2cb Modules.
[root@ovcacn08r1 ~]#

回避策: 失敗したメッセージはクラスタのステータスを誤って報告しており、クラスタは正常に機能しています。これらのエラー・メッセージは無視しても安全です。 falseメッセージをクリアするには、o2cbサービスを再起動し、ステータスを確認します。

[root@ovcacn10r1 ~]# service o2cb restart
Redirecting to /bin/systemctl restart o2cb.service
[root@ovcacn10r1 ~]# service o2cb status

バグ32667300

6.2.36 コンピュート・ノードのアップグレードは、以前はテナント・グループまたはリポジトリに含まれていなかった場合にデフォルト・リポジトリをリストア

ソフトウェア・コントローラ・リリース2.4.3からソフトウェア・コントローラ・リリース2.4.4にコンピュート・ノードをアップグレードする場合、デフォルト・テナント・グループの一部であるがリポジトリが割り当てられていないコンピュート・ノードがある場合、アップグレード・プロセスによって、デフォルト・リポジトリがそのコンピュート・ノードにリストアされます。

回避策: リポジトリが割り当てられていないコンピュート・ノードを保持し、アップグレード・プロセスによってそのコンピュート・ノードにデフォルトのリポジトリが割り当てられる場合は、アップグレード後にそのコンピュート・ノードからリポジトリを表さないだけです。

バグ32847571

6.2.37 ローカル・リポジトリをチェックしてターゲット・コンピュート・ノードが空であることを確認

ソフトウェア・コントローラ・リリース2.4.3からソフトウェア・コントローラ・リリース2.4.4にコンピュート・ノードをアップグレードする場合、アップグレードするコンピュート・ノードのローカル・リポジトリにISO、VMファイル、VMテンプレート、仮想アプライアンスまたは仮想ディスクが存在する場合、アップグレード事前チェックは失敗します。これは、アップグレードが発生する前にローカル・リポジトリ内のデータが保持されるようにするために予想される動作であり、これによりデータが消去されます。コンピュート・ノードのアップグレードの事前チェックが失敗した場合、コンピュート・ノードのローカル・リポジトリにあるすべてのオブジェクトを別のリポジトリに移動してから、アップグレードを再試行します。 ISO、VMファイル、VMテンプレート、仮想アプライアンス、または仮想ディスクを保持する必要がない場合は、ローカル・リポジトリを空にするためにそれらを削除します。

回避策: アイテムを別のリポジトリに移動して、アップグレードを再試行します。

アップグレードするコンピュート・ノードのOracle VM Manger Web UIにログインします。

次のように各ファイル・タイプを移動します:

表6.1 ローカル・リポジトリからのアイテムの移動

項目	ステップ
ISO	ISOをほかのリポジトリにクローニングします。ローカル・リポジトリからISOファイルを削除します。
VMテンプレート	クローン・カスタマイザを使用して、テンプレートを別のリポジトリに移動します。
仮想アプライアンス	各仮想アプライアンスを使用してVMを作成します。「Export to Virtual Appliance」を使用して作成したVMから仮想アプライアンスを作成し、他のリポジトリを指定します。ローカル・リポジトリから(ステップ1で作成した)仮想アプライアンスを削除します。
待機ディスク	これらの仮想ディスクを使用しているVMがローカル・リポジトリ内にある場合は、クローン・カスタマイザを使用して、対応するVMを(ローカル・リポジトリ内に存在する)仮想ディスクとともにほかのリポジトリに移行します。これらの仮想ディスクを使用するVMがローカル・リポジトリ内にない場合(たとえば、一部のVMの少数の仮想ディスクやすべての仮想ディスクがローカル・リポジトリに存在する場合)、次のステップに従います: これらの仮想ディスクを使用してVMを停止します。クローン・ターゲットを持つ仮想ディスクを他のリポジトリとしてクローニングします。このクローン・ターゲット・リポジトリは、VMがホストされるコンピュート・ノードに提示する必要があります。 VMから実際の仮想ディスクを削除します。クローンされた仮想ディスクを対応するVMにアタッチします。 VMを起動します。
VMファイル	対応するVMを他のリポジトリに移行します。

pca_upgraderを検証モードで実行し、事前チェック・パスを確認します。

事前チェックに合格した場合は、アップグレードを実行します。

[root@ovcamn05r1 ~]# pca_upgrader -V -t compute -c ovcacnXXr1
PCA Rack Type: PCA X8_BASE.
Please refer to log file /nfs/shared_storage/pca_upgrader/log/pca_upgrader_<timestamp>.log for more details.
 
 
Beginning PCA Compute Node Pre-Upgrade Checks...
 
Check target Compute Node exists                                        1/8
Check the provisioning lock is not set                                  2/8
Check OVCA release on Management Nodes                                  3/8
Check Compute Node's Tenant matches Server Pool                         4/8
Check target Compute Node has no local networks VNICs                   5/8
Check target Compute Node has no VMs                                    6/8
Check local repository of target Compute Node is empty                  7/8
Check no physical disks on target Compute Node have repositories        8/8
 
PCA Compute Node Pre-Upgrade Checks completed after 0 minutes
 
---------------------------------------------------------------------------
PCA Compute Node Pre-Upgrade Checks                                  Passed
---------------------------------------------------------------------------
Check target Compute Node exists                                     Passed
Check the provisioning lock is not set                               Passed
Check OVCA release on Management Nodes                               Passed
Check Compute Node's Tenant matches Server Pool                      Passed
Check target Compute Node has no local networks VNICs                Passed
Check target Compute Node has no VMs                                 Passed
Check local repository of target Compute Node is empty               Passed
Check no physical disks on target Compute Node have repositories     Passed
---------------------------------------------------------------------------
Overall Status                                                       Passed
---------------------------------------------------------------------------
PCA Compute Node Pre-Upgrade Checks                                  Passed
Please refer to log file /nfs/shared_storage/pca_upgrader/log/pca_upgrader_<timestamp>.log for more details.
 
[root@ovcamn05r1 ~]#

アップグレードを正常に実行した後、新しくアップグレードしたコンピュート・ノード(ovcacnXXr1-localfsrepo)のローカル・リポジトリにバックアップしたファイルをリストアします。上の表を使用してアイテムをリストアしたり、「Oracle® VM Managerユーザー・ガイドforリリース3.4」の「第4章」で詳細な手順を探すことができます。

バグ33093080

6.2.38 ターゲット・コンピュート・ノードの物理ディスクがないリポジトリがないかどうかのチェック

コンピュート・ノードをソフトウェア・コントローラ・リリース2.4.3からソフトウェア・コントローラ・リリース2.4.4にアップグレードする場合、物理ディスク(iSCSI/FC)にリポジトリが存在し、それらの物理ディスク(iSCSI/FC)がアップグレード中のコンピュート・ノードにのみ表示される場合、事前チェックは失敗します。

回避策: 物理ディスクからリポジトリの所有権を解放します。

ノート

リポジトリ用にアップグレードされるコンピュート・ノードに提供される「唯一の」のすべての物理ディスクを確認します。この手順は、これらの各物理ディスクに存在するリポジトリごとに実行する必要があります。

アップグレード前のステップ

Oracle VM Manager Web UIにログインします。
サーバーとVMタブで、適切なサーバー・プールを選択し、コンピュート・ノードがそのサーバー・プールの一部であることを確認します。
リポジトリ・タブでリポジトリを選択し、リポジトリが存在する物理ディスクをノートします。
リポジトリ・タブでリポジトリを選択し、関連するリポジトリを編集して所有権のリリースを確認します。
「リポジトリから」タブで、すべてのリポジトリの表示をクリックし、リポジトリを選択して削除します。

これにより、リポジトリがOracle VM Managerからのみ削除され、物理ディスク上の実際のファイルシステムは削除されません。

コンピュート・ノードのアップグレードを再試行