Posted by Will Usher on Mon, May 03, 2010 @ 11:31 AM
(Or "How we help our clients pick the best storage for their needs")
This being my first blog post, I thought I'd take a moment to introduce myself. I'm Will Usher and I've been working for F3 Technology Partners for the past two years. Here at F3, my time is split pretty evenly between pre-sales and post-sales engineering work. My two main focuses are VMware Virtualization and Storage. This blog post is going to be about my methodology around helping a client understand their storage options and picking the solution that best fits their needs.
I break down any potential storage solution into two of four categories; frame-based/frame-less and block-based/file-based. Every storage array on the market can be placed into two of these quadrants. So we're all on the same page, let me give a
quick background of what each quadrant means.
Frame-based arrays are your traditional SANs. You buy a controller (or two) and however much disk you need, generally added in trays. You can continue to add disk until you have reached the limit of disk that your controller can support.
Frame-less arrays are a similar in concept to grid computing systems; every time a node is added, CPU, memory, network and disk are added. You're not locked into the one or two controllers the way you are with frame based computing.
Block Based arrays are traditionally what was considered a SAN. They don't run traditional file systems like Windows' NTFS or Solaris' ZFS. They carve up raw storage into LUNs and serve that out via block based protocols (FC, iSCSI, FCoIP, etc.)
File Based arrays use an internal filesystem, like ZFS, WAFL, or NTFS, and are able to serve files to clients via file based protocols (CIFS/SMB, NFS, HTTP/S, FTP). They have traditionally been called NAS devices, but this is changing as many are now able to serve our block based protocols.
So now we know how to classify storage arrays, but how does this help my clients find the correct storage solution? The answer is that each of these architectures has specific advantages and disadvantages.
Frame based arrays
A frame based array will be easier to design and potentially easier to manage, thus lowering costs. When designing a frame based array you make an assumption that there will be at most two controllers. This makes inter-controller communication easier, as well as adding features easier. This can lead to faster development and richer feature sets.
Frame-less arrays
A frame-less array has a few advantages over their frame-based counterparts. It has to do with what I call "linear growth". With a frame-less architecture your array is composed of nodes. Generally each node has compute resources (CPU), network resources (FC, Ethernet, etc), cache (DRAM, NVRAM, SSD), and storage (disk). This means that every time you add capacity, you're also adding compute, network, and cache resources. This means you maintain a balanced system as you scale the capacity of the array. Contrast this to a frame based array, where you must anticipate your future growth and buy that upfront. If you under estimate your growth, you're going to end up doing a rip-and-replace to move up to the next larger controller. If you overestimate your growth, you've just wasted money on a controller that is too large for your environment. A storage engineer (like me J ) can help mitigate some of this risk based on our experience with other clients, but unless you have a crystal ball that can tell us how much storage you're going to need in the next three to five years, it's still going to be an approximation.
Block Based arrays
Traditional SANs use a block based design where disks are assigned to RAID groups and carved up into LUNs, which are then presented to servers as block devices. The server formats it with its native filesystem, and proceeds to use it like a local disk. This is easier to design as it has fewer moving parts than a file based array. Block based arrays are generally less expensive in the low and mid range, and scale larger at the high end than file based solutions. People generally associate block based arrays as being faster than file based arrays. This does not necessarily hold true today with high-performance file based products like the NetApp FAS, and the Oracle 7000. Keep reading to find out why.
File Based arrays
Once relegated to mundane file sharing tasks, file based arrays have improved leaps and bounds over the past five or so years, thanks in no small part to Moore's law. File based array's require more CPU power to do the same amount of work as their block based counterparts. This was an issue when we had Xeons running at 800 MHz, but now that we have six core Xeons running at 3+ GHz we have more CPU power than we know what to do with. File based arrays can leverage this abundance of CPU power to meet and in some cases exceed the performance of block based arrays. They do this several ways including leveraging advanced caching algorithms to prefetch blocks from disk into cache before they're needed by the client. O f course having equal performance certainly isn't a good reason to go file based over block based. So why are file based arrays gaining rapidly in popularity? Feature set and TCO. Because a file based array will have a local filesystem on the array, it unlocks a huge amount of features not possible with traditional block storage, for example DeDuplication and encryption. One only has to look at the (admittedly dizzying) selection of software features on the NetApp website to understand my point. The other big feature of file based storage is what's been coined Unified Storage. A unified storage device can serve both block based data (iSCSI, FC) and file level data (NFS, CIFS, HTTP, FTP, etc). This means a single device can take the place of a block based array and consolidate all of your file servers. This can save a lot of time between patching and administering windows file servers. Of course there are disadvantages of file based arrays; they tend to be more expensive and they don't scale much over a petabyte.
When I do this for a client I have the benefit of being much more interactive. I can take their needs and pain points into account and tailor the discussion around them. By the end of the meeting a client has a much better idea of what they want, and then I can offer several different solutions that fit their needs. We can the drill down on those products and the client can weigh the pros and cons of each one. My clients appreciate that we're vendor agnostic and that we can give them solutions and let them pick the best one, rather than trying to force a specific technology on them.
Do you agree with me? Think I've got it all wrong? Please let me know in the comments.
Posted by Pete Sorensen on Wed, Oct 21, 2009 @ 04:28 PM
I'm more than certain anyone reading this has at least on one occasion lost a file, overwritten a file with bad data, or had a corrupt file. It is always a painful experience knowing that a piece of information you once had is now gone (the infamous school report lost on the computer scenario). However there is good news. This kind of problem will soon be a thing of the past. Why you ask? Well we live in the future, where we can fit all the songs in the world in our pocket, have access to all the knowledge in the world at a moment's notice, and fly rich people into space.
The concept of snapshots is not something new; it's been around for a while. However only within recent years has it manifested in a way that is more useful to a wider spectrum of users and Operating Systems. In the past snapshots were just glorified copies of data, taking up expensive amounts of disk space. They were often equivalent to the delta in file changes, smaller if compression was used. It also would cause performance hits to the system as increased disk I/O always does.
The forms of snapshots that make the most sense are at the block level using pointers. This is much more intelligent than full copies of the data set (files). You do not need to be a file system expert to understand the benefits here. A file is a just a set of blocks (of fixed or variable size). These blocks are what contain the binary bits that describe the data in the file, everything from the file header to the bad grammar in your blog posts, and your pirated media. Everything that is stored on your computers permanent storage systems are boiled down to blocks. (Queue the Lego analogy)
If you have ever programmed and used pointers this will be a familiar concept. I will use the cliché blocks and arrows method to explain the concepts of pointer based snapshots
Ok so let's say we wrote a file creatively called ‘file 1' onto an empty file system. The file is unrealistically only made of 3 blocks of fixed size for the sake of simplicity. Ok then let's take a snapshot.
As you can see we have taken a snapshot because the blocks are now blue and I have labeled it ‘snapshot 1'. So what does this mean? Well other then the fact that I changed the block color it means that that there is now a file system object that points to blocks A, B, and C. Those blocks can no longer be deleted or marked as free space. The reason for this is if I modified or deleted one of these 3 blocks my snapshot would no longer work. One very important note is that currently ‘Snapshot 1' does not take up any disk space; this is because the snapshot of the file system and the current state of the file system are equal. Just to clarify if I have a file system with 150GB of data and I take a snapshot, that snapshot references 150GB of data but does not take up any additional disk space...yet.
Ok now the next step is to do something obvious, like modify that file.
Alright now ‘File 1' has been modified. The modifications removed block B and added block D. Now a few things have just happened regarding "snapshot 1". It is now taking up disk space. More specifically it is taking up the disk space equivalent to the size of block B. ‘Snapshot 1' still references blocks A, B, and C of ‘File 1' before we made our modification. However the active file system now looks like this.
Currently we have a file system with one file and one snapshot. The disk space that is used up is that of blocks A, B, C, and D. Even though block B is not part of the active file, it is referenced by ‘snapshot 1' and therefore cannot be marked as free space. We can now rollback ‘File 1' to how it looked in ‘snapshot 1'. Block B will then be restored as active and block D will no longer be referenced and will be marked as free disk space (Unless you have created a snapshot after we modified ‘file 1' in which case that snapshot would now be taking up equivalent disk space as block D).
This might sound like snapshots will take up a lot of disk space, but that is not necessarily true. You just need to look at your storage usage. How much new data is being generated? How much of it is being modified and at what rate are these things happening? Answering those questions will help you set retention policies on how many snapshots you should keep. Keep in mind that snapshots happen at the file system level and not on per folder or per file basis.
Real world examples are fun for the whole family.
Recently I upgraded my laptop to Windows 7 and joined it to a Windows 2003 Domain. Well I inadvertently logged in when the computer was in the wrong OU and therefore the wrong folder redirection policy was applied. Somehow the actions of my own doing and Window's sync tool caused all of my documents and application data stored on our file server to be wiped out. I didn't notice this till the next day. Normally it would be an ‘OMG WTF!!??' generating event. Thankfully I built our file server with Solaris using ZFS. Every user has their own file system where their data is redirected via AD group policy. Using a simple CRON job I have all user data snapshoted every hour (retained for 24 hours) and then at midnight every day (retained for 30 days). Moral of the story is that two commands and 15 seconds later it was as if it never happened.