4 既知の問題と回避策
この章では、Oracle Private Cloud Applianceの既知の問題および回避策について説明します。 カテゴリごとに別々のセクションで表示されるため、より簡単にナビゲートできます。
プラットフォームの問題
このセクションでは、アプライアンス・プラットフォーム・レイヤーに関連する既知の問題と回避策について説明します。
コンピュート・ノードのプロビジョニングに長時間かかる
新しいコンピュート・ノードのプロビジョニングには、通常わずか数分かかります。 ただし、プロセスの期間に悪影響を与える可能性のあるファクタがいくつかあります。 たとえば、管理ノードが負荷が高い場合や、プロビジョニングに関係するプラットフォーム・サービスがビジーであるか、ホスト間で移行している可能性があります。 また、複数のコンピュート・ノードのプロビジョニングを連続して開始した場合は、これらのプロセスはパラレルではなく、1つずつ実行されることに注意してください。
回避策: エラーが表示されないかぎり、コンピュート・ノードのプロビジョニング・プロセスがまだ進行中であり、最終的に完了すると想定する必要があります。 この時点で、コンピュート・ノードのプロビジョニング状態が「プロビジョニング済」に変わります。
バグ: 33519372
バージョン: 3.0.1
アプライアンス・ネットワーク環境の再構成の権限がありません
初期システム設定を完了したばかりで、ラック外部接続のネットワーク環境パラメータを変更しようとすると、これらの変更を行う権限がないため、コマンドは拒否されます。 これはセキュリティ機能によって発生します: 初期システム設定の権限は、これらの特定の設定操作のみに制限されます。 「サービス・エンクレーブ」への無制限のアクセス権を持つ管理者でも、初期システム設定後に切断し、再度ログインして、アカウントに関連付けられたすべての権限をアクティブ化する必要があります。
回避策: この動作は想定されており、不正アクセスから保護できるように設計されています。 初期システム設定の直後にアプライアンスの外部ネットワーク構成を変更する必要がある場合は、ログアウトしてから再度ログインして、セッションが必要な権限で起動していることを確認します。
バグ: 33535069
バージョン: 3.0.1
Grafanaサービス統計情報はゼロのまま
Grafana Service Monitoringフォルダには、Service Levelという名前のダッシュボードがあり、基本的なアプライアンス・サービスによって受信されたリクエストに関する統計情報が表示されます。 このダッシュボードでモニターされるサービスに関連するアクティビティがある場合でも、これらの数値はゼロのままです。
回避策: 現在使用可能な回避策はありません。
バグ: 33535885
バージョン: 3.0.1
Terraformプロビジョニングにはリージョンの完全修飾ドメイン名が必要です
Oracle Cloud Infrastructure Terraformプロバイダを使用してOracle Private Cloud Applianceでのインフラストラクチャ・プロビジョニングを自動化する場合は、Terraformプロバイダのリージョン変数にアプライアンスの完全修飾ドメイン名を指定する必要があります。
ハードウェア・データの同期によりプロビジョニング・ノードがプロビジョニング準備完了に表示される
「サービスWeb UI」と「サービスCLI」はどちらも、ハードウェア・コンポーネントに関する情報を、内部ハードウェア管理サービスによって現在登録されている実際のステータスと同期するためのコマンドを提供します。 ただし、ステータスの変更が自動的に検出されて通信されるため、通常の状況ではハードウェアのステータスを同期する必要はありません。
さらに、ハードウェア・データの同期時にコンピュート・ノードのプロビジョニング操作が進行中の場合、プロビジョニングの状態を「プロビジョニング準備完了」に戻すことができます。 この情報は正しくなく、プロビジョニング・コマンドの後すぐにハードウェア同期が発生したため発生します。 この場合、コンピュート・ノードを再度プロビジョニングしようとすると、問題が発生する可能性があります。
回避策: コンピュート・ノードのプロビジョニングを開始し、そのプロビジョニング状態がプロビジョニングの場合は、少なくともさらに5分待って、それがプロビジョニング済に変わるかどうかを確認します。 コンピュート・ノードが「プロビジョニング済」として一覧表示されるのに非常に長い時間がかかる場合は、ハードウェア・データの同期コマンドを実行します。
コンピュート・ノードがまだ「プロビジョニング済」に変更されない場合は、コンピュート・ノードのプロビジョニングを再試行してください。
バグ: 33575736
バージョン: 3.0.1
ストレージ・コントローラのラックの高さが表示されない
「サービスWeb UI」のRack Unitsリストには、基本的なステータス情報を持つすべてのハードウェア・コンポーネントが表示されます。 データ・フィールドの1つは「ラック高さ」で、問題のコンポーネントが取り付けられているラック・ユニット番号です。 ZFSストレージ・アプライアンスのコントローラpcasn02の場合、ラックの高さは「使用不可」と表示されます。
回避策: 回避策はありません。 現在、基盤となるハードウェア管理サービスはこの特定のデータ・フィールドに移入されません。 2つのコントローラはそれぞれ2ラック・ユニットを占有し、RU 1-4に取り付けます。
バグ: 33609276
バージョン: 3.0.1
修正可能: 最新のパッチをシステムに適用してください。
拡張機能に使用されるフリー・フォーム・タグ
次のフリー・フォーム・タグを使用して、Oracle Private Cloud Applianceの機能を拡張できます。
ノート:
これらのタグ名は、他の目的に使用しないでください。
-
PCA_no_lmこのタグを使用して、インスタンスをライブ移行しないようにコンピュート・サービスに指示します。 値はTrueまたはFalseのいずれかです。
デフォルトでは、実行中のすべてのインスタンスをコンピュート・ノードから退避する必要がある場合などに、インスタンスをライブ移行できます。 ライブ移行は一部のインスタンスで問題になる可能性があります。 たとえば、ライブ移行は、Microsoft Windowsクラスタ内のインスタンスではサポートされていません。 インスタンスがライブ移行されないようにするには、インスタンスでこのタグをTrueに設定します。
このタグは、インスタンスの作成または
instance_nameの編集ダイアログのタグ付けセクション、oci compute instance launchまたはoci compute instance updateコマンド、またはAPIを使用して指定します。oci compute instance launchコマンドのオプションの例を次に示します:--freeform-tags '{"PCA_no_lm": "True"}'インスタンスでこのタグをTrueに設定すると、フォルト・ドメインの変更時にインスタンスを移動できなくなります。 フォルト・ドメインの変更は、ライブ移行ではありません。 インスタンスのフォルト・ドメインを変更すると、インスタンスは停止、移動および再起動されます。
-
PCA_blocksizeこのタグを使用して、特定のブロック・サイズで新しいボリュームを作成するようにZFSストレージ・アプライアンスに指示します。
デフォルトのブロック・サイズは8192バイトです。 別のブロック・サイズを指定するには、「ブロック・ボリュームの作成」ダイアログのタグ付けセクション、
oci bv volume createコマンドまたはAPIを使用して、PCA_blocksizeタグを指定します。 サポートされている値は、512から1Mバイトまでの2の累乗で、文字列として指定され、完全に展開されます。oci bv volume createコマンドのオプションの例を次に示します:--freeform-tags '{"PCA_blocksize": "65536"}'ボリュームの作成後は、ブロック・サイズを変更できません。
これらのタグの使用は、タグ制限に対してカウントされます。
バージョン: 3.0.1
インポートされたイメージが高パフォーマンス・プールと同期されていません
デフォルトのストレージ構成を持つOracle Private Cloud Applianceでは、コンピュート・イメージをインポートすると、標準のZFSプール内のimages LUNのZFS Storage Applianceに格納されます。 ストレージ構成があとで高性能ディスク・シェルフで拡張された場合、追加の高性能ZFSプールがZFS Storage Appliance上に構成されます。 ストレージ・プール間にレプリケーションがないため、元のプールのイメージは新しい高パフォーマンス・プールで自動的に使用可能になりません。 イメージは手動でインポートする必要があります。
回避策: 高パフォーマンスのストレージ・シェルフをアプライアンス構成に追加する場合は、必要なコンピュート・イメージを再度インポートして、新しく作成されたZFSプールにロードされていることを確認します。
バグ: 33660897
バージョン: 3.0.1
管理ノードの再起動後のAPIサーバー障害
3つの管理ノードのいずれかが再起動されると、クラスタ内の他の2つの管理ノードを介してアクセスできても、APIサーバーがリクエストに応答しないことがあります。 これは、管理ノード間で共有される仮想IPの所有権の問題、またはDNSサーバーが、使用可能な管理ノード上のサービス・ポッドにトラフィックをルーティングするのに十分な速さで応答しないことが原因である可能性があります。 再起動された管理ノードがクラスタに再参加した後も、APIサーバーが正常な動作状態に戻り、リクエストを再度受け入れるまでに数分かかる場合があります。
回避策: 1つの管理ノードが再起動すると、すべてのサービスが最終的に通常の動作状態にリストアされますが、それらのポッドは管理ノード・クラスタ間で異なる方法で分散されることがあります。 管理ノードの再起動後にUI、CLIまたはAPI操作が失敗した場合は、5分から10分待ってから再試行してください。
バグ: 33191011
バージョン: 3.0.1
CLIコマンドは、MySQL接続エラーのためステータス500を返します
コマンドがOCI CLIから発行され、APIサーバーによって受け入れられると、マイクロサービス・ポッドおよびMySQLデータベースを含む一連の内部操作が、他のコンポーネント間で開始されます。 タイムアウトに達する前に、操作を実行するように指示されたポッドがMySQLデータベースに接続できない場合があります。 この例外はAPIサーバーに報告されます。APIサーバーは、予期しない条件(HTTPステータス・コード500)のためにリクエストを処理できなかったことを報告します。 このタイプの例外では、一般的なサーバー・エラー・コードが生成されることは正常です。 詳細情報はログに格納できます。
回避策: CLIコマンドの発行後に汎用ステータス500のエラー・コードが返された場合は、コマンドを再度実行してみてください。 エラーが断続的な接続の問題の結果であった場合は、再試行時にコマンドが成功する可能性があります。
バグ: n/a
バージョン: 3.0.1
ストレージ・コントローラのフェイルオーバー後にマイクロサービス・ポッドが応答しない
ZFS Storage Applianceのコントローラ間でフェイルオーバーまたはフェイルバックが発生すると、管理ノードまたはKubernetesマイクロサービスポッドにマウントされたNFS共有が応答しなくなる可能性があります。 ストレージ・リソースの数およびI/O負荷が高いほど、マウントされたNFS共有が応答しなくなるリスクが高くなります。 サービスは、ポッドが応答しない共有によって管理ノードで実行されると影響を受けます。
NFSファイル・システムをアンマウントおよび再マウントしようとしないでください。古いファイル・ハンドルが生成され、リカバリが大幅に困難になります。 適切なリカバリ・プロセスは、応答しない共有がある管理ノードを識別し、NFSトラフィックに使用されるネットワーク接続を再起動し、サービス・ポッドを監視して、それらが自動的にリストアされるか手動でリストアされるかを確認することです。
回避策: アプライアンス管理者は、この問題の診断および解決に必要な操作の実行を許可されていません。 サポートをリクエストするには、Oracleサポートに連絡してください。
バグ: 33495030
バージョン: 3.0.1
承認グループの管理者(SuperAdmin以外)は、サービスCLIを使用してパスワードを変更する必要があります
セキュリティ制限が高いため、SuperAdmin認可グループのメンバーではない管理者は、「サービスWeb UI」のアカウント・パスワードを変更できません。 SuperAdmin以外の認可グループの管理者が独自のプロファイルにアクセスしようとすると、認可エラーが表示されます。
回避策: サービスCLIにログインし、ユーザー・プリファレンスでユーザーIDを検索し、パスワードを次のように変更します:
PCA-ADMIN> show UserPreference Data: Id = 1c74b2a5-c1ce-4433-99da-cb17aab4c090 Type = UserPreference [...] UserId = id:5b6c1bfa-453c-4682-e692-6f0c91b53d21 type:User name:dcadmin PCA-ADMIN> changePassword id=<user_id> password=<new_password> confirmPassword=<new_password>
バグ: 33749967
バージョン: 3.0.1
モニタリング・フレームワークのパスワード・ポリシーが他のインフラストラクチャ・コンポーネントと異なる
アプライアンス・インフラストラクチャ・コンポーネントのパスワード・ルールは、次のとおりです: 最小長は8文字で、少なくとも1つの小文字(a-z)、大文字(A-Z)、数字(0-9)および記号(@$!#%*&)が含まれます。 「サービスCLI」コマンドを実行して、これらのルールに一致するパスワードを適用できますが、アプライアンス・クラウド・ネイティブ・モニタリングおよびアラート・フレームワークのパスワード・ポリシーに違反しています(内部的にはSauronと呼ばれます)。
updateSauronCredentialsコマンドを実行し、モニタリング・フレームワークで新しいパスワードを拒否すると、モニタリング・フレームワークではなく、アプライアンス・インフラストラクチャ・コンポーネントのパスワード・ルールがエラー・メッセージに説明されます。 場合によっては、「サービスCLI」によって、パスワード更新コマンドがモニタリング・フレームワークによって受け入れられなかったが成功したことが報告されます。
回避策: アプライアンス・モニタリング・フレームワークに設定したパスワードが特定のパスワード・ポリシーに準拠していることを確認してください : 12-20文字の長さで、少なくとも1つの小文字(a-z)、大文字(A-Z)、数字(0-9)および特殊文字(-_+=)が含まれます。
バグ: 34816137
バージョン: 3.0.2
HAProxyが停止している場合、「サービスWeb UI」およびGrafanaは使用できません
HAProxyは、マイクロサービスとの間のすべてのアクセスのためにPrivate Cloud Applianceプラットフォーム・レイヤーによって使用されるロード・バランサです。 ロード・バランサおよびプロキシ・サービスが停止すると、「サービスWeb UI」およびGrafanaモニタリング・インタフェースは使用できません。 ログインしようとすると、エラー・メッセージが表示されます: 「サーバーが応答しませんでした」。
回避策: 管理ノードのいずれかにログインします。 HAProxyクラスタ・リソースのステータスを確認し、必要に応じて再起動します。
# ssh pcamn01
# pcs status
Cluster name: mncluster
Stack: corosync
[...]
Full list of resources:
scsi_fencing (stonith:fence_scsi): Stopped (disabled)
Resource Group: mgmt-rg
vip-mgmt-int (ocf::heartbeat:IPaddr2): Started pcamn03
vip-mgmt-host (ocf::heartbeat:IPaddr2): Started pcamn03
vip-mgmt-ilom (ocf::heartbeat:IPaddr2): Started pcamn03
vip-mgmt-lb (ocf::heartbeat:IPaddr2): Started pcamn03
vip-mgmt-ext (ocf::heartbeat:IPaddr2): Started pcamn03
l1api (systemd:l1api): Started pcamn03
haproxy (ocf::heartbeat:haproxy): Stopped (disabled)
pca-node-state (systemd:pca_node_state): Started pcamn03
dhcp (ocf::heartbeat:dhcpd): Started pcamn03
hw-monitor (systemd:hw_monitor): Started pcamn03HAProxyを起動するには、次の例に示すようにpcs resourceコマンドを使用します。 クラスタ・リソースのステータスが「停止(無効)」から「開始済」に変更されたことを確認します。
# pcs resource enable haproxy
# pcs status
[...]
Resource Group: mgmt-rg
haproxy (ocf::heartbeat:haproxy): Started pcamn03バグ: 34485377
バージョン: 3.0.2
コンピュート・ノードのパスワードの変更時にロック・ファイルの問題が発生
コンピュート・ノードまたはILOMのパスワードを変更するためのコマンドを発行すると、システムは関連するデータベースに一時ロックを設定し、パスワードの変更が信頼性の高い一貫した方法で適用されるようにします。 最初の試行でデータベース・ロックを取得または解放できない場合、システムはさらにリクエストを完了しようとします。 通常の動作環境では、パスワードが最終的に正常に変更されることが予想されます。 ただし、最終的な結果が「パスワードの変更が完了しました」である場合でも、コマンド出力には「DBロック・ファイルの作成に失敗しました」や「DBロックの削除に失敗しました」などのエラー・メッセージが含まれている可能性があります。
回避策: エラー・メッセージは不正確であり、パスワード操作が期待どおりに完了しているかぎり無視できます。 回避策は必要ありません。
バグ: 34065740
バージョン: 3.0.2
システムの電源再投入後にDracutプロンプトでコンピュート・ノードがハングアップ
アプライアンスまたはその一部のコンポーネントの電源を切断する必要がある場合(メンテナンスの実行など)、複雑なリブート・シーケンスのステップが正常に完了しないリスクは常に最小限に抑えられます。 システムの電源再投入後にコンピュート・ノードがリブートすると、ブート・フレームワークが必要なinitramfs/initrdイメージの構築に失敗するため、dracutプロンプトでハングアップすることがあります。 その結果、ルート・ファイル・システムのプライマリGPTパーティション・エラーが報告されます。
回避策: コンピュート・ノードのILOMにログオンします。 サーバーの起動に失敗し、dracutリカバリ・シェルにあることを確認します。 コンピュート・ノードを通常の操作に戻せるようにするには、reset /Systemコマンドを使用してILOMからリセットします。
バグ: 34096073
バージョン: 3.0.2
使用不可スパイン・スイッチのエラー・レポートなし
電源の喪失または致命的なエラーのためにスパイン・スイッチがオフラインになった場合、システムは「サービス・エンクレーブ」 UI/CLIまたはGrafanaで問題を通知しません。 この動作は、スイッチ・クライアントが例外を正しく処理せず、デフォルトの「健全」ステータスを報告し続ける結果です。
回避策: 現在、スパイン・スイッチの問題を管理者に警告するエラーを生成するための回避策はありません。
バグ: 34696315
バージョン: 3.0.2
ZFS Storage Appliance電源の再投入後にセーフ・シェルでスタックしたコントローラ
Oracle ZFS Storage Applianceの2つのコントローラは、アクティブ/アクティブのクラスタ構成で動作します。 ファームウェアがアップグレードされた場合やメンテナンスが必要な場合など、一方のコントローラがオフラインになると、もう一方のコントローラはすべてのストレージ・リソースの所有権を取得し、サービスの継続を提供します。 このプロセスでは、いくつかのロックを適用して解放する必要があります。 リブートされたコントローラがクラスタに再参加して割り当てられたストレージ・リソースの所有権を取得すると、必要なロックが正しく解放されないと、クラスタの同期は失敗します。 この状況では、リブートされたコントローラがセーフ・シェルでスタックし、ピア・コントローラが特定のロックを解放するまで待機する可能性があります。 これは、完全に完了しなかったテイクオーバー操作の結果であり、クラスタは不確定状態のままです。
回避策: 現在、回避策はありません。 ストレージ・コントローラ・クラスタがこの状況で終了した場合は、Oracleに連絡して支援を求めてください。
バグ: 34700405
バージョン: 3.0.2
最初のテナンシ作成が失敗し、後続の試行がすでに存在しているレポート
初期インストール・プロセスが完了したら、クラウド環境に最初のテナンシを作成します。 テナンシ作成コマンドの実行を担当するマイクロサービス・ポッドが、関連する操作の開始と完了の間にクラッシュした場合、作成プロセスは失敗します。 ただし、テナンシを再度作成しようとすると、テナンシがすでに存在することを示す例外が返されます。 これは、最初の試行でポッドがクラッシュする前にテナンシ構成の一部が格納されたためです。
回避策: この問題は、通常、タイミングが悪いことが原因です。 初期インストール・プロセスを完了すると、マイクロサービス・ポッドはリージョンおよびレルムのデータを更新し、新しい値で再起動する必要があります。 これには約3分かかります。 ポッドが再起動されるまで待ってから、システムの最初のテナンシを作成します。
バグ: 34743353
バージョン: 3.0.2
ストレージ構成のタイムアウトにより、同時コンピュート・ノードのプロビジョニング操作が失敗
Private Cloud Applianceがインストールされている場合、または一連の拡張コンピュート・ノードが追加されている場合、すべての新しいコンピュート・ノードを一度にプロビジョニングすることはできません。 ただし、プロビジョニングされたノードごとに、ストレージ・イニシエータおよびターゲットをZFS Storage Applianceで構成する必要があることに注意してください。 ストレージ・アプライアンスが処理する構成更新リクエストが多すぎる場合は、タイムアウトします。 その結果、すべてのコンピュート・ノードのプロビジョニング操作は失敗し、プロビジョニングされていない状態にロールバックされます。
回避策: ZFS Storage Appliance構成のタイムアウトを回避するには、コンピュート・ノードを1つずつ、または3つ以下のグループに順次プロビジョニングします。
バグ: 34739702
バージョン: 3.0.2
パスワードの変更後に報告されたスイッチ障害
コマンドを実行してスイッチのパスワードを更新すると、変更がコンポーネントに適用されるまでに短い遅延が発生します。 この遅延中にヘルス・チェックが実行されると、認証エラーが検出され、コンポーネントの実行状態が「失敗」に変更されます。 これにより、アクティブな障害が発生し、「サービス・エンクレーブ」 UIおよびCLIに表示され、アラートをトリガーできます。 パスワードの更新が正常に完了し、健全性検査に合格すると、障害はクリアされます。
回避策: スイッチの状態をモニタリングします。 パスワードの変更によって障害が発生した場合は、新しいパスワードが受け入れられると自動的にクリアされます。
PCA-ADMIN> list fault id name status severity -- ---- ------ -------- 6418d404-7702-41e8-de2a-83dcc69d08a8 RackUnitRunStateFaultStatusFault(pcaswsp01) Active Critical 90611c79-cf3f-4012-94c4-db709c97e390 RackUnitRunStateFaultStatusFault(pcaswsp02) Active Critical PCA-ADMIN> show fault id=90611c79-cf3f-4012-94c4-db709c97e390 Data: Type = Fault Category = Status Severity = Critical Status = Active Associated Attribute = runStateFault Last Update Time = 2022-11-17 21:30:50,251 UTC Cause = RackUnit pcaswsp02 attribute 'runStateFault'= 'CRITICAL'. [...]
バグ: 34850833
バージョン: 3.0.2
Kubernetesヘルス・チェッカがエンドポイントを検出できない
リリース3.0.2にアップグレードすると、Kubernetesヘルス・チェッカが異常な状態で終了し、必要なエンドポイントに接続できなくなる可能性があります。 この問題は、Prometheus Kubernetesポッド内の「プロメテウス・コンテナ」がメモリー不足(OOMKilled)になり、繰り返し再起動されることが原因です。
# kubectl describe pod prometheus-k8s-0 -n monitoring
[...]
prometheus:
Container ID:
cri-o://5f1ef5176f4c1124085662556e94008e46c9090d35a2894e8187f9b16df14fbe
Image: 253.255.0.31:5000/sauron/prometheus-mirror:2.20.0-1
Image ID:
253.255.0.31:5000/sauron/prometheus-mirror@sha256:9a2552ae5a53ad11b83cdd91463f
d83ae8826620f31ee8c3eefc6ef99c1da0ab
Port: 9090/TCP
Host Port: 0/TCP
[...]
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: OOMKilledコンテナ・メモリー制限は、問題を回避するために増やされましたが、これらの設定はPrometheus Kubernetesポッドの再起動後にのみ有効になります。 最新のHelmチャートに基づいて、ポッドは適切なコンテナ・メモリー制限を適用して再起動されます。
# kubectl delete pod prometheus-k8s-0 -n monitoring pod "prometheus-k8s-0" deleted
回避策: アプライアンス管理者は、この問題の診断および解決に必要な操作の実行を許可されていません。 サポートをリクエストするには、Oracleサポートに連絡してください。
バグ: 34858888
バージョン: 3.0.2
パスワード変更でスタックしているリーフ・スイッチ
リーフ・スイッチのパスワードを変更すると、スイッチ自体のパスワード更新中にプロセスがハングアップする可能性があります。 スイッチのプロパティとログは、スイッチのprovisioningStateパラメータを「Update_Switch_Password」と表示することによってこれを示します。 スイッチのパスワード変更にはかなりのラグがある可能性があるため、コマンドの実行後10-30分以内に操作が正常に完了する可能性があります。 その時間枠内に状況が自動的に解決されない場合、スイッチはこの状態でスタック状態とみなされ、プラットフォームと同期しなくなる可能性があります。
回避策: スイッチがアプライアンス・プラットフォームと同期しなくなった場合は、スイッチ・オペレーティング・ソフトウェアでパスワードを手動で適用する必要があります。
# config
(config)# username admin password <password>
(config)# end
# copy running-config startup-configバグ: 34819799
バージョン: 3.0.2
アクティブなコンソール接続のためにデータ・スイッチのブートに失敗
「Cisco Nexus 9336C-FX2スイッチ」にアクティブなローカル・コンソール・セッションがある場合(端末サーバーが接続されている場合など)、リブート中にスイッチがランダムにハングアップすることがあります。 ブート・シーケンスの中断は、コンソール・ポートのゴースト・セッションが原因であると想定されます。 ローカル・コンソール接続が使用されていない場合、この動作は確認されていません。
回避策: データ・スイッチのコンソール・ポートにケーブルを接続しないでください。 Private Cloud Applianceインストールでは、ローカル・コンソール接続は必要ありません。
バグ: 32965120
バージョン: 3.0.2
ユーザー・インタフェースの問題
このセクションでは、グラフィカル・ユーザー・インタフェースに関連する既知の問題と回避策について説明します。
コンパートメント間でのリソースの移動は、「コンピュートWeb UI」ではサポートされていません
「コンピュートWeb UI」には、リソースをコンパートメント間で移動するファンクションはありません。 クラウド・リソースが存在するコンパートメントを変更する操作は、CLIでのみ実行できます。 ただし、すべてのリソース・タイプでコンパートメントの変更がサポートされるわけではありません。 たとえば、どのネットワーク・リソースも移動できません。
回避策: リソースを現在のコンパートメントから別のコンパートメントに移動する必要がある場合は、CLIを使用します。 CLIコマンドが正常に実行されると、「コンピュートWeb UI」で結果の変更を確認できます。
バグ: 33038606
バージョン: 3.0.1
インスタンス・プールを更新するために使用可能な「コンピュートWeb UI」操作がありません
「コンピュートWeb UI」には、既存のインスタンス・プールのプロパティを更新する機能はありません。 UpdateInstancePoolおよびUpdateInstancePoolDetails APIリソースのユーザー・インタフェース実装はありません。
回避策: CLIを使用してインスタンス・プールを更新します。 このコマンドを使用します:
oci compute-management instance-pool update [OPTIONS]
バグ: 33393214
バージョン: 3.0.1
変更なしでリソース・プロパティを保存すると、ステータスがプロビジョニングに簡単に変更されます
「コンピュートWeb UI」の編集ダイアログ・ボックスを開いてリソースのプロパティを変更し、実際にプロパティを変更せずに変更の保存をクリックすると、リソースのステータスは数秒間「プロビジョニング」に変更されます。 これは、保存ボタンをクリックしたユーザーに対してUIの通常のレスポンスです。 副作用はありません。
回避策: リソース・ステータスを変更していない場合にプロビジョニングに変更しないようにするには、かわりにダイアログ・ボックスの取消ボタンをクリックします。
バグ: 33445209
バージョン: 3.0.1
NFSエクスポート・スカッシュIDが表示されない
「コンピュートWeb UI」では、NFSエクスポートの詳細ページには、NFSエクスポート・オプションにスカッシュIDが表示されません。 NFSエクスポートへの匿名アクセスにはスカッシュIDが必要ですが、取得できるのはエクスポート・オプションの編集のみです。
回避策: NFSエクスポート・スカッシュIDを取得するには、NFSエクスポート詳細ページに移動し、NFSエクスポート・オプションまでスクロールして、編集オプションをクリックします。 または、CLIからエクスポート・オプションを検索します。
バグ: 33480572
バージョン: 3.0.1
ブラウザに表示されないスクロール・バー
Private Cloud Applianceのブラウザベースのインタフェースは、Oracle JavaScript Extension Toolkit (JET)を使用して構築され、Oracle企業設計ガイドラインに従います。 スクロール・バーは、指定したスペース内にコンテンツが収まらない画面の一部をアクティブに使用していないかぎり、非表示のままにしておくことを目的としています。 - たとえば: 大きな表、長いドロップダウン・リストなど。 すべてのブラウザまたはブラウザ・バージョンに、意図した方法でスクロール・バーが表示されるわけではありません。 たとえば、Google Chromeは通常意図したとおりにスクロール・バーを非表示にしますが、Mozilla Firefoxはスクロール・バーを非表示にしません。
回避策: スクロール・バーの動作は、設計上です。 これは、「コンピュートWeb UI」と「サービスWeb UI」の両方に適用されます。 割り当てられた画面領域を超えてコンテンツが実行される領域では、問題のコンテンツの上にカーソルを置くと、適切な場所にスクロール・バーが自動的に表示されます。
バグ: 33489195
バージョン: 3.0.1
コンパートメント・データの取得時の認可の失敗
Identity and Access Managementサービスを使用すると、ポリシーを介してリソースへのユーザー・アクセス権限を細かく制御できます。 これらのポリシーは、特定のタイプのリソースに対して、または特定のコンパートメントに存在するリソースに対して、ユーザー・グループが実行する権限がある操作を決定します。 特定の状況では、「コンピュートWeb UI」は、ユーザーがアクセス権を持たないすべてのリソースを非表示にすることはできません。 その結果、ユーザー操作によって、アカウントがアクセスを許可されていないデータのリクエストが発生する可能性があります。
「コンピュートWeb UI」の使用中に、権限のないデータの取得が操作によってトリガーされる場合に、認可の失敗が発生することがあります。 この場合、ブラウザにエラーが表示され、アカウント権限のためにアプリケーションが動作を停止したことが示されます。 コンパートメント・ツリーでは、アクセスが許可されていないコンパートメントを表示できるため、特に、このタイプの失敗が発生しやすくなります。
回避策: コンパートメント・ツリーのアクセスの問題が原因でエラーが発生した場合は、再試行をクリックすると目的のページが表示されます。 それ以外の場合は、テナンシ管理者に連絡して、必要なデータにアクセスするための追加の権限をリクエストしてください。
バグ: 33497526, 33520207
バージョン: 3.0.1
オブジェクト・リストは自動更新されません
「コンピュートWeb UI」では、ディレクトリ構造を参照して、バケットに格納されているオブジェクトを表示します。 オブジェクトのリストまたは表は定期的に自動的にリフレッシュされないため、オブジェクトの変更は、手動でページをリフレッシュしたときにのみ表示されます。 UIがバケットのステータスをポーリングするために使用できる機能はありません。
回避策: コンピュートWeb UI内のオブジェクトの現在のリストを表示するには、ページを手動でリフレッシュします。 この動作はオブジェクト・ストレージ・サービスに固有ではありません。UIの他の領域でも発生する可能性があります。 リソース・リストが定期的に自動的に更新されない場合は、手動でリフレッシュする必要があります。
バグ: 33519215
バージョン: 3.0.1
ファイル・ストレージ・マウント・ターゲット・リンクを使用できません
「コンピュートWeb UI」のファイル・ストレージ領域で、次のようにマウント・ターゲットのURLを確認できます: マウント・ターゲットのリストを表示し、目的のマウント・ターゲットを選択し、エクスポートをクリックして詳細ページを表示し、「マウント・ターゲット」フィールドを見つけます。 ただし、マウント・ターゲットが存在していても使用不可と表示されている場合があります。
回避策: UIは、常にファイル・システム・ストレージ・サービスからリソースの詳細を取得できるわけではありません。 UIで詳細を再度取得するように強制するには、ページをリフレッシュするか、移動して戻ります。
バグ: 33571007
バージョン: 3.0.1
セキュリティ・リスト・ルール表に表示されないUDPポート
セキュリティ・リストに属するイングレス・ルールおよびエグレス・ルールは、セキュリティ・リスト詳細ページのリソース・セクションの表に表示されます。 UDPポートに関連するルールを作成する場合、ポート番号はポート範囲列に表示されません。 UDP設定は失われません。これらは編集ウィンドウで表示できます。
回避策: セキュリティ・リストの編集ウィンドウには、UDPポートを含むすべての関連設定が表示されます。 イングレスまたはエグレス・ルールを変更するには、アクション・メニュー(行の右端)で編集を選択します。
バグ: 33575269
バージョン: 3.0.1
ドロップダウン・リストに表示されていないリソース
ドロップダウン・リストを使用してリソースを選択する必要がある場合、リストが非常に長いとすべてのアイテムが表示されるとはかぎりません。 リストをスクロールすると、より多くのアイテムがロードされますが、探しているアイテムが見つからない場合があります。 この動作の理由は、UIコンポーネントは、ロード時間が長いためにユーザーを遅くするのではなく、すばやく応答するように設計されています。 完全なアルファベット順リストをスクロールするのではなく、テキスト・フィールドにリソース名の一部を入力して、長いリストをフィルタすることをお薦めします。 これは、Oracle JavaScript Extension Toolkitの特性であるため、「コンピュートWeb UI」と「サービスWeb UI」の両方に影響
回避策: スクロールは、長いドロップダウン・リストでアイテムを検索するための望ましい方法ではありません。 代わりに、探しているリソースの名前を入力し始めると、使用可能なリスト・アイテムは、入力した内容に一致するものに縮小されます。
バグ: 33583708
バージョン: 3.0.1
ボリューム・グループは名前なしで作成できます
「コンピュートWeb UI」のブロック・ストレージ領域でボリューム・グループを作成する場合、名前を入力する必要はありません。 名前フィールドを空白のままにすると、ボリューム・グループは「名前なしアイテム」としてリストに表示されます。 ただし、CLIでボリューム・グループを作成するときに名前を指定しない場合、作成時間に基づいて名前が自動的に割り当てられます。
回避策: これはコードのバグではありません : この名前は技術的には必須パラメータではありません。 意味のない名前でボリューム・グループが作成されないようにするには、「コンピュートWeb UI」およびCLIで、作成時に適切な名前を指定してください。 名前を指定せずに誤ってボリューム・グループを作成した場合は、後でボリューム・グループを編集して、選択した名前を追加できます。
バグ: 33608462
バージョン: 3.0.1
ファイルシステムとマウント・ターゲットが表示されない
ユーザーが特定のコンパートメント内のリソースへのアクセス権を持ち、テナンシのルート・コンパートメントのコンテンツを表示する権限がない場合、「コンピュートWeb UI」には、ユーザーがリストを許可されているリソースが表示されないことがあります。 代わりに、承認エラーが表示されます。 特にファイル・システム・サービスでは、ユーザーがそのコンパートメントおよびそれに含まれるリソースへのフル・アクセス権を持っている場合でも、特定のコンパートメント内のファイル・システムまたはマウント・ターゲットは表示されません。
この動作は、ルート・コンパートメントのOCIDを使用して、UIからAPIリクエストが行われる方法によって発生します。 対照的に、CLIでは、リクエストされたリソースを効果的に格納するコンパートメントのOCIDを指定する必要があるため、UIと同じ認可問題の影響を受けません。
回避策: テナンシ管理者は、ファイル・システム・サービスのユーザーがルート・コンパートメントへの読取りアクセス権を持っていることを確認する必要があります。 ユーザーが使用を許可されているファイル・システムおよびマウント・ターゲットをリストできないユーザーは、テナンシ管理者に、アカウント権限を確認して必要な調整を行うように依頼する必要があります。
バグ: 33666365
バージョン: 3.0.1
オプションのICMPセキュリティ・ルール・パラメータは削除できません
VCNのセキュリティ・リストにイングレスまたはエグレス・セキュリティ・ルールを追加すると、ICMPプロトコルを特に選択できます。 「コンピュートWeb UI」は、各リストから「パラメータ・タイプ」および「パラメータ・コード」を選択することがオプションであることを示します。 パラメータ・タイプはICMPルールに必須であるため、これは正しくありません。
ICMPルールでタイプとコードの両方を指定した場合、パラメータ・コードを削除できます。 セキュリティ・ルールを編集し、コード・テキスト・フィールドにカーソルを置き、そのコンテンツを削除します。 これは、UIでのドロップダウン・リストの仕組みです。選択する"empty"オプションはありません。
回避策: ICMPセキュリティ・ルールを操作する場合は、常にパラメータ・タイプを指定します。 ドロップダウン・リストから選択したオプション・パラメータを削除するには、テキスト・フィールドのコンテンツを選択して削除します。
バグ: 33631794
バージョン: 3.0.1
DHCPオプションの作成時にコンパートメント・セレクタを使用できません
「コンピュートWeb UI」を使用してVCNのDHCPオプションを作成または変更する場合、DHCPオプションを別のコンパートメントに追加する方法はありません。 コンパートメント・セレクタは作成および編集ウィンドウで使用できないため、DHCPオプションはVCN自体と同じコンパートメントに暗黙的に格納されます。 ただし、DHCPオプションを別のコンパートメントに格納することはサポートされています。 その場合は、CLIを使用してください。
回避策: DHCPオプションを、適用先のVCNとは異なるコンパートメントに格納する場合は、CLIを使用してDHCPオプションを作成するか、CLIを使用して目的のコンパートメントに移動します。
バグ: 33722013
バージョン: 3.0.1
修正可能: 最新のパッチをシステムに適用してください。
オペレーションが取消された場合、カスタム検索ドメイン・エラーはロールバックされません
ネットワーキング・サービスでは、VCNおよびサブネットのレベルでDHCPオプションを設定することで、特定のインスタンス・ブート構成パラメータを制御できます。 制御できるDHCPオプションの1つは検索ドメインであり、DNS対応VCNおよびサブネットのインスタンスFQDNに自動的に追加されます。
検索ドメインは、example.tldの形式で指定する必要があります - TLDは最上位ドメインを表します。 無効な検索ドメインを保存しようとすると、2つのエラー・メッセージが表示されます: 「ドメインの検索」フィールドのすぐ下に表示され、もう一方はDHCPオプション・ウィンドウの下部に表示され、「一部のフィールドが不完全または無効です」と示されます。 DHCPオプションの作成または変更を取り消して、DHCPオプション・ウィンドウを再度開くと、設定が適用されていなくても、エラー・メッセージおよび誤った値が引き続き表示されることがあります。
回避策: 新しい設定を保存しようとして失敗したあとでDHCP Optionsウィンドウを閉じて開き直しても、同じエラー・メッセージと無効な値が表示される場合は、エラーを無視できます。 ブラウザ・ウィンドウをリフレッシュすると、エラー・メッセージがクリアされることがあります。 必要なフォーマットでカスタム検索ドメインを入力します: example.tld
バグ: 33734400
バージョン: 3.0.1
カスタム検索ドメインのDHCPオプション・エラー・メッセージが誤解しています
ネットワーキング・サービスでは、VCNおよびサブネットのレベルでDHCPオプションを設定することで、特定のインスタンス・ブート構成パラメータを制御できます。 制御できるDHCPオプションの1つは検索ドメインであり、DNS対応VCNおよびサブネットのインスタンスFQDNに自動的に追加されます。
検索ドメインは、example.tldの形式で指定する必要があります - TLDは最上位ドメインを表します。 ただし、「コンピュートWeb UI」はこのパラメータを検証しません。これは、DHCPオプションを保存するときにネットワーキング・サービスによって行われます。 「コンピュートWeb UI」は、値に空白が含まれていないことを確認します。 その場合、「ドメインの検索」フィールドにエラー・メッセージが表示されます: "example.tldの形式である必要があります"。 これは、値がスペースを含むことを示しているだけであるため、技術的には不正確です。
回避策: 必要なフォーマットでカスタム検索ドメインを入力します : example.tld。 ドメイン名にスペースは使用できません。 問題のエラー・メッセージが表示された場合は、「ドメインの検索」フィールドに入力した値を修正し、DHCPオプションの保存を再試行してください。
バグ: 33753758
バージョン: 3.0.1
権限が不十分な「サービスWeb UI」へのログイン時の不明エラー
「サービス・エンクレーブ」では、SuperAdmin認可グループのメンバーである管理者は、他の管理者アカウントを作成し、それらのアカウントが属する認可グループを決定できます。 特定の管理者が「サービスWeb UI」にログインできないようにするアクセス制限を設定できますが、「サービスCLI」には引き続きアクセスできます。
この状況が発生した場合、「サービスWeb UI」は認可の問題を明確に説明しないエラー・メッセージを返します - 次に例を示します:
{"message":"AUTH_000008: An error occurred getting system config state.",
"errorCode":"AUTH_SERVICE_GET_CONFIG_STATE_ERROR",
"cause":["Caused by: com.oracle.pca.ui.common.server.exception.PcaConsoleException:
SERVICE_000002: Calling underlying service resulted in an error:
Failed to get PcaSystem object from admin service [Bad Request]."],"csrfToken":null,"idps":null,"serviceError":null}回避策: この例のようなエラーが表示され、サービスWeb UIにアクセスできる場合は、適切な権限を持つアプライアンス管理者に依頼して、管理者アカウントのアクセス制限を修正してください。
バグ: 34522989
バージョン: 3.0.2
「コンピュートWeb UI」から新しいファイルシステムへのスナップショットのクローニングはサポートされていません
ファイル・システムのスナップショットをクローニングし、そのクローンを新しいファイル・システムとして使用できます。 ただし、この機能は「コンピュートWeb UI」では提供されません。
回避策: ファイル・システムをクローニングするには、OCI CLIを使用します。 すでにファイル・システム・スナップショットがある場合、これは新しいファイル・システムにクローニングするコマンド構文です:
oci fs file-system create --availability-domain <availability_domain_name> --compartment-id <compartment_OCID> --display-name <fs_display_name> --source-snapshot-id <snapshot_OCID>
バグ: 34566069
バージョン: 3.0.2
スナップショットからクローニングされたファイル・システムの詳細が表示されません
ファイル・システムを作成すると、そのファイル・システムに関するすべての関連情報が「コンピュートWeb UI」詳細ページに表示されます。 OCI CLIコマンドoci fs file-system getからの出力とほぼ同じ情報が含まれています。 ただし、OCI CLIを使用してファイルシステムのスナップショットをクローニングして新しいファイルシステムとして使用する場合、クローン・ファイル・システムの詳細ページには同じデータが表示されません。 関連する欠落フィールドには、ソース・スナップショット、親ファイル・システム、クローン・ルート、ハイドレーションなどがあります。
回避策: これらの詳細が必要な場合は、かわりにOCI CLIを使用します。 CLIには、クローン・ベースのファイル・システムのすべてのデータ・フィールドが表示されます。
バグ: 34566735
バージョン: 3.0.2
管理ネットワークの有効化後にネットワーク環境情報が自動的にリフレッシュされない
「サービスWeb UI」のネットワーク環境領域で、アプライアンス・ネットワーク構成を編集して管理ネットワークで分離された管理接続を有効にすると、構成変更を保存しても「ネットワーク環境情報」ページはリフレッシュされません。
回避策: 適用した管理ネットワーク・パラメータを表示するには、ブラウザの「ネットワーク環境情報」ページを手動でリフレッシュする必要があります。
バグ: 34769734
バージョン: 3.0.2
インスタンス・バックアップの詳細を表示できません
インスタンスのバックアップを作成すると、それはオブジェクト・ストレージ・バケットに格納されます。 バックアップ操作が完了し、バックアップ・オブジェクトの詳細を表示しようとすると、HTTP 404エラーが返される場合があります。
回避策: ブラウザ・ページを手動で再ロードします。 バックアップの詳細が表示されます。 ポップアップには追加のエラー・メッセージが表示される場合がありますが、それらは無視できます。
バグ: 34777856
バージョン: 3.0.2
VNICの詳細ページのIPアドレス・リストが更新されていません
「コンピュートWeb UI」では、インスタンスにアタッチされたVNICの詳細ページから、コンピュート・インスタンスに割り当てられたIPアドレスを管理できます。 VNICの詳細ページのリソース・セクションの「IPアドレス」表で、プライベートIPとパブリックIPを追加および削除できます。 ただし、パブリックIPの予約ポップアップ・ウィンドウが常に正しくレンダリングされるわけではなく、適用された変更は「VNIC IPアドレス」表に表示されません。
回避策: 回避策はありません。
バグ: 34797160
バージョン: 3.0.2
すべてのパブリックIPの使用中にパブリックIPアドレスを予約しようとしたときにエラーが表示されない
「コンピュートWeb UI」で、プールから使用可能なパブリックIPがなくなったときにパブリックIPアドレスを予約しようとすると、エラー・メッセージは表示されません。 パブリックIPの予約ウィンドウがハングしますが、試行している操作に関するフィードバックは提供しません。 予約可能なIPがないため、操作は完了しません。
回避策: パブリックIPの予約ウィンドウを閉じるか、ブラウザ・インタフェース・ページを再ロードします。 別のパブリックIPアドレスを予約するには、管理者がPrivate Cloud Appliance環境のパブリックIPプールを拡張する必要があります。
バグ: 34832457
バージョン: 3.0.2
Exadataネットワークの削除時に誤ったエラー・メッセージが表示される
「サービスWeb UI」を使用してExadataネットワークを削除すると、ネットワークが正常に削除されたにもかかわらず、操作が失敗したというエラー・メッセージが表示される場合があります。
回避策: エラー・メッセージに依存しません。 Exadataネットワークが削除され、Exadata Networksリストに表示されなくなったことを確認します。
バグ: 34680351
バージョン: 3.0.2
バックアップからボリューム・グループを作成する場合、そのボリュームは表示されません
ボリューム・グループに含まれるボリューム・セットのバックアップを作成し、そのボリューム・グループ・バックアップから新しいボリューム・グループを作成できます。 その後、新しいボリューム・グループには、バックアップの一部であったボリュームと同じボリュームが含まれます。 ただし、操作が正常に完了しても、新しいボリューム・グループの一部である個々のボリュームは、「コンピュートWeb UI」のボリューム・グループ詳細ページに表示されません。
回避策: OCI CLIを使用して、ボリュームが存在することを確認し、ボリュームに対して必要な操作を実行します。
バグ: 33997759
バージョン: 3.0.2
ネットワークの問題
この項では、アプライアンス・ネットワーキングのすべての側面に関連する既知の問題と回避策について説明します。これは、システム内部接続、データ・センターへの外部アップリンク、およびユーザーのコンピュート・インスタンスの仮想ネットワーキングです。
DNSゾーン範囲を設定できません
DNSゾーンを作成または更新する場合、スコープを設定できません。 コマンドライン出力では、scopeプロパティの値はnullです。
バグ: 32998565
バージョン: 3.0.1
DNSレコードを更新するには、コマンドに既存の保護されたレコードを含める必要がある
DNSレコードを更新する場合、更新がこれらのレコードに影響を及ぼさない場合でも、既存のすべての保護レコードを更新コマンドに含める必要があります。 この要件は、既存の保護されたレコードが誤って削除されないようにすることを目的としています。 ただし、特定の更新の実現が困難なSOAレコードについては、チェックが非常に制限されています。
回避策: コマンドの一部としてSOAレコードを指定するか、SOAドメインを含まないようにドメインを設定することで、既存のレコードを更新できます。 実際には、ほとんどのレコード更新は上位レベルで行われ、これらの制限の影響を受けません。
バグ: 33089111
バージョン: 3.0.1
修正可能: 最新のパッチをシステムに適用してください。
Oracle Linux 8インスタンス・ホスト名の解決に失敗
ホスト名のみを使用してOracle Linux 8コンピュート・インスタンスと対話しようとすると、DNSサーバーはリクエストを実行できず、名前解決に失敗します。 インスタンスの完全修飾ドメイン名(FQDN)を使用すると、期待どおりに解決されます。 この問題は、VCNのレベルでのDNSドメインの構成が不完全であることが原因です: 作業中のDNSゾーンの最小要件であるNSまたはSOAレコードはありません。
回避策: Oracle Linux 8インスタンスにアクセスするには、常にFQDNを使用します。 Oracle Linux 7インスタンスはこの問題の影響を受けません: ホスト名のみを使用するDNSリクエストが正しく処理されます。
バグ: 34734562
バージョン: 3.0.1
混乱しているエラー・メッセージでルート表の作成に失敗
ルート表を作成し、ルート・ルール・パラメータに誤りがある場合、APIサーバーは誤解を招くエラー・メッセージを返すことがあります。 特定のメッセージが読み取る: 「ルート表ターゲットは、LPG、NATゲートウェイ、インターネット・ゲートウェイ、DRGアタッチメントまたはサービス・ゲートウェイのいずれかである必要があります。」可能なターゲットのリストで、DRGアタッチメントが正しくありません。 動的ルーティング・ゲートウェイ自体は、DRGアタッチメントではなくターゲットとして指定する必要があります。
回避策: 問題のエラー・メッセージは無視してください。 動的ルーティング・ゲートウェイを介してトラフィックを送信するようにルート・ルールを構成する場合は、DRGをターゲットとして指定します。
バグ: 33570320
バージョン: 3.0.1
VCN作成で非推奨のパラメータを使用
VCNを作成する場合は、通常、対象となるCIDR範囲を指定します。 「コンピュートWeb UI」では、該当するフィールドに入力します。 ただし、CLIには2つのコマンド・パラメータが用意されています: --cidr-blockは非推奨となり、--cidr-blocksは非推奨となった新しいパラメータです。 Private Cloud ApplianceでOCI CLIを使用する場合は、--cidr-blockを使用する必要があります。 新しいパラメータはAPIサーバーでサポートされていません。
回避策: 非推奨のパラメータに関する警告メッセージは無視してください。 VCNで使用されるCIDR範囲を指定する場合は、--cidr-blockパラメータを使用します。
バグ: 33620672
バージョン: 3.0.1
セキュリティ・ルールによってブロックされたファイル・ストレージ・トラフィック
ユーザーがインスタンスにファイル・システムをマウントできるようにするには、マウント・ターゲットとインスタンス間の必要なネットワーク・トラフィックを許可するために、デフォルト・セキュリティ・リスト内のものに加えてセキュリティ・ルールを構成する必要があります。 Oracle Private Cloud Applianceでのファイル・ストレージ・ポートおよびプロトコルの構成は、アンダー・レイ・ネットワーク・アーキテクチャによってさらに複雑になります。これは、セキュリティ・ルールのソースと宛先が特定の方法で設定されていないかぎり、ファイル・ストレージ・トラフィックを予期せずブロックできます。
「シナリオA」 - ファイル・システム・サービスを使用するマウント・ターゲットおよびインスタンスが同じサブネットに存在する場合は、デフォルト・セキュリティ・リストに加えて、セキュリティ・リストを作成してサブネットにアタッチします。 新しいセキュリティ・リストには、次のステートフル・ルールが含まれている必要があります。
+++ Ingress Rules ++++++++++++++++++++
Source Protocol Source Ports Destination Ports
------ -------- ------------ -----------------
<subnet CIDR> TCP All 111, 389, 445, 4045,
2048-2050, 20048
<subnet CIDR> UDP All 111, 289, 445, 2048,
4045, 20048
+++ Egress Rules ++++++++++++++++++++
Destination Protocol Source Ports Destination Ports
----------- -------- ------------ -----------------
<subnet CIDR> TCP 111, 389, 445, 4045, All
2048-2050, 20048
<subnet CIDR> TCP All 111, 389, 445, 4045,
2048-2050, 20048
<subnet CIDR> UDP 111, 389, 445, All
4045, 20048
<subnet CIDR> UDP All 111, 389, 445,
4045, 20048「シナリオB」 - ファイル・システム・サービスを使用するマウント・ターゲットおよびインスタンスが異なるサブネットに存在する場合は、サブネットごとに新しいセキュリティ・リストを作成し、デフォルト・セキュリティ・リストに加えて各サブネットにアタッチします。
マウント・ターゲットを含むサブネットの新しいセキュリティ・リストには、次のステートフル・ルールが含まれている必要があります:
+++ Ingress Rules ++++++++++++++++++++
Source Protocol Source Ports Destination Ports
------ -------- ------------ -----------------
<instances subnet CIDR> TCP All 111, 389, 445, 4045,
2048-2050, 20048
<instances subnet CIDR> UDP All 111, 289, 445, 2048,
4045, 20048
+++ Egress Rules ++++++++++++++++++++
Destination Protocol Source Ports Destination Ports
----------- -------- ------------ -----------------
<instances subnet CIDR> TCP 111, 389, 445, 4045, All
2048-2050, 20048
<instances subnet CIDR> UDP 111, 389, 445, All
4045, 20048ファイルシステム・サービスを使用したインスタンスを含むサブネットの新しいセキュリティ・リストには、次のステートフル・ルールが含まれている必要があります:
+++ Ingress Rules ++++++++++++++++++++
Source Protocol Source Ports Destination Ports
------ -------- ------------ -----------------
<mount target subnet CIDR> TCP 111, 389, 445, 4045, All
2048-2050, 20048
<mount target subnet CIDR> UDP 111, 289, 445, 2048, All
4045, 20048
+++ Egress Rules ++++++++++++++++++++
Destination Protocol Source Ports Destination Ports
----------- -------- ------------ -----------------
<mount target subnet CIDR> TCP All 111, 389, 445, 4045,
2048-2050, 20048
<mount target subnet CIDR> UDP All 111, 389, 445,
4045, 20048回避策: ここに示すガイドラインに従って、ファイル・システムのサービス・トラフィックを有効にするイングレスおよびエグレス・ルールを構成します。 未変更のデフォルト・セキュリティ・リストがすでに添付されている場合、提案されたエグレス・ルールを追加する必要はありません。これは、すべてのエグレス・トラフィック(宛先: 0.0.0.0/0、プロトコル: all)を許可するデフォルトのステートフル・セキュリティ・ルールがすでにあるためです。
バグ: 33680750
バージョン: 3.0.1
ステートフルおよびステートレス・セキュリティ・ルールは結合できません
アプライアンスでは、テナンシ内のステートフル・セキュリティ・ルールとステートレス・セキュリティ・ルールの組合せを構成できます。 これらのセキュリティ・ルールから生成されたアクセス制御リストは正しいですが、仮想アンダー・レイ・ネットワークで誤った解釈が発生する可能性があります。 その結果、特定のトラフィックがブロックされるか、誤って許可される可能性があります。 したがって、ステートフルまたはステートレスのセキュリティ・ルールを使用することをお薦めします。
ノート:
特定のニーズがある場合は、ステートフル・ルールとステートレス・ルールを組み合せることができますが、ステートレス・ルールを使用する場合は対称である必要があります。つまり、ステートレス・エグレス・ルールと、同じフローにステートフル・イングレス・ルールを持つことはできません。バグ: 33744232
バージョン: 3.0.1
同じサイズの単一サブネットを持つVCNはサポートされていません
VCNを作成する際、最大サイズが/16"のCIDR範囲を割り当てます - たとえば: 10.100.0.0 /16,または172.16.64.0 /18。 ネットワーキング・サービスでは、VCN内にサブネットを作成することを期待しますが、それを複数の小さなサブネットに分割するのではなく、単一の大規模サブネットを使用する方が好ましい場合があります。 ただし、サブネットが属するVCNより小さくする必要があります。
回避策: VCN内で1つの大きなサブネットを使用する場合は、サブネットに必要なIPアドレス範囲を超えるCIDRでVCNが設定されていることを確認します。
バグ: 33758108
バージョン: 3.0.1
修正可能: 最新のパッチをシステムに適用してください。
システムの初期化中にCIDRとして構成されたパブリックIPでのルーティングの失敗
アプライアンスの初期設定ステップを完了すると(「Oracle Private Cloud Applianceインストレーション・ガイド」の章「Oracle Private Cloud Applianceの構成」の「初期設定の完了」を参照)、最後のステップの1つは、クラウド・リソースにパブリックIPとして割り当てられるデータ・センターのIPアドレスを定義することです。 BGPベースの動的ルーティングを選択した場合、パブリックIPは1つ以上のCIDRとして定義されているときに正しく通知されないため、アプライアンスの外部から到達できないことがあります。
回避策: アプライアンスの外部からクラウド・リソースのパブリックIPに到達できるようにするには、 /32ネットマスクを使用してすべてのIPアドレスを個別に指定します。 たとえば、192.168.100.0/24,と入力するかわりに、カンマ区切りのリストを送信します: 192.168.100.1/32, 192.168.100.2/32, 192.168.100.3/32, 192.168.100.4/32,など。
バグ: 33765256
バージョン: 3.0.1
修正可能: 最新のパッチをシステムに適用してください。
管理ネットワークは「サービスWeb UI」アクセスに使用できません
(オプション)管理ネットワークの目的は、システム管理者に「サービスWeb UI」への個別のアクセスを提供することです。 管理ネットワークの現在の実装は不完全であり、正しいアクセスを提供できません。
回避策: 使用可能なものがありません。 この時点で、「いけない」は初期構成時に管理ネットワークを構成します。
バグ: 34087174, 34038203
バージョン: 3.0.1
初期インストール手順中にネットワーク構成が失敗
アプライアンス・ラックを物理的に設置したあと、使用できるようにするには、システムを初期化し、データセンター環境に統合する必要があります。 この手順は、「Oracle Private Cloud Applianceインストレーション・ガイド」の「Oracle Private Cloud Applianceの構成」という章で説明されています。 この手順のネットワーク構成部分が失敗した場合 - たとえば、メッセージ・トランスポートまたはサービス・ポッドの問題、またはスイッチから戻されたエラーのため - 操作を再試行する前に手動でロールバックする必要があるロックが設定されています。
回避策: 使用可能なものがありません。 サポートが必要な場合は、Oracleに連絡してください。
可能な場合は、「サービスCLI」からネットワーク構成の状態を確認します。
PCA-ADMIN> show networkConfig
Data:
[...]
Network Config Lifecycle State = FAILEDバグ: 34788596
バージョン: 3.0.2
外部証明書は許可されていません
現時点では、Oracle Private Cloud Applianceは外部CA署名証明書の使用を許可しません。
回避策: 回避策については、Oracleサポートに連絡してください。
バグ: 33025681
バージョン: 3.0.2
低いアップリンクMTU設定によりブラウザ・インタフェースのロードが妨げられます
アップリンク・ポートの最大転送単位(MTU)を異常に小さいサイズに設定すると、Private Cloud Applianceとデータセンター環境の間のネットワーク・パフォーマンスが低下し、接続が中断されることがあります。 たとえば、分離された管理ネットワークではより低いMTUが必要になる場合がありますが、パケット・サイズが極端に小さいという症状は、「サービスWeb UI」をロードできないことです。 ただし、システムは特定の動作範囲を強制しないため、異常なMTUを構成するときにエラーは返されません。
回避策: デフォルトのアップリンクMTUは9216バイトです。 データ・センターの設定で別の設定が必要な場合は、1500バイトなどの一般的なパケット・サイズを使用してください。
バグ: 34841495
バージョン: 3.0.2
コンカレント作成操作後にプロビジョニングにスタックしたVCN
複数のVCNを同時に作成すると、一部はプロビジョニング状態でスタック状態になり、使用できなくなる可能性があります。 これはまれな競合状態が原因で、短い時間、異なるスレッドによってオブジェクトのライフサイクル状態を更新できます。
回避策: 一連のVCNを同時に作成した後、いずれかのVCNオブジェクトが"PROVISIONINGFAIL"状態で終了した場合、選択したインタフェース(UI、CLI、Terraform)を使用してスタック・リソースを削除し、再度作成します。
バグ: 34841815
バージョン: 3.0.2
管理ネットワーク構成はサービスへのアクセスをブロック
管理ネットワークが有効になっているPrivate Cloud Appliance環境では、すべての管理トラフィックがデータ・ネットワークから厳密に分離されます。 その結果、コンピュート・インスタンスとアプライアンス管理サービス間のピア・ツー・ピア接続は許可されません。
回避策: 管理機能にアクセスするには、Private Cloud Appliance外部のホストを使用してください。
バグ: 34849776
バージョン: 3.0.2
リリース3.0.2へのアップグレード後、既存のインスタンスのMetadataにFQDNが含まれていません
コンピュート・インスタンスのホスト名解決のために、DNS構成はインスタンス・メタデータに格納されている特定のパラメータに依存します。 リリース3.0.2のソフトウェアは、名前解決の信頼性を高めるために改善されています。 ただし、ソフトウェア・アップグレード前に作成されたインスタンスは、メタデータの変更を利用しません: 関連するフィールドは、完全修飾ドメイン名(FQDN)で自動的に更新されません。
回避策: 現在、既存のインスタンスに対する回避策はありません。 ソフトウェアのアップグレード後に作成されたインスタンスのメタデータには、正しい値が含まれています。
バグ: 34859081
バージョン: 3.0.2
リリース3.0.2へのアップグレード後にOracle Linux 8インスタンスのDNSエントリが正しくない
アプライアンス・ソフトウェアをリリース3.0.2にアップグレードしても、コンピュート・インスタンスのオペレーティング・システムの名前解決設定は自動的に更新されません。 インスタンスDHCPリースが更新されると、最新のネットワーク・パラメータが取得されます。 それまでは、Oracle Linux 8がDNSサーバー・メッセージに応答する方法が原因で、FQDNを使用した問合せは成功しますが、短いホスト名を解決できません。 Oracle Linux 7インスタンスはこの問題の影響を受けません。
回避策: Oracle Linux 8インスタンスのコマンドラインでDHCPクライアント・サービス(dhclient)を再起動します。 インスタンスを再起動すると、問題が解決されます。
バグ: 34918899
バージョン: 3.0.2
コンピュート・サービスの問題
この項では、コンピュート・サービスに関連する既知の問題および回避策について説明します。
ブロック・ボリュームに接続するための一貫性のあるデバイス・パスがありません
ブロック・ボリュームをインスタンスにアタッチするときには、インスタンス・リブート間で一貫性を保つデバイス・パスを指定することはできません。 つまり、attach-paravirtualized-volume CLIコマンドの場合、オプションの--deviceパラメータは機能しません。 インスタンスの再起動後にデバイス名が異なる場合があるため、これは、パーティション化、ファイル・システムの作成およびマウントなど、ボリュームで実行するタスクに影響します。
回避策: 回避策はありません。
バグ: 32561299
バージョン: 3.0.1
開始またはスケーリング中にインスタンス・プールを終了できません
プール内のインスタンスが起動中であり、プール内のインスタンスの数を増減するスケーリング操作の進行中は、インスタンス・プールを終了できません。 一方、個々のインスタンスはいつでも終了できます。
回避策: インスタンス・プールを終了するには、すべてのインスタンスが起動するか、スケーリング操作が完了するまで待ちます。 その後、インスタンス・プール全体を正常に終了できます。
バグ: 33038853
バージョン: 3.0.1
Windowsのネットワーク・インタフェースはDHCPサーバーからのMTU設定を受け入れません
インスタンスが起動されると、DHCPを介してIPアドレスがリクエストされます。 DHCPサーバーからのレスポンスには、VNIC最大転送単位(MTU)を9000バイトに設定する手順が含まれています。 ただし、Windowsインスタンスは1500バイトのMTUを使用して起動するため、ネットワーク・パフォーマンスに悪影響を及ぼす可能性があります。
回避策: インスタンスにDHCPサーバーによって初期IPアドレスが割り当てられたら、インタフェースMTUを手動で適切な値に変更します(通常は、インスタンスのプライマリVNICでは9000バイト)。 この新しい値は、ネットワーク切断およびDHCPリース更新で保持されます。
または、WindowsイメージにMTUPluginを含むcloudbase-initが含まれている場合、DHCPからインタフェースMTUを設定できます。 この機能を有効にするには、次のステップを実行します。
-
ファイル
C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confを編集します。 次の行を追加します。mtu_use_dhcp_config=true plugins=cloudbaseinit.plugins.common.mtu.MTUPlugin
-
コマンド
Restart-Service cloudbase-initを入力します。 -
MTU設定が変更されたことを確認します。 このコマンドを使用:
netsh interface ipv4 show subinterfaces。
バグ: 33541806
バージョン: 3.0.1
Oracle Solarisバックアップからのリストア後のメンテナンス・モードのインスタンス
既存のインスタンスのブート・ボリュームのバックアップから新しいインスタンスを作成することはサポートされています。 既存のインスタンスが実行中または停止している可能性があります。 ただし、Private Cloud Applianceで提供されているOracle Solarisイメージに基づいてインスタンスのブート・ボリューム・バックアップを使用する場合、そのバックアップから作成された新しいインスタンスはメンテナンス・モードでブートします。 Oracle Solarisコンソールにこのメッセージが表示されます : 「システム・メンテナンス(バイパスするにはcontrol-d)のユーザー名を入力してください:」
回避策: ブロック・ボリューム・バックアップから作成された新しいOracle Solarisインスタンスがメンテナンス・モードで起動したら、コンピュートWeb UIまたはCLIからインスタンスを再起動します。 この再起動後、インスタンスは通常の実行状態に戻り、そのネットワーク・インタフェースを介して到達可能です。
バグ: 33581118
バージョン: 3.0.1
コンピュート・ノード・メトリックに表示されないインスタンス・ディスク・アクティビティ
コンピュート・インスタンスにアタッチされた仮想ディスクは、ホスト・コンピュート・ノードのハイパーバイザを介してゲストに表示されます。 そのため、インスタンスのディスクI/Oは物理ホストのレベルで検出され、Grafanaのコンピュート・ノードのディスク統計に反映されます。 残念ながら、仮想ディスク上のアクティビティは、コンピュート・ノードのディスク・メトリックに集約されません。
回避策: コンピュート・ノード・メトリックを分析するのではなく、各コンピュート・ノードでインスタンス・ディスクI/Oおよび集計された負荷をモニターするには、Grafanaを介して表示される個々のVM統計を使用します。
バグ: 33551814
バージョン: 3.0.1
Oracle Solarisインスタンス内でアタッチされたブロック・ボリュームが表示されない
追加のブロック・ボリュームを実行中のOracle Solarisコンピュート・インスタンスにアタッチしても、オペレーティング・システムには自動的に表示されません。 ディスクを手動で再スキャンした後でも、新しくアタッチされたブロック・ボリュームは非表示のままです。 この問題は、ハイパーバイザがゲストLUNを再列挙するための正しいイベント・トリガーを送信しないために発生します。
回避策: 追加のブロック・ボリュームをOracle Solarisコンピュート・インスタンスにアタッチする場合は、インスタンスを再起動して、新しい仮想ディスクまたはLUNが検出されていることを確認します。
バグ: 33581238
バージョン: 3.0.1
ホスト名が正常に起動されたWindowsインスタンスに設定されていません
DNSが有効になっているVCNおよびサブネットで作業しており、インスタンスを起動すると、ホスト名がインスタンスの表示名または指定したオプションのホスト名のいずれかと一致することが想定されます。 ただし、Windowsインスタンスを起動すると、起動コマンド・パラメータに従ってホスト名が正しく設定されていない可能性があります。 この場合、インスタンス完全修飾ドメイン名(FQDN)は想定どおりに解決され、機能低下はありません。 インスタンス自体のホスト名設定のみが正しくありません。VCN DNS構成は想定どおりに機能します。
回避策: インスタンスのホスト名が指定したインスタンス起動パラメータと一致しない場合は、インスタンス内のホスト名を手動で変更できます。 機能への影響はありません。
または、WindowsイメージにSetHostNamePluginを含むcloudbase-initが含まれている場合、インスタンスのFQDN (hostname-label)に基づいてインスタンス・ホスト名(「コンピュータ名」)を設定できます。 この機能を有効にするには、次のステップを実行します。
-
ファイル
C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confを編集します。 次の設定を含む行が含まれていることを確認してください。plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin allow_reboot=true
-
コマンド
Restart-Service cloudbase-initを入力します。 -
インスタンス・ホスト名が変更されたことを確認します。
バグ: 33736674
バージョン: 3.0.1
Oracle Solaris UEFI対話型シェルでインスタンスがスタックしています
管理ノードのwebサーバーを介して提供されたイメージからデプロイされたOracle Solaris 11.4コンピュート・インスタンスがUEFI対話型シェルでスタックし、ブートに失敗することが判明しました。 インスタンスがそのブート・シーケンスを完了しない場合、ユーザーはログインできません。 この問題は、テナンシへのインポート中に元の.ociイメージ・ファイルが破損したことが原因である可能性があります。
回避策: UEFIのブート中にOracle Solaris 11.4インスタンスがハングアップし、まだ使用できない場合は、次のように進めます:
-
ブートに失敗したインスタンスを終了します。
-
インポートされたOracle Solaris 11.4イメージを削除します。
-
管理ノードのwebサーバーからOracle Solaris 11.4イメージを再度インポートします。
-
新しくインポートされたイメージからインスタンスを起動し、完全にブートした後でログインできることを確認します。
バグ: 33736100
バージョン: 3.0.1
インスタンス・バックアップがEXPORTINGまたはIMPORTING状態になることがある
まれに、インスタンスがエクスポートしてバックアップを作成したり、バックアップをインポートしたりするときに、いずれかのコンポーネントの障害が発生した場合、エクスポートまたはインポートされたバックアップはEXPORTINGまたはIMPORTING状態でスタックします。
回避策:
- インスタンス・バックアップを削除します。
- 5分以上待って、すべての内部サービスが実行されていることを確認します。
- インスタンスのエクスポートまたはインポート操作を再度実行します。
「コンピュート・インスタンスのデプロイメント」の「インスタンスのバックアップおよびリストア」を参照してください。
バグ: 34699012
バージョン: 3.0.1
コンピュート・ノードの再起動後にインスタンスの停止時間が延長されました
インスタンスの実行中にコンピュート・ノードが再起動すると、影響を受けるコンピュート・インスタンスは自動的にリカバリされます。 コンピュート・ノードが通常の操作に戻ると、ハイパーバイザは同じホスト・コンピュート・ノード上のインスタンスを再起動しようとします。
再起動コマンドは、コンピュート・ノード・エージェントとハイパーバイザの間にアクティブな接続が確立された場合にのみ発行されます。 ハイパーバイザ接続が停止している場合、インスタンスの再起動は失敗し、5分後に新しい試行が行われます。 最大5回の再起動試行は、5分間隔で行われます。
回避策: 再起動の試行に5回失敗した後、または再起動したコンピュート・ノードが通常の操作に戻った約25分後に、使用できないままのインスタンスは手動で再起動する必要があります。
バグ: 34343810
バージョン: 3.0.1
ターゲット・コンピュート・ノードでのゲスト構成のクリーンアップが不完全であるため、移行されたインスタンスの起動に失敗
コンピュート・インスタンスが1つのコンピュート・ノードから別のコンピュート・ノードにライブ移行されると、一連の内部操作および状態の変更が行われて、新しいホストでの正常な動作状態になったこと、および両方のコンピュート・ノードでのハイパーバイザ構成が、移行アクティビティの結果生じた変更を正しく反映していることが確認されます。 同様に、コンピュート・ノードのデータ・ネットワーク接続が中断されると、コールド移行プロセスが開始し、コンピュート・インスタンスも一連の内部操作および状態変化を通過します。
インスタンスが複数の連続する移行操作に関与している場合、すべての移行アクティビティがユーザーに成功しているように見えますが、コンピュート・サービスでは、すべての状態変更およびハイパーバイザ構成を十分に迅速にクリーン・アップできない可能性があります。 すべてのクリーンアップ操作が完了していないコールド移行後にコンピュート・インスタンスを起動しようとすると、起動コマンドは失敗し、「リクエストされた操作は無効です: すでに使用されている/var/lib/libvirt/qemu/nvram/<filename>_VARS.fdに異なるSELinuxラベルを設定しています」を示す内部サーバー・エラーが発生します。
回避策: このシナリオは、本番環境ではほとんど発生しません。 ただし、相互に数分以内に複数のインスタンス移行をトリガーする可能性があるアクションは避けてください。 移行後にインスタンスを回復できないこの状況になった場合は、Oracleに連絡してください。
バグ: 34640667
バージョン: 3.0.2
フォルト・ドメインの変更後にインスタンスが起動しない
コンピュート・インスタンスのフォルト・ドメインを変更すると、システムはそれを停止し、選択したターゲット・フォルト・ドメインのコンピュート・ノードにコールド移行して、新しいホストでインスタンスを再起動します。 このプロセスには、インスタンスがターゲット・コンピュート・ノードで正常な実行状態に戻れるようにするための多数の内部操作が含まれています。 これらの内部操作のいずれかが失敗した場合、インスタンスは停止したままになります。
フォルト・ドメインの変更で問題が発生するリスクは、操作の複雑さとともに増加します。 たとえば、複数のインスタンスを別のフォルト・ドメインに同時に移動する場合(特に、共有ブロック・ボリュームを持ち、ターゲット・フォルト・ドメイン内の異なるコンピュート・ノードに移行する場合)は、ストレージ・レベルでタイミングが重要な構成変更を多数必要とします。 移行されたコンピュート・インスタンスの新しいホストで基礎となるiSCSI接続を使用できない場合、ハイパーバイザはインスタンスを起動できません。
回避策: フォルト・ドメインを変更した後、コンピュート・インスタンスが停止したままの場合は、手動で起動してみてください。 前述のタイミングの問題が原因でインスタンスが起動できなかった場合は、手動起動コマンドによってインスタンスが通常の実行状態に戻される可能性があります。
バグ: 34550107
バージョン: 3.0.2
Libvirtプロセスの書込みエラーによりインスタンスの起動または移行が失敗
共有ディスクが読取り/書込みモードであるコンピュート・インスタンスの場合、ハイパーバイザはSCSI永続予約を介してゲストSCSIベースのディスクを管理します。 すべての関連リクエストは、ゲスト・ドメインに関連付けられたヘルパー・プロセス(qemu-pr-helper)によって処理されます。 このプロセスのIDは、Libvirt制御グループ(cgroup)に格納されます。 コンピュート・インスタンスの起動時に、ハイパーバイザがインスタンスに関連付けられたqemu-pr-helperプロセスのIDを検出できない場合があります。 これにより、次の例のような書込みエラーが発生します:
Unable to write to '/sys/fs/cgroup/cpu,cpuacct/machine.slice/machine-qemuXYZ.scope/tasks': No such process
回避策: 問題は断続的です。 同じ操作を繰り返すと、成功する可能性があります。
バグ: 34376870
バージョン: 3.0.2
インスタンスの移行がMOVING状態でスタックしています
「サービスWeb UI」を使用してVMを移行する場合、移行がMOVINGライフサイクル状態でスタックする可能性があるため、これ以上の移行を続行できません。
このエラーは、ライブ移行などの管理アクティビティがパッチ適用またはアップグレード・プロセス中に実行されている場合や、パッチ適用またはアップグレード・プロセスが完全に完了する前に管理アクティビティが開始される場合に発生することがあります。
回避策: この問題を解決するには、Oracle Supportに連絡してください。
バグ: 33911138
バージョン: , 3.0.1, 3.0.2
ストレージ・サービスの問題
このセクションでは、内部ZFSストレージ・アプライアンスおよびさまざまなストレージ・サービスの機能に関連する既知の問題と回避策について説明します: ブロック・ボリューム・ストレージ、オブジェクト・ストレージおよびファイル・システム・ストレージ。
インスタンスからのイメージの作成に時間がかかる
インスタンスから新しいコンピュート・イメージを作成すると、そのブート・ボリュームは一連のコピーおよび変換操作を通過します。 また、仮想ディスク・コピーは非スパースであるため、フル・ディスク・サイズはビットごとにコピーされます。 その結果、イメージの作成時間は、ベース・インスタンスのブート・ボリュームのサイズによって大幅に増加します。
回避策: イメージ作成ジョブが完了するまで待ちます。 「コンピュートWeb UI」で作業リクエストのステータスを確認するか、作業リクエストIDを使用してCLIでそのステータスを確認します。
バグ: 33392755
バージョン: 3.0.1
ZFSコントローラのフェイルオーバー後に大きなオブジェクト転送が失敗する
オブジェクト・ストレージ・バケットへの大きなファイルのアップロードまたはダウンロード中にZFSコントローラのフェイルオーバーまたはフェイルバックが発生した場合、接続が中断され、データ転送が失敗する可能性があります。 マルチパート・アップロードも同様に影響を受けます。 この問題は、短いストレージ接続がタイムアウトした場合に再試行関数を提供しないバージョンのOCI CLIを使用すると発生します。 再試行機能は、バージョン3.0から使用できます。
回避策: ラージ・オブジェクトおよびマルチパート・アップロードの信頼性の高い転送を行うには、OCI CLIバージョン3.0以降を使用します。
バグ: 33472317
バージョン: 3.0.1
100MiBより大きいオブジェクトのマルチパート・アップロードの使用
非常に大きなファイルをオブジェクト・ストレージにアップロードすると、接続やパフォーマンスの問題が発生する可能性があります。 オブジェクト・ストレージへのファイル転送を最大限の信頼性を得るには、マルチパート・アップロードを使用します。
回避策: マルチパート・アップロードを使用して、100MiBを超えるファイルをオブジェクト・ストレージに転送します。 この動作は予想されますが、バグとはみなされません。
バグ: 33617535
バージョン: n/a
大規模エクスポート・オプション更新後のファイル・システムのエクスポート一時アクセス不可
ファイル・システムのエクスポートを更新して多数の'source'タイプのエクスポート・オプションを追加すると、エクスポートが存在しなくなったことを示すサービス・エラーがコマンドによって返されます("code": "NotFound")。 実際、エクスポートは、構成更新が完了するまでアクセスできなくなります。 エクスポートにアクセスしたり、格納されている情報を表示しようとすると、同様のエラーが表示されます。 この動作は、ファイル・システムのエクスポート・オプションの更新に使用するメソッドによって発生します: 既存の構成が削除され、リクエストされた変更を含む新しい構成で置き換えられます。 まれに何十ものエクスポート・オプションを同時に追加した場合にのみ注目してください。
回避策: 更新が完了し、ファイル・システムのエクスポートが再度使用可能になるまで待ちます。 CLIコマンドoci fs export get --export-id <fs_export_ocid> は、問題のエクスポートに関する情報を返します。
バグ: 33741386
バージョン: 3.0.1
デタッチ状態になったブロック・ボリューム
ブロック・ボリュームは、複数の異なるコンピュート・インスタンスにアタッチでき、同じインスタンスに複数のアタッチメントを含めることもできます。 同じボリュームの同時ボリューム・デタッチ操作が発生したときに、自動化ツールと同様にプロセスが相互に干渉する場合があります。 たとえば、作業リクエストが異なると、ZFSストレージ・アプライアンス上のリソースを同時に更新しようとしたり、作業リクエスト内のデータが古いり、アプライアンスのリソース更新の競合が発生したりすることがあります。 この方法でブロック・ボリュームのデタッチ操作が失敗すると、ブロック・ボリュームがこのステージのインスタンスからデタッチされていても、問題のブロック・ボリューム・アタッチメントは「デタッチ中」状態でスタックする可能性があります。
回避策: ブロック・ボリュームがデタッチ中状態でスタックしているインスタンスがある場合、ボリュームはデタッチされていますが、さらに手動クリーンアップが必要です。 「デタッチ中」状態はクリアできませんが、影響を受けるインスタンスは停止でき、ブロック・ボリュームは最終目標の場合は削除できます。
バグ: 33750513
バージョン: 3.0.1
修正可能: 最新のパッチをシステムに適用してください。
Terraformを使用したボリュームのデタッチがタイムアウトのために失敗
Terraformを使用してインスタンスからボリュームをデタッチすると、ボリューム・アタッチメントが破棄されず、ボリュームがアタッチされた状態のままであることを示すエラー・メッセージで操作が失敗することがあります。 これは、Terraformがボリューム・アタッチメントの状態のポーリングを停止する前に、ストレージ・サービスがボリュームがデタッチされたことの確認を送信しない場合に発生する可能性があります。 Terraformがエラーを報告すると、ボリュームが正常にデタッチされることがあります。
回避策: Terraform構成を再適用します。 エラーがタイムアウトの結果であった場合、2回目の実行は成功します。
バグ: 34732321
バージョン: 3.0.2
スケジュール済ボリューム・バックアップがバックアップ・リストに表示されません
ブロック・ボリューム・バックアップ・ポリシーを構成すると、バックアップ・スナップショットが定期的に作成されます。 ただし、コンパートメント内のすべてのブロック・ボリューム・バックアップをリストする場合、これらの自動バックアップはリストに表示されません。 これは設計によって発生します: ZFSストレージ・アプライアンスからすべてのボリュームのバックアップのリストの取得には、比較的時間がかかるため、同期はボリュームごと、および明示的な手動リクエストが行われた場合にのみ行われます。
回避策: バックアップ・ポリシーを介して作成されたボリューム・バックアップのリストにアクセスするには、次に示すように--volume-id <bv_ocid>を指定してlistコマンドを使用し、問題のボリュームのバックアップを具体的に表示します。 これにより、エントリがボリューム・バックアップのリストと同期されます。つまり、コンパートメント内のすべてのブロック・ボリューム・バックアップを次回リストしたときにすべて表示されます。
oci bv backup list --volume-id <bv_ocid> --compartment-id <compt_ocid>
バグ: 33785277
バージョン: 3.0.1
OCI CLIオブジェクト・ストレージ・ネームスペースの正しい値が返されない場合がある
ネームスペース値を取得する多くのコマンドは、CLIコマンドoci os ns getを使用して取得されるデフォルト値を提供します。 そのコマンドによって返されるデータが正しくない可能性があるため、この値をネームスペースとして使用するコマンドは失敗します。
回避策: オブジェクト・ストレージ・ネームスペースのデフォルト値に依存しません。 パラメータが必要なときは常に、コマンドラインでネームスペース値を明示的に入力します。
正しいオブジェクト・ストレージ・ネームスペース値を取得するには、Web UIを使用します。 「コンピュートWeb UI」の右上隅にあるユーザー・メニューをクリックし、テナンシをクリックします。 ネームスペースの値は、オブジェクト・ストレージ設定の下にリストされます。
OCI CLIを使用してネームスペース値を取得する必要がある場合は、コマンドに"iaas"エンドポイントを明示的に追加します。
oci os ns get --endpoint https://iaas.<mypca>.example.com { "data": "<myobjstor>" }
開発者は、この動作がOracle Cloud Infrastructureと異なることに注意してください。
バグ: 34133183
バージョン: 3.0.1
タイムアウトが原因でファイル・システムのエクスポートの作成に失敗
多くのファイル・システム操作がパラレルに実行されるときに、タイミングが重要なファクタとなり、ときどき障害が発生する可能性があります。 具体的には、ファイル・システムが使用できないために、ファイル・システムのエクスポートの作成がタイムアウトする可能性があります。 その場合に返されるエラーは次のとおりです: 「内部サーバー・エラー: エクスポートを作成するファイルシステムがありません」」。
回避策: このエラーはリソースのロックおよびタイムアウトの問題が原因であるため、再度実行しようとすると操作が成功すると予想されます。 このエラーはまれなケースでのみ発生します。
バグ: 34778669
バージョン: 3.0.2
同時ファイル・システム作成操作によるフラッシュ中の例外
新しいテナンシ内に最初のファイル・システム・リソースが作成されると、特定のデータベース・エントリが作成されます。 別の同時ファイル・システム作成操作が進行中の場合は、両方のジョブが同じデータベース・エントリの作成を試行する可能性があります。 これにより競合が発生し、次のようなエラーが返されます: 「フラッシュ中に以前の例外が発生したため、セッション・トランザクションがロールバックされました。」。
回避策: このエラーはタイミングの問題が原因であるため、失敗した操作およびロールバックされた操作は、再度実行しようとすると成功します。
バグ: 34774136
バージョン: 3.0.2
サブセットIP範囲の別のエクスポートが削除されると、ファイル・システム・アクセスが失われます
仮想クラウド・ネットワーク(VCN)に含めることができるファイル・システム・マウント・ターゲットは1つのみです。 VCNに接続されたインスタンスで使用可能になったすべてのファイル・システムは、そのマウント・ターゲット内でエクスポートが定義されている必要があります。 ファイル・システムのエクスポートにより、重複するサブネットやIPアドレス範囲から様々なファイル・システムにアクセスできます。 次に例を示します: filesys01は、IP範囲10.25.4.0/23およびfilesys02からIP範囲10.25.5.0/24まで使用可能にできます。 後者のIP範囲は、前者のサブセットです。 マウントIPアドレスの割当て方法により、filesys02のエクスポートを削除すると、スーパーセットIP範囲のfilesys01へのアクセスも削除されます。
回避策: ファイル・システムのエクスポートでソースIPアドレスの範囲が重複しており、あるエクスポートを削除すると、前述の例のような別のエクスポートでアクセスの問題が発生する場合は、影響を受けるエクスポートを削除し、VCNマウント・ターゲット内で再度作成することをお薦めします。
バグ: 33601987
バージョン: 3.0.2
ファイル・システムのエクスポートUID/GIDを変更できません
ファイル・システムのエクスポートを作成する際には、ソースIPアドレスのアクセス権限やアイデンティティ・スカッシングなどのNFSエクスポート・オプションを追加できます。 NFSエクスポート・オプションでユーザー/グループ・アイデンティティ(UID/GID)のスカッシュ値を設定すると、その値は変更できなくなります。 別のIDを設定しようとすると、エラーが返されます: "Uid and Gid are not consistent with FS AnonId: <currentUID>"
回避策: UID/GIDマッピングを変更する必要がある場合は、NFSエクスポート・オプションを削除して、必要な値で再作成します。 OCI CLIを使用している場合は、(オプションだけでなく)ファイル・システム・エクスポート全体を削除し、--export-optionsパラメータで目的の値を指定してエクスポートを再作成する必要があります。
バグ: 34877118
バージョン: 3.0.2
ディスク割り当ての変更によるインスタンスの移行後のZFSプールの使用量の減少
コンピュート・インスタンスにアタッチされた仮想ディスクまたはブロック・ボリュームは、ZFS Storage ApplianceのZFSプールに構成されているiSCSI LUNです。 これらのLUNで使用可能なディスク領域は、作成時に完全に割り当てられます。 ただし、コンピュート・インスタンスが別のコンピュート・ノードに移行されると、そのブロック・ボリュームに関連付けられたLUNは、スパース・ディスク領域割当てに変更されます。 これは、構成されたサイズではなく、事実上使用中のディスク領域のみが割り当てられることを意味します。これは、ZFSプールの使用率の減少から明らかです。
PCA-ADMIN> show ZfsPool name=PCA_POOL
Data:
Id = e898b147-7cf0-4bd0-8b54-e32ec83d04cb
Type = ZfsPool
Pool Status = Online
Free Pool = 44879343128576
Total Pool = 70506183131136
Pool Usage Percent = 0.3634693989163486
Name = PCA_POOL
Work State = Normal回避策: 使用可能な回避策はありません。 ディスク領域割当てメソッドは、Oracle ZFS Storage Applianceオペレーティング・ソフトウェアによって制御されます。
バグ: 34922432
バージョン: 3.0.2
保守性の問題
このセクションでは、サービス、サポート、アップグレード、およびデータ保護機能に関連する既知の問題と回避策について説明します。
リリース3.0.2へのアップグレードの最小アップグレード・パッケージ・バージョン
アプライアンス・ソフトウェア・リリース3.0.1からリリース3.0.2へのアップグレード・パスには、失敗する可能性があるホスト・アップグレード・コマンドがあり、操作を完了するために2回目に実行する必要があります。 アプライアンス・ソフトウェアのアップグレード手順の実行に最新バージョンのアップグレード・プログラムを使用すると、これらの問題を回避できます。 リリース3.0.2にアップグレードする前にシステムにインストールする必要がある最小のパッケージ・バージョンは、pca-upgrader-3.0.101.17.g813e14f-1.el7です。
回避策: いずれかの管理ノードのコマンドラインから、upgraderパッケージがリストされたバージョンまたは新しいバージョンであることを確認します。 そうでない場合は、リリース3.0.2にアップグレードする前に、Oracleサポートに連絡してください。
# rpm -qa | grep 'pca-upgrader-3.0.'
pca-upgrader-3.0.101.17.g813e14f-1.el7バグ: 34077896
バージョン: 3.0.2
コンポーネントのアップグレード順序が変更されました
プラットフォームの更新時、「最初にコンピュート・ノードを更新する必要があります」。 この順序でコンピュート・ノードを更新しないと、アップグレードが失敗してシステムが中断する可能性があります。
- コンピュート・ノード
- 管理ノード
- 管理ノードのオペレーティング・システム
- MySQL Clusterデータベース
- シークレット・サービス
- コンポーネントのファームウェア
- Kubernetesクラスタ
- Microservices
バグ: 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
1つのストレージ・コントローラが使用できないときにアップグレード・コマンドが失敗
ZFS Storage Applianceには、HAクラスタで動作する2つのコントローラがあり、いずれかのコントローラが停止しても動作し続けます。 ただし、1つのコントローラが使用不可の場合、RabbitMQ内部メッセージ・バスの接続エラーのため、アップグレード関連の操作は失敗: 「RabbitMQサービスでエラーが発生しました: 90秒後に受信したレスポンスはありません」。 アップグレード・サービスはレスポンスを送信できないため、アップグレード・ジョブ履歴を表示することもできません。
回避策: 両方のストレージ・コントローラが稼働していることを確認します。 次に、必要なアップグレード・コマンドを再実行します。
バグ: 34507825
バージョン: 3.0.2
管理ノードのアップグレードが原因でLokiが停止
管理ノード・クラスタのアップグレード中に、各管理ノードが個別にアップグレードおよびリブートされます。 一般に、クラスタは高可用性を提供するため、サービスの継続があります。 ただし、管理ノード・クラスタのアップグレード中にLokiが短時間停止することが予想されます。 これは、コンテナ化されたマイクロサービスで通常の動作とみなされ、複数のサーバー・ノードに分散されたポッド内で実行され、1つずつ再起動されます。
回避策: 管理ノードのアップグレード中にLokiログアグリゲーションが中断された場合は、アップグレード操作が完了するまで待機し、Lokiが通常の操作に戻ることを確認します。 自動完全リカバリは、Kubernetesコンテナのライフサイクルの一部として必要です。
バグ: 34452451
バージョン: 3.0.2
共有ブロック・ボリュームを持つインスタンスは、異なるディザスタ・リカバリ構成の一部にできません
複数のインスタンス間で共有されるブロック・ボリュームをアタッチできます。 これらのインスタンスを障害リカバリ(DR)構成に追加すると、そのアタッチされたボリュームは専用のZFSストレージ・プロジェクトに移動されます。 ただし、インスタンスがそれぞれ別のZFSストレージ・プロジェクトを持つ異なるDR構成に属している場合、システムは共有ブロック・ボリュームを移動できません。そのため、常に無効なDR構成になります。 そのため、ディザスタ・リカバリ・サービスでは、共有ブロック・ボリュームを含むコンピュート・インスタンスを異なるDR構成に追加することはサポートしていません。
回避策: 共有ブロック・ボリュームを持つインスタンスを同じDR構成に含めたり、共有ボリュームではなく各インスタンスに異なるブロック・ボリュームをアタッチすることを検討してください。
バグ: 34566745
バージョン: 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
ディザスタ・リカバリ・レプリケーション・ターゲットの更新の失敗
ディザスタ・リカバリ・サービスの構成を更新してレプリケーション・ターゲットを変更する場合、ZFS Storage Applianceおよびそのネットワーク接続に適用する必要がある変更がいくつかあります。 一部の設定は、既存の接続がタイムアウトするまで変更できません。 そのため、障害時リカバリ・サービスでは、新しい設定をZFS Storage Applianceに適用するためにいくつかの試行が必要になる場合があります。
回避策: 構成の更新を再試行すると、障害リカバリ・コードに組み込まれます。 管理者アクションは必要ありません。 最終的に構成が正常に変更されることが予想されます。
または、レプリケーション・ターゲットの更新の失敗が永続的な場合は、障害リカバリ設定を破棄して再作成する必要があります。 これには、両方のシステムからすべてのDR構成を削除すること、両方のシステムの障害リカバリ・サービスを削除すること、両方のラックの障害リカバリ・サービスを新しいIPで再作成すること、およびすべてのDR構成を再作成することが含まれます。
バグ: 34773761
バージョン: 3.0.2