Object storage is starting to come back around recently with services like Box.net, and Dropbox to name a few. It is really a simple concept, which can be important in a virtualized environment, especially when you look at the industry trends.
Object storage is really quite simple. You store a file, not as blocks on a file system, but rather as an “Object” on a raw device. This is not so much different than when a database is given a raw mount point and manages the storage internally. The concept is that I place an “object” in the store. I define a policy that I want it protected in R1/R10. This means when I create the object, or modify it, the system needs to keep two copies, generally on separate physical hardware, and in some cases in separate geographies.
This sounds very much like the old Lefthand, now StoreVirtual concept, where data is constantly replicated to keep multiple copies. The major difference is that the storage is accessed via an API, application programming interface. Think about drop box for a second. I place a file in my drop box folder on my laptop. It is replicated up to the “cloud”, and is available on my iPad, iPhone, web browser, etc. I didn’t tell it what do do, I just placed a file in the folder and it was suddenly available everywhere I am. I can have the same object on a Mac as a Windows PC without worrying about incompatible file systems, permissions, many of the things which are inherent to the file storage models. The great part is I don’t worry about backing up the file when I image my laptop because it comes right back when I link my freshly imaged laptop to the application which is calling the API.
What is happening here is that programatically, storage is being controlled, the object, my file, is being replicated. I don’t think about anything going on in the back end, it is simple, and it is cost effective. I am using the object storage as a repository, so there is not a performance expectation.
The performance in and of itself is an interesting discussion point. This is not something I am going to run my virtual desktop environment on, at least not just yet, but it is a great way to throw some large inexpensive drives out and present them to my end user community as a way to store data. This enables me to archive more effeciently, and share files across heterogeneous environments.
So what does this have to do with VMware? When we design a VMware environment, we often look at just the virtual infrastructure. We think about todays statefull applications, and we assume virtualization will just simplify our lives. It is critical to take a step back and think about what changes with a virtual environment. If we are simplifying and consolidating, we are also introducing new complexities, and potentially opening the door to a whole new series of challanges. Using our expensive primary VMware storage as an archive platform may not be the wisest solution, having a windows VM chugging away on our virtual environment may be much more costly.
One of my favorite sayings is, there are nine ways to skin a cat, no offense to cat lovers, and as we design VMware storage solutions, it is critical to look at the project on a larger level. As I learn more about Openstack, I will be posting more on the Software Defined Datacenter and what I believe that really means.