115-GreyBeards talk database acceleration with Moshe Twitto, CTO&Co-founder, Pliops

We seem to be on a computational tangent this year. So we thought it best to talk with Moshe Twitto, CTO and Co-Founder at Pliops (@pliopsltd). We had first seen them at SFD21 (see videos of their sessions here) and their talk on how they could speed up database IO was pretty impressive. Essentially, they have a database/storage accelerator board used to increase block store IO activity to NVMe SSDs but also provide a key-value store IO accelerator,

Moshe was very knowledgeable about the technology and had previously worked at Samsung for their SSD group. He knew a lot about what happens underneath the covers of an SSD and what it takes to speed up IO. It turns out that many in memory databases use persistent key value stores to persist data or to operate in non- (or partial-) memory-mode. Listen to the podcast to learn more.

The Pliops board plugs into the PCIe bus and accelerates IO to NVMe SSDs connected to the bus or can act to accelerate IO to JBoF that’s networked behind it. Their board uses FPGA(s), NVDimms of their own design and DRAM to accelerate database IO using NVMe SSDS.

Pliops operates in one of two modes, as a Key-Value store or as a Block store. Their Key-Value store takes advantage of block store capabilities, so we start there.

In block mode, Pliops provides inline hardware data compression and encryption. Compression requires support for variable length blocks on backend SSDs. To better support this, they pack multiple compressed blocks into physical blocks. They also use a virtualization service to support mapping host LBAs to physical block addresses (using an internal key-value store). Hardware, inline encryption is also provided on a LUN (or namespace) basis. This could enable each database to have its own key. They have a root-of-trust secret key used to encrypt customer namespace (database) keys.

They also optimize physical block layouton the SSD to reduce write amplification (doing more than one write to the NAND for every host write to the SSD).

Block mode also supports smart caching. This is especially useful for database journaling/loging which reuses a portion of LBA address space (blocks} as a revolving journal/log. These blocks are overwritten with new data often and data written to them need not be destaged to NVMe SSDs as long as it can be maintained in NVDimm storage. At some point it gets destaged but probably only when log activity slows down (if ever) or some timeout occurs.

For their key-value storage accelerator, they have implemented an API that’s similar to RocksDB, a persistent key-value store, which is used as a physical storage backend for Reddis and similar in-memory databases. However, the challenge with RocksDB is that there are lots of tuning knobs/parameters. So getting right takes some work. But all this can be avoided just by using Pliops.

We didn’t talk too much about how their key-value store works. Moshe says they optimize the key structures and key data so that all database keys can be retained in their board’s memory and just by doing that, they can have immediate (1 IO) access to any data block pointed to by those keys.

He did mention that they provide ~the same performance for a database getting 10-25% host cache hit rates using their board as that same database would support with a 80-90% host cache hit rate not using their board. Some of this was shown at SFD21 (so check out the videos above for more performance info)

A couple of other advantages they bring to the table. As they are interposed between the host and the NVMe SSDs they can take advantage of their NVDIMMs and memory to write much wider stripes than the host writes. This allows them to reduce SSD read and write amplification (due to less garbage collection) by writing more full NAND pages. All this also reduces physical host (data) writes/day which can significantly improve SSD endurance.

Somewhere in all that smart caching and data compression, they are able to also decrease response times It turns out that databases that don’t use RocksDB or depend on key-value stores can easily take advantage of all their block store functionality to improve IO performance.

They mostly market their product to hyperscalers and superscalers. His definition of super-scalers was any organization that operates at public cloud levels but is not a public cloud (e.g., big social media companies).

Moshe Twitto, CTO & Co-founder Pliops

Moshe is an expert in advanced data management and coding algorithms. Prior to co-founding Pliops, Moshe served as CTO of Samsung’s SSD Controller Development Center in Israel.

Moshe holds MSEE, BSEE degrees from Technion University, Summa Cum Laude and served in the Unit 8200 Intelligence Division of the Israel Defense Corps.

GreyBeards deconstruct storage with Brian Biles and Hugo Patterson, CEO and CTO, Datrium

In this our 32nd episode we talk with Brian Biles (@BrianBiles), CEO & Co-founder and Hugo Patterson, CTO & Co-founder of Datrium a new storage startup. We like to call it storage deconstructed, a new view of what storage could be based on today and future storage technologies.  If I had to describe it succinctly, I would say it’s a hybrid between software defined storage, server side flash and external disk storage.  We have discussed server side flash before but this takes it to a whole another level.

Their product, the DVX consists of Hyperdriver host software and a NetShelf, external disk storage unit. The DVX was designed from the ground up based on the use of host/server side flash or non-volatile memory as a given and built everything else around that. I hesitate to say this but the DVX NetShelf backend storage is pretty unintelligent, just a dual controller disk storage with a multi-task coordinator. In contrast, the DVX Hyperdriver host software used to access their storage system is pretty smart and is installed as a VIB in vSphere. Customers can assign up to 8TB of host-based, server side flash/non-volatile memory to the storage system per server. The Datrium DVX does the rest.

The Hyperdriver leverages host flash, DRAM and compute cores to act as a caching layer for read and write IO and as a data management engine. Write data is write-thru straight from the server side flash to the NetShelf storage system which has Non-volatile DRAM (NVRAM) caching. Once write data is in NetShelf cache, it’s in two places, one on the host server side flash and the other in storage NVRAM. Reads are easier to handle, just being cached from the NetShelf storage in the server side flash. There’s no unique data residing in the hosts.

The Hyperdriver looks like a NFS mount to vSphere and the DVX uses a proprietary protocol to talk with the backend DVX NetShelf. Datrium supports up to 32 hosts and you can define the amount of Flash, DRAM and host compute allocated to the DVX Hyperdriver activity.

But the other interesting part about DVX is that much of the storage management functionality and storage control logic is partitioned between the host  Hyperdriver and NetShelf, with both participating to do what they do best.

For example,  disk rebuilds are done in combination with the host Hyperdriver. DVX RAID rebuild brings data from the backend into host cache, computes rebuild data and writes the reconstructed data back out to the NetShelf backend. This way rebuild performance can scale up with the number of hosts active in a cluster.

DVX data are compressed and deduplicated at the host before being sent to the NetShelf. The NetShelf backend also does a global deduplication on the host data. Hashing computations and data compression activities are all done on the host and passed on to the NetShelf.  Brian and Hugo were formerly with EMC Data Domain, and know all about data deduplication.

At the moment DVX is missing some storage functionality but they have an extensive roadmap with engineering resources to match and are plugging away at all of it. On the other hand, very few disk storage devices offer deduped/compressed data storage and warm server side caches during vMotion. They also support QoS functionality to limit the amount of host resources consumed by DVX Hyperdriver software

The podcast runs ~41 minutes and episode covers a lot of ground about how the new DVX product came about, how they separated storage functionality between host and backend and other aspects of DVX storage.  Listen to the podcast to learn more.

AAEAAQAAAAAAAAK8AAAAJGQyODQwNjg1LWI3NTMtNGY0OC04MGVmLTc5Nzg3N2IyMmEzYQBrian Biles, Datrium CEO & Co-founder

Prior to Datrium, Brian was Founder and VP of Product Mgmt. at EMC Backup Recovery Systems Division. Prior to that he was Founder, VP of Product Mgmt. and Business Development for Data Domain (acquired by EMC in 2009).

Hugo Patterson, Datrium CTO & Co-founderAAEAAQAAAAAAAANZAAAAJDhiMTI2NzMyLTdkZDAtNDE5Yy1hMTM5LTNiMWM2MWM3NTlmMA

Prior to Datrium, Hugo was an EMC Fellow serving as CTO of the EMC Backup Recovery Systems Division, and the Chief Architect and CTO of Data Domain (acquired by EMC in 2009), where he built the first deduplication storage system. Prior to that he was the engineering lead at NetApp, developing SnapVault, the first snap-and-replicate disk-based backup product. Hugo has a Ph.D. from Carnegie Mellon.

 

Greybeards talk server DRAM IO caching with Peter Smith, Director, Product Management at Infinio

Welcome to our sixth episode. We once again dive into the technical end of the pool with  an in-depth discussion of DRAM based server side caching with Peter Smith, Director of Product Management at Infinio. Unlike PernixData (checkout Episode 2, with Satyam Vaghani, CTO PernixData) and others in the server side caching business, Infinio supplies VMware server side storage caching using DRAM for NFS VMDKs. It got a bit technical fairly fast in the podcast, sorry about that.

This months podcast comes in at a little over 40 minutes and was recorded on 20 February 2014. The overall sound quality is much better than Episode 5 but we are still working out some of the kinks, so bear with us.  

Peter comes from a number of different IT infrastructure and co-location services and brings a wealth of knowledge on IO caching within a VMware server environment. With all the DRAM supplied in ESX servers these days and the increasing compute power that’s now available, the time seems ripe to implement a deduplicated, DRAM cache for VMware IO.

Infinio clusters together segments of ESX DRAM, across nodes in a VMware cluster to supply an IO cache. The software installs across the VMware cluster non-disruptively (~ = Vmotion) and Infinio clusters can be expanded without operational impact.

There was some discussion on the odds of a (random) SHA-1 hash collisions happening in our lifetimes (as Greybeards our lifetimes may be shorter than yours). I tried to get Peter or Howard to give me commensurate odds on this happening but alas, no takers.

Listen to the podcast to learn more…

Peter Smith

peter-smith-headshotDirector of Product Management. Peter brings more than 10 years of expertise as an infrastructure architect and IT operations director. In previous companies such as Harvard Business School and Endeca Technologies, Peter managed full-service datacenters and colocation spaces. Most recently Peter led infrastructure services for Endeca, and has also directed operations of customer-hosting infrastructure for clients including American Express, Fidelity UK, Bank of America, and Nike.

GreyBeards discuss server side flash with Satyam Vaghani, Co-Founder & CTO PernixData

Episode 2: Server Side Flash Software

Welcome to our second GreyBeards on Storage (GBoS) podcast. The podcast was recorded on October 29, 2013, when Howard and Ray talked with Satyam Vaghani, Co-Founder & CTO PernixData, a scale-out, server side flash caching solution provider

Well this month’s podcast runs about 40 minutes. Howard and I had an interesting and humorous discussion with Satyam Vaghani, who was a leading architect of VMware’s storage and file system stack and now is currently Co-Founder/CTO of PernixData, which offers a server side caching solution. Unlike other solutions in this space, Pernixdata offers advanced write-back caching and scale-out clustering solution for server side flash for data used by VMs running under vSphere. We discuss how they provide these features and why in our second podcast episode. Although why people are running analytics in a VM using server side flash is still a mystery …

 

Satyam Vaghani Bio’s

Satyam Vaghani, Co-founder and CTO Pernixdata
Satyam Vaghani is Co-Founder and CTO at PernixData, a company that leverages server flash to enable scale-out storage performance that is independent of capacity. Earlier, he was VMware’s Principal Engineer and Storage CTO where he spent 10 years delivering fundamental storage innovations in vSphere. He is most known for creating the Virtual Machine File System (VMFS) that set a storage standard for server virtualization. He has authored 50+ patents, led industry-wide changes in storage systems and standards via VAAI, and has been a regular speaker at VMworld and other industry and academic forums. Satyam received his Masters in CS from Stanford and Bachelors in CS from BITS Pilani.