Transcript
My name is Alexandre Ivec-Arnec. I'm the global manager of the Kasten pre-sales team. We are going to spend one hour, maybe a bit less, talking about how to migrate and secure applications on Red Hat OpenShift on AWS with Kasten. So I'm going to be the host for this session. And if you have questions, feel free to ask your question in the chat. I will try to keep an eye on the chat, especially during the demo. Especially during the demo. So basically, the objective for that session is going to, on one side, cover the reason why we are talking about securing applications on Red Hat OpenShift. We are seeing more and more applications having different type of data related to the cloud-native applications that potentially you could run on OpenShift. That's one aspect of the presentation. The second one is about the way you can manage multi-cloud Kubernetes environment, once again, especially leveraging Red Hat OpenShift. And in this particular case, we are going to make a focus on a specific offering that is called Red Hat OpenShift on AWS, also called ROSA, for the people that are familiar with this offering already. So that's what we are going to discuss during this webinar. So let me just put the slide in presentation mode. OK, all right. So before jumping into the, I would say, the technical details or the technical aspect of that presentation, I just want to share with you a few numbers about the context and the space where we are, just to give you a good level of understanding about the challenges that we are going to address during this presentation. So the first point is about the 74% of organizations that are still thinking that traditional and container based applications can be backed up the same way. Obviously, you will see during this presentation that they cannot be backed up the same way, simply because between the platform running virtual machines or bar metal servers and Kubernetes platform running applications, the platform itself is just completely different. So you can't address the same topic for applications having different requirements and constraints. So that's the reason why you need to think about another solution, something different that you are using already right now for the other workloads that you have in your environment. The second point is the 85% of companies that have experienced at least one ransomware attack in the past year. The thing that is interesting when you start digging into Kubernetes, especially when it comes to talk about Kubernetes environment in production, still a lot of customers right now are at the beginning of the adoption of Kubernetes in production. And all those topics, especially things related to security, data protection, and ransomware attack are still new for the Kubernetes environment and the Kubernetes space. So it's really important to think about that before moving business-critical applications in production on Kubernetes. 93% of organizations think multi-cloud support for containers backup is important. You will see that during the demo later on in this presentation. Kubernetes by itself is a platform that is definitely designed for multi-cloud environment. And in order to mitigate different type of risk, the idea will be, of course, to, at some point, get your workloads running on one client and potentially get at least one copy of your backup in a different cloud or in a different environment. So I'm going to show you how you can easily address that risk by using Kasten. And the last point, 75% of organizations indicate a skills shortage on their Kubernetes backup and recovery chain. This is one of the very difficult topics that we have right now. When we talk about Kasten, we are on the kind of crossroad between operation, backup, infrastructure, storage. And DevOps team, we are actually touching responsibilities or operation that right now are still spread across all those different teams in many organizations. And usually, the backup operation are managed by the backup team. But in the vast majority of the situation we have right now, those teams that are not yet familiar with the Kubernetes space. So the idea is, how can we make all of that much more simpler for those teams and make sure that even though you don't have any skills on Kubernetes or if you have just a very small or light level of understanding of that new platform, the idea is to make sure you will be capable very rapidly to operate this platform from a backup and recovery or data protection standpoint. Moving forward, when we talk about Kubernetes quite rapidly, we talk about hybrid and multi-cloud. So 50% of organizations on the market plan to increase the number of current cloud providers. So it's very common for us to discuss and work with customers on the market having at least two different type of cloud to manage. Of course, most of them have assets running on-premise. And some of their applications or data is being operated into the public cloud. But more and more customers are also using different hyperscalers for different purposes or different business lines. So the idea is, once again, how can we manage all of that in a simple and consistent way just to reduce the complexity and reduce the risk in these type of scenarios? 97% of customers on the market agreed their business requires a mix of cloud and on-premise resources. This one is right now really a kind of standard situation that we are seeing on a daily basis. At least customers are using or have already adopted one cloud provider. And they have, obviously, assets running on-premise. So once again, when we think about that statement in the Kubernetes space, quite rapidly, customers need to operate Kubernetes on both sides. And quite often, or more and more, they will need to move, migrate for different objectives, for different reasons. Application between different Kubernetes environment. And 88% of customers on the market are agreed about the requirement for hybrid or multi-cloud strategy. And this will be directly driven by business requirements and business challenges that they have to support. So once again, just the point that hybrid and multi-cloud situations is becoming more and more the de facto situation, especially when it comes to talk about Kubernetes. The first preconceived idea I would like to cover in this presentation is that belief that, since a very long time, Kubernetes is a platform that is mainly designed to manage something that we call stateless application. When we talk about stateless application, we're talking about application that don't necessarily have persistent data. The thing is, actually, since a very long time, as you can see on this slide, Kubernetes has been designed over time to be capable to manage persistent data inside the cluster. And when we observe the customer set that you have right now on the market, the biggest deployment, or the most major customers using Kubernetes in production right now to run business critical application, those customers are actually bringing the data side by side to the application. Because it provides so much assets, and it's such easier to manage an environment when the data is living side by side to this application, to those applications, that actually customers are adopting this approach. And the thing here is simply to demonstrate that, over time, the Kubernetes orchestrator on this platform, itself, has evolved to be capable to support persistent volume and bringing, over time, also additional features to provide snapshot and clone features to properly manage persistent volume within the Kubernetes cluster. Just one point to highlight here, especially, is since the end of 2018, the CSI operator framework is GA on Kubernetes. So for the people that are not familiar with the CSI driver, it's simply a specific driver that will be the interface for the Kubernetes platform to interact with a storage service, a storage system living outside the Kubernetes platform to request persistent volume for Kubernetes workload and make sure that those applications will get access to a persistent storage system to store and record the data. So this is something that is actually there since quite a long time. And of course, all of that has continued to evolve over time. And now, the vast majority of the storage vendor on the market, they have and they propose a CSI driver bringing more and more features and capabilities. So snapshots and clone are definitely the basic features that you will see with the vast majority of the driver on the market. But you will see more and more features coming in the future, especially when it comes to talk about large data sets managed in Kubernetes. There will be something called change block tracking that will be integrated and be adopted more and more by the market for the Kubernetes space. This is one of the concepts that is already there since a very long time when we talk about data protection for virtual machines. But the change block tracking concept is also starting to be adopted by the different vendors in the Kubernetes space. Moving forward, basically, what is Veeam Kasten from a use case perspective? Actually, the objective for us is to simplify all the data operations. So we used to talk about four specific use cases when it comes to interact with the market. We used to talk about backup and restore features for cloud-native applications. The idea is once we have the control and once we have access to the application and the data is related to this application, we are going to be capable to operate and provide disaster recovery functionalities to simplify the recovery if, for whatever the reason, you lose an entire Kubernetes cluster or if you lose the entire source environment with Veeam Kasten, you will be capable to very rapidly recover your applications on a different infrastructure or a different cloud. As we said before, hybrid and multi-cloud is a very common use case in the Kubernetes space. And when we talk about application mobility for Veeam Kasten, the objective for us is to be capable to be fully agnostic from Kubernetes and from an infrastructure standpoint. So this is something I will show you during the demo. But for instance, if you need to move your application from Azure to AWS or from something running on-premise to one of the IPs that are on the market, of course, you will have to adapt your applications from a networking standpoint, from a storage standpoint. You will have to deal with differences that you have between two different infrastructures. And this is one of the big assets that Veeam Kasten can provide to you in making sure that whatever the Kubernetes platform, whatever the cloud you are running your application, you will be capable to very easily restart your application somewhere else. And of course, as soon as it comes to talk about security, and especially nowadays with all those ransomware topics that we have to cover, you will see that Kasten brings integrations and some specific advanced feature to help you to be protected in a such situation. So what do we do and how it works? It's pretty straightforward. Basically, you will see that Kasten is simply an application running on top of a Kubernetes cluster. And from that perspective, we will get the full understanding about what is a Kubernetes environment, how does it work, what are the different object components, mechanism that you can observe on a such platform, and automatically, without doing anything, once Veeam Kasten is deployed, we will discover all the new applications that will be deployed on your Kubernetes environment. So this is something that is fully seamless and that is automated by default. Of course, once that is done and once the Kasten solution is deployed, the first thing to do is to protect your application. So you will see that during the demo, we are going to protect two specific type of workload that are slightly different from the way they are built. And the protect approach is something that is very simple because if you are a Kubernetes expert or not, you will see that you will get a UI or you will be capable to operate everything through the Kubernetes APIs. And whatever your level of understanding and skills with Kubernetes, the Veeam Kasten solution will be capable to help you to operate and execute those actions. And of course, doing the backup is one thing. It's great, but the most important thing It's great. is to be capable to restore your application. It doesn't matter what happens. And you will see, especially through the application mobility use case, that Vimcast-N is capable to restore your application absolutely anywhere, as long as you have a Kubernetes platform to restore those applications. So when it comes to talk about the discovery phase made by Vimcast-N, the thing is pretty simple. By default, you have a UI that is pretty straightforward to learn and adopt. And automatically, Vimcast-N will detect all the new applications that will be created on your Kubernetes environment. When we talk about applications from a technical standpoint, we talk about namespace from a Kubernetes definition standpoint. And automatically, we will detect all the namespace and all the resources that will be created inside the namespace. So you can think about persistent volume, deployment, config maps, secret services, and others. But also, we will be capable to understand that some applications will get resources being deployed outside of the namespace, so basically at the cluster level. So if you have specific applications using custom resource, we will be capable to detect and discover those additional resources and integrate those resources also into the backup that we are going to deliver. Because we are going to talk about stateful application having persistent data, the challenge for us and for a lot of customers on the market is to be capable to properly backup, protect, and recover different type of data services. So when we talk about data services, basically, we are talking about databases. It could be SQL or NoSQL databases. Those workloads could be deployed inside the Kubernetes platform or even outside, like using managed service provided by an hyperscaler. Veeam Kasten will be capable to understand that type of configuration and will be capable to properly integrate the backup of the data service being deployed inside or outside of the Kubernetes cluster and integrate that part of the backup with the rest of your application. When it comes to protect your application, to keep things simple, basically, we are going to do two big actions. The first one is going to create a local backup. That backup would remain inside the source environment, inside the Kubernetes cluster, simply to provide to you a way to very rapidly restore your application if you have any type of issue. And to make sure that your backup will be available all the time, we are going also to create a copy of that local backup that we used to call an export. And that export will be offloaded on an external storage repository. I will show you that once again during the demo. And in order to manage the lifecycle management of your backup and exports, you will see that you can set up different type of retention strategy to operate the rotation of your backup and just make the lifecycle management very easy. Restore absolutely anywhere. This is one of the demonstration I will do as well today. When it comes to backup cloud native applications running on Azure and restoring the same application on AWS, for instance, you will have to reconfigure your application on the destination environment. Because obviously, between Azure to AWS, the storage services will be different. The networking access will be different. And eventually, you will need to readapt some aspect of some configurations of your application. So we have something called transformation that you can inject during the restore process. And Kasten K10 will take care about the reconfiguration of your application just to make sure you will be fully compatible or compliant with your destination environment. And thanks to those transformation mechanism, that's the way for us to become fully agnostic from Kubernetes and cloud standpoint or infrastructure standpoint. Security is a hot topic, obviously, for us. And we do our maximum to fit with the NIST cybersecurity framework. So as you can see on the slide, we provide a bunch of native feature or additional integration to make sure that with Kasten K10, you will be properly protected against a ransomware attack. There are many things we could mention here. Just a few points. We are capable to integrate in many different way the way you are going to authenticate on the Veeam Kasten platform. Embedded into the product, you will get also the capabilities to create role-based access controls. So you can define specific roles with specific set of permissions. And eventually, if you have this requirement, delegate actions to some internal application owner or business line or eventually external customers that you could serve. So things like that are fully built in and embedded into the product. Obviously, when it comes to export the backup outside of the production environment, all the different object storage platform that will provide immutability to secure a bucket, we are going to be able to leverage that as well. By default, when we backup and especially when we export outside of the Kubernetes cluster, we encrypt the data. And in the way we manage the encryption, we are capable to integrate with some external vault to manage the rotation of the encryption key. Thinking about AWS Secret Manager, I'm thinking about Azure Core Vault or a solution like that. A very big part of the deployment that we have right now are customers using Kubernetes on air-gapped environments or Kubernetes environment that don't have access directly to internet. So Veeam Kasten is capable to be deployed in a search way for this type of environment. And there are many more features as well that we have provided over time. Maybe one of the last one is about the SIEM integration. So if you want to monitor everything that is happening on the Kasten platform, you will be capable to do that with SIEM platform like Datadog or Azure Sentinel for one of the last one that we have added from support perspective. Just a quick recap to let you understand if you are not familiar with Kubernetes that cloud-native application is something that is very different from, I would say, a virtual machine or bar-metal server. So from that perspective, you need to get a specific solution that will understand that construct, that will understand that Kubernetes is something that is operated in a very different way than, I would say, a regular virtualization platform and even more from application that could be still deployed on bar-metal server. So from that perspective, you need to get a solution that will understand the rules of the game and the way Kubernetes operate and manage applications. So that's the reason why you can't back up those type of application with probably the existing data protection solutions that you could have already on your side. So VMkasten 7.0, we released recently one of the biggest release we had so far. Just to give you a quick overview, we used to release almost every six months a major version of Kasten. On a regular basis, we release every two weeks a new version of our product because we are capable to provide enhancement, fix bug, fix security issue, add additional features in a very fast way. So our release cycle is by default every two weeks. But for the major release, when we have a big set of new features that we want to deliver, we used to do that approximately every six months. So the 7.0 has been released in May this year. And a couple of major features that we have released, several things. On one side, we've made everything to make Kasten compliant and available for highly secured environment that could require the FIPS 140-3 compliance. So since the 7.0 release, Kasten K10 can be deployed in a such type of environment. From a cybersecurity standpoint, we released recently the support of Azure Blob with immutability enabled. We have also made the effort to integrate or to make Kasten available with Azure Sentinel from an integration standpoint. VMkasten being a Kubernetes application, you will see that there are different ways to deploy Kasten. Basically on one side, there is an mChart, which is the standard method of deployment for Kubernetes platform. But also in the specific case of Red Hat OpenShift, we've created an operator to deploy the application. And for customers that would like to deploy from the mChart perspective, we have added additional security mechanism to make sure that you will deploy the right image and make sure there won't be any unexpected images that could be injected during the initial deployment. Now, thinking about Red Hat OpenShift, it's probably one of the platform where we can see the most VMkasten deployments. So we pay specific attention in supporting Red Hat OpenShift in many different ways. So we added also recently with the 7.0 release, some additional features. One of the big one that is there since quite a long time, but we've provided an instrument and additional features over time is the support of OpenShift virtualization. If you are not familiar with that, OpenShift virtualization is simply the way to not only run regular cloud native application on OpenShift, but also virtual machines. Running virtual machines on top of OpenShift requires specific integrations and make sure that Kasten will understand that when we are going to back up a VM, maybe we will need to take care about some specific object or configuration or settings that are not there on a regular basis with a standard cloud native application. So we've made all the integration and everything that is required to properly support OpenShift virtualization. Recently, we've added also the support of ImageStream. So once again, principle of ImageStream is a kind of registry that is embedded into OpenShift. And when we back up an application, now we're also capable to back up the images that could be hosted in the ImageStream. And in that case, when it comes the moment to restore, if for whatever the reason the image or the image is not available in ImageStream, we will be capable to restore the image and make sure that the restart process will work properly in a such scenario. Few things in addition, recently we've announced a quite important partnership with Microsoft Azure. And from that perspective, recently we released Kasten in the Azure Marketplace. And one of the things that is interesting is you can procure or purchase or buy Kasten through the Azure Marketplace, eventually using your Azure credit. And as well, when it comes to deploy Kasten into the public cloud, we are capable to provide a specific billing model. So in that case, we are capable to charge you on the number of worker nodes you are going to consume per hour. So the licensing model of Kasten is based on the number of worker nodes that you have in a given cluster. And if you need to leverage the public cloud for the scalability, and if you have a huge spike for a couple of hours in your cluster, you will be capable to pay Kasten just for the few hours based on the number of worker nodes that you will consume. So this is something that is new on Azure. It was already available in the past on the other hyperscalers, but we've added that capabilities with Microsoft Azure. And when it comes to recover, we've improved many embedded mechanism related to the way we can operate the disaster recovery for the Kasten application itself, and the way customers that could already use Veeam Backup for their virtual machines environment, we are going to very rapidly leverage an existing VBR repository and recover very fast the persistent volume that could be offloaded on the VBR repository towards the Kubernetes environment. Now it's time for the demo. So the context for the demo is going to be on the Red Hat OpenShift. I'm going to use two different environments with Red Hat OpenShift. On one side, I will get an OpenShift environment running on Azure, and on the other side, I'm going to use Red Hat OpenShift on AWS, so the ROSA service, which is the managed offering for OpenShift provided by AWS and the Red Hat. The objective is to back up two different type of workloads. I'm going to make the focus on the simplicity and the way we can easily backup and migrate applications. As I mentioned to you before, one of the hottest topic right now with OpenShift is the support of OpenShift virtualization. As you can probably see on the market, there is a lot of discussions and topics ongoing about alternatives to VMware, Red Hat OpenShift virtualization is one of them. The good thing is that in the specific case of ROSA. ROSA, OpenShift virtualization is available on AWS. The specific requirement for that use case is the requirement for getting bar metal server because you will need to use some specific instruction from the CPU to enable the virtualization function in OpenShift. Because there is a dedicated bar metal server offering on AWS, you can leverage that through the ROSA offering to enable OpenShift virtualization if you want to keep all the workloads on the same platform with the same operational model. By deploying more and more stateful workload with bigger data sets and especially when it comes to deploy also virtual machines, one of the challenges when it comes to backup and protect those workloads is the volume of the data. The volumes are getting bigger and bigger and in order to make that sustainable on the long term, it's very important to figure out a mechanism to make the backup and especially the backup windows more and more efficient. So there is something that is very common for virtual machines that are the change block tracking feature to optimize the volume of the data that you are going to transport during a backup phase. And that change block tracking is something that is also available from an API perspective with AWS EBS, which is a storage service that ROSA is going to use. And Vmcast did the integration that was required to properly interact with EBS and leverage the change block tracking exposed by EBS. So from that perspective, the first backup, especially in the case of virtual machine, even though it's not the only use case, but the first backup of virtual machine will be a full backup, as you can imagine. But all the upcoming backups will be a lighter backup and we are going to leverage the CBT integration to make the other backup faster and more efficient. So let's jump on the demonstration. So my source environment, I'm just checking that I'm still connected, should be okay. So the source environment is a Red Hat OpenShift platform deployed on Azure. So in that case, I'm going to leverage the Azure Red Hat OpenShift managed service available with this hyperscaler. If you want to double check that, you can see that the infrastructure provider is Azure. And if we try to have a look on the compute nodes part of this cluster, you can see that the instance type or something that is only available on Azure as well. So what we are going to do here is basically we are going to work with a specific namespace that is called arrive-pacman. Why dash pacman? Because the application running inside this namespace is basically a pacman application. I'm going to show you this application in a few seconds. As you can see in the inventory part, we are talking about, I would say, regular cloud native applications having different type of object resources and configuration. The thing that is just a little bit special with this application is the persistent volume claim. This application, actually, if we have a look rapidly to this app, this application is actually composed by two pods, one being the front end, it's the UI, and the second one is a MongoDB database in the second pod. And because we're talking about database, we need a persistent volume to store the data. So if we have rapidly a look on the configuration of the persistent volume or the persistent volume claim, so basically the disk that is configured with this application, you can notice here that the storage class, the storage provider for this volume is something called managed-csi. And actually, it's a storage class provided by Azure. So if we have a quick look to this application, it's actually this one, a basic pacman video game. And what I would like to show you is with this application, we have a small database that will be there to record the different score that you could do by doing several games. And if I have a look to the high score tab, you will see that there is a table with a couple of players that have already played, and you will see the score here. So when it comes to backup and restore this application, one of the checks that we will have to do is to make sure that once the backup, once this application will be restored, the database will be properly restored, and we should be capable to see again this table with the ranking of the different players. So let's go with the first part of the demo. So this is the custom application that is already deployed on the OpenShift cluster running in Azure. So I'm going to go on this application. You can see the application view and the policy view. If I try to get a quick look at the application view, you will see once again this ARRIVE PACMAN namespace. If I click on the name of that application, you will get a very easy way to see and observe the different components and the different resources that are deployed inside this namespace. So this is once again to show you that there is nothing complex in operating a solution like Vmkasten. Even though you are not familiar with Kubernetes, it's pretty straightforward. So the first action that we want to do is to protect this application. So in order to protect this app, we need to create a policy. So of course, I've created beforehand the policy that is going to backup this ARRIVE PACMAN. So if we have a quick look at this application, at this could be on an hourly basis, it could be on a daily basis. So for instance, you could decide if you want to backup every day at 2 a.m. this application. Eventually, if you want to get a bit more aggressive backup frequency, you could decide to run and execute this policy every 30 minutes, as an example. In the specific case of this demonstration, I'm going to trigger on-demand manually this policy. This is going to generate the backup that will remain inside the source environment, inside the OpenShift cluster in Azure. And of course, we would like to get a copy of that backup offloaded on an external storage repository. So I'm going to use something that we call the location profile that is actually an AWS F3 bucket. And we are going to offload from Azure to AWS a copy of that backup to secure the backup outside of the production environment. Then if you want to select the applications that you would like to cover with a policy, it's pretty straightforward. You can do it from the UI just by selecting the different namespaces that you want to protect. Or if you want something a bit more dynamic and easy to are going to capture all the resources inside a namespace. But if you want to be a bit more specific, you will see there are filters available during the backup, but also during the restore action. And you will be capable to restore a specific object within a namespace, if you want to do such action. In my case, I'm going to backup everything. I'm going to skip the other settings, but the idea was just to give you a quick overview about what a policy looks like and how simple it is to set up and configure a policy. And because everything we do from the UI, actually it's available also through the Kubernetes API. So you can extract, for instance, the definition of a policy in a YAML format. And if you want to automate any type of actions, it will be pretty straightforward because at the end of the day, it will be just a bunch of OC type of actions or kubectl actions, depending on the platform where you are. So now let's run this policy and see how it goes. Let's do this, this, this. Okay. All right. And let's click on continue. So if we go back on the main dashboard and give a couple of seconds, we can see that the Rosa Rabinow-Packman policy is going to run in a few seconds. Here we go. Now you can see that the backup is running. It's ongoing. And once the backup will be done, then Vimkasten will create an export and offload this export on this external AWS S3 bucket that we are going to use for the purpose of this demonstration. Okay. So the backup and export is going to take maybe two minutes. So in the meantime, let's just have a quick look at what I've briefly covered as a location profile. Location profile is simply a set of settings that will allow you to connect to an external storage repository. So for this demonstration, I'm just using and consuming an AWS S3 bucket. By default, when you set up this, you need to provide the access key and the secret key, a bunch of additional features. In my case, I'm going to leverage also the object locking API provided by AWS S3 to make sure that my bucket will be immutable. Okay. And obviously you can leverage the other storage services provided by the different hyperscalers. If you're on-premise, you can use any type of object storage that will expose an S3 compatible API. And also if you're a Veeam customer or having already VBR, you will be capable to leverage the Veeam repository as well. Let's go back on the main UI. I think that the backup and the export is still running. Let's have a quick look. Okay. So the backup is done successfully and now Veeamkasten is working on the export. In the meantime, just to give the time for Veeamkasten to do the export, let's have a look to the second environment that we have for this demonstration. So let me just refresh the page. This time, as I've explained before, we are going to leverage the Red Hat OpenShift service on AWS. So this is a ROSA cluster. You can see as well that the infrastructure provider is AWS. If you have a quick look on the compute nodes, it's pretty much the same thing. We're going to use a bar metal instances from AWS as well. And on this cluster, actually, we are going to have a look to a specific workload, which is virtual machines. As I told you before, by using the Red Hat OpenShift virtualization, you are capable to run virtual machine on top of a Kubernetes environment. So I've deployed for this demonstration a very simple CentOS VM. And from the management console of OpenShift, you can get access to this virtual machine like with most of the other virtual infrastructure on the market right now. And basically, you can operate and get access to this VM. So I'm going to do something very simple for this demo. I'm going just to open a file that I've prepared. So I've created this very simple text file just to show you that you can operate very easily a VM on OpenShift. And I'm going just to do an additional change to this file. And then I'm going to save this file. Okay. All right. If I try to just very rapidly have a look, you can see that the change has been properly saved, additional change for this VM. And now the objective on the second environment is to show you how from a Vimcast-N perspective, you can backup and restore such type of workload that is just slightly different from a regular, I would say, cloud-native application. So now we are once again on the Vimcast-N management console, but this time on the ROSA cluster. So we have 100 applications running right now. The namespace that we are going to look at is the demo-vm namespace. If I click on this one, you can see that from a workload perspective, there is especially one, which is the santos-vm. And the type of workload, is a little bit different in that case, because it's a virtual machine. So once again, from a discovery perspective, Vimcast-N is capable to discover absolutely any type of applications running on top of OpenShift in that specific case. So what do we want to do right now is simply try to backup this virtual machine running on OpenShift. So I've created already specific policy, like the one we just saw previously. If we try to have a quick look to this policy, it's pretty much the same thing from a setting perspective. So it doesn't make any difference if the namespace that we're going to backup hosts VMs or, I would say, more regular pods, but the setting from a policy perspective is absolutely the same. I'm going to run this on-demand. I'm going to leverage I'm going to leverage the same location profile as before. I'm going to select the demo-vm namespace. But it could have been any other namespace as well. And the other settings, by default, are pretty much the same. OK? So let's run this policy and see how it goes. Here we go. So let's go back on the main dashboard. As you can see, the OpenShift, the ocpv-demo policy is running right now. And same thing as before, vmkasten is going to back up, create a local backup for that virtual machine and that specific namespace. And then we are going to generate the export and offload that on our AWS F3 bucket. OK? So once again, it's going to take two to three minutes to execute those operations. So let's go back on the backup and the export of our Pacman application. So if I go back here on my source environment, which is my OpenShift cluster on Azure, I can see that the backup has been done successfully. And same thing for the exports. OK? So right now, at this stage, I have a local backup for my Pacman application and a copy of that local backup available on my AWS F3 bucket. So now it's done. Something that could be interesting eventually is to try if we can import that backup from this AWS F3 bucket to my ROSA cluster and try to restore this Pacman application on my ROSA cluster. In that case, I'm going to change completely the type of cloud and the type of infrastructure where I would like to run my application. So if I go back on my ROSA cluster and try to have a quick look on the project view, I'm going to see that right now there is no ARRIVE H-Pacman namespace available right now. So coming back on the VMCasten console running on my ROSA cluster, I can go back in the policy view and now try to set up another policy, this time that will operate an import action. And the objective for us is to try to import a restore point that is right now available on the ROSA, the AWS F3 bucket that I'm going to use for this demonstration. So this bucket is absolutely the same that is used by the OpenShift platform running on Azure and the ROSA cluster running on AWS. So the import policy is very simple. You just need to select the import policy. Once again, this time I'm going to run the policy on demand. And that's it. Just to make sure I'm going to select the right restore points, I've prepared and done before the demo. There is just an inclusion key that you can fetch from the source environment and that you can add on the import policy to make sure that the restore point that you are going to select is exactly this one and make sure that during the import process we'll be capable to open and look at all the things that are available into this restore point. So let's run the import policy. So you can see that the OCPV policy is still running. And in the meantime, we are going to operate the import action. We are going to execute the import action. This one is very fast because it's just about having the reference of that restore point available on our S3 bucket inside the Vimcast 10 application running on our ROSA cluster. So at this stage, we don't move any data. It's just about getting access to this restore point remotely. So now it's done. Let's try to restore this Pacman application, but this time on our ROSA cluster. So in order to do that, I can go back in the application view and still notice that right now there is no ARRIVE PACMAN namespace available yet. So I can just navigate in the management console of Cast 10 and go inside the removed view. By going inside the removed view, I can get access to the restore points that I have already imported but not yet restored on this destination environment. So as you can see, the status is imported. And if I click here, I have access to the restore function. So by getting access to the restore function, I can see all the restore points available for this application. And if I try to use the last one, the one that we have created just a few minutes ago, I can click on this restore point and get access to the configuration panel to see the way and define the way I would like to restore my Pacman application. So by default, I could decide to restore this application in a specific namespace that could be already created or pre-deployed on my ROSA environment. In my case, I don't want to do that because if I scroll down in the UI, I can see all the content available into the restore points that I'm going to use. So as you can see here, we can see that there is the persistent volume from the MongoDB pod that we saw just before in the source environment. And you will see all the other resources that were there in the namespace when we did the backup before. And you can also notice here that there is indeed the namespace resource with, of course, the name that we have at the source environment. So we are going to leverage this object during the restore process to recreate the namespace first and then restore the rest of the application. Now there is one challenge that we have to deal with. Keep in mind that this backup and this application comes from an OpenShift cluster running on the Azure. So basically, there are two things that we have to deal with. On one side, the storage class, the storage service that we would like to use during this restore process. I told you before that the managed CSI storage class is something coming from Azure. And obviously, we won't get the same storage class on AWS. So we need to find a way to reconfigure the persistent volume claim, the PVC, to consumer storage class that will be available on AWS. And the second point is the networking access, the route or the URL that we are going to use to verify the access to this Pacman application. We are going to change and we need to change the URL to leverage the networking access services available on AWS. So those are the two things that we need to manage during the restore process. So in order to do that, we can leverage the transformation engine that is available on the Vimkasten platform. And I have created in advanced two specific transform actions. One that is going to change the name of the storage class in the definition of the PVC. And the second one that will let the route that will be restored by Kasten to fetch the proper DNS name from the Rosa cluster on AWS. So those transformation steps being already created, I can just link those different transformations to my restore process, okay? So I'm going to add the first transform about the change for the route. And the second one that will operate the transformation or the reconfiguration of my PVC. Now I am almost ready to restore. There was one last change that I would like to set up. The thing that I want to exclude from the restore process is the definition of the storage class. If I try to crawl down up to the end, part of my restore point, I have the definition of the storage class coming from Azure. Of course, because I'm going to restore on AWS, it doesn't make any sense to restore the definition of that storage class on AWS. So now we are ready and we can restore this Pacman application and see how it works. So let's click on the restore. Here we go. I'm going to go back on the main dashboard of my Kasten application running on my Rosa cluster. You can see that the restore action is now ongoing. So we are going to recreate the namespace and then restore all the components and the pods and redeploy everything. And during that process, we are going to operate those two transformations. One for the storage class in the PVC and the other one to reconfigure the route in order to get access to this application at the end. So if you want to observe things happening during the restore process, once again, I'm still on my Rosa cluster, you can see now that the namespace has been already restored. And if I try to have a look in the workloads view, we are going to change the scope to the arrive Pacman namespace. In a couple of seconds, one minute, something like that, we will start seeing the different pods being created and being deployed into the Pacman namespace. So let's go back on the Vimcasten UI. We can still see that the restore process is ongoing and it's progressing for the moment. If we go back on OpenShift, here we go. We can now start seeing the first pod, which is the UI, the front end of the Pacman application. And we can see that the Pacman MongoDB workload is going to be redeployed. Now it's running, the status is okay, the status is running. If we want to try to check if everything is okay, we can go in the storage view, have a look at the persistent volume claim view. So we can see that the PVC has been apparently properly restored, at least it's bound. And if we look at the storage class, instead of having managed CSI, now we can see that the storage class is different. We are using the storage class provided or available on AWS. That's one thing. If we go on the networking view and try to check if we have a route for the Pacman application, we can notice that yes, indeed, we have a route. And apparently we have the link to get access to this application. So let's click on this. And here we go. Now we have access to our Pacman application, but this time running on our ROSA cluster in AWS. And if I try to get a look to the high score table, once again, you will see that apparently the databases has been properly backed up and we have the table with all the high scores made by the different players. If I try to go back and try to run this application, you can see that it's working. So that's fine. The backup and especially the restore, has been operated properly. Last check before we end the session. We tried during that migration of the Pacman application to backup and export as well a virtual machine running on our ROSA cluster. So if we go back on the policy, you can see that apparently everything is green. So everything is okay. And yes, indeed, the backup has been done properly and the export as well. Okay. So it was for me the way to demonstrate to you that no matter what type of workload you need to run on Red Hat OpenShift, it could be a traditional or regular cloud native application, or it could be a virtual machine running in a namespace. With VMCasten, it's completely seamless and it's simple in both case to properly protect those workloads. So this is the end of the session and the end of the demonstration. I'm just going to try to have a look to the chat and see if there are questions in the chat. Right now, I don't see any question in the chat. I hope the presentation and the demonstration was clear enough for you. If you want to dig into the product and the solution, keep in mind that if you want to deploy Kasten on Red Hat OpenShift, there is, I'm going to switch to the Kasten-ion namespace. We have a specific operator that is available on the operator hub of Red Hat, where from which we can easily deploy Kasten. And so basically this operator is going to handle for you the initial deployment and all the upcoming upgrades and basically the lifecycle management of the Kasten K10 application. The deployment via the operator is available also for environment that are in air-gapped environment. Same thing, if you prefer to deploy Kasten by using the mChart, you could be on connected or air-gapped environment. In both cases, you will be capable to install the solution. I hope you enjoyed the session. I believe there is no... particular question in the chat. Feel free to try and test the solution. For all the technical details that could be interesting for you, some additional links, the Kasten documentation is available. If you go on docs.kasten.io, you will get access to all the documentation of Kasten. If you're interested to see the different way you can install, set up, and operate the product, everything is there. And an additional, this one, vmkasten.dev, it's a blog that the Kasten pre-sales team and product team, we use to leverage to publish additional content on a specific use case that we use to manage and we provide our feedback on the way to properly, for instance, backup RabbitMQ or Kafka workloads that could be deployed on top of Kubernetes and on top of OpenShift. There are also some interactive demos that you can use if you're curious and if you want, for instance, try to see what the product looks like. You have demos with guided recommendation on how to navigate into the products, so feel free to leverage all those resources if you're interested by that. Thank you, everyone. I wish you a great day and I'm looking forward to talk to you in the future. Thank you, everyone.
