All about MoSMB Architecture – Part II

We are pleased to present part II of the excerpts from an interview with Dr. Sunu Engineer, CTO of Ryussi Technologies who is talking about his vision for “MoSMB – SMB with Mojo” architecture and how it will enable storage companies to embrace SMB 3.0 in their systems easily in a very short time.

What are the top 3 architectural features that are unique to MoSMB and they help differentiate it from other SMB that are available.

The top three features are:

1. Pluggable:  Ability to plugin to any storage system and any cluster system, the fact that it is developed as a set of libraries as against a monolithic server is its biggest differentiator.
2. Scalable: We have applied all the modern architecture principles of creating distributed and scalable servers to create the MoSMB server. Event based file server which is distributed and peer to peer allows any vendor to integrate it in their storage devices.

Closed source – Since MoSMB is closed source, our clients IP is protected as they do not have to expose the internals of their storage systems  which is not the case with open source systems like SAMBA which by the way is our only competitor that exists. We (at Ryussi) also have a software services arm which enables us to help our clients in the integration of MoSMB in their storage systems and optimize it. Furthermore, we can also help them in implementing additional features or functionality that they would require. They have to expose their code or run SAMBA as a separate process but using our libraries they can do it “in process” and still keep their IP safe.

Can you elaborate on the IO driver that the architecture supports?

By default we use the IO drivers which are actually shared libraries and they have a certain structure and you have to implement specific methods, and it is very similar to the VFS model in the Linux/Unix device drivers when you implement these functions. It has two components:

1. File System Driver
2. File Driver

These two drivers are supplied as shared object files where you can go to the MoSMB configuration file and specify that for this type of file system these are the drivers to use.
This allows us to support multiple types of IO systems from a single MOSMB server because for each type of storage system will use its own IO driver but the protocol is able to deal with it agnostically because there is one common interface the device driver interface that we are supporting.

So how easy or difficult is it to create an IO driver?

So an IO driver for a distributed object store can be created by one or two engineers in 4-6 weeks with unit testing. You can then do integration testing to ensure the product works in the storage vendor’s environment.

How do you integrate with clustering systems?
 
MoSMB supports enhanced transparent failover scenarios using Witness protocol. Witness facilitates faster failover because it notifies Hyper-V servers when a node is unavailable without needing to wait for the SMB 3.0 connection to time out.

Currently we have our own shared memory structure in order to do clustering (clustering library) and we can integrate it with the clients clustering library in 2-3 weeks using our simple interfaces.  We will tell what data needs to be synchronized and as long as they give us an API for getting and sending data. Our internal library is based on the RAFT protocol for synchronization and customers who don’t want to use their own can use this library instead in fact the library can be used as a distributed synchronization mechanism as an independent component.