 Just realize there is a balcony view too I did not know otherwise I would have sat there. So I am Pracheta, I am going to talk about how you can build a robust system for DR, right. But before I get start I would like to ask couple of questions, one I am presuming that everybody understand what is DR disaster recovery and it differs from what is HA which is high availability, yeah. We all have that basic understanding because I have got just 20 minutes I am not going to introduce disaster recovery, it is different than you know high availability and that is what we are going to go capture. Now another question that relates to that is how many of you have a DR solution in place, okay, some 20 percent, yeah, yeah there is, is it better now, no, there is static, okay give me a hand by that is okay but when I will be using it will be a challenge, is it, there is lot of static, yeah. Let me, let me keep it in my hand probably it was a pocket, okay. So some 20 percent of you said you have disaster recovery, now I truly believe that it does not mean that 80 percent of you do not require a disaster recovery solution, right, yes and no, yeah. Why do we need it because they can always things that can go wrong in your primary data center where you host everything and which is dear to you and yeah, you know with the whole power grid goes off or there is a God forbid tsunami hits or something or the other, right. So while you build for high availability, your application database is middleware always run, it is also important to build for disaster recovery at least for your critical workloads. Now those of you who said that you have DR in place, let me understand what is the good percentage of workloads that made to that DR, which means are you 100 percent workloads are available on the DR side, not really right, probably it is 20-30 percent of it because DRs is supposed to be costly and complex, are you guys with me, yes. So what about others, you know the 80 percent of you who have not really taken the next step to look at DR, chances could be maybe you started 2 years ago or 5 years ago and you know, you have not thought about it or it could be, yeah, it requires you know, some money behind it to really build another site and have things ready. Now while we go, while I am going to talk about a complete DR scenario, there are there can always be situation where you can achieve something partially as well, okay. I think by looking at the show of hands, I think what I have tried to build in the slide will absolutely make sense to you guys. Let us get started with this, life would have been absolutely wonderful and I wish that you know, time will come when we have recovery on press of a button, right, but that is not the case. It really requires planning, it really requires understanding of your infrastructure and then build solutions based on that. Now when it comes to disaster recovery, there is one thing which is very, there is a misnomer and many a times I have seen people using a DR as a synonymous to backup, people using DR as a synonymous to high availability, that is not, right. So while in high availability, you expect your application services to be running all the time, honestly 5 nines are also passed, today is the world of continuous availability, you just do not want your application to go down and it is possible there are tools that will allow you to do that, that means your application always run whatever fails, they can just you know run another node or another system, that is about it. Whereas backup is about you keep on taking backups and you can restore from them in case something you know really catastrophic happens and HA completely goes for a toss over, right, but DR is a little different, of course it has to be a backup, of course it has to be high availability to keep operations running, but DR is something that does not happen every month, every quarter or God forbid it should not happen even in years, but that is like your good medical insurance policy, you do not want to meet accidents ever, but you want to be covered all the time, what happens when that happens, right. So let us get started, where to get start, right, that is a question I get a lot from customers of all sizes, you know you might be a big enterprises with 100,000 users or you might be a small organization just 50 of you, you know this is always a question, if I have to get started where to get start, so good day, good time to get started, but yes it was yesterday, but today is also very good time to get started. So let us see what are the some basic things that have to keep in mind while you think about DR and how you plan your DR, okay, these are the four steps in my mind, of course there is a lot of process, high level basis you need to really understand, what is the scope of your DR, are your, let us say you have got a 100 node cluster, let us say it is a very big cluster, right, so you know you have got 10 clusters which are let us say 5 node each or something or the other, do you really want to build a DR for all of them or do you want to segregate and find out which is the most critical in component in your organization and you want to build a DR for that, because what happens in DR, you have to resources at some other end, which is not the same data center, right, so in, in yesterday time, yesterday years or let us say 5 years ago, the only way to build a DR was to have a DR site, another site which is 200 kilometers, 500 whatever kilometers away and you have some compute there, you have a small data center, a bunch of machines there, just you know a replica or copy of your live running in, so that you can switch over whenever there is a catastrophic, you know, incident, times have changed with cloud everything has changed, so you know I'll little bit touch about how you can go with the traditional way or you can look at something which is you know easy to achieve in this easy gratification time, we really don't have time to, you know, spend two months in planning etc, can you quickly do it, we'll talk about that as well, but really, really start with understanding, you know, your scope, what are resources you really want to be under this DR policy, think about your requirement and strategy, do as I said, I don't want to go into too many details about it because this can look very, very, you know, time consuming process itself, but this is the right way of doing it, you can skip couple of them, but yeah, this is a good flow towards started, understand, you know, what is the business impact it's going to have, if you're going to build a DR, do you have funds for it, you have IT budgets for it and so on and so forth, of course they implement it and a very, very important part about it is testing. I have seen a lot of organizations who have DR plans, till the time DR really happened, yeah, so when it happened, it just didn't come up on the DR side, why? Because it was not tested often. We all dread of unknowns, we really, really don't want to try out what if things fail, but the point is today we are building for disasters, what if, I think in the morning somebody spoke about Simben Army, you know, that is the world we are living in, we really want to build systems that can, that can absolutely sail through any kinds of disturbances. So, let's have a very high level architecture on basis of which I want to build. So typically, you have a, you know, premises, data center, it could be your own data center or you have a co-location data center, wherever you host your host DMs, nodes, et cetera, wherever you have your machines, so you may have some physical one, mostly nowadays everybody has virtual machines, right, or you might have containers, dockers, et cetera. So you have got a primary site, now the point is, the first thing is to establish a DR site. Now where this DR site is going to be, by the virtue of so many few things today, that is in your hand to sort of decide, you can choose to have a DR site in this Bangalore, it could be a Chennai for you or it could be a Coimbatore or wherever or you can go ahead and choose to put a DR site on the cloud, which means you don't want to invest into another data center, you can choose to make one of the clouds your data center. Now what is very, very important to have a look at, I'm not getting into what all tools you can use, maybe towards the end of the talk, but the point is the basics remain, you need to identify what all workloads should go there, how my data is going to be synchronized, because the most important piece of the puzzle is data synchronization and application consistency, isn't it? I can definitely bring up a system on the other side, but what if the application doesn't load the way it is supposed to be, or there is some discrepancy in my database, yeah? So it's very, very critical and that's the reason why a lot of organizations don't attempt it. But it's very important to look at it if you feel that your business applications are really need to keep on working. Now in this case, this data channel could be anything if you have got sand on the primary site, you want to do sand level replication, you can choose to do that, or you can use a network channel to do the replication. In some cases questions come how do I replicate so much of data, I might have terabytes, petabytes of data, how do I sync it for the first time on DR side? So typically use offline method where you copy everything in big hard disk, bring it to your Chennai site or whatever is a DR site, load it first and then do a sync replication over the network that should be pretty straightforward. DR as a service, so as I said, now it's possible for you to not only build DR the traditional way, you can also leverage something called as DR as a service. Essentially what it means, you can look at a cloud provider who will host the VMs for you and you know, in a stage in a sync fashion, whenever disaster strikes on your primary site, those critical machines will come to life on the cloud platform, right? So while a lot of organized, this is 2014 report for Forrester and it is it is growing up. While a lot of organizations are looking at it, one, I do not have such a big infrastructure to really invest into another site and have cooling and all those racks and and build servers, it doesn't doesn't make sense to me. So probably I'll just have those identified workloads to have a DR on the cloud. For others, I have seen, you know, couple of organizations where they're really, really finicky about DR. So they do have a primary site, then second DR site, and then they do a triple DR. So for the extra important, the star applications, they go ahead and put up do a DR from a DR to cloud. You know, that's like extra protection. So the point is, it makes sense. So probably you want to explore any traditional way of doing DR or DR as a service. Now let's get to the some house of it, you know, what all you need to keep in mind. And that is really, really essential for DR planning. First of all, I wanted to introduce this seven tiers, which share is a standard in the DR world, the seven stages in which your workloads can reside. Now, or probably I would maybe a better way to put it is to categorize your application in data into various tiers. Probably, of course, your test and dev is not a critical workload if it goes down for four hours or you know, maybe if there is a catastrophic situation, probably it's all right. But let's take an example of Chennai flood, a lot of organization who did not have DR were absolutely shut down for days, right? So first of all, it's very important to categorize your data, I have colored them so tiers 012 are primarily just taking backups, which means if you are not taking backup, if this is various levels of taking backup, you have a backup as well as a hot site. What is a hot site? A place where you can restore backup if your primary site goes down, right? Somewhere where you can restore typically what happens you take backups, and you assume that when I have to restore backup, I will have my primary site with me to restore it back. But if disaster really happens and you cannot access your data center for days, then you have to have another site somewhere where you can go ahead and restore those backups, right? A second category is, you know, more to do with electronic disk based backup where you go ahead and quickly restore data without any loss. Okay, now this is actually more to do with real DR, where there is almost no data loss and the point of recovery is very, very fast. Please understand, we are talking about disasters, right? When power grid flailed or when there is earthquake, where the system cannot be accessed manually over the net, your, you know, fibre cables are cut, then the then we are talking about, you know, these disaster site. So what is more important? I will skip in the interest of time. Another thing that you should keep in mind is how you want to keep it. If it is a very important workload, probably you not only want to do it locally, in some other city, you also want to look at another geography or continent altogether if it is really, really important to you. You go ahead, I'll share these slides, but the point is, you think about whether you want to fail over to be manual or completely automatic. Of course, nobody's looking at manual, but sometimes people want to save cost, they don't want to invest into orchestration tools. So they just say, okay, anyways, it's a disaster. What if it takes 15 more minutes for me to bring up manually on the other side? It saves me lots of money, fair enough it works for you. Otherwise, it's a failure to think building automated DR. But one thing which is very important, where is that? Okay, I had one more slide. Okay, is it gone? It was really important. Okay, give me a second. Okay, how does that happen? Okay, anyways, forget it. I wanted to introduce this thing to you guys, I did not know whether you know it. So I thought I'll introduce it. Does everyone understand what is RTU and RPO? Yeah? Yes or no? No? No, okay, no, yes. RTU stands for recovery time object and RPO stands for recovery point object. So RTU is how much time will it take for you to recover the lost data, whether it is, it can be five minutes for some organization which say, okay, disaster really happens. I'm okay to have a data which is old by five minutes. Others it can be 30 minutes, some it can be zero minutes. Okay, recovery point object is when disaster really strikes, you cannot expect five minutes when your DR will come up, right? It may be 20 minutes, maybe 30 minutes, maybe four hours. So define your RTU and RPO. And it is a good idea to have different RTU, RPO for different set of applications, because they are different in criticality in your organization, right? So I had a slide for RTU, RPO very neatly, therefore I was looking for it. So yeah, these are the three, these are the things that are really important. There's definitely a trade off the lesser number of RTU, RPO you're looking for the costly affair it's gonna be, right? So make a call. I have typically seen the DR planning to classification is the must once you have classified, because I've seen a lot of times, people don't even classify the data. If I ask you where your high business impact data lies, you'll say you'll say probably somewhere in my data center. That's not a great answer, because you should know where exactly it reside, whether what kind of security measurements you have taken because you know, that's that's the starting point of building a resilient system. So with zero RPO, probably you are looking at a sandwich replication, etc. And of course, it's gonna be the most costly affair. Very, very, very, very, very important is to test failure. Once you have set up stuff, make sure you test it every month or at least every quarter. Typically, all these good tools nowadays allow you to do the testing of failure. What they do, they go ahead to the 99.9% of the failure simulated and then bring it back. So your DR really doesn't happen, but it's more like a drill. So make sure that you test your DR. Okay, how much time I have? Okay, I'm just gonna get to the last one. There are a lot of DR as a service provider. Of course, there are, these guys also provide DR solutions, because typically you need some logic to go ahead and keep on pinging your primary and secondary side. If it is DR as a service, secondary could be cloud. So I would really encourage you to, for 80% of you, if you are building your setup, if you're in the phases where the chances of you to go exponentially high on customer acquisitions and etc. It's a good time to start building your DR before it becomes a, you know, elephant in the room. So since I don't have any time, if you have any questions, probably I can take one question. No, okay, very rude. Okay, I'll be around. You can ask questions if you have any. Thank you.