By: Ben Martin

作者：Ben Martin  翻译：jianxin

Linux内核包含了在软件中执行RAID-1的支持。RAID-1在两个或更多的磁盘上保存相同的文件系统，所以你可以丢失所有的数据，只要你保存有最后一张磁盘你就可以恢复所有的数据。这看起来很棒直到你考虑到一个RAM中的错误，突然的断电，或者另一个你机器上的硬件设备，都潜在的可能损坏你之前数据。有了Chiron FS,你就可以在网络上的两台机器的磁盘上维护一个RAID-1，这样如果一台机器瘫痪了，你仍然可以访问你的文件系统。

当然，在你维护一个RAID-1时，如果一个机器不能正常工作了但是网络还是了连通的，那么Chiton FS可能会很高兴的从不能正常工作的机器上复制有害的文件到其它机器，但是这可能是一个你愿意去冒的风险，考虑一下，所有你需要的只是两台成本很低的PC和一个网络连接。你总是可以增加其它的解决方法来改善你的数据安全和可用性。

最主要的Chiron FS的需求是你希望维护的RAID-1的位置是可以作为一个文件系统通过Linux内核挂载的。比如说，你可以使用本地的已挂载的ext3文件系统和一个从使用NFS或者sshfs的备份机器挂载的XFS文件系统，并且使用Chiron FS来使两个文件系统存储相同的内容。

在openSUSE 10.3平台上，你只需要点击一下鼠标就可以安装Chiron FS了，但是在Fedora和ubuntu上是不可以的。Chiron FS 的下载页面包含了Ubuntu Hardy和Gutsy的软件包，当然还有Fedora 8 的。我在一个64位的Fedora 8机器平台上使用Chiron FS 版本1.0.0从源代码建立这个软件。安装方法是很平常的命令 ./configure;make;sudo make install。

下面展示的是安装和Chiron FS的简单实用方法。首先建立了一个目录，我用它来包含我希望复制的文件系统。在这个例子中我的另一个服务器文件系统和我本地磁盘的文件系统是相同的，但是它也可以很容易的使用在NFS文件系统上。--fsname 参数不是必需的但是它总是一个好主意来给出你的文件系统的描述名称。接下来，我在Chiron FS 的~/my-chiron目录上建立了一个文件并且检查它在复制的文件系统/tmp/chiron-testing/my-other-server-filesystem.

内是否存在。

$ mkdir /tmp/chiron-testing

$ cd /tmp/chiron-testing

$ mkdir local-disk-filesystem

$ mkdir my-other-server-filesystem

$ mkdir ~/my-chiron

$ chironfs --fsname chiron-testing /tmp/chiron-testing/local-disk-filesystem=/tmp/chiron-testing/my-other-server-filesystem ~/my-chiron

$ df ~/my-chiron

Filesystem           1K-blocks      Used Available Use% Mounted on

chiron-testing        15997880  10769840   4402288  71% /home/ben/my-chiron

$ date > ~/my-chiron/test1

$ cat ~/my-chiron/test1

Thu May 29 15:17:30 EST 2008

$ cat /tmp/chiron-testing/my-other-server-filesystem/test1

Thu May 29 15:17:30 EST 2008

...

$ fusermount -u ~/my-chiron

当使用Chiron FS时，隐藏文件系统的复制版本是它不能够被直接访问是一个好主意（在这个例子中是在/tmp/chiron-testing中），这样你就不会漫不经心的使用它们并且避开了数据的复制。

Chiron FS包含了对于较慢镜像的联机和支持。联机可以让你知道什么时候一个复制失败了，这样你就可以在最后的复制失败和丢失所有数据之前采取措施。当一个读请求被交给Chiron FS，它将会使用一种轮叫调度算法从复制之一获得一个数据。你可以规定一个特殊的比其他的较慢的复制，这样Chrion FS将会避免它当数据必须被读取但是仍然复制所有的文件系统更新到那个较慢的复制。这是很有用的如果你正在用Chiron FS维护一个不再现场的备份；它让你避免从你的不在现场的复制读取数据的速度和花费的惩罚，然而复制的文件系统仍然会不在现场的改变。

你也可以通过挂载在/etc/fstab建立你的Chiron FS。在下面的安装中我在/data建立了一个文件系统，我复制它的数据到/noaccess/local-mirror ，在机器p1上NFS文件系统到/plexport。在fstab文件中/plexport前面的冒号告诉Chiron FS这是一个较慢的复制，所以它将会试图从NFS文件系统读取。因为Chiron FS是一个FUSE文件系统，你必须明确allow_other选项来让除了最初挂载Chiron FS的用户之外的用户可以访问它。

# cat /etc/fstab

...

p1:/p1export                                /p1export   nfs defaults 0 0

chironfs#:/p1export=/noaccess/local-mirror  /data       fuse allow_other,log=/var/log/chironfs.log 0 0

...

# mount /data

...

Performance

表现

我使用上面的使用一个NFS复制的安装方法来展示一些基准。在这个测试中，两个运行Chiron FS的机器“p1”都在Intel Q6600 CPU上运行一个虚拟机。因为机器有硬件虚拟，对于在虚拟机内部运行的表现最主要的影响是在两个虚拟机之间的网络连接。虚拟化，在理论上，可以对表现有一个积极的影响，因为两个虚拟机都操作在同一个物理硬件。在虚拟机上访问一个本地的文件系统和通过一个NFS访问的数据比较显示在这个标准中使用网络有一个重大的影响。然而，因为所有的测试都是在同一个虚拟机上的，相对的表现应该给出一个你可以期望的什么表现会变化的印象。

在这个测试中，我使用/noaccess/raw来测试这个机器访问相同的在本地用Chiron FS存储的复制的文件系统的速度。我也使用了一个/data-localonly文件系统，它包含两个本地的存储在/noaccess中的复制。我创建/data-localonly Chiron FS来移除虚拟网络连接作为标准的一个要素。提醒一下，网络Chiron FS正在使用一个挂载在/plexport的NFS共享。结果如下所示。

你可以看到，使用/data-localonly Chiron FS 大约需要直接使用两个本地文件系统两倍的时间。NFS文件系统的访问是很慢的相对于本地的文件系统。这个使用NFS表现惩罚是由于/data ，在这里进行的操作需要比所有本地和NFS文件系统需要的操作更多。这些告诉我们在一个Chiron FS中，一个较慢的复制对于整体的表现有很大的负面影响。

为了测试告诉Chiron FS比本地磁盘慢的NFS文件系统的冒号选项，我也创建了Linux内核提取的一个打包，从/data和/noaccess/local-mirror目录中读取文件。冒号选项可以影响读取的表现，因为写，从本身特性来讲，不得不在每一个复制上操作已保持一致性。在这个测试中，/data是一个拥有/noaccess/local-mirror和/p1export NFS文件系统的Chiron FS。从/data创建一个打包大约需要30秒；/noaccess/local-mirror创建一个打包大约需要6秒。直接从NFS文件系统（/plexport）创建大约需要30秒。在/data 和 /p1export需要相同时间的事实让我相信冒号目前被忽略了或者我不能让它生效，这样读操作被用在了每一个复制上。

总结

使用Chiron FS移除所有的从内核源提取的文件需要足够的额外时间。额外的时间是不可避免的，但是是绝对有意义的。从打包文件的释放，另一方面，在使用有两个文件系统的Chiron FS时需要大约两倍的时间，所以这里Chiron FS释放和写操作平均起来并没有严重的表现影响。因为每一个写操作都需要写到两个磁盘上，Chiron FS释放包的速度不会很大程度的改善。当使用包含有一个挂载了NFS文件系统的Chiron FS时，你必须忍受在NFS服务器在操作中较慢的写操作。

它显示出目前的Chiron FS忽略了冒号选项，这个选项本应该允许你将一个复制标记为只读属性。一旦这个功能被存储，你应该可以告诉Chiron FS不要从NFS服务器读取，这样你就可以避免网络拥挤和在读操作的往返旅行从而限制了写操作的表现。如果你很满意你的NFS文件系统的表现，使用Chiron FS应该不会减慢速度并且可以提供更大的文件系统可用性和一个很低成本的对于硬件不能正常工作的防护。