超高パフォーマンス・ボリューム・アタッチメントのトラブルシューティング
このトピックでは、超高パフォーマンス・レベルで構成され、ボリュームのアタッチが失敗するか、ボリューム・アタッチメントがマルチパス対応ではないボリュームで実行できるトラブルシューティングのステップと、確認が必要な前提条件について説明します。
ボリューム・アタッチメントの問題のトラブルシューティング
ブロック・ボリューム管理プラグインは、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ログイン・ステータス通知をサービスに送信するための十分な権限がありません。
解決方法
ブロック・ボリューム管理プラグインの権限を構成するには:
-
動的グループの作成: 次のコード・サンプルの一致ルールを使用して動的グループを作成し、指定したコンパートメント内のすべてのインスタンスを追加します:
ANY {instance.compartment.id = 'ocid1.tenancy.oc1..<tenancy_ID>', instance.compartment.id = 'ocid1.compartment.oc1..<compartment_OCID>'
-
動的グループのポリシーの構成: 前のステップで作成した動的グループに権限を付与するポリシーを構成して、インスタンス・エージェントによるアクセスを可能にし、ブロック・ボリューム・サービスをコールして、アタッチメント構成を取得できるようにします。
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行目に示すように、「マルチパス」列には「いいえ」と警告の三角形が表示されます。
CLIまたはAPIの使用を含め、ボリュームがマルチパス対応かどうかを確認する追加の手順については、「ボリューム・アタッチメントがマルチパス対応かどうかのチェック」を参照してください。
ボリュームがマルチパス用に構成されていない場合、その問題をトラブルシューティングするには、このセクションで説明する情報を確認し、発生した問題に対処します。
超高パフォーマンス・レベルで構成されたボリュームを、サポートされているシェイプ(少なくとも16コア用に構成)に基づいてインスタンスにアタッチする必要があります。
サポートされるシェイプ
現在のいずれのベア・メタル・シェイプでも、マルチパス対応のiSCSIアタッチメントがサポートされています。ベア・メタル・インスタンスにアタッチされたブロック・ボリュームのパフォーマンス特性の詳細は、「ベア・メタル・シェイプ」を参照してください。
16コア以上で構成された現在のVMシェイプでは、マルチパス対応アタッチメントがサポートされています。VMにアタッチされたボリュームのパフォーマンス特性については、「iSCSIおよび準仮想化アタッチ・ボリュームのVMシェイプ」を参照してください。
解決方法
ボリュームが、サポートされているシェイプ構成のインスタンスにアタッチされていない場合は、ボリュームをデタッチして、サポートされているシェイプ構成のインスタンスにアタッチする必要があります。
既存のインスタンスを編集して正しいシェイプ構成にすることもできますが、そのインスタンスを編集したら、ボリュームをデタッチして再アタッチしてください。
インスタンスの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アタッチメントで、このトピックで説明するすべてのステップを実行しても、ボリューム・アタッチメントで問題が発生し続ける場合は、「ステップ4: Oracle Cloud Agentの診断ファイルの生成」で説明されているステップを実行して診断ファイルを生成し、Oracleサポートに連絡してください。このステップは、準仮想化アタッチメントには適用されません。
リソース
特定のシナリオでは、ボリューム・アタッチメントはコンソールでマルチパス対応として表示されますが、アタッチメントは実際にはマルチパス対応ではなく、ボリュームはUltra High Performanceレベルで期待されるパフォーマンスを達成しません。この問題は、oci-utils
およびoci-iscsi-config
ツールの両方を同時に使用してボリュームを構成する場合に発生します。
次のいずれかの方法を使用して、この問題が発生しているかどうかを確認します。
multipath
コマンドを使用して、Linuxインスタンスでボリューム・アタッチメントが実際にマルチパス対応であるかどうかを確認します。インスタンスにログインし、次のようにll
タグを指定してmultipath
コマンドを実行します:# multipath -ll
コマンド出力から何も返されない場合は、インスタンスにマルチパス対応のアタッチメントがないことが確認されます。/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オプション」を参照してください。