WEBVTT

00:00.000 --> 00:15.000
I hope you're not so tired as I am.

00:15.000 --> 00:18.000
Anyway, thanks.

00:18.000 --> 00:20.000
Okay, so my name is Miguel Ruj.

00:20.000 --> 00:21.000
I come from Portugal.

00:21.000 --> 00:24.000
I'm a community user active.

00:24.000 --> 00:26.000
I love to come to Fossil.

00:26.000 --> 00:28.000
I think it's one of the best conferences.

00:28.000 --> 00:30.000
And I blog a bit.

00:30.000 --> 00:31.000
I should blog more.

00:31.000 --> 00:34.000
But I especially like to help people

00:34.000 --> 00:37.000
and Slack and some questions and Slack

00:37.000 --> 00:40.000
or stack more flow blogs and these kind of things.

00:40.000 --> 00:43.000
I work at Masquel at Oracle.

00:43.000 --> 00:46.000
However, I'm here on my own as a community guy.

00:46.000 --> 00:49.000
I've been working there for 13 years now.

00:49.000 --> 00:50.000
Multiple projects.

00:50.000 --> 00:51.000
Masquel proxy.

00:51.000 --> 00:53.000
Enterprise monitor and so on.

00:53.000 --> 00:56.000
But I'd say the most fulfilling ones were the latest.

00:56.000 --> 00:59.000
That is Masquel shell in the NAPI.

00:59.000 --> 01:02.000
And router and the architectures,

01:02.000 --> 01:06.000
the cluster set and so on.

01:06.000 --> 01:09.000
Let's get moving.

01:09.000 --> 01:12.000
I have a lot of content and not much time.

01:12.000 --> 01:15.000
So let's set the stage and let's talk a bit about

01:15.000 --> 01:19.000
why smarter query routing is important and why is needed.

01:19.000 --> 01:22.000
So I think you all know Masquel router and how it works,

01:22.000 --> 01:24.000
which is a quick refresher.

01:24.000 --> 01:27.000
Masquel router is a core component of the

01:27.000 --> 01:28.000
Masquel architectures.

01:28.000 --> 01:32.000
It serves as a, it has a full integration there.

01:32.000 --> 01:34.000
It does transport clients connection routing.

01:34.000 --> 01:36.000
So it knows where to send the queries.

01:36.000 --> 01:39.000
It sits behind your, between your applications clients

01:39.000 --> 01:41.000
and the notes in the topology.

01:41.000 --> 01:44.000
And it knows where to forward everything.

01:44.000 --> 01:46.000
So it provides a balancing application connection

01:46.000 --> 01:47.000
fell over.

01:47.000 --> 01:49.000
And it's very lightweight.

01:49.000 --> 01:51.000
It's just a simple middleware, very lightweight.

01:51.000 --> 01:55.000
And it's automatically does what is expected from it

01:55.000 --> 02:01.000
most of the times, with almost no setup.

02:01.000 --> 02:04.000
But I'd like to share a personal experience

02:04.000 --> 02:09.000
that's kind of demonstrates where current routing falls short,

02:09.000 --> 02:11.000
not falls apart, but falls short.

02:11.000 --> 02:15.000
So this was a personal experience with a friend of mine

02:15.000 --> 02:18.000
that they, you work in a small startup.

02:18.000 --> 02:20.000
They do some e-commerce.

02:20.000 --> 02:23.000
And they have, you know, the v-cluster deployment.

02:23.000 --> 02:26.000
So they have multiple secondaries.

02:26.000 --> 02:28.000
That's just a simplification of the architecture.

02:28.000 --> 02:31.000
They have multiple secondaries, read weblicas.

02:31.000 --> 02:34.000
And they do three types of traffic.

02:34.000 --> 02:37.000
They have a frontend traffic that they prefer to send

02:37.000 --> 02:38.000
to the secondaries.

02:38.000 --> 02:42.000
They have some kind of B-I traffic that he told me they have

02:42.000 --> 02:46.000
very expensive queries, lots of resources needed.

02:46.000 --> 02:48.000
And they don't care for replication lag.

02:48.000 --> 02:50.000
So they send it to the read replicas.

02:50.000 --> 02:54.000
And on top of that, they even deploy some instances

02:54.000 --> 02:56.000
running newer versions for testing.

02:56.000 --> 02:58.000
So they have it all in the same typology.

02:58.000 --> 03:02.000
And he was struggling with Moscow router.

03:02.000 --> 03:07.000
You know how to configure it to send the queries

03:07.000 --> 03:09.000
to the places you wanted them to go.

03:09.000 --> 03:13.000
So he started by trying to do manual route

03:13.000 --> 03:16.000
the router configuration, which was the terrible idea

03:16.000 --> 03:18.000
because if you configure router manually,

03:18.000 --> 03:22.000
then you lose all the flexibility and the capabilities

03:22.000 --> 03:24.000
of router to dynamically adapt to the topology

03:24.000 --> 03:26.000
and the topology changes.

03:26.000 --> 03:27.000
So no.

03:27.000 --> 03:30.000
Then he, I was talking to him and I was telling him,

03:30.000 --> 03:32.000
why don't you use the read-only target option

03:32.000 --> 03:34.000
that he can configure it through shell.

03:34.000 --> 03:39.000
And he can configure your routers to send the read-only traffic

03:39.000 --> 03:44.000
to only the secondaries, only the read replicas

03:44.000 --> 03:45.000
or both.

03:45.000 --> 03:48.000
And he was like, yeah, but for that, I need multiple routers.

03:48.000 --> 03:50.000
And it's like, yeah, that's the way to do it, right?

03:50.000 --> 03:52.000
You just place router next to your application.

03:52.000 --> 03:53.000
He said, no, no, no.

03:53.000 --> 03:54.000
We have some kind of layer.

03:54.000 --> 03:57.000
We have some one router in a container.

03:57.000 --> 03:58.000
One configuration.

03:58.000 --> 03:59.000
Then we deploy multiple of them.

03:59.000 --> 04:03.000
And that's under the virtual IP for HE for router.

04:03.000 --> 04:04.000
Something like that.

04:04.000 --> 04:07.000
So anyway, at the end,

04:07.000 --> 04:10.000
it's also thinking that for the newer versions,

04:10.000 --> 04:11.000
you cannot do anything with router.

04:11.000 --> 04:13.000
You cannot just configure it to send traffic there.

04:13.000 --> 04:15.000
So no.

04:15.000 --> 04:16.000
Also no.

04:16.000 --> 04:17.000
Rejected.

04:17.000 --> 04:20.000
And we were having lunch and by the end of HE he was like,

04:20.000 --> 04:22.000
hey, man, why don't you write up?

04:22.000 --> 04:25.000
Why don't I open a feature request and you write the batch

04:25.000 --> 04:27.000
to support this like, oh man, no way.

04:27.000 --> 04:29.000
The first of all is not that simple.

04:29.000 --> 04:32.000
And then I'm going to create a feature

04:32.000 --> 04:35.000
or some kind of feature that works just for you,

04:35.000 --> 04:36.000
and nobody else.

04:36.000 --> 04:38.000
And that's some undeniable.

04:38.000 --> 04:40.000
And we will just open a Pandora box.

04:40.000 --> 04:42.000
And it's just really a bad decision.

04:42.000 --> 04:46.000
So he said, okay, I wasn't going to pay you lunch, but nope.

04:46.000 --> 04:53.000
Anyway, this was just to demonstrate how with the evolution of my

04:53.000 --> 04:55.000
school architectures and topologies,

04:55.000 --> 04:59.000
routing can bring a lot of challenges.

04:59.000 --> 05:01.000
So we need to really need a smarter approach,

05:01.000 --> 05:05.000
something more flexible to adapt to this kind of topologies.

05:05.000 --> 05:08.000
This is an example of a cluster set.

05:08.000 --> 05:11.000
So in cluster set you have,

05:11.000 --> 05:13.000
geographically distributed instances,

05:13.000 --> 05:15.000
multiple clusters.

05:15.000 --> 05:18.000
Here there's just two, one in the US and another one in Europe.

05:18.000 --> 05:20.000
And in this kind of set ups,

05:20.000 --> 05:24.000
you want to optimize traffic based on proximity.

05:24.000 --> 05:29.000
So you want queries to go to the closest data center.

05:29.000 --> 05:33.000
And rather than consider the latency differences between that

05:33.000 --> 05:34.000
centers.

05:34.000 --> 05:37.000
So you want to do this optimization,

05:37.000 --> 05:41.000
and you want to configure it to use proximity.

05:41.000 --> 05:44.000
Another example, resource prioritization,

05:44.000 --> 05:47.000
in a scenario of, for example, an overload of the system,

05:47.000 --> 05:49.000
or some partial load type,

05:49.000 --> 05:53.000
usage, you certainly want, or you may want some critical

05:53.000 --> 05:55.000
operations to be prioritized.

05:55.000 --> 05:57.000
And you can do that with router,

05:57.000 --> 06:00.000
because router treats all sessions equally.

06:00.000 --> 06:03.000
So that's a challenge.

06:03.000 --> 06:06.000
Another example, the last one,

06:06.000 --> 06:11.000
if you want to do some kind of schema specific routing,

06:11.000 --> 06:16.000
you want to, some queries of a specific schema to go to that cluster.

06:16.000 --> 06:19.000
Some others of another schema to go to the other cluster.

06:19.000 --> 06:21.000
You just can't do it at a moment.

06:21.000 --> 06:26.000
You need to do some manual management of the connections

06:26.000 --> 06:30.000
and that's really complicated and is not ideal.

06:30.000 --> 06:36.000
So it's also another limitation with the current routing mechanisms.

06:36.000 --> 06:38.000
So just summarizing quickly this.

06:38.000 --> 06:41.000
Has a thing as the complexity of the setups grows.

06:41.000 --> 06:46.000
We certainly want support for application specific configurations.

06:46.000 --> 06:51.000
We want to adapt in scenarios of overloads,

06:51.000 --> 06:54.000
failovers, or even maintenance.

06:54.000 --> 06:58.000
And in particular, we want to enable granular control.

06:58.000 --> 07:01.000
So we want to go even down to individual statements within a session.

07:01.000 --> 07:06.000
We want to work with that and know and do better management of routing.

07:06.000 --> 07:12.000
So we want to consume routing for very narrow and very specific use cases.

07:12.000 --> 07:15.000
So meet my scroll routing guidelines.

07:15.000 --> 07:17.000
This is a new thing.

07:17.000 --> 07:20.000
It's just got out in nine two, a couple of weeks ago.

07:20.000 --> 07:22.000
For shell and router.

07:22.000 --> 07:30.000
And this is aims to lift up those limitations and solve those challenges.

07:30.000 --> 07:36.000
So let's jump to the details and tech and what's better than a snippet.

07:36.000 --> 07:40.000
So routing guidelines are written in JSON.

07:40.000 --> 07:44.000
They live in the metadata schema of the topologies.

07:44.000 --> 07:47.000
And they have four main attributes.

07:47.000 --> 07:48.000
Name version.

07:48.000 --> 07:50.000
We use semantic versioning for this.

07:50.000 --> 07:53.000
And then the important ones are the destinations and routes.

07:53.000 --> 07:56.000
If you look at the destinations, you can see this is a very simple example.

07:56.000 --> 07:59.000
The primary and the secondary.

07:59.000 --> 08:01.000
That's you know what it is.

08:01.000 --> 08:03.000
There's a match that's I'm going to talk about it later.

08:03.000 --> 08:04.000
It's also easy to read.

08:04.000 --> 08:07.000
That's member role primary and secondary.

08:07.000 --> 08:09.000
I guess you understand what that means.

08:09.000 --> 08:11.000
And then you have the routes.

08:11.000 --> 08:14.000
Also here on the bottom that one is named RO.

08:14.000 --> 08:16.000
It's for read only.

08:16.000 --> 08:23.000
There's a match expression that is saying that target parts of the session equals to routers with only part.

08:23.000 --> 08:28.000
And then a list of destinations that I will explain how it works.

08:28.000 --> 08:30.000
So let's break it down.

08:30.000 --> 08:32.000
Starting with the destinations.

08:32.000 --> 08:34.000
Like I was saying destinations.

08:34.000 --> 08:40.000
They group the servers of the topology using this pattern matching expressions.

08:40.000 --> 08:42.000
So here I have three.

08:42.000 --> 08:46.000
I'm using the member role primary, secondary and read replica.

08:46.000 --> 08:49.000
And I create this list of destinations.

08:49.000 --> 08:52.000
And each we call it destination class.

08:52.000 --> 08:58.000
Each class forms a pool of candidates for offices for routing.

08:58.000 --> 09:02.000
As for the routes, similarly they use pattern matching expressions.

09:02.000 --> 09:08.000
And routes are used to classify the incoming sessions according to an expression.

09:08.000 --> 09:10.000
And route to a list of destinations.

09:10.000 --> 09:13.000
So this one is called read only.

09:13.000 --> 09:21.000
The match expression, like I was saying before, is that if the session target part equals to the routers read only part.

09:21.000 --> 09:23.000
Then I want the queries to go to those destinations.

09:23.000 --> 09:27.000
The list of destinations is ordered by priority.

09:27.000 --> 09:30.000
The first one with priority zero, the secondary.

09:30.000 --> 09:37.000
And so it means that if there are secondary, if there are instances available on that destination class.

09:37.000 --> 09:39.000
The things the queries will go there first.

09:39.000 --> 09:42.000
If none is available, it will jump to the next one.

09:42.000 --> 09:44.000
That is the class primary.

09:44.000 --> 09:50.000
And then you see the strategy that is the strategy applied for the queries.

09:50.000 --> 09:55.000
So run, run in this case.

09:55.000 --> 09:59.000
So as for the matching rules, these matching expressions.

09:59.000 --> 10:02.000
We have three predefined sets of variables.

10:02.000 --> 10:07.000
Server ones, related to my school server, session related to the client session.

10:07.000 --> 10:10.000
And the router related to the router instance.

10:10.000 --> 10:15.000
And then you can apply functions and operators.

10:15.000 --> 10:17.000
So you have the logical operators.

10:17.000 --> 10:21.000
The inclusion checks, the like operator to the pattern matching.

10:21.000 --> 10:25.000
Arithmetic operations, comparisons, and the list of functions that I will show after that.

10:25.000 --> 10:28.000
You're going to be familiar with them.

10:29.000 --> 10:32.000
So summarizing these matching expressions.

10:32.000 --> 10:39.000
They are used to classify the servers and the sessions and the routers with logical conditions.

10:39.000 --> 10:42.000
So those expressions.

10:42.000 --> 10:44.000
Evaluates to true or false.

10:44.000 --> 10:49.000
You can compose using variables, operators, and values to create the matches.

10:49.000 --> 10:51.000
It can change them with these conditions.

10:51.000 --> 10:54.000
We don't are not for flexibility.

10:54.000 --> 11:03.000
This is the bottom, the syntax of how to, of the matching expressions.

11:03.000 --> 11:05.000
I'm not going to go through the whole list.

11:05.000 --> 11:07.000
You can then download the slides later.

11:07.000 --> 11:10.000
But just to give you an idea, this is the server ones.

11:10.000 --> 11:14.000
You have stuff like server address, power to your ID version.

11:14.000 --> 11:17.000
The member role that we used on the previous example.

11:18.000 --> 11:20.000
And so on.

11:20.000 --> 11:23.000
The session ones.

11:23.000 --> 11:28.000
Port, source, the username, schema, connection attributes.

11:28.000 --> 11:30.000
That opens the door for many, many things.

11:30.000 --> 11:33.000
There was already a talk that mentioned them.

11:33.000 --> 11:39.000
And the router ones, the router parts, read rights, read only, read rights split.

11:39.000 --> 11:45.000
Bind address, the name of the router, the host name, and so on.

11:45.000 --> 11:51.000
As for the functions, this is the ones available, concatenation, network,

11:51.000 --> 11:55.000
contains, resolve, rejects, and so on.

11:55.000 --> 11:58.000
You can, I put some examples there.

11:58.000 --> 12:04.000
You can work with these functions to create these complex or not matching expressions.

12:04.000 --> 12:12.000
So the workflow, the high level vision of it in router, is that router classifies destinations.

12:12.000 --> 12:16.000
So it's group servers into the destination classes.

12:16.000 --> 12:22.000
Each member of the topology can belong to one or non or multiple destination classes.

12:22.000 --> 12:28.000
Then the matching rules, the rules are matched when the incoming sessions come.

12:28.000 --> 12:34.000
And then router applies if a session is matched to a rule.

12:34.000 --> 12:37.000
And there are destination classes available.

12:37.000 --> 12:39.000
The router will apply the routing strategy.

12:39.000 --> 12:43.000
As of now, we have first available and run robin.

12:43.000 --> 12:47.000
And router is continuously monitoring the topology.

12:47.000 --> 12:52.000
Reclassifying servers if needed, updating routes, or disconnect invalid connections.

12:52.000 --> 13:00.000
If that's the case, because the routing guideline changed, or some other conditions.

13:00.000 --> 13:06.000
Now moving to shell and the admin API, as usual shell fully supports the management of

13:06.000 --> 13:07.000
routing guidelines.

13:07.000 --> 13:12.000
And it was extended with new bunch of new commands.

13:12.000 --> 13:15.000
It has support for the three architectures.

13:15.000 --> 13:18.000
You know, the cluster replica set in cluster set.

13:18.000 --> 13:23.000
There's a new routing guideline class with many functions to manage the routing guidelines.

13:23.000 --> 13:32.000
And this is just a print screen of creating default routing guideline on cluster topology.

13:33.000 --> 13:37.000
So these are the main commands to start.

13:37.000 --> 13:40.000
So you have create routing guideline.

13:40.000 --> 13:47.000
Set routing option that enables you to activate the guideline on a topology or deactivate.

13:47.000 --> 13:50.000
And each topology can have multiple routing guidelines.

13:50.000 --> 13:55.000
But only one case can be enabled at a time or non.

13:55.000 --> 13:58.000
Get routing guideline, remove routing guideline.

13:58.000 --> 14:02.000
Routing guidelines to list the ones of your topology.

14:02.000 --> 14:10.000
And import, because you can import from adjacent file into the topology using that command.

14:10.000 --> 14:12.000
As for the new class, the routing guideline class.

14:12.000 --> 14:18.000
There's a show command that will print in a human readable way.

14:18.000 --> 14:22.000
The destinations with a much expression for each one with a name.

14:22.000 --> 14:25.000
And includes the servers of your topology.

14:25.000 --> 14:27.000
That are much to those destinations.

14:27.000 --> 14:32.000
The routers library to do that in runtime.

14:32.000 --> 14:37.000
Has Jason to printed out destinations and routes to print the destinations and routes.

14:37.000 --> 14:42.000
Add routes, add destination, remove route, remove destination.

14:42.000 --> 14:49.000
I just use a bunch of synonyms for clear in the purpose, because the names face a URL.

14:49.000 --> 14:54.000
Set destination options, set route option, copy to copy over a routing guideline.

14:54.000 --> 14:57.000
Export to export it to adjacent file.

14:57.000 --> 14:59.000
So you can import it later.

14:59.000 --> 15:02.000
And rename to just rename it.

15:02.000 --> 15:03.000
Do you have a quick question?

15:03.000 --> 15:04.000
Yes.

15:04.000 --> 15:07.000
This is on the shelf, but you can probably talk to the routers.

15:07.000 --> 15:10.000
We're going to print that synchronizing the configuration setting.

15:10.000 --> 15:13.000
Now, everything is in the metadata.

15:13.000 --> 15:15.000
It's all stored in the metadata.

15:15.000 --> 15:18.000
Routing guidelines are stored there as Jason.

15:18.000 --> 15:20.000
And the route is reading from that to later.

15:20.000 --> 15:21.000
Yes.

15:21.000 --> 15:22.000
Exactly.

15:25.000 --> 15:26.000
Okay.

15:26.000 --> 15:28.000
There's still 10 minutes.

15:28.000 --> 15:35.000
So I want to go through some use cases and to show how the potential of routing guidelines.

15:35.000 --> 15:39.000
And let's start with the common one.

15:39.000 --> 15:41.000
High availability in disaster recovery.

15:41.000 --> 15:42.000
So cluster sets.

15:42.000 --> 15:48.000
And we want seamless fill over in this kind of topology.

15:48.000 --> 15:53.000
So we want to redirect traffic to alternate nodes when there is an outage.

15:53.000 --> 15:57.000
So we have service all the time.

15:57.000 --> 15:59.000
We want to prioritize local traffic.

15:59.000 --> 16:02.000
So we want to not prioritize local traffic.

16:02.000 --> 16:08.000
We want traffic to be local if possible for performance reasons.

16:08.000 --> 16:11.000
We want to optimize read by routing.

16:11.000 --> 16:13.000
Router already does that by default.

16:13.000 --> 16:17.000
So to router the queries to the primaries or the secondaries.

16:17.000 --> 16:20.000
And to the real replicas for the red scale out.

16:20.000 --> 16:23.000
But we want also to have fallback levels.

16:23.000 --> 16:28.000
In case the one of the destination classes is available.

16:28.000 --> 16:30.000
Just another one and so on and so on.

16:30.000 --> 16:35.000
To ensure maximum availability of your topology.

16:35.000 --> 16:38.000
So I don't know if you can see this.

16:38.000 --> 16:40.000
It's screenshots.

16:40.000 --> 16:43.000
I'm showing here the destinations command.

16:43.000 --> 16:46.000
And I've created all these destinations.

16:46.000 --> 16:49.000
And starting from top.

16:49.000 --> 16:52.000
The two first ones are related to the primary member.

16:52.000 --> 16:54.000
Primary local primary remote.

16:54.000 --> 16:59.000
And I'm using the cluster role is the primary cluster of the cluster set.

16:59.000 --> 17:04.000
And the member role is the primary member of that cluster.

17:04.000 --> 17:07.000
And I don't want the cluster to be validated.

17:07.000 --> 17:10.000
An validated cluster is in a case of fill over in cluster set.

17:10.000 --> 17:13.000
Like in an asynchronous topology.

17:14.000 --> 17:20.000
That old primary is invalidated because we don't want the data to be wrong.

17:20.000 --> 17:27.000
And finally, the server cluster name equals to the router local cluster.

17:27.000 --> 17:34.000
So when you bootstrap a router, the router is bootstrap against the cluster.

17:34.000 --> 17:36.000
And we know the name of that cluster.

17:36.000 --> 17:38.000
So that cluster is local to the router.

17:38.000 --> 17:43.000
So if I say that my server's cluster name is that router's same name.

17:43.000 --> 17:45.000
I know that is a local one.

17:45.000 --> 17:48.000
As for the remote is the same thing except in the end in set of equals.

17:48.000 --> 17:52.000
I'm using it's not equal.

17:52.000 --> 17:55.000
Then I did the same for the second there is scale out.

17:55.000 --> 17:59.000
And the final ones is the read only file bulk local.

17:59.000 --> 18:03.000
In this case, I accept that the cluster is validated like the extreme case.

18:03.000 --> 18:06.000
That I cannot read from anywhere else.

18:06.000 --> 18:08.000
And I would like to read from those.

18:08.000 --> 18:10.000
There's a destination for that.

18:10.000 --> 18:13.000
So destinations are defined as for the adding routes.

18:13.000 --> 18:18.000
The first one for read right traffic is the more simple one.

18:18.000 --> 18:23.000
I say that I want the target parts of my incoming session.

18:23.000 --> 18:30.000
To be either the routers read the right port or the read right split port.

18:30.000 --> 18:33.000
And I want to use the following destinations.

18:33.000 --> 18:41.000
They are the way you write the list is the order that they get into the routing guidelines.

18:41.000 --> 18:44.000
So first use the primary local.

18:44.000 --> 18:48.000
If not available, jump to the primary remote.

18:48.000 --> 18:53.000
And then I want to say also that I want to allow connection sharing in my school router.

18:53.000 --> 18:55.000
And what's the last one?

18:55.000 --> 18:56.000
Enable through.

18:56.000 --> 18:57.000
Yeah.

18:57.000 --> 19:01.000
Because you cannot route and they're disabled and we enable them at any time.

19:01.000 --> 19:05.000
As for the read only traffic.

19:05.000 --> 19:10.000
In this case, I want that the session target part is the read only part of router.

19:10.000 --> 19:16.000
And I do run the robbing of all the secondary destinations.

19:16.000 --> 19:20.000
This is just an example to show you how to.

19:20.000 --> 19:23.000
In this case, to define fallback levels.

19:23.000 --> 19:27.000
Being the first one, I want that things go to the secondarys.

19:27.000 --> 19:30.000
And the scale out local to scale the reads.

19:30.000 --> 19:33.000
And the last one, to use only the fallback.

19:33.000 --> 19:34.000
This one here.

19:34.000 --> 19:38.000
That is the one of the things related to cluster just as an extreme situation.

19:38.000 --> 19:42.000
Is the last resort.

19:42.000 --> 19:44.000
No, an example.

19:44.000 --> 19:46.000
Maybe this is easier to read.

19:46.000 --> 19:51.000
So this one is about geolocation based routing and compliance.

19:51.000 --> 19:56.000
So here I have some destinations based on regions.

19:56.000 --> 20:02.000
And I also have some traffic that I want to send to some particular instances for compliance reasons.

20:02.000 --> 20:06.000
So I have the two destinations for the regions on top.

20:06.000 --> 20:08.000
In this case, I'm using the server address.

20:08.000 --> 20:15.000
And I want the server address to be long to US east one example.com or US west two example.com.

20:15.000 --> 20:17.000
Those are the US regions.

20:17.000 --> 20:20.000
And the same for the European regions.

20:20.000 --> 20:23.000
And then I use the server tags compliance.

20:23.000 --> 20:29.000
So the tags are you can set them through shell.

20:29.000 --> 20:31.000
And they are key value pairs.

20:31.000 --> 20:35.000
This case I called it compliance.

20:35.000 --> 20:37.000
The key and the value GDPR.

20:37.000 --> 20:41.000
And those are the destinations that I named GDPR compliance.

20:41.000 --> 20:44.000
So having those destinations defined.

20:44.000 --> 20:46.000
And I can create the routes.

20:46.000 --> 20:51.000
And starting with the geotratic based on IP.

20:51.000 --> 20:54.000
The first one is called geobaste.

20:54.000 --> 20:59.000
And over there I'm using in the match expression the network.

20:59.000 --> 21:06.000
So I'm shaking if the network, the range of the IP address that network is the same as that.

21:06.000 --> 21:07.000
182.

21:07.000 --> 21:09.000
The other one.

21:09.000 --> 21:13.000
So IP network matching.

21:13.000 --> 21:17.000
I want those to be routed to those destinations.

21:17.000 --> 21:21.000
And on the other routes called compliance based.

21:21.000 --> 21:23.000
I'm using the tags.

21:23.000 --> 21:25.000
So I'm not tags the connection attribute.

21:25.000 --> 21:28.000
And I'm saying that the connection attribute region equals EU.

21:28.000 --> 21:38.000
And for those I want the traffic to go to the servers that were tagged with GDPR compliance.

21:38.000 --> 21:40.000
Schema based routing.

21:40.000 --> 21:45.000
Also just an example in case you want to split traffic.

21:45.000 --> 21:57.000
You want traffic of sessions that use a specific schema to go to some destinations and sessions using another schema to go to some other destinations.

21:57.000 --> 21:59.000
In this case different clusters.

21:59.000 --> 22:03.000
For that I can use the session schema variable.

22:03.000 --> 22:06.000
And with that, this is the example of the show command.

22:06.000 --> 22:10.000
And like I said before, it lists the routes with a match expression.

22:10.000 --> 22:13.000
And the destinations of your topology.

22:13.000 --> 22:15.000
It evaluates in that runtime.

22:15.000 --> 22:18.000
And so I have these two routes, the app schema routing.

22:18.000 --> 22:23.000
And that app schema routing that use the sessions schema variable to define.

22:23.000 --> 22:26.000
To define the destinations that we want to use.

22:26.000 --> 22:32.000
And the destination classes are based on the server variables.

22:32.000 --> 22:36.000
Cluster role, member role, and cluster name.

22:36.000 --> 22:47.000
And without I could define those four destinations for this example.

22:47.000 --> 22:52.000
It's just an example.

22:52.000 --> 22:57.000
I'm not sure you understand this.

22:57.000 --> 23:00.000
But you have a single endpoint to the connection.

23:00.000 --> 23:02.000
We're like a deployable schema once again.

23:02.000 --> 23:03.000
Yes.

23:03.000 --> 23:06.000
Then you could route based on that.

23:06.000 --> 23:08.000
Yeah, that's true.

23:08.000 --> 23:13.000
Next one.

23:13.000 --> 23:15.000
This is an interesting example.

23:15.000 --> 23:20.000
So in this case, I have four types of traffic.

23:20.000 --> 23:24.000
Testing, staging, production, and session affinity related traffic.

23:24.000 --> 23:33.000
So I want to 10% of my client sessions to go to testing servers.

23:33.000 --> 23:37.000
20% to go to staging servers for validation.

23:37.000 --> 23:41.000
And the remaining traffic to go to production servers for stability.

23:41.000 --> 23:46.000
And then I have this session affinity that is to ensure that sessions using that accounts.

23:46.000 --> 23:52.000
The persistent user are kept to all the servers for to ensure continuity.

23:52.000 --> 23:56.000
So for that, I have defined three types of servers.

23:56.000 --> 23:58.000
Production staging and testing.

23:58.000 --> 24:00.000
For those I've set tags.

24:00.000 --> 24:03.000
So using shalloc and tag the instances.

24:03.000 --> 24:08.000
And as for the routes, I use the session random value.

24:08.000 --> 24:15.000
So random value is a double that is randomly generated by router at runtime.

24:15.000 --> 24:19.000
Per session and it's between 0 and 1.

24:19.000 --> 24:23.000
So I say that if the random value is slower than 0.1, that's 10%.

24:23.000 --> 24:29.000
I want to send it to the testing servers using the first available routing strategy.

24:29.000 --> 24:35.000
Then if the random value is between 0.1 and 0.3, so 20%.

24:35.000 --> 24:37.000
I want to send it to the staging servers.

24:37.000 --> 24:44.000
And the rest, if it's higher than 0.3, send to the production servers using the first available.

24:44.000 --> 24:52.000
Finally, if the session user is persistent user, I just run the run through all the available destinations.

24:52.000 --> 24:56.000
Production staging and testing servers.

24:56.000 --> 25:04.000
Another interesting example, again, connection attributes.

25:04.000 --> 25:12.000
So in this case, I have traffic coming from my scope dump that I want to send to some backup servers.

25:12.000 --> 25:18.000
I have traffic coming from Linux sessions that I want to send to servers running Linux.

25:18.000 --> 25:22.000
And for that, I use the connection attributes OS and program name.

25:22.000 --> 25:27.000
And the metadata tags again to define the destinations.

25:27.000 --> 25:33.000
And in this case, I have defined the two destinations on top, backup servers, Linux servers using tags.

25:33.000 --> 25:37.000
And the routes first routes Linux traffic.

25:37.000 --> 25:44.000
I want to say that if the session with the connection attribute, your OS equals Linux,

25:44.000 --> 25:46.000
I want to send them to the Linux servers.

25:46.000 --> 25:54.000
And down if the program name is my scroll dump, I want to send that to the backup servers.

25:54.000 --> 25:59.000
And back to my friends challenge a couple of weeks ago, I told him,

25:59.000 --> 26:02.000
now you can do interesting things.

26:02.000 --> 26:04.000
So let's solve your problem.

26:04.000 --> 26:11.000
So we've started by defining destinations using the memory role.

26:11.000 --> 26:14.000
So primary, red, red, red, black and secondary.

26:14.000 --> 26:19.000
And we split the red, red because by traffic, by network.

26:19.000 --> 26:20.000
And remember rules.

26:20.000 --> 26:24.000
And we have the testing servers that use higher versions.

26:24.000 --> 26:27.000
And for that we use the server version variable.

26:28.000 --> 26:37.000
And with that we could define those destinations for the red replica traffic for frontend traffic.

26:37.000 --> 26:42.000
For as a follow up level, the red replica traffic for the BI traffic.

26:42.000 --> 26:47.000
The second there is that to receive the frontend traffic, the primary and the testing servers.

26:47.000 --> 26:54.000
In this case, I'm indicating that the server version is nine two.

26:55.000 --> 26:58.000
And this is how the routing guideline looks like.

26:58.000 --> 27:07.000
Frontend traffic prioritizing secondary and falling back to the red replica.

27:07.000 --> 27:12.000
And the BI traffic is prioritizing red replica that are dedicated for that.

27:12.000 --> 27:15.000
And only falls back to frontend red replica if needed.

27:15.000 --> 27:19.000
And in case none of those are available.

27:19.000 --> 27:23.000
So there's not much time to go into a lot of details.

27:23.000 --> 27:27.000
So it's closed and just three takeaways.

27:27.000 --> 27:33.000
Routing guidelines enable a declarative way of defining routing.

27:33.000 --> 27:35.000
It's very flexible in dynamic.

27:35.000 --> 27:38.000
Using shell admin API, it's really easy.

27:38.000 --> 27:41.000
It's quite pleasant to manage this.

27:41.000 --> 27:45.000
And this allows future radio architectures.

27:46.000 --> 27:56.000
We have more flexible setups and we can handle more narrow use cases and and complex topologies.

27:56.000 --> 27:57.000
Some resources.

27:57.000 --> 27:59.000
I wrote a cook book.

27:59.000 --> 28:01.000
It's on the shell repo.

28:01.000 --> 28:03.000
It's called routing guidelines MD.

28:03.000 --> 28:05.000
There's tons of examples.

28:05.000 --> 28:09.000
I go through all the shell commands in a.

28:09.000 --> 28:13.000
The intuitive kind of academic way of explaining things.

28:13.000 --> 28:14.000
So you buy the end of it.

28:14.000 --> 28:15.000
You understand everything.

28:15.000 --> 28:17.000
There's the official documentation, of course.

28:17.000 --> 28:19.000
And we're in Slack and we.

28:19.000 --> 28:20.000
We love to help people.

28:20.000 --> 28:21.000
So.

28:21.000 --> 28:22.000
Thanks.

28:27.000 --> 28:28.000
That's what's in margin.

28:28.000 --> 28:29.000
For four feet.

28:29.000 --> 28:30.000
Yes.

28:30.000 --> 28:31.000
Yes.

28:31.000 --> 28:32.000
One.

28:32.000 --> 28:33.000
Two.

28:33.000 --> 28:34.000
Two.

28:34.000 --> 28:35.000
Two.

28:35.000 --> 28:36.000
No.

28:36.000 --> 28:37.000
Not yet.

28:37.000 --> 28:39.000
Maybe when it is these things working.

28:39.000 --> 28:40.000
Yeah.

28:40.000 --> 28:42.000
Does it do mirroring?

28:42.000 --> 28:43.000
Sorry.

28:43.000 --> 28:44.000
Does it do mirroring as well?

28:44.000 --> 28:46.000
Like if you want to send it to two.

28:46.000 --> 28:47.000
If it is what?

28:47.000 --> 28:48.000
Sorry.

28:48.000 --> 28:49.000
Does it do mirroring?

28:49.000 --> 28:50.000
Oh, mirroring?

28:50.000 --> 28:51.000
No, no, no, no.

28:51.000 --> 28:55.000
We haven't thought about it.

28:55.000 --> 28:56.000
We haven't thought about it.

28:56.000 --> 28:57.000
But.

28:57.000 --> 28:58.000
Yeah.

28:58.000 --> 28:59.000
Thanks for that.

28:59.000 --> 29:00.000
Yes, everyone.

29:00.000 --> 29:02.000
Have you considered also.

29:02.000 --> 29:05.000
The matching of protein based on courier.

29:05.000 --> 29:06.000
Yes.

29:06.000 --> 29:07.000
Good question.

29:07.000 --> 29:08.000
That's.

29:08.000 --> 29:09.000
That's next.

29:11.000 --> 29:12.000
Yeah.

29:12.000 --> 29:13.000
I have a question.

29:13.000 --> 29:14.000
It's a country here.

29:14.000 --> 29:16.000
Some kind of high probability for the.

29:16.000 --> 29:19.000
Well, well.

29:21.000 --> 29:23.000
You can do many things.

29:23.000 --> 29:25.000
In this case, he, this guy was doing.

29:25.000 --> 29:27.000
He had it under a virtual IP.

29:27.000 --> 29:30.000
So if the router goes away, it goes to the next one.

29:30.000 --> 29:32.000
That's the line one.

29:32.000 --> 29:33.000
One router.

29:33.000 --> 29:37.000
If I say that, we have three that are same.

29:37.000 --> 29:38.000
There's a four that are same.

29:38.000 --> 29:42.000
I think the line one that one that's found out.

29:42.000 --> 29:44.000
No, you should actually you should deploy.

29:44.000 --> 29:46.000
Rotter together with the application with a client.

29:46.000 --> 29:48.000
So you can see router as the connector.

29:48.000 --> 29:50.000
It's the next station to the connector.

29:50.000 --> 29:51.000
So that's how it should be deployed.

29:51.000 --> 29:53.000
That's a recommendation actually.

29:53.000 --> 29:55.000
Okay.

29:55.000 --> 29:57.000
But it's like if you're going to boot that.

29:57.000 --> 30:00.000
You can go back and you go back and you go back.

30:00.000 --> 30:05.000
So that's what it's called.

30:05.000 --> 30:07.000
You can just go because you can do the same.

30:07.000 --> 30:09.000
You can put.

30:09.000 --> 30:11.000
By boot.

30:11.000 --> 30:13.000
So you can do it.

30:13.000 --> 30:15.000
The user name for the router.

30:15.000 --> 30:17.000
You can use the same one.

30:17.000 --> 30:19.000
Yeah, I mean, you are just stepping that out.

30:19.000 --> 30:21.000
Because you're going to do the boot.

30:21.000 --> 30:24.000
Yeah, and in shell, you can create an account for bootstraping.

30:24.000 --> 30:26.000
That you can use for all routers.

30:26.000 --> 30:28.000
Yeah.

30:28.000 --> 30:29.000
Yeah.

30:29.000 --> 30:32.000
And, uh,

30:32.000 --> 30:34.000
why not write me about some of that, uh,

30:34.000 --> 30:36.000
when you look at me into the server,

30:36.000 --> 30:38.000
the connections are coming from my set of values.

30:38.000 --> 30:39.000
Yes.

30:39.000 --> 30:41.000
Join the variables, right?

30:41.000 --> 30:42.000
Yes.

30:42.000 --> 30:44.000
Yes.

30:44.000 --> 30:45.000
Yes.

30:45.000 --> 30:47.000
Using the rest API, you can access that information.

30:47.000 --> 30:49.000
Yeah.

30:49.000 --> 30:52.000
Yeah.

30:52.000 --> 30:53.000
Alex.

30:53.000 --> 30:55.000
So it's important to share it.

30:55.000 --> 30:57.000
Do you need to mention that two screws are 9-2,

30:57.000 --> 30:58.000
with all variables working?

30:58.000 --> 30:59.000
Yes.

30:59.000 --> 31:00.000
So, so this is a well, yes.

31:00.000 --> 31:02.000
This is available in router 9-2 and shell 9-2,

31:02.000 --> 31:06.000
but your server can run 8-8 for whatever.

31:06.000 --> 31:07.000
So.

31:07.000 --> 31:08.000
Question.

31:08.000 --> 31:10.000
What are you doing in your configuration of route,

31:10.000 --> 31:13.000
or not so I can switch over to the standby route

31:13.000 --> 31:14.000
or your mobile call.

31:14.000 --> 31:16.000
And now the local one is a 3-2.

31:16.000 --> 31:17.000
Yes.

31:17.000 --> 31:19.000
You might as well query for my next set.

31:19.000 --> 31:20.000
Next.

31:20.000 --> 31:21.000
The next section.

31:21.000 --> 31:22.000
Not a query.

31:23.000 --> 31:24.000
Yes.

31:26.000 --> 31:27.000
That's something.

31:31.000 --> 31:32.000
Yeah.

31:32.000 --> 31:33.000
I understand the use case.

31:33.000 --> 31:35.000
That's something we should probably think about.

31:35.000 --> 31:36.000
Yeah.

31:36.000 --> 31:37.000
That's true.

31:37.000 --> 31:38.000
Yeah.

31:40.000 --> 31:41.000
Okay.

31:41.000 --> 31:42.000
Thanks.

31:42.000 --> 31:44.000
Thank you.