[MUSIC] In this video, you will learn about OCI, traffic management. The idea behind traffic management is that you can configure routing policies within your OCI resources such that based on performance or geolocation or load balancing requirements. You may route traffic between multiple resources within your OCI or hybrid environments. The answers are responses to a URL request which can be routed through the traffic management to a particular web server or load balancer and get the answer from there. And which is exactly what traffic management purpose is. So where is this traffic steering and traffic management UI in OCI? Let me take you to the website. Earlier we had looked at health checks. Now, let's get into networking DNS management. Fundamentally, DNS management gives you both private DNS and public DNS zone management. If you are using public IPs and you want them to be resolved using the OCIs public zone management, you can create your zone where you need to have your domain registered. And you can set up OCI resources or any other place with the public IP that you have and configure your DNS within OCI so that your DNS resolution happens using the OCI DNS servers. You could also use DNS from any other location for public IPs that you have. But when it comes to traffic management, it uses DNS as a backbone to steer traffic across multiple regions or multiple resources in OCI. When we look at traffic steering, there are different types of traffic steering policies that you can use. What is listed here is load balancer, failover, geolocation steering, ASN steering and IP prefix based steering. We will look at each one of them as we go further into this video. So exactly the same list of use cases are given, plus a couple of other special cases where you want to do a cloud migration or a hybrid environment etcetera can also be used. Let's look at some of the use cases to understand. In the case of a failover, we are looking at if you have for example within OCI itself, two regions in which you have deployed your application. And you have replicated the data by using let us say, remote peering or something so that your data is replicated. Using traffic steering with DNS, you can configure the DNS in such a way, primary location will be this. And in case the region A resources are unreachable, lead the DNS route traffic to region B. So how would you do that? If you come to your OCI control and choose load balancer as the option under traffic steering. You will give a policy name, let's say load balancing, and choose the option available there. But right now I think I was talking about failover, so let me take the case of failover. I will come into load balancing in a moment. So in the case of failover, let's say I say failover policy1. And when I configure this, I choose which are the answer pools. Let's say I say region A is one answer pool, and region B is an answer pool. You will need to give the public IP that is available in region A and the public IP that is in region B, maybe the load balancer or a compute instance as per your requirement. You can add more pools if required. And now the order in which these have to be routed to is given. So, if you want to say that in my environment, pool a will be the primary answer pool and if pool A is not available then region B will be used. Then your DNS in OCI will be updated to use this, how do you choose the domain? You should have already had zone created in DNS and use that zone. And you could use an existing health check as an input for this. Such that you can have your pools not being just statically being used for failover, but based on health checks it can do a failover. That's the idea behind failover using load balancing policies with traffic steering. On the other hand, as we saw earlier, load balancing is also available where if you choose load balancer as the option within traffic steering. You will be able to again give different pools or different answer locations and use the traffic data from the health checks. Either you can use it or not use it that is a choice that you have. But health checks gives you the ability to have data based load balancing across multiple regions. Which you are using are across multiple public IPs that you are having your application and provide between the multiple. Public IP resources. Let's say you have region A and region B as two resources available and you give the public IP that is available in both. You can give a weighted based load balancing if you want so that the traffic gets routed. And health checks can add to the way in which load balancing can happen. Next, we have the ability to use cloud migration scenarios. What do we mean by cloud migration? You may have your application in one cloud provider and you are coming into OCI. And when you are having the application getting migrated from your existing environment, maybe your on-premise or some other cloud and you're moving your application to OCI. You may want to route some traffic here and let the majority go to the existing cloud environment so that you can validate whether your OCI resources are working fine. That's an example of how you could use this as a cloud migration strategy. And in the case of hybrid environments where you have multiple deployments of the same application in different different cloud providers. You could very well distribute the data requests between the multiple hybrid cloud deployments and then comes an interesting case of geo location. Now, what is geo location? When you have your application deployed in specific regions for various reasons. Let's say this is in North America, one of the regions let's say it's in Ashburn and you have London. And let's say you have Mumbai as three regions in which you have set up your application with compute instances and if required load balancers. Now, when you are having users coming in from specific locations, for example, you might say any request coming in from Asia should be routed to Mumbai. Any end users who are coming from Europe and accessing your application should go to the London region. And anybody coming in from North America should be directed to Ashburn. All of them may be using the same URL to access the application. But for various requirements such as giving the end user a good experience because if a person in Asia is accessing London it might be slower. Let them come to Mumbai to give a good experience from an end user perspective. Also from controlling traffic moment you don't want data to move out of a particular geography, this comes in of help. How do you set this up? In your OCI, you have under traffic management, the ability to do geolocation based steering. Where if I give the option as geolocation policy for example, I might set up multiple answer pools. Each answer pool is possibly something like Ashburn trying to type out here. Each pole would represent a place where you have got your resources deployed. There may be multiple resources within the same region. But let's say I have a public IP for a load balancer in Ashburn, I have a Frankfurt specific implementation available within OCI, and I give the public IP of that over here. Each of these public IPs will come from your compute instance or from your load balancer that you provision, and let's say Mumbai. So you provision the resources upfront and come into traffic steering and detail the answer pools. And then you can go and specify if requests originate from Asia, let it go to Mumbai first, if Mumbai is unreachable then let us go to Frankfurt. And if Frankfurt is also not reachable, then let it go to Ashburn. From a latency perspective, that would be an ideal depiction of this or you might add additional locations. For example, if requests are coming from Europe, let the primary response go to Frankfurt, if Frankfurt is unreachable, let it go to Ashburn. And if both are not reachable, only then come to Mumbai and you can add multiple locations in this depending on your requirement. Now, how will OCI know where a request is coming from, where a client is coming from? That is standard internet means of identifying source. Whenever anybody is accessing a resource on the internet, when it goes to the DNS, it can identify the public IP from where the request comes. And public IP addresses are like pin codes in a country or postal codes in a country. Where from the public IP from where a resource comes or a request comes, you can identify which geography or which location the request is coming from. That is the idea behind using this. And additionally, you can attach a health check to use that input to do the traffic steering. And attach it to a domain to do the traffic steering across the different regions in which you have deployed your cloud applications. Thus, we have looked at geolocation, failover, load balancing. Then comes the idea of canary testing, zero rating service which are typical things that are done in any situation of having public facing services. When we look at ASN steering, ASN steering is a general functionality wherein you may have different network providers able to identify their, networks with an ASN number. And based on, from where the request is originating, you may want to route your traffic to a particular region, which is what ASN steering is. And based on the originating request IP prefix, you can do prefix based IP routing, maybe if requests are coming from within your VPN or from your on premise network. Send it to a particular location, if it is from the public internet send it to another location in the form of various regions in which you have deployed, is a choice you can use to deploy this. These are all different options that the traffic steering option gives you in OCI. And as a result of using these features, you are able to have a cross region deployment of your applications. And use DNS based traffic steering to enable highly available disaster recovery compliant as well as based on your compliance requirements to route traffic to specific locations. All of them can be taken care of with the traffic management steering policies, that you can implement in OCI. As a result, all these options are the ones that OCI provides, use the one which is appropriate for each application. So that you can get the best out of your public cloud deployments or private cloud deployments in OCI and other locations.
