Long gone are the days of one file server sitting in a corner humming away while employees save their files to the local hard drives. Today, storage devices are abstracted from the server.
IT pros are now required to make important decisions when choosing storage for a particular task. To help with your decision making process, here's an overview of some of the high-level differences between block level storage and file level storage. I also provide information about when to use which type of storage.
Block level storage
Anyone who has used a Storage Area Network (SAN) has probably used block level storage before. Block level storage presents itself to servers using industry standard Fibre Channel and iSCSI connectivity mechanisms. In its most basic form, think of block level storage as a hard drive in a server except the hard drive happens to be installed in a remote chassis and is accessible using Fibre Channel or iSCSI.
When it comes to flexibility and versatility, you can't beat block level storage. In a block level storage device, raw storage volumes are created, and then the server-based operating system connects to these volumes and uses them as individual hard drives. This makes block level storage usable for almost any kind of application, including file storage, database storage, virtual machine file system (VMFS) volumes, and more. You can place any kind of file system on block level storage. So, if you're running Windows, your volumes will be formatted with NTFS; VMware servers will use VMFS.
File level storage devices are often used to share files with users. By creating a block-based volume and then installing an operating system and attaching to that volume, you can share files out using that native operating system. Remember, when you use a block-based volume, you're basically using a blank hard drive with which you can do anything.
When it comes to backup, many storage devices include replication-type capabilities, but you still need to think about how to protect your workloads. With this type of storage, it's not unusual for an organization to be able to use operating system native backup tools or third-party backup tools such as Data Protection Manager (DPM) to back up files. Since the storage looks and acts like a normal hard drive, special backup steps don't need to be taken.
With regard to management complexity, block-based storage devices tend to be more complex than their file-based counterparts; this is the tradeoff you get for the added flexibility. Block storage device administrators must:
- Carefully manage and dole out storage on a per server basis.
- Manage storage protection levels (i.e., RAID).
- Track storage device performance to ensure that performance continues to meet server and application needs.
- Manage and monitor the storage communications infrastructure (generally iSCSI or Fibre Channel).
From a use case standpoint, there are a lot of applications that make use of this block-level shared storage, including:
- Databases. This is especially true when you want to cluster databases, since clustered databases need shared storage.
- Exchange. Although Microsoft has made massive improvements to Exchange, the company still does not support file level or network-based (as in, CIFS or NFS) storage. Only block level storage is supported.
- VMware. Although VMware can use file level storage via Network File System (NFS), it's very common to deploy VMware servers that use shared VMFS volumes on block level storage.
- Server boot. With the right kind of storage device, servers can be configured to boot from block level storage.
File level storage
Although block level storage is extremely flexible, nothing beats the simplicity of file level storage when all that's needed is a place to dump raw files. After all, simply having a centralized, highly available, and accessible place to store files and folders remains the most critical need in many organizations. These file level devices -- usually Network Attached Storage (NAS) devices -- provide a lot of space at what is generally a lower cost than block level storage.
File level storage is usually accessible using common file level protocols such as SMB/CIFS (Windows) and NFS (Linux, VMware). In the block level world, you need to create a volume, deploy an OS, and then attach to the created volume; in the file level world, the storage device handles the files and folders on the device. This also means that, in many cases, the file level storage device or NAS needs to handle user access control and permissions assignment. Some devices will integrate into existing authentication and security systems.
On the backup front, file level storage devices sometimes require special handling since they might run non-standard operating systems, so keep that in mind if you decide to go the file level route.
With the caveat that you may need to take some steps with regard to authentication, permissions, and backup, file level-only devices are usually easier to set up than block level devices. In many cases, the process can be as simple as walking through a short configuration tool and moving forward.
If you're looking for storage that screams -- that is, if you need high levels of storage performance -- be very careful with the file level option. In most cases, if you need high levels of performance, you should look at the block level options. Block level devices are generally configurable for capacity and performance. Although file-level devices do have a performance component, capacity is usually the bigger consideration.
File level use cases are generally:
- Mass file storage. When your users simply need a place to store files, file-level devices can make a lot of sense.
- VMware (think NFS). VMware hosts can connect to storage presented via NFS in addition to using block level storage.
Convergence of block and file storage
The block and file worlds are converging. Some new storage devices include both block and file-level capabilities. So if you are torn about whether to go with block or file, a hybrid/converged device might fit your needs.
Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at firstname.lastname@example.org.