Okay...
The basics:
Why ZFS over a Drobo or some other consumer storage appliance? Well, you can grow it as needed, easily create and destroy partitions without having to reformat, easily share these partitions to various computers in your house via NFS, iSCSI, or SMB (AFP with a little additional work), and data integrity under Solaris/ZFS is superb. In the event of a disk failure ZFS will failover to your mirror gracefully, and you can tweak several settings depending on what is important to you.
On the hardware side you just need some sort of device to host a bunch of disks. This can be an external hard drive enclosure (e.g.
Newegg.com - AMS DS-3141SSBK Steel / Aluminum 3.5" SATA 4-IN-3 SATA Module - External Enclosures), internal drive bays, USB flash storage, or even little solid state drive modules that connect directly to your SATA controller (e.g.
Logic Supply - Leaders in Mini-ITX & Small Form Factor Solutions). The drives can be your traditional SATA, SAS, flash, SSD, whatever, ZFS doesn't care.
For interfacing with your ZFS partitions, as mentioned above you can use NFS, iSCSI, and SMB natively. Really, any way you can connect to this device and mount these shares is fair game though, including Netatalk for AFP services. You would connect to this device via Ethernet. A fast consumer SATA disk will run at 7200 RPM, while a fast SAS disk will run at 15000 RPM. SATA disks are designed to provide a lot of storage for cheap at the expense of performance, while SAS will provide a lesser amount of storage while focusing on performance. Solid state drives (SSD) are also an option. With no drive head I believe the performance of these drives vary, but in general they outperform regular SATA disks by quite vast margins, although I don't know how they fare against SAS drives. If you are interested in using SAS drives you will need a SAS controller which you can get as a PCI Express card for around $100-200. ZFS doesn't require the drives to be of the same capacity, but you'll be limited by the capacity (and speed) of the smallest/slowest drive.
A 15000 RPM drive can apparently saturate a gigabit Ethernet line, so if you *really* want to hit this hard and think you might be limited by network bandwidth, "multi-pathing" or combining multiple ethernet adapters/NICs together is also an option.
For running ZFS itself you'll need either FreeBSD 8 which was just released and ZFS is now listed as stable, or OpenSolaris where ZFS has been stable for a while. If you have never used FreeBSD or Solaris before, not a big deal, as long as you can install the OS and it sees your drives and any other hardware you have attached to it, you're set. They both should have no problems with your drives, but if you decide to install any PCI cards such as a SATA/SAS controller or additional NIC or something, you might want to check to make sure these are supported. OpenSolaris has a hardware compatibility list (HCL) on their site.
The only other often mentioned hardware recommendation is RAM with ECC (error correction). Both your motherboard and the memory modules need to support this feature.
Once the OS has been installed, you interact with ZFS the same way on both OSes. You can literally have your appliance up and running with a few Unix commands...
You'll want to decide on what sort of drive configuration you want to run with ahead of time. ZFS can mirror and stripe drives, and supports the ZFS equivalent of RAID-5 and RAID-6. A "stripe" is pairing together multiple disks so that it is seen as one giant disk, and a mirror is a clone of your main drive so when one of the drives fails you do not lose any data. One popular drive configuration is doing both mirroring and striping (RAID 10), the other is RAID-Z (RAID 5) or RAID-Z2 (RAID 6). Each of these categories have their pros and cons...
With mirroring and striping, you can keep on adding drives in pairs and build the size of your overall storage without having to reformat or do anymore than simply enter a command to add these two drives to the pool. RAID-Z is a way to maximize the amount of disk space you have available, since the total disk space will be the number of drives you have minus 1 multiplied by the capacity of the smallest drive. So, for example, 4 1 TB drives will give you 3 TB of space in total. You need at least 3 drives to do RAID-Z/RAID-5. Therefore, you'll want to use at least 4 drives so that you can have one fail without losing any data. A RAID-Z2 setup (RAID 6) allows you to have two drives fail simultaneously without losing any data. It requires a minimum of 4 drives.
One important caveat with RAID-Z: you cannot add disks to an existing RAID-Z pool. You can *replace* disks with larger ones, but you can't just grow your storage the way you can with a mirror/stripe setup. Therefore, a RAID-Z setup might be a better option if you plan to put a drive in each drive bay. However, if you have 10 drive bays, for example, you could build a RAID-Z configuration with 5 drives, and in the future add some new drives, copy over the data to them, and then build a new RAID-Z pool using the entire set of 10 disks, so there are ways around this limitation.
The other caveat with RAID-Z is that your boot drive(s) cannot be in a RAID-Z pool. If you don't want to salvage the drive bays just for booting though, you could just boot off two flash drives that are mirrored. Solaris needs 2 gig of space for a minimal install.
One benefit of RAID-Z in addition to making more space available is its self-healing and the fact that this form of RAID-5 (unlike other software RAID-5 implementations) is safe and does not potentially jeopardize your data in the event of a power loss.
For testing all of this you can easily setup a virtual machine using VMware/Virtualbox/Parallels and present as many disks as you want to your Solaris/FreeBSD virtual machine so that you can get the knack of all of this. If you use dynamically expanding disk images you can make these drives as large as you want.
ZFS supports many configuration options which are very easy to set without having to reboot or do anything other than issue a single command. One configuration option is file compression. You can choose what compression algorithm you want to use, the aggressiveness of the compression (where more aggressive compression = more CPU resources), and you can choose to have individual partitions compressed while others remain uncompressed. So, for instance, you could create yourself a partition for large video files that you leave uncompressed, and other for documents that can be compressed without taxing your CPU. The compression is block level, meaning it occurs at a very low level, and can be enabled and disabled at your leisure. ZFS is built so that compression will make use of multiple CPU cores, so if you want to be super aggressive with this it might not be a bad idea to buy a quad core CPU for your appliance.
Moving into more advanced areas, ZFS includes an intent log (ZIL or slog) for writing data and an "L2ARC" cache for reading data. ZFS supports putting both of these caches on faster devices, such as SSDs or SAS drives, if you want faster reads and writes. I believe the recommendation for the ZIL is half of your physical memory.
I believe that ZFS itself will use half of your physical memory for caching and improving performance. Therefore, while I believe the minimum recommendation is 500 MB, the most common recommendations seem to be 2+ gig, but ZFS will use more if you make this available.
Another recently added ZFS feature is deduplication. This feature is off by default, but when it is on it compares checksums of your data and prevents storing duplicates. You will apparently need some more CPU power for this without jeopardizing performance.
It can take a while to tweak ZFS's settings to best match the speed of your computer and the resources you have available, but this can be done as simply as switching preferences on and off in an OS X app, the interface is clear and easy to follow. Even with your basic vanilla ZFS setup without compression enabled, no separate ZIL/L2ARC, deduplication or any of that, providing your network is up the task you should notice faster disk performance overall. Because the load you will put on your disks will be spread out across multiple disks, you'll get more operations per second.
Top
