Oracle Cloud Infrastructureドキュメント

超高パフォーマンス・ボリューム・アタッチメントのトラブルシューティング

このトピックでは、超高パフォーマンス・レベルで構成され、ボリュームのアタッチが失敗するか、ボリューム・アタッチメントがマルチパス対応ではないボリュームで実行できるトラブルシューティングのステップと、確認が必要な前提条件について説明します。

ボリューム・アタッチメントの問題のトラブルシューティング

ブロック・ボリューム管理プラグインは、iSCSIアタッチメント・タイプを使用してアタッチされた超高パフォーマンスで構成されたボリュームに必要です。ボリュームがインスタンスへのアタッチに失敗した場合、ブロック・ボリューム管理プラグインの構成が正しくないことが原因の可能性があります。これらの問題については、このセクションのトラブルシューティングの推奨事項を参照してください。

ブロック・ボリューム管理プラグインのログのエラー: ボリューム・アタッチメントが認可されていないか見つからないエラー

ブロック・ボリューム管理プラグインで権限を正しく構成していない場合、ボリュームはインスタンスへのアタッチに失敗します。

詳細

ボリュームはコンソールにアタッチされているとおりに表示されず、ブロック・ボリューム管理プラグインのログにNotAuthorizedOrNotFoundというエラー・メッセージが表示されます。

ブロック・ボリューム管理プラグインのログは、次の場所にあります:

"/var/log/oracle-cloud-agent/plugins/oci-blockautoconfig/oci-blockautoconfig.log

次に示すのは、この問題のサンプルのエラー・ログ・エントリです:

2021/08/13 09:14:25.864932 compute_client_command.go:255: Updating volume attachment to the state LOGIN_SUCCEEDED ...
2021/08/13 09:14:26.155473 compute_client_command.go:260: Service error:NotAuthorizedOrNotFound.
volume attachment ocid1.volumeattachment.oc1.iad.<volume-attachment_ID> not found.
http status code: 404. Opc request id: <request_ID>

原因

ブロック・ボリューム管理プラグインに、iSCSIログイン・ステータス通知をサービスに送信するための十分な権限がありません。

解決方法

ブロック・ボリューム管理プラグインの権限を構成するには:

  1. 動的グループの作成: 次のコード・サンプルの一致ルールを使用して動的グループを作成し、指定したコンパートメント内のすべてのインスタンスを追加します:

    ANY {instance.compartment.id = 'ocid1.tenancy.oc1..<tenancy_ID>', instance.compartment.id = 'ocid1.compartment.oc1..<compartment_OCID>'

  2. 動的グループのポリシーの構成: 前のステップで作成した動的グループに権限を付与するポリシーを構成して、インスタンス・エージェントによるアクセスを可能にし、ブロック・ボリューム・サービスをコールして、アタッチメント構成を取得できるようにします。

    Allow dynamic-group InstantAgent to use instances in tenancy
Allow dynamic-group InstantAgent to use volume-attachments in tenancy

リソース

ブロック・ボリューム管理プラグインのログのエラー: ユーザー・エージェントは空にできません

Oracleサービスに接続するには、コンピュート・インスタンスにパブリックIPアドレスまたはサービス・ゲートウェイが必要で、ない場合は、ボリュームのアタッチに失敗します。

詳細

ボリュームはコンソールにアタッチされているとおりに表示されず、ブロック・ボリューム管理プラグインのログにuser agent can not be blankというエラー・メッセージが表示されます。

ブロック・ボリューム管理プラグインのログは、次の場所にあります:

"/var/log/oracle-cloud-agent/plugins/oci-blockautoconfig/oci-blockautoconfig.log

次に示すのは、この問題のサンプルのエラー・ログ・エントリです:

2021/10/15 22:16:07.881953 compute_client_command.go:255: Updating volume attachment to the state LOGIN_SUCCEEDED ...
2021/10/15 22:16:07.882185 compute_client_command.go:260: user agent can not be blank
2021/10/15 22:16:07.882204 iscsi_commands_helper.go:302: user agent can not be blank
2021/10/15 22:16:07.882212 iscsi_commands_helper.go:310: user agent can not be blank

原因

ネットワーク構成が原因で、ブロック・ボリューム管理プラグインが、iSCSIログイン・ステータス通知をサービスに送信できません。

解決方法

インスタンスにパブリックIPアドレスがない場合は、仮想クラウド・ネットワーク(VCN)上にサービス・ゲートウェイを設定します。サービス・ゲートウェイを使用すると、データをパブリック・インターネットに公開することなく、Oracleサービスにプライベートにアクセスできます。次に、ブロック・ボリューム管理プラグインにサービス・ゲートウェイを設定する上での特記事項を示します:

  • サービス・ゲートウェイを作成する場合は、「Oracle Services Networkのすべての<region>サービス」というサービス・ラベルを有効にします。
  • インスタンスが含まれるサブネットのルーティングを設定する場合は、「ターゲット・タイプ」を「サービス・ゲートウェイ」、「宛先サービス」を「Oracle Services Networkのすべての <region>サービス」に設定して、ルート・ルールを設定します。

詳細な手順は、Oracleサービスへのアクセス: サービス・ゲートウェイに関する項を参照してください。

リソース

ボリューム・アタッチメントがマルチパス対応でない

超高パフォーマンス・レベルで構成されたボリュームをアタッチして、最適なパフォーマンスを実現するには、ボリューム・アタッチメントをマルチパス対応にする必要があります。ブロック・ボリューム・サービスでは、ボリュームをアタッチする際に、アタッチメントがマルチパス対応になるよう試行します。満たしていない前提条件があると、ボリューム・アタッチメントはマルチパス対応になりません。

ボリューム・アタッチメントがマルチパス対応かどうかのチェック

コンソールの「ボリューム詳細」ページから、ボリューム・アタッチメントがマルチパス対応かどうかを確認するには:

  1. ナビゲーション・メニューを開き、「ストレージ」をクリックします。「ブロック・ストレージ」で、「ブロック・ボリューム」をクリックします

  2. ボリューム・アタッチメントを確認するブロック・ボリュームをクリックします。

  3. 「リソース」セクションの「アタッチされたインスタンス」をクリックします。

  4. 「マルチパス」列に表示される値を確認します。

    • はい: ボリュームは超高パフォーマンス・レベルで構成されていて、ボリューム・アタッチメントはマルチパス対応です。これ以外のアクションは必要ありません。

    • いいえ: ボリュームは超高パフォーマンス・レベルで構成されていないため、ボリュームをマルチパス対応にする必要はありません。これ以外のアクションは必要ありません。
    • いいえ(警告のアイコン付き): ボリュームは超高パフォーマンス・レベルで構成されていますが、ボリューム・アタッチメントはマルチパス対応ではありません。最適なパフォーマンスを実現するには、ボリュームがサポートされているインスタンス・シェイプにアタッチされていることと、必要な前提条件が構成されていることを確認する必要があります。

ボリュームが超高パフォーマンス・レベルで構成されていても、必要とされるとおりマルチパス用に構成されていない場合は、次のスクリーンショットの1行目に示すように、「マルチパス」列には「いいえ」と警告の三角形が表示されます。

コンソールの「マルチパス」列の値。

CLIまたはAPIの使用を含め、ボリュームがマルチパス対応かどうかを確認する追加の手順については、「ボリューム・アタッチメントがマルチパス対応かどうかのチェック」を参照してください。

ボリュームがマルチパス用に構成されていない場合、その問題をトラブルシューティングするには、このセクションで説明する情報を確認し、発生した問題に対処します。

インスタンスはサポートされているコンピュート・シェイプをベースにすることが必要

超高パフォーマンス・レベルで構成されたボリュームを、サポートされているシェイプ(少なくとも16コア用に構成)に基づいてインスタンスにアタッチする必要があります。

ISCSIアタッチメントでサポートされるシェイプ

現在のいずれのベア・メタル・シェイプでも、マルチパス対応のiSCSIアタッチメントがサポートされています。ベア・メタル・インスタンスにアタッチされたブロック・ボリュームのパフォーマンス特性の詳細は、「ベア・メタル・シェイプ」を参照してください。

16コア以上で構成された現在のVMシェイプでは、マルチパス対応アタッチメントがサポートされています。iSCSIアタッチメントを使用してVMにアタッチされたボリュームのパフォーマンス特性については、「iSCSIでアタッチされたボリュームのVMシェイプ」を参照してください。

準仮想化アタッチメントでサポートされるシェイプ

VM.Standard.E4.Flexシェイプは、超高パフォーマンスで構成されたボリュームの準仮想化アタッチメントでサポートされる唯一のシェイプです。

解決方法

サポートされているシェイプ構成のインスタンスにボリュームがアタッチされていない場合は、ボリュームをデタッチして、サポートされているシェイプ構成のインスタンスにアタッチする必要があります。

既存のインスタンスを編集して正しいシェイプ構成にすることもできますが、そのインスタンスを編集したら、ボリュームをデタッチして再アタッチしてください。

警告

インスタンスのOCPU数が8未満の場合、マルチパス対応アタッチメントをサポートするようインスタンスを編集し、ボリュームをデタッチして再アタッチした後でも、ボリューム・アタッチメントがマルチパス対応にならないという問題が発生する可能性があります。この場合は、サポートされているシェイプからインスタンスを再作成し、ボリュームをその新しいインスタンスにアタッチする必要があります。詳細は、「インスタンスのサイズ変更後に準仮想化ボリューム・アタッチメントがマルチパス対応ではない」を参照してください。

リソース

コンピュート・イメージでマルチパス・アタッチメントのサポートが必要

超高パフォーマンス・レベルで構成されたボリュームは、マルチパス・アタッチメントをサポートするイメージを実行しているインスタンスにアタッチする必要があります。これには、カスタム・イメージも含まれます。

iSCSIアタッチメントでサポートされるイメージ

マルチパス・アタッチメントがサポートされるのは、Oracle Linuxイメージ、またはOracle Linuxイメージをベースとするカスタム・イメージが実行されているプラットフォーム・イメージのみです。

Unbreakable Enterprise Kernel (UEK)バージョンのUEK6U1以上では、最新プラットフォームのOracle Linuxイメージのいずれかを使用します。

カスタム・イメージの場合、Unbreakable Enterprise Kernel (UEK)バージョンもUEK6U1以上であることが必要です。UEK6U1 UEKは、2020年11月にリリースされたカーネルのメジャー・リリース・バージョン5.4.17-2036に関連付けられています。また、カスタム・イメージのStorage.Iscsi.MultipathDeviceSupportedプロパティをtrueに更新し、インスタンスを再起動する必要があります。詳細は、「カスタム・イメージのイメージ機能の構成」を参照してください

準仮想化アタッチメントでサポートされるイメージ

マルチパス対応アタッチメントの場合、アタッチされたインスタンスで次のいずれかのイメージ、または次のいずれかのイメージをベースとするカスタム・イメージが実行されている必要があります:

  • Oracle Linux
  • Ubuntu
  • CentOS
  • Windows
ノート

マルチパス対応アタッチメントは、Oracle Autonomous Linuxインスタンスではサポートされません。

Unbreakable Enterprise Kernel (UEK)バージョンのUEK6U1以上では、最新プラットフォームのOracle Linuxイメージのいずれかを使用します。

リソース

ボリュームの再アタッチ

シェイプの構成またはインスタンスのイメージを、マルチパス・アタッチメントをサポートするものに更新した場合は、インスタンスからボリュームをデタッチしてから、インスタンスに再度アタッチする必要があります。

リソース

iSCSIアタッチメントの診断ファイルの生成

iSCSIアタッチメントで、このトピックで説明するすべてのステップを実行しても、ボリューム・アタッチメントで問題が発生し続ける場合は、「ステップ4: Oracle Cloud Agentの診断ファイルの生成」で説明されているステップを実行して診断ファイルを生成し、Oracleサポートに連絡してください。このステップは、準仮想化アタッチメントには適用されません。

リソース

ボリューム・アタッチメントがマルチパス対応として誤って報告される

特定のシナリオでは、ボリューム・アタッチメントはコンソールでマルチパス対応として表示されますが、アタッチメントは実際にはマルチパス対応ではなく、ボリュームはUltra High Performanceレベルで予想されるパフォーマンスを達成しません。この問題は、oci-utilsおよびoci-iscsi-configツールの両方を同時に使用してボリュームを構成する場合に発生します。

次のいずれかの方法を使用して、この問題が発生しているかどうかを確認します。

オプション1: Linuxのmultipathコマンド
multipathコマンドを使用して、Linuxインスタンスでボリューム・アタッチメントが実際にマルチパス対応であるかどうかを確認します。インスタンスにログインし、次のようにllタグを指定してmultipathコマンドを実行します:
# multipath -ll
コマンド出力から何も返されない場合は、インスタンスにマルチパス対応のアタッチメントがないことが確認されます。
オプション2: node.startupの確認
次のように、/var/lib/iscsi/nodes/{IQN} のノード・レコードでnode.startupを確認します:
#cd /var/lib/iscsi/nodes/{IQN}
#grep -Hrn 'node.startup'
いずれかにnode.startup=automaticがある場合、ボリューム・アタッチメントはマルチパス対応ではありません。これらはすべてnode.startup=manualを表示する必要があります。

解決方法

アタッチメントがマルチパス対応でないと判断した場合は、/etc/fstabファイルを使用してこの問題を回避できます。/etc/fstabファイルを更新して、multipathdサービスが実行されるまで待機してからファイル・システムをマウントするようにsystemdサービスに指示します。これを行うには、ボリュームにx-systemd.requires=multipathd.serviceを追加します。例:
UUID={$AFFECTED_VOLUME_UUID} /test ext4 defaults,_netdev,nofail,x-systemd.requires=multipathd.service 0 2

/etc/fstabファイルを更新した後にインスタンスを再起動します。

/etc/fstabファイルの詳細は、「従来のfstabオプション」および「一貫性のあるデバイス・パスを使用したブロック・ボリューム用のfstabオプション」を参照してください。