おそらく 1 か月前から、iscsi エラーが発生し、マウントに失敗するようになりました。これは、20.04.3 のアップデートとほぼ同時に発生しました。本題に入るために、次のコマンドを発行しました。
root@cor8910:~# iscsiadm -m 検出 -t 送信ターゲット -p readynas2 172.16.7.2:3260,1 iqn.2011-09.nas-8B-3E-60:thunderbird 172.16.7.2:3260,1 iqn.2011-09.nas-8B-3E-60:vmguests
root@cor8910:~# iscsiadm -m 検出 -t 送信ターゲット -p readynas1 172.16.0.2:3260,1 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5
上記の出力は正しいですが、iscsiadm -m node -o showを実行すると、4つのレコードBEGIN RECORD 2.0-874が表示されます。
node.name = iqn.2011-09.nas-8B-3E-60:thunderbird . . . node.conn[0].address = 172.16.7.2 node.conn[0].port = 3260
#レコード終了 #レコード開始 2.0-874 node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . node.conn[0].address = readyNAS1 #レコード終了 接続アドレスが 1 ではなく readyNAS2 であるため、これは不適切です。ドット付き 10 進数にする必要があります レコード開始 2.0-874
node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . . node.conn[0].address = 172.16.7.2< br/> node.conn[0].port = 3260
#END RECORD これは正しいのですが、なぜアドレスがドット付き 10 進数で、以前のホストが同義語だったのでしょうか? BEGIN RECORD 2.0-874
node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = 172.16.0.2 レコード終了 レコード開始 2.0-874
node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = readynas1 #end record 最後の 1 つも問題ありません。この不良ノード レコードを削除できません。Google で検索したドキュメントには、ubuntu にはない /var/lib/iscsi が示されています。
root@cor8910:~# ls -al /etc/iscsi/nodes/ 合計20
drw------- 4 ルート ルート 4096 10月9日 15:31 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 drw------- 3 ルート ルート 4096 10月9日 15:31 iqn.2011-09.nas-8B-3E-60:thunderbird
drw------- 4 ルート ルート 4096 10月9日 15:31 iqn.2011-09.nas-8B-3E-60:vmguests
問題は、より安全な場所に移動した defaults サブフォルダーにあったのではないかと思います。ただし、Thunderbird フォルダーはまだログインされず、fstab 経由でマウントされません。他のフォルダーはログインおよびマウントされます。起動したら、iscsiadm を発行して全員にログインし、Thunderbird プロファイルが指している Thunderbird LUN を手動でマウントできます。
間違っているものをすべて修正できるようにしたいのですが、何が間違っているのかがわからない場合、open-iscsi を消去して再インストールすると、問題は解決しますか? 'readyNAS2' Netgear の ultra 4 NAS ユニットの場合、ドット付き 10 進数で参照することを構成でどのように認識するのでしょうか。'readyNAS1' Netgear の 214 NAS は、そのアドレスのホスト ファイル シノニムを取得していますか?
長所と短所を考えた結果、iscsiadm を削除して再インストールしました。これは実際には問題なく機能し、静的ターゲットが検出され、ログインは迅速に進みました。しかし、再インストール後の再起動時に問題が再発し、スタートアップに静的ノードを誤って作成する何かがあることが分かりました。man iscsiadm によると、検出できるタイプは sendtarget のみで、isns.NO STATIC ですが、ビルドして使用すると失敗するようです。
答え1
どうやら、open-iscsi は、発行されるコマンドとその発行順序に非常に敏感です。これを理解する鍵は、テスト用の「バージン」環境を取得することです。最新の 20.04.3 iso の VM を作成し、open-iscsi の構成を進めました。VM/etc/hostsに再定義されたファイルがなかったため、ドット付き 10 進数アドレスの同義語がありませんでした。これが問題の一部だった可能性は高いと思います。
上記のコマンド シーケンスを試しましたが、うまくいきませんでした。失敗もせず、試行すらしませんでした。その後、この URL にたどり着きました。ゆっくりと注意深く読み、細心の注意を払って従うことが重要です。https://www.hiroom2.com/2018/05/05/ubuntu-1804-open-iscsi-en/これは 18.04 用に書かれたものですが、VM では完璧に動作しました。その結果を「本番」デスクトップで再現したところ、まったく同じ結果が得られました。
指示シーケンスでは特に次の点に注意してください。
node.startup を自動に変更する前に iSCSI ターゲットに接続していた場合は、node.startup を自動に変更した後で再度 iSCSI ターゲットに接続する必要があります。