ZFS文件系统和Sun

ZFS文件系统和Sun x4500数据服务器在互联网行业的应用

Xinfeng.liu@

2008年6月

简介

在Web 2.0的时代，互联网上的数据呈现了爆炸性的增长。大型互联网客户迫切需要一种大容量、廉价、节省空间的存储解决方案。Sun Fire x4500服务器结合Solaris的ZFS文件系统很好地满足了这种需求。

Sun Fire X4500 服务器可以提供四路 x64 服务器的卓越性能，最多可在 4U 机架空间内提供 48 TB 最高密度存储。该系统包含2 个双核 AMD Opteron 处理器，16GB内存，并内置了6个SATAII的磁盘控制器，48块热插拔的磁盘，以及4个千兆网口。该系统可以提供高数据吞吐量，而成本只是传统解决方案的一半。

Solaris 10包含的ZFS文件系统是对传统文件系统的一次革命性的创新设计，ZFS解决了文件系统的完整性、安全性和可伸缩性以及管理困难等重要难题。ZFS文件系统是世界上第一个128位的文件系统，其存储容量和文件数量几乎只受硬件的限制，非常适合互联网上的大数据量的应用。而且ZFS文件系统的checksum和transactional 的操作方式实现了端对端的数据安全，减少了为保证数据的高可靠性对昂贵硬件的依赖，大大降低了存储成本。另外，ZFS文件系统的管理非常简便，采用了存储池的管理，并包含了传统的卷管理器的功能，但无需传

统卷管理器的复杂的命令操作。由于ZFS的独特设计，ZFS文件系统无需mount，无需fsck，无需journaling，大大地简化了日常维护。

ZFS文件系统已包含在Solaris 10或opensolaris中，无需另外下载并且是免费的和开源的。

本文主要介绍ZFS文件系统和Sun x4500服务器作为互联网上文件服务器的典型应用和优化。其内容包括：

●ZFS文件系统的特点和调优

●ZFS文件系统的部署规划建议

●Sun x4500作为文件服务器的系统调优

ZFS文件系统的特点和调优

ZFS文件系统在设计上与传统的文件系统有很大的不同。我们需要对ZFS的几个基本概念有

所了解：

Record Size

Record Size 也就是通常所说的文件系统的block size。ZFS采用的是动态的Record Size，也就

是说ZFS会根据文件大小选择*适合*的512字节的整数倍作为存储的块大小，最大的Record Size为128KB。通常没有必要手工设置Record Size。如果手工把Record Size调小，将不会得到空间的节省，并且常常会影响性能。ZFS的Block是计算checksum的单位，一个文件用到的block越多，计算checksum以及维护metadata的开销就会越大。

目前ZFS的版本下，只有一种情况需要手工调小Record Size：大文件上的小数据量的更新。常见的情况是数据库的数据文件在ZFS上，并且是做OLTP为主的应用。原因是大文件的blocksize是128KB，如果只更新其中一小部分数据，由于ZFS是copy-on-write的方式来更新数据，这种情况下仍然要读写128KB的数据，造成了不必要的开销。

另外，修改了Record Size后，对之前创建的文件不起作用。

ARC (Adaptive Replacement Cache)

这实际上是ZFS的文件系统的cache。它是一个可以自动伸缩的cache。目前一个操作系统实例里只有一个ARC，不管这个操作系统上有多少个ZFS Pool。而且metadata和实际的数据都共用这个ARC。

如果没有其它应用或操作系统本身争用内存，ZFS会尽可能多地使用物理内存作为cache。如果事先知道应用程序或操作系统需要使用多少内存，可以考虑限制ARC的大小。在/etc/system 中设置，例子：set zfs:zfs_arc_max=0x200000000 （设置ARC最大为8GB）

还可以使用如下工具来监测ARC的使用情况。

各列的含义，在这个Perl脚本里有描述。该工具的下载地址是：

/wiki/index.php/Arcstat

TXG (Transaction Groups)

应用的文件写操作一般分为两种，同步写和普通写操作。同步写是指写操作必须物理地写到

存储介质上才能返回给应用，通常这种情况发生在open文件时指定了O_DSYNC或O_SYNC

属性，以及调用fsync()等；普通写操作是指写操作写到文件系统cache里即可返回给应用，通常以普通方式打开文件后的write()，fwrite()操作都是这种操作。TXG (Transaction Groups)则是负责管理如何将文件系统cache（ARC）里的数据同步到磁盘上的机制。

对于写进文件系统cache里的每一个数据都会被编入一个TXG，通常情况下每隔5秒钟或文件系统cache里有太多脏数据（待写入磁盘的数据达到ARC的一半），当前TXG里的所有数据会被同步到磁盘，同时启动下一个TXG。每一个ZFS Pool同时最多会有3个TXG，分别处于

3种状态：open, quiescing, syncing。当TXG不能在5秒内把数据同步到磁盘上时将会影响open TXG，从而引起应用写操作的阻塞。这个现象叫做写抑制（throttling）。

当前的Solaris 版本（Solaris 10 8/07）对写抑制的控制不是非常好，当进行密集的写操作并且ARC较大、磁盘系统较慢时容易使TXG同步数据的时间非常长，发生throttling从而使应用的后续写操作的响应时间非常长。在新的opensolaris发行包里，这个问题已经有了很大的改进，ZFS会监测ARC接收数据的速度和ARC数据同步到磁盘上的速度，并自动调整ARC接收数

据的速度。另外ARC脏数据的大小限制改为1/8物理内存。通过这种控制可以使应用的写操

作响应时间更为均匀稳定。

ZIL (ZFS Intent Log)

对于同步写操作，ZFS为系统中每一个ZFS文件系统维护一个ZIL(ZFS Intent log)。同步写操

作的数据会先写入ZIL，并且会把磁盘的write cache的数据同步到磁盘上，然后应用的写操作返回。当文件提交命令发生时，ZFS会把ZIL里该文件的数据同步到磁盘上。

缺省情况下，ZIL是在ZFS存储池中动态分配的。某些同步写操作（比如数据库的联机重做日志或NFS COMMIT）如果响应时间慢将会极大影响性能。为了不使ZIL受其它I/O操作的影响，可以考虑采用一个专门的快速设备如NVRAM，SSD(Solid State Disk)等做ZIL，以下命令为ZFS存储池添加专用的ZIL:

zpool add log

另外，由于每次同步写操作会使ZFS把磁盘 write cache的数据同步到磁盘上，对于SAN的存储，频繁地flush cache会严重影响性能并且是不必要的。这个问题在OpenSolaris里已经得到

解决，解决办法是让设备驱动程序向存储系统发出适当的命令选项，从而使存储系统可以忽

略从non-volatile cache同步到磁盘的请求。前提是存储系统可以识别驱动程序发出的命令选项。I/O scheduler and priorities

缺省情况下，ZFS会限制每一个它能看到的存储池里的设备的I/O队列长度为35，并且通常读操作的优先级高于写操作。这种做法的目的是保证较好的I/O service time。

根据实际的应用需求和存储设备的不同，可能需要调整I/O队列的大小。比如为了得到更好地