foreign[Music]organizations have a core Mission which is backed by one or more Mission critical applications that need to be always operational as these Mission critical applications are containerized the need for a business continuity solution takes strategic importance while kubernetes offers Auto healing for failures within the cluster it doesn't handle cluster-wide disasters to add to that the typical manual operations that have been employed to recover traditional monolithic applications do not hold good for microservices-based kubernetes applications due to the need to protect several logical components of a kubernetes application for applications and kubernetes what should an ideal BCD or plan deliver quite simple we wanted to deliver business continuity with minimal downtime and we also want a simple to use kubernetes native solution that is built on a trusted and proven replication technology now what if we combine both these expectations into one solution netapp's Astro control now leverages snap mirror technology to bring a fully automated Dr solution for cloud native applications with a custom defined RPO while delivering RTO in minutes let's first go backstage and understand how Astro control orchestrates the entire bcdr workflow we will start with two kubernetes clusters I have one running in India this will be a production cluster and another cluster running in the United States which will be RDR cluster each kubernetes cluster has its own NetApp all flash fast storage system delivering persistent storage to the applications an instance of Astra control center is managing both these kubernetes clusters to set up a Dr solution for applications on these clusters we perform a one-time operation of peering both the storage systems a hack an e-commerce application in the India cluster through which I am selling anti-goods antiques are expensive and I need to deal with high value transactions that I cannot afford to go wrong with on implementing a Dr plan for my antique store Astro control automatically creates PVCs with equivalent attributes at the Dr site and sets up a snapper relationship between the source and the destination storage systems the data is incrementally replicated from the source to the destination based on the user defined RPO interval at the same interval the application metadata is also repeatedly captured by Astro control from the kubernetes cluster in case of a disaster or a need to fail over the application the user just needs to click a button in the back end the snap Arrow replication is stopped the volumes in the Dr site are promoted that is made available for read write access a copy of the application is rebuilt on the Dr kubernetes cluster using the latest metadata information from the Lost RPO window and the PVCs in the Dr site the application admin can now redirect client traffic to the application instance that is running in the Dr site the ball doesn't stop rolling there Astro control also provides workflows to resync the data between the two sites after recovering from the outage and to fail back to the production side to restore the original roles of the two sites we will look at a couple of these workflows now let's get into Astro control we have two kubernetes clusters India kubernetes cluster and USA kubernetes cluster we have two backends India ontap and USA ontap that are connected to the respective kubernetes platforms from the application section we can see my antique store running on the India cluster let me click on the application and head to the resources tab here we see all the kubernetes resources that constitute the applicationmoving to the storage section we can see two persistent volume claims and the associated persistent volumes that are used by the application now head to the data protection section I will select replication and click configure application policy I will choose my cluster in USA as the Dr location select the storage class to be used for the volumes in the Dr site replication type will be asynchronous and I will create a new namespace and the Dr kubernetes cluster for this application the replication frequency is 5 minutes this is our RPO the offset is left at default and in the next step we confirm the replication of the antique store application to us the replication begins straight away and after a few minutes the status changes to established now from NetApp System Manager we can see the snap mirror replication relationships configured automatically for the two persistent volumes we saw earlier now in my antique store one of my customers places an order for a gramophone costing 12 000 US Dollars and chooses direct bank transfer as the mode of payment the order is placed from the admin view we connect to the back end and can see a record in the order section the status of the order is on hold I will go ahead and change the status to pending payment as I'm yet to receive the funds via bank transfer a step away for a coffee and when I return my application is not responsive anymore this could be due to a partial outage of some services in my data center in India or could be the onset of total outage as well either way my application is not responsive but I need to process my orders and keep my store up and running enter Astro control we see that the India cluster is unavailable and in the application section we see that the antique store application is also unavailable let's click on the replicated instance of the application in the replication relationship we see that the source is also unavailable let's click on the three dots and choose failover and confirm the action the application and its operation will Now fail over to the kubernetes cluster in USA since the data of my application is already replicated to the data center in US my application is brought up and running in the U.S site in a matter of few minutes let's connect to the US kubernetes cluster to view the application should be created within the antique store Dr namespace that was specified we see that the parts of the application are running a service has been created to expose this application the PVCs have been created to provide the required persistent storage for this replicated instance of the application let us connect to the application by logging in as the admin we see the order that was placed and its status is payment pending this was the same state of the application when we had an outage in the India Data Center and we've been able to recover it within a few minutes and continue with our operations straight away from the US cluster this is our one-click Dr solution with Astro control moving forward my customer has made the payment and have delivered the product so we go ahead and update the status to complete it and my application continues to run from the usdr site now didn't that look easy and straightforward I bet we just did something remarkable in a few minutes in a manual approach this would have taken at least a few hours to fix without an assurance for resuming operations after all the time and effort let's summarize what we have seen we Traverse the Dr failover workflow for containerized applications all in a fully automated fashion we can manage our bcdr plans at an application Level granularity with varying rpos some applications may need a five minute RPO while some may need an hour it's not a one-size-fits-all approach and we cater to it all significant reduction in RTO this is a game changer the key here is NetApp snap mirror that ensures the data is already replicated to the secondary site and the application can be reconstructed in a matter of minutes I can confidently say that this new capability from NetApp Astra control is a game changer for all machine critical applications running in a cloud native format do note that this capability extends seamlessly to a hybrid Cloud implementation as well across all major hyperscalers for most such videos on NetApp Astra please scan the QR code on the top right and I look forward to seeing you on another demo very soon thank you [Music]