ZFS Best Practices Guide

From Siwiki

Jump to: navigation, search

Contents

[edit] ZFS Administration Considerations

[edit] ZFS Storage Pools Recommendations

This section describes general recommendations for setting up ZFS storage pools.

[edit] Systems
  • Run ZFS on a system that runs a 64-bit kernel
[edit] Memory and Swap Space
  • One Gbyte or more of memory is recommended.
  • Approximately 64 Kbytes of memory is consumed per mounted ZFS file system. On systems with 1,000s of ZFS file systems, provision 1 Gbyte of extra memory for every 10,000 mounted file systems including snapshots. Be prepared for longer boot times on these systems as well.
  • Because ZFS caches data in kernel addressable memory, the kernel sizes will likely be larger than with other file systems. You might configure additional disk-based swap areas to account for this difference on systems with limited RAM. You can use the size physical memory size as an upper bound for the extra amount of swap space that might be required. In any case, monitor swap space usage to determine if swapping occurs.
  • For additional memory considerations, see #Memory_and_Dynamic_Reconfiguration_Recommendations.
[edit] Storage Pools
  • Set up one storage pool using whole disks per system, if possible.
  • For production systems, use whole disks rather than slices for storage pools for the following reasons:
    • Allows ZFS to enable the disk's write cache for those disks that have write caches. If you are using a RAID array with a non-volatile write cache, then this is less of an issue and slices as vdevs should still gain the benefit of the array's write cache.
    • The recovery process of replacing a failed disk is more complex when disks contain both ZFS and UFS file systems on slices.
    • ZFS pools (and underlying disks) that also contain UFS file systems on slices cannot be easily migrated to other systems by using zpool import and export features.
    • In general, maintaining slices increases administration time and cost. Lower your administration costs by simplifying your storage pool configuration model.
  • If you must use slices for ZFS storage pools, review the following:
    • Consider migrating the pools to whole disks after a transition period.
    • Use slices on small systems, such as laptops, where experts need access to both UFS and ZFS file systems.
    • However, take great care when reinstalling OSes in different slices so you don't accidentally clobber your ZFS pools.
    • Managing data on slices is more complex than managing data on whole disks.
  • For production environments, configure ZFS so that it can repair data inconsistencies. Use ZFS redundancy, such as raidz, raidz2, mirror, or copies > 1, regardless of the RAID level implemented on the underlying storage device. With such redundancy, faults in the underlying storage device or its connections to the host can be discovered and repaired by ZFS.
  • Avoid creating a raidz, raidz2, or a mirrored configuration with one logical device of 40+ devices. See the sections below for examples of redundant configurations.
  • In a replicated pool configuration, leverage multiple controllers to reduce hardware failures and to improve performance. For example: 
     # zpool create tank mirror c1t0d0 c2t0d0
  • Set up hot spares to speed up healing in the face of hardware failures. Spares are critical for high mean time to data loss (MTTDL) environments. One or two spares for a 40-disk pool is a commonly used configuration. For example: 
     # zpool create tank mirror c1t0d0 c2t0d0 [mirror cxtydz ...] spare c1t1d0 c2t1d0
  • Run zpool scrub on a regular basis to identify data integrity problems. If you have consumer-quality drives, consider a weekly scrubbing schedule. If you have datacenter-quality drives, consider a monthly scrubbing schedule.
  • ZFS works well with the following devices:
    • Solid-state storage devices that emulate disk drives (SSDs). You might wish to enable compression on storage pools that contain such devices because of their relatively high cost per byte.
    • iSCSI devices. For more information, see the ZFS Administration Guide and the following blog: x4500_solaris_zfs_iscsi_perfect
    • Storage based protected LUNs (RAID-5 or mirrored LUNs from intelligent storage arrays). However, ZFS cannot heal corrupted blocks that are detected by ZFS checksums.

[edit] Hybrid Storage Pools (or Pools with SSDs)

  • The ZFS intent log (ZIL) is provided to satisfy POSIX requirements for synchronous transactions. The ZIL is allocated from blocks within the main storage pool. Better performance might be possible by using separate intent log devices in your ZFS storage pool, such as with NVRAM or a dedicated disk.
  • You can add an SSD to your storage pool as a separate log device. However, you can't currently remove a log device after it is added. With two SSDs, you can create a mirrored pair of log devices. In a mirrored log configuration, the second device could be detached. 
# zpool add tank log c0t4d0 c0t6d0
  • If a separate log device is not mirrored and the device that contains the log fails, storing log blocks reverts to the storage pool.
  • Replication issues -

[edit] Using Storage Arrays in Pools

  • With MPxIO
    • Running the Solaris 10 5/09 release is recommended.
    • Enable MPxIO by using the stmsboot command. The paths will change (under /scsi_vhci), but ZFS can handle this change.
  • ZFS and Array Replication Interactions Template:Draft
    • ZFS does not support the ability for a Solaris host to have both the the ZFS storage pool contained on the Master Volume and a controller-based (or host-based) snapshot of said ZFS storage pool accessible on the Shadow Volume. This Shadow Volume can be accessed on another Solaris host, if the storage array supports multiple hosts, or the snapshot Shadow Volume is used as the source of remote replication, where ZFS storage pool can then be accessed on the secondary node.
    • If the SNDR unit of replication is a ZFS storage pool (replicated as an SNDR I/O consistency group), all ZFS storage pool and file system properties, such as compression, are replicated too.
    • The TrueCopy snapshot feature does not retain write-order consistency across all volumes in a single ZFS storage pool. To address this issue, within TrueCopy, you must create a single I/O consistency group for all volumes in a "named" ZFS storage pool. The other solution is to do the following: 
# zpool export <entire ZFS storage pool>
# TrueCopy snapshot
# zpool import <entire ZFS storage pool>

[edit] Additional Cautions for Storage Pools

Review the following cautions before building your ZFS storage pool:

  • A pool created with a single slice has no redundancy and is at risk for data loss.
  • A pool created with multiple slices but no redundancy is also at risk for data loss. A pool created with multiple slices across disks is harder to manage than a pool created with whole disks.
  • A pool created with whole disks but no redundancy is at risk for data loss. In addition, a pool that is not created with ZFS redundancy (RAIDZ or mirror) will only be able to report data inconsistencies. It will not be able to repair data inconsistencies. Finally, a pool created without ZFS redundancy is harder to manage because you cannot replace or detach disks in a non-redundant ZFS configuration.
  • A pool cannot be shared across systems. ZFS is not a cluster file system.
  • When a vdev is replaced, the size of the replacements vdev, measured by usable sectors, must be the same or greater than the vdev being replaced. This can be confusing when whole disks are used because different models of disks may provide a different number of usable sectors. For example, if a pool was created with a "500 GByte" drive and you need to replace it with another "500 GByte" drive, then you may not be able to do so if the drives are not of the same make, model, and firmware revision. Consider planning ahead and reserving some space by creating a slice which is smaller than the whole disk instead of the whole disk.
  • Today, vdevs cannot shrink in size. If your plans include replacing vdevs with smaller vdevs, then you will also need to plan to grow the file system as additional capacity is needed or implement a plan to copy the data out of the file system before shrinking. CR 4852783 addresses the ability to shrink vdevs.
[edit] Simple or Striped Storage Pool Limitations

Simple or striped storage pools have limitations that should be considered.

  • Expansion of space is possible by two methods:
    • Adding another disk to expand the stripe. This method should also increase the performance of the storage pool because more devices can be utilized concurrently. Be aware that for current ZFS implementations, once vdevs are added, they cannot be removed. 
 # zpool add tank c2t2d0
  • Replacing an existing vdev with a larger vdev. For example: 
 # zpool replace tank c0t2d0 c2t2d0
  • ZFS can tolerate many types of device failures.
    • For simple storage pools, metadata is dual redundant, but data is not redundant.
    • You can set the redundancy level for data using the ZFS copies property.
    • If a block cannot be properly read and there is no redundancy, ZFS will tell you which files are affected.
    • Replacing a failing disk for a simple storage pool requires access to both the old and new device in order to put the old data onto the new device. 
    # zpool replace tank c0t2d0         ### wrong: cannot recreate data because there is no redundancy
    # zpool replace tank c0t2d0 c2t2d0  ### ok
[edit] Multiple Storage Pools on the Same System
  • The pooling of resources into one ZFS storage pool allows different file systems to get the benefit from all resources at different times. This strategy can greatly increase the performance seen by any one file system.
  • If some workloads require more predictable performance characteristics, then you might consider separating workloads into different pools.
  • For instance, Oracle log writer performance is critically dependent on I/O latency and we expect best performance to be achieved by keeping that load on a separate small pool that has the lowest possible latency.
[edit] ZFS Root Pool Considerations
  • A root pool must be created with disk slices rather than whole disks. Allocate the entire disk capacity for the root pool to slice 0, for example, rather than partition the disk that is used for booting for many different uses.
  • A root pool must be labeled with a VTOC (SMI) label rather than an EFI label.
  • A disk that contains the root pool cannot be repartitioned while the root pool is active. If the entire disk's capacity is allocated to the root pool, then it is less likely to need more disk space.
  • Consider keeping the root pool (that is, the pool with the dataset that is allocated for the root file system) separate from pool(s) that are used for data. Several reasons exist for this strategy:
    • Only mirrored pools and pools with one disk are supported. No RAID-Z or unreplicated pools with more than one disk are supported.
    • You cannot add additional disks to create multiple mirrored vdevs but you can expand a mirrored vdev by using the zpool attach command.
    • Data pools can be architecture-neutral. It might make sense to move a data pool between SPARC and Intel. Root pools are pretty much tied to a particular architecture.
    • In general, we think it's a good idea to separate the "personality" of a system from its data. Then, you can change one without having to change the other.
  • A root pool cannot be exported on the local system. For recovery purposes, you can import a root pool when booted from the network or alternate media.
  • Consider using descendent datasets in the root pool for non-system related data because you cannot rename or destroy the top-level pool dataset. Using the top-level pool dataset as a container for descendent datasets provide more flexibility if you need to snapshot, clone, or promote datasets in the root pool or a top-level dataset.
  • For more information about setting up a ZFS root pool, see [ZFS Root Pool Recommendations].
  • For more information about migrating to a ZFS root file system, see #ZFS_Migration_Considerations.

[edit] Storage Pool Performance Considerations

[edit] General Storage Pool Performance Considerations

  • For better performance, use individual disks or at least LUNs made up of just a few disks. By providing ZFS with more visibility into the LUNs setup, ZFS is able to make better I/O scheduling decisions.
  • Depending on workloads, the current ZFS implementation can, at times, cause much more I/O to be requested than other page-based file systems. If the throughput flowing toward the storage, as observed by iostat, nears the capacity of the channel linking the storage and the host, tuning down the zfs recordsize should improve performance. This tuning is dynamic, but only impacts new file creations. Existing files keep their old recordsize.
  • Tuning recordsize does not help sequential type loads. Tuning recordsize is aimed at improving workloads that intensively manage large files using small random reads and writes.
  • Currently, pool performance can degrade when a pool is very full and file systems are updated frequently, such as on a busy mail server. Under these circumstances, keep pool space under 80% utilization to maintain pool performance.
  • For better performance, do not build UFS components on top of ZFS components. For ZFS performance testing, make sure you are not running UFS on top of ZFS components.
[edit] Separate Log Devices

The ZFS intent log (ZIL) satisfies POSIX requirements for synchronous transactions. For example, databases often require their transactions to be on stable storage devices when returning from a system call. By default, the intent log is allocated from blocks within the main pool. However, it might be possible to get better performance by using separate intent log devices, such as NVRAM or a dedicated disk. Determine whether separate log devices are appropriate for your environment:

  • Any performance improvement seen by implementing a separate log device depends on the device type, the hardware configuration of the pool, and the application workload.
  • Log devices can be unreplicated or mirrored, but RAIDZ is not supported for log devices.
  • It is highly recommended to mirror the log device. At present, until CR 6707530 is integrated, failure of the log device may cause the storage pool to be inaccessible. Protecting the log device by mirroring will allow you to access the storage pool even if a log device has failed.
  • The minimum size of a log device is the same as the minimum size of device in pool, which is 64 Mbytes. The amount of in-play data that might be stored on a log device is relatively small. Log blocks are freed when the log transaction (system call) is committed.
  • The maximum size of a log device should be approximately 1/2 the size of physical memory because that is the maximum amount of potential in-play data that can be stored. For example, if a system has 16 Gbytes of physical memory, consider a maximum log device size of 8 Gbytes.
  • For a target throughput of X MB/sec and given that ZFS pushes transaction groups every 5 seconds (and have 2 outstanding), we also expect the ZIL to not grow beyond X MB/sec * 10 sec. So to service 100MB/sec of synchronous writes, 1 GBytes of log device should be sufficient.

For log setup information and log performance information, see the following blog: slog_blog_or_blogging_on For general information about separate log devices, see the ZFS Administration Guide.

[edit] Memory and Dynamic Reconfiguration Recommendations

The ZFS adaptive replacement cache (ARC) tries to use most of a system's available memory to cache file system data. The default is to use all of physical memory except 1 Gbyte. As memory pressure increases, the ARC relinquishes memory.

Consider limiting the maximum ARC memory footprint in the following situations:

  • When a known amount of memory is always required by an application. Databases often fall into this category.
  • On platforms that support dynamic reconfiguration of memory boards, to prevent ZFS from growing the kernel cage onto all boards.
  • A system that requires large memory pages might also benefit from limiting the ZFS cache, which tends to breakdown large pages into base pages.
  • Finally, if the system is running another non-ZFS file system, in addition to ZFS, it is advisable to leave some free memory to host that other file system's caches.

The trade off is to consider that limiting this memory footprint means that the ARC is unable to cache as much file system data, and this limit could impact performance.

In general, limiting the ARC is wasteful if the memory that now goes unused by ZFS is also unused by other system components. Note that non-ZFS file systems typically manage to cache data in what is nevertheless reported as free memory by the system.

For information about tuning the ARC, see the following section:

http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Limiting_the_ARC_Cache

[edit] RAID-Z Configuration Requirements and Recommendations

A RAID-Z configuration with N disks of size X with P parity disks can hold approximately (N-P)*X bytes and can withstand P device(s) failing before data integrity is compromised.

  • Start a single-parity RAID-Z (raidz) configuration at 3 disks (2+1)
  • Start a double-parity RAID-Z (raidz2) configuration at 5 disks (3+2)
  • (N+P) with P = 1 (raidz) or 2 (raidz2) and N equals 2, 4, or 8
  • The recommended number of disks per group is between 3 and 9. If you have more disks, use multiple groups.

For a RAID-Z configuration example, see x4500 with RAID-Z2.

[edit] Mirrored Configuration Recommendations

  • No currently reachable limits exist on the number of devices
  • On a Sun Fire X4500 server, do not create a single mirror with 48 devices. Consider creating 24 2-device mirrors. This configuration reduces the disk capacity by 1/2, but up to 24 disks or 1 disk in each mirror could be lost without a failure.
  • If you need better data protection, a 3-way mirror has a significantly greater MTTDL than a 2-way mirror. Going to a 4-way (or greater) mirror may offer only marginal improvements in data protection. Concentrate on other methods of data protection if a 3-way mirror is insufficient.

For a mirrored ZFS configuration examples, see x4500 with mirror and x4200 with mirror.

[edit] Should I Configure a RAID-Z, RAID-Z2, or a Mirrored Storage Pool?

A general consideration is whether your goal is to maximum disk space or maximum performance.

  • A RAID-Z configuration maximizes disk space and generally performs well when data is written and read in large chunks (128K or more).
  • A RAID-Z2 configuration offers excellent data availability, and performs similarly to RAID-Z. RAID-Z2 has significantly better mean time to data loss (MTTDL) than either RAID-Z or 2-way mirrors.
  • A mirrored configuration consumes more disk space but generally performs better with small random reads.
  • If your I/Os are large, sequential, or write-mostly, then ZFS's I/O scheduler aggregates them in such a way that you'll get very efficient use of the disks regardless of the data replication model.

For better performance, a mirrored configuration is strongly favored over a RAID-Z configuration particularly for large, uncacheable, random read loads.

For more information about RAIDZ considerations, see this blog:

When to (and not to) use RAID-Z

[edit] RAID-Z Configuration Examples

For RAID-Z configuration on a Thumper, mirror c3t0 and c3t4 (disks 0 and 1) as your root pool, with the remaining 46 disks available for user data. The following raidz2 configurations illustrate how to set up the remaining 46 disks. 

  * 5x(7+2), 1 hot spare, 17.5 TB
  * 4x(9+2), 2 hot spares, 18.0 TB
  * 6x(5+2), 4 hot spares, 15.0 TB

[edit] ZFS Migration Strategies

[edit] Migrating to a ZFS Root File System

In the SXCE (Nevada) build 90 release or in the Solaris 10 10/08 release, you can migrate your UFS root file system to a ZFS root file system by upgrading to build 90 or the Solaris 10 10/08 release and then using the Solaris Live Upgrade feature to migrate to a ZFS root file system. You can create a mirrored ZFS root pool either during an initial installation or a JumpStart installation. Or, by using the zpool attach command to create a mirrored ZFS root pool after installation.

For information about installing a ZFS root file system or migrating a UFS root file system to a ZFS root file system, see the Installing and Booting a ZFS Root File System

[edit] Migrating a UFS Root File System With Zones to a ZFS Root File System

Keep the following points in mind when using ZFS datasets on a Solaris system with zones installed:

For more information about using ZFS with zones, see the Zones FAQ.

[edit] Manually Migrating Non-System Data to a ZFS File System

Consider the following practices when migrating non-system-related data from UFS file systems to ZFS file systems:

  • Unshare the existing UFS file systems
  • Unmount the existing UFS file systems from the previous mount points
  • Mount the UFS file systems to temporary unshared mount points
  • Migrate the UFS data with parallel instances of rsync running to the new ZFS file systems
  • Set the mount points and the sharenfs properties on the new ZFS file systems


[edit] ZFS Interactions With Other Volume Management Products

  • ZFS works best without any additional volume management software.
  • If you must use ZFS with SVM because you need an extra level of volume management, ZFS expects that 1 to 4 Mbytes of consecutive logical block map to consecutive physical blocks. Keeping to this rule allows ZFS to drive the volume with efficiency.
  • You can construct logical devices for ZFS by using volumes presented by software-based volume managers, such as SolarisTM Volume Manager (SVM) or Veritas Volume Manager (VxVM). However, these configurations are not recommended. While ZFS functions properly on such devices, less-than-optimal performance might be the result.

[edit] General ZFS Administration Information

  • ZFS administration is performed while the data is online.
  • For information about setting up pools, see #ZFS_Storage_Pools_Recommendations.
  • ZFS file systems are mounted automatically when created.
  • ZFS file systems do not have to be mounted by modifying the /etc/vfstab file.
  • Currently, ZFS doesn't provide a comprehensive backup/restore utility like ufsdump and ufsrestore commands. However, you can use the zfs send and zfs receive commands to capture ZFS data streams. You can also use the ufsrestore command to restore UFS data into a ZFS file system.
  • For most ZFS administration tasks, see the following references:
  • You can use "iostat -En" to display error information about devices that are part of a ZFS storage pool.
  • A dataset is a generic term for a ZFS component, such as file system, snapshot, clone, or volume.
  • When you create a ZFS storage pool, a ZFS file system is automatically created. For example, the following syntax created a pool named tank and top-level dataset named tank that is mounted at /tank. 
# zpool create tank mirror c1t0d0 c2t0d0
# zfs list tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank    72K  8.24G    21K  /tank
  • Consider using the top-level dataset as a container for other file systems. The top-level dataset cannot be destroyed or renamed. You can export and import the pool with a new name to change the name of the top-level dataset, but this operation would also change the name of the pool. If you want to snapshot, clone, or promote file system data then create separate file systems in your pool. File systems provide points of administration that allow you to manage different sets of data within the same pool.

[edit] Using ZFS for Application Servers Considerations

[edit] ZFS NFS Server Practices

Consider the following lessons learned from a UFS to ZFS migration experience:

  • Existing user home directories were renamed but they were not unmounted. NFS continued to serve the older home directories when the new home directories were also shared.
  • Do not mix UFS directories and ZFS file systems in the same file system hierarchy because this model is confusing to administer and maintain.
  • Do not mix NFS legacy shared ZFS file systems and ZFS NFS shared file systems because this model is difficult to maintain. Go with ZFS NFS shared file systems.
  • ZFS file systems are shared with the sharenfs file system property and zfs share command. For example: 
    # zfs set sharenfs=on export/home
  • This syntax shares the file system automatically. If ZFS file systems need to be shared, use the zfs share command. For example: 
    # zfs share export/home

For information about ZFS-over-NFS performance, see #ZFS_and_NFS_Server_Performance.

[edit] ZFS NFS Server Benefits

  • NFSv4-style ACLs are available with ZFS file systems and ACL information is automatically available over NFS.
  • ZFS snapshots are available over NFSv4 so NFS mounted-home directories can access their .snapshot directories.

[edit] ZFS file service for SMB (CIFS) or SAMBA

Many of the best practices for NFS also apply to CIFS or SAMBA servers.

  • ZFS file systems can be shared using the SMB service, for those OS releases which support it. 
    # zfs set sharesmb=on export/home
  • If native SMB support is not available, then SAMBA offers a reasonable solution.

[edit] ZFS Home Directory Server Practices

Consider the following practices when planning your ZFS home directories:

  • Set up one file system per user
  • Use quotas and reservations to manage user disk space
  • Use snapshots to back up users' home directories
  • Beware that mounting 1000s of file systems, will impact your boot time

Consider the following practices when migrating data from UFS file systems to ZFS file systems:

  • Unshare the existing UFS file systems
  • Unmount the existing UFS file systems from the previous mount points
  • Mount the UFS file systems to temporary unshared mount points
  • Migrate the UFS data with parallel instances of rsync running to the new ZFS file systems
  • Set the mount points and the sharenfs properties on the new ZFS file systems

See the #ZFS_NFS_Server_Practices section for additional tips on sharing ZFS home directories over NFS.

[edit] ZFS Home Directory Server Benefits

  • ZFS can handle many small files and many users because of its high capacity architecture.
  • Additional space for user home directories is easily expanded by adding more devices to the storage pool.
  • ZFS quotas are an easy way to manage home directory space.
  • Use ZFS property inheritance to apply properties to many file systems.

[edit] ZFS Backup / Restore Recommendations

[edit] Using ZFS Snapshots

  • Using ZFS snapshots is a quick and easy way to backup user home directories. For example, the following syntax creates recursive snapshots of all home directories in the tank/home file system. 
   # zfs snapshot -r tank/home@monday
  • You can create rolling snapshots to help manage snapshot copies. For more information, see the Rolling Snapshots Made Easy blog.
  • You can use the zfs send and zfs receive commands to archive snapshots to more permanent storage.
  • You can create an incremental snapshot stream (see "zfs send -i" syntax).
  • The zfs send and receive commands are not enterprise-backup solutions. The receive operation is an all-or-nothing event, you can get all of a snapshot or none of it. If you store the output of zfs send on a file or on tape, and that file becomes corrupted, then it will not be possible to receive correctly and none of the data will be recoverable. See RFE CR6736794. Enterprise backup solutions, as well as other copying methods, such as cp, tar, rsync, pax, cpio, and so on, are more appropriate for backup/restore than zfs send/receive.

[edit] Using ZFS With AVS

The Sun StorageTek Availability Suite (AVS), Remote Mirror Copy and Point-in-Time Copy services, previously known as SNDR (Sun Network Data Replicator) and II (Instant Image), are similiar to the Veritas VVR (volume replicator) and Flashsnap (point-in-time copy) products, is currently available in the Solaris Express release.

SNDR differs from the ZFS send and recv features, which are time-fixed replication features. For example, you can take a point-in-time snapshot, replicate it, or replicate it based on a differential of a prior snapshot. The combination of AVS II and SNDR features, also allows you to perform time-fixed replication. The other modes of the AVS SNDR replication feature allows you to obtain CDP (continuous data replication). ZFS doesn't currently have this feature.

For more information about AVS, see the OpenSolaris AVS Project.

View the AVS/ZFS Demos here.

[edit] Using ZFS With Enterprise Backup Solutions

  • The zfs send and receive commands do not provide an enterprise-level backup solution. At a minimum, these commands provide the ability to send and receive ZFS file system snapshots.
  • The robustness of ZFS does not protect you from all failures. You should maintain copies of your ZFS data either by taking regular ZFS snapshots, and saving them to tape or other offline storage. Or, consider using an enterprise backup solution. The best solution is to use an enterprise backup solution to save and restore ZFS data.
  • The Sun StorEdge Enterprise Backup Software (Legato Networker 7.3.2) product can fully back up and restore ZFS files including ACLs.
  • The Symantec Netbackup 6.5 product can fully back up and restore ZFS files including ACLs. Release 6.5.2A offers some fixes which make backup of ZFS file systems easier.
  • IBM's TSM product can be used to back up ZFS files. However supportability is not absolutely clear. Based on TSM documentation on IBM website, ZFS with ACLs is supported with TSM client 5.3. It has been verified (internally to Sun) to correctly work with 5.4.1.2 
 tsm> q file /opt/SUNWexplo/output
 #     Last Incr Date      Type    File Space Name
 ---     --------------      ----    ---------------
  1   08/13/07   09:18:03   ZFS     /opt/SUNWexplo/output
                             ^
                             |__correct filesystem type
  • ZFS snapshots are accessible in the .zfs directories of the file system that was snapshot. Configure your backup product to skip these directories.

For the latest information about enterprise-backup solution issues with ZFS, see the ZFS FAQ.

In order to take advantage of ZFS features, such as snapshots, to improve the backup and restore process, ndmp service will be released in Solaris (first in opensolaris). With this addition, an enterprise backup solution could take advantage of snapshots to improve data protection for large storage repositories.

[edit] Looking Forward: ZFS and ADM

The Automatic Data Migration project will provide hierarchical storage management capabilities to ZFS, leveraging the features of SAM-QFS.

[edit] ZFS and Database Recommendations

For information about on-going ZFS and database performance testing, see zfs_and_databases. See also ZFS for Databases.

  • General remarks
    • If the database uses a fixed disk block or record size for I/O, set the ZFS recordsize property to match. You can do this on a per-file system basis, even though multiple file systems might share a single pool.
    • With it's copy-on-write design, tuning down the ZFS recordsize is a way to improve OLTP performance at the expense of batch reporting queries.
    • ZFS checksums every block stored on disk. This alleviates the need for the database layer to checksum data an additional time. If checksums are computed by ZFS instead of at the database layer, any discrepancy can be caught and fixed before the data is returned to the application.
    • ZFS performance on databases is a very fast moving target. Keeping up-to-date with Solaris releases is very important.
  • As of July 2007, the following features might impact database performance:
    • ZFS issues up to 35 concurrent I/Os to each top-level device and this can lead to inflated service time.
    • ZFS does some low-level prefetches of up to 64K for each input block, which can cause saturation of storage channels. See bug 6437054 (fixed) and this blog.
    • Using vdev-level prefetches of 8K and between 5 and 10 concurrent I/O was shown to help some database loads. For help tuning these values see the ZFS Evil Tuning Guide.
  • Oracle Considerations
    • For better OLTP performance, match the ZFS recordsize to the Oracle db_block_size.
    • Keep an eye on batch reporting during mixed batch and OLTP; a small recordsize can lead to an IOPS inflation during batch.
    • Use a separate file system with the default 128K record size for Oracle logs.
    • You can create a ZFS storage pool with separate devices for the ZFS intent log (ZIL). For more information, see separate intent log. Do not confuse ZFS intent log devices with Oracle logs.
    • Consider minimizing Oracle log latency if this is the only I/O in the transaction path. With SAN storage arrays, Oracle log latency should be close to the latency of writing to the SAN caches and no need exists to partition spindle resources between data space and log space: a single pool works.
    • For Oracle over JBOD storage, it has been observed that using a segregated set of spindles (not subject to competing reads or writes) can help the log latency. This in turn can help some workloads, such as those with a high write to read ratio at the storage level. For the Oracle log pool, using some fast separate devices (NVRAM, battery back DRAM, 15K RPM drivces) for the intent log, appears like a very good idea.
  • PostgreSQL
    • Limit the ZFS ARC as described in #Memory_and_Dynamic_Reconfiguration_Recommendations
    • See the Oracle Considerations section above about using a separate pool for logs
    • Set ZFS recordsize=8K (Note: Do this before any datafile creation)
    • Initialize the database from the log pool, then for each database create a new tablespace pointing to data spool
  • MySQL
    • For better OLTP performance, match the ZFS recordsize to the storage engine block size.
    • InnoDB:
      • Limit the ZFS ARC as described in #Memory_and_Dynamic_Reconfiguration_Recommendations
      • See Oracle Considerations section above about using a separate pool for logs
      • Use a different path for data and log (set in my.cnf)
      • Set ZFS recordsize=16K for the InnoDB data files, and leave it at the default for InnoDB logs. (Note: Do this before any datafile creation)
  • MyISAM:
    • Limit the ZFS ARC as described in #Memory_and_Dynamic_Reconfiguration_Recommendations
    • Create a separate intent log for the log (WAL). If you do not have this feature (that is, you're running a Solaris 10 release), then create at least 2 pools, one for data and one for the log (WAL)
    • Set ZFS recordsize=8K (Note: Do this before any datafile creation)

See results real results obtained on PostgreSQL and MySQL with db_STRESS benchmark.

For ZFS/MySQL performance information, see Scaling MySQL on a 256-way T5440 server using Solaris ZFS and Java 1.7

[edit] ZFS and Complex Storage Considerations

  • Certain storage subsystems stage data through persistent memory devices, such as NVRAM on a storage array, allowing them to respond to writes with very low latency. These memory devices are commonly considered as stable storage, in the sense that they are likely to survive a power outage and other types of breakdown. At critical times, ZFS is unaware of the persistent nature of storage memory, and asks for that memory to be flushed to disk. If indeed the memory devices are considered stable, the storage system should be configured to ignore those requests from ZFS.
  • For potential tuning considerations, see: ZFS_Evil_Tuning_Guide#Cache_Flushes

[edit] Virtualization Considerations

[edit] ZFS and Virtual Tape Libraries (VTLs)

VTL solutions are hardware and software combinations that are used to emulate tapes, tape drives, and tape libraries. VTLs are used in backup/archive systems with a focus on reducing hardware and software costs.

  • VTLs are big disk space eaters and we believe ZFS will allow them to more efficiently and securely manage the massive, online disk space.
    • Falconstor VTL - has been tested on Thumper running ZFS. For more information, see: Sun Puts Thumper To Work
    • NetVault from BakBone - This backup solution includes a VTL feature that has been tested on Thumper running ZFS.

[edit] ZFS Performance Considerations

See the following sections for basic system, memory, pool, and replication recommendations:

[edit] ZFS and Application Considerations

[edit] ZFS and NFS Server Performance

ZFS is deployed over NFS in many different places with no reports of obvious deficiency. Many have reported disappointing performance, but those scenarios more typically relate to comparing ZFS-over-NFS performance with local file system performance. It is well known that serving NFS leads to significant slowdown compared to local or directly-attached file systems, especially for workloads that have low thread parallelism. A dangerous way to create better ZFS-over-NFS performance at the expense of data integrity is to set the kernel variable, zil_disable. Setting this parameter is not recommended.

Later versions of ZFS have implemented a separate ZIL log device option which improves NFS synchronous write operations. This is a better option than disabling the ZIL. Anecdotal evidence suggests good NFS performance improvement even if the log device does not have nonvolatile RAM. To see if your zpool can support separate log devices use zpool upgrade -v and look for version 7. For more information, see separate intent log.

See also #ZFS_and_Database_Recommendations.

For more detailed information about ZFS-over-NFS performance, see [[1]zfs and nfs, a fine combination].


[edit] ZFS Overhead Considerations

  • Checksum and RAID-Z parity computations occur in concurrent threads in recent Solaris releases.
  • Compression is no longer single-threaded due to integration of CR 6460622.

[edit] Data Reconstruction

Traditional RAID systems, where the context of the data is not known and data is reconstructed (also known as resilvering), blindly reconstruct the data blocks in block order. ZFS only needs to reconstruct data, so ZFS can be more efficient than traditional RAID systems when the storage pool is not full. ZFS reconstruction occurs top-down in a priority-based manner. Jeff Bonwick describes this in more detail in his Smokin' Mirrors blog post.

Since ZFS reconstruction occurs on the host, some concern exists over the performance impact and availability trade-offs. Two competing RFEs address this subject:

Retrieved from "http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide"
Solaris Internals
Personal tools
The Books
The Ads