CloudByte Blog

In a series of blog posts, CloudByte’s Founder and VP of Engineering, Umasankar Mukkara, explains the need for disruption in storage technology in today’s virtualized reality, how CloudByte ElastiStor disrupts, and the derived benefits from this next-generation storage technology for datacenters, both at enterprises and service providers. Read the first post “Introduction to CloudByte ElastiStor“.  

In my last post, I talked about the need for disruption in shared storage technology and how CloudByte’s disruption can lead to huge cost savings at service providers and enterprises by 80%-90%.  This post discusses the fundamental building block of CloudByte ElastiStor technology… the Tenant Storage Machine (TSM).

An ElastiStor controller is built using commodity server and storage. At a physical view, the controller node has various types of storage attached to a server that has different connectivity ports such as SAS ports, FC ports and Network ports. ElastiStor consolidates the connected physical storage into storage pools and lays out large number of virtual storage controllers or Tenant Storage Machines on them as shown below.

Fig: Overview of ElastiStor node

In a typical legacy monolithic storage controller, the physical resources of the controller are shared in an ad-hoc manner and storage LUNs are exposed in a monolithic fashion. This makes a LUN configurable only in terms of capacity and not in terms of performance, which is the restricting factor in configuring all the LUNs on a physical controller to just one customer. In other words, a physical storage controller is dedicated to just one application or customer, in order to deliver guaranteed performance.

 Anatomy of a TSM

A Tenant Storage Machine (TSM) is like a VM that has the guest OS, completely isolated from other VMs. The exception being that the TSM neither runs on a hypervisor nor maintains its guest OS. CloudByte ElastiStor maintains very thick boundaries between TSMs resulting in complete isolation and security.

Following elements form a typical TSM in an ElastiStor.

• Own root file system
• Networking end point  / IP address
• Own Access Layer protocol stacks (NFS v3/v4, CIFS, NFS, FC)
• Visibility to it’s storage
• Set of storage QoS policies

Fig: Anatomy of a CloudByte TSM

 

As seen above, a TSM encompasses its own storage access protocol stacks, making a TSM resilient to protocol based attacks. By having its own protocol stacks and root filesystem, a TSM is completely isolated while storage is accessed through the storage controller. QoS Controller is at the heart of CloudByte IP, which translates the configured QoS policies into real physical resources such as CPU cycles, amount of File System cache, number of worker threads of protocol stacks, block stripe size etc.

QoS. Now configurable and guaranteed.

All you need to do as an administrator is to know the quantity of IOPS,  throughput, and latency that your application needs. Once you configure them on the centralized web administration console,  a TSM is spawned on an appropriate physical node to deliver those tailored QoS parameters.

So, what happens to the TSM QoS during physical node failure ? Well, we have you covered there as well. ElastiStor delivers TSM QoS even in fail over mode, by failing over individual TSMs, if required to a different controller nodes where physical resources are available to meet the QoS needs.

Summing up, CloudByte TSM architecture enables storage admins to deliver tailored storage performance (IOPS, throughput, latency) and capacity to all the applications, sharing a common storage resource pool. An industry first, this capability eliminates the need for any storage fragmentation and the resultant exorbitant costs and management complexity.