機械翻訳について

第3章 既知の問題と回避策

目次

この章では、Oracle Private Cloud Applianceの既知の問題と回避策について説明します。 カテゴリごとに別々のセクションで表示されるため、より簡単にナビゲートできます。

3.1 プラットフォームの問題

このセクションでは、アプライアンス・プラットフォーム・レイヤーに関連する既知の問題と回避策について説明します。

3.1.1 コンピュート・ノードのプロビジョニングに長時間かかる

新しいコンピュート・ノードのプロビジョニングには、通常わずか数分かかります。 ただし、プロセスの期間に悪影響を与える可能性のあるファクタがいくつかあります。 たとえば、管理ノードが負荷が高い場合や、プロビジョニングに関係するプラットフォーム・サービスがビジーであるか、ホスト間で移行している可能性があります。 また、複数のコンピュート・ノードのプロビジョニングを連続して開始した場合は、これらのプロセスはパラレルではなく、1つずつ実行されることに注意してください。

回避策: エラーが表示されていないかぎり、コンピュート・ノードのプロビジョニング・プロセスはまだ進行中であり、最終的に完了すると想定する必要があります。 この時点で、コンピュート・ノードのプロビジョニング状態が「プロビジョニング済」に変わります。

バグ: 33519372

バージョン: 3.0.1

3.1.2 アプライアンス・ネットワーク環境の再構成の権限がありません

初期システム設定を完了したばかりで、ラック外部接続のネットワーク環境パラメータを変更しようとすると、これらの変更を行う権限がないため、コマンドは拒否されます。 これはセキュリティ機能によって発生します: 初期システム設定の権限は、これらの特定の設定操作のみに制限されます。 サービス・エンクレーブへのアクセスが制限されていない管理者であっても、最初のシステム設定後に切断し、再度ログインして、アカウントに関連付けられたすべての権限をアクティブ化する必要があります。

回避策: この動作は予期され、不正アクセスから保護できるように設計されています。 初期システム設定の直後にアプライアンスの外部ネットワーク構成を変更する必要がある場合は、ログアウトしてから再度ログインして、セッションが必要な権限で起動していることを確認します。

バグ: 33535069

バージョン: 3.0.1

3.1.3 管理ノードから使用可能なコンピュート・イメージをリストできません

アプライアンスにはコンピュート・イメージのセットが用意されています。 3つの管理ノードの共有ストレージに格納され、webサーバーを介してダウンロードおよびインポートできるようになります。 イメージを取得するには、webサーバーのアドレスとイメージの正確な名前が必要です。 残念ながら、イメージ・ディレクトリに格納されているファイルをリストするために、権限のあるアプライアンス管理者のみがOracle Linuxコマンドラインにアクセスできます。 テナンシ・ユーザーが管理ノードのwebサーバーからイメージを取得できるように、次の回避策が用意されています。 システムにパッチ適用またはアップグレードを行うと、イメージ・ディレクトリの内容が時間とともに変わることがあります。

回避策: 管理ノードで実行されているwebサーバーからコンピュート・イメージを取得するには、次のURL構文を使用します。 不明な場合は、管理ノード・クラスタの仮想IPに関連付けられたホスト名(<mgmt_vip_hostname>)を指定するようにアプライアンス管理者に依頼してください。 

URL syntax:
https://<mgmt_vip_hostname>.<system_name>.<domain_name>:8079/images/<image_file_name>

Example:
https://manager.myprivatecloud.example.com:8079/images/uln-pca-Oracle-Linux-8-2022.01.12_0.oci

ダウンロード可能なコンピュート・イメージは、管理ノードの共有ストレージに格納されます。 ダウンロードURLを構成するために必要なイメージ・ファイル名は次のとおりです。 

uln-pca-Oracle-Linux-7.9-2022.01.12_0.oci
uln-pca-Oracle-Linux-8-2022.01.12_0.oci
uln-pca-Oracle-Solaris-11.4.35-2021.09.20_0.oci

バグ: 33765086

バージョン: 3.0.1

3.1.4 Grafanaサービス統計情報はゼロのまま

Grafana Service Monitoringフォルダには、Service Levelという名前のダッシュボードが含まれます。このダッシュボードには、基本的なアプライアンス・サービスによって受信されたリクエストに関する統計情報が表示されます。 このダッシュボードでモニターされるサービスに関連するアクティビティがある場合でも、これらの数値はゼロのままです。

回避策: 回避策は現在使用できません。

バグ: 33535885

バージョン: 3.0.1

3.1.5 Terraformバージョン4.51.0以降、プロビジョニングには追加のオーバーライドが必要です

Oracle Private Cloud Applianceと組み合せてTerraformを使用してインフラストラクチャ・プロビジョニングを自動化するには、特定の変数をオーバーライドする必要があります。 ただし、使用するTerraformのバージョンによって、オーバーライドする変数は異なります。

4.50.0までのTerraformバージョンの場合:

export domain_name_override=<your_appliance_domain>
export custom_cert_location=<path_to_certificate>

Terraformバージョン4.51.0以降の場合:

export domain_name_override=<your_appliance_domain>
export custom_cert_location=<path_to_certificate>
export OCI_DEFAULT_REALM=<your_appliance_name>

オブジェクト・ストレージ・サービスのデフォルト・レルム変数はオーバーライドしないでください。

回避策: 環境およびTerraformプロバイダのバージョンに対して正しい変数をエクスポートしていることを確認します。

バグ: 33579632

バージョン: 3.0.1

3.1.6 ハードウェア・データの同期によりプロビジョニング・ノードがプロビジョニング準備完了に表示される

サービスWeb UIとサービスCLIの両方に、ハードウェア・コンポーネントに関する情報を、内部ハードウェア管理サービスによって現在登録されている実際のステータスと同期するコマンドが用意されています。 ただし、ステータスの変更が自動的に検出されて通信されるため、通常の状況ではハードウェアのステータスを同期する必要はありません。

さらに、ハードウェア・データの同期時にコンピュート・ノードのプロビジョニング操作が進行中の場合、プロビジョニングの状態を「プロビジョニング準備完了」に戻すことができます。 この情報は正しくなく、プロビジョニング・コマンドの後すぐにハードウェア同期が発生したため発生します。 この場合、コンピュート・ノードを再度プロビジョニングしようとすると、問題が発生する可能性があります。

回避策: コンピュート・ノードのプロビジョニングを開始していて、そのプロビジョニングの状態がプロビジョニングの場合は、少なくとも5分待ってプロビジョニング済に変更されるかどうかを確認します。 コンピュート・ノードが「プロビジョニング済」として一覧表示されるのに非常に長い時間がかかる場合は、ハードウェア・データの同期コマンドを実行します。

バグ: 33575736

バージョン: 3.0.1

3.1.7 ストレージ・コントローラのラックの高さが表示されない

サービスWeb UIでは、ラック・ユニット・リストには、基本ステータス情報を含むすべてのハードウェア・コンポーネントが表示されます。 データ・フィールドの1つは「ラック高さ」で、問題のコンポーネントが取り付けられているラック・ユニット番号です。 ZFSストレージ・アプライアンスのコントローラpcasn02の場合、ラックの高さは「使用不可」と表示されます。

回避策: 回避策はありません。 現在、基盤となるハードウェア管理サービスはこの特定のデータ・フィールドに移入されません。 2つのコントローラはそれぞれ2ラック・ユニットを占有し、RU 1-4に取り付けます。

バグ: 33609276

バージョン: 3.0.1

3.1.8 拡張機能に使用されるフリー・フォーム・タグ

特定のOracle Private Cloud Applianceクラウド・サービスでは、フリー・フォーム・タグを使用して基本機能を拡張します。 具体的には、次のタグが使用されています。

  • PCA_no_lm

    Computeサービスでは、このフリー・フォーム・タグを使用して、インスタンスがライブ移行されないようにします。 このメカニズムは、Windowsクラスタリングの場合など、特定のタイプのインスタンスでライブ移行によって問題が発生しないようにすることを目的としています。

  • PCA_volume_blocksize

    Block Storageサービスでは、このフリー・フォーム・タグを使用して、ZFSストレージ・アプライアンスに特定のブロック・サイズで新しいボリュームを作成するように指示します。 ボリュームの作成後は、ブロック・サイズを変更できません。

    デフォルトのブロック・サイズは8192バイトです。 タグ‘{“PCA_blocksize”: “<value>"}'を適用して、異なるブロック・サイズを指定します。 サポートされている値は、512から1Mバイトまでの2の累乗で、文字列として指定され、完全に展開されます。

これらのタグは、ユーザー・タグ制限に対してカウントされます。

回避策: ユーザー定義のフリー・フォーム・タグが、ここに記載のものと競合しないようにしてください。

バグ: 33647286

バージョン: 3.0.1

3.1.9 インポートされたイメージが高パフォーマンス・プールと同期されていません

デフォルトのストレージ構成を持つOracle Private Cloud Applianceでは、コンピュート・イメージをインポートすると、標準ZFSプール内のimages LUNのZFSストレージ・アプライアンスに格納されます。 ストレージ構成があとで高性能ディスク・シェルフで拡張された場合、ZFSストレージ・アプライアンスで高パフォーマンスのZFSプールが構成されます。 ストレージ・プール間にレプリケーションがないため、元のプールのイメージは新しい高パフォーマンス・プールで自動的に使用可能になりません。 イメージは手動でインポートする必要があります。

回避策: 高パフォーマンスなストレージ・シェルフをアプライアンス構成に追加するときに、必要なコンピュート・イメージを再度インポートして、新しく作成されたZFSプールにロードされるようにします。

バグ: 33660897

バージョン: 3.0.1

3.1.10 管理ノードの再起動後のAPIサーバー障害

3つの管理ノードのいずれかが再起動されると、クラスタ内の他の2つの管理ノードを介してアクセスできても、APIサーバーがリクエストに応答しないことがあります。 これは、管理ノード間で共有される仮想IPの所有権の問題、またはDNSサーバーが、使用可能な管理ノード上のサービス・ポッドにトラフィックをルーティングするのに十分な速さで応答しないことが原因である可能性があります。 再起動された管理ノードがクラスタに再参加した後も、APIサーバーが正常な動作状態に戻り、リクエストを再度受け入れるまでに数分かかる場合があります。

回避策: 1つの管理ノードが再起動すると、すべてのサービスは最終的に通常の動作状態にリストアされますが、それらのポッドは管理ノード・クラスタ間で異なる方法で分散される場合があります。 管理ノードの再起動後にUI、CLIまたはAPI操作が失敗した場合は、5分から10分待ってから再試行してください。

バグ: 33191011

バージョン: 3.0.1

3.1.11 ストレージ・コントローラのフェイルオーバー後にマイクロサービス・ポッドが応答しない

ZFSストレージ・アプライアンスのコントローラ間でフェイルオーバーまたはフェイルバックが発生すると、管理ノードにマウントされたNFS共有またはKubernetesマイクロサービス・ポッドが応答しなくなる可能性があります。 ストレージ・リソースの数およびI/O負荷が高いほど、マウントされたNFS共有が応答しなくなるリスクが高くなります。 サービスは、ポッドが応答しない共有によって管理ノードで実行されると影響を受けます。

NFSファイル・システムをアンマウントおよび再マウントしようとしないでください。古いファイル・ハンドルが生成され、リカバリが大幅に困難になります。 適切なリカバリ・プロセスは、応答しない共有がある管理ノードを識別し、NFSトラフィックに使用されるネットワーク接続を再起動し、サービス・ポッドを監視して、それらが自動的にリストアされるか手動でリストアされるかを確認することです。

回避策: アプライアンス管理者は、この問題の診断および解決に必要な操作の実行を許可されていません。 Oracle Supportに連絡して支援を依頼してください。

バグ: 33495030

バージョン: 3.0.1

3.1.12 承認グループの管理者(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

3.2 ユーザー・インタフェースの問題

このセクションでは、グラフィカル・ユーザー・インタフェースに関連する既知の問題と回避策について説明します。

3.2.1 コンパートメント間でのリソースの移動はコンピュートWeb UIではサポートされません

Compute Web UIでは、リソースをあるコンパートメントから別のコンパートメントに移動する機能は提供されません。 クラウド・リソースが存在するコンパートメントを変更する操作は、CLIでのみ実行できます。 ただし、すべてのリソース・タイプでコンパートメントの変更がサポートされるわけではありません。 たとえば、どのネットワーク・リソースも移動できません。

回避策: リソースを現在のコンパートメントから別のコンパートメントに移動する必要がある場合は、CLIを使用します。 CLIコマンドが正常に実行されると、Compute Web UIに結果の変更が表示されます。

バグ: 33038606

バージョン: 3.0.1

3.2.2 インスタンス・プールを更新するために使用可能なコンピュートWeb UI操作がありません

コンピュートWeb UIには、既存のインスタンス・プールのプロパティを更新する機能がありません。 UpdateInstancePoolおよびUpdateInstancePoolDetails APIリソースのユーザー・インタフェース実装はありません。

回避策: CLIを使用してインスタンス・プールを更新します。 このコマンドを使用します: 

oci compute-management instance-pool update [OPTIONS]

バグ: 33393214

バージョン: 3.0.1

3.2.3 変更なしでリソース・プロパティを保存すると、ステータスがプロビジョニングに簡単に変更されます

コンピュートWeb UIで編集ダイアログ・ボックスを開いてリソースのプロパティを変更し、プロパティを実際に変更せずに変更の保存をクリックすると、リソースのステータスが「プロビジョニング」に数秒間変更されます。 これは、保存ボタンをクリックしたユーザーに対してUIの通常のレスポンスです。 副作用はありません。

回避策: リソース・ステータスが変更されていない場合にプロビジョニングに変更されないようにするには、かわりにダイアログ・ボックスの取消ボタンをクリックします。

バグ: 33445209

バージョン: 3.0.1

3.2.4 手動リフレッシュまでリソース名変更が表示されません

Compute Web UIでリソースの表示名を変更すると、画面上で自動的にリフレッシュされないことがあります。 一部のリソースでは、手動リフレッシュ・ボタンをクリックした後にのみ、名前の変更が表示されます。

回避策: リソース名の変更が自動的にUIに反映されない場合は、リフレッシュ・ボタンをクリックしてウィンドウの内容を手動でリフレッシュします。

バグ: 33467585

バージョン: 3.0.1

3.2.5 NFSエクスポート・スカッシュIDが表示されない

Compute Web UIでは、NFSエクスポートの詳細ページにNFSエクスポート・オプションのスカッシュIDが表示されません。 NFSエクスポートへの匿名アクセスにはスカッシュIDが必要ですが、取得できるのはエクスポート・オプションの編集のみです。

回避策: NFSエクスポートのスカッシュIDを取得するには、NFSエクスポート詳細ページに移動し、NFSエクスポート・オプションまで下にスクロールし、オプションの編集をクリックします。 または、CLIからエクスポート・オプションを検索します。

バグ: 33480572

バージョン: 3.0.1

3.2.6 ブラウザに表示されないスクロール・バー

Oracle Private Cloud Applianceのブラウザベースのインタフェースは、Oracle JavaScript Extension Toolkitを使用して構築され、Oracle社の設計ガイドラインに従います。 スクロール・バーは、指定したスペース内にコンテンツが収まらない画面の一部をアクティブに使用していないかぎり、非表示のままにしておくことを目的としています。 - たとえば: 大きな表、長いドロップダウン・リストなど。 すべてのブラウザまたはブラウザ・バージョンに、意図した方法でスクロール・バーが表示されるわけではありません。 たとえば、Google Chromeは通常意図したとおりにスクロール・バーを非表示にしますが、Mozilla Firefoxはスクロール・バーを非表示にしません。

回避策: スクロール・バーの動作は設計です。 コンピュートWeb UIとサービスWeb UIの両方に適用されます。 割り当てられた画面領域を超えてコンテンツが実行される領域では、問題のコンテンツの上にカーソルを置くと、適切な場所にスクロール・バーが自動的に表示されます。

バグ: 33489195

バージョン: 3.0.1

3.2.7 コンパートメント・データの取得時の認可の失敗

Identity and Access Managementサービスを使用すると、ポリシーを介してリソースへのユーザー・アクセス権限を細かく制御できます。 これらのポリシーは、特定のタイプのリソースに対して、または特定のコンパートメントに存在するリソースに対して、ユーザー・グループが実行する権限がある操作を決定します。 状況によっては、コンピュートWeb UIで、ユーザーがアクセスできないすべてのリソースを非表示にできないことがあります。 その結果、ユーザー操作によって、アカウントがアクセスを許可されていないデータのリクエストが発生する可能性があります。

Compute Web UIの使用中に、権限のないデータの取得が操作によってトリガーされた場合に認可失敗に至る場合があります。 この場合、ブラウザにエラーが表示され、アカウント権限のためにアプリケーションが動作を停止したことが示されます。 コンパートメント・ツリーでは、アクセスが許可されていないコンパートメントを表示できるため、特に、このタイプの失敗が発生しやすくなります。

回避策: コンパートメント・ツリー・アクセスの問題によってエラーが発生した場合は、再試行をクリックすると、意図したページが表示されます。 それ以外の場合は、テナンシ管理者に連絡して、必要なデータにアクセスするための追加の権限をリクエストしてください。

バグ: 33497526

バージョン: 3.0.1

3.2.8 オブジェクト・リストは自動更新されません

Compute Web UIでは、バケットに格納されているオブジェクトを、そのディレクトリ構造内で参照して表示します。 オブジェクトのリストまたは表は定期的に自動的にリフレッシュされないため、オブジェクトの変更は、手動でページをリフレッシュしたときにのみ表示されます。 UIがバケットのステータスをポーリングするために使用できる機能はありません。

回避策: コンピュートWeb UIでオブジェクトの現在のリストを表示するには、ページを手動でリフレッシュします。 この動作はオブジェクト・ストレージ・サービスに固有ではありません。UIの他の領域でも発生する可能性があります。 リソース・リストが定期的に自動的に更新されない場合は、手動でリフレッシュする必要があります。

バグ: 33519215

バージョン: 3.0.1

3.2.9 ファイル・ストレージ・マウント・ターゲット・リンクを使用できません

Compute Web UIのFile Storage領域では、次のようにマウント・ターゲットURLを検索できます: マウント・ターゲットのリストを表示し、目的のマウント・ターゲットを選択し、エクスポートをクリックして詳細ページを表示し、「マウント・ターゲット」フィールドを見つけます。 ただし、マウント・ターゲットが存在していても使用不可と表示されている場合があります。

回避策: UIは、常にファイル・システム・ストレージ・サービスからリソース詳細を取得できるとはかぎりません。 UIで詳細を再度取得するように強制するには、ページをリフレッシュするか、移動して戻ります。

バグ: 33571007

バージョン: 3.0.1

3.2.10 セキュリティ・リスト・ルール表に表示されないUDPポート

セキュリティ・リストに属するイングレス・ルールおよびエグレス・ルールは、セキュリティ・リスト詳細ページのリソース・セクションの表に表示されます。 UDPポートに関連するルールを作成する場合、ポート番号はポート範囲列に表示されません。 UDP設定は失われません。これらは編集ウィンドウで表示できます。

回避策: セキュリティ・リストの編集ウィンドウには、UDPポートを含むすべての関連する設定が表示されます。 イングレスまたはエグレス・ルールを変更するには、アクション・メニュー(行の右端)で編集を選択します。

バグ: 33575269

バージョン: 3.0.1

3.2.11 ドロップダウン・リストに表示されていないリソース

ドロップダウン・リストを使用してリソースを選択する必要がある場合、リストが非常に長いとすべてのアイテムが表示されるとはかぎりません。 リストをスクロールすると、より多くのアイテムがロードされますが、探しているアイテムが見つからない場合があります。 この動作の理由は、UIコンポーネントは、ロード時間が長いためにユーザーを遅くするのではなく、すばやく応答するように設計されています。 完全なアルファベット順リストをスクロールするのではなく、テキスト・フィールドにリソース名の一部を入力して、長いリストをフィルタすることをお薦めします。 これはOracle JavaScript Extension Toolkitの特性であるため、Compute Web UIとサービスWeb UIの両方に影響します。

回避策: スクロールは、長いドロップダウン・リストでアイテムを検索する優先方法ではありません。 代わりに、探しているリソースの名前を入力し始めると、使用可能なリスト・アイテムは、入力した内容に一致するものに縮小されます。

バグ: 33583708

バージョン: 3.0.1

3.2.12 アイデンティティ・プロバイダの説明が表示されません

サービスWeb UIでは、アイデンティティ・プロバイダの説明がアイデンティティ・プロバイダの詳細ページに表示されません。 ただし、アイデンティティ・プロバイダの作成時に説明を指定でき、アイデンティティ・プロバイダの編集時にも表示されます。

回避策: アイデンティティ・プロバイダの編集ウィンドウには、説明フィールドなど、関連するすべての設定が表示されます。 説明を表示するには、アイデンティティ・プロバイダの設定を変更する編集をクリックします。

バグ: 33585827

バージョン: 3.0.1

3.2.13 ボリューム・グループは名前なしで作成できます

Compute Web UIのブロック・ストレージ領域でボリューム・グループを作成する場合、名前を入力する必要はありません。 名前フィールドを空白のままにすると、ボリューム・グループは「名前なしアイテム」としてリストに表示されます。 ただし、CLIでボリューム・グループを作成するときに名前を指定しない場合、作成時間に基づいて名前が自動的に割り当てられます。

回避策: これはコードのバグではありません : この名前は技術的には必須パラメータではありません。 ボリューム・グループに意味のない名前を使用しないようにするには、作成時に適切な名前をCompute Web UIおよびCLIに指定してください。 名前を指定せずに誤ってボリューム・グループを作成した場合は、後でボリューム・グループを編集して、選択した名前を追加できます。

バグ: 33608462

バージョン: 3.0.1

3.2.14 ファイルシステムとマウント・ターゲットが表示されない

ユーザーが特定のコンパートメント内のリソースへのアクセス権を持ち、テナンシのルート・コンパートメントのコンテンツを表示する権限がない場合、コンピュートWeb UIには、ユーザーがリストできるリソースが表示されない場合があります。 代わりに、承認エラーが表示されます。 特にファイル・システム・サービスでは、ユーザーがそのコンパートメントおよびそれに含まれるリソースへのフル・アクセス権を持っている場合でも、特定のコンパートメント内のファイル・システムまたはマウント・ターゲットは表示されません。

この動作は、ルート・コンパートメントのOCIDを使用して、UIからAPIリクエストが行われる方法によって発生します。 対照的に、CLIでは、リクエストされたリソースを効果的に格納するコンパートメントのOCIDを指定する必要があるため、UIと同じ認可問題の影響を受けません。

回避策: テナンシ管理者は、ファイル・システム・サービスのユーザーがルート・コンパートメントに対する読取りアクセス権を持っていることを確認する必要があります。 ユーザーが使用を許可されているファイル・システムおよびマウント・ターゲットをリストできないユーザーは、テナンシ管理者に、アカウント権限を確認して必要な調整を行うように依頼する必要があります。

バグ: 33666365

バージョン: 3.0.1

3.2.15 1970年初日にジョブが終了したことを示すタイム・スタンプ

サービスWeb UIでは、ジョブのリストを表示し、ジョブ名をクリックして詳細ページを表示できます。 ジョブ表とジョブの詳細ページの両方で、タイム・ゾーンによっては、ジョブ終了日が1969年12月31日または1970年1月1日として表示される場合があります。 ジョブ・タイプによっては、ジョブが正常に完了したときに正しい終了日が表示されます。 ただし、このような特定のケースでは、ジョブが成功したか失敗したかに関係なく、誤ったジョブ・エンド・タイム・スタンプが保持されます: インスタンスをコンピュート・ノードから離れ、テナンシを削除する場合。

回避策: 正しいジョブ・エンド・タイム・スタンプを取得する回避策はありません。 ジョブ終了が1969年12月31日または1970年1月1日に設定されている場合は、エラーを無視してください。 ジョブの状態 - 成功または失敗 - 正しく表示されます。

バグ: 33582003

バージョン: 3.0.1

3.2.16 オプションのICMPセキュリティ・ルール・パラメータは削除できません

VCNのセキュリティ・リストにイングレスまたはエグレス・セキュリティ・ルールを追加すると、ICMPプロトコルを特に選択できます。 Compute Web UIは、それぞれのリストから「パラメータ・タイプ」および「パラメータ・コード」を選択することがオプションであることを示します。 パラメータ・タイプはICMPルールに必須であるため、これは正しくありません。

ICMPルールでタイプとコードの両方を指定した場合、パラメータ・コードを削除できます。 セキュリティ・ルールを編集し、コード・テキスト・フィールドにカーソルを置き、そのコンテンツを削除します。 これは、UIでのドロップダウン・リストの仕組みです。選択する"empty"オプションはありません。

回避策: ICMPセキュリティ・ルールを使用する場合は、常にパラメータ・タイプを指定します。 ドロップダウン・リストから選択したオプション・パラメータを削除するには、テキスト・フィールドのコンテンツを選択して削除します。

バグ: 33631794

バージョン: 3.0.1

3.2.17 DHCPオプションの作成時にコンパートメント・セレクタを使用できません

Compute Web UIを介してVCNのDHCPオプションを作成または変更する場合、DHCPオプションを別のコンパートメントに追加する方法はありません。 コンパートメント・セレクタは作成および編集ウィンドウで使用できないため、DHCPオプションはVCN自体と同じコンパートメントに暗黙的に格納されます。 ただし、DHCPオプションを別のコンパートメントに格納することはサポートされています。 その場合は、CLIを使用してください。

回避策: DHCPオプションを、適用するVCNとは異なるコンパートメントに格納する場合、CLIを通じてDHCPオプションを作成するか、CLIを使用してそれらを目的のコンパートメントに移動します。

バグ: 33722013

バージョン: 3.0.1

3.2.18 プライマリ管理アカウントの設定後にアプライアンスの初期構成ウィザードがハングアップする

「Oracle Private Cloud Applianceインストレーション・ガイド」には、「アプライアンスの初期設定」をガイドするステップごとの手順が記載されています。 プライマリ管理アカウントを作成した後、新しく作成したアカウントでサインインする前にブラウザ・ウィンドウをリフレッシュするように指示されます。 ただし、ブラウザをリフレッシュしても十分ではありません。 初期構成ウィザードに進むと、設定の保存を妨げるエラーが発生します。

回避策: プライマリ管理アカウントの設定時にブラウザをリフレッシュするかわりに、ブラウザを閉じて再度開きます。 初期構成ウィザードに戻り、作成した管理者アカウントでサインインします。 必要な設定を適用してウィザードを完了できるようになりました。

バグ: 33774118

バージョン: 3.0.1

3.2.19 サービスWeb UIにより適用されないアップリンクVLAN制限

サービスWeb UIでアプライアンスの初期設定手順を実行する場合は、論理接続またはルーティング・タイプを選択してネットワーク構成を開始します。 静的ルーティングでアップリンクを構成する場合は、このトラフィックをVLAN経由で送信することを選択できます。 ただし、サービスWeb UIでは、入力したVLAN IDがサポートされている値が検証されません。 そうでない場合、無効なパラメータが原因で操作が失敗し、エラーが返されます。

回避策: データ・センターへのアプライアンス・アップリンクに対して静的ルーティングを選択し、VLANを構成する必要がある場合は、初期インストール・チェックリストおよびネットワーク・インフラストラクチャの概念に記載されているように、サポートされている2-3899の範囲内のIDを使用してください。

バグ: 33805854

バージョン: 3.0.1

3.2.20 オペレーションが取消された場合、カスタム検索ドメイン・エラーはロールバックされません

ネットワーキング・サービスでは、VCNおよびサブネットのレベルでDHCPオプションを設定することで、特定のインスタンス・ブート構成パラメータを制御できます。 制御できるDHCPオプションの1つは検索ドメインであり、DNS対応VCNおよびサブネットのインスタンスFQDNに自動的に追加されます。

検索ドメインは、example.tldの形式で指定する必要があります - TLDは最上位ドメインを表します。 無効な検索ドメインを保存しようとすると、2つのエラー・メッセージが表示されます: 「ドメインの検索」フィールドのすぐ下に表示され、DHCPオプション・ウィンドウの下部に「一部のフィールドが不完全または無効です」と表示されます。 DHCPオプションの作成または変更を取り消して、DHCPオプション・ウィンドウを再度開くと、設定が適用されていなくても、エラー・メッセージおよび誤った値が引き続き表示されることがあります。

回避策: 新しい設定の保存に失敗した後にDHCPオプション・ウィンドウを閉じ、再度開くと、同じエラー・メッセージと無効な値が引き続き表示される場合は、エラーを無視できます。 ブラウザ・ウィンドウをリフレッシュすると、エラー・メッセージがクリアされることがあります。 必要なフォーマットでカスタム検索ドメインを入力します: example.tld

バグ: 33734400

バージョン: 3.0.1

3.2.21 カスタム検索ドメインのDHCPオプション・エラー・メッセージが誤解しています

ネットワーキング・サービスでは、VCNおよびサブネットのレベルでDHCPオプションを設定することで、特定のインスタンス・ブート構成パラメータを制御できます。 制御できるDHCPオプションの1つは検索ドメインであり、DNS対応VCNおよびサブネットのインスタンスFQDNに自動的に追加されます。

検索ドメインは、example.tldの形式で指定する必要があります - TLDは最上位ドメインを表します。 ただし、Compute Web UIはこのパラメータを検証しません。これは、DHCPオプションを保存するときにNetworkingサービスによって実行されます。 Compute Web UIは、値にスペースが含まれていないことを確認します。 その場合、「ドメインの検索」フィールドにエラー・メッセージが表示されます: "example.tldの形式である必要があります"。 これは、値がスペースを含むことを示しているだけであるため、技術的には不正確です。

回避策: 必要なフォーマットでカスタム検索ドメインを入力します : example.tld。 ドメイン名にスペースは使用できません。 問題のエラー・メッセージが表示された場合は、「ドメインの検索」フィールドに入力した値を修正し、DHCPオプションの保存を再試行してください。

バグ: 33753758

バージョン: 3.0.1

3.2.22 コンピュート・ノード・プロビジョニング状態がサービスWeb UIで自動的にリフレッシュされない

サービスWeb UIには、「ラック・ユニット」表と各コンピュート・ノードの詳細ページの両方に、コンピュート・ノードの「プロビジョニング状態」が表示されます。 ただし、コンピュート・ノードをプロビジョニングする準備ができ、UIからプロビジョニング・コマンドを実行すると、状態変更を表示するためにコンピュート・ノードの詳細ページが自動的にリフレッシュされません。

回避策: サービスWeb UIの詳細ページからコンピュート・ノードをプロビジョニングする場合、ブラウザ・ページを手動でリフレッシュして、コンピュート・ノードの状態を追跡し、プロビジョニングの完了を確認します。

バグ: 33817224

バージョン: 3.0.1

3.3 ネットワーク接続に関する問題

この項では、アプライアンス・ネットワーキングのすべての側面に関連する既知の問題と回避策について説明します。これは、システム内部接続、データ・センターへの外部アップリンク、およびユーザーのコンピュート・インスタンスの仮想ネットワーキングです。

3.3.1 DNSレコードを更新するには、コマンドに既存の保護されたレコードを含める必要がある

DNSレコードを更新する場合、更新がこれらのレコードに影響を及ぼさない場合でも、既存のすべての保護レコードを更新コマンドに含める必要があります。 この要件は、既存の保護されたレコードが誤って削除されないようにすることを目的としています。 ただし、特定の更新の実現が困難なSOAレコードについては、チェックが非常に制限されています。

回避策: コマンドの一部としてSOAレコードを指定するか、SOAドメインを含めないようにドメインを設定することで、既存のレコードを更新できます。 実際には、ほとんどのレコード更新は上位レベルで行われ、これらの制限の影響を受けません。

バグ: 33089111

バージョン: 3.0.1

3.3.2 混乱しているエラー・メッセージでルート表の作成に失敗

ルート表を作成し、ルート・ルール・パラメータに誤りがある場合、APIサーバーは誤解を招くエラー・メッセージを返すことがあります。 特定のメッセージが読み取る: " 「ルート表ターゲットは、LPG、NATゲートウェイ、インターネット・ゲートウェイ、DRGアタッチメントまたはサービス・ゲートウェイのいずれかである必要があります。」 "可能なターゲットのリストで、DRGアタッチメントが正しくありません。 動的ルーティング・ゲートウェイ自体は、DRGアタッチメントではなくターゲットとして指定する必要があります。

回避策: 問題のエラー・メッセージは無視します。 動的ルーティング・ゲートウェイを介してトラフィックを送信するようにルート・ルールを構成する場合は、DRGをターゲットとして指定します。

バグ: 33570320

バージョン: 3.0.1

3.3.3 VCN作成で非推奨のパラメータを使用

VCNを作成する場合は、通常、対象となるCIDR範囲を指定します。 Compute Web UIでは、これを該当するフィールドに入力します。 ただし、CLIには2つのコマンド・パラメータが用意されています: --cidr-blockは非推奨となり、--cidr-blocksは非推奨となった新しいパラメータです。 OCI CLIをOracle Private Cloud Applianceとともに使用する場合は、--cidr-blockを使用する必要があります。 新しいパラメータはAPIサーバーでサポートされていません。

回避策: 非推奨パラメータに関する警告メッセージは無視します。 VCNで使用されるCIDR範囲を指定する場合は、--cidr-blockパラメータを使用します。

バグ: 33620672

バージョン: 3.0.1

3.3.4 セキュリティ・ルールによってブロックされたファイル・ストレージ・トラフィック

ユーザーがインスタンスにファイル・システムをマウントできるようにするには、マウント・ターゲットとインスタンス間の必要なネットワーク・トラフィックを許可するために、デフォルト・セキュリティ・リスト内のものに加えてセキュリティ・ルールを構成する必要があります。 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

3.3.5 ステートフルおよびステートレス・セキュリティ・ルールは結合できません

アプライアンスでは、テナンシ内のステートフル・セキュリティ・ルールとステートレス・セキュリティ・ルールの組合せを構成できます。 これらのセキュリティ・ルールから生成されたアクセス制御リストは正しいですが、仮想アンダー・レイ・ネットワークのバグによって間違った解釈が発生します。 その結果、特定のトラフィックがブロックされるか、誤って許可される可能性があります。 したがって、ステートフルまたはステートレスのセキュリティ・ルールのいずれかを使用する必要があります。

回避策: すべてのステートフルまたはステートレスのセキュリティ・ルールを作成します。 両方のタイプの混在はサポートされていません。

バグ: 33744232

バージョン: 3.0.1

3.3.6 同じサイズの単一サブネットを持つ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

3.3.7 システムの初期化中にCIDRとして構成されたパブリックIPでのルーティングの失敗

アプライアンスで「初期設定手順」を完了すると、最後のステップの1つは、パブリックIPとしてクラウド・リソースに割り当てられるデータ・センターIPアドレスを定義することです。 BGPベースの動的ルーティングを選択した場合、パブリックIPは1つ以上のCIDRとして定義されているときに正しく通知されないため、アプライアンスの外部から到達できないことがあります。

回避策: クラウド・リソースのパブリックIPをアプライアンスの外部から確実に到達できるようにするには、すべてのIPアドレスを /32ネットマスクで個別に指定します。 たとえば、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

3.4 コンピュート・サービスの問題

この項では、コンピュート・サービスに関連する既知の問題および回避策について説明します。

3.4.1 ブロック・ボリュームに接続するための一貫性のあるデバイス・パスがありません

ブロック・ボリュームをインスタンスにアタッチするときには、インスタンス・リブート間で一貫性を保つデバイス・パスを指定することはできません。 つまり、attach-paravirtualized-volume CLIコマンドの場合、オプションの--deviceパラメータは機能しません。 インスタンスの再起動後にデバイス名が異なる場合があるため、これは、パーティション化、ファイル・システムの作成およびマウントなど、ボリュームで実行するタスクに影響します。

回避策: 回避策はありません。

バグ: 32561299

バージョン: 3.0.1

3.4.2 開始またはスケーリング中にインスタンス・プールを終了できません

プール内のインスタンスが起動中であり、プール内のインスタンスの数を増減するスケーリング操作の進行中は、インスタンス・プールを終了できません。 一方、個々のインスタンスはいつでも終了できます。

回避策: インスタンス・プールを終了するには、すべてのインスタンスの起動またはスケーリング操作が完了するまで待機します。 その後、インスタンス・プール全体を正常に終了できます。

バグ: 33038853

バージョン: 3.0.1

3.4.3 Windowsのネットワーク・インタフェースはDHCPサーバーからのMTU設定を受け入れません

インスタンスが起動されると、DHCPを介してIPアドレスがリクエストされます。 DHCPサーバーからのレスポンスには、VNIC最大転送単位(MTU)を9000バイトに設定する手順が含まれています。 ただし、Windowsインスタンスは1500バイトのMTUを使用して起動するため、ネットワーク・パフォーマンスに悪影響を及ぼす可能性があります。

回避策: インスタンスにDHCPサーバーによって初期IPアドレスが割り当てられた場合、インタフェースMTUを適切な値(通常、インスタンスのプライマリVNICの9000バイト)に手動で変更します。 この新しい値は、ネットワーク切断およびDHCPリース更新で保持されます。

または、WindowsイメージにMTUPluginを含むcloudbase-initが含まれている場合、DHCPからインタフェースMTUを設定できます。 この機能を有効にするには、次のステップを実行します。

  1. ファイルC:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confを編集します。 次の行を追加します。 

    mtu_use_dhcp_config=true
plugins=cloudbaseinit.plugins.common.mtu.MTUPlugin

  2. コマンドRestart-Service cloudbase-initを入力します。

  3. MTU設定が変更されたことを確認します。 このコマンドを使用: netsh interface ipv4 show subinterfaces。

バグ: 33541806

バージョン: 3.0.1

3.4.4 同じコンピュート・ノードからの同時インスタンス移行はサポートされていません

システムでは、すべてのコンピュート・インスタンスを特定のコンピュート・ノードから複数回移行するプロセスを妨げません。 そのため、インスタンスが正常に移行された可能性が高い場合でも、これらの移行ジョブで障害が報告されます。

回避策: 特定のコンピュート・ノードからコンピュート・インスタンスの移行を開始した後、前の移行ジョブが完了したことを確認しないかぎり、同じコマンドを再度実行しようとしないでください。

バグ: 33582029

バージョン: 3.0.1

3.4.5 バックアップからのリストア後のメンテナンス・モードのSolarisインスタンス

既存のインスタンスのブート・ボリュームのバックアップから新しいインスタンスを作成することはサポートされています。 既存のインスタンスが実行中または停止している可能性があります。 ただし、Oracle Private Cloud Applianceで提供されるOracle Solarisイメージに基づいてインスタンスのブート・ボリューム・バックアップを使用する場合、そのバックアップから作成された新しいインスタンスはメンテナンス・モードで起動されます。 Oracle Solarisコンソールにこのメッセージが表示されます : " システム・メンテナンス(バイパスするにはcontrol-d)のユーザー名を入力してください: "

回避策: ブロック・ボリューム・バックアップから作成された新しいOracle Solarisインスタンスがメンテナンス・モードで起動したら、コンピュートWeb UIまたはCLIからインスタンスを再起動します。 この再起動後、インスタンスは通常の実行状態に戻り、そのネットワーク・インタフェースを介して到達可能です。

バグ: 33581118

バージョン: 3.0.1

3.4.6 コンピュート・ノード・メトリックに表示されないインスタンス・ディスク・アクティビティ

コンピュート・インスタンスにアタッチされた仮想ディスクは、ホスト・コンピュート・ノードのハイパーバイザを介してゲストに表示されます。 そのため、インスタンスのディスクI/Oは物理ホストのレベルで検出され、Grafanaのコンピュート・ノードのディスク統計に反映されます。 残念ながら、仮想ディスク上のアクティビティは、コンピュート・ノードのディスク・メトリックに集約されません。

回避策: コンピュート・ノード・メトリックを分析するのではなく、インスタンス・ディスクI/Oおよび各コンピュート・ノードでの集計済ロードをモニターするには、Grafanaを通じて表示される個々のVM統計を使用します。

バグ: 33551814

バージョン: 3.0.1

3.4.7 Oracle Solarisインスタンス内にアタッチされたブロック・ボリュームが表示されない

実行中のOracle Solarisコンピュート・インスタンスに追加のブロック・ボリュームをアタッチすると、それらはオペレーティング・システムに自動的に表示されません。 ディスクを手動で再スキャンした後でも、新しくアタッチされたブロック・ボリュームは非表示のままです。 この問題は、ハイパーバイザがゲストLUNを再列挙するための正しいイベント・トリガーを送信しないために発生します。

回避策: 追加のブロック・ボリュームをOracle Solarisコンピュート・インスタンスにアタッチする場合は、インスタンスを再起動して、新しい仮想ディスクまたはLUNが検出されたことを確認します。

バグ: 33581238

バージョン: 3.0.1

3.4.8 ホスト名が正常に起動されたWindowsインスタンスに設定されていません

DNSが有効になっているVCNおよびサブネットで作業しており、インスタンスを起動すると、ホスト名がインスタンスの表示名または指定したオプションのホスト名のいずれかと一致することが想定されます。 ただし、Windowsインスタンスを起動すると、起動コマンド・パラメータに従ってホスト名が正しく設定されていない可能性があります。 この場合、インスタンス完全修飾ドメイン名(FQDN)は想定どおりに解決され、機能低下はありません。 インスタンス自体のホスト名設定のみが正しくありません。VCN DNS構成は想定どおりに機能します。

回避策: インスタンス・ホスト名が指定されたインスタンス起動パラメータと一致しない場合は、インスタンス内のホスト名を手動で変更できます。 機能への影響はありません。

または、WindowsイメージにSetHostNamePluginを含むcloudbase-initが含まれている場合、インスタンスのFQDN (hostname-label)に基づいてインスタンス・ホスト名(「コンピュータ名」)を設定できます。 この機能を有効にするには、次のステップを実行します。

  1. ファイルC:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confを編集します。 次の設定を含む行が含まれていることを確認してください。 

    plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin
allow_reboot=true

  2. コマンドRestart-Service cloudbase-initを入力します。

  3. インスタンス・ホスト名が変更されたことを確認します。

バグ: 33736674

バージョン: 3.0.1

3.4.9 Oracle SolarisインスタンスがUEFI対話型シェルにスタックしている

管理ノードのwebサーバーを介して提供されたイメージからデプロイされたOracle Solaris 11.4コンピュート・インスタンスが、UEFI対話型シェルにスタックし、ブートに失敗していることがわかっています。 インスタンスがそのブート・シーケンスを完了しない場合、ユーザーはログインできません。 この問題は、テナンシへのインポート中に元の.ociイメージ・ファイルが破損したことが原因である可能性があります。

回避策: Oracle Solaris 11.4インスタンスがUEFIブート中にハングし、使用不可のままである場合は、次のように進めます。

  1. ブートに失敗したインスタンスを終了します。

  2. インポートしたOracle Solaris 11.4イメージを削除します。

  3. 管理ノードのwebサーバーからOracle Solaris 11.4イメージを再度インポートします。

  4. 新しくインポートされたイメージからインスタンスを起動し、完全にブートした後でログインできることを確認します。

バグ: 33736100

バージョン: 3.0.1

3.4.10 インスタンスの起動中にインスタンスのYum構成が上書きされる

Oracle Cloud Infrastructure用に構築されたOracle Linuxコンピュート・イメージには、インスタンスの起動時にyum構成でリポジトリURLを設定するメタデータ値があります。 これらのOracle LinuxイメージをOracle Private Cloud Applianceとともに使用すると、インスタンスのyum構成は、yum-null.oracle.comへの非機能リンクで上書きされます。

回避策: インスタンス内でyumを使用できるようにするには、構成を手動で修正する必要があります。 リブート後にyum構成が保持されるようにするには、ファイル/etc/yum/vars/ociregionに正しい値を設定します。

バグ: 33756673

バージョン: 3.0.1

3.5 ストレージ・サービスの問題

このセクションでは、内部ZFSストレージ・アプライアンスおよびさまざまなストレージ・サービスの機能に関連する既知の問題と回避策について説明します: ブロック・ボリューム・ストレージ、オブジェクト・ストレージおよびファイル・システム・ストレージ。

3.5.1 インスタンスからのイメージの作成に時間がかかる

インスタンスから新しいコンピュート・イメージを作成すると、そのブート・ボリュームは一連のコピーおよび変換操作を通過します。 また、仮想ディスク・コピーは非スパースであるため、フル・ディスク・サイズはビットごとにコピーされます。 その結果、イメージの作成時間は、ベース・インスタンスのブート・ボリュームのサイズによって大幅に増加します。

回避策: イメージ作成ジョブが完了するまで待機します。 Compute Web UIで作業リクエスト・ステータスを確認するか、作業リクエストIDを使用してCLIでそのステータスを確認します。

バグ: 33392755

バージョン: 3.0.1

3.5.2 ブロック・ボリューム・バックアップ・ポリシーでサポートされていないオフセット(秒)

ブロック・ボリュームのバックアップ・ポリシーを作成する場合は、バックアップを毎日、毎週、毎月または毎年行うかを指定します。 選択した頻度に応じて、月、日、曜日および時間も指定できます。 APIには、オフセットを指定するスケジュール・パラメータも用意されていますが、実装されていません。 そのため、この設定をバックアップが行われるZFSストレージ・アプライアンスに渡すことはできません。

回避策: ボリューム・バックアップ・ポリシーで時間を定義するには、時間のみを指定します。offsetSecondsパラメータはサポートされていません。

バグ: 33529592

バージョン: 3.0.1

3.5.3 オブジェクト・ストレージ・コマンドが認証エラーで失敗します

テナンシ内のユーザーは、様々なクラウド操作の認証および認可のために、プロファイルに最大3つのAPIキーを追加できます。 テナンシ内の各操作について、コマンドが実行されるかどうかを判断するためにIAMサービスが使用するAPIキーを使用して、コマンドがAPIサーバーに送信されます。 パフォーマンスを最適化するために、ZFSストレージ・アプライアンスは、受信したキーをオブジェクト・ストレージ・コマンドの一部としてユーザーOCIDとともにキャッシュします。 ユーザーが別のAPIキーで別のオブジェクト・ストレージ・コマンドを実行し、以前にキャッシュされたキーがまだ期限切れでない場合、別のキーが必要であるため、コマンドは認証エラーになります。

回避策: オブジェクト・ストレージ・サービスを操作する場合、プロファイルに複数のAPIキーを持つユーザーは、すべてのオブジェクト・ストレージ・コマンドに同じキーを使用する必要があります。 APIキーを切り替えるときは、キャッシュされたキーが期限切れになるまで、オブジェクト・ストレージ操作を実行しないでください。 コマンドによってキャッシュされたキーが触れるたびに、失敗しても、そのキーの存続期間が延長されます。

バグ: 33560908

バージョン: 3.0.1

3.5.4 オブジェクト・ストレージがTerraformと互換性がない

Oracle Private Cloud Applianceに実装されたObject Storageサービスは、現在、TerraformおよびOracle Cloud Infrastructure Go SDKと互換性がありません。

回避策: オブジェクト・ストレージでTerraformを使用するための回避策はありません。

バグ: 33654986

バージョン: 3.0.1

3.5.5 オブジェクト・ストレージ事前認証済リクエストREST構文エラー

ユーザーがAPIキーを指定せずにバケットにアクセスできるように事前認証済リクエストを作成するには、Oracle Cloud Infrastructure APIリファレンスでREST APIコールに次の構文を使用するように指示されます: POST /n/{namespaceName}/b/{bucketName}/p/。 この構文を使用すると、認証エラーが発生します。 Oracle Private Cloud Appliance APIサーバーは最後にスラッシュを受け入れないため、削除する必要があります。

回避策: 次のようにREST APIコマンドの書式を設定します: POST /n/{namespaceName}/b/{bucketName}/p。

バグ: 33540180

バージョン: 3.0.1

3.5.6 ZFSコントローラのフェイルオーバー後に大きなオブジェクト転送が失敗する

オブジェクト・ストレージ・バケットへの大きなファイルのアップロードまたはダウンロード中にZFSコントローラのフェイルオーバーまたはフェイルバックが発生した場合、接続が中断され、データ転送が失敗する可能性があります。 マルチパート・アップロードも同様に影響を受けます。 この問題は、短いストレージ接続タイムアウトの場合に再試行機能を提供しないバージョンのOCI CLIを使用している場合に発生します。 再試行機能は、バージョン3.0から使用できます。

回避策: 大きなオブジェクトおよびマルチパート・アップロードの信頼性の高い転送を行うには、OCI CLIバージョン3.0以降を使用します。

バグ: 33472317

バージョン: 3.0.1

3.5.7 100MiBより大きいオブジェクトのマルチパート・アップロードの使用

非常に大きなファイルをオブジェクト・ストレージにアップロードすると、接続やパフォーマンスの問題が発生する可能性があります。 オブジェクト・ストレージへのファイル転送を最大限の信頼性を得るには、マルチパート・アップロードを使用します。

回避策: マルチパート・アップロードを使用して、100MiBを超えるファイルをオブジェクト・ストレージに転送します。

バグ: 33617535

バージョン: 3.0.1

3.5.8 ジョブの失敗にもかかわらずファイル・システム・エクスポートが作成されました

多数のエクスポート・オプションを使用してファイル・システム・エクスポートを作成すると、システムがビジーであり、すべての指示を十分にすばやく処理できないため、タイムアウトが発生する可能性があります。 この時点で、「lock wait timeout」を超えたことを示すエラー・メッセージが返され、操作が失敗したことを示します。 実際、ファイルシステム・サービスは、システム負荷のためにリクエストが受け入れられたがまだ完了していないため、バックグラウンドで再試行し続けます。 タイムアウト・エラーにもかかわらず、エクスポートが正常に作成された可能性があります。

回避策: エクスポートのステータスを確認するには、CLIコマンドoci fs export getの使用を検討してください。

バグ: 33690163

バージョン: 3.0.1

3.5.9 ZFSコントローラのフェイルオーバー後にコンピュート・イメージのインポートが失敗する

ZFSコントローラのフェイルオーバーまたはフェイルバックが発生した場合、イベント後にしばらくの間、コンピュート・イメージのインポートを正常に完了できない可能性があります。 このZFSストレージ・アプライアンスの動作は予測できませんが、イメージのインポート操作は再度成功することが期待されますが、いくつかの試行が必要になる可能性があります。

回避策: ZFSコントローラのフェイルオーバーまたはフェイルバックが発生した直後にイメージのインポートが失敗した場合、成功するまで操作を再試行してください。

バグ: 33677366

バージョン: 3.0.1

3.5.10 インポート後に、UEFIを使用してBIOS起動モードで表示されるコンピュート・イメージ

Compute Web UIを介してコンピュート・イメージをインポートする場合、使用可能な「起動モード」オプションは1つのみです。 「準仮想化モード」を選択すると、メタデータがUEFIを指定している場合でも、インポート時にイメージがBIOSに設定されます。 その結果、そのイメージからインスタンスを起動しようとすると、操作は失敗します。 CLIを使用してインスタンスを起動するときに、起動オプションをオーバーライドできます。

同じ問題が、テナンシからオブジェクト・ストレージにエクスポートされたカスタム・イメージに適用されます。 "firmware": "UEFI_64"設定は正しくエクスポートされますが、「準仮想化」起動モードでインポートすると、設定が上書きされます。

回避策: 準仮想化起動モードでUEFIコンピュート・イメージをインポートした場合は、次に示すように、CLIを使用してこのイメージからインスタンスを起動し、正しい起動オプションを含めます:

oci compute instance launch [...] \
--launch-options '{"boot-volume-type":"PARAVIRTUALIZED","firmware":"UEFI_64",
"is-consistent-volume-naming-enabled":false,"is-pv-encryption-in-transit-enabled": false,
"network-type":"PARAVIRTUALIZED","remote-data-volume-type": "PARAVIRTUALIZED"}'

あるいは、一部のブラウザでは、「起動モード」オプションを選択せずにCompute Web UIを介してイメージをインポートできます。 イメージのインポート・ウィンドウを取り消して閉じ、イメージのインポート・ボタンをクリックして再度開くと、準仮想化モードが選択解除されることがあります。 これらの設定でイメージをインポートすると、イメージ・メタデータからのUEFI設定を適用できます。

バグ: 33736077

バージョン: 3.0.1

3.5.11 大規模エクスポート・オプション更新後のファイル・システムのエクスポート一時アクセス不可

ファイル・システムのエクスポートを更新して多数の'source'タイプのエクスポート・オプションを追加すると、エクスポートが存在しなくなったことを示すサービス・エラーがコマンドによって返されます("code": "NotFound")。 実際、エクスポートは、構成更新が完了するまでアクセスできなくなります。 エクスポートにアクセスしたり、格納されている情報を表示しようとすると、同様のエラーが表示されます。 この動作は、ファイル・システムのエクスポート・オプションの更新に使用するメソッドによって発生します: 既存の構成が削除され、リクエストされた変更を含む新しい構成で置き換えられます。 まれに何十ものエクスポート・オプションを同時に追加した場合にのみ注目してください。

回避策: 更新が完了し、ファイル・システムのエクスポートが再び使用可能になるまで待ちます。 CLIコマンドoci fs export get --export-id <fs_export_ocid>は、対象のエクスポートの情報を返す必要があります。

バグ: 33741386

バージョン: 3.0.1

3.5.12 デタッチ状態になったブロック・ボリューム

ブロック・ボリュームは、複数の異なるコンピュート・インスタンスにアタッチでき、同じインスタンスに複数のアタッチメントを含めることもできます。 同じボリュームの同時ボリューム・デタッチ操作が発生したときに、自動化ツールと同様にプロセスが相互に干渉する場合があります。 たとえば、作業リクエストが異なると、ZFSストレージ・アプライアンス上のリソースを同時に更新しようとしたり、作業リクエスト内のデータが古いり、アプライアンスのリソース更新の競合が発生したりすることがあります。 この方法でブロック・ボリュームのデタッチ操作が失敗すると、ブロック・ボリュームがこのステージのインスタンスからデタッチされていても、問題のブロック・ボリューム・アタッチメントは「デタッチ中」状態でスタックする可能性があります。

回避策: ブロック・ボリュームがデタッチ中状態でスタックしたインスタンスがある場合、ボリュームはデタッチされましたが、さらに手動でクリーンアップする必要があります。 「デタッチ中」状態はクリアできませんが、影響を受けるインスタンスは停止でき、ブロック・ボリュームは最終目標の場合は削除できます。

バグ: 33750513

バージョン: 3.0.1

3.5.13 スケジュール済ボリューム・バックアップがバックアップ・リストに表示されません

ブロック・ボリューム・バックアップ・ポリシーを構成すると、バックアップ・スナップショットが定期的に作成されます。 ただし、コンパートメント内のすべてのブロック・ボリューム・バックアップをリストする場合、これらの自動バックアップはリストに表示されません。 これは設計によって発生します: ZFSストレージ・アプライアンスからすべてのボリュームのバックアップのリストの取得には、比較的時間がかかるため、同期はボリュームごと、および明示的な手動リクエストが行われた場合にのみ行われます。

回避策: バックアップ・ポリシーを使用して作成されたボリューム・バックアップのリストにアクセスするには、次に示すように--volume-id <bv_ocid>でlistコマンドを使用して、問題のボリュームのバックアップを明確に表示します。 これにより、エントリがボリューム・バックアップのリストと同期されます。つまり、コンパートメント内のすべてのブロック・ボリューム・バックアップを次回リストしたときにすべて表示されます。 

oci bv backup list --volume-id <bv_ocid> --compartment-id <compt_ocid>

バグ: 33785277

バージョン: 3.0.1

3.6 保守性の問題

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

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

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

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

バグ: 33265549

バージョン: 3.0.1

3.6.2 障害リカバリ・コマンドでメッセージ属性が欠落している

一般に、get、listおよびshowコマンドの場合、メッセージ属性はレスポンスに含まれます。 ディザスタ・リカバリの実装に一貫性がありません: APIコールdr-admin.computeinstance.get、dr-admin.mapping.listおよびdr-admin.service.showのメッセージ属性は返されません。

回避策: 回避策はありません。 この一貫性のない動作は、APIと直接相互作用している開発者またはアプリケーションにのみ影響します。

バグ: 33676119

バージョン: 3.0.1

3.6.3 2番目のシステムでDRレプリケーションの有効化に失敗

「Oracle Private Cloud Appliance管理者ガイド」の「ディザスタ・リカバリ」指示に従ってZFSストレージ・アプライアンス間のピアリングを設定する場合、最後のステップは2つのシステムでレプリケーションを有効にすることです。 ただし、最後のコマンドは、2番目のアプライアンスで実行すると失敗します。 これは、最初のアプライアンスでレプリケーションを有効にした結果としてレプリケーション・ターゲットがすでに構成されており、既存のレプリケーション・ターゲットの使用が受け入れられていないために発生します。

回避策: 最初のアプライアンスからレプリケーションを有効にした場合、2番目のアプライアンスで同じコマンドを実行しないでください。 かわりに、ストレージ・アプライアンスにログオンし、レプリケーション・ターゲットを手動で変更して、正しいターゲットの「ホスト名」および「ラベル」パラメータを設定します。

標準および高パフォーマンスのレプリケーション・ターゲットには、drSetupServiceコマンドと同じリモートIPアドレスを使用します。 次の例では、remoteIp=10.50.7.33およびremoteIpPerf=10.50.7.34を使用します。 

# ssh pcamn01
pcamn01 ~]# ssh 100.96.2.2

sn011742XC3024:> shares replication targets
sn011742XC3024:shares replication targets> ls
Targets:
TARGET       LABEL                        ACTIONS
target-000   mypca1sn01-dr1.example.com   0
target-001   mypca1sn02-dr1.example.com   0

sn011742XC3024:shares replication targets> select target-000
sn011742XC3024:shares replication target-000> set hostname=10.50.7.33
                      hostname = 10.50.7.33 (uncommitted)
sn011742XC3024:shares replication target-000> set label=target-zfssa-replication
                         label = target-zfssa-replication (uncommitted)
sn011742XC3024:shares replication target-000> commit
[...]

sn011742XC3024:shares replication target-000> up

sn011742XC3024:shares replication targets> select target-001
sn011742XC3024:shares replication target-001> set hostname=10.50.7.34
                      hostname = 10.50.7.34 (uncommitted)
sn011742XC3024:shares replication target-001> set label=target-zfssa-replication-high
                         label = target-zfssa-replication-high (uncommitted)
sn011742XC3024:shares replication target-001> commit
[...]

sn011742XC3024:shares replication target-001> exit

ZFSストレージ・アプライアンス構成が更新され、ストレージ・コントローラからログアウトしたら、管理ノードで次のコマンドを実行します。

kubectl exec -it `kubectl get pods |grep dr-admin |awk '{print $1}'` --python3 -c "from pca_dr_admin.metadata import access; \
from pca_dr_admin.replication import replication; access.set_replication_enabled(); access.set_replication_high_enabled(); \
replication.create_repl_action('pca_dr_metadata', 'PCA_POOL'); replication.wait_repl_update_synced('pca_dr_metadata', 'PCA_POOL')"

バグ: 33760254

バージョン: 3.0.1

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

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

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

バグ: 33730639

バージョン: 3.0.1

Copyright © 2013, 2022, Oracle and/or its affiliates.