SDS CATEGORIES - Is There Any Special Node?

Special Node in SDS

In this article we’ll be looking deeper into SBS-SW (Software Based Storage) which includes IzumoFS.

SDS Mapping
“SDS
Source: Techno Systems Research Co., Ltd.

Common concept of SBS-SW is to create distributed storage system using commoditised servers. As I mentioned in last article a distributed storage has better availability and extendibility compare to legacy storages and that is what makes SBS-SW so great.

Category with in SBS-SW

So what is the difference between these products? For example many company showcases integration with cloud service, inter-site clustering or dedupe methods but these are not fundamental features that differentiate the core concept of product. There are no common way to categorise each product but in this article I would like to focus on the role of each cluster nodes. That leads us to think about what protocol we use to access a storage system.

Here is the list of common role of node when creating storage system with SBS-SW.

  1. Node that saves data
  2. Connector that handles data transfer
  3. Node that handles only meta data
  4. Gateway that handles specific protocol access
  5. Node that manages whole cluster

All storage system must have “1”. For other roles it depends completely on product whether to need or have those node in a cluster or whether it should be installed virtually or physically. I’ll illustrate two patterns of cluster one which includes many “special nodes” and one without those.

The product which has “Special Nodes”

Having node with several role can be easier for storage manager to implement a system though actually it very much get effected by how the product was made at first place. For example if the product is based on object storage, in many case it requires to have specific gateway to access storage using CIFS or NFS.

The thing we have to care about here is the “Availability” and “Scalability” which is the main feature of SBS-SW. Usually for those node with specific role, including gateway, do not have “Availability” and “Scalability”. We often hear from our client who have experience in managing SDS claims that those gateway or special node easily becomes bottle neck because whole access have to pass through those node.

System with gateway or connector

This is where SDS vendors can show there innovative idea. Some products manages to add both “Availability” and “Scalability” to those “Special Nodes”. Though if we need to place those special nodes we still need to prepare higher hardware cost or rack space for placing those hardware because overall number of nodes in a cluster will of course increase. The design of system will become more complicated and that leads to higher initial and running cost.

The product without “Special Nodes”

There are few products that has pure P2P architecture, which means the product that can create storage system without any special nodes. With this structure we can be sure that access will be decentralised from any node and can maintain cluster size as small as possible. In short, the system becomes much simpler.

System without gateway or connector

Although there are no special nodes that means the single node must be capable of doing things that special node was doing. Ideally it should have following features.

  • Storage node can save and transfer data
  • Each node contains both data and meta data
  • Has availability and scalability independent from number of nodes
  • Capable of handling multi protocols, such as Object / HDFS / CIFS / NFS / iSCSI without gateway
  • Nodes can manage and watch each other

It’s hard to determine whether product supports these conditions just by simple yes or no but I believe there are no product capable of doing all the things in the list at the time of Nov 2015.

It is very hard to implement all of these features into one single node. Important thing to remember is when you consider SDS that has no special node architecture you must be careful to understand exactly on what level do that product fulfil these features depending on your requirements. For example, there is a case that most of the time you don’t need special node but in some case you need it.

How about IzumoFS?

Maybe you might have guessed it but IzumoFS do not have any special nodes. Base concept of IzumoFS is to keep it “simple”. At least for now IzumoFS don’t even offer optional node either.

I think IzumoFS is capable of doing all of the things I mentioned in the list earlier except for Object / HDFS protocol support. IzumoFS is file based SDS, which you might have known from its name “FS”, and it’s focused to implement file server. So every node is capable of handling CIFS / NFS / iSCSI.

Using three protocols natively

It’s not so common to hear about these kind of difference when we seek for SDS product but I think existence of “Special Node” is what truly make that product unique. It affects very much to performance, availability, scalability and manageability of the whole system. When you consider trying out SBS-SW, please keep in mind about “Special Node” and whether you want them or not.