为什么在重新启动后多路径devnode会改变？

Question

当我命令多路径-ll时，输出显示如下所示。

ocr3 (149455400000000000000000001000000ca0200000d000000) dm-9 IET,VIRTUAL-DISK
[size=980M][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
 \_ 1:0:0:11 sdo 8:224 [active][ready]
\_ round-robin 0 [prio=0][enabled]
 \_ 1:0:0:10 sdn 8:208 [active][ready]

然而，在重新启动后，sdo和sdn等相同的CRE3‘S节点发生了变化。

我认为这是一个一致性问题。

为什么devnode在重新启动后会改变呢？

如何使devnode在重新引导过程中永久化？

Answer 1

为了允许热插拔和动态重新配置，您不应该假设/dev/sd*设备节点在一次引导到下一次启动时保持不变。

在一个只有一个AHCI控制器的工作站上，顺序通常是静态的，因为它主要是由存储控制器驱动程序加载的顺序决定的:通常根磁盘的驱动程序在引导的initramfs阶段加载，在usb-storage之前。由AHCI控制器管理的磁盘的顺序随后被固定，因为控制器端口由驱动程序按端口号顺序探测。

但是在连接到SAN存储的系统上，事情就不那么简单了。可以有多个磁盘控制器(一个用于内部系统磁盘，然后一个用于每个SAN HBA)，在启动时，通常以PCI总线顺序探测HBA，然后以可能也取决于SAN配置的驱动程序特定顺序检测每个HBA中的LUN。单个HBA中的订单可能基于LUN WWID或其他一些存储配置细节。

而且每个HBA没有预先分配的/dev/sd*名称范围:一旦为每个HBA的LUN分配了名称，系统就会继续到下一个HBA，而不会在/dev/sd*名称中留下任何空白。

一旦将/dev/sd*名称分配给磁盘或LUN，就不能在系统运行时将其自动重新分配为指向另一个LUN，否则文件系统或数据库可能会损坏。在系统运行时，这种重新分配必须始终涉及sysadmin。只有在启动时才能自动重新分配它们。

因此，当SAN管理员为您的系统提供一个新的LUN时，它的WWID当然应该是唯一的，但是WWID值可能在现有LUN之前、之后或中间。当它是热添加，每个路径到它将得到下一个免费的/dev/sd*设备名称，所以他们将在所有现有的LUN之后。即使仅此一项，实际上也可以保证下次系统启动时，/dev/sd*名称的排序将发生变化。

当然，如果您想要的话，可以使用udev规则将/dev/sda*名称修正为特定的HBA和WWID。但这是一项很大的工作，收益很小。就内核而言，所有的/dev/sd*设备都应该执行完全相同的操作:如果您发现这不是真的，那么您已经发现了一个bug，您应该报告它。因此，他们的命令是没有必要的。

Linux内核开发人员在2.5.*开发周期中意识到了这一点，因为他们试图从在线可配置性中消除任何限制。现在有一些方法可以使您的系统配置完全独立于/dev/sd*名称：

• 如果使用传统分区，则可以使用/dev/disk/by-*设备名称而不是/dev/sd*设备，或者在/etc/fstab中使用UUID=或LABEL=语法。
• 如果使用LVM，它甚至不会持久地存储设备名称，而是在它可以看到的任何磁盘和分区上查找LVM签名，然后从那里动态地构建配置。这种情况在引导时会自动发生，每次运行vgscan时都会发生。(是的，有一些安全措施可以防止在使用磁盘时更改LVM映射。)
• 如果使用multipathing，它将显示多路径LUN(如果禁用friendly_names )、第一次看到每个WWID时分配的/dev/mapper/mpath*名称，然后持久存储在/etc/multipath/wwids中(或者RHEL/CentOS 6及更早版本中的/var/lib/multipath/bindings，如果/var是一个单独的文件系统.)，或者您可以自己指定的别名。

我曾经不得不管理一个旧的RHEL 3系统，它有SAN磁盘连接到它。最初，它只有一个HBA；然后添加了另一个HBA，用于冗余和SAN迁移。但它来自不同的供应商，因此无法获得特定于供应商的mulipath解决方案。我不得不使用(从那时起就放弃了) mdadm的多路径特性。它需要跟踪设备名称，就像您正在想的那样。两个字:它糟透了。当那个系统最终被淘汰时，我感到非常高兴。