既知の問題

詳細: デフォルトのOracle Cloud Infrastructureリゾルバは、パブリックURLエンドポイント(およびパブリック・ホスト名を持つURLエンドポイント)をIPアドレスに解決します。さらに、サブネットは、内部ホスト名(およびプライベート・ホスト名)のURLエンドポイントをIPアドレスに解決するカスタムDNSサーバーを使用して構成できます。ただし、APIゲートウェイ・サービスで作成するAPIゲートウェイは、サブネットからカスタムDNSサーバーを継承しません。かわりに、APIゲートウェイでは、内部/プライベート・ホスト名URLエンドポイントを解決しないデフォルトのOracle Cloud Infrastructureリゾルバが使用されます。

この制限により、HTTPまたはHTTPS URLバック・エンドとして内部/プライベート・ホスト名URLエンドポイントを持つAPIゲートウェイを作成すると、ホスト名をIPアドレスに解決できないため、APIへのコールは失敗します。

回避策: 解決に向けて取り組んでいます。当面は、HTTPまたはHTTPS URLバック・エンドとして内部/プライベートURLエンドポイントを持つAPIゲートウェイを作成する場合に、ホスト名ではなく、URLでホストのIPアドレスを指定する必要があります。また、バック・エンドがHTTPS URLの場合は、コンソールで「SSL検証の無効化」オプションを選択する(またはAPIデプロイメント仕様のJSONファイルにisSSLVerifyDisabled: trueを含める)必要があります。

この問題への直接リンク: APIゲートウェイがサブネットからカスタムDNSサーバーを継承しない

詳細: 合成モニタリングでは、ブラウザおよびスクリプト化ブラウザ・モニターで、フレームを使用するアプリケーションの実行に失敗することがあります。

回避策: 問題を認識しており、解決に取り組んでいます。スクリプト化ブラウザ・モニターの場合、.sideスクリプトのindex=<frame-index>をid=<id-of-frame>またはname=<name-of-frame>に置き換えることで、この問題を回避できます。

たとえば、次のスクリプトが元のバージョンの場合:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "index=0",
      "targets": [
        ["index=0"]
      ],
      "value": ""
    }

次のスクリプトが変更後のバージョンになります:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "id=frame1",
      "targets": [
        ["id=frame1"]
      ],
      "value": ""
    }

この問題への直接リンク: ブラウザおよびスクリプト化ブラウザ・モニターで、フレームを使用するアプリケーションが実行されない場合がある

詳細: apm-domainsリソース・タグに基づく認可ポリシーは、トレース・エクスプローラおよび合成モニタリングAPIでは機能しないため、認可は失敗します。

回避策: 問題を認識しており、解決に取り組んでいます。

この問題への直接リンク: apm-domainsリソース・タグに基づく認可ポリシーに関する問題

詳細: ボールト暗号化キーを使用するよう構成されたボリュームのリージョン間レプリケーションを有効化しようとすると、次のエラー・メッセージが表示されます: ボリュームの編集エラー: ボリューム<volume_ID>ではボールト暗号化キーが使用されているため、リージョン間レプリケーションを有効化できません。

回避策: 解決に向けて取り組んでいます。顧客管理キーで暗号化されたボリュームでは、リージョン間レプリケーションがサポートされません。レプリケーションを有効化するための回避策として、ボリュームからボールト暗号化キーの割当てを解除してください。このシナリオでは、ボリュームはOracle管理キーで暗号化されます。

この問題への直接リンク: 顧客管理キーで暗号化されたボリュームで、リージョン間レプリケーションがサポートされない

詳細: 超高パフォーマンス用に構成されたボリュームの最適なパフォーマンス・レベルを達成するには、ボリューム・アタッチメントがマルチパス対応である必要があります。VMインスタンスに対するマルチパス対応のアタッチメントは、16個以上のOCPUを持つシェイプに基づくインスタンスでのみサポートされます。

16個未満のOCPUを持つインスタンスがある場合、OCPUが16個以上になるようにインスタンスのサイズを変更することで、マルチパス対応のアタッチメントをサポートできます。このステップは、元のOCPU数が8未満でボリューム・アタッチメントが準仮想化されているインスタンスに対しては効果がありません。このシナリオでは、ボリュームがデタッチされて再アタッチされた後、インスタンスがマルチパス対応のアタッチメントをサポートしていても、ボリューム・アタッチメントはマルチパス対応になりません。

回避策: 回避策として、16個以上のOCPUを持つシェイプに基づいて新しいインスタンスを作成してから、ボリュームを新しいインスタンスにアタッチすることをお薦めします。

この問題への直接リンク: インスタンスのサイズ変更後に準仮想化ボリューム・アタッチメントがマルチパス対応ではない

詳細: 最大数のブロック・ボリュームを小さいVM.Standard.A1.Flexインスタンスにアタッチしようとすると、ボリュームのアタッチに失敗する場合があります。これは、基盤となる物理ホスト構成に制限があるために発生します。

回避策: 解決に向けて取り組んでいます。回避策として、VMのサイズ変更によりVMのサイズを拡大してから、ボリュームの接続を再試行することをお薦めします。

この問題への直接リンク: 最大数のブロック・ボリュームを小さいVM.Standard.A1.Flexインスタンスにアタッチすると失敗する場合がある

詳細: ボールト・サービスの暗号化キーを使用して暗号化されたボリュームのリージョン間コピーに対して有効になっているバックアップ・ポリシーを使用して、ボリュームおよびボリューム・グループのバックアップをスケジュールすると、暗号化キーはボリューム・バックアップとともに宛先リージョンにコピーされません。宛先リージョン内のボリューム・バックアップ・コピーは、かわりにOracle提供のキーを使用して暗号化されます。

回避策: 解決に向けて取り組んでいます。回避策として、手動またはスクリプトを使用してボリューム・バックアップおよびボリューム・グループ・バックアップをリージョン間でコピーし、コピー操作のターゲット・リージョンでキー管理キーIDを指定できます。手動でのリージョン間コピーの詳細は、リージョン間でのボリューム・バックアップのコピーを参照してください。

この問題への直接リンク: スケジュール済のリージョン間バックアップ・コピーでボールト暗号化キーが宛先リージョンにコピーされない

詳細: Windowsブート・ボリュームをデータ・ボリュームとして別のインスタンスにアタッチする場合、「ブロック・ボリュームに接続」に示すステップを使用してボリュームに接続しようとすると、ボリュームのアタッチに失敗し、次のエラーが発生する可能性があります:

Connect-IscsiTarget : The target has already been logged in via an iSCSI session.

回避策: コンソールからコピーしたConnect-IscsiTargetコマンドに、次のものを追加する必要があります:

-IsMultipathEnabled $True

この問題への直接リンク: Windowsブート・ボリュームをデータ・ボリュームとして別のインスタンスにアタッチすることは失敗します

詳細: GetInstanceをコールすると、InstanceSourceViaImageDetailsのbootVolumeSizeInGBs属性がnullです。

回避策: 解決に向けて取り組んでいます。この問題を回避するには、GetBootVolumeをコールして、BootVolumeのsizeInGBs属性を使用します。

この問題への直接リンク: bootVolumeSizeInGBs属性がnullです

詳細: Firefoxを使用してコンソールにアクセスしようとした場合、コンソール・ページがブラウザにロードされません。この問題は、Firefoxユーザー・プロファイルの破損が原因であると考えられます。

回避策: 新しいFirefoxユーザー・プロファイルを次のように作成します:

1. Firefoxの最新バージョンを使用していることを確認します。そうでない場合、最新バージョンに更新します。
2. 新しいユーザー・プロファイルを作成し、古いユーザー・プロファイルを削除します。ユーザー・プロファイルを作成および削除する手順は、Mozillaサポートを参照してください: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles。
3. 新しいプロファイルでFirefoxを開きます。

または、他のサポートされているブラウザのいずれかを使用できます。

この問題への直接リンク: Firefoxブラウザのバグにより、コンソールがロードされない場合があります

詳細: ノード・プールで開始する新しいワーカー・ノードのプロパティは、ノード・プールのプロパティに対する最新の変更を反映しません。UpdateNodePoolDetails API操作を使用してノード・プールのプロパティを更新する際に、非推奨のquantityPerSubnetおよびsubnetIds属性が使用されていることが原因となっている可能性があります。

この問題への直接リンク: ワーカー・ノード・プロパティが更新されたノード・プール・プロパティと同期しません

詳細: Kubernetesダッシュボードを起動するとき、状況によっては、"net/http: TLS handshake timeout"や"connection reset by peer"というエラー・メッセージがWebブラウザに表示されることがあります。この問題は、Kubernetesバージョン1.11を実行している新規作成されたクラスタでのみ発生しています。関連するKubernetes問題の詳細は、https://github.com/kubernetes/dashboard/issues/3038を参照してください。

回避策:

1. ターミナル・ウィンドウで入力します:

   $ kubectl -n kube-system port-forward svc/kubernetes-dashboard 8443:443

2. Webブラウザでhttps://localhost:8443に移動します

この問題への直接リンク: Kubernetesダッシュボードを起動できません

詳細: Kubeconfigトークン・バージョン2.0.0を使用してバージョン2.11より前のHelm/Tillerバージョンにアクセスすると、次のいずれかのエラーが発生します:

• Error: Unauthorized
• Error: could not get Kubernetes client: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1beta1"

回避策: Helm /Tillerを次のようにアップグレードします:

1. ターミナル・ウィンドウで、次のコマンドを入力してKubeconfigトークン・バージョン1.0.0をダウンロードします:

   $ oci ce cluster create-kubeconfig --token-version=1.0.0 --cluster-id=<cluster_ocid>

2. クラスタのリージョンでOracle Cloud Infrastructure Registryレジストリの指定に使用するリージョン・キーを識別します(リージョンごとの可用性を参照)。たとえば、クラスタが米国東部(アッシュバーン)にある場合、iadはそのリージョンでレジストリを指定するために使用するリージョン・キーです。

3. 次のコマンドを入力してTillerをアップグレードします:

   $ helm init --upgrade -i <region-key>.ocir.io/odx-oke/oke-public/tiller:v2.14.3

   ここで、<region-key>は前のステップで識別したキーです。

4. ブラウザでhttps://helm.sh/docs/using_helm/#installing-the-helm-clientに移動し、指示に従ってHelmクライアント・バイナリをダウンロードしてインストールします。

5. アップグレードされたHelm/Tillerで、次のコマンドを入力してKubeconfigトークン・バージョン2.0.0をダウンロードします:

   $ oci ce cluster create-kubeconfig --token-version=2.0.0 --cluster-id=<cluster_ocid>

この問題への直接リンク: クラスタ内のHelmにアクセスできません

詳細: Container Engine for Kubernetes 1.8.0リリースには、顧客のワーカー・ノードで実行されているkubeletの暗号強度を向上するためのセキュリティの強化が含まれていました。2019年8月20日から2019年9月16日の間に作成された新しいワーカー・ノードには、この構成が含まれます。新しい暗号セットでは、http/2を介したkubeletへの接続は許可されません。この制限は、メトリック・サーバーと、メトリック・サーバーに依存するHorizontal Pod Autoscalerにも影響します。

回避策:

既存の各ワーカー・ノードで順番に:

1. 新しいポッドが開始されないようにし、kubectl drain <node_name>を入力してワーカー・ノードの既存のポッドを削除します。詳細情報:

   • kubectlの使用については、Kubectlを使用したクラスタへのアクセスを参照してください
   • drainコマンドについては、Kubernetesドキュメントのdrainを参照してください

   推奨: アプリケーションに応じてポッド中断の予算を活用し、ドレイン操作全体を通じて十分な数のレプリカ・ポッドが実行されていることを確認してください。

2. ワーカー・ノードを削除します(たとえば、コンソールで終了します)。
3. 代替ワーカー・ノードが起動するのを待機します。

代替ワーカー・ノードには、kubeletとの通信を可能にする新しい設定が含まれます。

この問題への直接リンク: 一部のKubernetes機能(メトリック・サーバーなど)では、http/2経由でkubeletと通信できません

詳細: クラスタ内のワーカー・ノードで新しいポッドが起動すると、状況によってはタイムアウトが原因でポッドがノードにアタッチされたすべてのボリュームのマウントに失敗し、次のようなメッセージが表示されます:

Unable to mount volumes for pod "<pod_name>(<pod_uid>)": timeout expired waiting for volumes to attach or mount for pod "<namespace>"/"<pod_name>". list of unmounted volumes=[<failed_volume>]. list of unattached volumes=[<… list of volumes >]

この問題に対して特定されている考えられる原因の1つは、ポッド仕様のsecurityContextフィールドにfsGroupフィールドが含まれている場合です。コンテナが非rootユーザーとしてワーカー・ノードで実行されている場合、securityContextのfsGroupフィールドを設定すると、Kubernetesが所有権を変更する必要があるファイルの数が原因でタイムアウトが発生する可能性があります(https://github.com/kubernetes/kubernetes/issues/67014を参照)。

ポッド仕様のsecurityContextにfsgroupフィールドが含まれていない場合、原因は不明です。

回避策:

ポッド仕様のsecurityContextにfsgroupフィールドが含まれていて、コンテナが非rootユーザーで実行されている場合は、次の回避策を検討してください:

• securityContextからfsgroupフィールドを削除します。
• (fsgroupのかわりに) securityContextのsupplementalGroupsフィールドを使用し、supplementalGroupsをボリューム識別子に設定します。
• コンテナがルートとして実行されるようにポッド仕様を変更します。

ポッド仕様のsecurityContextにfsgroupフィールドが含まれていないか、コンテナがすでにrootとして実行されている場合は、ワーカー・ノードを再起動または置換する必要があります。たとえば、インスタンスを停止して起動するか、インスタンスを再起動するか、インスタンスを終了して新しいインスタンスを起動します。必要に応じて、インスタンスの停止、起動または再起動またはインスタンスの終了の手順に従って、コンソールまたはAPIを使用します。または、次の例のようなCLIコマンドを使用してインスタンスを終了することもできます:

$ INSTANCE_OCID=$(kubectl get node <name> -ojsonpath='{.spec.providerID}')
$ oci compute instance terminate --instance-id $INSTANCE_OCID

<name>は、インスタンスの「プライベートIPアドレス」プロパティから導出されたワーカー・ノード名です(たとえば、10.0.10.5)。

この問題への直接リンク: タイムアウトが原因でKubernetesポッドがボリュームのマウントに失敗します

詳細: OS管理サービスを使用してOracle Cloud Infrastructureインスタンス上でオペレーティング・システムの更新およびパッチを管理する場合、Container Engine for Kubernetesによって作成されたクラスタ・ノード・プールがオンラインにならない状況が発生することがあります。

回避策:

2つの回避策が考えられます:

• 回避策1: OS管理を使用してOracle Cloud Infrastructureインスタンスを管理する場合は、OS管理でOracle Enterprise Linuxを有効にします。ソフトウェア・ソースの管理を参照してください。
• 回避策2: OS管理を使用してOracle Cloud Infrastructureインスタンスを管理しない場合は、OS管理の実行を許可するポリシーが存在しないことを確認してください。具体的には、インスタンスの動的グループにOS管理サービスへのアクセス権を付与するポリシーを削除します。OS管理のポリシーの設定を参照してください。

この問題への直接リンク: OS管理によってKubernetesクラスタ・ノード・プールが失敗する

詳細: Kubernetesバージョン1.19 (またはそれ以降)を実行しているマスター・ノードと、Kubernetesバージョン1.18 (またはそれ以前)を実行しているワーカー・ノードがノード・プールに含まれる場合、FlexVolumeボリューム・プラグインを使用してクラスタにアタッチされたマウント・ブロック・ボリュームが期待どおりに動作しないことがあります。たとえば、次のように表示されます:

• ブロック・ボリュームが正常にアタッチされても、ワーカー・ノードでポッドが実行されている場合は、FailedMount警告メッセージが表示されます。
• ワーカー・ノードで実行されているkubeletのログ内に、Volume not attached according to node status for volumeというエラー・メッセージが表示されます。

回避策:

1. Kubernetesバージョン1.19 (またはそれ以降)を実行しているワーカー・ノードを含むノード・プールがクラスタにまだ存在していない場合は、ここでそのようなノード・プールを追加します。
2. 次のように、Kubernetesバージョン1.18 (またはそれ以前)を実行している、影響を受けるワーカー・ノードを削除します:
   1. 新しいポッドが開始されないようにし、kubectl drain <node_name>を入力して、影響を受けるワーカー・ノードの既存のポッドを削除します。詳細情報:
      • kubectlの使用については、Kubectlを使用したクラスタへのアクセスを参照してください
      • drainコマンドについては、Kubernetesドキュメントのdrainを参照してください
   2. 影響を受けるワーカー・ノードを削除します(たとえば、コンソールで終了します)。

この問題への直接リンク: Kubernetesバージョン1.19 (またはそれ以降)を実行しているマスター・ノードと、Kubernetesバージョン1.18 (またはそれ以前)を実行しているワーカー・ノードを含むノード・プールでのボリューム・マウントの問題

/ # nslookup www.oracle.com
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; connection timed out; no servers could be reached 

sudo /usr/sbin/lsmod | grep br_netfilter 

結果が返されない場合は、Bridge Netfilterカーネル・モジュールが有効になっていません。Bridge Netfilterカーネル・モジュールは、KubernetesポッドのVxLANトラフィックをマスカレードするために必要です。

sudo modprobe br_netfilter 
sudo sh -c 'echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf'

この問題への直接リンク: DNS (nslookup、digまたはcurl)による問題の解決

詳細: VCNネイティブ・ポッド・ネットワークを使用している場合、ポッドへのインバウンド・リクエストのソース・クライアントIPアドレスが予想どおりに保持されないことがあります。かわりに、マニフェスト・ファイルでexternalTrafficPolicy: Localが設定されているLoadBalancerタイプのKubernetesサービスを介して受信したインバウンド・リクエストは、ワーカー・ノードのIPアドレスから送信されたものとして表示される場合があります。

回避策: マニフェスト・ファイルにoci.oraclecloud.com/load-balancer-type: "lb"注釈があるLoadBalancerタイプのKubernetesサービスを介して受信したインバウンドTCPリクエストの場合、X-Forwarded-ForまたはX-Real-IPヘッダーからソース・クライアントIPアドレスを取得します。

この問題への直接リンク: externalTrafficPolicy: Localを使用するLoadBalancerサービスを介したトラフィックのソース・クライアントIPが保持されない

詳細: VCNネイティブ・ポッド・ネットワークを使用している場合、クラスタ内の1つ以上のノード・プールのワーカー・ノードにベア・メタル・シェイプを指定すると、ポッドはネットワーク経由で通信できない可能性があります。

回避策: VCNネイティブ・ポッド・ネットワークを使用している場合、クラスタ内のすべてのノード・プールのワーカー・ノードにVMシェイプを指定します。

この問題への直接リンク: ベア・メタル・インスタンスでのポッド・ネットワーク接続の問題

詳細: VCNネイティブ・ポッド・ネットワークを使用している場合、ノード・プールに選択したフレキシブル・シェイプに指定したOCPUの数に関係なく、ノード・プールのワーカー・ノード当たりのポッドの最大数は31に制限されることがあります。

回避策: ノード・プールのワーカー・ノード当たり31個を超えるポッドが必要な場合は、ノード・プールのワーカー・ノードに別のシェイプを選択します。

この問題への直接リンク: フレキシブル・シェイプのノード当たりの最大ポッド数の制限が正しくない

詳細: VCNネイティブ・ポッド・ネットワークを使用している場合、VCNに指定された最初のCIDRブロック外のCIDRブロックを持つポッド・サブネットに接続されているワーカー・ノードで実行されているポッドは、Kubernetesサービスと通信できない可能性があります。

回避策: VCNに指定された最初のCIDRブロック内にCIDRブロックを持つポッド・サブネットを作成します。

この問題への直接リンク: CIDRブロックが追加されたVCNでのポッド・ネットワーク接続の問題

詳細: Node Doctorスクリプトを使用してノードの問題をトラブルシューティングする場合、スクリプトに次のような例外エラー・メッセージが表示されることがあります:

FileNotFoundError: [Errno 2] No such file or directory: ’/home/opc/vendor/pip…

Node Doctorスクリプトは引き続き実行され、メッセージGenerating node doctor bundleが表示されてトラブルシューティング出力が生成されます。

回避策: 問題を認識しており、解決に取り組んでいます。その間、Node DoctorスクリプトでメッセージGenerating node doctor bundleが表示される場合は、トラブルシューティング出力がまだ有効であることに注意してください。

Node DoctorスクリプトでFileNotFoundError: [Errno 2]...例外エラー・メッセージが表示されないようにする場合は、次のように入力してNode Doctorスクリプトを更新します:

node-doctor.sh --update

Node Doctorスクリプトとその更新方法の詳細は、Node Doctorスクリプトを使用したKubernetesクラスタのノード問題のトラブルシューティングを参照してください。

この問題への直接リンク: Node Doctorスクリプトで、FileNotFoundError: [Errno 2] exceptionと表示されます

詳細: クラスタでVCNネイティブ・ポッド・ネットワーキングが使用され、ワークロード・ポッドとCoreDNSポッドの両方が同じワーカー・ノードで実行されている場合、トラフィックが誤ってNATedであるため、DNS解決が失敗することがあります。

解決策: 2023年3月21日に、この問題を解決したOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新がリリースされました。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新の手順に従って、更新をデプロイします。

この問題への直接リンク: 解決済: VCNネイティブ・ポッド・ネットワーキングを使用するクラスタでDNS解決が失敗することがある

詳細: クラスタがVCNネイティブ・ポッド・ネットワーキングを使用し、ワーカー・ノードがOracle Linux 8 (OL8)を実行している場合、ワーカー・ノードの1つでポッドの起動に失敗することがあります。この問題の特性は次のとおりです:

• ワーカー・ノードがOL8イメージを実行しています。
• ホスト・ネットワーク関連のポッドはワーカー・ノードで予期したとおりに実行されますが、他のすべてのポッドは起動に失敗します。
• crictlログには、メッセージAdding address to IPVLAN parent device (IPアドレスがワーカー・ノードのセカンダリVNICにアタッチされていることを示す)が含まれ、その後にエラー・メッセージError adding secondary VNIC IPが続きます。
• ワーカー・ノードでLinux IP addressコマンドを実行すると、1つ(または複数)のセカンダリVNICにIPアドレスがアタッチされていないことが示されます。
• その他すべて(またはほとんど)のワーカー・ノードは期待どおりに動作しています。

この問題で特定される可能性の高い原因は、ネットワーク・デバイスおよび接続を管理するNetworkManagerに関連しています。場合によっては、NetworkManagerによって、1つ以上のワーカー・ノードのセカンダリVNICにアタッチされているIPアドレスがデタッチされ、OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインが失敗します。

解決策: 2023年3月21日に、この問題を解決したOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新がリリースされました。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新の手順に従って、更新をデプロイします。

この問題への直接リンク: 解決済: VCNネイティブ・ポッド・ネットワーキングを使用するクラスタで、Oracle Linux 8を実行しているワーカー・ノードでのポッドの起動に失敗することがある

詳細:ノード・プールにOracle Linux 8.7またはOracle Linux 8.8を指定した場合(Oracle Linux 8.7またはOracle Linux 8.8プラットフォーム・イメージ、またはOracle Linux 8.7またはOracle Linux 8.8上に構築されたOKEワーカー・ノード・イメージを選択)、ノード・プールのワーカー・ノードのステータスが予期せずNotReadyに変更される可能性があります。この問題の特性は次のとおりです:

• ワーカー・ノードでは、Oracle Linux 8.7またはOracle Linux 8.8が実行されています。
• ワーカー・ノードでは、Kubernetesバージョン1.24.1、1.25.4または1.26.2が実行されています。(Kubernetesバージョン1.25.12、1.26.7および1.27を実行しているワーカー・ノードは影響を受けません。)
• 存続期間の短いポッドはワーカー・ノードに頻繁にデプロイされます。
• ノード・プールのワーカー・ノードにデプロイされたポッドは、予想より長くContainerCreatingステータスのままになることもあります。

回避策: 問題を認識しており、解決に取り組んでいます。

その間に、この問題が発生した場合は、次の回避策のうち要件に最も適したものを使用してください:

• ノード・プールのOracle Linux 7イメージを指定します。
• ノード・プールのOracle Linux 8.6イメージ(または以前のOracle Linux 8イメージ)を指定します。
• ノード・プールの新しいバージョンのKubernetesを指定します。(Kubernetesバージョン1.25.12、1.26.7および1.27を実行しているワーカー・ノードは影響を受けません。)

コンソールに表示されなくなったイメージのOCIDを取得するには:

• プラットフォーム・イメージ: すべてのOracle Linux 7.xイメージおよびすべてのOracle Linux 8.xイメージを参照してください
• OKEワーカー・ノードのイメージ: OKEワーカー・ノードのすべてのOracle Linux 7.xイメージおよびOKEワーカー・ノードのすべてのOracle Linux 8.xイメージを参照してください

この問題への直接リンク: Kubernetesバージョン1.24.1、1.25.4または1.26.2でOracle Linux 8.7またはOracle Linux 8.8を実行している場合、ワーカー・ノードのステータスがNotReadyに予期せず変化します

詳細: VCNネイティブのポッド・ネットワーキングを使用する2023年6月26日より前に作成されたクラスタでは、新しいワーカー・ノードのプロビジョニングに遅延が表示される場合があります。

OCI VCN-Native Pod Networking CNIプラグインを使用してワーカー・ノードをブートストラップする場合、Container Engine for Kubernetesは、各コンピュート・インスタンスにKubernetesカスタム・リソース(NativePodNetworkまたはNPN、リソース)をデプロイします。ワーカー・ノードが正常にブートストラップされると、Container Engine for Kubernetesによって、コンピュート・インスタンスに関連付けられたNPNリソースにSUCCESSのステータスが付与されます。

場合によっては、コンピュート・インスタンスがContainer Engine for Kubernetesが関連付けられたNPNリソースにSUCCESSのステータスを付与する前に終了した場合、NPNリソースは無期限にBACKOFFまたはIN_PROGRESSステータスのままになります。このような失効したリソースが存在すると、新しいワーカー・ノードのプロビジョニングが遅延する可能性があります。

解決:この問題は、2023-06-26の後に作成されたクラスタで修正されています。2023-06-26より前に作成されたクラスタの問題を解決するには、この項の手順に従って、1回かぎりのアクションを実行して古いリソースを削除します。

開始する前に、システムが次の前提条件を満たしていることを確認してください。

• OCI CLIがインストールされている(CLIのインストールを参照)
• OCI CLIが構成されていること(CLIの構成を参照)
• jqがダウンロードされ、インストールされました(https://jqlang.github.io/jq/download/を参照)
• Allow group <group-name> to manage instance-family in <location>など、少なくともINSTANCE_READ権限を付与するIAMポリシーが存在します(グループに必要なポリシーの作成を参照)
• 適切なkubeconfigファイルにアクセスして、kubectlを使用してOCI VCN-Native Pod Networking CNIプラグインを使用するクラスタを管理できるようにします(Kubectlを使用したクラスタへのアクセスを参照)

失効したリソースを次のように特定して削除します。

1. システムがすべての前提条件を満たしていることを検証します。
   1. 次のスクリプトをpre-req-check.shという名前のファイルに保存します。

      #!/bin/bash
      echo Validating cluster access to get npn resources
      ACTIVE_RESOURCES=($(kubectl get npn -o json | jq '[.items[] | select(.status.state == "SUCCESS")]' | jq -r '.[] | .metadata.name'))
      if [[ -z "$ACTIVE_RESOURCES" ]] || [ ${#ACTIVE_RESOURCES[@]} == 0 ]
      then
        echo No active NPN resources found. Make sure you have cluster access and this is an OCI VCN-Native CNI cluster. '\'nPlease check prerequisites and retry.
        exit
      fi
       
      cr_name=${ACTIVE_RESOURCES[0]}
      echo Validating access to get compute instance
      INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
      INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
       
      if [[ -z "$INSTANCE_STATE" ]]
      then
        echo Unable to get instance details, please check prerequisites and retry.
      else
        echo All prerequisites in place, please proceed to cleaning up stale resources.
      fi

   2. 次のように入力して、pre-req-check.shスクリプトを実行します:

      sh pre-req-check.sh

2. ステータスがSUCCESSでないために削除可能なNPNリソースを識別します。
   1. 次のように入力して、SUCCESSのステータスを持たないNPNリソースのリストを potential_stale_resources.txtという名前のテキスト・ファイルに出力します。

      kubectl get npn -o json | jq '[.items[] | select(.status.state != "SUCCESS")]' | jq -r '.[] | .metadata.name' >> potential_stale_resources.txt

   2. オプションで、次のように入力して、potential_stale_resources.txtの候補となるNPNリソースのリストを表示します。

      cat potential_stale_resources.txt

      たとえば、potential_stale_resources.txtには次のものが含まれます。

      anyhqljth4...trq
      anyhqljth4...snq
      anyhqljth4...qhq

3. 使用できない、または終了したコンピュート・インスタンスに関連付けられている候補NPNリソースを決定することで、削除する失効したNPNリソースを特定します。
   1. 次のスクリプトをget_stale_resources.shという名前のファイルに保存します。

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read  -r cr_name
      do
        echo verifying NPN resource $cr_name
        INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
        if [  -z $INSTANCE_ID ]
        then
          echo Unable to get npn resource details. Please check prerequisites and retry from step 2.
          exit
        fi
        echo Associated instance is $INSTANCE_ID
        INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
        if [  -z $INSTANCE_STATE ]
        then
          # check for 404 for tombstoned instances
          STATUS=$(oci compute instance get --instance-id $INSTANCE_ID 2>&1 | tail -n +2 | jq .status)
          if [ $STATUS == 404 ]
          then
            echo 404 getting instance $INSTANCE_ID, Instance has been tombstoned. Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          fi
        else
          echo Instance $INSTANCE_ID in $INSTANCE_STATE state
          if [ $INSTANCE_STATE == "TERMINATED" ]
          then
            echo Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          else
            echo Instance $INSTANCE_ID not terminated. '\'nSkipping resource $cr_name '\'n
          fi
        fi
      done < $1

   2. 次のように入力して、get_stale_resources.shスクリプトを実行します:

      sh get_stale_resources.sh potential_stale_resources.txt

      get_stale_resources.shスクリプトは、削除する失効したNPNリソースを識別し、処理メッセージを画面に出力し、失効したNPNリソースの名前をstale_resources.txtという名前のファイルに書き込みます。例:

      Reading resources from potential_stale_resources.txt
      verifying NPN resource anyhqljth4...trq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...trq
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq in RUNNING state
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq not terminated.
      Skipping resource anyhqljth4...trq
       
      verifying NPN resource anyhqljth4...snq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...snq
      Instance ocid1.instance.oc1.phx.anyhqljth4...snq in TERMINATED state
      Adding resource anyhqljth4...snq to stale_resources
       
      verifying NPN resource anyhqljth4...qhq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...qhq
      ServiceError:
      {
          "client_version": "Oracle-PythonSDK/2.104.2, Oracle-PythonCLI/3.29.0",
          "code": "NotAuthorizedOrNotFound",
          "logging_tips": "Please run the OCI CLI command using --debug flag to find more debug information.",
          "message": "instance ocid1.instance.oc1.phx.anyhqljth4...qhq not found",
          "opc-request-id": "CCB8D1925...38ECB8",
          "operation_name": "get_instance",
          "request_endpoint": "GET https://iaas.us-phoenix-1.oraclecloud.com/20160918/instances/ocid1.instance.oc1.phx.anyhqljth4...qhq",
          "status": 404,
          "target_service": "compute",
          "timestamp": "2023-06-27T20:24:28.992241+00:00",
          "troubleshooting_tips": "See [https://docs.oracle.com/iaas/Content/API/References/apierrors.htm] for more information about resolving this error. If you are unable to resolve this issue, run this CLI command with --debug option and contact Oracle support and provide them the full error message."
      }
      404 getting instance ocid1.instance.oc1.phx.anyhqljth4...qhq, Instance has been tombstoned
      Adding resource anyhqljth4...qhq to stale_resources

   3. オプションで、次のように入力して、stale_resources.txt内の失効したNPNリソースのリストを表示します:

      cat stale_resources.txt

      たとえば、stale_resources.txtには次のものが含まれます。

      anyhqljth4...snq
      anyhqljth4...qhq

4. stale_resources.txtファイルにリストされている失効したNPNリソースを削除します。
   1. 次のスクリプトをdelete_stale_resources.shという名前のファイルに保存します。

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read -r cr_name
      do
          echo Deleting $cr_name
          kubectl delete npn $cr_name
      done < $1

   2. 次のように入力して、delete_stale_resources.shスクリプトを実行します:

      sh delete_stale_resources.sh stale_resources.txt

      delete_stale_resources.shスクリプトは、stale_resources.txtファイルにリストされている失効したNPNリソースを削除し、処理メッセージを画面に出力します。例:

      Reading resources from stale_resources.txt
      Deleting anyhqljth4...snq
      nativepodnetwork.oci.oraclecloud.com "anyhqljth4...snq" deleted

5. ハウスキーピングの適切な方法として、前に作成したstale_resources.txtおよびpotential_stale_resources.txtファイルを削除します。

この問題への直接リンク: VCNネイティブ・ポッド・ネットワーキングを使用したクラスタでの新規ワーカー・ノードのプロビジョニングには、予想よりも時間がかかります

詳細:仮想ノードのArmシェイプを指定すると、ノード上でスケジュールされたポッドが、意図したとおりにArmプロセッサで実行されます。ただし、kubectl describe nodeコマンドまたはKubernetes APIを使用して仮想ノードを確認した場合、ノードでスケジュールされたポッドがArmプロセッサで実行されていても、ノードのアーキテクチャ・プロパティにはAMD64と表示されます。

回避策: 問題を認識しており、解決に取り組んでいます。

一方、この問題が発生した場合は、仮想ノードの「アーキテクチャ」プロパティーの値を無視します。

この問題への直接リンク: Armプロセッサで実行するようにスケジュールされたポッドの場合、AMD64として表示される仮想ノード・アーキテクチャ

詳細: 新しく作成されたデータベースに既存のPDBは表示されません。また、コンソールに表示されるまでに数時間かかる場合があります。これには、新規データベースの場合はデフォルトのPDBが含まれ、クローニングまたはリストアされたデータベースの場合は既存のPDBが含まれます。旧バージョンへのインプレース・リストアの場合、PDBリストは同様に更新され、遅延が発生する可能性があります。

回避策: なし

この問題への直接リンク: 新規データベース内の既存のPDB

詳細: コンソールまたはAPIでは、プライマリ・データベースでのPDBの作成およびクローニングは許可されていません。

回避策: プライマリ・データベースでのPDBの作成またはクローニングには、sqlplusを使用できます。これらは後でOCIコンソールで同期されます。

この問題への直接リンク: 既存のData Guard構成におけるPDB

詳細: データベース・サービスAPIを使用して、Oracle Database 12cリリース1 (12.1.0.2)でファイルベースのTDEウォレットを顧客管理キーベースのTDEウォレットに移行すると、次のエラーで失敗します:

[FATAL] [DBAAS-11014] - 必要なパッチ(30128047)がOracleホーム<ORACLE_HOME>に存在しません。
処置: 必要なパッチ(30128047)を適用し、操作を再試行してください

nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

前述のコマンドの<kms_key_ocid>は、使用している顧客管理キーのOCIDです。

詳細: データベース・サービスAPIを使用して、Oracle Database 12cリリース1 (12.1.0.2)で顧客管理キーベースのTDEウォレットをファイルベースのTDEウォレットに移行すると、次のエラーで失敗します:

[FATAL] [DBAAS-11014] - 必要なパッチ(30128047)がOracleホーム<ORACLE_HOME>に存在しません。
処置: 必要なパッチ(30128047)を適用し、操作を再試行してください

nohup /var/opt/oracle/dbaascli/dbaascli tde hsm_to_file --dbname <database_name> --skip_patch_check true &

詳細: データベース・サービスAPIを使用して、Oracle Database 12cリリース2 (12.2.0.1)でファイルベースのTDEウォレットを顧客管理キーベースのTDEウォレットに移行すると、次のエラーで失敗します:

[FATAL] [DBAAS-11014] - 必要なパッチ(30128047)がOracleホーム<ORACLE_HOME>に存在しません。
処置: 必要なパッチ(30128047)を適用し、操作を再試行してください

回避策: 次のように、ファイルベースのTDEウォレットを顧客管理キーベースのTDEウォレットに移行します:

1. 次のように、データベースでいずれかのAutonomous DatabaseまたはCDB$ROOTのUNDO表領域またはTEMP表領域が暗号化されているかどうかを確認します:
   CDB$ROOTから次の問合せを実行して、すべてのAutonomous Databaseに含まれているすべての暗号化された表領域をリストします:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   次に、問合せの結果の「NAME」列で、UNDO表領域およびTEMP表領域の名前を検索します。暗号化されたUNDO表領域またはTEMP表領域がある場合は、次のステップに進みます。

2. 次のように、UNDO表領域またはTEMP表領域を暗号化解除します:

   UNDO表領域が暗号化されている場合

   次のように、既存のUNDO表領域を暗号化解除します:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   暗号化されたすべてのUNDO表領域に対して、この手順を繰り返します。

   TEMP表領域が暗号化されている場合

   1. 次のように、デフォルトのTEMP表領域を確認します:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      デフォルトのTEMP表領域は暗号化されていないが、他のTEMP表領域が暗号化されている場合は、次のように、他のTEMP表領域を削除します:

      SQL> drop tablespace <temp_tablespace_name>;

      この手順の残りのステップはスキップします。

      デフォルトのTEMP表領域が暗号化されている場合は、残りの手順に進み、暗号化されていないデフォルトのTEMP表領域を作成および設定します。

   2. 次のように、encrypt_new_tablespacesパラメータをDDLに設定します:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. 次のように、現在のTEMP表領域の仕様でTEMP表領域を作成します:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. 次のように、新しいTEMP表領域をデータベースのデフォルトのTEMP表領域として設定します:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. 次のように、既存のTEMP表領域を削除します:

      SQL> drop tablespace <temp_tablespace_name>;

   暗号化されたすべてのTEMP表領域に対して、この手順を繰り返します。

   データベースは、暗号化されていないデフォルトのUNDO表領域およびTEMP表領域で実行され、古いTEMP表領域およびUNDO表領域も復号化されます。

   次のように、encrypt_new_tablespacesを元の値に設定します:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   顧客管理キーへのキーストアの移行に進みます。

3. いずれのプラガブル・データベースにもCDB$ROOTにも暗号化されたUNDO表領域またはTEMP表領域がないことを確認したら、DBAASCLIユーティリティを--skip_patch_check trueフラグとともに使用して、バグ30128047のパッチの検証をスキップします。Oracleホームでバグ31527103のパッチが適用されていることを確認してから、次のdbaascliコマンドを実行します:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   前述のコマンドの<kms_key_ocid>は、使用している顧客管理キーのOCIDです。

詳細: データベース・サービスAPIを使用して、Oracle Database 12cリリース2 (12.2.0.1)で顧客管理キーベースのTDEウォレットをファイルベースのTDEウォレットに移行すると、次のエラーで失敗します:

[FATAL] [DBAAS-11014] - 必要なパッチ(30128047)がOracleホーム<ORACLE_HOME>に存在しません。
処置: 必要なパッチ(30128047)を適用し、操作を再試行してください

回避策: 次のように、顧客管理キーベースのTDEウォレットをファイルベースのTDEウォレットに移行します:

1. 次のように、データベースでいずれかのAutonomous DatabaseまたはCDB$ROOTのUNDO表領域またはTEMP表領域が暗号化されているかどうかを確認します:
   CDB$ROOTから次の問合せを実行して、すべてのAutonomous Databaseに含まれているすべての暗号化された表領域をリストします:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   次に、問合せの結果の「NAME」列で、UNDO表領域およびTEMP表領域の名前を検索します。暗号化されたUNDO表領域またはTEMP表領域がある場合は、次のステップに進みます。

2. 次のように、UNDO表領域またはTEMP表領域を暗号化解除します:

   UNDO表領域が暗号化されている場合

   次のように、既存のUNDO表領域を暗号化解除します:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   暗号化されたすべてのUNDO表領域に対して、この手順を繰り返します。

   TEMP表領域が暗号化されている場合

   1. 次のように、デフォルトのTEMP表領域を確認します:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      デフォルトのTEMP表領域は暗号化されていないが、他のTEMP表領域が暗号化されている場合は、次のように、他のTEMP表領域を削除します:

      SQL> drop tablespace <temp_tablespace_name>;

      この手順の残りのステップはスキップします。

      デフォルトのTEMP表領域が暗号化されている場合は、残りの手順に進み、暗号化されていないデフォルトのTEMP表領域を作成および設定します。

   2. 次のように、encrypt_new_tablespacesパラメータをDDLに設定します:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. 次のように、現在のTEMP表領域の仕様でTEMP表領域を作成します:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. 次のように、新しいTEMP表領域をデータベースのデフォルトのTEMP表領域として設定します:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. 次のように、既存のTEMP表領域を削除します:

      SQL> drop tablespace <temp_tablespace_name>;

   暗号化されたすべてのTEMP表領域に対して、この手順を繰り返します。

   データベースは、暗号化されていないデフォルトのUNDO表領域およびTEMP表領域で実行され、古いTEMP表領域およびUNDO表領域も復号化されます。

   次のように、encrypt_new_tablespacesを元の値に設定します:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   顧客管理キーへのキーストアの移行に進みます。

3. いずれのプラガブル・データベースにもCDB$ROOTにも暗号化されたUNDO表領域またはTEMP表領域がないことを確認したら、DBAASCLIユーティリティを--skip_patch_check trueフラグとともに使用して、バグ30128047のパッチの検証をスキップします。Oracleホームでバグ29667994のパッチが適用されていることを確認してから、次のdbaascliコマンドを実行します:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   前述のコマンドの<kms_key_ocid>は、使用している顧客管理キーのOCIDです。

詳細: BYOLから付属のライセンスに、またはその逆にデータベースまたはDBシステムのライセンス・タイプを変更すると、最初の1時間は両方のタイプのライセンスに対して請求されます。その後は、更新されたライセンス・タイプに従って請求されます。

回避策: 解決に向けて取り組んでいます。

この問題への直接リンク: ライセンス・タイプ変更時の請求の問題

詳細: サービス・ゲートウェイを使用してVCNを構成する場合、プライベート・サブネットによって、OSの更新に必要なYUMリポジトリへのアクセスがブロックされます。この問題は、すべてのタイプのDBシステムに影響を与えます。

回避策: この問題は解決されました。問題の解決前に推奨されていた回避策は次のとおりです:

Oracle Services Networkのすべての<region>サービスという使用可能なサービスCIDRラベルを使用すると、サービス・ゲートウェイによりOracle YUMリポジトリへのアクセスが可能になります。ただし、サービス・ゲートウェイを介してYUMサービスにアクセスする場合は引き続き問題が発生する可能性があります。この問題には解決策があります。詳細は、サービス・ゲートウェイを介してインスタンスがOracle yumサービスにアクセスする際の問題を参照してください。

この問題への直接リンク: サービス・ゲートウェイでは、現在OSの更新がサポートされていません

詳細: データベースCLI (dbcli)またはRMANを使用したオブジェクト・ストレージへの管理対象外のバックアップが次のエラーで失敗します:

-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

Symantec証明書に関して、2つの共通のWebブラウザによって実装されるポリシーに従い、Oracleでは、Oracle Cloud Infrastructureで使用される認証局が最近変更されました。SSL証明書が変更された結果、Oracle Database Cloud Backupモジュールが古い証明書をまだ参照していると、オブジェクト・ストレージへのバックアップが失敗する可能性があります。

dbcliの回避策: ログ・ファイルで、リストされたエラーを確認し、見つかった場合はバックアップ・モジュールを更新します。

RMANのバックアップ・ログ・ファイルで前述のエラーを確認します:

1. 失敗したバックアップ・ジョブのIDを確認します。

   dbcli list-jobs

   この出力例では、失敗したバックアップ・ジョブのIDは、"f59d8470-6c37-49e4-a372-4788c984ea59"です。

   root@<node name> ~]# dbcli list-jobs
    
   ID                                       Description                                                                 Created                             Status
   ---------------------------------------- --------------------------------------------------------------------------- ----------------------------------- ----------
   cbe852de-c0f3-4807-85e8-7523647ec78c     Authentication key update for DCS_ADMIN                                     March 30, 2018 4:10:21 AM UTC       Success
   db83fdc4-5245-4307-88a7-178f8a0efa48     Provisioning service creation                                               March 30, 2018 4:12:01 AM UTC       Success
   c1511a7a-3c2e-4e42-9520-f156b1b4cf0e     SSH keys update                                                             March 30, 2018 4:48:24 AM UTC       Success
   22adf146-9779-4a2c-8682-7fd04d7520b2     SSH key delete                                                              March 30, 2018 4:50:02 AM UTC       Success
   6f2be750-9823-4ed5-b5ff-8e49f136dd22     create object store:bV0wqIaoLA4xLT4dGjOu                                    March 30, 2018 5:33:38 AM UTC       Success
   0716f464-1a10-40df-a303-cadee0302b1b     create backup config:bV0wqIaoLA4xLT4dGjOu_BC                                March 30, 2018 5:33:49 AM UTC       Success
   e08b21c3-cd09-4e3a-944c-d1da96cb21d8     update database : hfdb1                                                     March 30, 2018 5:34:04 AM UTC       Success
   1c3d7c58-79c3-4039-8f48-787057ce7c6e     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:37:11 AM UTC       Success
   f59d8470-6c37-49e4-a372-4788c984ea59     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:43:45 AM UTC       Failure

2. 失敗したジョブのIDを使用して、確認するログ・ファイルの場所を取得します。

   
   dbcli describe-job -i <failed_job_ID>

   describe-jobコマンドからの関連出力は次のようになります:

   Message: DCS-10001:Internal error encountered: Failed to run Rman statement.
   Refer log in Node <node_name>: /opt/oracle/dcs/log/<node_name>/rman/bkup/<db_unique_name>/rman_backup/<date>/rman_backup_<date>.log.

Oracle Database Cloud Backupモジュールを更新します:

1. データベースがバックアップに使用するSwiftのオブジェクト・ストアIDおよびユーザーを確認します。

   1. dbcli list-databasesコマンドを実行して、データベースのIDを確認します。

   2. データベースIDを使用して、バックアップ構成ID (backupConfigId)を確認します。

      dbcli list-databases
      dbcli describe-database -i <database_ID> -j

   3. 前のステップでメモしたバックアップ構成IDを使用して、オブジェクト・ストアID (objectStoreId)を確認します。

      dbcli list-backupconfigs
      dbcli describe-backupconfig –i <backupconfig_ID> -j

   4. 前のステップでメモしたオブジェクト・ストアIDを使用して、オブジェクト・ストア・ユーザー(userName)を確認します。

      dbcli list-objectstoreswifts
      dbcli describe-objectstoreswift –i <objectstore_ID> -j

2. ステップ1で取得したオブジェクト・ストア資格証明を使用して、バックアップ・モジュールを更新します。

   dbcli update-objectstoreswift –i <objectstore_ID> -p –u <user_name>

RMANの回避策: RMANのログ・ファイルで、リストされたエラー・メッセージを確認します。見つかった場合は、oracleユーザーとしてホストにログオンし、Swiftの資格証明を使用してバックアップ・モジュールを再インストールします。

java -jar <opc_install.jar_path> -opcId '<swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

マルチノードDBシステムでは、クラスタ内のすべてのノードで回避策を実行してください。

このコマンドの使用方法の詳細は、Oracle Database Cloud Backupモジュールに関するドキュメントを参照してください。

この問題への直接リンク: dbcliまたはRMANを使用したオブジェクト・ストレージへのバックアップが証明書の変更のために失敗します

詳細: 2018年10月18日にリリースされたSDKでは、データベース・サイズとデータベース・バックアップAPIのデータベース・エディション属性の重大な変更が導入されています。

回避策: 重大な変更の詳細は、次の言語固有のドキュメントを参照し、該当する場合は既存のコードを更新してください:

この問題への直接リンク: データベース・サービスSDKの重大な変更

詳細: コンソールまたはAPIを使用しているときに、バックアップおよびリストア操作がDBシステムで機能しない可能性があります。

回避策: Oracle Database Cloud Backupモジュールをインストールしてから、Oracle Support Servicesに連絡して詳細な指示を確認します。

Oracle Database Cloud Backupモジュールをインストールするには:

1. DBシステムにSSHで接続し、opcとしてログインします。

   
   ssh -i <SSH_key> opc@<DB_system_IP address>
   login as: opc

   または、opc @<DB_system_hostname>を使用してログインします。

2. http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.htmlからOracle Database Cloud Backupモジュールをダウンロードします。
3. opc_installer.zipの内容をターゲット・ディレクトリ(例: /home/opc)に抽出します。
4. テナンシで、一時ユーザーを作成し、テナンシのオブジェクト・ストレージにアクセスする権限を付与します。
5. この一時ユーザーの場合は、「認証トークンの作業」を作成し、パスワードをノートにとります。

6. 次のcurlコマンドを実行して、資格証明が機能することを確認します:

   ノート
   
   Swiftパスワードは「認証トークン」と呼ばれるようになりました。詳細は、「Swiftでの認証トークンの使用」を参照してください。

   curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

   正しいリージョンを使用するように、https://cloud.oracle.com/infrastructure/storage/object-storage/faqを参照してください。

   コマンドにより、HTTP 200またはHTTP 204 No Contentのいずれかの成功ステータス・レスポンス・コードが返される必要があります。その他のステータス・コードは、オブジェクト・ストレージへの接続中に問題が発生したことを示します。

7. 次のコマンドを実行します。

   java -jar opc_install.jar -opcid <user_id> -opcPass '<auth_token>' -libDir <target_dir> -walletDir <target_dir> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -configFile config.txt

   <target_dir>は、ステップ3でopc_installer.zipを抽出したディレクトリです。

   このコマンドは、libopc.soなどのファイルをダウンロードするため、完了するまでに数分かかることがあります。コマンドが完了すると、ターゲット・ディレクトリに複数のファイル(libopc.soなど)が表示されます。

8. ディレクトリをターゲット・ディレクトリに変更して、lipopc.soおよびopc_install.jarファイルを/opt/oracle/oak/pkgrepos/oss/odbcsディレクトリにコピーします。

   cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcs

   
   
   cp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs

   (rootとして実行するために、コピー・コマンドとともにsudoを使用することが必要な場合があります。)

9. 次のコマンドを実行して、指定したディレクトリが存在するかどうかを確認します:

   
   
   ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

   このディレクトリが存在する場合は、次のステップを実行します:

   1. /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcsディレクトリにファイルをバックアップします。

   2. 次の2つのコマンドを実行して、このディレクトリ内の既存のlibopc.soファイルとopc_install.jarファイルを置き換えます:

      
      cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
      cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

10. opc_install.jarのバージョンを確認します。

    
    java -jar /opt/oracle/oak/pkgrepos/oss/odbcs/opc_install.jar |grep -i build
    

    /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcsが存在する場合は、次のコマンドも実行します:

    
    java -jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

    どちらのコマンドでも、次の出力が返されます:

    Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.

11. (オプション)一時ユーザーと、バックアップ・モジュールのインストールに使用したターゲット・ディレクトリを削除します。

手順が完了したら、Oracle Supportまたはテナント管理者に連絡して詳細な指示を確認してください。バックアップを有効にするDBシステムのOCIDを指定する必要があります。

この問題への直接リンク: DBシステムで管理対象バックアップを使用できません

詳細: VM.Standard1.1シェイプを実行しているホスト・マシンのメモリー制限によって、Oracle Cloud Infrastructureで管理される自動データベース・バックアップ・ジョブ(コンソールまたはAPIのいずれかを使用して管理されるジョブ)に障害が発生することがあります。システムのメモリー・パラメータを変更して、この問題を解決できます。

回避策: システムのメモリー・パラメータを次のように変更します:

1. オペレーティング・システムのoracleユーザーに切り替えます。

   [opc@hostname ~]$ sudo su - oracle

2. データベース・インスタンスにログインするように環境変数を設定します。例:

   
   [oracle@hostname ~]$ . oraenv
    ORACLE_SID = [oracle] ? orcl
   				

3. SQL*Plusを起動します。

   [oracle@hostname ~]$ sqlplus / as sysdba

4. 初期メモリー・パラメータを次のように変更します:

   
   SQL> ALTER SYSTEM SET SGA_TARGET = 1228M scope=spfile;
   SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1228M;
   SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 2457M;
   SQL> exit
   							

5. データベース・インスタンスを再起動します。

   
   [oracle@hostname ~]$ srvctl stop database -d db_unique_name -o immediate
   [oracle@hostname ~]$ srvctl start database -d db_unique_name -o open								

この問題への直接リンク: プロセス・クラッシュのために管理対象自動バックアップがVM.Standard1.1シェイプで失敗します

詳細: High PerformanceおよびExtreme Performance DBシステムで、圧縮または並列(あるいはその両方)を使用するデータ・ポンプ・ユーティリティ操作が失敗することがあり、エラー「ORA-00439: 機能は有効ではありません」が返されます。この問題は、データベース・バージョン12.1.0.2.161018および12.1.0.2.170117に影響します。

回避策: データベース・バージョン12.1.0.2.161018または12.1.0.2.170117のOracle Databaseホームにそれぞれパッチ25579568または25891266を適用します。または、コンソールを使用して、2017年4月のパッチをDBシステムとデータベース・ホームに適用します。

この問題への直接リンク: Oracle Data Pumpの操作で「ORA-00439: 機能は有効ではありません」が返されます

詳細: 適切な権限が自動的に適用されなかったため、1ノードのDBシステムからEM Expressコンソールに接続しようとすると、「セキュアな接続が失敗しました。」というエラー・メッセージが表示される場合があります。

回避策: DBシステムのウォレット・ディレクトリに対するasmadminグループの読取り権限を追加してから、接続を再試行します:

1. DBシステム・ホストにSSHで接続し、opcとしてログインし、sudoでgridユーザーに移行します。

   [opc@dbsysHost ~]$ sudo su - grid
   [grid@dbsysHost ~]$ . oraenv
   ORACLE_SID = [+ASM1] ?
   The Oracle base has been set to /u01/app/grid
   

2. 次のコマンド出力に赤色で示されているウォレット・ディレクトリの場所を確認します。

   [grid@dbsysHost ~]$ lsnrctl status | grep xdb_wallet
   
   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=dbsysHost.sub04061528182.dbsysapril6.oraclevcn.com)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet))(Presentation=HTTP)(Session=RAW))

3. opcユーザーに戻り、oracleユーザーに切り替えて、ウォレット・ディレクトリに変更します。

   [opc@dbsysHost ~]$ sudo su - oracle
   [oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet

4. ディレクトリの内容をリストし、権限をメモします。

   
   [oracle@dbsysHost xdb_wallet]$ ls -ltr
   total 8
   -rw------- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
   -rw------- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
   

5. 権限を変更します:

   
   [oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*

6. 読取り権限が追加されたことを確認します。

   [oracle@dbsysHost xdb_wallet]$ ls -ltr
   total 8
   -rw-r----- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
   -rw-r----- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
   

この問題への直接リンク: 1ノードのDBシステムからEM Expressコンソールに接続できません

詳細: Exadataバックアップ・ユーティリティ(bkup_api)またはRMANを使用したオブジェクト・ストレージへのバックアップ操作が次のエラーで失敗します:

* DBaaS Error trace:
-> API::ERROR -> KBHS-00715: HTTP error occurred 'oracle-error'
-> API::ERROR -> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> API::ERROR -> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> API::ERROR -> ORA-27023: skgfqsbi: media manager protocol error
-> API::ERROR Unable to verify the backup pieces
-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

Symantec証明書に関して、2つの共通のWebブラウザによって実装されるポリシーに従い、Oracleでは、Oracle Cloud Infrastructureで使用される認証局が最近変更されました。SSL証明書が変更された結果、Oracle Database Cloud Backupモジュールが古い証明書をまだ参照していると、オブジェクト・ストレージへのバックアップが失敗する可能性があります。

bkup_apiの回避策: ログ・ファイルで、前にリストされたエラーを確認し、見つかった場合はバックアップ・モジュールを再インストールします。

次のコマンドを使用して、失敗したバックアップのステータスを確認します:

/var/opt/oracle/bkup_api/bkup_api bkup_status --dbname=<database_name>

次のコマンドを実行して、バックアップ・モジュールを再インストールします:

/var/opt/oracle/ocde/assistants/bkup/bkup -dbname=<database_name>

RMANの回避策: RMANのログ・ファイルで、リストされたエラー・メッセージを確認します。見つかった場合は、oracleユーザーとしてホストにログオンし、Swiftの資格証明を使用してバックアップ・モジュールを再インストールします。

java -jar <opc_install.jar_path> -opcId '<Swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

クラスタ内のすべてのノードでこの回避策を実行してください。

このコマンドの使用方法の詳細は、Oracle Database Cloud Backupモジュールに関するドキュメントを参照してください。

この問題への直接リンク: bkup_apiまたはRMANを使用したオブジェクト・ストレージへのバックアップが証明書の変更のために失敗します

詳細: Exadata DBシステム用の共有データベース・ホーム機能のリリースにより、コンソールでも、dbaasapiおよびdbaascliユーティリティを使用して作成および管理されるデータベースに関する情報が同期化されて表示されるようになりました。ただし、Data Guardが構成されているデータベースでは、次の条件下で正しい情報がコンソールに表示されません:

• Data Guardがコンソールを使用して有効化されており、dbaascliを使用してプライマリまたはスタンバイ・データベースが変更された場合(データベースを別のホームに移動するなど)、結果はコンソールに反映されません。
• Data Guardが手動で構成された場合、コンソールに2つのデータベース間のData Guardアソシエーションは表示されません。

回避策: 問題を認識しており、解決に取り組んでいます。当面は、コンソールのみまたはコマンドライン・ユーティリティのみを使用してData Guard対応データベースを管理することをお薦めします。

この問題への直接リンク: dbaascliを使用する場合、コンソール情報がData Guard対応データベースに対して同期されない

詳細: これは、Oracle GIのバージョンがバンドル・パッチなしの12.2.0.1の場合にのみ発生するクラスタウェアの問題です。この問題は、投票ディスクをオフラインにしてからオンラインにした後に、そのディスクが破損することによって発生します。

回避策: GIのバージョンと、投票ディスクが破損しているかどうかを確認します。ディスクを修復し(該当する場合)、最新のGIバンドルを適用します。

1. GIバージョンが、バンドル・パッチが適用されていない12.2.0.1であることを確認します:

   
   [root@rmstest-udaau1 ~]# su - grid
   [grid@rmstest-udaau1 ~]$ . oraenv
   ORACLE_SID = [+ASM1] ? +ASM1
   The Oracle base has been set to /u01/app/grid
   [grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory
   Oracle Interim Patch Installer version 12.2.0.1.6
   Copyright (c) 2018, Oracle Corporation.  All rights reserved.
   
   
   Oracle Home       : /u01/app/12.2.0.1/grid
   Central Inventory : /u01/app/oraInventory
      from           : /u01/app/12.2.0.1/grid/oraInst.loc
   OPatch version    : 12.2.0.1.6
   OUI version       : 12.2.0.1.4
   Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log
   
   Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt
   
   --------------------------------------------------------------------------------
   Local Machine Information::
   Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com
   ARU platform id: 226
   ARU platform description:: Linux x86-64
   
   Installed Top-level Products (1):
   
   Oracle Grid Infrastructure 12c                                       12.2.0.1.0
   There are 1 products installed in this Oracle Home.
   
   
   There are no Interim patches installed in this Oracle Home.
   
   
   --------------------------------------------------------------------------------
   
   OPatch succeeded.

2. 投票ディスクの破損が原因でGIが起動できなかったことの証拠を見つけるには、/u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trcファイルを確認します:

   ocssd.trc
    
   2017-01-17 23:45:11.955 :    CSSD:3807860480: clssnmvDiskCheck:: configured 
   Sites = 1, Incative sites = 1, Mininum Sites required = 1 
   2017-01-17 23:45:11.955 :    CSSD:3807860480: (:CSSNM00018:)clssnmvDiskCheck: 
   Aborting, 2 of 5 configured voting disks available, need 3 
   ...... 
   . 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmCheckForNetworkFailure: 
   skipping 31 defined 0 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmRemoveNodeInTerm: node 4, 
   slcc05db08 terminated. Removing from its own member and connected bitmaps 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: 
   ################################### 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssscExit: CSSD aborting from 
   thread clssnmvDiskPingMonitorThread 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: 
   ################################### 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: (:CSSSC00012:)clssscExit: A 
   fatal error occurred and the CSS daemon is terminating abnormally 
    
   ------------
    
   2017-01-19 19:00:32.689 :    CSSD:3469420288: clssnmFindVF: Duplicate voting disk found in the queue of previously configured disks 
   queued(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009 
   cbd]), 
   found(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009c 
   bd]), is not corrupted 
   2017-01-19 19:01:06.467 :    CSSD:3452057344: clssnmvVoteDiskValidation: 
   Voting disk(o/192.168.10.19/PCW_CD_02_slcc05cel11) is corrupted

3. SQL*Plusを使用して、投票ディスクが破損していることを確認することもできます:

   1. gridユーザーとしてログインし、環境をASMに設定します。

      [root@rmstest-udaau1 ~]# su - grid
      [grid@rmstest-udaau1 ~]$ . oraenv
      ORACLE_SID = [+ASM1] ? +ASM1
      The Oracle base has been set to /u01/app/grid

   2. SYSASMとしてSQL*Plusにログインします。

      $ORACLE_HOME/bin/sqlplus / as sysasm

   3. 次の2つの問合せを実行します:

      SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0;
      SQL> select  CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;

      システムが正常である場合、結果は次の例のようになります:

      問合せ1の結果

      NAME                           VOTING_FILE
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        Y
      DBFSC3_CD_09_SLCLCX0787        Y
      DBFSC3_CD_04_SLCLCX0786        Y

      問合せ2の結果

      NAME                           COUNT(*)
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        8
      DBFSC3_CD_09_SLCLCX0787        8
      DBFSC3_CD_04_SLCLCX0786        8

      正常なシステムでは、最初の問合せで返されたすべての投票ディスクが2番目の問合せでも返される必要があり、すべてのディスクのカウントがゼロ以外である必要があります。それ以外の場合、1つ以上の投票ディスクが破損しています。

4. 投票ディスクが破損している場合は、投票ディスクを含むグリッド・ディスクをオフラインにします。セルは、不良投票ディスクを他のグリッド・ディスクに自動的に移動し、その投票ディスクをオンラインにします。

   1. 次のコマンドで、DATAC01_CD_05_SCAQAE08CELADM13というグリッド・ディスクをオフラインにします。

      SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
           Diskgroup altered.

   2. 30秒待機してからステップ3cの2つの問合せを再実行し、投票ディスクが新しいグリッド・ディスクに移行され、正常であることを確認します。

   3. オフラインにしたグリッド・ディスクがオンラインになったことを確認します:

      SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';

      mode_statusはONLINEである必要があり、voting_fileはYではない必要があります。

   破損した投票ディスクが含まれる残りの各グリッド・ディスクについて、ステップ4aから4cを繰り返します。

   ノート
   
   

   投票ディスクの破損が原因でCRSが起動しない場合は、ステップ4でコマンドを実行する前に、排他モードで起動してください。

   crsctl start crs -excl

    

5. バンドル・パッチなしのOracle GIバージョン12.2.0.1を使用している場合、投票ディスクが破損していたかどうかにかかわらず、GIバージョンを最新のGIバンドルにアップグレードする必要があります。

   dbaascliユーティリティを使用してExadata Database Service on Dedicated InfrastructureでOracle Grid InfrastructureおよびOracle Databaseのパッチ適用操作を実行する方法の詳細は、dbaascliを使用したOracle Grid InfrastructureおよびOracle Databaseのパッチ適用を参照してください。

この問題への直接リンク: Grid Infrastructureが、ディスクをオフラインにしてからオンラインにすると起動しません

詳細: 2018年6月15日以降に起動されたExadata DBシステムには、コンソール、APIまたはOracle Cloud Infrastructure CLIを使用してデータベースを作成、リストおよび削除する機能が自動的に含まれます。ただし、この日付よりも前にプロビジョニングされたシステムでは、この機能を有効化するための追加ステップが必要です。

追加ステップなしでこの機能を使用しようとすると、次のエラー・メッセージが表示されます:

• データベースの作成時 - このExadata DBシステムでは「データベースの作成」はサポートされていません。この機能を有効化するには、Oracle Supportに連絡してください。
• データベースの終了時 - このExadata DBシステムではDeleteDbHomeはサポートされていません。この機能を有効化するには、Oracle Supportに連絡してください。

回避策: ExadataエージェントをExadata DBシステムの各ノードにインストールする必要があります。

最初に、Oracle Support Servicesから支援を受けるためにサービス・リクエストを作成します。Oracle Supportは、エージェントを取得できるOracle Cloud Infrastructure Object Storageの場所に対する事前認証済URLを提供して応答します。

Exadataエージェントをインストールする前に:

• Exadata DBシステムのすべてのノード上でツール(dbaastools rpm)を最新バージョンにアップグレードします。Exadata Cloud Serviceインスタンスでのツールの更新を参照してください。
• DBシステムが作成されたリージョンに必要なセキュリティ・リストがあるOracle Cloud Infrastructure Object Storageにアクセスできるように、システムが構成されていることを確認します。Oracle Cloud Infrastructure Object Storageへの接続の詳細は、Exadata Cloud Serviceでのバックアップの前提条件を参照してください。

Exadataエージェントをインストールするには:

1. rootとしてノードにログオンします。

2. 次のコマンドを実行して、エージェントをインストールします:

   [root@<node_n>~]# cd /tmp
   [root@<node_n>~]# wget https://objectstorage.<region_name>.oraclecloud.com/p/1q523eOkAOYBJVP9RYji3V5APlMFHIv1_6bAMmxsS4E/n/dbaaspatchstore/b/dbaasexadatacustomersea1/o/backfill_agent_package_iwwva.tar
   [root@<node_n>~]# tar -xvf /tmp/backfill_agent_package_*.tar -C /tmp
   [root@<node_n>~]# rpm -ivh /tmp/dbcs-agent-2.5-3.x86_64.rpm

   出力例:

   [root@<node_n>~]# rpm -ivh dbcs-agent-2.5-3.x86_64.rpm
   Preparing...                ########################################### [100%]
   Checking for dbaastools_exa rpm on the system
   Current dbaastools_exa version = dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64
   dbaastools_exa version dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64 is good. Continuing with dbcs-agent installation
      1:dbcs-agent             ########################################### [100%]
   initctl: Unknown instance:
   initctl: Unknown instance:
   initzookeeper start/running, process 85821
   initdbcsagent stop/waiting
   initdbcsadmin stop/waiting
   initdbcsagent start/running, process 85833
   initdbcsadmin start/running, process 85836
   

3. エージェントがインストールされ、実行されていることを確認します。

   [root@<node_n>~]# rpm -qa | grep dbcs-agent
   dbcs-agent-2.5-0.x86_64
   [root@<node_n>~]# initctl status initdbcsagent
   initdbcsagent start/running, process 97832

4. 残りのノードでステップ1から3を繰り返します。

エージェントをすべてのノードにインストールした後、エージェントを最新バージョンにアップグレードしたり、エージェント資格証明をローテーションするなど、Oracleが追加ワークフロー・タスクを完了するために最大30分かかります。プロセスが完了すると、コンソール、APIまたはOracle Cloud Infrastructure CLIでExadata管理対象機能を使用できるようになります。

この問題への直接リンク: 2018年6月15日より前にプロビジョニングされたシステムでは管理対象機能が有効になりません

詳細: パッチ適用構成ファイル(/var/opt/oracle/exapatch/exadbcpatch.cfg)が、Exadata DBシステムが別のリージョンにデプロイされている場合でも、us-phoenix-1リージョンのオブジェクト・ストアを参照します。

この問題は、データベース・ツール・パッケージ(dbaastools_exa)のリリース・バージョンが17430以下の場合に発生します。

回避策: Exadata Cloud Serviceインスタンスでのツールの更新の手順に従って、ツール・パッケージのリリース・バージョンが17430以下であることを確認し、最新バージョンに更新します。

この問題への直接リンク: パッチ適用構成ファイルが間違ったリージョンを参照します

詳細: Oracle Linux 7で一時ファイルを処理する方法が変更されたため、/var/tmp/.oracleディレクトリから必要なソケット・ファイルが削除されることがあります。この問題は、バージョン19.1.2のオペレーティング・システム・イメージを実行しているExadata DBシステムにのみ影響します。

回避策: opcユーザーとしてsudo /usr/local/bin/imageinfoを実行し、オペレーティング・システム・イメージのバージョンを確認します。イメージのバージョンが19.1.2.0.0.190306の場合は、ドキュメントID 2498572.1の指示に従って問題を修正します。

この問題への直接リンク: Oracle Linux 7で必要な一時ファイルが削除されたため、様々なデータベース・ワークフロー障害が発生します

詳細: 同じリージョン内の別々のADでコンピュートおよびストレージのDR操作を実行するときにボリューム・グループ・バックアップを使用する場合、DR移行を行き来すると、コンピュートおよび関連するブロック・ストレージ(ボリューム・グループ・バックアップを使用)が毎回違うADにアクセスする原因となります。

回避策: この問題は、ボリューム・グループ・レプリケーションを使用してレプリケートされたブロック・ストレージには影響しません。

詳細: ブロック・ストレージ・ボリュームのパフォーマンスの自動チューニング設定が、DR操作中に継承されません。

回避策: パフォーマンスの自動チューニングが有効になったブロック・ストレージ・ボリュームでは、フル・スタックDRによって、ブロック・ストレージ・ボリュームが別のリージョンに移行された後に、設定を再度有効にする必要があります。

詳細: フル・スタックDRで保護されたリソースの変更直後にフェイルオーバー操作を実行した場合、リソースのリカバリが失敗するか、リソースが正しくリカバリされない可能性があります。たとえば、DR保護グループに追加したボリューム・グループのレプリケーション・ターゲットまたはその他のプロパティを変更し、その後すぐにプライマリ・リージョンでボリューム・グループのレプリケーション設定の変更がフル・スタックDRで検出されない場合、そのボリューム・グループのリカバリに影響が出ます。

回避策: DR保護下のリソースに変更を加えた直後に、スイッチオーバー事前チェックを実行します。

詳細: フル・スタックDRでは、Oracle Cloud Agent (OCA)のコマンドの実行ユーティリティを使用して、インスタンスでローカル・スクリプトが実行されます。Microsoft Windowsインスタンスでローカル・スクリプトを実行するようにユーザー定義ステップを構成する場合は、フル・スタックDRの「実行ユーザー」機能を使用して別のuseridを指定し、インスタンスに存在するローカル・スクリプトを実行できます。

回避策: Microsoft Windowsインスタンスでスクリプトを実行できるのは、Oracle Cloud Agentのコマンドの実行ユーティリティで使用されるデフォルトのocarunユーザーIDのみです。この制限は、Oracle Linuxインスタンスには影響しません。

詳細: フル・スタックDRでは、Oracle Cloud Agent (OCA)のコマンドの実行ユーティリティを使用して、インスタンスでローカル・スクリプトが実行されます。デフォルトでは、これらのスクリプトは、ocarunユーザーとして実行されます。

回避策: Microsoft Windowsインスタンスでは、DR計画でユーザー定義ステップとして実行するよう構成されたローカル・スクリプトは、このocarunユーザーIDでアクセスして実行できる必要があります。

詳細: DR計画のユーザー定義ステップを使用してローカル・スクリプトを実行すると、スクリプト・インタプリタまたはスクリプトへのフル・パスを指定しないと、フル・スタックDRでエラーがスローされます。

回避策: DR計画で、インスタンスに存在するローカル・スクリプトを実行するようユーザー定義ステップを構成する際は、スクリプト名の前に付いているインタプリタへのフル・パスと、スクリプトへのフル・パスを必ず指定してください。

詳細: DR操作中に、宛先サブネットのCIDRブロックとソース・サブネットのCIDRブロックが一致し、インスタンスの元のプライベートIPがまだ割り当てられていない場合、フル・スタックDRは、インスタンスに割り当てられている元のプライベートIPの再割当てを試みます。

フル・スタックDRを使用してOCFS2クラスタ内のすべてのノードを再配置し、いずれかのクラスタ・ノードのプライベートIPを再割当てできない場合、スタンバイ・リージョンでノードが起動された後に、OCFS2クラスタからそれらのクラスタ・ノードがデタッチされます。

回避策: 宛先サブネットのCIDRブロックとソース・サブネットのCIDRブロックが一致し、クラスタ・ノードに必要なすべてのプライベートIPアドレスが宛先サブネットで使用可能であることを確認してください。

詳細: フル・スタックDRによってインスタンスが別のリージョンに再配置された後、インスタンス・アクセスに関して、インスタンスのリソース・ページに次のメッセージが表示される場合があります:

このイメージを使用するインスタンスへの接続方法が不明です

回避策: このメッセージは無視します。元のSSHキーファイルを使用してインスタンスに接続し、認証を行うと、インスタンスへのSSH接続が正常に機能します。

詳細: フル・スタックDRによってインスタンスが別のリージョンに再配置された後、ブート・ボリュームのイメージの部分に関して、インスタンスのリソース・ページに正しく表示されない場合があります。

たとえば、「イメージ情報」列に、「データのロード中にエラーが発生しました」というメッセージが表示される場合があります

回避策: このエラー・メッセージはイメージ名の表示用ですが、インスタンスまたはそのブート・ボリュームの操作には影響しません。

詳細: nohupコマンドのスリープ時間がない場合、runコマンドの実行に失敗し、ステータスが正常にレポートされません。

nohup sh enabler.sh  &> enabler.log &
sleep 10
exit 0

詳細: Windowsマシンで作成されたzipファイルのオンデマンド・アップロードで、ログ・コンテンツのアップロードに失敗することがあります。失敗の理由は、Windowsで作成されたzipの最終変更時間がファイルの作成時間と同じであることです。そのため、ファイルが解凍されると、ファイルの最終変更時間がファイルの作成時間として設定されますが、それがログ・ファイル内のログ・エントリのタイムスタンプより古い可能性があります。このような場合、ファイルの最終変更時刻より新しいタイムスタンプを持つログ・エントリはアップロードされません。

問題の例:

ログ・エントリのタイムスタンプ: 2020-10-12 21:12:06

ログ・ファイルの最終変更時間: 2020-10-10 08:00:00

回避策: ログ・ファイルを新しいフォルダにコピーし、zipファイルを作成します。このアクションにより、ファイルの最終変更時間がログ・エントリのタイムスタンプより新しくなります。この新しいzipファイルをオンデマンド・アップロードに使用します。

回避策の実施後に、前の例を使用:

ログ・エントリのタイムスタンプ: 2020-10-12 21:12:06

ログ・ファイルの最終変更時間: 2021-03-31 08:00:00

この問題への直接リンク: zipファイルを使用したWindowsマシンからのオンデマンド・アップロード

詳細: 10,000を超えるファイルを含むフォルダは、ログ収集の問題(およびオペレーティング・システムの問題)を引き起こす可能性があります。

管理エージェント・ログ・アナリティクス・プラグインで大きなフォルダが検出されると、次の例のようなメッセージが管理エージェントmgmt_agent.logファイルに追加されます:

2020-07-30 14:46:51,653 [LOG.Executor.2388 (LA_TASK_os_file)-61850] INFO - ignore large dir /u01/service/database/logs. set property loganalytics.enable_large_dir to enable.

解決策: 大きなフォルダは避けることをお薦めします。

ただし、大きなフォルダのログのモニタリングを続行する場合は、次のアクションを実行してmgmt_agent.logファイルに示されているプロパティを有効にできます:

sudo -u mgmt_agent echo "loganalytics.enable_large_dir=true" >> INSTALL_DIRECTORY/agent_inst/config/emd.properties

INSTALL_DIRECTORYをagent_instフォルダのパスに置き換えます。

この問題への直接リンク:大きいフォルダのログをモニターする場合の特別な処理

詳細: これまで、Oracle Cloud Infrastructure Registryにログインするとき、およびコンテナ・レジストリのイメージに対して操作を実行するときは、テナンシ名またはテナンシ・ネームスペースのいずれかを使用することができました。

2019年9月30日より後は、Oracle Cloud Infrastructure Registryの使用時にテナンシ名ではなくテナンシ・ネームスペースを使用する必要があります。

背景: 2019年9月30日より後は、次のことができなくなります:

• Oracle Cloud Infrastructure Registryにログインするときにテナンシ名を指定します。
• リポジトリ・パスにテナンシ名を含むイメージに対する操作を実行します。

かわりに、Oracle Cloud Infrastructure Registryの使用時にテナンシ名ではなくテナンシ・ネームスペースを使用する必要があります。

テナンシ・ネームスペースは、自動生成された英数字の不変ランダム文字列です。たとえば、acme-devテナンシのネームスペースはansh81vru1zpです。テナンシ・ネームスペースは、コンソールの「コンテナ・レジストリ」ページで確認できます。

一部の古いテナンシでは、テナンシ・ネームスペースがテナンシ名と同じである可能性があります。その場合、処置は必要ありません。

2019年9月30日以前は、テナンシ・ネームスペースとテナンシ名が異なる場合、次が必要です:

• Oracle Cloud Infrastructure Registryにログインするときに、テナンシ名のかわりにテナンシ・ネームスペースの指定を開始します。
• Oracle Cloud Infrastructure Registryに新規イメージをプッシュするときに、テナンシ名のかわりにテナンシ・ネームスペースの指定を開始します。
• パスにテナンシ名を含むOracle Cloud Infrastructure Registryの既存のイメージを移行します。

次の回避策と例での前提:

• テナンシ名はacme-devです
• テナンシ・ネームスペースはansh81vru1zpです
• ユーザー名はjdoe@acme.comです

Oracle Cloud Infrastructure Registryにログインする場合の回避策: 以前は、Oracle Cloud Infrastructure Registryにログインするときに、ユーザー名を求められ、<tenancy-name>/<username>という形式で入力できました。

例:

$ docker login phx.ocir.io

Username: acme-dev/jdoe@acme.com
Password:

2019年9月30日以前に、Oracle Cloud Infrastructure Registryへのログイン時に、テナンシ名のかわりにテナンシ・ネームスペースの使用を開始する必要があります。ユーザー名を求められたら、<tenancy-namespace>/<username>という形式で入力します。

例:

$ docker login phx.ocir.io

Username: ansh81vru1zp/jdoe@acme.com
Password:

Oracle Cloud Infrastructure Registryに新規イメージをプッシュする場合の回避策: 以前は、Oracle Cloud Infrastructure Registryに新規イメージをプッシュするときに、docker pushコマンドのリポジトリ・パスの一部としてテナンシ名を指定できました。この形式でコマンドを入力できました:

$ docker push <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag>

例:

$ docker push phx.ocir.io/acme-dev/helloworld:latest

2019年9月30日以前に、新規イメージのプッシュ時に、docker pushコマンドでテナンシ名のかわりにテナンシ・ネームスペースの使用を開始する必要があります。この形式でコマンドを入力します:

$ docker push <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

例:

$ docker push phx.ocir.io/ansh81vru1zp/helloworld:latest

リポジトリ・パスにテナンシ名を含むOracle Cloud Infrastructure Registryの既存のイメージの回避策: 以前にOracle Cloud Infrastructure Registryにイメージをプッシュした場合、それらの既存のイメージにリポジトリ・パスの一部としてテナンシ名が含まれている可能性があります。たとえば、phx.ocir.io/acme-dev/helloworld:latestです。

2019年9月30日より後は、リポジトリ・パスにテナンシ名を含むコンテナ・レジストリの既存のイメージに対して操作を実行できなくなります。

そのため、2019年9月30日以前に、リポジトリ・パスにテナンシ名を含む既存のすべてのイメージを対象に、テナンシ名をテナンシ・ネームスペースに置き換える必要があります。

既存のイメージのリポジトリ・パスにあるテナンシ名をテナンシ・ネームスペースに置き換えるには:

1. 次を入力してイメージをプルします:

   $ docker pull <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag>

   例:

   $ docker pull phx.ocir.io/acme-dev/helloworld:latest

2. 次を入力し、docker tagコマンドを使用してリポジトリ・パスを変更します:

   $ docker tag <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag> <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

   例:

   $ docker tag phx.ocir.io/acme-dev/helloworld:latest phx.ocir.io/ansh81vru1zp/helloworld:latest

3. 次を入力し、新しいリポジトリ・パスを使用してイメージをコンテナ・レジストリにプッシュします:

   $ docker push <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

   例:

   $ docker push phx.ocir.io/ansh81vru1zp/helloworld:latest

4. リポジトリ・パスにテナンシ名を含む既存のすべてのイメージについて、前述のステップを繰り返します。

この問題への直接リンク: 2019年9月30日以前に、イメージ・タグおよびDockerログイン資格証明にテナンシ名ではなくテナンシ・ネームスペースを使用します