Our approach on object storage and cloud storage

It is object storage’s time to shine. Across the industry object storage is now acknowledged as the only way to enable massive scale and just about every major analyst is coming out with an object storage market report this year (or already has). While I was on the phone with one of these analysts, he was surprised that we differentiate between our object storage (CAStor) and cloud storage (CAStor + CloudScaler) offerings. I wanted to take a quick minute and explain why we took this approach.

cloudobjObject storage is trusted – access flows freely on a trusted network

From a macro perspective what object storage does is strip away complexity when compared to file based storage. The hassles and limitations of file systems are gone, including the bloated protocols, cumbersome hierarchical directory structure, and rigid data protection methods. What is left is a less complex storage solution that as a result is massively scalable. This is the true essence of object storage and what CAStor, our core product, delivers. I want to stress that just because we are stripping out complexity and making it easy to manage and use doesn’t mean that what we do is easy. As you can see in the figure below, CAStor takes any x86 hardware, any hard drive technology (SATA, SSD…) and any network to create a storage subnet. The two key components are scale out capacity/throughput and scale out index/search – all accessible via HTTP. All of this is openly and freely accessible within the hosted network. So with CAStor it is assumed if you can access the same network, that you have the authority to write and access objects. This approach is great for active archives or big data use cases. What we have experienced is that these use cases often happen in a trusted environment where performance (throughput) is a top priority. This isn’t the case with cloud storage.

Cloud storage needs to be secured – access is restricted to protect tenants

One of the main tenants of cloud storage is multi-tenancy (pun intended), which CAStor can do; however, most people assume that multi-tenancy includes authorization and authentication. So, this is what CloudScaler adds, authentication (identity management system based [LDAP and Linux PAM] and token based) and authorization by using administrator defined policies. So why not just add authentication, authorization, and RESTful access to CAStor?

The answer goes back to our belief that object storage needs to be architecturally pure because simplicity enables ease of management, rapid scale and performance. Adding additional complexity will affect these characteristics. If we added authentication and authorization to CAStor, there would be an impact to performance on trusted networks and we have many customers who need rapid performance and rapidly scaling storage accessible within their network. This is why we added these functions as a scale-out application called CloudScaler. To preserve performance within trusted networks for CAStor while still providing a way to easily scale out access and bandwidth, metering and call logging on the front through CloudScaler.

But that doesn’t mean we won’t add to CAStor, what we add just needs to make sense… introducing CAStor 6.5.

To that point we continue to refine both CAStor and CloudScaler based upon market needs. With CAStor 6.5 (which is now available) we brought replication of object into CAStor, enhanced elastic content protection to allow for seamless transition of data protection schemes (from replication to erasure coding and vice versa) and optimized the bidding process we use to enable our ‘all nodes do the same thing’ (aka symmetric architecture) approach. These aren’t new features but we did make significant strides in simplifying use and increasing performance. This made sense to us and we know it will make sense for you by ensuring you are extracting every bit of value from your hardware.