EMC's DSSD D5 - CTO40

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

I listen to episode 40 of the CTO advisor the podcast in which we talk to industry experts and Go through various scenarios where the conversation doesn't go as deep in the weeds as a maybe a packet pushers conversation and stays Fairly high level and we might dip and dab into speeds and fees such as this one Conversation that I am having with Matt Donoghue who's the product manager of EMC's DSSD D5 the rack scale all flash array that EMC announced as part of EMC world 2016 I sat down with Matt during EMC world.

So there's a little bit of background noise The conversation however was a great conversation. Hope you enjoy it. I I Don't know I might answer that differently So yeah, so that's a good that's a good point to start why yeah No, I think I think DSSD is different because when you look at traditional storage You know, it's looked very similar with some, you know innovation along the way Whether it be things like flash came along and be used as opposite of disk You know really DSSD is really built for the application developer and the application And that's kind of how we've looked at you know, what what we were building.

So we have capabilities that Around how our application developer would access our underlying storage. That's different than a traditional storage appliance traditional storage appliance block device They all in some way look look look the same so DSSD can look like a block device But we also have API so application developers can take advantage of the very high performance capabilities that we're driving Very low latency. So when you say that it's aimed towards application developers most of the application developers are taught to at least in the enterprise Block level storage even object-based storage they get that so when you say it's API driven How is that fundamentally different?

Let me clear let me clarify that I think what I was trying to say is You know, we provide, you know native and flexible data access right for that application. So if you're a traditional running a traditional database Database administrator and then you're used to consuming storage as a block device DSSD presents itself as a block device okay, however, you know if you're you know an application developer and You want to take advantage of the very highest performance low latency capabilities that DSSD can offer Whether you're a firm and Wall Street or you know, the Intel community or whatever.

We have this API so you can replace application iO Verbs with our own sort of API verbs so providing that flexibility. We've also built plugins So with our partner Cloudera, we built a plug-in to Hadoop That allows customers to get that same low latency performance without having to rewrite their application So for us, so that's a great I think Intro or Description of the concept so let's dig a little bit deeper. Would you say You know traditionally if I'm an application developer I'm accessing the Storage layer via traditional block level drivers in the OS that extracts away a lot of new complexity and But with the extraction of complexity usually there's a performance so it's one of the advantages to DSSD I can take native calls from like a Hadoop or Add this layer of APIs eliminate that abstraction and Then what like performance advantages that other than an abstraction about taking advantage of so, you know We customers can use this like a block device high performance block device on the market just right there I think the API allows you to Eliminate more layers of software so, you know in the in the actual kernel and the IO stack Right as a part of the kernel and our block device.

There's a you know, lightweight sort of software in that stack But if you look at a traditional IO stack Storage stack if layers and layers of software in the kernel, you know, you have to do a system call You have file systems volume managers, you know many many layers of software DSSD is focused on being able to compress compress all that. You'll be able to be able to DMA Directly from the underlying storage to the application without having to do a system call Context switch interrupt a lot of things that you would do in a traditional IO stack even an even all flash storage IO stack because we're all about performance So when I'm when I take a custom OS like VMware vSphere that has similar advantages when VMware vSphere It's not I don't think it's an apples-to-apples comparison But similar concept I can take advantage of being able to write to storage directly without going through the OS that gives me a layer of Performance that I can't get normally even even if without the architectural changes of DSD just being lightened fast flash But it sounds like that also adds some complexity when it comes to services.

I normally depend on so with Storage management solutions. I can get replication out of out the box. Yep Do I lose the ability to replicate when I go with a DSD type solution? Yeah, so again, that's why we're more about the application owner that the administrator Most of those data services we rely on the application to To do that. So look at something like compression, you know, we believe You know application aware compression is more effective And so we rely on the the you know, the application part of that We don't have a lot of the storage data services you see in a traditional storage product And that's what one reason why I said it isn't about the you know, the storage Administrator as much with the SSD much more about the application owner.

So the reason we made that choice is When we built that when we built the company the focus was all on If we had to make a choice between performance and something else was always on We're gonna make a choice on performance And if you start adding data services like data compression to the data path, it just blows your performance So so literally you guys are Making the fastest possible heart rate to me and then giving direct access to the developer so if I need a race car, I can strip out the safety belt strip out the Fancy suspension take all of that out and just make the fastest rocket that can go in the straight line as possible I have that option or if I want to start adding the safety harnesses or whatever Or I can just use this traditional blocking block Yeah, exactly device in whatever services the OS provides love that.

I can never forget the application whatever the application made of a provide And we will have you know, some of these data services like we're exploring things like snapshots and you know Encryption and stuff like that, but it's just like whenever you're adding something to the data path Services probably, you know more problematic for our solution We're comfortable with that trade-off because the workloads we focus on, you know, either they're very well built into the application layer with a new or a traditional database or So, you know if I have if I'm using this as kind of a SAP on a layer when we talk about in memory type databases where I'm expanding My super fast in memory database to this persistent layer that one is persistent So I'm not battling, you know challenges with not persistent memory so I can write Not as fast as memory but way faster than standard flash.

Yeah, so now I can create like really creative applications. I Don't think SAP HANA supports anything like this outside of block level today yeah, but what how do you guys envision this being leveraged in a Scenario like an SAP HANA in memory database extension near alignment. Yeah I mean those are things we're exploring around a memory extension. I as you pointed out today You know with SAP HANA the entire working set of data is in memory, right? So can't necessarily leverage a tier of high-performance flash like what DSSD can offer Outside of being able to speed up like a boot time operation after a DR event There are some in-memory applications that maybe for the column store Use more persistent and flash as part of the working set of data.

So we do work with those We do think that there's an opportunity around, you know Applications around HANA and what they could do with something like DSSD, you know down down the road, you know things we explore So if I'm a Spark shop, and I'm and I have like really smart developers. I can take a Spark database In memory database right this second tier into my database is you guys are giving me that or we could do it Or you can do that. That's the point like I mean with Hadoop, you know working with Cloudera.

We built this plug-in to HDFS You know changes committed upstream essentially made HDFS pluggable for shared storage We could do that or a partner could do that for something like Spark or for other sort of middleware layers leveraging this API So I think for a lot of these, you know Bigger opportunities that might be something that we our partner would do. I think the API Like that becomes if it's a very custom application, that's maybe a one-off That's probably where you'll see that use case more of a customer would get involved I think the customer, you know would expect us or a partner for something like Hadoop to have a plug-in So when it comes to partners who's really excited who's like chomping at the bits to get to this Our partners?

Yeah, I would say you know Cloudera is a big one for us. I think Mike Olson wrote a blog. He's been quoted Around you know the performance you've been able to show around HBase and how we're really going to be able to help customers You know move from you know, the construct of MapReduce and batch analytics and you know, massively scaled computations to more enterprise analytics and which requires higher performance and that's where DSST plugs in so they were both mutually excited about that We recently Last week a SAS published a performance White paper on what that they've done with DSST and what they showed in that paper is not only is DSST the fastest performance storage for SAS, but also, you know, we're the first solution to be able to scale beyond four nodes You know, we scale to eight nodes and even at eight nodes, you're still faster than the leading all flash arrays with four nodes.

So That's another SAS I think is excited. They take a more infrastructure-neutral strategy But I mean, they're very excited about the performance So let's talk about business outcomes and business value. Who's seen the most business value out of this type of platform? As in types of customers? Yeah Or workloads? Well, both types of customers and workloads. Yeah, both types of customers and workloads Yeah, I guess on the workload side, we kind of talked about SAS I think the other one that we've seen a lot of interest in is around, you know, like high-performance databases So things like Oracle, high-performance analytics, Oracle analytics So customers are today when they need performance, they're buying a lot of engineered systems So that, you know, instantly, you know, one of the things that took me to my mind Is that, you know, we have this push to move from Oracle to in-memory databases in general And this seems like a quick and dirty trick to delay that move to in-memory database Are you guys seeing that use case at all?

I don't know that we have that conversation I mean, I think, you know, honestly, customers have a lot of Oracle out there They're oftentimes struggling with performance And, you know, customers like to kind of keep a best-of-breed approach Rather than necessarily having a fully workload-integrated engineered system just for a single workload Where they see the value is, hey, you can run your high-performance Postgres database You can run your HBase and Oracle, you know, all on one D5 And have the performance that supports all those workloads and is best-of-breed for each one So I think that's where there really is business value for customers And on Oracle specifically, I think one of the things that we're talking about here at EMC World With what we've shown with dual D5s is you can get twice the capacity, you know, twice the performance Still one-third the latency, lower TCO, and one-third the rack space Than the leading sort of Oracle engineered system out there And that's pretty powerful for customers from a business value perspective So fees and fees, how big is a DSS D5?

It's a 5U appliance So in that 5U, today we have 144 terabytes of raw storage 100 gigabytes per second of bandwidth, 10 million IOPS At 100 microseconds latency So it's a powerful, you know, 5U footprint And what's great about that is, as you can imagine If you're looking at your analytical workflow You're probably running multiple different applications You might be using Hadoop in one place You might have high-performance file systems You might have Oracle in one place You might have Oracle in another place You might be using Hadoop in one place You might have high-performance file systems You might have Oracle, you know, DSSE Because it's highly rated across these different performance metrics You know, it can support the varying needs and constraints of each of these applications Because they're not all the same They don't all necessarily need IOPS They don't all necessarily need bandwidth It's a balance Have you guys done anything to quantify the difference In accessing this via API versus through a traditional IO stack?

So us versus us So API versus block device Again, we have the fastest block device in the market We think it's roughly a 20% difference Than our flood-direct memory API But if you compare that to a traditional IO stack So if you look at us as around 100 microseconds Your traditional IO stack is anywhere from 300 microseconds to a millisecond or much more And I'm talking with a flash-based stack So still a big difference At least a third Alright, so I'm running out of hard-related questions Because I'm not a hardware guy So you talked about two DSS-D5s Are these things clusterable at all at that layer?

Or do you just add a bunch of different ones? S. Or some skill to do it beyond block Or do it beyond, even just installing a block This is a different solution It's different than, it's not your standard fiber channel SAN connectivity, it's PCIe, it's NVMe And that's exactly the reason for it Making this easily packaged Well, the other thing is DSST is very uniquely positioned Uniquely built for a rack system A rack-level system Because in a single 5U appliance You could support performance requirements Of a whole rack of compute nodes So you think of having a bunch of, you know 1U, sort of stateless servers Connected to this appliance Running a bunch of different applications on it Very well built for this kind of use case Or eventually when it goes through Some type of certification process with SAP This could be an SAP HANA appliance Right Even if it's just block level It's an appliance that I can just buy As I can buy a dblock-based appliance today And just throw it in my data center And not have to worry about integration Or even support all the way up through the HANA layer Yeah, exactly And that's why we're, you know We made that a big focus Because we're seeing a lot of that interest That is really cool So, talking about cross-pollination Is this an option In a private hosted virtual stream day today?

I have nothing to really announce or talk about Around virtual stream today They're doing a lot of great things But nothing specific there Alright, well, thanks a lot I really appreciate it Cool, alright, thanks a lot Thank you