MatrixStore Performance (AKA: 10GigE just isn’t Enough…)

A common MatrixStore question is – can we do 10GigE? The answer is both “yes” and “why do you need that?”

To understand that response it is good to compare traditional to the MatrixStore way of doing things.

Traditional Data Flow between Clients and Servers

Traditional connections to a server are of course limited to the bandwidth provided by the “entry point” to the server. 100Mbit/s, 1GigE, 10GigE…

A typical traditional architecture:

Solutions being released this year are still based on that architecture.

The first problem with the traditional architecture is that the solution is limited to the speed of the cable in the solution. The better types of solutions in this class maybe have two or more bonded connections, but ultimately you are talking about only a few clients being able to get full speed access: double the number of clients and you’ll lose half the access speed per client.

Pumping all your data through a single pipeline is akin to everyone flying to New York and then transferring rather than flying direct to your final destination.

The second bottleneck in a traditional server is also a major issue: how fast can that server process the packets that it receives? If the server is, e.g., utilising software RAID, then the ability of the server to be able to software RAID more than a hundred MB/s is often limited by CPU power. Without the server having some very powerful hardware inside, a single server is not going to be able to get anywhere near 10GbitE/s, however many 10GbitE/s ports it has.

The third problem is that most post-houses and broadcasters simply aren’t set up with 10Ge infrastructure. There might be a few servers with 10Ge but few have anything other than 1Ge clients.

Add to that the obvious problems of having a single point of failure, and the difficulty in being able to expand the location, and you begin to ask if there isn’t a better way!

MatrixStore RAIN (Redundant Array of Independent Nodes) Architecture

With MatrixStore, the server is a RAIN cluster. Typically we sell each MatrixStore node with two 1GbitE connections. But that is limiting – the beauty of the solution is that the clients using the solution are not limited to 1GbitE or 2GbitE at all. Whilst one client is writing to one node another client can be writing to a second node: the result is a combined aggregate bandwidth:

Secondly, because the work in the cluster is distributed: there are many CPUs to handle the connections being made including the RAID’ing of the data.

Third, all the clients can be on 1GbitE, but the total bandwidth can be as large as the cluster is.

Even if the data is all coming from the same client could be writing many files at the same time to multiple different locations using different IP connections for all the files being sent.

So, in short, if you need more aggregate bandwidth, simply add more nodes!:

Lastly, if individual files need to be sent with larger bandwidths and if your clients support them, then there is always the option to put individual 10GbitE connections on the nodes in the cluster.

The View From OM

If you pack all of your data into a single “server” or node, then you will always be very limited in how quickly you can get data into or out of that node. The MatrixStore model distributes data load, enables flexibility in configuration, and allows aggregate bandwidth to be appropriate to the amount of Nearline data being stored.

Nearline data storage isn’t just “stack it up cheap” – it’s about how you access and use that data. It’s about being integrated into the workflow. It’s about  availability, resilience and … speed.

Author: JM