Pros & cons of Volume-level vs. File-level sharing
In the past 24hrs alone, I’ve had a couple of people asking about the differences between Volume-level and File-level SAN. Not to say that they did not understand the differences between the two, but they wanted to better understand the impact each approach would have on their workflow. I thought it would be beneficial to share their perceptions and my comments back to them with other COW users.
Volume-level or File-level sharing?
But first, for those less familiar with this terminology, let's just quickly review the differences between the two approaches:
Volume-level sharing, as the name implies, means that the sharing of the storage takes place at the volume-level. In such a setup, only one user in the workgroup can have write access to a given volume. Meanwhile, other users can read but they cannot write to that same volume. This is why, in a Volume-level environment, it is necessary to maintain multiple volumes available, so everyone in the team has at least one location they can write.
File-level sharing works exactly like a network share (just faster and more scalable). Everyone can read and write to one (or more) shared volume.
Here we go:
A volume-level SAN is far simpler to manage than file-level SAN.
Not always. Yes, there is inherent simplicity in a Volume-level solution due to its “static” nature: Once a volume has been flagged as “writable” or “readable” to an OS, there is nothing else to do, until someone else needs write access to the same volume. In a small setup, there is usually no need to create lots of volumes, and the SAN can be very easy to manage. However, as the number of users increases, it becomes necessary to create, manage and backup an ever-increasing number of volumes. At some point, the lack of flexibility and challenges associated with working with too many volumes becomes a real burden. This is why most larger SAN are based on File-level technology.
There is a high-risk of accidentally deleting someone else’s file in a File-level SAN.
Yes and no. The risk does exist, but it is overstated to talk about a "high-risk". In fact, a File-level SAN works exactly like millions of file servers used in facilities and enterprises around the world. How often do you hear of people "accidentally" deleting files belonging to someone else? Not that often. In addition, you can easily implement file security (with granular permissions) to restrict access to certain files and folders.
There is a greater chance of loosing data in a File-level SAN.
Yes and no. This is a variation of the previous one. It is true that by distributing data across multiple volumes, there is less risk of loosing "everything” in a Volume-level SAN. However, because there are more volumes, there is also, statistically, a greater probability of running into a corrupted volume at one point or another. Also, because each workstation is managing its own file system, there is a far greater chance of corrupting this volume if the workstation crashes. This doesn't mean you'll automatically loose data, but you will need to run check disk and repair the volume (which introduces downtime). In a File-level SAN, the metadata controller is the ONLY machine manipulating the file system. If a client machine crashes, there is no risk of file system corruption. Only if the metadata master machine crashes, can there be a need to repair the SAN volume.
A Volume-level SAN offers “private workspaces” that protects people’s work.
True. Because of its very nature, a Volume-level SAN makes it impossible for anyone to - accidentally or not - delete someone else’s work. This said, it does not prevent a local user from accidentally deleting any content stored on the drive he has access to. So in the end, the risk of "accidentally" deleting stuff remains and you should still maintain good backups if this is a concern to you.
It is possible for two users to work on the same project in a File-level SAN.
No. This is a rather common misconception. It is not the SAN, but the application that locks files or not. For instance, on Windows, if two users open the same .txt file using TextEditor, they will both be able to update the file. The last one to hit "save" will indeed overwrite the other's changes because the file is not locked. However, other applications, such as Word, do lock their files. If User A opens a .doc file and User B tries to open the same file, he will get an error message saying the file is locked and can only be open for read. To date, most content creation packages do NOT support multiple editors simultaneously opening and manipulating the same project. On the other hand, this is a quite common feature for MySQL databases and media asset management (MAM) applications.
It can take some time for a modified file to be updated in a File-level SAN.
This highly depends on the SAN software you use. In the case of metaSAN, the update is almost instantaneous (within seconds). For instance, if User A deletes (or save) a file to the SAN, User B will see the same file appear in his file browser within seconds.
The use of a metadata controller introduces overhead and affects performance.
In theory, this is true, but in practice it is a non-issue because we're talking milliseconds of overhead for opening or closing a file. Once a file is open, and its metadata has been sent to the client workstation, there is nothing else to do for the metadata controller. There is also no additional overhead for the client when fetching or writing data to the disk. This means that the performance of the SAN is only bound to the performance of your storage. The only time overhead should be a concern is when the number of file is huge and the amount of data very small. This is the case for banking and other transactional operations that read and write millions of tiny little files. In a rich-media environment, files are rather big (we're not talking Bytes, but KB, MB and GB) and the overhead becomes truly negligible.
A Volume-level SAN does not require a separate metadata network.
True. The static nature of Volume-level SAN means that there is no need for instant communication between the various clients. In a File-level SAN it is necessary for all workstations to be able to talk to each other and coordinate with the metadata controller. This "handshake" takes place over a private or semi-private LAN.
A File-level SAN requires a separate metadata partition on the SAN storage.
Not always. This requirement depends on the SAN software you use. For instance, Apple requires Xsan users to dedicate part of their storage to a metadata partition. On the other hand, metaSAN does not require such a partitioning because metaSAN leverages the HFS+ or NTFS journaled file systems (which maintain their own metadata alongside the data).
metaSAN is a File-level SAN
True. However, it can also behave like a Volume-level SAN. thanks to ProjectStore (a software tool that now comes bundled with metaSAN), it is possible for users to create any number of virtual volumes that they can "lock" while working on them, exactly like they would on a Volume-level solution. However, with ProjectStore you still have a main shared volume that everyone can read and write to. With ProjectStore, there is also no need to create volumes of predefined size. With a Volume-level SAN, you must first take your storage and sub-divide it into multiple volumes. For example, if you purchase a 32TB volume, you will end up slicing it into 16x 2TB volumes or 8x 4TB volumes or whatever combination (depending on how many SAN clients need to work on the SAN). Once these volumes have been created, it is not possible to contract or expand them if you run out of space on one of your project (you have to re-format them). In contrast, ProjectStore allows you to create hundreds or thousands of “virtual” volumes. They take no space until you start writing content into them. And as long as there is storage space left on your main SAN volume, you can keep writing to any project. This means it is far easier to manage, allocate and repurpose storage space between projects.
Hope this helps.
Small Tree Communications