在本文中我们将要讨论的是，如何抛开昂贵的SAN（存贮区域网络Storage Area Network，如全球文件系统GFS）或网络块设备在Linux下实现数据复制。我们在复制系统中采用了FAM（文件变更监视模块）和IMON（信息节点监视模块），这两个系统都是SGI当初为IRIX开发的。

 

　　SGI的员工真是非常的Cool，是他们将这两个程序移植到了Linux上并且公开了源代码。当花费已不再是问题时，可以采用基于GFS（全球文件系统）和SAN实现实时数据镜像；否则，数据共享及其它许多的选择就不可或缺了。有几个方法可供选择。在本文中我们将会对这些方法进行讨论，你将会看到它们各自的优缺点。

 

　　为何要用复制替代共享？

 

　　难道假设文件服务器不向客户端提供共享数据吗？是的，假设的工作环境确实是这样的。如果我们正在使用的文件服务器是通过NFS或SMB之类软件的共享文件的，系统中就会存在一个”瓶颈”和”引起系统故障的关键点”。若是在GFS之上通过共享的存贮设备（SAN或多通道的SCSI）共享数据，这种配置不但代价昂贵，并且这种存贮盒还会成为”引起系统故障的关键点”。也可以用NBD（网络块设备）建立一个网络镜像，但这不是一种常用的方式，NBD本身有些缺限，它非常难于设置管理，如果你只是要在少数几个WEB服务器间复制数据，用NBD只会给你带来更多的麻烦。

 

    尽量简单

 

　　方案一：

 

　　两台WEB服务器中的一台为主服务器，另外一台是备份服务器。要求备份服务器上的文件要与主服务器上的保持相同,这很简单吧。

　　但是如何使其自动工作呢？用户每天得多次FTP到主服务器上复制数据。但当主服务器发生错误、由备份服务器接管系统时会发生什么呢？由于这种备份操作不是实时的，备份服务器中的数据肯定与主服务器不一致，这时管理员会非常恼怒J。你当然可以运行一个计时守护程序，每隔5秒运行一次”rsync –av –delete source destination”，但这样做会增加机器的负荷，影响系统的运转。

 

　　方案二：

 

　　有一台FTP服务器用来保存更新web数据，而六个web服务器使用dns轮转方式实现负载平衡，这样可以保证每台服务器上的数据都是相同的。这样我们就可以避免使用NFS，但是这样的解决方案并不能令人满意。

　　那么最好的解决方法是什么呢？应该是”只有在数据发生变化时才将文件复制到各个web服务器上”，如果文件没有发生变化就什么也不作。这也就是我们使用”fam”来做的工作。

 

　　使之智能工作那么，我们怎么知道文件发了变化呢？我想M$ 的Windows程序开发员会这么说：我们可以每隔几秒就搜寻目标目录一次，将其中的文件与缓存中保存的文件做比较，看文件时间戳及大小是否发生了变化。对，没错，是这样。这是种轮询的工作方式，它的问题在于查找并比较文件的时间戳和大小，它的代价是昂贵的。你能想象在WEB服务器上每隔5秒就运行一次”ls –lR /somedirectory”造成的后果吗？最好的方法应该是：文件被改动的时候能够有人告诉我们，这样我们可以采取相应的动作。这正是”IMON”要做的工作。

 

    什么是FAM

　　fam就是文件变更监视模块，它向应用程序提供了一组API，当指定的文件或目录发生变化时，由其向应用程序发出通知。FAM由两部分组成：后台守护程序fam，它负责接收请求和发送通知；库文件libfam，客户端应用程序用它来与FAM通信。若远程主机打开了受监视的文件，本地的fam会与远程主机的fam联系，将请求发送给远程fam。Fam也可以在某个文件开始或停止运行时通知它的客户端。（比如：在IRIX交互桌面中，如果一个程序正在运行那么它的图标就会不会闪烁）。Fam是由Bruce Karsh在1989年为IRIX编写的，并由Bob Miller在1995年重写。这个公开源代码的fam版本构建并运行于Linux和IRIX之上，与IRIX6.5.8中的fam相同。

 

　　什么是IMON？

　　imon就是信息节点监视模块，它是内核的一部分，当文件有变动时由它通知fam。由应用程序告诉fam对某个目录或文件进行监视，fam再将这个请求传送给imon。当被监视的这些文件有变化时，内核通知imon，再由imon通知fam，最后由fam通知负责监视这个文件的应用程序。imon是由Wiltse Carpenter在1989年为IRIX的内核编写的，再由Roger Chickering移植到Linux下。Linux下的imon内核补丁与IRIX下的imon在许多方面都很类似，只是与内核文件系统的挂接代码不同。

 

　　安装FAM和IMON

 

　　可从SGI的网站下载FAM和IMON，具体详情请查看后面的资源列表。IMON是一个内核补丁，内核通过它监视内的解决方案存在一个小问题：碰到比较大的目录就不工作了，如含有四千到五千个子目录的情况。可能是内核不堪重负了。