Transcript
Hi, everyone, and welcome to today's Tech Bites, live on a Tuesday and not a Thursday. We have a really exciting session planned for you today. We're talking what's new in Kubernetes protection at scale with Veeam Kasten version 9, coming very, very soon. I'm Kirsten Stoner. It's good to be back once again on Tech Bites, and today I'm joined with Matt Bader, product manager for Veeam Kasten. How are you doing today, Matt? I'm just wonderful, Kirsten. I'm a little disappointed. I'm not here with Rick. I love Rick, but you're absolutely fantastic at this, too, so just happy to be back on Tech Bites. Yeah, Rick is enjoying a lovely vacation, and I know it's that time of year where everybody is on vacation. I wish I was on vacation, but we get to talk tech, which is always really exciting, and also talk about what's new and what's coming, right? So before we get started, I just want to – we still want to know where you are tuning in from, so be sure to put it in the chat. I'm actually across the pond today in Prague, Czech Republic, so let us know where you're tuning in from. Also, as we're presenting throughout this session, be sure to post your questions in the chat as well, because we have some good content for you today, and so we want to hear your questions. We'd love to answer them live for you on this live stream. So let's get started. Modern virtualization is becoming more and more popular, and Kasten is really here to make sure that you're able to protect those workloads familiar to you and simple to you and at scale. So Matt, do you want to get started breaking some of the new stuff down for our audience? Yeah. Yeah, absolutely. So I'm going to call a bit of an audible on you here, Kirsten, and that is in that I want to talk a little bit about, just from a workload perspective today, things that are going on both in Kasten and outside of Kasten that support KubeVirt-based solutions, or what we sort of collectively call modern virtualization, for a couple of reasons. One, I've actually got a webinar coming up in just over an hour now that will be going through in detail all of the individual new capabilities in 9.0. So I didn't want to try and pack 60 minutes of content into 20 minutes of me talking way too fast. So I will welcome all of you that are attending today. If there are specific things you're interested in about 9.0, I'm sure we can get the registration link into the chat. Otherwise, just the events page on Veeam.com should be right at the top right now because it is just a short 57 minutes away. But so with that said, I want to cover a couple of exciting things. I think for people that have tuned into my prior appearances on TechBytes over the last year or so, there's been an increasing interest in KubeVirt-based solutions, in OpenShift virtualization in particular, as customers are looking for alternative hypervisor paths and looking at where they can still retain the kind of enterprise functionalities that they've become used to for the solutions that they've been using for the last 10 years, 20 years. And one of the most exciting things that we've been working on in this space for the last six plus months isn't actually a cast in deliverable at all. It's what we've already spoiled on screen here or maybe you've already heard about this recently at a VeeamON event, but it is announcing native support within VBR itself for OpenShift virtualization. So, I want to be very clear, this is not for managing container-based applications directly through VBR. It really is just about that specific KubeVirt workload and I'll get into why that is too. The first questions I'm going to get hit with over and over again are, hey, when am I going to see this? What are the basic capabilities? What is this going to do for me? So, the initial release of this support is going to coincide with the VBR 13.1 release later this summer. You don't require premium licensing to take advantage of protecting OpenShift Virt. Any standard VoL license today will do the trick, but come back to this slide in a second and talk about the what's and the where's, but I think the obvious thing to answer is really the why. So, we have support for KubeVirt workloads within Kasten today. Why do this? I think the best way I can explain this is through an example like you see on screen here where a KubeVirt virtual machine is just another YAML manifest like anything in Kubernetes. It's a very extensible platform to be able to build your own custom resource types and controllers, but depending on what your data protection needs are, it could require a lot of familiarity with those objects, with those APIs to do what you want with them. So, again, a virtual machine could just be another YAML file. Maybe it doesn't look that different from something like a VMX file that you've been looking at for years or possibly decades, but still different, and let's say in this particular case, hey, when I restore this virtual machine, maybe I'm recovering this on a different cluster and I had my distributed virtual switch or standard vSwitch and VLAN on my target is not the same name as my source. Happens all the time. That's a really basic thing that I might want to change or, you know, it could be anything else here. It could be virtual machine name. It could be, hey, I want to use this storage class for these disks when I restore. So could I do all of these things in Kasten today? Absolutely. Because Kasten is built with flexibility in mind, because all of these workloads are different, right? Customers can, again, build their own resource types. I really look at Kasten as this toolbox where you can do most anything. But again, it requires familiarity with those tools and the workloads that you're working with. So in this particular case, like I just want to target a different network. Here I'm having to, again, understand what that API looks like, create some JSON path query to target that field and say what I want to replace that string with. Whereas on the VBR side, because VBR is built with, you know, that particular workload in mind and a VM looks like a VM, whether, you know, you're talking about customer A or customer B, or often in a lot of ways, whether you're talking about one hypervisor versus another. So these are pretty, you know, battle-tested workflows of the things that admins care about. So on the right-hand side, you know, with that native support, again, I'm working with my normal VBR console. I'm creating backup jobs, which is standard backup job type settings. And same thing when I go through a restore operation here. You know, in this case, oh, I'm, you know, I'm targeting a different cluster. And in this case, oh, I want to go through and do my network mappings, you know, to actually be able to see these are all the virtual NICs that you have assigned to these different VMs. These are the available network attachment definitions, effectively, you know, your virtual networks on the target cluster, pick what you want. Same experience that people have been dealing with for restoring a vSphere or Hyper-V for like, again, 10 plus years. So it's about easy button to me. Yeah. So you're telling me with this new integration, right, it's within VBR natively. So customers who are already familiar with the backup and replication, it's going to be very easy for them to get started protecting their OpenShift workloads through being backup and replication, and then being able to restore different types of workloads into OpenShift. Is that what you're laying down, Matt? Yeah. So great, great question. And so I'll make a call out a couple clarifications here. When I say VBR protecting OpenShift workloads, I want to be very specific that we're talking about just OpenShift virtualization. So it's being used to protect kube-based virtual machines and their related dependent resources. So this does similar work to Kasten as like identifying what all of those dependencies are and bundling that up for you. But it is still, this is not a general purpose solution for any container-based application. That's absolutely still where you want Kasten because just how different those applications can be from one another. You want the flexible toolbox-based approach for that scenario. So it's just about matching the right solution with the right problem. But you said something else really interesting, which was, can I restore things from other platforms into these clusters? And that's another one of the interesting pathways that then gets opened up in this offering because we're just, again, using the standard Veeam Data Mover, storing things in the standard VBK format, which becomes highly portable. Not only could you take a backup of an OpenShift virtualization VM and then try to go restore that to a vSphere cluster, but I think for a lot of people, more importantly, the opposite would be true. So there's lots of, there are different tools, there's different options out there for how to migrate from vSphere to OpenShift virtualization, where you might have both environments side by side and doing more of a ongoing replication of storage into that environment. But we've also talked to plenty of organizations where the infrastructure they're running Hypervisor A on today is what they're going to run OpenShift Vert on once they've completed that migration. So they really don't necessarily have the opportunity to do that kind of ongoing migration. It would actually prefer an approach where, okay, I've got some long enough maintenance window over a weekend or something like that, where we've got our final backups of our applications taken from Hypervisor A, and then can go target those back to an OpenShift virtualization cluster and deal with, again, the same type of mapping things that you typically would when you're restoring between hypervisors. These disks came from this data store, so they should be mapped to XYZ storage class or similarly the virtual network mappings. But otherwise, from transforming the overall format and the data perspective, VBR just takes care of that for you, which is pretty cool. Yeah, that is cool. I do love that about the portable backup format, the VPK file. It makes things really easy to move between different hypervisors, different environments. And then as organizations continue to innovate and change maybe the different type of hypervisor they're running, maybe they're looking at something like OpenShift virtualization, it makes it really easy for them to move that data around, right? Yeah, absolutely. And, you know, talking to our audience, I know, I'm wondering, you know, is anybody out there tuning in and using OpenShift virtualization? If you are, be sure to put that in the chat. I know I saw Kevin on Facebook said that he entered the chat. Welcome, Kevin. Be sure to ask some questions as we continue to go on through this presentation as well. So this is really cool stuff, and I'm sure this also helps with, you know, scalability as well. Did you guys add any type of scalability improvements, performance improvements into what's coming in version 9? Ah, yeah. Okay, great. Great, great question. Great segue. So, you know, with this change of introducing, you know, native support in VBR for this workload, what does that mean then for running KubeVirt-based VMs within Kasten today? You know, what changes there? And we're not removing any of the functionality we've built specific for KubeVirt VMs in Kasten. It may change priorities in terms of what capability gets delivered in what place. But realistically, I think we all feel fairly strongly that the VBR-based solution becomes the best option when we're talking about, you know, the core data center platform use case where we're talking about, you know, thousands of virtual machines. I think there is still a, you know, a good use case for Kasten and KubeVirt, you know, certainly where you may really prioritize having a truly Kubernetes native solution. You want something that's self-contained on the cluster, like running a small amount of VMs at the edge, like in retail or we've got some other defense customers that use KubeVirt for that purpose. So, I think, you know, Kasten still has a good fit there. But what you're asking about, you know, the scalability piece of this, where are we going with that both, again, for Kasten and as well in the future for this KubeVirt-based offering? So, what I want to do is provide just a little bit of background on how that works today, from a scalability perspective, how we create backups from Kasten today and, again, what's being changed there in 9.0, because this is pretty neat. So, the existing flow, I'll go through this kind of quickly. I think people that are already familiar with Kasten, this won't be too complex. But when we, you know, snapshot an application, we're creating volume snapshots of the VMs' disks, and then within the Kasten namespace, we're just creating basically a temporary clone, a thin clone from those snapshots, and each one of those is going to get mounted to some data mover pod. And that's going to, in this case, because we're talking about, you know, raw block storage, it's having to read the entire PVC to understand, you know, what has changed since the last time this was exported, because there is no sort of platform-level change block tracking. So, what are the scalability downsides or concerns to how this works, you know, in Kubernetes sort of out of the box today? Unlike vSphere, which in most cases, unless you're using vVols, like your underlying storage is kind of abstracted in terms of, you know, like VMFS data stores. In this particular case, now, the snapshot performance isn't a VM snapshot. It is, you know, individual underlying storage snapshots. So, it's obviously going to depend on and vary with the performance of that underlying storage platform. We've seen, you know, some function better than others early in these migration projects. I already mentioned, you know, it requires that full read. So, it's, you know, putting more impact, you know, from a read perspective is effectively equivalent to like an active full backup every time you're running an export. So, it's putting more strain on that infrastructure. And also, because it's just requesting these serialized storage snapshots, if you've got a VM that has many disks, how do I ensure consistency of all of those snapshots? You know, there's work going on in the Kubernetes upstream space of developing and adopting standards for doing like consistency groups or group snapshots. So, these are all things that I think over time as the ecosystem matures, there will be the storage optimized path where, again, we'll be able to get those consistency groups. You'll be able to get storage accelerated change block tracking to eliminate some of these challenges. But that's dependent on, you know, obviously, finalization of these standards, but more importantly, adoption of those standards on behalf of those individual storage vendors. So, what's changing in going to be introduced as a tech preview within CAST and 9.0? And then this capability we'll also see come to the native VBR offering later this year as well. This is a new API, a new project we've been engaged with Red Hat on for roughly the last year or so to develop a storage agnostic approach to doing change block tracking. So, we'll walk through, you know, process-wise what this looks like here, how that kind of differs. In this particular case, you know, now we're requesting one of these VM backup objects as opposed to just, you know, starting by doing some storage snapshots. And what that's going to do when this VM backup session is active, it's going to spin up some temporary scratch disks. These are going to get used for essentially once we say, all right, we're running this backup, it doesn't stop your VM from writing to disk, right? So, changes are taking place, the backup product CAST in in this place needs a consistent point in time to be able to read from, right? Like as though it had been that storage snapshot. What these scratch, the purpose of these scratch disks, they basically hold any overwrite. So, let's say, you know, our VM backup tracker here or state disk, these are what's handling that list of changes since the last time we backed up. If while this backup is running, you know, one of these PVCs, it's overwriting something we were trying to back up. It's just going to get sort of seamlessly written to one of these scratch disks and eventually just gets read by CAST in itself through this NBD or network block device server. So, it's just exposing this network interface, kind of more a bit like vSphere, VADP, or VAI APIs doing it that way over the network. So, the big difference we see here then is with those data mover pods, we're not creating a temporary PVC from a snapshot anymore. There is no storage snapshot. But instead, each one of those data mover pods is talking to that network block device server, getting this list of, hey, what are my changed blocks from the last time we ran the backup, which is stored in this thin state PVC. And that's just handed over to the data mover pod. So, we can say, now I don't have to read the entire disk. I can say, okay, this one meg chunk, that one meg chunk, and that one meg chunk are the differences. These are what are going to get exported to our repository. So, the big benefits here is obviously now not having to do that full read on every single backup, but also the fact that now it doesn't matter if I'm using a software-defined storage solution like Ceph RBD, or if I'm using existing SAN storage, maybe I've got a Hitachi array or NetApp array or Dell array that I want to use that for my kubevert storage. I'm not dependent on that underlying array's snapshot capability. Does it support its own change block tracking? Does it support volume group snapshots? No, all of this is now abstracted at the OpenShift vert layer. And the other kind of nice benefit here, I know that not every workload you're going to be able to freeze when you take those backups, and you want just a crash-consistent backup is good enough. Now, if I've got multi-disk PVCs like I do here, I'm also just getting that crash consistency now with that VM backup created instance, versus, again, previously I would have had to keep that device frozen through all of those individual storage snapshots to achieve the same. And the best part about all of this and when this launches, again, as tech preview with 9.0, there'll be some steps to enable this. But the nice thing is there's no actual policy changes required. I don't have to go in there and say, OK, I want to turn on CBT for these. Change block tracking is effectively enabled in kubevert at the per-VM level. You could say, OK, I want to enable it for everything, or only VMs in these namespaces, or only VMs with these labels. But if it's there, if it's available to us, we're immediately going to start taking advantage of that. So this is, again, it feels a lot like inside baseball of getting into the minutiae of this. But it is such a, I think this is going to be a big unblocking moment for a lot of customers that are looking to complete these migrations this year. And even more so, I think, as we march towards the end of this year, are able to deliver this same capability in the VBR-based offering, as well as some other nearer-term roadmap things we're targeting for the VBR integration. I think that the end of 2026 is now looking very bright for these customers approaching kubevert migration projects. Whereas the start of 2026 would have been a little rockier having to work through these challenges. So again, not everything that's coming in 9.0. I would encourage people to, hopefully, if they can, check out that webinar coming up or the recording. But it gives you, hopefully, a bit of a taste of what we're looking at from a strategy perspective of trying to support this really critical and quickly growing workload within the ecosystem. Yeah, that's really interesting stuff. I remember last year at VeeamON in San Diego, I was talking to some Veeam customers. And they had specifically asked about change block tracking and how they can cast and supported that. And if that would help them back up some of their OpenShift virtualization workloads and things like that. And at the time, I remember I was like, I think it's coming soon, but it's not quite there yet. So I'm glad that we're finally getting this more developed within our product to give that to customers. Because with change block tracking, it's going to also help shorten the backup time to create those backups. So it's not going to have to take so long to perform and have that big backup window, right? Yeah, less time, less compute consumed, obviously, on the cluster itself. So yeah, wins across the board. Yeah. So yeah, and speaking of that webinar that's coming up, I know we had a question that was asked in the chat about if they could get these slides after this stream. If you register for that webinar to learn a little bit more, you'll definitely be able to get those PowerPoint slides after that webinar. And you'll get to learn so much more about what's coming with version 9. Because Matt just hit on a couple things, but I know there's more. I know there's some security features added. I know there's some observability features that are added that can always be useful in any type of resilience strategy, right? So I know I mentioned a little bit about VeeamON in San Diego, which was last year. But VeeamON changed a lot this year. And for the first time since I've been at Veeam, we took VeeamON global. So we have three flagship events in three major cities around the world, New York, London, and coming soon, we're going to Sydney in July. And these are great events. So let's take a moment to look back at the sights and sounds of where it all started in the Big Apple. Good morning, everyone. How are we doing? This is our 12th VeeamON, but this is the very first one in New York City. It took us a long time to get here, and we are super excited about it. Now, every legacy security model was designed on one principle, that the actor was human. And that assumption just fundamentally broke instantly. So today, for the first time, we are going to show you what we have built to deliver data and AI trust at enterprise scale. And this is the industry's first data and AI trust layer. New York and London were a really big success. And if you weren't able to attend either of those events, don't worry, because we have a full playlist on YouTube with the great content from these events. There is more than 12 hours of insights, product announcements, demos, and customer and analyst perspectives to take you in. And I know I saw some familiar faces in that video, so I'm sure all this content is really great and you don't want to miss it. Also, just to let everybody know, we're going back on tour as well. So VeeamON tour is already underway. You might have seen one in your city. I know Munich was a couple weeks ago. If you want to join us at VeeamON tour, there's going to be more than 30 events worldwide. And there's definitely one near you. So head on over to VeeamON.com today and check out and see if we'll be in one of your locations. We also have some great blog posts about Veeam Kasten version 9, and you don't want to miss out on those blog posts, that content to learn a little bit more about what's coming. I know Matt said that this release is just right around the corner. So you want to make sure you know all of what's coming when it's available, right? So with that... I think in there too, Kirsten, there's a write-up on this year's GigaOM report for Kubernetes Data Protection. So this is the sixth year of the report and six out of six of those years, Kasten has been the closest to dead center leader in that space. Something we're very proud of. I think it's obviously because we're continuing to innovate just around the data protection ecosystem and customer needs here. I make the joke all the time, the good news is with Kubernetes is you have options. The bad news is you have options. So driving support for all of these different patterns of doing things, I think is a big part of what keeps us on top. But otherwise, I mean, I would definitely recommend people check out that report too, just to understand what's being evaluated, how we came out on top. Yeah, I almost forgot. Thank you for reminding me. Earlier today, I was watching the Kasten version 8.5 Tech Bytes just to see, and I think it was mentioned there as well. So you're right, Kasten's on top. And we want to see, we want to read more about why it's one of the best ways to protect your workloads, right? So I know we've shared some links in the chat to all these great resources. I want to say thanks for Matt for giving us the rundown on what's coming with Beam Kasten. Thanks for joining us again. And I hope everybody has a great rest of their Tuesday, and we'll be talking to you soon. Bye.
