Now, let's talk about NSX and SRM and how to make DR successful with the two technologies today. Now, everything that's going to be required is vSphere 6.0 and above, NSX 6.2 and above, requires SRM 6.0 or higher, and you can also have other DR orchestrator as well, SRM doesn't necessarily have to be the key player in it but NSX and SRM have tight product integration and then some storage replication, whether it be vSphere replication or Array-based replication. So, let's look at cross-VC NSX with SRM for DR. It gives you the ability to create storage-based protection groups that does the network mapping automatically in the back-end for you. This is one of those physical human error points that I talked about earlier that when you're recovering a site, what if the networks aren't synced? What if the load balancers aren't synced? What if your IP subnet isn't available in the secondary site? When you create a DR plan using a storage-based protection group, SRM automatically goes in and automatically identifies all of your universal logical switches and maps them together in the back-end for you, removing one of the components that is usually a high error point when it comes to disaster recovery. Now, NSX 6.2 and above has integration into your environment in such a way that when you have implicit mapping between two sites, it really allows you to have a preserved network environment where you can reduce OpEX, you're decreasing manual labor and manual intervention and a faster recovery time by up to 40 percent on the secondary site because your network is already there. Your infrastructure as far as an IP network and IP sublayer is already there, it's readily available and it also applies risk mitigation and gives you another compliance object into the environment. Now, cross-VC NSX and a DR use case is something that we see a lot now with customers. What's nice is you don't need to re-IP anymore, because you don't have to manually map networks between the two sites. When you migrate VMs between two sites or between a primary and secondary site, you don't need to replicate the security policies. You don't need to replicate the IP addresses. When you create a security policy on the primary site, it follows it over to the secondary site. Now, let's step away from DR for just a second and talk about cross-VC vMotion and multi-site networking. What you see here is two sites that are coupled together with universal logical objects. We have a universal distributed logical switch spanning across both sides and we have three universal logical switches that are spending across both sides. Now, in this environment, whether I'm using SRM to recover the environment or I'm using cross-VC vMotion to just move my virtual machine from site A to site B, when you create a DFW rule and you apply it to virtual machines, when that VM moves to the secondary site, that universal DFW rule is still applied even if the VMs are across multiple sites. During a DR event when that virtual machine comes online on the secondary site, the universal DFW rule is still applied between the two virtual machines. Now, this is right out of the box, there's no manual intervention and there's nothing that an administrator needed to do to make sure that this rule was applied when you did across VC vMotion or SRM brought the virtual machines up automated on the secondary site. Now, enhanced disaster recovery is something that we want to be able to deploy into an STDC environment. Now, what this means is, inside of our environment, we have two separate sites. We're peering with our upstream OSPF or BGP routers, we've created our universal logical construct which is our UDLR and our ULSs, universal distributed logical router and universal logical switches, and we have our constructs set up between the two sites. SRM is deployed. We have a primary application running on site one and we have our standby application that are SRM placeholder VMs on the secondary site. Now, during a specific outage, everything will sync between the two sites. You'll see that we have the universal control cluster sinking, all of our logical routes are sinking, and currently, all of our ingress and egress is going over the primary site. Now, when there is a failure and we have to bring up that secondary site and bring up those VMs using SRM or using another automated tool, we can now control where the ingress and egress traffic is handled. It can still be handled over the primary site because you'd still need east-west adjacency for let's say a database server or you're just doing physical infrastructure maintenance on a primary site and you don't want to change the ingress and egress point or change external facing DNS records, you just want to evacuate a couple of clusters or a couple of racks so you can do some maintenance. Typically, an enhanced DR event, you don't have the entire datacenter fail, you only have a couple of virtual machines or a couple of racks fail, which in this case, allows us to reduce RTO, and bring up just the failed environment instead of having to forklift the entire infrastructure over to the secondary site. Now, in the event of an entire site failure, we're able to bring up the entire infrastructure on the secondary site, change the locale ID, which is our routing based protocol to the secondary site and immediately traffic then is restored on the ingress and egress points on that secondary site. What this does is upon a disaster recovery event, DR orchestration is automated, north-south traffic is fully restored on the secondary site. Your DFW rules are enforced and readily available in a secondary site and there's no change in IP address when you move and bring up that application. There's no manual sync and all of this can be automated fully through SRM. Now, let's talk about planned migrations and maintenance for a little bit. In this deployment, we have two sites: we have our SRM Server, we have our vCenter Server, we have an application that's deployed, we have our NSF Manager, we have our universal control cluster, our universal logical switches, and a universal distributed logical router. Now, in this scenario, what we're doing is we have a UDLR control VM that has an allow prefix on the primary side and the deny prefix on the secondary site. The reason for this is because we don't want a black hole traffic to the secondary site, we want to be able to have the routes available and advertised, but not have any traffic actually be pushed to that secondary site. Each site is currently set to the protected site or site A's locale ID which means that all routing is going to go over the primary site ESGs. Now, in the event that you want to migrate, move VMs or recover them between the two sides, you're able to take a part of that application, maintain its IP address, but still maintain north-south connectivity across the primary site. Now, this is helpful when you want to do physical infrastructure maintenance or you want to do a migration between data center one and data center two. You're able to take the entire application or individual components of the application, maintain east-west adjacency, maintain connectivity to the primary site ingress and egress entry point, but at the same time, not have to change IPs. You have the same subnet spaces, same IP space available across all sites. Now, during a complete application outage or a complete application migration or Datacenter migration, you're able to take the entire workload, move it over to the secondary site. We're going to change that UDLR prefix to deny traffic on the primary site, start allowing traffic on the secondary site. We're also going to change the locale ID back to the secondary site which will immediately restore ingress and egress traffic through the secondary site ESG. Now, all of that sounds very complex, but it's very simple to automate through SRM. It's just a couple of lines inside of your recovery plan. Now, let's talk about testing DR with SRM. This is a very important part because you can have a solid DR runbook, a solid recovery plan. But if you can't test it and you can't actually revive your application holistically in end and be able to test it in a bubble environment, then how do you know it's going to work? So, being able to test your application in a full production mirror allows you to go in and certify the environment. It lets you as the administrator, you as the product engineer to go back and tell the business we can test this. We've tested it quarterly, we've tested it monthly, and we know exactly how long it takes for the recovery, we know exactly what our RPO and RTO goals are when we bring up the environment. You're able to test the environment in a complete mirror of the production. It's fully isolated inside of the environment using what's called App isolation inside of NSX. This is right out of the box, it's minimal configuration, and it literally puts an isolation bubble around the entire environment. East-west routing and application connectivity using the NSX's DLR deployed inside of this bubble environment gives you the ability to not just bring up a flat environment, but actually test database servers connecting to web servers and connecting to App servers and gives you end-to-end testing through the environment. You're able to test using the actual production IPs, and it's non-disruptive to the running production environment. To be able to access this, we can simply deploy an Edge services gateway, create a NAT rule, we put in DNS A record on that external routable network, and now you as the application owner or your development testers are able to test this full production mirror environment from your existing production environment or from your desktop environment and actually play and test this so you can see how long it takes and you can fine tune it and really reduce RTO in this environment. Remember, it's completely non-disruptive to the production environment even when you're using the overlapping IPs that are currently in place and running your actual application in the environment. It's a real-life production simulation that is completely isolated from the rest of the network. Now, everything I've talked about sounds like it's a lot of clicking, it's a lot of manual interaction, it's actually not. All of this can be completely automated using vRO and the orchestration tools that allow you to work with SRM and NSX. Both NSX and SRM have an API driven back-end. You can use your favorite HTTP rest plug-in that allows you to communicate with both NSX and SRM, and you can do complete testing and complete validation automation using the vRO Plugins. This allows you to go in and create an automated test plan that you can run once a month, run once a quarter. It'll bring up the environment, it'll put it in the application bubble, it'll kickoff the SRM test plan, allow you to then have your A records that are accessible. Once testing is done, you reverse that vRO workflow, and then it cleans up the environment after itself. So, what are the benefits of applying NSX and SRM to disaster recovery? It decouples you from your physical environment. It decouples you from having to rely on that physical infrastructure and your networking environment. It allows you to reproduce this environment because it's virtual. Just like today, when you go and you want to deploy virtual machines, you pull it from a catalog or you pull it from a cloned template, you can now do that in your networking environment. You could pull out cloned environments with switches and routers, your load balancers, all of that can be templatized and redeployed and reproduced easily. It also gives you the networking automation that you can't traditionally do with physical environments, with physical switches, with physical routers, allowing you to go in and automate the process, removing that manual interaction with end users and administrators. So, that was a lot. Let's talk about some some final notes and summarize a little bit. So, DR automation with NSX, there are some caveats to it. Cross vC synchronizes logical networking components, L2 and L3 firewalls and your security components. VRO based automation makes site-to-site sync possible with a little bit of coding. Now, as you're watching this, I haven't really talked about edges and synchronization. Each north-south gateway or the Edge Services Gateway is independent to each site. So we don't synchronize that. You can automate that in the back-end or you can do a backup and restore between the two sites, but as far as the logical networking components go, the Edge Services Gateways are independent to each site. Now, what happens when the NSX components fail? You're able to automate that recovery using APIs and be able to kick that up through SRM runbooks. Remember, when the NSX components fail, it does not give any outage or impact data plane connectivity, it just puts you into a read-only environment where you can't change or modify logical switches or logical routing components. So, some of the key takeaways here is NSX and SRM simplifies disaster recovery. It gives you integration and it really brings you down the path of an SDCD approach towards DR, cross vC networking and security allows you to have features that are not currently available in a physical environment. There's no need for expensive WAN connectivity or OTV or physical hardware dependencies. DR runbooks can now be automated fully end-to-end and you removing the complexity of having to reIP when you're moving applications between two sites. To summarize this being able to decouple from your physical environment, having logical networking be able to be duplicated across multiple sites really removes the traditional headaches and pain points of DR in a physical environment.
