こんにちは、Aireです。
今回はAWS上のAmazon LinuxにiSCSIイニシエータとマルチパスを導入し、Amazon Linux（iSCSIイニシエータ）からiSCSIターゲットに接続してみました。基本的には以下の記事と同じ手順で構築できましたが、AWSまたはAmazon Linuxを考慮した手順が一部必要でしたので、本記事ではそれらの追加手順を紹介したいと思います。
「ソフトウェアパッケージのインストール」時の留意事項
実行環境（AWSのネットワーク設定）に応じて、ソフトウェアパッケージのインストール前に以下の設定を行ってください。
S3用のVPCエンドポイント（ゲートウェイ型）を作成する（Amazon Linuxがインターネットへの通信不可の場合は必要）
Amazon LinuxにiSCSI InitiatorやDevice Mapper Multipathパッケージをインストールする場合、Amazon Linuxリポジトリにアクセスする必要があります。Amazon LinuxリポジトリはAmazon S3に存在するため、VPCエンドポイントを作成することで、インターネットとの通信が許可されていないプライベートサブネットからでも当該リポジトリにアクセスできます。
以下、AWS管理コンソールからS3用のVPCエンドポイント（ゲートウェイ型）を作成する手順を記載します。（引数値は実際の環境に合わせて変更してください）
- VPCダッシュボードに移動します。移動後、ナビゲーションペインで[エンドポイント]を選択し、[エンドポイントを作成]をクリックします。
- エンドポイントの作成画面に移動します。[エンドポイントの設定]欄では、エンドポイントの名前の入力とサービスカテゴリの選択を行います。S3はAmazonが提供するサービスなので、
AWSのサービスを選択します。
- [サービス]欄では、VPCエンドポイントを使用してアクセスするサービス名を指定します。検索ボックスに
S3と入力し、サービスがcom.amazonaws.<リージョンコード>.s3、タイプがGatewayのサービスを選択します。
- [VPC]欄では、VPCエンドポイントの作成先となるVPCを選択します。
- [ルートテーブル]欄では、VPCエンドポイントが使用するルートテーブルを選択します。サービス宛てのトラフィックを、VPCエンドポイントのネットワークインターフェイスにポイントするルートが自動的に追加されます。
- [ポリシー]欄では、VPCエンドポイントにアタッチするVPCエンドポイントポリシーを指定します。VPCエンドポイントポリシーは、VPCエンドポイント経由でサービスにアクセスできるAWSプリンシパルや許可する権限をJSON形式で記述したものです。
カスタムを選択した場合は、AWSポリシー作成ツールでポリシーを作成し、作成したポリシーを[ポリシー]欄に貼り付けます。
- 最後に、[タグ]欄で適宜タグのキーと値を追加し、[エンドポイントを作成]をクリックします。
「iSCSIイニシエータからiSCSIターゲットに接続」する際の留意事項
以下の記事と同じ手順を実施したところ、デバイスの認識に関して期待と異なる挙動が見られました。
<Amazon Linux 2023の場合>
マルチパス設定の完了後、multipath -llコマンドを実行したところ、/dev/sdaのステータスがfailed faulty runningになっていました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ sudo multipath -ll 3548.083595 | do_rtpg: sg ioctl failed: Invalid argument mpatha (xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) dm-0 LIO-ORG,volume1 size=10G features='0' hwhandler='1 alua' wp=ro `-+- policy='round-robin 0' prio=50 status=active |- 2:0:0:1 sdb 8:16 active ready running `- 3:0:0:1 sdd 8:48 active ready running 3548.098604 | sda: uid = 3600140590da41907d8d442aa1b02febd (sysfs) mpathb (yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy) dm-1 LIO-ORG,volume0 size=10G features='0' hwhandler='0' wp=ro `-+- policy='round-robin 0' prio=50 status=active |- 2:0:0:0 sda 8:0 failed faulty running `- 3:0:0:0 sdc 8:32 active ready running |
lsblk -Sコマンドを実行し、SCSIデバイスを確認したところ、iSCSIデバイスの/dev/sdaのシリアル番号が正常に表示されていませんでした。
|
1 2 3 4 5 6 |
lsblk -S NAME HCTL TYPE VENDOR MODEL REV SERIAL TRAN sda 2:0:0:0 disk LIO-ORG volume0 4.0 iscsi sdb 2:0:0:1 disk LIO-ORG volume1 4.0 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx iscsi sdc 3:0:0:0 disk LIO-ORG volume0 4.0 yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy iscsi sdd 3:0:0:1 disk LIO-ORG volume1 4.0 zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz iscsi |
<Amazon Linux 2の場合>
マルチパス設定の完了後、multipath -llコマンドを実行したところ、mpathb（/dev/sda）表示されませんでした。
|
1 2 3 4 5 6 |
$ sudo multipath -ll mpatha (xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) dm-0 LIO-ORG ,volume1 size=10G features='0' hwhandler='0' wp=ro `-+- policy='round-robin 0' prio=1 status=active |- 2:0:0:1 sdc 8:32 active ready running `- 3:0:0:1 sdd 8:48 active ready running |
lsblk -Sコマンドを実行し、SCSIデバイスを確認してみましたが、こちらはAmazon Linux 2023とは異なり、シリアル番号が表示されないため、デバイス間で違いを確認できませんでした。
|
1 2 3 4 5 6 |
lsblk -S NAME HCTL TYPE VENDOR MODEL REV TRAN sda 3:0:0:0 disk LIO-ORG volume0 4.0 iscsi sdb 2:0:0:0 disk LIO-ORG volume0 4.0 iscsi sdc 2:0:0:1 disk LIO-ORG volume1 4.0 iscsi sdd 3:0:0:1 disk LIO-ORG volume1 4.0 iscsi |
調べた結果、これらの挙動はいずれも共通の原因（次節で説明）によるものでした。以下の対処方法を実施することで原因は解消可能です。
ルートデバイスボリュームのシンボリックリンクとそれを作成するudevルールを削除する（Xenベースのインスタンスの場合は必要）
Xen ベースのインスタンス上で Amazon Linuxを起動すると、ルートデバイスボリューム（ルートボリュームとなっているEBSボリューム）がOS上で/dev/xvdaとして認識されます。また、Amazon Linuxにデフォルトで存在するudevルールによって、/dev/sdaという名前のシンボリックリンクファイルがデバイス認識時に作成されます。
<コマンド実行例>
|
1 2 3 |
$ ls -l /dev/sd* lrwxrwxrwx 1 root root 4 7月 17 12:56 /dev/sda -> xvda lrwxrwxrwx 1 root root 5 7月 17 07:50 /dev/sda1 -> xvda1 |
通常、iSCSIイニシエータからターゲットにログインする際は、iSCSIデバイスに対して/dev/sdXのような命名が行われますが、Amazon Linuxを使用する場合、イニシエータ上には既にシンボリックリンクファイル/dev/sdaが存在するため、iSCSIデバイス名との衝突が発生し、iSCSIデバイスに対するデバイスファイルが作成されていない状態となります。
その結果、lsblk -Sの実行結果に/dev/sdaのシリアル番号が表示されず、multipath -llの実行結果も failed になっていました。
次節以降、Amazon Linuxのバージョンごとの対処方法を記載します。
Amazon Linux 2023の場合
- iSCSIターゲットに接続中の場合、一旦ログアウトします。
- EC2のudevルール
/lib/udev/rules.d/51-ec2-hvm-devices.rulesを開きます。/dev/xvdXに対してシンボリックリンクファイル/dev/sdXを作成する下記のルールをコメントアウトします。
|
1 2 3 |
$ vi /lib/udev/rules.d/51-ec2-hvm-devices.rules # 以下の行をコメントアウト（先頭に#を記載）する。 KERNEL=="xvd*", PROGRAM="/usr/sbin/ec2udev-vbd %k", SYMLINK+="%c" |
- ルートデバイスボリュームのシンボリックリンクファイル
/dev/sda、/dev/sda1を削除します。 - iSCSIターゲットに再接続後、
lsblk -Sやmultipath --llコマンドを実行し、デバイスが正常に認識されていることを確認します。
Amazon Linux 2の場合
- iSCSIターゲットに接続中の場合、一旦ログアウトします。
- EC2のudevルール
/etc/udev/rules.d/51-ec2-hvm-devices.rulesを開きます。/dev/xvdXに対してシンボリックリンクファイル/dev/sdXを作成する下記のルールをコメントアウトします。
|
1 2 3 |
$ vi /etc/udev/rules.d/51-ec2-hvm-devices.rules # 以下の行をコメントアウト（先頭に#を記載）する。 KERNEL=="xvd*", PROGRAM="/sbin/ec2udev-vbd %k", SYMLINK+="%c" |
- ルートデバイスボリュームのシンボリックリンクファイル
/dev/sda、/dev/sda1を削除します。 - iSCSIターゲットに再接続後、
lsblk -Sやmultipath --llコマンドを実行し、デバイスが正常に認識されていることを確認します。
Nitroベースのインスタンスを使用する場合は本対処方法は不要
OSバージョンに関わらず、Amazon Linuxを起動するインスタンスとして、Xenベースのインスタンスではなく、Nitroベースのインスタンス（M6など）を使用する場合は、前述の対処方法は実施不要です。
Nitroベースのインスタンスでは、EBS ボリュームはNVMeデバイスとして認識され、/dev/nvmeXnYのような名前が割り当てられます。NVMeデバイスに関するルールは/lib/udev/rules.d/51-ec2-hvm-devices.rulesなどに記載されていないため、/dev/sdXのようなシンボリックリンクファイルは作成されません。
