☰

iSCSI 目标搞砸 - 重新映射目标和块设备

tag-icon • tag-icon block-device iscsi targetcli
iSCSI 目标搞砸 - 重新映射目标和块设备

我们已经成功运行 CentOS 7 服务器几个月了，有两个 iSCSI 目标，全部使用targetcli.这些是使用 MS iSCSI 启动器从 Windows 7 盒子安装的。效果很好。大约一个月前，我添加了另一个目标，要从第二台机器安装。看来我可能忘记了我需要跑步saveconfig。上周，我们开始评估元数据服务器 TigerStore。它安装在第三台 Windows 7 计算机上。我在 CentOS 机器上设置了第四个目标，用于使用 TigerStore 进行测试（它还使用 Windows 启动器来安装然后提供服务的目标）。再次忘记我需要saveconfig。

我们一直在使用所有四个目标，没有出现任何问题。事实上，我周五晚上就在使用它。然而，当我今天早上进来时，第一台机器上的目标已经安装了几个月，只显​​示一个驱动器号，当我点击时，给我一个权限错误。我检查了 Windows 机器#2，其安装的 iSCSI 目标也是如此。 TigerStore 服务器仍然连接到目标并且工作正常。

重新启动所有三台 Windows 机器，权限问题相同。现在是我真正搞砸的地方：重新启动 CentOS 服务器，并且两个目标配置显示没有 LUN（这是我没有运行 saveconfig 的两个配置）。因为……设备的位置发生了变化。重启前，一对是/dev/sdb1和/dev/sdb2，另一对是/dev/sdc1和。/dev/sdc2现在这些不同了，作为/dev/sdc我的系统驱动器，以前/dev/sdb是现在/dev/sda，/dev/sdc现在是/dev/sdb。因此，所有的映射都是一团糟。

所以我想我这里有一个由两部分组成的问题：

1) 我是否可以创建新的 LUN 以targetcli指向新的块设备位置，以便使映射正常工作（无需更改目标上的用户数据）？

2) 我可以强制系统/dev/sd*每次启动时使用相同的位置分配吗？

好的，三部分问题：

3）如果我不能做到#2，我应该采取什么不同的措施来确保这种情况不会再次发生。作为参考，这是 a 的输出targetcli ls：

o- / ..................................................................... [...]
  o- backstores .......................................................... [...]
  | o- block .............................................. [Storage Objects: 2]
  | | o- block1 ..................... [/dev/sdb1 (0 bytes) write-thru activated]
  | | | o- alua ............................................... [ALUA Groups: 1]
  | | |   o- default_tg_pt_gp ................... [ALUA state: Active/optimized]
  | | o- block3 ..................... [/dev/sdb2 (0 bytes) write-thru activated]
  | |   o- alua ............................................... [ALUA Groups: 1]
  | |     o- default_tg_pt_gp ................... [ALUA state: Active/optimized]
  | o- fileio ............................................. [Storage Objects: 0]
  | o- pscsi .............................................. [Storage Objects: 0]
  | o- ramdisk ............................................ [Storage Objects: 0]
  o- iscsi ........................................................ [Targets: 4]
  | o- iqn.2018-03.com.grd.t3 ............................ [TPGs: 1]
  | | o- tpg1 .............................................. [gen-acls, no-auth]
  | |   o- acls ...................................................... [ACLs: 0]
  | |   o- luns ...................................................... [LUNs: 1]
  | |   | o- lun0 ................ [block/block3 (/dev/sdb2) (default_tg_pt_gp)]
  | |   o- portals ................................................ [Portals: 1]
  | |     o- 10.0.0.1:3260 ................................................ [OK]
  | o- iqn.2018-03.com.grd:t1 ............................ [TPGs: 1]
  | | o- tpg1 .............................................. [gen-acls, no-auth]
  | |   o- acls ...................................................... [ACLs: 0]
  | |   o- luns ...................................................... [LUNs: 1]
  | |   | o- lun0 ................ [block/block1 (/dev/sdb1) (default_tg_pt_gp)]
  | |   o- portals ................................................ [Portals: 1]
  | |     o- 10.0.0.1:3260 ................................................ [OK]
  | o- iqn.2018-03.com.grd:t2 ............................ [TPGs: 1]
  | | o- tpg1 .............................................. [gen-acls, no-auth]
  | |   o- acls ...................................................... [ACLs: 0]
  | |   o- luns ...................................................... [LUNs: 0]
  | |   o- portals ................................................ [Portals: 1]
  | |     o- 10.0.0.1:3260 ................................................ [OK]
  | o- iqn.2018-04.com.grd:t3 ............................ [TPGs: 1]
  |   o- tpg1 .............................................. [gen-acls, no-auth]
  |     o- acls ...................................................... [ACLs: 0]
  |     o- luns ...................................................... [LUNs: 0]
  |     o- portals ................................................ [Portals: 1]
  |       o- 10.0.0.1:3260 ................................................ [OK]
  o- loopback ..................................................... [Targets: 0]
  o- srpt ......................................................... [Targets: 0]

谢谢！

答案1

解决方案是删除后台存储块和 lun（将目标保留在原处）。然后，我在 targetcli 中重建了块以指向正确的 /dev/sd* 位置。

展望未来，我们将使用 /dev/disk/by-partuuid 迁移所有这些内容，将后台存储映射到块设备，这应该可以解决持久性问题。

相关内容