VMwareでのiSCSIのトラブルシューティングです。
環境は「VMware ESXi 6.5」を想定しています。
参考
【Linux CentOS7】 Multipath について詳しく解説
iSCSIとは
iSCSIとはVMware ESXi(ホスト)と外付けストレージ(NetApp、3PERなど)との間でイーサネット接続を使用して通信をします。
ホストサーバーにiSCSIホストバスアダプタ(HBA)が付属している場合はHBAを利用し、HBAがなくてもNIC(ネットワークインターフェイスカード)で通信をすることができます。
そのためファイバーチャネルに比べて費用や運用コストが低いです。
iSCSIはクライアント/サーバーシステムの構成
簡単にiSCSIの構成例です。
下図のように「iSCSI」は、クライアント/サーバーシステムの構成になっています。
イニシエータ
iSCSIの「接続元(From)」です。
ターゲット(外部ストレージ、NetApp、HPE 3PERなど)にコマンドを実行する側です。
VMware ESXiホスト側の HBA(Host Bus Adaptor)が担当します。
イニシエータが「クライアント」の位置づけになります。(サーバーのリソースを利用します)
イニシエータとは「initiator(創始者、首唱者、教導者など)」です。
SCSIではイニシエータはデータの読み書き命令を発する役割のことを言います。
ターゲット
iSCSIの「接続先(To)」です。
イニシエータから、コマンドを受け取りデータの書き込み、読み出しを行うストレージのことを言います。
ターゲットが「サーバー」の位置づけになります。(ディスクというリソースを提供するためです)
VMware側イニシエータの例
VMware側のイニシエータの構成はこのような名前になっています。
- VMware側デバイス : HP iSCSI Disk (naa.xxxc0ff000293xxx08xxxd2xxx00000) など
- VMware側アダプタ : vmhba64 iSCSI Software Adapter iscsi_vmk など
- VMware側ID : iqn.1998-01.com.vmware:xxx-xxx-001-xxxxxxx など
naa.xxxc0ff000293 ← アレイが認識している LUN の一意の naa ID
vmhba64 ← ストレージアダプタには「vmhbaXX」の形式のIDが割り当てられる
- 物理PCIエイリアス名 : vmhba 0-31
- vmlinux論理エイリアス名 : vmhba 32-64
- ネイティブドライバ論理エイリアス名 : vmhba 64-95, 128-159, …
iqn ← IQN(iSCSI Qualified Name、iSCSI イニシエータ修飾名)の略です。IQNは「イニシエータ」や「ターゲット」を一位に識別するためのIDです。
iSCSIトラブルシューティング
「VMware ESXi」と「iSCSI」を接続してうまく認識してデータストアを設定できれば問題ありませんが、「環境」や「機種」や「組合せ」によってはうまく行かないことがあります。
その場合は以下を参考にトラブルシューティングをします。
iSCSIとの通信テスト
まずは「VMware ESXi」と「iSCSI」が通信できるか確認します。
# vmkping 192.168.1.10 |
iSCSIのポート確認
VMware ESXiイニシエータからターゲットのストレージのポート(TCP/3260)にアクセスできるか確認します。
# nc -z 192.168.1.10 3260 |
ESXi ホストに接続されているすべての LUN パスの一覧を表示する
# esxcli storage core path list |
ESXi ホストに現在接続されている LUN の一覧
# esxcli storage core device list |
LUN マルチパス情報のリストを表示する
# esxcli storage nmp device list |
iSCSIセッションの確認【アダプタ側のセッションを確認する】
アダプタのセッション一覧を表示します。
# esxcli swiscsi session list -d vmhba64 |
iSCSIセッションの確認【ターゲット側のセッションを確認する】
ターゲットのセッション一覧を確認します。
# esxcli swiscsi session list -t iqn.xxxxxxxxxx -d vmhba64 |
iSCSIのログ
/var/log/vobd.log ファイル
ESXiのジャンボフレーム対応について
ESXiでサポートされている最大「MTU」サイズは「9000」です。
ジャンボフレームとは MTU で使える最大サイズのフレームのことを言います。
MTUは「Maximum Transration Unit」の略で「最大転送単位」と訳せます。
定義された MTU サイズに対応するようにホストが適切に構成されていることを確認する
# vmkping -s <パケットサイズ> -d <iSCSIのIPアドレス> |
-s パケットサイズを定義します。
-d パケットを断片化しません。
【例】
# vmkping -s 8972 -d 192.168.0.10 |
なぜパケットサイズが「8972」なのでしょうか?
9000 – 8972 = 28bytes です。
さらに 28 bytes の内訳は IP ヘッダのサイズが 20bytes で ICMP のサイズが 8bytes から来ています。
Broadcomはジャンボフレームに対応していないか?
iSCSI SAN 構成ガイド
https://www.vmware.com/files/jp/pdf/support/VMware-vsp_41_iscsi_san_cfg-PG-JP.pdf
以下の記述あり。
「依存型ハードウェア iSCSI Broadcom 社の依存型 iSCSI アダプタはジャンボフレームをサポートしていません。」とあるので念のため確認した方がいいでしょう。
VMware ESXi側でのiSCSIパラメータ設定
VMware ESXi側でiSCSIのパラメータを設定できます。
- timeout(タイムアウト) → デフォルト 5秒 もしうまくiSCSIに接続できない場合 → 60秒に延ばす
- Delayed Ack(遅延ACK) → デフォルト チェック もしうまくiSCSIに接続できない場合 → チェックを外す
iSCSIログインエラー
設定がうまく出来ていないと以下のようにログインエラーが出力されることがあります。
2017-08-04T05:05:32.191Z: [iscsiCorrelator] 707816046us: [esx.problem.storage.iscsi.target.connect.error] Login to iSCSI target iqn.xxxxx-03.com.hp:storage.xxxxxx.xxx on vmhba64 @ vmk2 failed. The iSCSI initiator could not establish a network connection to the target. |
CHAP認証周りを確認します。
アクセスは出来ているけどターゲットへのログインに失敗しています。
iSCSIのアクセスコントロールに関して
iSCSIはセキュリティを保つためにアクセスコントロールをサポートしています。
主に以下の3つのアクセスコントロールがあります。
- イニシエータ名によるアクセス コントロール
- IP アドレスによるアクセス コントロール
- CHAP プロトコルによるアクセス コントロール
コメント