2019独角兽企业重金招聘Python工程师标准>>>

ZFS最佳实践指南

（注：本文目前的写作背景是Solaris 10 以及 OpenSolaris，但同样对FreeBSD具有参考作用，

• 原文请参见：http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide）
• 其它参考：
  • Ubuntu上使用ZFS（Zettabyte File System）
  • 提升ZFS性能的10个简便方法
• 性能测试
  • Ubuntu测试-使用phoronix-test-suite
  • 六款优秀的 Linux 基准测试工具

1 ZFS管理事项

1.1 ZFS存储池建议

本节描述了配置ZFS存储池的通用建议。

1.1.1 系统

• 请使用64位内核运行ZFS。

1.1.1.1 内存与交换空间

• 推荐使用1GB以上的内存。

• 装载每个ZFS文件系统约耗费64KB的内存空间。在一个存在上千个ZFS文件系统的系统上，我们建议您为包括快照在内的每1000个所装载的文件系统多分配1GB额外内存。并对为其所带来的更长的引导时间有所准备。

• 因为ZFS在内核保留内存中缓存数据，所以内核的大小很可能会比使用其它文件系统时要大。您可以配置额外的基于磁盘的交换空间（Swap Space）来解决系统内存限制的这一问题。您可以使用物理内存的大小作为额外所需的交换空间的大小的上限。但无论如何，您都应该监控交换空间的使用情况来确定是否交换正在进行。

• 如条件允许，请不要将交换空间与ZFS文件系统所使用分区（slice）放在同一磁盘上。保证交换区域同ZFS文件系统分开。最佳策略是提供足够多的内存使您的系统不常使用交换设备。

• 更多的内存使用事项，请见：内存与动态重构（Dynamic Reconfiguration）建议。

1.1.2 存储池

• 如条件允许，架设每个系统的存储池请使用整个磁盘。

• 对于生产系统，考虑使用整个磁盘而不是分区（slice），有如下理由：

  • 允许ZFS开启磁盘的写缓存。但如果您使用有永久性写缓存的磁盘阵列，那么这一问题并不突出，作为虚拟设备的分区也可以受益于盘阵的写缓存。

  • 若在分区上包含有ZFS和UFS文件系统，则对待替换坏盘的恢复步骤则变得更加复杂。

  • 若在其他分区上还含有UFS文件系统，则ZFS存储池（和其下的磁盘），使用zpool import和export功能不易被迁移至他处。

  • 一般而言，维护分区会增加管理成本。应通过简化您的存储池结构来降低管理成本。

• 对于所有生产环境，请配置ZFS以便其可以修复数据不一致问题。使用ZFS的冗余技术，如raidz，raidz2，镜像，或者副本>1，不需要考虑在其下的存储设备上的RAID级别的实现。应用此类冗余技术，其下的存储设备到主机连接的故障都可以被ZFS发现并修复。

• 请不要用48个设备来创建一个raidz，raidz2或者镜像配置的逻辑设备。请参见后面的冗余配置的示例。

• 在创建复制的存储池配置中，请使用多个控制器达到了减少硬件故障和提高性能的作用，例如：

• 配置热备来加速硬件故障时的恢复速度。对于高数据损失平均时间（Mean Time To Data Loss，MTTDL ，译者注）的环境来说热备是至关重要的。例：

• 请定期运行zpool scrub来确定数据完整性问题。若您的驱动器是消费级质量的驱动器，则请考虑将scrub的进度以周为单位进行；若是数据中心级质量的驱动器，则请考虑以月为单位。

• 对模拟磁盘驱动器（SSD）的电子存储设备，ZFS也可以工作得很好。由于每字节成本相对较高，您可在这类存储池上开启压缩属性。

1.1.2.1 简单的或条带化的存储池限制

简单的或条带化的存储池有一些应被考虑的限制。

• 可通过两种方式实现对存储空间的扩充：

  • 添加另一磁盘以扩展条带（stripe）。这也会提升存储池的性能，因为更多的设备可以被并发使用。注意：当前的ZFS实现是，一旦添加，虚拟设备则不能被移除。

• 用更大的虚拟设备替代现有的虚拟设备

• ZFS能容许多种设备故障。

  • 对于简单的存储池来说，元数据（metadata）是双重冗余的，但数据并不冗余。

  • 您可以使用ZFS copies属性为数据设定冗余级别。

  • 若文件块不能被完全读取且没有冗余，ZFS会告诉您哪些文件受其影响。

• 对于简单存储池而言，替换故障硬盘既需要访问旧有设备也需要访问新设备，这是为了能够将旧数据放到新设备上。

1.1.3 多个存储池于同一系统

• 在ZFS存储池中的资源允许不同的文件系统在不同的时候受益于所有资源。这一策略可大幅提高在存储池内的任一文件系统性能。

• 若一些作业量需要更多的可预测的性能特点，那么您可考虑将作业量分给不同的存储池。

• 例如，Oracle日志记录器性能非常依赖于I/O响应时间，我们可以通过将这样的负载保持于一个单独的有最低响应时间的小存储池来实现。

1.1.3 根存储池建议

若您正在使用ZFS根文件系统（root file system），请保持根存储池（即存储池的数据集是被分配给根文件系统的）与用于数据的存储池分开。 关于这一策略存在几个理由：

• 在您不会想要放到数据存储池的根存储池上存在一些限制（与数据池相比，根存储池存在一些限制）。镜像存储池与单磁盘存储池是支持的。但是，RAID-Z或有一块磁盘以上的非复制存储池不行。（注：在 FreeBSD 上，如果不使用 ZFS 引导系统，而只是用它作为根文件系统，则没有这种限制）

• 数据存储池可以是体系结构无关的。这对在SPARC和Intel之间移动数据存储池是有好处的。根存储池是非常依赖于特定的体系结构的。

• 通常，我们认为将系统的“个性”同其数据分开是个不错的主意。这样的话，您就可以改变一个而不用改变其他的。

给我们当前分配的作为单独的文件系统（例如：根，/usr和/var）配置不同的存储池根本不合理。这或许都不是一个所支持的配置。对于这些目录有单独的数据集倒是可能，但只能在同一个存储池中。 关于ZFS和SVM镜像的根内容，请参见UFS/SVM节。

1.2 存储池性能事项

1.2.1 通用存储池性能事项

• 为了更佳的性能，请使用单个磁盘或至少只是由少数盘组成的LUN。通过使ZFS于LUN的设置中更可见，ZFS能够提供更佳的I/O调度决策。

• 依赖于作业量，当前的ZFS的实现相比于其他的基于分页的文件系统可以不时的使更多I/O被请求。如果吞吐量正在流向存储，由iostat来观察，其已接近存储和主机之间的信道链路的容量，调小zfs recordsize属性一般能提高性能。这种调整是动态的，但只是对新文件创建有影响。已存在的文件还是保持其原有的recordsize。

• 调节recordsize对顺序类型的负载没有帮助。调节recordsize的方式是针对使用随机少量的读写来密集的处理大文件的情况来提升作业量。

• 请参考ZFS与数据库建议

• 当前，存储池的性能可能会因为存储池很满且文件系统被频繁的更新而下降，如繁忙的邮件服务器。在这些情况下，请保持存储池的空间在80%以下以维持存储池性能。

1.2.1.1 单独日志设备

ZFS intent log（ZIL，ZFS意图日志）符合POSIX的同步事务（synchronous transactions）的要求。例如，数据库从系统调用返回时常常需要其事务要在稳定的存储设备上。在默认情况下，intent log从主存储池中分配块。然而，若使用独立的intent log设备，其可能会获得更佳的性能，像NVRAM或专用磁盘。请确定是否一个单独的日志设备适合您的环境：

• 实现单独的日志设备（log device）所体现的任何性能提升都依赖于设备类型、存储池的硬件配置、和应用的作业量。

• 日志设备可以是不复制或镜像的，但RAIDZ不被日志设备所支持。

• 日志设备的最小的尺寸同存储池中的最小设备尺寸相同，也是64MB。存储于日志设备上的实际数据量可能相对较少。当日志事务（系统调用）被提交时，日志块被释放。

• 最大的日志设备的尺寸应大概是物理内存的1/2，因为那是能被保存的实际数据的最大量。例如，如果一个有16GB物理内存的系统，其最大的日志设备应是8G。

• 对于日志设置信息和日志性能信息，请参见如下Blog：slog_blog_or_blogging_on来查看关于单独日志设备的总说明，参见《Solaris ZFS管理指南》（《Solaris ZFS Administration Guide》）。

1.2.1.2 内存与动态重构（Dynamic Reconfiguration）建议

ZFS的自适应置换高速缓存（Adaptive Replacement Cache，ARC）试图使用最多的系统可用内存来缓存文件系统数据。默认是使用除了1GB以上的所有的物理内存。当内存压迫性增长时，ARC会放弃内存。 请在如下情形时考虑限制最大ARC内存的使用范围：

• 当有已知数量的内存总是被应用程序请求时。数据库常常属于这一类。

• 在支持内存板动态重构的平台上，以防止ZFS将渐大的内核占据到所有的内存板上。

• 请求大内存分页的系统也会受益于对ZFS缓存的限制，这可将大的分页分解为基本分页。

• 最后，若系统上还运行有其他非ZFS文件系统，除了ZFS之外，最好再留一些空闲内存给那些文件系统作为缓存。

这些限制内存使用范围的方式被认为会使ARC不能缓存更多的文件系统数据，这可能会对性能有所影响。 总之，若内存既没被ZFS使用也没被其他系统组件使用，限制ARC则是浪费资源的。注意非ZFS文件系统通常仍会设法使用系统的空闲内存来缓存数据。 调节ARC的详细信息，请参考如下段落： http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Limiting_the_ARC_Cache

1.2.2 RAID-Z配置要求及建议

一个以N块X大小和P个奇偶校验磁盘的RAID-Z配置可以拥有大约（N-P）×X的字节并能承受P个设备故障而不破坏数据完整性。

• 配置单奇偶校验的RAID-Z需要3块磁盘起（2+1） 。

• 配置双奇偶校验的RAID-Z2需要4块硬盘起（2+2） 。

• 配置三奇偶校验的RAID-Z3需要6块起（3+3）。

• 推荐的每组磁盘数在3至9之间。如果您有更多的磁盘，请使用多个组。

有都市传说认为 ZFS 应配置为 (N+P），其中N为2的整数次方幂而P为与对应 RAID-Z/RAID-Z2/RAID-Z3 的奇偶校验盘数量，并且对性能影响很大。这种说法是没有科学根据的。

1.2.3 镜像配置建议

• 在设备数上没有可实际影响的限制

• 在SUN Fire X4500服务器上，请勿用48个设备创建一个镜像。请考虑创建24个两两设备的镜像。这一配置将磁盘容量缩小了1/2，但多至24个磁盘或每一个镜像上1个磁盘都可以无故障的被失去。

• 若您需要更佳的数据保护，三路镜像可在MTTDL上比双路镜像有显著提升。但再升为四路（或更高的）镜像，则只是在数据保护上提供有限的改进。所以若三路镜像还不够，请考虑其他的数据保护方式。

1.2.3 我应该配置RAID-Z、RAID-Z2还是镜像存储池/h3>

通常需要考虑的是您的目标是最大磁盘空间还是最优性能

• RAID-Z配置可获得最大磁盘空间，且当被写入和读取大块（large chunk）（128KB或更大）的数据时通常都表现不错。

• RAID-Z2配置提供了卓越的数据可用性且其具备同RAID-Z相似的特点。相比于RAID-Z或双路镜像，RAID-Z2具有显著更佳的数据损失平均时间（MTTDL）。

• 镜像配置消耗更多的磁盘空间，但通常其具备更好的随机少量的读取能力。

• 如果您的I/O是大量的、顺序的、或是写频繁的，则ZFS的I/O调度器会将其汇集起来，以这样一种方式您会获得很高效的磁盘使用而不论数据的复制模型。

为获得更好的性能，在大量的、不可缓存的、随机读取负载上，镜像配置要显著的胜于RAID-Z配置。 关于RAIDZ所需注意事项的更多信息，请参考如下blog： WHEN TO (AND NOT TO) USE RAID-Z

1.2.4 RAID-Z配置举例

例如在Tunmper上的RAID-Z配置，将c3t0和c3t4（磁盘0和1）镜像作为您的根存储池，剩下的46块可用磁盘用于用户数据。如下的raidz2配置举例说明了如何配置剩下的46块盘：

• 5×(7+2)，1个热备，17.5 TB

• 4×(9+2)，2个热备，18.0 TB

• 6×(5+2)，4个热备，15.0 TB

1.3 ZFS迁移事项

1.3.1 ZFS与分区技术（Zone）

当在安装有区域（zone）的Solaris系统上使用ZFS数据集（dataset）时请牢记如下几点：

• 当前您还不能给区域关联ZFS快照。

• 在Solaris 10发行版中对于全局区域（global zone）的根路径（root path）或非全局区域（non-global zone）请不要使用ZFS文件系统。

• 您可以在Solaris Express发行版中使用ZFS作为区域的根路径，但请牢记修补或升级这些区域是不被支持的。

想要了解区域使用ZFS的更多信息，请参见如下FAQ条目： [1]（http://opensolaris.org/os/community/zones/faq/#cfg_zfsboot）

1.3.2 UFS/SVM

当下，您不能在当前的Solaris 10发行版中使用ZFS为根文件系统。如果您想使用基于镜像备份的根文件系统，您需要使用SVM将包含系统软件（root，/usr，/var，等等）的分区（slice）进行镜像。其他所有存储都可以使用ZFS来进行管理。请不要使用ZFS和SVM重叠存储。例如，您可以使用磁盘或分区作为SVM卷或者ZFS存储池的一部分。但请不要在相同的磁盘或者分区上使用SVM和ZFS配置。 当将数据从UFS文件系统迁移至ZFS文件系统时，请参考如下实践：

• 取消共享（unshare）现有的UFS文件系统

• 从之前的挂载点（mount points）取消挂载现有的UFS文件系统

• 挂载UFS文件系统至临时非共享挂载点

• 互起rsync实例，迁移UFS数据至ZFS文件系统

• 在新的ZFS文件系统上设置挂载点和sharenfs属性

1.3.2.1 UFS/SVM 交互

ZFS 可以不需要任何额外的卷管理软件即能很好工作。 如果您需要额外级别的卷管理，ZFS要求能将连续的1至4MB的逻辑块映射至连续的物理块上。若可以达到这一要求，我们就能以ZFS的功能使用卷了。

1.3.3 VxVM/FS

2 常规ZFS管理信息

• ZFS只管理在线数据。

• 关于配置存储池的更多信息，请参见，ZFS存储池建议。

• ZFS文件系统当被创建时便被自动挂载。

• ZFS 文件系统不需要通过修改/etc/vfstab被挂载。

• 当前，ZFS不提供像ufsdump和ufsrestore命令这样的全面的备份/恢复工具。然而您可以使用zfs send和 zfs receive命令来捕获ZFS数据流。您也可以使用ufsrestore命令来恢复UFS数据至ZFS文件系统。

• 更多的ZFS管理任务，请参看zfs.1m和zpool.1m联机手册。更详细的文档，请参考《Solaris ZFS管理指南》（《Solaris ZFS Administration Guide》）。询问ZFS问题，请加入opensolaris/zfs讨论组。

3 应用服务器使用ZFS事项

3.1 ZFS NFS 服务器实践

请参考如下课程所述之UFS至ZFS迁移经验：

• 存在用户主目录（home directory）被重命名但其并为被取消挂载。当新的主目录也被共享时，NFS却继续服务于旧主目录。

• 切勿混淆UFS的目录与在同样文件系统层面上的ZFS文件系统，这会搞乱管理和维护。

• 切勿混淆基于NFS原始共享的ZFS文件系统（NFS legacy shared ZFS file systems）与基于ZFS的NFS共享的文件系统（ZFS NFS shared file systems），因为这样的模型很难以维护。请使用基于ZFS的NFS共享的文件系统（译者注，即使用ZFS自带的sharenfs方式而不要使用NFS自己的通用的原始共享方式）。

• ZFS可以由sharenfs文件系统属性与zfs share命令共享。例如：

• 该语法自动共享文件系统。若ZFS文件系统需要被共享，请使用zfs share命令。例如：

关于跨NFS的ZFS的性能信息，请参阅ZFS与NFS服务器性能。

3.1.1 基于ZFS的NFS服务器优势

• NFSv4风格的ACL（访问控制列表）在ZFS文件系统上可用且ACL信息可自动通过NFS可用。

• ZFS快照可以通过NFSv4可用，这样挂载主目录的NFS就可以访问其.snapshot目录了。

3.2 ZFS主目录服务器实践

当规划您的ZFS主目录（home directory）时，请参考如下实践：

• 每个用户配置一个文件系统

• 使用磁盘配额和保留以管理用户磁盘空间

• 使用快照备份用户主目录

当从UFS文件系统向ZFS文件系统迁移数据时，请参考如下实践：

• 取消（Unshare）现有UFS文件系统的共享

• 从之前的挂载点（mount points）取消挂载现有的UFS文件系统

• 挂载UFS文件系统至临时非共享挂载点

• 互起rsync实例，迁移UFS数据至ZFS文件系统

• 在新的ZFS文件系统上设置挂载点和sharenfs属性

请参阅 #ZFS_NFS_Server_Practices section for additional tips on sharing ZFS home directories over NFS.

3.2.1 ZFS主目录服务器的好处

• 得益于ZFS的高容量架构，可以使其能够处理许多小文件与许多用户。

• 用户主目录（home directory）的额外空间可以通过添加更多的设备到存储池而轻松扩大。

• ZFS磁盘配额是一种便捷的管理主目录空间的方式。

• 使用ZFS inheritance属性可将属性应用于许多文件系统。

3.3 ZFS邮件/新闻服务器

3.4 ZFS软件开发服务器

3.5 ZFS备份还原建议

3.5.1 使用ZFS快照

• 可以使用ZFS快照作为备份用户主目录的快速便捷方式。例如，如下语法会创建在/tank/home中的所有主目录的递归的快照。

# zfs snapshot -r tank/home@monday

• 您可以创建滚动快照用来管理快照副本。要了解更多信息，请参考Blog：Rolling Snapshots Made Easy。

• 您可以使用zfs send和zfs receive命令存档快照至更持久的存储上。

• 您可以创建增量快照流（请看“zfs send -i”语法）。

• zfs send 和 receive命令不是企业级备份解决方案。

3.5.2 使用ZFS于AVS

Sun StorageTek Availability Suite（AVS），是一套Solaris的基于主机的数据服务，其同Veritas VVR（Volume Replicator）和Flashsnap（point-in-time copy，时间点副本）产品类似，当前在Solaris Express发行版中可用。 SNDR（Sun StorEdge Network Data Replicator）同ZFS send和recv功能不同，其具备的是固定时间（time-fixed）的复制功能。例如，您可以获得一时间点快照，复制它，或是基于先前快照的差别进行复制。AVS II与SNDR功能的结合，还允许您进行固定时间复制。其他模式的AVS SNDR复制功能允许您获得CDP（Continuous Data Replication，持续数据复制）。ZFS当前并没有这类功能。 关于AVS的更多信息，请参见OpenSolaris AVS项目。 请在此查看AVS/ZFS演示。

3.5.3 使用ZFS于企业备份解决方案

• Sun StorEdge Enterprise Backup Software（Legato Networker 7.3.2）产品可全面备份和恢复包括ACL的ZFS文件。

• Symantec NetBackup 6.5产品可完全备份与恢复ZFS文件，包括ACL，虽然其兼容性矩阵（Compatibility Matrix）（2007年9月） 很意外的没有提及ZFS。

• IBM的TSM产品也可被用于备份ZFS文件。但是具体的支持性不是非常清晰。基于TSM支持的文档在IBM的站点，ZFS的ACL可被TSM client 5.3支持。已被确认（SUN内部）可在5.4.1.2上正常工作。

tsm> q file /opt/SUNWexplo/output # Last Incr Date Type File Space Name — ————– —- —————

• ZFS快照可以在有快照的文件系统中通过.zfs目录访问。请配置您的备份产品跳过这些目录。

关于ZFS的企业级备份解决方案问题的最新信息，请参见ZFS FAQ 为了能充分利用ZFS的功能，如快照，来提高备份和还原的进度，ndmp服务会在Solaris（首先在OpenSolaris）中发行。根据这些附加功能，企业级备份解决方案可以通过充分利用快照来提升对大存储库的数据保护。

3.6 ZFS与数据库建议

关于正在进行的ZFS和数据库性能测试的信息，请参看zfs_and_databases。还可参见ZFS for Databases

概要说明

• 如果数据库针对I/O使用固定磁盘的块或记录尺寸，请将ZFS的recordsize属性设成与数据库一致。您可以在每个文件系统上做这一操作，即使是共享一个存储池的多个文件系统。

• 由于其copy-on-write设计，调小ZFS的recordsize是一种以牺牲批处理报告查询为代价而提高OLTP（On-Line Transaction Processing，联机事务处理）性能的方式。

• ZFS校验存于磁盘上的每个块（block）。这减轻了数据库层面上对校验数据的需要和额外的时间。若校验由ZFS代替了数据库的，所有的差异都可以在数据返回给应用程序之前被捕获和修正。ZFS在数据库上的性能是非常快的活动目标。保持对Solaris发行版的更新非常重要。

截至2007年7月，如下功能会对数据库性能产生影响：

• ZFS 放出多至35个并发I/O至每个顶级设备，且这可以导致服务的时间延长。

• ZFS对每一输入块进行一些多至64K的低级预取操作，这样做可令存储带宽饱和。详情请参见6437054号Bug以及这篇blog。

• 使用8K的预取并用5到10个并发I/O来帮助一些数据库的负载。对于调节这些值的做法请参看ZFS Evil Tuning Guide。这种调节需要有望在未来发行版中去除。

Oracle事项

• 为得到更好的OLTP性能，请将ZFS的recordsize同Oracle的db_block_size相匹配。

• 请在混合的批处理和OLTP中关注批处理报告

• 对Oracle日志请以默认的128K记录尺寸使用单独的文件系统。

• 在SXCE Build 68发行版中，您可以为ZFS intent log（ZIL）使用单独的设备创建ZFS存储池。更多信息，请参见separate intent log。请不要将ZFS intent log设备同Oracle日志相混淆。

• 最小化Oracle日志响应时间，以期在整个事务过程中只是唯一的I/O，这往往是我们所希望的。就SAN存储阵列而言，Oracle日志响应时间应是接近写至SAN缓存的响应时间的，因此没有必要在数据空间和日志空间中来划分主轴（spindle）资源：单一的存储池操作。但对于在JBOD存储上的Oracle来说，其已被看到使用被分出来的一套主轴（不受制于读或写的竞争）可以有助于日志的响应时间。这反过来可以对一些工作量有帮助，如这类在存储级别上有高写读比的操作。

PostgreSQL

• 限定ZFS ARC已在内存与动态重构（Dynamic Reconfiguration）建议中描述

• 关于对日志使用单独存储池，请参看上述Oracle事项。

• 请设置ZFS recordsize=8K（注意：请在任何数据文件的创建之前做这一设置！）

• 从日志存储池中初始化数据库，之后为每一个数据库创建一个新的表分区（tablespace）指向数据存储池

MySQL

参考：A look at MySQL on ZFS

• InnoDB:

• 限定ZFS ARC已在内存与动态重构（Dynamic Reconfiguration）建议中描述

• 关于对日志使用单独存储池，请参看上述Oracle事项。

• 请设置ZFS recordsize=8K|16K（注意：请在任何数据文件的创建之前做这一设置！）

• 之后请对数据和日志使用不同的路径（在mysql.conf）中设置

• MyISAM:

• 限定ZFS ARC已在内存与动态重构（Dynamic Reconfiguration）建议中描述

• 请为日志（WAL）创建独立的intent log。若您没有该功能（即您运行在Solaris 10发行版），那么请创建至少两个存储池，一个存数据，一个存日志（WAL）

• 关于对日志使用单独存储池，请参看上述Oracle事项。

• 请设置ZFS recordsize=8K|16K（注意：请在任何数据文件的创建之前做这一设置！）

请参阅一些在PostgreSQL和MySQL中用db_STRESS性能测试获得的真实结果。

3.7 ZFS与复合存储事项

• 某些存储子系统会将数据暂放在固态内存设备，如存储阵列上的NVRAM，允许其以非常低的响应时间响应写操作。这些内存设备通常被认为是稳定的存储，在一定意义上其能幸免于掉电或其他类的崩溃。在关键时刻，ZFS是不知道该内存存储器的持久性的，并且要求该存储器的数据同步至磁盘。若这些存储器真的被确定为是稳定的，存储系统应被配置为忽略这些来自ZFS的请求。

3.8 驱动问题

4 ZFS管理/观察工具

5 虚拟化事项

5.1 ZFS与虚拟带库（VTL）

虚拟带库解决方案是通过对模拟磁带、磁带驱动器和带库的使用而出现的一种硬件与软件的结合体。虚拟带库被用于备份/存档系统，被定位于用来减少硬件和软件的成本。 虚拟带库是大量磁盘空间的吞噬者，我们相信ZFS将允许其更有效和安全的管理大量的、在线磁盘空间。

• Falconstor虚拟带库–该虚拟带库需要磁盘块设备来工作。其不使用外部文件系统。因此目前不能使用ZFS和Falconstor虚拟带库相结合的方法。

• Copan 虚拟带库–同上（Copan 使用 Falconstor 虚拟带库）。

• 来自BakBone的NetVault–该备份解决方案包括了虚拟带库功能，其已经在运行有ZFS的Thumper上测试过。

5.2 ZFS与VMWare

6 ZFS性能事项

对于基本系统、内存、存储池和副本建议，请参考如下章节：

• ZFS存储池建议

• 我应该配置RAID-Z、RAID-Z2还是镜像存储池/p>

• Roch/Jim/Neel的Blog

6.1 ZFS与应用程序事项

6.1.1 ZFS与NFS服务器性能

配有ZFS的NFS，这被应用在许多不同地方并未报有明显不足。很多人报告对性能表示失望，但这恐怕是将跨NFS的ZFS的性能同本地文件系统所比较了。众所周知相比于本地或直连的文件系统而言，提供NFS服务会明显降低速度。尤其是对于低线程并发的作业量而言。有一种危险的创建更优的跨NFS的ZFS的方式，是以牺牲数据完整性为代价设定内核变量zil_disable。该参数的设定并不被推荐。 请参考：ZFS与数据库建议。 关于跨NFS的ZFS性能的更多详细信息，请参见 zfs and nfs。

• Web 服务器

• 流作业量

6.2 ZFS文件系统的其他行为与使用误区

6.3 DTrace剖分（profile）以分类应用程序

6.4 性能优化

6.5 调节与策略设置

6.6 ZFS更多事项

• 压缩

• 校验和- 校验问题已被测量过，约1GHz的CPU可以校验500MB/sec的数据。

• RAID-Z

• 截至Solaris 10 11/06发行版时，校验和，压缩，和RAID-Z奇偶计算全部出现在线程同步存储池数据的上下文中。在重负载情况下，该线程可能成为性能瓶颈。在未来发行版中所有这类计算有望在并发线程中完成。通过修复了6460622号Bug之后，压缩问题已不再是单线程，且会成为Solaris 10 8/07发行版的一部分。

6.7 可扩展性

转载于:https://my.oschina.net/u/2306127/blog/2251130

来源：weixin_33819479