Before we delve headlong into the Virtualized Storage features of Robin, permit me to tie up some loose ends pertaining to my previous post, on multi-tenancy with Robin.
Unlike traditional virtualization technologies that are hypervisor based, Robin’s technology is implemented using containers that are very efficient and do not carry the kind of overhead that traditional hypervisors do. In addition to Robin’s native LXC container support, there is support for Docker. Robin users can provision Docker containers and orchestrate traditional and Docker-based clustered applications such as Hadoop.
Now coming to LXC vs Docker, an analogy may be in order. Comparing a 747 with the space shuttle as if the space shuttle is just another type of plane would be a travesty, don’t you think? Robin is, however, the Switzerland (or is it Sweden, most likely India) of platforms and treats both as equal citizens. For a more in-depth technical deep dive into this please read – Linux Containers – A comparison of LXC and Docker.
Now, onto Virtualized Storage …
Imagine a scenario where you do not have to worry about dealing with a myriad of storage formats such as file, block, object. All of this is abstracted out by a Storage Abstraction Layer that is collocated with your compute resource. Sounds like wishful thinking — doesn’t it? But wait, that is precisely what Robin has managed to do.
Robin’s unique architecture
Robin architecture separates compute from storage and gives you a lot of flexibility, including but not limited to:
- Separation of compute and storage layers. This results in enormous CAPEX and OPEX savings.
- CAPEX savings will result from a reduced server footprint. You pay only for what you need. If you need compute, then buy compute-only nodes and don’t pay for storage, which you will end up doing when you buy traditional hardware.
- OPEX savings will result from having to install licensed software on a reduced number of compute servers.
- Elastic and independent scaling of compute and storage.
- A virtualized storage layer that resides in the compute layer and abstracts out all the backend storage formats such as block, object and file.
- Effective use of caching using SSDs in the compute layer, where all your hot data is cached and available for immediate use instead of frequent round trips to the backend storage clusters.
- Tiering of data in the storage layer. An example of this would be storing hot data (6 months’ to 1 year’s worth) in an always-available format such as HDFS. Warm data in a secondary HDFS layer and cold data in storage like QFS or Ceph.
- Data Cloning and Snapshot capabilities.
Our customers are loving these features — they are thrilled and feel empowered. Though the recommended architecture has nodes of two configurations — one for compute with high CPU, cores, memory and SSDs, the other for storage which is low on CPU, cores, memory but very dense with HDDs and no SSDs — it also supports a hybrid node architecture which has all of these in one box. This would be like having a traditional box with SSDs added.
Robin has been implemented on in-house clusters and in the cloud, with both traditional and hybrid architectures. Robin also has the capability to use the new breed of high density SSDs for storage.
With Robin it is business as (Un)usual. Don’t forget to “Think inside the Container”.