Scality shoves sparkling file system into its RING

Scality has added a file system in the fourth major release of its object storage RING, and it is planning to add NFS heads down the road, the object storage company says.

This is being driven by the unstoppable rise of unstructured data and the predominance of filesystem-based access to it.

The traditional object storage cry is that filesystems at scale, with millions and billions of files, are inefficient and slow. Object storage is claimed to be more efficient than filesystems, with its hash-table and/or erasure coding of a stored object's content being used to compute its address in an object storage space spread across separate but networked physical nodes.

Scality is adding a metadata ring to its data ring, with its application server front-end code incorporating a Fuse (File system emulation in User Space) connector, which was introduced in version 3 of the Ring and has been improved with a full POSIX-compliant filesystem.

The connector talks to a specific metadata ring (MD Ring) which turns a file request into an object request – which is then fulfilled from the original data ring. The MD and data rings can be implemented on the same physical ring nodes with a logical separation. Alternatively, and with larger configurations, they would be implemented on physically separate physical rings.

The number of objects in the MD Ring equals the number of files in the system and access time is independent of the number of files. Scality protects the metadata through replication and keeps five copies for safety.

The roadmap includes the addition of an NFS gateway function to the App servers: in effect they become NAS heads. This will happen in six to eight months' time.

CEO Jerome Lecat said that NFS is less efficient (slower) than the Fuse connector method which, in turn, is less efficient than the standard REST interface for Ring access.

Why is Scality adding an inefficient file system to its efficient ring? Lecat said: "Filesystems like the NetApp and BlueArc, etc – ones with global namespaces – are less efficient than going through REST interface ... But so many applications are deployed with file systems that people are not willing to rewrite... "Filesystems (NetApp BlueArc, etc with global namespaces) are less efficient than going through REST interface ... We're therefore bolting an inefficient filesystem on our efficient Ring."

Better erasure code technology

Scality is adding improved erasure code technology branded as its Advanced Resilience Configuration (ARC). Erasure code technology splits an object up into fragments and stores multiple and different combinations of fragments in different places to provide the ability to recover the data if fragments are lost.

Scality's version of erasure coding technology stores the original data and a checksum, and there is no penalty on read access. It can have a flexible configuration with the default being 16 original data fragments and has the ability to cope with four maximum failures. The storage overhead is 25 per cent.

Lecat said ARC provides 13 nines of durability in a dual data centre configuration (2 rings): "That is 10 times better than Amazon, and, in theory, you would lose a piece of data once in 10 million years."

He is convinced that unstructured data growth is driving changes in storage system revenues, with scale-out file storage (NAS and Objects) growing to $20bn revenues by 2020 from $3.4bn in 2010.

Scality will start experimenting with a reseller channel in the coming months, with trials running in several countries. It also has friendly relations with Crossroads. The two may add a tape interface to the Ring and use the LTFS filesystem and tape to store less active objects in huge object storage applications, but only if there is a demand for it. ®