Grey Beards on Systems - GreyBeards talk hyper-convergence with Jason Collier, CTO & Co-founder Scale Computing

Episode Date: August 6, 2014

Welcome to our 11th monthly episode where we return to discussing hyper converged systems, this time with Jason Collier, CTO and Co-Founder Scale Computing. The GreyBeards haven’t talked with an hyper converged system vendor since our 1st episode and we had talked with Scale Computing and Jason at Storage Field Day 5 (SFD5) a couple of months … Continue reading "GreyBeards talk hyper-convergence with Jason Collier, CTO & Co-founder Scale Computing"

Hey everybody, Ray Lucchese here and Howard Marks here. Welcome to the next episode of Greybeards on Storage monthly podcast, a show where we get Greybeards storage and system bloggers to talk with system and storage vendors to discuss upcoming products, technologies, and trends affecting the data center today. Welcome to the 11th episode of Graybeards on Storage, which was recorded on August 1st, 2014. We have with us here today Jason Collier, CTO of Scale Computing. Why don't you tell us a little bit about yourself and your company, Jason? Yeah, will do. Thanks, Ray. Yeah, so I'm Jason Collier. I'm CTO and one of the

co-founders at Scale Computing. And Scale Computing is actually, we've been around for, you know, about seven years now. Started the company back in 2007, started shipping our first products in 2009. We initially started out with kind of a unified scale-out storage approach. Of course, everybody was always asking, why is a storage company named Scale Computing? Well, about two years ago, we actually finally got to answer that question when we came out with our 8C3-based products, which are what's kind of deemed in the industry today as basically hyperconvergence, where we integrate server storage and virtualization into a single platform.

Hyperconvergence. You're going to have to give us an understanding of that. We've talked to a number of companies in the past, and we've had various descriptions of this sort of thing. So, Jason, why don't you give it a shot? It's a, you know, it's one of those ubiquitous definitions, right, in the industry right now. And, you know, what I see hyperconvergence is, it's the basically melding when you look at the data center, right? There are three tenets to the data center. You've got servers, storage, and networking. And those are typically, you know, like cobbled together in a variety of different ways. And then, of course, what I see as convergence is basically putting those things together. Hyper-convergence, and it's been defined a few different ways by a few different people in the industry.

And I've heard, you know, hyper-convergence or hyper-visor convergence. And, you know, kind of what I see it is also the melding of that together, not necessarily just the hardware components, but also the software components that starts to really make those systems function as kind of a single cohesive unit versus basically, you know, having these independent silos of those components to manage. So, I mean, I see hyperconvergence as one kind of a you know whatever it's defined as what it is um though it's not really clearly defined you know once again but i see it really is the is the melding of those those tenants of the data center into into kind

of the single cohesive solution so what you call the stuff that uh you know the guys at vce vblock and and v specs and oh god there must be about four systems. HDS has got something. IBM's got something. Yeah, those are – when you start talking about Vblock and VSpecs and Dell Smart Start, that's converged, but it's not hyper-converged. And truth is, it's more – those solutions are more about purchasing than architecture. The difference is... It is, yeah. It's a single SKU to buy, right?

Yeah. V-blocks is a single SKU. V-specs is a reference architecture. But either way, it's the same kit, and it just makes it easier to buy. Why has this become so important or so popular these days? I mean, you talk to these guys like that at EMC. No, no, no, no. Some other special thing. Magic or something like that. Every company within two years of VCE came out with their own version of this thing. And EMC had to come out with a V-SPEX

version of their product just to go out. But I don't understand why it's so popular now. Jason? I think people want to, overall, they want to reduce their operating costs. And when you look at the way this is done, I mean, it's become extremely complex. And then when you kind of pair that back with what is the job of IT, what is the role of IT, and I think, you know, it's basically as these systems have gotten more and more complex, you've got basically your team of SAN administrators, team of network guys, team of server and virtualization experts. Everybody has become the mechanic. So they're basically just trying to keep the car running. And IT has forgotten that it's really its job is to drive the car from point A to point B. And everybody's just trying to keep it running. So I think the converged aspect of it is one of those things where it's trying to get IT back in the driver's seat and controlling basically business flow decisions, basically

where the applications, like what makes your business make money, getting the IT folks to basically start focusing on the business aspects of the company and not basically just keeping the car running. Well, I think there's a big difference between the VCE style converged, which is about purchasing and provisioning, and hyper-converged systems, which is about architecture, where we're not buying a storage device and a SAN switch and a LAN switch and some servers and having them all put together by the vendor for us. The truth is, and I've talked to a bunch of people who buy V-blocks, and the answer is, we had a hiring freeze in 2009, and if I get a V-blocks, it comes in the rack and it's all cabled. And if I buy all the parts, at very least, I need to have one of my guys spend two days putting them together. And I don't have that guy for two days because we've had a hiring freeze.

So that's entirely business-driven. When we start looking at hyper-converged systems, one of the keys that I wouldn't make definitional is hyper-converged systems are scale-out. And the converged systems almost always run with traditional storage. And so you get the advantages of scale-out from being hyper-converged as well. And then you get the operational efficiency if we're talking about a system like scales or Nutanix, where the storage and the compute have a single management console. Right, right. And here's one thing that I've also noticed that is a differential. And this is why hyperconverged itself is a definition. I mean, typically, you know, so scale computing, Nutanix, and SimpliVity have been kind of those companies that have been lumped into that hyperconverged category.

There's a few others coming out, like Nimbox recently came out of Stealth. But there's also some fundamental differences in those architectures. One, from a technical perspective, but also when you actually look at, you know, as I mentioned, I really see it as the integration of the kind of the server storage, you know, networking component, but then also tied together with, you know, effectively an orchestration layer, if you will, but something that's also controlling the virtualization stack, because I think that's important that that's actually controlled with that as well. And one of the things when you're looking at these hyper-converged solutions, one of the things is how do you create a virtual machine in this environment? And if you look at Nutanix and

SimpliVity, I'm like, how do you create a virtual machine in that environment? Well, you still do it through VMware and vCenter. And so one of the things I've seen, you know, so one, we've been for a couple of years, I mean, we, our orchestration layer controls the virtualization stack as well. So it's not just the storage component that it's doing. And I think, you know, and like I saidIMBOX is still relatively new, but I think that's kind of how they're rolling with it as well. Yeah, I haven't seen NIMBOX, except for the basic press release, much yet. But yeah, so if you look at Nutanix or SimpliVity, they're basically saying you manage the storage from within vCenter, which would be the same argument for vSAN.

Right, yeah, exactly. And we could argue that vSAN is hyper-converged, but it's just the software, and you need to do the hardware yourself. Right, but then of course you've got Project Marvin looming in the background. So it'll be interesting to see what that is. Who knows? Prophet Marvin. Marvin. Oh, God. All right. VMware's own appliance to run vSphere and vSAN, and therefore be the equivalent of scale computing or Nutanix or SimpliVity in the buy the appliance, tell us how many VMs you're going to run, we'll sell you the right number of appliances, and that's all you have to think about. Oh, really? I hadn't heard of that.

Well, you know, it's based on a poster somebody took a picture of on the VMware campus one day and tweeted out. And, you know, God knows how true all these rumors are. We'll probably find out at VMworld, I'm guessing. No doubt. One should only hope. So shouldn't yours be considered ultra-convergence if hyper-convergence is orchestration

of storage and networking? Aren't you guys a step above the rest of these guys from your perspective, Jason? Yes. Okay, well I was just checking to make sure that that was the case. Were you expecting any other answer, Ray? No, I was just checking to make sure that that was the case. Were you expecting any other answer, Ray?

No, I was not, but I was hoping that would be the case. You've known me for a while, Ray. You know I'm a pretty honest guy. So, Jason, tell us a little bit about how your system is configured or what are the components of your system? What does it look like? That sort of thing. Talk to me about the hardware, man. Yeah, okay. So the hardware, and we've actually got three different variations on the hardware, and it really depends on, you know, what your overall workload is going to look like. So from a, basically, how many VMs do you want to run the environment? And one other thing to clarify, we really do specifically gear our stuff toward what you think of as like SMB and mid-market companies. So like

places that are like, you know, employees from like 50 employees to 5,000 employees, that's kind of the wheelhouse of where we focus our products at. So we have our, basically our 8C series, but we got our 1,000, 2,000 and 4,000 systems. The 1,000 system, that's kind of our base entry component. And we start with three nodes in a cluster. And the nodes are effectively like 1U, think of them as pizza boxes, kind of commodity hardware. In the 1000, there are four SATA-based hard drives. In each one of those, there are four 1 gig or four 10 gig ports.

And there's a single CPU that's a quad-core Xeon and 32 gig of RAM per node in the 1000 series. And that's our entry-level component. Now, as I said, it takes three of those to constitute a cluster. So when you first buy scale, you buy three nodes worth of that. And one of the things like, you know, unlike a lot of vendors in the industry, we are happy to broadcast our price out there. And that three node starter system is $25,500 US as the MSRP. We mostly sell through channel. And there are a lot of different ways that you can actually get the product. And really, there's no rocket science when you need to add on to it. So as Howard mentioned before, scale out is a big component of the whole hyperconvergence stack.

And so you start with three nodes and then you can basically add a node at a time to scale it out after that. So $25,500 is the starting price and then guess what? Take that, divide it by three and about $8,500 is the per node price on the $. So then we've also got the 2000 which is all SAS based and it is we can do 15k or 10k in the SAS. There are still four drives per node. It is a still a single socket but it's a hex core CPU and 64 gig of RAM. So basically doubling the amount of RAM in that node. Once again, takes three nodes to actually start that out. And then our 4000-based systems are, basically, there's still one U form factor, but it is eight drives. It's all SAS-based. It is only offered in 10 gig. The others you can get in 1 gig or 10 gig, but the 4000 is only 10 gig, and it is a dual

socket hex core with 128 gig RAM per node. Now, one of the interesting things you could start out, say, with the 1000, you know, series of systems, and as you grow and expand, and guess what? As Moore's Law comes along, and as we offer more nodes with more capability, you can actually mix and match these nodes. So you can take and plug one series into a different series and still have a single cluster to manage. And that's really kind of where a lot of our kind of back-end storage technology comes in that allows us to mix and match, you know, basically devices of different, you know, performance characteristics within there. So, I mean, you mentioned SATA drive, SAS.

Is there a specific capacity that goes with these systems, or it just depends on what the customer wants, or how does that play out? Yeah, pretty much. It depends on what the customer wants. Now, typically we're going to ship a node, and it's going to be fully loaded with whatever it happens to be, but there's a selection as far as, like, the drive, basically the drive sizes and speeds that

you want to put in there. Currently, we do not have an SSD offering, but it is on the roadmap and it is coming in short order. Don't you know disk is dead? Yeah. Oh, I've heard it all the time. However, in the, you know, everything we find in basically the customers that we sell into, DISC is not dead. I mean, in probably 90% of the customers we go into, when you think of, you know, probably being that 500 to 1,000, like, person organizations, we go in, we do usually an extensive measurement of their current environment to see what it looks like and typically most people top out at a couple thousand iops so yeah as much as disk is dead i think disk is about as dead as tape right don't go there don't go there don't go there well tape is the guy getting thrown on the cart in monty python on the Holy Grail going, I'm not dead yet. Not dead yet.

And it never will, right? It's been not dead yet for 15 years. Yeah, yeah. So we've talked about this before, Jason, but how does this, you know, if I'm a SMB kind of organization these days, it seems like cloud would be another viable solution to hear versus bringing in a scale computing cluster kind of thing. So what do you think about that? I mean, how does this compare against cloud environments? We actually come up across that more than you'd think. People thinking about

switching over to cloud. And I'll tell you, one of the big issues I think in the industry is that bandwidths to the cloud are not what they need to be, especially from an SMB organization. When you've got an entire company running off of a, you know, DSL modem or a cable modem. Okay, go ahead. That is an inhibitor to cloud. Well, not only that. I mean, I actually did. We had a very specific case where we were going up and competing against cloud.

And I did up basically a pricing off of basically just like Microsoft. They were looking at Azure. And I did. They were looking at running 20 VMs. You know, about, I think, half of them were going to be Windows, half of them were going to be Linux. And I worked up basically a monthly cost comparison on what that would actually look like. And basically what they were running with their workloads, like it ended up being something like it was going to be $4,500 a month to virtualize that workload out there. And, you know, effectively, when you looked at what they needed was basically our entry-level systems at $25K.

I mean, you're paying your system off in, you know, effectively less than six months, right? Yeah. So I think there's still a discrepancy in where basically cloud pricing is versus what you can actually get from the physical perspective. Now, that said, I think kind of the future of where this is going is going to be more of a hybrid-style model. And it all comes down to the applications that you're running within your organization. Certain applications lend themselves well to being run on-premise, and certain applications lend themselves well to being run basically in a distributed cloud manner. I think of us as a primary example. You know, our Salesforce is very distributed. We've got, you know, regional sales coverage.

We got, you know, so a lot of people in our HQ and all that stuff. But I'm not going to go out by SAP or something like SAP or Oracle, run it on premise when I've got Salesforce out there. For us, that application and the size we are, that actually works perfect for us. So that is an application that works fantastic for us. Now, counter to that, I mean, we're developing, you know, effectively software to go into these hardware environments where we have to do a lot of, you know, actual like physical hardware testing. That's something that we could never push out to the cloud. We can't just take and run that out on Amazon and be able to handle basically, you know, specific hardware failure scenarios that we have to deal with.

So, you know, as just an example, I think it completely depends on the application where you should run it. And I think, you know, kind of the future of where the whole, you know, cloud versus on-prem is going, I really think it's going to be, you know, more of that hybrid style. But if you can, you know, have a system that runs your cloud-based stuff and your local-based stuff in a similar fashion, a similar construct, a similar orchestration component, then that is a winning solution. Having spent 25 years consulting to the size companies that you sell to, I have reached the conclusion that none of them should run their own Exchange server.

I agree. If you've got a couple hundred employees, that exchange server means you're going to have a guy who's three quarters of the time exchange administrator. And, boy, it's cheaper to just get Office 365. Yeah, absolutely. Agree. And I think it's completely application dependent.

You know, another good example of that, though, I also had a – we got a customer. They do, like, kind of steel fab stuff in Kansas City. And they have their CNC machines. They run a 24 by 7 manufacturing operation. They have their CNC machines that talk to their MRP system that tells the CNC machine what it should build. And this guy is like, the least reliable piece of my IT infrastructure is my internet connection. He's like, there is no way I am going to run my MRP system in the cloud. So it comes down 100% to what application are you willing to run. And you'll find that a lot of these guys, especially in SMB and mid-market, there is one application that their business cannot function without.

And it's typically that application that will have some kind of on-premise requirement. And for that, that's where the system comes in. But I completely agree that no company of that size should be running their own Exchange server. It's way too complex of a system for a company that size. It just requires too much babysitting. It does. It requires a lot of effort to keep that thing running. Okay, let's go back to the system here. So the VMs can run Linux or Windows or stuff like that?

Is that how this works? If it will virtualize on x86, we can run it. We've done everything from DOS, OS2, Novell, Plan 9, DDoS. You name it, we've pretty much been able to run it on the system. You have customers still running OS2? Yes. Oh, my God. Yeah, but they're all in Europe, right?

Okay. We won't go there. It's amazing. And it's usually that little business-critical application too, right? It's some app they hired somebody to write 15 years ago, and he died. Or maybe he just became a consultant or something like that. And then think about the hardware the thing's probably running on. Those guys do want to virtualize that because they're like, oh, God, where do I get parts?

I mean they don't even make this kind of like interface for hard drives anymore. So it's not like I can go buy one on eBay. Well, you can, but there's no telling it's going to work. Oh, yeah. It'll probably be like $2,500 for like a 10-meg hard drive with some freaky interface. So, with scale computing, you get like an enterprise license to vSphere and all that stuff? Or how does this

play out here? We don't need vSphere. This is a beautiful thing. Yeah, we don't run VMware, right? You left out the stinking. Yeah. Hey, don't go there. We're still stinking VMware. No, I mean, that's the beauty of the system, right? The virtualization component, that's included.

So when I said that, you got that 25.5 MSRP. That's basically, that is the hardware. That is all the software. And that is a year of premium support. 24 by 7, 365 support. We've got the ability to remote into clusters to fix stuff. So instead of a matter of hours to get a tech on site, you can call us up, you can, we can basically have you open a support tunnel to us and we can have people on there in a matter of seconds to fix any of the, to fix any of the issues. But yeah, and the reality is, no, there's no VMware. So there's no,

you know, there's no VTACs you got to pay, right? So? Yeah, well, just – I mean you would pay more than $25,000 to vSphere. For the license, yes. To VMware. Yes. To host three nodes with vSphere. Yep, yep. Yeah, and it gets – I mean you can do their – they've got their – oh, I'm trying to remember what the bundle is called now. Essentials Plus.

Yeah, so yeah, Essentials Plus, you can start out at about $7,500, which is good up to three servers. The second you get like four servers and need to do it, then guess what? Welcome to the enterprise licensing costs. And now you're talking – it could be upwards of like $20,000 a server. Yeah. Yeah, yeah. So how do you benchmark something like this? I'm trying to think. Yeah, yeah. So how do you benchmark something like this? I've never seen any of you guys in like spec SFS or SPC.

So, I mean, the internal storage protocol is all block or what the hell is this thing? So, yeah, so that's basically our technology scribe that we created, which is effectively – it is basically a distributed block engine. So, you know, kind of the way it works, and this is actually another piece that goes along with the simplicity of it, right? You're not supposed to care about the storage, and it's basically that layer that handles that component. And what we actually did is, so instead of using NFS or SMB or iSCSI or any of those components, what we did is we actually stripped all of that out and looked at what the hypervisor is actually requesting of the storage. And then

we wrote an interface directly into this distributed block engine from the hypervisor. So the hypervisor speaks its own proprietary, what it would be thinking if you just hook a disk up to it. What does the hypervisor want to say through the Linux kernel and all the way down to the blocks on the devices? We actually interface directly with that. Guess what? That means we eliminate basically the overhead of running storage protocols on that because of the fact that we have converged these elements together.

We don't need it to talk to like any third party subsystem. So what Scribe does then is, you know, we've got two real concepts. We've got a concept of VSDs, which are the virtual storage devices. When you create a VM and you create a disk that attaches into a VM, that is a virtual storage device. That then talks to the Sbe layer that then also interfaces into RSDs, which are the real storage devices. So these are basically anything block that can attach into a system. These could be anything from, you know, like a USB flash drive all the way from, so SATA, SAS, SSD, could even be external storage. But bearing in mind, simplicity is one of our things. We don't want you to have to manage external storage. But bearing in mind, simplicity is one of our things. We don't want you to have to manage external storage components. So we want those components to be as internalized as possible

so we have as much control over the simplicity aspect. But those RSDs then, the scribe layer, depending on the VSD when you create the VSD, which is what is actually attaching to the virtual machine, you define at the VSD level what level of protection you want, what quality of service you want, and basically other aspects, locality of that data feeds into the Scribe engine, which then it uses to basically place the data on the RSDs on the back. So when you're looking at what we're putting on the RSD that that is all block but what we're presenting up is effectively you can almost think of it as object because it's not like a file system we're

actually using. The object would be the VSD itself which shows up as a disk to the virtual machine. Okay so you mentioned protection so you're offering RAID or you're replicating the data or mirroring or just... So the interesting thing is that is completely configurable at the VSD level. So today what we've got in the product is what we call, we got a simple VSD and a reliable VSD. A reliable VSD, we can have up to 16-way mirrors of basically any of that data. But typically what we do and kind of the stock, the configuration of that VSD would be when you create a VM, that disk is automatically made highly available in that we take and do two copies of that. So we're effectively mirroring it,

but we also mirror it on different nodes within the cluster. So no data is ever mirrored on the same node. And what that allows us to do is tolerate entire node failures, but still maintain access to that. As I said, though, we can actually crank that replication factor up. So as the clusters get bigger, so say by the time you get up to, you know, say 16, you know, a 1620 node cluster, we can increase the replication factor that we're doing across the cluster so that you can tolerate bigger failures. Because as you know, basically the more moving parts you've got in a big complex system,

the more something is going to fail. So we can crank that up based on the actual cluster size as well. Now, one of the other things I mentioned, we've got the simple and reliable VSDs, but we've also got plans to create VSDs that are doing things like using basically erasure coding and being able to, say, utilize different protection schemes. And think about this. Utilizing different protection schemes, so like RAID, but we're doing that and we're defining those characteristics on a per virtual machine level

yeah so and it's even actually below that i mean you can have a so example you could create here's here's my database right that i'm going to create you could create you know effectively the c drive or root partition of that could be okay i, I just want a simple, reliable root partition, like you're going to mirror the drives. You can set that for that specific VSD and say, here's, and then create a data drive or a log and a log drive for the database components. Well, then you can define with that different VSD spec, say, I need a guaranteed amount of IOPS, which could basically then say, okay, well, that's going to then dictate that this goes on the fastest available RSD that I have, or RSDs, and then also protection factor associated with that as well. So if I want to basically say,

have that data mirrored and have it on the fastest performance storage, that can be done. And bear in mind, this is once again done at the virtual disk level. So it's not like, so let's strip this all back to what we started talking about and what converged systems look like. And, you know, you look at something like a VCE. I mean, you are still defining RAID sets that then you're defining LUNs on top of, and then you're offering that out to the virtualization component. Well, you're not managing that on a pervium basis. The only way you can manage that on a pervium basis is like, okay, well, I got to put that on this specific one if I want these specific characteristics for that data. So that just kind of injects all that complexity back into that environment. So, I mean, really where we're going, where we're taking the technology is like having the granularity down to,

you know, basically how you want data protected and how you want that data to perform kind of at the virtual machine level is really where we're really taking the company and the storage components that we've got. So you mentioned QoS and that sort of stuff. Is that in the product today, or is that something coming when you kind of go with SSDs and stuff like that? It's under the hood right now, so it's technically in the product, but it's not presented out to the end user at this component. But when we kind of unleashed the SSD-based product,

I mean, we have been, you know, I'll say we've been criticized a bit, like, why don't you have SSDs? like, why don't you have SSDs? And really, why don't you have SSDs? Well, I mean, a majority of it's been backed down to basically the market that we're serving. One, majority of them don't need it. That said, it always comes up, right? People are asking the question. But I find mainly they're asking the question because, well, guess what? A lot of the other guys in the space, they pretty much require SSDs. vSAN is a prime example of that. And the reason that they require SSDs is because of the architecture of the storage to begin with, right? It's a requirement to get any performance level out of it at all.

So the reality is the way that we do basically data placement, the wide striping and, and all the components that we do, we can sustain really good performance levels without actually needing it. And the second reason though, is when we do SSD, we want to do it the right way. And there is a very specific right way, because guess what? You don't need a hundred percent SSD for all your workloads all the time. If you think you do, you're throwing away a lot of money, right? Didn't the guys from Violin Memory tell us we did?

Yeah, yeah, yeah. We won't go there. He's not the only one, mind you. I thought I remembered Eric telling us that was a good idea. He did, yeah, he did. Yes, he did. So, you know, yeah, and our customers, bear in mind also our customers, they're typically the ones that definitely don't want to throw – they don't want to throw away any money, let alone a lot of money. So it's really being conscientious of that, and we really want to do it the right way.

And the way that we're architecting it, kind of the way I described how VSDs are going to work and how VSDs work and how RSDs work, I mean, it's – basically it takes getting that level of that fundamental access and then basically the data movement patterns and stuff like that to really nail down – when you think about it, like, you know, basically kind of that sub-object tiering component uh getting that done and done right is more important to us than say oh i can and you know we've had this running in the lab for years like oh i can just take one of those hc 4000 nodes loaded up with ssds and then uh basically sell it and guess what it performs really really well you know but that's not the right way to do it. Yeah, but that's the equivalent of the legacy storage vendors. It is. I'll take my existing array, and I'll fill it full of SSDs, and it'll be four times faster and ten times more expensive. Not everyone's doing that. Hold on that thought for a bit.

I'm not talking to the expense, mind you. Right there. Well, hold on that thought for a bit. I'm not talking the expense, mind you. Right. No, no. Some of the legacy vendors have done a really nice job. Yes, yes. And it's 10 times more expensive, and it's 15 times faster, and that's a good thing. But some of them have just said, here was my existing product, and I'm going to buy SSDs instead of spinning disks. And it's still 10 times more

expensive, but it's only four times faster. Oh, right. In any event. So your system supports, let me call it demotion kinds of things and that sort of stuff? Or how does that work? Well, it's quite simply. So actually, when you take a cluster and you install it, I mean, the first thing you do is basically you plug them in, power them on, assign an IP, create a cluster. All the other administration component is done from the user interface. But the reality is there is nothing that you need to do to basically make the live migration components or the high availability components function. So we have the capability of doing vMotion from one node to another. It's all live migration. So we're doing basically a memory-to-memory copy, the way that the vMotion component has

always been done. And, yeah, that piece just works kind of out of the box. There's no configuration for it. You can move from, you know, any VM from one node in the cluster to any other node in the cluster. On top of that, we've also got high availability built into it as well. So if you have, you know, kind have the catastrophic cord pull scenario on a node or example of basically a thermite going into a particular node not referencing anything. One of my favorite things. Oh, I know.

But if you have that style of thing happen, if the VMs are actually running on that node, the VMs actually go down, but since we're basically distributing that data across the other nodes within the cluster, basically, the VMs will actually automatically start back up on the remaining healthy nodes within the cluster. And that's all. It's basically a zero configuration option for the user. They plug it in, they set up the cluster, and our typical basically rack and stack IP, initialize the cluster, and you're up installing your first VM is pretty much 20 minutes from the point of you getting that box unpackaged and racked up.

Oh, that's nice. So nothing to configure. You don't have to go in and configure complex clustering, make sure MPIO is set up correctly, make sure all those other aspects are done. It's just out of the box. It's ready to go and has those capabilities. Yeah, yeah. Okay.

Well, being the paranoid type, I've got to ask, how do I back this sucker up? There are a multitude of ways that we can actually do that. And so we've got – we do have the option where you can actually kind of schedule like offload a backup. So if you've got VMs and you just want those to be backed up to like, say, an external NAS device or something like that, that's built into the product now. So you can basically just take VMs, like here's a, you know, like have it take a snapshot and offload that to a separate NAS. That can be done today. We also do have an OEM partnership with DoubleTake. So we've also got DoubleTake availability. So if you want for more of a DR style scenario, we can do availability

guest to guest to, you know, basically an offsite, basically offsite cluster. And it doesn't even have to be a scale cluster at that point either. So if you have existing VMware environments and you wanted to use that as a DR target, we could set that up as well. If it's guest-to-guest, then it's Windows-to-Windows or Linux-to-Linux. Bingo. One of the exciting things that we're going to be coming out with, and we're basically scheduled for kind of late Q4 for this, is we do have – or are going to have built into the cluster basically per VM level snapshotting and replication to a remote site with instant restore for disaster recovery. What? What?

Oh, and by the way, that includes failback. Oh, good, because failback's the hard part that nobody ever pays any attention to. And that's probably the part that we've paid the most attention to. So these are two-scale computing clusters in two different sites. Is this synchronous, or is this obviously asynchronous? It will be asynchronous. We're replicating the snapshots, but we also maintain basically a snapshot history. And the way that we're kind of going to be displaying this is also depending on your kind of the bandwidth connection between sites. We're going to show you how many snapshots you're behind at any location.

One of the interesting things about our snapshotting architecture, though, is we have instantly promotable writable clones. So there's no copy out of any type of snapshot space it's effectively promoted live so we can take and this is kind of how our cloning and snapshotting works locally but it's effectively going to work the same the same remotely and so we're excited about this and here's one of the best parts and guess what in that in the price it's all included software is all included there is going to be no additional uplift for um i love the pay one price model don't you i mean that's what i mean that was what you know coming in as like a founder of this company and you know being an it guy for years before that um it it was that that was my single pet peeve was licensing i will mention there there are several storage companies and several networking companies that i always dealt with i'm just like oh you want to do this well here's this licensing fee and this licensing fee and this licensing fee and guess what the thing

ended up costing like three times as much as what the initial quote was. But I could get everything wrapped in there. And it was just one of those things. Like I said, simplicity is not only the product for us. It's basically how you interact with the company. And I think buying the product is a big part of that. Okay. But your storage is only available to the compute on HC3 nodes, right? Yep.

Okay. We did away completely with basically interfacing with any third-party type of environments. Right. It's just not really who we're going after. And by the way, that just gets to be a, that's just a rat hole. Yeah, I understand the complexity it introduces, but it means that, you know, basically I, you know, in for a penny, in for a pound that, you know, I have to go. And it means that if I need more compute, I have to buy more storage, even if I don't need more storage.

Yeah. Well, that's one of the other things that's going to be on the roadmap as well for us is effectively the – think of it as nodes that are more dense on storage and nodes that are more dense on compute. Yeah, okay. Right. Yeah, that makes sense once you get into the SSD because you can have performance storage nodes and capacity storage nodes and compute heavy nodes. Yep.

And that all really kind of comes down to where that whole scribe and the tiering component really comes in. Yeah. Right. Yeah. Well, we're going to have to have another talk when you get scribe auto-tiering and see how that all works together. You know, we're about at the end here. You know, Jason, it seems like it's gone past in like five minutes, but I look here, my timer went

off and all that stuff. I know. Hey, good times. Good times. I don't even think we have any major edits or anything. Howard, is there any last questions you have for Jason? No, I think I'm good. Okay. Well, then, this has been great. Thank you, Jason,

for being on our podcast and our call. Thanks. Always a good time. I have known you guys both for years, and I love just basically having the opportunity to sit down and chat with you and talk shop. All right. Next month, we will talk to another startup storage technology person. Any questions you have between now and then, let us know. Thanks for now. Bye, Howard. Bye, Ray. And thanks again, Jason. Thank you, guys. Appreciate it. Until next time.