- Pool Size - The pools that I have are less than 10 TB in size, and if given the opportunity to start again, I would change that. Storage space is only part of what you need to consider when building your storage pool. ZFS snapshots can take up a LOT of space, especially in pools that either transfer large files or pools that go through a lot of change. I often have snapshots that are more than 1 GB in size.... which is something that I did not consider. Think about how long you're going to want to keep snapshots, and try to factor that into your math.
- Number of Drives - ZFS pools require a lot of processing overhead, which can decrease pool performance, especially if you are using slow drives, or not enough drives. Going forward, I'm going to remember that a minimum of 5 drives is going to be my baseline. Also, nothing slower than 7200 RPM, and then only in a pinch. 10,000 RPM drives should be the minimum standard - and when you need performance from the pool, spring for the 15,000 RPMs.
- Network Speed - My company's network is only 100 MB. It's really not a problem, because of the type of data that we transfer, and what most users require of the system. However, when you're dealing with large-scale data transfers, like I tend to be doing lately, Gigabit is required. I side-stepped this by connecting my servers with Gigabit and then connecting that to the existing network. So, I can transfer data between the servers effectively... but most users have to deal with latency that I consider to be too high.
These are the top points to be considered, IMHO. However, there are countless others that will apply to an implementation's specifics. It is vital that you consider how you are going to use the pool, how others are going to use the pool, what the limitations are of each user's connection, and how you want to safeguard that data to avoid catastrophic data loss.
I've lost data using traditional RAID pools, and I've lost data in ZFS pools. However, I've found it much easier to recover data from ZFS failure than from BIOS or RAID card traditional implementations. At some point we're all going to lose data, it may not be catastrophic, but it's going to happen. Whether your storage pools fail, or you lose that DVD that you saved all of your old 90's grunge songs on, it's going to happen. How much money you are willing to spend to prevent that is where your real limitations are going to lie.
-----------------
Updated!
(Ok, please forgive me... it's finals week, so my brain is a little fried. I actually started out this post, because I read some inspiration tonight, and had a few thoughts to share on that. So, here goes...)
I read this article today, which is how this rant spawned: http://www.macgasm.net/2011/03/15/zfs-return-mac/
First of all, I think that adding ZFS to Mac desktops is a non-starter... most desktops have 1 hard drive, but this article doesn't talk about desktops, it talks about servers. Personally, I would never use a Mac in a server environment, but their target market isn't me... at all. I work for an insurance brokerage, not a graphic design firm. (Well, technically, I am the Director of IT for a Graphic Design and Photography firm, too... but I still wouldn't put a Mac in that position - but that's just me.) I love Macs, but they're just not my thing...
From a technical standpoint ZFS is by no means easier. Even if Apple were to create a fantastic gui to bring the power of ZFS off the command line to the traditional user, it's still difficult. And, because I'm really a nerd at heart... I like it in the command line. I like using the command line, I like breaking things in the command line, especially if I can fix it the same way. So, maybe my inner nerdness is getting in the way of my opinion here... but ZFS is complex, and something that qualified admins should be using. Macs aren't used in most enterprise network structures, where most admins are working. If Apple wants to use a new combined file system and logical volume manager, then they need to create HFS++ and build something like it themselves. If history is any indicator of the future, they will... and it will be completely closed-source and proprietary... much to my dismay.
-----------------
Updated!
(Ok, please forgive me... it's finals week, so my brain is a little fried. I actually started out this post, because I read some inspiration tonight, and had a few thoughts to share on that. So, here goes...)
I read this article today, which is how this rant spawned: http://www.macgasm.net/2011/03/15/zfs-return-mac/
First of all, I think that adding ZFS to Mac desktops is a non-starter... most desktops have 1 hard drive, but this article doesn't talk about desktops, it talks about servers. Personally, I would never use a Mac in a server environment, but their target market isn't me... at all. I work for an insurance brokerage, not a graphic design firm. (Well, technically, I am the Director of IT for a Graphic Design and Photography firm, too... but I still wouldn't put a Mac in that position - but that's just me.) I love Macs, but they're just not my thing...
From a technical standpoint ZFS is by no means easier. Even if Apple were to create a fantastic gui to bring the power of ZFS off the command line to the traditional user, it's still difficult. And, because I'm really a nerd at heart... I like it in the command line. I like using the command line, I like breaking things in the command line, especially if I can fix it the same way. So, maybe my inner nerdness is getting in the way of my opinion here... but ZFS is complex, and something that qualified admins should be using. Macs aren't used in most enterprise network structures, where most admins are working. If Apple wants to use a new combined file system and logical volume manager, then they need to create HFS++ and build something like it themselves. If history is any indicator of the future, they will... and it will be completely closed-source and proprietary... much to my dismay.
No comments:
Post a Comment