プラットフォームの問題

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

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

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

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

バグ: 33519372

バージョン: 3.0.1

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

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

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

バグ: 33535069

バージョン: 3.0.1

ハードウェア・コンポーネント・パスワードの変更中にエラーが発生しました

Oracle Private Cloud Applianceアーキテクチャのハードウェア・レイヤーは、動作および管理ソフトウェアが異なる様々なタイプのコンポーネントで構成されます。スタンドアロン製品として、パスワード・ポリシーは異なる場合がありますが、アプライアンス・ソフトウェアはより厳しいルールセットを適用します。コンポーネントのパスワードを変更しようとしたときにエラーが返される場合は、新しいパスワードがハードウェア・コンポーネントのPrivate Cloud Applianceポリシーに準拠していることを確認してください。

アプライアンス環境全体のパスワード・メンテナンスの詳細は、「Oracle Private Cloud Applianceセキュリティ・ガイド」を参照してください。

回避策: ハードウェア・コンポーネントの場合、サービスCLIを使用して、次のルールに準拠するパスワードを設定します:

少なくとも8文字で構成されます
- コンピュート・ノード、管理ノード、およびスイッチの最大長は20文字です
- ILOMおよびZFS Storage Applianceの最大長は16文字
小文字(a-z)が1つ以上含まれています
少なくとも1つの大文字(A-Z)を含む
少なくとも1つの数字(0-9)が含まれます
少なくとも1つの記号(@$!#%*&)が含まれています

バグ: 35828215

バージョン: 3.0.2

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

ストレージ拡張の自動ディスク・シェルフ・プロビジョニングが無効

Private Cloud Applianceの初期インストール中に、存在するディスク・シェルフは自動的に適切なプールに追加されます: 容量または高性能。ディスク・シェルフをあとで追加してアプライアンスのストレージ容量を拡張すると、これらのディスク・シェルフは自動的にプロビジョニングされず、それぞれのストレージ・プールに追加されます。この機能変更は、3.0.2-b1081557より新しいアプライアンス・ソフトウェア・バージョンに実装されました。

ストレージの展開は順次処理されるため、1回の操作で追加されるディスク・シェルフの数に関係なく、ストレージ・プールの自動再構成によってスペア・ドライブが過剰に数えられます。ストレージ・リソースをコスト効率よく正しくバランスよく使用するために、最新のアプライアンス・ソフトウェアでこの自動化を削除することを決定しました。

回避策: Private Cloud Applianceのストレージ拡張は、スペア・ドライブの数をラックの特定のストレージ構成に調整できるように、ケースごとに最適に構成されます。 Oracleに連絡してください。ストレージ拡張のシナリオについては、ノート「ドキュメントID 3020837.1」を参照してください。

バグ: 36623140

バージョン: 3.0.2

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

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

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

バグ: 33609276

バージョン: 3.0.1

修正可能: 最新のパッチをシステムに適用してください。

スイッチのハードウェアの状態が「稼働中」と報告されました

拡張ラックには、ベース・ラックに接続された独自のスイッチ・セットがあります。相互接続されたラック間でデータおよび管理ネットワークが統合されると、アプライアンス・プラットフォームは拡張ハードウェアを同じシステムの一部として認識します。スイッチを問合せすると、リストにはシステム内のそのタイプのすべてのスイッチが含まれますが、拡張スイッチのハードウェア状態は「OK」ではなく「Up」と報告されます。

# pca-admin switch leaf list
+----------+-----------+------------+-------------------------------------+-------------+-----------+----------+--------------------+
|   RackID | Rack Unit | CPU Vendor | Model                               | IP Address  | Hostname  | HW State | Provisioning state |
+----------+-----------+------------+-------------------------------------+-------------+-----------+----------+--------------------+
|        1 | 22        | Cisco      | cisco Nexus9000 C9336C-FX2 Chassis  | 100.96.2.22 | pcaswlf01 | OK       | Ready              |
|        1 | 23        | Cisco      | cisco Nexus9000 C9336C-FX2 Chassis  | 100.96.2.23 | pcaswlf02 | OK       | Ready              |
|        2 | 23        | Cisco      | cisco Nexus9000 C9336C-FX2 Chassis  | 100.96.2.40 | pcaswlf03 | Up       | Ready              |
|        2 | 22        | Cisco      | cisco Nexus9000 C9336C-FX2 Chassis  | 100.96.2.41 | pcaswlf04 | Up       | Ready              |
+----------+-----------+------------+-------------------------------------+-------------+-----------+----------+--------------------+

# pca-admin switch mgmt list
+----------+-----------+------------+-------------------------------------+-------------+-----------+----------+--------------------+
|   RackID | Rack Unit | CPU Vendor | Model                               | IP Address  | Hostname  | HW State | Provisioning state |
+----------+-----------+------------+-------------------------------------+-------------+-----------+----------+--------------------+
|        1 | 24        | Cisco      | cisco Nexus9000 C9348GC-FXP Chassis | 100.96.2.1  | pcaswmn01 | OK       | Ready              |
|        2 | 23        | Cisco      | cisco Nexus9000 C9348GC-FXP Chassis | 100.96.2.46 | pcaswmn02 | Up       | Ready              |
+----------+-----------+------------+-------------------------------------+-------------+-----------+----------+--------------------+

回避策: 異なるハードウェア状態ラベルは無害です。回避策はありません。

バグ: 37076258

バージョン: 3.0.2

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

次のフリー・フォーム・タグを使用して、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

Terraform適用するとデフォルト・タグを削除できます

terraform apply中に、OCI Terraformプロバイダがリソースから既存のタグのデフォルトを予期せず削除することがあります。たとえば、リソースの作成時に自動的に割り当てられたOracle-Tags.CreatedByおよびOracle-Tags.CreatedOnタグのデフォルトは、後続のterraform applyで削除できます。

回避策: ignore_defined_tags属性をプロバイダ・ブロックに追加し、次の例に示すように、planまたはapplyでTerraformプロバイダが無視するタグをリストします:

provider "oci" {
    ignore_defined_tags = ["Oracle-Tags.CreatedBy", "Oracle-Tags.CreatedOn"]
}

バグ: 36692217

バージョン: 3.0.2

新しい定義済タグを含むTerraformリソース定義内のタグ定義に依存

Terraform計画に、定義済タグ定義と、それらの定義済タグを使用するその他のリソース定義の両方が含まれている場合は、リソースが正しい順序で作成されるように、この依存関係についてTerraformに通知する必要があります。次の例に示すように、この同じ計画で定義されているタグを使用する各リソースの定義に、タグの定義場所を指すdepends_onメタ引数を含めます:

resource "oci_identity_tag_namespace" "example_tag_ns" {
  tag_namespace_definition
}
resource "oci_identity_tag" "example_tag" {
  tag_key_definition
}
...
resource "oci_resource" "resource_name" {
  depends_on = [
    oci_identity_tag.example_tag
  ]
  resource_definition
}

depends_onを使用して依存関係についてTerraformに通知しない場合は、次のいずれかのメソッドを使用できます:

個別のTerraform計画に定義済タグを作成し、そのタグを使用するリソースを作成する計画を適用する前に、その計画を適用します。
タグを使用するリソースの作成時にタグが不明であったために適用が失敗した場合は、同じ計画を再度適用します。

バグ: 36701647

バージョン: 3.0.2

Terraform計画による動的グループおよびポリシーの作成の失敗

Terraformを使用してアイデンティティ・グループまたは動的グループおよび関連付けられたポリシーを作成する場合、Terraform計画を適用するとエラーが返される可能性があります。 IAMサービスでは、存在しないアイデンティティ・グループに対してポリシーを作成することはできません。したがって、Terraform計画で定義されたポリシー・リソースが、適用先のアイデンティティ(動的)グループの前に作成されると、認可エラーまたはオブジェクトが見つかりませんというエラーが返されます。たとえば:

...â
 Error: 404-NotAuthorizedOrNotFound, Authorization failed or requested resource not found.
 Suggestion: Either the resource has been deleted or service Identity Policy need policy to access this resource.
 Policy reference: https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/policyreference.htm
...

通常、すべてのリソースはエラー・メッセージにもかかわらず正しく作成されます。 Terraform計画を2回適用すると、通常、コマンドは成功します。

回避策: Private Cloud Applianceリソース作成操作間に依存関係が存在する場合は、Terraform depends_on機能を使用して、この依存関係をTerraform計画で明示的にします。 depends_onメタ引数は、依存リソースを作成する前に依存リソースを作成するようにTerraformに指示します。たとえば、次の強調表示された行と同様のdepends_on文を追加します。

resource "oci_identity_dynamic_group" "test_dynamic_group" {
  compartment_id = "ocid1.tenancy....unique_ID"
  description    = "Terraform test dependency"
  matching_rule  = "matching_rule1"
  name           = "testdyngrp"
}
resource "oci_identity_policy" "dg_policy" {
  compartment_id = "ocid1.tenancy....unique_ID"
  description    = "Test DG Policy"
  name           = "DGPolicy"
  statements     = [
    "allow dynamic-group testdyngrp to manage all-resources in tenancy"
  ]
  depends_on = [
    oci_identity_dynamic_group.test_dynamic_group
  ]
}

バグ: 36536058

バージョン: 3.0.2

ユーザー名の最大長はOracle Cloud Infrastructureと異なります

Oracle Cloud Infrastructureは、非常に長いユーザー名のアカウントを受け入れます。 Private Cloud ApplianceのIAMサービスの最大ユーザー名長が同じではありません。これは、パブリック・クラウド設定をPrivate Cloud Appliance環境に移行するときに問題になる可能性があります。この場合、IAMサービスはエラー" Data too long for column 'name' at row x "を返します。

回避策: より短いユーザー名を設定して、問題の原因となるユーザー・アカウントを更新します。

バグ: 36536058

バージョン: 3.0.2

Terraform複雑なタグ値で二重引用符をエスケープする必要があります

複合タグ値には、キーと値フィールドの値があります。 Terraformでは、この複合値では、複合値を囲む中カッコ内の二重引用符をエスケープする必要があります。

次の例は、複雑なタグ値を示しています。この例では、key1_nameタグ・キーの値は別のキーとその値です:

{"key1_name": {"key2_name": "key2_value"}}

比較のために、次の例では、OCI CLIでこの値を指定する方法を示します:

--freeform-tags '{"key1_name": {"key2_name": "key2_value"}}'

次の例は、Terraformを使用してこの値を指定する方法を示しています:

freeform_tags = {"key1_name" = "{\"key2_name\": \"key2_value\"}"}

次の例は、OKEクラスタの作成に使用される定義済タグのTerraformです。 OraclePCA.cpNodeShapeConfigタグの値である2つのキー/バリュー・ペアに注意してください:

defined_tags={"OraclePCA.cpNodeCount"="3","OraclePCA.cpNodeShape"="VM.PCAStandard1.Flex","OraclePCA.cpNodeShapeConfig"="{\"ocpus\":1,\"memoryInGBs\":10}","OraclePCA.sshkey"="sshkey"}

バグ: 36691556

バージョン: 3.0.2

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

デフォルトのストレージ構成を持つ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

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

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 pcamn03

HAProxyを起動するには、次の例に示すように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

ストレージ構成のタイムアウトにより、同時コンピュート・ノードのプロビジョニング操作が失敗

Private Cloud Applianceがインストールされている場合、または一連の拡張コンピュート・ノードが追加されている場合、すべての新しいコンピュート・ノードを一度にプロビジョニングすることはできません。ただし、プロビジョニングされたノードごとに、ストレージ・イニシエータおよびターゲットをZFS Storage Applianceで構成する必要があることに注意してください。ストレージ・アプライアンスが処理する構成更新リクエストが多すぎる場合は、タイムアウトします。その結果、すべてのコンピュート・ノードのプロビジョニング操作は失敗し、プロビジョニングされていない状態にロールバックされます。

回避策: ZFS Storage Appliance構成のタイムアウトを回避するには、コンピュート・ノードを1つずつ、または3つ以下のグループに順次プロビジョニングします。

バグ: 34739702

バージョン: 3.0.2

アクティブなコンソール接続のためにデータ・スイッチのブートに失敗

「Cisco Nexus 9336C-FX2スイッチ」にアクティブなローカル・コンソール・セッションがある場合(端末サーバーが接続されている場合など)、リブート中にスイッチがランダムにハングアップすることがあります。ブート・シーケンスの中断は、コンソール・ポートのゴースト・セッションが原因であると想定されます。ローカル・コンソール接続が使用されていない場合、この動作は確認されていません。

回避策: データ・スイッチのコンソール・ポートにケーブルを接続しないでください。 Private Cloud Applianceインストールでは、ローカル・コンソール接続は必要ありません。

バグ: 32965120

バージョン: 3.0.2

証明書が期限切れのため、失敗した状態のスイッチ

アプライアンス・ソフトウェアのアップグレード中に、コンポーネント間の認証のために新しい証明書がインストールされます。証明書がスイッチにアップロードされていない可能性があります。スイッチ上の証明書の有効期限が切れると、証明書は障害状態になり、クリティカルなアクティブ障害になります。

PCA-ADMIN> list fault where status EQ ACTIVE
Data:
  id                                     Name                                          Status   Severity
  --                                     ----                                          ------   --------
  d38d1e3b-893e-49bd-a62a-77b0bd22e5d9   RackUnitRunStateFaultStatusFault(pcaswmn01)   Active   Critical
  c0358065-ea81-4ad3-4a6c-017194f73659   RackUnitRunStateFaultStatusFault(pcaswlf01)   Active   Critical
  2fe549b7-596c-4a6c-25d3-1f9fa4b0bd1c   RackUnitRunStateFaultStatusFault(pcaswlf02)   Active   Critical
  25d3c91d-1e69-4f73-8319-f5ed18f6a903   RackUnitRunStateFaultStatusFault(pcaswsp01)   Active   Critical
  4af35eff-994f-c400-a93a-314cc43c97a1   RackUnitRunStateFaultStatusFault(pcaswsp02)   Active   Critical

回避策: スイッチの証明書の有効期限が切れていることを確認してから、スイッチを再プロビジョニングして、新しい証明書を強制的にアップロードします。ノートの「ドキュメントID 3080032.1」の手順に従います。正常に完了すると、スイッチは「準備完了」状態に戻ります。

バグ: 37743552

バージョン: 3.0.2

アプライアンスのアップグレード後のフェデレーテッド・ログイン失敗

アイデンティティ・フェデレーションを使用すると、ユーザーは既存の会社のユーザー名とパスワードでPrivate Cloud Applianceにログインできます。アプライアンス・ソフトウェアのアップグレード後、アイデンティティ・プロバイダとPrivate Cloud Appliance間の信頼関係が破損し、すべてのフェデレーテッド・ログインが失敗する可能性があります。アップグレード中に、内部サービスの変更のためにPrivate Cloud Appliance X.509外部サーバー証明書を更新できます。この場合、アイデンティティ・プロバイダ側の証明書は一致しなくなります。

回避策: アイデンティティ・プロバイダで許可されている場合は、そのサービス・プロバイダ証明書を更新します。

アプライアンスのSAMLメタデータXMLファイルをhttps://iaas.<domain>/saml/<TenancyId>から取得し、ローカル・ファイルに保存します。

テキスト・エディタでローカル・ファイルを開き、<X509Certificate>要素を見つけます。

<SPSSODescriptor>
    <KeyDescriptor use="signing">
        <KeyInfo>
            <X509Data>
                <X509Certificate>  
                    <COPY CERTIFICATE CONTENT FROM HERE>
                  </X509Certificate>
            </X509Data>
        </KeyInfo>
    </KeyDescriptor>
</KeyDescriptor>

証明書の内容をコピーして、次のように構造化された新しい*.pemファイルに保存します:
```
-----BEGIN CERTIFICATE-----
<PASTE CERTIFICATE CONTENT HERE>
-----END CERTIFICATE-----
```
Private Cloud Applianceのこの新しいサービス・プロバイダ証明書でアイデンティティ・プロバイダを更新します。

アイデンティティ・プロバイダが簡単に証明書を更新できない場合は、サービス・プロバイダを削除してアイデンティティ・フェデレーションを再構成することをお薦めします。詳細は、「Oracle Private Cloud Appliance管理者ガイド」の項「Microsoft Active Directoryによるフェデレート」を参照してください。

バグ: 35688600

バージョン: 3.0.2

コンパートメントまたはテナンシを削除する前にストレージ・バケットが存在しないことの確認

コンパートメントまたはテナンシを削除するコマンドが発行されると、アプライアンス・ソフトウェアには、ZFS Storage Applianceに存在するすべてのバケットへのアクセス権を持つサービス・アカウントがないため、オブジェクト・ストレージ・バケットが存在しないことを確実に確認できません。その結果、特定のオブジェクト・ストレージ・バケットへのアクセスは、コンパートメントが削除されると失われる可能性があります。

回避策: コンパートメントまたはテナンシを削除する前に、そのコンパートメントまたはテナンシにオブジェクト・ストレージ・バケットが存在しないことを確認します。

バグ: 35811594

バージョン: 3.0.2

RabbitMQエラーでアップグレード・ジョブのリストが失敗

「サービスCLI」コマンドgetUpgradeJobsを実行すると、次のエラーが返される場合があります:

PCA-ADMIN> getUpgradeJobs
Status: Failure
Error Msg: PCA_GENERAL_000012: Error in RabbitMQ service: null

回避策: 問題は一時的なものです。後でコマンドを再試行してください。

バグ: 35999461

バージョン: 3.0.2

バージョン3.0.2-b1001356での可用性ドメイン名の変更

ソフトウェア・バージョン3.0.2-b1001356 (2023年12月)では、Private Cloud Applianceの単一可用性ドメインの名前が" ad1 "から" AD-1 "に変更されました。この変更は、Oracle Cloud Infrastructureとの互換性のために必要でした。可用性ドメインは、少数のコマンド・セットでは必須パラメータであり、他のいくつかのコマンドではオプション・パラメータです。

次のコマンドでは、--availability-domainパラメータが必要です:

oci bv boot-volume create
oci bv boot-volume list
oci bv volume create
oci bv volume-group create
oci compute instance launch
oci compute boot-volume-attachment list
oci fs file-system create
oci fs file-system list
oci fs mount-target create
oci fs mount-target list
oci fs export-set list
oci iam fault-domain list

回避策: システムが実行しているアプライアンス・ソフトウェアのバージョンに応じて、コマンド内の可用性ドメインを識別するために正しい値が使用されていることを確認します。スクリプトまたは--availability-domainパラメータを含む任意の形式の自動化を使用している場合は、バージョン3.0.2-b1001356以降でアプライアンスをアップグレードまたはパッチ適用するときに、コードが更新されていることを確認してください。

バグ: 36094977

バージョン: 3.0.2

MySQL Clusterデータベースにパッチを適用できるパッケージがありません

アプライアンス・ソフトウェア・バージョン3.0.2-b1001356のリリースでは、新しいMySQL RPMパッケージがULNチャネルPCA 3.0.2 MNに追加されました。ただし、パッケージ署名の問題により、ULNミラーによるダウンロードが防止されます。つまり、システム上のMySQLクラスタ・データベースには、使用可能な最新バージョンへのパッチ適用ができません。

システムにパッチを適用しても、欠落しているMySQLパッケージに関連するエラー・メッセージや異常な動作は表示されません。回避策に従って新しいパッケージを取得します。これらをULNミラーにダウンロードしたら、MySQLクラスタ・データベースにパッチを適用できます。

ノート:

新しいULNミラー・インストールの場合、MySQLパッケージの更新を有効にするステップは、「パッチ適用のための環境の構成」の「Oracle Private Cloud Applianceパッチ適用ガイド」に含まれています。

システムがこの問題の影響を受けているかどうかを判断するには、ULNミラーで、pca302_x86_64_mnソフト・リンクによって参照されるyumディレクトリにMySQLパッケージがあるかどうかを確認します。検索で結果が返されない場合、ULNミラーはMySQLパッケージをダウンロードできませんでした。 yum設定ディレクトリのデフォルトのロケーションは/var/www/html/yumで、次の例で使用されます:

# ls -al /var/www/html/yum/pca302_x86_64_mn/getPackage/ | grep mysql
-rw-r--r--. 1 root root  85169400 Dec 19 03:19 mysql-cluster-commercial-client-8.0.33-1.1.el7.x86_64.rpm
-rw-r--r--. 1 root root   4751220 Dec 19 03:19 mysql-cluster-commercial-client-plugins-8.0.33-1.1.el7.x86_64.rpm
-rw-r--r--. 1 root root    689392 Dec 19 03:19 mysql-cluster-commercial-common-8.0.33-1.1.el7.x86_64.rpm
-rw-r--r--. 1 root root  12417692 Dec 19 03:19 mysql-cluster-commercial-data-node-8.0.33-1.1.el7.x86_64.rpm
-rw-r--r--. 1 root root   2229080 Dec 19 03:19 mysql-cluster-commercial-icu-data-files-8.0.33-1.1.el7.x86_64.rpm
-rw-r--r--. 1 root root   2236184 Dec 19 03:19 mysql-cluster-commercial-libs-8.0.33-1.1.el7.x86_64.rpm
-rw-r--r--. 1 root root   1279012 Dec 19 03:19 mysql-cluster-commercial-libs-compat-8.0.33-1.1.el7.x86_64.rpm
-rw-r--r--. 1 root root   3478680 Dec 19 03:19 mysql-cluster-commercial-management-server-8.0.33-1.1.el7.x86_64.rpm
-rw-r--r--. 1 root root 364433848 Dec 19 03:19 mysql-cluster-commercial-server-8.0.33-1.1.el7.x86_64.rpm
-rw-r--r--. 1 root root   2428848 Dec 19 03:19 mysql-connector-j-commercial-8.0.33-1.1.el7.noarch.rpm
-rw-r--r--. 1 root root   4570200 Dec 19 03:19 mysql-connector-odbc-commercial-8.0.33-1.1.el7.x86_64.rpm

回避策: ULNミラーに適切なGPGキーをインポートすると、更新されたMySQLパッケージをダウンロードできます。次の手順を実行します。

ULNミラー・サーバーにログインします。
次のロケーションからMySQL GPGキーをダウンロードします:
- https://repo.mysql.com/RPM-GPG-KEY-mysql-2022。
- https://repo.mysql.com/RPM-GPG-KEY-mysql-2023。

GPGキーをインポートします。

# rpm --import RPM-GPG-KEY-mysql-2022
# rpm --import RPM-GPG-KEY-mysql-2023

ULNミラーを更新します。
```
# /usr/bin/uln-yum-mirror
```
キーが正常にインポートされると、新しいMySQLパッケージがULNミラーにダウンロードされます。

確認のため、新しいパッケージのいずれかを使用してシグネチャを確認します。

# rpm --checksig mysql-cluster-commercial-management-server-8.0.33-1.1.el7.x86_64.rpm
mysql-cluster-commercial-management-server-8.0.33-1.1.el7.x86_64.rpm: rsa sha1 (md5) pgp md5 OK

バグ: 36123758

バージョン: 3.0.2

ドメイン名で大文字がサポートされない

ドメイン名では大文字はサポートされていません。システムのドメイン名は、内部ネットワークのベース・ドメインとして使用され、Oracle Private Cloud Applianceパブリック対応サービスによって使用されます。この属性の最大長は190文字です。使用可能な文字は、a"→"z"、"0"→"9"、"-"です

バグ: 36484125

バージョン: 3.0.2

Prometheusバックアップ・アーカイブが破損している

Private Cloud Applianceは、大規模な停止が発生した場合にシステム・データを保持するために、内部日次バックアップ・スケジュールに従います。自動バックアップには、もともとPrometheusモニタリング・データが含まれていましたが、そのボリュームによって重大な副作用が生じました。圧縮しても、14日の保存期間が切れる前に、バックアップに割り当てられたファイル・システムがいっぱいになるデータ量。ある時点で、アーカイブの構築中に障害が発生し、結果としてバックアップが破損します。このため、アプライアンス・ソフトウェア・バージョン3.0.2-b1081557の日次バックアップからPrometheusが削除されました。

回避策: Prometheusのモニタリング・データは、自動バックアップには含まれません。 Prometheusデータを保持するには、バックアップを作成して手動でリストアします。詳細は、「ドキュメントID 3021643.1」のノートを参照してください。

バグ: 36623554

バージョン: 3.0.2

ホスト名へのインストールまたはアップグレード中にSauronイングレスが大文字でブレーク

アプライアンスをアップグレードするときに、ホスト名に大文字が使用されているため、プラットフォームのアップグレードが失敗する可能性があります。

回避策: このコマンドを実行して、ホスト名のすべての既存コピーで大文字を小文字に変更し、アップグレードを再試行します。

curl -k -X PUT -HHost:api.pca.oracledx.com https://253.255.0.32/v1/uri?uri=<FQDN in Lowercase> -u admin:<sauron_password>

バグ: 36792458

バージョン: 3.0.2

アップグレード後のタスクでのUpgraderログ・レポート・ヘルス・チェック・エラー

アプライアンス・ソフトウェア・バージョン3.0.2-b1261765にアップグレードまたはパッチ適用すると、pca-health-checkerスクリプトは、ファイル・システムのマウントが欠落しているため、アップグレード後のタスクでエラーを返します: 253.255.12.2:/export/clamav_db。 Upgraderはエラーによって中断されず、すべてのタスクを完了することが予想されます。

回避策: このエラーは無視できます。機能的な影響はありません。

バグ: 37311137

バージョン: 3.0.2

アプライアンス・ソフトウェアのアップグレード中にサポート・バンドルを収集できない

アプライアンス・ソフトウェア・バージョン3.0.2-b1392231にアップグレードする場合、サポート・バンドルを生成および収集することは一時的にできません。その他のログ収集メソッドには影響しません。

回避策: アップグレードが完了すると、サポート・バンドル機能は正常に戻ります。アップグレード・ウィンドウ中のログ収集には、タイム・スライスを使用します。

バグ: 37828395

バージョン: 3.0.2

ローカル・エンドポイントにパフォーマンス・プールを追加できません

複数のPrivate Cloud Applianceシステム間のピア接続は、ローカル・エンドポイント間で構成されます。ローカル・エンドポイント構成のパラメータには、ZFSプールのIPアドレスが含まれます。ただし、ローカル・エンドポイントの後に高パフォーマンスのZFSプールが作成された場合、その構成を新しいプールIPで更新することはできません。ローカル・エンドポイントを削除し、新しいパラメータで再作成する必要があります。これは、ネイティブのディザスタ・リカバリ(DR)サービスに悪影響を及ぼします。ローカル・エンドポイントを削除する前に、すべてのDR構成も削除する必要があります。

回避策: ローカル・エンドポイントを削除して再作成します。 DR構成が存在する場合は、これらも削除して再作成する必要があります。

バグ: 37196927

バージョン: 3.0.2

1つのアプライアンスでピア接続を削除して再作成したあとでDR構成を使用できない

ネイティブのディザスタ・リカバリ(DR)サービスの場合、2つのPrivate Cloud Applianceシステム間のピア接続は、接続の各側から構成する必要があります。ピア接続を2つのシステムのいずれかで削除する必要があり、再度作成すると、ピアリングは完全かつ完全に機能していると報告されます。ただし、既存のDR構成からDR計画を実行すると、通常、Precheck FailedやDR metadata project not replicatedなどのメッセージを含むエラーが返されます。

回避策: ピア接続は対称になるように設計されています。 1つのシステムでピア接続を削除して再作成する場合は、2番目のシステムでもピア接続を削除して再作成する必要があります。

バグ: 37260498

バージョン: 3.0.2

異常なストレージ・コントローラでピアリングすると、レプリケーション・アクションのテストが失敗

2つのPrivate Cloud Applianceシステム間でピア接続を作成するときに、ターゲットOracle ZFS Storage Applianceコントローラの1つが異常な状態にある場合、ピアリング操作は失敗します。実際、ターゲットは作成されますが、レプリケーション・アクション・テストが失敗し、ピア接続が「failed」ライフサイクル状態のままになります。ピアリング・ログおよび進捗レコードのエラー・メッセージは、次の例のようになります:

Details = Replication target for host <serial>/<IP>/<Pool> failed post-checks.
Post-check failed during replication action test of <Pool>: Failed to create replication action for <share>.
Reset the peer connection and try again.
  PeerConnectionId = id:ocid1.drpeerconnection.<unique_ID> type:PeerConnection

回避策: ピア接続を作成する前に、両方のシステムのストレージ・コントローラが正常に動作している必要があります。構成をクリーンアップし、すべてのストレージ・コントローラが健全であることを確認して、ピア接続を再度作成します。

バグ: 37743102

バージョン: 3.0.2

不完全なピア接続を削除すると、新しいピア接続が作成されない

2つのPrivate Cloud Applianceシステム間のピア接続は、両方のラックで対称的に構成する必要があります。 1つのラックの構成が「作成」状態でスタックし、もう1つのラックの構成がactiveになった場合、ピアリング接続は完了できません。通常のアクションでは、両方のシステムのピアリング構成を削除し、新しいピアリング接続を作成します。ただし、不完全な構成は、通常のコマンドを使用して削除することはできません。これは、これらのシステムをピアリングするための新しい試行が失敗することを意味します。テストでは、完全修飾ドメイン名ではなくIPアドレスを使用してレプリケーション・ターゲットが登録されたときにこの問題が発生し、作成時にDNSの問題が示されます。

回避策: 不完全な構成の問題を解決し、両方のシステム間でピアリングを再設定するには、Oracleのサポートをリクエストします。不完全な構成用に作成されたレプリケーション・ターゲットは、ZFS Storage Applianceから手動で破棄する必要があります。操作の順序は次のとおりです:

両方のシステムからピア接続を削除します。
不完全な構成用に作成されたレプリケーション・ターゲットを手動で破棄します。次の例は、IPアドレスで識別されるターゲットを示しています:
```
TARGET     LABEL                ACTIONS
target-000 LOCAL-PCA_POOL_HIGH  0
target-001 LOCAL-PCA_POOL       0
target-002 192.168.1.43         0
```
両方のシステム間のピア接続を再度作成します。

バグ: 37873134

バージョン: 3.0.2

ストレージ・ハードウェア障害が自動的にクリアされないことがある

フォルト・コードにAK-8003-HFを含むストレージ・ハードウェア障害が発生した場合、フォルト・コード間のデータベースの不一致により、これらのフォルトの自動クリアが正しく機能しない可能性があります。

回避策: PCA 3.0サービス・アドバイザを使用して、Storage Applianceの健全性を確認し、障害が解決されていることを確認します。 Storage Applianceで障害が解決されたが、障害コードがソフトウェア・ヘルス・チェッカにまだ存在する場合は、clearFault id=$faultidコマンドを使用して障害を手動でクリアできます。

PCA-ADMIN> list fault where status EQ ACTIVE                  
Command: list fault where status EQ ACTIVE
Status: Success
Time: 2025-05-28 12:27:31,527 UTC
Data: 
  id                                     Name                                        Status   Severity   
  --                                     ----                                        ------   --------   
  08bec50b-00b8-48df-99bb-fc31cb839e03   sn02AK00684129--AK-8003-HF--vnic7           Active   Major      
  7f7baee8-033d-4912-a759-c31c646bb30d   sn01AK00684129--AK-8003-F9--PCIe 7/NET0     Active   Minor      
  6357a915-bae9-463e-a619-8abf10c59751   sn02AK00684129--AK-8003-F9--PCIe 7/NET0     Active   Minor      
  f2370a63-4dda-470b-98ad-e7f63bf36702   sn02AK00684129--AK-8003-F9--PCIe 7/NET1     Active   Minor      
  06a377c6-2283-c11c-ad4b-90a861380b0f   sn02AK00684129--SPINTEL-8006-CE--DIMM 0/2   Active   Minor      
  e4520a8a-32e1-422f-ac9b-989459aab000   sn02AK00684129--AK-8003-HF--aggr2           Active   Major      
  ff96bce2-4ef5-43f5-9791-e9b4c64e35e8   sn02AK00684129--AK-8003-HF--vnic8           Active   Major      
  3a2f6f38-a062-4205-940f-cda0fc1b19fc   sn01AK00684129--AK-8003-F9--PCIe 7/NET1     Active   Minor      
PCA-ADMIN> show fault id=08bec50b-00b8-48df-99bb-fc31cb839e03
Command: show fault id=08bec50b-00b8-48df-99bb-fc31cb839e03
Status: Success
Time: 2025-05-28 12:27:36,373 UTC
Data: 
  Id = 08bec50b-00b8-48df-99bb-fc31cb839e03
  Type = Fault
  Category = Internal
  Severity = Major
  Status = Active
  Last Update Time = 2025-05-27 14:57:24,752 UTC
  Cause = Network connectivity via datalink vnic7 has been lost.
  Message Id = AK-8003-HF
  Time Reported = 2025-05-27 14:56:52,000 UTC
  Action = Check the networking cable, switch port, and switch configuration.  Contact your vendor for support if the datalink remains inexplicably failed. Please refer to the associated reference document at http://support.oracle.com/msg/AK-8003-HF for the latest service procedures and policies regarding this diagnosis.
  Health Exporter = zfssa-analytics-exportersn02AK00684129
  Uuid = 60e580ca-f410-41f7-a10e-e9f68d8a442c
  Diagnosing Source = zfssa_analytics_exporter
  Upgrade Fault = True
  Faulted Component Type = HARDWARE
  ASR Notification Time = 2025-05-27 14:57:24,748 UTC
  Last Occurrence Activation Time = 2025-05-27 14:57:24,739 UTC
  Last Occurrence Clearing Time = 2025-05-26 11:33:25,611 UTC
  FaultHistoryLogIds 1 = id:a2a2a5f5-13e9-4e7c-bd1f-b09a32de8e36  type:FaultHistoryLog  name:
  FaultHistoryLogIds 2 = id:1f814f6f-24d3-48d3-b289-76d03a8841a5  type:FaultHistoryLog  name:
  FaultHistoryLogIds 3 = id:07ef95a5-fef0-4143-ac02-a1437dfb494d  type:FaultHistoryLog  name:
  BaseManagedObjectId = id:Unknown/vnic7/Unknown  type:HardwareComponent  name:
  Description = Network connectivity via datalink vnic7 has been lost.
  Name = sn02AK00684129--AK-8003-HF--vnic7
  Work State = Normal
PCA-ADMIN> clearFault id=08bec50b-00b8-48df-99bb-fc31cb839e03
Command: clearFault id=08bec50b-00b8-48df-99bb-fc31cb839e03
Status: Success
Time: 2025-05-28 12:27:59,397 UTC
Data: 
  status = Success
PCA-ADMIN> list fault where status EQ ACTIVE                  
Command: list fault where status EQ ACTIVE
Status: Success
Time: 2025-05-28 12:28:04,790 UTC
Data: 
  id                                     Name                                        Status   Severity   
  --                                     ----                                        ------   --------   
  7f7baee8-033d-4912-a759-c31c646bb30d   sn01AK00684129--AK-8003-F9--PCIe 7/NET0     Active   Minor      
  6357a915-bae9-463e-a619-8abf10c59751   sn02AK00684129--AK-8003-F9--PCIe 7/NET0     Active   Minor      
  f2370a63-4dda-470b-98ad-e7f63bf36702   sn02AK00684129--AK-8003-F9--PCIe 7/NET1     Active   Minor      
  06a377c6-2283-c11c-ad4b-90a861380b0f   sn02AK00684129--SPINTEL-8006-CE--DIMM 0/2   Active   Minor      
  e4520a8a-32e1-422f-ac9b-989459aab000   sn02AK00684129--AK-8003-HF--aggr2           Active   Major      
  ff96bce2-4ef5-43f5-9791-e9b4c64e35e8   sn02AK00684129--AK-8003-HF--vnic8           Active   Major      
  3a2f6f38-a062-4205-940f-cda0fc1b19fc   sn01AK00684129--AK-8003-F9--PCIe 7/NET1     Active   Minor      
PCA-ADMIN>

バグ: 37999786

バージョン: 3.0.2

1つのアプライアンスでピア接続を削除すると、システムがアクティブな接続を報告

2つのPrivate Cloud Applianceシステム間のピア接続は、接続の各側から構成する必要があります。いずれかのシステムでピア接続が削除された場合、もう一方のシステムはピアリングがアクティブであることを引き続き報告します。これは正しくありませんが、システムは接続のリモート側の構成状態を追跡できません。

回避策: ピア接続は対称になるように設計されています。一方のシステム上のピア接続を削除する場合は、もう一方のシステムでも削除する必要があります。

バグ: 37262830

バージョン: 3.0.2

DR操作中にDR構成にインスタンスを追加すると、障害が発生

DR操作の進行中は、管理者がDR構成に含まれるコンピュート・インスタンスを変更しないでください。特に、(スイッチオーバー) DR計画の実行と、all=Trueオプションを指定したDR構成へのコンピュート・インスタンスの追加を組み合わせると、エラーが発生する可能性が高くなります。 DR計画の実行が中断され、DR構成間で競合が発生し、ZFS Storage Applianceが過負荷になり、受信リクエストの受入れが停止する可能性があります。

回避策: コンピュート・インスタンスをDR構成に追加する場合、またはDR構成を一般に変更する場合は、DR計画実行が進行中でないことを確認してください。 DR計画を実行する前に、DR構成のインスタンス・リストに対する継続的な更新がないことを確認してください。 all=Trueオプションなど、1回の操作で多数のコンピュート・インスタンスを追加すると、長時間実行されるジョブになります。そのようなジョブがまだ進行中でないことを確認します。また、1つのDR構成に100個以下のコンピュート・インスタンスを追加することをお薦めします。

バグ: 37299009

バージョン: 3.0.2

1つのシステムで高パフォーマンスのストレージ・プールが公開されない場合のピア接続の作成の失敗

2つのOracle Private Cloud Applianceシステム間のピア接続では、各側でローカル・エンドポイントを構成する必要があります。ネイティブのディザスタ・リカバリ(DR)サービスの場合、ローカル・エンドポイント構成に各ストレージ・プールのIPアドレスが含まれている必要があります。システムにオプションの高パフォーマンス・プールがあるが、いずれかのシステムのローカル・エンドポイント構成にそのインタフェースを含めない場合は、ピア接続を作成できません。高パフォーマンス・プールのレプリケーション・ターゲットを作成できないことを示すエラーが返されます。

回避策: 高パフォーマンスのZFSストレージ・プールを含む2つのシステムをピアリングする場合は、各システムにIPアドレスが割り当てられていることを確認し、それぞれのローカル・エンドポイント構成を通じてそれを公開します。両方のパラメータを含める: zfsCapacityPoolEndpointIpおよびzfsPerformancePoolEndpointIp。

バグ: 37316895

バージョン: 3.0.2