【译】ZFS最佳实践指南-Part1

原文链接：http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide

1ZFS管理事项
1.1 ZFS存储池建议[/url]本节描述了配置ZFS存储池的通用建议。


1.1.1 系统

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

1.1.1.1内存与交换空间

• 推荐使用1GB以上的内存。
• 装载每个ZFS文件系统约耗费64KB的内存空间。在一个存在上千个ZFS文件系统的系统上，我们建议您为包括快照在内的每1000个所装载的文件系统多分配1GB额外内存。并对为其所带来的更长的引导时间有所准备。
• 因为ZFS在内核保留内存中缓存数据，所以内核的大小很可能会比使用其它文件系统时要大。您可以配置额外的基于磁盘的交换空间（SwapSpace）来解决系统内存限制的这一问题。您可以使用物理内存的大小作为额外所需的交换空间的大小的上限。但无论如何，您都应该监控交换空间的使用情况来确定是否交换正在进行。
• 如条件允许，请不要将交换空间与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或者镜像配置的逻辑设备。请参见后面的冗余配置的示例。
• 在创建复制的存储池配置中，请使用多个控制器达到了减少硬件故障和提高性能的作用，
  例如：

# zpool create tank mirror c1t0d0 c2t0d0

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

# zpool create tank mirror c1t0d0 c2t0d0 spare c1t1d0 c2t1d0

• 请定期运行zpool scrub来确定数据完整性问题。若您的驱动器是消费级质量的驱动器，则请考虑将scrub的进度以周为单位进行；若是数据中心级质量的驱动器，则请考虑以月为单位。
• 对模拟磁盘驱动器（SSD）的电子存储设备，ZFS也可以工作得很好。由于每字节成本相对较高，您可在这类存储池上开启压缩属性。

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

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

# zpool add tank c2t2d0

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

# zpool replace tank c0t2d0 c2t2d0

• ZFS能容许多种设备故障。
  • 对于简单的存储池来说，元数据（metadata）是双重冗余的，但数据并不冗余。
  • 您可以使用ZFS copies属性为数据设定冗余级别。
  • 若文件块不能被完全读取且没有冗余，ZFS会告诉您哪些文件受其影响。

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

# zpool replace tank c0t2d0         ### 错误：不能再创建数据因为不存在冗余

# zpool replace tank c0t2d0 c2t2d0  ### ok
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节。