Grey Beards on Systems - 116: GreyBeards talk VCF on VxBlock 1000 with Martin Hayes, DMTS, Dell Technologies

Episode Date: March 30, 2021

Sponsored By: This past week, we had a great talk with Martin Hayes (@hayes_martinf), Distinguished Member Technical Staff at Dell Technologies about running VMware Cloud Foundation (VCF) on VxBlock 1000 converged infrastructure (CI). It used to be that Cloud Foundation required VMware vSAN primary storage but that changed a few years ago. . When that … Continue reading "116: GreyBeards talk VCF on VxBlock 1000 with Martin Hayes, DMTS, Dell Technologies"

Hey everybody, Ray Lucchese here with Keith Townsend. Welcome to another sponsored episode of the Greybeards on Storage podcast, a show where we get Greybeards bloggers together with storage assistant vendors to discuss upcoming products, technologies, and trends affecting the data center today. This Greybeards on Storage episode brought to you today by Dell EMC VX Block and was recorded on March 23rd, 2021. We have with us here today Martin Hayes, Distinguished Member of Technical Staff at Dell Technologies.

So Martin, why don't you tell us a little bit about yourself and what's new with VX Blocks these days? Hi Ray, hi Keith. Pleased to be here today. So for myself personally, I've been around Dell Technologies and Dell EMC and EMC and VC quite a while. I joined back in 2011, back at the start of the VXBlock

or the VBlock journey as it was then. Or, you know, we really, we invented the converged infrastructure industry, right? So I've been with us since the start. Oh, my. Yeah, yeah, yeah, for a while. I'm beginning to look back at the years now. I'm finding a couple of grey beards as well, right?

Yeah, yeah, of course. Yeah. So prior to that, I kind of went on a little sabbatical. You know, I was working in a telco in Ireland, in the largest telco in Ireland, Aircom, for a couple of years. And prior to that, when I left university, I joined EMC proper way back in the back end of the 90s. So I'm a native from Cork, Ireland.

I haven't ventured far, so I'm still here now. But I have traveled quite extensively with Dell, with Deltal Technologies, EMC, and VC, visiting all our CI customers customers really throughout the globe. So I spend a lot of time on airplanes. So I kind of miss it. I kind of miss it a little bit in the last year or so. We do, yeah. So I didn't think I would, but I do, right?

But we won't record that part, right? No, we'll record it. So what's going on with VXBlock these days? So, yeah, so we've been, so I presume everybody, you know, who's familiar with the VMware side of the technology, you know, there's been a lot of buzz around Cloud Foundation over the last 18 months, two years in particular, and particular with VMware in terms of HCI, right? So it's been a big play with HCI and it's been a very good fit with vSAN,

with vSphere and NSX-T, bringing that all together in a kind of one automated lifecycle managed product or offering, right? So we've been looking at that for the last year or two in terms of how could we bring VCF with VMware to market as well, right? Okay.

So with the advent of VCF 3.9, maybe about a year, year 15 months ago, VMware released the capability to do native fiber channel storage with VCF, right? Our cloud foundation. So that really opened up a whole gamut of possibility for us to offer the benefits of cloud foundation, the benefits of lifecycle foundation that benefits of

lifecycle management with vcf on a three-tier architecture like uh like the vx block and vx block 1000. so so last week um march 18th uh day after paddy's day um or simpatrick's day call it here um we had we had our secondary celebration where we um VCF 4.1 on the VXBlock 1000 platform. Oh, okay. So this is quite a new change for you guys then, right? It is. It is for sure. I mean, we always were in terms of, you know, I think the VXBlock 1000 was synonymous with the, you know,

when we brought the first platform to market back in 2011 around the whole lifecycle management piece around the LCM, RCM process, and so on. I think VMware lifted that a level with VCF and SDDC manager. So we were anxious to kind of, rather than reinvent the wheel, to kind of collaborate, I suppose, with VMware and lift that offering a little bit more in terms of the lifecycle management experience on the vSphere piece in particular.

So I'm pretty anxious to dig into this. This is one of the technical areas where, you know, we're not talking purely storage. We're talking kind of this higher level data center and cloud management function. I've used VCF in the past and I've used or at least I've experienced the benefits of VXBlock. Previously, VXBlock is still a very, very important part of the Dell portfolio because this is where I put my heavy workloads like SAP, HANA, SAP, proper ERP solutions

on. What was the driver? What were customers asking for when you take something like these mission-critical apps or data center consolidation and merge it with VMware management? Yeah, so I think there's kind of two parts to that answer. I think the first piece was they were conscious, these customers, of wanting to, you know, a lot of customers want to get the next new thing, right? So they want to be a step ahead in terms of VCF offers a lot. It offers them a lot of, probably from a VMware perspective, that fastest route to the public and hybrid cloud.

So the ability to deploy that base camp with VCF and then segue or layer on top, for instance, VRA or V-Realize Automation, or the ability to bounce into the cloud, if that's a term, right? Bounce into the cloud or the public cloud using VCF or NSX-T on AWS. So that's the first piece. So some of these customers were interested in maybe potentially using existing platforms or technologies that they hadn't fully deprecated yet, right? To deploy those new features and functionalities. The second piece, as you said it yourself, was how could they do that in unison with existing mission-critical workload that they already had around SAP HANA, around database,

some of the bare metal workload they were using, and so on. So I think the VXBlock actually uniquely fixes that problem for them or addresses it in terms of the inherent scalability of VX block being what we call an end of row scaler in terms of the ability to scale out to hundreds of thousands of virtual machines, VCS enables them to compartmentalize, right? To put, say, VCF on one UCS domain and potentially leave SAP HANA on another UCS domain or bare metal on another UCS domain, all right? So there's no lift and shift. So it's potentially the ability to, right, we can look at new technology or deploy new technology in unison what we've got already. So how does that workload domain separation differ from VCF instances and things like that?

Are they effectively one and the same? So a VCF instance would be associated with a workload domain or can you have multiple workload domains? Yeah. So that VCF instance, right? So a single VCF instance can, you know, multiple workload domains, 14 plus one, right? And the workload domain then is aligned to a vCenter instance itself, all right? So if you think in a block, I could deploy on my vSAN AMP, right? So that's the new construct we have. If folks are familiar with CI and the VXBlock platform, we had this concept of a, we're this concept of a, we're kind of ahead of our time there again as well in terms of the advanced management platform

to manage all the out-of-band, but in-band management as well. That really doubled up as a cloud management platform, which really segued nicely in when we added vSAN to that to allow us to do VCF on top for the management domain. The management domain then hosts those multiple instances of vCenter. And then what we can do is we can align each instance of vCenter potentially to a UCS domain or part of a UCS domain. So I might've missed this part of it,

because this is one of my big questions coming into this conversation. When I think of VCF, I think of vSAN. When I think of VXBlock, I think of block storage that's not vSAN, like the complete opposite of it, because there's, you know, there's inherent advantages of VXBlock, especially for managing large workloads or data center consolidation. How do you guys reconcile like the vSAN-centric nature of VCF and the block nature of VXBlock? I think the answer to that is I think VMware did a fantastic job in selling VCF with vSAN, right? First and foremost, right?

So that's why it became synonymous with vSAN, right? But when you peel it back, right, VCF really just automates the VMware stack being vSAN, NSX-T, and the vSphere piece. And then it wraps around your tried and trusted kind of cloud concepts that you might be familiar with if you're familiar with AWS, around multi-regions where I'm doing DR, or multi-availability zone where I might be doing Metro between two sites. Now, VMware do Metro between two sites. All right. Now VMware do Metro between two sites using stretched vSAN. All right.

And VMware do DR between two sites using stretched vSAN. All right. Or vSAN or some kind of replication or vSphere replication. Whereas we know here, right, so Dell EMC have been doing stretched or Metro connectivity for years now using srdf metro aren't using vplex yeah power right yeah and power marks right and we've been doing for years we've been doing we've been doing multi or dr types uh dr type replication using recover point and recover point for vm so it's an easy transition you take the same concept. So all we're doing really is

VCF is exactly the same on block, except we're using a different underlying storage technology to deliver the local storage, obviously, or the shared storage on a per data center basis. But we're using just slightly different underlying technology using more Dell technologies to do stretched availability zone using Vplex first and SRDF Metro sometime in the future, right? And also potentially some maybe SRDF asynchronous SRDF technology or RecoverPoint for VM to do multi-DR. I'm a former Vblock customer. We buy a couple of them. So, you know, I understand local replication extremely well. We've used RecoverPoint for DR.

In these two worlds operationally, the VMware team and the storage team have been traditionally separate. Today's environment, we need those teams to merge and become a little bit more seamless. So this is exciting news. But still, some of these concepts are a little bit foreign to these teams. So it would be great if you can just walk us through conceptually how something in the future may work around like recover point. I just have not. You know, the the way that we did DR testing was that we'd open a ticket with the storage team. They'd represent storage to a set of hosts. And then the VMware team would either take over with scripting or manual provisioning of storage to that remote

VMware system. Are we thinking that at some point this would just be automated? Yeah, so we won't use SRM. So we won't use SRM. The likelihood is we won't use SRM with RecoverPoint for VM, right? Because it's got its own workflow to automation engine within RecoverPoint for VM, right? That's got a deep hook into vSphere, right?

So we can write workflows that do the automated recovery, right? So if you if you were familiar for instance with EHC in the past or enterprise type of cloud from VMware or from Dell EMC something very similar all right where we did automated workflow or automated workflows to do DR type failover with NSX-V for instance all right to stretch those networks so the issue with DR is not so much the storage replication, it's getting the networks from site A to site B, right? That's always been the big challenge with DR. It hasn't really been on the storage side, right?

Because the replication is always really happening on the, the replication is really always happening on the backend, and it's only a manner of then your RPO or whatever, right? So from a storage perspective, when is it available on the backend and it's only a manner or then a European or whatever. Right. So from a storage perspective, it's what is available on the other side, right? The issue with the replication piece was always, and this is what really VCF fixes with this concept of multi-DR or multi-region rather, is the ability with that key, one of the key components of the underlying components of VCF, which is NSX-T, and the ability to do multi-region support

with those stretched AVNs, Ray, that we talked about ad nauseum. Yeah, yeah. Right? So basically what that is, is the ability, so if I lose my site A, no matter what the underlying replication technology is, so if I know that I have a copy on the other side, my big issue isn't really the storage. It's my network identity. My network identity has to follow to the far side. And that's what VCF does. VCF automates the multi-region, the replication of those networks, those stretched overlay networks from say site A data center to site B data center. So we we normally think about this in terms of DR

because we're storage folks, we're enterprise architects. But one of the cloud benefits is that that technology also supports not just multi-tenancy, but landscape management. So as we think about moving from a legacy set of monolithic applications to more cloud native applications, and the gap in between, again, I'm a SAP, former SAP recovering architect. One of the challenges that we've always had was landscape refresh, landscape management, and a huge problem with that was the networking.

So you think about every time you needed a new SAP landscape or a new test environment, you'd have to, there was a painstaking process to automate that creation, one of which would be networking. Are you guys seeing demand for this type of technology to automate SAP-like applications? They are not quite Cloud-native, but you need these Cloud-native type of constructs

from operationally from a CI, CD perspective or just traditional application landscape management. Yeah. What we are seeing and it answers that question mean, what we are seeing, and it kind of answers that question, is are we seeing more and more customers who are looking for what we call zero touch provisioning on the network

to integrate more of the application stack? Even if that's, I say, Piana, or even if it's, even if from traditionally as people would understand from infrastructure as a service with VRA or VCloud director did the same kind of thing at the start, right? Where you'd provision a workflow and the network would just get attached.

All right. So that's definitely, you know, and everybody's heard the buzziness around, you know, infrastructure as code, right? Which is basically just a bit of a script, right? I hope I haven't dumbed that down, right? But so we're definitely seeing more and more around that and a requirement for that to decouple the physical pressing of the button and the physical configuration of the network stack. So Martin, does that come with NSX-T or is that VRA or a combination of the two?

A combination of both, right? So NSX-T can have automated or built-in plugins that are heavily API-driven, right? So customers can use or leverage the API hook into NSX-T where it will auto-provision networks on the fly and attach to virtual machines. So if I can connect to a portal, I deploy, I want a new Windows machine or a Linux machine, then it will add the network from a network pool consumed from NSX-T, transparent to the user. All right. And where does the edge cluster, the NSX-T edge cluster fit into this worldview? Okay, so we'll step back and it's another subject close to your heart, right? All right, so I think we've been guilty of this

in terms of terminology, and especially the last year or two, there's a lot of terminology floating around. And we talked around AVNs, and we talked overlays and underlays and Geneve and so on. So basically, VCF uses what are called application virtual networks, right? To deliver a couple of key services to the VCF user, right? Now, basically what an application virtual network is, it's an overlay network based on Geneve. So it's a virtual wire, right? So older term VXLAN or different type of encapsulation method,

which was VXLAN, right? So with NSX-T, it changed to Geneve encapsulation. So basically what it is, is it's a network that's sitting on an underlay transport, right? And I can attach to a VM to it and VM does no any different, right? So as I said, VCF uses that to deliver some services, as we just talked about for Upper Stack, for VRA, for Relay Automation. And it also will heavily leverage it in terms of some of the capability we talked about, Keith, around the DR piece, right?

That ability. So the ability to use overlay networks really made that ability to stretch networks from site A to site B a lot easier, much easier, right? And much easier and with a greater ability to separate the fault domains, right? But we won't really get into the weeds there, right? But just to say that, right? So it's really key to adding services and technology

and features and functionality to VCF. Now, what that does mean, of course, is once I encapsulate something in an overlay, at some point, I'm going to have to de-encapsulate it. So if I use overlay networks and they're used heavily, as I said, in the management domain and they're used in the workload domains within VCF, at some point, then I'm going to have to de-encapsulate. And that's where the concept of the edge cluster comes in. And all the edge cluster really is, is a series of servers where one interface facing the overlay takes in the packet, de-encapsulates and takes it off and exposes the VLAN header and shoots it off in

its merry way out to the traditional wired network. That's all it does, right? And, of course, it does other things in terms of network, in terms of firewalling and all that kind of stuff. But don't do brass tacks. That's what it does, right? It takes encapsulated traffic in an edge and then de-encapsulates it and shoots it off in its merry way and does the reverse, of course, on the way in, right, on the ingress to the network, right?

So that sometimes confuses some of our customers that I've talked to in the last couple of weeks and saying, oh, well, do I need an edge cluster? My view is that you probably do if you're thinking, you know, I think it's worthwhile in terms of if you want all those additional features, of course, which you will, because no doubt in six months' time,

you're going to say, well, we want to do this DR stuff, Martin. I told you so right um so but that being said for we don't mandate on our release of vcf and block we don't mandate an edge cluster what that will mean is is that is that you you everything that gets deployed in the management domain and everything that gets deployed in your production domains get attached to traditional vLANs or traditional networks. That means, of course, that you don't get the benefits of true VRA integration if you decide to deploy VRA-lized automation,

or it becomes, I wouldn't say impossible, but a whole lot more tricky to do multi-DR, multi-AZ from an automated fashion. Of course, the gotcha is you don't get the edges, but the way it's licensed, the platform is licensed, it still prepares what's called prepare, it still prepares the actual underlying, or not the, the hypervisor for NS6T capability, right? It deploys the Vibs, attaches the license, deploys the managers in the management domain. So you get a lot of the overhead.

And of course, you can use what's called micro-segmentation with CLANs, which is security capability. So that's a big gotcha. So you don't need the edge. You still get the benefits of micro-segmentation. But you do, I think, my recommendation is that I would think long and hard about not going the full hog with the edge cluster because it's just going to be a little bit tricky to do after the fact. So I love the conversation about merging the cloud layer. And I know some people might get offended by calling VMware Cloud Foundation cloud. It is enterprise cloud.

It is merging that or integrating that layer with the underlay of a VX block data center design. And I think this conversation has highlighted a lot of the nuance that people really don't see when they draw it on the picture and, you know, kind of paint the cloud and paint the integration. One of the things that Dell has, Dell Technologies, inclusive of VMware, has done really well, both on the VxRail side of the house, which is what we normally think about VCF, and the VxBlock side of the house, which is, you know, more, I want to say artisanal, traditional enterprise stack, is move enterprises closer to cloud-like capabilities. Can you talk competitively? What are the things that VxBlock is doing with VCF that you're just not going to get with other converged infrastructure systems, even if you coupled it with VCF?

So the VBAL stuff for PowerMax is now present, and that's starting to come out with other storage as well, right? Oh, yeah. Yeah. So that's a good place to start there, right, around VVOLs, right? So we are going to ingest, and we talked about it earlier as well, in terms of, you know, VVols gives us the capability on traditional storage, if we call it that, and I'm not the greatest fan of that management, right? And integrate with all the, you know, the work we've done with VMware or the work with the BUs I've done with VMware

in terms of container storage integration and the CNS or cloud-native storage integration with vSphere with Tanzu, all right? So I think that's something that our competitors don't offer, right? So it gives us another kind of string to our bow in terms of that coexistence of traditional applications,

modern and emerging applications, and potentially cloud-type applications up our stack. Yeah. All right. I would say the other thing that's somewhat similar is some of the capabilities of scale-out scale up that are present in the solution and the GPU support and all the AI stuff that's starting to come online is pretty impressive. The capabilities that you can configure in a VX block solution, they're just amazing, right? Yeah, and we've talked a lot around as well, I suppose, what we talk around primary storage, or primary storage from a

VCF perspective, which we know Unity XT, PowerMax, PowerStore, right? We haven't also talked about the capability, right? You know, the engineering capability where we've integrated PowerScale and Isilon, right? For file sharing, big data, vertical workloads, and so on, right? To attach with VCF as well, all right? So that's a big, you know, that's all the work that we've already done on block, all right? That's kind of in a VCF construct. It's kind of seen as, you know, even the term supplemental is seen as secondary,

but we've engineered it already into the platform. All right. So that's that, you know, so that's, that's a good mix, I think. Right. So that primary and secondary storage story, right. With VX block and VCS. What about the data protection story? There's something there as well, right?

In terms of data protection. Data domain. You know, the same, same thing. Right. So, yeah. In terms of data protection. Data domain. Same thing, right? So, yeah. So, again, all the work we've done on the data protection side is transposable, right? That's a big word for me, right? From what we've done into a VCF construct, right? All we've changed really with VCF is the consumption and automation layer, right?

Everything else remains the same and consumable. Now, we've done a little bit more work in terms of power protecting the management domain for VCF management workload, being engineered to protect the actual workload domain itself or the management domain. But everything else is, as I said, if it's offered with Block, it's offered with block it's offered with vcf and where does the where does the life cycle management stuff fit into all this framework so yeah so um that's that's another that's a good question right so so there is a you know true patrol there is a decoupling right of for instance vcf on hci in terms of being a closed system, a closed vSphere system, in terms of, I don't mean that in a bad way, right, but enclosed, rather, in terms of,

you have vSphere, NSX-T, and you have vSphere, NSX-T, and vSAN, right, all sitting on the hypervisor, right, give or take, and you have your management entity, right, which are your NSX-T managers, your vCenter, and that's pretty much about it, are your N6T managers, your vCenter, and that's pretty much about it. And vSAN built into vCenter. So to do the lifecycle management from an SDDC manager perspective from VCF, click of a button. As long as the HCL is compatible with the underlying host. So I think VCF went straight away a couple of years back from going down the path. I think they originally, or VMware, wanted to maybe lifecycle the top rack switches and it quickly turned out that maybe that's not a great idea because I'm a network guy and most network guys

don't ever want to touch the switch. Should never be upgraded, ever. Don don't break it it works right so so i think you know so but so in that vsan construct it's it is nice and tight and it's it's it's straightforward right um from a block perspective you know it is straightforward from a virtualization point uh perspective but of course when you get into the the all the other bits of the underlying components there is an array that's outside the management of sdc. There is an array that's outside the management of SDDC manager. There is a SAN that's outside the construct of SDDC manager, or that's ownership. And there is, of course, the network layer as well,

the physical network layer. But what we're seeing is what we're going to do is we're going to, we're looking at building with VX Block Central, our traditional, or lcm manager for the management domain on block built to building kind of unified workflows and what we call cable to cloud in terms of you know uh bringing together the workload the lifecycle management experience of what's on block for those underlying physical infrastructure components and what sdc manager will do with that click of a button. Okay.

If that makes sense. There's a bit of work to that. So we're on the podcast and we're kind of open. There's a bit of work with that, but what I would say there is we see a lot of those underlying components. Our view of this is

customers will be able to do, would probably be able to go through multiple iterations of SDDC manager type upgrades without ever having to impact the underlying infrastructure. Yeah. So this is the desired outcome. If you're taking something like a VX block, you want a data center wide, in some cases, infrastructure layer. You want to be able to put multiple platforms on top. One of those platforms is VCF. Another platform may be you want bare metal Tanzu Kubernetes and you don't want it to be within your VCF environment. You just want a separate environment. And some of it, you just want bare metal Linux or Windows nodes that have nothing to do at

all with your VMware environment. That's a typical design. But you want a consistent underlay with lifecycle management that you don't want to put the engineering effort into. So I think it's a smart decision to decouple the two and VCF not the VCF be the entry point to the VMware experience and your CI lifecycle management be the entry point into lifecycle management of the underlying CI. And NSX-T is kind of the key to all that stuff working together to some extent. Yeah. And yes and no. Right. Right. So we can have we can have and that's a very good point. Right. The some extent. Yeah. And yes and no, right? So we can have, and that's a very good point, right?

The keep mix, right? So on the management platform, right? So the vSAN AMP, right? So that scales and we probably could place a touch on that now, right? So for VCF, it needs to be vSAN based, which it is, right? So it needs to be a minimum of four servers, but our vSAN AMP scales to 16 servers, right? Specifically for that type of use case, right? So we'll scale up and scale out. I keep on getting them mixed up, right? So it's scale up more servers or scale out more memory.

I get mixed up, right? But it can scale up and scale out, right? In terms of there's a, we have a medium and a small, medium and large, medium, large for VCF, and it can scale from four to 16 servers. And the reason from four to 16 servers. And the reason it scales to 16 servers is, as Keith just mentioned there, the ability to potentially put VCF on one part, compartmentalize it on one part of the management platform, but also potentially ecosystem workload, other vCenters, potentially other lifecycle managers for bare metal or whatnot on that AMP management platform to lifecycle management

manage the rest of the infrastructure, independent of ECF. Okay. So Keith, any last questions for Martin? No, we can talk about this stuff all day, so I'm not going to open it. So Martin, anything you'd like to say to our listening audience before we close?

No, I think I've chewed the air off you guys. Well, this has been great. Thank you very much. Absolutely. Martin for being on our show today and thanks again to Dell EMC for sponsoring this podcast. That's it for now. Bye Keith. Bye. And bye Martin. Bye guys. Until next time.

Next time we will talk to another system storage technology person. Any questions you want us to ask, please let us know. And if you enjoy our podcast, tell your friends about it. Please review us on Apple Podcasts, Google Play, and Spotify, as this will help get the word out. Thank you.