So, this all looks great on a PowerPoint presentation and great slide animation but what if you want to see it actually out in a real environment? So after this video, we have a recorded demo that I put together in our labs inside of VMware on campus. It's going to show everything that I portrayed inside of this deck and inside of this PowerPoint in an actual real live environment. It's not simulated and there's no behind the curtains magic that's happening. It's an actual demo of taking an application. We're going to split it between the two sites, maintain connectivity, I'll get under the hood a little bit and do some trace routing and some pinging between the two sites so you can actually see that I'm changing destinations, changing default gateways, and changing site to site connectivity and then we'll wrap it up with the full site disaster recovery failure bringing the application online in less than a few minutes. Hello and welcome to the demo. Before we begin, let's take a look at our environment. Currently, we have two data centers deploye. We have a universal distributed logical router and we have three universal logical switches deployed for our 3-tier app. Currently, we have cost based routing setup between the two sites for dynamic routing using OSPF. Our application is a simple 3-tier app with a database application and web tier. Each individual server is connected to its own universal logical switch. Now, let's take a look at the running application. Here's our web app. It's available in online and ready to be used by customers. Before we begin the demo, let's do a little bit of environmental checking. Let's first ping the application to make sure that it's responding with the correct IP address. As we can see here, it's responding with 10.114.220.2. Now, this is important because we're going to maintain that same IP address as the machines are filled over to the secondary side. Now if we do a trace route on the application, we can see that it's using that 212.198 and 220.26 IP addresses. These are the IP addresses of the primary site ESG northbound interface and the leaf IP address for the universal distributed logical router. Currently, all north-south traffic has been handled by the primary site, ESG. Let's take a look around in the environment through our vSphere Web Client. We can see here that we have four V centers, two per site. We have dedicated management clusters and V centers on both sides and we also have a compute cluster housing our multi-tier application and we have a DR compute cluster on the secondary site. Now, let's take a look at Site Recovery Manager. We have two separate prediction groups, one for our database and one for our web and app tiers. And we also have to recovery plans. Once again, one for the database and one for the web and app tier. We have these split up so we can take the application and break it between the two sites. Now, let's simulate a partial application failure. We're going to take the web server and the application servers and we're just going to disconnect them from the network. This will bring the application down and bring the machines offline from the network. The reason we're doing this is to show that we're going to maintain the same IP address for all the machines as they are recovered to the secondary site. Now let's ping our application. We can see that now it's currently offline. If we return to our vSphere Web Client and navigate to the Site Recovery Manager, recovery plans, we can now begin the recovery of the web and application tier. And for the purposes of this demo, we're going to be doing this manually but keep in mind this can be fully automated. If any piece of the application fails, that can be recovered automatically. We can see now that site recovery manager has completed the application recovery and now our app is background line running on the secondary site. It maintained the same IP address that it had on the primary site and we can see here that it's still using the primary site, ESG, and the primary site, LIF IP address, from the UDLR. Currently, the East-West traffic is handled by the UDLR while maintaining ingress and egress traffic through the primary site ESG. Now, let's go through and simulate an entire site outage. First, we're going to do the same thing by taking the database server and disconnecting it from the network bringing it offline application. And we're going to allow Site Recovery Manager to recover that tier of the application. We've gone ahead and sped this up for the purpose of the demo as the database tier takes a little bit of time. Now, to make sure that the site is no longer available, we're going to navigate to the primary site perimeter ESG and we're going to disconnect the northbound interface that was currently being advertised as a route. The 212.198 interface will not be taken offline. We can see here now that if we ping the application, it's broken. That's because we have all of the traffic being routed over the primary site ESG. Let's go and fix that. We're going to go navigate now to the recovery site cluster and we're going to change its locale ID back to the original recovery site locale ID. What this will do is allow any running VM's, recovered or consistent, begin to use the local sites ESG for ingress and egress traffic. Once the locale ID is updated, we can immediately see that the new routes have been advertised and that the site and the application is now back online. If we do a trace route on the application, we can see that it's now using the secondary site ESG and the secondary site LIF IP address, the 208.86 and the 220.34 IP address. We've now done a partial application fail over maintaining north-south traffic to the primary site, and we've now done a complete site failure recovering the entire application and then also recovering the ingress and egress traffic to the primary site interface. Thank you very much for watching. In part two of this demo, we're going to show a complete site failure and recovery using dynamic routing only. First, let's look at our sites. As you can see our primary site has a cost weight of one for its primary route and site two has a cost of ten for its primary route. Pinging the application, we can see that it is online available and using the same IP address as before. Doing a trace route on the application will show and verify that we're currently using the 2.12.198 IP address as the primary route for this application. Now, let's bring our application and our site down. First off, we're going to take all of our VMs offline. This includes the application server, the database server, and the web server. We're just going to disconnect them from the network for purposes of this demo but we're basically simulating a complete application failure. Now, let's simulate a network outage as well. We're going to navigate to the primary site ESG and go ahead and disconnect its main up link from the network. Doing this allows us to show that we've taken down not only the entire application but the network as well and those routes are no longer available on the primary side. Once again, we're going manually kickoff the recovery plans in SRM. Keep in mind that this can be fully automated if the site did completely go down. But for purposes of this demo, we're going to go ahead and launch them manually. And we can see here that SRM has recovered the application and our application is back online. Notice how it's using the same IP address as it originally did on the primary site. But if we do a trace route on the application, we see here that it is now using the new route that has been advertised from our recovery site. Now, the old route is no longer being advertised. Let's test our application in the web browser. We can see that it's fully recovered and online and ready for use. Thank you very much.
