实现ASM磁盘的两种方式：asmlib、udev

1、asmlib的介绍

ASMLib的是Oracle数据库10g及以上版本的自动存储管理功能的支持库。 oracle提供了该库的Linux的具体实现。关于asmlib程序的介绍，可以参考如下文档：

http://blog.csdn.NET/cymm_liu/article/details/7908962

从以上文档我们了解到，对于asmlib，常规情况下只是在单条路径下使用，那么，现在我们可以讨论下，在多路径的前提下，能否使用asmlib呢？

关于多路径的简介，参考文档：http://blog.csdn.net/cymm_liu/article/details/7927984

涉及多路径磁盘的问题  ：使用ASM中的多径磁盘有两个问题。 ASM不能两次看到了同样的磁盘的处理。如果是这样，它会导致错误。一个磁盘可以出现在一个多路径配置三次：  1、第一条路径到磁盘  2、第二条路径到磁盘  3、多路访问点

下面是一个例子：

系统有一个本地磁盘/dev/sda，和一个磁盘通过连接外部存储。该机具有两个连接或路径到外部存储。 linux的SCSI驱动程序，会看到两个路径。他们将显示为/dev/sdb和/dev/sdc的。系统可能会访问sdb或sdc，访问结束在同一个地方。  

果启用了多路径，将有一个多路径磁盘，例如/ dev/ multipatha，可以访问两个路径。也就是说，所有的I / O去访问multipatha这个磁盘可以使用两条路径。如果系统使用sdb这条路径，并且这条线路被拔掉时，系统会得到一个错误。但多路径磁盘会知道切换到sdc路径。  
大多数系统软件并不知道的多路径的配置。所以这些软件可以使用任何路径：sdb、sdc或multipatha，而且也不会知道其中的差别。 ASMLib程序也是这样，默认的配置情况下，并不会去关心具体使用哪条路径。只是提供了一个库文件。关于asmlib的作用，可以参考这篇文档：http://blog.csdn.Net/cymm_liu/article/details/7908962

ASMLib程序将只选择的路径之一，因为ASM无法处理两次看到了同样的磁盘。这就解决了第一个问题。 ASM只能看到一个路径，这就比较好了。

但是，又有一个问题：ASM看到哪条路径？ 在默认配置的情况下，ASMLib程序会选择它找到的第一个路径。这是由Linux 操作系统所报告的第一条路径。这就会取决于存储驱动程序，它可能是/dev/sdb，也可能是/dev/sdc/、还有可能是/dev/multipatha。。。

The system administrator wants ASMLib to always use the multipath disk. What's the point of having it if Oracle is not using it? There is no way, however, for ASMLib to know what a multipath looks like. It must be told via its configuration.

Disk扫描排序  

ASMLib程序安装后，磁盘被一个进程标记为专门供ASMlib使用的。在磁盘扫描进程运行的过程中，ASMLib会学习哪个磁盘可以被标记为供asmlib使用的。asmlib每次启动的时候都会运行这个磁盘扫描进程，扫描所有的磁盘，来标记（或者检查已被标记的）到底哪个磁盘可以被asmlib使用。系统管理员也可以手工运行磁盘扫描命令:/etc/init.d/oracleasm scandisks 强制扫描。  ASMLib程序检查每个磁盘操作系统列出他们的确切顺序。对于大多数系统来说，这是很好的。  

在最后一节中，我们描述了一个情况：操作系统的顺序是不够好。系统管理员希望ASMLib看到单一路径磁盘之前，先看到多路径磁盘。这允许asmlib选择多路径磁盘，并提供给Oracle使用。  

ASMLib程序允许两个磁盘扫描顺序的修改。首先，它允许排除某些磁盘。换句话说，ASMLib程序将完全忽略这些磁盘。其次，系统管理员可以指定首先要扫描的磁盘。在此列表中的磁盘先被扫描，其他不在此列表中的磁盘后被扫描。

一个多路径配置，可以用起来非常方便。系统管理员可以选择排除所有的单一路径磁盘， ASMLib程序将忽略他们，只扫描多路径磁盘。相反，管理员可以指定多路径磁盘扫描第一，的ASMLib将首先看到他们，在但路径之前。  

配置扫描的顺序  

ASMLib配置文件位于/etc/sysconfig/oracleasm，是一个软连接，链接到/etc/sysconfig/oracleasm-_dev_oracleasm，其实在读取这个配置信息的时候，都是读取的后面这个文件（也就是说，我们改变配置，也要改后面这个文件才能生效）它包含了所有的启动配置，通过/etc/init.d/oracleasm configure命令中指定的系统管理员。该命令不可以配置扫描排序。  

配置文件包含了许多的配置变量。 ORACLEASM_SCANORDER变量指定要扫描的磁盘的顺序。 ORACLEASM_SCANEXCLUDE变量指定的磁盘将被忽略（不被扫描）。

 The variables take a whitespace-seperated list of prefix strings to match。换句话说，如果一个磁盘开始的前缀字符与配置文件里的匹配。例如，前缀字符串sd将匹配所有的SCSI设备。磁盘sda开始与sd。请注意，他们不使用通配符。他们是简单的前缀，还要注意的是/dev/路径并不是前缀的一部分。  

NOTE: When scanning, only the device names known by the kernel are scanned. With device-mapper, the kernel sees the devices as /dev/dm-XX. The /dev/mapper/XXX names are created by udev for human readability. Any configuration of ORACLEASM_SCANORDER orORACLEASM_SCANEXCLUDE must use the dm prefix.

A couple examples:

NOTE: If you are hand editing file /etc/sysconfig/oracleasm, make sure the link to /etc/sysconfig/oracleasm-_dev_oracleasm is not broken.

Multipath Disks First

The system administrator configures ASMLib to scan the multipath disks first. In the ASMLib configuration file she edits the ORACLEASM_SCANORDER variable to look like so:

                                               
  ORACLEASM_SCANORDER="multipath sd"
                                            

During a scan, ASMLib first tries all disks that start with "multipath". The multipath device/dev/multipatha certainly matches. It is scanned first. Next, ASMLib tries all disks that start with "sd". This is all the SCSI disks. The local disk /dev/sda will be scanned, but it is not an ASM disk. The single path disks /dev/sdb and /dev/sdc are also scanned. They are ASM disks, but ASMLib will see that it already has a path to that disk. It will ignore them. Finally, ASMLib will scan any other disks that did not match either prefix.

 

Excluding Single Path Disks

The system administrator configures ASMLib to ignore the single path disks. In the ASMLib configuration, he edits the ORACLEASM_SCANEXCLUDE variable to look like so:

                                               
  ORACLEASM_SCANEXCLUDE="sdb sdc"
                                            

Here, the system administrator has been more specific. ASMLib should ignore exactly the disks /dev/sdb and /dev/sdc. It should not ignore other SCSI disks. While scanning, ASMLib will ignore those paths, only seeing the /dev/multipath disk. Once again, Oracle will use the multipath disk.

2、udev简单介绍

下面通过问答的形式，把udev的概念描述清楚：

问：udev是什么? 它的目的何在?

答：udev是一种工具，它能够根据系统中的硬件设备的状态动态更新设备文件，包括设备文件的创建，删除等。设备文件通常放在/dev目录下。使用udev后，在/dev目录下就只包含系统中真正存在的设备。

问：udev支持什么内核？

答：udev只支持linux-2.6内核，因为udev严重依赖于sysfs文件系统提供的信息，而sysfs文件系统只在linux-2.6内核中才有。

问：udev是一个内核程序还是用户程序？

答：udev是一个用户程序(user-mode daemon)。

问：udev和devfs有什么差别？

答：udev能够实现所有devfs实现的功能。但udev运行在用户模式中，而devfs运行在内核模式中。据称：devfs具有一些不太容易解决的先天缺陷。

问：udev的配置文件放在哪里？

答：udev是一个用户模式程序。它的配置文件是/etc/udev/udev.conf。这个文件一般缺省有这样几项：

udev_root=”/dev” ; udev产生的设备文件的根目录是/dev
udev_db=”/dev/.udevdb” ; 通过udev产生的设备文件形成的数据库
udev_rules=”/etc/udev/rules.d” ;用于指导udev工作的规则所在目录。
udev_log=”err” ;当出现错误时，用syslog记录错误信息。

问：udev的工作过程是怎样的？

答：由于没有研究过udev的源程序，不敢贸然就说udev的工作过程。我只是通过一些网上的资料和udev的说明文档，大致猜测它的工作过程可能是这样的：

当内核检测到在系统中出现了新设备后，内核会在sysfs文件系统中为该新设备生成一项新的记录，一般sysfs文件系统会被mount到/sys目录中。新记录是以一个或多个文件或目录的方式来表示。每个文件都包含有特定的信息。(信息是如何表述的，还要另外研究？)

udev在系统中是以守护进程的方式udevd在运行，它通过某种途径(到底什么途径，目前还没搞懂。)检测到新设备的出现，通过查找设备对应的sysfs中的记录得到设备的一些信息。udev会根据/etc/udev/udev.conf文件中的udev_rules指定的目录，逐个检查该目录下的文件，这个目录下的文件都是针对某类或某个设备应该施行什么措施的规则文件。udev读取文件是按照文件名的ASCII字母顺序来读取的，如果udev一旦找到了与新加入的设备匹配的规则，udev就会根据规则定义的措施对新设备进行配置。同时不再读后续的规则文件。

问：udev的规则文件的语法是怎样的？

答：udev的规则文件以行为单位，以”#”开头的行代表注释行。其余的每一行代表一个规则。每个规则分成一个或多个“匹配”和“赋值”部分。“匹配”部分用“匹配“专用的关键字来表示，相应的“赋值”部分用“赋值”专用的关键字来表示。“匹配”关键字包括：ACTION，KERNEL，BUS，SYSFS等等，“赋值”关键字包括：NAME，SYMLINK，OWNER等等。具体详细的描述可以阅读udev的man文档。

下面举个例子来说明一下，有这样一条规则：SUBSYSTEM==”net”, ACTION==”add”, SYSFS{address}==”00:0d:87:f6:59:f3″, IMPORT=”/sbin/rename_netiface %k eth0″
这个规则中的“匹配”部分有三项，分别是SUBSYSTEM，ACTION和SYSFS。而”赋值”部分有一项，是IMPORT。这个规则就是说，当系统中出现的新硬件属于net子系统范畴，系统对该硬件采取的动作是加入这个硬件，且这个硬件在SYSFS文件系统中的“address”信息等于“00：0d…”时，对这个硬件在udev层次施行的动作是调用外部程序/sbin/rename_netiface，传递的参数有两个，一个是“%k”，代表内核对该新设备定义的名称。另一个是”eth0“。    从上面这个例子中可以看出，udev的规则的写法比较灵活的，尤其在“匹配”部分中，可以通过诸如”*“, ”?“,[a-c],[1-9]等shell通配符来灵活匹配多个匹配项。具体的语法可以参考udev的man文档。

问：udev怎样做到不管设备连接的顺序而维持一个统一的设备名？

答：实际上，udev是通过对内核产生的设备名增加别名的方式来达到上述目的的。前面说过，udev是用户模式程序，不会更改内核的行为。因此，内核依然会我行我素地产生设备名如sda,sdb等。但是，udev可以根据设备的其他信息如总线（bus），生产商（vendor）等不同来区分不同的设备，并产生设备文件。udev只要为这个设备文件取一个固定的文件名就可以解决这个问题。在后续对设备的操作中，只要引用新的设备名就可以了。但为了保证最大限度的兼容，一般来说，新设备名总是作为一个对内核自动产生的设备名的符号链接（link）来使用的。

例如：内核产生了sda设备名，而根据信息，这个设备对应于是我的内置硬盘，那我就可以制定udev规则，让udev除了产生/dev/sda设备文件外，另外创建一个符号链接叫/dev/internalHD。这样，我在fstab文件中，就可以用/dev/internalHD来代替原来的/dev/sda了。下次，由于某些原因，这个硬盘在内核中变成了sdb设备名了，那也不用着急，udev还会自动产生/dev/internalHD这个链接，并指向正确的/dev/sdb设备。所有其他的文件像fstab等都不用修改。

问：怎样才能找到这些设备信息，并把他们放到udev的规则文件中来匹配呢？

答：这个问题比较难，网上资料不多，我只找到一篇文章来介绍如何写udev的规则。他的基本方法是通过udevinfo这个实用程序来找到那些可以作为规则文件里的匹配项的项目。有这样两种情况可以使用这个工具：

第一种情况是，当你把设备插入系统后，系统为设备产生了设备名（如/dev/sda）。那样的
话，你先用udevinfo -q path -n/dev/sda，命令会产生一个该设备名对应的在sysfs下的路径，如/block/sda。然后，你再用udevinfo -a -p/sys/block/sda，这个命令会显示一堆信息，信息分成很多块。这些信息实际来自于操作系统维护的sysfs链表，不同的块对应不同的路径。你就可以用这些信息来作为udev规则文件中的匹配项。但需要注意的是，同一个规则只能使用同一块中显示的信息，不能跨块书写规则。

第二种情况是，不知道系统产生的设备名，那就只有到/sys目录下去逐个目录查找了，反复用udevinfo　-a -p/sys/path…这个命令看信息，如果对应的信息是这个设备的，那就恭喜你。否则就再换个目录。当然，在这种情况下，成功的可能性比较小。

问: udev和devfs是什么关系
答: udev完全在用户态(userspace)工作，利用设备加入或移除时内核所发送的hotplug事件(event)来工作。关于设备的详细信息是由内核输出(export)到位于/sys的sysfs文件系统的。所有的设备命名策略、权限控制和事件处理都是在用户态下完成的。与此相反，devfs是作为内核的一部分工作的。

问: 如果udev不能完成所有devfs的工作的话，为什么把devfs标记为OBSOLETE/removed?

答: 引用 Al Viro (Linux VFS 内核维护者):

-devfs所做的工作被确信可以在用户态来完成。
-devfs被加入内核之时，大家寄望它的质量可以迎头赶上。
-devfs被发现了一些可修复和无法修复的 bug。
-对于可修复的 bug，几个月前就已经被修复了，其维护者认为一切良好。
-对于后者，同样是相当常一段时间以来没有改观了。
-devfs的维护者和作者对它感到失望并且已经停止了对代码的维护工作。

问: 但是当一个并不存在的/dev节点被打开的时候，udev并不能如devfs一样自动加载驱动程序。
答: 的确如此，但Linux的设计是在设备被发现的时候加载模块，而不是当它被访问的时候。

问: 不过等等，我确实希望 udev 可以在不存在的节点被打开的时候自动加载驱动。这是我使用devfs的唯一原因了。给udev 增加这个功能吧。
答: 不，udev 是用来管理/dev 的，不是用来加载内核驱动的。

问: 嗨，求你们了。这不难做到的。
答: 这么个功能对于一个配置正确的计算机是多余的。系统中所有的设备都应该产生hotplug 事件、加载恰当的驱动，而 udev 将会注意到这点并且为它创建对应的设备节点。如果你不想让所有的设备驱动停留在内存之中，应该使用其它东西来管理你的模块(如脚本, modules.conf, 等等) 这不是udev 的工作。

问: 但是我真的喜欢那个功能，还是加上吧
答: devfs用的方法导致了大量无用的modprobe尝试，以此程序探测设备是否存在。每个试探性探测都新建一个运行 modprobe 的进程，而几乎所有这些都是无用的。

问: 我喜欢devfs的设备文件命名方式，udev 可以这样命名么?
答: 可以，udev 可以使用 /dev 的命名策略来创建节点。通过一个配置文件，可以把内核缺省的名字映射到 devfs 的名字。可以看看udev 中带的 udev.rules.devfs 文件。注意: devfs 的命名方式是不被建议并且不被官方支持的，因为它所用的简单枚举设备的方式在设备可能被随时加入或删除的情况下确实是一个比较笨的方法。这些编号代给你的将只有麻烦，而并不能用来确定设备。看看那个永久性磁盘 (persistentdisk) 的规则就知道如何在用户态下正确的做这件事，而不是傻傻地列出设备。

问: udev 可以为哪些设备创建节点?
答: 所有在 sysfs 中显示的设备都可以由 udev 来创建节点。如果内核中增加了其它设备的支持，udev 也就自动地可以为它们工作了。现在所有的块设备都在被支持之列，大部分的主字符设备也是被支持的。内核开发者们正致力于让所有的字符设备都被支持。可以到linux-kernel邮件列表上寻找补丁或是查看补丁的状态。

问: udev 是否会去掉匿名设备数量的限制?
答: udev 完全工作于用户态。如果内核支持了更多的匿名设备，udev就会支持。

问: udev 是否会支持符号链接?
答: udev 现在就支持符号链接，每个设备节点拥有多个符号链接也是被支持的。

问: udev如何处理/dev文件系统?
答: 建议使用一个每次启动系统的时候重新创建的 tmpfs 作为 /dev 的文件系统。不过实际上udev并不关心那种文件系统在被使用。

问: 在 init 运行之前，udev 如何处理设备?
答: udev 可以被放入 initramfs 之中，并在每个设备被发现的时候运行。也可以让udev 工作在一个真的根分区被加载之后根据 /sys 的内容创建的初始/dev目录之中。

问: 我是否可以利用 udev 在一个 USB 设备被加载的时候自动加载上这个设备?
答: 技术上讲是可以的，但是 udev 不是用于这个工作的。所有的主流发布版 (distro)都包含了 HAL (http://freedesktop.org/wiki/Software_2fhal) 用于这个工作，它也是专门用于监视设备变更的，并且集成进入了桌面软件。

换个角度说，这可以简单的通过 fstab 来实现:/dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0
这样，用户可以用如下命令来访问设备:
$mount /media/PENDRIVE
同样不需要管理员权限，但却拥有了设备的全部访问权限。使用永久性磁盘链接(label, uuid) 将可以指定同一设备，无论其实际上的内核名字是什么。

问: 有什么我需要注意的安全问题么?
答: 当使用动态设备编号的时候，一个给定的主/从设备号可能在不同时间对应不同的设备，如果一个用户拥有对这个节点的访问权限，并且可以创建一个到这个节点的硬链接，他就可以如此得到一个这个设备节点的拷贝。当设备被移除之后，udev 删除了设备节点，但硬链接依然存在。如果这个设备节点之后被重新使用不同的访问权限被创建的时候，其硬链接仍然可以使用先前的访问权限来访问。(同样的问题也存在在使用 PAM 改变访问权限的 login 上。)

简单的解决方案就是通过把 /dev 放在 tmpfs 这样的单独的文件系统之上来防止建立硬链接。

关于到底使用asmlib，还是使用udev更有优势，可以参考文章：

http://www.oracledatabase12g.com/archives/why-asmlib-and-why-not.html