Kong Kong Tutorials, 27 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Zero-Touch Disaster Recovery With Kong and Ansible Automation Platform

Description

In this video, Ross McDonald, solutions engineer at Kong, shows how to leverage a combination of Kong Gateway and Kong Mesh to maintain business continuity for @AnsibleAutomation.

Links and more detailed info in the blog post: https://konghq.com/blog/ansible-automation-platform/

▬▬▬▬▬▬ TIMECODES ▬▬▬▬▬▬

0:00 - Intro
0:12 - Architecture Overview
0:47 - Benefit of Service Mesh Over a Load Balancer
1:16 - Kong Mesh Deployment Overview
2:03 - Grafana Dashboard
2:16 - Disaster Recovery Scenario with Ansible Automation Platform (AAP)
4:50 - Restart the Production Data Plane
5:16 - Requests Funneling Back to Production
5:58 - Fully Recovered!
6:25 - Conclusion

Don’t let an outage catch you off guard! Reach out to Kong or Red Hat if you would like to explore a joint Disaster Recovery solution tailored to your needs: https://konghq.com/contact-sales or https://www.redhat.com/en/contact?contact=sales

#RedHat #Ansible #AutomationPlatform #KongMesh #KongGateway #DisasterRecovery #BusinessContinuity #ServiceMesh #APIGateway

A

In this video we're going to review a zero touch, disaster recovery solution for red hat's ansible.

A

Automation platform leveraging the power of kong's api gateway and service mesh solution.

A

Here is a high level overview of our architecture. Up at the top are end users issuing api requests.

A

Through an application front end where the traffic ultimately reaches a kong api gateway at the edge.

A

Of our network, the gateway then routes, the traffic through kong's service, mesh architecture, which.

A

Prioritizes the production aap cluster over the dr cluster, both of these clusters are executing.

A

Workloads behind the scenes for this demonstration, we have a pig latin translator, but you can think.

A

Of this, as any business critical workload that you may have in your infrastructure today,.

A

The benefit of using a service mesh over a typical load balancer is that any failure at any location.

A

Within the routing structure will automatically be routed around with no manual intervention required.

A

So, regardless of whether the failures are occurring on a service level,.

A

A node level or even a region level, the mesh architecture's, dynamic, routing capabilities.

A

Allow for the mesh to route around any errors automatically.

A

Allowing you and your team to focus on more high priority issues here is.

A

The kong mesh user interface, which provides high level information about the mesh runtime.

A

Here you can see the two zones we have deployed today, production and dr in order to prioritize.

A

The traffic to stay within the prod zone, we have locality, aware load, balancing.

A

Enabled on the mesh, this ensures that latency is low and that only if production is down.

A

Will traffic reach the disaster, recovery or dr zone.

A

And then here are the data plane proxies. We have deployed.

A

One kong, api gateway for ingress into the mesh and then two aap or tower services, one for each zone.

A

We also have a grafana dashboard, which shows the request heating, each environment.

A

This will allow us to see how traffic is redistributed as we encounter failures.

A

To see this architecture in action, we'll start by sending requests to aap.

A

Which will be running in ansible playbooks behind the scenes and printing out the results.

A

The console here then the results here you can see that the time to translate from prod, so we can see.

A

Exactly which environment this is hitting from the client's perspective, we can see the traffic.

A

As it hits each environment and then up here on the top left and the top right are the aap.

A

Uis showing us the commands that are being run in each case.

A

The top left over here is the production environment, and you can see that we have new.

A

Instances of our pig, latin translator, job being scheduled and then over on the right is the dr.

A

To simulate a failure, we're going to kick off a job from our dr instance.

A

Which will stop the production proxies here? You can see our kuma stop prod dpp.

A

I'm going to go ahead and execute this. This will effectively terminate the mesh data plane that.

A

Lives in the production environment, forcing the mesh to reroute the traffic to our dr.

A

And after a few seconds we'll see the instance here, so the last request hit prod.

A

You can see here in our chart that the traffic is now starting to be redistributed.

A

To the dr zone signified by the green line.

A

We can see the last request from our client here hit the dr zone, and now we.

A

Have the traffic converging on the dr zone from the mesh perspective.

A

Note that we did not have to touch anything, we didn't have to modify.

A

Or manually update any configurations or load balancers. In order to point to the dr.

A

That this all occurred fully automatically all from within the service mesh itself.

A

We can let this run for a few minutes to see exactly all the requests are hitting dr.

A

Now, let's go ahead and restart the production data plane going to run the start, prod dpp task here.

A

Here you can see the pig latin translator requests.

A

That were moved from the production to the dr aap instance.

A

And now that production has been restarted, we should start to see.

A

The requests now funnel back over to production.

A

Just like you see here request2219 and now you can see that the last api request did.

A

Come from our prod instance- and this is confirmed by looking at our charts.

A

Well now, where the dr zone is losing its traffic.

A

And the production traffic is starting to creep back up.

A

And here you can see, we have fully recovered.

A

From the client's perspective, no steps were needed, no errors were received, but.

A

From the backend configuration everything was reverted over to the dr automatically.

A

And then, when things were resolved on the production side, traffic was rerouted.

A

To recap: we showed how you can achieve effortless disaster recovery.

A

By utilizing the self-healing properties of the kong service mesh platform.

A

This allows for zero touch failover, where downed mesh nodes are automatically routed around.

A

No manual intervention required. We then showed how once service was restored. Traffic was.

A

Automatically rerouted back to our production environment. Again, no intervention needed fully.

A

Automated fully resilient to see what else you can do with kong mesh head over to konghq.com.